On Mon, Aug 8, 2016 at 8:41 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 8 Aug 2016, ican realizeum wrote: > >> 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) In case 1. it shows: ohci_rh_resume: control 240 (that's 1001000000) https://i.imgur.com/5Wwwxwf.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) In case 2. it shows: ohci_rh_resume: control 2c0 (that's 1011000000) https://i.imgur.com/8sxP70x.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) ? > > Good question. Unfortunately, I can't think of a good way to find the > answer. > > What shows up in the log with the patch below? > > Alan Stern > > > > Index: usb-4.x/drivers/usb/host/ohci-hub.c > =================================================================== > --- usb-4.x.orig/drivers/usb/host/ohci-hub.c > +++ usb-4.x/drivers/usb/host/ohci-hub.c > @@ -212,6 +212,7 @@ __acquires(ohci->lock) > msleep (20 /* usb 11.5.1.10 */ + 12 /* 32 msec counter */ + 1); > > temp = ohci_readl (ohci, &ohci->regs->control); > + ohci_info(ohci, "ohci_rh_resume: control %x\n", temp); > temp &= OHCI_CTRL_HCFS; > if (temp != OHCI_USB_RESUME) { > ohci_err (ohci, "controller won't resume\n"); > Thanks for this patch, Alan. Much appreciated as I had no idea how to use ochi_info(). Cheers! -- 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
