I have two laptops on which I've installed Ubuntu Studio 9.04. The first laptop (Acer) has a Centrino 32-bit Intel CPU in it and the second (HP) has a 64-bit dual core Intel CPU. I'm running the 32-bit version of Ubuntu Studio on the Acer and the 64-bit version on the HP. While testing the installation on the Acer in August, I noticed that after about 100 or so bytes of session data being transmitted (an 'ls' command, an scp session, etc...) the Acer would completely lock up. I created the session using gnome-terminal.

When I say "lock up" I mean a complete system failure. At first I thought it was Xorg freezing. Ctrl-Alt-F1 through F6 would not get me to a VT. Pinging the box returned nothing at this point. The only recourse is to press the power button until the system shuts off and then reboot. The system is fine as long as I don't do any SSH sessions which makes it kind of hard to use... Since this laptop was an Acer, I chalked it up to some instability in the system. Maybe a CPU overheat or bad RAM. It was a $279 refurb after all.

But I recently got a brand new HP HDX16t which is a really nice bit of hardware. To my surprise, SSH sessions do the same exact thing. So I just tested a little more. It has nothing to do with how long I remain connected. I let it sit for about five minutes an pings continued to work while I was logged in via SSH. I also checked the interface on the remote machine (the one I'm connected to the HP from) and watched to verify the amount of data transmitted (roughly) until the system stops responding to pings. It's still about 100 or so bytes and then the system is not responsive. Identical behavior to the Acer.

The chances of me having two laptops that both have dodgy hardware are pretty slim. I've swapped network cables, and switches (Netgeat and Linksys) and the same problem occurs, so it doesn't appear to be network hardware. I tested with NFS for file transfers next to see if this might be a NIC driver issue or maybe a disk I/O driver issue. NFS and rsync both did the same thing. Sadly, since the system locks up, there's no real way I can think of logging the cause of the problem. It's likely that the system is already too far gone before it can log anything.

I also tried doing all of this with Xorg/gdm stopped straight from the console. Same behavior. It seems to only affect the system when it's transferring data out. If I pull in from somewhere everything is fine. I'm going to try and export a flash drive to see if it might be an I/O driver problem with the SATA drive...

---------- Post updated at 01:44 AM ---------- Previous update was at 01:30 AM ----------

Same thing with a flash drive exported via NFS. So it's probably not a disk I/O issue. That leads me to believe that the NIC driver might be problematic. The NIC is listed in lspci as "Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Giabit Ethernet controller (rev02) I'm pretty sure that's a fairly stable driver. Anything else I should check?