linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Mohr <andi@lisas.de>
To: Woody Suwalski <terraluna977@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	USB list <linux-usb@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 3.8-rc1 - another regression on USB :-(
Date: Sat, 12 Jan 2013 14:16:02 +0100	[thread overview]
Message-ID: <20130112131602.GA32186@rhlx01.hs-esslingen.de> (raw)
In-Reply-To: <50E438F7.7040403@gmail.com>

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

  reply	other threads:[~2013-01-12 13:16 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-22  2:00 Linux 3.8-rc1 Linus Torvalds
2012-12-22  2:57 ` Steven Rostedt
2013-01-16  9:25   ` David Nyström
2012-12-23 13:39 ` [Regression w/ patch] Media commit causes user space to misbahave (was: Re: Linux 3.8-rc1) Rafael J. Wysocki
2012-12-23 14:08   ` Mauro Carvalho Chehab
2012-12-23 17:36     ` Linus Torvalds
2012-12-23 20:21       ` Mauro Carvalho Chehab
2012-12-23 22:29         ` Linus Torvalds
2012-12-24 19:28           ` Mauro Carvalho Chehab
2012-12-23 20:39       ` Laurent Pinchart
2012-12-23 22:04 ` linux-next stats (Was: " Stephen Rothwell
     [not found] ` <50D764BA.1030501@gmail.com>
2012-12-23 22:35   ` Linux 3.8-rc1 - another regression on USB :-( Linus Torvalds
2012-12-23 23:27     ` Greg Kroah-Hartman
2012-12-24  3:46       ` Woody Suwalski
2012-12-28 23:12         ` Woody Suwalski
2013-01-01 15:17         ` INVALID " Woody Suwalski
2013-01-02 13:41       ` Woody Suwalski
2013-01-12 13:16         ` Andreas Mohr [this message]
2013-01-12 16:54           ` Oliver Neukum
2013-01-12 17:38           ` Alan Stern
2013-01-16  4:26             ` Woody Suwalski
2013-01-16  8:25               ` Oliver Neukum
2013-01-16 15:00               ` Alan Stern
2013-01-17  2:25                 ` Woody Suwalski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130112131602.GA32186@rhlx01.hs-esslingen.de \
    --to=andi@lisas.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=terraluna977@gmail.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).