From owner-freebsd-current Sun Aug 10 10:54:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA02848 for current-outgoing; Sun, 10 Aug 1997 10:54:07 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA02843 for ; Sun, 10 Aug 1997 10:54:04 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id LAA11619 for ; Sun, 10 Aug 1997 11:54:04 -0600 (MDT) Message-Id: <199708101754.LAA11619@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: current@FreeBSD.ORG Subject: Re: Trap 9 When Boot SMP In-reply-to: Your message of "Sat, 09 Aug 1997 16:23:28 CDT." <199708092123.QAA14184@zuhause.mn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Aug 1997 11:54:04 -0600 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, Thomas found a 'fix', although we don't understand WHY the problem exists. It appears that %es is getting corrupted somewhere during boot. The 'solution' was: > The es value IS the culprit. > > Havn't found where it is being mangled, I suspect the > doreti code. > > I nailed es to ds at the top of smp_idleloop in init_smp.c. > asm("pushl %ds; popl %es"); --- This corruption of %es is very repeatable, with a value of 0x27 appearing: changing root device to sd2 APIC_IO: routing 8254 via 8259 pn pin 0 Fatal trap 9: general protection fault while in kernel mode cpuid = 0 instruction pointer = 0x8:0xf0216e22 stack pointer = 0x10:0xf42baea4 frame pointer = 0x10:0xf42bbaef8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 6 (cpuidle1) interrupt mask kernel: type 9 trap, code = 0 CPU0 stopping CPUs: 0x00000002 stopped Stopped at _sccnputc+0x22: repe movsl (%esi),%es(%edi) db> trace _sccnputc(cff,53,5,f42baf24,f011fab7) at sccnputc+0x22 _cnputc(53,0,0,53,f42baf70) at _cnputc+0x42 _putchar(53,f42baf94) at _putchar+0x97 _kvprintf(f010d931,f011fa20,f42baf94,a,f42bafa8) at _kvprintf+065 _printf(f010d30,0,f010dadc,f02d2ff4,f01cd307) at _printf+0x3d _smp_idleloop(0) at smp_idleloop+0x24 _fork_trampoline(0,0,f066a200,f42b9000) at _fork_trampoline+0x13 --- anyone have any theories about this one? This is the only reported system having this problem, and I have no clues as to why... -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD