Fortunately this freezing problem is reproducible, even if it takes a little while.

My test setup: an ethernet LAN with my new laptop (x100e), old laptop (x30), and desktop (zino HD)

On the desktop I monitor the new laptop's health like this, so I can get notified shortly after it drops off the network:
    while date && ssh x.x.x.x cat /proc/acpi/thermal_zone/TZ00/temperature; do sleep 9; done

And on the old laptop I am copying across files to the new laptop:
    (sudo tar --exclude 'lost+found' -cf - /u /v) | ssh root@x.x.x.x 'tar -C / -xvf -'

Twice last night I ran this copy and the new laptop froze at more or less the same time. Now I am repeating these tests observing the devices, I see the following:

* the x100e is just at its GDM login screen, I am not touching it
* copying is going fine. The temperature on the laptop starts at 49C and goes up to 57-59C where it stabilises
* the x100e blanks its screen. This is typically 10 minutes after starting the copy.
* immediately the x100e drops off the network: that is, I see
ssh: connect to host x.x.x.x port 22: Connection timed out
(and it no longer responds to pings from either the old laptop or the desktop)

Strangely, if I move the mouse pointer on the new laptop, it's still alive. Once I tried pressing Ctrl-Alt-F1 and that froze it. Normally I can login via gdm, and bring up a terminal window. 'ifconfig eth0' shows the original IP. But a ping to my default gateway sometimes freezes the whole machine, or else just hangs and ^C or ^Z won't stop it. On the most recent failure I did "sudo ifdown -a" which was OK until ^C, then "sudo stop NetworkManager" and a second or two later the whole machine froze.

Now some more data:
* it fails in the above way if I have fglrx driver loaded (and also has radeon.modeset=0 in grub config, although I don't suppose that makes a difference)

* it DOESN'T crash if I leave the screen on a text console using Ctrl-Alt-F1 first. This is despite the fact that the text console also blanks.

* it fails in the above way if I have uninstalled the fglrx driver (leaving radeon.modeset=0 in grub config)

(Aside: I got "System error: InstallArchives() failed" when using the Admin > Hardware Drivers tool. I finished removing the fglrx-* packages using apt-get, and then rebooted. UPDATE: this may be a side-effect of etckeeper, which I notice giving an error about a corrupt git object when doing apt-get. I've now removed etckeeper, I didn't realise it hooked itself in in this way)

* it still fails if I forcibly turn off modeset on the module like this before starting the test, following instructions from https://wiki.ubuntu.com/X/KernelModeSetting

Ctrl-Alt-F1, login as root
stop gdm
modprobe -r radeon drm
modprobe radeon modeset=0
start gdm
-- and switch back to graphical display

(although I don't think this will make a difference, given the radeon.modeset=0 in grub config)

* it DOESN'T crash if I force the vesa display driver in /etc/X11/xorg.conf as per https://wiki.ubuntu.com/X/KernelModeSetting - however the screen doesn't blank either. Also, the screen display is poor as it is stretched out horizontally. /var/log/Xorg.0.log says it's using 1024x768, and the screen is actually 1366x768.

* choosing fbdev in xorg.conf doesn't work at all: I get an error saying "Ubuntu is running in low-graphics mode ... (EE) FBDEV(0): EGA/VGA planes are not yet supported by the fbdev driver"

So what it seems to be is something to do with screen blanking when using either the radeon or fglrx drivers [although I hadn't confirmed from Xorg.0.log that actually the fglrx driver was being used in place of the radeon driver, this is something I still need to do]

This suggests a potential workaround of disabling screen blanking entirely (say in xorg.conf, although I don't know if gnome settings override that). I'd still like to get to the bottom of what's happening to have more confidence in the reliability of my system.