On 12/6/06, Scott, Brian <[EMAIL PROTECTED]> wrote:
Hi,I don't know if this is a bug, stupid hardware or my failure to grasp something important. I'm trying to set up a system image for a classroom using openbsd 4.0. The machines in use (hp d530c) are happily able to run all flavours of windows, FreeBSD, and various flavours of linux (with varying degrees of success, not related to this problem). The systems have usb keyboards and mice. I can install OpenBSD without any problems. The keyboard is running in the legacy bios mode so everything works fine. When I boot the installed system it hangs while polling USB devices: OpenBSD 4.0 (GENERIC) #1107: Sat Sep 16 19:15:58 MDT 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Pentium(R) 4 CPU 2.80GHz ("GenuineIntel" 686-class) 2.80 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID real mem = 1064857600 (1039900K) avail mem = 963342336 (940764K) using 4256 buffers containing 53346304 bytes (52096K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(2e) BIOS, date 07/10/03, BIOS32 rev. 0 @ 0xeb4e0, SMBIOS rev. 2.3 @ 0xf8dd4 (59 entries) bios0: Hewlett-Packard HP d530 CMT(DC577AV) pcibios0 at bios0: rev 2.2 @ 0xeb4e0/0x4b20 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfe520/192 (10 entries) pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82801EB/ER LPC" rev 0x00) pcibios0: PCI bus #5 is the last bus bios0: ROM list: 0xc0000/0xa600 0xca600/0x2000 0xcc600/0x1800 0xe0c00/0x9a00! cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 "Intel 82865G/PE/P CPU-I/0-1" rev 0x02 vga1 at pci0 dev 2 function 0 "Intel 82865G Video" rev 0x02: aperture at 0xf0000000, size 0x8000000 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) uhci0 at pci0 dev 29 function 0 "Intel 82801EB/ER USB" rev 0x02: irq 10 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1 at pci0 dev 29 function 1 "Intel 82801EB/ER USB" rev 0x02: irq 11 usb1 at uhci1: USB revision 1.0 uhub1 at usb1 uhub1: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered If I disable uhci* (suggested in some emails I found searching for the problem) the system boots correctly and the keyboard works (in legacy mode but who cares). The mouse doesn't work and thus X is unusable. One email I found suggested unplugging the devices until the system booted then replugging them. This worked. The relevant part of the dmesg is: uhidev0 at uhub1 port 2 configuration 1 interface 0 uhidev0: CHICONY Compaq USB Keyboard, rev 1.10/1.05, addr 2, iclass 3/1 ukbd0 at uhidev0: 8 modifier keys, 6 key codes wskbd1 at ukbd0 mux 1 wskbd1: connecting to wsdisplay0 uhidev1 at uhub1 port 2 configuration 1 interface 1 uhidev1: CHICONY Compaq USB Keyboard, rev 1.10/1.05, addr 2, iclass 3/0 uhidev1: 2 report ids uhid0 at uhidev1 reportid 1: input=5, output=0, feature=0 uhid1 at uhidev1 reportid 2: input=5, output=0, feature=4 uhidev2 at uhub1 port 1 configuration 1 interface 0 uhidev2: Logitech Optical USB Mouse, rev 2.00/3.40, addr 3, iclass 3/1 ums0 at uhidev2: 3 buttons and Z dir. wsmouse0 at ums0 mux 0 So the problem seems to be device discovery early in the boot process. Finally, I tried moving the devices to other USB ports on the system. All of the ports on the rear of the system appear to be tied to uhub1 (which leaves me wondering what uhub0 and uhub2 are for - but that's not your problem). The front ports appear to be connected to an ehci controller: ehci0 at pci0 dev 29 function 7 "Intel 82801EB/ER USB2" rev 0x02: irq 10 usb3 at ehci0: USB revision 2.0 uhub3 at usb3 uhub3: Intel EHCI root hub, rev 2.00/1.00, addr 1 uhub3: 8 ports with 8 removable, self powered Everything works correctly if keyboard and mouse are plugged into these connectors. So my problems are: I would like to present my students with a functional X system so I need mouse support. A manual procedure (unplug connectors while booting) will create a very negative view of openBSD. I would prefer to not use it in the classroom than do that. It would also interfere with multi-booting systems or other bios changes that need the keyboard prior to operating system load. Moving connectors to the front would also be a problem. These conenctors are normally kept free for adhoc connection of devices by students, so a manual procedure would be needed. Are there ways for me to influence the behaviour of uchi (sysctls etc) or delay detection to later in the boot process?
I ran into this issue myself once when using a keyboard and mouse from GrandTec.com (although then, it was the keyboard that froze and the mouse was fine; not that I used the mouse, but it didn't freeze). I assumed it was a bug, a quirk of the interaction with the hardware, and pushed it out of my mind. You obviously can't do that. Probably it would work with a different model of mouse. Alternatively, do the machines have PS/2 ports? Could you use USB->PS2 adaptors? -Nick
