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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
