ghaerr
commented
3 weeks ago I'll take a look and try to analyze the problem. But first - are you running this code in the function start_kernel? The function has the following comment at the top of it:
/* this procedure called using temp stack then switched, no temp vars allowed */
void start_kernel(void)
{
...
setsp(&task->t_regs.ax); /* change to idle task stack */
...
// are your variables being declared here? If so, that's disallowed as the stack has been switched within this function.
}It seems from your description that local variables are being declared within a block, which the compiler will then expect them in certain registers or stack locations. The setsp call above switches stacks midway through the function, which is required long story short for the way the dynamically allocated task array works. Thus, if any local variables are declared within kernel_start, the variables may or may not be accessible and/or overwritten, depending on system activity. This is all part of the trickiness of running code within kernel init (the complex startup sequences having been previously described).
If the locals are declared within start_kernel, then this is likely the issue. The entire set of testing needs to be performed in a separate function, much like was done with testloop, etc. If this is not the issue, let me know and I'll investigate further.
[EDIT: I probably need to change "no temp variables allowed" to "no local variables allowed" to be more clear.]
Mellvik
A rather interesting issue related to the discussion in #71, the implementation of a precision timer and a fix for divide-by-zero.
The problem occurs only in QEMU, which means that QEMU itself may be the culprit. That said, it takes either a very fast or very recent version (maybe both) of QEMU for the problem to occur. Which makes the analysis even harder. The symptoms simply don't make sense. A classic start of a real rabbit chase.
The problem: A special sequence of actions cause
printkto either cause the current function to exit or the system to hang, a classic stack pollution case.The situation leading to the problem:
get_ptimeprintkusing the result of that division@ghaerr, it would be interesting if you run this code snippet on ELKS on your QEMU which is likely quite a bit faster than my Mac Mini, which does not show the problem.
Anyway, this code snippet (not doing anything other than demonstrating the problem) demonstrates the problem: Either the statements from the second
printkto the end of the function are skipped (like an immediate return) - or we have a hang (the experimental code resides ininit/main.c):Some observations from a seemingly infinite number of testvariants:
Activating the
//temp = 3UL;line eliminates the problem - which is very interesting because it means that...... is not the same as
... even if that number is exactly what was returned from
get_ptime();. So it's not the number returned but the call toget_ptime()that seems to be important. That said,... doesn't cut it either. The error cannot be provoked unless the actual return value from
get_ptime()is used. Very strange indeed.Still, the variable itself is unimportant - as is its size. Setting
d6 = temp;whered6is anunsigned intand subsequently used6instead oftempin the division still triggers the problem.Adding delays between the two
get_ptime()calls to increase the # of pticks to > 64k makes no difference, IOW whether get_ptime returns a long or a short doesn't make any difference.This observation is supported by changing
temptounsigned intand casting the 2nd call toget_ptime(), still no difference.Changing the
dd(int) in the first divide statement tod6(unsigned) changes behaviour slightly, from 'exit function and continue' to 'hang right there' - which means nothing other than that a 'stray' return happens to 'land' on a slightly different address.The only way to make the routine 'work' with the return value from
get_ptime()is to AVOID long divide.... which obviously is no good if
d6 > 78- but we're closer to a conclusion: Somehow the interaction betweenget_ptime()and long div (signed and unsigned) cause a stack pollution which in turn causeprintkto malfunction on very fast machines - or there is a bug in QEMU 7.2.0.And the hunt continues.