From owner-freebsd-smp@FreeBSD.ORG Tue Aug 30 20:35:15 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 C271316A468 for ; Tue, 30 Aug 2005 20:35:15 +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 4A02743D49 for ; Tue, 30 Aug 2005 20:35:15 +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 ; Tue, 30 Aug 2005 16:50:33 -0400 From: John Baldwin To: "M. Warner Losh" Date: Tue, 30 Aug 2005 16:23:57 -0400 User-Agent: KMail/1.8 References: <200508291157.26619.jhb@FreeBSD.org> <200508301422.46354.jhb@FreeBSD.org> <20050830.125925.124085095.imp@bsdimp.com> In-Reply-To: <20050830.125925.124085095.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508301623.57973.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: Tue, 30 Aug 2005 20:35:15 -0000 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. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org