Opened 15 years ago
Closed 14 years ago
#211 closed defect (worksforme)
Time sometimes appears to stop on mips32
Reported by: | Jakub Jermář | Owned by: | |
---|---|---|---|
Priority: | critical | Milestone: | 0.4.3 |
Component: | helenos/kernel/mips32 | Version: | mainline |
Keywords: | Cc: | ||
Blocker for: | Depends on: | ||
See also: |
Description (last modified by )
Time sometimes appears to stop on mips32. This has several symptoms such as:
- in tetris, the blocks stop falling, even though one can move them sidewise
- cursor stops blinking
- it is not possible to switch to another vc when running
tester loop 1
After some time, the system wakes up and continues to operate normally, but the problem may return.
This can be observed with the testmips machine in GXemul (0.4.7.2).
Change History (4)
comment:1 by , 15 years ago
Description: | modified (diff) |
---|
comment:2 by , 14 years ago
comment:3 by , 14 years ago
An instrumented version of GXemul reveals that the last value written into the compare register was greater (by about 97000) than the current value of the count register, which is pretty normal. This disproves the theory that the overflow happens as a result of writing the compare register after the count register has already missed it.
comment:4 by , 14 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
There appears to be a problem in GXemul which is responsible for this behavior. Anders Gavare says:
that the code which asserted the interrupt pin did so when it had updated the count register to go past the compare register, but since there was another hack in cpu_mips_coproc.c which _also_ updated the count register, then the first mechanism sometimes failed.
As for the likely GXemul fix, Anders said:
the solution was to keep track of the number of updates done in cpu_mips_coproc.c (i.e. for each read of the count register), and do a "rollback" just before doing the count-goes-past-the-compare-register check.
I have tested the fixed version provided by Anders and the issue was no longer reproducible.
Closing this ticket as not a defect.
This is because for some reason the count register outgrows the compare register as evidenced by the following output GXenmul commands during the non-preemptive period:
and a while later, while the system was still not preemptive:
Since an interrupt is generated when the two registers match, there was no interrupt until count wrapped around 0xffffffff and reached compare from below.