From owner-freebsd-current Thu Oct 7 11:28:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E2A6D14A27 for ; Thu, 7 Oct 1999 11:28:30 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.8.7/8.8.7) with ESMTP id LAA05422 for ; Thu, 7 Oct 1999 11:27:56 -0700 Date: Thu, 7 Oct 1999 11:27:56 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: freebsd-current@freebsd.org Subject: i386 wierd one...... kernel stack frame pointer corruption(?) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This just started happening over the last day... It's blowing up during probing because the frame pointer is getting nuked... this is a 2xPPro machine. The code in question is: static u_int64_t isp_get_portname(isp, loopid, nodename) struct ispsoftc *isp; int loopid; int nodename; { u_int64_t wwn = 0; mbreg_t mbs; mbs.param[0] = MBOX_GET_PORT_NAME; mbs.param[1] = loopid << 8; if (nodename) mbs.param[1] |= 1; isp_mboxcmd(isp, &mbs); Which generates: 000012f0 : 12f0: 55 pushl %ebp 12f1: 89 e5 movl %esp,%ebp 12f3: 83 ec 10 subl $0x10,%esp 12f6: 56 pushl %esi 12f7: 53 pushl %ebx 12f8: bb 00 00 00 00 movl $0x0,%ebx 12fd: be 00 00 00 00 movl $0x0,%esi 1302: 66 c7 45 f0 6a movw $0x6a,0xfffffff0(%ebp) 1307: 00 1308: 8b 4d 0c movl 0xc(%ebp),%ecx 130b: 66 c1 e1 08 shlw $0x8,%cx 130f: 66 89 4d f2 movw %cx,0xfffffff2(%ebp) 1313: 83 7d 10 00 cmpl $0x0,0x10(%ebp) 1317: 74 04 je 131d 1319: 80 4d f2 01 orb $0x1,0xfffffff2(%ebp) 131d: 8d 45 f0 leal 0xfffffff0(%ebp),%eax 1320: 50 pushl %eax 1321: ff 75 08 pushl 0x8(%ebp) 1324: e8 b7 27 00 00 call 3ae0 1329: 66 81 7d f0 00 cmpw $0x4000,0xfffffff0(%ebp) <-- EBP is 0 132e: 40 There isn't anything in isp_mboxcmd that I can see would wipe the stack such that I can see in the C code or the generated output. This code itself hasn't changed in months. One thing that is possible is that it's a very deep callstack... It's during probing and it may have called completion on a completing command while down at the bottom of the stack starting another command. If you run out of kernel stack, don't you get some other kind of fault? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message