On Sun, 1 Jun 2008, Tobias Diedrich wrote: > Ok, after another long debugging session I finally found out the > reason for the immediate reboot (after finding the place that > suspends the serial console (drivers/pnp) and disabling that suspend > path): > The system is woken up by USB activity! (Optical mouse, anyone?) > > Lo and behold: > drivers/usb/core/hcd-pci.c tries it's best to activate 'wake on > usb', which I didn't know since it apparently also never worked. > However, after applying the 'use platform_enable_wakeup'-patch, > not only forcedeth wake starts working, also usb wake. > If I prevent usb wake: > |echo disabled > /sys/devices/pci0000\:00/0000\:00\:02.0/power/wakeup' > |echo disabled > /sys/devices/pci0000\:00/0000\:00\:02.1/power/wakeup' > And then hibernate in platform mode, the immediate reboot is gone > and waking up using magic packets works fine even without setting up > /proc/acpi/wakeup first. > > Maybe I should try hooking mouse and keyboard onto different usb > host controllers, so I can disable wakeup for the mouse host > controller and enable wakeup for the keyboard host controller, > then it should be possible to wake the system by pressing a key. :) You don't need to do that. Wakeup can be set specifically for each individual USB device, provided CONFIG_USB_SUSPEND is enabled. On Sun, 1 Jun 2008, Tobias Diedrich wrote: > (BTW I first thought the 'immediate reboot because of usb wake' effect is > caused by the optical mouse generating a wake event, but it rather > seems to be a problem with a flaky secondary usb host controller, > which sees a connected device where nothing is attached) Can you provide debugging information (i.e., CONFIG_USB_DEBUG) with the details on this bogus wakeup? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
