> > Call Trace:
> > [__kmem_cache_alloc+255/272]__kmem_cache_alloc+0xff/0x110
> > [get_vm_area+38/256]get_vm_area+0x26/0x100
> > [__vmalloc+75/304]__vmalloc+0x4b/0x130
> > [vmalloc+34/48]vmalloc+0x22/0x30
> > [<e08fe502>]sg_init+0x82/0x130 [sg]
> > [<e09022c7>].rodata.str1.1+0x23/0x2b0 [sg]
> > [<e0903be0>]sg_fops+0x0/0x58 [sg]
> > [<e0903b20>]sg_template+0x0/0x94 [sg]
>
> That is known - sg_init() is blatantly calling vmalloc under
> write_lock_irqsave().
Hye,
is that the same problem ?
Apparently it's not scsi related as the one above:
Debug: sleeping function called from illegal context at slab.c:1374
c72a5f60 c01170b4 c02809c0 c0284df1 0000055e c72dfc80 c01311aa c0284df1
0000055e 00000000 00000400 bffffd24 c72dfc80 c01aebcf c72df960 00000011
c010d142 00000080 000001d0 c72a4000 00000100 bffffd24 bffffc2c 00000000
Call Trace:
[<c01170b4>]__might_sleep+0x54/0x60
[<c01311aa>]kmalloc+0x56/0x214
[<c01aebcf>]capable+0x1b/0x34
[<c010d142>]sys_ioperm+0x82/0x11c
[<c0108a3f>]syscall_call+0x7/0xb
It's from a 2.5.40 pulled from bk.
Regards
-- Joaquim Fellmann
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/