[Top][All Lists]

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

Re: [Openvortex-dev] Findings...

From: Manuel Jander
Subject: Re: [Openvortex-dev] Findings...
Date: Tue, 22 Apr 2003 22:30:44 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030327 Debian/1.3-4

Hi James,

Shamus wrote:

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).
Great !

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.  :-/
I agree. I expected the card wouldn't be doing anything before it was programmed to. Imagine a soundcard capturing sound and writing it per DMA somewhere into memory ... very bad. Maybe there some few Vortex card badly designed with such odd behaviour. Anyway, our driver
has to deal with such situations.

Any sugestions ?


reply via email to

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