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?
Thanks for any help,
Brian Scott
**********************************************************************
This message is intended for the addressee named and may contain
privileged information or confidential information or both. If you
are not the intended recipient please delete it and notify the sender.
**********************************************************************
