Date: Tue, 8 Sep 1998 01:38:12 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: doconnor@gsoft.com.au (Daniel O'Connor) Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: CAM crashes Message-ID: <199809080738.BAA00360@panzer.plutotech.com> In-Reply-To: <XFMail.980901163135.doconnor@gsoft.com.au> from Daniel O'Connor at "Sep 1, 98 04:31:35 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809080738.BAA00360>