Date: Thu, 29 Apr 2010 03:29:07 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Malcolm Kay <malcolm.kay@internode.on.net> Cc: freebsd-acpi@freebsd.org Subject: Re: Athlon 64 X2, Gigabyte GA-M55SLI-S4, Fragile Message-ID: <20100429013237.O14495@sola.nimnet.asn.au> In-Reply-To: <201004181033.05506.malcolm.kay@internode.on.net> References: <201004181033.05506.malcolm.kay@internode.on.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100429013237.O14495>