Uwe Hermann | A slightly paranoid Debian developer

Oh great. I have experienced random hangups of my Laptop recently, and I had absolutely no clue what caused them, even after a reboot and looking into the logfiles. Today, after another hangup/crash I think I found the problem (but not the solution):

May 16 00:08:35 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
May 16 00:08:35 localhost kernel: sky2 eth0: tx timeout
May 16 00:08:35 localhost kernel: x45 [sky2]
May 16 00:08:35 localhost kernel:  [pg0+943960755/1069376512] sky2_poll+0x469/0x548 [sky2]
May 16 00:08:35 localhost kernel:  [pg0+953407031/1069376512] nv_kern_isr+0x31/0x63 [nvidia]
May 16 00:08:35 localhost kernel:  [net_rx_action+82/199] net_rx_action+0x52/0xc7
May 16 00:08:35 localhost kernel:  [__do_softirq+52/125] __do_softirq+0x34/0x7d
May 16 00:08:35 localhost kernel:  [do_softirq+34/38] do_softirq+0x22/0x26
May 16 00:08:35 localhost kernel:  [irq_exit+41/52] irq_exit+0x29/0x34
May 16 00:44:32 localhost syslogd 1.4.1#17.2: restart.
May 16 00:44:32 localhost kernel: klogd 1.4.1#17.2, log source = /proc/kmsg started.

Note that I could do absolutely nothing on the laptop anymore, no moving the mouse, no typing on the keyboard, no switching from X11 into a text console, no CTRL+ALT+BACKSPACE to kill X11, no CTRL+ALT+DELETE to reboot, nothing.

I think sky2 (network driver) or the NVIDIA driver may be the culprit (or a combination of both). After some searching it seems other people have/had similar problems, but not quite the same...

I guess I'll have to file a bugreport somewhere...

Mhh, Andrew Morton cleans up the Linux kernel code...

We have no less than 65 implementations of TRUE and FALSE in the tree [...]

The patch implements TRUE and FALSE in include/linux/kernel.h and removes all the private versions.

The patch also kills off a few private implementations of NULL.

(via Stuart Yeates)

I have upgraded my kernel to Linux 2.6.16 today with some consequences:

• The "SysKonnect Yukon2 support (EXPERIMENTAL)" option supports my network card just fine now, no need for external sk98lin drivers anymore (gah, I bet this URL will break in a few hours). For googling purposes: I have the following card: Ethernet controller: Marvell Technology Group Ltd. 88E8036 Fast Ethernet Controller (rev 10).
• As I have reported before, my disk drive cannot be talked into using DMA without this kernel patch. The patch does not apply to 2.6.16 anymore, so I have fixed it. May I present: my first Linux kernel patch (IIRC), sent off to the LKML today. Let's see if this gets in the kernel...
• The kernel now includes the ipw2200 driver (not the most recent version, though), which allows me to use my Intel PRO/Wireless 2200BG wireless network card without having to use external drivers. However, the driver does not allow you to put the card into monitor mode. The code is there, it just isn't enabled, for whatever reason. I have created a trivial patch, but it seems that someone else has already fixed this issue. Just in case anyone cares, here's my patch:

  diff -Naur linux-2.6.16.orig/drivers/net/wireless/ipw2200.c linux-2.6.16/drivers/net/wireless/ipw2200.c
  --- linux-2.6.16.orig/drivers/net/wireless/ipw2200.c    2006-03-20 06:53:29.000000000 +0100
  +++ linux-2.6.16/drivers/net/wireless/ipw2200.c 2006-03-24 01:27:15.000000000 +0100
  @@ -38,6 +38,9 @@
   #define DRV_COPYRIGHT  "Copyright(c) 2003-2005 Intel Corporation"
   #define DRV_VERSION     IPW2200_VERSION
  
  +#define CONFIG_IPW2200_MONITOR "y"
  +
  +
   #define ETH_P_80211_STATS (ETH_P_80211_RAW + 1)
  
   MODULE_DESCRIPTION(DRV_DESCRIPTION);
  

  You should better copy+paste the patch from the HTML source or it might break...

• There doesn't seem to be a loop-aes patch for 2.6.16, so I probably cannot mount my encrypted volumes. I'll try the latest release (for 2.6.15-*) tomorrow, if I'm lucky the patches still apply to 2.6.16...
• If you have an NVIDIA graphics card, you need this cumulative patch against the 1.0-8178 NVIDIA Linux x86 drivers, or else they won't compile.

Update 2006-03-24: The loop-aes v3.1c patches apply just fine. I almost forgot to mention the NVIDIA changes...

That's nice. Apparently SUSE/Novell are planning to no longer include any proprietary (kernel) drivers in their Linux distributions. (Most of) the kernel developers dislike binary drivers in the kernel and SUSE/Novell are clearly supporting the developers with their move.

Although they plan a system for including binary drivers from userspace somehow, I still think this is a good sign. I hope it will help to convince some hardware manufacturers to release the source code of some of their (now) proprietary drivers...

This whole debate was started by Arjan van de Ven's original post to the LKML in December 2005, AFAIK.

(via Heise)

Yet another thing that has been on my TODO list for quite a while: encrypted USB thumb drives and/or encrypted external USB hard drives.

I have finally tried this over the weekend using loop-AES. This is very useful for securing your USB thumb drive contents in case you lose it or it gets stolen. Also, I use an external USB hard drive for backups (previously unencrypted). This is encryped now, too.

Here's a quick HOWTO:

1. Get the loop-AES kernel patches, apply them, enable "AES encrypted loop device support" in "Device Drivers -> Block Devices -> Loopback device support", and recompile the kernel.
   I also enabled "loop encryption key scrubbing support" as it seems to promise higher security (can anybody confirm that?).
   If you're using the Debian kernel packages, apt-get install loop-aes-2.6-686 (or a similar package) should suffice.
2. Get a loop-aes enabled losetup, mount etc.:
   apt-get install loop-aes-utils
3. Securely delete the target partition: shred -n 1 -v /dev/sda3.
   Use -n 25 or higher if you want more security and have a few days time to wait for the thing to finish...
4. Setup the loopback device: losetup -e aes256 -C 3 -S 'seed' /dev/loop0 /dev/sda3.
   Notes:
   • I used AES-256 as cipher, but others are possible.
   • The -C 3 means "run hashed password through 3000 iterations of AES-256 before using it for loop encryption. This consumes lots of CPU cycles at loop setup/mount time but not thereafter." (see losetup(8)). This is supposed to be more secure.
   • Using -S 'seed' (replace "seed" with a secret string like "g7sN4" or something) should make brute force attacks a bit harder. Don't forget the seed!
   • You'll be asked for a passphrase > 20 characters. Choose a good one. Don't forget it!
5. Create the filesystem (I used ext3): mke2fs -j /dev/loop0
6. Detach the loopback device: losetup -d /dev/loop0
7. Add this to /etc/fstab:
   /dev/sda3 /mnt/crypted_sda3 ext3 noauto,loop=/dev/loop0,encryption=AES256,itercountk=3 0 0
8. Mount the (now encrypted) partition by supplying the seed and entering the chosen password: mount -o pseed=seed /mnt/crypted_sda3
9. Done. You can now copy stuff to /mnt/crypted_sda3 which will be encrypted automatically.

For a more detailed guide read the Encrypted-Root-Filesystem-HOWTO. A performance comparison of different ciphers is available, but in general I didn't notice too much of a slow-down because of the encryption...