linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* RE: 2.6.2-rc3: irq#19 - nobody cared - with an au88xx
@ 2004-04-07  4:08 Brown, Len
  2004-04-07 14:59 ` Daniel Jacobowitz
  0 siblings, 1 reply; 11+ messages in thread
From: Brown, Len @ 2004-04-07  4:08 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: linux-kernel

>I'm assuming that it is not the fault of either of these drivers, since
>both of those are quite straightforward; they appear to be actually
>being triggered when nothing is going on.

If IRQ initialization is done incorrectly, it is possible
For a driver to request_irq(X), while the hardware is actually
on IRQ Y.

Then when that device becomes active, it would kill the other
devices on Y because its handler is looking for interrupts on X.

If this happens with acpi enabled, but doesn't happen with acpi=off
or pci=noacpi, then we need to compare the /proc/interrupts between
the working and failintg configs to see if the IRQs have moved around
when perhaps they should not have.  Dmesg from the ACPI case would
also be needed.

>There was a set of APIC errors an hour before, but they're probably
>unrelated:
>Apr  6 11:31:31 nevyn kernel: APIC error on CPU1: 00(08)
>Apr  6 11:31:31 nevyn kernel: APIC error on CPU0: 00(02)

I believe this is due to transient hardware errors on your MB.
Though not fatal, it isn't a good indicator.

-Len

^ permalink raw reply	[flat|nested] 11+ messages in thread
* 2.6.2-rc3: irq#19 - nobody cared - with an au88xx
@ 2004-02-07  4:42 Daniel Jacobowitz
  0 siblings, 0 replies; 11+ messages in thread
From: Daniel Jacobowitz @ 2004-02-07  4:42 UTC (permalink / raw)
  To: linux-kernel

I've started getting this, every 24 hours or so:

irq 19: nobody cared!
Call Trace:
 [<c010d38a>] __report_bad_irq+0x2a/0x90
 [<c010d480>] note_interrupt+0x70/0xb0
 [<c010d7c0>] do_IRQ+0x160/0x1a0
 [<c0105000>] _stext+0x0/0x60
 [<c010b8d8>] common_interrupt+0x18/0x20
 [<c0108990>] default_idle+0x0/0x40
 [<c0105000>] _stext+0x0/0x60
 [<c01089bc>] default_idle+0x2c/0x40
 [<c0108a4b>] cpu_idle+0x3b/0x50
 [<c04b64a0>] unknown_bootoption+0x0/0x120
 [<c04b6926>] start_kernel+0x1a6/0x1f0
 [<c04b64a0>] unknown_bootoption+0x0/0x120

handlers:
[<f886b290>] (au_isr+0x0/0xb0 [au8830])
Disabling IRQ #19

and then sound doesn't work for a while.

There's a good chance this is my fault.  IRQ 19 is:

 19:   18500001          0   IO-APIC-level  au88xx

and the au88xx driver is an out-of-tree driver that was developed on
2.4/early-2.5, and I ported it to 2.6 myself.  It worked flawlessly on
2.6.0-test7; has something changed in how interrupt handlers are required to
behave?

[Just ask if you actually want the source to this driver... I don't know
enough about the card to actually submit it to Linus's tree and the driver's
original authors aparently didn't care to.]

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2004-04-12 21:52 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <BF1FE1855350A0479097B3A0D2A80EE0023E89C2@hdsmsx402.hd.intel.com>
2004-02-07  6:11 ` 2.6.2-rc3: irq#19 - nobody cared - with an au88xx Len Brown
2004-02-07  6:33   ` Daniel Jacobowitz
2004-04-06 18:02   ` Daniel Jacobowitz
2004-04-06 22:04     ` Daniel Jacobowitz
2004-04-06 23:43     ` Joshua Kwan
2004-04-07  4:08 Brown, Len
2004-04-07 14:59 ` Daniel Jacobowitz
2004-04-12 18:51   ` Daniel Jacobowitz
2004-04-12 21:28     ` Daniel Jacobowitz
2004-04-12 21:51       ` Jeff Garzik
  -- strict thread matches above, loose matches on Subject: below --
2004-02-07  4:42 Daniel Jacobowitz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).