[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#520928: linux-image-2.6.26-1-686: PIIX4 /dev/hda performance regression (10x times, DMA dissabled)



On 10-19 03:07, Ben Hutchings wrote:
> On Mon, 2009-03-23 at 18:36 +0100, root wrote:
> > Package: linux-image-2.6.26-1-686
> > Version: 2.6.26-13lenny2
> > Severity: important
>
> > So it looks like there is some blacklist (in piix modules) for this server board,
> > and kernel uses generic (and non-dma) module for ide. But with 2.6.18-686 it was working.
> 
> However, this blacklist has been present since before Linux 2.6.12, so
> it doesn't really explain the change.
Hmm, i checked in git, and you are right, it is for long time (with small modification).
But as I already stated in Etch's 2.6.18-686 dmesg doesn't containt,
messages which are in 2.6.26. But according to sources they should be
excetly the same. So for some reason (API interfaces, PCI read procedures)
it is not blacklisted on older kernel.

> 
> > Additionally I probably have newset BIOS possible.
> > 
> > Mayby this is because of broken write cache flushing?
> [...]
> 
> What do you mean?

I just can't find erratum for this chipset so I don't know what was reason
for blacklisting this pci device id + rev. I was hypothetising
this is due to the broken "cache flush" support. So it (but in hw) can
potentilly make data losses. So for safety it is using slower mode.

But now i know it is something to do with UDMA directly.



> > As far as I know rev 03 is blacklisted for some reason. Is there a way to force
> > dma?
> 
> I expect that you can do this using hdparm, but I wouldn't recommend it.

And i don't want to experimate in this way.

What i want to say that when i was using 2.6.18 i have no problem with
performance, and no data losses, or any strange message, any DMA errors,
any incorect CRC checksums, etc.

Mayby it was problem in older BIOSes. I had no problem, even in older version
of BIOS. No i have the newest BIOS, and still it should be no problem.
(and in fact booting on 2.6.18 and testing it shows it is working correclty
in UDMA).
I checked few times data, and there was no silent data coruption.

Can it be "false positive"? I can't find erratum document, so i can't
verify if this is problem with my hardware or with implementation
of erratum in linux kernel. Eventually erratum can state in what
condition it is not safe to use UDMA, and i can check if
this conditions are met or not.



-- 
Witold Baryluk
JID: witold.baryluk // jabster.pl

Attachment: signature.asc
Description: Digital signature


Reply to: