[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <45B2C6E1.9000901@shaw.ca>
Date: Sat, 20 Jan 2007 19:50:25 -0600
From: Robert Hancock <hancockr@...w.ca>
To: Chr <chunkeey@....de>
Cc: Alistair John Strachan <s0348365@....ed.ac.uk>,
Jeff Garzik <jeff@...zik.org>,
Björn Steinbrink <B.Steinbrink@....de>,
linux-kernel@...r.kernel.org, htejun@...il.com,
jens.axboe@...cle.com, lwalton@...l.com
Subject: Re: SATA exceptions with 2.6.20-rc5
Chr wrote:
>> Could you (or anyone else) test what happens if you take the 2.6.20-rc5
>> version of sata_nv.c and try it on 2.6.19? That would tell us whether
>> it's this change or whether it's something else (i.e. in libata core).
>
> Ok, did that! (got a fresh 2.6.19 tar ball, and used 2.6.20-rc5' sata_nv.c
> with the oneliner in libata_sff.c)
>
> And surprise.................... after one hour uptime, there is not even one
> sata exceptions in dmesg! (I'll report back tomorrow...)
That is interesting, indeed.. If that holds up then I assume some other
change in 2.6.20-rc is either causing or triggering this problem. It
would be useful if you could try git bisect between 2.6.19 and
2.6.20-rc5, keeping the latest sata_nv.c each time, and see if that
gives any indication. If not, just trying some of the different
2.6.20-rcX versions may be useful.
Before that, though, can you try making this change I suggested below in
2.6.20-rc5 and see if the problem still shows up?
>
>> Assuming that still doesn't work, can you then try removing these lines
>> from nv_host_intr in 2.6.20-rc5 sata_nv.c and see what that does?
>>
>> /* bail out if not our interrupt */
>> if (!(irq_stat & NV_INT_DEV))
>> return 0;
>>
>> as that's the difference I'm most suspicious of causing the problem.
>
-
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