lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4AA1ACF8.7030101@kernel.org>
Date:	Sat, 05 Sep 2009 09:12:40 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Tim Blechmann <tim@...ngt.org>
CC:	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Re: 2.6.31-rc5 regression: hd don't show up

Tim Blechmann wrote:
>>>>>>> booting the machine today, one hd is missing again ... bootlog attached
>>>>>> Hmmm... strange.  I don't really see how it could be escaping.  Can
>>>>>> you please apply the attached patch?  It still won't change the
>>>>>> behavior but should be able to catch where it's escaping.
>>>>> attached you find two bootlogs, for a correct boot, and with one hd
>>>>> missing ...
>>>> Heh heh, this is getting a bit embarrassing.  Seems like I wasn't
>>>> looking at the right path.  Can you please try this one too?  If it
>>>> says "XXX D7 pulldown quick exit path" and then succeed to probe,
>>>> that's the previous failure case so you don't need to keep trying to
>>>> reproduce the problem.
>>> i've attached the two boot logs again ...
>> Okay, it was another wrong guess.  Can you please try this one?
> 
> unfortunately, i haven't been able to get a bootlog of a failure the
> issue after rebooting like 20 times with yesterday's linus/master.
> once i couldn't boot, since the root hd wasn't found, so i don't think,
> the issue is solved, it just doesn't show very frequently ...
> 
> the bootlog of a working system is attached, if i experience another
> issue, i will send you another bootlog. since i am out of town for a few
> days, it may take some time, though ...

Alright, please keep me posted.  Another possibility is that it's
timing related and the PHY goes down briefly post-reset.  I think I've
found the code path but not sure yet and given how many times my hunch
has been wrong on this case, not too confident either.  Anyways, if
it's timing related, too many printks could have thrown it off.  If
you can't reproduce the failure with the previous patch, please try
this one and see whether it prints out "XXX: clearing to
ATA_DEV_NONE" on failure.

Thanks.

-- 
tejun

View attachment "nodev-debug-3.patch" of type "text/x-patch" (540 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ