Date: Sun, 18 Apr 2010 10:33:05 +0930 From: Malcolm Kay <malcolm.kay@internode.on.net> To: freebsd-acpi@freebsd.org Cc: Ian Smith <smithi@nimnet.asn.au> Subject: Athlon 64 X2, Gigabyte GA-M55SLI-S4, Fragile Message-ID: <201004181033.05506.malcolm.kay@internode.on.net>
next in thread | raw e-mail | index | archive | help
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.
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
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.
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.
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
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.
Your attention, thoughts and ideas will be appreciated.
Thanks,
Malcolm Kay
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201004181033.05506.malcolm.kay>