linux-kernel - Re: Endless print of uhci_result_common: failed with status 440000

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 8 Apr 2011 14:51:02 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Zdenek Kabelac <zdenek.kabelac@...il.com>
cc:	USB list <linux-usb@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Endless print of uhci_result_common: failed with status 440000

On Fri, 8 Apr 2011, Zdenek Kabelac wrote:

> Most probably because I've run  in the loop
> 
> while : ; do pm-suspend ; sleep 5; done
> 
> for debug purposes...
> 
> 
> >> [   53.851937] btusb_intr_complete: hci0 urb ffff88011735c300 failed
> >> to resubmit (19)
> >> [   53.855223] btusb_bulk_complete: hci0 urb ffff88011735c540 failed
> >> to resubmit (19)
> >> [   53.867211] btusb_bulk_complete: hci0 urb ffff88011735c9c0 failed
> >> to resubmit (19)
> >> [   53.875279] btusb_send_frame: hci0 urb ffff880117204d80 submission failed
> >> [   54.127633] systemd[1]: Service bluetooth.target is not needed
> >> anymore. Stopping.
> >> [   54.205292] PM: Syncing filesystems ... done.
> >> [   54.216056] PM: Preparing system for mem sleep
> >>
> >> And system was 'dead' - (Moon sign on laptop was already blinking at
> >> this moment)
> >
> > Why did the system suspend like this?  A software undock shouldn't
> > cause a suspend.
> 
> pm-suspend - with  script executed on suspend which undocks laptop
> (otherwise when I'd forget to press button on docking station before
> suspend - it would stay 'red' mode - thus all buses are connected -
> and as I've noticed in past - it's not working well, when I unplug
> laptop in this 'still connected'  mode - so this software 'undock'
> solved this problem)

All right.  It looks like there are two possible sources of problems 
here: the undock and the suspend.  It would be best to debug them 
separately.

For example, if you change the loop above to just do the undock and
redock without suspending, do the problems still occur?

Another thing to try: Suspend by doing "echo ram >/sys/power/state" 
instead of running pm_suspend.

> >> I've strong believe - it's the moment  where USB_DEBUG version was
> >> printing those lines in endless loop.
> >> (Or let say it this way:   More then few minutes loop  - as maybe it
> >> will end within a week - but I don't have that much time to wait ;))
> >
> > Those debugging messages will continue for as long as the hardware
> > fails to respond properly.
> 
> Which is probably 'forever' when the machine is suspending.
> (note - even SysRq+B  no longer works at this moment)

No, when the machine is suspending there should not be any errors
because there should not be any USB traffic.  All the ongoing transfers
are cancelled as part of the suspend transition, and they start up
again during resume.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/