Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Mar 2010 21:22:28 +0800
From:      Alastair Hogge <agh@coolrhaug.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        kochetkov.andrew@gmail.com, Randy Chou <randychou@yahoo.com>, freebsd-hardware@freebsd.org
Subject:   Re: Intel DP45SG motherboard problem (amd64)
Message-ID:  <201003162122.28370.agh@coolrhaug.com>
In-Reply-To: <201003011154.00827.jhb@freebsd.org>
References:  <201002212231.12018.agh@coolrhaug.com> <201002271530.05185.agh@coolrhaug.com> <201003011154.00827.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201003162122.28370.agh>