On 2021-02-07 01:48, Toomas Soome wrote:
On 7. Feb 2021, at 09:04, Chris <oi...@sunos.info> wrote:
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 <oi...@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 <oi...@sunos.info> wrote:
On 2021-01-30 02:28, Toomas Soome wrote:
On 30. Jan 2021, at 10:39, Chris <oi...@sunos.info> wrote:
On 2021-01-30 00:03, Toomas Soome wrote:
On 30. Jan 2021, at 09:40, Chris <oi...@sunos.info> wrote:
On 2021-01-29 22:24, Toomas Soome via openindiana-discuss wrote:
On 30. Jan 2021, at 03:43, Chris <oi...@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? :-)
When the interpreter is starting, we read in and process the following
config
files and in listed order:
/boot/solaris/bootenv.rc # managed by eeprom command
/boot/defaults/loader.conf # defaults from pkg
/boot/loader.conf # if present, distribution defaults from pkg
/boot/loader.conf.local # user settings, if present
/boot/conf.d/* # user settings by snippets
/boot/transient.conf # one time settings created by reboot command,
automatically removed on boot.
This means that anything you set in later file (like in
/boot/conf.d/somefile),
can override previous setting. However, for console, as there may be some
output
while processing each file, “bad” setting in /boot/defaults/loader.conf can
cause
issues till replaced in later file.
That's what I thought. Much the same as on FreeBSD. I was hoping I might
learn
that there was a no_console= or console_ttya="NO" line that might be
available.
I guess commenting the line /boot/default/loader.conf is the current
solution.
Remembering to re-comment it following updates.
Thanks for the reply, Toomas.
rgds,
toomas
--Chris
--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
