I did not change it and I have yet to get a good reason from the person
who did. I have explained why it was wrong to change, but I guess things
will have to start crashing again when Linus accepts changes that I never
looked at or discussed.
Take it up with ManDrake Linux folks, it was there person that submitted
the change directly. I have VETOed the change, that only works in an
environment that respects boundaries and specialities.
I do not like the final changes that are in pre9-final.
There appears no valid reason for the change.
The one line delete and replace ment for the extra 20 (twenty) is bloat.
The change dorks up the modes if it PCI or Legacy.
Since ALL modern PCI-IDE chipsets that are onboard do not behave in native
mode because the first 4 PCI BARS are empty (is everyone listening?)
This is not "native mode" but "compatable mode".
Only devices that fill the first for BARS with the legacy IO's can claim
"native"; regardless, I am sorry that your system is crapped out.
Bitch Linus and not me
Cheers,
On Thu, 5 Oct 2000, Martin Diehl wrote:
>
> 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/
>
Andre Hedrick
The Linux ATA/IDE guy
-
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