Date: Mon, 27 Feb 2012 16:00:07 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: Andriy Gapon <avg@FreeBSD.org> Cc: "<freebsd-current@FreeBSD.org>" <freebsd-current@FreeBSD.org> Subject: Re: revisiting tunables under Safe Mode menu option Message-ID: <292A7F25-54E1-4795-867F-7B3D3D031319@fisglobal.com> 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 2:45 AM, Andriy Gapon <avg@FreeBSD.org> 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 the= ir >> pre-release checklist: ask developers about what could be dropped and wh= at 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 re= move the >> code that automatically disables ACPI in Safe Mode? >>=20 >> o hint.apic.0.disabled - APIC code doesn't seem to be a significant sour= ce of boot >> troubles, like ACPI it has become almost a mandatory thing. So maybe we= should >> remove this setting? > [dropped proposals snipped] >> o hw.eisa_slot - Looks like something from ancient times. Probably just >> irrelevant for most systems. >>=20 >> o hint.kbdmux.0.disabled - I do not recall any recent problems with kbdm= ux. In >> fact disabling it may produce a surprising behavior for a user if there = are >> multiple keyboards actually attached. >>=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-bo= oting with >> other OSes. >>=20 >> o More? >>=20 >=20 > How does the following look? > diff --git a/sys/boot/forth/menu-commands.4th b/sys/boot/forth/menu-comma= nds.4th > index 828a148..41ba317 100644 > --- a/sys/boot/forth/menu-commands.4th > +++ b/sys/boot/forth/menu-commands.4th > @@ -62,30 +62,19 @@ marker task-menu-commands.4th > -rot 2dup 12 + c! rot \ replace 'N' with ASCII numeral >=20 > evaluate 0=3D if > - s" hint.apic.0.disabled" unsetenv > s" hw.ata.ata_dma" unsetenv > s" hw.ata.atapi_dma" unsetenv > s" hw.ata.wc" unsetenv > - s" hw.eisa_slots" unsetenv > - s" hint.kbdmux.0.disabled" unsetenv > + s" kern.eventtimer.periodic" unsetenv > + s" kern.geom.part.check_integrity" unsetenv > + s" debug.acpi.disabled" unsetenv > else > - \ > - \ Toggle ACPI elements if necessary > - \ > - acpipresent? if acpienabled? if > - menuacpi @ dup 0<> if > - toggle_menuitem ( N -- N ) > - then > - drop > - acpi_disable > - then then > - > - s" set hint.apic.0.disabled=3D1" evaluate > s" set hw.ata.ata_dma=3D0" evaluate > s" set hw.ata.atapi_dma=3D0" evaluate > s" set hw.ata.wc=3D0" evaluate > - s" set hw.eisa_slots=3D0" evaluate > - s" set hint.kbdmux.0.disabled=3D1" evaluate > + s" set kern.eventtimer.periodic=3D1" unsetenv > + s" set kern.geom.part.check_integrity=3D0" unsetenv > + s" set debug.acpi.disabled=3Dhostres" unsetenv > then >=20 > menu-redraw >=20 >=20 The reasoning is sound and diff looks good. +1 BUT... testing warranted and feedback from others should also be sought-= after for consensus. Good work. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?292A7F25-54E1-4795-867F-7B3D3D031319>