Re: revisiting tunables under Safe Mode menu option

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

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"