Re: revisiting tunables under Safe Mode menu option

On Feb 27, 2012, at 3:38 PM, Andriy Gapon wrote:
>> 
>> 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.
> 
> I think that this is a good idea.
> 
>> If there's a better way to disable SMP that doesn't get into problems
>> with interrupt delivery, then please propose it.
> 
> I think that kern.smp.disabled should be it.
> 

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.
>> 
>>> [dropped proposals snipped]
>>>> o hw.eisa_slot - Looks like something from ancient times.  Probably just 
>>>> irrelevant for most systems.
>>>> 
>> 
>> This turns off probes in the ISA ioport space that used to cause problems.
>> Why get rid of it?
> 
> 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.
> 

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?
> 
> No, no problems (maybe because I never had device eisa in my kernels).
> 
>>>> 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.
>>>> 
>> 
>> 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?
> 
> Having two keyboards and one of them not working because it is not an active one.
> 
>>>> Just so that the Safe Mode doesn't turn into a NOP I propose to add the
>>>> following tunables:
>>>> 
>>>> o kern.eventtimer.periodic=1 - Use periodic timer to drive clocks just in
>>>> case a system has any problems with the default mode.  Example: PR
>>>> 164457.
>>>> 
>>>> o kern.geom.part.check_integrity=0 - Let GPART code be more permissive,
>>>> could be useful during upgrades from earlier versions of FreeBSD or when
>>>> multi-booting with other OSes.
>>>> 
>>>> o More?
>>>> 
>> 
>> 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.
> 
> I completely agree with this suggestion (always did), but unfortunately my forth
> and menu.rc skills are weak and my FreeBSD time is short.
> 

> 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