Bug 30961 - [noapic] USB device not accepting new address on Dell 2400
[noapic] USB device not accepting new address on Dell 2400
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-07 12:38 EST by Shane Painter
Modified: 2007-04-18 12:32 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-07-24 18:46:54 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)
Temporary workaround for slab poisoning (2.66 KB, patch)
2001-03-26 12:27 EST, Pete Zaitcev
no flags Details | Diff
Dmesg Output from 6450 (14.82 KB, text/plain)
2001-04-12 17:08 EDT, Shane Painter
no flags Details
Mptable Output from 6450 (10.86 KB, text/plain)
2001-04-12 17:09 EDT, Shane Painter
no flags Details

  None (edit)
Description Shane Painter 2001-03-07 12:38:11 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Sorry my new account still does not show RC2 or RC1,...

usb-ohci.c: unlink URB timeout
usb.c: USB device not accepting new address=6 (error=-110)
usb_control/bulk_msg: timeout
usb-ohci.c: unlink URB timeout
usb.c: USB device not accepting new address=7 (error=-110) 

Reproducible: Always
Steps to Reproduce:
1.load RC1 or RC2 with ps2 mouse
2.boot system, plug in usb mouse
3.error is reported to STDERR
usb-ohci.c: unlink URB timeout
usb.c: USB device not accepting new address=6 (error=-110)
usb_control/bulk_msg: timeout
usb-ohci.c: unlink URB timeout
usb.c: USB device not accepting new address=7 (error=-110)
Comment 1 Arjan van de Ven 2001-03-07 13:08:50 EST
What kind of motherboard chipset is this ?
Comment 2 Bill Nottingham 2001-03-07 13:21:53 EST
How much memory is in the machine?
Comment 3 Shane Painter 2001-03-08 12:16:10 EST
Motherboard is a Serverworks chipset - which works with RH7.0?
It has 512M RAM. 

Other oddities: The USB mouse works during installation, but upon reboot - kudzu
cannot see the mouse and promts you to remove the configuration. We are also
seeing this on the 6450 w/Serverworks and 2G Ram. 

Also, the 2550 and some others complain when USB mouse or Keyboard is attached -
but they still work. At the bottom there is a matrix of what does/doesn't work.
This is definatly a priority for us...
 
Here are some specifics by platform:
2550 (rc1)
==========
- keyboard connected and just worked
- mouse connected and had to run mouseconfig
- do get a console message (see below)

2550 (rc2)
==========
- same as for rc1
- When I connect the keyboard I see "usb.c: USB device 2 (vend/prod
  0x45e/0xb) is not claimed by any active driver" on the console which is
  harmless but possibly(?) annoying to people.

-----log contents-----
Mar  7 15:48:02 localhost kernel: hub.c: USB new device connect on bus1/2,
assigned device number 2
Mar  7 15:48:02 localhost kernel: usb.c: USB device 2 (vend/prod 0x45e/0xb) is
not claimed by any active driver.
Mar  7 15:48:02 localhost kernel: usb.c: registered new driver keyboard
Mar  7 15:48:02 localhost kernel: input0: USB HIDBP Keyboard 045e:000b on on
usb1:2.0
Mar  7 15:48:02 localhost kernel: usb.c: registered new driver hid
Mar  7 15:48:02 localhost kernel: keybdev.c: Adding keyboard: input0
Mar  7 15:49:19 localhost kernel: hub.c: USB new device connect on bus1/1,
assigned device number 3
Mar  7 15:49:19 localhost kernel: input1: USB HID v1.10 Mouse [Logitech USB
Mouse] on usb1:3.0
Mar  7 15:49:19 localhost kernel: usb.c: registered new driver usb_mouse
Mar  7 15:49:19 localhost kernel: mouse0: PS/2 mouse device for input1
Mar  7 15:49:19 localhost kernel: mice: PS/2 mouse device common for all mice
-----end-----

6450 (rc2)
==========
- keyboard and mouse seen as devices but drivers don't properly load
- The following log snippet is from when I had the machine running and
  connected one of the USB keyboards, then disconnected it and tried the
  other.  The mouse results were similar.  A reboot with USB mouse and
  keyboard attached didn't help.

-----log contents-----
Mar  7 15:58:56 localhost kernel: hub.c: USB new device connect on bus1/2,
assigned device number 2
Mar  7 15:58:59 localhost kernel: usb_control/bulk_msg: timeout
Mar  7 15:58:59 localhost kernel: usb-ohci.c: unlink URB timeout
Mar  7 15:58:59 localhost kernel: usb.c: USB device not accepting new address=2
(error=-110)
Mar  7 15:58:59 localhost kernel: hub.c: USB new device connect on bus1/2,
assigned device number 3
Mar  7 15:59:02 localhost kernel: usb_control/bulk_msg: timeout
Mar  7 15:59:02 localhost kernel: usb-ohci.c: unlink URB timeout
Mar  7 15:59:02 localhost kernel: usb.c: USB device not accepting new address=3
(error=-110)
Mar  7 16:01:00 localhost kernel: hub.c: USB new device connect on bus1/2,
assigned device number 4
Mar  7 16:01:03 localhost kernel: usb_control/bulk_msg: timeout
Mar  7 16:01:03 localhost kernel: usb-ohci.c: unlink URB timeout
Mar  7 16:01:03 localhost kernel: usb.c: USB device not accepting new address=4
(error=-110)
Mar  7 16:01:03 localhost kernel: hub.c: USB new device connect on bus1/2,
assigned device number 5
Mar  7 16:01:06 localhost kernel: usb_control/bulk_msg: timeout
Mar  7 16:01:06 localhost kernel: usb-ohci.c: unlink URB timeout
Mar  7 16:01:06 localhost kernel: usb.c: USB device not accepting new address=5
(error=-110)
Mar  7 16:01:10 localhost kernel: hub.c: USB new device connect on bus1/1,
assigned device number 6
Mar  7 16:01:13 localhost kernel: usb_control/bulk_msg: timeout
Mar  7 16:01:13 localhost kernel: usb-ohci.c: unlink URB timeout
Mar  7 16:01:13 localhost kernel: usb.c: USB device not accepting new address=6
(error=-110)
Mar  7 16:01:14 localhost kernel: hub.c: Cannot enable port 1 of hub 1,
disabling port.
Mar  7 16:01:14 localhost kernel: hub.c: Maybe the USB cable is bad?
Mar  7 16:01:15 localhost kernel: hub.c: Cannot enable port 1 of hub 1,
disabling port.
Mar  7 16:01:15 localhost kernel: hub.c: Maybe the USB cable is bad?
Mar  7 16:01:16 localhost kernel: hub.c: Cannot enable port 1 of hub 1,
disabling port.
Mar  7 16:01:16 localhost kernel: hub.c: Maybe the USB cable is bad?
Mar  7 16:01:16 localhost kernel: hub.c: USB new device connect on bus1/1,
assigned device number 7
Mar  7 16:01:19 localhost kernel: usb_control/bulk_msg: timeout
Mar  7 16:01:20 localhost kernel: usb-ohci.c: unlink URB timeout
Mar  7 16:01:20 localhost kernel: usb.c: USB device not accepting new address=7
(error=-110)
Mar  7 16:01:21 localhost kernel: hub.c: Cannot enable port 1 of hub 1,
disabling port.
Mar  7 16:01:21 localhost kernel: hub.c: Maybe the USB cable is bad?
Mar  7 16:01:21 localhost kernel: hub.c: USB new device connect on bus1/1,
assigned device number 8
Mar  7 16:01:24 localhost kernel: usb_control/bulk_msg: timeout
Mar  7 16:01:24 localhost kernel: usb-ohci.c: unlink URB timeout
Mar  7 16:01:24 localhost kernel: usb.c: USB device not accepting new address=8
(error=-110)
Mar  7 16:01:25 localhost kernel: hub.c: Cannot enable port 1 of hub 1,
disabling port.
Mar  7 16:01:25 localhost kernel: hub.c: Maybe the USB cable is bad?
Mar  7 16:02:28 localhost kernel: hub.c: USB new device connect on bus1/2,
assigned device number 9
Mar  7 16:02:31 localhost kernel: usb_control/bulk_msg: timeout
Mar  7 16:02:31 localhost kernel: usb-ohci.c: unlink URB timeout
Mar  7 16:02:31 localhost kernel: usb.c: USB device not accepting new address=9
(error=-110)
Mar  7 16:02:31 localhost kernel: hub.c: USB new device connect on bus1/2,
assigned device number 10
Mar  7 16:02:34 localhost kernel: usb_control/bulk_msg: timeout
Mar  7 16:02:34 localhost kernel: usb-ohci.c: unlink URB timeout
Mar  7 16:02:34 localhost kernel: usb.c: USB device not accepting new address=10
(error=-110)
-----end-----
Here is a matrix of what works/doesn't

                 KB            MO
300          y                y            --  Dfct 29646
1300        y                n            --  same console error as Dfct 29646
1400        y                y
1550        Dean's working on it
2300        NA
2400        n                n            -- Dfct 29628
2450        n                n            -- same as Dfct 29628
2500        y                y
2550        y                y
4350        NA
4400        y                y
6350        NA
6450        Jonathan's working on it
8450        y                Unable to test mouse while xwindows broken
100          Equivalent to 350 per Becky
110          y                y
350          Test pending (machine in use)


Comment 4 Shane Painter 2001-03-08 12:19:18 EST
This might help as well...

DFCT29646  
 Title:  Use of USB on Newt gives "not claimed by any active driver" error
message  
 Description:  On a Newt with bios A01 and RC2 installed, plugging in USB device
causes console to state:

usb.c: USB device 2 (vend/prod 0x45e/0xb) is not claimed by any active driver.

However, all USB devices function normally.  (logging as sev 3)  
Comment 5 Shane Painter 2001-03-12 14:22:21 EST
How is this coming? This is a BIG bug for us, so I am pretty concerned about 
getting it fixed. Have you been able to reproduce this on your equiptment there?
Comment 6 Pete Zaitcev 2001-03-14 21:16:17 EST
Just got a remote access to a 24xx in Meridian.
Mar 14 21:35:33 ha3 kernel: usb-ohci.c: usb-00:0f.2, PCI device 1166:0220
(ServerWorks)
Comment 7 Glen Foster 2001-03-19 10:23:33 EST
This defect considered MUST-FIX for Florence Gold
Comment 8 Pete Zaitcev 2001-03-21 01:15:24 EST
It seems that interrupts do not get delivered for some reason.
Everything works with "noapic". Took me a while to figure it though...
Sorry for the delay - investigated alignment in ohci.

With noapic:

[root@ha3 /root]# cat /proc/interrupts
           CPU0       
  0:      26226          XT-PIC  timer
  1:          4          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  5:       6516          XT-PIC  aic7xxx, eth0
  8:          1          XT-PIC  rtc
 10:         20          XT-PIC  usb-ohci
 11:         30          XT-PIC  aic7xxx
 12:          0          XT-PIC  PS/2 Mouse
 14:          0          XT-PIC  ide0
NMI:          0 
LOC:      26189 
ERR:          0
MIS:          0
[root@ha3 /root]# 

Regular (broken) configuration:

[root@ha3 /root]# cat /proc/interrupts
           CPU0       
  0:       6476    IO-APIC-edge  timer
  1:          4    IO-APIC-edge  keyboard
  2:          0          XT-PIC  cascade
  8:          1    IO-APIC-edge  rtc
 10:          0          XT-PIC  usb-ohci
 12:          0    IO-APIC-edge  PS/2 Mouse
 14:          2    IO-APIC-edge  ide0
 22:        131   IO-APIC-level  eth0
 30:         30   IO-APIC-level  aic7xxx
 31:       2770   IO-APIC-level  aic7xxx
NMI:          0 
LOC:       6420 
ERR:          0
MIS:          0
[root@ha3 /root]# 
Comment 9 Pete Zaitcev 2001-03-26 12:27:01 EST
Created attachment 13703 [details]
Temporary workaround for slab poisoning
Comment 10 Pete Zaitcev 2001-03-26 12:39:05 EST
Two problems prevent OHCI from running here.

First is that OHCI does not work when slab poisoning
is enabled. I have a patch that fixes that but it is not
a good patch. Since we do not plan to ship a kernel
with poisoning, let us keep the patch for a reference,
but not include it.

Second problem is that A04 bios for my 2450 was buggy.
I replaced it with A06 revision and it fixed the problem.
Here is a telltale sign of a buggy BIOS. In dmesg output,
look at the translation table. For example:

IRQ to pin mappings:
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ12 -> 0:12
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 1:0
IRQ17 -> 1:1
IRQ18 -> 1:2
IRQ20 -> 1:4
IRQ21 -> 1:5
IRQ22 -> 1:6
IRQ23 -> 1:7
IRQ30 -> 1:14
IRQ31 -> 1:15
.................................... done.

Observe that IRQ 10, used by OHCI, is missing.
This bug screws Win2k as well.

The main problem is BIOS, but I will not resolve
this as NOTABUG because I think usb-ohci needs
right fixing for those who use poisoning. David Brownell
posted a better patch already, I will look into that.
Resolving as DEFERRED.

Also... Dell folks are not able to test the thing until
we ship them a non-poisoned kernel. If they
build their own kernels for preinstalled systems
it is easy to fix - just disable CONFIG_KERNEL_DEBUG.
Comment 11 Matt Wilson 2001-04-03 18:49:24 EDT
please test with 2.4.2-0.1.40 or 2.4.2-0.1.49
Comment 12 Shane Painter 2001-04-12 17:04:52 EDT
This problem is now resolved on all platforms EXCEPT 6400/6450.

The 6450 reports:
"Cannot enable port 1 hub 1 - disabling port" when a USB Keyboard is plugged in
and
"USB Device not accepting new address ..." when USB mouse is plugged in
-----------------------
The 6400 reports:
"USB Device not accepting new address ..." when either a USB mouse or Keyboard 
is plugged in.

Attached are dmesg and mptable output files for your viewing pleasure.
Comment 13 Shane Painter 2001-04-12 17:08:32 EDT
Created attachment 15265 [details]
Dmesg Output from 6450
Comment 14 Shane Painter 2001-04-12 17:09:09 EDT
Created attachment 15266 [details]
Mptable Output from 6450
Comment 15 Pete Zaitcev 2001-04-16 17:17:20 EDT
It is the same story as usual on the 6450 - interrupts
are not delivered. The output of /proc/interrupts
is hidden inside the attachement "6450_mptable.txt".
It's "noapic" time for that machine (unless 7.1 release
cures it, which I doubt).
Comment 16 Pete Zaitcev 2001-05-18 22:24:01 EDT
First, I found 6450 and tested it with noapic, it works.

Next, I handparsed mptable, it seems that kernel got it right.
This pretty much makes it a firmware bug.

Now, I am waiting for someone in Dell to tell me what
APIC pin does the USB use on that machine. MPtable
indicates #15 on the second APIC.
Comment 17 Pete Zaitcev 2001-06-11 14:05:41 EDT
Testing X40 (NAPA.EXE).

N.B. 2450 does have USB routed through IO-APIC,
yet 6450 does not, apparently. And I thought those
were the same family designs. Strange...
Comment 18 Pete Zaitcev 2001-07-10 14:47:14 EDT
Matt, any news with new BIOS?
Comment 19 Matt Domsch 2001-07-23 12:08:48 EDT
Dell PowerEdge 6400 BIOS A09 might have the fix (need to verify), but has a 
different bug with the e820 memory map which causes the -enterprise kernel to 
fail to load an initrd properly.  Dell's BIOS team is addressing the e820 map 
problem, and if the USB problem isn't also solved, they'll look at that too.
Comment 20 Clay Cooper 2001-07-23 14:40:10 EDT
USB still does not work on a 6400 w/ bios A09 using SMP kernel.  Here's
/var/log/messages output.  Looks pretty familiar.

Jul 23 10:09:35 localhost kernel: hub.c: USB new device connect on bus1/1,
assigned device number 2
Jul 23 10:09:39 localhost kernel: usb_control/bulk_msg: timeout
Jul 23 10:09:39 localhost kernel: usb-ohci.c: unlink URB timeout
Jul 23 10:09:39 localhost kernel: usb.c: USB device not accepting new address=2
(error=-110)
Jul 23 10:09:39 localhost kernel: hub.c: USB new device connect on bus1/1,
assigned device number 3
Jul 23 10:09:43 localhost kernel: usb_control/bulk_msg: timeout
Jul 23 10:09:43 localhost kernel: usb-ohci.c: unlink URB timeout
Jul 23 10:09:43 localhost kernel: usb.c: USB device not accepting new address=3
(error=-110)
Jul 23 10:10:00 localhost kernel: hub.c: USB new device connect on bus1/2,
assigned device number 4
Jul 23 10:10:04 localhost kernel: usb_control/bulk_msg: timeout
Jul 23 10:10:04 localhost kernel: usb-ohci.c: unlink URB timeout
Jul 23 10:10:04 localhost kernel: usb.c: USB device not accepting new address=4
(error=-110)
Jul 23 10:10:04 localhost kernel: hub.c: USB new device connect on bus1/2,
assigned device number 5
Jul 23 10:10:08 localhost kernel: usb_control/bulk_msg: timeout
Jul 23 10:10:08 localhost kernel: usb-ohci.c: unlink URB timeout
Jul 23 10:10:08 localhost kernel: usb.c: USB device not accepting new address=5
(error=-110)
Jul 23 10:10:26 localhost kernel: hub.c: USB new device connect on bus1/1,
assigned device number 6
Jul 23 10:10:30 localhost kernel: usb_control/bulk_msg: timeout
Jul 23 10:10:31 localhost kernel: usb-ohci.c: unlink URB timeout
Jul 23 10:10:31 localhost kernel: usb.c: USB device not accepting new address=6
(error=-110)
Jul 23 10:10:31 localhost kernel: hub.c: USB new device connect on bus1/1,
assigned device number 7
Jul 23 10:10:35 localhost kernel: usb_control/bulk_msg: timeout
Jul 23 10:10:35 localhost kernel: usb-ohci.c: unlink URB timeout
Jul 23 10:10:35 localhost kernel: usb.c: USB device not accepting new address=7
(error=-110)
Jul 23 10:11:57 localhost kernel: hub.c: Cannot enable port 1 of hub 1,
disabling port.
Jul 23 10:11:57 localhost kernel: hub.c: Maybe the USB cable is bad?
Jul 23 10:11:58 localhost kernel: hub.c: Cannot enable port 1 of hub 1,
disabling port.
Jul 23 10:11:58 localhost kernel: hub.c: Maybe the USB cable is bad?
Jul 23 10:11:59 localhost kernel: hub.c: Cannot enable port 1 of hub 1,
disabling port.
Jul 23 10:11:59 localhost kernel: hub.c: Maybe the USB cable is bad?
Jul 23 10:12:01 localhost kernel: hub.c: Cannot enable port 1 of hub 1,
disabling port.
Jul 23 10:12:01 localhost kernel: hub.c: Maybe the USB cable is bad?
Jul 23 10:12:03 localhost kernel: hub.c: Cannot enable port 1 of hub 1,
disabling port.
Jul 23 10:12:03 localhost kernel: hub.c: Maybe the USB cable is bad?
Jul 23 10:12:04 localhost kernel: hub.c: Cannot enable port 1 of hub 1,
disabling port.
Jul 23 10:12:04 localhost kernel: hub.c: Maybe the USB cable is bad?
Jul 23 10:12:06 localhost kernel: hub.c: Cannot enable port 1 of hub 1,
disabling port.
Jul 23 10:12:06 localhost kernel: hub.c: Maybe the USB cable is bad?
Comment 21 Pete Zaitcev 2001-07-23 17:49:37 EDT
Messages certainly would look familiar, they are
the same messages for _any_ problem with transfers.

To show what problem you are seeing, run mptable
and the "cat /proc/interrupts". Getting dmesg
output is useful too, if it does not overlow.
Comment 22 Matt Domsch 2001-07-24 18:46:49 EDT
Dell PE6400 test BIOS T42 solves this problem.  It will eventually become an 
internal X-rev, then a public A-rev.

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