Date: Thu, 02 Oct 2003 09:44:33 +0900 From: Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp> To: Thomas Moestl <t.moestl@tu-bs.de> Cc: freebsd-sparc@freebsd.org Subject: Re: vm_fault for pbuf on sparc64 Message-ID: <ybsoex0mpse.wl@ett.sat.t.u-tokyo.ac.jp> In-Reply-To: <20031001171214.GC746@timesink.dyndns.org> References: <ybssmmgnwjx.wl@ett.sat.t.u-tokyo.ac.jp> <20031001144131.GB746@timesink.dyndns.org> <ybsr81xlzl9.wl@ett.sat.t.u-tokyo.ac.jp> <20031001171214.GC746@timesink.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At Wed, 1 Oct 2003 19:12:15 +0200,
Thomas Moestl wrote:
>
> On Thu, 2003/10/02 at 00:58:10 +0900, Hidetoshi Shimokawa wrote:
> > At Wed, 1 Oct 2003 16:41:31 +0200,
> > Thomas Moestl wrote:
> > >
> > > On Mon, 2003/09/29 at 11:44:02 +0900, Hidetoshi Shimokawa wrote:
> > > > I have a problem with handling of pbuf on sparc64.
> > > > My driver's strategy() routine will write pbuf by CPU rather
> > > > than DMA by the device. I confirmed that the pbuf is mapped in
> > > > pmap_qenter() but I got a vm_fault for the access to the pbuf.
> > >
> > > Hmmm. Can you please post the code in question, so that I can take a
> > > look?
> > >
> > > - Thomas
> >
> > The code is in p4.
> > fwmem_strategy() is in:
> > //depot/user/simokawa/firewire/sys/dev/firewire/fwmem.c
> > callback routine is called from:
> > //depot/user/simokawa/firewire/sys/dev/firewire/fwochi.c
> > //depot/user/simokawa/firewire/sys/dev/firewire/firewire.c
>
> Hmmm, this looks like a bug in the driver:
>
> static void
> fw_strategy(struct bio *bp)
> {
> dev_t dev;
>
> dev = bp->bio_dev;
> if (DEV_FWMEM(dev))
> fwmem_strategy(bp);
>
> bp->bio_error = EOPNOTSUPP;
> bp->bio_flags |= BIO_ERROR;
> bp->bio_resid = bp->bio_bcount;
> biodone(bp);
> }
>
> There's a missing return after your call fwmem_strategy(), so you flag
> the buffer with B_DONE immediately (via biodone()). This causes
> physio() to not wait on the buffer, but to unmap it and proceed. It
> seems that the fwmem transfers are asynchronous, so, depending on the
> timing, the buffer can be accessed from the ISR after it has already
> been unmapped because of this.
Oops, you are right. I have forgotten to insert return when I added
EOPNOTSUPP code. After inserting return, the problem goes away.
Thank you very much for spotting this bug. Apparently, I was going in
wrong direction X-)
/\ Hidetoshi Shimokawa
\/ simokawa@sat.t.u-tokyo.ac.jp
PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybsoex0mpse.wl>