Re: revisiting tunables under Safe Mode menu option
Found this old mail between avg@ and myself and just had to laugh The boot loader is so much more levels of awesome now, but I had forgotten how much thought I had put into it. Awesome sauce! ;D -- Cheers, Devin > On Mar 1, 2012, at 9:06 AM, Andriy Gapon <a...@freebsd.org> wrote: > > on 01/03/2012 18:52 Devin Teske said the following: >> >> >>> -Original Message- >>> From: Andriy Gapon [mailto:a...@freebsd.org] >>> Sent: Thursday, March 01, 2012 12:39 AM >>> To: Devin Teske >>> Cc: John Baldwin; freebsd-current@FreeBSD.org; Scott Long; Devin Teske >>> Subject: Re: revisiting tunables under Safe Mode menu option >>> >>> on 01/03/2012 03:34 Devin Teske said the following: >>>> >>>> +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe >>>> Mode knows about ACPI but only acts on it when being enabled). >>> >>> Can you explain why? >>> +1 for having both menu items and each doing its own thing without any >>> entanglement :-) >>> >> >> First, I realize that this may sound entirely *dumb*, but here-goes: >> >> In transitioning from an old release (sans-menu; 4.11 for example) to a newer >> release (with menu; 6.x for example), one of the first thing that is noticed >> is >> "Safe Mode". >> >> I know that when I first saw this, I scratched my head and wondered what it >> did >> and what it might be useful for. To this day, I still have never used it. >> >> When I created the new menu for 9.x/higher, I had to rewrite that portion of >> the >> code and eventually learned what Safe Mode does when used. Still can't say >> that >> I've ever used it, however, at the point that I saw that it disabled ACPI >> among >> other things, that it is more of a blanket option for anything and everything >> that might be useful if/when you're having problems (*cough* still can't say >> that I've ever used it, as when I have problems I'm usually slogging through >> the >> kernel code, not relying on safe mode to fix some problem). >> >> That being said, I felt that it was a huge improvement to the UI to have the >> Safe Mode option divulge a little bit of its secret by visibly diddling the >> ACPI >> menu item (giving a clue to people that *haven't* read the code that this >> option >> is indeed not independent but instead conglomerate in-nature). >> >> Indeed, I've watched field engineers when exploring the menu options and >> their >> eyes light-up when they see that "Safe Mode" toggles ACPI off when enabled. >> Extrapolating on their surprise, they appear to have an "Aha!"-moment as >> previously... this field engineer had no idea what on God's green Earth what >> "Safe Mode" did (or didn't) as he didn't know about "kenv" and certainly >> couldn't read "Forth". At that point, he may not have had a full >> understanding >> of all the options that Safe Mode diddled, but at that point he at least >> knew >> that Safe Mode is a multi-option that does many things -- which is more than >> 6.x, 7.x, or 8.x ever offered which simply boots immediately the Safe Mode >> option is selected and does nothing to explain what it is that Safe Mode is >> doing (which would in-turn properly calibrate the user's expectations). >> >> Making the menu items completely independent would be take away the (however >> slight) above value-add that was brought in by entwining these two >> menu-items. >> I'm not saying that this would be a grave travesty, but would in-fact be a >> value-loss. > > Devin, > > you did a great job with boot menu enhancement in general and in this area in > particular. You greatly improved usability while preserving the historic > behavior > and put a lot of work and creativity into that. Thank you! > > But the argument is that the historic behavior is no longer useful. I see > that > removing the historic behavior also kills a little bit of your code (and a > little > bit of magic). That's true, that's a loss in the code. > > But I still believe that it would be an improvement from the point of view of > usability end-users. > > Having a whole sub-menu where multiple parameters could be tweaked > individually > would be even greater improvement. But that's not as easy to do. > > -- > Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: revisiting tunables under Safe Mode menu option
Devin Teske devin.teske at fisglobal.com writes: ... So I would welcome discussions involving development of something better (and am willing to help). ... Not exactly sure what service safemode start should do (BSD doesn't have the same concept of runlevels as Linux does; so it's not exactly intuitive to think we could go from multi-user mode *into* safe mode). But service safemode status would be interesting. Interestingly, it would perhaps be nice if service safemode stop brought the system back to fully usable without need for reboot (something Windows doesn't offer). I looked around the Internet and collected some sound bites: - Safe Mode - it forces a check of startup (root) partition. - you have access to only minimal number of basic files and drivers (mouse, monitor, keyboard, mass storage, base video, fonts, default system services, and no network connections). If your computer does not start successfully using Safe Mode, you might need to use the Safe Mode with Root Shell feature to repair your system. - it disables all startup items and login items - it has to delete (and eventually recreate) any shared caches (dynamic loader, dynamic libraries, etc) - it enables boot logging The boot log is useful in determining the exact cause of system startup problems. Log all drivers and services that were loaded (or not loaded) by the system to a file. - what about remote fs (NFS, etc) ? - it helps you diagnose problems. If a symptom does not reappear when you start in safe mode, you can eliminate the default settings and minimum device drivers as possible causes. If a newly added device or a changed driver is causing problems, you can use safe mode to remove the device or reverse the change. The same with newly installed packages. - enabled debugging mode It may be preconfigured for debugging mode with info to be sent across a serial cable to another computer that is running a debugger. - enabled networking mode (optional) This to allow remote safe mode. - startable from a local or remote terminal, on a command line. In case of a remote startup it would require networking mode enabled. - boot verbosity mode (full, regular, minimal, none) - logging verbosity mode (full, regular, minimal, none) - option to return to boot menu (loader) - option to reboot - Safe Mode with Root Shell Like regular Safe Mode with boot into root shell (like Single User Mode, with configurable root password requirement). This mode is particularly useful if you need to repair your system by copying a file from a CD-ROM to your hard drive, or if you need to reconfigure a service that is preventing your computer from starting properly. This functionality is indeed similar to Single User Mode, but after further considerations it may be different under Safe Mode. jb ___ 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
Re: revisiting tunables under Safe Mode menu option
on 01/03/2012 03:34 Devin Teske said the following: +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe Mode knows about ACPI but only acts on it when being enabled). Can you explain why? +1 for having both menu items and each doing its own thing without any entanglement :-) -- Andriy Gapon ___ 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
Re: revisiting tunables under Safe Mode menu option
on 01/03/2012 03:07 Kevin Oberman said the following: I disabled APIC with a tunable (hint.apic.0.disabled=1). The T43 has no BIOS setting to turn it off. I have some time and still have the computer and it is up and running 9-Stable. In theory, I am retired, but still work part-time job at Lawrence Berkeley and have a contract with another university that will end sin a few weeks. I should be able to spend some time looking at it, but I may be tied up with those at times. I am NOT a programmer any more. My last kernel hacking was done in assembly on a VAX (or, maybe and Alpha) running VMS about 25 years ago. If you want me to help, I'll try, but I'll probably need detailed instructions and, since the system is owned by the U.S. government, I can't allow others to access it. I think that obtaining verbose boot logs for both cases would be a nice start. If you can't get the log as a text (e.g. via serial console) for the APIC case, then a series of digital camera screenshots would be fine too. P.S. Here seems to be a dmesg of FreeBSD 7 successfully booting on T43 with APIC enabled: http://www.4ucode.com/Study/Topic/1091620 -- Andriy Gapon ___ 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
RE: revisiting tunables under Safe Mode menu option
-Original Message- From: Andriy Gapon [mailto:a...@freebsd.org] Sent: Thursday, March 01, 2012 12:39 AM To: Devin Teske Cc: John Baldwin; freebsd-current@FreeBSD.org; Scott Long; Devin Teske Subject: Re: revisiting tunables under Safe Mode menu option on 01/03/2012 03:34 Devin Teske said the following: +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe Mode knows about ACPI but only acts on it when being enabled). Can you explain why? +1 for having both menu items and each doing its own thing without any entanglement :-) First, I realize that this may sound entirely *dumb*, but here-goes: In transitioning from an old release (sans-menu; 4.11 for example) to a newer release (with menu; 6.x for example), one of the first thing that is noticed is Safe Mode. I know that when I first saw this, I scratched my head and wondered what it did and what it might be useful for. To this day, I still have never used it. When I created the new menu for 9.x/higher, I had to rewrite that portion of the code and eventually learned what Safe Mode does when used. Still can't say that I've ever used it, however, at the point that I saw that it disabled ACPI among other things, that it is more of a blanket option for anything and everything that might be useful if/when you're having problems (*cough* still can't say that I've ever used it, as when I have problems I'm usually slogging through the kernel code, not relying on safe mode to fix some problem). That being said, I felt that it was a huge improvement to the UI to have the Safe Mode option divulge a little bit of its secret by visibly diddling the ACPI menu item (giving a clue to people that *haven't* read the code that this option is indeed not independent but instead conglomerate in-nature). Indeed, I've watched field engineers when exploring the menu options and their eyes light-up when they see that Safe Mode toggles ACPI off when enabled. Extrapolating on their surprise, they appear to have an Aha!-moment as previously... this field engineer had no idea what on God's green Earth what Safe Mode did (or didn't) as he didn't know about kenv and certainly couldn't read Forth. At that point, he may not have had a full understanding of all the options that Safe Mode diddled, but at that point he at least knew that Safe Mode is a multi-option that does many things -- which is more than 6.x, 7.x, or 8.x ever offered which simply boots immediately the Safe Mode option is selected and does nothing to explain what it is that Safe Mode is doing (which would in-turn properly calibrate the user's expectations). Making the menu items completely independent would be take away the (however slight) above value-add that was brought in by entwining these two menu-items. I'm not saying that this would be a grave travesty, but would in-fact be a value-loss. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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
Re: revisiting tunables under Safe Mode menu option
On Thursday, March 01, 2012 3:39:21 am Andriy Gapon wrote: on 01/03/2012 03:34 Devin Teske said the following: +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe Mode knows about ACPI but only acts on it when being enabled). Can you explain why? +1 for having both menu items and each doing its own thing without any entanglement :-) Yeah, I think at this point we could make safe mode not disable ACPI, but leave those as independent knobs. That's simpler to implement and arguably more intuitive (though having the boot menu now have 'YES/NO' state that gets updated helps a lot with the UI being easier to understand). -- John Baldwin ___ 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
Re: revisiting tunables under Safe Mode menu option
on 01/03/2012 18:52 Devin Teske said the following: -Original Message- From: Andriy Gapon [mailto:a...@freebsd.org] Sent: Thursday, March 01, 2012 12:39 AM To: Devin Teske Cc: John Baldwin; freebsd-current@FreeBSD.org; Scott Long; Devin Teske Subject: Re: revisiting tunables under Safe Mode menu option on 01/03/2012 03:34 Devin Teske said the following: +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe Mode knows about ACPI but only acts on it when being enabled). Can you explain why? +1 for having both menu items and each doing its own thing without any entanglement :-) First, I realize that this may sound entirely *dumb*, but here-goes: In transitioning from an old release (sans-menu; 4.11 for example) to a newer release (with menu; 6.x for example), one of the first thing that is noticed is Safe Mode. I know that when I first saw this, I scratched my head and wondered what it did and what it might be useful for. To this day, I still have never used it. When I created the new menu for 9.x/higher, I had to rewrite that portion of the code and eventually learned what Safe Mode does when used. Still can't say that I've ever used it, however, at the point that I saw that it disabled ACPI among other things, that it is more of a blanket option for anything and everything that might be useful if/when you're having problems (*cough* still can't say that I've ever used it, as when I have problems I'm usually slogging through the kernel code, not relying on safe mode to fix some problem). That being said, I felt that it was a huge improvement to the UI to have the Safe Mode option divulge a little bit of its secret by visibly diddling the ACPI menu item (giving a clue to people that *haven't* read the code that this option is indeed not independent but instead conglomerate in-nature). Indeed, I've watched field engineers when exploring the menu options and their eyes light-up when they see that Safe Mode toggles ACPI off when enabled. Extrapolating on their surprise, they appear to have an Aha!-moment as previously... this field engineer had no idea what on God's green Earth what Safe Mode did (or didn't) as he didn't know about kenv and certainly couldn't read Forth. At that point, he may not have had a full understanding of all the options that Safe Mode diddled, but at that point he at least knew that Safe Mode is a multi-option that does many things -- which is more than 6.x, 7.x, or 8.x ever offered which simply boots immediately the Safe Mode option is selected and does nothing to explain what it is that Safe Mode is doing (which would in-turn properly calibrate the user's expectations). Making the menu items completely independent would be take away the (however slight) above value-add that was brought in by entwining these two menu-items. I'm not saying that this would be a grave travesty, but would in-fact be a value-loss. Devin, you did a great job with boot menu enhancement in general and in this area in particular. You greatly improved usability while preserving the historic behavior and put a lot of work and creativity into that. Thank you! But the argument is that the historic behavior is no longer useful. I see that removing the historic behavior also kills a little bit of your code (and a little bit of magic). That's true, that's a loss in the code. But I still believe that it would be an improvement from the point of view of usability end-users. Having a whole sub-menu where multiple parameters could be tweaked individually would be even greater improvement. But that's not as easy to do. -- Andriy Gapon ___ 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
Re: revisiting tunables under Safe Mode menu option
On Mar 1, 2012, at 9:52 AM, Devin Teske wrote: -Original Message- From: Andriy Gapon [mailto:a...@freebsd.org] Sent: Thursday, March 01, 2012 12:39 AM To: Devin Teske Cc: John Baldwin; freebsd-current@FreeBSD.org; Scott Long; Devin Teske Subject: Re: revisiting tunables under Safe Mode menu option on 01/03/2012 03:34 Devin Teske said the following: +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe Mode knows about ACPI but only acts on it when being enabled). Can you explain why? +1 for having both menu items and each doing its own thing without any entanglement :-) First, I realize that this may sound entirely *dumb*, but here-goes: In transitioning from an old release (sans-menu; 4.11 for example) to a newer release (with menu; 6.x for example), one of the first thing that is noticed is Safe Mode. I know that when I first saw this, I scratched my head and wondered what it did and what it might be useful for. To this day, I still have never used it. To be fair, I'm pretty sure that 'Safe Mode' was documented in one of the docbook manuals, though the FreeBSD project never, to my knowledge, had a quick install/troubleshooting guide' that documented the loader menu. The name was inspired by Windows, but if you aren't familiar with that side of the world, then I can see how the name would have diminished meaning. So I understand where you're coming from. I'd like to turn the discussion away from ACPI specifically. What I'd like to see improved is two things: 1. There are a number of knobs that can be manipulated to help enable a non-booting system boot, which in turn gives a system administrator a fighting chance to figure out what's wrong. ACPI is (or was) one of these options, but there are several others, and up until your re-write of the menu system, they were opaque to the user. I'd like to explore the idea of having a sub-menu that exposes these knobs and allows them to be individually controlled, but still have an upper-level option that turns them all-on or all-off for ease of use. 2. There are a ton of kenv/TUNABLE knobs in any given kernel, and many of them are useful for sysadmins, even beyond just the 'safe mode' subset. I'd like to see a post-processor run on the kernel build that collects all of the kenv knobs in that kernel and puts them into a file that can be read by the boot menu system. The system then dynamically turns these into another sub-menu of knobs that can be manipulated. So, how hard would it be to have nested sub-menus? Would (1) be something feasible to do in the near term? Would (2) be feasible to do in the long term? Thanks, 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
RE: revisiting tunables under Safe Mode menu option
-Original Message- From: Scott Long [mailto:sco...@samsco.org] Sent: Thursday, March 01, 2012 9:13 AM To: Devin Teske Cc: 'Andriy Gapon'; 'John Baldwin'; freebsd-current@FreeBSD.org; 'Devin Teske' Subject: Re: revisiting tunables under Safe Mode menu option On Mar 1, 2012, at 9:52 AM, Devin Teske wrote: -Original Message- From: Andriy Gapon [mailto:a...@freebsd.org] Sent: Thursday, March 01, 2012 12:39 AM To: Devin Teske Cc: John Baldwin; freebsd-current@FreeBSD.org; Scott Long; Devin Teske Subject: Re: revisiting tunables under Safe Mode menu option on 01/03/2012 03:34 Devin Teske said the following: +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe Mode knows about ACPI but only acts on it when being enabled). Can you explain why? +1 for having both menu items and each doing its own thing without any entanglement :-) First, I realize that this may sound entirely *dumb*, but here-goes: In transitioning from an old release (sans-menu; 4.11 for example) to a newer release (with menu; 6.x for example), one of the first thing that is noticed is Safe Mode. I know that when I first saw this, I scratched my head and wondered what it did and what it might be useful for. To this day, I still have never used it. To be fair, I'm pretty sure that 'Safe Mode' was documented in one of the docbook manuals, though the FreeBSD project never, to my knowledge, had a quick install/troubleshooting guide' that documented the loader menu. The name was inspired by Windows, but if you aren't familiar with that side of the world, then I can see how the name would have diminished meaning. So I understand where you're coming from. I'd like to turn the discussion away from ACPI specifically. What I'd like to see improved is two things: 1. There are a number of knobs that can be manipulated to help enable a non- booting system boot, which in turn gives a system administrator a fighting chance to figure out what's wrong. ACPI is (or was) one of these options, but there are several others, and up until your re-write of the menu system, they were opaque to the user. I'd like to explore the idea of having a sub-menu that exposes these knobs and allows them to be individually controlled, but still have an upper-level option that turns them all-on or all-off for ease of use. 2. There are a ton of kenv/TUNABLE knobs in any given kernel, and many of them are useful for sysadmins, even beyond just the 'safe mode' subset. I'd like to see a post-processor run on the kernel build that collects all of the kenv knobs in that kernel and puts them into a file that can be read by the boot menu system. The system then dynamically turns these into another sub-menu of knobs that can be manipulated. So, how hard would it be to have nested sub-menus? Would (1) be something feasible to do in the near term? Would (2) be feasible to do in the long term? Sub-menus are not hard at all. The menu.4th module released under 9.0-RELEASE already supports sub-menus and hierarchical menus. You don't have to change the Forth code in even the slightest, this can all be done through rc files like menu.rc. The magic of-course is achieved through the utilization of the menu-clear FICL word (linked-to below): http://svnweb.freebsd.org/base/release/9.0.0/sys/boot/forth/menu.4th?revision=22 9286view=markup NOTE: menu-clear is the last function in the file at the very bottom. The comment for which is thus: This function unsets all the possible environment variables associated with creating the interactive menu. Call this when you want to clear the menu area in preparation for another menu. Further-more, I have full examples on how to implement (working) sub-menus, hierarchical menus, and such. However... Design discussions would have to follow as we do have serious limitations. First, each menu can have only 9 items (we are in-fact limited by screen real-estate as we do indeed want to retain support for serial consoles during boot). Also, don't forget that we actually have three different types of menu items that can be used for each item in each menu: 1. Normal action-items (like Boot) 2. Toggle items (like On/Off or Yes/No features) 3. Cyclic items (allowing selection of one kernel out of 5 different ones, for example) So creativity can probably find a graceful solution to however many items we need to support. (thinking out loud here: maybe such a discussion would be best shunted off to hackers if/when we get to the point of discussing actual changes, patches, and code) -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any
RE: revisiting tunables under Safe Mode menu option
-Original Message- From: Andriy Gapon [mailto:a...@freebsd.org] Sent: Thursday, March 01, 2012 9:07 AM To: Devin Teske Cc: 'John Baldwin'; freebsd-current@FreeBSD.org; 'Scott Long'; 'Devin Teske' Subject: Re: revisiting tunables under Safe Mode menu option on 01/03/2012 18:52 Devin Teske said the following: -Original Message- From: Andriy Gapon [mailto:a...@freebsd.org] Sent: Thursday, March 01, 2012 12:39 AM To: Devin Teske Cc: John Baldwin; freebsd-current@FreeBSD.org; Scott Long; Devin Teske Subject: Re: revisiting tunables under Safe Mode menu option on 01/03/2012 03:34 Devin Teske said the following: +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe Mode knows about ACPI but only acts on it when being enabled). Can you explain why? +1 for having both menu items and each doing its own thing without any entanglement :-) First, I realize that this may sound entirely *dumb*, but here-goes: In transitioning from an old release (sans-menu; 4.11 for example) to a newer release (with menu; 6.x for example), one of the first thing that is noticed is Safe Mode. I know that when I first saw this, I scratched my head and wondered what it did and what it might be useful for. To this day, I still have never used it. When I created the new menu for 9.x/higher, I had to rewrite that portion of the code and eventually learned what Safe Mode does when used. Still can't say that I've ever used it, however, at the point that I saw that it disabled ACPI among other things, that it is more of a blanket option for anything and everything that might be useful if/when you're having problems (*cough* still can't say that I've ever used it, as when I have problems I'm usually slogging through the kernel code, not relying on safe mode to fix some problem). That being said, I felt that it was a huge improvement to the UI to have the Safe Mode option divulge a little bit of its secret by visibly diddling the ACPI menu item (giving a clue to people that *haven't* read the code that this option is indeed not independent but instead conglomerate in-nature). Indeed, I've watched field engineers when exploring the menu options and their eyes light-up when they see that Safe Mode toggles ACPI off when enabled. Extrapolating on their surprise, they appear to have an Aha!-moment as previously... this field engineer had no idea what on God's green Earth what Safe Mode did (or didn't) as he didn't know about kenv and certainly couldn't read Forth. At that point, he may not have had a full understanding of all the options that Safe Mode diddled, but at that point he at least knew that Safe Mode is a multi-option that does many things -- which is more than 6.x, 7.x, or 8.x ever offered which simply boots immediately the Safe Mode option is selected and does nothing to explain what it is that Safe Mode is doing (which would in-turn properly calibrate the user's expectations). Making the menu items completely independent would be take away the (however slight) above value-add that was brought in by entwining these two menu- items. I'm not saying that this would be a grave travesty, but would in-fact be a value-loss. Devin, you did a great job with boot menu enhancement in general and in this area in particular. You greatly improved usability while preserving the historic behavior and put a lot of work and creativity into that. Thank you! Thank you for your kind words! Really! But the argument is that the historic behavior is no longer useful. I see that removing the historic behavior also kills a little bit of your code (and a little bit of magic). That's true, that's a loss in the code. (nods) [snip] Having a whole sub-menu where multiple parameters could be tweaked individually would be even greater improvement. But that's not as easy to do. Actually, it is easy to do. Since day one, menu.4th has supported sub-menus and hierarchical menus. HINT: see menu-clear at the bottom of menu.4th ASIDE: Before I do some mock-ups illustrating multiple rc files providing sub-menus, we'll need to discuss what these menus will look like and how they'll be generated (I heard of a hint of having build(7) generate something). I'm not opposed to say, having a submenu.rc.in which is processed into submenu.rc (obviously more-appropriately named than submenu) and hooked into a menu-item visible in menu.rc. Mind you, menu.rc may have to be forked-off itself (for reasons we won't discuss until we get down to the nitty-gritty; possibly on -hackers). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition
Re: revisiting tunables under Safe Mode menu option
On 3/1/12 8:52 AM, Devin Teske wrote: . Indeed, I've watched field engineers when exploring the menu options and their eyes light-up when they see that Safe Mode toggles ACPI off when enabled. Extrapolating on their surprise, they appear to have an Aha!-moment a ... they have all seen 'safe mode' on windows. They know what that does and they are assuming this does the same thing. Basically Windows safe mode disables all the bells and whistles of the installation and reverts to known safe defaults for everything it can reach. i.e. VGA screen, basic keyboard, IDE disk, no desktop extensions, all fancy CPU options turned off. ___ 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
Re: revisiting tunables under Safe Mode menu option
On 3/1/12 9:13 AM, Scott Long wrote: 1. There are a number of knobs that can be manipulated to help enable a non-booting system boot, which in turn gives a system administrator a fighting chance to figure out what's wrong. ACPI is (or was) one of these options, but there are several others, and up until your re-write of the menu system, they were opaque to the user. I'd like to explore the idea of having a sub-menu that exposes these knobs and allows them to be individually controlled, but still have an upper-level option that turns them all-on or all-off for ease of use. 2. There are a ton of kenv/TUNABLE knobs in any given kernel, and many of them are useful for sysadmins, even beyond just the 'safe mode' subset. I'd like to see a post-processor run on the kernel build that collects all of the kenv knobs in that kernel and puts them into a file that can be read by the boot menu system. The system then dynamically turns these into another sub-menu of knobs that can be manipulated. So, how hard would it be to have nested sub-menus? Would (1) be something feasible to do in the near term? Would (2) be feasible to do in the long term? not only collecting stuff from am kernel build but from a running system. it would be nice fro example to be able to influence the /etc/rc.d system by disabling some functions. e.g. come up but don't turn on the window system, or networking.. We can disable a device but how about specifying a different default route than that in /etc/rc.conf? if we extract the setup tha tthe machine eventually comes up to, we can allow that to be tuned as well. Thanks, 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 ___ 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
RE: revisiting tunables under Safe Mode menu option
-Original Message- From: Julian Elischer [mailto:jul...@freebsd.org] Sent: Thursday, March 01, 2012 1:22 PM To: Devin Teske Cc: 'Andriy Gapon'; freebsd-current@freebsd.org; 'Devin Teske'; 'John Baldwin' Subject: Re: revisiting tunables under Safe Mode menu option On 3/1/12 8:52 AM, Devin Teske wrote: . Indeed, I've watched field engineers when exploring the menu options and their eyes light-up when they see that Safe Mode toggles ACPI off when enabled. Extrapolating on their surprise, they appear to have an Aha!-moment a ... they have all seen 'safe mode' on windows. They know what that does and they are assuming this does the same thing. Basically Windows safe mode disables all the bells and whistles of the installation and reverts to known safe defaults for everything it can reach. i.e. VGA screen, basic keyboard, IDE disk, no desktop extensions, all fancy CPU options turned off. Right, making the assumption that FreeBSD's safe mode will do the same thing as Windows' safe mode is a poor assumption. As you point out, all those things that Windows safe mode does, FreeBSD does not. X11 drivers are not affected by safe mode. Network is not affected by safe mode. Services started at boot, are not affected... So I would welcome discussions involving development of something better (and am willing to help). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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
RE: revisiting tunables under Safe Mode menu option
-Original Message- From: Julian Elischer [mailto:jul...@freebsd.org] Sent: Thursday, March 01, 2012 1:28 PM To: Scott Long Cc: Devin Teske; freebsd-current@freebsd.org; 'Devin Teske'; 'John Baldwin'; 'Andriy Gapon' Subject: Re: revisiting tunables under Safe Mode menu option On 3/1/12 9:13 AM, Scott Long wrote: 1. There are a number of knobs that can be manipulated to help enable a non- booting system boot, which in turn gives a system administrator a fighting chance to figure out what's wrong. ACPI is (or was) one of these options, but there are several others, and up until your re-write of the menu system, they were opaque to the user. I'd like to explore the idea of having a sub-menu that exposes these knobs and allows them to be individually controlled, but still have an upper-level option that turns them all-on or all-off for ease of use. 2. There are a ton of kenv/TUNABLE knobs in any given kernel, and many of them are useful for sysadmins, even beyond just the 'safe mode' subset. I'd like to see a post-processor run on the kernel build that collects all of the kenv knobs in that kernel and puts them into a file that can be read by the boot menu system. The system then dynamically turns these into another sub-menu of knobs that can be manipulated. So, how hard would it be to have nested sub-menus? Would (1) be something feasible to do in the near term? Would (2) be feasible to do in the long term? not only collecting stuff from am kernel build but from a running system. it would be nice fro example to be able to influence the /etc/rc.d system by disabling some functions. e.g. come up but don't turn on the window system, or networking.. We can disable a device but how about specifying a different default route than that in /etc/rc.conf? if we extract the setup tha tthe machine eventually comes up to, we can allow that to be tuned as well. I'm interested in which path you would choose amongst what I've seen mentioned thus far: a. Modifying the boot menu to offer fine-grain control over each aspect of Safe Mode (wherein perhaps the Safe Mode option becomes a hook for a sub-menu rather than its current setup as an On/Off toggle). b. Keeping Safe Mode as an On/Off toggle, but shifting the fine-grain control to userland (wherein loader(8) simply sets a safemode Boolean and the user is dropped into something like single-user mode but with prompts for each feature) c. Something else. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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
Re: revisiting tunables under Safe Mode menu option
On Mar 1, 2012, at 2:39 PM, Devin Teske wrote: I'm interested in which path you would choose amongst what I've seen mentioned thus far: a. Modifying the boot menu to offer fine-grain control over each aspect of Safe Mode (wherein perhaps the Safe Mode option becomes a hook for a sub-menu rather than its current setup as an On/Off toggle). I would favor this. Safe Mode (or whatever it gets renamed to) activates a sub menu with N number of knobs plus an all-on/all-off option. 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
Re: revisiting tunables under Safe Mode menu option
On 3/1/12 1:35 PM, Devin Teske wrote: Right, making the assumption that FreeBSD's safe mode will do the same thing as Windows' safe mode is a poor assumption. As you point out, all those things that Windows safe mode does, FreeBSD does not. X11 drivers are not affected by safe mode. Network is not affected by safe mode. Services started at boot, are not affected... So I would welcome discussions involving development of something better (and am willing to help). but, with help from the rc people. it could.. the kenv framework gives us a much more flexible way to implement the sysV runlevels that linux inherrited. here's what I would envision: a single safe mode switch a way to control what that does (either 'safe mode' drops you to another menu which includes boot safe mode: and configure safe mode (the second one drops you to yet another menu of check boxes). the result of this is a preconfigured set of kenv entries being dumped into the kenv space. The rc system can look at the kenv space for some key entries and act accordingly. it can also SAVE to /boot/safe_mode.conf the set of kenv entries selected when safe mode is used, and the forth code can load that and use it as a default on next 'safe' mode usage. BTW do we use the forth boot stuff on all architectures? what of NFS boots? ___ 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
RE: revisiting tunables under Safe Mode menu option
-Original Message- From: Scott Long [mailto:sco...@samsco.org] Sent: Thursday, March 01, 2012 1:43 PM To: Devin Teske Cc: 'Julian Elischer'; freebsd-current@freebsd.org; 'Devin Teske'; 'John Baldwin'; 'Andriy Gapon' Subject: Re: revisiting tunables under Safe Mode menu option On Mar 1, 2012, at 2:39 PM, Devin Teske wrote: I'm interested in which path you would choose amongst what I've seen mentioned thus far: a. Modifying the boot menu to offer fine-grain control over each aspect of Safe Mode (wherein perhaps the Safe Mode option becomes a hook for a sub- menu rather than its current setup as an On/Off toggle). I would favor this. Safe Mode (or whatever it gets renamed to) activates a sub menu with N number of knobs plus an all-on/all-off option. How many knobs are we talking about here? I hope not more than 8, (the 9th menu being reserved for return to main menu). If there's going to be more than 8, then we'll have to recode menu.4th or envision a sub-sub-menu or start using cyclic menus, or worse... re-design menu.4th completely to allow (say) scrolling menus with infinite items (e.g., there would be an indicator at the bottom of the menu that there is more than can fit within the menu area; and pressing the down-arrow would slide the menu view down to the next set of items). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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
RE: revisiting tunables under Safe Mode menu option
-Original Message- From: Julian Elischer [mailto:jul...@freebsd.org] Sent: Thursday, March 01, 2012 1:52 PM To: Devin Teske Cc: 'Andriy Gapon'; freebsd-current@freebsd.org; 'Devin Teske'; 'John Baldwin' Subject: Re: revisiting tunables under Safe Mode menu option On 3/1/12 1:35 PM, Devin Teske wrote: Right, making the assumption that FreeBSD's safe mode will do the same thing as Windows' safe mode is a poor assumption. As you point out, all those things that Windows safe mode does, FreeBSD does not. X11 drivers are not affected by safe mode. Network is not affected by safe mode. Services started at boot, are not affected... So I would welcome discussions involving development of something better (and am willing to help). but, with help from the rc people. it could.. the kenv framework gives us a much more flexible way to implement the sysV runlevels that linux inherrited. here's what I would envision: a single safe mode switch a way to control what that does (either 'safe mode' drops you to another menu which includes boot safe mode: and configure safe mode (the second one drops you to yet another menu of check boxes). the result of this is a preconfigured set of kenv entries being dumped into the kenv space. The rc system can look at the kenv space for some key entries and act accordingly. it can also SAVE to /boot/safe_mode.conf the set of kenv entries selected when safe mode is used, and the forth code can load that and use it as a default on next 'safe' mode usage. BTW do we use the forth boot stuff on all architectures? what of NFS boots? Glad you asked. There are architectures that don't use beastie.4th at all and thus simply fall to the autoboot sequence after handling loader.conf. These architectures lack a menu, so it would be nice if we accommodated them with (at least) allowing manual configuration through environment variables (later grabbed with kenv by the rc folks). I don't think it's beyond scope to think we couldn't cleanly implement this with (say) a well-crafted /etc/rc.d/safemode Not exactly sure what service safemode start should do (BSD doesn't have the same concept of runlevels as Linux does; so it's not exactly intuitive to think we could go from multi-user mode *into* safe mode). But service safemode status would be interesting. Interestingly, it would perhaps be nice if service safemode stop brought the system back to fully usable without need for reboot (something Windows doesn't offer). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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
Re: revisiting tunables under Safe Mode menu option
on 29/02/2012 00:18 Kevin Oberman said the following: APIC is required for SMP, but works on many older, single CPU systems and removes the massive sharing of IRQs common on non-APIC systems. OTOH, some ThinkPads simply won't boot with APIC. My old T43 (Pentium-M) had this issue. I had to turn off APIC to get a GENERIC kernel to boot. I think that I have heard of other systems that have an issue with FreeBSD APIC. (APIC seems to work fine with Windows, so it's something about the FreeBSD implementation, but the problem is pretty rare, seems limited to 3-5 year old uniprocessor systems, so it's probably not worth trying to track down. I think that it would be useful to track this down. If it's a bug then it's a bug and who knows how it can bite in the future. If you still have the hardware and can allocate some time to this issue, then it would be great. Also, when you said disabled APIC - did you disable it via BIOS settings or via the FreeBSD tunable? BTW, a nitpick - T43 production seems to have started in April 2005, so it's more like 7 years :) -- Andriy Gapon ___ 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
Re: revisiting tunables under Safe Mode menu option
On Wed, Feb 29, 2012 at 1:49 AM, Andriy Gapon a...@freebsd.org wrote: on 29/02/2012 00:18 Kevin Oberman said the following: APIC is required for SMP, but works on many older, single CPU systems and removes the massive sharing of IRQs common on non-APIC systems. OTOH, some ThinkPads simply won't boot with APIC. My old T43 (Pentium-M) had this issue. I had to turn off APIC to get a GENERIC kernel to boot. I think that I have heard of other systems that have an issue with FreeBSD APIC. (APIC seems to work fine with Windows, so it's something about the FreeBSD implementation, but the problem is pretty rare, seems limited to 3-5 year old uniprocessor systems, so it's probably not worth trying to track down. I think that it would be useful to track this down. If it's a bug then it's a bug and who knows how it can bite in the future. If you still have the hardware and can allocate some time to this issue, then it would be great. Also, when you said disabled APIC - did you disable it via BIOS settings or via the FreeBSD tunable? BTW, a nitpick - T43 production seems to have started in April 2005, so it's more like 7 years :) Andriy, Gee. Time flies when you're having fun... or when a project is approaching its due date. I disabled APIC with a tunable (hint.apic.0.disabled=1). The T43 has no BIOS setting to turn it off. I have some time and still have the computer and it is up and running 9-Stable. In theory, I am retired, but still work part-time job at Lawrence Berkeley and have a contract with another university that will end sin a few weeks. I should be able to spend some time looking at it, but I may be tied up with those at times. I am NOT a programmer any more. My last kernel hacking was done in assembly on a VAX (or, maybe and Alpha) running VMS about 25 years ago. If you want me to help, I'll try, but I'll probably need detailed instructions and, since the system is owned by the U.S. government, I can't allow others to access it. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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
Re: revisiting tunables under Safe Mode menu option
On Feb 28, 2012, at 5:46 AM, John Baldwin wrote: On Tuesday, February 28, 2012 1:23:11 am Scott Long wrote: 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? .oO(uh oh, what'd I do now?) 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. Hmm, with the newer boot menu, can't one now toggle safe mode and ACPI independently? Semi-independently; ordered rather. Toggling Safe Mode On will toggle ACPI Off. This is the only real example of one menu item reaching into another menu item, and it only happens when toggling Safe Mode on (not off). Despite the above description, it is in-fact intuitive and the effects are as-expected. Booting Safe Mode with ACPI enabled is no harder than toggling Safe Mode on [first] before [then] re-enabling ACPI (followed by ENTER). (Assuming we haven't removed the ability to disable ACPI from the menu, if we have we should perhaps put that back). Having them be orthogonal knobs would seem to the be the best approach. +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe Mode knows about ACPI but only acts on it when being enabled). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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
Re: revisiting tunables under Safe Mode menu option
On Monday, February 27, 2012 2:03:21 pm Scott Long wrote: 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. You want APIC for other things as well (hwpmc(4) requires it, as do CMCI interrupts, and we really do like to make use of the local APIC timer). [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? I agree this should probably stay. -- John Baldwin ___ 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
Re: revisiting tunables under Safe Mode menu option
On Tuesday, February 28, 2012 1:23:11 am Scott Long wrote: 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. Hmm, with the newer boot menu, can't one now toggle safe mode and ACPI independently? (Assuming we haven't removed the ability to disable ACPI from the menu, if we have we should perhaps put that back). Having them be orthogonal knobs would seem to the be the best approach. -- John Baldwin ___ 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
Re: revisiting tunables under Safe Mode menu option
On Monday, February 27, 2012 4:49:34 pm Andriy Gapon wrote: on 27/02/2012 18:26 John Baldwin said the following: On Monday, February 27, 2012 5:45:39 am Andriy Gapon wrote: How does the following look? diff --git a/sys/boot/forth/menu-commands.4th b/sys/boot/forth/menu-commands.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 evaluate 0= 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=1 evaluate s set hw.ata.ata_dma=0 evaluate s set hw.ata.atapi_dma=0 evaluate s set hw.ata.wc=0 evaluate - s set hw.eisa_slots=0 evaluate - s set hint.kbdmux.0.disabled=1 evaluate + s set kern.eventtimer.periodic=1 unsetenv + s set kern.geom.part.check_integrity=0 unsetenv + s set debug.acpi.disabled=hostres unsetenv then menu-redraw I'm not sure we need the 'hostres' thing in HEAD and 9-stable after my latest changes? Other than that I think this is fine. I added it based on the past reports. If you think that it's not useful now, then I'll drop it. Thanks! I think it should not be needed now. It would be needed if you merged this to 9.0 release. -- John Baldwin ___ 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
Re: revisiting tunables under Safe Mode menu option
On Feb 28, 2012, at 6:44 AM, John Baldwin wrote: On Monday, February 27, 2012 2:03:21 pm Scott Long wrote: 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. You want APIC for other things as well (hwpmc(4) requires it, as do CMCI interrupts, and we really do like to make use of the local APIC timer). Well, 'Safe Mode' isn't meant to be a normal, continuous operating mode, it's meant to be a debug mode that helps boot otherwise unbeatable systems. 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
Re: revisiting tunables under Safe Mode menu option
On Feb 28, 2012, at 6:46 AM, John Baldwin wrote: On Tuesday, February 28, 2012 1:23:11 am Scott Long wrote: 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. Hmm, with the newer boot menu, can't one now toggle safe mode and ACPI independently? (Assuming we haven't removed the ability to disable ACPI from the menu, if we have we should perhaps put that back). Having them be orthogonal knobs would seem to the be the best approach. Yes, Andriy reminded me of this last night, so I withdraw my comments. 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
Re: revisiting tunables under Safe Mode menu option
On Mon, Feb 27, 2012 at 10:23 PM, Scott Long sco...@samsco.org wrote: 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. APIC is required for SMP, but works on many older, single CPU systems and removes the massive sharing of IRQs common on non-APIC systems. OTOH, some ThinkPads simply won't boot with APIC. My old T43 (Pentium-M) had this issue. I had to turn off APIC to get a GENERIC kernel to boot. I think that I have heard of other systems that have an issue with FreeBSD APIC. (APIC seems to work fine with Windows, so it's something about the FreeBSD implementation, but the problem is pretty rare, seems limited to 3-5 year old uniprocessor systems, so it's probably not worth trying to track down. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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
Re: revisiting tunables under Safe Mode menu option
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? [dropped proposals snipped] o hw.eisa_slot - Looks like something from ancient times. Probably just irrelevant for most systems. 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. 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? How does the following look? diff --git a/sys/boot/forth/menu-commands.4th b/sys/boot/forth/menu-commands.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 evaluate 0= 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=1 evaluate s set hw.ata.ata_dma=0 evaluate s set hw.ata.atapi_dma=0 evaluate s set hw.ata.wc=0 evaluate - s set hw.eisa_slots=0 evaluate - s set hint.kbdmux.0.disabled=1 evaluate + s set kern.eventtimer.periodic=1 unsetenv + s set kern.geom.part.check_integrity=0 unsetenv + s set debug.acpi.disabled=hostres unsetenv then menu-redraw -- Andriy Gapon ___ 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
Re: revisiting tunables under Safe Mode menu option
On Feb 27, 2012, at 2:45 AM, Andriy Gapon a...@freebsd.org 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? [dropped proposals snipped] o hw.eisa_slot - Looks like something from ancient times. Probably just irrelevant for most systems. 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. 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? How does the following look? diff --git a/sys/boot/forth/menu-commands.4th b/sys/boot/forth/menu-commands.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 evaluate 0= 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=1 evaluate s set hw.ata.ata_dma=0 evaluate s set hw.ata.atapi_dma=0 evaluate s set hw.ata.wc=0 evaluate -s set hw.eisa_slots=0 evaluate -s set hint.kbdmux.0.disabled=1 evaluate +s set kern.eventtimer.periodic=1 unsetenv +s set kern.geom.part.check_integrity=0 unsetenv +s set debug.acpi.disabled=hostres unsetenv then menu-redraw 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. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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
Re: revisiting tunables under Safe Mode menu option
On Monday, February 27, 2012 5:45:39 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? [dropped proposals snipped] o hw.eisa_slot - Looks like something from ancient times. Probably just irrelevant for most systems. 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. 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? How does the following look? diff --git a/sys/boot/forth/menu-commands.4th b/sys/boot/forth/menu-commands.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 evaluate 0= 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=1 evaluate s set hw.ata.ata_dma=0 evaluate s set hw.ata.atapi_dma=0 evaluate s set hw.ata.wc=0 evaluate - s set hw.eisa_slots=0 evaluate - s set hint.kbdmux.0.disabled=1 evaluate + s set kern.eventtimer.periodic=1 unsetenv + s set kern.geom.part.check_integrity=0 unsetenv + s set debug.acpi.disabled=hostres unsetenv then menu-redraw I'm not sure we need the 'hostres' thing in HEAD and 9-stable after my latest changes? Other than that I think this is fine. -- John Baldwin ___ 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
Re: revisiting tunables under Safe Mode menu option
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
Re: revisiting tunables under Safe Mode menu option
on 27/02/2012 18:26 John Baldwin said the following: On Monday, February 27, 2012 5:45:39 am Andriy Gapon wrote: How does the following look? diff --git a/sys/boot/forth/menu-commands.4th b/sys/boot/forth/menu-commands.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 evaluate 0= 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=1 evaluate s set hw.ata.ata_dma=0 evaluate s set hw.ata.atapi_dma=0 evaluate s set hw.ata.wc=0 evaluate -s set hw.eisa_slots=0 evaluate -s set hint.kbdmux.0.disabled=1 evaluate +s set kern.eventtimer.periodic=1 unsetenv +s set kern.geom.part.check_integrity=0 unsetenv +s set debug.acpi.disabled=hostres unsetenv then menu-redraw I'm not sure we need the 'hostres' thing in HEAD and 9-stable after my latest changes? Other than that I think this is fine. I added it based on the past reports. If you think that it's not useful now, then I'll drop it. Thanks! -- Andriy Gapon ___ 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
Re: revisiting tunables under Safe Mode menu option
on 27/02/2012 21:03 Scott Long said the following: 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. 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. 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. 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): diff --git a/sys/boot/forth/menu-commands.4th b/sys/boot/forth/menu-commands.4th index 828a148..416cb85 100644 --- a/sys/boot/forth/menu-commands.4th +++ b/sys/boot/forth/menu-commands.4th @@ -62,30 +62,21 @@ marker task-menu-commands.4th -rot 2dup 12 + c! rot\ replace 'N' with ASCII numeral evaluate 0= if - s hint.apic.0.disabled unsetenv + s kern.smp.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 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=1 evaluate + s set kern.smp.disabled=1 evaluate s set hw.ata.ata_dma=0 evaluate s set hw.ata.atapi_dma=0 evaluate
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 ___ 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
revisiting tunables under Safe Mode menu option
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. What we have for Safe Mode now (from menu-commands.4th): \ \ 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=1 evaluate s set hw.ata.ata_dma=0 evaluate s set hw.ata.atapi_dma=0 evaluate s set hw.ata.wc=0 evaluate s set hw.eisa_slots=0 evaluate s set hint.kbdmux.0.disabled=1 evaluate 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? o hw.ata.ata_dma, hw.ata.atapi_dma - I am not sure if there have been any significant problems with ATA DMA recently. Maybe these could be removed? o hw.ata.wc - I am not sure if this setting is relevant to the safe boot. Another candidate for removal? o hw.eisa_slot - Looks like something from ancient times. Probably just irrelevant for most systems. 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. 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? -- Andriy Gapon ___ 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
Re: revisiting tunables under Safe Mode menu option
On Mon, 2012-01-30 at 18:59 +0200, Andriy Gapon wrote: o hw.ata.ata_dma, hw.ata.atapi_dma - I am not sure if there have been any significant problems with ATA DMA recently. Maybe these could be removed? I still have to work with hardware that requires ata_dma disabled. It seems to be required for most systems I've worked with that have a compact flash socket on the mainboard (sometimes you can just limit the mode to udma33 or less, sometimes you have to turn it off completely.) Adding kern.eventtimer.periodic=1 seems like a good idea. As a general philosophical thing, I don't have a problem with the idea safe mode turns off everything that has ever historically been problematic, because I don't think anyone expects a system to run well in safe mode. I see it more as a tool to start narrowing down the area of trouble, like step 1 of a binary search for the problem. As such, the most important aspect is a comprehensive list of what changes for safe mode, so that you can procede by selectively en/disabling the various things it does. -- Ian ___ 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
Re: revisiting tunables under Safe Mode menu option
On Jan 30, 2012, at 11:30 AM, Ian Lepore wrote: On Mon, 2012-01-30 at 18:59 +0200, Andriy Gapon wrote: o hw.ata.ata_dma, hw.ata.atapi_dma - I am not sure if there have been any significant problems with ATA DMA recently. Maybe these could be removed? I still have to work with hardware that requires ata_dma disabled. It seems to be required for most systems I've worked with that have a compact flash socket on the mainboard (sometimes you can just limit the mode to udma33 or less, sometimes you have to turn it off completely.) Adding kern.eventtimer.periodic=1 seems like a good idea. As a general philosophical thing, I don't have a problem with the idea safe mode turns off everything that has ever historically been problematic, because I don't think anyone expects a system to run well in safe mode. I see it more as a tool to start narrowing down the area of trouble, like step 1 of a binary search for the problem. As such, the most important aspect is a comprehensive list of what changes for safe mode, so that you can procede by selectively en/disabling the various things it does. I second the point about ATA DMA, but it is worth pointing out that those sysctls don't do anything with ATA_CAM (see http://www.freebsd.org/cgi/query-pr.cgi?pr=164226) . -Nathan ___ 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
