[pvrusb2] HVR-1950 driver loading problem

[Mike Isely]

On Sun, 14 Jun 2009, Mike Isely wrote:

> On Sun, 14 Jun 2009, JE Geiger wrote:
> 
> > PVR2_TRACE_STATE is what is causing the NULL kernel pointer deref.
> > Using debug=32255 (drops 512) I get these info messages.  I bet that
> > is all over the driver.
> 
> Probably a bad printf format.  I'll take a look, and I'm sure that one 
> will be easy to fix.  The oops listing unfortunately looks mostly 
> useless, but I'll poke around.

I just tried to reproduce this and FAILED.

To answer your earlier question, no there are no dependencies between 
the bits.  You can turn on / off any combination of bits and nobody bad 
should happen - that is, if you don't consider tons of noise in your log 
to be "bad" :-)

I turned on PVR2_TRACE_STATE and nothing crashed.

Then I simulated the probe failure you are reporting and still nothing 
crashed.

Then I turned on all of the bits (just set the mask to 0xffffffff) and 
still no crash.

Finally I switched to an HVR-1950 and still it would not crash.

I don't run Fedora here so I can't easily reproduce that environment.  I 
will try this again on a 2.6.29 kernel however.

Can you discard the v4l-dvb snapshot you're trying and instead just try 
the standalone pvrusb2 driver?


> 
> > 
> > Back to the problem at hand:
> > 
> > The hardware pointer address seems to be moving.  Is this normal?
> > 
> 
> The assignment of USB address is done by the USB core, and it is normal 
> to see it advancing each time the device is detected.
> 
> As for the -75 status that's EOVERFLOW which is something I've *NEVER* 
> seen before.  What's more you have it coming from code which has been 
> unchanged and stable for multiple years.  So right now I do not know 
> what is going on here.  My first impression is that a bad call is being 
> made into the USB core at this point but as I said the code in question 
> is rock stable, unchanged for a very long time.  I need to look at it to 
> see possible sources for that error code.  I will likely have some more 
> questions / tests for you there.

Still looking at this, but the other problem should have been the easy 
one.  This one I'm not optimistic about understanding.

  -Mike


-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8