Aha. Excellent.
> lspci tells:
>
> 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 81)
^^^^^^
I think you actually do have an 8363, and so some sort of fix is
probably needed.
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
> 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev
> 40)
> /cut/
>
> But in fact mine is a *VT8365* (KM133) Northbridge.
>
> from pci-pc.c:
> { PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA,
> PCI_DEVICE_ID_VIA_8363_0, pci_fixup_via_northbridge_bug },
> ^^^^^^^^
> { PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA,
> PCI_DEVICE_ID_VIA_8622, pci_fixup_via_northbridge_bug },
> { PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA,
> PCI_DEVICE_ID_VIA_8361, pci_fixup_via_northbridge_bug },
> { PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA,
> PCI_DEVICE_ID_VIA_8367_0, pci_fixup_via_northbridge_bug },
> { 0 }
>
> Maybe because of this, the kernel thinks mine is a 8363, and applies the fix,
> but in fact it doesn't need to be applied, or does it? I'm confused %:I
I think your system does need the fix, but only bit 7 needs clearing.
Not all of it. If memory serves me, clearing bit 7 was the
experimentally-determined fix for the bug, however, VIA said that all 3
bit needed clearing. Perhaps this should be looked into, as I
experienced the same screen corruption bug on the same chipset. I have
yet to try my own proposed fix on it, however :-/
I'll do this within the next week or so, and if it works for me, I'll
propose a patch to only clear bit 7, at least on these chips. Sound
good to you?
-- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell He's alive. He's alive! Oh, that fellow at RadioShack said I was mad! Well, who's mad now? -- Montgomery C. Burns - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/