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)
>
> 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) ?
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");
--
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
