Inxi / pinxi ARM (or MIPS) testers appreciated


#21
pi@raspberrypi:~ $ ./pinxi -zv8
System:    Host: raspberrypi Kernel: 4.14.52-v7+ armv7l bits: 32 compiler: gcc v: 4.9.3 Console: tty 0 
           dm: LightDM 1.18.3 Distro: Raspbian GNU/Linux 9 (stretch) 
Machine:   Type: ARM Device System: Raspberry Pi 3 Model B Plus Rev 1.3 details: BCM2835 rev: a020d3 
           serial: <filter> 
Memory:    RAM Report: permissions: Unable to run dmidecode. Are you root? 
PCI Slots: ARM: No ARM data found for this feature. 
CPU:       Topology: Quad Core model: ARMv7 v7l variant: cortex-a53 bits: 32 type: MCP arch: v7l family: 7 
           model-id: N/A stepping: 4 microcode: N/A bogomips: 358 
           Speed: 1400 MHz min/max: 600/1400 MHz Core speeds (MHz): 1: 1400 2: 1400 3: 1400 4: 1400 
           Features: crc32 edsp evtstrm fastmult half idiva idivt lpae neon thumb tls vfp vfpd32 vfpv3 vfpv4 
           Vulnerabilities: No CPU vulnerability/bugs data available. 
Graphics:  Device-1: bcm2708-fb driver: bcm2708_fb v: kernel bus ID: N/A chip ID: brcm:soc 
           Display: server: X.org 1.19.2 driver: fbturbo tty: 207x58 
           Message: Advanced graphics data unavailable in console. Try -G --display 
Audio:     Device-1: googlevoicehat-soundcard driver: snd_googlevoicehat_soundcard bus ID: N/A 
           chip ID: googlevoicehat:soc 
           Sound Server: ALSA v: k4.14.52-v7+ 
Network:   Device-1: Standard Microsystems type: USB driver: lan78xx bus ID: 1-1.1.1:4 chip ID: 0424:7800 
           IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter> 
           IP v4: <filter> scope: global broadcast: <filter> 
           IP v6: <filter> scope: link 
           IF-ID-1: wlan0 state: down mac: <filter> 
           WAN IP: <filter> 
Drives:    Local Storage: total: 14.92 GiB used: 3.34 GiB (22.4%) 
           ID-1: /dev/mmcblk0 model: 00000 size: 14.92 GiB serial: <filter> scheme: MBR 
           Message: No Optical or Floppy data was found. 
RAID:      Message: No RAID data was found. 
Partition: ID-1: / size: 14.58 GiB used: 3.32 GiB (22.7%) fs: ext4 dev: /dev/mmcblk0p2 label: rootfs 
           uuid: 6bfc8851-cf63-4362-abf1-045dda421aad 
           ID-2: /boot size: 42.5 MiB used: 21.7 MiB (51.0%) fs: vfat dev: /dev/mmcblk0p1 label: boot 
           uuid: 6228-7918 
Unmounted: Message: No unmounted partitions found. 
USB:       Hub: 1-0:1 info: Full speed (or root) Hub ports: 1 rev: 2.0 speed: 480 Mb/s chip ID: 1d6b:0002 
           Hub: 1-1:2 info: Standard Microsystems USB 2.0 Hub ports: 4 rev: 2.0 speed: 480 Mb/s 
           chip ID: 0424:2514 
           Hub: 1-1.1:3 info: Standard Microsystems USB 2.0 Hub ports: 3 rev: 2.0 speed: 480 Mb/s 
           chip ID: 0424:2514 
           Device-1: 1-1.1.1:4 info: Standard Microsystems type: Network driver: lan78xx interfaces: 1 rev: 2.1 
           speed: 480 Mb/s chip ID: 0424:7800 
Sensors:   Missing: Required tool sensors not installed. Check --recommends 
Repos:     Active apt repos in: /etc/apt/sources.list 
           1: deb http://raspbian.raspberrypi.org/raspbian/ stretch main contrib non-free rpi
           Active apt repos in: /etc/apt/sources.list.d/aiyprojects.list 
           1: deb https://dl.google.com/aiyprojects/deb stable main
           Active apt repos in: /etc/apt/sources.list.d/raspi.list 
           1: deb http://archive.raspberrypi.org/debian/ stretch main ui
Processes: CPU top: 5 
           1: cpu: 59.0% command: perl pid: 2594 mem: 14.2 MiB (1.6%) 
           2: cpu: 1.2% command: sshd: pid: 2554 mem: 5.71 MiB (0.6%) 
           3: cpu: 1.2% command: -bash pid: 2569 mem: 4.01 MiB (0.4%) 
           4: cpu: 0.3% command: lxpanel pid: 827 mem: 27.8 MiB (3.1%) 
           5: cpu: 0.1% command: bt_prov_server.py started by: python3 pid: 295 mem: 21.7 MiB (2.4%) 
           Memory top: 5 
           1: mem: 32.3 MiB (3.6%) command: xorg pid: 567 cpu: 0.0% 
           2: mem: 27.8 MiB (3.1%) command: lxpanel pid: 827 cpu: 0.3% 
           3: mem: 21.7 MiB (2.4%) command: bt_prov_server.py started by: python3 pid: 295 cpu: 0.1% 
           4: mem: 20.6 MiB (2.3%) command: pcmanfm pid: 828 cpu: 0.0% 
           5: mem: 15.8 MiB (1.8%) command: piwiz pid: 845 cpu: 0.0% 
Info:      Processes: 126 Uptime: 17h 26m Memory: 1003.7 MiB used: 271.6 MiB (27.1%) gpu: 128.0 MiB 
           Init: systemd v: 232 runlevel: 5 Compilers: gcc: 6.3.0 alt: 6 Shell: bash v: 4.4.12 
           running in: tty 0 (SSH) pinxi: 3.0.24-21 

#22

Should be working now, I had a bad match in there. this is from a rasberry pi 2, seems to work now. Note that the hack method doesn’t give me driver data, just the name of the device and the vendor.

This is in 3.0.24-23

Graphics:
  Device-1: bcm2708-fb driver: bcm2708_fb v: kernel bus ID: N/A 
  chip ID: brcm:soc 
  Device-2: bcm2835-hdmi driver: N/A bus ID: N/A chip ID: brcm:soc 
  Display: server: X.org 1.19.2 driver: fbturbo tty: 125x40 
  Message: Advanced graphics data unavailable in console. Try -G --display 
Audio:
  Device-1: bcm2835-audio driver: bcm2835_audio bus ID: N/A chip ID: brcm:soc 
  Device-2: bcm2835-hdmi driver: N/A bus ID: N/A chip ID: brcm:soc 
  Sound Server: ALSA v: k4.14.34+ 
Network:
  Device-1: Standard Microsystems SMSC9512/9514 Fast Ethernet Adapter 
  type: USB driver: smsc95xx bus ID: 1-1.1:3 chip ID: 0424:ec00 
  Device-2: ASUSTek USB-N53 802.11abgn Network Adapter [Ralink RT3572] 
  type: USB driver: rt2800usb bus ID: 1-1.3:4 chip ID: 0b05:179d serial: 1.0

The mmc stuff would require a new mmc parser I think, which would work sort of like the usb parser in terms of checking for mmc devices that are not storage. Not sure if I’ll go that far on it. As far as I’ve seen, only rasberry pi 3 is using that mmc wifi device, if it proves to be used more commonly maybe I’ll add an mmc parser, but given most mmc devices are storage, and it’s hard to even find docs on non storage mmc, I may just leave this one alone, I’ll see. If I get access to a rasberry pi 3 I might work on it.


#23

Working as you expected:

Graphics:  Device-1: bcm2708-fb driver: bcm2708_fb v: kernel bus ID: N/A chip ID: brcm:soc 
           Device-2: bcm2835-hdmi driver: N/A bus ID: N/A chip ID: brcm:soc 
           Display: server: X.org 1.19.2 driver: fbturbo tty: 207x58 
           Message: Advanced graphics data unavailable in console. Try -G --display 
Audio:     Device-1: googlevoicehat-soundcard driver: snd_googlevoicehat_soundcard bus ID: N/A 
           chip ID: googlevoicehat:soc 
           Device-2: bcm2835-hdmi driver: N/A bus ID: N/A chip ID: brcm:soc 
           Sound Server: ALSA v: k4.14.52-v7+ 
Network:   Device-1: Standard Microsystems type: USB driver: lan78xx bus ID: 1-1.1.1:4 chip ID: 0424:7800 
           IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter> 
           IP v4: <filter> scope: global broadcast: <filter> 
           IP v6: <filter> scope: link 
           IF-ID-1: wlan0 state: down mac: <filter> 
           WAN IP: <filter>

I can let you ssh into my pi3B+ with a Public key, I just need to isolate it from the rest of the network :innocent:, I can prepare that for tomorrow if u want.


#24

Sounds good, as long as you can leave the connection up for a while, ARM stuff I usually just poke around in when I don’t have any other work or standard inxi issues to deal with, I’d actually been waiting for inxi dev to quiet down so I could focus on corner case stuff for one release, 3.0.24-xx was finally that time, OpenBSD, ARM, MIPS.

The good thing for regular users is that these corner cases almost always expose some slight glitch for non corner case users, so handling them tends to make inxi better.

The reason, for instance, I could figure out this particular case was because someone has given me ongoing access to a rasberry pi B device, so I can just drop into it to check now and then to make sure I’ve not broken, and ideally, actually improved, things for ARM.

I’m hoping Strit can get the odroid oc1/2 stuff since that’s an entire device group I have not been able to confirm the status of ARM support for.

The MMC stuff is harder than I thought, initially I did not even realize that you could run wlan off an mmc device, I thought mmc was just for block storage, so i have to re-evaluate how I look at that.


#25

Just uploaded the OC2 results: Filename: pinxi-ARM-manjaro-arm-2018-09-17_210400-3.0.24.tar.gz
OC1 will be done soon.


#26

Perfect, thanks. pinxi 3.0.24-24 should correct the failed hdmi detections for graphics and audio.


#27

My OC1 run is stalling on:
Parsing /sys files...

Any idea why? The OC2 one didn’t stall.


#28

Depends, it’s a big operation, but there’s also some data that must be filtered out to avoid a hang. But I’ve handled most of those cases that I’m aware of, but sometimes new ones come up. But those usually lead to an error, not a hang.

PowerPC had a problem parsing /sys so I had to disable it for root, couldn’t figure out the cause.


#29

This one just hangs. Been at that line for the last 10 minutes. It was really quick on the OC2.


#30

If it’s hanging it means it got stuck on a file. For now just go to line 1322 and comment out the parser:

nano +1322 pinxi

then: # sys_traverse_data() if (!$b_root || !$b_ppc || $b_sys_debug) ;


#31

That worked. OC1 Result is in the file pinxi-ARM-manjaro-arm-2018-09-17_214153-3.0.24.tar.gz.


#32

great, I think there’s one other category of directory I have to exclude, but it’s hard to figure out what it is, maybe the list of /sys files will show it.


#33

Let me know if you need more OC1/OC2 tests. I live in Denmark, so depending on timezones it can take a day or two. :stuck_out_tongue:


#34

use pinxi -U to update to -25, that will probably correct the missing audio/graphics devices.

The C1 data is very sloppy, they put the meson name where it doesn’t belong, like mesonfb instead of fb, the C2 was not bad in that way, it’s too bad these ARM projects can’t be forced to use consistent syntax in their device files to identify the device type.

I’m not sure how far I should go in this area when a company does it this badly because that means the regex used to determine if a device is audio, video, or network becomes more expensive to cater to literally only one arm device.

I may look at how I do this for non arm devices to see if I can’t get that optimized a bit.

But this C1 is very messy, rather than say, identify the type as ‘watchdog’, which is what all others I’ve seen do, they use: amlogic-watchdog, which is just wrong. They fixed that in C2 though.

I can’t make the regex too lose either however or many devices will get falsely id’ed. Maybe the best course is to do the corrections there in the data generator itself now that I think about it.


#35

I agree. We also have to do special things to get a kernel and a bootloader on it that works. :stuck_out_tongue:


#36

Oh, that’s good to know, I’ll move the corrections into the data generators then, so they don’t mess up the overall gfx/net/audio id logic.


#37

ARM devices have always been spcial cases, and to be honest I never thought they would get as good support as they have with inxi. :slight_smile:


#38

It took a lot of work, and I couldn’t do most of it at all in legacy inxi, which is why I started looking at old googlecode/github issues once inxi perl was running. In inxi bash it was impossible, in inxi perl it’s just difficult.


#39

pinxi 3.0.24-26 has a soc device type correcting tool now, translates them to standard syntax from non standard, that way I can keep that regex only in the soc data generator, and not negatively impact all other users. Since I’m sure to hit ARM/MIPS/SPARC variants for hdmi, audio, ethernet, wifi, and display, I’ll just correct them there then send them translated to the inxi device generator logic.

I’ve added in a new flag, --no-sys-debug which will disable the /sys debugger if you experience a hang. But the ideal is to blacklist the directory/file that is making it hang so it will run correctly.


#40

Yoy0 can you confirm on the mips device that I didn’t break any logic with the refactoring I’ve just done? Maybe another --debug 22 dataset to confirm.