> at the very beginning, alevt-date not at all. > I'll see if I can hack something else together tomorrow.
I see. Some quick crash test example would be nice to have . > Note that this also can only happen if another process is just > allocating/setting/changing a filter and in just that moment when > it has downed the semaphore in dvb_demux.c the softirq > which handles the networking is triggered and calls the > set_multicast_list() function in dvb_net. Can we introduce some crash patch, some mdelay() in the driver code after downing of the semaphore to magnify the problem? > Then, the call which sets the section filter for the multicast > list will use a down_interruptible() in dvb_demux.c which will > fail and thus call schedule() which causes an oops in schedule() > because set_multicast_list() is called during interrupt. > Also cf. /usr/src/linux/Documentation/networking/netdevices.txt > which states that sleeping is not allowed here. > > > > dvb-kernel survived that test. Please post crashme > > code sample which can attempt to cause the oops for > > the budget modules. > > This is of course a bug in the upper DVB layers and not the > budget modules. I meant budget modules as whole system, let's compare stability from user point of view, difference of using budget cards vs. av7110. Budgets can be affected by down_interruptible so we might look for some workaround. I must admit that I was seeing for long time this down_interruptible calls all around the code and it doesn't look too good. Emard -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
