[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.63.0707102024300.4142@trinity.phys.uwm.edu>
Date: Tue, 10 Jul 2007 20:31:11 -0500 (CDT)
From: Bruce Allen <ballen@...vity.phys.uwm.edu>
To: Jeff Garzik <jeff@...zik.org>,
Kai Makisara <Kai.Makisara@...umbus.fi>,
Douglas Gilbert <dougg@...que.net>
cc: Mark Lord <liml@....ca>, David Greaves <david@...eaves.com>,
Tejun Heo <htejun@...il.com>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Jan Dvorak <fermentol@...il.com>,
Klaus Fuerstberger <kfuerstberger@...or.de>,
Bruce Allen <bruce.allen@....mpg.de>,
Robert Hancock <hancockr@...w.ca>
Subject: Re: SMART problems in 2.6.22
On Tue, 10 Jul 2007, Douglas Gilbert wrote:
> Kai Makisara wrote:
>> I have done some more debugging on this one. An easy way to reproduce
>> the
<SNIP>
>> The log shows that the sense data returned by the commands differ: with
>> 2.6.22 the bytes 4f and 2c (tf.lbam and tf.lbah) are not returned. Both
>> of the status commands fail to return these bytes but the tests in
>> smartctl are more strict for the second case. This is why the second
>> status command seems to be failing.
<SNIP>
> Kai, Thanks for the analysis.
<SNIP>
> So when smartmontools sees 0 and 0 in those positions it pulls out the
> red card for that device. My guess is that libata in lk 2.6.22 is
> corrupting those FIS device to host register values.
Kai, Doug: thank you very much for tracking down the source of this
problem.
Jeff: OK, from what I am reading here I think that this is a genuine
libata/kernel bug. But I'm out of my depth here, so the ball is in your
court. Hopefully you'll understand what's going on and how to fix it.
Cheers,
Bruce
-
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/
Powered by blists - more mailing lists