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: <4A25EA78.7070705@kernel.org>
Date:	Wed, 03 Jun 2009 12:14:00 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Niel Lambrechts <niel.lambrechts@...il.com>
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

Hello, Niel.

Niel Lambrechts wrote:
> Did you perhaps have any time to look into my feedback around the
> readahead patch?

Yeah, I've been thinking about it and am a bit out of ideas, so no
immediate follow-up.

>>>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.

Given the non-deterministic nature of the failure, I think bisection
would be quite difficult.  I think the best way to diagnose the
problem is to track down the owner of the failed request.  It has
FAILFAST set and yet the issuer fails to deal with an error condition
which is expected when FAILFAST is set.  I'll prep a patch to track
request / bio failure.

Thanks.

-- 
tejun
--
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/