[linux-dvb] ifconfig locks on down - B2C2 flexcop.

stonewall at inebraska.com stonewall at inebraska.com
Wed Jul 13 16:15:06 CEST 2005


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 at linuxtv.org
> > [mailto:linux-dvb-bounces at linuxtv.org] On Behalf Of Johannes
> > Stezenbach
> > Sent: Wednesday, July 13, 2005 7:15 AM
> > To: linux-dvb at linuxtv.org
> > Subject: Re: [linux-dvb] ifconfig locks on down - B2C2 flexcop.
> >
> > stonewall at inebraska.com 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 mailing list
> > linux-dvb at linuxtv.org
> > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>
> _______________________________________________
> linux-dvb mailing list
> linux-dvb at linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb




More information about the linux-dvb mailing list