[pvrusb2] Driver status [was:CPU Run pvrusb2-context]

[Mike Isely]

On Thu, 14 Oct 2010, JE Geiger wrote:

> 
> 2.6.34 is the version where I started having problems.  I had to update the
> in kernel pvrusb2 driver to the isely.net version to get the problem to go
> away.
> 
> The problem is that there is the driver that Mike keeps up to date, the v4l
> stuff, then the kernel itself.  It appears that there is quite a time lag
> between the problem being fixed in Mike's tree and it migrating up to the
> real kernel at kernel.org that everyone pulls from.  I am not sure all of
> the fixes ever made it to even the most current kernel 2.6.36....

The time lag is due to several factors.  First, I have to make the fixes 
available to be pulled upstream.  If it's a critical thing, I usually do 
this right away.  Otherwise I may wait until I accumulate enough changes 
to make it worthwhile.  (The process in v4l-dvb for pulling changes has 
seemingly gotten messier in the past year so it's more of a pain now to 
get things pulled up, unfortunately.)

Second, the process for getting changes in the kernel in general can 
introduce a lot of lag.  Normally there is a 2 week "merge window" which 
opens immediately after a point-release of the kernel, e.g. "2.6.34".  
During that window all changes pending since the last merge window get 
pulled in.  Once the merge window closes, then one has to wait for the 
next merge window - which does not occur until after the next 
point-release, which can be 1-3 months of delay.

And there may be additional lag before a distro picks up the changes and 
builds them into any kernels they release...

With that said, there is a speedier process for kernel changes which are 
strictly considered to be bug fixes.  If the change is just a fix and 
not a feature addition, AND if it is simple enough that it can be 
cherry-picked with low risk of (further) breakage, then such a fix can 
be immediately queued for the next kernel bug-fix release, e.g. 
"2.6.34.1".  This can be as quick as a few days, depending on the 
criticality of the fix and how wide the impact is.

A while back there was a point-release of the kernel issued which 
completely wiped out the pvrusb2 driver - attempting to load the driver 
not only failed but it jammed things up badly enough to require a 
reboot.  It technically wasn't my fault: a behavior had changed in the 
USB stack which triggered the breakage and nobody noticed until the 
kernel release had taken place.  (The pvrusb2 driver wasn't the only 
driver that got burned by it.)  Within about 2 days I had a fix to deal 
with the new behavior, and it got pulled up and released into the next 
bug-fix release just a few days after that.  I think this was back in 
2.6.27, but my memory is foggy and I'm too lazy right now to go back 
through old e-mail to find the sequence of events.


> 
> Download the current version, make modules, make modules_install, reboot,
> then modprobe and rmmod several times in a row.  It should fix the issues.
> 

The current state of the various driver versions is this:

The in-kernel and in-V4L versions are perfectly in sync with each other 
and everything I've made available upstream has been pulled (months 
ago).  I believe kernel 2.6.35 is in fine shape and the lastest bug-fix 
releases of 2.6.34.x are also fine.

The latest standalone driver (from last July) technically has a few more 
tweaks in it than what's been pulled upstream, but they are so minor / 
trivial that I haven't bothered to get them pulled up.

I have been slowly accumulating some other changes since the last 
snapshot that that fix up cropping support (thanks to another pvrusb2 
user who knows far more about the cx25843 chip than I'll ever learn), 
but there's nothing merged in there yet that's really worth releasing.

I know of some other pvrusb2 driver changes coming *down* to me from 
other kernel developers; these are changes that adapt to other changes 
within the kernel or that simplify some bits (by taking advantage of 
some newer kernel facilities).  Once these changes flow into the v4l-dvb 
hg repository, I will integrate them with the standalone driver and 
release another snapshot.  Or, if it is discovered that the standalone 
driver already breaks with the latest kernels due to these incoming 
changes, then I will pull the changes myself and release a new snapshot 
anyway.  But right now I'm kind of in a lull (and working on other 
things unrelated to this driver) at the moment.

There is an unresolved question involving suspected module hangs upon 
removal - devsk has reported these to me.  What he has described would 
suggest that this problem is rampant - I should be getting flooded with 
complaints.  But nobody else is seeing this problem and I've so far been 
unable to reproduce it.  That's not to say the problem isn't there - 
I've learned long ago that subtle latent bugs can lurk for a long time, 
unnoticed.  It's entirely possible that there is a problem here but at 
the moment I've not been able to get any traction on it and I haven't 
yet understood what devsk is doing to trigger it.  If I do however 
figure this out and have a fix, this will immediately trigger release of 
another snapshot.

I guess this has sort of turned into a State of The Driver message ;-)

  -Mike

-- 

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