AIC7902 w/ seagate U320 drive issue on releng-4 (and current)

Bruce Evans bde at zeta.org.au
Sun Jul 27 03:17:25 PDT 2003


On Sat, 26 Jul 2003, Don Bowman wrote:

> > From: Don Bowman
>
>  ... [scsi errors with seagate cheetah on supermicro with adaptec aic7902]
>
> I sometimes then get a panic due to this KASSERT in
> sys/ufs/ufs/ufs_readwrite.c:
>
>                 /*
>                  * We should only get non-zero b_resid when an I/O error
>                  * has occurred, which should cause us to break above.
>                  * However, if the short read did not cause an error,
>                  * then we want to ensure that we do not uiomove bad
>                  * or uninitialized data.
>                  *
>                  * XXX b_resid is only valid when an actual I/O has occured
>                  * and may be incorrect if the buffer is B_CACHE or if the
>
>                  * last op on the buffer was a failed write.  This KASSERT
>                  * is a precursor to removing it from the UFS code.
>                  */
>                 KASSERT(bp->b_resid == 0, ("bp->b_resid != 0"));

This KASSERT() (and the second paragraph of the comment) somehow was never
committed to -current.  (rev.1.85 in -current became revs.1.65.2.0 and
revs.1.65.2.10 of ufs_readwrite.c in RELENG_4, except the part in
rev.1.65.2.10 wasn't actually in 1.85 or any other commit to -current;
then history was further tangled by merging ufs_readwrite.c into
../ffs/ffs_vnops.c without merging any history.)

I think the KASSERT() is correct, but it doesn't belong in RELENG_4.

It would be interesting to know the contents of the buffer header.  An
inconsistent value of b_resid is less expected here than in most places,
since ffs should never write beyond the end of the partition.  I would
have thought that the case of an i/o error was least problematic -- it
should have caused bread() to fail, so that the above is not reached.

Bruce


More information about the freebsd-scsi mailing list