EeePC notworking

29.10.2010 21:31

Here's something that may interest owners of EeePCs running Linux and is not getting much attention as far as I can see.

The atl1e driver for Atheros L1E (wired) Ethernet interface occasionally corrupts network data. To my knowledge this is the chip used on at least EeePC 901 and 1000. I'm seeing this bug in kernel 2.6.26 and there are reports of it in the latest versions as well.

What this means is that transferring any data through the wired network over a protocol that does not do its own checksumming is unsafe. This includes NFS, HTTP, FTP and so on and using these protocols may leave you with corrupted data. SSH (scp, rsync) is safe, since it performs cryptographic checks and will drop the connection if it encounters an error ("Corrupted MAC on input").

What is known so far is that corruption occurs in 128 byte blocks and that it's highly likely it only happens once per boot or sleep/resume cycle. It appears that the error happens during the transfer of packets from hardware's receive buffers to the kernel. Since this chip does its own TCP checksum check this means that the check is done before the corruption occurs and therefore does not protect you.

Here is an example of corrupted data:

--- correct-data	2010-10-22 22:20:33.000000000 +0200
+++ corrupt-data	2010-10-22 22:20:33.000000000 +0200
@@ -14,15 +14,15 @@
 000000d0  d0 d1 d2 d3 d4 d5 d6 d7  d8 d9 da db dc dd de df  |................|
 000000e0  e0 e1 e2 e3 e4 e5 e6 e7  e8 e9 ea eb ec ed ee ef  |................|
 000000f0  f0 f1 f2 f3 f4 f5 f6 f7  f8 f9 fa fb fc fd fe ff  |................|
-00000100  00 01 02 03 04 05 06 07  08 09 0a 0b 0c 0d 0e 0f  |................|
-00000110  10 11 12 13 14 15 16 17  18 19 1a 1b 1c 1d 1e 1f  |................|
-00000120  20 21 22 23 24 25 26 27  28 29 2a 2b 2c 2d 2e 2f  | !"#$%&'()*+,-./|
-00000130  30 31 32 33 34 35 36 37  38 39 3a 3b 3c 3d 3e 3f  |0123456789:;<=>?|
-00000140  40 41 42 43 44 45 46 47  48 49 4a 4b 4c 4d 4e 4f  |@ABCDEFGHIJKLMNO|
-00000150  50 51 52 53 54 55 56 57  58 59 5a 5b 5c 5d 5e 5f  |PQRSTUVWXYZ[\]^_|
-00000160  60 61 62 63 64 65 66 67  68 69 6a 6b 6c 6d 6e 6f  |`abcdefghijklmno|
-00000170  70 71 72 73 74 75 76 77  78 79 7a 7b 7c 7d 7e 7f  |pqrstuvwxyz{|}~.|
-00000180  80 81 82 83 84 85 86 87  88 89 8a 8b 8c 8d 8e 8f  |................|
+00000100  00 01 02 03 04 05 06 07  08 09 0a 0b 0c 0d 9e 9f  |................|
+00000110  a0 a1 a2 a3 a4 a5 a6 a7  a8 a9 aa ab ac ad ae af  |................|
+00000120  b0 b1 b2 b3 b4 b5 b6 b7  b8 b9 ba bb bc bd be bf  |................|
+00000130  c0 c1 c2 c3 c4 c5 c6 c7  c8 c9 ca cb cc cd ce cf  |................|
+00000140  d0 d1 d2 d3 d4 d5 d6 d7  d8 d9 da db dc dd de df  |................|
+00000150  e0 e1 e2 e3 e4 e5 e6 e7  e8 e9 ea eb ec ed ee ef  |................|
+00000160  f0 f1 f2 f3 f4 f5 f6 f7  f8 f9 fa fb fc fd fe ff  |................|
+00000170  00 01 02 03 04 05 06 07  08 09 0a 0b 0c 0d 0e 0f  |................|
+00000180  10 11 12 13 14 15 16 17  18 19 1a 1b 1c 1d 8e 8f  |................|
 00000190  90 91 92 93 94 95 96 97  98 99 9a 9b 9c 9d 9e 9f  |................|
 000001a0  a0 a1 a2 a3 a4 a5 a6 a7  a8 a9 aa ab ac ad ae af  |................|
 000001b0  b0 b1 b2 b3 b4 b5 b6 b7  b8 b9 ba bb bc bd be bf  |................|

More technical details are in the Linux kernel Bugzilla, bug #12282.

Posted by Tomaž | Categories: Code | Comments »

Leaky thyristors, part 2

24.10.2010 12:14

A while ago I wrote how thyristors in my power supply seem to be conducting a small, but significant current in the reverse direction.

Yesterday I took a handful of thyristors and some equipment and made a few measurements in an attempt to get to the bottom of this effect.

This is the circuit I used:

Measurement circuit for reverse anode currnt in SCR.

I measured Bourns SCR type TIC106D and TIC106N. Both have a specified peak reverse current of 1 mA and gate trigger current of 200 μA.

Note that this circuit operates the SCRs in the 4th quadrant - Gate-cathode voltage is positive while anode-cathode voltage is negative. While this is a valid mode of operation for triacs, I haven't seen any discussion of behavior of SCRs under these conditions. The reverse voltage is significantly smaller that allowed peak reverse voltage (400 V for TIC106D and 800 V for TIC106N)

Here are the results. Red graph shows measurements of two different TIC106N elements while the blue graph shows measurements for one TIC106D:

Reverse anode current versus gate current in SCR.

It appears that approximately half of the gate current flows into the anode instead of the cathode under these conditions. Also, lower the rated voltage of the SCR larger the reverse current.

Gate current used here is much larger than the minimum trigger current required. However, I've often seen advice that thyristors should be triggered by current pulses with an amplitude much larger than the required trigger current.

I would welcome any explanations of these measurements from the perspective of the two-transistor model.

Posted by Tomaž | Categories: Analog | Comments »

Metacity window placement

21.10.2010 17:13

The other day I was trying to solve my problems with window placement on a multi-monitor Desktop by using separate X screens for each monitor. That did not end well so I reverted back to the usual Xinerama mode, which is as far as I know the default mode on all distributions out there and is therefore much better tested in applications.

This time I turned to the desktop environment, actually its window manager Metacity, to see if something can be done there.

What I found is that all misplaced windows were placed by code that gets triggered by a workaround. The code I'm talking about is src/code/place.c around line 686:

  if (meta_prefs_get_disable_workarounds ())
    {
	...
    }
  else
    {
      /* workarounds enabled */
      
      if ((window->size_hints.flags & PPosition) ||
          (window->size_hints.flags & USPosition))
        {
          meta_topic (META_DEBUG_PLACEMENT,
                      "Not placing window with PPosition or USPosition set\n");
          avoid_being_obscured_as_second_modal_dialog (window, fgeom, &x, &y);
          goto done_no_constraints;
        }
    }

The interesting points here are that:

  1. Workaround is enabled by default (and can be disabled by setting /apps/metacity/general/disable_workarounds gconf key).
  2. If workaround is enabled and an application wants to place a window itself (which Mozilla applications want to), Metacity disregards that request. It then skips most of the smart placing code (for example code that makes sure that windows get grouped on the same monitor) and basically just places the window on the first free spot. Which is usually on the wrong monitor.

So, disabling the workaround actually solves the problem!

The documentation says that workarounds are enabled by default for a good reason and that some applications misbehave and want to place windows all over the place. So far the only side effect I've seen is that applications that hide in the tray (XChat, Rhythmbox) don't remember the position of their windows when reopened (which contradicts a bit my understanding of the code above).

Also I'm not sure why the rest of the constraining logic is simply skipped. If I see some terrible side effects of disabled workarounds I'll probably look into it. But so far I don't see much point in creating a patch. Metacity is kind of forgotten right now while all developers are working on the next best thing (called Mutter, not really usable last time I tried). My trivial patch that fixes title bar for gVIM still hasn't been applied upstream.

Posted by Tomaž | Categories: Code | Comments »

Flashback

18.10.2010 18:34

Did you know Adobe Flash stores a lot of information about the sites you visit in your home directory? If you have this plug-in installed clearing browser history doesn't remove all incriminating evidence. Have a look in ~/.macromedia on your machine and chances are there's a lot of info there about your web browsing habits.

I like to have browsers I regularly use set to delete cookies on every restart. While this doesn't make me impossible to track on the web at least I'm not handing out this info on a platter. However Flash doesn't offer this functionality and sadly it's still pretty hard to get around without it.

So here's some code I have in my ~/.gnomerc to help with that:

# Run in a sub-shell to prevent exporting shell variables
(
MACROMEDIA_DIR="$HOME/.macromedia"

if [ ! -e "$MACROMEDIA_DIR" ]; then
	TMPDIR=`mktemp --tmpdir -d "macromedia-$USER-XXXXXX"`

	rm -f "$MACROMEDIA_DIR"
	ln -s "$TMPDIR" "$MACROMEDIA_DIR"
fi
)

This gets executed on every GNOME session. It symlinks .macromedia directory into /tmp where it gets cleaned up on every reboot.

I tend to shutdown my machines over night, so this ensures that any cookies get regularly cleaned out.

Posted by Tomaž | Categories: Code | Comments »

Love and kisses Zaphod

15.10.2010 11:34

I've been using two monitors with a Debian/X.org/GNOME setup at work for more than 3 years now. After a while I got used to an odd window ending up on a wrong monitor. Over time even coworkers with different OSes got tired of laughing at the OpenOffice.org splash screen appearing half-way across monitors (seriously, it's been how many major releases and they still haven't fixed that?).

Anyway, recently I began using my home desktop computer as a media center by permanently connecting it to the TV via a HDMI cable. While it's a minor annoyance if windows pop up on the monitor on the wrong side of the table it's a major pain if they do on the TV behind my back that's turned off most of the time.

The worst offenders seem to be dialog windows by Mozilla software (Firefox, Thunderbird) and I investigated the matter a bit.

First, there's the obligatory Ubuntu forum HOW-TO that is outdated and mostly useless.

Then there's GNOME bug 145503. What seems to be a simple request (force placement of new windows to a single monitor) turns out into the usual flame war with all the usual arguments: "nobody uses that setup" (not likely considering the Ubuntu forums and myself), "X.org infrastructure doesn't allow for properly describing that setup" (ok...), "we don't want to break the current placing algorithm because so much work has gone into it" (right...), etc.

One suggestion did seem useful though: use one X screen for each monitor (called Zaphod mode) instead of one X screen spanning multiple monitors (Xinerama). This creates two completely separate screens running on one X server. The only connection is that both use the same keyboard and you can drag a mouse cursor (but not windows) across the screen boundaries.

Making that setup was not trivial and took some trial and error. This is the xorg.conf I ended up with:

Section "Monitor"
	Identifier	"ViewSonic VG2230wm"
EndSection

Section "Monitor"
	Identifier	"Sony KDL-40V550"
EndSection

Section "Device"
	Identifier	"ATI Radeon HD 4350 0"
	Driver		"radeon"
	Option		"ZaphodHeads"	"DVI-0"
	Screen		0
EndSection

Section "Device"
	Identifier	"ATI Radeon HD 4350 1"
	Driver		"radeon"
	Option		"ZaphodHeads"	"HDMI-0"
	Screen		1
EndSection

Section "Screen"
	Identifier	"Desktop"
	Device		"ATI Radeon HD 4350 0"
	Monitor		"ViewSonic VG2230wm"
EndSection

Section "Screen"
	Identifier	"TV"
	Device		"ATI Radeon HD 4350 1"
	Monitor		"Sony KDL-40V550"
EndSection

Section "ServerLayout"
	Identifier	"Default Layout"
	Screen		0 "Desktop" 0 0
	Screen		1 "TV" RightOf "Desktop"
EndSection

The sad thing is everything today seems to be built around the idea that you are using Xinerama. A lot of things in GNOME break with that setup and worst of all, I could not get HDMI sound to work all. There's also talk that you lose graphics acceleration but I didn't bother to confirm that. It's obvious that neither the X.org driver nor the majority of userland software works well with that setup.

Scrap that idea - Xinerama seems to be the only practical way to have multiple monitors on X.org today. So I guess this only leaves hacking Metacity to solve this problem. As it is only limited to certain repeatable cases I'm hoping it can be solved with some minor fix without major philosophical implications.

Posted by Tomaž | Categories: Code | Comments »

Windows build of z80dasm

12.10.2010 9:00

Remember z80dasm, the Z80 disassembler I made because none of the disassemblers I found were able to disassemble Galaksija's ROM?

Adrien Destugues made a binary for Microsoft Windows systems of the latest version of z80dasm. It's now available for download alongside the source and Debian packages.

Posted by Tomaž | Categories: Code | Comments »