From owner-freebsd-bugs  Wed May 21 12:50:09 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id MAA01794
          for bugs-outgoing; Wed, 21 May 1997 12:50:09 -0700 (PDT)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id MAA01784;
          Wed, 21 May 1997 12:50:04 -0700 (PDT)
Date: Wed, 21 May 1997 12:50:04 -0700 (PDT)
Message-Id: <199705211950.MAA01784@hub.freebsd.org>
To: freebsd-bugs
Cc: 
From: j@uriah.heep.sax.de (J Wunsch)
Subject: Re: kern/3629: /sys/scsi/pt.c doesn't initialize buf_queue
Reply-To: j@uriah.heep.sax.de (J Wunsch)
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

The following reply was made to PR kern/3629; it has been noted by GNATS.

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. ;-)