mirror of
https://github.com/smxi/inxi.git
synced 2024-11-16 08:11:39 +00:00
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.
This commit is contained in:
Harald Hope
parent
a36210924e
commit
2feaf0b853
22
inxi.1
22
inxi.1
|
|
@ -15,7 +15,7 @@
|
|||
.\" with this program; if not, write to the Free Software Foundation, Inc.,
|
||||
.\" 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
|
||||
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
|
||||
.B \-v 7
|
||||
\- Adds network IP data (\fB\-i\fR), forced bluetooth (\fB\-E\fR),
|
||||
Logical (\fB\-L\fR), RAID (\fB\-R\fR); triggers \fB\-xxx\fR
|
||||
\- Adds network IP data (\fB\-i\fR), forced bluetooth (\fB\-E\fR), Logical
|
||||
(\fB\-L\fR), RAID (\fB\-R\fR), full CPU flags/features (\fB\-f\fR), triggers
|
||||
\fB\-xxx\fR
|
||||
|
||||
.TP
|
||||
.B \-v 8
|
||||
|
|
@ -860,7 +861,7 @@ location (\fB\-w\fR), and user home directory name. Removes Host:.
|
|||
On by default for IRC clients.
|
||||
|
||||
.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
|
||||
issues in IRC for example.
|
||||
|
||||
|
|
@ -1122,8 +1123,9 @@ found for each distribution system base detection.
|
|||
|
||||
.TP
|
||||
.B \-xx \-C\fR
|
||||
\- Adds \fBL1\-cache:\fR and \fBL3\-cache:\fR if either are available.
|
||||
Requires dmidecode and doas[BSDs]/sudo/root.
|
||||
\- Adds \fBL1\-cache:\fR and \fBL3\-cache:\fR if either are present/available.
|
||||
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
|
||||
.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.
|
||||
|
||||
.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
|
||||
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.
|
||||
|
||||
\- \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.
|
||||
|
||||
.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
|
||||
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
|
||||
.B \-\-usb\-sys\fR
|
||||
Shortcut, legacy. See \fB\-\-force usb\-sys\fR
|
||||
|
|
|
|||
187
inxi.changelog
187
inxi.changelog
|
|
@ -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
|
||||
Patch: 00
|
||||
|
|
|
|||
Loading…
Reference in a new issue