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
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
