I On May 31, 2013, at 10:10 AM, Andreas Sandberg <[email protected]> wrote:
> Hi Everyone, > > I just discovered a corner case in the IDE disk model. It seems like there > are cases involving draining that cause the simulator to panic with this > message: > > panic: Inconsistent DMA transfer state: dmaState = 2 devState = 0 > > I'm not entirely sure of what's going on, but I suspect something like this > happens: > > 1. A DMA transfer is started > 2. The system starts to drain > 3. doDmaTransfer() and notices that the system is draining and schedules a > retry in the future to avoid traffic while the system is draining. > 4. The system is resumed > 5. The CPU issues a reset command to the IDE disk (devState := > DevicE_Idle_[S|SI]) or some other command that changes the device state. > 6. The DMA transfer is retried with inconsistent state. gem5 behaves like > fully functional firecracker. > > The fact that the disk can be reset without descheduling DMA retries seems a > bit fishy. I'm pretty sure all of the retry events should be descheduled on > many of the state transitions in the disk state machine. Does anyone know how > to best handle this? I'm not sure I want to poke around in that mess. > > Another question is whether the disk really need to hold DMA operations while > draining. Wouldn't it be OK to complete them instead? I suspect that'd be > slightly more robust and the system should drain correctly anyway. > > Thoughts anyone? > > //Andreas My initial reaction is that the disk should go ahead and finish the current operation instead of trying to pull it back at the last moment. Ali _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
