From owner-freebsd-current@FreeBSD.ORG Mon Aug 17 16:34:53 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05FAC106568B; Mon, 17 Aug 2009 16:34:53 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id BC3FE8FC16; Mon, 17 Aug 2009 16:34:52 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 4EC181E0031D; Mon, 17 Aug 2009 18:34:51 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n7HGViKt003454; Mon, 17 Aug 2009 18:31:44 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id n7HGVi7B003453; Mon, 17 Aug 2009 18:31:44 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Mon, 17 Aug 2009 18:31:44 +0200 To: freebsd-current@FreeBSD.org, mav@FreeBSD.org Message-ID: <20090817163144.GA2991@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: most simple way to hang ahci(4): camcontrol tur on ada disks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 16:34:53 -0000 Hi! After looking again at my `cdrecord -scanbus -V' log... http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010660.html ...I remembered camcontrol(8) can send the test unit ready command as well, so I booted into single user (to avoid having to fsck again) and tried it - and lo and behold, the first `ls' afterwards hung again. So its not something weird cdrecord/cdrdao do, a simple test unit ready is enough to reproduce it, or at least here... (My guess is this has something to do with the fact that sata disks are not atapi i.e. don't speak scsi commands by default so the test unit ready would have to be either emulated or translated and there's probably something missing or broken in that code? Or maybe scsi commands should just be rejected on non-atapi sata devices for now?) HTH, Juergen