Hi,
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?
Comments?
Regards
Martin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Oct 07 2000 - 21:00:15 EST