From simokawa@sat.t.u-tokyo.ac.jp  Mon May 19 05:27:49 1997
Received: from mail.sat.t.u-tokyo.ac.jp (dryad.sat.t.u-tokyo.ac.jp [133.11.70.140])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA18250
          for <FreeBSD-gnats-submit@freebsd.org>; Mon, 19 May 1997 05:27:46 -0700 (PDT)
Received: by mail.sat.t.u-tokyo.ac.jp (8.7.5+2.6Wbeta7/3.4Wbeta6-SAT1.0) with ESMTP
	id VAA05187; Mon, 19 May 1997 21:27:28 +0900 (JST)
Received: by ichi.sat.t.u-tokyo.ac.jp (8.8.5/sat-V0.6)
	id VAA00503; Mon, 19 May 1997 21:27:28 +0900 (JST)
Message-Id: <199705191227.VAA00503@ichi.sat.t.u-tokyo.ac.jp>
Date: Mon, 19 May 1997 21:27:28 +0900 (JST)
From: Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp>
Reply-To: simokawa@sat.t.u-tokyo.ac.jp
To: FreeBSD-gnats-submit@freebsd.org
Subject: /sys/scsi/pt.c doesn't initialize buf_queue
X-Send-Pr-Version: 3.2

>Number:         3629
>Category:       kern
>Synopsis:       /sys/scsi/pt.c doesn't initialize buf_queue
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon May 19 05:30:01 PDT 1997
>Closed-Date:    Wed May 21 21:35:28 MEST 1997
>Last-Modified:  Wed May 21 19:10:01 PDT 1997
>Originator:     Hidetoshi Shimokawa
>Release:        FreeBSD 2.2-STABLE i386
>Organization:
Univ. of Tokyo
>Environment:

	FreeBSD-2.2 + EPSON scanner (processor type SCSI device)

>Description:

	pt.c is using pt->buf_queue without initialization.

>How-To-Repeat:

	I found this bug while writing scanner control program.

>Fix:
	
Please apply the following patch

*** pt.c.org	Sat Sep  7 08:09:12 1996
--- pt.c	Mon May 19 21:00:56 1997
***************
*** 86,92 ****
      0,
  	{0, 0},
  	SDEV_ONCE_ONLY,	/* Only one open allowed */
! 	0,
  	"Processor",
  	ptopen,
      sizeof(struct scsi_data),
--- 86,92 ----
      0,
  	{0, 0},
  	SDEV_ONCE_ONLY,	/* Only one open allowed */
! 	ptattach,
  	"Processor",
  	ptopen,
      sizeof(struct scsi_data),
***************
*** 98,103 ****
--- 98,112 ----
  	0,
  	pt_strategy,
  };
+ 
+ static errval
+ ptattach(struct scsi_link *sc_link)
+ {
+ 	struct scsi_data *pt = sc_link->sd;
+ 
+ 	TAILQ_INIT(&pt->buf_queue);
+ 	return 0;
+ }
  
  /*
   * ptstart looks to see if there is a buf waiting for the device


And, I appreciate if you add the following entry in scsiconf.c
I would like to submit scanner control program as port later.

#if NPT > 0
	{
		T_PROCESSOR, T_PROCESSOR, T_FIXED, "EPSON SC", "*", "*",
		"pt", SC_ONE_LU
	},
#endif /* NPT */
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: joerg 
State-Changed-When: Wed May 21 21:35:28 MEST 1997 
State-Changed-Why:  
Suggested fix applied in rev 1.22 of pt.c. 
Thanks! 

From: j@uriah.heep.sax.de (J Wunsch)
To: simokawa@sat.t.u-tokyo.ac.jp
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/3629: /sys/scsi/pt.c doesn't initialize buf_queue
Date: Wed, 21 May 1997 21:30:06 +0200

 As Hidetoshi Shimokawa wrote:
 
 > 	pt.c is using pt->buf_queue without initialization.
 
 I gonna apply your fix, thanks.
 
 > #if NPT > 0
 > 	{
 > 		T_PROCESSOR, T_PROCESSOR, T_FIXED, "EPSON SC", "*", "*",
 > 		"pt", SC_ONE_LU
 > 	},
 > #endif /* NPT */
 
 I think processor target devices are not supposed to be auto-detected.
 When thinking about the integration of your change, i started to
 wonder why my ScanJet at work is doing the job...  and came to the
 conclusion that it's something like
 
 	device pt0 at scbus?
 
 (Or do you have the problem that it's falsely discovered on multiple
 LUNs?  This would be a different thing, and a reason to add it..)
 
 -- 
 cheers, J"org
 
 joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
 Never trust an operating system you don't have sources for. ;-)

From: Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp>
To: joerg_wunsch@uriah.heep.sax.de, j@uriah.heep.sax.de
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/3629: /sys/scsi/pt.c doesn't initialize buf_queue
Date: Thu, 22 May 1997 11:05:31 +0900

 j> As Hidetoshi Shimokawa wrote:
 j> 
 j> > 	pt.c is using pt->buf_queue without initialization.
 j> 
 j> I gonna apply your fix, thanks.
 
 Thanks.
 
 j> > #if NPT > 0
 j> > 	{
 j> > 		T_PROCESSOR, T_PROCESSOR, T_FIXED, "EPSON SC", "*", "*",
 j> > 		"pt", SC_ONE_LU
 j> > 	},
 j> > #endif /* NPT */
 j> 
 j> I think processor target devices are not supposed to be auto-detected.
 j> When thinking about the integration of your change, i started to
 j> wonder why my ScanJet at work is doing the job...  and came to the
 j> conclusion that it's something like
 j> 
 j> 	device pt0 at scbus?
 j> 
 j> (Or do you have the problem that it's falsely discovered on multiple
 j> LUNs?  This would be a different thing, and a reason to add it..)
 
 Oops, I'm sorry. It is unnecessary.
 So could you remove it and add the following inside #if NWORM > 1 -- #endif,
 instead?
 
         {
                 T_READONLY, T_WORM, T_REMOV, "RICOH", "MP62*", "*",
                 "worm", SC_ONE_LU
         },
 
 RICOH MP6200S is a CD-RW (Rewritable) drive.
 Without above entry, it is recognized as CD-ROM drive.
 
 Of course, the drive cannot be used by current worm driver.
 But I wrote a preliminary driver for it. I will send you it later.
 
 I'm sorry again.
 
 /\ Hidetoshi Shimokawa
 \/  simokawa@sat.t.u-tokyo.ac.jp
 PGP public key: finger -l simokawa@sat.t.u-tokyo.ac.jp
>Unformatted:
