Jeremy's Weblog

About a month ago, I installed Gentoo on the new-to-me Acer Aspire1. Installation went like anything else, it is just a normal x86 host after all. I don't have everything on it working, because I don't care. If you are looking for additional resources on getting the extras working, you may want to look here or here.

The exciting part, that I got working and am ready to announce publicly, is my new atom-x86 binpkg repo. What makes this repo different than the binpkgs located on tinderbox.dev.gentoo.org/default-linux is that this repo has CFLAGS specific to the Intel Atom processor. I identified the compiler flags by using the following gcc command: gcc -Q --help=target -march=native and set the following -march=prescott -mtune=generic -msahf. On my linode (review) host, I have a chroot that builds all new packages in my world file once a day which comes from the aspire1. In this manor, I am able to always have binary packages available to me whenever I update my aspire1. Now, I have all the benefits of a source distro and the speed of a binary distro.

If you would like to use this repo, set PORTAGE_BINHOST in /etc/make.conf and add 'getbinpkg' to FEATURES (or use the emerge options directly). Be advised, that thought this works for me, I make no guarantees for you.

PORTAGE_BINHOST="http://tinderbox.jolexa.net/atom-x86/"
FEATURES="${FEATURES} getbinpkg"

I also have an html view of the packages available.

In the mail today, I got the Efika MX Open Client. My first impressions are pretty good. No noise and no moving parts, it should last for a long time. It comes with Ubuntu 9.10 minimal on it out of the box.

That HDMI output makes it the best text console I have ever seen on my 40" 1080p LCD TV! Seriously though, on my TODO:

• Analyze the possibilities for a HTPC. This will be just something fun to do.
• Gentoo Prefix on ARM. This will be the first time, that we know of, that it has been attempted. It shouldn't be that hard because Gentoo already has ARM support which means that most apps already work.
• Install Gentoo Linux on it and help armin76 document the installation process.
• Assisting the Gentoo ARM team with providing binary packages and weekly stages for Gentoo Linux users.
• And more...

Size comparision of Efika MX vs Aspire1

Back of the Efika MX. Power, HDMI, Ethernet, headphone, mic

Front of Efika MX. USB, USB, SD Card Slot

It has been months since seeqpod was shutdown. I have finally found fl4sh.com. I took this recommendation/review and went ahead and signed up for an account. After all, I needed a pandora replacement after they limited free listening to 40 hours per month! Now, if I only had my saved seeqpod playlists! Oh well, rock on.

I've used a custom ~/.screenrc file for at least a year now. I find that this snippet helps improve the usability for me.

#Custom Stuff
caption always "%{= wb}$USER @ %H >> %-Lw%{= r}%50>%n* %t%{-}%+Lw%< %-=<< (%c.%s)"

activity "%c activity -> %n%f %t"
bell "%c bell -> %n%f %t^G"
vbell_msg " *beep* "

startup_message off

defscrollback 500

multiuser off
# Always start screen with utf8 enabled. (screen -U)
defutf8 on

Output (caption at bottom):

As Dan writes, I too survive work by using Gentoo Prefix.

%% uname -a
HP-UX localhost B.11.31 U 9000/800 HP-UX
%% gcc --version
gcc (GCC) 4.2.4 (Gentoo 4.2.4-r01.2 p1.1)
%% bash --version
GNU bash, version 4.0.35(1)-release (hppa2.0n-hp-hpux11.31)
%% ls --version
ls (GNU coreutils) 8.1
Packaged by Gentoo (8.1 (p1))

Thanks to haubi for putting effort into the necessary upstream changes/patches for hppa-hpux support!

The problem:

$ dmesg |grep mtrr
mtrr: no more MTRRs available

I found on my 'new-to-me' AA1 that MTRR handling in the BIOS was messed up. Thanks to this bug report I figured out that I should compile the kernel with MTRR sanitizer enabled. That is:

$ zgrep -i MTRR /proc/config.gz
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1

And output of /proc/mtrr is as follows. Before and after.

$ cat /proc/mtrr
reg00: base=0x0fffe0000 ( 4095MB), size=  128KB, count=1: write-protect
reg01: base=0x0fffc0000 ( 4095MB), size=  128KB, count=1: uncachable
reg02: base=0x000000000 (    0MB), size=  512MB, count=1: write-back
reg03: base=0x020000000 (  512MB), size=  512MB, count=1: write-back
reg04: base=0x03f800000 ( 1016MB), size=    8MB, count=1: uncachable
reg05: base=0x03f600000 ( 1014MB), size=    2MB, count=1: uncachable
reg06: base=0x03f500000 ( 1013MB), size=    1MB, count=1: uncachable
reg07: base=0x000000000 (    0MB), size=  128KB, count=1: uncachable
after kernel modification:
reg00: base=0x000000000 (    0MB), size= 1024MB, count=1: write-back
reg01: base=0x03f500000 ( 1013MB), size=    1MB, count=1: uncachable
reg02: base=0x03f600000 ( 1014MB), size=    2MB, count=1: uncachable
reg03: base=0x03f800000 ( 1016MB), size=    8MB, count=1: uncachable
reg04: base=0x040000000 ( 1024MB), size=  256MB, count=1: write-combining

This is needed for decent video playback with the on-board Intel 945 video.

As Linux-Mag points out (Gentoo Optimizations Benchmarked) using gcc optimizations for "omg, teh speed" is not all that practical. Sure, I'll add some compiler flags here and there as long as I am compiling everything anyway but I don't consider that a feature of Gentoo Linux.

I actually prefer Gentoo for the package management and customization via USE flags (even with the headaches that they cause sometimes).

I had this genius idea about using sshfs with rtorrent. I thought that this use case would fit best in situations where you have good bandwidth but not much diskspace, such as my linode VPS (review). So, I'll attempt to share my findings in this regard.

If you are not familiar with rtorrent. You just need to know that it is a powerful, lightweight bittorrent client. It has a "watch" feature that watches a directory for new torrents, and obviously it can put downloaded files in a specified location. I tried both of these with sshfs.

First, I was having trouble with rtorrent just 'freezing' up when I put a torrent file in the sshfs accessible watch dir. I didn't quite know what was wrong here. Research led me to rtorrent bug 322 and that sshfs did not support filesystems without mmap properly. Darn. More research led me to a recent kernel commit that looked promising. Low and behold, reboot my host with 2.6.31.x kernel and rtorrent works with sshfs watch and destination directory. Yay.

Well, not so fast...

The performance is quite poor with the destination directory on sshfs. This is to be expected because now your download speed for torrents is limited to the download speed of your final destination. But, rtorrent was only giving me a sustained speed of 1/4 of that demonstrated with a simple file copy to the destination. I speculate that this is from the rtorrent overhead or maybe fragmenting? Not sure exactly and I don't care. My solution to this was to use the rtorrent "move on finished" feature that downloads the file to local disk and then moves it to sshfs destination after it is finished. Amazingly, this works quite well.

My testing scenario was the following:
-79MB Gentoo 2008.0 install cd torrent. With the complete sshfs solution, it took ~6 minutes to download (to the sshfs destination) and then 5 minutes to check the hash. So, roundtrip of 11 minutes from start download to seeding. With the on_finished solution, it took 1 minute to download (to local disk) and 1 minute to check the hash and move to the sshfs destination. For a roundtrip of ~2 minutes from start of download to seeding.

In conclusion, this isn't the perfect solution because you impose a large bottleneck into the mix and unintended I/O activity on the local disk. However, it works for me and what I am doing. Maybe it will give someone else some ideas in the future.