From owner-freebsd-smp@FreeBSD.ORG Wed Aug 31 19:57:51 2005 Return-Path: X-Original-To: freebsd-smp@freebsd.org Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E8B616A41F for ; Wed, 31 Aug 2005 19:57:51 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5678D43D46 for ; Wed, 31 Aug 2005 19:57:45 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[10.50.40.201]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Wed, 31 Aug 2005 16:12:51 -0400 From: John Baldwin To: "M. Warner Losh" Date: Wed, 31 Aug 2005 15:56:18 -0400 User-Agent: KMail/1.8 References: <200508301422.46354.jhb@FreeBSD.org> <200508301623.57973.jhb@FreeBSD.org> <20050830.150750.91757991.imp@bsdimp.com> In-Reply-To: <20050830.150750.91757991.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508311556.19878.jhb@FreeBSD.org> Cc: freebsd-smp@freebsd.org, markir@paradise.net.nz Subject: Re: 6.0 BETA3 reboot hangs on SMP system if BIOS USB disabled X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 19:57:51 -0000 On Tuesday 30 August 2005 05:07 pm, M. Warner Losh wrote: > In message: <200508301623.57973.jhb@FreeBSD.org> > > John Baldwin writes: > : On Tuesday 30 August 2005 02:59 pm, M. Warner Losh wrote: > : > In message: <200508301422.46354.jhb@FreeBSD.org> > : > > : > John Baldwin 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). Yes, that's ok. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org