stonewall@xxxxxxxxxxxxx wrote: > Johannes - also on this - it is consistent. It does it every time. I'm > actually quite surprised I can Ctl-C out of ifconfig when I do it at the > command line . . . and interestingly enough, all dvb0_? devices are down. So > it succeeds in bringing the device down on the last one - just hangs the > ifconfig. > > The ifconfig I am using is part of the net-tools package from > > http://sites.inka.de/lina/linux/NetTools/ > > Version 1.60-r11 I don't think it's ifconfig's fault. At the moment I have no clue. You could try to enable more debug options in your kernel e.g. CONFIG_DEBUG_SLAB, CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_SPINLOCK_SLEEP, CONFIG_DEBUG_BUGVERBOSE, CONFIG_DEBUG_STACKOVERFLOW, CONFIG_DEBUG_STACK_USAGE, CONFIG_DEBUG_PAGEALLOC and see if that turns something up. It would be nice if the kernel had some debug support for this, so we could see who holds the mutex. One thing you could do is to add some debug to dmx_section_feed_release_filter, like: struct dvb_demux_filter *dvbdmxfilter = (struct dvb_demux_filter *) filter, *f; struct dvb_demux_feed *dvbdmxfeed = (struct dvb_demux_feed *) feed; struct dvb_demux *dvbdmx = dvbdmxfeed->demux; if (down_interruptible (&dvbdmx->mutex)) { printk("ARGH: %d\n", atomic_read(dvbdmx->mutex.count)); return -ERESTARTSYS; } If the mutex count is something != 0 or 1 the someone trashed the memory. Otherwise someone likely hold the mutex and we need to find out who. But before I put more work into this I would like to hear that someone else can reproduce it. Johannes
