> 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;) rgds, toomas _______________________________________________ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss