Well, I've looked at the given link ( thank you Keith ) and wow it is interesting, there being a fairly frank discussion in a related bug thread. Some points of interest :
- the overall primary problem is these Linux drivers are not written in-house by Gigabyte/Asus/etc. So linux contributors must do that.
- a secondary problem is that mobo/chipset makers do not publicly expose much, if anything, about their own hardware. No data sheets. You have to be commercially 'on the inside of the tent' with an NDA and what-not to get a look at those.
- hence the effort so far has been reverse engineering from purchased mobo examples and much guesswork & high hopes, though with some trepidation.
- one cautionary tale quoted was a ( test ) driver that read from a chip register and that then caused a voltage spike in the memory chips causing irreparable damage to same. That was a register read, not a write ! So there-be-dragons down in the weeds on this matter. You can't just go looking around blindly, you have to know or be told key facts ( in commercial confidence ). Nasal daemons et al.
- this is not illegal or IMHO necessarily a bad thing. The makers have a right to try/keep some sort of competitive edge in their market. Protecting intellectual property is a big part of that. I get it.
Anyway, for my mobo at least, there is quite a bit less shown by the linux sensors command than can be viewed on the opening BIOS pages at boot up. So much more real-time sensor information is there, just not accessible via Linux when actually operating the computer at some decent pace/power.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
This has been the issue with Linux from the beginning. Being open source, no manufacturer will agree to let the secrets of the hardware be exposed to the competition.
But in Windows land, manufacturers will bend over backwards to accommodate the OS being used by the largest group of purchasers and NDA's protect the intellectual property.
All the Linux drivers are almost always reverse-engineered by the Linux end user community.
Only in very rare cases does a manufacturer develop their own hardware drivers.
Thanks for the posts Mike. Good to hear there has been further development along the lines of liquidctl which I used back in the day when I used AIO's.
Very nice to see that the app is packaged as an AppImage and Flatpak to take installation troubles out of the equation.
I have always been under the impression that a Epyc Rome CPU would be a better choice than a Naples CPU. Even the 7601.
Here is a review that puts some numbers on that impression.
Tom M
A Proud member of the O.F.A. (Old Farts Association). Be well, do good work, and keep in touch.® (Garrison Keillor) I want some more patience. RIGHT NOW!
Assuming you can work around the bad ram channel would this make a good crunching CPU? (64c/128t).
A Proud member of the O.F.A. (Old Farts Association). Be well, do good work, and keep in touch.® (Garrison Keillor) I want some more patience. RIGHT NOW!
Well, I've looked at the
)
Well, I've looked at the given link ( thank you Keith ) and wow it is interesting, there being a fairly frank discussion in a related bug thread. Some points of interest :
- the overall primary problem is these Linux drivers are not written in-house by Gigabyte/Asus/etc. So linux contributors must do that.
- a secondary problem is that mobo/chipset makers do not publicly expose much, if anything, about their own hardware. No data sheets. You have to be commercially 'on the inside of the tent' with an NDA and what-not to get a look at those.
- hence the effort so far has been reverse engineering from purchased mobo examples and much guesswork & high hopes, though with some trepidation.
- one cautionary tale quoted was a ( test ) driver that read from a chip register and that then caused a voltage spike in the memory chips causing irreparable damage to same. That was a register read, not a write ! So there-be-dragons down in the weeds on this matter. You can't just go looking around blindly, you have to know or be told key facts ( in commercial confidence ). Nasal daemons et al.
- this is not illegal or IMHO necessarily a bad thing. The makers have a right to try/keep some sort of competitive edge in their market. Protecting intellectual property is a big part of that. I get it.
Anyway, for my mobo at least, there is quite a bit less shown by the linux sensors command than can be viewed on the opening BIOS pages at boot up. So much more real-time sensor information is there, just not accessible via Linux when actually operating the computer at some decent pace/power.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
This has been the issue with
)
This has been the issue with Linux from the beginning. Being open source, no manufacturer will agree to let the secrets of the hardware be exposed to the competition.
But in Windows land, manufacturers will bend over backwards to accommodate the OS being used by the largest group of purchasers and NDA's protect the intellectual property.
All the Linux drivers are almost always reverse-engineered by the Linux end user community.
Only in very rare cases does a manufacturer develop their own hardware drivers.
Found what I wanted all
)
Found what I wanted all along : a GUI view of system state on linux. As provided by Coolero :
You can also set the fan temp/speed profiles, plus the pretty lights.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Thanks for the posts Mike.
)
Thanks for the posts Mike. Good to hear there has been further development along the lines of liquidctl which I used back in the day when I used AIO's.
Very nice to see that the app is packaged as an AppImage and Flatpak to take installation troubles out of the equation.
Will see if I can get it
)
Will see if I can get it working, never tried AppImage and Flatpak stuff.
JohnDK wrote:Will see if I
)
You should try an AppImage app. Flatpak you have to deal with the Flathub repository.
For you to get a feel for an AppImage application, try out this clone of CPU-Z.
CPU-X
Or install it from the Ubuntu 20.04 repo
apt install cpu-x
There is more information on
)
There is more information on installation here.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
I have always been under the
)
I have always been under the impression that a Epyc Rome CPU would be a better choice than a Naples CPU. Even the 7601.
Here is a review that puts some numbers on that impression.
Tom M
A Proud member of the O.F.A. (Old Farts Association). Be well, do good work, and keep in touch.® (Garrison Keillor) I want some more patience. RIGHT NOW!
One missing ram channel. Make
)
One missing ram channel. Make offer.
Epyc 7442 qs make offer
Assuming you can work around the bad ram channel would this make a good crunching CPU? (64c/128t).
A Proud member of the O.F.A. (Old Farts Association). Be well, do good work, and keep in touch.® (Garrison Keillor) I want some more patience. RIGHT NOW!
My advice. Don’t do it. You
)
My advice. Don’t do it. You have a working system, don’t mess with it and drop the CPU into the socket again.
_________________________________________________________________________