/var/log/messages doesn't contain anything suspicious. In another forum someone else suggested I try doing an rsync locally via 127.0.0.1 to see if that works. It did. So this seems to specifically have to do with going over the wired NIC. The loaded kernel module is r8169.

I'll test with Gentoo minimal or SystemRescueCD later to see if the problem exists cross distribution on the HP. On the Acer, I ran the 32-bit version of Studio64 (another Debian based AV production distro) and I had no trouble syncing data from one of my other desktops with rsync. Sadly I can't recall pushing data out of the Acer, so that's not much of an answer. I'll see what happens with one of these other distros and post back later.



---------- Post updated at 08:26 AM ---------- Previous update was at 08:18 AM ----------

I also tried stopping sysklogd, moving /var/log/messages to /var/log/message.old and then restarting before doing another rsync test. The system locks up and writes nothing to /var/log/messages. The only message before the crash is the restart of sysklogd. The next set of messages is from the reboot after the crash. So unfortunately the system seems to freeze well before it can save any info to the log.



---------- Post updated at 12:33 PM ---------- Previous update was at 08:26 AM ----------

OK... a little more testing and digging around and I've gotten some new info. It was recommended that I try doing the rsync to the laptop's eth0 IP address. So I did and the rsync worked fine. The only time it becomes a problem is when I try to transfer data out of the laptop over the network.

Seeing that I have the laptop here at work with me now, I decided that this is different networking hardware, worth a shot to try it here just to rule out the switches at home. Same problem transferring to my workstation (Gentoo on there).

Last night I left the system on while it was locked up and it just never came back. Today I went to put a CD in to boot a different Linux distro liveCD and test with that. When I opened the drive I hadn't turned the system off yet and I got kernel error messages:

Code:

ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
ata1.00: cmd 60/08:00:37:08:a9/00:00:10:00:00/40 tag 0 ncq 4096 in
res 40/00:fe:00:00:00/00:00:00:00:00/40 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1.00: failed to set xfermode (err_mask=0x4)
ata1.00: failed to set xfermode (err_mask=0x4)
ata1.00: failed to set xfermode (err_mask=0x4)
end_request: I/O error, dev sda, sector 279513143
end_request: I/O error, dev sda, sector 279513143
end_request: I/O error, dev sda, sector 279513143
sd 0:0:0:0: [sda] Asking for cache data failed
sd 0:0:0:0: [sda] Assuming drive cache: write through
BUG: soft lockup - CPU#0 stuck for 61s! [ata_aux:46]
BUG: soft lockup - CPU#0 stuck for 61s! [ata_aux:46]
BUG: soft lockup - CPU#0 stuck for 61s! [ata_aux:46]
BUG: soft lockup - CPU#0 stuck for 61s! [ata_aux:46]
BUG: soft lockup - CPU#0 stuck for 61s! [ata_aux:46]
BUG: soft lockup - CPU#0 stuck for 61s! [ata_aux:46]

So the kernel is still somewhat alive! I hesitate to say that the problem is the SATA controller or drive because if I don't do any data transfers out of the system over the network it can do other disk intensive work just fine. Audio and video editing work just great which is pretty disk intensive. Here is additional info about the system regarding the CPU and SATA portions of the system:

The CPU in the system is an Intel Core 2 Duo 7550 running a 2.26 GHz.
The SATA controller is an Intel Corporation ICH9M/M-E SATA AHCI Controller
There are six SATA ports detected (in dmesg) ata1 through ata6
The system drive is ata1.00 which is a Western Digital WD3200BEKT-60F3T1
The kernel is using libata version 3.0

I've done more web searches for soft lockups and SATA, but haven't found much that's been fruitful especially where network transfers are concerned. Still... this is progress in understanding the problem.

I should also note that I am having a lot of trouble booting various liveCDs. This is likely owing to the fact that the DVD drive is a SATA drive and the liveCDs are probably expecting IDE, so they can't find the CD-ROM for squashfs after the kernel hands off to whatever init process comes next.