On Mon, Aug 8, 2016 at 7:43 PM, ican realizeum <icanrealizeum@xxxxxxxxx> wrote: > On Mon, Aug 8, 2016 at 5:38 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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) forgot to include stacktrace for this case: https://i.imgur.com/T32GYom.jpg > > 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) for reference the stacktrace for this case was this: https://i.imgur.com/VMak4ED.jpg > > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
