[gentoo-amd64] USB 2.0 falling back to full-speed

[gentoo-amd64] USB 2.0 falling back to full-speed

[Raffaele BELARDI]

I've recently had to change my MB to a M2A-VM (AMD 690G/ATI SB600 
chipset), since then I have problems with the USB2.0.

The syslog most of the times shows at boot the ehci_hcd kernel driver 
(the 2.0 driver) trying to assign some address to the 2.0 hub, and the 
hub refusing it or failing with some I/O error. The driver tries 4 
different addresses, then falls back to ohci_hcd (the 1.1 driver) and 
works fine but at low speed. The whole procedure takes maybe 1 minute, 
for this time any peripheral connected to the port will not be detected.

Google suggested hw problems (e.g. cables), so I installed Windows and 
did some test, looks like it is working fine at high speed (I used an 
utility similar to usbview to check the driver tree). I'll do some more 
testing to exclude the hw problem.

Note that since 2.6.26 the kernel displays the "unable to enumerate USB 
device on port x" at every boot, but according to Google it is 
relatively common and does not harm functionality, so I believe my 
problem is something else.

If anybody has some suggestion I'll appreciate.

raf

[gentoo-amd64] Re: USB 2.0 falling back to full-speed

[Duncan]

Raffaele BELARDI <raffaele.belardi@st.com> posted 48C62775.6050808@st.com,
excerpted below, on  Tue, 09 Sep 2008 09:36:21 +0200:

> I've recently had to change my MB to a M2A-VM (AMD 690G/ATI SB600
> chipset), since then I have problems with the USB2.0.
> 
> The syslog most of the times shows at boot the ehci_hcd kernel driver
> (the 2.0 driver) trying to assign some address to the 2.0 hub, and the
> hub refusing it or failing with some I/O error. The driver tries 4
> different addresses, then falls back to ohci_hcd (the 1.1 driver) and
> works fine but at low speed. The whole procedure takes maybe 1 minute,
> for this time any peripheral connected to the port will not be detected.

Do you have the USB drivers compiled in or as modules?  I know some years 
ago, in some cases they'd only work as modules.  This was with USB 1.1 
hardware, but maybe USB 2.0 has similar issues?

Anyway, since then I've always compiled them as modules, and haven't had 
a problem, other than once when I booted my backup installation which was 
outdated and didn't have modules for the current kernel, and I ended up 
without keyboard and mouse since those are USB.  Fortunately I have the 
ACPI power switch detection setup to shut-down, so I was able to do so 
gracefully and reboot to a different kernel, but it was certainly 
frustrating, as I prefer to compile in all the basics.  I've been going 
to test a newer kernel with the drivers compiled in, but so far haven't 
gotten the appropriate round tuit... =:^(

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: USB 2.0 falling back to full-speed

[Raffaele BELARDI]

Duncan wrote:
> Do you have the USB drivers compiled in or as modules?  I know some years 
> ago, in some cases they'd only work as modules.  This was with USB 1.1 
> hardware, but maybe USB 2.0 has similar issues?
> 
> Anyway, since then I've always compiled them as modules, and haven't had 
> a problem, other than once when I booted my backup installation which was 
> outdated and didn't have modules for the current kernel, and I ended up 
> without keyboard and mouse since those are USB.  Fortunately I have the 
> ACPI power switch detection setup to shut-down, so I was able to do so 
> gracefully and reboot to a different kernel, but it was certainly 
> frustrating, as I prefer to compile in all the basics.  I've been going 
> to test a newer kernel with the drivers compiled in, but so far haven't 
> gotten the appropriate round tuit... =:^(
> 

They're compiled-in, I have module support disabled for this kernel. 
I've had some Google hit suggesting that a similar problem was solved by 
loading first the ehci_hcd, then the ohci_hcd. It was relatively old 
message, but given also your input it is worth a try.

raf

Re: [gentoo-amd64] Re: USB 2.0 falling back to full-speed

[Raffaele BELARDI]

Raffaele Belardi wrote:
> 
> They're compiled-in, I have module support disabled for this kernel. 
> I've had some Google hit suggesting that a similar problem was solved by 
> loading first the ehci_hcd, then the ohci_hcd. It was relatively old 
> message, but given also your input it is worth a try.
> 

I've also found somebody reported ehci-related problem on the same SB600 
chipset:
http://bugzilla.kernel.org/show_bug.cgi?id=8692

The HW has problems, there are some bug fixes which should be already in 
the kernel I am using (2.6.25-r8, I believe, I am on another machine), 
but there is also a hint in comment #55 about bad interaction between 
ehci and CPU throttling, which I am using. I'll try disabling 'ondemand'.

raf

Re: [gentoo-amd64] Re: USB 2.0 falling back to full-speed

[Raffaele BELARDI]

Raffaele Belardi wrote:
> I've also found somebody reported ehci-related problem on the same SB600 
> chipset:
> http://bugzilla.kernel.org/show_bug.cgi?id=8692
> 
> The HW has problems, there are some bug fixes which should be already in 
> the kernel I am using (2.6.25-r8, I believe, I am on another machine), 
> but there is also a hint in comment #55 about bad interaction between 
> ehci and CPU throttling, which I am using. I'll try disabling 'ondemand'.

I did some testing:
- powernow disabled, ehci and ohci compiled-in, USB2.0 fails
- powernow enabled, ehci and ohci loaded as modules, USB2.0 fails
=> powernow disabled, ehci and ohci loaded as modules, USB2.0 success
=> powernow enabled, ondemand and performance selected, default set to 
'performance' (later changed by gnome to ondemand?), ehci and ohci 
loaded as modules, USB2.0 success

The last configuration is good enough for me, I'm not losing any 
functionality. I'll do some more testing to confirm it is working.

Regarding powernow, the above link contains some hint to why it 
adversely affects the USB2.0 functionality.

Regarding usb loaded as module, the only syslog difference I found with 
the compiled-in version is that in the former ehci is loaded after ohci, 
while in the latter it is loaded before ohci.

Is there a way to force the kernel to initialize/invoke drivers in a 
specific order with compiled-in drivers?

raf

[gentoo-amd64] Re: USB 2.0 falling back to full-speed

[Duncan]

Raffaele BELARDI <raffaele.belardi@st.com> posted 48C7ADE8.3020300@st.com,
excerpted below, on  Wed, 10 Sep 2008 13:22:16 +0200:

> Regarding usb loaded as module, the only syslog difference I found with
> the compiled-in version is that in the former ehci is loaded after ohci,
> while in the latter it is loaded before ohci.
> 
> Is there a way to force the kernel to initialize/invoke drivers in a
> specific order with compiled-in drivers?

I believe there is... at least in some cases... using the kernel command 
line in grub.  It's not something I've tried nor do I remember the 
details, unfortunately.

The config description for ehci says root-hubs are paired with an ohci/
uhci hub as well, for 1.1 fallback, and suggesting that you configure in 
the appropriate one of those as well, which you did.  In theory, 
therefore, both should work regardless of which one starts first.  
Obviously the theory doesn't match this implementation.  I'd be surprised 
if there wasn't either an ordering mechanism (user-side) or an in-kernel 
quirk list regarding start order, however, just because hardware bugs 
happen.

As for CPU throttling, after reading that bug ( 
http://bugzilla.kernel.org/show_bug.cgi?id=8692 ), it appears they 
/tried/ to avoid having sensitive operations going on during frequency 
changes.  But that was well after boot and everything was initialized.  
It's entirely possible they still need to modify the boot to stabilize 
frequencies while initializing the drivers, as well.  If you're up to a 
lot of testing (well, it's obvious from that bug how many rounds it could 
take...), you might consider filing a bug on it and see what they say.  
Since you can't say it's a regression from a known working version, they 
may not be quite as willing to work on it, but then again, they know what 
fixed it in the up and running case, so fixing it during initialization 
as well shouldn't be so hard.

But anyway, I'm glad my info was of help getting it working in some 
fashion, even if it's not your first config choice.  I guess you're lucky 
you found both triggers at about the same time.  Consider the chances if 
you'd not thought to try them together!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: USB 2.0 falling back to full-speed

[Raffaele BELARDI]

Duncan wrote:
>  If you're up to a
> lot of testing (well, it's obvious from that bug how many rounds it could 
> take...), you might consider filing a bug on it and see what they say.  
> Since you can't say it's a regression from a known working version, they 
> may not be quite as willing to work on it, but then again, they know what 
> fixed it in the up and running case, so fixing it during initialization 
> as well shouldn't be so hard.
> 

I'll think of it, although I'm afraid I might not find the time to 
follow up on the possible developer's requests. Since you have done it 
already, do you have pointers to get me started? I assume there's some 
fixed format needed to get the bug filed.

Thanks for helping solve this problem!

raf

[gentoo-amd64] Re: USB 2.0 falling back to full-speed

[Duncan]

Raffaele BELARDI <raffaele.belardi@st.com> posted 48C90384.9070804@st.com,
excerpted below, on  Thu, 11 Sep 2008 13:39:48 +0200:

> I'll think of it, although I'm afraid I might not find the time to
> follow up on the possible developer's requests. Since you have done it
> already, do you have pointers to get me started? I assume there's some
> fixed format needed to get the bug filed.
> 
> Thanks for helping solve this problem!

Not really a fixed format.  Just provide everything you can think they 
might want... mentioning the other bug by number (as in bug #xxxxxxx) so 
it gets auto-linked, telling them the kernel you are using and any where 
you noticed changes in behavior, attaching your kernel .config file and a 
kernel boot log (dmsg, there's an option in the config to change the size 
of the log buffer if necessary), plus any post-boot syslog messages that 
seem relevant, mentioning Gentoo/amd64, the gcc version in case it's a 
mis-compile, the mobo and chipset, what you've already done to try to 
trace it down, etc.  You'll probably want to run the vanilla kernel for 
reporting and testing, just so no weird patches from anything else are 
confusing things.

My cases have all been regressions, in which case I noted the last kernel 
that worked and the first that didn't, usually to the -rc level.  One can 
then bisect down to the daily snapshot and beyond if one has the time tho 
it's not entirely necessary once they start debugging, usually.

Of course your bug will be somewhat different, in that it's not really a 
regression (you may want to test that for sure, try a couple older 
kernels just to see), but what's likely a bit of an extension from the 
other bug, so they already have a decent amount of data on how this thing 
normally behaves.  I'd put that in the explanation.

I don't expect this one to be too major, actually.  They may simply add 
the chipset to a list of boards that needs a reverse order or something, 
or may just give you a (grup) kernel command line option to reverse it 
and tell you that's the solution...

If it were me, in keeping with the provide any info that might be 
relevant theme... since there's already some discussion of it here, I'd 
put a link to the thread as well.  Who knows what bit of info might be 
here that would otherwise take several rounds of back and forth before 
you or they even realize it's relevant?  FWIW, here's the gmane link to 
your original post:

http://permalink.gmane.org/gmane.linux.gentoo.amd64/13127

FWIW, if you post the bug number here once you have it, I'll probably CC 
myself.  As I said all the ones I've filed have been regressions, so it'd 
be interesting to see how this runs.

BTW, unlike Gentoo and most FLOSS projects, many of which strongly prefer 
that you file a bug in bugzilla, the kernel mode of operation is more 
mailing list oriented, and they only have a bugzilla since that's what 
many users have come to expect for filing bugs and tend to be comfortable 
with.  If you prefer mailing, you can mail the LKML, CCing the 
appropriate area maintainer, etc.  However, for those not already in the 
kernel loop, bugzilla is likely much simpler, and Andrew and others do 
watch it and make sure the bugs get channeled to the right place.

BTW, http://bugzilla.kernel.org .

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: USB 2.0 falling back to full-speed

[Raffaele BELARDI]

Duncan wrote:
>  You'll probably want to run the vanilla kernel for 
> reporting and testing, just so no weird patches from anything else are 
> confusing things.

Per you suggestion I downloaded a 2.6.25.15 kernel from kernel.org, 
compiled with my old defaults (no modules, ondemand powernow) and got no 
USB problem at boot. So I looked better at the gentoo-sources changelog, 
I found I was previously using an older kernel (2.6.25.11) and thought 
'good, they fixed it'. But then the problem appeared again, this time 15 
minutes after the boot and I lost the USB mouse. So now I am trying the 
2.6.25.15 with usb loaded as modules, at least I can try to re-load the 
module to get the high speed functionality back.

Unfortunately there is no fix in recent kernels for SB600 chipset 
related to USB, so I might be one of the few experiencing this problem. 
Weird.

[gentoo-amd64] Re: USB 2.0 falling back to full-speed

[Duncan]

Raffaele BELARDI <raffaele.belardi@st.com> posted 48CE7D84.7080603@st.com,
excerpted below, on  Mon, 15 Sep 2008 17:21:40 +0200:

> Unfortunately there is no fix in recent kernels for SB600 chipset
> related to USB, so I might be one of the few experiencing this problem.
> Weird.

I know the frustration of being one of the few.  I've an open kernel bug 
on a compilation failure apparently related to the changed location of 
certain arch-related header files in the 2.6.27-rcs, that only manifests 
if KBUILD_OUTPUT is set as suggested in the root makefile.  Apparently 
I'm the only one testing the rcs on X86_64 that handles it exactly that 
way (there's another way to accomplish the same thing using a command 
line option), and they're having trouble duplicating the problem. FWIW 
http://bugzilla.kernel.org/show_bug.cgi?id=11450 .  So yeah, one of the 
few can definitely be frustrating!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: USB 2.0 falling back to full-speed

[Raffaele BELARDI]

Duncan wrote:
> FWIW, if you post the bug number here once you have it, I'll probably CC 
> myself.  As I said all the ones I've filed have been regressions, so it'd 
> be interesting to see how this runs.
> 

http://bugzilla.kernel.org/show_bug.cgi?id=11599

I got an answer within a couple of hours, looks like it is a know hw bug 
in the chipset. I was suggested to try with 2.6.27-rc6, I'm downloading 
it now.

Hope I don't hit the same problem Duncan is experiencing when compiling 
2.6.27...

raf

[gentoo-amd64] Re: USB 2.0 falling back to full-speed

[Duncan]

Raffaele BELARDI <raffaele.belardi@st.com> posted 48D756E0.6090202@st.com,
excerpted below, on  Mon, 22 Sep 2008 10:27:12 +0200:

> http://bugzilla.kernel.org/show_bug.cgi?id=11599
> 
> I got an answer within a couple of hours, looks like it is a know hw bug
> in the chipset. I was suggested to try with 2.6.27-rc6, I'm downloading
> it now.
> 
> Hope I don't hit the same problem Duncan is experiencing when compiling
> 2.6.27...

FWIW, 2.6.27-rc7 is out now tho I've not tried it yet. ... And my 
compiling problem turned out to be due to usage of the KBUILD_OUTPUT var 
to set the output-dir, as detailed in the makefile.  That's certainly a 
bug since it /is/ documented in the makefile, but at least there's a way 
around it now.

(That said, now that I can compile, there's another bug in actually 
getting -rc6 to run (again I've not yet tried -rc7), grub loads the 
kernel or I'd have a grub error (I tried it by pointing grub at a non-
existent file), but there's no early console output at all from it and it 
self-reboots pretty quickly, so the init must be failing pretty early.  
I'm running radeonfb tho, without vgacon even compiled in.  I should try 
it with the standard vgacon and see if that works.)  

So anyway, as long as you are compiling into the kernel sources tree 
itself (or, reports are, setting the output dir from the command line 
instead of by var), you should avoid the compile problem I had, and 
hopefully you don't hit whatever other bug it is I'm hitting with -rc6, 
and hopefully it's fixed for me in -rc7. =:^S

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-amd64] Re: USB 2.0 falling back to full-speed

[Duncan]

Duncan <1i5t5.duncan@cox.net> posted pan.2008.09.22.14.04.10@cox.net,
excerpted below, on  Mon, 22 Sep 2008 14:04:10 +0000:

> FWIW, 2.6.27-rc7 is out now tho I've not tried it yet. ... And my
> compiling problem turned out to be due to usage of the KBUILD_OUTPUT var
> to set the output-dir, as detailed in the makefile.  That's certainly a
> bug since it /is/ documented in the makefile, but at least there's a way
> around it now.

Well, playing around with -rc7, I finally figured out what I was doing 
wrong, and yes, it was a PEBCAK bug! =:^(  I had been copying the 
KBUILD_OUTPUT dir from the old kernel to the new one, thus apparently 
saving a few hundred jobs of copying header files from the sources dir 
into the outputdir and the like. (Running -j, unlimited jobs, I'd peak at 
180 or so copying over the old working outputdir, something over 400 
without).

Only between -rc1 and -rc2 for 2.6.27, they changed the location of a 
bunch of header files, and the old headers in the outputdir/include 
subdir were fighting with the new ones.

By starting with an entirely clean outputdir (but for the old .config, 
which I run make oldconfig on, first thing), everything worked the way it 
was supposed to.  So I reclosed the bug, rejected-invalid.

I guess I know for next time, now.

(BTW, Beso, that's why you haven't heard anything from me lately on my 
kernel scripts... I was wondering what might be wrong with them...  Now I 
have to think a bit and probably change a couple things... wouldn't want 
anyone else to be stumped by the same problem I was, due to my scripts...)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman