[lkml]   [2000]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectIDE problems 2.4.0-t9p8 and later

the following change from t9p7->t9p8 in ide-pci.c

- if ((dev->class & ~(0xfa)) != ((PCI_CLASS_STORAGE_IDE << 8) | 5)) {
+ if ((dev->class & ~(0xff)) != (PCI_CLASS_STORAGE_IDE << 8)) {

causes a lot of trouble to me. Seems to be the same thing, which has
already been reported to l-k, but to my best knowledge it's unsolved.
So I had a look into this issue:
My IDE-Chipset is a SiS 5513 integrated into SiS 5591 Northbridge.
dev->class is 0x01018a. Hence the old test (there from 2.2.* to
2.4.0-t9p7) said "true" (due to the "|5") while the new one says "false".
So the chipset mode is now identified "native" although it's in
compatibility mode. PCI-IRQ 14 is used for both ports instead of IRQ 15
for ide1 in compatibility mode. Needless to say, everything (including
BM-DMA) works fine for me before t9p8 but now hangs when initializing the
devices on the 2nd ide port. (hdc/hdd: lost interrupt). Reverting the
changes cures everything.
I've double checked the crucial "|5" change against the documentation
for the SiS 5591 chipset, which I have here. Value=0x8a in PCI-register 9
definitely means "bus master capable" (0x80) and "operating mode is
programmable" (0x0a) and "compatibility mode" (~0x05) for both channels.
So the old code was the correct one.
I've seen several complains on this to l-k during the last days which
appeared to be misunderstood as broken changes wrt PCI_CLASS_STORAGE_IDE
(the leading 0x0101 in dev->class). The crucial point however is the
"|5" on the trailing byte.
So, may I ask if there was some good reason for this change?
What have I missed?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:39    [W:0.036 / U:6.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site