[pvrusb2] HVR-1950 driver loading problem

[JE Geiger]

OK.  I have tried dropping down in kernel versions (2.6.26.8) (2.6.27.24) on
same Fedora 11 and still the same problem.  So must be something not
necessarily kernel related (repeating resets, not the Oops).

I enabled debug messages from udev and, although I know very little about
udev, I get the general concept and if you search for the word firmware, you
see it loaded then immediately later removed.  It sure looks like a udev
problem for the repeating reset.  Would welcome a comment.  My udev is 141.

The udev log is http://www.kd4ab.org/udevdbug

As far as the crash on PVR2_TRACE_STATE, I don't know.

Where is the function scnprintf defined and where is the object code.  I
looked around and it is not one I recognize from my distant past (K&R 2nd,
little white paperback).  Is this one of the "special" kernel functions.  I
found google references to why it is used, etc. but I cannot find the actual
function .h or .c.

I have several machines and I will change the PC to another one and try
again using a clean pvrusb2 as released with the kernel for Fedora 11.

Thanks for running the tests and the info about the trace bits being
independent.   I will advise as I get further into this.  I think it makes
more sense for me to test further as opposed to you using up your time.  I
will ask questions if I get stuck.



On Sun, Jun 14, 2009 at 11:36 PM, Mike Isely <isely at isely.net> wrote:

> 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.
> >
>


>
> 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
> _______________________________________________
> pvrusb2 mailing list
> pvrusb2 at isely.net
> http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
>