19 Jan
2006
19 Jan
'06
3:05 a.m.
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(a)joe-job.com> wrote:
On Wed, 2006-01-18 at 22:45 -0800, Mike Taht wrote:
--
Mike Taht
PostCards From the Bleeding Edge
http://the-edge.blogspot.com
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