I have a myth frontend machine which has been running happily for some time. In order to make it more "appliance-like" I have had the power button on the remote mapped to hibernate-ram, so it can turn back on faster. This worked reasonably well, though mythfrontend itself has had some problems working this way, but that's beyond the scope of this post.
The last kernel where wake-on-usb worked properly was in the gentoo-sources-2.6.32-r? series. I skipped 2.6.33 and moved directly to gentoo-sources-2.6.34-r?. Wake-on-usb does not work with the 2.6.34 series. Furthermore, the problem appears to be in the suspend portion, not the wake. I have an el-cheapo mceusb remote and receiver, and the receiver has a little red LED that flashes any time it receives a signal from the remote. So during normal operation, press a button on the remote, see the LED flash. With 2.6.32 and earlier, when the system is suspended, pressing the power button on the remote would make the LED on the receiver light, and it would stay lit until the system had wakened, then it would go out, and begin responding as-normal to further button presses. With 2.6.34, when the system is suspended, press the power button on the remote and the LED on the receiver stays dark. So this looks to me as if something in the suspend code has turned the USB port completely off, on its way down. What's ironic is that if I power the system off (/sbin/poweroff, not the switch on the power supply) the LED on the receiver still responds. So something specific was done here during suspend.
I'm willing to grant that perhaps I only had working suspend/wake with 2.6.32 and earlier only because of a bug, and now it's "fixed". But I don't think so. I'd like to track this down, and I believe that there is some way to intelligently go through the kernel patches that turned 2.6.32 into 2.6.33 then 2.6.34. Obviously going through every patch would be daunting, but it seems to me that this is a problem that has to be in both USB and Suspend (more probably ACPI) and there ought to be a way to intelligently reduce the set of patches I need to look at.
Is anyone familiar with this process, to help me on my way?
Incidentally, in another thread someone had wake-on-LAN quit working between 2.6.32 and 2.6.34, as well. They may be related.
Wake-on-USB works with 2.6.32, fails with 2.6.34
Message
Wake-on-USB works with 2.6.32, fails with 2.6.34
.sigs waste space and bandwidth
Try the latest unstable kernel if you haven't. If that doesn't fix, try to replicate the problem in vanilla-sources - if it exhibits the problem there and hasn't yet been fixed in the latest kernel.org kernel, you can perform a bisection test to determine the exact change that broke it (requires compiling and testing ~10 kernels and reporting whether they worked or not to narrow down the exact change involved, but it's an automated process through git to fetch the kernels to test). This lets you file a useful bug report and will almost ensure it gets fixed in future releases.
There's another problem here, and that is that LIRC is in the process of moving into the kernel, and parts of it are in-kernel in 2.6.35. That might solve my problems, but I don't think Gentoo has LIRC userspace that can work with the in-kernel, though I may be wrong on that. Anyway, there are such big changes that I've been reluctant to move to 2.6.35. I'm on the LIRC list, so maybe it's time to ask there about what I need to do. I've been thinking in terms of solving one problem at a time, but even now I've kind of shelved the suspend problems, so maybe moving to 2.6.35 will solve that, as a bonus.
.sigs waste space and bandwidth
Re: Wake-on-USB works with 2.6.32, fails with 2.6.34
r?, r what ?depontius wrote:gentoo-sources-2.6.34-r?
+1depontius wrote:I've been reluctant to move to 2.6.35
There have been several problems reported by many with USB HID devices and 2.6.34-r6
There was actually a bug that is actually solved with 2.6.34 >= r7
Considering several security patches commited since,
If r? == r6 then I would advise you to give r10 a chance.
I think that box is at 2.6.34-r10 or 2.6.34-r11. I built the new kernel this past Saturday, with whatever my server picked up as latest'n'greatest 2.6.34 when it rsync'ed in the wee hours of Saturday morning. That system isn't running at the moment - I just tried connecting. My mythbackend is at 2.6.35-gentoo-r7, but I'd purposely held the frontend machine back. Now that I think of it, I normally do service on my home machines on the weekend, so their portage trees will have the same timestamp. I see "gentoo-sources-2.6.34-r11". I'm able to "emerge -p" that kernel, so it's not hard masked.
So I guess the answer is 2.6.34-r11 for that machine.
I did a little other searching and found complaints about a similar phenomenon on Ubuntu, but they made it sound as if a fix got into the mainstream kernel about a month ago, in which case I should have had it by now. They list a patch, so tonight I'll compare my kernel source to the patch and see if it looks more like the source or the final. Maybe this patch will fix my problems, maybe it's unrelated.
So I guess the answer is 2.6.34-r11 for that machine.
I did a little other searching and found complaints about a similar phenomenon on Ubuntu, but they made it sound as if a fix got into the mainstream kernel about a month ago, in which case I should have had it by now. They list a patch, so tonight I'll compare my kernel source to the patch and see if it looks more like the source or the final. Maybe this patch will fix my problems, maybe it's unrelated.
.sigs waste space and bandwidth
Rats. On bugzilla it appeared easy to make an ebuild for the now-released, but not yet in portage lirc-0.8.7. In addition to being latest'n'greatest, it works with 2.6.35. So I made a local ebuild, and indeed it works with 2.6.34-r11. Then I build kernel 2.6.35-r9 and rebuilt lirc against that.
Still no-go. What's worse, on the one try I had time to make, eth0 didn't come back from suspend. So with 2.6.35 wake-on-usb still doesn't work, and eth0 doesn't wake properly. 0 for 2. Negative progress.
I've gone back to making the remote button power down instead of suspend. I can't turn on with the remote, and it takes longer to be ready from the front-panel switch, but at least it works.
Maybe my time would be better spent getting baselayout-2 and systemd working - for a faster boot.
Still no-go. What's worse, on the one try I had time to make, eth0 didn't come back from suspend. So with 2.6.35 wake-on-usb still doesn't work, and eth0 doesn't wake properly. 0 for 2. Negative progress.
I've gone back to making the remote button power down instead of suspend. I can't turn on with the remote, and it takes longer to be ready from the front-panel switch, but at least it works.
Maybe my time would be better spent getting baselayout-2 and systemd working - for a faster boot.
.sigs waste space and bandwidth
- Art Vandalay
- Guru
- Posts: 335
- Joined: Tue Sep 16, 2003 9:57 pm
- Location: Melbourne - VIC
Hi Depontius,
Were you ever able to resolve this problem?
Has this situation been resolved with the newer kernels? I am on 2.6.36-gentoo
I too are in a similar situation....ie I can put my desktop into S3 but can only wake via pushing the power button.
My motherboard is a Gigabyte X58A-UD5 and I was under the impression that wake-up via a USB event was not a feature of this board as it is not mentioned in the BIOS.
The BIOS and manual only mention wake on lan, and wake up via ps2 keyboard or mouse....btw, wake on lan works a treat.
But to my surprise when I boot into Windows 7 I can successfully wake the pc up via my usb mouse...and I can see that it remains powered on when the pc is in suspend to ram mode (S3).
Question: Does this mean I should theoretically be able to do this in gentoo as well, or is this some Windows trickery to get around the motherboard limitation?
Info as follows:
Thanks
Were you ever able to resolve this problem?
Has this situation been resolved with the newer kernels? I am on 2.6.36-gentoo
I too are in a similar situation....ie I can put my desktop into S3 but can only wake via pushing the power button.
My motherboard is a Gigabyte X58A-UD5 and I was under the impression that wake-up via a USB event was not a feature of this board as it is not mentioned in the BIOS.
The BIOS and manual only mention wake on lan, and wake up via ps2 keyboard or mouse....btw, wake on lan works a treat.
But to my surprise when I boot into Windows 7 I can successfully wake the pc up via my usb mouse...and I can see that it remains powered on when the pc is in suspend to ram mode (S3).
Question: Does this mean I should theoretically be able to do this in gentoo as well, or is this some Windows trickery to get around the motherboard limitation?
Info as follows:
and system setup as follows:telesto jk # acpitool -w
Device S-state Status Sysfs node
---------------------------------------
1. PCI0 S5 *disabled no-bus:pci0000:00
2. PEX0 S5 *disabled pci:0000:00:1c.0
3. PEX1 S5 *disabled pci:0000:00:1c.1
4. PEX2 S5 *disabled
5. PEX3 S5 *disabled pci:0000:00:1c.3
6. PEX4 S5 *disabled pci:0000:00:1c.4
7. PEX5 S5 *disabled pci:0000:00:1c.5
8. HUB0 S5 *disabled pci:0000:00:1e.0
9. USB0 S3 *enabled pci:0000:00:1d.0
10. USB1 S3 *enabled pci:0000:00:1d.1
11. USB2 S3 *enabled pci:0000:00:1d.2
12. USB3 S3 *enabled pci:0000:00:1a.0
13. USB4 S3 *enabled pci:0000:00:1a.1
14. USB5 S3 *enabled pci:0000:00:1a.2
15. USBE S3 *disabled pci:0000:00:1d.7
16. USE2 S3 *disabled pci:0000:00:1a.7
17. AZAL S5 *disabled pci:0000:00:1b.0
I'd love to get this working as I have a similar motherboard in my lounge room that is a frontend mythbox, and hence, would like to be able to wake the frontend up via my usb remote receiver.Portage 2.1.9.32 (default/linux/amd64/10.0/desktop/kde, gcc-4.4.5, glibc-2.12.2-r0, 2.6.36-gentoo x86_64)
=================================================================
System uname: Linux-2.6.36-gentoo-x86_64-Intel-R-_Core-TM-_i7_CPU_930_@_2.80GHz-with-gentoo-2.0.1
Timestamp of tree: Tue, 18 Jan 2011 02:15:01 +0000
app-shells/bash: 4.1_p9
dev-java/java-config: 2.1.11-r3
dev-lang/python: 2.7.1, 3.1.3
dev-util/cmake: 2.8.3-r1
sys-apps/baselayout: 2.0.1-r1
sys-apps/openrc: 0.7.0
sys-apps/sandbox: 2.4
sys-devel/autoconf: 2.13, 2.68
sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1
sys-devel/binutils: 2.21
sys-devel/gcc: 4.4.5
sys-devel/gcc-config: 1.4.1
sys-devel/libtool: 2.4-r1
sys-devel/make: 3.82
virtual/os-headers: 2.6.36.1 (sys-kernel/linux-headers)
ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=core2 -msse4 -mcx16 -mpopcnt -msahf -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/config"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo"
CXXFLAGS="-march=core2 -msse4 -mcx16 -mpopcnt -msahf -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="assume-digests binpkg-logs distlocks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"
GENTOO_MIRRORS="http://ftp.swin.edu.au/gentoo ftp://ftp.swin.edu.au/gentoo"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j9"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/var/lib/layman/zugaina /var/lib/layman/vmware /var/lib/layman/iElectric /usr/local/portage"
SYNC="rsync://rsync.au.gentoo.org/gentoo-portage"
USE="64bit X a52 aac acl acpi alsa amd64 apache2 apm bash-completion berkdb bluetooth branding bzip2 cairo cdda cdr cleartype cli consolekit corefonts cracklib crypt cue cups cxx dbus dri dts dvd dvdr embedded emboss encode exif extras fam fbcondecor ffmpeg firefox flac fortran gd gdbm gdu gif gnutls gpm hal hddtemp hpcups hpijs hpn iconv ipv6 java jpeg kde lcms ldap libnotify libvisual lm_sensors mad mikmod mmx mng modules mp3 mp4 mpeg msn mudflap multilib mysql mysqli ncurses nls nptl nptlonly nsplugin nvidia ogg opengl openmp pam pango pcre pdf perl pmu png policykit ppds pppd python qt3support qt4 rar readline rss scanner sdl semantic-desktop sensord session snmp spell sqlite sse sse2 ssl startup-notification static-libs suid svg sysfs tcpd tiff truetype type1 udev unicode usb vaapi vdpau vorbis x264 xcb xinerama xml xorg xulrunner xv xvid xvmc yahoo zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Thanks
I might not have morals...but at least I have standards
- Art Vandalay
- Guru
- Posts: 335
- Joined: Tue Sep 16, 2003 9:57 pm
- Location: Melbourne - VIC
ok have made some progress.
i realised with my bios pressing ctrl+f1 at the main screen activates the advanced options and i can now see that 'wake s3 from usb device' is indeed enabled. why this option isn't visible by default is beyond me....anyway...
in my kernel under "Device Drivers" -> "USB Support" i had to enable "USB runtime power management" (ie USB_SUSPEND).
recompiled, rebooted, tried again...still no luck.
after some further research it looks like with the newer kernels an extra step is required.
for example to get my usb optical mouse to wake the pc....
going through the same procedure for my usb cordless keyboard i can now wake up my mythtv frontend in the front room
but i have had no success with my usb ir receiver...when i cat the wakeup file there is no enabled or disabled....
which leads me to my next question...are all USB IR Receivers made equal? ie should all be able to wake a pc from s3 or is it only certain usb IR receivers that have this functionality??
I am using a dvico IR receiver:
i realised with my bios pressing ctrl+f1 at the main screen activates the advanced options and i can now see that 'wake s3 from usb device' is indeed enabled. why this option isn't visible by default is beyond me....anyway...
in my kernel under "Device Drivers" -> "USB Support" i had to enable "USB runtime power management" (ie USB_SUSPEND).
recompiled, rebooted, tried again...still no luck.
after some further research it looks like with the newer kernels an extra step is required.
for example to get my usb optical mouse to wake the pc....
tells me the usb port and pci slot being used# dmesg|grep -i optical
[ 10.610913] usb 8-1: Product: Microsoft Wheel Mouse Optical®
[ 10.627044] input: Microsoft Microsoft Wheel Mouse Optical® as /devices/pci0000:00/0000:00:1d.2/usb8/8-1/8-1:1.0/input/input3
[ 10.627229] generic-usb 0003:045E:0040.0001: input,hidraw0: USB HID v1.00 Mouse [Microsoft Microsoft Wheel Mouse Optical®] on usb-0000:00:1d.2-1/input0
now enabling the device directly...# cat /sys/devices/pci0000\:00/0000\:00\:1d.2/usb8/8-1/power/wakeup
disabled
now we have# echo enabled > /sys/devices/pci0000\:00/0000\:00\:1d.2/usb8/8-1/power/wakeup
now when i sleep the pc i can wake it up with my usb device...ie the mouse.# cat /sys/devices/pci0000\:00/0000\:00\:1d.2/usb8/8-1/power/wakeup
enabled
going through the same procedure for my usb cordless keyboard i can now wake up my mythtv frontend in the front room
but i have had no success with my usb ir receiver...when i cat the wakeup file there is no enabled or disabled....
which leads me to my next question...are all USB IR Receivers made equal? ie should all be able to wake a pc from s3 or is it only certain usb IR receivers that have this functionality??
I am using a dvico IR receiver:
Would love to hear from someone using a similar device or had some experience with this stuff....# dmesg|grep -i dvico
[ 3.243469] usb 3-1: Product: DVICO USB HID Remocon V1.00
[ 3.243470] usb 3-1: Manufacturer: DVICO
[ 5.249875] generic-usb 0003:0FE9:9010.0001: hiddev0,hidraw0: USB HID v1.10 Device [DVICO DVICO USB HID Remocon V1.00] on usb-0000:00:1a.0-1/input0
I might not have morals...but at least I have standards
I never thought to go into /sys/devices to look for the wakeup stuff. The system is currently booted to 2.6.32, and I just walked the appropriate /sys path, and indeed wakeup is enabled. Next to boot 2.6.36 and check the same thing.
I don't know if our problems are relevant to each other. Yours seems to be more related to certain devices not waking properly - mine seems to be related to kernel levels. Have you tried your wake experiments with a 2.6.32-series kernel?
Another thing to look at would be USB 2 vs USB 1.1. The same jack gets fielded by two different drivers and comes out on two different devices, depending on which USB level it is. I have separate ACPI wakeup entries for USB 2 vs USB 1.1 - which reminds me, I need to re-borrow the smart-hub from a friend at work and experiment again. His hub switches things to USB 2 - so I can plug in my USB 1.1 mceusb IR receiver, and it will send USB 2 events to the computer.
I don't know if our problems are relevant to each other. Yours seems to be more related to certain devices not waking properly - mine seems to be related to kernel levels. Have you tried your wake experiments with a 2.6.32-series kernel?
Another thing to look at would be USB 2 vs USB 1.1. The same jack gets fielded by two different drivers and comes out on two different devices, depending on which USB level it is. I have separate ACPI wakeup entries for USB 2 vs USB 1.1 - which reminds me, I need to re-borrow the smart-hub from a friend at work and experiment again. His hub switches things to USB 2 - so I can plug in my USB 1.1 mceusb IR receiver, and it will send USB 2 events to the computer.
.sigs waste space and bandwidth
Got it working!
@depontius have you solved your issue in the end?
I have struggled with remote wakeup in my Scaleo E (it has mceusb built in) for a long time now. And this thread helped a _lot_. I got it working at last.
Here's an oneliner that found me all the wakeup-enabled usb devs:
On a freshly booted system, here's how it looks here (ignore the missing product file):
Here's my /proc/acpi/wakeup:
After a quick:
Remote wakeup works again! What's weird is that regardless of /proc/acpi/wakeup it wakes up off of the RF keyboard (which is annoying due to its trackball being too sensitive...), but I can disable it in sysfs.
I'll report back if I can get a udev rule to handle that.
EDIT:
OK, I have it working, here're two simple scripts:
enable_wakeup.sh:
... and disable_wakeup.sh:
A simple /etc/udev/rules.d/80-wakeup.rules:
Tweak to taste (remember to chmod +x the scripts and tweak the RUN assignments to match where the path where you put them) and you're off
I have struggled with remote wakeup in my Scaleo E (it has mceusb built in) for a long time now. And this thread helped a _lot_. I got it working at last.
Here's an oneliner that found me all the wakeup-enabled usb devs:
Code: Select all
$for i in `find /sys/devices/pci* -name wakeup | grep usb`; do if [ -n "$(cat $i)" ]; then echo -n "$i - "; echo -n "$(cat $(dirname `dirname $i`)/product | tr -d "\n"): "; cat $i; fi; doneCode: Select all
/sys/devices/pci0000:00/0000:00:1d.0/usb2/power/wakeup - UHCI Host Controller: enabled
/sys/devices/pci0000:00/0000:00:1d.1/usb3/power/wakeup - UHCI Host Controller: enabled
/sys/devices/pci0000:00/0000:00:1d.2/usb4/power/wakeup - UHCI Host Controller: enabled
/sys/devices/pci0000:00/0000:00:1d.2/usb4/4-2/power/wakeup - eHome Infrared Transceiver: disabled
/sys/devices/pci0000:00/0000:00:1d.3/usb5/power/wakeup - UHCI Host Controller: enabled
/sys/devices/pci0000:00/0000:00:1d.7/usb1/power/wakeup - EHCI Host Controller: enabled
/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-4/power/wakeup - cat: /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-4/product: No such file or directory
: disabled
/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.4/power/wakeup - 2.4G USB RF KeyBoard: enabled
Code: Select all
Device S-state Status Sysfs node
PCI0 S5 *disabled no-bus:pci0000:00
PEX0 S5 *disabled
PEX1 S5 *disabled
PEX2 S5 *disabled
PEX3 S5 *disabled
HUB0 S5 *disabled pci:0000:00:1e.0
UAR1 S5 *disabled pnp:00:07
UAR2 S5 *disabled pnp:00:08
USB0 S3 *disabled pci:0000:00:1d.0
USB1 S3 *disabled pci:0000:00:1d.1
USB2 S3 *disabled pci:0000:00:1d.2
USB3 S3 *disabled pci:0000:00:1d.3
USBE S3 *disabled pci:0000:00:1d.7
AC97 S5 *disabled
AZAL S5 *disabled pci:0000:00:1b.0
Code: Select all
$ echo "enabled" > /sys/devices/pci0000:00/0000:00:1d.2/usb4/4-2/power/wakeup
$ echo "USB2" > /proc/acpi/wakeup
I'll report back if I can get a udev rule to handle that.
EDIT:
OK, I have it working, here're two simple scripts:
enable_wakeup.sh:
Code: Select all
#!/bin/bash
[ "${ACTION}" != "add" ] && exit
ACPIWAKE=/proc/acpi/wakeup
PCI=$(echo ${DEVPATH} | cut -d/ -f4)
ACPIDEV=$(cat /proc/acpi/wakeup | grep $PCI | awk '{ print $1 }')
STATUS=$(cat /proc/acpi/wakeup | grep $ACPIDEV | awk '{ print $3 }')
[ "${STATUS}" != "*enabled" ] && echo ${ACPIDEV} > ${ACPIWAKE}
TMP=${DEVPATH}
# enable wakeup on the whole chain
while true; do
WAKE=/sys${TMP}/power/wakeup
[ -f "${WAKE}" -a -n "$(cat ${WAKE})" ] && echo "enabled" > ${WAKE}
TMP=${TMP%/*}
[ $TMP == "/devices" ] && break
done
Code: Select all
#!/bin/bash
[ "${ACTION}" != "add" ] && exit
TMP=${DEVPATH}
# disable wakeup on the deepest possible entry
while true; do
WAKE=/sys${TMP}/power/wakeup
[ -f "${WAKE}" -a -n "$(cat ${WAKE})" ] && echo "disabled" > ${WAKE} && break
TMP=${TMP%/*}
done
Code: Select all
# enable wakeup from mceusb
SUBSYSTEM=="usb", ATTR{idVendor}=="1509", ATTR{idProduct}=="9242", RUN+="/usr/local/bin/enable_wakeup.sh"
# disable wakeup from keyboard
SUBSYSTEM=="usb", ATTR{idVendor}=="05af", ATTR{idProduct}=="0319", RUN+="/usr/local/bin/disable_wakeup.sh"
I got some more information about this earlier this week from the LIRC mailing list. It turns out that they made changes to the wakeup mechanism and how USB interacts with it between 2.6.32 and 2.6.33. As near as I can figure, "/proc/acpi/wakeup" only gets the USB channel ready to wake the system. At least when I look in "/sys/devices/pci/pcixxxx/power/wakeup" I see what was done in "/proc/acpi/wakeup" mirrored there. But it looks like it's also necessary to get the USB device itself ready to wake the system, in "/sys/bus/usb/xxxxx/power/wakeup". The other night I enabled the latter path as well as the usual one, and was able to sleep and wake the system with the remote control.
I need to carefully look at your udev script, but what I think I'd really like is a udev script that waits for its "mceusb" event, then enables that device and the USB port that it's plugged into.
I suspect for the moment I'm just going to kludge together a local.start script to hard-enable the right device. I need to get to a newer kernel, so I can migrate LIRC from the out-of-kernel mceusb to the newer in-kernel mceusb.
I need to carefully look at your udev script, but what I think I'd really like is a udev script that waits for its "mceusb" event, then enables that device and the USB port that it's plugged into.
I suspect for the moment I'm just going to kludge together a local.start script to hard-enable the right device. I need to get to a newer kernel, so I can migrate LIRC from the out-of-kernel mceusb to the newer in-kernel mceusb.
.sigs waste space and bandwidth
What it does is, whenever my receiver gets loaded (that's the ATTR{idVendor}=="1509", ATTR{idProduct}=="9242" - these might be different for you) it iterates back from the device itself and enables every power/wakeup it finds disabled. Then it enables the bus in /proc/acpi/wakeup. I think I was unable to wake without explicitly enabling it there.depontius wrote: I need to carefully look at your udev script, but what I think I'd really like is a udev script that waits for its "mceusb" event, then enables that device and the USB port that it's plugged into.
As for disabling - it only disables the furthest possible entry, so as not to disable e.g. other devices on the same bus.
Rules tweaked and installed, we'll see what happens.
Actually, I've got logger statements in the enable/disable scripts, which I put in /usr/local/sbin, and I exit right after. Once I've seen what the log says, I'll remove the exit statements and let her fly.
Then I'll try going back to 2.6.37.
Then I'll look at migrating to the in-kernel lirc drivers.
EDIT
On a quick first-try, I got no events logged upon a reboot. Should I be expecting udev events when I'm still using the out-of-kernel lirc drivers, or will those events only happen once I convert to in-kernel drivers? For the first attempt, I stuck my logger statement before checking to see if action=add, figuring more verbosity would help, or at least enlighten.
Actually, I've got logger statements in the enable/disable scripts, which I put in /usr/local/sbin, and I exit right after. Once I've seen what the log says, I'll remove the exit statements and let her fly.
Then I'll try going back to 2.6.37.
Then I'll look at migrating to the in-kernel lirc drivers.
EDIT
On a quick first-try, I got no events logged upon a reboot. Should I be expecting udev events when I'm still using the out-of-kernel lirc drivers, or will those events only happen once I convert to in-kernel drivers? For the first attempt, I stuck my logger statement before checking to see if action=add, figuring more verbosity would help, or at least enlighten.
.sigs waste space and bandwidth
It doesn't rely on any lirc drivers. You can verify that the scripts will get run withdepontius wrote:EDIT
On a quick first-try, I got no events logged upon a reboot. Should I be expecting udev events when I'm still using the out-of-kernel lirc drivers, or will those events only happen once I convert to in-kernel drivers? For the first attempt, I stuck my logger statement before checking to see if action=add, figuring more verbosity would help, or at least enlighten.
Code: Select all
$ udevadm test /sys/bus/usb/devices/3-2Code: Select all
udevadm_test: run: '/usr/local/bin/enable_wakeup.sh'- Art Vandalay
- Guru
- Posts: 335
- Joined: Tue Sep 16, 2003 9:57 pm
- Location: Melbourne - VIC
now that i am on holidays i revisited this topic...couldn't end the year with this not being solved!
ended up ditching my dvico ir receiver and getting a cheap mce usb receiver (model 1039) off ebay which has solved the issue, as they are capable of waking a system from s3
i created the following udev rule:
# enable wake from S3 for MCE USB device 0471:0815
SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="0471", ENV{ID_MODEL_ID}=="0815" RUN+="/bin/sh -c 'echo enabled > /sys$env{DEVPATH}/power/wakeup'"
wake up from the remote now works perfect....didn't happen overnight, but it did happen
thanks guys
ended up ditching my dvico ir receiver and getting a cheap mce usb receiver (model 1039) off ebay which has solved the issue, as they are capable of waking a system from s3
i created the following udev rule:
# enable wake from S3 for MCE USB device 0471:0815
SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="0471", ENV{ID_MODEL_ID}=="0815" RUN+="/bin/sh -c 'echo enabled > /sys$env{DEVPATH}/power/wakeup'"
wake up from the remote now works perfect....didn't happen overnight, but it did happen
thanks guys
I might not have morals...but at least I have standards
I recently moved my mythfrontend machine from 2.6.38 to 3.2.1, and moved from lirc-0.8.7. to lirc-0.9.0, and from lirc_mceusb to devinput, all in the same process. (Unfortunately it was practically impossible to break this migration into pieces.)
I lost wake-on-usb in the process, though somehow I did keep power to the USB receiver in the process. The "receive" light on the receiver would come on when I pressed the power button on the remote, then stay on. Then I needed to use the front-panel power button to wake the system, and once it woke the "receive" light would go off, and all would be well.
I never did implement the udev script mentioned above. But in the spirit of that script I went through the whole device chain and enabled power/wakeup every step of the way. I also enabled power/wakeup on the pci devices where the usb is attached, just for good measure.
I have wake-on-usb back.
On general principle, I really need to go back and study the udev script above, and do that on my mythfrontend instead of my hard-coded enables. There are other things I'd like to do in a hardware-event-driven way, and this is the start point.
I lost wake-on-usb in the process, though somehow I did keep power to the USB receiver in the process. The "receive" light on the receiver would come on when I pressed the power button on the remote, then stay on. Then I needed to use the front-panel power button to wake the system, and once it woke the "receive" light would go off, and all would be well.
I never did implement the udev script mentioned above. But in the spirit of that script I went through the whole device chain and enabled power/wakeup every step of the way. I also enabled power/wakeup on the pci devices where the usb is attached, just for good measure.
I have wake-on-usb back.
On general principle, I really need to go back and study the udev script above, and do that on my mythfrontend instead of my hard-coded enables. There are other things I'd like to do in a hardware-event-driven way, and this is the start point.
.sigs waste space and bandwidth