Ubuntu 16.04.1 will be the new Ubuntu release targeted for July 21st.
As a .1 release, this version will ship the very same kernel as the 16.04, plus some hardware enablement, usually seen as the HWE acronym.
If you are targeting any development for this release, this is the kernel schedule for it:
24-Jun Last day for kernel commits for this cycle
27-Jun - 02-Jul Kernel prep week.
03-Jul - 15-Jul Bug verification & Regression testing..
18-Jul Release to -updates.
Ubuntu created an interesting way of distributing binaries called snap, and the snap tool is available in Power since Ubuntu 16.04.
Snap is a way to make packages available with their dependencies on a sandbox. You can install it using apt:
# apt-get install snapd
You can search for packages using the find parameter as:
1604 ➜ ~ snap find
Name Version Developer Notes Summary
ab 1.0 snappy-test - Test snap with shortest name
audovia 3.2.2 songbuilder 9.99USD Database application for making music using JFugue MusicStrings
beagleblack 3.1 mvo - OEM Beagle Bone Black
canonical-dragon 0.7.1 canonical - The gadget snap for the dragonboard
canonical-i386 3.2.i386 canonical - The gadget snap for generic i386 systems
canonical-pc 3.2 canonical - AMD64 generic package
canonical-pi2 3.2 canonical - Raspberry Pi 2 support package
eeevil 1 chipaca - very evil
hello 2.10 canonical - GNU Hello, the "hello world" snap
hello-world 6.1 canonical - Hello world example
htop 2.0.1 maxiberta - Interactive processes viewer
http 4.6692016091 chipaca - HTTPie in a snap
morse-converter-py 1-2 brunonova - Simple command-line Morse converter
snappy-debug 0.21 canonical - Debug tools for ubuntu-core
sudo 1 chipaca - not sudo
ubuntu-core 16.04+20160531.11-53 canonical - The ubuntu-core OS snap
ufw 0.36pre-16.2 canonical - ufw (Uncomplicated Firewall) for Ubuntu Core
xkcd-webserver 16.04-6 canonical - Show random XKCD compic via a build-in webserver
1604 ➜ ~ snap install htop
error: access denied (snap login --help)
In order to install a package/snap you should use the install parameter:
1604 ➜ ~ sudo snap install htop
228.00 KB / 228.00 KB [=================================================================================================>_] 100.00 % 100.81 KB/s
Name Version Rev Developer Notes
htop 2.0.1 18 maxiberta -
And list the packages available using the word list:
1604 ➜ ~ snap list
Name Version Rev Developer Notes
htop 2.0.1 18 maxiberta -
ubuntu-core 16.04+20160531.11-53 125 canonical -
Anyway, another great tool for the Power ecosystem.
If you compile Debian Jessie kernel, or any kernel older than 4.2, using a newer toolchain (GCC or Advance Toolchain), you might hit this problem:
/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/gettimeofday.S: Assembler messages:
/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/gettimeofday.S:42: Error: syntax error; found `@', expected `,'
/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/gettimeofday.S:42: Error: junk at end of line: `@local'
/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/gettimeofday.S:48: Error: syntax error; found `@', expected `,'
/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/gettimeofday.S:48: Error: junk at end of line: `@local'
/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/gettimeofday.S:83: Error: syntax error; found `@', expected `,'
/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/gettimeofday.S:83: Error: junk at end of line: `@local'
/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/gettimeofday.S:87: Error: syntax error; found `@', expected `,'
/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/gettimeofday.S:87: Error: junk at end of line: `@local'
/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/gettimeofday.S:195: Error: syntax error; found `@', expected `,'
/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/gettimeofday.S:195: Error: junk at end of line: `@local'
make: *** [arch/powerpc/kernel/vdso32/gettimeofday.o] Error 1
/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/Makefile:42: recipe for target 'arch/powerpc/kernel/vdso32/gettimeofday.o' failed
make: *** [arch/powerpc/kernel/vdso32] Error 2
make: *** [arch/powerpc/kernel] Error 2
make: *** Waiting for unfinished jobs....
/«PKGBUILDDIR»/scripts/Makefile.build:403: recipe for target 'arch/powerpc/kernel/vdso32' failed
/«PKGBUILDDIR»/Makefile:951: recipe for target 'arch/powerpc/kernel' failed
This problem happens because newer toolchain does not allow code generation targeting 32 bits Little Endian, and the kernel code was trying to use it for VDSO.
This problem was later solved by the following commit in kernel 4.2:
Author: Michael Ellerman <firstname.lastname@example.org>
Date: Mon May 11 20:01:02 2015 +1000
powerpc/vdso: Disable building the 32-bit VDSO on little endian
The only little endian configuration we support is ppc64le. As such if
we’re building little endian we don’t need a 32-bit VDSO, because there
is no 32-bit userspace.
This patch is a fairly ugly mess of #ifdefs, but is the minimal logic
required to disable the 32-bit VDSO. We can hopefully clean up the
result in future with some further refactoring.
Signed-off-by: Michael Ellerman <email@example.com>
In order to circumvent this problem, you have three options:
- Cherry pick this commit into your old kernel, as being worked in Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785065
- Move to a newer kernel (newer than 4.2)
- Use an older toolchain (4.8), that does not block code generation for 32-bits LE.
I frequently see users trying to compile the kernel for ppc64el and facing a very common problem that is related to an assembly instruction that does not have an operand.
arch/powerpc/kernel/swsusp_asm64.S: Assembler messages:
arch/powerpc/kernel/swsusp_asm64.S:188: Error: missing operand
scripts/Makefile.build:293: recipe for target ‘arch/powerpc/kernel/swsusp_asm64.o’ failed
make: *** [arch/powerpc/kernel/swsusp_asm64.o] Error 1
Makefile:907: recipe for target ‘arch/powerpc/kernel’ failed
make: *** [arch/powerpc/kernel] Error 2
It happens due to the following instruction tlbia not having an argument. It was added in commit 543b9fd3
This is also widely discussed in the wild. Anyway, if you face this problem, it is because you have CONFIG_HIBERNATION=y, and you turned it off, as, using:
We changed it for Ubuntu in the following bug.
Finally Ubuntu KVM is going to have support for Dynamic DMA Window. The package is at the ubuntu-virt PPA and you can learn on how to install it following these steps.
PS: At this moment, due to a problem the package is not at the ppc64el repository, but will show up soon.
It is all know that Debian and Ubuntu makes ISO builds every day, these builds contain the latest code available burned in a ISO image.
We* created an infrastructure, called Daily Automation Tool, that tests the installation of these builds on ppc64el platform using different methods.
These are the builds we are testing daily:
- Ubuntu 16.10 (Yakety Yak)
- Ubuntu 16.04 (Xenial Xerus)
- Ubuntu 14.04 (Trusty Thar)
- Debian testing
- Debian 9.0 (Stretch)
Everyday all these builds are installed on different type of hypervisor on Power, using different file systems. This is hypervisor that are being tested:
- KVM guest
- Bare Metal (Still being implemented)
These are the following file system paths that are being exercised:
This is an example of the tests that ran earlier today.
You can check this tool on the “Automated tests” menu above, or, following the direct link.
* This worked was done, in fact, by Erwan Prioul
It is all known that packages are upgraded daily in Ubuntu and Debian world. This is based on how Ubuntu and Debian works, and I personally like it.
The only nuisance is you need to upgrade your system frequently, otherwise you are going to use old package versions, making it difficult to report bugs, and also, being exposed to security vulnerabilities.
There is a solution on how to ask your system to automatically check for new packages, download and install them automatically.
I usually do that on my system. In order to do that, you need to install a package called cron-apt. Cron-apt, by defaul, only downloads packages which means that the actual installation must be done manually.
# apt-get install cron-apt
If you want to be install the packages automatically, you just need to add the upgrade or dist-upgrade line to be executed by the cron-apt. This is how I do this:
# echo dist-upgrade -d -y -o APT::Get::Show-Upgraded=true >> /etc/cron-apt/action.d/3-download
In this example, the system is dist-upgraded every day at 4:00 AM, as showed in the cron-apt cron entry:
$ cat /etc/cron.d/cron-apt
0 4 * * * root test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt
I wrote an article on how to tune a 10Gbps NIC performance on Linux on Power. Although it is 7 years old, it is still valid and I still see a lot of references to it, and still receive mails about it.
Deep learning is a branch of machine learning based on a set of algorithms that attempt to model high-level abstractions in data by using multiple processing layers, with complex structures or otherwise, composed of multiple non-linear transformations.
Power platform is a premier architecture for Deep Learning workloads as showed by University of Maryland Baltimore County, the University of Illinois, and the STFC-Hartree Centre. These article show that POWER8 is ideal for deep learning, big data, and machine learning due to its high performance, large caches, 2x-3x higher memory bandwidth, very high I/O bandwidth, and of course, tight integration with GPU accelerators.
The OpenPOWER Deep Learning Software Distribution is available for Ubuntu/ppc64el, and can be downloaded easily.
You can learn more about Deep Learn more about this framework reading Dr. Michael Gschwind article entitled New OpenPOWER Software Distribution Puts Deep Learning a Click Away
From time to time, I need to generate an assembly code from a C code to see how the compiler is generating stuff.
One of the problems I have is related to the assembly instructions that do not show register name, but just the number, which makes you confused related to literal and register names , as for example, when I generate an assembly for the following instructions, I see:
- Move value 0 to the register 9
- Move value of register 9 to register 3
The problem becomes worse when you mix GPR (General Purpose Register) with VSX registers, as:
If you do not know the Power Assembly instructions forms quite well, it is hard to map what is a immediate value, what is a GPR and what is a VSR.
If you are facing the same problem, the problem is that GCC has the option -mno-regnames as default.
In this case, I would recommend you using the GCC parameter -mregnames, which will dump registers differently than just the number, as %r for GPR and %vs for VSR registers. The code becomes much more human readable, as