From owner-freebsd-sparc64@FreeBSD.ORG Wed Oct 1 10:11:56 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6711216A4B3 for ; Wed, 1 Oct 2003 10:11:56 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id A759743FB1 for ; Wed, 1 Oct 2003 10:11:54 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 14864 invoked by uid 65534); 1 Oct 2003 17:11:53 -0000 Received: from p508E5C19.dip.t-dialin.net (EHLO timesink.dyndns.org) (80.142.92.25) by mail.gmx.net (mp004) with SMTP; 01 Oct 2003 19:11:53 +0200 X-Authenticated: #5374206 Received: by galatea (Postfix, from userid 1001) id 5749CBC; Wed, 1 Oct 2003 19:12:15 +0200 (CEST) Date: Wed, 1 Oct 2003 19:12:15 +0200 From: Thomas Moestl To: Hidetoshi Shimokawa Message-ID: <20031001171214.GC746@timesink.dyndns.org> References: <20031001144131.GB746@timesink.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: freebsd-sparc@freebsd.org Subject: Re: vm_fault for pbuf on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2003 17:11:56 -0000 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 http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C