Re: ohci-pci controller won't resume and HC died; cleaning up - only on shutdown/reboot

[ican realizeum]

On Mon, Aug 8, 2016 at 11:01 PM, Alan Stern  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 100100)
>> 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 101100)
>> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ohci-pci controller won't resume and HC died; cleaning up - only on shutdown/reboot

[Alan Stern]

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 100100)
> 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 101100)
> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ohci-pci controller won't resume and HC died; cleaning up - only on shutdown/reboot

[ican realizeum]

On Mon, Aug 8, 2016 at 8:41 PM, Alan Stern  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 100100)
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 101100)
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, >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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ohci-pci controller won't resume and HC died; cleaning up - only on shutdown/reboot

[Alan Stern]

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, >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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ohci-pci controller won't resume and HC died; cleaning up - only on shutdown/reboot

[ican realizeum]

On Mon, Aug 8, 2016 at 7:43 PM, ican realizeum  wrote:
> On Mon, Aug 8, 2016 at 5:38 PM, Alan Stern  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 :00:12.0 and
>> :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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ohci-pci controller won't resume and HC died; cleaning up - only on shutdown/reboot

[ican realizeum]

On Mon, Aug 8, 2016 at 5:38 PM, Alan Stern  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 :00:12.0 and
> :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)

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

> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ohci-pci controller won't resume and HC died; cleaning up - only on shutdown/reboot

[Alan Stern]

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 :00:12.0 and
: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.

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ohci-pci controller won't resume and HC died; cleaning up - only on shutdown/reboot

[ican realizeum]

On Mon, Aug 8, 2016 at 11:42 AM, ican realizeum  wrote:
> Sorry, I just realized that in gmail `Default reply behaviour` was set
> to `Reply` not `Reply All`, so I skipped the list when I replied
> last(for I forgot to select Reply All as I did before). Oops. So now
> hopefully everyone else can see the quoted previous email below.
>
> On Mon, Aug 8, 2016 at 4:35 AM, Alan Stern  wrote:
>> On Mon, 8 Aug 2016, ican realizeum wrote:
>>
>>> Roger that. Here's what I found out:
>>> if I try to sysrq+o (aka poweroff) manually from a file that systemd
>>> runs at shutdown such as manually created a+x file:
>>> /usr/lib/systemd/system-shutdown/debug.sh
>>>
>>> then I get no ohci errors,
>>> screenshot: https://i.imgur.com/VVeAyj7.jpg
>>> only the "PME# disabled" and "enabling bus mastering" are seen.
>>> But if I allow the kernel(and/or whatever else happens before that) to
>>> do it, then the errors are back just like in my original post.
>>
>> The difference isn't clear.
>>
>>> The stack is this:
>>> https://i.imgur.com/9wlbure.jpg
>>> but it looks like something else called that and I don't know
>>> what(looks forked?), unless it's something from the following stack
>>> from the point where "Stop disk" happens:
>>> https://i.imgur.com/z9uq4ez.jpg
>>> Maybe I'll find out something from there.
>>
>> 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()

>>
>> However, this doesn't answer the question of why the resume failed.
>> My best guess is that it failed because something it needed had already
>> been shut down.
>>
>> Alan Stern
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ohci-pci controller won't resume and HC died; cleaning up - only on shutdown/reboot

[ican realizeum]

Sorry, I just realized that in gmail `Default reply behaviour` was set
to `Reply` not `Reply All`, so I skipped the list when I replied
last(for I forgot to select Reply All as I did before). Oops. So now
hopefully everyone else can see the quoted previous email below.

On Mon, Aug 8, 2016 at 4:35 AM, Alan Stern  wrote:
> On Mon, 8 Aug 2016, ican realizeum wrote:
>
>> Roger that. Here's what I found out:
>> if I try to sysrq+o (aka poweroff) manually from a file that systemd
>> runs at shutdown such as manually created a+x file:
>> /usr/lib/systemd/system-shutdown/debug.sh
>>
>> then I get no ohci errors,
>> screenshot: https://i.imgur.com/VVeAyj7.jpg
>> only the "PME# disabled" and "enabling bus mastering" are seen.
>> But if I allow the kernel(and/or whatever else happens before that) to
>> do it, then the errors are back just like in my original post.
>
> The difference isn't clear.
>
>> The stack is this:
>> https://i.imgur.com/9wlbure.jpg
>> but it looks like something else called that and I don't know
>> what(looks forked?), unless it's something from the following stack
>> from the point where "Stop disk" happens:
>> https://i.imgur.com/z9uq4ez.jpg
>> Maybe I'll find out something from there.
>
> 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.
>
> However, this doesn't answer the question of why the resume failed.
> My best guess is that it failed because something it needed had already
> been shut down.
>
> Alan Stern
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ohci-pci controller won't resume and HC died; cleaning up - only on shutdown/reboot

[Alan Stern]

On Sun, 7 Aug 2016, ican realizeum wrote:

> > This doesn't seem like anything you need to worry about.  If it only
> > happens on shutdown or reboot then it won't affect your use of the
> > computer.
> Cool!
> So, apparently something(?) is turning off something(as in power
> off/suspend?), so that the poweroff functionality from kernel is
> currently unable to flush drive cache or put drive into standby mode
> during the poweroff which it needs to do.

I don't know anything about that.

>  So whatever that is, is
> probably the one that's doing this "HC died" thing too. So I don't
> think I should worry, as you said anyways.

_Something_ is trying to start up your OHCI controllers at shutdown 
time.  I don't know what or why, but it isn't working.  Since you don't 
have any devices connected to those controllers, the failure doesn't 
hurt anything.

> > Furthermore, the lsusb output says you don't have any USB devices
> > plugged into either of the OHCI controllers.  Have you tried seeing
> > what happens if there is something plugged in (say, a keyboard or
> > mouse)?
> I haven't.
> I occasionally plug in a USB stick which seems to work fine, so far.
> >
> > Also, what do you get in the "registers" files under
> > /sys/kernel/debug/usb/ohci/*/ after you change the runtime PM setting
> > to "on"?  (You'll need to mount a debugfs filesystem for this.)
> When 'auto':
> # cat /sys/kernel/debug/usb/ohci/*/registers
> bus pci, device :00:12.0
> OHCI PCI host controller
> ohci_hcd
> SUSPENDED (no register access)
> bus pci, device :00:13.0
> OHCI PCI host controller
> ohci_hcd
> SUSPENDED (no register access)
> --
> When 'on':
> # cat /sys/kernel/debug/usb/ohci/*/registers
> bus pci, device :00:12.0
> OHCI PCI host controller
> ohci_hcd
> OHCI 1.0, NO legacy support registers, rh state suspended
> control 0x6c3 RWE RWC HCFS=suspend CBSR=3
> cmdstatus 0x0 SOC=0
> intrstatus 0x0004 SF
> intrenable 0x805a MIE RHSC UE RD WDH
> hcca frame 0x00ae
> fmintvl 0x27782edf FSMPS=0x2778 FI=0x2edf
> fmremaining 0x0c5c FR=0x0c5c
> periodicstart 0x2a2f
> lsthresh 0x0628
> hub poll timer off
> roothub.a 02000205 POTPGT=2 NPS NDP=5(5)
> roothub.b  PPCM= DR=
> roothub.status 8000 DRWE
> roothub.portstatus [0] 0x0100 PPS
> roothub.portstatus [1] 0x0100 PPS
> roothub.portstatus [2] 0x0100 PPS
> roothub.portstatus [3] 0x0100 PPS
> roothub.portstatus [4] 0x0100 PPS
> bus pci, device :00:13.0
> OHCI PCI host controller
> ohci_hcd
> OHCI 1.0, NO legacy support registers, rh state suspended
> control 0x6c3 RWE RWC HCFS=suspend CBSR=3
> cmdstatus 0x0 SOC=0
> intrstatus 0x0004 SF
> intrenable 0x805a MIE RHSC UE RD WDH
> hcca frame 0x00bb
> fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf
> fmremaining 0x800012ff FRT FR=0x12ff
> periodicstart 0x2a2f
> lsthresh 0x0628
> hub poll timer off
> roothub.a 02000205 POTPGT=2 NPS NDP=5(5)
> roothub.b  PPCM= DR=
> roothub.status 8000 DRWE
> roothub.portstatus [0] 0x0100 PPS
> roothub.portstatus [1] 0x0100 PPS
> roothub.portstatus [2] 0x0100 PPS
> roothub.portstatus [3] 0x0100 PPS
> roothub.portstatus [4] 0x0100 PPS

Ah, yes.  The ohci-hcd driver puts its controllers into suspend even if 
runtime PM isn't enabled.  That's a holdover from before Linux's 
runtime PM was written.  I suppose it's not needed any more, but 
keeping it doesn't hurt -- and it explains why those errors continue to 
show up even after you write "on" to power/control.

> Thanks Alan!
> 
> I have worked around the shutdown issue that was preventing my SSD
> from gracefully shutdown and this USB issue seems to not affect me
> anyways.
> (details here btw: https://bugzilla.kernel.org/show_bug.cgi?id=151631 )
> 
> Thanks and sorry for the spam. But if I can do anything to help with
> testing patches or anything regarding usb issue(s) I'd be happy to.

If you're curious to see what is causing the controllers to resume, you
could add a "dump_stack();" line to drivers/usb/host/ohci-hub.c in the
ohci_rh_resume() routine immediately after the line that says:

ohci_err (ohci, "controller won't resume\n");

You should set power/control to "on" when testing this.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ohci-pci controller won't resume and HC died; cleaning up - only on shutdown/reboot

[ican realizeum]

On Sun, Aug 7, 2016 at 6:49 PM, Alan Stern  wrote:
> On Sun, 7 Aug 2016, ican realizeum wrote:
>
>> Hey, I tried to send this to list but I didn't have Plain text mode(in
>> gmail) so it bounced back, resending now below, however meanwhile I
>> made a bug report for it too:
>> https://bugzilla.kernel.org/show_bug.cgi?id=151641
>> Thanks.
>> ---
>> Here's a screenshot: https://i.imgur.com/3P7ztlj.png
>> I've tried, without tlp and ensuring both 12.0 and 13.0 are "on" instead of
>
> What is tlp?
This is a package on Manjaro Linux with the description:
Linux Advanced Power Management
source code here: https://github.com/linrunner/TLP
I'm using it to set my devices to 'auto' mode, and supposedly save power
By "without tlp" above I meant that I made sure tlp didn't set any
device into low power mode or anything like that.

>
>> "auto". No effect.
>>
>> I wonder if this is related to the failure to Synchronize SCSI cache, such
>> as maybe somethings get shutdown as part of reboot/shutdown like that kvm
>> thing. But I don't know much.
>>
>> kernel:
>> Linux myzee 4.7.0-ga157b3a #7 SMP PREEMPT Sat Aug 6 15:22:34 EEST 2016
>> x86_64 GNU/Linux
>>
>> Active patches:
>> https://github.com/icanrealizeum/manjarred/blob/16904e09a57c7332893f824dc0dc139ba1c4fc46/system/Z575/OSes/manjaro2/on_baremetal/filesystem_now/manjaro/home/z/build/1packages/kernel/linuxgit/PKGBUILD#L39-L62
>
> This doesn't seem like anything you need to worry about.  If it only
> happens on shutdown or reboot then it won't affect your use of the
> computer.
Cool!
So, apparently something(?) is turning off something(as in power
off/suspend?), so that the poweroff functionality from kernel is
currently unable to flush drive cache or put drive into standby mode
during the poweroff which it needs to do. So whatever that is, is
probably the one that's doing this "HC died" thing too. So I don't
think I should worry, as you said anyways.
>
> Furthermore, the lsusb output says you don't have any USB devices
> plugged into either of the OHCI controllers.  Have you tried seeing
> what happens if there is something plugged in (say, a keyboard or
> mouse)?
I haven't.
I occasionally plug in a USB stick which seems to work fine, so far.
>
> Also, what do you get in the "registers" files under
> /sys/kernel/debug/usb/ohci/*/ after you change the runtime PM setting
> to "on"?  (You'll need to mount a debugfs filesystem for this.)
When 'auto':
# cat /sys/kernel/debug/usb/ohci/*/registers
bus pci, device :00:12.0
OHCI PCI host controller
ohci_hcd
SUSPENDED (no register access)
bus pci, device :00:13.0
OHCI PCI host controller
ohci_hcd
SUSPENDED (no register access)
--
When 'on':
# cat /sys/kernel/debug/usb/ohci/*/registers
bus pci, device :00:12.0
OHCI PCI host controller
ohci_hcd
OHCI 1.0, NO legacy support registers, rh state suspended
control 0x6c3 RWE RWC HCFS=suspend CBSR=3
cmdstatus 0x0 SOC=0
intrstatus 0x0004 SF
intrenable 0x805a MIE RHSC UE RD WDH
hcca frame 0x00ae
fmintvl 0x27782edf FSMPS=0x2778 FI=0x2edf
fmremaining 0x0c5c FR=0x0c5c
periodicstart 0x2a2f
lsthresh 0x0628
hub poll timer off
roothub.a 02000205 POTPGT=2 NPS NDP=5(5)
roothub.b  PPCM= DR=
roothub.status 8000 DRWE
roothub.portstatus [0] 0x0100 PPS
roothub.portstatus [1] 0x0100 PPS
roothub.portstatus [2] 0x0100 PPS
roothub.portstatus [3] 0x0100 PPS
roothub.portstatus [4] 0x0100 PPS
bus pci, device :00:13.0
OHCI PCI host controller
ohci_hcd
OHCI 1.0, NO legacy support registers, rh state suspended
control 0x6c3 RWE RWC HCFS=suspend CBSR=3
cmdstatus 0x0 SOC=0
intrstatus 0x0004 SF
intrenable 0x805a MIE RHSC UE RD WDH
hcca frame 0x00bb
fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf
fmremaining 0x800012ff FRT FR=0x12ff
periodicstart 0x2a2f
lsthresh 0x0628
hub poll timer off
roothub.a 02000205 POTPGT=2 NPS NDP=5(5)
roothub.b  PPCM= DR=
roothub.status 8000 DRWE
roothub.portstatus [0] 0x0100 PPS
roothub.portstatus [1] 0x0100 PPS
roothub.portstatus [2] 0x0100 PPS
roothub.portstatus [3] 0x0100 PPS
roothub.portstatus [4] 0x0100 PPS

>
> Alan Stern
>
Thanks Alan!

I have worked around the shutdown issue that was preventing my SSD
from gracefully shutdown and this USB issue seems to not affect me
anyways.
(details here btw: https://bugzilla.kernel.org/show_bug.cgi?id=151631 )

Thanks and sorry for the spam. But if I can do anything to help with
testing patches or anything regarding usb issue(s) I'd be happy to.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ohci-pci controller won't resume and HC died; cleaning up - only on shutdown/reboot

[Alan Stern]

On Sun, 7 Aug 2016, ican realizeum wrote:

> Hey, I tried to send this to list but I didn't have Plain text mode(in
> gmail) so it bounced back, resending now below, however meanwhile I
> made a bug report for it too:
> https://bugzilla.kernel.org/show_bug.cgi?id=151641
> Thanks.
> ---
> Here's a screenshot: https://i.imgur.com/3P7ztlj.png
> I've tried, without tlp and ensuring both 12.0 and 13.0 are "on" instead of

What is tlp?

> "auto". No effect.
> 
> I wonder if this is related to the failure to Synchronize SCSI cache, such
> as maybe somethings get shutdown as part of reboot/shutdown like that kvm
> thing. But I don't know much.
> 
> kernel:
> Linux myzee 4.7.0-ga157b3a #7 SMP PREEMPT Sat Aug 6 15:22:34 EEST 2016
> x86_64 GNU/Linux
> 
> Active patches:
> https://github.com/icanrealizeum/manjarred/blob/16904e09a57c7332893f824dc0dc139ba1c4fc46/system/Z575/OSes/manjaro2/on_baremetal/filesystem_now/manjaro/home/z/build/1packages/kernel/linuxgit/PKGBUILD#L39-L62

This doesn't seem like anything you need to worry about.  If it only 
happens on shutdown or reboot then it won't affect your use of the 
computer.

Furthermore, the lsusb output says you don't have any USB devices
plugged into either of the OHCI controllers.  Have you tried seeing
what happens if there is something plugged in (say, a keyboard or
mouse)?

Also, what do you get in the "registers" files under 
/sys/kernel/debug/usb/ohci/*/ after you change the runtime PM setting 
to "on"?  (You'll need to mount a debugfs filesystem for this.)

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html