John Morris (zultron on freenode) has put up package repositories containing Xenomai packages for Precise, Squeeze and Lucid.
The packages in this PPA are beta test quality.
if you have previously installed from John's debian repository, make sure to remove any lines containing "distro.zultron.com" from /etc/apt/sources.list and any files under /etc/apt/sources.list.d !
To enable the package repo and install the packages, the following commands must be run as superuser:
# Set CODENAME as appropriate for your environment # should be one of 'precise', 'lucid', 'squeeze'; set manually if you get something different CODENAME=$(lsb_release -cs); echo $CODENAME # Add the repository to /etc/apt/sources.list echo "deb http://deb.machinekit.net/$CODENAME $CODENAME main" >> /etc/apt/sources.list echo "deb-src http://deb.machinekit.net/$CODENAME $CODENAME main" >> /etc/apt/sources.list # update the package list apt-get update # Install the package containing the signing keys; answer 'y' to install despite missing keys apt-get install zultron-keyring # Install the xenomai run-time tools and headers (for building LCNC) apt-get install xenomai-runtime libxenomai-dev # Install the xenomai-patched kernel apt-get install linux-image-3.5.7-xenomai-220.127.116.11
Before you reboot, please verify if you have a r8168 Ethernet controller.
Run this command:
$ lspci | grep 8168
If the output contains something like this:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
then make sure you read through the next section, and install that driver before your reboot. If you do not follow this, there is a chance that the new kernel will come up without a stable network connection. In this case:
The network connection should now work reliably.
The r8169 driver is finicky when driving an r8168 NIC, and won't drive it at 1Gb in any case. The Xenomai patches break it entirely.
If you have an r8168 and networking problems (or want full 1Gb speed), install the correct r8168 driver. The r8169 may be loaded in the initrd, in which case the r8168 cannot be automatically loaded, because the two drivers conflict. To fix this problem, the initrd must be rebuilt to include the r8168.
sudo apt-get install kmod-r8168-modules-3.5.7-xenomai-18.104.22.168 sudo update-initramfs -u -k 3.5.7-xenomai-22.214.171.124
David Armstrong contributed the following fix:
It can happen that your device is not managed by hid-multitouch but you'd think it should.
It can be because your device is in the table of supported hardware and tests show that hid-multitouch is not loaded. Or it can be because you have a new device that is not known to work but you just want to try. You can try this:
if lsusb shows your usb device then note the vendor and product id should be similar to
Bus 005 Device 002: ID 0408:3001 Quanta Computer, Inc. Optical Touch Screen the vendor id is in this case '0408' and the product id '3001'
download load_hid_multitouch.sh and put it in /etc/udev. then. chmod 744 /etc/udev/load_hid_multitouch.sh
place file 41-hid-multitouch.rules and put it in /etc/udev/rules.d. then chmod 644 /etc/udev/rules.d/41-hid-multitouch.rules
using the vendor id and product id from running lsusb ... Edit /etc/udev/rules.d/41-hid-multitouch.rules (insert your idVendor and idProduct, do not forget to remove the stars '*') reload udev rules or reboot
Files contributed by David:
Please run the regression tests as described in XenomaiKernel to ensure Xenomai is working correctly. Please report both success and failure, with info about your hardware (especially 32/64 bit, CPU, number of CPUs and chipset) and a pastebin of the regression run to the mailing list.
Testers are encouraged to discuss in #linuxcnc-devel or #xenomai on freenode. Feel free to direct questions to mhaberler or zultron in those channels.
If you experience spikes of high latencies, there are a couple of issues that should be looked at first.
Large latency spikes (>100uS) may be seen on some CPUs when transitioning between idle states. To test for this problem, while running latency-test, run the following loop in a shell:
while true; do echo "nothing" > /dev/null ; done
Reset the counters in latency-test. If latencies stay low while the above loop runs, and then spike again after stopping the loop, the latencies are caused by idle state transitions.
The problem may be fixed by adding one or both of nohlt and idle=poll to the kernel command line, either manually in the grub menu or automatically at each boot of the Xenomai kernel in the grub configuration.
SMIs may be disabled on the system. This may be dangerous! See the warnings at FixingSMIIssues#Turning off SMI may be dangerous. The PPA packages the smictrl utility, from Xenomai developer Jan Kiszka, that can manipulate the SMI register flags. It is essentially the same code as the Xenomai and RTAI SMI workaround code and manipulates the SMI register through libpci.
# install the smictrl package sudo apt-get install smictrl # check if chipset is SMI-enabled and which flags are set # will return a hex number like 0000202b smictrl # turn off SMIs globally; outputs new and old values smictrl -s 0
On some machines, the BIOS locks down SMIs, and they may not be manipulated outside the BIOS. There is not workaround for this.
John plans to continue maintaining the kernel .configs for Xenomai and to maintain packages for RedHat-like distros. For Ubuntu/Debian users, he will support these packages for all current releases, and to update the packages for future releases of Xenomai, until someone else volunteers. Please volunteer!
The Xenomai devs have expressed interest in hosting the RedHat packages on xenomai.org, and have begun packaging for Debian. Between John's efforts, official Xenomai support, and the transparency of the packaging approach (see next section), sustained availability of updated packages will be ensured.
The philosophy behind the kernel package is that it should be recreatable from scratch and easily upgradeable, so that there is never again a situation where the LinuxCNC community is stuck on an old kernel.
All upstream sources are easily accessible and all changes are well-documented so that recreating the work from scratch is trivial.
The package is also easy to upgrade. When a new version of Xenomai is released for a newer kernel version, the new upstream distributions may be easily swapped in and a new package built. The steps are simple and should not require more than an hour, at most, excluding build time.
The several pieces combined to build this package are described below. Detailed instructions for building from scratch are in the README file in the git repo: http://github.com/zultron/kernel-rt-deb
The linux kernel source is the kernel.org vanilla source tarball.
The /debian directory is placed inside the unpacked vanilla source. It is based on files generated from the make-kpkg utility, and contains minimal modifications to support Xenomai, as described below.
The /debian files are in a git repo here: http://github.com/zultron/kernel-rt-deb From this repo, which began from untouched output of make-kpkg, all changes are clearly observable.
The kernel .config files are in this git repo: http://github.com/zultron/kernel-tools They are separately maintained in a central place for both Debian and RedHat packages.
The kernel must be patched with i-pipe and Xenomai patches, both of which introduce new kernel .config options. Mixing a vanilla kernel .config with the Xenomai config produces a resulting .config where the vanilla and xenomai options cannot be distinguished. The /debian rules are therefore modified to keep the configuration separate where they can be tracked in git and updated from upstream sources, and merges them only at build time.
The base kernel .config files (for amd64 and i386) are extracted from the Ubuntu upstream v3.5 kernel. When a new Xenomai package is released and the kernel version updated, these files may be directly replaced with suitable files from the matching Ubuntu kernel packages. The Ubuntu kernel packages were chosen because they had a package with a matching kernel version, and because the .config files are well-tested to support an enormous variety of hardware.
The Xenomai kernel .config files contain the minimal changes to enable Xenomai and i-pipe, and provided by Gilles Chanteperdrix, a key Xenomai developer. The files contain a few extra settings to override unsuitable options in the base .config files. These are well-documented in the file with pointers to more information.
During the kernel build, the debian rules use kconfigtool.py to overlay the Xenomai configuration on top of the base configuration to create the final .config file used in the kernel build.
The i-pipe and Xenomai patches to the kernel source are provided in the Xenomai distribution tarball. The Xenomai source debian rules create the linux-patch-xenomai package, which puts the patches in /usr/src/kernel-patches/diffs/xenomai.
The kernel package /debian files are modified to apply those patches at build time to make updating easier: the package maintainer doesn't need to patch the kernel source manually.
The Xenomai packages are built from the release tarballs. There are just a few changes that must be made when building: debian/changelog must be updated, and the --enable-dlopen-skins and --enable-x86-tsc options must be added to CONFIG_OPTS in the debian/rules file. The debconf version dependency must be backed down to 7 to build for Lucid.