> 2023年2月27日 09:31，Thomas Bogendoerfer <tsbogend@xxxxxxxxxxxxxxxx> 写道： > > On Mon, Feb 27, 2023 at 01:22:47AM +0000, Jiaxun Yang wrote: >> >> >> [...] >> Clearing interrupt happens in write_c0_compare but the problem is the interrupt >> does really get cleared because it triggered again straight away. > > the function you are patching is a test function whether counter/compare > is usable, so it's not in the normal timer handling. See a problem there > would more to broken hardware than to a bug in that function. The problem is sometimes on a multi-core system this function managed to run on one of the core but then fail on another. In our real use of compare interrupt, we are clearing interrupt by writing back old value of compare, which is guarenteed to be smaller then current count because there are so many instructions being executed from exception vector to here. Also as we have no way to disable compare interrupt, if this function determined compare to be broken then it won’t register event_handler function, which will cause panic for null pointer when unexpected-ish interrupt comes. > >> Had confirmed issue on MIPS I6500 uarch simulation trace. > > so not seen on real hardware ? It was discovered on FPGA and then I tried to debug with simulation to reveal what’s going on hardware side. Thanks - Jiaxun > > Thomas. > > -- > Crap can work. Given enough thrust pigs will fly, but it's not necessarily a > good idea. [ RFC1925, 2.3 ]
