linux-kernel - Re: 2.6.29 regression: ATA bus errors on resume

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: <4A2424A2.5020704@gmail.com>
Date:	Mon, 01 Jun 2009 20:57:38 +0200
From:	Niel Lambrechts <niel.lambrechts@...il.com>
To:	Tejun Heo <tj@...nel.org>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"linux.kernel" <linux-kernel@...r.kernel.org>,
	Theodore Tso <tytso@....edu>
Subject: Re: 2.6.29 regression: ATA bus errors on resume

Niel Lambrechts wrote:
> On 05/27/2009 02:07 AM, Tejun Heo wrote:
>> The above is the offending failure and all three failfast bits are
>> set.  This corresponds to the following ATA exception.
<snip>
>> Can you please try the attached patch?  It takes suspend/resume cycle
>> out of the equation and simply induces artificial failure to readahead
>> requests.  It's currently set to fail every 40th readahead.  Feel free
>> to adjust the frequency as you see fit.  catting files into /dev/null
>> would trigger readahead to kick in.  Can you reproduce filesystem
>> failure with this alone?
>>    
>
> No corruption, I tried cat on an entire directory of mp3s, then also
> started X, but there the messages debug output got fairly drastic so I
> didn't care to continue for an entire day.
>
> It did trigger the "XXX ...failing readahead" message nearly 300
> times, and I also did a s2disk and resume cycle in there - so I hope
> this is enough for us to conclude that it is not the cause. 

Hi Tejun,

Did you perhaps have any time to look into my feedback around the
readahead patch?

>From my side, I tried on Saturday to bisect this problem again, doing
5-8 hibernates per each bisect from 2.6.28. I stopped at 2.6.30-rc2 due
time (or fatigue), and did not manage to replicate the problem at all
which is strange since I was playing audio, doing finds and even doing
an entire dd of the root partition. I saved the bisect logs so perhaps I
can continue to see if the problem becomes more prevalent in later
versions - the first time it ever happened to me was somewhere in 2.6.29
originally.

The other interesting thing was to see that "hard resetting link"
messages seem to first start appearing at v2.6.29-rc7 or perhaps rc8. Is
it worth trying to track down the commit that lead to this?

Do you have any other debug patches to try, or should I try to delve
deeper into finding commits that can be reverted? I'm running out of
ideas, I even tried to find later firmware for my drive, but I seem to
be on the latest level.

Thanks for the help so far!

Niel


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