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