is wine-devel broken?

sorry my client is bouncing guys. something up with my net

polyex: Howdy!

Managed to get a new high-score on circus linux!

2007 pts, with all settings turned off.

what is that

sfox: Basically, it's just an open-source clone of circus. (Basically, breakout. But with an extra challenge.)

idk what either of those things are

sfox: en.wikipedia.org/wiki/Circus_(video_game)

polarian: correct

hi

ant-x

rwp re: power_profile and powerdxx. powerdxx does not work for me all, saying that I should use hwpstate_intel instead, which is a very different tool, neitehr compatible nor analogous to powerdxx.

ant-x, That's interesting. For me powerd ran without message but didn't do anything that I could tell. But then powerdxx ran perfectly on my Intel E3-1270 system.

To debug both I ran them in the foreground with verbose and they would give information about their status then.

heloo

fold, if you have a question, custom here is to ask it to the channel without waiting to be acknowledged.

rwp, Here is one example of the problem with powerdxx: <lonkamikaze/powerdxx #15>.

ant-x, Thanks for that example!

V_PauAmma_V: thanks

I was trying to solve something that resolved automatically

after installing a package

somehow pkg autoremove did something strange

ant-x, As I read that ticket "You can use that if you have issues with hwpstate controlling your CPU frequency." does not strongly inform me that hwpstate is now the frequency controller. It just does not jump out at me that that is what it says. I agree it does. But we the unwashed masses need more clarity in the communication.

rwp, The sentence before that was all I needed to know: "For CPUs that are supported by the hwpstate driver powerd++ is obsolete and in fact not possible, because the driver discards frequencies set via the sysctl interface."

That just says that things are broken though.

I am not proficient enought to understand it. Some other sysctl's are not working as well, e.g. I wrote the following: <wiki.freebsd.org/AntonShepelev/HP_15-bw0xx#bri_keys>.

Observe also the attitude: "To save you from more people like this..." <lonkamikaze/powerdxx #15#issuecomment-827599547> -- kinda strokes one's ego...

That's uncharacteristically rude verbage on Allan's part.

It's pretty obvious people are trying to get frequency scaling to work for them. The tool of choice has been powerdxx so people ask about it. Telling people that powerdxx does not work anymore is not going to help them!

Instead they should be clearly telling them that powerdxx has been replaced by hwpstate and that hwpstate should be doing this now. That would help people get on track.

rwp, and saving powerdxx developers from such people... Indeed, hwpstate_* does not provide the level of control and automatisation that powerdxx does (when it works, that is).

I am learning about hwpstate right here and now and know nothing about it.

Also there is a spread in releases. Sure there are people running 15-CURRENT. I am running 14. I was running 13. There are people here still running 12 too.

I continue to think that the release notes, that I have not reviewed for CURRENT yet, should clearly say that on newer CPUs they have switched from powerdxx to hwpstate if that is what they are doing. And it should point to documentation that allows people to do the things with hwpstate that they were doing with powerdxx.

rwp, I some suppose hwpstate should be taken for granted. By the way, it does not seem to work on a per-core basis on my laptop, either: <lists.freebsd.org/archives/freebsd-questions/2024-July/005473.html> .

Looking now I think they should stop saying that "no longer work as expected" is terrible communication. Because though absolutely true what it COMMUNICATES is that the user is screwed because functionality has been lost.

rwp, a regression has been observed, yes. /Sometimes/ this is inevitable, though.

Those who run v. 12, how are they supposed to upgrade to 15? What is the procedure of upgrading very old versions?

If hwpstate is the new thing, the only thing, and it does not work then I think the discussion should stop mentioning powerdxx entirely and just focus on hwpstate not working.

Nobody confuxed the two subjects together. The powerdxx problem was raised on Github, where I caught metioned of hwpstate, and started using that. I then asked a question about it on the mailing list.

Reading your email it seems that it is not possible to individually control cpu core frequencies. I don't know if that was possible before. Was it? It wasn't something I ever tried to do.

So far I either have low core count laptops where I am satisfied with all of them cores moving together. Or I have higher count servers where honestly the power difference is not important and they run at full speed most of the time.

ant-x, That type of upgrade has a few different strategies. One is to upgrade through the intervening major releases and follow the upgrade notes for each. Making sure to upgrade the boot code and such as that's the main failure. The bootloader needs to be updated to know about newer file system features and other things.

rwp, See the note at the end of the /Intel Speed Shift/ section: <docs.freebsd.org/en/books/handbook/config/#hwpstate_intel> .

That also allows etcupdate to merge in the configurations at each step.

rwp, whpstate claims to support that. No, it may not have been possible before, but powerdxx could control frequency based on temperature, and hwpstate can't...

Or one can treat the upgrade as an install of sorts. Upgrade complete and discard all previous etc configuration and simply set and configure the new configuration you desire. And also upgrade the bootlader to know about the new file system features.

ant-x, That section you cite does indicate pretty directly that that individual core frequency control is possible.

I don't know even where exactly the failure is: either hwpstate fails to effect per-core control, or sysctl is reporing the wrong numbers. Also observe from the man-page of hwpstate_intel that the frequecny control is /very/ indirect, via the .epp parameter: <man.freebsd.org/cgi/man.cgi?hwpstate_intel(4)> .

Re: upgrade complete: I should be very chary of discaring my hard-earned /etc configuration...

That is pretty indirect.

But I think most people have been satisfied with the way the Linux cpu governor does it and there are only a few general algorithms available there. ondeman, performance, conservative, and so on. That's probably good enough for most people.

May be, but the ability to specify a maximum termperature in powerdxx is very good.

It does feel like a big step backwards to lose that feature set.

And I wonder why it must be so. powerdxx can vary those .epp parameters to make sure the temperature is in range, can it not?

My personal purpose for the throttling is just to prevent the fan from whiting... For some reason or other, with .epp=100 on all the cores, a game fails to run via Wine, which makes me wonder how throtting may interfere with it.

hi does anybody works in the freebsd foundation

lastshell, I don't know, but you can try their official contact form: <freebsdfoundation.org/about-us/contact-us> .

ty

yw

ant-x, A game does not run in that case? How weird! I can't imagine how those might be connected. So bizarre.

rwp, Yes. The game (via Wine) works with .epp 85, but hands in the main menu with .epp=100 . Remineds me of the infamous Runtime error 200 in TurboPascal's CRT unit.

Instead of the Turbo button it needed the Slug button to slow things down at the start.

There have been 100 million dollar satellites destroyed because of similar overflow errors.

Yeah, I had a computer with a Turbo button, and an actual keyhole with a key in it, which caused my schoolmates to think it was started like an ingnition in a car...

Good night to all.