From fmc@reanimators.org  Sun Aug 10 22:59:40 1997
Received: from daemonweed.reanimators.org (root@daemonweed.reanimators.org [198.137.202.50])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA14306
          for <FreeBSD-gnats-submit@freebsd.org>; Sun, 10 Aug 1997 22:59:38 -0700 (PDT)
Received: (from fmc@localhost)
	by daemonweed.reanimators.org (8.8.5/8.8.5) id VAA27228;
	Sun, 10 Aug 1997 21:06:43 -0700 (PDT)
Message-Id: <199708110406.VAA27228@daemonweed.reanimators.org>
Date: Sun, 10 Aug 1997 21:06:43 -0700 (PDT)
From: Frank McConnell <fmc@reanimators.org>
Reply-To: fmc@reanimators.org
To: FreeBSD-gnats-submit@freebsd.org
Subject: ch driver does not use bounce buffers
X-Send-Pr-Version: 3.2

>Number:         4270
>Category:       kern
>Synopsis:       ch driver does not use bounce buffers
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Aug 10 23:00:01 PDT 1997
>Closed-Date:    Fri Nov 19 13:43:52 PST 1999
>Last-Modified:  Fri Nov 19 13:44:13 PST 1999
>Originator:     Frank McConnell
>Release:        FreeBSD 2.2.1-RELEASE i386
>Organization:
Reanimators
>Environment:

	FreeBSD 2.2.1-RELEASE, AMD 486DX4/100, 64MB RAM
	Adaptec 1542CP ISA SCSI i/f, Archive Python DDS DAT drive
	with changer

>Description:

	Using "chio status" to query the changer status fails,
	and provokes the aha driver to report "DMA beyond
	beyond end of ISA".

>How-To-Repeat:

	On a similarly configured system, simply use the "chio status"
	command.

>Fix:
	
	Apply the following diffs to add bounce-buffer support to 
	the ch driver.

	Some notes:
	(a) Works for me.
	(b) Private e-mail from Bill Pechter (see pr kern/4107)
	    seemed to me to indicate that he thought it worked for
	    him too.
	(c) There's another code path in the ch driver where a buffer
	    is allocated on the stack (not malloc()ed) and passed
	    down through scsi_scsi_cmd().  Is that safe?  I don't
	    know.  (See ch_get_params() and the use of sense_data.)


*** ch.c.2.2.1-RELEASE	Fri Mar  7 01:34:26 1997
--- ch.c	Tue Jul 29 21:30:42 1997
***************
*** 36,41 ****
--- 36,42 ----
   *      $Id: ch.c,v 1.34.2.1 1997/03/07 09:34:26 joerg Exp $
   */
  
+ #include "opt_bounce.h"
  #include "opt_scsi.h"
  
  #include <sys/param.h>
***************
*** 511,517 ****
  	struct read_element_status_page_header *pg_hdr;
  	struct read_element_status_descriptor *desc;
  	caddr_t data = NULL;
! 	size_t size, desclen;
  	int avail, i, error = 0;
  	u_int8_t *user_data = NULL;
  
--- 512,518 ----
  	struct read_element_status_page_header *pg_hdr;
  	struct read_element_status_descriptor *desc;
  	caddr_t data = NULL;
! 	size_t size, desclen, datalen;
  	int avail, i, error = 0;
  	u_int8_t *user_data = NULL;
  
***************
*** 528,534 ****
  	 * we can allocate enough storage for all of them.  We assume
  	 * that the first one can fit into 1k.
  	 */
! 	data = (caddr_t)malloc(1024, M_DEVBUF, M_WAITOK);
  	if (error = ch_getelemstatus(sc, sc->sc_firsts[chet], 1, data, 1024))
  		goto done;
  
--- 529,540 ----
  	 * we can allocate enough storage for all of them.  We assume
  	 * that the first one can fit into 1k.
  	 */
! 	datalen = 1024;
! #ifdef BOUNCE_BUFFERS
! 	data = (caddr_t)vm_bounce_kva_alloc(btoc(datalen));
! #else
! 	data = (caddr_t)malloc(datalen, M_DEVBUF, M_WAITOK);
! #endif
  	if (error = ch_getelemstatus(sc, sc->sc_firsts[chet], 1, data, 1024))
  		goto done;
  
***************
*** 545,554 ****
  	 * Reallocate storage for descriptors and get them from the
  	 * device.
  	 */
  	free(data, M_DEVBUF);
  	data = (caddr_t)malloc(size, M_DEVBUF, M_WAITOK);
  	if (error = ch_getelemstatus(sc, sc->sc_firsts[chet],
! 	    sc->sc_counts[chet], data, size))
  		goto done;
  
  	/*
--- 551,566 ----
  	 * Reallocate storage for descriptors and get them from the
  	 * device.
  	 */
+ #ifdef BOUNCE_BUFFERS
+ 	vm_bounce_kva_alloc_free((vm_offset_t)data, btoc(datalen));
+ 	data = (caddr_t)vm_bounce_kva_alloc(btoc(size));
+ #else
  	free(data, M_DEVBUF);
  	data = (caddr_t)malloc(size, M_DEVBUF, M_WAITOK);
+ #endif
+ 	datalen = size;
  	if (error = ch_getelemstatus(sc, sc->sc_firsts[chet],
! 				     sc->sc_counts[chet], data, size))
  		goto done;
  
  	/*
***************
*** 575,581 ****
--- 587,597 ----
  
   done:
  	if (data != NULL)
+ #ifdef BOUNCE_BUFFERS
+ 		vm_bounce_kva_alloc_free((vm_offset_t)data, btoc(datalen));
+ #else
  		free(data, M_DEVBUF);
+ #endif
  	if (user_data != NULL)
  		free(user_data, M_DEVBUF);
  	return (error);
>Release-Note:
>Audit-Trail:

From: "Justin T. Gibbs" <gibbs@plutotech.com>
To: fmc@reanimators.org
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/4270: ch driver does not use bounce buffers 
Date: Mon, 11 Aug 1997 22:03:28 -0600

 >	Some notes:
 
 ...
 
 >	(c) There's another code path in the ch driver where a buffer
 >	    is allocated on the stack (not malloc()ed) and passed
 >	    down through scsi_scsi_cmd().  Is that safe?  I don't
 >	    know.  (See ch_get_params() and the use of sense_data.)
 
 Yes, it happens to be safe as scsi_scsi_cmd has a hack in it to
 detect stack allocations and to bounce them either through a malloced
 buffer or a vm_bounce buffer.  It is a hack since the type drivers
 should not be putting anything on the stack since at the time the
 virtual address is translated/accessed/etc. you may be in a totally
 different process context or none at all.
 
 --
 Justin T. Gibbs
 ===========================================
   FreeBSD: Turning PCs into workstations
 ===========================================
State-Changed-From-To: open->closed 
State-Changed-By: phk 
State-Changed-When: Fri Nov 19 13:43:52 PST 1999 
State-Changed-Why:  
This PR predates the CAM scsi system and does therefore no longer apply. 
>Unformatted:
