FS#267 — Bus needs to handle responses even when bus is blocked for requests
Attached to Project— M5 Bugs
Opened by Steve Reinhardt (stever) - Wednesday, 16 May 2007, 05:33PM
Last edited by Ali Saidi (saidi) - Friday, 11 April 2008, 02:06PM
Opened by Steve Reinhardt (stever) - Wednesday, 16 May 2007, 05:33PM
Last edited by Ali Saidi (saidi) - Friday, 11 April 2008, 02:06PM
| Bug | |
| Memory System | |
| New | |
| Steve Reinhardt | |
| All |
| Medium | |
| Normal | |
| 2.0beta2 | |
| 2.0 | |
| Undecided | |
 |
Title should be self-explanatory... see Ron for more details. Currently we can get into deadlock w/o this (in Ali's dual-bus-bridge situation).
This task blocks these from closing
FS#256 - . Two busses and a bridge can deadlock if the bridge between them has a full queue
FS#256 - . Two busses and a bridge can deadlock if the bridge between them has a full queue
What needs to happen:
Currently in the system when the bus tries to do a sendX() and the device return false, it moves into a blocked state waiting for a retry from the device. This prevents the bus from sending responses through. If that device, or another device, sends a response packet to the Bus it should not schedule a retry, or panic if it came from the device waiting on the retry. It should instead send the response through (as long as the bus is not occupied). For a first pass we can implement it by just sending the response through even if the bus is occupied. Eventually we will need to return false and schedule a retry event for that response, even while we are waiting for the retry that caused us to block.
Talk with Ron if you need more details/help
Note that a complete fix will require changes on the device side as well, since currently if a device wants to send a packet but knows it's waiting on a retry from the bus, it will just wait on that retry rather than calling sendTiming(). If it's waiting on a retry for a prior request but then it wants to send a response, it needs to try and send the response in spite of the outstanding retry.
Fortunately I think all of these changes can largely be localized in SimpleTimingPort (I hope).
Since DMA Devices are never the target of requests I think steve's comment is true that it is localized to SimpleTimingPort as a DMA device only sends our requests and the blocking behavior is fine.