Mailing List Archive: MythTV: Users

mce remote (lirc) fails after resume from standby

Index | Next | Previous | View Threaded

alan at alanmarian

Jun 27, 2009, 8:15 PM

Post #1 of 13 (1347 views)
Permalink

mce remote (lirc) fails after resume from standby

I have most of my issues figured out but getting the remote to work
consistently after standby is still causing problems. The only
reliable way to get the remote to work is unplug the usb receiver and
plug it back in. Restarting lirc or myth doesn't help. Most of the
time it fails but every once in a while it works fine. Below is the
relevant parts from syslog after a resume (showing the failure). The
call trace seems to indicate something is breaking... but what, why,
and how to fix it?

Thanks

Jun 27 21:04:37 fe1 kernel: [ 1008.813863] ACPI: Waking up from system
sleep state S3
<snip>...
Jun 27 21:04:37 fe1 kernel: [ 1011.656021] usb 2-1: reset low speed
USB device using ohci_hcd and address 2
Jun 27 21:04:37 fe1 kernel: [ 1012.356020] usb 2-2: reset low speed
USB device using ohci_hcd and address 3
Jun 27 21:04:37 fe1 kernel: [ 1013.044020] usb 2-3: reset low speed
USB device using ohci_hcd and address 4
Jun 27 21:04:37 fe1 kernel: [ 1013.584021] usb 2-4: reset full speed
USB device using ohci_hcd and address 5
Jun 27 21:04:37 fe1 kernel: [ 1013.799863] lirc_mceusb2 2-4:1.0: no
reset_resume for driver lirc_mceusb2?
Jun 27 21:04:37 fe1 kernel: [ 1013.799887] lirc_mceusb2[5]: usb remote
disconnected
Jun 27 21:04:37 fe1 kernel: [ 1013.980023] usb 2-4: reset full speed
USB device using ohci_hcd and address 5
Jun 27 21:04:37 fe1 kernel: [ 1014.189839] lirc_dev:
lirc_register_plugin: sample_rate: 0
Jun 27 21:04:37 fe1 kernel: [ 1014.195835] lirc_mceusb2[5]: Philips
eHome Infrared Transceiver on usb2:5
Jun 27 21:04:37 fe1 kernel: [ 1014.195915] PM: resume devices took 5.376 seconds
Jun 27 21:04:37 fe1 kernel: [ 1014.195921] ------------[ cut here ]------------
Jun 27 21:04:37 fe1 kernel: [ 1014.195923] WARNING: at
/build/buildd/linux-2.6.28/kernel/power/main.c:177
suspend_test_finish+0x7c/0x80()
Jun 27 21:04:37 fe1 kernel: [ 1014.195924] Component: resume devices
Jun 27 21:04:37 fe1 kernel: [ 1014.195925] Modules linked in:
nls_cp437 cifs ppdev bridge stp bnep input_polldev video output xfs lp
parport snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss
snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi
snd_seq_midi_event snd_seq snd_timer snd_seq_device snd soundcore
lirc_mceusb2 i2c_nforce2 serio_raw pcspkr snd_page_alloc k8temp
lirc_dev joydev nvidia(P) hid_logitech ff_memless usbhid forcedeth
fbcon tileblit font bitblit softcursor
Jun 27 21:04:37 fe1 kernel: [ 1014.195946] Pid: 6110, comm: pm-suspend
Tainted: P 2.6.28-13-generic #44-Ubuntu
Jun 27 21:04:37 fe1 kernel: [ 1014.195948] Call Trace:
Jun 27 21:04:37 fe1 kernel: [ 1014.195953] [<ffffffff80250927>]
warn_slowpath+0xb7/0xf0
Jun 27 21:04:37 fe1 kernel: [ 1014.195956] [<ffffffff8026d478>] ?
down_trylock+0x38/0x50
Jun 27 21:04:37 fe1 kernel: [ 1014.195959] [<ffffffff80251040>] ?
try_acquire_console_sem+0x10/0x40
Jun 27 21:04:37 fe1 kernel: [ 1014.195962] [<ffffffff8025c676>] ?
lock_timer_base+0x36/0x70
Jun 27 21:04:37 fe1 kernel: [ 1014.195965] [<ffffffff80531fcf>] ?
usb_suspend_both+0x26f/0x310
Jun 27 21:04:37 fe1 kernel: [ 1014.195969] [<ffffffff80697836>] ?
printk+0x67/0x69
Jun 27 21:04:37 fe1 kernel: [ 1014.195972] [<ffffffff804188a7>] ?
kobject_put+0x27/0x60
Jun 27 21:04:37 fe1 kernel: [ 1014.195975] [<ffffffff804b6075>] ?
put_device+0x15/0x20
Jun 27 21:04:37 fe1 kernel: [ 1014.195979] [<ffffffff804be09a>] ?
dpm_complete+0x18a/0x1a0
Jun 27 21:04:37 fe1 kernel: [ 1014.195981] [<ffffffff8028003c>]
suspend_test_finish+0x7c/0x80
Jun 27 21:04:37 fe1 kernel: [ 1014.195984] [<ffffffff80280124>]
suspend_devices_and_enter+0xe4/0x180
Jun 27 21:04:37 fe1 kernel: [ 1014.195986] [<ffffffff802803d9>]
enter_state+0xe9/0x120
Jun 27 21:04:37 fe1 kernel: [ 1014.195989] [<ffffffff802804ca>]
state_store+0xba/0x100
Jun 27 21:04:37 fe1 kernel: [ 1014.195991] [<ffffffff80418747>]
kobj_attr_store+0x17/0x20
Jun 27 21:04:37 fe1 kernel: [ 1014.195993] [<ffffffff80347675>]
sysfs_write_file+0xc5/0x140
Jun 27 21:04:37 fe1 kernel: [ 1014.195997] [<ffffffff802e7eeb>]
vfs_write+0xcb/0x130
Jun 27 21:04:37 fe1 kernel: [ 1014.195999] [<ffffffff802e8040>]
sys_write+0x50/0x90
Jun 27 21:04:37 fe1 kernel: [ 1014.196013] [<ffffffff8021253a>]
system_call_fastpath+0x16/0x1b
Jun 27 21:04:37 fe1 kernel: [ 1014.196015] ---[ end trace bfba85e0b835c862 ]---
Jun 27 21:04:37 fe1 kernel: [ 1014.196103] PM: Finishing wakeup.
Jun 27 21:04:37 fe1 lircd-0.8.4a[1652]: error reading from /dev/lirc0
Jun 27 21:04:37 fe1 lircd-0.8.4a[1652]: No such device
Jun 27 21:04:37 fe1 kernel: [ 1014.196104] Restarting tasks ... done.
Jun 27 21:04:37 fe1 lircd-0.8.4a[1652]: caught signal
Jun 27 21:04:37 fe1 lircd-0.8.4a[6251]: lircd(default) ready
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

peloy at chapus

Jun 28, 2009, 5:45 AM

Post #2 of 13 (1281 views)
Permalink

Re: mce remote (lirc) fails after resume from standby [In reply to]

Hi Alan,

On Sat, Jun 27, 2009 at 09:15:13PM -0600, Alan Marchiori wrote:

> I have most of my issues figured out but getting the remote to work
> consistently after standby is still causing problems. The only
> reliable way to get the remote to work is unplug the usb receiver and
> plug it back in. Restarting lirc or myth doesn't help. Most of the
> time it fails but every once in a while it works fine. Below is the
> relevant parts from syslog after a resume (showing the failure). The
> call trace seems to indicate something is breaking... but what, why,
> and how to fix it?

The "warn_slowpat" stack trace may not be a problem -- I've seen it in
the past and haven't noticed any bad effects; I think it just means (at
least in some cases) that some driver took longer to wake up.

I also had problems with my MCE remote after resume from S3 sleep. It
was weird because things would work fine if I resumed by pressing the
machine's power botton instead of doing an USB resume by pressing the
power button on the remote.

I ended up adding one line to the lirc_mceusb2.c file and this fixed the
problem for me:

root [at] altamir:/usr/src/lirc-0.8.4a/drivers/lirc_mceusb2# diff -u lirc_mceusb2.c.orig lirc_mceusb2.c
--- lirc_mceusb2.c.orig 2009-01-28 16:56:52.000000000 -0500
+++ lirc_mceusb2.c 2009-01-28 16:29:26.000000000 -0500
@@ -1121,6 +1121,7 @@
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 0)
.suspend = usb_remote_suspend,
.resume = usb_remote_resume,
+ .reset_resume = usb_remote_resume,
#endif
.id_table = usb_remote_table
};

This was for lirc 0.8.4a. I just checked lirc 0.8.5 and they've changed
function names but the driver structure is still lacking a .reset_resume
field.

I don't know if the above will fix your resume problem, but my
recommendation is that you try the above patch. As I said, resuming from
S3 sleep by pressing the remote's power botton would not work at all
for me without the above little patch, and I've been running for a few
months with the above patch with no ill or side effects.

Cheers,

Eloy Paris.-

> Jun 27 21:04:37 fe1 kernel: [ 1008.813863] ACPI: Waking up from system
> sleep state S3
> <snip>...
> Jun 27 21:04:37 fe1 kernel: [ 1011.656021] usb 2-1: reset low speed
> USB device using ohci_hcd and address 2
> Jun 27 21:04:37 fe1 kernel: [ 1012.356020] usb 2-2: reset low speed
> USB device using ohci_hcd and address 3
> Jun 27 21:04:37 fe1 kernel: [ 1013.044020] usb 2-3: reset low speed
> USB device using ohci_hcd and address 4
> Jun 27 21:04:37 fe1 kernel: [ 1013.584021] usb 2-4: reset full speed
> USB device using ohci_hcd and address 5
> Jun 27 21:04:37 fe1 kernel: [ 1013.799863] lirc_mceusb2 2-4:1.0: no
> reset_resume for driver lirc_mceusb2?
> Jun 27 21:04:37 fe1 kernel: [ 1013.799887] lirc_mceusb2[5]: usb remote
> disconnected
> Jun 27 21:04:37 fe1 kernel: [ 1013.980023] usb 2-4: reset full speed
> USB device using ohci_hcd and address 5
> Jun 27 21:04:37 fe1 kernel: [ 1014.189839] lirc_dev:
> lirc_register_plugin: sample_rate: 0
> Jun 27 21:04:37 fe1 kernel: [ 1014.195835] lirc_mceusb2[5]: Philips
> eHome Infrared Transceiver on usb2:5
> Jun 27 21:04:37 fe1 kernel: [ 1014.195915] PM: resume devices took 5.376 seconds
> Jun 27 21:04:37 fe1 kernel: [ 1014.195921] ------------[ cut here ]------------
> Jun 27 21:04:37 fe1 kernel: [ 1014.195923] WARNING: at
> /build/buildd/linux-2.6.28/kernel/power/main.c:177
> suspend_test_finish+0x7c/0x80()
> Jun 27 21:04:37 fe1 kernel: [ 1014.195924] Component: resume devices
> Jun 27 21:04:37 fe1 kernel: [ 1014.195925] Modules linked in:
> nls_cp437 cifs ppdev bridge stp bnep input_polldev video output xfs lp
> parport snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss
> snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi
> snd_seq_midi_event snd_seq snd_timer snd_seq_device snd soundcore
> lirc_mceusb2 i2c_nforce2 serio_raw pcspkr snd_page_alloc k8temp
> lirc_dev joydev nvidia(P) hid_logitech ff_memless usbhid forcedeth
> fbcon tileblit font bitblit softcursor
> Jun 27 21:04:37 fe1 kernel: [ 1014.195946] Pid: 6110, comm: pm-suspend
> Tainted: P 2.6.28-13-generic #44-Ubuntu
> Jun 27 21:04:37 fe1 kernel: [ 1014.195948] Call Trace:
> Jun 27 21:04:37 fe1 kernel: [ 1014.195953] [<ffffffff80250927>]
> warn_slowpath+0xb7/0xf0
> Jun 27 21:04:37 fe1 kernel: [ 1014.195956] [<ffffffff8026d478>] ?
> down_trylock+0x38/0x50
> Jun 27 21:04:37 fe1 kernel: [ 1014.195959] [<ffffffff80251040>] ?
> try_acquire_console_sem+0x10/0x40
> Jun 27 21:04:37 fe1 kernel: [ 1014.195962] [<ffffffff8025c676>] ?
> lock_timer_base+0x36/0x70
> Jun 27 21:04:37 fe1 kernel: [ 1014.195965] [<ffffffff80531fcf>] ?
> usb_suspend_both+0x26f/0x310
> Jun 27 21:04:37 fe1 kernel: [ 1014.195969] [<ffffffff80697836>] ?
> printk+0x67/0x69
> Jun 27 21:04:37 fe1 kernel: [ 1014.195972] [<ffffffff804188a7>] ?
> kobject_put+0x27/0x60
> Jun 27 21:04:37 fe1 kernel: [ 1014.195975] [<ffffffff804b6075>] ?
> put_device+0x15/0x20
> Jun 27 21:04:37 fe1 kernel: [ 1014.195979] [<ffffffff804be09a>] ?
> dpm_complete+0x18a/0x1a0
> Jun 27 21:04:37 fe1 kernel: [ 1014.195981] [<ffffffff8028003c>]
> suspend_test_finish+0x7c/0x80
> Jun 27 21:04:37 fe1 kernel: [ 1014.195984] [<ffffffff80280124>]
> suspend_devices_and_enter+0xe4/0x180
> Jun 27 21:04:37 fe1 kernel: [ 1014.195986] [<ffffffff802803d9>]
> enter_state+0xe9/0x120
> Jun 27 21:04:37 fe1 kernel: [ 1014.195989] [<ffffffff802804ca>]
> state_store+0xba/0x100
> Jun 27 21:04:37 fe1 kernel: [ 1014.195991] [<ffffffff80418747>]
> kobj_attr_store+0x17/0x20
> Jun 27 21:04:37 fe1 kernel: [ 1014.195993] [<ffffffff80347675>]
> sysfs_write_file+0xc5/0x140
> Jun 27 21:04:37 fe1 kernel: [ 1014.195997] [<ffffffff802e7eeb>]
> vfs_write+0xcb/0x130
> Jun 27 21:04:37 fe1 kernel: [ 1014.195999] [<ffffffff802e8040>]
> sys_write+0x50/0x90
> Jun 27 21:04:37 fe1 kernel: [ 1014.196013] [<ffffffff8021253a>]
> system_call_fastpath+0x16/0x1b
> Jun 27 21:04:37 fe1 kernel: [ 1014.196015] ---[ end trace bfba85e0b835c862 ]---
> Jun 27 21:04:37 fe1 kernel: [ 1014.196103] PM: Finishing wakeup.
> Jun 27 21:04:37 fe1 lircd-0.8.4a[1652]: error reading from /dev/lirc0
> Jun 27 21:04:37 fe1 lircd-0.8.4a[1652]: No such device
> Jun 27 21:04:37 fe1 kernel: [ 1014.196104] Restarting tasks ... done.
> Jun 27 21:04:37 fe1 lircd-0.8.4a[1652]: caught signal
> Jun 27 21:04:37 fe1 lircd-0.8.4a[6251]: lircd(default) ready
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

alan at alanmarian

Jun 29, 2009, 8:44 PM

Post #3 of 13 (1249 views)
Permalink

Re: mce remote (lirc) fails after resume from standby [In reply to]

On Sun, Jun 28, 2009 at 6:45 AM, Eloy Paris<peloy [at] chapus> wrote:
> Hi Alan,
>
> On Sat, Jun 27, 2009 at 09:15:13PM -0600, Alan Marchiori wrote:
>
>> I have most of my issues figured out but getting the remote to work
>> consistently after standby is still causing problems. �The only
>> reliable way to get the remote to work is unplug the usb receiver and
>> plug it back in. �Restarting lirc or myth doesn't help. �Most of the
>> time it fails but every once in a while it works fine. �Below is the
>> relevant parts from syslog after a resume (showing the failure). �The
>> call trace seems to indicate something is breaking... but what, why,
>> and how to fix it?
>
> The "warn_slowpat" stack trace may not be a problem -- I've seen it in
> the past and haven't noticed any bad effects; I think it just means (at
> least in some cases) that some driver took longer to wake up.
>
> I also had problems with my MCE remote after resume from S3 sleep. It
> was weird because things would work fine if I resumed by pressing the
> machine's power botton instead of doing an USB resume by pressing the
> power button on the remote.
>
> I ended up adding one line to the lirc_mceusb2.c file and this fixed the
> problem for me:
>
> root [at] altamir:/usr/src/lirc-0.8.4a/drivers/lirc_mceusb2# diff -u lirc_mceusb2.c.orig lirc_mceusb2.c
> --- lirc_mceusb2.c.orig 2009-01-28 16:56:52.000000000 -0500
> +++ lirc_mceusb2.c � � �2009-01-28 16:29:26.000000000 -0500
> @@ -1121,6 +1121,7 @@
> �#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 0)
> � � � �.suspend = � � �usb_remote_suspend,
> � � � �.resume = � � � usb_remote_resume,
> + � � � .reset_resume = usb_remote_resume,
> �#endif
> � � � �.id_table = � � usb_remote_table
> �};
>
> This was for lirc 0.8.4a. I just checked lirc 0.8.5 and they've changed
> function names but the driver structure is still lacking a .reset_resume
> field.
>
> I don't know if the above will fix your resume problem, but my
> recommendation is that you try the above patch. As I said, resuming from
> S3 sleep by pressing the remote's power botton would not work at all
> for me without the above little patch, and I've been running for a few
> months with the above patch with no ill or side effects.
>

I made the patch did make & make install.

I now get the following in syslog:
Jun 29 21:34:18 fe1 lircd-0.8.4a[1577]: accepted new client on /dev/lircd
Jun 29 21:34:18 fe1 lircd-0.8.4a[1577]: could not get hardware features
Jun 29 21:34:18 fe1 lircd-0.8.4a[1577]: this device driver does not
support the new LIRC interface
Jun 29 21:34:18 fe1 lircd-0.8.4a[1577]: make sure you use a current
version of the driver
Jun 29 21:34:18 fe1 lircd-0.8.4a[1577]: Failed to initialize hardware

Is this a problem with using lirc 0.8.5? Or is something left over
from my old lirc setup (0.8.4.a)? I tried apt-get remove lirc but it
also wanted to remove a bunch of mythbuntu packages so I don't think I
want to do that.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

alan at alanmarian

Jun 29, 2009, 8:47 PM

Post #4 of 13 (1247 views)
Permalink

Re: mce remote (lirc) fails after resume from standby [In reply to]

>
> I made the patch did make & make install.
>
> I now get the following in syslog:
> Jun 29 21:34:18 fe1 lircd-0.8.4a[1577]: accepted new client on /dev/lircd
> Jun 29 21:34:18 fe1 lircd-0.8.4a[1577]: could not get hardware features
> Jun 29 21:34:18 fe1 lircd-0.8.4a[1577]: this device driver does not
> support the new LIRC interface
> Jun 29 21:34:18 fe1 lircd-0.8.4a[1577]: make sure you use a current
> version of the driver
> Jun 29 21:34:18 fe1 lircd-0.8.4a[1577]: Failed to initialize hardware
>
> Is this a problem with using lirc 0.8.5? �Or is something left over
> from my old lirc setup (0.8.4.a)? �I tried apt-get remove lirc but it
> also wanted to remove a bunch of mythbuntu packages so I don't think I
> want to do that.
>

wow, I just saw the lircd-0.8.4a all over those entries... strange
when I do this:

myth [at] fe:~$ which lircd
/usr/local/sbin/lircd
myth [at] fe:~$ /usr/local/sbin/lircd -v
lircd 0.8.5

must be a lircd 0.8.4a somewhere...
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

jarod at wilsonet

Jun 29, 2009, 8:52 PM

Post #5 of 13 (1248 views)
Permalink

Re: mce remote (lirc) fails after resume from standby [In reply to]

On Jun 29, 2009, at 11:44 PM, Alan Marchiori wrote:

> On Sun, Jun 28, 2009 at 6:45 AM, Eloy Paris<peloy [at] chapus> wrote:
>> Hi Alan,
>>
>> On Sat, Jun 27, 2009 at 09:15:13PM -0600, Alan Marchiori wrote:
...
>> I ended up adding one line to the lirc_mceusb2.c file and this
>> fixed the
>> problem for me:
>>
>> root [at] altamir:/usr/src/lirc-0.8.4a/drivers/lirc_mceusb2# diff -u
>> lirc_mceusb2.c.orig lirc_mceusb2.c
>> --- lirc_mceusb2.c.orig 2009-01-28 16:56:52.000000000 -0500
>> +++ lirc_mceusb2.c 2009-01-28 16:29:26.000000000 -0500
>> @@ -1121,6 +1121,7 @@
>> #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 0)
>> .suspend = usb_remote_suspend,
>> .resume = usb_remote_resume,
>> + .reset_resume = usb_remote_resume,
>> #endif
>> .id_table = usb_remote_table
>> };
>>
>> This was for lirc 0.8.4a. I just checked lirc 0.8.5 and they've
>> changed
>> function names but the driver structure is still lacking
>> a .reset_resume
>> field.
>>
>> I don't know if the above will fix your resume problem, but my
>> recommendation is that you try the above patch. As I said, resuming
>> from
>> S3 sleep by pressing the remote's power botton would not work at all
>> for me without the above little patch, and I've been running for a
>> few
>> months with the above patch with no ill or side effects.

Eloy, would you mind submitting this upstream to the lirc list? I
can't recall if you already did and it was overlooked, or what, but
send it there again, and I'll keep an eye out for it and see if we
can't get it included properly.

> I made the patch did make & make install.
>
> I now get the following in syslog:
> Jun 29 21:34:18 fe1 lircd-0.8.4a[1577]: accepted new client on /dev/
> lircd
> Jun 29 21:34:18 fe1 lircd-0.8.4a[1577]: could not get hardware
> features
> Jun 29 21:34:18 fe1 lircd-0.8.4a[1577]: this device driver does not
> support the new LIRC interface
> Jun 29 21:34:18 fe1 lircd-0.8.4a[1577]: make sure you use a current
> version of the driver
> Jun 29 21:34:18 fe1 lircd-0.8.4a[1577]: Failed to initialize hardware
>
> Is this a problem with using lirc 0.8.5? Or is something left over
> from my old lirc setup (0.8.4.a)? I tried apt-get remove lirc but it
> also wanted to remove a bunch of mythbuntu packages so I don't think I
> want to do that.

Yes, this is more or less the same lirc version mis-match biting
Fedora 10 users in the ass right now. There were incompatible changes
between the 0.8.4 and 0.8.5, so you need to make sure if you're
building your own driver that it matches your available userspace. I'd
suggest you try patching the driver in lirc 0.8.4a instead of the
latest lirc release or cvs if updating your userspace to match isn't
practical.

--
Jarod Wilson
jarod [at] wilsonet

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

alan at alanmarian

Jun 29, 2009, 9:06 PM

Post #6 of 13 (1252 views)
Permalink

Re: mce remote (lirc) fails after resume from standby [In reply to]

>
> Yes, this is more or less the same lirc version mis-match biting Fedora 10
> users in the ass right now. There were incompatible changes between the
> 0.8.4 and 0.8.5, so you need to make sure if you're building your own driver
> that it matches your available userspace. I'd suggest you try patching the
> driver in lirc 0.8.4a instead of the latest lirc release or cvs if updating
> your userspace to match isn't practical.
>

I got 0.8.5 working ... ubuntu had lircd in /usr/sbin the make install
put lircd in /usr/local/sbin

I removed the files (lircd and lircmd) in /usr/sbin and made symlinks
in /usr/sbin pointing to /usr/local/sbin.

Worked on the first try. I did one suspend-resume cycle and it also
seems to have solved the suspend-resume issue.

Thanks!
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

jarod at wilsonet

Jun 29, 2009, 9:13 PM

Post #7 of 13 (1260 views)
Permalink

Re: mce remote (lirc) fails after resume from standby [In reply to]

On Jun 30, 2009, at 12:06 AM, Alan Marchiori wrote:

>>
>> Yes, this is more or less the same lirc version mis-match biting
>> Fedora 10
>> users in the ass right now. There were incompatible changes between
>> the
>> 0.8.4 and 0.8.5, so you need to make sure if you're building your
>> own driver
>> that it matches your available userspace. I'd suggest you try
>> patching the
>> driver in lirc 0.8.4a instead of the latest lirc release or cvs if
>> updating
>> your userspace to match isn't practical.
>>
>
> I got 0.8.5 working ... ubuntu had lircd in /usr/sbin the make install
> put lircd in /usr/local/sbin
>
> I removed the files (lircd and lircmd) in /usr/sbin and made symlinks
> in /usr/sbin pointing to /usr/local/sbin.

Well, that's one way to do it, I guess. Just look out if you update
your box and a newer lirc 0.8.4a package overwrites your symlinks or
something.

--
Jarod Wilson
jarod [at] wilsonet

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

g8ecj at gilks

Jun 29, 2009, 10:20 PM

Post #8 of 13 (1250 views)
Permalink

Re: mce remote (lirc) fails after resume from standby [In reply to]

>>
>> Yes, this is more or less the same lirc version mis-match biting Fedora
>> 10
>> users in the ass right now. There were incompatible changes between the
>> 0.8.4 and 0.8.5, so you need to make sure if you're building your own
>> driver
>> that it matches your available userspace. I'd suggest you try patching
>> the
>> driver in lirc 0.8.4a instead of the latest lirc release or cvs if
>> updating
>> your userspace to match isn't practical.
>>
>
> I got 0.8.5 working ... ubuntu had lircd in /usr/sbin the make install
> put lircd in /usr/local/sbin
>
> I removed the files (lircd and lircmd) in /usr/sbin and made symlinks
> in /usr/sbin pointing to /usr/local/sbin.
>
> Worked on the first try. I did one suspend-resume cycle and it also
> seems to have solved the suspend-resume issue.

A better fix would be at the configure stage specify prefix
./configure --prefix=/usr
That will ensure that the install goes to the right place

--
Robin Gilks

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

alan at alanmarian

Jun 30, 2009, 9:01 AM

Post #9 of 13 (1222 views)
Permalink

Re: mce remote (lirc) fails after resume from standby [In reply to]

>>> Yes, this is more or less the same lirc version mis-match biting Fedora
>>> 10
>>> users in the ass right now. There were incompatible changes between the
>>> 0.8.4 and 0.8.5, so you need to make sure if you're building your own
>>> driver
>>> that it matches your available userspace. I'd suggest you try patching
>>> the
>>> driver in lirc 0.8.4a instead of the latest lirc release or cvs if
>>> updating
>>> your userspace to match isn't practical.
>>>
>>
>> I got 0.8.5 working ... ubuntu had lircd in /usr/sbin the make install
>> put lircd in /usr/local/sbin
>>
>> I removed the files (lircd and lircmd) in /usr/sbin and made symlinks
>> in /usr/sbin pointing to /usr/local/sbin.
>>
>> Worked on the first try. �I did one suspend-resume cycle and it also
>> seems to have solved the suspend-resume issue.
>
> A better fix would be at the configure stage specify prefix
> ./configure --prefix=/usr
> That will ensure that the install goes to the right place
>

maybe; either way since apt thinks I have 0.8.4a installed if it wants
to update it will overwrite the files whether they are symlinks or
not.

I'm sure there is some way to tell apt not to update the lirc package,
but I don't know it.

Hopefully it won't be an issue very often.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

peloy at chapus

Jun 30, 2009, 10:43 AM

Post #10 of 13 (1212 views)
Permalink

Re: mce remote (lirc) fails after resume from standby [In reply to]

Hi Jarod,

On Mon, Jun 29, 2009 at 11:52:36PM -0400, Jarod Wilson wrote:

> >>root [at] altamir:/usr/src/lirc-0.8.4a/drivers/lirc_mceusb2# diff -u lirc_mceusb2.c.orig lirc_mceusb2.c
> >>--- lirc_mceusb2.c.orig 2009-01-28 16:56:52.000000000 -0500
> >>+++ lirc_mceusb2.c 2009-01-28 16:29:26.000000000 -0500
> >>@@ -1121,6 +1121,7 @@
> >> #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 0)
> >> .suspend = usb_remote_suspend,
> >> .resume = usb_remote_resume,
> >>+ .reset_resume = usb_remote_resume,
> >> #endif
> >> .id_table = usb_remote_table
> >> };
> >>
> >>This was for lirc 0.8.4a. I just checked lirc 0.8.5 and they've
> >>changed function names but the driver structure is still lacking a
> >>.reset_resume field.
> >>
> >>I don't know if the above will fix your resume problem, but my
> >>recommendation is that you try the above patch. As I said, resuming
> >>from S3 sleep by pressing the remote's power botton would not work
> >>at all for me without the above little patch, and I've been running
> >>for a few months with the above patch with no ill or side effects.
>
> Eloy, would you mind submitting this upstream to the lirc list? I
> can't recall if you already did and it was overlooked, or what, but
> send it there again, and I'll keep an eye out for it and see if we
> can't get it included properly.

My apologies -- it's been in my to-do list to send this small patch to
the LIRC maintainers but I keep neglecting to do that. I don't know if
if the patch is correct, but without it LIRC stops working after S3
resume for me. I'll submit it to the lirc list and let the maintainers
decide if the patch makes sense, or if the problem needs to be handled
in a different way.

> >I made the patch did make & make install.
> >
> >I now get the following in syslog:
> >Jun 29 21:34:18 fe1 lircd-0.8.4a[1577]: accepted new client on
> >/dev/lircd
> >Jun 29 21:34:18 fe1 lircd-0.8.4a[1577]: could not get hardware
> >features
> >Jun 29 21:34:18 fe1 lircd-0.8.4a[1577]: this device driver does not
> >support the new LIRC interface
> >Jun 29 21:34:18 fe1 lircd-0.8.4a[1577]: make sure you use a current
> >version of the driver
> >Jun 29 21:34:18 fe1 lircd-0.8.4a[1577]: Failed to initialize hardware
> >
> >Is this a problem with using lirc 0.8.5? Or is something left over
> >from my old lirc setup (0.8.4.a)? I tried apt-get remove lirc but it
> >also wanted to remove a bunch of mythbuntu packages so I don't think I
> >want to do that.
>
> Yes, this is more or less the same lirc version mis-match biting
> Fedora 10 users in the ass right now. There were incompatible
> changes between the 0.8.4 and 0.8.5, so you need to make sure if
> you're building your own driver that it matches your available
> userspace. I'd suggest you try patching the driver in lirc 0.8.4a
> instead of the latest lirc release or cvs if updating your userspace
> to match isn't practical.

Yes, patching the 0.8.4a driver given that Alan has a 0.8.4a lircd seems
like the easiest thing to do here.

Cheers,

Eloy Paris.-
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

peloy at chapus

Jun 30, 2009, 10:48 AM

Post #11 of 13 (1222 views)
Permalink

Re: mce remote (lirc) fails after resume from standby [In reply to]

Hi Alan,

On Mon, Jun 29, 2009 at 10:06:18PM -0600, Alan Marchiori wrote:

> > Yes, this is more or less the same lirc version mis-match biting
> > Fedora 10 users in the ass right now. There were incompatible
> > changes between the 0.8.4 and 0.8.5, so you need to make sure if
> > you're building your own driver that it matches your available
> > userspace. I'd suggest you try patching the driver in lirc 0.8.4a
> > instead of the latest lirc release or cvs if updating your userspace
> > to match isn't practical.
>
> I got 0.8.5 working ... ubuntu had lircd in /usr/sbin the make install
> put lircd in /usr/local/sbin
>
> I removed the files (lircd and lircmd) in /usr/sbin and made symlinks
> in /usr/sbin pointing to /usr/local/sbin.
>
> Worked on the first try. I did one suspend-resume cycle and it also
> seems to have solved the suspend-resume issue.

Glad to hear. Was this with the little patch that I sent earlier? If so
then I guess I need to send that patch to the lirc maintainers sooner
rather than later...

Keep in mind that an Ubuntu update of your lirc packages will probably
overwrite your local lirc 0.8.5 installation.

Cheers,

Eloy Paris.-
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

alan at alanmarian

Jun 30, 2009, 1:32 PM

Post #12 of 13 (1203 views)
Permalink

Re: mce remote (lirc) fails after resume from standby [In reply to]

>> Worked on the first try. I did one suspend-resume cycle and it also
>> seems to have solved the suspend-resume issue.
>
> Glad to hear. Was this with the little patch that I sent earlier? If so
> then I guess I need to send that patch to the lirc maintainers sooner
> rather than later...

Yes, I used your patch and can confirm now after multiple
suspend-resume cycles that my mce remote is still working fine.

> Keep in mind that an Ubuntu update of your lirc packages will probably
> overwrite your local lirc 0.8.5 installation.

This point has been noted several times :) maybe with some luck the
next lirc update will include the patch.

thanks again,
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

jarod at wilsonet

Jul 5, 2009, 3:11 PM

Post #13 of 13 (1103 views)
Permalink

Re: mce remote (lirc) fails after resume from standby [In reply to]

On 06/30/2009 01:43 PM, Eloy Paris wrote:
> On Mon, Jun 29, 2009 at 11:52:36PM -0400, Jarod Wilson wrote:
>
>> >
>> > Eloy, would you mind submitting this upstream to the lirc list? I
>> > can't recall if you already did and it was overlooked, or what, but
>> > send it there again, and I'll keep an eye out for it and see if we
>> > can't get it included properly.
>
> My apologies -- it's been in my to-do list to send this small patch to
> the LIRC maintainers but I keep neglecting to do that. I don't know if
> if the patch is correct, but without it LIRC stops working after S3
> resume for me. I'll submit it to the lirc list and let the maintainers
> decide if the patch makes sense, or if the problem needs to be handled
> in a different way.

Its in lirc cvs as of a few seconds ago, didn't see any reason not to
put it in, since its confirmed to improve things for multiple users now.

--
Jarod Wilson
jarod [at] wilsonet

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads