Re: 11 beta testing

[Van Ly <van.ly%SDF.ORG@localhost>]

RVP <rvp%SDF.ORG@localhost> writes:

> On Sun, 12 Oct 2025, Van Ly wrote:
>
>> At the moment btop reads 46degC and the following script reads 42.000, 43.000
>>
>
> Both envstat and btop read the same data, but, some variation is normal
> because these on-die thermocouples are a) pretty accurate and b) can instantly
> sample the current core temp. So you might see diff. values each time--even
> with envstat(1) alone. Try this cmd. a few times to see this:
>
> ```
> envstat -ns coretemp0:'cpu0 temperature',coretemp1:'cpu1 temperature'
> ```
>

That PR fixes btop-1.4.5.

The btop-1.4.4 I have running seems to only get the temperature reading
on startup and that number won't change after.  The envstat reading
fluctuates as expected.

>> The first thing I asked of the code assistant was for at tool to
>> flowchart the logic in envstat and btop but the friction and hoops to
>> jump thru lead to a timebomb.  I think it should be possible to infer
>> what's going with the kernel and the cpu temperature reading using an
>> initial schematic like the citric acid cycle
>>
>>   https://sdf.org/~van.ly/img/citric_acid_cycle.jpg
>>
>
> I can't figure out how the Krebs cycle relates to CPU temp. variance :), but,
> the way NetBSD gets this data is pretty simple:
>
> https://github.com/NetBSD/src/blob/trunk/sys/arch/x86/x86/coretemp.c#L359
>
> It just reads some MSRs on x86. The same values are passed to _all_ programs.
>

On YT there is this presentation

  "will wright gdc 2005 spore (the future of content) remastered"

playfully, coretemp.c line 359 to the next 30 lines could be visualized
as a `sinkhole' and the nearside has stage i context details of interest
in that diagram and the farside has the resulting temperature reading,
descending into the `sinkhole' pairs each line of C code to assembly
code sequence, kind of like function call or stack pointer manipulation.
The code assistant is able to line by line explain c code and would be
assembly code block.  The c++ btop implementation isn't as straight
forward to unpack.

Next, unexpected behavior observed but not heard.

The mixerctl audio volume control will set the following values

   outputs.master=183,183 volume delta=3
   outputs.master.mute=off  [ off on ]
   outputs.master2=183,183 volume delta=3
   outputs.master2.mute=off  [ off on ]

and after a while say 30 or 45 minutes

   outputs.master=255,255 volume delta=3

the first line will self reset to `255,255' but I don't hear a difference.

-- 
vl