Thanks for informing me, Giacomo. This is likely due to the fact that the places that call setWhenReady ignore the previous whenReady cycle and overwrite it. I'll do a quick patchset to revert the first assert and workaround this problem. I imagine the tickInserted assertion was ok, because the block is always first inserted, then whenReady is set (I am trying to run the tests, but fs takes forever on my machine). Please let me know if it is still broken with the tickInserted assert, because then that means something is really bad (I'll check here too).
Nikos/Jason, this is likely due to an incomplete definition of whenReady. If we need to care about previous whenReady when overwriting a valid block, then we must add it to the calculations (i.e., a write must wait for previous writes to end). However (and I think this is a better approach), if whenReady is the tick at which the write contents (payload) is available to be accessed, then the first assertion does not make sense, whenReady should be left as is (i.e., including the fillLatency), but on the part that uses whenReady, if the access must be delayed due to the block not being present, the fillLatency should be deducted, and the forwardLatency included (i.e., the non-write access is being serviced by the write packet). Speaking of FS, to whoever runs x86 fs simulations (Gabe, possibly?), here at the office we always have to apply 2 local patches to be able to run with our own image and kernel: https://gem5-review.googlesource.com/c/public/gem5/+/11850 and another one that I haven't submitted because I don't know if it's safe for every approach, but that removes the variable disk2 from makeX86System, which forces a swap that is not present on my image (linux-bigswap2.img). Then I run (build/X86/gem5.opt configs/example/fs.py --disk-image=img_path --kernel=kernel_path). Could you take a look at it and see if I am doing something wrong, or it makes sense? Regards,Daniel Em quinta-feira, 6 de dezembro de 2018 18:00:11 GMT+1, Giacomo Travaglini <[email protected]> escreveu: <!--#yiv1942089052 P {margin-top:0;margin-bottom:0;}--> Hi Daniel, A group of quick regressions are broken after the following patch (that has been recently merged)(They fail the assertion that has been introduced by the patch) https://gem5-review.googlesource.com/c/public/gem5/+/14715 quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic: FAILEDquick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual: FAILEDquick/fs/10.linux-boot/arm/linux/realview-switcheroo-atomic: FAILEDquick/fs/10.linux-boot/arm/linux/realview-simple-atomic: FAILEDquick/fs/10.linux-boot/arm/linux/realview-simple-atomic-checkpoint: FAILEDquick/fs/10.linux-boot/arm/linux/realview-simple-atomic-dual: FAILED Could you please have a look at it? Thanks Giacomo IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
