On Feb 27, 2012, at 3:45 AM, Andriy Gapon wrote: > on 30/01/2012 18:59 Andriy Gapon said the following: >> >> 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? >> >> 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. >> 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. >> 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: >> >> 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. Scott _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
