From owner-freebsd-ppc Tue Oct 1 6:12:56 2002 Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3161D37B401; Tue, 1 Oct 2002 06:12:53 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7325C43E81; Tue, 1 Oct 2002 06:12:52 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id JAA19206; Tue, 1 Oct 2002 09:12:51 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g91DCLg10985; Tue, 1 Oct 2002 09:12:21 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15769.40756.959761.373890@grasshopper.cs.duke.edu> Date: Tue, 1 Oct 2002 09:12:20 -0400 (EDT) To: Peter Grehan Cc: Andrew Gallatin , freebsd-ppc@freebsd.org Subject: Re: atomic.h vs atomic.s In-Reply-To: <3D999C61.DCA16E15@freebsd.org> References: <15768.30116.381592.891890@grasshopper.cs.duke.edu> <15768.62718.937391.963035@grasshopper.cs.duke.edu> <3D98FD84.D523B8F@freebsd.org> <15769.39791.486131.152431@grasshopper.cs.duke.edu> <3D999C61.DCA16E15@freebsd.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-ppc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Grehan writes: > > Are you saying that the lwarx instruction itself is not atomic wrt to > > interrupts? > > No, I got it wrong, see my previous email. > > > More or less.. I could compile about 20 files, then the machine would > > crash. Once I made it through all the .o's, I couldn't get a kernel > > to link without the machine falling over, so I gave up and used the > > cross compiler/linker that Mark Peek posted last year.. > > OK, more bugs to fix :-) No, I think it was the same one, but the other direction. When linking a kernel, I ran out of mbufs. Probably because the ref counts never dropped to zero on some clusters, so they never got freed. The crashes every 10-15 files were panic: m_ext refcnt < 0. # rm kernel.debug # make kernel.debug linking kernel.debug Out of mbuf address space! Consider increasing NMBCLUSTERS exclusive sleep mutex Giant r = 0 (0x33b680) locked @../../../vm/vm_object.c:446 panic: mb_reclaim() called with locks held syncing disks... 393 All mbufs or mbuf clusters exhausted, please see tuning(7). <...> BTW, ddb works well enough to be useful just by fixing the compile errors (booting w/o loader) and commenting out a NetBSD (db_symstr) function I didn't want to think about: panic: m_ext refcnt < 0 Welcome to Debugger, panic Stopped at 0x2b1da4: lwz r0, r1, 0x14 db> tr 0xe74c1be0: at panic+0x134 0xe74c1ca0: at m_freem+0x104 0xe74c1cf0: at gem_reset+0x2400 0xe74c1d30: at gem_intr+0xe0 0xe74c1d60: at swi_sched+0x340 0xe74c1da0: at fork_exit+0x100 0xe74c1dd0: at fork_trampoline+0xc saved LR(0x7c0802a2) is invalid. db> e 0xe093c284 -0x1f6c3d7c: 0 Index: db_disasm.c =================================================================== RCS file: /home/ncvs/src/sys/powerpc/powerpc/db_disasm.c,v retrieving revision 1.1 diff -u -r1.1 db_disasm.c --- db_disasm.c 10 Jul 2002 12:21:54 -0000 1.1 +++ db_disasm.c 1 Oct 2002 00:01:15 -0000 @@ -717,8 +717,8 @@ LI = LI << 8; LI = LI >> 6; LI += loc; - db_symstr(pstr, LI, DB_STGY_ANY); - pstr += strlen(pstr); +/* db_symstr(pstr, LI, DB_STGY_ANY); + pstr += strlen(pstr);*/ func &= ~Op_LI; } switch (func & Op_SIMM) { Index: trap.c =================================================================== RCS file: /home/ncvs/src/sys/powerpc/powerpc/trap.c,v retrieving revision 1.33 diff -u -r1.33 trap.c --- trap.c 19 Sep 2002 04:38:35 -0000 1.33 +++ trap.c 30 Sep 2002 23:35:32 -0000 @@ -280,7 +280,7 @@ printtrap(frame->exc, frame, 1, (frame->srr1 & PSL_PR)); #ifdef DDB - if ((debugger_on_panic || db_active) && kdb_trap(frame->exc, 0, frame)) + if (kdb_trap(frame->exc, frame)) return; #endif panic("%s trap", trapname(frame->exc)); The thing which really scares me is the transient abort traps which go away when the compiler is re-run: # make ffs_softdep.o cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -D_KERNEL -include opt_global.h -msoft-float -fno-common -ffreestanding -Wno-error ../../../ufs/ffs/ffs_softdep.c cc: Internal error: Abort trap (program as) Please submit a full bug report. See for instructions. *** Error code 1 Stop in /usr/src/sys/powerpc/compile/G4. # make ffs_softdep.o cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -D_KERNEL -include opt_global.h -msoft-float -fno-common -ffreestanding -Wno-error ../../../ufs/ffs/ffs_softdep.c # Perhaps this is another consequence of the atomic problem... I'll try your kernel and see if the problems go away. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ppc" in the body of the message