Odi's astoundingly incomplete notes
New Entries
Graphics board thermal death anatomy
The Radeon board of my old MacBook Pro is dying. During an update the laptop may have overheated. Suddenly the screen got garbled. From now on every few boots only end in a kernel panic (segfault). Compositing refuses to use OpenGL and falls back to using XRender. Also the mouse cursor now has stripes filling the normally empty area of the cursor sprite (see image). The kernel log contains the following messages:[drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD) [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).OS-X doesn't want to boot any more. It gets stuck on an empty blue screen. Booting it in safe mode (holding down the shift key) works, though. Also there the cursor has the same stripy pattern.
Refit still boots and is usable, although I only get a black screen when it initializes the graphics card in "BIOS mode". So I can control Grub only blindly, and I get no early boot messages from the kernel until the KMS driver loads.
Neat workaround for the funny barcode cursor: use the SWCursor option of the radeon driver.
Seems it's time to replace this old buddy with a new one soon.
Add comment
JAX-WS wildcard address
If you have wondered how to make a JAX-WS endpoint listen on the wildcard address:
Endpoint.publish("http://0:8080/MyService", new MyService());
Just use 0 as the IP. If you wonder why that works, look at the implementation of Inet4Address.isAnyLocalAddress() which basically checks for zero.hostapd on Gentoo
When using hostapd on Gentoo, make sure to add the
debug USE flag. Otherwise you will never get any error messages from it. It will only exit with error code 1 and no message even if it's just a silly typo in the config file. Also no logging will work without that USE flag.Orecchiette cime di rapa
This is my version of pasta with Cime di Rapa. Cime di Rapa is an exquisite vegetable with a strong and slightly bitter taste. It's popular mostly in southern Europe and nearly unknown north of the alps. In Zurich you can find it throughout the winter season in smaller shops or on the market, very rarely in supermarkets.

This is a cheap and simple vegan/vegetarian pasta dish that's quickly prepared and tastes great.
You need:
Wash the Cime and chop it. We use the whole plant. Chop the parsley, garlic and onions. Setup the water for the pasta.
In a large pan, heat some olive oil and fry parsley, garlic and onions. I use enough oil so that they are actually fried and not roasted. So the onions do not get brown.

Add the chopped Cime di Rapa and after a minute add some water and/or red wine. Cover with a lid. The Cime should now cook in steam, it should not be roasted.

When the Cime gets soft, add the tomatos, purée and a tea spoon of sambal. Add a bit of water when the sauce gets too thick. Salt to taste. By this time the water should be boiling and you can put in the pasta and salt. When the pasta is ready, so is the sauce. Serve hot.

This is a cheap and simple vegan/vegetarian pasta dish that's quickly prepared and tastes great.
You need:
- fresh Cime di rapa (1 medium sized plant per person)
- Orecchiette
- Olive Oil
- Garlic (1 clove per person)
- Onions
- Tomatos in juice from the tin (200g per person)
- Tomato purée
- Sambal Oelek
- Parsley (fresh or from stock in your freezer)
Wash the Cime and chop it. We use the whole plant. Chop the parsley, garlic and onions. Setup the water for the pasta.
In a large pan, heat some olive oil and fry parsley, garlic and onions. I use enough oil so that they are actually fried and not roasted. So the onions do not get brown.
Add the chopped Cime di Rapa and after a minute add some water and/or red wine. Cover with a lid. The Cime should now cook in steam, it should not be roasted.
When the Cime gets soft, add the tomatos, purée and a tea spoon of sambal. Add a bit of water when the sauce gets too thick. Salt to taste. By this time the water should be boiling and you can put in the pasta and salt. When the pasta is ready, so is the sauce. Serve hot.
Wha Me Eat
BT battery strength support upcoming in 3.3
Yey, the 3.3 kernel will report the battery strength of Bluetooth mice and keyboards! The patch just went in.
Upgraded from x86 to x86_64
Yesterday I have upgraded my 2006 MacBook Pro from 32 to 64 bit Gentoo. It went notably smooth. This was the ONLY reinstall in five years. Here the full beauty of Gentoo shows: smooth upgrades from a 2.4 kernel then to 3.1 today, kde-3 to kde-4.7, glibc, etc. everything without ever completely reinstalling and not being able to do something else while it's upgrading!
Downtime for this one: one night during which it was recompiling everything.
The steps involved were more or less:
Downtime for this one: one night during which it was recompiling everything.
The steps involved were more or less:
- run a full backup
- make sure to have a bit of free space left
- find a decent boot CD with 64bit kernel where WiFi works: SystemRescueCD
- mount the hard drive
- move the old root under a directory (
/old) - install Gentoo stage 3 over the network
- move over the distfiles from
/old/usr/portage/distfiles(they use a lot of space and saves you lots of downloads) - move back the
/homedirectories and/root - copy back
/etc/passwd* /etc/group* - copy back some
/etc/conf.dfiles, especiallynet - copy back
/etc/make.confand changeCHOST="x86_64-pc-linux-gnu" - copy back
/etc/portage/* - copy back
/usr/src/linux, make oldconfig and make - also re-emerge grub and do grub setup again
- reboot, yey!
- emerge xorg-x11
- emerge kde-meta
- go to sleep
- restart into KDE, see Desktop the way I left it, smile at the world
- emerge what else is in
/old/var/lib/portage/worldduring breakfast - delete most of /old, just keep some files in /old/etc and /old/var if needed later
- delete /usr/portage/distfiles
- rely on backup and this website
emerge --sync now takes only seconds while before it could take minutes. No idea what causes that much difference.EDITOR and PAGER in Gentoo
Gentoo lets you define your locale, editor, visual (vim), pager (less). They set the respective environment variables. By default these are unset. Make sure to set them.:
eselect locale eselect pager eselect editor eselect visual eselect vi
openssl version information in ELF binaries
It seems that on Debian the OpenSSL libraries (
Gentoo (and other distributions) does not have OpenSSL built with version information. Using a Debian binary (like spotify) on such a system causes
I have hacked up a little Java utility that does just that. It should work on most ELF binaries that link against openssl. Yes it's Java, as it's the language I'm fluent in. Feel free to convert it to C.
Download ElfFix.
libssl.so, libcrypto.so) contain symbol version information. Binaries linked on a Debian system against OpenSSL may thus contain version requirements on these shared objects.Gentoo (and other distributions) does not have OpenSSL built with version information. Using a Debian binary (like spotify) on such a system causes
ldd to complain about the missing version information:/usr/lib64/libcrypto.so.1.0.0: no version information available /usr/lib64/libssl.so.1.0.0: no version information availableGentoo's
revdep-rebuild thus detects the binary as broken. To fix this issue we can modify the binary and remove the version information in question.I have hacked up a little Java utility that does just that. It should work on most ELF binaries that link against openssl. Yes it's Java, as it's the language I'm fluent in. Feel free to convert it to C.
Download ElfFix.
Oracle without swap
I have been running Oracle 11.2 on x86_64 linux 2.6.39 with no swap and transparent hugepage support. The system has 6GB RAM and
Oracle is configured to using automatic memory management with
While Oracle would run fine most of the time, sometimes connect fails with:
Obviously
So to fix this, I reduced the SGA to 3.5GB. This results in a bit less than 5GB used memory. And now it works fine without swap!
*) This is a nice example why the linux ate my ram website is not right, when it claims
vm.overcommit_memory=0. Oracle is configured to using automatic memory management with
MEMORY_TARGET = 4000M. There is nothing else on the system. So 6GB vs 4GB should be plenty, right? Wrong.While Oracle would run fine most of the time, sometimes connect fails with:
ORA-01034: ORACLE not available ORA-27102: out of memory Linux-x86_64 Error: 12: Cannot allocate memoryIf you go to the server and check the memory usage, all seems fine however:
~ # free -m
total used free shared buffers cached
Mem: 5972 5714 257 0 11 4078
-/+ buffers/cache: 1624 4347
Swap: 0 0 0
After adding a little swap file (1 GB) the problem goes away. With vm.swappiness=40 the swap usage remains stable at around 250MB. So what's going on here?Obviously
free's output of 1.6GB used memory is wrong. The 4GB SGA lies in the shm filesystem, and obviously doesn't show up here. Why? Because in Linux shm is mapped to the filesystem cache*. I guess this is a trick so that reads from shm do not get copied to cache. So to get the real memory usage you have to add the shm usage to free's output. And that sum is 5.6GB. Which is admittedly a bit much for a 6GB swapless system.So to fix this, I reduced the SGA to 3.5GB. This results in a bit less than 5GB used memory. And now it works fine without swap!
*) This is a nice example why the linux ate my ram website is not right, when it claims
Disk cache [...] NEVER EVER takes memory away from [applications].Another example is locked pages in disk cache.
-this may be a fork() related problem: Linux doesn't let you fork unless it can pre-allocate enough space, even if it's never actually used. You may need enough swap space to host the memory image in swap if needed.
I am not convinced. That would mean fork() doesn't work at all in a system with no swap. Which is obviously not the case.