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
signature.asc
Description: Digital signature