smxi is a user on You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.


Issues debugged, now working on device without errors. Just a few things needed fixing.

Testing an system with on forums, didn't expect to get MIPS response, but that's why it never hurts to ask. openwrt is presenting problems, it appears to have an ultra stripped down busybox, and more packages have to be installed to even get inxi running, and there are some real problems, but it is generating relatively error free output, until a kernel thing crashes the networking. Early days.

Added pci device info, from pcidump, in in dev , seems to be working.

OpenBSD's pcidump has very little pci data however, less than FreeBSD's pciconf, so I can't match the IF to the PCI NIC as with GNU/Linux and FreeBSD.

But it works. Requires root to run pcidump, which is too bad, will have to add error message for pcidump noting requires root if not root.

Updated for other unix variant identifications, so will not crash or show error/warnings when started on one of those OSes.

My goal with BSD/Unix is basically for all error handlers and null data handlers to work as expected, and to have at least OpenBSD and FreeBSD + FreeBSD variants roughly working. Given the lack of consistent tools / data sources, that's about as far as I'll go unless someone pays me for my time.

I may also look at NetBSD just because that would cover the 3 main BSDs.

I gave a quick check for support, because of @distrotube review yesterday. After fixing a failed BSD ID, I quickly determined that SunOS/OpenSolaris/OpenIndiana aren't going to be getting much if any support beyond the null data handlers kicking in correctly, which they do.

These BSDs come from a different era, and actually expect people to learn tools and logic that applies only to that single OS. They should collaborate, create shared tools to make a more consistent BSD interface.

Re 3.0.24, for the first time, I had to use cpu steppings to differentiate between kaby lake and coffee lake cpus, they have the same model IDs, so the only way you can roughly tell them apart is through stepping number. So that brings inxi into the present re cpu architectures.

Before tagging new version, threw in an updated CPU architecture dataset, finally found a place that correctly lists the cpu family, model data and is reasonably upto date.

This brings in zen+, zen 2 amd architectures, and coffee lake, tremont, goldmont, ice lake, cannon lake intel architectures.

3.0.24 released. Thanks anonymous Manjaro debug dataset user 'loki' for this report. This fixes the ram/memory report crash, and slightly enhances output for those corner case system boards that have memory arrays for non system memory, like video, cache, or flash.

When memory array is not system memory, now shows what its use is.

Added -Cxx cpu L1/L3 cache report as well. This requires dmidecode and sudo/root to use.

Extended system base to Parrot, but why did they change /etc/debian_version?

Bug fix for , encountered an unusual motherboard with memory arrays not related to system memory, an old laptop, this caused a break in memory output because it was expecting memory arrays where non existed.

This will be fixed in 3.0.24, which is coming soon.

Also realized I can pull in L1 and L3 cache from dmidecode if root, so added that to -Cxx output as well.

A few final changes, added -a as shortcut for --admin, which allows something like -Fxxxaz

Thanks to guys for testing and checking for glitches, and making a few last minute suggestions, like adding --admin to -v8, which is now the case.

Thanks to vascom, the inxi maintainer for making the suggestion (github inxi issue 160) to expand --admin -C to have more useful output.

USB output is now also much nicer and consistent between Hub and Device-x lines.

just did 3.0.23, revised USB output, vastly enhanced --admin -C cpu vulnerabilty output, and some more system base ids, including a new Debian specific one.

testing cpu bugs now:

Topology: Quad Core model: AMD GX-412TC SOC bits: 64 type: MCP
family: 16 (22) model-id: 30 (48) stepping: 1 microcode: 7030105
L2 cache: 2048 KiB
Speed: 600 MHz ....
Vulnerabilities: Type: l1tf status: Not affected
Type: meltdown status: Not affected
Type: spec_store_bypass
mitigation: Speculative Store Bypass disabled via prctl and seccomp
Type: spectre_v1 mitigation: __user pointer sanitization
Type: spectre_v2 mitigation: Full AMD retpoline

- feature request from maintainer, request for enhanced --admin -C cpu errata data.

This is a good idea, and should not be too difficult to carry out.

Look for it in inxi 3.0.23. Will give type and status of each cpu issue, like meltdown, spectre_v1 and spectre_v2.

This feature only works with newer Linux kernels.

smxi boosted

Some people give me playful grief because I have a pocket notebook that is never more than 10 feet away from me 24 hours a day and I frequently write down any random random thoughts that occur to me, lists, things I need to remember, interesting quotes, etc etc.

I must say, though, that despite being someone you could call “fully digital” for pretty much everything, starting to carry this notebook a few years ago has been one of the most life-changing oh great decisions I’ve ever made.

3 just came out, so I decided to test the system base feature on it, and discovered that has yet again changed the structure of their /etc/os-release file, adding in some more items.

Rather than play guessing games for proper LMDE system base detection, and other Debian based distro system bases, I decided to just add in a Debian base data generator. This is working in , though it probably won't hit master branch for a few weeks.

smxi boosted

A clean house is a sign of a broken computer.

3.0.22 also, more system base added, deepin and blankon, tedious process to match those.

3.0.22 now live. Features -Gxxx compositor version (if found, not many show version data), many more compositors, added more system tray type devices to -Sxxx info item

Fixed a big bug in networking where devices on the same bus id would show the same IF identifier because it wasn't checking the busid in the matching tool. Thanks anonymous debugger data sender!

Added more disk vendor IDs, the number of no name Asian vendors appears to be endless.

New desktop found, , from .

thanks anonymous debugger dataset, found a glitch in IF to Device match in network, in cases where a complex NIC with multiple BusIDs is running (4 in this case), inxi was showing only the first IF for all the cards, now it matches to bus id, vendor id, and chip id, for non arm/mips/sparc/ppc devices, to make sure it gets the right IF address per bus id.

Good timing on that debugger dataset (thanks skynet), just squeezing in that last patch and testing of it before inxi 3.0.22 goes live.