Messages in this thread | | | Date | Sun, 6 Jun 2004 10:04:56 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: 2.6.7-rc1 breaks forcedeth |
| |
On Sun, 6 Jun 2004, Manfred Spraul wrote: > > I'll add that, but it's only a partial fix: what if ehci_hcd is loaded > before the forcedeth driver?
Yes. We've had those kinds of problems before, and sometimes you need a PCI quirk to disable a screaming device. See the PIIX3 USB quirk in drivers/pci/quirks.c for example.
The good news is that it's fairly rare. Devices don't generally have pending interrupts, since they haven't been turned on, or at least the BIOS has finished doing whatever it was doing to them. The USB thing happens because the BIOS leaves the USB controller active (probably for keyboard usage) and USB normally generates interrupts whether anything happens or not.
> Luis, could you apply the patch and boot with it? It should print > something like > > forcedeth: irq line 11, Status 0x00000020, Mask 0x00000020 > > If mask and status are really not zero, then it explains your problems.
It could be something else on the NForce thing too, of course. Including just having ACPI get confused about the polarity of the interrupt (if the interrupt is _off_, but we've told the irq controller the wrong polarity, the controller will obviously think that it is _on_).
But it's usually a good thing to try to reset a device as much as possible when you probe for it. If for no other reason than the fact that then you'll have it in a "known state", and hopefully there won't be as many surprises..
Linus - 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/
| |