On Tue, 27 Aug 2013, Adam Borowski wrote: > > What happens if go back to a kernel without that commit and enable > > CONFIG_USB_SUSPEND? The behavior should be identical -- basically the > > commit is supposed to have the effect of always assuming that > > CONFIG_USB_SUSPEND has the same value as CONFIG_PM_RUNTIME, except in > > one spot where it is assumed to have the same value as CONFIG_PM. > > Going to the parent of that commit but enabling CONFIG_USB_SUSPEND indeed > causes the lockup. So it's not that commit what's the culprit -- it's just > that Debian kernels did not have the option enabled but do have > CONFIG_PM_RUNTIME which you merged it with. > > Surprisingly, though, today's "next" with CONFIG_PM_RUNTIME unset _does_ > lock up. > > I also tried removing all USB devices: > * none attached: ok > * USB keyboard: ok > * USB mouse (two different manufacturers): lockup > So what else should I test? Is there any way to get the dmesg information when the system locks up? For example, serial console, or netconsole? Seeing that, along with CONFIG_USB_DEBUG enabled, would help. Even if you can't do that, you should at least post a dmesg log showing the boot-up. I tried to reproduce your problem on my computer, but I couldn't. Maybe I wasn't using the right combination of kernel version and config options. > Meow! Woof woof! 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
