From owner-freebsd-mobile@freebsd.org Wed Mar 2 01:29:18 2016 Return-Path: Delivered-To: freebsd-mobile@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7613AC0242; Wed, 2 Mar 2016 01:29:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A53D819CB; Wed, 2 Mar 2016 01:29:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A415DB990; Tue, 1 Mar 2016 20:29:17 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Cc: Warner Losh , Marcel Moolenaar , "Lundberg, Johannes" , "freebsd-embedded@freebsd.org" , "freebsd-mobile@freebsd.org" Subject: Re: hint.uart.1 in device.hints causes freeze at boot Date: Tue, 01 Mar 2016 17:19:34 -0800 Message-ID: <21207070.KlEgumgKTW@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <4E9118B0-FC9F-444F-B277-3E5BAE75C723@xcllnt.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 01 Mar 2016 20:29:17 -0500 (EST) X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 01:29:18 -0000 On Friday, February 26, 2016 11:08:37 PM Warner Losh wrote: > On Fri, Feb 26, 2016 at 6:49 PM, Marcel Moolenaar wrote: > > Any reason not to add .disabled=1 to all the entries that are there, > with the possible exception of uart.0? At least for i386 and amd64? > Bonus points for writing code that filters those out when there's > no ACPI. While PNPBIOS could also supply this info, I doubt that you > could find hardware that has pnpbios data and not ACPI data except > maybe some of the soekris boxes to test against. > > Better still would be to split the current GENERIC.hints into two bits. > One that was strictly for legacy (!ACPI and !PNPBIOS) situations, and > one that we always load. There look to be at least a couple of hints > that are universally relevant still. I might have a 200MHz pentium I > can test this with... If there was an easy way to load a new hints file we could ship a /boot/legacy.hints and have a note in the handbook / FAQ about using it if needed. We could even have smarts in the loader to suck it in perhaps if !ACPI and !PnPBIOS. > As near as I can tell, only the following are relevant: > hint.fd.0.at="fdc0" > hint.fd.0.drive="0" > hint.fd.1.at="fdc0" > hint.fd.1.drive="1" > hint.acpi_throttle.0.disabled="1" > hint.p4tcc.0.disabled="1" hint.sc.0.at is relevant if you want to use sc(4) instead of vt(4). For a long time I've booted machines that only had that hint. The npx.0 hint used to matter (but no longer does). I think we should definitely trim the hints file for amd64. amd64 pretty much mandates ACPI. For i386 I would be fine with a the legacy.hints route even if it wasn't automagical but something you had to manually load. The only thing about the hints that is still somewhat useful on x86 is enabling serial console (though boot -h and/or console=comconsole already does that) and enabling remote GDB. (hint.uart.1.flags=0x80 is shorter and doesn't require remembering random I/O port addresses like the hw.uart route for GDB.) -- John Baldwin