From owner-cvs-all  Mon Jan 18 17:02:53 1999
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id RAA13657
          for cvs-all-outgoing; Mon, 18 Jan 1999 17:02:53 -0800 (PST)
          (envelope-from owner-cvs-all@FreeBSD.ORG)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA13650;
          Mon, 18 Jan 1999 17:02:51 -0800 (PST)
          (envelope-from ken@FreeBSD.org)
From: Kenneth Merry <ken@FreeBSD.ORG>
Received: (from ken@localhost)
	by freefall.freebsd.org (8.8.8/8.8.5) id RAA11248;
	Mon, 18 Jan 1999 17:02:48 -0800 (PST)
Date: Mon, 18 Jan 1999 17:02:48 -0800 (PST)
Message-Id: <199901190102.RAA11248@freefall.freebsd.org>
To: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject: cvs commit: src/sys/cam cam_xpt.c
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

ken         1999/01/18 17:02:48 PST

  Modified files:
    sys/cam              cam_xpt.c 
  Log:
  Generalize the quirk entry for the Conner CFP* drives.  It did just cover
  the CFP2107, but it appears (not surprisingly) that the 1 gig and 4 gig
  versions of that drive have the same problem with tagged queueing.
  
  Also, fix the problem reported in PR kern/9482.  The XPT_DEV_MATCH case in
  xptioctl() wasn't putting a proper path in the CCB before it called
  xpt_action().  When CAMDEBUG is defined, and CAM_DEBUG_TRACE debugging is
  turned on, the CAM_DEBUG statement at the beginning of xpt_action would end
  up deferencing a NULL path pointer.  That of course caused a panic.
  
  My solution is to just stick the xpt peripheral's path in the CCB.
  
  PR:		kern/9482
  Reviewed by:	gibbs
  
  Revision  Changes    Path
  1.38      +24 -4     src/sys/cam/cam_xpt.c

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message