On Mon, Aug 8, 2016 at 11:01 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 8 Aug 2016, ican realizeum wrote: > >> >> 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 > > Well, 240 means the controller is in the RESUME state (which is what it > should be at that point), and 2c0 means the controller is still in the > SUSPEND state. So even after the driver told the controller to change > from SUSPEND to RESUME, it's still in SUSPEND. > > The spec doesn't list any reasons why this might happen. All I can > guess is that the controller needs some input that the shutdown > procedure has turned off. > > Alan Stern > Thanks Alan. I've no further ideas. Peace out :) -- 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
