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