Re: totally random "VFS: Cannot open root device"

[Tejun Heo <htejun@gmail.com>]

Jeff Garzik wrote:
> Tejun Heo wrote:
> 
>> Jean-François Stenuit wrote:
>>
>>> Hi Tejun,
>>>
>>> Thanks for taking the time to check.
>>>
>>> Output of your trace with ata_piix.override_PCS=0
>>>  1st boot : success : combined=0 orig_mask=0x11
>>>  2nd boot : success : combined=0 orig_mask=0x11
>>>  3rd boot : failure : combined=0 orig_mask=0x0
>>>  4th boot : failure : combined=0 orig_mask=0x0
>>>  5th boot : failure : combined=0 orig_mask=0x0
>>>  6th boot : failure : combined=0 orig_mask=0x0
>>>  7th boot : success : combined=0 orig_mask=0x11
>>> Output of your trace with ata_piix.override_PCS=1
>>>  1st boot : success : combined=0 orig_mask=0x0
>>>  2nd boot : success : combined=0 orig_mask=0x0
>>>  3rd boot : success : combined=0 orig_mask=0x0
>>>  4th boot : success : combined=0 orig_mask=0x0
>>>  5th boot : success : combined=0 orig_mask=0x0
>>>  6th boot : success : combined=0 orig_mask=0x0
>>>  7th boot : success : combined=0 orig_mask=0x0
>>>  8th boot : success : combined=0 orig_mask=0x0
>>>
>>> Looks like you have found a fix/workaround for this bug (but it still 
>>> does not give the reason why it's failing).
>>>
>>
>> It probably is a BIOS issue.  The weird thing though is that the port 
>> works fine with its corresponding ENABLED bit cleared.  Anyways, if it 
>> works by ignoring the ENABLED bit, ignoring should just be fine.
>>
>> 0602, can you verify this workaround works on your machine too?
>>
>> Jeff (Hi!), if 0602 also confirms that this workaround works, I'll 
>> submit a patch to make ata_piix ignore PCS values on ICH5's.  How does 
>> that sound to you?
> 

Hi, Jeff.

> 
> I am being dragged into this thread with little background info.  Here's 
> some data points that may be relevant:
> 
> * until very recently, ata_piix's definitions for the ENABLED and 
> PRESENT bits was reversed.

I saw that in the log but it doesn't seem to be the reason for this as 
PCS reports 0x00 on failure cases.  None of ENABLED/PRESENTS bits is set.

> * the PRESENT bit reflects a device present status just like the SStatus 
> phy register does.  This implies that one must wait, before assuming 
> that the PRESENT bit's absence truly indicates absence of a device.
> 
> * the device may be in various power management states.  It may be wise 
> to issue COMRESET by
>     - clear ENABLED bit
>     - set ENABLED bit
>     - wait for device to appear
>     - if no device appeared, clear ENABLED bit
> 
> In sum, think about the underlying SATA phy registers, and how they 
> logically map to the PCS bits.

Interestingly, it seems that those problemetic ICH5's seem to work 
happily on ports where ENABLED bits are cleared.  Turning off ENABLED 
bits on my ICH7 certainly disables the ports.  It almost seems that the 
ENABLED bits are read incorrectly even though they are set correctly.

I'm a little bit scared about turning on or off those bits.  As probing 
a disabled/non-present port doesn't cause any problem (we're doing it 
already for combined cases) and simply ignoring the ENABLED bits does 
cure the symptom.  IMHO, it's best to just ignore those mysteriously 
zero but nevertheless working bits.  I'll submit a patch to ignore 
ENABLED bits on ICH5's.  If you don't like it, please NACK it; then, 
I'll try to cook something up which dances with the ENABLED bits.

Thanks.

-- 
tejun