Mailing List archive

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

[linux-dvb] Re: [BUG] linuxtv-dvb-1.0.0 unstable with Nova-t



David Kuehling wrote:
> 
> Ok, that worked.  oops is attached (oops-20030820), as well as the
> output from ksymoops (oopsed-20030820).  The crash occured in
> kmem_cache_free+52.  Disassembly and comparison with the C-source
> suggests, that the crash is happening excactly at slab.c:1433 in the
> Linux kernel.  The line is:

  Call Trace: [free_uid+44/64] [release_task+41/336] [sys_wait4+775/912] [system_call+51/56]

Cool, I thought I was the only one who gets this. I spent considerable
time trying to hunt it down, but didn't find anything :-(

free_uid() is totally unrelated to the DVB drivers, and even uses its own
slab. The Oops happens when a process (which again can be totally
unrelated to DVB) ends and is reaped by init.

I observed that this usually happens some time after I closed xawtv. If I don't
use xawtv I don't get this Oops. Maybe some wild writes into memory,
but the Oops is too consistently on the same spot. Because free_uid()
uses its own slab I doubt it can be caused by a double kfree().

Anyway, I "solved" it by *disabling* CONFIG_SLAB_DEBUG. Maybe it's
caused by gcc-3.3 bugs...

> Well, I understand nothing of the Linux kernel, but isn't that some kind
> of memory corruption problem?  Maybe I should recompile Linux with
> memory debugging enabled...

I suspect you already have, else you wouldn't get this Oops. There should be a
line just before the Oops which prints the reason for the Oops.

> BTW, what about the Windows DLL used by the driver (copied to
> /etc/dvb/tda1004x.mc).  This looks like an ugly hack, could a too-recent
> version be responsible for the crash?  Would it help, if I uploaded it?

It's not a DLL, it's firmware for the frontend's micro-controller.


Johannes


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.



Home | Main Index | Thread Index