Holger Kiehl writes: > > from that person if this suffices to remove the race. So, if you or > > anybody else with SMP can test it that would be great. > > > Yes, this fixes the oops. I have made a lot of tests and was unable > to reproduce the oops with your dvb_net.c. Good to hear. Thanks for the testing. > Thanks for the quick responce and fix! Hope this will soon go into the > kernel. This also fixes the issue that one could no longer reboot or > poweroff the system and I think there where some reports on this too. > > > The could of course be something else showing up onl on 64 bit. > > Does this ooops also happen on 32 bit SMP? > > > Just recently I have setup and tested a 32 bit system with SMP kernel > and there where no such issues, but it had the Nova-S card. The 64 bit > system I am now testing has the skystar card. Tomorrow I will try > and see if I can get another system with 32 bit and the skystar. I think this race is much more likely on drivers where the stop_feed call has some kind of waiting (e.g. for the hardware response) in it because then the chances that the two processes using the filters happen at the same time are very high. So, cards with hardware PID filters like the Skystar card will expose the race much more often. The two processes I am talking about are the delayed work queue in dvb_net caused by the "mac filter" call from the network stop call (from inside kernel network core) and the stop call in dvb_net itself. They are called right after each other at a network stop, the first a little delayed because it goes through the work queue. That's why this mostly happens during an "ifconfig ... down". Ralph
