Re: Notes on kern/57133

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	Hello.  As a followup on this bug I now know what's causing the panic to get triggered.
The issue is that if a request gets requeued requeud, resid gets set to 0, which causes the
KASSERT to fire.  So the question is, is it always the case that if a request gets requeued,
resid gets set to 0, or is that only in certain cases?  A related question is has it always
been the case that resid gets reset to 0 on a requeue, but the mpii(4) driver didn't used to
check for this condition?  Or, is the resetting of resid to 0 a new phenomenon?  Note that I
did a search of all the scsi/atapi drivers in the tree and I couldn't find another instance
where this check is done.  So, I'm inclined to think this check is relatively new and it's just
that no one has run into it before.
While it would be interesting to know why these particular requests are getting requeued, and
I'll try to figure that out, if it is true that resid gets set to 0 on requeue, then this check
is just wrong in the mpii(4) driver.

Any thoughts from anyone?

-Brian