linux-kernel - Re: 2.6.29-rc libata sff 32bit 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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 22 Jan 2009 03:20:13 +0300
From:	Sergei Shtylyov <sshtylyov@...mvista.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Mikael Pettersson <mikpe@...uu.se>,
	Hugh Dickins <hugh@...itas.com>,
	Jeff Garzik <jgarzik@...hat.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, linux-ide@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: 2.6.29-rc libata sff 32bit PIO regression

Hello, I wrote:

>>>>>>  > I've a Dell Precision 670 here (four-year-old EM64T Xeon with 
>>>>>> ata_piix)
>>>>>>  > which doesn't like your commit 
>>>>>> 871af1210f13966ab911ed2166e4ab2ce775b99d
>>>>>>  > libata: Add 32bit PIO support.  Full dmesg (and .config) 
>>>>>> attached, but
>>>>>>  > here's an extract showing the start of the error messages on 
>>>>>> ata2:
>>>>>>             
>>>>> Cool - so we need two different 32bit PIO methods - at least 
>>>>> according to
>>>>> the docs for the AMD we should use entirely 32bit I/O there. Fun fun
>>>>>         
>>>>    Could you refer me to the exact AMD doc that requires that?
>>>>     
>>>
>>> AMD762 page 82, under DevB:1x40 bit 14 and bit 12
>>>   
>>
>>   What exactly AMD-762 document has this? I'm not seeing it in either 
>> stasheet ot software/BIOS design guide. Besides, AMD-762 is a north 
>> bridge and doesn't include IDE.
>
>  Finally found it in the AMD-768 datasheet.
>
>>> "Note: only 32-bit writes to the data port are allowed when this bit is
>>> set."
>>>   
>>  
>>   Now tell me who forces you to set that bit (I assume it's the write 
>> buffer enable) for the ATAPI devices?
>
>   Yes, it's the write buffer enable (about which I have written already).

   IMHO, this is the same situation as with the prefetch -- you want to 
avoid additional data read (write in this case) cycles to with an ATAPI 
device, so you have to turn it off.

MBR, Sergei


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