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

Fri Feb 5 17:54:24 UTC 2021

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?).
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.

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.
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.
> 
> rgds,
> toomas
--Chris

-- 
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX