stonewall@xxxxxxxxxxxxx wrote: > Actually, yes, there is another process with dvb_*, and szap is running (as > it's supposed to be): > > szap S 00000008 0 8099 1 8101 (NOTLB) > f7295f30 00000086 f7295f20 00000008 00000001 c2000f60 c1fcf060 c03d1c00 > c2000f60 c03d1c00 f7295ef8 700224f8 00000008 c0503020 f7295f08 c2000520 > 00000000 0001ae35 53896652 0000026b c2000f60 f7da4020 f7da4144 00000000 > Call Trace: > [<c037223c>] schedule_timeout+0x6c/0xc0 > [<c0128d2e>] sys_nanosleep+0xde/0x160 > [<c01033b9>] syscall_call+0x7/0xb > > -and- > > kdvb-fe-0 S 00000008 0 8101 1 8099 7994 (L-TLB) > f7fcbf0c 00000046 f7fcbefc 00000008 00000001 00000002 f7f10328 c03d1c00 > f7fca000 f7fcbed8 f8df4f67 f7f10328 f7fcbf14 00000002 f7fcbee4 c2000520 > 00000000 00005fa2 6a8f135b 0000026b c2000f60 f7d9a540 f7d9a664 00000000 > Call Trace: > [<c037223c>] schedule_timeout+0x6c/0xc0 > [<f8f210be>] dvb_frontend_thread+0x14e/0x4f0 [dvb_core] > [<c01014d5>] kernel_thread_helper+0x5/0x10 > > Does this help? - I wish I knew what I was looking for . . . None of these should hold the mutex that ifconfig is blocked on. Johannes