Date: Mon, 27 Feb 2012 23:23:11 -0700 From: Scott Long <scottl@samsco.org> To: Andriy Gapon <avg@freebsd.org> Cc: FreeBSD current <freebsd-current@freebsd.org>, Devin Teske <dteske@vicor.com> Subject: Re: revisiting tunables under Safe Mode menu option Message-ID: <3BA1B476-ED05-4E8E-8DFA-0B06EFB48867@samsco.org> In-Reply-To: <4F4C0600.2000903@FreeBSD.org> References: <4F26CC5A.2070501@FreeBSD.org> <4F4B5ED3.5090508@FreeBSD.org> <65B1891F-9079-4948-BF37-8A50B4E85071@samsco.org> <4F4C0600.2000903@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BA1B476-ED05-4E8E-8DFA-0B06EFB48867>