> Can anyone else cause this sort of oops? /me ducks behind a wall... I had recently reported an oops while removing pvrusb2 driver. And in the same process pvrusb2-context.
The stack looked different but silent corruptions or bad pointers almost always screw up the stack. Did you find out why were there corrupt strings reported in the dmesg? > [ 1193.215000] usbcore: deregistering interface driver pvrusb2 > [ 1193.215000] pvrusb2: Device being rendered inoperable > [ 1193.215000] pvrusb2: unregistered device x¼<96>Ý^A<88>ÿÿstats [mpeg] > [ 1193.215000] pvrusb2: unregistered device ¨¼<96>Ý^A<88>ÿÿradio0 [mpeg] > [ 1193.215000] tuner-simple 1-0061: destroying instance > [ 1193.215000] tda9887 1-0043: destroying instance This was a successful removal. Corrupt strings in messages are always a cause of concern! And a very good hint towards potential problem...:-) -devsk ________________________________ From: Mike Isely <[email protected]> To: Communications nexus for pvrusb2 driver <[email protected]> Sent: Wed, April 7, 2010 9:01:02 PM Subject: [pvrusb2] driver oops [was: An Apology to the list] On Wed, 7 Apr 2010, JE Geiger wrote: > I would not spend a lot of time on it, since the kernel debug code > complains about 5 different kernel objects when loading the driver. > These are kernel objects not pvrusb2 objects. > > I anticipate that the problem is way deep inside the kernel. > > I did do a test and the composite capture of the mpeg2 encoder is > working (which is what I need). > > As time permits, I will try a compile 2.6.30.current and see if it > still happens. > No, the pvrusb2 driver should never cause a kernel oops. There is logic specifically in there to cleanly untangle itself from the kernel when it is removed - in particular when it is associated to active hardware. If you are talking about kobj structures, those are basic elements in the kernel for tracking specific kinds of resources. The pvrusb2 driver, like many other drivers, has to deal with those too. If you have found a way to oops the kernel upon removal of the pvrusb2 driver then I need to chase it - if only at least to try to reproduce it here. Knowing that the problem only started with the 2.6.33.x kernel is a huge help. I'm sure the driver is working fine under normal circumstances. What I am concerned about however are abnormal circumstances. The pvrusb2 driver works with hotpluggable hardware and has to be able to handle all manner of wierd crap that can happen if the hardware is yanked at ANY TIME during the driver's execution. Similarly, if an attempt is made to remove the driver from the kernel at ANY TIME, the driver is supposed to be able to handle this. It is entirely possible that there are corner cases still happening, but I try to hunt down and deal with these when they are spotted. You just hit one, it seems. I'm thinking it's something new with that later kernel, because the circumstance you are describing is very common - and I've done it a lot here without error many times while debugging the driver. Can anyone else cause this sort of oops? /me ducks behind a wall... -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
