From owner-freebsd-current Thu Dec 7 21: 7:35 2000 From owner-freebsd-current@FreeBSD.ORG Thu Dec 7 21:07:29 2000 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from hcarp00g.ca.nortel.com (unknown [47.248.128.170]) by hub.freebsd.org (Postfix) with ESMTP id 4028237B400; Thu, 7 Dec 2000 21:07:28 -0800 (PST) Received: from hcarp00g.ca.nortel.com (hcarp00g.ca.nortel.com [47.196.31.114]) by hcarp00g.ca.nortel.com (8.11.1/8.11.1) with ESMTP id eB848c835502; Thu, 7 Dec 2000 23:08:39 -0500 (EST) (envelope-from atrens@nortel.ca) Date: Thu, 7 Dec 2000 23:08:38 -0500 (EST) From: X-Sender: Reply-To: To: John Baldwin Cc: Subject: possibly related data point - (was) Re: Current Broken! In-Reply-To: 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 John, I'm not a constraints expert either, but I noticed that when I try to build a kernel WITHOUT any optimization, I get a failure in /usr/src/sys/i386/atomic.h . # make atomic.o cc -c -O0 -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/../include -I/usr/src/sys/contrib/dev/acpica/Subsystem/Include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 -fomit-frame-pointer /usr/src/sys/i386/i386/atomic.c In file included from /usr/src/sys/i386/i386/atomic.c:48: machine/atomic.h: In function `atomic_set_char': machine/atomic.h:178: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_clear_char': machine/atomic.h:179: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_add_char': machine/atomic.h:180: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_subtract_char': machine/atomic.h:181: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_set_short': machine/atomic.h:183: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_clear_short': machine/atomic.h:184: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_add_short': machine/atomic.h:185: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_subtract_short': machine/atomic.h:186: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_set_int': machine/atomic.h:188: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_clear_int': machine/atomic.h:189: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_add_int': machine/atomic.h:190: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_subtract_int': machine/atomic.h:191: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_set_long': machine/atomic.h:193: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_clear_long': machine/atomic.h:194: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_add_long': machine/atomic.h:195: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_subtract_long': machine/atomic.h:196: inconsistent operand constraints in an `asm' *** Error code 1 with any optimization, eg -O, there is _NO_ error. Makes me think the optimizer is optimizing out the offending contraints. Ouch. Probably not what was intended. Maybe this is what's biting you ? I cut and pasted the cc command, inserted a -E, removed the #line directives, and captured the offending lines - since my mailer doesn't like really long lines, I've folded them - each function previously occupied a single line. void atomic_set_char (volatile u_char *p, u_char v){ __asm volatile ( "orb %b2,%0" : "=m" (*p) : "0" (*p), "ir" ( v )); } void atomic_clear_char (volatile u_char *p, u_char v){ __asm volatile ( "andb %b2,%0" : "=m" (*p) : "0" (*p), "ir" ( ~v )); } void atomic_add_char (volatile u_char *p, u_char v){ __asm volatile ( "addb %b2,%0" : "=m" (*p) : "0" (*p), "ir" ( v )); } void atomic_subtract_char (volatile u_char *p, u_char v){ __asm volatile ("subb %b2,%0" : "=m" (*p) : "0" (*p), "ir" ( v )); } void atomic_set_short (volatile u_short *p, u_short v){ __asm volatile ("orw %w2,%0" : "=m" (*p) : "0" (*p), "ir" ( v )); } void atomic_clear_short (volatile u_short *p, u_short v){ __asm volatile ("andw %w2,%0" : "=m" (*p) : "0" (*p), "ir" ( ~v )); } void atomic_add_short (volatile u_short *p, u_short v){ __asm volatile ("addw %w2,%0" : "=m" (*p) : "0" (*p), "ir" ( v )); } void atomic_subtract_short (volatile u_short *p, u_short v){ __asm volatile ("subw %w2,%0" : "=m" (*p) : "0" (*p), "ir" ( v )); } void atomic_set_int (volatile u_int *p, u_int v){ __asm volatile ("orl %2,%0" : "=m" (*p) : "0" (*p), "ir" ( v )); } void atomic_clear_int (volatile u_int *p, u_int v){ __asm volatile ("andl %2,%0" : "=m" (*p) : "0" (*p), "ir" ( ~v )); } void atomic_add_int (volatile u_int *p, u_int v){ __asm volatile ("addl %2,%0" : "=m" (*p) : "0" (*p), "ir" ( v )); } void atomic_subtract_int (volatile u_int *p, u_int v){ __asm volatile ("subl %2,%0" : "=m" (*p) : "0" (*p), "ir" ( v )); } void atomic_set_long (volatile u_long *p, u_long v){ __asm volatile ("orl %2,%0" : "=m" (*p) : "0" (*p), "ir" ( v )); } void atomic_clear_long (volatile u_long *p, u_long v){ __asm volatile ("andl %2,%0" : "=m" (*p) : "0" (*p), "ir" ( ~v )); } void atomic_add_long (volatile u_long *p, u_long v){ __asm volatile ("addl %2,%0" : "=m" (*p) : "0" (*p), "ir" ( v )); } void atomic_subtract_long (volatile u_long *p, u_long v){ __asm volatile ("subl %2,%0" : "=m" (*p) : "0" (*p), "ir" ( v )); } So there you have it. I'll step back now since I haven't done any x86 assembly since 1986 ... and this is readily reproduceable in -current. Hope this helps, Cheers, Andrew. On Thu, 7 Dec 2000, John Baldwin wrote: > Date: Thu, 07 Dec 2000 19:39:41 -0800 (PST) > From: John Baldwin > To: The Hermit Hacker > Cc: freebsd-current@FreeBSD.ORG > Subject: Current Broken! > > > On 08-Dec-00 The Hermit Hacker wrote: > > > > Just upgraded the kernel, rebooted and it hung/panic'd with: > > > > panic: spin lock sched lock held by 0x0xc02a73el for > 5 seconds > > cpuid = 1; lapic.id = 01000000 > > Debugger("panic") > > > > I have DDB enabled, and ctl-alt-esc doesn't break to the debugger, so its > > totally hung here ... > > > > dual-cpu celeron, smp enabled ... > > > > Marc G. Fournier ICQ#7615664 IRC Nick: > > Scrappy > > Systems Administrator @ hub.org > > primary: scrappy@hub.org secondary: > > scrappy@{freebsd|postgresql}.org > > Yes. Something is broken with mutexes for the non-I386_CPU (and thus for SMP) > case in -current with the latest commit to i386/include/mutex.h. Of course, > you can revert that commit and then your kernel won't compile.... In the code > I've looked at so far, it looks like possibly a weird register allocation bug > in gcc and/or another weird nuance in the register constraints. In the > specific case I am looking at, the mtx_exit() of Giant in STOPEVENT in > syscall2() failed to properly release an unrecursed, uncontested Giant in > mtx_exit() and fell through to mtx_exit_hard(), which assumes that Giant is > either recursed or contested. When I disassembled the kernel and looked at the > code, gcc assumed that when it looked up curproc for the mtx_enter() operation > (which executed ok as far as I can tell), it could leave the value of curproc > cached in %edi _across_ the call to the stopevent() function. My only guess is > that %edi was clobbered during stopevent(), causing the cmpxchgl to fail, and > throwing the code into mtx_exit_hard() when it shouldn't have. :( > > If anyone is an expert at register constraints, etc., please feel free to look > at the macros in src/sys/i386/include/mutex.h > > -- +-- | Andrew Atrens Nortel Networks, Ottawa, Canada. | | All opinions expressed are my own, not those of any employer. | --+ Berkeley had what we called "copycenter", which is "take it down to the copy center and make as many copies as you want". -- Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message