Created attachment 1622 [details]
dmesg with mem=3300M

Created attachment 1623 [details]
lspci

Created attachment 1624 [details]
lsmod

На всякий случай ещё можно попробовать запретить загрузку модуля e752x_edac
(например, занесением его в /etc/hotplug/blacklist) и проверить поведение
системы в таком варианте с полным объёмом памяти (без mem=3300M).  По крайней
мере в случае, если ошибки выявляются достаточно быстро.

Хотя всё-таки подозрение на swiotlb...

В 2.6.18 это не починилось?

К сожалению, у меня больше нет доступа к машине.

Похоже, проблема действительно существует, и наблюдается в 2.6.18:

http://bugzilla.kernel.org/show_bug.cgi?id=7246

Выдрано из последнего фрагмента
(в upstream закрыто как CLOSED PATCH_ALREADY_AVAILABLE):

The 3w-xxxx driver calling pci_map_sg() with sc_data_direction ==
DMA_BIDIRECTIONAL caused data corruption when going through swiotlb.c, on EM64T
with 4GB or higher of RAM.  AMD64 systems using IOMMU were never affected.

This problem doesn't exist in the 3w-xxxx driver in kernels 2.6.23 and higher.
The reason is the 'scsi data buffer accessors' patches removed most instances 
of scsi drivers calling pci_map_sg() and replaced them with scsi_dma_map().

This corrected the problem of the 3w-xxxx driver over-riding the default
sc_data_direction that was causing data corruption with EM64T systems with 
4GB+ RAM.

If you need a driver update for an older kernel to fix this issue, please go to
www.3ware.com, however no driver patch to 3w-xxxx needs to be sent to the
kernel tree to fix this issue.

Применительно к 2.6.18-alt даже не знаю, FIXED это или WONTFIX.

Видимо всё таки фиксед

Закрываю.  И советую всем, кто натолкнется -- бежать и выкидывать 8 серию с обменом на 9ки.