Bug 955
Summary: | Nvidia Nforce2 interrupt handling problems | ||
---|---|---|---|
Product: | Drivers | Reporter: | Andy Dustman (andy-kernel.388488) |
Component: | PCI | Assignee: | Andy Grover (andrew.grover) |
Status: | REJECTED DUPLICATE | ||
Severity: | normal | CC: | rvdboom |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.0-test1 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
boot test 1
boot test 2 boot test 3 boot test 4 boot test 5 boot test 6 boot test 7 boot test 8 .config |
Description
Andy Dustman
2003-07-17 22:28:31 UTC
Created attachment 558 [details]
boot test 1
In this test, local APIC, IO-APIC, and ACPI are all enabled in the kernel. ACPI
reports IRQs 20-22 are disabled, but assigns devices there anyway. This later
produces some "irq xx: nobody cared!" messages and backtraces for the ALSA
intel8x0 driver (for Nvidia Nforce2 sound) and radeon. In addition, the 3c59x
doesn't work, though this is not obvious from this dmesg output.
Created attachment 559 [details]
boot test 2
This uses the same kernel as before, but adds pci=noacpi. This kernel runs for
awhile, i.e. sound and network and DRI on the radeon all work, but after a few
minutes of running something that exercises all three (i.e. Enemy Territory),
the network connection is lost, and the kernel reports:
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out, tx_status 00 status e601.
diagnostics: net 0cc0 media 8080 dma 0000003a fifo 0000
eth0: Interrupt posted but not delivered -- IRQ blocked by another device?
Flags; bus-master 1, dirty 5780(4) current 5780(4)
Transmit list 00000000 vs. de955480.
Note that the intel8x0 audio and 3c59x both share the same interrupt.
Created attachment 560 [details]
boot test 3
In this test, noapic is used in an attempt to turn off the APIC. This doesn't
work. It causes a spew of this message:
APIC error on CPU0: 40(40)
Created attachment 561 [details]
boot test 4
noapic and pci=noacpi in a further attempt to disable the ACPI. Note that some
of the APIC initialization message occur before the kernel command line is
printed, perhaps before it is parsed. The system locks up hard after a minute
or two of Enemy Territory, i.e. SysRq is unresponsive.
Created attachment 562 [details]
boot test 5
noapci pci=noacpi mem=nopentium. Same results as #4.
Created attachment 563 [details]
boot test 6
At this point, I decide that the only way to really disable the APIC is to turn
it off in the kernel. Build, install, reboot with no additional parameters.
Once again the 3c59x is broken (transmit timed out, IRQ blocked by another
device?).
Created attachment 564 [details]
boot test 7
As with the previous test but adding pci=noacpi. System locks hard after a few
minutes of game play.
Created attachment 565 [details]
boot test 8
Like previous test, but using mem=nopentium pci=noacpi. Another lock-up after a
brief moment of game play. I'm out of ideas at this point.
Created attachment 566 [details]
.config
Kernel config used for tests 6-8. The one for 1-5 is the same except with APIC
and IO-APIC enabled.
Additional note: With kernel 2.4.21-pre6 (with patches, it's Gentoo gs-sources)
and ATI's binary driver, it works pretty well, with just some video
artifacts/rendering errors, and the occassional soft lockup (sometimes frees up
on it's own, other times I have to kill, sometimes with sig 9).
I can verify at least part of this bug report. Noted on LKML to which I got no response, message titled "APIC & ACPI on EPoX 8RDA+ (nForce 2)"; http://marc.theaimsgroup.com/?l=linux-kernel&m=105802788025190&w=2 However, this machine is completely stable with a recent BIOS and the proprietary NVIDIA drivers. I haven't played ET yet, but games like Quake3, UT2003 and Tribes2 all run fine. The symptoms are identical, except that with APIC the kernel simply doesn't boot at all. With ACPI & pci=noacpi everything seems to work fine. Otherwise, devices such as my USB, IEEE1394 and USB 2.0 onboard do not get assigned an IRQ and fail to initialise. Andy, make sure your board's BIOS is the most recent available and try again. I did not find that ACPI causes any problems except when it is given control of PCI routing. "nForce 2 chipset" is too vague, who retails your board? If it's EPoX, maybe this board should be blacklisted until this issue is resolved. I'm pretty sure this is an ACPI bug. *** This bug has been marked as a duplicate of 10 *** *** Bug 929 has been marked as a duplicate of this bug. *** |