linux-kernel - Re: SATA exceptions with 2.6.20-rc5

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]

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/