[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Openvortex-dev] Findings...

From: Shamus
Subject: [Openvortex-dev] Findings...
Date: Tue, 22 Apr 2003 18:12:06 -0700

Hash: SHA1

Hi all!

I've finally been able to track down the problem on my machine with
the ALSA driver. In vortex_interrupt(...) there is a call to
snd_mpu401_uart_interrupt(...) and something in that call is causing
the kernel panic (unable to dereference virtual address or some
such--see previous email for exact wording).

I also found out the reason I was having trouble with the source code
(so it seemed). It seems that (at least as of the 2.4.19 kernel) as
soon as you call request_irq(...) that it starts calling the
vortex_interrupt(...) function *immediately* and the source mask has
the IRQ_TIMER bit set--not good! So anyway, if you don't clear this
IRQ it keeps calling the IRQ handler until you acknowledge it. Since I
had a return; statement above where it does

        if (source & IRQ_TIMER)
                hwread(vortex->mmio, VORTEX_IRQ_STAT);

it would simply keep calling the IRQ handler--effectively locking up
the system. All *before* the driver had a chance to call
vortex_core_init(chip)! I'm not sure why the call to
snd_mpu401_uart_interrupt(...) is causing the crash, but at least I
know where to look... BTW, the crash occurred *after* it returned from
vortex_core_init(chip), when the card is supposed to be fully
initialized.  :-/

Other than that, it would probably be a better idea to initialize the
Vortex hardware *before* attempting to grab the IRQ using
request_irq(...), since then the card would be properly initialized
and ready to handle IRQs properly at that point. It would probably
stop the spurious IRQ_TIMER from happening as well when grabbing the

- -- Shamus

Version: Encrypted with PGP Plugin for Calypso


reply via email to

[Prev in Thread] Current Thread [Next in Thread]