CentOS - Feb 2007 - VIA C3 Nehemiah Locks Up

Hello,
	I've got an EPIA-M series motherboard in a system that has locked up 
twice under random conditions. Nothing is logged to the console or logs, 
the system just hangs.

The system is installed with CentOS 4.4 and running the 2.6.9-42.0.8.EL 
i686 kernel. I am aware that older C3 processors had the CMOV problem, 
but that is resolved in the later boards (procinfo below). I've seen a 
few posts about similar problems, but it's not clear whether this is a 
bad board, or if there's an issue with the kernel.

cpuspeed was running, I've since disabled and stopped the service as 
it's been rumored to cause problems. This was mentioned in this bug 
report that is still open :

http://bugs.centos.org/view.php?id=1270

Can anyone confirm that there are no known problems with the VIA C3 
Nehemiah Model 9 and CentOS, or if some (kernel) tweaks are required to 
make these systems stable?

Regards,
	Chris

Board Info :

http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=81

# cat /proc/cpuinfo
processor       : 0
vendor_id       : CentaurHauls
cpu family      : 6
model           : 9
model name      : VIA Nehemiah
stepping        : 8
cpu MHz         : 534.860
cache size      : 64 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr cx8 mtrr pge cmov pat mmx fxsr 
sse rng rng_en ace ace_en
bogomips        : 1070.44

# lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT8623 [Apollo CLE266]
00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP]
00:0f.0 Ethernet controller: VIA Technologies, Inc. VT6105 [Rhine-III] 
(rev 8b)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (rev 80)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (rev 80)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (rev 80)
00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc. 
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] 
(rev 74)
01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8623 [Apollo 
CLE266] integrated CastleRock graphics (rev 03)

Chris Miller wrote:
>
> Hello,
>     I've got an EPIA-M series motherboard in a system that has locked 
> up twice under random conditions. Nothing is logged to the console or 
> logs, the system just hangs.
>
> The system is installed with CentOS 4.4 and running the 
> 2.6.9-42.0.8.EL i686 kernel. I am aware that older C3 processors had 
> the CMOV problem, but that is resolved in the later boards (procinfo 
> below). I've seen a few posts about similar problems, but it's not 
> clear whether this is a bad board, or if there's an issue with the 
> kernel.
>
> cpuspeed was running, I've since disabled and stopped the service as 
> it's been rumored to cause problems. This was mentioned in this bug 
> report that is still open :
>
> http://bugs.centos.org/view.php?id=1270
>
> Can anyone confirm that there are no known problems with the VIA C3 
> Nehemiah Model 9 and CentOS, or if some (kernel) tweaks are required 
> to make these systems stable?
>
Try running a large rsync to system with "hdparm -d" DMA turned on.
I've
read a thread on Via's forums that some of their southbridge chipsets do 
not handle DMA contention and freak out. Turn DMA off using
 hdparm and try the rsync again. I was able to get around this by 
turning dma off for the hard drive.

http://forums.viaarena.com/messageview.aspx?catid=28&threadid=60131&STARTPAGE=3&FTVAR_FORUMVIEWTMP=Linear

I've had a sales engineer that works a lot with Via systems say 
something to me of this topic:
> Are you using any additional peripherals (wireless LAN, USB devices,
> etc...)?  I've found that the DMA issues are usually triggered when a
> DMA-enabled PCI device enters the picture, however, I have seen reports
> of these problems arising in situations where considerable network data
> transfer occurs simultaneously with heavy disk activity.

Jed