[OpenIndiana-discuss] How to get a usable console on OI?

[Joshua M. Clulow]

On Sun, 24 Jan 2021 at 21:13, Chris <oidev at bsdos.info> wrote:
> On 2021-01-24 18:53, Chris wrote:
> > On 2021-01-24 17:48, Joshua M. Clulow via openindiana-discuss wrote:
> >> On Sun, 24 Jan 2021 at 17:27, Chris <oidev at bsdos.info> wrote:
> > All the reports I've seen thus far, indicate 800x600.
> > You're suggestion confirms it:
> > ts_p_dimension = {
> >     ts_p_dimension.width = 0t800
> >     ts_p_dimension.height = 0t600
> > }
> > ts_pdepth = 0t32

Based on that, I don't imagine trying to drop the resolution is really
going to help.

> > I'm booting via BIOS. While the CPU may be involved. I would have
> > imagined that the cycles would be on the GPU. Which should be more than
> > adequate to run high frame rates.

With the current framebuffer console code we have, I believe we
basically map a region of the video RAM into the host physical address
space.  The terminal emulator in the kernel which runs on the CPU just
copies pixels (bytes, really) from the region in memory where we store
the font into the right place in the mapped region to make it all show
up on the screen.  I don't believe the GPU is really being used for
anything, at least directly.

Does this system support UEFI booting as well?  It may help to get the
entire contents of the "tems" object to get us more detail about
exactly how the console is set up; e.g.,

    # mdb -ke 'tems::print -d'

> > Thank you *very* much for taking the time to reply!

You are most welcome!

> > I'll dump some mpstat data to file, and see what (if anything) pops up,
> > and report what it contains.

I have taken a look at your mpstat output, and it does indeed seem
like between ~09:02:23PM and ~09:02:44PM (a period of around 20
seconds) one CPU was spending 100% of its time executing kernel code
(the "sys" column).  This matches up with the ~20 seconds of sys time
(the 23.223s) in the output of "time ls" you also posted.

As it seems this is pretty reproducible, the next thing I would do is
figure out what we're doing in the kernel for that 20 seconds.  You'll
want to use DTrace to capture kernel stacks; e.g.,

    # dtrace -x stackframes=100 -n '
        profile-997 /arg0/ { @[stack()] = count(); }
        tick-60s { exit(0); }' -o out.kern_stacks

That will capture the stack of what's running in the kernel (if the
kernel is running at the time) on each CPU, 997 times per second, for
60 seconds.  While that's running, kick off the "time ls" again.  Take
the "out.kern_stacks"  file and pass it through the flame graph
generator; e.g., something like:

    $ ./stackcollapse.pl out.kern_stacks | ./flamegraph.pl > output.svg

You can open "output.svg" in a web browser and inspect the aggregated
view of all the stacks.  It'll probably be small enough to attach to
an e-mail here.

Note, the perl scripts above, and more detailed instructions, are all
up on GitHub:

    https://github.com/brendangregg/FlameGraph#dtrace


Cheers.

-- 
Joshua M. Clulow
http://blog.sysmgr.org