Message-ID: <BANLkTikaa+jgjuckXan8d-JVDDdUhO_JDw@mail.gmail.com>
Date:	Fri, 8 Apr 2011 17:34:09 +0200
From:	Zdenek Kabelac <zdenek.kabelac@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	USB list <linux-usb@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Endless loop with "detected XactErr"

2011/4/8 Alan Stern <stern@...land.harvard.edu>:
> On Fri, 8 Apr 2011, Zdenek Kabelac wrote:
>
>> >> Just with changing last number - I've got only one such line on serial console.
>> >> By looking into  "drivers/usb/host/ehci-q.c"  - there seems to be
>> >> endless goto loop.
>> >
>> > It isn't endless.  You didn't notice the test against QH_XACTERR_MAX.
>> >
>>
>> Maybe I've not been patient enough - but I'd been waiting for quite some time
>> and the console was just scrolling this line on display - so I need to
>> turn-off the machine.
>> (After like a minute of this looping)
>
> This is because the loop ends and then starts again (you can tell
> because the retry counter goes back to 1).
>
>> > This particular error message indicates a hardware problem in the USB
>> > signals.  A bad contact, a bad cable, a device failure -- something
>> > like that.
>>
>> Well it's been connected to Lenovo docking station - so unsure what
>> bad cable you mean here.
>> (and AFAICT it seems to work quite well all the time).
>
> It doesn't have to be a bad cable.  It could be any sort of hardware
> failure.  Perhaps the docking or undocking operation itself messes
> something up.
>
>> >> Here is the trace from last resume:
>> >
>> >> [  473.873802] ACPI: \_SB_.GDCK - undocking
>> >> [  473.897678] hub 2-0:1.0: state 7 ports 4 chg 0000 evt 0010
>> >> [  473.904809] ehci_hcd 0000:00:1a.7: detected XactErr len 0/4 retry 1
>> >
>> > And presumably additional lines containing similar messages.
>> >
>> > There's no real reason for them ever to stop, since they are only
>> > debugging messages.  If you turn off CONFIG_USB_DEBUG you'll never see
>> > tham.
>>
>>
>> You mean it's normal I get machine stuck in endless loop when I turn
>> on debugging ?
>
> Are you really sure the machine is stuck?  If you disable
> CONFIG_USB_DEBUG, does it hang or can you still get useful work done?
>
>> I though debug is there to debug the problem - not to add a new one ??
>
> It doesn't add any problems, since you can always turn the debugging
> off.  And the messages do aid in debugging -- if they weren't present,
> you would not have been aware of the problem.
>
>> As this happened during suspend - I had no other option than to simply
>> turn off the machine.
>
> It doesn't appear that way in the log you posted.  The resume completed
> at timestamp 467.8, and the debugging messages didn't start until 6
> seconds later.
>
> You might want to track down the original source of the
> underlying error.  Since the machine was docked the entire time, the
> line saying:
>
> [ �473.873802] ACPI: \_SB_.GDCK - undocking
>
> definitely looks suspicious.  I bet if you can fix that then the USB
> problems will go away.

Hmm looking now into more logs - it might have been used this:

"echo 1 >/sys/devices/platform/dock.0/undock"

for this particular testcase  - I might have been checking several
combination and making modification of some pm script for this.
So yes - in this case the machine could have been undocked by the above command.

Is that a major problem for USB ?

This machine get into busy loop at 473.9 (the last loggged line) during suspend.
The laptop was in 'dock' - but undocked by software command.

Zdenek
--
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/

Powered by blists - more mailing lists