[linux-audio-user] Re: x86_64 and ingo's realtime patches, works?

Mike Taht mike.taht at gmail.com
Thu Jan 19 02:05:54 EST 2006

I am not using any proprietary kernel modules at present,  I was
trying to say was that CONFIG_DEBUG_DEADLOCKS was an artifact of me
trying to debug madwifi earlier in the 2.6.15 release cycle. (I guess
I got onboard this release on 2.6.15-rt2) The module is certainly not
inserted now.

After I get this kernel to crash some different way, or after another
day of surviving the abuse I've been throwing at it, I will rebuild
without CONFIG_DEBUG_DEADLOCKS and with latency tracing enabled. From
a device and driver coverage standpoint I've exercised everything I
can think of, all that remains is how long can it hold up... I've only
had one RT kernel work this good, ever...

I will take up the madwifi issue on the appropriate forum when I have
time to return to it. (and I figure someone else will have solved it
by then)

On 1/18/06, Lee Revell <rlrevell at joe-job.com> wrote:
> On Wed, 2006-01-18 at 22:45 -0800, Mike Taht wrote:
> > Lee:
> >
> > At the moment, the madwifi-ng drivers compiled for this machine oops
> > out. It's not RT's fault - in fact the 2.6.15 non-rt kernel just hangs
> > completely a few seconds into accessing the madwifi card. The machine
> > survives a bit longer and prints out a reasonable error message when
> > compiled for RT and CONFIG_DEBUG_DEADLOCKS. I have some hope now that
> > the mutex code is in 2.6.16 that it will get easier to track down the
> > problem with madwifi.
> Please, when posting a report like this, be sure to mention if you are
> using any proprietary kernel modules, otherwise it's impossible to
> interpret!
> Lee

Mike Taht
PostCards From the Bleeding Edge

More information about the Linux-audio-user mailing list