Bug 6591
Summary: | VIA K8T800 SMP: kernel randomly loses all interrupts from my UHCI or SATA controllers | ||
---|---|---|---|
Product: | ACPI | Reporter: | Nicholas Miell (nmiell) |
Component: | Config-Interrupts | Assignee: | acpi_config-interrupts |
Status: | REJECTED INSUFFICIENT_DATA | ||
Severity: | normal | CC: | acpi-bugzilla, bunk, sergio |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.16 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
dmesg from boot
/proc/interrupts dmesg diff, post patch lspci -vvv output |
Description
Nicholas Miell
2006-05-20 23:07:09 UTC
Please make sure you are using latest BIOS. Please try acpi=off to make sure this is acpi related issue. I have the latest non-beta BIOS for this system. I can't reproduce this with acpi=off. (I can't reproduce with noapic, either.) However, I'm not able to reproduce it reliably even with ACPI on, and when I boot the system with acpi=off my UHCI controllers and my graphics card don't get interrupts (the error is something similar to "kernel: PCI: No IRQ known for interrupt pin A of device 0000:01:00.0. Probably buggy MP table." for each the devices), so the difference in configuration may be a contributing factor. >This has been going on for a while (since mid-2005, at least), and it hasn't
>magically fixed itself, so I'm finally filing a bug
Does it work before? If you remove USB support in kernel, can you see
interrupt lost on SATA?
> Does it work before? As far as I know, yes, but I didn't own any SATA disks and the SATA controller was disabled in the BIOS. I also don't remember if there was a time period when I was using SATA and this wasn't happening. > If you remove USB support in kernel, can you see interrupt lost on SATA? I tried temporarily blacklisting the uhci-hcd and ehci-hcd modules (which prevents them from ever being loaded), and wasn't able to reproduce the error, but, once again, this problem can't be reproduced on demand. I also wrote a little SystemTap script which directly calls unmask_IO_APIC_irq with the SATA controller's IRQ number. If I run this script when I'm not getting any interrupts from the SATA controller, I start getting interrupts again. This suggests to me that the interrupt may be disabled at the IOAPIC level without the kernel's knowledge. I also wrote another SystemTap script which records stack traces everytime unmask_IO_APIC_irq or mask_IO_APIC_irq are called in order to determine if the IOAPIC is actually disabling the IRQ without the kernel's knowledge. However, whenever I leave this script running, I've never been able to reproduce problem. This suggests to me that their may be IOAPIC access timing issues involved. > VT8237 PCI bridge please try this patch http://lkml.org/lkml/diff/2006/9/7/235/1 and see this bug http://bugme.osdl.org/show_bug.cgi?id=6419 This problem predates the following commit: commit 75cf7456dd87335f574dcd53c4ae616a2ad71a11 Author: Chris Wedgwood <cw@f00f.org> Date: Tue Apr 18 23:57:09 2006 -0700 Subject: [PATCH] PCI quirk: VIA IRQ fixup should only run for VIA southbridges Prior to this commit, quirk_via_irq was running on my machine but not doing anything (no "PCI: VIA IRQ fixup for %s, from %d to %d\n" message was printed at boot.) Were I to apply the suggested patch, it still wouldn't do anything (the conditions for it's activation have gotten more restrictive, not less), so I'm not going to waste my time configuring and building a kernel to test it. (In reply to comment #6) > Prior to this commit, quirk_via_irq was running on my machine but not doing > anything (no "PCI: VIA IRQ fixup for %s, from %d to %d\n" message was printed > at boot.) before this patch (http://lkml.org/lkml/2006/4/19/16) any_VIA_PCI was quirked, so yours too . yes "PCI: VIA IRQ fixup for %s, from %d to %d\n" message was printed at boot. you can just apply the patch and just make bzImage and install (which is cp arch/boot/bzImage over /boot/vmlinuz-2.6.17) and reboot, don't need to recompile all over again. Last thing, can you attach your dmesg and cat /proc/interrupts Created attachment 9039 [details]
dmesg from boot
My dmesg, as requested.
Created attachment 9040 [details]
/proc/interrupts
/proc/interrupts, as requested.
Looks like I spoke too soon -- the quirk is getting applied to my system. I remember doing something to change whether or not that quirk gets run (see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190309 ), but I don't remember if what I did is similar in result to this new patch. Looks like I'll actually have to configure and build a kernel. I haven't had to do that for months. *sigh* OK, that patch didn't help any, which is consistent with my prior experimentations with that VIA PCI quirk. ok, let me see your dmesg , with patch applied, please Created attachment 9063 [details]
dmesg diff, post patch
OK I need other report vi /etc/X11/xorg.conf Please comment # Load "dri" and see if boot with X without problems, let see if it is a problem with via_agp please use the post past This system doesn't use VIA AGP. I saw this 177: 4143175 0 IO-APIC-level EMU10K1, eth0, radeon@pci:0000:01:00.0 so what hardware have this system ? may you attach "lspci -vvv" and "lsmod | grep via", please ? Created attachment 9080 [details]
lspci -vvv output
[nicholas@entropy ~]$ lsmod | grep via i2c_viapro 43353 0 i2c_core 60993 3 w83627hf,i2c_isa,i2c_viapro sata_via 42821 1 libata 113113 1 sata_via can you reproduce this issue with 2.6.21-rc5 or later? can you reproduce this issue with nmi_watchdog=0? Please reopen this bug if: - it is still present with kernel 2.6.21 and - you can provide the requested information. |