Bug 2227

Created attachment 2247 [details]
dmesg

Created attachment 2248 [details]
acpidmp

Created attachment 2249 [details]
dmidecode

Created attachment 2250 [details]
/proc/interupts

Created attachment 2251 [details]
/proc/interupts no-acpi

Created attachment 2252 [details]
lspci -vv

please try disable CONFIG_PCI_USE_VECTOR. do your EHCI controller work in acpi 
mode or nonacpi mode?

i disabled CONFIG_CPI_USE_VECTOR
here is the relevant section of dmesg: 

irq 21: nobody cared!
Call Trace:
 [<c010b83a>] __report_bad_irq+0x2a/0x90
 [<c010b930>] note_interrupt+0x70/0xb0
 [<c010bc20>] do_IRQ+0x130/0x140
 [<c0107030>] default_idle+0x0/0x30
 [<c0105000>] _stext+0x0/0x60
 [<c0109e08>] common_interrupt+0x18/0x20
 [<c0107030>] default_idle+0x0/0x30
 [<c0105000>] _stext+0x0/0x60
 [<c0107054>] default_idle+0x24/0x30
 [<c01070d0>] cpu_idle+0x30/0x40
 [<c03a86fc>] start_kernel+0x14c/0x160
 [<c03a8460>] unknown_bootoption+0x0/0x110

handlers:
[<e1907850>] (snd_intel8x0_interrupt+0x0/0x210 [snd_intel8x0])
Disabling IRQ #21

/proc/interupts :

  0:     570288          XT-PIC  timer
  1:       1467    IO-APIC-edge  i8042
  2:          0          XT-PIC  cascade
  8:          2    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 14:      10683    IO-APIC-edge  ide0
 15:         42    IO-APIC-edge  ide1
 19:      42663   IO-APIC-level  <NULL>
 20:      59024   IO-APIC-level  ohci_hcd, eth0
 21:     152238   IO-APIC-level  NVidia nForce2
 22:      50125   IO-APIC-level  ohci_hcd

with acpi=off kernel parameter audio works (somewhat)

This looks more like an audio bug than an ACPI bug. 
Does audio work properly when you boot with "noapic" (note spelling). 
 
> ACPI: PCI Interrupt Link [APCL] enabled at IRQ 21 
> IOAPIC[0]: Set PCI routing entry (2-21 -> 0xc1 -> IRQ 21 Mode:1 Active:0) 
> 00:00:02[C] -> 2-21 -> IRQ 193 
 
active:0 means polarity HIGH.  Curiously, all the PCI interrupts on this box are marked that way, 
which is somewhat unusual.  No problems with eth0 or USB? 
 
177:      26235   IO-APIC-level  ohci_hcd, eth0 
185:      20652   IO-APIC-level  ohci_hcd 
193:     152282   IO-APIC-level  NVidia nForce2 
225:        467   IO-APIC-level  <NULL> 
 
the IRQ was shut down after 99900/152282  interrupts on this IRQ were not claimed by the 
driver.  If ACPI set the polarity incorrectly, then this would have fired at 100000 interrupts -- ie a 
completely quiescent device would have caused an interrupt storm.  This suggest that either the 
device itself has an issue, or that there is something funky on this board with that interrupt line 
being pulled by a device that Linux does not have on that IRQ. 
 
lspci shows that EHCI is on this IRQ as well.  Perhaps you can load the EHCI driver and not the 
sound driver and see if it handles any interrupts? 
 
I'm curious why the snd_intel8x0 driver is handling interrupts for a device called "NVidia nForce2" 
-- maybe that is part of the problem? 
 
So this may have nothing to do with ACPI.  Except that ACPI is the only way to enable the 
IOAPIC on this box.  You can run with ACPI and without the IOAPIC by booting an ACPI-enabled 
kernel with "noapic". 
 
I'm curious if in both apic and "noapic" modes if your ACPI interrupt is working properly -- you 
should see it increment in /proc/interrupts when you press the power button.  (first 
"/sbin/inti.d/acpid stop" to make sure it doesn't shut down your machine. 
 
Can you attach your .config?  I have a similar machine I may be able to try. 
 
it would also be interesting if the system functions properly when you boot in IOAPIC mode with 
"noirqdebug"  this will disable the nobody cared shutdown of the IRQ.  Should not harm other 
devices b/c the IRQ is dedicated to this device.  Observing the rate of change for audio interrupts 
in /proc/interrupts may show if some particular action is cauting a burst of un-claimed interrupts. 
 

Generaly this box is quite a nuissance.  I'll be damned if i ever go for
chaintech again.

> This looks more like an audio bug than an ACPI bug. 
> Does audio work properly when you boot with "noapic" (note spelling). 

Yes.  I'm not very handy with alsa, oss emulation doesn't work with xmms, but
mplayer seems to sucessfully find sound device and play on it.
  
> which is somewhat unusual.  No problems with eth0 or USB? 
 
I think forcedeth (reverse engineered driver for nvidia network adapter) halts
the system every now and then.  I have no proof that it's this particular 
driver, the only thing to it, is that i've ran the system for ~24 hours without
that module and it didn't crash, while with it, usually doesn't survive for more
then 12 hours.  I don't see anything in the log even with sysrq+t.

I have one USB device - wacom drawing pad, and the cursor on it shakes even when
 the mouse is perfectly still.  This is probably more of chosing correct
sensitivity level, rather than IRQ issue.

> completely quiescent device would have caused an interrupt storm.  This 
> suggest that either the 
> device itself has an issue, or that there is something funky on this board
> with that interrupt line being pulled by a device that Linux does not have on
> that IRQ. 

I don't know, but with the amout of trouble this board is causing me it can be
antything. ;)
 
 
> I'm curious why the snd_intel8x0 driver is handling interrupts for a device
> called "NVidia nForce2" 
> -- maybe that is part of the problem? 
 
I think this is alight though, NVidia nForce2 (Audio) is what it is.  Have a
look at the attached "/proc/interupts no-acpi" file

> So this may have nothing to do with ACPI.  Except that ACPI is the only way to
> enable the IOAPIC on this box.  You can run with ACPI and without the IOAPIC
> by booting an ACPI-enabled  kernel with "noapic".

I'll run for a while with "noapic" see how that feels. (at least audio works
like that)

> I'm curious if in both apic and "noapic" modes if your ACPI interrupt is
> working properly -- you should see it increment in /proc/interrupts when you
> press the power button.  (first "/sbin/inti.d/acpid stop" to make sure it 
> doesn't shut down your machine. 
 
Now i can't seem to get any signals from the power button with "noapic" or
without it.  But I remeber that once upon a time i've had it working, and i
could see stuff comming out of /proc/acpi/events.  Can't remeber what i changed
since then.  If it's important i can spend some time on it. 

> Can you attach your .config?  I have a similar machine I may be able to try.

Will do.  Though i'm afraid it's this particular board that's messed up. It's a
mini-ATX, btw. 
 
I'll also post /proc/interupts for noapic, just in case.

Created attachment 2272 [details]
/proc/interupts noapic

Created attachment 2273 [details]
/usr/src/linux/.config

*** This bug has been marked as a duplicate of 2574 ***