Jeff - wow, this may be related to the ifconfig issue. I, too, am using the SkyStar 2 card. I have not noticed this ifconfig issue on my Hauppauge Nova-S card. Stonewall On Wednesday 13 July 2005 13:56, Jeff Olhoeft wrote: > I've seen this problem, too. I haven't had a chance to do a > thorough examination of it yet, though. > > I also am having the interrupt issues with a 2.6D SkyStar 2, > even with the latest CVS drivers. Likewise I haven't had time > to go through things in detail yet, so hadn't gotten around > to posting about it yet. > > I'm hoping to spend some time working with the card soon, and > will be able to put together a detailed bug report. > > Jeff > > > -----Original Message----- > > From: linux-dvb-bounces@xxxxxxxxxxx > > [mailto:linux-dvb-bounces@xxxxxxxxxxx] On Behalf Of Johannes > > Stezenbach > > Sent: Wednesday, July 13, 2005 7:15 AM > > To: linux-dvb@xxxxxxxxxxx > > Subject: Re: [linux-dvb] ifconfig locks on down - B2C2 flexcop. > > > > 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 > > > > _______________________________________________ > > > > linux-dvb@xxxxxxxxxxx > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > > _______________________________________________ > > linux-dvb@xxxxxxxxxxx > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
