From owner-freebsd-current@FreeBSD.ORG Tue Feb 28 06:23:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88D43106567B; Tue, 28 Feb 2012 06:23:15 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 5D97C8FC12; Tue, 28 Feb 2012 06:23:15 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id q1S6NBR8022112; Mon, 27 Feb 2012 23:23:11 -0700 (MST) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Scott Long In-Reply-To: <4F4C0600.2000903@FreeBSD.org> Date: Mon, 27 Feb 2012 23:23:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3BA1B476-ED05-4E8E-8DFA-0B06EFB48867@samsco.org> References: <4F26CC5A.2070501@FreeBSD.org> <4F4B5ED3.5090508@FreeBSD.org> <65B1891F-9079-4948-BF37-8A50B4E85071@samsco.org> <4F4C0600.2000903@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1257) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: FreeBSD current , Devin Teske Subject: Re: revisiting tunables under Safe Mode menu option X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 06:23:15 -0000 On Feb 27, 2012, at 3:38 PM, Andriy Gapon wrote: >>=20 >> Turning off the APIC turns off SMP in a very efficient, clean manner. = I >> added this not to isolate the APIC code, but to turn off SMP. That's = why >> it's there, and I'd like the ability to turn off SMP to stay there in = some >> form. >=20 > I think that this is a good idea. >=20 >> If there's a better way to disable SMP that doesn't get into problems >> with interrupt delivery, then please propose it. >=20 > I think that kern.smp.disabled should be it. >=20 I recall this tunable being problematic, but I don't recall the reason. = Reading the code makes me think that it should be fine; maybe it's time = to switch this knob from hint.apic.0.disabled to kern.smp.disabled, as = you've done in your proposed patch. >> As for it being mandatory, >> it's really only mandatory for MSI these days, though it used to be = required >> for more complex PCIX topologies. >>=20 >>> [dropped proposals snipped] >>>> o hw.eisa_slot - Looks like something from ancient times. Probably = just=20 >>>> irrelevant for most systems. >>>>=20 >>=20 >> This turns off probes in the ISA ioport space that used to cause = problems. >> Why get rid of it? >=20 > Just cleaning up what looked like cruft... I don't believe I heard of = any > problem reports like that lately. But probably you are right and this = shouldn't > be removed until eisa is dropped from i386 GENERIC. Is it time = already? > OTOH, it seems that the eisa probe code should not get executed on a = non-legacy > system (ACPI present and enabled) unless it has an actual PCI-EISA = bridge. > So I am deferring this decision to you. Please let me know your = preference. >=20 As long as the 'eisa' device is in the GENERIC profile, this is a = low-cost safety measure. However, I don't really want to start an = argument about purging 'eisa' from the profile. Its death should come = swiftly and without warning. >> Is its presence causing you problems? >=20 > No, no problems (maybe because I never had device eisa in my kernels). >=20 >>>> o hint.kbdmux.0.disabled - I do not recall any recent problems with >>>> kbdmux. In fact disabling it may produce a surprising behavior for = a >>>> user if there are multiple keyboards actually attached. >>>>=20 >>=20 >> Fair enough, if we're all happy that the kbdmux code has progressed = beyond >> this being useful, then get rid of it. But what's the surprising = behavior? >=20 > Having two keyboards and one of them not working because it is not an = active one. >=20 >>>> Just so that the Safe Mode doesn't turn into a NOP I propose to add = the >>>> following tunables: >>>>=20 >>>> o kern.eventtimer.periodic=3D1 - Use periodic timer to drive clocks = just in >>>> case a system has any problems with the default mode. Example: PR >>>> 164457. >>>>=20 >>>> o kern.geom.part.check_integrity=3D0 - Let GPART code be more = permissive, >>>> could be useful during upgrades from earlier versions of FreeBSD or = when >>>> multi-booting with other OSes. >>>>=20 >>>> o More? >>>>=20 >>=20 >> I suggested before that maybe it's time to expand this "Safe Mode" = topic into >> a sub-menu that allows selection of some/all/none of the options. >=20 > I completely agree with this suggestion (always did), but = unfortunately my forth > and menu.rc skills are weak and my FreeBSD time is short. >=20 > Here is an updated patch (with the eisa_slots decision pending): I still think that it's useful to be able to disable ACPI. Just because = ACPI works well on modern hardware doesn't mean that everything crummy = from 2000-2007 suddenly disappeared off the face of the earth. But I = agree that turning it off on modern systems probably does more harm than = good. Hence my suggestion for a finer control over this in the menu. = Maybe Devin Teske can lend some help with this task? For extra credit, = it should be possible to write a simple static analysis tool that = collects all of the tunables that are compiled into the kernel and = generates a data file that the boot menu can process and turn into = interactive knobs for the user. Scott