Process CPU state not shown on MacOS

[BenBE]

Sorted by CPU, but it doesn't shows it correctly which process is taken CPU:

I've builded rust from mac ports.

Originally posted by @sharewax in #446 (comment)

[sharewax]

Apple M1 Silicon btw, Big Sur 11.3.1.

[BenBE]

@sharewax: Can you test if the CPU state (the column labelled S left to the CPU%) has been showing previously on some release version and if so, on which one? You can get to the various release versions quickest by cloning the git repository and checking out the various tags.

If you find an old version that worked. it'd be also really helpful if you could do a git bisect from there. If you need some assistance with that, feel free to ask.

[sharewax]

Checked back to 2.1.0 version (2018 year) - it doesn't show correct state. Does it have sence to check more? Probably not.
My main question was not about state, but about CPU percent - because it's shows 0.4% for firefox and 0.0 for rustc during compilcation.

[BenBE]

Ah, k. In that case I misunderstood you on that part. Nonetheless, the missing state information is something that probably should be fixed. Given that it's been broken for that long strongly hints it never worked.

Regarding the (far too) low CPU usage display, that's probably still some issue with either the read-out or some conversion. Unfortunately I don't have any Apple hardware myself, thus someone else will have to have a look into this.

[risentveber]

To get correct process status S requires to disable SIP csrutil disable (in recovery mode), and after rebooting just start sudo htop - see original hishamhm/htop#701, I think it may help

[sharewax]

Currently it works much better than it was:
regular user

sudo htop

htop version 3.1.1

[BenBE]

This issue is about the S (state) column only showing ? …

[sharewax]

Sorry, my initial bug was about percents of CPU usage. But we found that states doesn't work too.
Currently percents counted normally, but states no.

[BenBE]

@sharewax Glad to hear the CPU utilization issue got fixed. I split out this one from #446 to avoid mixing different issues in one issue.