CPU frequency in OpenBSD? about inxi

[GoogleCodeExporter]

I'd have to see the debugger data for: inxi -xx@14
run as regular user and as root, ie, run twice.

I have almost no datasets from openbsd, if I have one I'd be surprised. I had 
short term access to an openbsd system which is how I got some of the stuff 
working for openbsd, or did I? Maybe, I can't remember.

Without a full dataset I can't do any debugging, though openbsd was harder than 
freebsd because there was less information readily available, though neither is 
anywhere as data absent as osx, which I played with for a day just to see if 
it's still a bsd, my conclusion is, no, it's not, except in name.

Generally with openbsd I prefer to get patches because I have no access to an 
openbsd system, but with a full, complete, data set from user/root I have 
enough to at least see what's possible. There is a limit though because the bsd 
ecosystem is so fragmented re its tools and outputs and methods that inxi has 
to limit what is supported there to the main players, which is something that 
disappointed me to discover to be honest.

Original comment by [email protected] on 31 Aug 2014 at 6:46

[GoogleCodeExporter]

re the stuff you showed, there's not enough there to create a row item for the 
cpu, no cpu version info. That doesn't mean there isn't the info, it just means 
I need the full dataset to determine if it's possible. I'd have to check the 
full outputs to see if there's anything else present. Freebsd had just enough, 
though it's also not complete  at this point re the cpu line, I just got a 
sample a few days ago so I may be able to figure out what made its line missing 
some pieces. Freebsd and Openbsd are the only bsds I'll personally spend any 
dev time on issues (I have ongoing userspace access to a freebsd server, so I 
can test updates etc, but I have zero ongoing access to an openbsd system), 
otherwise it's going to be patches received and implemented for any other bsd, 
their marketshares are simply too small to warrant time on my part.

Original comment by [email protected] on 31 Aug 2014 at 6:53

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Ok, I'm not sure why google code didn't accept my email response with 
attachments, but here they are:

Original comment by [email protected] on 31 Aug 2014 at 7:43

Attachments:

• inxi-bsd-keyhole.local-20140831-142801-all.tar.gz
• inxi-bsd-keyhole.local-20140831-142842-all-root.tar.gz

[GoogleCodeExporter]

You mentioned not having an OpenBSD system you can test on...

Well, let's see if we can remedy that situation...   for obvious reasons I wont 
post the info here, but contact me via email if you're interested... 

Chuck

Original comment by [email protected] on 31 Aug 2014 at 10:07

[GoogleCodeExporter]

The datasets look good, thanks. I can see a fair amount of data I can add in, I 
just have to be careful to not break freebsd stuff while fixing openbsd stuff. 

I always appreciate ongoing active assistance re debugging and issues, datasets 
etc.

I don't have time this coming week to get into inxi hacking (it's VERY time 
consuming and difficult) but I will take you up on the openbsd access at some 
point soon, I assume email is break19 at ... so I'll email you when I'm closer 
to having time to start checking stuff, thanks for the offer, it's enormously 
helpful for me to get direct access, that's also how I did freebsd by the way, 
a few people gave me logins to their systems. 

I'm actually signficantly encouraged by what I see in the boot and sysctl 
outputs and I think I'll be able to get bsd stuff, particularly openbsd, 
improved significantly, which is why I'm not going to start it for a while, I 
know what happens when I get into inxi hacking, lol, and it's always time 
consuming, particularly when I get real support/features added.

I'm happy to see the new ram -m feature worked, I never got that tested in 
openbsd/freebsd, but it looks like it worked exactly as expected. I did quite a 
few core improvements to that area, though there's still some weird glitches 
with error handling that I am somewhat confused by.

There's also a glitch with openbsd df, apparently openbsd df is slightly 
different, but I have to look at the datasets to see where the difference is.

I should add a simple list of options for each command in the debugger, ie, run 
df --help > something.txt 

There's also a gawk error that is strange.

Re the sensors stuff in sysctl, that's largely out of the scope of what inxi 
shows for sensors, I looked into any possible sensors type cli tool in bsds but 
didn't really find anything like lm-sensors, which is already a massive pain to 
do because the range of data formatting is massive, and seems to be totally up 
to the hardware vendors, so that's the least likely thing to get support in 
bsds judging from how near impossible it is to do in lm-sensors already.

Original comment by [email protected] on 31 Aug 2014 at 10:37

[GoogleCodeExporter]

Note: inxi 2.2.2 cleans up a few of the bugs I saw on your system, and also on 
freebsd.

I added some openbsd debugger data collectors, pcidump as well.

This does not deal with the cpu errors/missing data items, but does clean up 
some actual bugs and stray debugger outputs I had left in by accident, which 
only triggered on bsd systems. It does correct the dmidecode error handler, so 
it will now show the correct error message.

Once I have more data I'll take a look at the actual lines and missing data 
items.

Original comment by [email protected] on 1 Sep 2014 at 11:30

[GoogleCodeExporter]

2.2.2-23-bsd ( update to bsd branch: inxi -! 15 )

Issues fixed:

1. -G null graphics card data fails to show failure message

2. -G graphics drivers fail to show unloaded status

3. -p / -P filesystem type 

4. -I used memory

5. -r ports/repo data

6. -f cpu flags

7. -C cpu data mixed up

8. -C cpu cache, if found, or shoes, correctly, N/A if not

9. -m/-M dmidecode error handling corrected

10. irregularities in output format of dmesg.boot, changed all = to : for 
consistency when gawk parsing.

And some other things.

Remaining, unfortunately it looks like pcidump requires root for openbsd, so I 
don't now how much time I'll put into that.

At least on this test system, the optical cdrom data is not correct, openbsd 
does something there i haven't seen anyone do, so that might require some 
further tweaks.

I did note that raw sensors data can be deduced from sysctl output, though 
there is zero way to know which sensor data applies to what.

That's all I have time for this week, I'll take a look later at the other stuff.

I'm a bit sad that pcidump requires root, I don't see why, pciconf and lspci 
don't. That's what generates the -A/-G/-N card data lines.

Original comment by [email protected] on 3 Sep 2014 at 1:17

[GoogleCodeExporter]

2.2.2-24-bsd ( update to bsd branch: inxi -! 15 )

Added cpu frequency, current.

Why each bsd has to have a different syntax for these things in sysctl is 
absolutely beyond me.

I'll definitely only personally support freebsd and openbsd in inxi, all other 
bsd versions that have issues where their different syntaxes break something 
here, will have to figure out for themselves what it is, and what is required 
to fix it, aka, a real patch, clean. I have no idea why such simple things 
can't be done more consistently.

Also by the way disturbing is that freebsd seems to have also changed output 
syntax and methods in at least sysctl, making even that unreliable in terms of 
parsing it for anything. A lot of the stuff I had working is now not working, 
already, in freebsd, due to various changes.

Original comment by [email protected] on 3 Sep 2014 at 1:27

[GoogleCodeExporter]

On Wednesday, September 03, 2014 1:17:34 AM you wrote:

Well, the pcidump is an easy fix. simply add a+r to /dev/pciX -- which I just 
did.  

And yes, lspci is available on OpenBSD as pkg_add pciutils -- also just did 
that as well. It doesnt want to behave yet, but I will see what I need to do 
for that.

Original comment by [email protected] on 3 Sep 2014 at 1:36

[GoogleCodeExporter]

as far as different sysctl goes? because each different BSD is a 
wholly-different operating system.  It's not like Linux with a single kernel 
and basically the same userspace, just different package managers and different 
'themes' or preferred GUI.

With that said, you likely do NOT need to ever modify the script to work on 
OpenBSD ever again once you get it all good.. Open does NOT change things 
without a damn good reason.  One of the reasons I have begun to prefer it over 
FreeBSD.

Original comment by [email protected] on 3 Sep 2014 at 1:55

[GoogleCodeExporter]

the acpitz temp is the motherboard, the two kate0 reports are the CPU on-die 
temp.

FreeBSD has dev.cpu0.temperature iirc, for on-die temp, but supports far less 
as far as temperature monitoring goes.

Original comment by [email protected] on 3 Sep 2014 at 1:58

[GoogleCodeExporter]

Good to hear on openbsd not changing. In general I don't like adding features 
that require root, but given that on bsds -M requires root for dmidecode, and 
-m as well, I guess it doesn't matter as much.

I checked pcidump, it doesn't look very promising, it seems to be missing 
device type, which makes it very hard to parse, if not impossible.

there's a range of things that will probably not work in inxi, particularly 
with multiple cpu cores/multi cpu systems, I'd have to see a few datasets from 
systems like that to see what it looks like.

Even the cpu count is erratic, I think freebsd has it. That's why you see the ' 
core' starting the cpu line, that entire set of data is null so far. 

Original comment by [email protected] on 3 Sep 2014 at 2:48

[GoogleCodeExporter]

On Wednesday, September 03, 2014 2:49:07 AM you wrote:

hw.ncpu is number of cpu/cores on OpenBSD. Also, even when I run the script as 
root, it complains that dmidecode requires root :)

Original comment by [email protected] on 3 Sep 2014 at 3:04

[GoogleCodeExporter]

On Wednesday, September 03, 2014 2:49:07 AM you wrote:

Oh, one thing you may also consider: On -all- the BSD's the network card is 
referenced by the driver name.

Like, on my laptop, the wifi card is called iwi0 (which is an Intel Centrino 
2200bg family) the ethernet is msk(0) (which is Marvel Yukon family 
10/100/1000)

On the server you can access, the network card is nfe0 which is NVIDIA nForce 
MCP 10/100/Gigabit Ethernet device) You can "man nfe" to see chipset that 
driver supports.. same with man msk or man iwi

I would think simply putting the driver name there would suffice for most 
things. 

Original comment by [email protected] on 3 Sep 2014 at 3:14

[GoogleCodeExporter]

inxi is built to print out pci array type data, if I can't get it, I can't get 
it.

There's no way in current inxi to work from drivers to cards, sadly, or it's 
far too much work, so if there is no openbsd way to show pci data in a way that 
lets inxi know what each type is, like in freebsd or linux, then that probably 
will not happen.

Both Freebsd pciconf and linux lspci have identifiers that let gawk know that 
data for the various pci device types is starting, without that identifier I 
can't really show any data.

P: Network:   Card-1: Intel 82574L Gigabit Ethernet Controller (82574L) driver: 
em bus-ID: 0:6:0:0 chip-ID: 8086:10d3
P:            IF: em0 state: active speed: 1000baseT duplex: full-duplex mac: 
<filter>
P:            Card-2: Intel 82574L Gigabit Ethernet Controller (82574L) driver: 
em bus-ID: 0:7:0:0 chip-ID: 8086:10d3
P:            IF: em1 state: no carrier speed: N/A duplex: N/A mac: <filter>

That's from a freebsd system.

In theory I can use if type data just for network cards, but it's a pain to do 
a different method for each card, for just one OS, that gets nasty quickly in 
my opinion. I will say if I can't get the data in a reasonable way, I will 
leave it blank, that's for example why darwin/osx is almost all blank, lol.

I found and fixed a pci id glitch with freebsd, they use at least 2, and 
probably more, class=.... for network devices, but I have very finite sample 
sets, I'm always reluctant to do anything significant without multiple datasets 
from the os in question, I have one now from openbsd, I have some from freebsd, 
but most are incomplete.

Original comment by [email protected] on 3 Sep 2014 at 4:29

[GoogleCodeExporter]

On Wednesday, September 03, 2014 2:49:07 AM you wrote:

AHA! I see why it's not seeing the client.

It's not stripping the path name from the binary...

I added an ech of $App_Working_name just before the case/esac group, and check 
this out:

App_Working_Name = /usr/local/bin/quasselclient
CPU~ core Intel Pentium M () clocked at 1733 MHz OS~OpenBSD 5.6 i386 Up~2 days 
Mem~845.8/2038.4MB HDD~() Procs~88 Client~/usr/local/bin/quasselclient v0.10.0 
(dist-575f27e) inxi~2.2.2-29-bsd  

doesn't seem to be stripping the path.

Original comment by [email protected] on 3 Sep 2014 at 4:35

[GoogleCodeExporter]

"hw.ncpu is number of cpu/cores on OpenBSD. Also, even when I run the script as 
root, it complains that dmidecode requires root :)"

If it's complaining about dmidecode requiring root that's a bug or issue.

post another data set, inxi -xx@14
as root so I can see it.

It's hard to test systems when you don't have root, I  emulate the data using 
dmidecode files for testing when needed.

So far I'm seeing two Openbsd bash specific errors, ie, the errors are coming 
from openbsd's bash, not from gawk, error 1 is failure to give the shell 
version with inxi -Ixxx and error two is your failure to show quasselclient 
properly.

I believe both those have the same cause, specific to openbsd, though I'm not 
positive, but that's what it looks like to me.

Original comment by [email protected] on 3 Sep 2014 at 4:35

[GoogleCodeExporter]

I found the issue, it's a case that never triggers except in bsd.

I didn't trim off the /.. part in the bsd / fallback case, that's a case that 
will never trigger on linux systems.

2.2.2.-31-bsd should work for quassel now.

Original comment by [email protected] on 3 Sep 2014 at 4:48

[GoogleCodeExporter]

The shell version issue however I have not found the cause for, it makes no 
sense re why it doesn't work. I've run all the commands in cli directly and 
they work fine, so I'm not clear what is wrong there. The stuff works on 
FreeBSD as well.

Original comment by [email protected] on 3 Sep 2014 at 4:58

[GoogleCodeExporter]

Re sensors, because of experience, I will not touch bsd sensors until I have at 
least 20 datasets, at least 5 from different openbsd systems I'd say. Sensors 
are a near nightmare to handle due to the total lack of consistency in 
motherboard output data formats, which lm-sensors has to suffer with as well, 
though at least there are hints in sensors output of what is what.

Examples of what is required is multifan systems, systems with sensors for 
different components.

Same more or less goes for cpu stuff, to handle correctly smp/multi processor 
systems, I need data samples from a range of systems, ideally at least one from 
a multicpu system, different types of multicore systems, and multicore plus 
multicpu systems. I have a faint idea of how maybe it could work, but it 
requires a lot of datasets to actually see if that idea is right.

For example, if the core count is reliable, then you can count how many cpus 
you find in the output, like cpu0, cpu1, etc, but if those are sometimes just 
cores, not processors/cpu units, then it's harder. linux is fairly easy because 
/proc/cpuinfo is very reliable, the only thing hard there is with intel cpus 
with hyperthreading, which looks like 2 cores per core, but we have that 
handled due to large numbers of datasets.

To actually get a feature reliably working, I need at least 10 datasets from 
different systems, only one from a vm is required since they are all largely 
the same. The -m feature, for example, required 40-50 datasets to get stable, 
due the extreme unreliability of the dmidecode output, which is often a pure 
fiction invented by some overworked mobo company drone. Luckily those logic 
issues are cross platform, ie, it doesn't really matter what os it is, the 
problems are the same, so the fixes from linux systems work on bsd systems just 
fine.

i don't however like using dmidecode for data because it requires root, for 
example, in linux, -M machine data comes from /sys, which can be read in 
userspace, no root required. No such luck with -m, which needs root in all 
cases.

For now, there are two issues I want to fix before I call this bsd stuff good 
enough for now, one, figure out why bash logic is failing in the shell version 
section. I have one hint with openbsd, it's ps does not support -f, I think 
it's -f, freebsd ps does. That's a pain though because the different os 
versions show different output for the same options in some cases.

The second is to get a crude cpu count working on freebsd/openbsd, that will 
not try to deduce more data about the system like it does for linux systems, it 
will just show the cores present, and won't try to figure out if it's multi 
processor or single but multicore. That's the easiest short term fix I think.

Original comment by [email protected] on 3 Sep 2014 at 6:10

[GoogleCodeExporter]

Also is the problem of churn in output, for example, freebsd sysctl had an item 
for cpu L2 cache, and the latest samples I got do not, and it has not been 
replaced.

For the amd stuff you have, I was able to fake it by pulling the L2 cache info 
out of the model line, but that's not data that you can count on being there, 
and it's totally non reliable. To get the real L2 cache, you need a per core 
report of L2 cache, then you figure out how many cores, and add up the caches, 
to get the real cache. I don't believe that will ever be possible to do on bsd 
systems. 

These kinds of limitations are by the way why I stopped active dev on bsd inxi, 
though I don't mind fixing clear failures and bugs like we've done so far in 
this issue, but there is a limit because the tools has available in the bsds 
just are not very good. There isn't even, for example, one tool that gives you 
both physical memory installed and used memory, in openbsd, you have to combine 
two outputs for that. In freebsd, you can get both in sysctl, at least so far 
you can, unless they change it.

I do however like openbsd because of their ssh and libressl work, and their 
focus on real security, otherwise I wouldn't try to support it at all.

Original comment by [email protected] on 3 Sep 2014 at 6:19

[GoogleCodeExporter]

2.2.3 fixes the dmidecode root error, and also starts a new branch for bsd, the 
2.2.3 one, stable 2.2.3 contains all fixes for bsds etc, so 2.2.3-x-bsd patch 
series will contain the next set of fixes, when i get time to do them.

I may do the core count hack for now, then leave it alone for a while.

Original comment by [email protected] on 3 Sep 2014 at 7:15

[GoogleCodeExporter]

Btw, don't check for root, check for permissions if you can..  chmod'ing the 
specific device node to read by world lets dmidecode work as a user without 
sudo.

Just mention it in the help or --recommends portion of the script.

Original comment by [email protected] on 3 Sep 2014 at 7:59

[GoogleCodeExporter]

dmidecode parser was improved during the last round of fixes, now it redirects 
stderr to stdout and then simply reads the messages. If permission is denied, 
it gets root error message. 

I'm going to slowly move all inxi error stuff to that, before it used root/not 
root to determine what to do, but I realized that's not a good method because 
of permissions being flexible to some degree.

Good suggestion to note this on help/recommends, there's some things in inxi 
that use sudo if present, but I've never liked it. 

Original comment by [email protected] on 3 Sep 2014 at 8:15

[GoogleCodeExporter]

inxi 2.2.9 fully closes this issue, and way more re bsd support.

Further fixes were adding -d/-D support, multibsd support, dragonfly debugging, 
openbsd debugging, freebsd debugging.

All new bsd issues, start a new issue.

Original comment by [email protected] on 24 Sep 2014 at 2:14

• Changed state: Fixed