Re: 10.0 on VE-900

Hi,

Our current C7 temp driver relies on datasheet for VIA C7-D CPUs which
may not apply for VIA Nano and above (though for my only board with
C7-D it also shows zeros...). Linux has a different approach by
reading MSR registers (undocumented), which reads different ones for
C7 and Nano. I once started writing a patch to do similar thing on
NetBSD, but it have never been finished. May come back on that some
time in the future. Registering a bug report would be helpful too.
Thus, for now I would consider that NetBSD temp driver won't work with
at least for Nano CPUs and above.

Regarding wsbell it's something I haven't observed myself. Can you
describe more on how to reproduce it? Are there any logs available or
the full system just completely freeze?

On Sun, Apr 7, 2024 at 2:34 AM Rui-Xiang Guo <[email protected]> wrote:
>
> Hi,
> For testing padlock and viac7temp, they are added into
> sys/arch/amd64/conf/GENERIC by this patch:
> ===================================================================
> RCS file: /cvsroot/src/sys/arch/amd64/conf/GENERIC,v
> retrieving revision 1.599.4.5
> diff -r1.599.4.5 GENERIC
> 90a91
> > padlock0      at cpu0         # VIA PadLock
> 91a93
> > viac7temp*    at cpu?         # VIA C7 temperature sensor
>
> I also load viadrmums before booting, the dmesg is uploaded to:
> https://dmesgd.nycbug.org/index.cgi?do=view&id=7632
>
> No such luck, envstat does not show values from viac7temp:
>                  Current  CritMax  WarnMax  WarnMin  CritMin  Unit
> [acpiacad0]
>     connected:      TRUE
> [viac7temp0]
>   temperature:     0.000                                      degC
> [viac7temp1]
>   temperature:     0.000                                      degC
>
> Another problem, it causes system to freeze when beep is triggered if wsbell
> were loaded. They are shown in dmesg as below:
> wsbell0 at spkr0 mux 1
> wsbell1 at spkr1 mux 1
> wsbell2 at spkr2 mux 1
>
> -rxg
>