Inxi hangs on Raspberry Pi

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start RPI
2. inxi -@ 7

What is the expected output? What do you see instead?
Normal inxi output, instead: Nothing

What version of the product are you using? On what operating system?
1.8.26-00

Please paste your inxi output below.
...

Please paste your 'cat /proc/cpuinfo' output below.
Processor       : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 697.95
Features        : swp half thumb fastmult vfp edsp java tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7

Hardware        : BCM2708
Revision        : 000f
Serial          : 000000005c17bbda

please paste your 'cat /proc/meminfo' output below.
MemTotal:         497764 kB
MemFree:          200308 kB
Buffers:           13032 kB
Cached:           232752 kB
SwapCached:            0 kB
Active:           137360 kB
Inactive:         139416 kB
Active(anon):      14332 kB
Inactive(anon):    16744 kB
Active(file):     123028 kB
Inactive(file):   122672 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       4194300 kB
SwapFree:        4193412 kB
Dirty:              1096 kB
Writeback:             0 kB
AnonPages:         31008 kB
Mapped:            15244 kB
Shmem:                84 kB
Slab:              14756 kB
SReclaimable:      10832 kB
SUnreclaim:         3924 kB
KernelStack:        1176 kB
PageTables:         1236 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     4443180 kB
Committed_AS:     135872 kB
VmallocTotal:     139264 kB
VmallocUsed:        1764 kB
VmallocChunk:     136672 kB

please paste your 'sensors' output below.
(Not functional on RPI.)

Further information:
Hangs at the following command (checked with 'ps'):
gawk -F:   ??BEGIN { ???IGNORECASE=1 ??} ??# TAKE STRONGER NOTE: \t+ does NOT 
always work, MUST be [ \t]+ ??# TAKE NOTE: \t+ will work for $FILE_CPUINFO, but 
SOME ARBITRARY FILE used for TESTING might contain SPACES! ??# Therefore PATCH 
to use [ \t]+ when TESTING! ??/^processor[ \t]+:/ { ???nr = $NF ??}  ??/^model 
name|^cpu\t+:/ { 
???gsub(/computing|computer|corporation|communications|electronics|electrical|el
ectric|gmbh|group|industrial|international|revision|software|technologies|techno
logy|ltd\.|\<ltd\>|inc\.|\<inc\>|intl\.|co\.|\<co\>|corp\.|\<corp\>|\(tm\)|\(r\)
|®|\(rev ..\)/, "", $NF ) ???gsub(/@|cpu deca|dual core|dual-core|tri 
core|tri-core|quad 
core|quad-core|ennea|genuine|hepta|hexa|multi|octa|penta|processor|single|triple
|[0-9\.]+ *[MmGg][Hh][Zz]/, "", $NF ) ???gsub(/,/, " ", $NF) ???gsub(/^ +| +$/, 
"", $NF) ???gsub(/ [ \t]+/, " ", $NF) ???cpu[nr, "model"] = $NF ??}  ??/^cpu 
MHz|^clock\t+:/ { ???if (!min) { ????min = $NF ???} ???else { ????if ($NF < 
min) { ?????min = $NF ????} ???}  ???if ($NF > max) { ????max = $NF ???} 
???gsub(/MHZ/,"",$NF) ## clears out for cell cpu ???gsub(/.00[0]+$/,".00",$NF) 
## clears out excessive zeros ???cpu[nr, "speed"] = $NF ??}  ??/^cache size/ { 
???cpu[nr, "cache"] = $NF ??}  ??/^flags/ { ???cpu[nr, "flags"] = $NF ??}  
??/^bogomips/ { ???cpu[nr, "bogomips"] = $NF ??}  ??/vendor_id/ { 
???gsub(/genuine|authentic/,"",$NF) ???cpu[nr, "vendor"] = tolower( $NF ) ??}  
??END { ???#if (!nr) { print ",,,"; exit } # <- should this be necessary or 
should bash handle that ???for ( i = 0; i <= nr; i++ ) { ????print cpu[i, 
"model"] "," cpu[i, "speed"] "," cpu[i, "cache"] "," cpu[i, "flags"] "," cpu[i, 
"bogomips"] ","  cpu[nr, "vendor"] ???} ???if (!min) { ????print "not found" 
????exit ???} ???if (min != max) { ????printf("Min:%s%s Max:%s%s\n", min, 
"Mhz", max, "Mhz") ???} ???else { ????printf("%s %s\n", max, "Mhz") ???} ??} 
/proc/cpuinfo

Original issue reported on code.google.com by krf...@gmail.com on 20 Jan 2013 at 1:30

[GoogleCodeExporter]

This issue is accepted, but needs a lot more information. There's no mention of 
the OS/linux version that I can see, for example.

That looks like the cpu/arm section of course, so maybe it will be possible to 
debug to some degree, hard to say though.

Keep in mind, rasberrie pi last I checked is hardware, not the OS, so the key 
difference would be arm cpu. 

One also wonders if other arm cpu driven devices also hang there, if so, it's 
probably some oversight, since actually inxi has never really been tested on 
arm beyond a few simple tests I think trash80 ran.

Original comment by inxi-...@techpatterns.com on 21 Jan 2013 at 10:53

• Changed state: Accepted

[GoogleCodeExporter]

You're in luck, that cpuinfo data itself seems to hang inxi when I insert it 
directly, so there's a chance I can get it debugged.

Original comment by inxi-...@techpatterns.com on 21 Jan 2013 at 10:57

[GoogleCodeExporter]

This issue was caused because inxi was expecting an integer in the Processor : 
field of /proc/cpuinfo, but the ARM data sent a string.

To work around this, I emulate the numbering, and also if cpu speed is blank, I 
use bogomips to generate the cpu speed, if bogomips is present and speed is 
gone.

According to wikipedia, razberrie pi uses bogomips = 1 x cpu speed, but they 
don't have any data for other ARM cpus.

http://en.wikipedia.org/wiki/BogoMips

I'm sure there will be other ARM fixes over time, but for now, inxi wont' hang, 
though the data will possibly be wrong for some arm cpus, or for dual core arm 
cpus, but we'll cross that bridge when we come to it.

At least it won't hang, if more arm /proc/cpuinfo examples can be provided, 
please post them here or on techpatterns.com/forums

Update to inxi 1.8.29 and it should not hang any more, at least not on that 
section.

Original comment by inxi-...@techpatterns.com on 22 Jan 2013 at 12:21

• Changed state: Fixed

[GoogleCodeExporter]

the hang, by the way, wasn't actually a hang, it was an infinite loop, which 
probably made the poor razberrie pi cpu work pretty hard.

Original comment by inxi-...@techpatterns.com on 22 Jan 2013 at 12:48

[GoogleCodeExporter]

I tested a qemu razberry pi image, v6 arm, not 7 as you have, and this works 
now:

 found. For package install advice run: inxi --recommends
[18:06] <h2-pi> System:    Host raspberrypi Kernel 3.6.8 armv6l (32 bit, gcc 
4.7.2) 
[18:06] <h2-pi>           Desktop LXDE (Openbox 3.5.0) info lxpanel dm (startx) 
Distro Debian GNU/Linux wheezy/sid
[18:06] <h2-pi> Machine:   No /sys/class/dmi machine data - try newer kernel, 
or install dmidecode
[18:06] <h2-pi> CPU:       Single core ARMv6-compatible processor rev 7 (v6l) 
(-UP-) cache unknown  flags (-) bmips 220.56 clocked at 220.56 MHz 
[18:06] <h2-pi> Graphics:  Card: Failed to Detect Video Card! X.org 1.12.4 
driver fbdev Resolution N/A 
[18:06] <h2-pi> Drives:    HDD Total Size: 1.9GB (-)
[18:06] <h2-pi>           1: id /dev/sda model QEMU_HARDDISK size 1.9GB serial 
scsi0-hd0 
[18:06] <h2-pi> Partition: ID: / size 1.8G used 1.5G (89%) fs ext4 
[18:06] <h2-pi> Sensors:   None detected - is lm-sensors installed and 
configured?
[18:06] <h2-pi> Repos:     Active apt sources in file: /etc/apt/sources.list
[18:06] <h2-pi>           deb http: //mirrordirector.raspbian.org/raspbian/ 
wheezy main contrib non-free rpi
[18:06] <h2-pi>           Active apt sources in file: 
/etc/apt/sources.list.d/raspi.list
[18:06] <h2-pi>           deb http: //archive.raspberrypi.org/debian/ wheezy 
main
[18:06] <h2-pi> Info:      Processes 90 Uptime 30 min Memory 55.4/247.4MB 
Runlevel 2 Gcc sys 4.6.3 Client Irssi 0.8.15 inxi 1.8.29 

Original comment by inxi-...@techpatterns.com on 22 Jan 2013 at 2:45

[GoogleCodeExporter]

Thanks for the fast fix!

Works for me now:
System:    Host: rpi Kernel: 3.2.27+ armv6l (32 bit) Console: tty 1 Distro: 
Debian GNU/Linux 7.0
Machine:   No /sys/class/dmi machine data - try newer kernel, or install 
dmidecode
CPU:       Single core ARMv6-compatible processor rev 7 (v6l) (-UP-) cache: 
unknown  flags: (-) clocked at 697.95 MHz 
Graphics:  Card: Failed to Detect Video Card! X.org: 1.12.4 driver: fbdev tty 
size: 120x31 Advanced Data: N/A out of X
Drives:    HDD Total Size: 1500.3GB (28.7% used) 1: USB id: /dev/sda model: 
HD154UI size: 1500.3GB 
Partition: ID: / size: 20G used: 3.7G (20%) fs: ext4 ID: /boot size: 252M used: 
17M (7%) fs: vfat 
           ID: swap-1 size: 4.29GB used: 0.72GB (17%) fs: swap 
Sensors:   None detected - is lm-sensors installed and configured?
Info:      Processes: 108 Uptime: 1 day Memory: 369.3/486.1MB Runlevel: 2 
Client: Shell (zsh) inxi: 1.8.29

Original comment by krf...@gmail.com on 22 Jan 2013 at 8:23

[GoogleCodeExporter]

Oh. I just noticed that a normal 'inxi' doesn't really give me the clock of the 
CPU:
$ inxi
CPU~Single core ARMv6-compatible processor rev 7 (v6l) (-UP-) clocked at not 
found Kernel~3.2.27+ armv6l Up~1 day Mem~370.0/486.1MB HDD~1500.3GB(28.7% used) 
Procs~108 Client~Shell inxi~1.8.29 

This one might still use the old code to get the clock or something?

Original comment by krf...@gmail.com on 22 Jan 2013 at 8:25

[GoogleCodeExporter]

It was the same function, but it used different logic for the short form, which 
I hadn't looked at for a long time.

It should now be working in 1.8.30 I believe, though I didn't test it, but the 
mistake was easy to find so I think it's handled now.

It looks like ARM type cpus, with non intel/amd standard /proc/cpuinfo output 
are going to probably require some ongoing tweaks and adjustments as more data 
samples come in. Given that arm and some other platforms are starting to 
actually be used, this is as good a time as any to start getting real multiarch 
cpu support in inxi. I am trying to make each fix as universal as I can, but I 
suspect each different architecture may require further corrections, 
particularly for multi core ARM or other cpus, but time will tell.

Original comment by inxi-...@techpatterns.com on 22 Jan 2013 at 9:16

[GoogleCodeExporter]

% inxi
CPU~Single core ARMv6-compatible processor rev 7 (v6l) (-UP-) clocked at 697.95 
Kernel~3.2.27+ armv6l Up~2 days Mem~419.9/486.1MB HDD~1500.3GB(28.7% used) 
Procs~109 Client~Shell inxi~1.8.30 

Works now. Thanks a lot!

Original comment by krf...@gmail.com on 23 Jan 2013 at 6:58