linux-kernel - Re: EHCI software retries break Supermicro IPKVM

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <Pine.LNX.4.44L0.1204301707060.1558-100000@iolanthe.rowland.org>
Date:	Mon, 30 Apr 2012 17:12:32 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Grzegorz Nosek <root@...aldomain.pl>
cc:	linux-usb@...r.kernel.org, <linux-kernel@...r.kernel.org>,
	<support@...ermicro.com>
Subject: Re: EHCI software retries break Supermicro IPKVM

On Sun, 29 Apr 2012, Grzegorz Nosek wrote:

> W dniu 19.04.2012 19:40, Alan Stern pisze:
> > Do you have any idea what's going wrong?
> 
> Nope. I found this workaround by bisecting.
> 
> > Can you provide complete dmesg logs for kernels both with and without
> > your patch (and with CONFIG_USB_DEBUG enabled)?  Maybe also usbmon
> > traces too.
> 
> Attached. Sorry it took so long, it was rather hard to align time when I 
> can easily reboot this machine with when I actually had the time to do it.
> 
> Note: USB support is compiled in the kernel image, so I couldn't attach 
> usbmon very early. Instead, I captured usbmon traces (and dmesgs since 
> boot) from connecting and disconnecting an ISO image via the KVM's 
> virtual CD drive, which exhibits the same problems (the IPKVM is visible 
> as an USB keyboard, an USB mouse and two USB CD-ROM drives).

That's fine; the logs show pretty clearly what the problem is.

It isn't a software issue.  You've got a hardware problem; either the
IPKVM itself, or the connecting cable, or your computer's EHCI
controller is bad.  The only reason the device worked without the retry
logic is because it failed so completely that the kernel was forced to
run it at full speed (12 Mb/s) instead of high speed (480 Mb/s).  With
the retry logic present, the device was barely workable at high speed
(but it probably didn't work well enough to be very useful).

Have you tried plugging the IPKVM into a different computer to see if 
it behaves any better?

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/