From owner-freebsd-hardware@FreeBSD.ORG Tue Mar 16 13:22:32 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C45D31065673 for ; Tue, 16 Mar 2010 13:22:32 +0000 (UTC) (envelope-from agh@coolrhaug.com) Received: from mail5.qnetau.com (mail5.qnetau.com [202.146.209.190]) by mx1.freebsd.org (Postfix) with ESMTP id 1B31D8FC17 for ; Tue, 16 Mar 2010 13:22:31 +0000 (UTC) Received: (qmail 35119 invoked by uid 399); 16 Mar 2010 13:22:29 -0000 Received: from unknown (HELO madcat.localnet) (203.59.9.21) by mail5.qnetau.com with ESMTPM; 16 Mar 2010 13:22:29 -0000 X-Originating-IP: 203.59.9.21 From: Alastair Hogge To: John Baldwin Date: Tue, 16 Mar 2010 21:22:28 +0800 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.5; i386; ; ) References: <201002212231.12018.agh@coolrhaug.com> <201002271530.05185.agh@coolrhaug.com> <201003011154.00827.jhb@freebsd.org> In-Reply-To: <201003011154.00827.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201003162122.28370.agh@coolrhaug.com> Cc: kochetkov.andrew@gmail.com, Randy Chou , freebsd-hardware@freebsd.org Subject: Re: Intel DP45SG motherboard problem (amd64) X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: agh@coolrhaug.com List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 13:22:32 -0000 On Tue March 2 2010 00:54:00 John Baldwin wrote: > On Saturday 27 February 2010 2:30:05 am Alastair Hogge wrote: > > On Sat February 27 2010 00:29:13 John Baldwin wrote: > > > On Friday 26 February 2010 6:15:28 am Alastair Hogge wrote: > > > > On Thu February 25 2010 21:02:58 John Baldwin wrote: > > > > > On Wednesday 24 February 2010 6:32:21 pm Alastair Hogge wrote: > > > > > > On Wed February 24 2010 22:46:29 John Baldwin wrote: > > > > > > > On Tuesday 23 February 2010 5:40:31 pm Alastair Hogge wrote: > > > > > > > > On Wed February 24 2010 00:14:00 John Baldwin wrote: > > > > > > > > > On Tuesday 23 February 2010 8:51:04 am Alastair Hogge wrote: > > > > > > > > > > > > Hello John, > > > > > > > > > > > > > > > > > > > > > > > > In regards to an old email thread: > > > > > > > > > > > > http://lists.freebsd.org/pipermail/freebsd- > > hardware/2009- > > > > > > > > > > > > June/thread.html#5887 > > > > > > > > > > > > > > > > > > > > > > > I've attached the i386 dmesg & "mptable device" from > > > > > > > > > > > > a 9.0-CURRENT -r204168 system which still fails on > > > > > > > > > > > > booting an amd64 CD. > > > > > > > > > > > > > > > > > > > > > > You need to build a custom amd64 kernel which includes > > > > > > > > > > > "device > > > > > > > > > > > > > > mptable" > > > > > > > > > > > > > > > > > > and use that. You may need to set > > 'hint.acpi.0.disabled=1' > > > > > > > > > > > > as well to force ACPI to be disabled. > > > > > > > > > > > > > > > > > > > > OK, I've cross built an amd64 system and installed it on > > > > > > > > > > a spare HDD. Once it booted I ran "mptable -verbose > > > > > > > > > > -dmesg -grope" Here is the > > > > > > > > > > > > > > output: > > > > > > > > > It appears that the new kernel works, yes? > > > > > > > > > > > > > > > > Yes > > > > > > > > > > > > > > > > > That should at least get you a > > > > > > > > > working system now. > > > > > > > > > > > > > > > > Pretty exciting, however, it looks like that booting from an > > > > > > > > installation CD is still problematic. > > > > > > > > > > > > > > Yes, but it is really odd that you do not have any ACPI tables. > > > > > > > All 64-bit machines should have ACPI. > > > > > > > > > > > > > > > > I have no idea why the system does not provide ACPI > > > > > > > > > tables. Is there a BIOS option to enable/disable ACPI > > perhaps? > > > > > > > > > I can't find anything . > > > > > > > > > > > > > > Can you save the output of 'acpidump -d -t' to a file and post > > > > > > > the > > > > > > URL? > > > > > > > > > > If the output is very short, you can just paste it inline into > > > > > > > a reply. > > > > > > > > > > > > # acpidump -d -t > > > > > > /* > > > > > > RSD PTR: OEM=INTEL, ACPI_Rev=2.0x (2) > > > > > > XSDT=0xcfd62e18, length=36, cksum=1 > > > > > > */ > > > > > > acpidump: XSDT is corrupted > > > > > > > > > > Hmm, the checksum for the XSDT is bad. You can try hacking > > > > > src/usr.sbin/acpi/acpidump/acpi.c to disable the checksum check for > > the > > > > > > XSDT. Just look for the 'XSDT is corrupted' string in that source > > file > > > > and > > > > > > > > comment out the call to acpi_checksum(). Something like this: > > > > > > > > > > rsdp = (ACPI_TABLE_HEADER *)acpi_map_sdt(rp- > > > > > >XsdtPhysicalAddress); > > > > > > > > if (memcmp(rsdp->Signature, "XSDT", 4) != 0 /* || > > > > > acpi_checksum(rsdp, rsdp->Length) != 0 */) > > > > > errx(1, "XSDT is corrupted"); > > > > > addr_size = sizeof(uint64_t); > > > > > > > > > > Then see if acpidump -d -t gets any further. > > > > > > > > Pleas see http://pastebin.ca/1811641 > > > > You might noticed a different XSDT in the lastest dump. This is > > > > because > > I > > > > > moved the amd64 hdd to the other system and booted it from there. > > > > Both > > > > > > systems > > > > > > > are identical except for the video cards. > > > > > > > > > I would also look for a BIOS > > > > > update perhaps, > > > > > > > > I've updated the BIOS, but still no luck. > > > > > > > > > and/or complain to your motherboard vendor that their BIOS > > > > > is broken. > > > > > > > > Complaining has begun. > > > > > > Hmm, it looks like it is a common problem with this board actually. > > > Try editing src/contrib/dev/acpica/include/acconfig.h and changing > > > ACPI_CHECKSUM_ABORT to 0 instead of FALSE. > > > > acpidump output doesn't change & the system still fails to boot with ACPI > > enabled. > > This would not change acpidump output, just the kernel. Are you able to > capture the boot messages with this kernel? Full log: http://codepad.org/96PT5OO8 > Specifically, do you get any > error messages from ACPI? Also, what happens if you find the code that > uses ACPI_CHECKSUM_ABORT (I think in sys/contrib/acpica/tables/tbutils.c) > and put #if 0 around that block? Full log with changes: http://codepad.org/QPmK0m9f Not much difference from the first log.