On Fri, 20 Jan 2012, Konstantin Svist wrote: > Thanks Alan! > > After a few more hours of testing, I think I found the main source of > the problem -- not surprisingly, it's the IR dongle itself. Apparently, > it reacts to ambient light or some light source in the particular room. > Long story short, the machine suspends fine when I cover the IR port > with my hand but wakes up as soon as I remove my hand. This was probably > the source of wakeups while it was trying to suspend. No idea why that > made the machine freeze, though - maybe too many interrupts...? Could be, but it still shouldn't happen. If you want to look into it any further, go right ahead... > There is still some weird behavior I want to ask about: > While testing the dongle on the 'problematic' machine, I have to run > both "echo USB# >/proc/acpi/wakeup" and "echo enabled > > /sys/bus/usb/devices/3-1/power/wakeup" to get the dongle to wake from /proc/acpi/wakeup is deprecated. Instead you should do something like "echo enabled >/sys/bus/usb/devices/usb3/../power/wakeup". In recent kernels this has now become the default, so you shouldn't have to do this step at all. > remote button press. But when I try it on my laptop, "echo > USB1>/proc/acpi/wakeup" is enough and > /sys/bus/usb/devices/3-1/power/wakeup doesn't do anything -- and the > laptop wakes no matter which button was pressed on the remote. I'm confused by your description. Firstly, is the dongle's sysfs path 3-1 on both machines? Secondly, what button presses on the remote will wake up the problematic machine? Thirdly, did you check whether the dongle's behavior is the same regardless of whether /sys/bus/usb/devices/3-1/power/wakeup contains "enabled" or "disabled"? > Does this make any sense? Is this difference in behavior caused by the > difference in the BIOS? It doesn't make much sense, and it probably has nothing to do with the BIOS. But I can't really tell because of all the things you left out. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
