[mythtv-users] iMON & ir-keytable on Fedora 15

Tue May 31 01:20:12 UTC 2011

On 5/28/2011 7:59 PM, Jarod Wilson wrote:
> On May 27, 2011, at 9:52 PM, Erik Sejr wrote:
>
>> On 5/27/2011 7:27 PM, Erik Sejr wrote:
>>> On 5/27/2011 2:53 AM, Douglas Clowes wrote:
>>>> On 2011-05-27 18:11, Erik Sejr wrote:
>>>>> Hello list,
>>>>> I've got an Antec case with a Soundgraph (iMon) LCD&  IR receiver. I
>>>>> recently upgraded from Fedora 13 to Fedora 15, and I read over some of
>>>>> Jarods changes in the imon module (particularly the removal of the
>>>>> ir_protocol option). I was using this option to set the device to MCE
>>>>> mode (ir_protocol = 1) in Fedora 13 and running lircd using the devinput
>>>>> driver.
>>>>>
>>> Thanks for the responses. I read over your post Rob, and that seems to
>>> cover very well what needs to be done to set it up, and it matches up
>>> quite well to what i'm doing.
>>>
>>> When I run ir-keytable like that Rob, it appears to work and it does not
>>> segfault. I ran it in test mode right after 'ir-keytable -s rc0 -t' and
>>> tried a few buttons on the remote. Nothing.
>>>
>>> I was reading another post in which Jarod included the option for the
>>> module to enable debug mode. I added this to my config and rebooted the
>>> machine (just in case). I re-ran ir-keytable -s rc0 -c -w
>>> /etc/rc_keymaps/rc6_mce -p rc6 and this time it hung trying to switch
>>> the protocol (it did indicate it cleared and wrote the table). I killed
>>> it with CTRL+C, then checked dmesg for debug output from imon and found
>>> this:
>>>
>>> [  239.450438] imon:send_packet: error submitting urb(-22)
>>> [  239.455427] imon:lcd_write: send packet failed!
>>> [  294.911327] ------------[ cut here ]------------
>>> [  294.911335] WARNING: at lib/list_debug.c:53 __list_del_entry+0x8d/0x98()
>>> [  294.911337] Hardware name: EX58-UD5
>>> [  294.911339] list_del corruption. prev->next should be
>>> ffff88003795dd28, but was ffff88019e9098d8
>>> [  294.911341] Modules linked in: uinput fuse ipt_MASQUERADE iptable_nat
>>> nf_nat xt_recent nfs lockd fscache nfs_acl auth_rpcgss sunrpc
>>> cpufreq_ondemand acpi_cpufreq freq_table mperf xfs exportfs
>>> snd_hda_codec_hdmi nvidia(P) rc_imon_pad ir_sony_decoder hdpvr
>>> ir_jvc_decoder ir_rc6_decoder v4l2_common ir_rc5_decoder videodev imon
>>> ir_nec_decoder v4l2_compat_ioctl32 rc_core joydev snd_hda_intel
>>> snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm microcode
>>> serio_raw iTCO_wdt r8169 i7core_edac iTCO_vendor_support i2c_i801
>>> snd_timer snd i2c_core mii edac_core soundcore snd_page_alloc wmi ipv6
>>> firewire_ohci ata_generic firewire_core pata_acpi uas usb_storage
>>> crc_itu_t pata_jmicron [last unloaded: lirc_dev]
>>> [  294.911375] Pid: 13673, comm: ir-keytable Tainted: P           
>>> 2.6.38.6-27.fc15.x86_64 #1
>>> [  294.911377] Call Trace:
>>> [  294.911382]  [<ffffffff8105510e>] warn_slowpath_common+0x83/0x9b
>>> [  294.911384]  [<ffffffff810551c9>] warn_slowpath_fmt+0x46/0x48
>>> [  294.911387]  [<ffffffff812377ed>] __list_del_entry+0x8d/0x98
>>> [  294.911389]  [<ffffffff81237806>] list_del+0xe/0x2d
>>> [  294.911394]  [<ffffffff814743b7>] wait_for_common+0xd3/0x101
>>> [  294.911398]  [<ffffffff8104df76>] ? default_wake_function+0x0/0x14
>>> [  294.911400]  [<ffffffff81474458>]
>>> wait_for_completion_interruptible+0x1d/0x2c
>>> [  294.911405]  [<ffffffffa0cf723d>] send_packet+0x1e3/0x270 [imon]
>>> [  294.911408]  [<ffffffffa0cf74b8>] imon_ir_change_protocol+0x138/0x181
>>> [imon]
>>> [  294.911412]  [<ffffffffa0cbe304>] store_protocols+0x199/0x26e [rc_core]
>>> [  294.911416]  [<ffffffff812e2958>] dev_attr_store+0x20/0x22
>>> [  294.911420]  [<ffffffff811793d1>] sysfs_write_file+0x111/0x14d
>>> [  294.911425]  [<ffffffff81121829>] vfs_write+0xac/0xf3
>>> [  294.911427]  [<ffffffff81121a18>] sys_write+0x4a/0x6e
>>> [  294.911430]  [<ffffffff81009bc2>] system_call_fastpath+0x16/0x1b
>>> [  294.911432] ---[ end trace b9578ab86a371b80 ]---
>>> [  294.911433] imon:send_packet: task interrupted
>>>
>>> So I re-ran it (exactly the same command line) and this time, no hang
>>> and no backtrace in dmesg.  I did notice that every time I unload, and
>>> reload the module the imon:send_packet: error submitting urb(-22)
>>> message appears in dmesg.
>>>
>>> Trying the remote again it appears the signals are being decoded:
>>>
>>> [  766.129258] intf0 decoded packet: 02 00 00 4f 00 00 00 00
>>> [  766.225164] intf0 decoded packet: 02 00 00 00 00 00 00 00
>>>
>>> and, looking at the mce keymap table the code is correct based on the
>>> button I pressed, but it appears nothing is ever passed out the event
>>> device in /dev. I've tried to hexdump it and I see nothing at on the
>>> kernel interface device.
>>>
>>> lrwxrwxrwx 1 root root 9 May 27 18:31 usb-15c2_0038-event-if00 -> ../event7
>>> Bus 006 Device 002: ID 15c2:0038 SoundGraph Inc. GD01 MX VFD Display/IR
>>> Receiver
>>>
>>> I'm guessing this may be a bug in iMon,
> Nope. That looks like an rc-core bug, which I submitted a patch for upstream
> a week or two ago, with stable cc'd, so it should wind up in 2.6.38 and 2.6.39
> as well, sooner or later.
>
>
>>> as it was working OK back with
>>> F13 and an earlier version of the module. Is there a place I can send
>>> Jarod a bug report on imon?
> If its a Fedora bug, you can hit up bugzilla.redhat.com. The canonical upstream
> locations are linux-media at vger.kernel.org and bugzilla.kernel.org though, if its
> not something Fedora-specific. 
>
>
>> Ok, I figured this out, as it turns out I was using the wrong keymap for
>> the way my remote was programmed, I needed imon_mce and not rc6_mce.
> They're for the same remote, but the rc6_mce one is raw IR, the imon_mce
> one is for the stupid piece of crap onboard decoder in the imon hardware,
> which passes along what looks sort of like rc6 signals as scancodes for
> some signals, and something completely different for others..
>
>
>> I
>> got the two files mixed up in my head and was looking in one when I
>> thought I was looking in the other. Sorry. Its all working now (though
>> the crash there was a little odd).
> Pretty sure that's the has-change_protocol variant of this:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=08aeb7c9a42ab7aa8b53c8f7779ec58f860a565c
>
Thanks Jarod, i'm sure that fix will come along in a kernel update at
some point in the future. I do like where your work on IR support is
going, I think it'll provide a better and simpler way of making use of
remotes in Linux. Thanks also for all the work you put into the iMon
driver and your tireless efforts supporting the users of it.

Erik