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]
Message-ID: <20130112131602.GA32186@rhlx01.hs-esslingen.de>
Date:	Sat, 12 Jan 2013 14:16:02 +0100
From:	Andreas Mohr <andi@...as.de>
To:	Woody Suwalski <terraluna977@...il.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	USB list <linux-usb@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 3.8-rc1 - another regression on USB :-(

Hi,

> Greg, Linus,
> It sounds insane, but after banging on the issue I have found out that 
> USB problem is caused (also in vanilla kernel) with a config change:
> USB-all built as modules - bad USB
> USB core built in, UHCI/EHCI modules -  semi functional - but 1Mb/s
> transfer
> USB core and UHCI EHCI built-in - bingo - no issues.
> 
> Could anybody duplicate that, or is it somehow my setup???

Since there was no additional reply here (needed) so far,
some of my (questionably relevant?) thoughts on this:

There's of course the EHCI vs. UHCI(/OHCI) duality
(EHCI host controller responsible for high speed transfers,
the other for 1.1 full speed, both serving the same port connectors).
So if the coordination between the two is a problem,
you might end up with merely full speed on a 2.0 port.

And with drivers builtin vs. module, the init sequence/timing
might possibly be affected - right?
Perhaps this got worsened by semi-recent driver init kernel changes?
(AFAIR the kernel was changed to init more things in parallel,
for faster bootup). So maybe that affected EHCI vs. UHCI coordination timing.

(taking many stabs in the dark here...)



I seem to have USB issues as well; for some storage devices
I cannot gain high speed currently, while e.g. for USB sticks that works -
and of course prior to disabling the BIOS's limit-to-1.1 setting
(doh! oh my...) that was very understandable, but AFAIK it's still not
reliable (maybe it's some of my local host controller troubleshooting commits...
need to git revert them).
Due to my woes originally being BIOS-originated I cannot provide any
hard evidence about any 3.7.x vs. 3.8.x breakage timeframe.


I noticed that I had PSU issues - the 5V rail was dangerously low;
resoldering/cleaning the PSU helped.
In your case the USB disconnects might hint at that as well - I'd
recommend installing an lm-sensors configuration (or check at BIOS
health page) like I did.
I'm in the process of compiling a small but hopefully helpful
USB troubleshooting document (voltage, EMI, ...).


I'm usually more or less current (currently on -rc2 plus local commits).

Andreas Mohr
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ