Intel DP45SG motherboard problem (amd64)

[John Baldwin]

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?  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?

-- 
John Baldwin