From owner-freebsd-stable@FreeBSD.ORG Sat Sep 22 08:35:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30E321065672 for ; Sat, 22 Sep 2012 08:35:01 +0000 (UTC) (envelope-from mueller23@insightbb.com) Received: from mail.insightbb.com (smtp.insight.synacor.com [208.47.185.22]) by mx1.freebsd.org (Postfix) with ESMTP id E427D8FC08 for ; Sat, 22 Sep 2012 08:35:00 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=1.1 cv=9N16BR7CdXKpNQwIZhku8ahSw/STxmWXHCUXChRWPR0= c=1 sm=0 a=RIz-OqEagCYA:10 a=jLN7EqiLvroA:10 a=_8di5KHbAAAA:8 a=6I5d2MoRAAAA:8 a=8ziC-gI-4xEHFQ84MC8A:9 a=nsfc2OUghBgA:10 a=qm7f-9QL9LsA:10 a=SV7veod9ZcQA:10 a=AcdsImxJPJ9Yo6Ye3TGm+Q==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp01.insight.synacor.com smtp.mail=mueller23@insightbb.com; spf=softfail; sender-id=softfail Authentication-Results: smtp01.insight.synacor.com header.from=mueller23@insightbb.com; sender-id=softfail Received-SPF: softfail (smtp01.insight.synacor.com: transitional domain insightbb.com does not designate 74.134.34.76 as permitted sender) Received: from [74.134.34.76] ([74.134.34.76:44427] helo=localhost) by mail.insightbb.com (envelope-from ) (ecelerity 2.2.2.40 r(29895/29896)) with ESMTP id 12/61-15248-6977D505; Sat, 22 Sep 2012 04:32:23 -0400 Date: Sat, 22 Sep 2012 04:32:22 -0400 Message-ID: <12.61.15248.6977D505@smtp01.insight.synacor.com> From: "Thomas Mueller" To: freebsd-stable@freebsd.org Cc: Jim Harris , delphij@freebsd.org Subject: Re: tws bug ? (LSI SAS 9750) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 08:35:01 -0000 On Fri, Sep 21, 2012 at 5:37 PM, Mike Tancsa wrote: > On 9/21/2012 8:03 PM, Jim Harris wrote: >>> . >>> then a lot of >>> . >>> (probe65:tws0:0:65:0): INQUIRY. CDB: 12 0 0 0 24 0 >>> (probe65:tws0:0:65:0): CAM status: Invalid Target ID >>> (probe65:tws0:0:65:0): Error 22, Unretryable error >>> (probe1:tws0:0:1:0): INQUIRY. CDB: 12 0 0 0 24 0 >>> (probe1:tws0:0:1:0): CAM status: Invalid Target ID >>> (probe1:tws0:0:1:0): Error 22, Unretryable error >>> (probe2:tws0:0:2:0): INQUIRY. CDB: 12 0 0 0 24 0 >>> (probe2:tws0:0:2:0): CAM status: Invalid Target ID >>> . >>> . >>> . >>> (probe63:tws0:0:63:0): INQUIRY. CDB: 12 0 0 0 24 0 >>> (probe63:tws0:0:63:0): CAM status: Invalid Target ID >>> (probe63:tws0:0:63:0): Error 22, Unretryable error >>> (probe64:tws0:0:64:0): INQUIRY. CDB: 12 0 0 0 24 0 >>> (probe64:tws0:0:64:0): CAM status: Invalid Target ID >>> (probe64:tws0:0:64:0): Error 22, Unretryable error >> These can be ignored. CAM is just telling you that there are no >> devices attached at these target IDs. > What about a change similar to what Alexander Motin did in > http://lists.freebsd.org/pipermail/svn-src-head/2012-June/038196.html Jim Harris responded: > Ah, yes. I was thinking you had CAM_DEBUG enabled which is why you > were seeing this spew - but that's not the case. This indeed should > be fixed and not just ignored. > Seeing the attributions on Alexander's commit, you certainly seem to > have a monopoly on controllers that exhibit this problem on FreeBSD. > :) > I believe the CAM_LUN_INVALID here should be fixed as well, similar to > the twa commit. If you send me a revised patch I will commit it. The specific subject of this thread is not my issue, but I did notice problems apparently related to CAM on a SATA hard drive. I use one UFS partition, with FreeBSD 9.0-BETA1 installed (subsequently updated on another partition, using GPT as opposed to MBR), for ports tree and also NetBSD pkgsrc and NetBSD source code. I built NetBSD 5.1_STABLE i386 from FreeBSD and also built xorg-modular on the new NetBSD installation from pkgsrc. Going into and out of the newly installed Xorg resulted in some crashes with the FreeBSD 9.0-BETA1 partition mounted and not cleanly unmounted. File system was damaged, and FreeBSD fsck_ffs wouldn't fix it, went into a loop: Script started on Wed Sep 19 04:15:02 2012 fsck_ffs /dev/ada0p9 ** /dev/ada0p9 ** Last Mounted on /BETA1 ** Phase 1 - Check Blocks and Sizes CANNOT READ BLK: 7584192 CONTINUE? [yn] y THE FOLLOWING DISK SECTORS COULD NOT BE READ: 7584318, 7584319, ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 1475900 files, 4638292 used, 21162419 free (61643 frags, 2637597 blocks, 0.2% fragmentation) ***** FILE SYSTEM STILL DIRTY ***** ***** PLEASE RERUN FSCK ***** Script done on Wed Sep 19 04:17:27 2012 This happened repeatedly, meaning an impasse. I didn't get to record preceding error messages relating to ATA and CAM but, seeing this last message, wonder if there are some bugs in the CAM. I booted that new NetBSD 5.1_STABLE i386 installation, on a USB stick, was able to mount that partition and see it wasn't trashed though there was a message about the dirty flag. I then umounted and ran NetBSD fsck_ffs successfully, just a few files were lost, and FreeBSD can access that partition again. I still intend to be more cautious when in NetBSD, not mounting a FreeBSD partition unnecessarily when doing something crash-prone on my system in NetBSD, such as going into and out of X. Tom