Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update WinRing0 #1

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update WinRing0 #1

wants to merge 1 commit into from

Conversation

mirh
Copy link

@mirh mirh commented Feb 27, 2017

You may also want to host/include complete linked sources to build the whole thing then, if you deem so.

@sweoggy
Copy link
Owner

sweoggy commented Feb 27, 2017

What are the changes from the version which is currently used? :)

@mirh
Copy link
Author

mirh commented Feb 27, 2017

Weeell.. Technically it's just about this.
Though, libs now come from vs15 so.. Who knows what changes microsoft might have brought up in last decade 😛

In other news, it was more of a ping to signal you about winring0 sources actually being alive again.
Which could be a bit more neatly integrated in the project as I said above.

@sweoggy
Copy link
Owner

sweoggy commented Feb 27, 2017

Now I wish I didn't ask lol 😅

Feel free to make the changes you are mentioning and I will merge them.

@mirh
Copy link
Author

mirh commented Feb 27, 2017

I haven't all that faith in me tbh.
If you are out of time (too!) though, I guess we'll have to wait for either to find some then :s

@mpollice
Copy link

If I may chime in here. One Problem with WinRing0 is the need for a certificate for the driver. I always had the source sitting around here (found it on some forum somewhere years ago) but you can't simply rebuild the driver. mirh you explained this in your forum post also. Hence I never bothered to include the source of the library/driver into this project and just provided a link to the binaries.

Speaking about the project in general (sorry for being off-topic here), There are some things I always wanted to add to it but never had the time to (proper support for newer Fam15h, Fam16h support where I lack the hardware and more recently Fam17h, also lacking the hardware right now). At one time I had a working branch with GPU-related functionality (reading the GPU p-states table) and stuff that was added in Richland (cTDP), but these things were never completely finished and/or didn't work, also due to limitations of the hardware I had (cTDP seems to depend on platform support on top of basic support in the APU).
I might merge back some of the changes made in several forks once I get the time. However, some of the changes made I don't fully approve of (or maybe I need to give it a 2nd thought). That's fine, that's what open source software is about, You can fork it and apply your own changes. I'm just wondering for example, whether there could be confusion among users if say forks with different version numbers are around. Some community driven tools have fixed that issue with some additions to the name (like say "sweoggy Edition", just an example not a proposal), in other fields forks outright changed the name of the project. Just floating a few of my thoughts here. If you think we should discuss this elsewhere, I'm open to it but I'm no longer active on XS.

@mirh
Copy link
Author

mirh commented Mar 19, 2017

Hence I never bothered to include the source of the library/driver into this project and just provided a link to the binaries.

Well, this project is released under GPL3, so technically even if WinRing0 is "only" BSD, I wouldn't want to make uncle richard sad.

Tbh, I don't think binaries should ever have a place in sources to begin with (then when releasing binaries, you can do whatever you want).

I'm just wondering for example, whether there could be confusion among users if say forks with different version numbers are around.

Yes and no. I see what you mean, but thankfully, at least in my wanderings it always looked like newer forks always managed to retain features added in previous ones (or if any, at least this seems true for this compared to all the other deads).

Obviously, nothing is stopping uninformed people that stumble over that version or the other, to just use it.. Period. But in the meantime for those that manage to even realize there are multiple versions.. Just the most simple "checking at release date" seems already a pretty good indicator of what they should use.

If you think we should discuss this elsewhere, I'm open to it but I'm no longer active on XS.

Oh, now I got who you are... Well, I don't really mind personally (even though an issue or this would probably result in a tidier chatting)

But I don't know yours or @sweoggy's plans, and.. If you had the time to "stick to the scene", perhaps you could form a common organization or something?
Maybe you could also bring in the porter of the linux version https://github.com/danfe/amdmsrtweaker-lnx

@mpollice
Copy link

For precisely what you said I never put the WinRing0 libraries into my repository for this project. The other reason would be I don't believe in committing binaries to a source repository, but that's a philosophical debate. It seems we agree on this. The releases feature of Github could be used though, I think. What I meant is I also never considered it to be a good idea to commit the sources of WinRing0 either. Both due to licensing concerns and there being no real use due to what I said regarding the need of a certificate for the driver.

I just roughly explained my plans but to be honest they are not very concrete aside from the general goals. Currently I don't feel like creating an organization so I'm fine with several forks pursuing different goals. In fact this was the intention when putting it on Github (the original creator licensing it under GPLv3 also played a role ofc). Too often I have observed closed source community projects that got abandoned in this area.

Funny you link this, because I knew the original Linux fork here https://github.com/johkra/AmdMsrTweaker
This is a fork of this fork extending it further. I actually had plans to merge Linux support in some way or another, but never had the time either to make the project truly cross-platform.

Lastly thanks for reminding me there is another major forum related to tweaking computer hardware ;-)

@mirh
Copy link
Author

mirh commented Mar 20, 2017

Both due to licensing concerns and there being no real use due to what I said regarding the need of a certificate for the driver.

Winring0 uses a Simplified BSD License, which is GPL compatible.
Besides, tbh, at least up to some months ago (#thanksMS #W10shit) it wasn't really all that of an immense deal to get yourself a certificate.

As you say, github releases certainly are a godsend here.

Currently I don't feel like creating an organization so I'm fine with several forks pursuing different goals.

I mean, sure. At least though.. Agree if the development should continue on yours or his!

Too often I have observed closed source community projects that got abandoned in this area.

I totally see you. I feel so dreadful sometimes, thinking how much time was wasted reinventing the wheels.

I actually had plans to merge Linux support in some way or another, but never had the time either to make the project truly cross-platform.

Well, let's see what they think =) @johkra @danfe

Lastly thanks for reminding me there is another major forum related to tweaking computer hardware

Lol, tbh it's mostly google that lead me there.

@danfe
Copy link

danfe commented Mar 22, 2017

Thanks for the highlight, I'm very interested in the tool and look forward for its further development, as well as merging all OS-specific forks (Linux, FreeBSD) into one true upstream.

I actually had plans to merge Linux support in some way or another, but never had the time either to make the project truly cross-platform.

In fact, it seems totally doable, given how nicely those system-specific pieces are isolated, and how clean and portable the remaining C++ code is. I can crank a patch (to add Linux+FreeBSD support) and file an issue if that what it takes.

I'm just wondering for example, whether there could be confusion among users if say forks with different version numbers are around.

That was precisely the reason why I sticked to the original version number: to give end-users less things to worry about when comparing results across different operating systems.

I guess I cannot comment much on the Windows side of things, apart from #thanksMS #W10shit, keeping binaries in the repo is indeed bad (the first thing I purged after forking), yet "drivers now had to be certified what shall we do well that's your pain" (yeah that's pretty mean). I don't known enough about Win10, or if particular code in question being BSD-licensed plays any significant role in this case.

@colin1497
Copy link

I know this is a side project for everyone, and I don't know if it is still alive for any of you, but I'm diving in here since this seems to be the most active discussion thread I can find and has all the active developers.

It seems that the spring release of Windows 10 has killed functionality here on my 860k - running Mirh's test release (including his winring0 build or not including it) I get "ERROR: cannot read from PCI configuration space (F0x0)" and running other versions or K15TK I get BSOD.

@mirh
Copy link
Author

mirh commented Jul 20, 2017

I'm not sure I can be considered a developer, anyway

It seems that the spring release of Windows 10 has killed functionality here on my 860k

Meaning the Creator's Update?
I wouldn't know. It may be as well the SecureBoot nazi-enforcing of certificates.
shauleiz/vXboxInterface#7 (comment)
Plus you reinstalling the system or something.

and running other versions or K15TK I get BSOD

Well, that means something is getting loaded in that case after all.

@colin1497
Copy link

colin1497 commented Jul 21, 2017

Yes, Creator's Update. I hate the names -- 1703.

With the original build from mpollice and K15TK I get BSOD, with your files I get the "ERROR: cannot read from PCI configuration space (F0x0)."

I haven't had a chance to dig much further, but the original build and K15TK both worked (mostly) prior to 1703. As I recall, I could get it to BSOD in some cases, but I figured out that if I was careful and only did certain things it would play nice. What was working then doesn't work now.

@mirh
Copy link
Author

mirh commented Jul 21, 2017

There shouldn't be really a lot of differences between this slightly updated build and older ones.. So I suspect this would crash too, if it got loaded.

Could you check windows event viewer for reports about this driver?

@mpollice
Copy link

I have my release in use on machines with 1703 without any issue. Most of them are not set up to use Secure Boot though, so this is the only reason I can imagine right now.

@colin1497
Copy link

colin1497 commented May 18, 2018

Circling back to this with 1804 because I really missed my lower voltage states. Can't go back to older versions and check, but I'm able to set all pstates EXCEPT P3. I don't know if I failed to figure this out before or if something has changed. So, this works:

AmdMsrTweaker [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected]

This crashes the machine:

AmdMsrTweaker [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected]

When I first started using this, the latter version worked.

Yes, I know this is an ancient machine at this point.

Edit:
The above is with the original mpollice 1.1 version.
With sweoggy version I get "ERROR: WinRing0 initialization failed"
With sweoggy version and winring files from mpollice version I get "ERROR: cannot read from PCI configuration space (F0x0)"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants