Lirc mceusb resume problem

[Lupick]

Binary package hint: lirc

Dear All

I've XBMC 10.1 running on Ubuntu 11.04. I'm using a mceusb dongle

I've installed lirc and my harmony remote works fine.

The main problem is after the suspend the remote is not able to resume the pc and if I manually do it lirc is not working anymore.

with ubuntu 10.10 the problem was solved using the following howto:

http://wiki.xbmc.org/?title=Automati..._resume_script

but it looks like it's not working on 11.04.

I've tried to:

1. stop lirc
2. rmmod --force lirc_dev
3. rmmod --force mceusb
but it looks like I ca't "ERROR resource busy" or sometime the command hang.

Thank you

L.

[Jarod Wilson (jarod-wilsonet)]

That "automatic lirc resume script" is full of fail. Wtf is it trying to rmmod/modprobing the driver for? Who comes up with this sort of dreadful crap?

[Lupick (lupick)]

Now I'm able to resume the PC using the remote.

After the resume lirc stop working and I've to reboot.

L.

[Ari (ari-reads)]

Reposting the link to the xbmc wiki as it doesn't work (at least for me).

http://wiki.xbmc.org/index.php?title=Automatic_lirc_resume_script

With or without the script, after resume, lirc in 11.04 just dies and won't work until the machine is rebooted.

In my case, after resume, the usb receiver dongle will will light up and stay on forever (normally, after the remote stops emiting, it the LED will turn off). Then the remote becomes unusable.

lsusb:
Bus 004 Device 002: ID 1784:0008 TopSeed Technology Corp. eHome Infrared Transceiver

 cat /proc/bus/input/devices

I: Bus=0003 Vendor=1784 Product=0008 Version=0101
N: Name="Media Center Ed. eHome Infrared Remote Transceiver (1784:0008)"
P: Phys=usb-0000:00:12.0-3
S: Sysfs=/devices/pci0000:00/0000:00:12.0/usb4/4-3/4-3:1.0/rc/rc0/input2
U: Uniq=
H: Handlers=kbd event2
B: PROP=0
B: EV=100013
B: KEY=fff 0 200108fc326 237605100000000 0 700158000 419200100001 9e968000000000 10000000
B: MSC=10

[Jarod Wilson (jarod-wilsonet)]

Okay, so it looks like there may well be some work that needs to be done on the resume function of the mceusb driver. Getting that squared away is the real answer to this problem, not some highly questionable script. I have the topseed 1784:0008 device myself, should be able to reproduce (and fix) the problem in relatively short order.

Sidebar: this bug really should have been reported at bugzilla.kernel.org and/or brought to the attention of the lirc or linux-media mailing lists, but then again, that why I (as a non-Ubuntu user) went ahead and subscribed myself to launchpad lirc bugs...

[Lupick (lupick)]

Ok,

Please let me know if you are able to find a fix /workaround!

L.

On Fri, Jun 10, 2011 at 4:16 AM, Jarod Wilson <email address hidden> wrote:
> Okay, so it looks like there may well be some work that needs to be done
> on the resume function of the mceusb driver. Getting that squared away
> is the real answer to this problem, not some highly questionable script.
> I have the topseed 1784:0008 device myself, should be able to reproduce
> (and fix) the problem in relatively short order.
>
> Sidebar: this bug really should have been reported at
> bugzilla.kernel.org and/or brought to the attention of the lirc or
> linux-media mailing lists, but then again, that why I (as a non-Ubuntu
> user) went ahead and subscribed myself to launchpad lirc bugs...
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/789819
>
> Title:
>  Lirc mceusb resume problem
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/lirc/+bug/789819/+subscriptions
>

[Ari (ari-reads)]

I tried a new kernel hoping the issue was addressed, but no luck.

Kernel 2.6.39-3 (xorg-edgers ppa) shows the exact same problem. After resume, the IR receiver LED stays ON and the remote is no longer responsive.

When the machine wakes up (using the remote), this is what shows up in the system log: (see the "failed to initialize hardware" part.

****************

Jun 16 19:28:46 htpc kernel: [ 186.253837] Modules linked in: cryptd aes_x86_64 aes_generic vesafb snd_hda_codec_realtek arc4 ath9k snd_hda_codec_hdmi snd_hda_intel snd_seq_midi mac80211 snd_hda_codec snd_rawmidi snd_hwdep btusb ath9k_common ath9k_hw ath snd_seq_midi_event snd_pcm snd_seq bluetooth rc_rc6_mce ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder cfg80211 ir_nec_decoder psmouse mceusb xhci_hcd rc_core k10temp serio_raw snd_timer snd_seq_device sp5100_tco i2c_piix4 fglrx(P) snd soundcore snd_page_alloc lp parport ahci r8169 libahci

Jun 16 19:28:46 htpc kernel: [ 186.293822] Code: 5c 41 5d 41 5e 41 5f c9 c3 0f 1f 00 49 8b 96 e8 c0 2f a0 48 c7 c6 33 c2 2f a0 eb ac 0f 1f 84 00 00 00 00 00 48 8b 87 c0 02 00 00 <4c> 8b 68 50 e8 c0 19 00 00 48 89 c3 e9 3f ff ff ff 4c 89 e9 48
Jun 16 19:28:46 htpc kernel: [ 186.294265] RIP [<ffffffffa02f96f7>] show_protocols+0xf7/0x130 [rc_core]
Jun 16 19:28:46 htpc kernel: [ 186.294338] RSP <ffff88003c99de38>
Jun 16 19:28:46 htpc kernel: [ 186.294374] CR2: 0000000000000050
Jun 16 19:28:46 htpc kernel: [ 186.294410] ---[ end trace d0499d14df5dda02 ]---
Jun 16 19:28:46 htpc kernel: [ 186.431342] lirc_dev: module unloaded
Jun 16 19:28:46 htpc kernel: [ 186.441789] lirc_dev: IR Remote Control driver registered, major 250
Jun 16 19:28:46 htpc kernel: [ 186.444385] ir_lirc_codec: Unknown parameter `lirc_dev'
Jun 16 19:28:46 htpc lircd-0.8.7[2103]: lircd(default) ready, using /var/run/lirc/lircd
Jun 16 19:28:46 htpc lircd-0.8.7[2103]: accepted new client on /var/run/lirc/lircd
Jun 16 19:28:46 htpc lircd-0.8.7[2103]: could not get file information for /dev/lirc0
Jun 16 19:28:46 htpc lircd-0.8.7[2103]: default_init(): No such file or directory
Jun 16 19:28:46 htpc lircd-0.8.7[2103]: Failed to initialize hardware
Jun 16 19:28:46 htpc kernel: [ 186.797439] EXT4-fs (sdb1): re-mounted. Opts: discard,errors=remount-ro,commit=0
Jun 16 19:28:46 htpc kernel: [ 186.809922] EXT4-fs (sda1): re-mounted. Opts: commit=0
Jun 16 19:28:47 htpc lircd-0.8.7[2103]: accepted new client on /var/run/lirc/lircd
Jun 16 19:29:53 htpc lircd-0.8.7[2103]: caught signal
Jun 16 19:29:53 htpc lircd-0.8.7[2314]: lircd(default) ready, using /var/run/lirc/lircd

[Jarod Wilson (jarod-wilsonet)]

What is this business about:

----8<----
Jun 16 19:28:46 htpc kernel: [ 186.431342] lirc_dev: module unloaded
Jun 16 19:28:46 htpc kernel: [ 186.441789] lirc_dev: IR Remote Control driver registered, major 250
Jun 16 19:28:46 htpc kernel: [ 186.444385] ir_lirc_codec: Unknown parameter `lirc_dev'
----8<----

You appear to have something still running (like that horrific xbmc script) that is doing BAD THINGS.

I just tried to reproduce the problem here with a sane install, and the mceusb driver suspends and resumes just fine when you don't do crazy crap like trying to force-remove modules. Left an active session running, spitting out key data received by the mceusb hardware, and it picks up and keeps on working after a full suspend and resume cycle. As far as I'm concerned, there's no mceusb driver bug here.

[Ari (ari-reads)]

Hi Jarod - you are correct, the script was installed when I took the log, a leftover of trying to find a workaround. Sorry for the clutter on my previous post, please disregard it.

I removed the script, same result (this is where I got started, actually):

Boot-up log:

Jun 17 22:37:21 htpc kernel: [ 4.343722] usb usb9: No SuperSpeed endpoint companion for config 1 interface 0 altsetting 0 ep 129: using minimum values
Jun 17 22:37:21 htpc kernel: [ 4.391083] IR NEC protocol handler initialized
Jun 17 22:37:21 htpc kernel: [ 4.421626] IR RC5(x) protocol handler initialized
Jun 17 22:37:21 htpc kernel: [ 4.443968] xHCI xhci_add_endpoint called for root hub
Jun 17 22:37:21 htpc kernel: [ 4.443978] xHCI xhci_check_bandwidth called for root hub
Jun 17 22:37:21 htpc kernel: [ 4.445025] IR RC6 protocol handler initialized
Jun 17 22:37:21 htpc kernel: [ 4.454178] hub 9-0:1.0: USB hub found
Jun 17 22:37:21 htpc kernel: [ 4.454202] hub 9-0:1.0: 4 ports detected
Jun 17 22:37:21 htpc kernel: [ 4.462468] cfg80211: Calling CRDA to update world regulatory domain
Jun 17 22:37:21 htpc kernel: [ 4.463728] IR JVC protocol handler initialized
Jun 17 22:37:21 htpc kernel: [ 4.479351] IR Sony protocol handler initialized
Jun 17 22:37:21 htpc kernel: [ 4.494324] lirc_dev: IR Remote Control driver registered, major 251
Jun 17 22:37:21 htpc kernel: [ 4.499261] IR LIRC bridge handler initialized
Jun 17 22:37:21 htpc kernel: [ 4.589881] Bluetooth: Core ver 2.15
Jun 17 22:37:21 htpc kernel: [ 4.589973] NET: Registered protocol family 31
Jun 17 22:37:21 htpc kernel: [ 4.589977] Bluetooth: HCI device and connection manager initialized
Jun 17 22:37:21 htpc kernel: [ 4.589982] Bluetooth: HCI socket layer initialized
Jun 17 22:37:21 htpc kernel: [ 4.593916] Bluetooth: Generic Bluetooth USB driver ver 0.6
Jun 17 22:37:22 htpc kernel: [ 4.597809] usbcore: registered new interface driver btusb
Jun 17 22:37:22 htpc kernel: [ 4.630116] Registered IR keymap rc-rc6-mce
Jun 17 22:37:22 htpc kernel: [ 4.630309] input: Media Center Ed. eHome Infrared Remote Transceiver (1784:0008) as /devices/pci0000:00/0000:00:12.0/usb4/4-3/4-3:1.0/rc/rc0/input2
Jun 17 22:37:22 htpc kernel: [ 4.630432] rc0: Media Center Ed. eHome Infrared Remote Transceiver (1784:0008) as /devices/pci0000:00/0000:00:12.0/usb4/4-3/4-3:1.0/rc/rc0
Jun 17 22:37:22 htpc kernel: [ 4.636151] rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered at minor = 0
Jun 17 22:37:22 htpc kernel: [ 4.636189] mceusb 4-3:1.0: Registered Topseed Technology Corp. eHome Infrared Transceiver on usb4:2
Jun 17 22:37:22 htpc kernel: [ 4.636315] usbcore: registered new interface driver mceusb
Jun 17 22:37:22 htpc kernel: [ 4.684405] input: Eee PC WMI hotkeys as /devices/platform/eeepc-wmi/input/input3

Suspend part:

Jun 17 22:37:56 htpc kernel: [ 25.554946] Freezing user space processes ... (elapsed 0.01 seconds) done.
Jun 17 22:37:56 htpc kernel: [ 25.570377] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Jun 17 22:37:56 htpc kernel: [ 25.590347] PM: Entering mem sleep
Jun 17 22:37:56 htpc kernel: [ 25.590471] Suspending console...

[Jarod Wilson (jarod-wilsonet)]

Is the Ubuntu lirc initscript restarting lircd on resume? Or is this a udev rule running? Gotta be one of those two, since otherwise, I don't know what would be triggering the call to show_protocols. You included the trace for your wireless doing something bad, but omitted the bulk of the trace for the actual oops. Can I get the full oops trace please?

Basically, I think this is a manifestation of something I've already submitted a fix for upstream, but its a slightly unexpected one.

http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-ir.git;a=commitdiff;h=43a931f8c6f291a7d0c055bc282bdc1847b299e7

[Ari (ari-reads)]

Attached the full syslog - boot, suspend, resume, where the issue can be seen.

Things to note:

- I use ATI/AMD catalyst drivers (official ubuntu package / Catalyst 11.5, from Natty X-Updates ppa)

 - Also (not sure if this is relevant or not) I have a simple python script running all the time (launched from rc.local) that will check every 60 seconds whether my wireless router is pingable and if it is not, it will bring down wlan0 and then bring it up again.

This was done with natty's kernel 2.6.38 kernel (with natty-proposed enabled). Testing with 2.6.39-3 kernel from this other PPA:

https://launchpad.net/~xorg-edgers/+archive/ppa?field.series_filter=natty

produced the same result (lirc dies on resume).

Note also that when the issue happens, doing /etc/init.d/lirc restart doesn't fix the problem (irw doesn't show the remote keys anymore)

[Jarod Wilson (jarod-wilsonet)]

So three problems here:

1) During resume, we see this:
kernel: [ 29.950131] usb 4-3: USB disconnect, address 2

This is your mceusb device. For some reason, your USB chipset isn't being suspended correctly, and its causing a full disconnect and reconnect of at least mceusb device. That's bad (and not mceusb's fault).

2) lirc is being restarted, rather than simply left running. The lirc daemon should be able to handle a lirc device coming and going from underneath it without requiring a restart like this, best as I can recall. But I think its some Ubuntu "feature-add" udev rule that restarts lircd when a new device is connected -- see item #1, the reconnect looks like a new device being connected.

3) When lirc is being restarted, its calling show_protocols before everything is actually wired up, which is indeed the bug I referenced earlier that a fix for has already been sent upstream.

kernel: [ 30.053825] Pid: 1693, comm: cat Tainted: P W 2.6.38-10-generic #44-Ubuntu System manufacturer System Product Name/E35M1-I DELUXE
kernel: [ 30.053832] RIP: 0010:[<ffffffffa03d76e7>] [<ffffffffa03d76e7>] show_protocols+0xf7/0x130 [rc_core]

At this point, nothing more that I can do. The fix for #3 was sent upstream and the stable team cc'd, so in theory, that patch will eventually make it into a stable series kernel and then into an Ubuntu kernel. Item #2 requires someone in Ubuntu-land who knows better what's going on to evaluate, and #1, not sure, probably requires someone in usb-land upstream to fix suspend and resume with your particular usb chipset.

[Ari (ari-reads)]

As part of the installation of LIRC, I created the following (as part of a how-to recipe):

$ pwd
/etc/udev/rules.d
$ cat 10-local.rules
KERNEL=="event*",ATTRS{idVendor}=="1784",ATTRS{idProduct}=="0008",SYMLINK="input/irremote"
$ cat 90-mcewakeup.rules
SUBSYSTEM=="usb", ATTRS{idVendor}=="1784", ATTRS{idProduct}=="0008" RUN+="/bin/sh -c 'echo enabled > /sys$env{DEVPATH}/../power/wakeup'"

Wondering if this looks OK? could this be connected to the udev "restart" that you mentioned?

Also, I found that pm-tools (used in ubuntu to handle suspend/resume) would list any modules to be unloaded in a file here:
/etc/pm/config.d/
however in my installation, this is empty.
I captured the "pm-suspend.log" output, just for reference: http://paste.kde.org/85057/raw/
This doesn't show lirc unloading either.
Any pointer on where lirc may be unloaded by ubuntu?

Regarding 3), is there a way I could test the patch?

Last but not least, I'm supposed to receive a new remote next month (the new motorola nyxboard), so I will be able to test with it as well.

Currently, after a resume, irw says "connection refused", cat /proc/bus/input/devices no longer shows the remote device, and /etc/init.d/lirc restart produces no change. Plugging/unplugging the receiver and then reloading lirc also produces no result.

[Jarod Wilson (jarod-wilsonet)]

The added udev rules look fine, they should be harmless and unrelated here. The pm-suspend log looks fine too. The problem is that your usb controller appears to be forcing a full disconnect and reconnect of all usb devices. That equates to a new mceusb device being plugged in, and some udev and/or upstart rule running that restarts lirc. Take a look at the lirc initscript and whatever else is installed as part of the ubuntu lirc package.

For #3, you're more than welcome to pull a copy of the patch and build a kernel locally to test.

Having a non-functional irw post-resume is expected in this case. The mceusb device got disconnected, then the kernel oopsed on reconnect. The rc-core subsystem and mceusb driver are both in suspect states, and memory corruption has occurred. All bets are off at that point, until you reboot.

The nyxboard is mostly uninteresting, its simply an HID device. The fact there's RF involved is entirely opaque to the kernel.

[Ari (ari-reads)]

can you post a link to the patch? I will try to manually apply it to ubuntu 11.04's kernel and recompile it. will try and see what happens...

[Jarod Wilson (jarod-wilsonet)]

Already posted a link to the patch in comment #9.

[Mike (kismitt)]

Did this matter ever get resolved for 11.04? I'm having the same issue after resume. It was working great under 10.10 and now after upgrading to 11.04 it stop working. Here's the bug I open up:

https://bugs.launchpad.net/ubuntu/+source/lirc/+bug/816598

[Alec Leamas (leamas-alec)]

Possibly wrong kernel version, but this is definitely about the kernel modules and suspend-resume. Meda subsystem, BTW