Date: Mon, 27 Feb 2012 12:03:21 -0700 From: Scott Long <scottl@samsco.org> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: revisiting tunables under Safe Mode menu option Message-ID: <65B1891F-9079-4948-BF37-8A50B4E85071@samsco.org> In-Reply-To: <4F4B5ED3.5090508@FreeBSD.org> References: <4F26CC5A.2070501@FreeBSD.org> <4F4B5ED3.5090508@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 27, 2012, at 3:45 AM, Andriy Gapon wrote: > on 30/01/2012 18:59 Andriy Gapon said the following: >>=20 >> First, I think that this proposal/discussion could have been more = useful before >> the 9.0. Maybe the RE would be interested in adding another item to = their >> pre-release checklist: ask developers about what could be dropped and = what should >> be added to the Safe Mode settings in a new (.0) release. Probably = the developers >> should keep the Safe Mode in mind too when adding new features or = making other >> drastic changes, but the reminder should be welcome. > [snip] >> o Since we have a separate ACPI option and because ACPI now is almost = a mandatory >> thing (and not a significant source of boot troubles), maybe we could = remove the >> code that automatically disables ACPI in Safe Mode? >>=20 >> o hint.apic.0.disabled - APIC code doesn't seem to be a significant = source of boot >> troubles, like ACPI it has become almost a mandatory thing. So maybe = we should >> remove this setting? 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. If there's a better way to disable SMP that doesn't get = into problems with interrupt delivery, then please propose it. 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. > [dropped proposals snipped] >> o hw.eisa_slot - Looks like something from ancient times. Probably = just >> irrelevant for most systems. >>=20 This turns off probes in the ISA ioport space that used to cause = problems. Why get rid of it? Is its presence causing you problems? >> 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 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? >> 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 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. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?65B1891F-9079-4948-BF37-8A50B4E85071>