On Fri, Sep 21, 2012 at 5:37 PM, Mike Tancsa <m...@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 <jimhar...@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 _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"