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

[Chris]

On 2021-01-25 11:52, Chris wrote:
> On 2021-01-24 23:10, Joshua M. Clulow via openindiana-discuss wrote:
>> 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'
> Attached as mdb-ke
> 
>> 
>>> > 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
>> 
> OK I simply created an sh script (DTTRACE) with the contents above and
> fired it off as; sudo ./DTRACE &
> followed by; ls -Cla /usr/include
> which created: out.kern_stacks (attached).
> 
>> 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
> The results of the above are attached as: out_kern_stacks.svg
> I has somehow expected a longer spike on the graph, as the output of
> ls -Cla /usr/include took the same ~20 seconds to finish writing to the
> screen as before.
OK the list stripped the flamegraph file attached. So I'm attaching it as:
out_kern_stacks_svg.txt
in hopes it makes it through.

HTH

Thanks again! :-)

--Chris
> 
> Thank you very much all your helpful advice!
> 
> --Chris
>> 
>> 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.
> 

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