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