From owner-freebsd-scsi Tue Apr 21 10:24:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA19248 for freebsd-scsi-outgoing; Tue, 21 Apr 1998 10:24:39 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA19134; Tue, 21 Apr 1998 17:24:04 GMT (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id LAA29727; Tue, 21 Apr 1998 11:23:45 -0600 (MDT) Message-Id: <199804211723.LAA29727@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Peter Wemm cc: "Justin T. Gibbs" , gibbs@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: ahh, I think I see part of the problem.. (CAM bouncing) In-reply-to: Your message of "Tue, 21 Apr 1998 19:42:30 +0800." <199804211142.TAA19500@spinner.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Apr 1998 11:19:56 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >In this particular case I've been using the 545S since it panics on >startup rather than after the system is 95% of the way through booting. > >After the bad probe, it finally fails with things like: > >sd0: invalid partition table (or is that invalid partition magic?) >error 22: panic: cannot mount root (2) > >If I do a trace at that point, the nesting is so deep that it scrolls well >off the screen so I can't see the more interesting top few stack frames. Serial debugger??? You should probably trap the first completed transaction and have a look around. >Do you have a nutshell summary of what all the bus dma calls do so that I >have a better chance of finding more useful hints as to what's wrong? Here goes. DMA tags encapsulate the dma characteristics of a particular class of transfers. These include maximum size, alignment, boundary, address limits, and filter function. DMA tag attributes are inherited from parent to child and in final form the dma tag used by a driver might look like this: ISA Bus tag | Driver ISA Attach Tag | MailBox Allocation Tag In the case of the BT driver, there is no parent bus tag to inherit from yet, so a tag is created without a parent in the probe/attach routines. This tag lists all of the constraints of the device. Going one step further down, the MailBox tag, allocated in MI code, lists the MI restrictions on the DMA (for example it must be representable by a 32bit counter), but as it is related to a more restrictive tag, even if the attributes used to create this low level tag are less restrictive than a parent, the system still honors the parents restrictions. Tags are created with the bus_dma_tag_create() function. Once you have a tag, you need to allocate a mapping object for each transfer instance that will use a particular tag. If you wish to map memory that you don't own and hence cannot allocate in a special way to minimize the overhead of the mapping (e.g. the data in a buffer object), you must use the bus_dmamap_create() function. If you can allocate the space yourself, you can allocate the space and the mapping associated with it using the bus_dmamem_alloc() routine. In order to perform a bus dma transfer, you must: 1) Map the object into bus dma space using bus_dmamap_load(). This will call your callback function when a mapping is possible or call it with an error code. 2) Perform a bus_dmamap_sync operation (PREREAD, PREWRITE) to prepare that memory for the transfer. Depending on the platform, this may perform the actual bounce operation, invalidate the cache, etc. 3) Tell the hardware to perform the transfer. 4) Perform another sync operation on the map (POSTREAD, POSTWRITE). This performs the "bounce back" for bounce buffer reads. 5) Unload the mapping. It just so happens that I forgot to perform steps 4 and 5 in the BT driver. Ooops. Diff attached. >Also, what is the function of this variable? >static bus_addr_t bounce_lowaddr = BUS_SPACE_MAXADDR; >It's set to 0xffffffff. (2^32-1) but appears to be used in a role that I'd >almost expect that it was meant to be 0x00ffffff.. On the other hand, it >almost looks stale too since contigmalloc always gives a good page. See my description of DMA tags above. If the MI code does not wish to further restrict a component of the tag it is creating, it uses that of its parent by specifying the maximum possible value. >Cheers, >-Peter >-- >Peter Wemm Netplex Consulting -- Justin ==== //depot/cam/sys/dev/buslogic/bt.c#7 - /a/perforce/src/sys/dev/buslogic/bt.c ==== *** /tmp/tmp.28790.0 Tue Apr 21 11:19:15 1998 --- /a/perforce/src/sys/dev/buslogic/bt.c Tue Apr 21 11:14:32 1998 *************** *** 1358,1363 **** --- 1358,1374 ---- ccb = bccb->ccb; csio = &bccb->ccb->csio; + if ((ccb->ccb_h.flags & CAM_DIR_MASK) != CAM_DIR_NONE) { + bus_dmasync_op_t op; + + if ((ccb->ccb_h.flags & CAM_DIR_MASK) == CAM_DIR_IN) + op = BUS_DMASYNC_POSTREAD; + else + op = BUS_DMASYNC_POSTWRITE; + bus_dmamap_sync(bt->buffer_dmat, bccb->dmamap, op); + bus_dmamap_unload(bt->buffer_dmat, bccb->dmamap); + } + if (bccb == bt->recovery_bccb) { /* * The recovery BCCB does not have a CCB associated To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message