[mythtv-users] USB IR Receivers

Alec Leamas leamas.alec at gmail.com
Mon Sep 7 16:20:32 UTC 2015


On 04/09/15 16:24, Kirk Bocek wrote:
>
>
> On 9/4/2015 1:50 AM, Alec Leamas wrote:
>> On 03/09/15 22:23, Kirk Bocek wrote:
>>>
>>>
>>> On 9/3/2015 12:27 PM, Kirk Bocek wrote:
>>
>>>
>>> Next problem. modprobing my new mceusb.ko yields a kernel crash of some
>>> sort:
>>>
>>> $modprobe -v mceusb
>>> insmod
>>> /lib/modules/4.1.5-100.fc21.x86_64/kernel/drivers/media/rc/rc-core.ko.xz
>>> insmod
>>> /lib/modules/4.1.5-100.fc21.x86_64/kernel/drivers/media/rc/mceusb.ko.xz
>>> Killed
>>>
>>> $dmesg
>>> ...
>>> [  163.692148] mceusb: module verification failed: signature and/or
>>> required key missing - tainting kernel
>>> [  163.730477] Registered IR keymap rc-rc6-mce
>>> [  163.730711] input: Media Center Ed. eHome Infrared Remote Transceiver
>>> (0471:20cc) as
>>> /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/rc/rc0/input8
>>> [  163.731422] rc0: Media Center Ed. eHome Infrared Remote Transceiver
>>> (0471:20cc) as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/rc/rc0
>>> [  163.746365] BUG: unable to handle kernel NULL pointer dereference at
>>> 0000000000000003
>>> [  163.746457] IP: [<ffffffffa064a129>] usb_endpoint_xfer_int+0x10/0x25
>>
>> Here is a kernel oops. As long as this is with us, anything can
>> happen. Now, the question is if you can reproduce this without your
>> patches to mceusb.c. If so, this is a kernel bug which should be
>> reported. If not, you need to find out (bisect?) which part of your
>> patch which causes this.
>
> This is all I added:
>
>      /* Philips/Spinel plus IR transceiver for ASUS */
>      { USB_DEVICE(VENDOR_PHILIPS, 0x20cc) },
>
> Remove those lines from source file, recompile and reinstall and crash
> goes away. But IR instance goes away too. No /sys/class/rc, etc. No
> driver tree:
>
> $lsmod |grep mce
> mceusb                 36864  0
> rc_core                28672  1 mceusb
>
> So just edit one of the existing device lines to 0x20cc: modprobe and
> same result as before, kernel oops.

The more I think about this I tend to think that that is a kernel bug 
which should be reported. It just should not crash this way whatever 
input it gets. Even if you patched the driver this way, a bad remote 
declaring itself with some supported vendor:product id will give the 
same crash if it behaves like your remote (?)

You can also probably trigger the same crash using the unmodified source 
by binding the driver to the device using the 'bind' interface which 
works similar to the 'unbind' one. IIRC, this bypasses the driver tables 
and binds unconditionally (?)

Ergo: it might be a Good Thing to report this to the kernel folks.


Cheers!

--alec



More information about the mythtv-users mailing list