> On 7. Feb 2021, at 20:20, Chris <oi...@sunos.info> wrote: > > 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.
oh, but there is;) if you enter command ‘console’ or set console=, you will get list of available console types and current settings, “null” console is silent one. But if you set it, there are few things you need to keep in mind: 1. kernel does only know about text and ttyX, if nothing is set, it defaults to ttya. 2. console variable is used for both loader and kernel, in case of multiconsole, our kernel does not support it, and it will use the first entry from list. 3. variable os_console will allow you to set console for kernel, that will allow you to set console for loader and os_console for kernel. rgds, toomas _______________________________________________ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
