This is excellent news, Mike!!!
I'd very much like that patch, please! It's been YEARS since I've recompiled a 
kernel, so this will
be a fun trip down memory lane!
How long do you think till this patch gets merged into the mainline kernels? Is 
that even a
reasonable aspiration? Asking for a friend 😄
As for the I2C thing, the driver can be blacklisted so that's one workaround.
Cheers!
On Mon, 2019-10-21 at 20:19 -0500, Mike Isely wrote:
> Update...
> So the kernel oops is happening because the driver is trying to tear down 
> state for a V4L2 radio
> device - except there was no radio device configured so the tear-down ended 
> up dereferencing
> through a null pointer.  Boom.
> I backtracked through the code to figure out "why now", and I could not find 
> a reason.  From what
> I can tell this bug has likely been there for about 11 years.  The code which 
> bypasses setup of
> the radio device takes that path if there's no radio support configured for 
> the hardware - which
> is sadly the case for the HVR-1950 - and git blame shows that area of code 
> last modified in
> 2008.  (That makes sense because that's about when the HVR-1950 was added.)  
> Best I can figure
> that some other happenstance had to have prevented the kernel from blowing up 
> on this
> pointer.  FWIW, it's actually trying to dereference an offset from null, but 
> the distance to the
> offset is still small enough that it should fit in the first virtual page 
> address and thus be
> detected.
> Anyway, I made a change to the two places in the code where this matters, 
> basically don't touch
> the radio data structure if it isn't there, and now the kernel oops is gone.
> This also explains why I could not reproduce the problem before - because the 
> different device I
> was trying has a working radio in it that can be operated by the pvrusb2 
> driver.  Thus this
> condition did not arise.
> There's still other strangeness to figure out, namely the sysfs teardown 
> problem and implementing
> *something* to keep a userspace I2C client from jamming up the pvrusb2 
> driver.  But this is
> progress.
> Obviously I will get this pushed.  I can send you a source patch if you'd 
> like to try rebuilding
> the module on your end.  Since we're not running identical kernels I can't 
> just send you the
> binary.
>   -Mike
-- 



Diego Rivera

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
pvrusb2 mailing list
[email protected]
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2

Reply via email to