vm_fault for pbuf on sparc64
simokawa at sat.t.u-tokyo.ac.jp
Wed Oct 1 17:44:39 PDT 2003
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))
> bp->bio_error = EOPNOTSUPP;
> bp->bio_flags |= BIO_ERROR;
> bp->bio_resid = bp->bio_bcount;
> 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 at sat.t.u-tokyo.ac.jp
PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html
More information about the freebsd-sparc64