Re: Regression 3.2 -> 3.3-rc1 10 sec hang at boot and resume,COMRESET failed

[Brian Norris]

On Mon, Feb 6, 2012 at 8:19 AM, Tejun Heo <tj@xxxxxxxxxx> wrote:
> Hello,
>
> (cc'ing Jian Peng, hi)

Hello,

Jian Peng is no longer working on this project; I have taken over for his work.

> On Mon, Feb 06, 2012 at 12:42:56PM +0800, Lin Ming wrote:
>> On Mon, 2012-02-06 at 12:15 +0900, Norbert Preining wrote:
>> > On Mo, 06 Feb 2012, Lin Ming wrote:
>> > > Only this patch on top of HEAD *without* reverting 7faa33da9b7.
>> >
>> > Works. Am I right that it differs from 7faa33da9b7 only in that
>> > the later also changes:
>>
>> Right.
>>
>> Tejun,
>>
>> This regression is caused by 7faa33da9b7(ahci: start engine only during
>> soft/hard resets).
>>
>> But I can't reproduce it.
>>
>> What's your guess?
>
> Urgh.... yeah, following standard can sometimes be silly thing to do.
> Jian, I think we'll have to add a flag for your controller and revert
> to the original behavior for others.  How can your controller be
> distinguished?

Our controller utilizes the ahci_platform.c driver and does not have a
distinguishing interface ID (e.g., PCI ID). It is maintained in an
out-of-tree distribution, but we would like to have a
standards-compliant solution in mainline so that we do not have to
support a fork of the main codebase.

Is there any possibility of debugging this regression instead of
effectively reverting it for mainline? Or perhaps can I have better
information regarding the hardware on which this regression is seen?
With some time, I can try to debug it further.

I see the following options:
(1) implement a flag that can be passed through ahci_platform; this
would not be very useful, as we would still have to tweak the driver
out of tree.
(2) Drop the fix entirely. This is a spec. violation, but we can
simply try to maintain the fix out-of-tree.
(3) Debug Norbert's hardware problems.

(1) or (2) aren't ideal, and they are effectively very similar. The
only advantage to (1) is that there will be at least some illusion of
our controller's support in future kernel development.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/