[pvrusb2] driver oops [was: An Apology to the list]

[devsk]

> 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 <isely at isely.net>
To: Communications nexus for pvrusb2 driver <pvrusb2 at isely.net>
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
pvrusb2 at isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2