linux-kernel - Re: [PATCH] libata-sff: fix 32-bit PIO regression

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] [day] [month] [year] [list]

Date:	Mon, 9 Feb 2009 18:14:33 +0000 (GMT)
From:	Hugh Dickins <hugh@...itas.com>
To:	Sergei Shtylyov <sshtylyov@...mvista.com>
cc:	jgarzik@...ox.com, linux-ide@...r.kernel.org,
	linux-kernel@...r.kernel.org, alan@...rguk.ukuu.org.uk, rjw@...k.pl
Subject: Re: [PATCH] libata-sff: fix 32-bit PIO regression

On Mon, 9 Feb 2009, Sergei Shtylyov wrote:
> Hello, I wrote:
> 
> > > When I checked (mounting and listing a CD), about 34% of
> > > commands had slop 2.
> 
> >    Hm, that probably involved the raw block reads. I don't remember the raw
> > sector length off-hand but it may well be just even, not divisble by 4.
> 
>    Oops, I read "listening" instead of "listing". :-/
>    But I thought that listing shouldn't involve anything other than block 
> reads. OTOH, I'm not familiar enough with ISO9660... What commands are you
> seeing (if you have them dumped)?

No, I didn't dump out the commands, just added temporary slop stats
into the xfer32 function, to check what paths were being tested.

That machine is busy running tests now: I could try again when it's
done, what would you recommend for dumping out the commands (remember,
I'm not an ATA developer)?

Though, to be honest, I'd prefer to just let this unlikely subject drop!

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