Re: APIC/LAPIC hanging problems on nForce2 system.

[Bartlomiej Zolnierkiewicz]

Hi,

On Thu, 06 Jan 2005 10:03:44 +0100, Prakash K. Cheemplavam
<prakashkc@xxxxxx> wrote:
> Martin Drab schrieb:
> > On Wed, 5 Jan 2005, Prakash K. Cheemplavam wrote:
> >
> > ...
> > DEBUG: pci_fixup_nforce2() called.
> > DEBUG:   nForce2 revision byte = 0xC1.
> > DEBUG:   fixed value = 0x9F01FF01.
> > DEBUG:   current value = 0x8F0FFF01.  <---------------
> > ...
> >
> > So that means, that the device doesn't have the "C1 Halt Disconnect"
> > enabled at that point, and, though, no fixup is done. However, if you take
> > a closer look at the result of "lspci -xxx" (attached as "lspci-xxx.log"),
> >
> > 00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different version?) (rev c1)
> > ...
> > 60: 08 00 01 20 20 00 88 80 10 00 00 00 01 ff 0f 9f <-------
> > ...
> >
> > you'll notice, that all of a sudden that bit 28 of PCI.0x6c *is set!! That
> > means, that sometimes later, after the pci_fixup_nforce2() is called,
> > something, smewhere, somehow has to set the bit to 1. But this part in the
> > arch/i386/pci/fixup.c prevents it.
> 
> You are not by chance using athcool or something to enable disconnect?
> 
> >
> >         /*
> >          * Apply fixup only if C1 Halt Disconnect is enabled
> >          * (bit28) because it is not supported on some boards.
> >          */
> >           vvvvvvvvvvvvvvvvv
> >         if ((val & (1 << 28)) && val != fixed_val) {
> >                 printk(KERN_WARNING "PCI: nForce2 C1 Halt Disconnect fixup\n");
> >                 pci_write_config_dword(dev, 0x6c, fixed_val);
> >         }
> >
> > So my question is: Is the condition necessary? If there really are boards,
> > that don't support this, then is would probably have to be a more
> > sophisticated test, or the fixup would have to be called again later, when
> > the flag is set. BTW.: Any clue on what could possibly set the flag?
> 
> Well, I also think it is quite stupid to only apply the fix if
> disconnect is enabled at boot time and don't apply it if it is not. The
> kernel dev responsible for it is rather pedantic: Fix only when needed,

Hey, I only coded it because I was getting a lot of false IDE bugreports... ;-)

> ie don't apply anything in a foreseeing way (prevent what could break),
> if change something in userspace, do it correctly. (not exact words of
> course, but the conclusion of it.) Ie if you enable disconnect outside
> of bios and kernel, you should also set the fix by hand...
>
> Easy workaround: Enable disconnect in bios, if possible, then the kernel
> will fix it for you...
> 
> I admit there is logic behind the dev's point of view, nevertheless it
> is not a very near-to-life-and-make-it-simpler-for-the-user logic. There
> is often a difference in point of view of kernel dev and average user...

Changing _only_ "fixup" bits seems like a reasonable compromise IMO.
Could you (or Martin) make a patch and submit it to -mm for testing?

Bartlomiej
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/