[rt2x00-users] Kernel panic due to rt2x00 driver?

Stanislaw Gruszka sgruszka at redhat.com
Tue Jul 10 17:04:02 AEST 2012


On Tue, Jul 10, 2012 at 04:30:24AM +0200, Alex Jones wrote:
> > > >[12310.835902] Pid: 4786, comm: kworker/u:3 Tainted: P
> > > 
> > > ->Tainted: P<-
> > > 
> > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=kernel/panic.c#l187
> > 
> > Yes, we do not support tainted kernels.
> > 
> > Alex, is this problem reproducible without the proprietary module ?
> 
> The kernel is tainted due to the modules for my DVB TV card -  the PC is a dedicated XBMC pvr machine 
> in my livingroom and mainly used for watching live tv.  The problem has only ever happened when I've
> pressed a button on the remote control (USB IR), but it's only very occassional.  I did try tonight 
> with an untainted kernel but no oops could be triggered, but as it's so intermittent this doesn't 
> really mean anything.  
> 
> I can understand your no tainted kernel policy but I can't see anything in the oops that would finger the TV card
> modules.  Is there anything more I can do to try and establish where the problem lies when an oops occurs again?

I'm almost 100% certain this is not rt2x00 problem.

Look at the end of the call trace:

[12310.836966] RIP: 0010:[<ffffffff8116941e>]  [<ffffffff8116941e>] kmem_cache_alloc_trace+0x5e/0x150

[12310.856499]  [<ffffffff81494d48>] usb_control_msg+0x58/0x120

[12310.858487]  [<ffffffffa02d8bb6>] rt2x00usb_vendor_request+0xc6/0x150 [rt2x00usb]

Wrong pointer dereference is on kmem_cache_alloc_trace(), and we call that
from usb_control_msg() using simple kmalloc(size, flags) API - we do not
pass any pointers. So internals of kmem_cache are corrupted. Where?
You can find out by compiling kernel with CONFIG_DEBUG_INFO, and doing

gdb vmlinux
l *(kmem_cache_alloc_trace+0x5e)

What is corrupting kmem_cache ? Hard to tell, I think this is not
rt2x00, but rather DVB proprietary driver or USB IR driver. Finding
out will require turning on various debug options in kernel - good
set of debug options are for example here:
http://pkgs.fedoraproject.org/gitweb/?p=kernel.git;a=blob;f=config-debug;h=b9334f4acc2454249b98654974ee33cca6fd4c4c;hb=HEAD

But if this is really nasty memory corruption problem, you probably
will need to use CONFIG_DEBUG_PAGEALLOC and boot kernel with
debug_guardpage_minorder=1

Stanislaw 




More information about the users mailing list