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