[linux-audio-user] Problem possibly RT related?
rlrevell at joe-job.com
Sun Jan 1 16:25:55 EST 2006
On Sun, 2006-01-01 at 15:48 -0500, Lee Revell wrote:
> On Sun, 2006-01-01 at 12:18 -0800, Noah Roberts wrote:
> > On 1/1/06, Lee Revell <rlrevell at joe-job.com> wrote:
> > > On Sun, 2006-01-01 at 10:48 -0800, Noah Roberts wrote:
> > > > On 12/31/05, Lee Revell <rlrevell at joe-job.com> wrote:
> > > > > On Sat, 2005-12-31 at 21:42 -0800, Noah Roberts wrote:
> > > > > > I bought a wireless PCMCIA card and had the oddest things happen when
> > > > > > I load the module.
> > > > >
> > > > > Which module?
> > > >
> > > > rt2500
> > >
> > > I don't see this in the kernel source tree.
> > You can get it at http://rt2x00.serialmonkey.com as it isn't part of
> > the mainline kernel but is a special driver for this PCMCIA card. The
> > module I posted about was a different one (the one I tested before was
> > actually the rt2500 driver, the latest beta is supposed to be a catch
> > all for any version of these chipsets), but I just tried this one too
> > and it did the same thing to me so the problem is the same.
> > I am upgrading to the latest and greatest version of everything to see
> > if this helps. I had other RT problems with this kernel anyway.
> > Also, I apparently didn't set the trace options as those files didn't
> > exist for me. Big windstorm brewing too...might not get to finish
> > today (power might go out). I'll post more when I can. Thanks for
> > helping.
> That driver looks like a piece of junk. It's clearly a quick and dirty
> port of Windows code (the comments refer to running in "DPC context" and
> IRQ priority levels which do not exist on Linux). And there seems to be
> nothing stopping it from doing a LOT of work in (soft) IRQ context, like
> I don't understand why these developers would choose to develop their
> driver outside the Linux kernel. It obviously will need a LOT of work
> to be mergeable.
It seems that the developers agree with me that the current driver is
garbage. The version you are using is not developed anymore. Upon
further inspection, rather than use a Linux bottom half mechanism like
workqueues, tasklets, or softirqs to perform the work that the comments
say should be done in DPC context, it just runs them all in hardirq
context with interrupts disabled. This would certainly make it a
problem for use in low latency systems.
Maybe you can try the beta driver:
More information about the Linux-audio-user