Johannes,
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 . . .
Stonewall
On Tuesday 12 July 2005 23:39, Johannes Stezenbach wrote:
> stonewall@xxxxxxxxxxxxx wrote:
> > Johannes - here is the dmesg output before I did a Ctrl-C to break out of
> > the errant ifconfig:
> >
> > SysRq : Show State
> >
> > ifconfig S 00000008 0 8226 8216 (NOTLB)
> > f4f0fdbc 00000082 f4f0fdac 00000008 00000001 f7f10000 00000208 c03d1c00
> > 00000000 00004240 00000000 00001fff 00004240 00000000 20a35fff
> > c2000520 00000000 000034eb e61ca35d 00000268 00000040 f7f1b020 f7f1b144
> > f8e76d9d Call Trace:
> > [<c0370b28>] __down_interruptible+0xa8/0x128
> > [<c0370bc2>] __down_failed_interruptible+0xa/0x10
> > [<f8f1d801>] .text.lock.dvb_demux+0x1fb/0x31a [dvb_core]
> > [<f8f1cfbb>] dmx_section_feed_release_filter+0xab/0xd0 [dvb_core]
> > [<f8f23afa>] dvb_net_feed_stop+0x7a/0x1e0 [dvb_core]
> > [<c0304821>] dev_close+0xb1/0xc0
> > [<c0305f98>] dev_change_flags+0x58/0x130
> > [<c0348cc4>] devinet_ioctl+0x254/0x5c0
> > [<c034b194>] inet_ioctl+0x64/0xb0
> > [<c02faf98>] sock_ioctl+0xd8/0x210
> > [<c0171b31>] do_ioctl+0x81/0xa0
> > [<c0171d02>] vfs_ioctl+0x62/0x1d0
> > [<c0171eb1>] sys_ioctl+0x41/0x70
> > [<c01033b9>] syscall_call+0x7/0xb
>
> Hm, now the question is who's holding the dvb_demux mutex.
>
> What other tasks are in SysRq-T output? If you grep for
> .text.lock.dvb_demux, does anything show up? Or at least
> any other process with "dvb_" or "dmx_" in the call trace?
>
> If not, I have no clue. I just looked through dvb_demux.c
> and I can't see any case where a function could exit without
> releasing the mutex. (Memory corruption could cause this
> kind of lockup, but that's more difficult to check.)
>
> Johannes
