Re: APIC/LAPIC hanging problems on nForce2 system.

[Martin Drab]

On Thu, 6 Jan 2005, Prakash K. Cheemplavam 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?

Yes, in fact I am. So that enables it then, OK.
 
> > 
> >         /*
> >          * 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,
> 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...

That assumes that the BIOS allows to enable it.

> 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...

Right. And how about to fix it, but leave the disconnect bit in its 
previous state. Would it help? Something like

	fixed_val = (val & (1<<28)) | (fixed_val & ~(1<<28));
	if (val != fixed_val) {
		printk(KERN_WARNING "PCI: nForce2 C1 Halt Disconnect fixup\n");
		pci_write_config_dword(dev, 0x6c, fixed_val);
	}

Martin

-
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/