tws bug ? (LSI SAS 9750)

[Thomas Mueller]

On Fri, Sep 21, 2012 at 5:37 PM, Mike Tancsa <mike at 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 at 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