linux-kernel - Re: [PATCH, RFT, v4] sata

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, 26 May 2007 16:56:53 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	dean gaudet <dean@...tic.org>, Dave Dillow <dave@...dillows.org>
CC:	linux-ide@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH, RFT, v4] sata_mv: convert to new EH

dean gaudet wrote:
> On Fri, 25 May 2007, Jeff Garzik wrote:
> 
>> Already uncovered and fixed a few bugs in v3.
>>
>> Here's v4 of the sata_mv new-EH patch.
> 
> you asked for test results with 2.6.21.3 ... that seems to boot fine,
> and i've tested reading from the disks only and it seems to be working
> fine.  ditto for 2.6.22-rc3.
> 
> but 2.6.22-rc3 + your v4 patch fails... i'll send you the serial console
> outputs offline.

Well, I have the same hardware as dean, and do not see the 
BUG_ON/WARN_ON traces that he sees.  These are the same two code 
locations that caused spewage before.  This only difference I see is 
that he is testing with an NCQ-capable disk, and I am not -- which could 
be a very significant difference.  Dave also appears to have an 
NCQ-capable disk.

Dave's output (sent privately to me) was different -- errors and 
corruption -- rather than the BUG_ON/WARN_ON stuff both he and dean sent 
in March 2007, which is interesting.

Dave, any chance you could try 2.6.22-rc3 + my v4 patch, on a different 
hard drive?  Preferably a non-Maxtor, or at least not another Maxtor 
6L200S0.  If that's a big deal, don't worry about it.  I just want to 
rule out buggy firmware and/or bad hard drive in your case.

dean's output (backtraces matching March 2007 reports) was what I 
expected, and if I can reproduce that with an NCQ-capable disk locally, 
I should be able to fix it from there without trouble.  Probably just 
some hardware bits accidentally kicking into NCQ mode, when they should not.

	Jeff

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