Date: Sat, 22 Sep 2012 04:32:22 -0400 From: "Thomas Mueller" <mueller23@insightbb.com> To: freebsd-stable@freebsd.org Cc: Jim Harris <jimharris@freebsd.org>, delphij@freebsd.org Subject: Re: tws bug ? (LSI SAS 9750) Message-ID: <12.61.15248.6977D505@smtp01.insight.synacor.com>
next in thread | raw e-mail | index | archive | help
On Fri, Sep 21, 2012 at 5:37 PM, Mike Tancsa <mike@sentex.net> 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 <jimharris@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?12.61.15248.6977D505>