FTBFS on "ppc64el"

[onlyjob]

Version 2.1 FTBFS on ppc64el as follows:

# github.com/shirou/gopsutil/process
src/github.com/shirou/gopsutil/process/process_linux.go:559: undefined: PageSize
src/github.com/shirou/gopsutil/process/process_linux.go:560: undefined: PageSize
src/github.com/shirou/gopsutil/process/process_linux.go:581: undefined: PageSize
src/github.com/shirou/gopsutil/process/process_linux.go:582: undefined: PageSize
src/github.com/shirou/gopsutil/process/process_linux.go:583: undefined: PageSize
src/github.com/shirou/gopsutil/process/process_linux.go:584: undefined: PageSize
src/github.com/shirou/gopsutil/process/process_linux.go:585: undefined: PageSize
src/github.com/shirou/gopsutil/process/process_linux.go:586: undefined: PageSize
src/github.com/shirou/gopsutil/process/process_linux.go:723: undefined: ClockTicks
src/github.com/shirou/gopsutil/process/process_linux.go:724: undefined: ClockTicks
src/github.com/shirou/gopsutil/process/process_linux.go:724: too many errors

See full build log: https://buildd.debian.org/status/fetch.php?pkg=nomad&arch=ppc64el&ver=0.4.0%2Bdfsg-1&stamp=1468713257

[shirou]

perhaps, #225 is related. But as I said, I can not work because I don't have that arch.

[andhe]

hello @shirou

I've tried building latest git master on ppc64el and not quite there yet it seems (unless I've made a mistake which is very possible). It fails on a testcase, here's a snippet from the build log:

=== RUN TestCPUPercentIntervalZeroPerCPU
--- PASS: TestCPUPercentIntervalZeroPerCPU (0.01s)
FAIL
exit status 1
FAIL github.com/shirou/gopsutil/cpu 0.291s
=== RUN TestDisk_usage
--- PASS: TestDisk_usage (0.00s)

Which later ends with:

dh_auto_test: go test -v -p 1 github.com/shirou/gopsutil github.com/shirou/gopsutil/cpu github.com/shirou/gopsutil/disk github.com/shirou/gopsutil/docker github.com/shirou/gopsutil/host github.com/shirou/gopsutil/internal/common github.com/shirou/gopsutil/load github.com/shirou/gopsutil/mem github.com/shirou/gopsutil/net github.com/shirou/gopsutil/process returned exit code 1
debian/rules:13: recipe for target 'build' failed
make: *** [build] Error 1

Any suggestions what I could try?

PS. if you want ppc64el access I'm sure we can arrange a guest account on debian porter boxes.

[andhe]

Oh, I might have just missed the relevant part of the log:

--- FAIL: TestCpuInfo (0.00s)
cpu_test.go:53: error open /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq: no such file or directory
cpu_test.go:56: could not get CPU Info

Which seems pretty self-explaning. Would be appreciated if the test-suite could deal with /sys not being available though.

[andhe]

hmm... /sys is actually available, but cpufreq/ is not available in /sys/devices/system/cpu/cpu0/ on the ppc64el porter box it seems.

Regression introduced in commit 10a1ae2

[andhe]

Ping @dvusboy ... any chance you want to improve on your previous commit 10a1ae2 ?
Probably /proc/cpuinfo MHz could/should be used as a fallback atleast when cpufreq is not available/supported.

[andhe]

Even with above commit, tests still fails because there's no "model name" in cpuinfo.... This is how it looks:

(sid_ppc64el-dchroot)ah@plummer:~/upstream/gopsutil$ cat /proc/cpuinfo
processor : 0
cpu : POWER8E (raw), altivec supported
clock : 3425.000000MHz
revision : 2.1 (pvr 004b 0201)

processor : 1
cpu : POWER8E (raw), altivec supported
clock : 3425.000000MHz
revision : 2.1 (pvr 004b 0201)

processor : 2
cpu : POWER8E (raw), altivec supported
clock : 3425.000000MHz
revision : 2.1 (pvr 004b 0201)

processor : 3
cpu : POWER8E (raw), altivec supported
clock : 3425.000000MHz
revision : 2.1 (pvr 004b 0201)

processor : 4
cpu : POWER8E (raw), altivec supported
clock : 3425.000000MHz
revision : 2.1 (pvr 004b 0201)

processor : 5
cpu : POWER8E (raw), altivec supported
clock : 3425.000000MHz
revision : 2.1 (pvr 004b 0201)

processor : 6
cpu : POWER8E (raw), altivec supported
clock : 3425.000000MHz
revision : 2.1 (pvr 004b 0201)

processor : 7
cpu : POWER8E (raw), altivec supported
clock : 3425.000000MHz
revision : 2.1 (pvr 004b 0201)

processor : 8
cpu : POWER8E (raw), altivec supported
clock : 3425.000000MHz
revision : 2.1 (pvr 004b 0201)

processor : 9
cpu : POWER8E (raw), altivec supported
clock : 3425.000000MHz
revision : 2.1 (pvr 004b 0201)

processor : 10
cpu : POWER8E (raw), altivec supported
clock : 3425.000000MHz
revision : 2.1 (pvr 004b 0201)

processor : 11
cpu : POWER8E (raw), altivec supported
clock : 3425.000000MHz
revision : 2.1 (pvr 004b 0201)

processor : 12
cpu : POWER8E (raw), altivec supported
clock : 3425.000000MHz
revision : 2.1 (pvr 004b 0201)

processor : 13
cpu : POWER8E (raw), altivec supported
clock : 3425.000000MHz
revision : 2.1 (pvr 004b 0201)

processor : 14
cpu : POWER8E (raw), altivec supported
clock : 3425.000000MHz
revision : 2.1 (pvr 004b 0201)

processor : 15
cpu : POWER8E (raw), altivec supported
clock : 3425.000000MHz
revision : 2.1 (pvr 004b 0201)

timebase : 512000000
platform : pSeries
model : IBM pSeries (emulated by qemu)
machine : CHRP IBM pSeries (emulated by qemu)

[andhe]

So, model is something different (and included for each processor) on my x86. Also even if we tried "machine" (for "model name") not sure if we can use the "trailing generic info" at all with the current parser. If I read the code correctly it just skips over the empty lines instead of treating them as block separators, thus the trailing generic info will likely end up as just additional info to the last processor block.

Easiest way to just make the testsuite pass on ppc64el should be to use the "cpu" field that exists for each processor block as the "model name", eg in cpu/cpu_linux.go:

- case "model name":
+ case "model name", "cpu":

Comments welcome.

[dvusboy]

Wow! I can't say the regression come from my commit. The content of /proc/cpuinfo looks completely different from an x86_64 Linux host:

processor   : 11
vendor_id   : GenuineIntel
cpu family  : 6
model       : 62
model name  : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping    : 4
microcode   : 0x428
cpu MHz     : 2098.769
cache size  : 15360 KB
physical id : 0
siblings    : 12
core id     : 5
cpu cores   : 6
apicid      : 11
initial apicid  : 11
fpu     : yes
fpu_exception   : yes
cpuid level : 13
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt
bogomips    : 4199.88
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

Instead of cpu MHz, you have clock. So, the parser on /proc/cpuinfo won't pick up the clock speed any way. @andhe: Can you provide the output of uname -rio.

[andhe]

@dvusboy yeah I noticed you followed it up with commit 3dc4e52 so might not have pinpointed the right cause, but there's still an exception thrown. On v2.1 it's probably just gets parsed as 0 MHz and no exception. Anyway, #269 should resolve it. Would be great with your review on that.

ah@plummer:~$ uname -rio
3.16.0-4-powerpc64le unknown GNU/Linux

And yes, /proc/cpuinfo (as well as many other files in /proc) is very arch specific. There are likely other tools out there (procps? util-linux? ...) which possibly has a test-suite for a wide selection of architectures which anyone interested in writing a more cross-architecture parser should look at importing in gopsutil.