inxi / pinxi 2.9.00 beta testers!
Re: inxi / pinxi 2.9.00 beta testers!
k_sz, thanks, I'll take a look at the data to see if any other differences occur with the CMB syntax internally, but the battery data looks completely normal to me so it seems it's only that variant name that was different. You can delete those two files now, thanks.
Let me think a bit on the passive ftp issue, I'll look into it, but I remember that I had to enforce passive to make it work consistently, so most likely I won't be able to resolve that type of failure in pinxi. I can improve the message however to suggest a manual upload to somewhere or something like that.
anticapitalista, I'm glad to hear that you found the issue and it was on your side. My basic idea with beta testing inxi is similar to Debian with next stable, it does not get released as inxi 3.0.0 until there are NO resolvable issue reports remaining. The design of pinxi from the very start was to not break a few key things:
1. existing user config files for inxi. those will work exactly the same when pinxi becomes inxi, no changes will be required for users or maintainers. There will be more config options, which I still have to create documentation for, but all the old ones, with one exception that probably almost nobody ever used, will keep working the same.
2. the normal user 'api', or options, would likewise not be changed. So most tools that issue commands to inxi to get some output would continue to get that same output from inxi 3.0.0. The main exceptions to this, which would not impact any tools like inxi gui, was that the advanced options, the -! , -@, -% type stuff, were removed and replaced with --alt, --debug, --dbg, --downloader, --ftp, --sleep, and a few others.
With this said, however, I am going to change the handler for the perl HTTP::Tiny downloader failure to only show output when a debug switch, --dgb 1 I think it is, is activated, and to log, not print, the data when logging is active. It really doesn't matter in any larger sense if the first request fails since the next in the loop would probably work.
That was some leftover stuff from the very early development phase, where I needed to see all failures visibly, I'd forgotten to remove those, or that they were even there, so let's consider that a bug you found as well since it is kind of an oversight, making the list of bugs discovered by antix users now too long for me to actually count, literally.
It seems like most issues are resolved, so I'm going to return to work on some loose ends, like completing the RAID data output section, and some more bsd stuff, but if anyone finds anything wrong, by all means, let me know. Same goes for suggestions or observations where something strikes you as not quite right, for whatever reason, no matter how subjective it might be.
I'd like to release inxi 3.0.0 with a relatively stable API, so to speak, that is, all the options and features and output choices would be relatively locked down and bug and issue free, so as noted, I will take as long as is required to do that.
Let me think a bit on the passive ftp issue, I'll look into it, but I remember that I had to enforce passive to make it work consistently, so most likely I won't be able to resolve that type of failure in pinxi. I can improve the message however to suggest a manual upload to somewhere or something like that.
anticapitalista, I'm glad to hear that you found the issue and it was on your side. My basic idea with beta testing inxi is similar to Debian with next stable, it does not get released as inxi 3.0.0 until there are NO resolvable issue reports remaining. The design of pinxi from the very start was to not break a few key things:
1. existing user config files for inxi. those will work exactly the same when pinxi becomes inxi, no changes will be required for users or maintainers. There will be more config options, which I still have to create documentation for, but all the old ones, with one exception that probably almost nobody ever used, will keep working the same.
2. the normal user 'api', or options, would likewise not be changed. So most tools that issue commands to inxi to get some output would continue to get that same output from inxi 3.0.0. The main exceptions to this, which would not impact any tools like inxi gui, was that the advanced options, the -! , -@, -% type stuff, were removed and replaced with --alt, --debug, --dbg, --downloader, --ftp, --sleep, and a few others.
With this said, however, I am going to change the handler for the perl HTTP::Tiny downloader failure to only show output when a debug switch, --dgb 1 I think it is, is activated, and to log, not print, the data when logging is active. It really doesn't matter in any larger sense if the first request fails since the next in the loop would probably work.
That was some leftover stuff from the very early development phase, where I needed to see all failures visibly, I'd forgotten to remove those, or that they were even there, so let's consider that a bug you found as well since it is kind of an oversight, making the list of bugs discovered by antix users now too long for me to actually count, literally.
It seems like most issues are resolved, so I'm going to return to work on some loose ends, like completing the RAID data output section, and some more bsd stuff, but if anyone finds anything wrong, by all means, let me know. Same goes for suggestions or observations where something strikes you as not quite right, for whatever reason, no matter how subjective it might be.
I'd like to release inxi 3.0.0 with a relatively stable API, so to speak, that is, all the options and features and output choices would be relatively locked down and bug and issue free, so as noted, I will take as long as is required to do that.
- rokytnji.1
- Global Moderator
- Posts: 718
- Joined: Sun Apr 13, 2014 9:06 pm
Re: inxi / pinxi 2.9.00 beta testers!
Late to the party . So just a bunch of readouts
Just unplugged the power adapter brick for the next test readouts
.
Power cable still unplugged
Code: Select all
harry@biker:~
$ sudo wget -O /usr/local/bin/pinxi https://github.com/smxi/inxi/raw/inxi-perl/pinxi
[sudo] password for harry:
--2018-03-08 17:30:04-- https://github.com/smxi/inxi/raw/inxi-perl/pinxi
Resolving github.com (github.com)... 192.30.253.112, 192.30.253.113
Connecting to github.com (github.com)|192.30.253.112|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://raw.githubusercontent.com/smxi/inxi/inxi-perl/pinxi [following]
--2018-03-08 17:30:05-- https://raw.githubusercontent.com/smxi/inxi/inxi-perl/pinxi
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.184.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.184.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 435100 (425K) [text/plain]
Saving to: ‘/usr/local/bin/pinxi’
/usr/local/bin/pinxi 100%[==========================>] 424.90K 1.13MB/s in 0.4s
2018-03-08 17:30:06 (1.13 MB/s) - ‘/usr/local/bin/pinxi’ saved [435100/435100]
harry@biker:~
$ sudo chmod +x /usr/local/bin/pinxi
Code: Select all
harry@biker:~
$ time inxi --help
<snip>
real 0m1.040s
user 0m0.505s
sys 0m0.562s
harry@biker:~
$ time pinxi --help
<snip>
real 0m0.220s
user 0m0.143s
sys 0m0.047s
Code: Select all
harry@biker:~
$ sudo pinxi -U
Starting pinxi self updater.
Using tiny as downloader.
Currently running pinxi version number: 2.9.00
Current version patch number: 369-p
Current version release date: 2018-03-07
Updating pinxi in /usr/local/bin using pinxi branch as download source...
Failed to connect to server/file!
Error 32: Error downloading file with tiny: https://github.com/smxi/inxi/raw/inxi-perl/pinxi
Error: pinxi branch
Code: Select all
harry@biker:~
$ sudo pinxi -U --alt 40
Starting pinxi self updater.
Using curl as downloader.
Currently running pinxi version number: 2.9.00
Current version patch number: 369-p
Current version release date: 2018-03-07
Updating pinxi in /usr/local/bin using pinxi branch as download source...
Successfully updated to pinxi branch version: 2.9.00;
New pinxi branch version patch number: 369-p;
New pinxi branch version release date: 2018-03-07;
To run the new version, just start pinxi; again.
----------------------------------------
Starting download of man page file now.
Skipping man download because branch version is being used.
Code: Select all
harry@biker:~
$ pinxi -zv7
System: Host: biker Kernel: 4.15.5-antix.1-amd64-smp x86_64 bits: 64 compiler: gcc v: 6.3.0
Desktop: IceWM 1.4.2 dm: slim Distro: antiX-17_x64-full Heather Heyer 24 October 2017
Machine: Type: Laptop System: Dell product: Latitude E4310 v: 0001 serial: N/A Chassis: type: 9 serial: N/A
Mobo: Dell model: 0T6M8G v: A01 serial: N/A BIOS: Dell v: A03 date: 07/08/2010
Battery: BAT-0: charge: 48.8 Wh condition: 43.1/48.8 Wh (88%) volts: 12.5/11.1
model: Samsung SDI DELL RM6618A type: Li-ion serial: N/A status: Full
Memory: RAM Report: permissions: Unable to run dmidecode. Are you root?
CPU: Topology: Dual Die Dual Core model: Intel Core i5 M 520 type: MT MCP arch: Nehalem rev: 5
L2 cache: 3072 KB
flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 19150
Speed: 1443 MHz min/max: 1199/2400 MHz Core speeds: 1: 1421 2: 1378 3: 1419 4: 1463
Graphics: Card-1: Intel Core Processor Integrated Graphics Controller driver: i915 v: kernel bus ID: 00:02.0
chip ID: 8086:0046
Display Server: X.Org 1.19.2 driver: intel resolution: 1366x768~60Hz
OpenGL: renderer: Mesa DRI Intel Ironlake Mobile version: 2.1 Mesa 13.0.6 direct render: Yes
Audio: Card-1: Intel 5 Series/3400 Series High Definition Audio driver: snd_hda_intel v: kernel
bus ID: 00:1b.0 chip ID: 8086:3b57
Sound Server: ALSA v: k4.15.5-antix.1-amd64-smp
Failed to connect to server/file!
Network: Card-1: Intel 82577LM Gigabit Network Connection driver: e1000e v: 3.2.6-k port: 6040 bus ID: 00:19
chip ID: 8086:10ea
IF: eth0 state: down mac: <filter>
Card-2: Intel Centrino Advanced-N 6200 driver: iwlwifi v: kernel bus ID: 02:00 chip ID: 8086:422c
IF: wlan0 state: up mac: <filter>
IP v4: <filter> scope: global broadcast: <filter>
IP v6: <filter> scope: link
WAN IP: <filter>
Drives: HDD Total Size: 55.90 GB used: 23.81 GB (42.6%)
ID-1: /dev/sda model: KINGSTON_SV300S3 size: 55.90 GB serial: <filter> rev: BBF0
Optical-1: /dev/sr0 vendor: TSSTcorp model: DVD+-RW TS-U633F rev: D500 dev-links: cdrom
Features: speed: 24 multisession: yes audio: yes dvd: yes rw: cd-r,cd-rw,dvd-r,dvd-ram
state: running
Partition: ID-1: / size: 7.63 GB used: 3.78 GB (49.6%) fs: ext4 dev: /dev/sda2 label: rootantiX
uuid: 78252287-6dbf-4719-9c7f-13d6bbc8143b
ID-2: /home size: 47.08 GB used: 20.03 GB (42.5%) fs: ext4 dev: /dev/sda1 label: homeantiX
uuid: 62a4a2cd-066a-47d3-a366-f8059a89cbcb
RAID: Message: No RAID data was found.
Unmounted: Message: No unmounted partitions found.
USB: Hub: 1:1 usb: 2.00 type: Full speed (or root) hub chip ID: 1d6b:0002
Hub: 1:2 usb: 2.00 type: Intel Integrated Rate Matching Hub chip ID: 8087:0020
Hub: 2:1 usb: 2.00 type: Full speed (or root) hub chip ID: 1d6b:0002
Hub: 2:2 usb: 2.00 type: Intel Integrated Rate Matching Hub chip ID: 8087:0020
Device-1: Dell DW375 Bluetooth Module bus ID: 2:3 usb: 2.00 type: Bluetooth chip ID: 413c:8187
Device-2: Broadcom BCM5880 Secure Applications Processor with fingerprint swipe sensor bus ID: 2:4
usb: 1.10 type: Application Specific Interface chip ID: 0a5c:5801
Sensors: System Temperatures: cpu: 48.0 C mobo: N/A
Fan Speeds (in RPM): N/A
Info: Processes: 154 Uptime: 2:57 Memory: 7.72 GB used: 617.6 MB (7.8%) Init: SysVinit v: 2.88 runlevel: 5
default: 5 Compilers: gcc: 6.3.0 alt: 6 Shell: bash 4.4.12 running in: lxterminal
pinxi: 2.9.00-369-p
Code: Select all
harry@biker:~
$ sensors
dell_smm-virtual-0
Adapter: Virtual device
Processor Fan: 0 RPM
CPU: +52.0°C
SODIMM: +45.0°C
Other: +50.0°C
Other: +57.0°C
coretemp-isa-0000
Adapter: ISA adapter
Core 0: +54.0°C (high = +95.0°C, crit = +105.0°C)
Core 2: +51.0°C (high = +95.0°C, crit = +105.0°C)
.
Code: Select all
harry@biker:~
$ acpi -b
Battery 0: Discharging, 100%, 04:04:53 remaining
Code: Select all
harry@biker:~
$ pinxi -Fxxx
System: Host: biker Kernel: 4.15.5-antix.1-amd64-smp x86_64 bits: 64 compiler: gcc v: 6.3.0
Desktop: IceWM 1.4.2 dm: slim Distro: antiX-17_x64-full Heather Heyer 24 October 2017
Machine: Type: Laptop System: Dell product: Latitude E4310 v: 0001 serial: N/A Chassis: type: 9 serial: N/A
Mobo: Dell model: 0T6M8G v: A01 serial: N/A BIOS: Dell v: A03 date: 07/08/2010
Battery: BAT-0: charge: 42.8 Wh condition: 43.1/48.8 Wh (88%) volts: 12.3/11.1
model: Samsung SDI DELL RM6618A type: Li-ion serial: N/A status: Discharging
CPU: Topology: Dual Die Dual Core model: Intel Core i5 M 520 type: MT MCP arch: Nehalem rev: 5
L2 cache: 3072 KB
flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 19150
Speed: 1475 MHz min/max: 1199/2400 MHz Core speeds: 1: 1588 2: 1426 3: 1993 4: 1380
Graphics: Card-1: Intel Core Processor Integrated Graphics Controller driver: i915 v: kernel bus ID: 00:02.0
chip ID: 8086:0046
Display Server: X.Org 1.19.2 driver: intel resolution: 1366x768~60Hz
OpenGL: renderer: Mesa DRI Intel Ironlake Mobile version: 2.1 Mesa 13.0.6 direct render: Yes
Audio: Card-1: Intel 5 Series/3400 Series High Definition Audio driver: snd_hda_intel v: kernel
bus ID: 00:1b.0 chip ID: 8086:3b57
Sound Server: ALSA v: k4.15.5-antix.1-amd64-smp
Network: Card-1: Intel 82577LM Gigabit Network Connection driver: e1000e v: 3.2.6-k port: 6040 bus ID: 00:19
chip ID: 8086:10ea
IF: eth0 state: down mac: 5c:26:0a:06:32:15
Card-2: Intel Centrino Advanced-N 6200 driver: iwlwifi v: kernel bus ID: 02:00 chip ID: 8086:422c
IF: wlan0 state: up mac: 00:27:10:6a:ae:60
Drives: HDD Total Size: 55.90 GB used: 23.81 GB (42.6%)
ID-1: /dev/sda model: KINGSTON_SV300S3 size: 55.90 GB serial: 50026B7743028DAC rev: BBF0
Partition: ID-1: / size: 7.63 GB used: 3.78 GB (49.6%) fs: ext4 dev: /dev/sda2
ID-2: /home size: 47.08 GB used: 20.03 GB (42.5%) fs: ext4 dev: /dev/sda1
Sensors: System Temperatures: cpu: 57.0 C mobo: N/A
Fan Speeds (in RPM): N/A
Info: Processes: 157 Uptime: 3:11 Memory: 7.72 GB used: 619.8 MB (7.8%) Init: SysVinit v: 2.88 runlevel: 5
default: 5 Compilers: gcc: 6.3.0 alt: 6 Shell: bash 4.4.12 running in: lxterminal
pinxi: 2.9.00-369-p
Code: Select all
harry@biker:~
$ sudo pinxi -zv7
[sudo] password for harry:
System: Host: biker Kernel: 4.15.5-antix.1-amd64-smp x86_64 bits: 64 compiler: gcc v: 6.3.0
Desktop: IceWM 1.4.2 dm: slim Distro: antiX-17_x64-full Heather Heyer 24 October 2017
Machine: Type: Laptop System: Dell product: Latitude E4310 v: 0001 serial: <filter> Chassis: type: 9
serial: <filter>
Mobo: Dell model: 0T6M8G v: A01 serial: <filter> BIOS: Dell v: A03 date: 07/08/2010
Battery: BAT-0: charge: 42.4 Wh condition: 43.1/48.8 Wh (88%) volts: 12.2/11.1
model: Samsung SDI DELL RM6618A type: Li-ion serial: N/A status: Discharging
Memory: Array-1: capacity: 8 GB slots: 2 EC: None max module size: N/A
Device-1: DIMM_A size: 4 GB speed: 1067 MHz type: DDR3 detail: synchronous bus width: 64 bits
total: 64 bits manufacturer: 80AD part-nu: HMT351S6BFR8C-H9 serial: 2E71D725
Device-2: DIMM_B size: 4 GB speed: 1067 MHz type: DDR3 detail: synchronous bus width: 64 bits
total: 64 bits manufacturer: 80AD part-nu: HMT351S6CFR8C-H9 serial: 01BB7EB6
CPU: Topology: Dual Die Dual Core model: Intel Core i5 M 520 type: MT MCP arch: Nehalem rev: 5
L2 cache: 3072 KB
flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 19150
Speed: 1566 MHz min/max: 1199/2400 MHz Core speeds: 1: 1310 2: 1353 3: 1406 4: 1463
Graphics: Card-1: Intel Core Processor Integrated Graphics Controller driver: i915 v: kernel bus ID: 00:02.0
chip ID: 8086:0046
Display Server: X.Org 1.19.2 driver: intel resolution: 1366x768~60Hz
OpenGL: renderer: Mesa DRI Intel Ironlake Mobile version: 2.1 Mesa 13.0.6 direct render: Yes
Audio: Card-1: Intel 5 Series/3400 Series High Definition Audio driver: snd_hda_intel v: kernel
bus ID: 00:1b.0 chip ID: 8086:3b57
Sound Server: ALSA v: k4.15.5-antix.1-amd64-smp
Failed to connect to server/file!
Network: Card-1: Intel 82577LM Gigabit Network Connection driver: e1000e v: 3.2.6-k port: 6040 bus ID: 00:19
chip ID: 8086:10ea
IF: eth0 state: down mac: <filter>
Card-2: Intel Centrino Advanced-N 6200 driver: iwlwifi v: kernel bus ID: 02:00 chip ID: 8086:422c
IF: wlan0 state: up mac: <filter>
IP v4: <filter> scope: global broadcast: <filter>
IP v6: <filter> scope: link
WAN IP: <filter>
Drives: HDD Total Size: 55.90 GB used: 23.81 GB (42.6%)
ID-1: /dev/sda model: KINGSTON_SV300S3 size: 55.90 GB serial: <filter> rev: BBF0
Optical-1: /dev/sr0 vendor: TSSTcorp model: DVD+-RW TS-U633F rev: D500 dev-links: cdrom
Features: speed: 24 multisession: yes audio: yes dvd: yes rw: cd-r,cd-rw,dvd-r,dvd-ram
state: running
Partition: ID-1: / size: 7.63 GB used: 3.78 GB (49.6%) fs: ext4 dev: /dev/sda2 label: rootantiX
uuid: 78252287-6dbf-4719-9c7f-13d6bbc8143b
ID-2: /home size: 47.08 GB used: 20.03 GB (42.5%) fs: ext4 dev: /dev/sda1 label: homeantiX
uuid: 62a4a2cd-066a-47d3-a366-f8059a89cbcb
RAID: Message: No RAID data was found.
Unmounted: Message: No unmounted partitions found.
USB: Hub: 1:1 usb: 2.00 type: Full speed (or root) hub chip ID: 1d6b:0002
Hub: 1:2 usb: 2.00 type: Intel Integrated Rate Matching Hub chip ID: 8087:0020
Hub: 2:1 usb: 2.00 type: Full speed (or root) hub chip ID: 1d6b:0002
Hub: 2:2 usb: 2.00 type: Intel Integrated Rate Matching Hub chip ID: 8087:0020
Device-1: Dell DW375 Bluetooth Module bus ID: 2:3 usb: 2.00 type: Bluetooth chip ID: 413c:8187
Device-2: Broadcom BCM5880 Secure Applications Processor with fingerprint swipe sensor bus ID: 2:4
usb: 1.10 type: Application Specific Interface chip ID: 0a5c:5801
Sensors: System Temperatures: cpu: 54.0 C mobo: N/A
Fan Speeds (in RPM): N/A
Info: Processes: 158 Uptime: 3:13 Memory: 7.72 GB used: 625.6 MB (7.9%) Init: SysVinit v: 2.88 runlevel: 5
default: 5 Compilers: gcc: 6.3.0 alt: 6 Shell: bash 4.4.12 running in: lxterminal
pinxi: 2.9.00-369-p
Re: inxi / pinxi 2.9.00 beta testers!
Everything seems to work except detecting my wifi chip. My system is a baytrail SOC with SDIO connected wifi/bluetooth.
I have a broadcom wifi chip - brcmfmac43241b4-sdio.bin probably known as BCM43241
The speed improvement is quite noticeable.
Thanks
Actually, there are a couple of interesting results. The desktop is Cinnamon and audio shows "message: bus/chip ids unavailable" - the drivers are right.
I have a broadcom wifi chip - brcmfmac43241b4-sdio.bin probably known as BCM43241
The speed improvement is quite noticeable.
Thanks
Code: Select all
john@LapLet ~ $ sudo pinxi -Fxz
System:
Host: LapLet Kernel: 4.16.0-rc4.0 x86_64 bits: 64 compiler: gcc v: 5.4.0
Desktop: N/A Distro: Linux Mint 18.2 Sonya
Machine:
Type: Laptop System: ASUSTeK product: T100CHI v: 1.0 serial: <filter>
Mobo: ASUSTeK model: T100CHI v: 1.0 serial: <filter>
UEFI: American Megatrends v: T100CHI.206 date: 09/25/2015
Battery:
BAT-C: charge: 24.7 Wh condition: 24.9/30.0 Wh (83%)
model: Intel SR 1 SR Real Battery status: Discharging
CPU:
Topology: Quad Core model: Intel Atom Z3775 type: MCP arch: Silvermont
L2 cache: 1024 KB
flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 11730
Speed: 533 MHz min/max: 533/2399 MHz Core speeds: 1: 1280 2: 1333 3: 580
4: 551
Graphics:
Card-1: Intel Atom Processor Z36xxx/Z37xxx Series Graphics & Display
driver: i915 v: kernel bus ID: 00:02.0
Display Server: X.Org 1.18.4 driver: intel resolution: 1920x1200~60Hz
OpenGL: renderer: Mesa DRI Intel Bay Trail version: 4.2 Mesa 17.2.8
direct render: Yes
Audio:
Card-1: Intel HDMI/DP LPE Audio driver: HdmiLpeAudio
message: bus/chip ids unavailable
Card-2: bytcr-rt5640 driver: bytcr-rt5640
message: bus/chip ids unavailable
Sound Server: ALSA v: k4.16.0-rc4.0
Network:
Message: No PCI card data found.
Drives:
HDD Total Size: 0 KB used: 57.48 GB
ID-1: /dev/mmcblk0 model: N/A size: 59.48 GB
ID-2: /dev/mmcblk2 model: N/A size: 58.24 GB
Partition:
ID-1: / size: 15.85 GB used: 12.89 GB (81.3%) fs: ext4 dev: /dev/mmcblk2p6
ID-2: /home size: 58.42 GB used: 29.77 GB (51.0%) fs: ext4
dev: /dev/mmcblk0p1
ID-3: swap-1 size: 2.00 GB used: 1.2 MB (0.1%) fs: swap
dev: /dev/mmcblk2p4
Sensors:
System Temperatures: cpu: 36.0 C mobo: N/A
Fan Speeds (in RPM): N/A
Info:
Processes: 195 Uptime: 1 day Memory: 1.83 GB used: 1.10 GB (60.0%)
Init: systemd runlevel: 5 Compilers: gcc: 5.4.0 Shell: bash 4.3.48
pinxi: 2.9.00-369-p
j
Code: Select all
john@LapLet ~ $ ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:1114 errors:0 dropped:0 overruns:0 frame:0
TX packets:1114 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:89119 (89.1 KB) TX bytes:89119 (89.1 KB)
wlan0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet addr:192.168.1.8 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:11576 errors:0 dropped:0 overruns:0 frame:0
TX packets:2796 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2253303 (2.2 MB) TX bytes:222561 (222.5 KB)
MX-18 on Asus T100CHI (z3775 Intel baytrail) mixed-mode 32 bit UEFI, 64 bit OS
Dell 3250 Inspiron desktop, i5-6400, 64 bit OS
Dell 3250 Inspiron desktop, i5-6400, 64 bit OS
Re: inxi / pinxi 2.9.00 beta testers!
anticapitalista, I've treated your download failure as a bug, but it was more of a lack of logging of downloads. I've also extended the download debugger options so now it prints out much more if you use the --dbg 1 debugger option, that will trip all download output results that will help you resolve the issue. But the normal output is suppressed. Those issues are now all handled in 0370-p
Re: inxi / pinxi 2.9.00 beta testers!
rokytnji.1, I may have to rethink the default downloader for -U, I have one remote system where I also have to use --alt 40 to get the download to work. I need to also add some better instructions to users in that case. I've removed as noted the visible download failure data for IP download failures, I'm not sure why this happens, I know in my failure case it's on a remote network that probably filters out some type of data that perl HTTP::Tiny, the default downloader, uses to get confirmation that the request succeeded.
Your sensors issues should be resolved, except there''s no way I can have pinxi guess what the 'Other:' temp data refers to, given how hot they are relative to cpu, I'd guess it might be graphics, but that's too much guesswork to be reliable.
I'd actually noticed the sodimm temp type, and have now extended pinxi sensors to list that if present. Your processor fan speed should now show, as 0, but not 'N/A'. It's much easier working on perl inxi than it was working on gawk->bash inxi, let me tell you!
0371-p should resolve the sensors weaknesses, though note that there is no mobo data available that can be identified as such clearly. I've never seen the 'Other' type, that's delightfully unhelpful, sigh, but sensors data is the WORST and most unreliable data I've come across in inxi development, there's literally no standards or rules, the various companies just make up the language for the field ids at random as far as I can tell, though most use certain consistent syntaxes, consistent enough so that inxi/pinxi can make decent guesses at what is meant.
Your sensors issues should be resolved, except there''s no way I can have pinxi guess what the 'Other:' temp data refers to, given how hot they are relative to cpu, I'd guess it might be graphics, but that's too much guesswork to be reliable.
I'd actually noticed the sodimm temp type, and have now extended pinxi sensors to list that if present. Your processor fan speed should now show, as 0, but not 'N/A'. It's much easier working on perl inxi than it was working on gawk->bash inxi, let me tell you!
0371-p should resolve the sensors weaknesses, though note that there is no mobo data available that can be identified as such clearly. I've never seen the 'Other' type, that's delightfully unhelpful, sigh, but sensors data is the WORST and most unreliable data I've come across in inxi development, there's literally no standards or rules, the various companies just make up the language for the field ids at random as far as I can tell, though most use certain consistent syntaxes, consistent enough so that inxi/pinxi can make decent guesses at what is meant.
Last edited by h2-1 on Thu Mar 08, 2018 9:27 pm, edited 1 time in total.
Re: inxi / pinxi 2.9.00 beta testers!
jbMacAZ, good stuff. To fully resolve your issues I'd need to get a: --debug 24 (24 is an undocumented option that adds the -i switch to the output, which then shows me in the debugger data all that stuff. At least it should.
The cinnamon failure is almost certainly due to a slight change in their internal syntax used, that should be easy to fix, just need to see the data set, it can be in several places.
SDIO is a new one on me, I'll need to probably add more debugger commands to get that type of data, SOC are a real challenge in some areas, I run one too but it has pci data for networking so it's not an issue.
I've grown aware of a definite weakness in the system for -n or -i , which is that right now, that data is directly linked to the pci device, or usb device, if found. I may be able to integrate the bluetooth if it's usb, but sometimes the devices refuse to identify themselves in any obvious way as an ethernet/wifi device.
This was caused by something in inxi that always bugged me, the fact that -n/-i output was actually just tacked onto the end, and not linked per IF device name, but one side effect of this switch is that now if no pci data appears, no -n data does either, or -i stuff, except for the wan ip line, which is always tacked onto the end I think, I'll double check.
mmcblk name failure is either due to missing something in pinxi, or because there is no name, the debugger data should show me that, I think.
The failure to show the networking data when no card data found is a bug in my opinion, arm systems all have that glitch too, so I will need to introduce a fallback case where if results for pci are null, print out the advanced data anyway if -n or -i, that should not be impossible, since pinxi has the ip data anyway at that point, it's just not using it because it couldn't link it to the specific networking device.
The cinnamon failure is almost certainly due to a slight change in their internal syntax used, that should be easy to fix, just need to see the data set, it can be in several places.
SDIO is a new one on me, I'll need to probably add more debugger commands to get that type of data, SOC are a real challenge in some areas, I run one too but it has pci data for networking so it's not an issue.
I've grown aware of a definite weakness in the system for -n or -i , which is that right now, that data is directly linked to the pci device, or usb device, if found. I may be able to integrate the bluetooth if it's usb, but sometimes the devices refuse to identify themselves in any obvious way as an ethernet/wifi device.
This was caused by something in inxi that always bugged me, the fact that -n/-i output was actually just tacked onto the end, and not linked per IF device name, but one side effect of this switch is that now if no pci data appears, no -n data does either, or -i stuff, except for the wan ip line, which is always tacked onto the end I think, I'll double check.
mmcblk name failure is either due to missing something in pinxi, or because there is no name, the debugger data should show me that, I think.
The failure to show the networking data when no card data found is a bug in my opinion, arm systems all have that glitch too, so I will need to introduce a fallback case where if results for pci are null, print out the advanced data anyway if -n or -i, that should not be impossible, since pinxi has the ip data anyway at that point, it's just not using it because it couldn't link it to the specific networking device.
Re: inxi / pinxi 2.9.00 beta testers!
Note: because there is no PCI info, pinxi has no access to bus or chip ids, so in that case, with audio, there is a special fallback case where it uses another source to get the audio card data, but that does not have the chip or bus id, since there is no chip or bus id, basically. I'm glad i got that fixed, that was actually made for ancient systems that sometimes failed to show audio devices in lspci, but it's nice to see it also kicking in for new soc systems for audio.The desktop is Cinnamon and audio shows "message: bus/chip ids unavailable" - the drivers are right.
This fallback case, since it will never have chip or bus ids, shows that special message, which is actually how I realized what had happened, that only shows if the data does not come from the pci bus.
As noted above, cinnamon is easy to fix once I get the debugger data, all I have to do is see what they changed to add it to the detections.
Re: inxi / pinxi 2.9.00 beta testers!
rokytnji.1
this is almost certainly a bug, /proc/cpuinfo will show me that, but I'm finding the way companies are getting that data is getting more and more random, I've been doing almost non stop cpu fixes, but it looks like something tripped the thing to report as dual die when it's almost certainly 1 die only, and dual core. I can debug that with /proc/cpuinfo, that's easy to inject other cpu datasets into the code.
Code: Select all
Topology: Dual Die Dual Core model: Intel Core i5 M 520 type: MT MCP arch: Nehalem rev: 5
L2 cache: 3072 KB
Re: inxi / pinxi 2.9.00 beta testers!
Done, happy hunting! pinxi claims it uploaded a file. Let me know if you need something else or more testing.h2-1 wrote:jbMacAZ, good stuff. To fully resolve your issues I'd need to get a: --debug 24 (24 is an undocumented option that adds the -i switch to the output, which then shows me in the debugger data all that stuff. At least it should.
Question: Should inxi find my USB ethernet dongle?
MX-18 on Asus T100CHI (z3775 Intel baytrail) mixed-mode 32 bit UEFI, 64 bit OS
Dell 3250 Inspiron desktop, i5-6400, 64 bit OS
Dell 3250 Inspiron desktop, i5-6400, 64 bit OS
Re: inxi / pinxi 2.9.00 beta testers!
green250@antix250:~
$ wget -O /usr/local/bin/pinxi https://github.com/smxi/inxi/raw/inxi-perl/pinxi
/usr/local/bin/pinxi: Permission denied
Do I need sudo?
$ wget -O /usr/local/bin/pinxi https://github.com/smxi/inxi/raw/inxi-perl/pinxi
/usr/local/bin/pinxi: Permission denied
Do I need sudo?