60a899a075
one error recovery action oustanding for a given peripheral. This is bad for several reasons. The first problem is that the error recovery actions would likely be to fix the same problem. (e.g., we queue 5 CCBs to a disk, and the first one comes back with 0x04,0x02. We start error recovery, and the second one comes back with the same status. Then the third one comes back, and so on. Each one causes the drive to get nailed with a start unit, when we really only need one.) The other problem is that we only have space to store one CCB while we're doing error recovery. The subsequent error recovery actions that got started were over-writing the CCBs from previous error recovery actions, but we still tried to call the done routine N times for N error recovery actions. Each call to dadone() was done with the same CCB, though. So on the second one, we got a "biodone: buffer not busy" panic, since the buffer in question had already been through biodone(). In any case, this fixes things so that any any given time, there's only one error recovery action outstanding for any given peripheral driver. Reviewed by: gibbs Reported by: Philippe Regnauld <regnauld@deepo.prosa.dk> [ Philippe wins the "bug finder of the week" award ] |
||
---|---|---|
.. | ||
scsi | ||
cam_ccb.h | ||
cam_conf.h | ||
cam_debug.h | ||
cam_extend.c | ||
cam_extend.h | ||
cam_periph.c | ||
cam_periph.h | ||
cam_queue.c | ||
cam_queue.h | ||
cam_sim.c | ||
cam_sim.h | ||
cam_xpt_periph.h | ||
cam_xpt_sim.h | ||
cam_xpt.c | ||
cam_xpt.h | ||
cam.c | ||
cam.h |