dmitriy.kazimirov/inxi
1
0
Fork 0
mirror of https://github.com/smxi/inxi.git synced 2024-11-16 16:21:39 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Thanks manjaro user alven for finding a bunch of corner and not so corner case

Browse source 
errors, glitches, documentation oversights, etc.

This is a point release between the coming full CPU refactor and the current
set of bug fixes and issue handlings.

This release also contains the debuggers for the new CPU data logic, which are
important to get this CPU refactor stable and reliable across old/new systems,
different operating systems and platforms.

Wanted to do this intermediate releaase to get the current fixes out, which
make inxi overall better for CPU issues, but do not handle the core requirement
to do a full refactor.

--------------------------------------------------------------------------------

CORRECTION:

1. On release notes for 3.3.08: due to a long delay to get real debugger data
from the person who had the issue, but finally getting it after the release of
3.3.08, there was NO bug in ps wwaux output. Something else was creating the
linewraps, maybe the subshell, it's basically impossible to know since we never
got a real debugger data set, which is the only real way to get the actual same
data inxi will see.

Was it a subshell wrapping the output? We just can't know, nor are we likely to
ever find out.

This highlights very well however why some issues are essentially impossible to
ever fully resolve without the --debug 22 dataset. This bug/fix is definitely in
that class of issues.

It's never good to accuse another program of having a bug when it doesn't, so
sorry to ps authors, no bug or issue exists for ps in this area.

--------------------------------------------------------------------------------
KNOWN ISSUES:

1. wiryonolau issue #259 points out that if --tty is used, default IRC filter
rule is still active and on. Because his case appears to be from an autostart
using Bash, which then gives up to find the parent at dash, which then makes
inxi believe it's in an IRC shell client, that issue doesn't appear to be
resolvable.

--------------------------------------------------------------------------------
BUGS:

1. Documentation, help menu and man page showed wmctl instead of wmctrl,
which for someone who reads the help man, leads to command --fake wmctl failing.
Thanks manjaro user alven for finding this typo.

2. For dmidecode cpu data, had global total values for cache that could result
in wrong output values, 2x or more wrong for L1 / L3 cache on linux. Difficulty
is preserving that data for bsd, which in general do not show phys cpu counts,
and thus make showing totals off. Created new '-total' item for each L cache
type, which will handle > 1 cpus, and also can be used to determine if > 1 cpus
present!.

3. Manjaro user pointed out that hub types were wrong, this is because inxi was
using the INTERFACE ID values for hubs instead of the TYPE values. For all other
device types, INTERFACE is correct, but for hubs, we needed TYPE, so fix is to
detect INTERFACE 9/0/0 and if TYPE present for that, swap.

--------------------------------------------------------------------------------
FIXES:

1. For > 1 cpu systems, with dmidecode sourced cpu cache data, can now determine
physical cpu count based on comparing L2 and L2-total values. This means that
when dmidecode is used on BSD for CPU data, inxi may now be able to deduce that
it is a > 1 cpu system.

2. Forgot to set $run{'filter'} to 0 for whitelist start client detection.

3. Going along with bug 3, changed 'Full speed (or root) hub' to:
Full speed or root hub, to make more clear that it's one or the other, or both.

4. For apply_filter(), added test if <superuser required> just return the
string.

--------------------------------------------------------------------------------
ENHANCEMENTS:

1. Going with bug 1, and fix 1, for > 1 cpu systems, will now show for all
cache: items L1: 2x 1.5 MiB (3 MiB), same for L2 and L3. This is far less
confusing than showing the totals without explaining what they are.

2. Going along with 1, now root is not required to show L1 and L3 -Cxx on Linux
as long as the system is reasonably new, about after 2008, and has getconf -a
supported. That support is came in somewhere around 2.10, not sure exactly when.
Debian Etch had it, Sarge did not, Ubuntu 9.10 had it. Tinycore does not have
getconf at all. This will probably be replaced by a more robust full cpu /sys
data tool.

3. Added ht to default short -Cx flag list, that should show, and it's short.

4. Added --no-filter to activate -Z, --filter-override isn't consistent with
other --no-xxx options, even I forgot it. No changes, just another way to use
-Z.

5. For issue #260 added pch as a new sensor output type, it's kind of a builtin
southbridge / northbridge in the CPU die, but it's not a core, and has a
different temp. Will anyone even know what pch is? probably not, but who cares.

--------------------------------------------------------------------------------
CHANGES:

1. No longer showing for > 1 physical cpu systems the sum total of L1/2/3 cache
data. Now shows per cpu L1/L2/L3, and if > 1 cpu, shows for example:

cache: L1: 2x 512 KiB (1024 KiB) L2: 2x 2 MiB (4 MiB)  L3: 2x 20 MiB (40 MiB)

For single physical cpu output remains the same:

cache: L1: 576 KiB L2: 3 MiB L3: 16 MiB

--------------------------------------------------------------------------------
DOCUMENTATION:

1. Updated help/man for L1/L3 cache -Cxx changes.

2. Updated man and help to suggest -Z for --tty.

3. Forgot to note -v 7 adds -f, added to man/help.

--------------------------------------------------------------------------------
CODE:

* Added 'getconf -a' to debugger, that may be usable for cpu cache data, need to
gather data on that to confirm. that's regading issue #257 cache glitches.

2. Removed all * $physical_count for cache data in cpu_properties, that is now
handled by creating string with cpu count, per cpu caches, and total in parens.

3. Added in fallback failure case for the ZFS file system issue exposed by
accident in issue #258 - will now log in debugger the error, so we can try to
find what is going on there, impossible to reproduce until we find what zfs or
more likely, freebsd, changed there. Could be hyper specific, some weird thing
like a person making a zfs device name with space, impossible to guess. Note
that since the freebsd user declined to supply any data to help resolve this
issue, then closed it, we're back where we usually end up with FreeBSD issues,
either a Linux user (or worse, me) willing and able to find the issue and supply
the debugger data required shows up, OR the issue is ignored as valid but
impossible to resolve.

RANT: Note that this also confirmed to me that in order to preserve my own
sanity and not waste endless hours trying to get data, from now on, unless
utterly trivial, if a FreeBSD user refuses to promptly supply the required data,
the issue will be closed with a freebsd-closed-no-data-supplied label, which
means, valid but not possible to solve due to user refusing to help me help
them.

Come on FreeBSD users!! If you want help, and inxi to support your distro, help
me help you!! If not, then why are you even filing an issue in the first place?
Do you expect faeries to spread magic bug / issue fixing faerie dust over inxi
and then activate it with their little wands? This is growing tiresome to be
honest because it's so utterly predictable.

4. Shuffled order of sensor type detections, there was a slim chance that a non
gpu sensor type could have string intel in it, so put the gpu sensors second
to last, before 'main'.

5. Started refactor of cpu core/cache logic. Added feature to cpu_arch, and
changed it to cpu_info since now it gives by vendor/family/model/stepping both
micorarch and cache/core math array returns. Also started refactor to make more
predictable, with increased comments, about what is going on in cpu_properties
to avoid breaking existing correct results.

6. Added to --debug /sys cpu data globber tool, that will help debugging the new
/sys cpu data feature, will let me insert the file data directly into the logic.

7. Added CpuItem::cpu_data_sys() with debuggers, that will now start collecting
user cpu data whenever the debugger is run, though it's not active yet.

8. Set $Data::Dumper::SortKeys = 1; dugh, could have saved big headaches if had
found this before. Makes all keys sorted cleanly, gets rid of random hash sorts.
This commit is contained in:
Harald Hope 2021-11-22 12:47:54 -08:00
parent a36210924e
commit 2feaf0b853
3 changed files with 751 additions and 157 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

699
inxi
View file

File diff suppressed because it is too large Load diff

22
inxi.1
View file

@ -15,7 +15,7 @@
.\" with this program; if not, write to the Free Software Foundation, Inc., .\" with this program; if not, write to the Free Software Foundation, Inc.,
.\" 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. .\" 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
.\" .\"
.TH INXI 1 "2021\-10\-21" "inxi" "inxi manual" .TH INXI 1 "2021\-11\-22" "inxi" "inxi manual"
.SH NAME .SH NAME
inxi \- Command line system information script for console and IRC inxi \- Command line system information script for console and IRC
@ -773,8 +773,9 @@ USB (\fB\-J\fR); triggers \fB\-xx\fR extra data option.
.TP .TP
.B \-v 7 .B \-v 7
\- Adds network IP data (\fB\-i\fR), forced bluetooth (\fB\-E\fR), \- Adds network IP data (\fB\-i\fR), forced bluetooth (\fB\-E\fR), Logical
Logical (\fB\-L\fR), RAID (\fB\-R\fR); triggers \fB\-xxx\fR (\fB\-L\fR), RAID (\fB\-R\fR), full CPU flags/features (\fB\-f\fR), triggers
\fB\-xxx\fR
.TP .TP
.B \-v 8 .B \-v 8
@ -860,7 +861,7 @@ location (\fB\-w\fR), and user home directory name. Removes Host:.
On by default for IRC clients. On by default for IRC clients.
.TP .TP
.B \-Z\fR,\fB \-\-filter\-override\fR .B \-Z\fR,\fB \-\-filter\-override\fR,\fB \-\-no\-filter\fR
Absolute override for output filters. Useful for debugging networking Absolute override for output filters. Useful for debugging networking
issues in IRC for example. issues in IRC for example.
@ -1122,8 +1123,9 @@ found for each distribution system base detection.
.TP .TP
.B \-xx \-C\fR .B \-xx \-C\fR
\- Adds \fBL1\-cache:\fR and \fBL3\-cache:\fR if either are available. \- Adds \fBL1\-cache:\fR and \fBL3\-cache:\fR if either are present/available.
Requires dmidecode and doas[BSDs]/sudo/root. For Linux, uses \fBgetconf \-a\fR (if supported), otherwise uses dmidecode +
doas[BSDs]/sudo/root. Force use of dmidecode by adding \fB\-\-dmidecode\fR.
.TP .TP
.B \-xx \-D\fR .B \-xx \-D\fR
@ -1728,7 +1730,7 @@ Shortcut, legacy. See \fB\-\-force dmidecode\fR.
Force inxi to use Curl, Fetch, Perl, or Wget for downloads. Force inxi to use Curl, Fetch, Perl, or Wget for downloads.
.TP .TP
.B \-\-force [dmidecode|hddtemp|lsusb|pkg|usb-sys|vmstat|wmctl]\fR .B \-\-force [dmidecode|hddtemp|lsusb|pkg|usb-sys|vmstat|wmctrl]\fR
Various force options to allow users to override defaults. Values be given Various force options to allow users to override defaults. Values be given
as a comma separated list: as a comma separated list:
@ -1758,7 +1760,7 @@ data source instead of \fBlsusb\fR (Linux only).
\- \fBvmstat\fR \- Forces use of vmstat for memory data. \- \fBvmstat\fR \- Forces use of vmstat for memory data.
\- \fBwmctl\fR \- Force \fBSystem\fR item \fBwm\fR to use \fBwmctrl\fR \- \fBwmctrl\fR \- Force \fBSystem\fR item \fBwm\fR to use \fBwmctrl\fR
as data source, override default \fBps\fR source. as data source, override default \fBps\fR source.
.TP .TP
@ -1965,6 +1967,10 @@ You can see what inxi believed started it in the \fB\-Ixxx\fR line,
\fBShell:\fR or \fBClient:\fR item. Please let us know what that result was \fBShell:\fR or \fBClient:\fR item. Please let us know what that result was
so we can add it to the parent start program whitelist. so we can add it to the parent start program whitelist.
In some cases, you may want to also use \fB\-\-no\-filter\fR/\fB\-Z\fR option if
you want to see filtered values. Filtering is turned on by default if \fBinxi\fR
believes it is running in an IRC client.
.TP .TP
.B \-\-usb\-sys\fR .B \-\-usb\-sys\fR
Shortcut, legacy. See \fB\-\-force usb\-sys\fR Shortcut, legacy. See \fB\-\-force usb\-sys\fR

187
inxi.changelog
View file

@ -1,3 +1,190 @@
================================================================================
Version: 3.3.09
Patch: 01
Date: 2021-11-22
--------------------------------------------------------------------------------
RELEASE NOTES:
--------------------------------------------------------------------------------
Thanks manjaro user alven for finding a bunch of corner and not so corner case
errors, glitches, documentation oversights, etc.
This is a point release between the coming full CPU refactor and the current
set of bug fixes and issue handlings.
This release also contains the debuggers for the new CPU data logic, which are
important to get this CPU refactor stable and reliable across old/new systems,
different operating systems and platforms.
Wanted to do this intermediate releaase to get the current fixes out, which
make inxi overall better for CPU issues, but do not handle the core requirement
to do a full refactor.
--------------------------------------------------------------------------------
CORRECTION:
1. On release notes for 3.3.08: due to a long delay to get real debugger data
from the person who had the issue, but finally getting it after the release of
3.3.08, there was NO bug in ps wwaux output. Something else was creating the
linewraps, maybe the subshell, it's basically impossible to know since we never
got a real debugger data set, which is the only real way to get the actual same
data inxi will see.
Was it a subshell wrapping the output? We just can't know, nor are we likely to
ever find out.
This highlights very well however why some issues are essentially impossible to
ever fully resolve without the --debug 22 dataset. This bug/fix is definitely in
that class of issues.
It's never good to accuse another program of having a bug when it doesn't, so
sorry to ps authors, no bug or issue exists for ps in this area.
--------------------------------------------------------------------------------
KNOWN ISSUES:
1. wiryonolau issue #259 points out that if --tty is used, default IRC filter
rule is still active and on. Because his case appears to be from an autostart
using Bash, which then gives up to find the parent at dash, which then makes
inxi believe it's in an IRC shell client, that issue doesn't appear to be
resolvable.
--------------------------------------------------------------------------------
BUGS:
1. Documentation, help menu and man page showed wmctl instead of wmctrl,
which for someone who reads the help man, leads to command --fake wmctl failing.
Thanks manjaro user alven for finding this typo.
2. For dmidecode cpu data, had global total values for cache that could result
in wrong output values, 2x or more wrong for L1 / L3 cache on linux. Difficulty
is preserving that data for bsd, which in general do not show phys cpu counts,
and thus make showing totals off. Created new '-total' item for each L cache
type, which will handle > 1 cpus, and also can be used to determine if > 1 cpus
present!.
3. Manjaro user pointed out that hub types were wrong, this is because inxi was
using the INTERFACE ID values for hubs instead of the TYPE values. For all other
device types, INTERFACE is correct, but for hubs, we needed TYPE, so fix is to
detect INTERFACE 9/0/0 and if TYPE present for that, swap.
--------------------------------------------------------------------------------
FIXES:
1. For > 1 cpu systems, with dmidecode sourced cpu cache data, can now determine
physical cpu count based on comparing L2 and L2-total values. This means that
when dmidecode is used on BSD for CPU data, inxi may now be able to deduce that
it is a > 1 cpu system.
2. Forgot to set $run{'filter'} to 0 for whitelist start client detection.
3. Going along with bug 3, changed 'Full speed (or root) hub' to:
Full speed or root hub, to make more clear that it's one or the other, or both.
4. For apply_filter(), added test if <superuser required> just return the
string.
--------------------------------------------------------------------------------
ENHANCEMENTS:
1. Going with bug 1, and fix 1, for > 1 cpu systems, will now show for all
cache: items L1: 2x 1.5 MiB (3 MiB), same for L2 and L3. This is far less
confusing than showing the totals without explaining what they are.
2. Going along with 1, now root is not required to show L1 and L3 -Cxx on Linux
as long as the system is reasonably new, about after 2008, and has getconf -a
supported. That support is came in somewhere around 2.10, not sure exactly when.
Debian Etch had it, Sarge did not, Ubuntu 9.10 had it. Tinycore does not have
getconf at all. This will probably be replaced by a more robust full cpu /sys
data tool.
3. Added ht to default short -Cx flag list, that should show, and it's short.
4. Added --no-filter to activate -Z, --filter-override isn't consistent with
other --no-xxx options, even I forgot it. No changes, just another way to use
-Z.
5. For issue #260 added pch as a new sensor output type, it's kind of a builtin
southbridge / northbridge in the CPU die, but it's not a core, and has a
different temp. Will anyone even know what pch is? probably not, but who cares.
--------------------------------------------------------------------------------
CHANGES:
1. No longer showing for > 1 physical cpu systems the sum total of L1/2/3 cache
data. Now shows per cpu L1/L2/L3, and if > 1 cpu, shows for example:
cache: L1: 2x 512 KiB (1024 KiB) L2: 2x 2 MiB (4 MiB) L3: 2x 20 MiB (40 MiB)
For single physical cpu output remains the same:
cache: L1: 576 KiB L2: 3 MiB L3: 16 MiB
--------------------------------------------------------------------------------
DOCUMENTATION:
1. Updated help/man for L1/L3 cache -Cxx changes.
2. Updated man and help to suggest -Z for --tty.
3. Forgot to note -v 7 adds -f, added to man/help.
--------------------------------------------------------------------------------
CODE:
* Added 'getconf -a' to debugger, that may be usable for cpu cache data, need to
gather data on that to confirm. that's regading issue #257 cache glitches.
2. Removed all * $physical_count for cache data in cpu_properties, that is now
handled by creating string with cpu count, per cpu caches, and total in parens.
3. Added in fallback failure case for the ZFS file system issue exposed by
accident in issue #258 - will now log in debugger the error, so we can try to
find what is going on there, impossible to reproduce until we find what zfs or
more likely, freebsd, changed there. Could be hyper specific, some weird thing
like a person making a zfs device name with space, impossible to guess. Note
that since the freebsd user declined to supply any data to help resolve this
issue, then closed it, we're back where we usually end up with FreeBSD issues,
either a Linux user (or worse, me) willing and able to find the issue and supply
the debugger data required shows up, OR the issue is ignored as valid but
impossible to resolve.
RANT: Note that this also confirmed to me that in order to preserve my own
sanity and not waste endless hours trying to get data, from now on, unless
utterly trivial, if a FreeBSD user refuses to promptly supply the required data,
the issue will be closed with a freebsd-closed-no-data-supplied label, which
means, valid but not possible to solve due to user refusing to help me help
them.
Come on FreeBSD users!! If you want help, and inxi to support your distro, help
me help you!! If not, then why are you even filing an issue in the first place?
Do you expect faeries to spread magic bug / issue fixing faerie dust over inxi
and then activate it with their little wands? This is growing tiresome to be
honest because it's so utterly predictable.
4. Shuffled order of sensor type detections, there was a slim chance that a non
gpu sensor type could have string intel in it, so put the gpu sensors second
to last, before 'main'.
5. Started refactor of cpu core/cache logic. Added feature to cpu_arch, and
changed it to cpu_info since now it gives by vendor/family/model/stepping both
micorarch and cache/core math array returns. Also started refactor to make more
predictable, with increased comments, about what is going on in cpu_properties
to avoid breaking existing correct results.
6. Added to --debug /sys cpu data globber tool, that will help debugging the new
/sys cpu data feature, will let me insert the file data directly into the logic.
7. Added CpuItem::cpu_data_sys() with debuggers, that will now start collecting
user cpu data whenever the debugger is run, though it's not active yet.
8. Set $Data::Dumper::SortKeys = 1; dugh, could have saved big headaches if had
found this before. Makes all keys sorted cleanly, gets rid of random hash sorts.
--------------------------------------------------------------------------------
-- Harald Hope - Mon, 22 Nov 2021 12:45:00 -0700
================================================================================ ================================================================================
Version: 3.3.08 Version: 3.3.08
Patch: 00 Patch: 00