Bug 486511 - ppc: usb: rawhide kernel fails to enumerate USB
ppc: usb: rawhide kernel fails to enumerate USB
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
ppc Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-19 23:04 EST by Tony Breeds
Modified: 2009-03-10 14:05 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-10 14:05:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg from 2.6.29-0.131.rc5.git2.fc11.ppc (17.09 KB, text/plain)
2009-02-19 23:05 EST, Tony Breeds
no flags Details
dmesg from 2.6.29-rc5 (15.04 KB, text/plain)
2009-02-19 23:05 EST, Tony Breeds
no flags Details
one of these changes seem to cause the problem (1.27 KB, patch)
2009-03-01 16:28 EST, Alex Kanavin
no flags Details | Diff
Trivial patch to disable CONFIG_GEF_SBC610 (525 bytes, patch)
2009-03-03 18:50 EST, Tony Breeds
no flags Details | Diff
detect sbc610 boards (900 bytes, patch)
2009-03-03 20:18 EST, Kyle McMartin
no flags Details | Diff
Trivial patch to disable CONFIG_GEF_SBC610 v2 (524 bytes, patch)
2009-03-03 22:01 EST, Tony Breeds
no flags Details | Diff

  None (edit)
Description Tony Breeds 2009-02-19 23:04:22 EST
Description of problem:
The rawhide kernel (2.6.29-0.131.rc5.git2.fc11) fails to enumerate devices attached to USB hubs on ppc.  I've tested a 2.6.29-rc5 upstream release and
the devices function correctly.

Version-Release number of selected component (if applicable): 2.6.29-0.131.rc5.git2.fc11, this same problem is evident in the F-11-Alpha release. 


How reproducible: 100%


Steps to Reproduce:
1.  Boot rawhide kernel on MacMini or similar machine
  
Actual results:
[root@ago ~]# egrep 'usb [0-9]' dmesg-2.6.29-0.131.rc5.git2.fc11.ppc
usb 3-1: new full speed USB device using ohci_hcd and address 2
usb 3-1: device descriptor read/64, error -62
usb 3-1: device descriptor read/64, error -62
usb 3-1: new full speed USB device using ohci_hcd and address 3
usb 3-1: device descriptor read/64, error -62
usb 3-1: device descriptor read/64, error -62
usb 3-1: new full speed USB device using ohci_hcd and address 4
usb 3-1: device not accepting address 4, error -62
usb 3-1: new full speed USB device using ohci_hcd and address 5
usb 3-1: device not accepting address 5, error -62
usb 3-1: new full speed USB device using ohci_hcd and address 6
usb 3-1: device descriptor read/64, error -62
usb 3-1: device descriptor read/64, error -62
usb 3-1: new full speed USB device using ohci_hcd and address 7
usb 3-1: device descriptor read/64, error -62
usb 3-1: device descriptor read/64, error -62
usb 3-1: new full speed USB device using ohci_hcd and address 8
usb 3-1: device not accepting address 8, error -62
usb 3-1: new full speed USB device using ohci_hcd and address 9
usb 3-1: device not accepting address 9, error -62

Expected results:
[root@ago ~]# egrep 'usb [0-9]' dmesg-2.6.29-rc5 
usb 2-1: new full speed USB device using ohci_hcd and address 2
usb 2-1: configuration #1 chosen from 1 choice
usb 2-1.1: new full speed USB device using ohci_hcd and address 3
usb 2-1.1: configuration #1 chosen from 1 choice
usb 2-1.2: new low speed USB device using ohci_hcd and address 4
usb 2-1.2: device not accepting address 4, error -62
usb 2-1: USB disconnect, address 2
usb 2-1.1: USB disconnect, address 3
usb 2-1: new full speed USB device using ohci_hcd and address 8
usb 2-1: configuration #1 chosen from 1 choice
usb 2-1.1: new full speed USB device using ohci_hcd and address 9
usb 2-1.1: not running at top speed; connect to a high speed hub
usb 2-1.1: configuration #1 chosen from 1 choice
usb 2-1.2: new low speed USB device using ohci_hcd and address 10
usb 2-1.2: configuration #1 chosen from 1 choice
generic-usb 0003:05AC:0307.0001: input: USB HID v1.10 Mouse [Logitech Apple Optical USB Mouse] on usb-0001:10:1b.0-1.2/input0
usb 2-1.3: new full speed USB device using ohci_hcd and address 11
usb 2-1.3: configuration #1 chosen from 1 choice
generic-usb 0003:05AC:020B.0002: input: USB HID v1.10 Keyboard [Mitsumi Electric Apple Extended USB Keyboard] on usb-0001:10:1b.0-1.3/input0
generic-usb 0003:05AC:020B.0003: input: USB HID v1.10 Device [Mitsumi Electric Apple Extended USB Keyboard] on usb-0001:10:1b.0-1.3/input1

Additional info:
[root@ago device-tree]# cat model 
PowerMac10,1
[root@ago openprom]# cat model 
OpenFirmware 3
Comment 1 Tony Breeds 2009-02-19 23:05:11 EST
Created attachment 332667 [details]
dmesg from 2.6.29-0.131.rc5.git2.fc11.ppc
Comment 2 Tony Breeds 2009-02-19 23:05:47 EST
Created attachment 332668 [details]
dmesg from 2.6.29-rc5
Comment 3 Josh Boyer 2009-02-26 15:00:00 EST
Tony, can you poke at this a bit and see which patch (or config option) in rawhide seems to introduce the problem?

I have no working ppc32 machine at the moment.
Comment 4 Tony Breeds 2009-02-26 19:45:16 EST
Sure.  My MacMini is a little slow but I'll get there.
Comment 5 Kyle McMartin 2009-02-27 08:49:16 EST
Sorry :/ we're just not currently patching this in any way in rawhide, so it's either an issue with a config setting, or an upstream issue as well. Possibly there's other reports of this on linuxppc-dev, or is ppc32 pretty well abandoned as far as top of tree testing goes?
Comment 6 Alex Kanavin 2009-02-27 14:24:56 EST
I see there's a ton of patches that come with the rawhide kernel's src.rpm or did you mean something else? Might be one of them...
Comment 7 Josh Boyer 2009-02-27 14:58:56 EST
(In reply to comment #5)
> Sorry :/ we're just not currently patching this in any way in rawhide, so it's
> either an issue with a config setting, or an upstream issue as well. Possibly
> there's other reports of this on linuxppc-dev, or is ppc32 pretty well
> abandoned as far as top of tree testing goes?

There aren't reports of it on linuxppc-dev.  At least not in the past two months or so.  ppc32 testing from a kernel aspect is mostly limited to embedded boards that Fedora doesn't support anyway.
Comment 8 Tony Breeds 2009-02-27 18:20:32 EST
(In reply to comment #5)
> Sorry :/ we're just not currently patching this in any way in rawhide, so it's
> either an issue with a config setting, or an upstream issue as well. Possibly
> there's other reports of this on linuxppc-dev, or is ppc32 pretty well
> abandoned as far as top of tree testing goes?

I tested -rc5 from upstream and the problem isn't there, so it's either a Fedora patch or a config setting.  I'm trying to track down which it is.
Comment 9 Alex Kanavin 2009-03-01 16:28:41 EST
Created attachment 333664 [details]
one of these changes seem to cause the problem

I've done a few kernel builds using config files from F10 2.6.27 kernel, and I think I've narrowed the problem down to changes in config-powerpc-generic file. (see attachment for the patch). If you take the rawhide kernel and revert those changes, the problem should be gone - please verify.

Options that introduce new modules are probably not involved, and of the remaining options
+CONFIG_RELOCATABLE=y
+CONFIG_SIMPLE_GPIO=y
seem highly suspicious to my uneducated eye.

Anyway I'd like some hints about how to bisect this further (and how to do incremental kernel builds using src.rpm because a build from scratch takes 3 hours on my powerbook).
Comment 10 Kyle McMartin 2009-03-01 17:02:38 EST
Given we're basically patching nothing that would effect this, the easiest way to find the broken option would be to just 'make prep' on rawhide and copy the resulting config file to .config and build it locally and disable/enable the options that way.

You can at least (generally) reduce build time (and turn off piles of unrelated things like network drivers which wouldn't be causing this.)

regards, Kyle
Comment 11 Josh Boyer 2009-03-01 18:36:57 EST
(In reply to comment #9)
> Created an attachment (id=333664) [details]
> one of these changes seem to cause the problem
> 
> I've done a few kernel builds using config files from F10 2.6.27 kernel, and I
> think I've narrowed the problem down to changes in config-powerpc-generic file.
> (see attachment for the patch). If you take the rawhide kernel and revert those
> changes, the problem should be gone - please verify.
> 
> Options that introduce new modules are probably not involved, and of the
> remaining options
> +CONFIG_RELOCATABLE=y
> +CONFIG_SIMPLE_GPIO=y
> seem highly suspicious to my uneducated eye.

CONFIG_RELOCATABLE=y should actually get disabled entirely in the final .config file that is generated due to Kbuild dependencies.  It's generally only enabled for ppc64 kernels.
Comment 12 Tony Breeds 2009-03-03 18:49:14 EST
(In reply to comment #8)
> (In reply to comment #5)
> > Sorry :/ we're just not currently patching this in any way in rawhide, so it's
> > either an issue with a config setting, or an upstream issue as well. Possibly
> > there's other reports of this on linuxppc-dev, or is ppc32 pretty well
> > abandoned as far as top of tree testing goes?
> 
> I tested -rc5 from upstream and the problem isn't there, so it's either a
> Fedora patch or a config setting.  I'm trying to track down which it is.

The problem seems to be "CONFIG_GEF_SBC610", turning that off in an otherwise unchanged fedora kernel results in a functioning USB stack on my Mac Mini.

I'm doing a scratch build now of kernel-2.6.29-0.193.rc6.git7, with a patched config-powerpc-generic.  Assuming this works, can we get that removed from the fedora config while we talk with upstream to work out why it's a problem?
Comment 13 Tony Breeds 2009-03-03 18:50:33 EST
Created attachment 333953 [details]
Trivial patch to disable CONFIG_GEF_SBC610
Comment 14 Josh Boyer 2009-03-03 19:52:33 EST
(In reply to comment #12) 
> The problem seems to be "CONFIG_GEF_SBC610", turning that off in an otherwise
> unchanged fedora kernel results in a functioning USB stack on my Mac Mini.
> 
> I'm doing a scratch build now of kernel-2.6.29-0.193.rc6.git7, with a patched
> config-powerpc-generic.  Assuming this works, can we get that removed from the
> fedora config while we talk with upstream to work out why it's a problem?

Disabled.
Comment 15 Josh Boyer 2009-03-03 19:54:05 EST
I'm thinking it was upstream commit a969e76a7101bf5f3d369563df1ca1253dd6131b that causes the problem:

commit a969e76a7101bf5f3d369563df1ca1253dd6131b
Author: Martyn Welch <martyn.welch@gefanuc.com>
Date:   Mon Sep 29 13:35:15 2008 +0100

    powerpc: Correct USB support for GE Fanuc SBC610
    
    Support for the SBC610 VPX Single Board Computer from GE Fanuc (PowerPC
    MPC8641D).
    
    Fixup to correctly reconfigure USB, provided by an NEC uPD720101, after
    device is reset. This requires a set of chip specific registers in the
    devices configuration space to be correctly written, enabling all ports
    and switching the device to use an external 48-MHz Oscillator.
    
    Signed-off-by: Martyn Welch <martyn.welch@gefanuc.com>
    Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Comment 16 Kyle McMartin 2009-03-03 20:17:51 EST
Looks like it, it should be checking the subvendor/subdevice ids at the very least. Sigh. Broken code ftl. How about?
Comment 17 Kyle McMartin 2009-03-03 20:18:45 EST
Created attachment 333960 [details]
detect sbc610 boards

meh.
Comment 18 Tony Breeds 2009-03-03 22:01:19 EST
Created attachment 333966 [details]
Trivial patch to disable CONFIG_GEF_SBC610 v2

Apparently it wasn't as "trivial" as I thought.  This one builds.

Note You need to log in before you can comment on or make changes to this bug.