Disable internal audio

Have been working with Ardour lately and the multiple audio devices (internal + PCI) have been causing issues both on output and input. The easiest workaround is removing totally the unused sound card, which in my case was the internal Intel HDA. The single step required was to blacklist the module of the sound card. You can identify the module by “lspci” and then blacklisting the module is straight forward:

vi /etc/modprobe.d/blacklist

and add the line

blacklist <module name>

A single reboot should do the job or you could unload the module instantly. Although, reboot would confirm whether the blacklist function worked or not.

Advertisements

An ARM comparison: Raspberry Pi vs OpenRD Client

Bellow there’s a comparison between Raspberry Pi (Model B) and OpenRD Client, two low-power ARM SoC (System on a Chip), running Linux (Rasbian and Fedora respectively). I used the EEMBC CoreMark benchmark with default settings for 100000, 1000000 and 2000000 iterations. For each set, each device keep its performance with the same rate of iterations per second. The difference between the devices is at, an average level of, 520 iterations per second. That translates to 1.4x faster in favour of the OpenRD Client.

While OpenRD Client performs better, in terms of efficiency, Raspberry Pi seems to doing much better. In terms of CPU, Raspbeery Pi uses a 700MHz (with the possibility of setting it up to 1GHz) ARMv11 processor while OpenRD Client an older 1.2GHz Marvell Sheeva (ARMv5TE). ARMv11 supports an FPU unlike ARMv5 and that is one of the reasons that Raspberry Pi performs quite well despite its lower specifications. In terms of memory, Raspberry Pi uses 256MB DDR2 800MHz (newer models have 512MB RAM), in share with its relatively powerful GPU, while OpenRD Client uses 512MB DDR2 800MHz. OpenRD Client also provides Gigabit Ethernet as well as many more I/O interfaces. Also, OpenRD has preloaded OS, unlike Raspberry Pi that boots from an SD card. During this benchmark, Raspberry Pi was running Rasbian “Wheezy” (unofficial Debian port to armhf) while OpenRD Client Fedora 8.


(Raspberry Pi diagram – http://www.raspberrypi.org/wp-content/uploads/2012/04/Raspi_Iso_Blue.png)


(OpenRD Client Hardware Block diagram – http://www.globalscaletechnologies.com/skins/skin_1/images/OpenRD-Client_back.PNG)

HFS+ on Linux

My MacBook Pro seems to have died. Its hard disk holds lots of data that have not been backed up anywhere else. The important data have been mostly backed up but latest changes haven’t been backed up. Other than that, I had to check the hard disk for bad sectors etc and since I don’t have another Mac to test it on I had to do it on my Fedora box. My system (Fedora 15) would automatically detect and mount the HFS+ hard disk on read only mode. It was also missing the fsck tool for HFS+ partitions. Getting the fsck tool for HFS+ required downloading and installing hfsplus-tools via yum.However, fsck.hfs will not allow you, except if you use the –force option, to scan the partition if it has journalling on, which is the case with HFS+ partitions by default.

But how would I turn off journalling when I don’t have a Mac system to attach my disk on? After a couple of minutes I came across a post on the Ubuntu forum which linked to this blog. The author has a C code that turns journalling off. A fixed version of this code can be found here. The compiled code results in an executable which gets as its only argument the partition that you want to get journalling off.

# gcc journalling_off.c -o journalling_off
# ./journalling_off /dev/sdg2

Next step was to perform the fsck check on the target disk

# fsck.hfs /dev/sdg2
** /dev/sdg2
** Checking HFS Plus volume.
** Checking Extents Overflow file.
** Checking Catalog file.
** Checking multi-linked files.
** Checking Catalog hierarchy.
** Checking Extended Attributes file.
** Checking volume bitmap.
** Checking volume information.
** The volume OS X appears to be OK.

Disk looks OK. Next step is to mount it with read-write permissions:

# mount -t hfplus -o rw,user /dev/sdg2 /mnt/osx

Next issue encountered was the different UIDs between my account on the OS X system and that on the Linux system. Therefore, next step was to change the UIDs under the whole user directory on the OS X disk so I could access without problem with write permissions from my Linux box:

# find panoskrt/ -uid 501 -exec chown panoskrt {} \;

HPC-Europa2 Virtual Cluster liveDVD – milestone6 (final release)

The JRA2 team is proud to announce the release of HPC-Europa2 live DVD milestone 6. You can download milestone 6 ISO image (compressed with size 1.7 GB) from the below links:

CINECA (Italy) – http://www.hpc-europa.eu/?q=node/142
EPCC (Scotland) – http://hpce2jra2.epcc.ed.ac.uk/milestone6.iso.gz
HLRS (Germany) – https://fs.hlrs.de/projects/live-ptd/iso/milestone6.iso.gz

Release Note for Milestone 6
============================
The Virtual Cluster liveDVD:
* provides tools and libraries that are installed and used at the partner sites.
* emaulates the environment of the platforms available at HPC-Europa centers.
* allows hands-on building of a virtual cluster.

The liveDVD contains training and dissemination material published by the
HPC-Europa2 project, including material from the partner centers such as slides,
video tutorials and example code. Optional access to a source code repository enables
the migration of code and data from the Virtual Cluster to the user account created
on the HPC-Europa machines.

The liveDVD is based on SliTaz GNU/Linux, a free operating system, working completely
in RAM and booting from a removable media. The file size of the SliTaz GNU/Linux
3.0 ISO image is 29 MB. Hence, it leaves plenty of space for adding tools, libraries
and training material into this liveDVD. The SliTaz system is quick, responsive, and clean.
A lightweight and elegant desktop is included as well in the 29MB ISO image.

The milestone 6 ISO image has roughly the size of 3.8 GB including several tools
and libraries, as well as training material. Moreover, it contains a documentation
of how to build a virtual cluster using VirtualBox, and HPC-Europa2's Science and
Supercomputing in Europe research highlights for 2009 and 2010. Finally, this milestone
release addresses several bug fixes, such as firefox with flash support and
build scripts for Torque.

Since the previous release (milestone 5), existing packages have been updated, such as:
* MPICH2 to version 1.4.1p1
* Firefox to version 9.0.1 with flash support.
* Paraver to support the updated version of MPICH2.

In addition, this release has added several new packages:
* lava-1.0.6: Platform Lava - an open source version of Platform Load Sharing Facility (LSF).
* info (texinfo-4.13a) and man pages (man-db-2.6.0.2 and man-pages-3.35) for Linux documentation.
* Abiword and Gnumeric for office word documents and spreadsheets.
* Compiler wrappers (based on gcc and gfortran) to emulate Intel, IBM and NEC SX compilers.

You can download milestone 6 ISO image (compressed - size 1.7 GB) from the below link:
    http://www.hpc-europa.eu/?q=node/142

System Requirements
===================
* A laptop or computing with a DVD drive.
* Intel or AMD processor with a hardware virtualization support when using KVM
  and libvirt. Otherwise, this liveDVD can be run under VirtualBox or VMware or similar.

Known Issues
============
* PGI compilers require a license file in order to work (not included in this milestone).
* Totalview requires a license file in order to work (not included in this milestone).
  For requiring a demo license visit:
  http://www.roguewave.com/products/totalview-family/totalview.aspx
* On a MacBook Pro laptop, the mousepad does not work. Need to use an USB mouse
* Resizing video screen on VLC causes an unexpected exit of the program.
* VLC has no sound for viewing mkv videos.
* VLC cannot stream files or view incoming streams.

Acknowledgement
===============
This work was carried out under the HPC-EUROPA2 project (project number: 228398),
with the support of the European Community - Research Infrastructure Action of the FP7.

Ethernet device rename

I have been looking recently to find a way of creating a bridge interface on SliTaz in order to get KVM/libVirt working with the expected br0 interface. Unfortunately, the network configuration files of SliTaz do not provide any information, neither the documentation. A post on the forum didn’t get any replies either. Rather than trying figuring how a proper bridge interface would work on SliTaz, I thought of renaming eth0 to br0, as the later would be expected by KVM/libVirt. As far as I know the following process would need to be followed for other distros as well as there is no specific way of renaming an interface other than using udev rules.

On SliTaz, the required udev rule is defined /etc/udev/rules.d/70-persistent-net.rules. The default entry looks like the following (where Xs the MAC address):

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="XX:XX:XX:XX:XX:XX",
ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

The generated rule matches the eth0 interface with the specific network card. The required change is the renaming of the NAME field to br0. If the targeted system is a virtual machine with changeable MAC address, or most likely a live distro like in my case, the ATTR field, that specifies the MAC address, would need to be changed as well. Changing it to 0* would work and on the next boot the device should be renamed. The final udev rule:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="0*",
ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="br0"

There is one more addition to do on SliTaz and that is to rename the default ethernet device in /etc/network.conf from eth0 to br0. That would allow higher level applications and scripts to look for br0 rather the non-existant eth0.

Compiling SPEC Benchmarks tools on ARM

Some of the SPEC benchmarks come for a variety of architectures but not for ARM, which is not surprising anyway. The easiest way to execute the benchmarks is by using the provided scripts, which is pretty much straight forward operation. The benchmarks come with pre-compiled tools and libraries that are needed by the benchmarks. Among them is Perl, which will fail to compile on ARM systems because of some invalid object definitions in its makefile. These definitions get in the makefile by the Configure script which is called before calling make. Instead of messing around with Configure, I added a couple of lines in the buildtools file, which is responsible for building the SPEC tools on a new architecture or after having modified the host system, in order to remove the unnecessary lines from the corresponding makefiles.

The buildtools script can be found under tools/src/ in the SPEC benchmarks directoy. What is needed is to go in the Perl building section, line 103, and replace the fist part of the building phase with the following oneliner:

(cd $PERLSRC; LD_LIBRARY_PATH=`pwd`; export LD_LIBRARY_PATH; 
./Configure -dOes $PERLFLAGS -Ddosuid=undef -Dprefix=$INSTALLDIR 
-Dd_bincompat3=undef; cat makefile | grep -v built-in 
| grep -v "command line" > makefile.new; cp makefile.new makefile; 
cat x2p/makefile | grep -v built-in | grep -v "command line" > x2p/makefile.new; 
cp x2p/makefile.new x2p/makefile; make; ./perl installperl ) 
|| die "Can't build perl"

Running Fortran on ARM

Generally and very briefly, there is no official Fortran compiler available for the ARM architecture. The easiest way to get Fortran code (specifically Fortran 77) to run on the ARM architecture, or any other architecture that doesn’t have a Fortran compiler, is to convert the Fortran code to C. In order to do that efficiently, we can use Netlib’s f2c command line tool, available for Linux, Unix and Windows.

The steps that need to be followed are:

1) Compile the library – source at http://www.netlib.org/f2c/libf2c.zip
Rename makefile.u to makefile and do make. Copy the generated libf2c.a to /usr/lib and the f2c.h header under /usr/include.
2) Compile the binary – source at http://www.netlib.org/f2c/src/
Rename makefile.u to makefile and do make. Copy the binary f2c under /usr/local/bin.

Supposing we have the foo.f file we can generate the C version by running f2c foo.f, giving us foo.c. It can now be compiled using ‘gcc foo.c -o foo -lf2c‘.

In order to automate this process a while, the following script can be used. It accepts only one argument, the Fortran source file.

#!/bin/bash
fortranFile=$1
fileName=`echo $1 | sed 's/\(.*\)\..*/\1/'`
echo $fileName
f2c $fortranFile
gcc ${fileName}.c -o $fileName -lf2c

UPDATE: There is GCC Fortran compiler for ARM Fedora and Debian and I presume for other distros as well. The issue now is that these distributions are compiled for ARMv5, while the latest ARM processors (Cortex-A8, A9, A15) are of the ARMv7 architecture. The compilers, and the OS in general is therefore unable to make use of the additional instructions sets and FPU. Other distros, such as Slackware, are compiled on even older architecture, ARMv4.