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