vm_fault for pbuf on sparc64

[Thomas Moestl]

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.
 
> Is there any way to investigate page table in DDB?

No, except for doing it entirely by hand, which is rather tedious.

	- Thomas

-- 
Thomas Moestl <t.moestl at tu-bs.de>	http://www.tu-bs.de/~y0015675/
              <tmm at FreeBSD.org>		http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0  9C0F 1FE6 4F1D 419C 776C