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