>>>>> "Johannes" == Johannes Stezenbach <js@convergence.de> writes:
> David Kuehling wrote:
>> Any clues? How could I retrieve some more useful data on the
>> crashes?
> Try SysRq-S a couple of times and then SysRq-U. Sometimes the Oops
> makes it into the log files that way. Then you can use ksymoops to
> decode it into something which is usable for us.
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:
slab_bufctl(slabp)[objnr] = slabp->free;
Identified via division operation of previous line:
unsigned int objnr = (objp-slabp->s_mem)/cachep->objsize;
divl 0x18(%esi)
esi is cachep, assigned at beginn of function.
Disassembly from `gdb /usr/src/linux/vmlinux' matches disassembly from
ksymoops.
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...
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?
David
--
GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40
Attachment:
oops-20030820
Description: Binary data
Attachment:
oopsed-20030820
Description: Binary data