[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#810726: linux-image-4.3.0-1-amd64: Kernel 4.3 breaks Hauppauge HD-PVR recording



On Tue, Jan 26, 2016 at 11:06:53PM -0300, Javier Martinez Canillas wrote:
> Hello David,
> 
> Sorry for the late response.

Hi Javier,

No problem.

> On 01/20/2016 04:41 PM, David Engel wrote:
> >Javier and Mauro, this is in regards to Debian bug #810726, which I
> >filed last week.  I also informed Hans about it at that time.
> >
> >Using git bisect, I finally identified the attached commit as the
> >offending one.  Sure enough, after reverting that change, my hdpvr
> >behaves reliably with the 4.3.3 kernel.  Further testing has revealed
> >that I can achieve the same result with the standard, Debian kernel by
> >blacklisting the ir_kbd_i2c module.
> >
> 
> The attached commit is only fixing module autoloading for the I2C driver
> so is just exposing a existent bug. If you built the driver in the image
> instead of as a module, the bug should be present even with that commit
> reverted.

Yes, I realize that.  The thing is the LIRC receive support on the
hdpvr has been notoriously flaky, at least in MythTV circles, and
often causes recording instability.  Previously, with the autoloading
bug, most hdpvr users weren't affected by it unless they manually
loaded the appropriate LIRC modules.  Now, with the autoloading bug
fixed, many unsuspecting hdpvr users will experience the instability
when upgrading kernels.

> >It seems something in the IR initialization is causing the hdpvr to
> >become unreliable.  This is even when the IR support is not used nor
> >wanted.  Additionally, blacklisting the lirc_zilog module is not
> >sufficient to work around the problem, nor is keeping it but using the
> >tx_only=1 parameter.
> >
> 
> I believe the root cause has to be found since as I said, it was only
> working because the module didn't have the module alias information so
> udev/kmod were not able to load the module when the kernel report the
> MODALIAS uevent when the I2C device was registered.

I agree the root cause needs to be found.  Personally, I think it
would be better to disable the LIRC support in some way by default
until the underlying problem can be fixed, but that's your call.
There is a work around with blacklisting the ir-kbd-i2c module, so
perhaps making sure that is more widely known is sufficient.

Anyway, I can offer my help in testing any fixes you come up with.

David
-- 
David Engel
david@istwok.net


Reply to: