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 [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
