Re: imon (0aa8:8001) crash

[Paul S. <pa...@si...>]

although the driver no longer crashes the hauppauge remote that worked
perfectly in the previous setup now is working very poorly.

Looking at the current source and the source I used back then (looks
like version 0.8.0) there are so many differences I am somewhat
overwhelmed.

Can you please point me where in the code to look for the part where
what comes in from the receiver is processed before it is handed to the
rest of the system?

On 02-02-10 3:17, Jarod Wilson wrote:
> On Sat, Jan 30, 2010 at 12:06 AM, Jarod Wilson <ja...@wi...> wrote:
>   
>> On Fri, Jan 29, 2010 at 9:12 AM, Jarod Wilson <ja...@wi...> wrote:
>>     
>>> On Fri, Jan 29, 2010 at 5:08 AM, Paul Sijben <si...@oc...> wrote:
>>>       
>>>> I have just upgraded my ancient HTPC setup to Ubuntu 9.10 and ran into
>>>> the imon crash that seems to plague more people.
>>>>         
>>> Huh? What "imon crash that seems to plague more people" are you
>>> referring to? I'm pretty sure I've not seen this backtrace, or if I
>>> have, its only been once before...
>>>
>>>       
>>>> So I tried the lirc svn build but to no avail.
>>>>
>>>> My dmesg output on this issue is below. Is there a patch I can apply to
>>>> make this work for me?
>>>>
>>>> [   17.949793] lirc_imon: imon_probe: found iMON device (0aa8:8001, intf0)
>>>>         
>>> I think you're only the second person I've come across that actually
>>> has some of the pre-vendor-code 15c2 stuff...
>>>
>>> ...
>>>       
>>>> [   17.949954] lirc_imon: Configuring IR receiver for iMON protocol
>>>> [   17.949965] BUG: unable to handle kernel NULL pointer dereference at
>>>> 00000002
>>>> [   17.949970] IP: [<f810944d>] send_packet+0x1d/0x240 [lirc_imon]
>>>>         
>>> ...
>>>       
>>>> [   17.950019] EIP: 0060:[<f810944d>] EFLAGS: 00010246 CPU: 1
>>>> [   17.950023] EIP is at send_packet+0x1d/0x240 [lirc_imon]
>>>>         
>>> ...
>>>       
>>>> [   17.950056] Call Trace:
>>>> [   17.950062]  [<f810979e>] ? imon_set_ir_protocol+0x6e/0x130 [lirc_imon]
>>>> [   17.950067]  [<f810b3f1>] ? imon_probe+0x351/0xf6c [lirc_imon]
>>>>         
>>> ...
>>>
>>> I've seen something similar to this once before, I'll see what I can
>>> figure out in the way of a possible fix.
>>>       
>> Pretty sure I see what's going on now. Try this:
>>
>> cvs diff: Diffing .
>> Index: lirc_imon.c
>> ===================================================================
>> RCS file: /cvsroot/lirc/lirc/drivers/lirc_imon/lirc_imon.c,v
>> retrieving revision 1.114
>> diff -u -p -r1.114 lirc_imon.c
>> --- lirc_imon.c 10 Jan 2010 21:24:08 -0000      1.114
>> +++ lirc_imon.c 30 Jan 2010 05:05:38 -0000
>> @@ -579,6 +579,10 @@ static int send_packet(struct imon_conte
>>
>>        /* Check if we need to use control or interrupt urb */
>>        if (!context->tx_control) {
>> +               if (!context->tx_endpoint) {
>> +                       err("%s: device has no tx endpoint", __func__);
>> +                       return -EINVAL;
>> +               }
>>                pipe = usb_sndintpipe(context->usbdev_intf0,
>>                                      context->tx_endpoint->bEndpointAddress);
>>                interval = context->tx_endpoint->bInterval;
>> @@ -2203,7 +2207,8 @@ static int imon_probe(struct usb_interfa
>>        }
>>
>>        /* set IR protocol/remote type */
>> -       imon_set_ir_protocol(context);
>> +       if (context->tx_control || context->tx_endpoint)
>> +               imon_set_ir_protocol(context);
>>
>>        printk(KERN_INFO MOD_NAME ": iMON device (%04x:%04x, intf%d) on "
>>               "usb<%d:%d> initialized\n", vendor, product, ifnum,
>>
>>     
>
> Paul confirmed this did the trick off-list, so I've committed this
> patch to lirc cvs.
>
>
>   

-- 
Paul Sijben
tel 0334557522