Btw,

As I mentioned this is not the only panic,

it's fairly easy to generate panics with only a vnd device, like

vnconfig /dev/vnd0 /a_file
newfs /dev/vnd0a
mount /dev/vnd0a /mnt/tmpdisk
cp -Rp /a_dir_with_lots_of_files /mnt/tmpdisk


this will sooner or later(on my system) generate a panic if I have a
pretty big filesystem on vnd0a this will allways generate a panic.

I can not generate a kernel dump for this unfortunatly, probably because
the nature of the panic but a have wrote a backtrace by hand when I where
threw into ddb on panic.

This is still on my system with an custom kernel, but I give you the
traceback corresponding to a sourceline of files from source date'd 18
september.
(linenumber extracted with: objdump -l --prefix-addresses -S netbsd.gdb)


the backtrace is following:

*** vndstrategy()
/usr/src/sys/dev/vnd.c:553
c02e5a7d <vndstrategy+0x37d> mov    %edx,0xc(%ebx)
*** spec_strategy()
/usr/src/sys/miscfs/specfs/spec_vnops.c:611
*** ufs_strategy()
/usr/src/sys/ufs/ufs/ufs_vnops.c:1735
*** genfs_gop_write()
/usr/src/sys/miscfs/genfs/genfs_vnops.c:1502

(okey it takes a lot of time to extract linenumber, maybe the above
information
is the most interesting).

VOP_PUTPAGES
ffs_full_fsync
ffs_fsync
VOP_FSYNC
ffs_fsync
sync_fync
VOP_FSYNC
sched_sync



Regards,

Karl





On Sun, 19 Sep 2004, Jason Thorpe wrote:

> Date: Sun, 19 Sep 2004 12:01:34 -0700
> From: Jason Thorpe <thorpej@shagadelic.org>
> To: Roland C. Dowdeswell <elric@imrryr.org>
> Cc: Karl Janmar <karl@utopiafoundation.org>, tech-kern@netbsd.org
> Subject: Re: cgd->vnd panic in BETA_2.0
>
>
> On Sep 19, 2004, at 11:47 AM, Roland C. Dowdeswell wrote:
>
> > Well, I haven't seen the problem, but then I have not [recently]
> > run cgd(4) on vnd(4).  But, from the trace I can guess what is
> > going on here.  Basically, when cgdiodone() is called it checks to
> > see if there are any pending transactions that need to be completed
> > and if there are it will start them.  When the cgd(4) is configured
> > on a vnd(4), this jumps into file system code which expects to be
> > run from a process context not an interrupt context.
> >
> > I'll have to think a bit about how to solve this one.
>
> In general, we probably need to make sure that all disk drivers'
> "strategy" routines are safe for calling from interrupt context.
>
> For vnd, this probably means having a kernel thread waiting around to
> do the actual processing.
>
>          -- Jason R. Thorpe <thorpej@shagadelic.org>
>
>