athlon-mp daily hang 5.2.1

Thierry DELHAISE befree_fr at
Thu May 6 13:02:53 PDT 2004

What I can say to this problem is :

- I've open a bug report : 66098 mainly for the same reason :

I'm running FreeBSD 5.2.1 patch 5 with a fresh build world (it took me 
3  days to have world since gcc was hanging the machine all 5 minutes 
approximatly) on an SMP machine with two PIII 733 and a BIOS compatible 
SMP 1.4 specs (the motherboard is an MSI board) with feature like PM 
enable and APIC enable.

The first think I face out was when I shutdown the machine shutdown -h 
or -r my machine hangs at

stopping ...... vnlru.... stopped after nothing  I 've seen that this 
allways hang when boot() is called on cpu1 and that when sometime when 
boot is called from cpu0 my machine can stop or reboot correctly. But 
boot on cpu1 represent 98% of my tests.

Some days after, when I was running an heavy compilation, I face out 
severals  machine hangs. So I've started to investigate temperature 
problem, RAM problem disk, etc... Just to be sure, I've reinstall this 
machine under Linux with a 2.6 Kernel. No problems. So I come back to 
FreeBSD from a fresh install and start investigating acpi.

Since now 2 weeks, the machine never hangs with just one trick (a bad 
trick for sure) : acpiconf -d . I've disabled acpi management. I let 
boot the machine and setting up acpi conf since the acpi.ko module is 
load at boot time and in the final boot process I disable acpi with 
this command.

May be you could test to see if you experience  allways the same 
problem or if that's solved the problem and report here the problem.

I think acpi code witch seems to be recent in FreeBSD have some problem 
may be due to specific management or bugs of our cheapset : mine is a 
VIA694. I remember that under Linux it took a long time to have a 
stable machine with acpi enable (in fact this was stabilize when IBM 
and Intel provide some code to handle acpi) :  acpi code was clean but 
this was how specs were implemented on cheapset that was breaking 
code.... So they had to handle some specific chipset feature ...

Another way to test could be to disable PM in Bios for a limited time 
to know if the problem persist.

just my two cents.


More information about the freebsd-questions mailing list