From owner-freebsd-scsi Tue Sep 8 00:38:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA16992 for freebsd-scsi-outgoing; Tue, 8 Sep 1998 00:38:30 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA16987 for ; Tue, 8 Sep 1998 00:38:28 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id BAA00360; Tue, 8 Sep 1998 01:38:12 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199809080738.BAA00360@panzer.plutotech.com> Subject: Re: CAM crashes In-Reply-To: from Daniel O'Connor at "Sep 1, 98 04:31:35 pm" To: doconnor@gsoft.com.au (Daniel O'Connor) Date: Tue, 8 Sep 1998 01:38:12 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Daniel O'Connor wrote... [ Sorry I took so long to reply, not much excuse for it, really. ] > Hi, > I am using CAM on a 2.2.7 system (I have the 19980716 diffs applied) and I can > make it consistently panic the machine with vm_page_free: freeing busy page by > using cdda2wav (I will attach the patches I used to get it to work - they are > really rough though :) Believe it or not, I just reproduced the panic on a -current SMP CAM box. The stack trace is almost identical. > Here is what I get out of gdb -> > test2# gdb -k kernel.0 vmcore.0 > GDB is free software and you are welcome to distribute copies of it > under certain conditions; type "show copying" to see the conditions. > There is absolutely no warranty for GDB; type "show warranty" for details. > GDB 4.16 (i386-unknown-freebsd), > Copyright 1996 Free Software Foundation, Inc... > IdlePTD a50000 > current pcb at 215e10 > panic: vm_page_free: freeing busy page > #0 boot (howto=256) at ../../kern/kern_shutdown.c:266 > 266 dumppcb.pcb_cr3 = rcr3(); > (kgdb) where > #0 boot (howto=256) at ../../kern/kern_shutdown.c:266 > #1 0xf012fde3 in panic (fmt=0xf01c6bc2 "vm_page_free: freeing busy page") > at ../../kern/kern_shutdown.c:400 > #2 0xf01c6c86 in vm_page_freechk_and_unqueue (m=0xf0b0a674) > at ../../vm/vm_page.c:948 > #3 0xf01c6d0a in vm_page_free (m=0xf0b0a674) at ../../vm/vm_page.c:1014 > #4 0xf01c4666 in vm_object_terminate (object=0xf1223280) > at ../../vm/vm_object.c:409 > #5 0xf01c44b7 in vm_object_deallocate (object=0xf1223280) > at ../../vm/vm_object.c:353 > #6 0xf013ca36 in shm_deallocate_segment (shmseg=0xf31634c0) > at ../../kern/sysv_shm.c:148 > #7 0xf013cada in shm_delete_mapping (p=0xf1188c00, shmmap_s=0xf12381c0) > at ../../kern/sysv_shm.c:176 > #8 0xf013d2f1 in shmexit (p=0xf1188c00) at ../../kern/sysv_shm.c:605 > #9 0xf01295a2 in exit1 (p=0xf1188c00, rv=0) at ../../kern/kern_exit.c:176 > #10 0xf0129484 in exit (p=0xf1188c00, uap=0xefbfff94, retval=0xefbfff84) > at ../../kern/kern_exit.c:106 > #11 0xf01dc423 in syscall (frame={tf_es = 39, tf_ds = -272695257, tf_edi = 0, > tf_esi = -1, tf_ebp = -272639212, tf_isp = -272629788, > tf_ebx = 537620576, tf_edx = 0, tf_ecx = 1, tf_eax = 1, tf_trapno = 7, > tf_err = 7, tf_eip = 537571453, tf_cs = 31, tf_eflags = 646, > tf_esp = -272639232, tf_ss = 39}) at ../../i386/i386/trap.c:920 > #12 0x200ab07d in ?? () > (kgdb) > > This crash is easily repeatable.. Sometimes though, cdda2wav works perfectly > and does not crash the machine when it exits, but I haven't worked those > circumstances out yet. > > The command I was running at the time was > 'cdda2wav -Owav -H -P -q -t1 track01.wav' It really looks like a problem with shared memory, or perhaps cdda2wav's use of it, rather than a CAM problem. Notice the stack trace comes from the shared memory code, not from anything in the CAM code. I won't exactly disavow all responsibility for it, but I don't know very much at all about the VM system. If I have time, I'll take a look at it some more, but I don't expect that to happen for a while. I've got a lot of work to do for the CAM integration, and I expect I'll have a fair amount to do afterwards as well. :( If someone else wants to try to tackle this one, please do. I don't think CAM could have anything to do with this, but it is possible. The only place I can think of where CAM does anything with the VM system (besides malloc()/free()) is in the passthrough driver, where it calls vmapbuf() and vunmapbuf() to map CCB data buffers into and out of kernel virtual address space. I'd imagine that if we're doing something wrong there, it could cause problems elsewhere. The only thing is, I've put the passthrough driver under fairly heavy loads, and I've never seen anything like this. So, I suspect it really is a problem with either the shared memory code or the VM system somewhere. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message