Date: Thu, 26 Jan 2012 10:19:30 +0300 From: Sergey Kandaurov <pluknet@freebsd.org> To: Andriy Gapon <avg@freebsd.org> Cc: svn-src-head@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r230545 - head/sys/boot/forth Message-ID: <CAE-mSOJG23JSJRUvm-e2oYwwdsWtWhbiA1pNcFC1PQpY16Znrw@mail.gmail.com> In-Reply-To: <4F205673.30907@FreeBSD.org> References: <201201251836.q0PIa1sl037892@svn.freebsd.org> <4F205673.30907@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 25 January 2012 23:22, Andriy Gapon <avg@freebsd.org> wrote: > on 25/01/2012 20:36 Sergey Kandaurov said the following: >> Author: pluknet >> Date: Wed Jan 25 18:36:01 2012 >> New Revision: 230545 >> URL: http://svn.freebsd.org/changeset/base/230545 >> >> Log: >> =A0 Clarify and improve the boot menu with some small changes: >> =A0 - Enter instead of ENTER >> =A0 - Remove colons >> =A0 - Line up option values >> =A0 - Use dots to provide a line to visually connect the menu >> =A0 =A0 selections with their values >> =A0 - Replace Enabled/Disabled with off/On >> =A0 =A0 (bigger inital cap for "On" is a visual indicator) >> =A0 - Remove confusing "Boot" from selections that don't boot. >> =A0 - With loader_color=3D1 in /boot/loader.conf, use reverse video to >> =A0 =A0 highlight enabled options >> >> =A0 PR: =A0 =A0 =A0 =A0 misc/160818 >> =A0 Submitted by: =A0 =A0 =A0 Warren Block <wblock wonkity com> >> =A0 Reviewed by: =A0 =A0 =A0 =A0Devin Teske <devin dot teske fisglobal c= om>, current@ >> =A0 MFC after: =A01 week > > Sorry for hi-jacking this commit notification... > > I have this crazy idea that we should remove the 'Safe Boot' and "ACPI' o= ptions > from the default boot menu (on platforms where they are present). Sounds reasonable and not so crazy. I cannot recall any systems which would boot successfully with ACPI disabled. ACPI toggle while being present in boot menu might confuse many more people than help the rest those people with working ACPI-less h/w configuration. Even my 5-years old Intel-based system ends up with general protection fault on legacy_attach(). More recen= t h/w has even less chances to boot without ACPI support (especially SMP h/w, as such hw is often supplied with broken/incomplete MPtable). I have had such idea to remove these two menu options since 7.x timeframe. FYI: em0: No MSI/MSIX using a Legacy IRQ em0: Unable to allocate bus resource: interrupt Fatal trap 9: general protection fault while in kernel mode db> bt Tracing pid 0 tid 100000 td 0xffffffff80a71eb0 rman_get_flags() at 0xffffffff80472560 =3D rman_get_flags em_free_pci_resources() at 0xffffffff8030fdff =3D em_free_pci_resources+0x7= f em_attach() at 0xffffffff803160eb =3D em_attach+0xcbb device_attach() at 0xffffffff80466e99 =3D device_attach+0x69 bus_generic_attach() at 0xffffffff80467f3a =3D bus_generic_attach+0x1a pci_attach() at 0xffffffff8035e633 =3D pci_attach+0xf3 device_attach() at 0xffffffff80466e99 =3D device_attach+0x69 bus_generic_attach() at 0xffffffff80467f3a =3D bus_generic_attach+0x1a device_attach() at 0xffffffff80466e99 =3D device_attach+0x69 bus_generic_attach() at 0xffffffff80467f3a =3D bus_generic_attach+0x1a pci_attach() at 0xffffffff8035e633 =3D pci_attach+0xf3 device_attach() at 0xffffffff80466e99 =3D device_attach+0x69 bus_generic_attach() at 0xffffffff80467f3a =3D bus_generic_attach+0x1a device_attach() at 0xffffffff80466e99 =3D device_attach+0x69 bus_generic_attach() at 0xffffffff80467f3a =3D bus_generic_attach+0x1a pci_attach() at 0xffffffff8035e633 =3D pci_attach+0xf3 device_attach() at 0xffffffff80466e99 =3D device_attach+0x69 bus_generic_attach() at 0xffffffff80467f3a =3D bus_generic_attach+0x1a device_attach() at 0xffffffff80466e99 =3D device_attach+0x69 bus_generic_attach() at 0xffffffff80467f3a =3D bus_generic_attach+0x1a pci_attach() at 0xffffffff8035e633 =3D pci_attach+0xf3 device_attach() at 0xffffffff80466e99 =3D device_attach+0x69 bus_generic_attach() at 0xffffffff80467f3a =3D bus_generic_attach+0x1a legacy_pcib_attach() at 0xffffffff806e6a50 =3D legacy_pcib_attach+0x70 device_attach() at 0xffffffff80466e99 =3D device_attach+0x69 bus_generic_attach() at 0xffffffff80467f3a =3D bus_generic_attach+0x1a legacy_attach() at 0xffffffff8069b9c9 =3D legacy_attach+0x19 device_attach() at 0xffffffff80466e99 =3D device_attach+0x69 bus_generic_attach() at 0xffffffff80467f3a =3D bus_generic_attach+0x1a nexus_attach() at 0xffffffff806f0958 =3D nexus_attach+0x68 device_attach() at 0xffffffff80466e99 =3D device_attach+0x69 bus_generic_new_pass() at 0xffffffff80468146 =3D bus_generic_new_pass+0xd6 bus_set_pass() at 0xffffffff80465fda =3D bus_set_pass+0x7a configure() at 0xffffffff80694d8a =3D configure+0xa mi_startup() at 0xffffffff803e8257 =3D mi_startup+0x77 btext() at 0xffffffff8027665c =3D btext+0x2c > Rationale. > It seems that most users expect these options to provide a more robust bo= ot > while in fact on most modern machines they can result in an opposite thin= g. > Those who know what the options do and really need their functionality ca= n get > the desired effects via loader's command line. Agreed. > Besides, 'Safe Boot' seems to be already somewhat undermined by rc.d/kld. --=20 wbr, pluknet
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAE-mSOJG23JSJRUvm-e2oYwwdsWtWhbiA1pNcFC1PQpY16Znrw>