FS#256 — . Two busses and a bridge can deadlock if the bridge between them has a full queue
Attached to Project— M5 Bugs
Opened by Ali Saidi (saidi) - Monday, 07 May 2007, 01:06PM
Last edited by Ali Saidi (saidi) - Friday, 11 April 2008, 01:58PM
Opened by Ali Saidi (saidi) - Monday, 07 May 2007, 01:06PM
Last edited by Ali Saidi (saidi) - Friday, 11 April 2008, 01:58PM
| Bug | |
| Memory System | |
| New | |
| No-one | |
| All |
| Critical | |
| Normal | |
| 1.1 | |
| 2.0 | |
| Undecided | |
![]() |
Two busses and a bridge can deadlock if the bridge between them has a full queue in both directions because the bus only retries the device at the head of the retry list. For example in the picture below:
Device <---- i/o bus ----> Bridge <----- mem bus -----> physical memory/cpu
If the bridges queues are full and the device wants to write to physical memory and the cpu wants to write to the device at nearly the same time then the device attempts to write but its sendTiming fails because the Bridge queue is full -- the i/o bus is now blocked and will only retry the device. Similarly on the other side the cpu tries a sendTiming but it fails because the bridge queue is full -- the mem bus is now blocked and will only retry the cpu. Now both busses are blocked blocked waiting for requests that go to the bus bridge to be able to go, and the bus bridge is sitting around waiting for the ability for it to send data, but it never gets that ability since the bus is waiting for the cpu or device to send something.
Device <---- i/o bus ----> Bridge <----- mem bus -----> physical memory/cpu
If the bridges queues are full and the device wants to write to physical memory and the cpu wants to write to the device at nearly the same time then the device attempts to write but its sendTiming fails because the Bridge queue is full -- the i/o bus is now blocked and will only retry the device. Similarly on the other side the cpu tries a sendTiming but it fails because the bridge queue is full -- the mem bus is now blocked and will only retry the cpu. Now both busses are blocked blocked waiting for requests that go to the bus bridge to be able to go, and the bus bridge is sitting around waiting for the ability for it to send data, but it never gets that ability since the bus is waiting for the cpu or device to send something.
This task depends upon
FS#267 - Bus needs to handle responses even when bus is blocked for requests
View Dependency Graph
FS#267 - Bus needs to handle responses even when bus is blocked for requests
View Dependency Graph
This task blocks these from closing
