Athlon 64 X2, Gigabyte GA-M55SLI-S4, Fragile

[Ian Smith]

On Sun, 18 Apr 2010, Malcolm Kay wrote:

 > I recently installed FreeBSD Release 8.0 (i386) on this machine.
 > With a default boot sequence the machine crashes within a few 
 > minutes (typically less than 4), simply powering down without 
 > warning.

For background: in earlier explorations of this issue in -questions: 
http://lists.freebsd.org/pipermail/freebsd-questions/2010-April/214916.html 
I tried helping with a few questions, then adviced Malcolm to post this 
here; I've no idea what's happening but hoped that someone here would.

 > Processor:AMD Athlon(tm) 64 X2 Dual Core Processor 5600+
 > Motherboard:Gigabyte GA-M55SLI-S4 (Rev 1.0)
 > Drives:2 x WDC WD3200KS-00PFB0 21.00M21 (SATA 300GB)
 >        1 x WDC WD10EADS-00P8B0 01.00A01 (SATA 1TB)
 > 
 > The 300GB drives have been in use for some time one carrying
 > FBSD 6.3 and the other FBSD 7.0. These have booted and run 
 > without problems typically with uptimes of months usually
 > terminated by a mains power failure.
 > 
 > Release 8.0 is installed on the 1TB drive.
 > 
 > With acpi disabled the drives are not found so booting fails:
 > normal for a relatively modern machine?
 >
 > I notice that sysctl for release 8.0 reports:
 >   machdep.idle: amdc1e
 >   machdep.idle_available: spin, amdc1e, hlt, acpi,
 > whereas on earlier releases we have
 >   machdep.cpu_idle_hlt: 1
 >   machdep.hlt_cpus: 0

% find /sys/ -type f -exec grep -iHl amdc1e {} \;
/sys/amd64/amd64/machdep.c
/sys/i386/i386/machdep.c
apparently identical code in both to detect and enable this, as it did.

 > Googling suggested there can be some issues with amdc1e
 > so tried changing machdep.idle=acpi and later machdep.idle=hlt
 > The system remained fragile. I had really expected that the "hlt"
 > option would work.

Sounds a fair expectation.  Glad to hear more recently that this box is 
still happily staying up with:

 > I now have machdep.idle=spin
 > In /etc/rc.local
 >      #!/bin/sh
 >      echo "setting machdep.idle=spin"
 >      /sbin/sysctl machdep.idle=spin
 > With this the machine stays up and runs without apparent 
 > problems. But the spin option seems to me to be a less than 
 > ideal workaround.

Indeed, and that this stops the box crashing must indicate something?

 > I have used verbose boot with machdep.idle=spin and collected the 
 > following:
 >    # acpidump -dt | gzip > xi_home.asl.gz
 >    # gzip < /var/run/dmesg.boot > xi_home.dmesg.boot.gz
 >    # sysctl -a | gzip > xi_home.sysctl-a.gz
 > Ian Smith has suggested that I post to this list and has kindly 
 > offered to host these as:
 >    http://smithi.id.au/mk/xi_home.asl.gz
 >    http://smithi.id.au/mk/xi_home.dmesg.boot.gz
 >    http://smithi.id.au/mk/xi_home.sysctl-a.gz

Only a couple of nibbles so far.  Should be more than enough info.

 > Oh, yes I also have:
 >    hw.acpi.verbose=1
 > in loader.conf but suspect this may be too early in the boot 
 > sequence to be effective.
 > 
 > With verbose boot I see messages:
 > t_delta 16.043d7574c63ce4e0 too long
 > t_delta 15.fbc6ac0df0853a80 too short
 > t_delta 16.02e33b0b45fef6e2 too long
 > t_delta 15.fd000012edba9452 too short
 > t_delta 16.071c8a4c41eb266a too long
 > t_delta 15.f8c6a8fa5f8dde0a too short
 > t_delta 16.05b425c4a1d780d4 too long
 > t_delta 15.fa4fe6f074261dba too short
 > .
 > .
 > .
 > Googling shows a number of reports of similar issues
 > but I've not managed to find any explanations or even what 
 > t_delta represents.

% find /sys/ -type f -exec grep -iHlw t_delta {} \;
/sys/kern/kern_tc.c

Those messages might or might not be relevant to your problem.  I have a 
different issue also accompanied by such messages that Nate Lawson 
thought pointed to an ATA problem that I've not followed up yet, blush.

http://lists.freebsd.org/pipermail/freebsd-acpi/2009-December/006192.html

But I suspect all this may be a red herring to the machdep.idle issue, 
unless it helps someone to connect a few more dots ..

 > Your attention, thoughts and ideas will be appreciated.
 > Thanks,
 > 
 > Malcolm Kay

HTH(alb), Ian