6.0 BETA3 reboot hangs on SMP system if BIOS USB disabled

M. Warner Losh imp at bsdimp.com
Tue Aug 30 21:09:10 GMT 2005


In message: <200508301623.57973.jhb at FreeBSD.org>
            John Baldwin <jhb at freebsd.org> writes:
: On Tuesday 30 August 2005 02:59 pm, M. Warner Losh wrote:
: > In message: <200508301422.46354.jhb at FreeBSD.org>
: >
: >             John Baldwin <jhb at FreeBSD.org> writes:
: > : On Monday 29 August 2005 08:51 pm, Mark Kirkwood wrote:
: > : > John Baldwin wrote:
: > : > > 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?
: > : >
: > : > Sure does, thanks for looking at this!
: > :
: > : Ok, don't go away. :)  Warner or I can work on a patch to fix this then
: > : that won't require you to set that tunable.
: >
: > I think that might be very hard to do that.
: >
: > While some (bogus) BIOSes set the maps to be all f's for devices they
: > have disabled, many devices default to this value on power up.  Since
: > we have to perform lazy resource assignment for these devices, it may
: > be difficult to differentiate between the unassigned case and the
: > disabled case.  Is there something I'm missing as to how we can tell
: > the difference between these two cases?
: 
: That should be identical cases.  The problem currently is that we think that 
: 0xffffffff is valid and we turn on the MEMEN bit in the PCI command register, 
: so when the box goes to reboot it tries to execute the BIOS code that is 
: normally mapped at 0xffff0000 and ends up executing what that BAR maps 
: instead, hence his hang.  Basically, I think we should treat 0xffffffff just 
: like we treat 0x0.

We can treat 0xfffffxxxx the same as we treat '0' fairly easily enough
in pci_add_map.  However, this is different than treating the device
as being disabled.  What will likely happen is that we'll allocate
fresh resources for the device, in effect re-enabling it.  If that's
OK, then I'd agree that the fix is a one liner (well, more with
comment updates).

Warner


More information about the freebsd-smp mailing list