cvs commit: src/sys/bus/usb usb.c

Michael Neumann mneumann at ntecs.de
Sun May 25 15:35:34 PDT 2008


Matthew Dillon wrote:
:mneumann    2008/05/25 09:53:41 PDT
:
:DragonFly src repository
:
:  Modified files:
:    sys/bus/usb          usb.c 
:  Log:
:  Defer boot-time exploration of USB busses until all devices in the
:  system have been attached, but no later. This ensures that we do
:  not explore ohci or uhci busses before the companion ehci controller
:  has been initialised, so it should fix the problem of multi-speed
:  USB devices getting attached as USB 1 devices first and then
:  re-attached as USB 2.
:  
:  This fixes issue #946 for qemu and my HP Compaq 6710b laptop.
:  
:  Obtained-from:  FreeBSD/usb.c 1.104 to 1.106 and NetBSD/usb.c 1.35
:  Dragonfly-bug:  <http://bugs.dragonflybsd.org/issue947>
:  
:  Revision  Changes    Path
:  1.44      +31 -10    src/sys/bus/usb/usb.c

    Make sure USB keyboards still work :-)  There was some code in there
    to probe for a USB keyboard very early in the boot sequence.  I forget
    where exactly.
Oh yes, my commit seems to revert usb.c rev 1.24 [1]. I should have read
this before. But I don't think rev 1.24 is very good, as it leads to
kernel panics :).
What exactly is cold boot? Is it what I think it is:

  cold boot = machine is powered on for the first time
  warm boot = just do a jump to the BIOS init routine
I wonder how FreeBSD has solved the problem, if at all, because I do not
see any further special code that would handle USB keyboards early at
boot.
I don't understand what exactly is the reason why cold boot is
distinguished from warm boot when configuring devices. Maybe they go
amock for warm boot because they are already configured?
[1]:
http://www.dragonflybsd.org/cvsweb/src/sys/bus/usb/usb.c.diff?r1=1.23&r2=1.24&f=h




More information about the Commits mailing list