On Mon, Aug 8, 2016 at 5:38 PM, Alan Stern <st...@rowland.harvard.edu> wrote: > On Mon, 8 Aug 2016, ican realizeum wrote: > >> >> The caller was hcd_resume_work(), which is part of a workqueue. This >> >> routine runs when the OHCI driver calls usb_hcd_resume_root_hub(). >> >> There are only 3 places in the driver where this happens (two in >> >> ohci-hcd.c and one in ohci-hub.c), but as far as I can tell, none of >> >> them should have occurred if power/control was set to "on". If you >> >> want, you can add an ohci_info() before each of those calls; knowing >> >> which one it was will probably tell us what happened. >> I didn't know how to use ohci_info() but I used dump_stack() >> https://i.imgur.com/VMak4ED.jpg >> it's from ohci_resume() > > Are you sure you wrote "on" to the power/control file for the usb3 and > usb4 devices? The stack dump says that the 0000:00:12.0 and > 0000:00:13.0 controllers were being runtime-resumed, but they should > not have been suspended to begin with, because their children (the > usb3 and usb4 devices) should have been prevented from going into > runtime suspend. > Ok, here's what I found out: tlp being enabled in /etc/default/tlp (as TLP_ENABLE=1) would always set those to 'auto' aka they show up as 'suspended', regardless of what I did (eg. set them 'on') before executing shutdown(from X, in menu, Shutdown) Even if TLP_ENABLE=0 during startup, if I set it to =1 before shutdown, it will put them in suspend.
With TLP_ENABLE=1, and in /usr/lib/systemd/system-shutdown/debug.sh I put some lines to show me the runtime_status it's always 'suspended' on all four (12.0 12.2 13.0 13.2) and: 1. if I have line in debug.sh which attempts to poweroff manually via sysrq, like this: echo o > /proc/sysrq-trigger ; sleep 5 then, there are no 'controller won't resume' and no 'HC died' messages, but there are only those with PME# and bus mastering. This seems quite fine! (as a side, there's still the failure to flush SSD cache and failure to turn off SSD gracefully, but that's another bug) 2. if I don't manually poweroff from debug.sh and therefore allow the normal shutdown process to continue, then I get those errors with 'controller won't resume' and 'HC died' It looks like something is at least trying to prevent those from waking up but I'm not sure if it's something in device_shutdown() or something before do_poweroff(), because apparently both sysrq+o(poweroff) and normal poweroff have the same stacktrace(?i should probably check this) If I turn off tlp (=0) then all four(ohci-s) are 'active' and there are no ohci messages whatsoever! (regardless of doing a manual sysrq+o poweroff or allowing the normal poweroff to happen) //Now, this makes me wonder what have I tried with tlp off in the first post that it still gave the errors - I'll assume I did something wrong and they were still suspended - but they shouldn't have been if tlp was off (unless maybe I changed TLP_ENABLE to =1 before shutdown thinking it will not have effect on the current shutdown! but it always has! as I've just found out) The only question remains then, why in the case 2. above, it can't power them on(and thus cause the errors in the title), but in case 1. it can(without the errors) ? > You might want to check the power/runtime_status contents in the > relevant device directories before doing the shutdown. > > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
