Searched hist:12064 (Results 1 - 3 of 3) sorted by relevance
| /gem5/src/dev/net/ | ||
| H A D | i8254xGBe.hh | diff 12064:39f4d937dd22 Fri Jun 02 20:03:00 EDT 2017 Gabe Black <gabeblack@google.com> dev: Avoid arbitrarily deep stack depth in the i8254xGBe model. When it comes time to send a packet with the i8254xGBe model hooked up to EtherTap and while running in KVM mode, the packet will first go to the EtherTap over the network style port between them. EtherTap, because it's not actually a model of anything in the simulation, will immediately pass the packet off to the real network and report that the transmission was successful to the i8254xGBe. The i8254xGBe will notice that it still has stuff it can send (the KVM mode CPU has no trouble keeping it full) and will, without returning and collapsing the stack, immediately call back into EtherTap with the next packet. This loop repeats, continually deepening the stack, until gem5 crashes with a segfault. To break this loop, a few small changes have been made. First, txFifoTick has been repurposed slightly so that it continuously keeps track of whether there's still work to do to flush out the fifo during the current tick. The code in txWire has been adjusted slightly so that it clears that variable at the start (also removing some redundancy), so that other code can set it again if more work needs to be done. Specifically, the ethTxDone function will set that flag. If there's more work to be done flushing the Fifo while in tick(), it will loop until txFifoTick stays cleared, meaning either the Fifo is empty, or the object on the other end hasn't said it's done yet. Finally, a new bool member called inTick has been added which keeps track of whether the tick() function is still active somewhere in the callstack. If it is, then the tick event shouldn't be rescheduled in ethTxDone, since tick will take care of that before it returns. It won't check to see if it needs to, and so without this check there's a panic from scheduling the same event twice. It's not completely clear that the Fifo should send packets over and over as fast as the other side accepts them within the same tick, although it's not clear that it shouldn't either. If not, then probably all that would need to change would be to remove the "while" loop so that the tick event would be rescheduled, and the Fifo would be further emptied the next time around. Change-Id: I653379b43389d0539ecfadb3fc6c40e38a8864c2 Reviewed-on: https://gem5-review.googlesource.com/3642 Reviewed-by: Andreas Hansson <andreas.hansson@arm.com> Maintainer: Gabe Black <gabeblack@google.com> |
| H A D | i8254xGBe.cc | diff 12064:39f4d937dd22 Fri Jun 02 20:03:00 EDT 2017 Gabe Black <gabeblack@google.com> dev: Avoid arbitrarily deep stack depth in the i8254xGBe model. When it comes time to send a packet with the i8254xGBe model hooked up to EtherTap and while running in KVM mode, the packet will first go to the EtherTap over the network style port between them. EtherTap, because it's not actually a model of anything in the simulation, will immediately pass the packet off to the real network and report that the transmission was successful to the i8254xGBe. The i8254xGBe will notice that it still has stuff it can send (the KVM mode CPU has no trouble keeping it full) and will, without returning and collapsing the stack, immediately call back into EtherTap with the next packet. This loop repeats, continually deepening the stack, until gem5 crashes with a segfault. To break this loop, a few small changes have been made. First, txFifoTick has been repurposed slightly so that it continuously keeps track of whether there's still work to do to flush out the fifo during the current tick. The code in txWire has been adjusted slightly so that it clears that variable at the start (also removing some redundancy), so that other code can set it again if more work needs to be done. Specifically, the ethTxDone function will set that flag. If there's more work to be done flushing the Fifo while in tick(), it will loop until txFifoTick stays cleared, meaning either the Fifo is empty, or the object on the other end hasn't said it's done yet. Finally, a new bool member called inTick has been added which keeps track of whether the tick() function is still active somewhere in the callstack. If it is, then the tick event shouldn't be rescheduled in ethTxDone, since tick will take care of that before it returns. It won't check to see if it needs to, and so without this check there's a panic from scheduling the same event twice. It's not completely clear that the Fifo should send packets over and over as fast as the other side accepts them within the same tick, although it's not clear that it shouldn't either. If not, then probably all that would need to change would be to remove the "while" loop so that the tick event would be rescheduled, and the Fifo would be further emptied the next time around. Change-Id: I653379b43389d0539ecfadb3fc6c40e38a8864c2 Reviewed-on: https://gem5-review.googlesource.com/3642 Reviewed-by: Andreas Hansson <andreas.hansson@arm.com> Maintainer: Gabe Black <gabeblack@google.com> |
| /gem5/src/systemc/tests/ | ||
| H A D | verify.py | diff 13033:97942c2a58ad Sat Jul 28 04:13:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Make verify.py ignore an Info: message. This message is about how to disable a warning about sc_bit being deprecated. Change-Id: I1a0b12e2ca5b58328e37605ba3f7e3e1a384e351 Reviewed-on: https://gem5-review.googlesource.com/12064 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
Completed in 22 milliseconds