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

[Chris]

On 2021-01-25 12:09, Chris wrote:
> 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.
Nope. The list ate that one too.
let's try:
https://sunos.info/out_kern_stacks_svg instead. :-)
> 
> 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