On Mon, Jun 10, 2013 at 09:18:47PM -0500, Bryce Edwards wrote:
> Verbose boot:
> 
> https://www.dropbox.com/s/obm8rtavro68ea8/acpi-verbose.jpg
> 
> 
> On Mon, Jun 10, 2013 at 11:27 AM, Bryce Edwards <br...@bryce.net> wrote:
> > On Mon, Jun 10, 2013 at 11:19 AM, John Baldwin <j...@freebsd.org> wrote:
> >> On Monday, June 10, 2013 10:35:07 am Jeremy Chadwick wrote:
> >>> On Mon, Jun 10, 2013 at 09:18:14AM -0500, Bryce Edwards wrote:
> >>> > I'm getting the following warning, and then the system locks:
> >>> >
> >>> > ACPI Warning: Incorrect checksum in table [(bunch of spaces)] - 0x29,
> >>> > should be 0x48
> >>> >
> >>> > Here's a pic: http://db.tt/O6dxONzI
> >>> >
> >>> > System is on a SuperMicro C7X58 motherboard that I just upgraded to
> >>> > BIOS 2.0a, which I would like to stay on if possible.  I tried
> >>> > adjusting all the ACPI related BIOS settings without success.
> >>>
> >>> The message in question refers to hard-coded data in one of the many
> >>> ACPI tables (see acpidump(8) for the list -- there are many).  ACPI
> >>> tables are stored within the BIOS -- the motherboard/BIOS vendor has
> >>> full control over all of them and is fully 100% responsible for their
> >>> content.
> >>>
> >>> It looks to me like they severely botched their BIOS, or somehow it got
> >>> flashed wrong.
> >>>
> >>> You need to contact Supermicro Technical Support and tell them of the
> >>> problem.  They need to either fix their BIOS, or help figure out what's
> >>> become corrupted.  You can point them to this thread if you'd like.
> >>>
> >>> I should note that the corruption/issue is major enough that you are
> >>> missing very key/important lines from your dmesg (after "avail memory"
> >>> but before "kdbX at kdbmuxX", which come from pure reliance upon ACPI.
> >>> Lines such as:
> >>>
> >>> Event timer "LAPIC" quality 400
> >>> ACPI APIC Table: <PTLTD        APIC  >
> >>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
> >>> FreeBSD/SMP: 1 package(s) x 4 core(s)
> >>>  cpu0 (BSP): APIC ID:  0
> >>>  cpu1 (AP): APIC ID:  1
> >>>  cpu2 (AP): APIC ID:  2
> >>>  cpu3 (AP): APIC ID:  3
> >>> ioapic0 <Version 2.0> irqs 0-23 on motherboard
> >>> ioapic1 <Version 2.0> irqs 24-47 on motherboard
> >>>
> >>> In the meantime, you can try booting without ACPI support (there should
> >>> be a boot-up menu option for that) and pray that works.  If it doesn't,
> >>> then your workaround is to roll back to an older BIOS version and/or put
> >>> pressure on Supermicro.  You will find their Technical Support folks are
> >>> quite helpful/responsive to technical issues.
> >>>
> >>> Good luck and keep us posted on what transpires.
> >>
> >> Actually, that message is mostly harmless.  All sorts of vendors ship
> >> tables with busted checksums that are in fact fine. :(  However, the table
> >> name looks very odd which is more worrying.  Booting without ACPI enabled
> >> would be a good first step.  Trying a verbose boot to capture the last
> >> message before the hang would also be useful.
> >>
> >> --
> >> John Baldwin
> >
> > Booting without ACPI did not work for me, although I might be able to
> > hack away at lots of BIOS setting to make it work.  It didn't assign
> > IRQ's to things like the storage controller, etc. soI thought it was
> > probably not worth the effort.
> >
> > I did contact SuperMicro support as well, so we'll see what they have to 
> > say.
> >
> > I'll get a verbose boot posted up in a bit.

A screenshot of a verbose boot is insufficient; as I'm sure you noticed
there are pages upon pages of information before the lock-up/crash.
Those pages are what folks are interested in.

Because the system is hung, I doubt hitting Scroll Lock + using
PageUp/PageDown to go through the kernel message scrollback will work.

You're going to need a serial-based console (i.e. hook something up to
COM1 on the motherboard, and get a null modem cable to connect to
another system where you use a serial port/terminal emulator (ex. PuTTY
for Windows, etc.) that has a scrollback buffer which you can copy-paste
or save.  Set your serial port for 9600 baud, 8 bits, no parity, and 1
stop bit (9600bps, 8N1).  You'll need to have physical access to both
systems simultaneously.

At the VGA console, boot FreeBSD then escape to the loader prompt
("ok") and issue the following commands:

set boot_multicons="YES"
set boot_serial="YES"
set console="comconsole,vidconsole"
boot

You should begin seeing output on the serial port, and the system will
eventually hang/etc..  Then provide the captured output from the serial
port here.  :-)

-- 
| Jeremy Chadwick                                   j...@koitsu.org |
| UNIX Systems Administrator                http://jdc.koitsu.org/ |
| Making life hard for others since 1977.             PGP 4BD6C0CB |

_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Reply via email to