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
