Hello All!

PROBLEM: USB keyboards works only 4 per PC host port.

I work for project which will use 15 - 25 keyboards for children teaching.
I discover current Linux 2.6.22 , 2.6.24, 2.6.26 dot not support more
than 4 keyboards per single PC host port. All plugged in keyboards
are listed as USB devices, listed as input devices, but capable to
send input events are only 4 keyboards, no matter where keyboards
are plugged in to HUB cascade. All plugged in keyboards switch LED's,
when i press NumLock.

I tested various usb-hub units and various host PC hardware, i even
replace hub power supplay units from 5V1A to 5V3A. All tested cases
give best results - 4 keyboards per PC host port and worstest - some PC
cannot do more than 8 keyboards at all.
I suppose this is Linux kernel bug because i test keyboards under
Windows, which support any schema of cascading of usb hubs.

I will send any log file if that is necessary, but trouble will pop up
in a row of kernels. 2.6.22 didn't have error messages. 2.6.24, 2.6.26
tend to total slow down with eternal reset messages:
Jul 25 07:16:00 awork kernel: input,hiddev97: USB HID v1.10 Mouse 
[USB-compliant keyboard] on usb-0000:00:1d.0-1.1.2
Jul 25 07:16:01 awork kernel: usb 2-1.1.1: reset low speed USB device using 
uhci_hcd and address 17
Jul 25 07:16:01 awork kernel: usb 2-1.1.2: reset low speed USB device using 
uhci_hcd and address 18
Jul 25 07:16:02 awork kernel: usb 2-1.1.1: reset low speed USB device using 
uhci_hcd and address 17


Best regards,
Aivils Stoss
--

[ message continues ]

On the very same machine and hubs?

Samuel
--

[ message continues ]

Yes, on same machine. Under Windows i don't have evdev interface,
checked only how keypress go to console.
Of course to repeat a try You must have at least 5 keyboards and
1 7-port or 2 4-port hubs and kernel 2.6.22 and above. I allways
got result - 5th, 6th, 7th keyboard does not send events to console


--

[ message continues ]

[adding linux-usb mailing list]

Hi,

I finally got 5 USB keyboards together along with 2 hubs.
I daisy-chained the hubs and connected 1 keyboard to the hub that is
on the notebook computer USB port, then I connected 4 keyboards to the
second hub.  They all worked for me, meaning that I can type on all of
them and have their characters show up on my console.

I'm testing with 2.6.7-rc2.
'usbtree' output of the USB subsystem is attached.


---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/
[ message continues ]

Yeah! 2.6.7 is a bit obsolete. At my end 2.6.15 support more than 4
keyboards per PC port , but mess up input when is plugged more than
9 keyboards. 10th is capable to send keypress events, but last pressed
key will be repeated until ctrl-c . 10th keyboard disturb an auto repeat of 
all keyboards.



--

[ message continues ]

Sorry, my keyboard made a typo.  I'm testing with 2.6.27-rc2.

So the problem is now different from your original report, right?


What speed is the host port that the keyboards are connected to?
Could it be a USB bus bandwidth limitation?  (not that any code
checks for that)

I barely found 5 USB keyboards, so I surely can't test 10 or more.  ;)
I suppose that it will take some USB debug messages to attempt to see
what is going on...


---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/
--

[ message continues ]

No problem is same. Older kernels have another troubles.
2.6.22-1-mepis-smp
Quite stable. Have oops sometime inside evdev. Support up to 16=20
USB keyboards, where 4 hubs are plugged into PC and 4 keyboards on
each hub. Any hub cascade support only 4 keyboards, where 5th or more
is registered but don't send input events. Oops inside evdev , when
USB keyboard unplugged. No slow down even all USB keyboards does
not work properly. My be this one support more than 16 keyboards, but
i don't have PC USB ports enough.

2.6.24-7
4 keyboards per port. If plug in 5th tend to total slow down with this one:
usb 2-1.1.1: reset low speed USB device using=20
uhci_hcd and address 17
5th - means 5th keyboard in USB hub's cascade, which is plugged into
single PC USB port.

2.6.26
4 keyboards per port. If plug in 5th tend to total slow down.

2.6.27-rc3
Sorry Randy i cannot repeat Your achievement. This worse of all tested
kernels. I got working 3 USB keyboards, when i plug in 4th, all keyboards,
include PS/2 stop working. Kernel does not hung up. I can reach box
via net. dmesg , /proc/bus/input/devices attached. lsusb hung up.

Please notify me , if i should use 2.6.27-rc2 !



[ message continues ]

Have you tried looking in your system log for error messages indicating 
the source of the problem?

uhci_hcd 0000:00:1d.1: bandwidth allocation failed: period 8, phase 4, 826 + 118 us
input: USB HID v1.10 Device [CHESEN USB Keyboard] on usb-0000:00:1d.1-2.2.4
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
uhci_hcd 0000:00:1d.1: bandwidth allocation failed: period 8, phase 4, 826 + 118 us
uhci_hcd 0000:00:1d.1: bandwidth allocation failed: period 8, phase 4, 826 + 118 us
uhci_hcd 0000:00:1d.1: bandwidth allocation failed: period 8, phase 4, 826 + 118 us
uhci_hcd 0000:00:1d.1: bandwidth allocation failed: period 8, phase 4, 826 + 118 us
uhci_hcd 0000:00:1d.1: bandwidth allocation failed: period 8, phase 4, 826 + 118 us
uhci_hcd 0000:00:1d.1: bandwidth allocation failed: period 8, phase 4, 826 + 118 us
uhci_hcd 0000:00:1d.1: bandwidth allocation failed: period 8, phase 4, 826 + 118 us
uhci_hcd 0000:00:1d.1: bandwidth allocation failed: period 8, phase 4, 826 + 118 us

Those messages seem pretty clear.  Each keyboard requires two interrupt 
transfers occupying 118 us of bandwidth apiece.  That's 236 us per 
keyboard.

Since there is only 900 us total available for interrupt transfers in
any frame, and since uhci-hcd isn't smart enough to allocate different
interrupt endpoints to different frames, you run out of bandwidth after
four keyboards.

Now if you plugged some of these keyboards into different UHCI 
controllers on the computer, then the problem wouldn't arise.  Each of 
your four UHCI controllers has two ports.  So without using any hubs at 
all, you can plug 8 keyboards into the computer and they will all work.

If you use some extra hubs as well then you can plug four keyboards 
into each controller, allowing you to use 16 keyboards total.

Alan Stern

--

[ message continues ]

Has the evdev oops been reported and/or fixed?

Please try to include full dmesg (kernel boot log) in the future.

It doesn't seem preferable for you yet.

Looks like it could be a problem just to put N low-speed devices on one root hub/port:

uhci_hcd 0000:00:1d.1: bandwidth allocation failed: period 8, phase 4, 826 + 118 us
uhci_hcd 0000:00:1d.1: bandwidth allocation failed: period 8, phase 4, 826 + 118 us
uhci_hcd 0000:00:1d.1: bandwidth allocation failed: period 8, phase 4, 826 + 118 us
etc etc.



---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/
--

[ message continues ]

We haven't seen the respective oops yet, or have I missed it?

I'd bet it is fixed in newer kernels by patches that introduce proper 
locking into evdev code.

-- 
Jiri Kosina
SUSE Labs
--

[ message continues ]

If evdev (or any other part of the input sybsystem) still oopses in
2.6.26 and 2.6.27 I would like to see that oops very much.

-- 
Dmitry
--

[ message continues ]

I don't know exists this one in the 2.6.26 and above :o(

Aivils Stoss

# cat /proc/version
Linux version 2.6.22-1-mepis-smp (root@mepis-pro) (gcc version 4.1.2 20061115 
(prerelease) (Debian 4.1.1-21)) #1 SMP PREEMPT Sun Dec 2 19:15:40 EST 2007

# dmesg
input: CHESEN USB Keyboard as /class/input/input41
input: USB HID v1.10 Device [CHESEN USB Keyboard] on usb-0000:00:1d.3-2.4.4
hub 5-0:1.0: port 2 disabled by hub (EMI?), re-enabling...
usb 5-2: USB disconnect, address 8
usb 5-2.1: USB disconnect, address 14
usb 5-2.1.2: USB disconnect, address 23
BUG: unable to handle kernel paging request at virtual address 00100100
 printing eip:
f8832664
*pde = 00000000
Oops: 0000 [#1]
PREEMPT SMP
Modules linked in: i915 drm evdev binfmt_misc cpufreq_ondemand 
cpufreq_userspace cpufreq_powersave acpi_cpufreq speedstep_lib freq_table 
rfcomm hidp l2cap bluetooth ppdev lp thermal fan button processor ac battery 
ipv6 snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul 
snd_emu10k1 snd_util_mem snd_hwdep piix ide_core fuse ndiswrapper dm_crypt 
dm_snapshot dm_mirror dm_mod usbhid hid sworks_agp amd_k7_agp ali_agp sis_agp 
ati_agp nvidia_agp via_agp wlan_scan_sta ath_rate_sample snd_emu10k1x 
snd_seq_dummy snd_seq_oss snd_seq_midi snd_seq_midi_event snd_seq snd_rawmidi 
snd_seq_device snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd 
soundcore intel_agp agpgart ac97_bus i2c_i801 i2c_core snd_page_alloc 
parport_pc parport floppy ath_pci wlan ath_hal(P) serio_raw psmouse uhci_hcd 
atl2 pcspkr
CPU:    0
EIP:    0060:[<f8832664>]    Tainted: P       VLI
EFLAGS: 00010206   (2.6.22-1-mepis-smp #1)
EIP is at evdev_disconnect+0x73/0xb1 [evdev]
eax: 00000000   ebx: 000ffcf0   ecx: f73d5540   edx: 01329000
esi: f6c31340   edi: cf00c000   ebp: d2a56800   esp: c1a59e48
ds: 007b   es: 007b   fs: 00d8  gs: 0000  ss: 0068
Process khubd (pid: 168, ti=c1a58000 task=c1aaf030 task.ti=c1a58000)
Stack: c368c800 c368c800 c368cecc c0321be7 00000000 c048f02c c18de420 d2a56800
 ...
[ message continues ]

Could you please verify with any more recent kernel than 2.6.15 and report 
back whether the issue is still present, please?

Also, is this bug specific to USB keyboards? i.e. if you for example plug 
in USB flash sticks instead of keyboards, do they all work correctly?

Thanks,

-- 
Jiri Kosina
SUSE Labs
--

[ message continues ]