From owner-freebsd-bugs@FreeBSD.ORG Tue Jan 27 10:30:13 2009 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E46910656BB for ; Tue, 27 Jan 2009 10:30:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8C2958FC1D for ; Tue, 27 Jan 2009 10:30:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0RAUDCt020649 for ; Tue, 27 Jan 2009 10:30:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0RAUDOf020646; Tue, 27 Jan 2009 10:30:13 GMT (envelope-from gnats) Date: Tue, 27 Jan 2009 10:30:13 GMT Message-Id: <200901271030.n0RAUDOf020646@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Thomas Quinot Cc: Subject: Re: kern/131032: hald causing panic in atapicam X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Thomas Quinot List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2009 10:30:14 -0000 The following reply was made to PR kern/131032; it has been noted by GNATS. From: Thomas Quinot To: Dominic Fandrey Cc: bug-followup@FreeBSD.org Subject: Re: kern/131032: hald causing panic in atapicam Date: Tue, 27 Jan 2009 11:24:56 +0100 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Dominic Fandrey, 2009-01-27 : > It's that line. I don't think it's supposed to be there: > at /usr/src/sys/modules/cam/../../cam/scsi/scsi_sg.c:798 This module is part of the generic CAM layer, which sits *above* the various SCSI transport modules (e.g. ATAPI/CAM and umass). It is *not* part of ATAPI/CAM, and it is fully expected that this generic code is involved when using umass devices. =20 > As you said atapicam shouldn't be involved at all, so why > is an atapicam funtion doing a giant-locked read? This is *not* an ATAPI/CAM function. Thomas. --+HP7ph2BbKc20aGI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFJfuD3AE1UuDk9JGkRArfzAJ40+tGYYhnKVrMXsylS8A+DlKf9zQCfSplb rJUMrfZuXgDv0eyrT4tJK38= =hM6J -----END PGP SIGNATURE----- --+HP7ph2BbKc20aGI--