[OpenIndiana-discuss] ~6 minutes to OI banner/boot options in text install

Sun Feb 7 07:04:50 UTC 2021

On 2021-02-06 13:36, Chris wrote:
> On 2021-02-06 00:56, Toomas Soome wrote:
>>> On 6. Feb 2021, at 01:41, Chris <oidev at sunos.info> wrote:
>>> 
>>> On 2021-02-05 14:16, Chris wrote:
>>>> On 2021-02-05 13:46, Toomas Soome wrote:
>>>>>> On 5. Feb 2021, at 19:54, Chris <oidev at sunos.info> wrote:
>>>>>> On 2021-01-30 02:28, Toomas Soome wrote:
>>>>>>>> On 30. Jan 2021, at 10:39, Chris <oidev at sunos.info> wrote:
>>>>>>>> On 2021-01-30 00:03, Toomas Soome wrote:
>>>>>>>>>> On 30. Jan 2021, at 09:40, Chris <oidev at sunos.info> wrote:
>>>>>>>>>> On 2021-01-29 22:24, Toomas Soome via openindiana-discuss wrote:
>>>>>>>>>>>> On 30. Jan 2021, at 03:43, Chris <oidev at sunos.info> wrote:
>>>>>>>>>>>> On 2021-01-29 17:18, Andy Fiddaman wrote:
>>>>>>>>>>>>> On Fri, 29 Jan 2021, Chris wrote:
>>>>>>>>>>>>> ; OK just dragged a Dell Optiplex 790 off the shelf
>>>>>>>>>>>>> ; with a 4 core 8 thread i5 CPU in it, and as much RAM
>>>>>>>>>>>>> ; as I could jam in it.
>>>>>>>>>>>>> ; BIOS:
>>>>>>>>>>>>> ; boot UEFI
>>>>>>>>>>>>> ; SATA ahci
>>>>>>>>>>>>> ; I've tried 2 different Nvidia cards, as well as the
>>>>>>>>>>>>> ; intermal video. The results are the same;
>>>>>>>>>>>>> ; 2.5 minutes to get to the OI banner/boot options.
>>>>>>>>>>>>> ; An additiona 3.5 to draw the OI banner/options screen.
>>>>>>>>>>>>> ; It takes ~0.5 seconds to draw each cell. To be clear;
>>>>>>>>>>>>> ; I'm not complaining here. Rather, I'm trying to
>>>>>>>>>>>>> ; pinpoint WTF is going wrong in hopes of overcoming
>>>>>>>>>>>>> ; the problem. I've attempted to put OI on 3 different
>>>>>>>>>>>>> ; computers now, and the results have all been
>>>>>>>>>>>>> ; underwhelming in the console dept.
>>>>>>>>>>>>> ;
>>>>>>>>>>>>> ; Any thoughts?
>>>>>>>>>>>>> If you can press <escape> really early in the boot process, you 
>>>>>>>>>>>>> get the
>>>>>>>>>>>>> first loader prompt (I forget exactly how it looks). At that 
>>>>>>>>>>>>> point,
>>>>>>>>>>>>> enter "-t" without the quotes and press return. That will keep 
>>>>>>>>>>>>> in
>>>>>>>>>>>>> VGA mode, which might well be faster/usable.
>>>>>>>>>>>> Huge thanks for the reply, Andy!
>>>>>>>>>>>> Yes, it made a difference. Drawing each cell only takes 0.25
>>>>>>>>>>>> seconds. :-P
>>>>>>>>>>>> So somewhat faster, anyway. It's funny. It starts out quite
>>>>>>>>>>>> fast. The speed I normally experience with other stuff. It
>>>>>>>>>>>> writes
>>>>>>>>>>>> Available consoles:
>>>>>>>>>>>> text VGA ...
>>>>>>>>>>>> ttya port 0x3f8
>>>>>>>>>>>> ttyb ... not present
>>>>>>>>>>>> ttyc ... not present
>>>>>>>>>>>> ttyd ... not present
>>>>>>>>>>>> null software device
>>>>>>>>>>>> spin software device
>>>>>>>>>>>> Right at this point is where it drops to about 1/2 or slower 
>>>>>>>>>>>> speed.
>>>>>>>>>>>> Then, cell by cell, it prints
>>>>>>>>>>>> console ttyb failed to initialize
>>>>>>>>>>>> console ttyc failed to initialize
>>>>>>>>>>>> console ttyd failed to initialize
>>>>>>>>>>> This is the point where you have got hint about why this happens. 
>>>>>>>>>>> The same defect
>>>>>>>>>>> is with virtualbox, when you have configured host pipe for serial 
>>>>>>>>>>> device.
>>>>>>>>>>> The three lines above tell us that ttya was successfully 
>>>>>>>>>>> initialized, so it must
>>>>>>>>>>> have to do about ttya.
>>>>>>>>>> OK I neglected to note that this was including the advice by Andy 
>>>>>>>>>> to drop to
>>>>>>>>>> text mode, by interrupting loader, and entering -t at the prompt 
>>>>>>>>>> followed by
>>>>>>>>>> enter. It's clear that it was attempting serial mode -- note the 
>>>>>>>>>> port 0x3f8
>>>>>>>>>> Without interrupting loader, text and ttya return:
>>>>>>>>>> text VESA (800x600 - 1600x1200 depending on what I'm hooked up to)
>>>>>>>>>> ttya ... not present
>>>>>>>>>> I'm attempting it again via Legacy where
>>>>>>>>>> text VESA 1600x1200
>>>>>>>>>> ttya ... not present
>>>>>>>>>> Choosing 5 (options), followed by 5 (verbose) has already taken 20
>>>>>>>>>> minutes (it's still in progress). I think I'm just going to try to
>>>>>>>>>> install it and work on it further from the internal disk. In hopes
>>>>>>>>>> of getting at least a small speed increase from 0 to actual boot.
>>>>>>>>>> I greatly appreciate your insight on this, Toomas.
>>>>>>>>> Ok, so this guess was not good one afterall. If you are doing CD 
>>>>>>>>> (ISO) boot, you
>>>>>>>>> will get loader started as first stage - that is, there is no way to 
>>>>>>>>> enter
>>>>>>>>> options; however, once you get out of menu and on O prompt, you can 
>>>>>>>>> enter:
>>>>>>>>> framebuffer off
>>>>>>>>> on BIOS boot, this will switch to VGA text mode, on UEFI, it will 
>>>>>>>>> switch terminal
>>>>>>>>> draw from GOP Blt() to SimpleTextOutput protocol (gfx can not be 
>>>>>>>>> switched off as
>>>>>>>>> there is no VGA text mode in UEFI, there may not be even VGA).
>>>>>>>>> If you are booting from USB stick, press space on very first spinner 
>>>>>>>>> to get boot:
>>>>>>>>> prompt, from there you can enter: -t as Andy was suggesting, it will 
>>>>>>>>> start loader
>>>>>>>>> in text mode, without switching to VBE framebuffer. Once the OS is 
>>>>>>>>> installed, you
>>>>>>>>> can create /boot/config with -t in it, this will achieve the same 
>>>>>>>>> effect.
>>>>>>>>> That much about workaround.
>>>>>>>>> “normally”, if drawing in FB mode is slow, it will help to use lower 
>>>>>>>>> resolution
>>>>>>>>> and/or depth, but as you wrote, 800x600 was just as bad as 
>>>>>>>>> 1920x1200, it means
>>>>>>>>> something else is going on there.
>>>>>>>>> You can set mode as: framebuffer set XxY[xD], where D is for depth, 
>>>>>>>>> defaults to
>>>>>>>>> 32, if not present. framebuffer list [depth] will list available 
>>>>>>>>> modes. With BIOS
>>>>>>>>> mode, you can also try something like 640x400 or 640x480, below that 
>>>>>>>>> the terminal
>>>>>>>>> will get too weird even with 6x12 font...
>>>>>>>>> If depth 8 or 15/16 does not make it faster, it still means there is 
>>>>>>>>> something
>>>>>>>>> weird going on, and at this point, I’d suggest to check if there is 
>>>>>>>>> firmware
>>>>>>>>> update from vendor. (tbh, firmware update would be good as first 
>>>>>>>>> check, the hw
>>>>>>>>> vendors are known to produce a lot of bad things, especially if it 
>>>>>>>>> comes to have
>>>>>>>>> bios emulation with uefi csm.).
>>>>>>>> Sure. Good point. But already updated it. You've given me some things 
>>>>>>>> to poke at.
>>>>>>>> I'll give them a try, and see if anything interesting develops.
>>>>>>>> Thank you very much for taking the time, Toomas. Greatly appreciated!
>>>>>>> Well, I wrote that stuff;)
>>>>>> You seemed like a nice person. It's a pity I have to hate you now for
>>>>>> doing that. ;-)
>>>>>> Seriously tho. After some 5 days now poking at this, and only getting 
>>>>>> marginal
>>>>>> improvements via different framebuffer settings (BTW how does one make 
>>>>>> a
>>>>>> framebuffer setting stick from boot to boot?).
>>>>> add framebuffer set … to /boot/loader.rc.local
>>>> Thank you. I think you may have already told me that too. Sorry.
>>>> But TBH, the differences are negligible. So I think my time is probably
>>>> better spent tracking down the cause. :-)
>>>>>> It occurred to me that I didn't recall having any of these problems on 
>>>>>> earlier
>>>>>> SunOS/Solaris, or Illumos/OI installs. So I decided to walk back in 
>>>>>> history,
>>>>>> and see if I could discover where the problem left/started. So, always 
>>>>>> choosing
>>>>>> text install images, I went from OI-hipster-text-20201031.usb, to
>>>>>> OI-hipster-text-20200504.usb, to OI-hipster-text-20191106.usb, and 
>>>>>> BINGO!
>>>>>> Everything worked perfectly. The time to the boot options menu/banner 
>>>>>> was
>>>>>> *instantaneous*. So I figured I'd simply walk the commits going forward 
>>>>>> to
>>>>>> discover what introduced the slow screen writes.
>>>>> hm, that is interesting finding.
>>>>>> On OI-hipster-text-20201031.usb:
>>>>>> % time ls --color=force -Cla /usr/include/
>>>>>> took 22.4s
>>>>>> On OI-hipster-text-20191106.usb:
>>>>>> % time ls --color=force -Cla /usr/include/
>>>>>> 0.000u  8.270s  0:08.28  99.8%
>>>>>> That's 3 times faster!
>>>>>> Finding that many of the tools I need weren't available because I 
>>>>>> needed
>>>>>> to bootstrap a newer version of pkg. I did the unthinkable, and issued
>>>>>> pkg update -v
>>>>>> Which of course required a reboot into the new environment. The results
>>>>>> of the new environment was unrewarding. Getting to the boot options
>>>>>> menu/banner screen took nearly 9 minutes. Now I'm back to square 0. :-(
>>>>>> Altho illumos-3c2328bf3b:
>>>>>> % time ls --color=force -Cla /usr/include/
>>>>>> 0.008u  8.999s  0:09.11  98.6%
>>>>>> Which is *technically* slower. The difference is negligible for sure.
>>>>> That's just two samples, you need more to draw conclusions:)
>>>> I only _post_ 2 samples. I must have towards 50. But they were
>>>> close enough to simply pick the first in these 2 installs. :-)
>>>>>> But the fonts don't seem as smooth. In all cases the EDID was read
>>>>>> correctly (1920x1200 @32bpp). OH and if it matters, it's on an Intel
>>>>>> chipset (Intel video).
>>>>>> Time to (re)install OI-hipster-text-20191106.usb and start over.
>>>>>> Any thoughts? Best places to look? I'd love to shorten the timeline
>>>>>> to a (correctly) working install of OI. 7 days and counting.
>>>>> Is it BIOS or UEFI setup? if bios, then all you need is to copy 
>>>>> /boot/loader from
>>>>> older BE (beadm mount OLD /mnt; cp, then beadm umount). Just in case, 
>>>>> make copy of
>>>>> existing one.
>>>> Thanks! Good idea. I could probably choose the previous env from the 
>>>> loader,
>>>> and mark it default.
>>>>> But, there are few things to keep in mind.
>>>>> loader and kernel console draw are different things, the ls itself got 
>>>>> some fixes recently.
>>>>> So, is the performance degradation actually hitting only loader?
>>>>> Can you please mail me output from: tr '\0' '\n' < 
>>>>> /system/boot/environment
>>>> Will do.
>>>> Thanks for taking the time to reply, Toomas! :-)
>>> OK we have a winner! Thanks to some advice from Toomas:
>>> adding: console=text to /boot/conf.d/console
>>> which I later moved to /boot/loader.conf.local (console="text")
>>> followed by commenting the console= line from /boot/default/loader.conf
>>> I now have speed to boot menu that is close to the
>>> OI-hipster-text-20191106.usb install I mentioned earlier in this thread.
>>> While the screen still isn't as fast as the other some half dozen OSs
>>> I use. It's not so slow I can't work with it. :-)
>>> So a HUGE thanks go out to everyone here on the list, that chimed in
>>> to help out -- THANK YOU! :-)
>>> 
>>> @moderator
>>> Please mark this solved. ;-)
>>> 
>> 
>> 
>> The issue is still up, we do need better way to pick up serial config (ACPI 
>> SPCR);
>> but workaround is good to have.
>> 
>> Note, you do not need to have console=text in config if you have commented 
>> out the
>> /boot/defaults/loader.conf line; however, defaults will be replaced by next
>> update.
> Well commenting the line in /boot/default/loader.conf seemed to prevent it 
> from
> polling for other possibilities. Of course I could be wrong. I'll check to 
> confirm.
CONFIRMED
adding console="text" to /boot/loader.conf.local does NOT negate the
ttya,ttyb,ttyc or ttyd entires in /boot/default/loader.conf if left 
UNcommented.

What's the magic incantation? :-)

>> 
>> rgds,
>> toomas
--Chris
-- 
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX