Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.4) Gecko/20030922 Description of problem: I use a Fujitsu Siemens CELSIUS MOBILE H Notebook with integrated Bluetouth Keybord. Wit the standard i686 kernel the Keybord not work. The kernel isn`t able to locate MAus and Keybord. If i modify the Kernelsouce like this: //usr/src/linux-2.4/drivers/usb/host vi usb-uhci.c //#define CONFIG_USB_UHCI_HIGH_BANDWIDTH the kernel locates the Keybord and mouse in this way: - class: MOUSE bus: USB detached: 0 device: input/mice driver: mousedev desc: "Silitek Corp. BlueTooth Keyboard and Mouse" usbclass: 3 usbsubclass: 1 usbprotocol: 2 usbbus: 3 usblevel: 1 usbport: 0 usbdev: 2 vendorId: 047b deviceId: 0101 usbmfr: CST usbprod: Blue Tooth Keyboard/Mouse -class: KEYBOARD bus: USB detached: 0 driver: keybdev desc: "Silitek Corp. BlueTooth Keyboard and Mouse" usbclass: 3 usbsubclass: 1 usbprotocol: 1 usbbus: 3 usblevel: 1 usbport: 0 usbdev: 2 vendorId: 047b deviceId: 0101 usbmfr: CST usbprod: Blue Tooth Keyboard/Mouse - This looks OK. But now USB Stick runns verry slow. It means I need 3 min for 3mb. What shout I do? mfg Thilo M�ller Version-Release number of selected component (if applicable): kernel-2.4.21-4.0.1.EL.i686.rpm How reproducible: Always Steps to Reproduce: 1.Use the original Kernel from RedHat 2. 3. Additional info:
Created attachment 97851 [details] celsiusH touchpad synchronisation The problem also concerns to the mouse pointer of the Celsius Mobile H Touchpad. When applying the patch to the usb-uhci.c the Touchpad will be found but when using gpm or X11 the mousepointer is not controllable. When running the following script times then the touchpad synchronizes correctly. <-------------bof--> #!/bin/sh modprobe -r hid sleep 1 moprobe hid sleep 1 modprobe -r hid sleep 1 moprobe hid sleep 1 <-------------eof--> // Thomas Baumann // tirili
A second way to sync the Touchpad is to power off/on the keyboard to resync the touchpad. Thilo Mueller
Created attachment 98032 [details] celsiusH patch /* *_DEPTH_FIRST puts descriptor in depth-first mode. This has * somehow similar effect to FSBR (higher speed), but does not * slow PCI down. OTOH USB performace is slightly slower than * in FSBR case and single device could hog whole USB, starving * other devices. */ /* Turning off both CONFIG_USB_UHCI_HIGH_BANDWITH and *_DEPTH_FIRST * will lead to <64KB/sec performance over USB for bulk transfers targeting * one device's endpoint. You probably do not want to do that. */ Hope this helps. // Thomas Baumann
Sorry, above patch was incomplete. you need the following lines as well: @@ -108,7 +108,7 @@ * in FSBR case and single device could hog whole USB, starving * other devices. */ -#define USE_CTRL_DEPTH_FIRST 0 // 0: Breadth first, 1: Depth first +#define USE_CTRL_DEPTH_FIRST 1 // 0: Breadth first, 1: Depth first #define USE_BULK_DEPTH_FIRST 0 // 0: Breadth first, 1: Depth first /* Turning off both CONFIG_USB_UHCI_HIGH_BANDWITH and *_DEPTH_FIRST
Comment on attachment 98032 [details] celsiusH patch diff -ur -X dontdiff linux-2.4.21-1.1931.2.391.ent/drivers/usb/host/usb-uhci.c linux-2.4.21-1.1931.2.391.u1/drivers/usb/host/usb-uhci.c --- linux-2.4.21-1.1931.2.391.ent/drivers/usb/host/usb-uhci.c 2003-08-12 17:17:10.000000000 -0700 +++ linux-2.4.21-1.1931.2.391.u1/drivers/usb/host/usb-uhci.c 2003-08-12 17:54:08.000000000 -0700 @@ -97,7 +97,7 @@ * is optimal, but PCI can be slowed down up-to 5 times, slowing down * system performance (eg. framebuffer devices). */ -#define CONFIG_USB_UHCI_HIGH_BANDWIDTH +// #define CONFIG_USB_UHCI_HIGH_BANDWIDTH /* *_DEPTH_FIRST puts descriptor in depth-first mode. This has * somehow similar effect to FSBR (higher speed), but does not @@ -97,7 +97,7 @@ * is optimal, but PCI can be slowed down up-to 5 times, slowing down * system performance (eg. framebuffer devices). */ -#define CONFIG_USB_UHCI_HIGH_BANDWIDTH +// #define CONFIG_USB_UHCI_HIGH_BANDWIDTH /* *_DEPTH_FIRST puts descriptor in depth-first mode. This has * somehow similar effect to FSBR (higher speed), but does not @@ -108,7 +108,7 @@ * in FSBR case and single device could hog whole USB, starving * other devices. */ -#define USE_CTRL_DEPTH_FIRST 0 // 0: Breadth first, 1: Depth first +#define USE_CTRL_DEPTH_FIRST 1 // 0: Breadth first, 1: Depth first #define USE_BULK_DEPTH_FIRST 0 // 0: Breadth first, 1: Depth first /* Turning off both CONFIG_USB_UHCI_HIGH_BANDWITH and *_DEPTH_FIRST
Hallo, Thomas it helps not realy. It looks faster, but if you sync the devices 3 MB needs 5 min. Thanks Thilo
If you install bluez-utils-2.7 and bluez-libs-2.7 from Rawhide and run 'hid2hci' does the USB HID device magically turn into a Bluetooth adapter? If so, I suspect that doing this and then using the BT HID support is the correct answer for 2.6.
Wholesale Depth-first is not an option. Many other configurations will break. It looks as if HID loses packets, which is possible, I guess. I could have scoped an implementation with some sort of better queuing, but I would need the hardware and a lot of time. This all looks rather hopeless...
Is this configuration available for testing? If not, what's the status? Does this work on RHEL 4?
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.