6.0 BETA3 reboot hangs on SMP system if BIOS USB disabled

John Baldwin jhb at FreeBSD.org
Mon Aug 29 15:56:40 GMT 2005


On Sunday 28 August 2005 04:59 am, Mark Kirkwood wrote:
> Sorry - I attached the wrong dmesg (same machine, but running 5.4 doh!)
>
> FWIW here are two dmesg, one with usb disabled (from 3 Aug, so is still
> BETA2) and one with usb enabled (from 24 Aug).
>
> Mark Kirkwood wrote:
> > I had previously posted something very similar to -current with BETA2,
> > but received no replies. Also the SMP factor might make this more
> > appropriate here :-)
> >
> > Tyan S2510 dual PIII 6.0-BETA3 (dmesg attached for case with USB
> > disabled):

Ok, your BIOS is being a PITA. :)  First off, can you try setting 
'hw.pci.enable_io_modes=0' from the loader and seeing if that fixes the 
problem?

When USB is disabled, your BIOS writes 0xffffffff to its BAR instead of 0x0 
which conflicts with where the BIOS is mapped so that when the box reboots it 
tries to execute the USB controller's registers instead of the BIOS code to 
reboot, hence the hang. :)  Note the ohci0 lines from the dmesg's:

dmesg.nousb:

ohci0: <OHCI (generic) USB controller> mem 0xfffff000-0xffffffff at device 
15.2 on pci0
pcib0: unable to route slot 15 INTA
ohci0: Could not allocate irq
device_attach: ohci0 attach returned 6

dmesg.usb:

ohci0: <OHCI (generic) USB controller> mem 0xfeafc000-0xfeafcfff irq 10 at 
device 15.2 on pci0
ohci0: [GIANT-LOCKED]
usb0: OHCI version 1.0, legacy support
usb0: <OHCI (generic) USB controller> on ohci0
usb0: USB revision 1.0

I think the real fix is that we should treat BARs whose value is identical to 
what it would be if tbe value 0xffffffff is written to it as invalid just as 
we treat BARs with a value of 0 as invalid.  Warner (cc'd) might be able to 
come up with a patch for that faster than I could.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org


More information about the freebsd-smp mailing list