Bug 181732 - 4-port usb hub not working as expected with rawhide kernels.. works under latest fc4 kernel
Summary: 4-port usb hub not working as expected with rawhide kernels.. works under lat...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 5
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-02-16 01:19 UTC by Jef Spaleta
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version: 2.6.18-1.2200.fc5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-10-21 21:38:37 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
kernel-2.6.15-1.1948_FC5 boot dmesg with non-functional usb hub (11.60 KB, text/plain)
2006-02-16 02:58 UTC, Jef Spaleta
no flags Details
kernel-2.6.15-1.1831_FC4 dmesg with functional hub on boot (11.72 KB, text/plain)
2006-02-16 02:59 UTC, Jef Spaleta
no flags Details
kernel-2.6.15-1.1884_FC5 dmseg with non-functional hub at boot (11.78 KB, text/plain)
2006-02-16 03:27 UTC, Jef Spaleta
no flags Details

Description Jef Spaleta 2006-02-16 01:19:03 UTC
Description of problem:
I have a 4-port hub which is behaving quite oddly on recent rawhide kernels.
usb-storage devices which i plug into the hub are not being correctly picked up
and /dev/ entries are not being created for them if and only if i plug them into
the hub.  Seems to be working fine under fc4.

Whats really baking my noodle is that lsusb lists the devices just fine
but they are not listed in /proc/scsi/scsi when attached through the hub.
I don't know how to interpret the problem when the device shows up in lsusb but
  is not showing up in /proc/scsi/scsi

the only message I don't think I understand in /var/log/messages is the message:
Feb 15 20:00:05 goober kernel: usb 1-1.1: no configuration chosen from 1 choice

Please advise me as to additional information I can provide with regard to
figuring out where things are going wrong with devices attached through the hub.

-jef 

Version-Release number of selected component (if applicable):
kernel-smp-2.6.15-1.1948_FC5  and kernels from at least the last 2 weeks.


How reproducible:
always


Additional info:

####Case #1 cf card reader attached through hub

/sbin/lsusb output:
Unknown line at line 5924
Unknown line at line 5925
Unknown line at line 5926
Unknown line at line 5927
Unknown line at line 5928
Unknown line at line 5929
Unknown line at line 5930
Unknown line at line 5931
Unknown line at line 5932
Unknown line at line 5933
Unknown line at line 5934
Unknown line at line 5935
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 010: ID 0781:9191 SanDisk Corp.  
Bus 001 Device 009: ID 0451:2046 Texas Instruments, Inc. TUSB2046 Hub
Bus 001 Device 001: ID 0000:0000

cat /proc/scsi/scsi output:
Attached devices:

/var/log/messages additions:
Feb 15 20:14:41 goober kernel: ohci_hcd 0000:00:07.4: wakeup
Feb 15 20:14:41 goober kernel: usb 1-1: new full speed USB device using ohci_hcd
and address 9
Feb 15 20:14:41 goober kernel: usb 1-1: configuration #1 chosen from 1 choice
Feb 15 20:14:41 goober kernel: hub 1-1:1.0: USB hub found
Feb 15 20:14:41 goober kernel: hub 1-1:1.0: 4 ports detected
Feb 15 20:14:41 goober kernel: usb 1-1.1: new full speed USB device using
ohci_hcd and address 10
Feb 15 20:14:42 goober kernel: usb 1-1.1: not running at top speed; connect to a
high speed hub
Feb 15 20:14:42 goober kernel: usb 1-1.1: no configuration chosen from 1 choice


#####Case #2 no hub in use, cf carder reader attached to usb port on computer
/sbin/lsusb output:
Unknown line at line 5924
Unknown line at line 5925
Unknown line at line 5926
Unknown line at line 5927
Unknown line at line 5928
Unknown line at line 5929
Unknown line at line 5930
Unknown line at line 5931
Unknown line at line 5932
Unknown line at line 5933
Unknown line at line 5934
Unknown line at line 5935
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 011: ID 0781:9191 SanDisk Corp.
Bus 001 Device 001: ID 0000:0000

cat /proc/scsi/scsi output:
Attached devices:
Host: scsi2 Channel: 00 Id: 00 Lun: 00
  Vendor: SanDisk  Model: ImageMate CF     Rev: 1.00
  Type:   Direct-Access                    ANSI SCSI revision: 02

/var/log/messages  additions:
Feb 15 20:18:04 goober kernel: ohci_hcd 0000:00:07.4: wakeup
Feb 15 20:18:04 goober kernel: usb 1-1: new full speed USB device using ohci_hcd
and address 11
Feb 15 20:18:04 goober kernel: usb 1-1: not running at top speed; connect to a
high speed hub
Feb 15 20:18:04 goober kernel: usb 1-1: configuration #1 chosen from 1 choice
Feb 15 20:18:04 goober kernel: scsi2 : SCSI emulation for USB Mass Storage devices
Feb 15 20:18:10 goober kernel:   Vendor: SanDisk   Model: ImageMate CF      Rev:
1.00
Feb 15 20:18:10 goober kernel:   Type:   Direct-Access                      ANSI
SCSI revision: 00
Feb 15 20:18:10 goober kernel: SCSI device sda: 500736 512-byte hdwr sectors
(256 MB)
Feb 15 20:18:10 goober kernel: sda: Write Protect is off
Feb 15 20:18:10 goober kernel: sda: assuming drive cache: write through
Feb 15 20:18:10 goober kernel: SCSI device sda: 500736 512-byte hdwr sectors
(256 MB)
Feb 15 20:18:10 goober kernel: sda: Write Protect is off
Feb 15 20:18:10 goober kernel: sda: assuming drive cache: write through
Feb 15 20:18:10 goober kernel:  sda: sda1
Feb 15 20:18:10 goober kernel: sd 2:0:0:0: Attached scsi removable disk sda
Feb 15 20:18:10 goober kernel: sd 2:0:0:0: Attached scsi generic sg0 type 0

Comment 1 Pete Zaitcev 2006-02-16 01:47:15 UTC
Wild!

Jef, would do this for me... plug this thing in on broken kernel, plug the
storage, then take a dmesg > /tmp/dmesg.bad. Then, do the same on working
kernel (as close sequence as possible), and  dmesg > /tmp/dmesg.good.
Then attach both dmesgs to the bug, unedited.

It would be best if this was done on the same box, to exclude the HC issues.
The objective is to have a meaningful run of  diff -u dmesg.good dmesg.bad
I'm asking about unedited dmesg because the problem may be in HC initialization,
handoff, TT (transaction translator), or other thing way above the failure.


Comment 2 Jef Spaleta 2006-02-16 02:55:51 UTC
Done...
good kernel kernel-2.6.15-1.1831_FC4
bad kernel kernel-2.6.15-1.1948_FC5
run on exactly the same hardware I just installed the good FC4 kernel on the
rawhide box and rebooted with the hub+reader plugged in a boot time and repeated
for the bad kernel.  I'd have to look around more for something closer in
sequence that works. 

dmesg.bad and dmesg.good to be attached in a moment.

-jef

Comment 3 Jef Spaleta 2006-02-16 02:58:10 UTC
Created attachment 124736 [details]
kernel-2.6.15-1.1948_FC5 boot dmesg with non-functional usb hub

Comment 4 Jef Spaleta 2006-02-16 02:59:02 UTC
Created attachment 124737 [details]
kernel-2.6.15-1.1831_FC4 dmesg with functional hub on boot

Comment 5 Jef Spaleta 2006-02-16 03:27:44 UTC
Created attachment 124738 [details]
kernel-2.6.15-1.1884_FC5 dmseg with non-functional hub at boot

Okay here is the oldest rawhide kernel that I can find locally on my systems.
kernel-2.6.15-1.1884_FC5  exhibits badness.

-jef

Comment 6 Pete Zaitcev 2006-02-17 08:12:25 UTC
Perfect dmesgs. I already diffed them, saw that message about the
configuration not selected. Unfortunately I'm a little under with
other work.


Comment 7 Jef Spaleta 2006-02-19 02:53:51 UTC
Yeah, I'm sure this isn't a particularly high priority issue.
And well.. it gives me a plausible excuse to use with the household's financial
officer to buy a usb-2 compliant hub.

I wish i had a second rawhide box up and running of a different hardware vintage
to cross compare.

-jef 

Comment 8 Pete Zaitcev 2006-02-19 03:37:10 UTC
It's may be ok physically, just descriptors are erroneous.
Also, older kernels worked, so it's a regression, strictly speaking.
I'll get to it, the question is only when.


Comment 9 Dave Jones 2006-10-16 20:35:35 UTC
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.

Comment 10 Jef Spaleta 2006-10-21 21:38:37 UTC
my 4-port hub is working again.

thank you kernel fairies!




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