-
-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Running under cygwin #103
Comments
This code was treating the `d_reclen` incorrectly from some of the original old porting work. It is not the same as `d_namlen` and `d_namlen` is not widely supported or standard. It should be using `strlen(d_name)`. This addresses an issue mentioned in Interlisp/medley#103.
Submitted PR Interlisp/maiko#128 to address the |
This code was treating the `d_reclen` incorrectly from some of the original old porting work. It is not the same as `d_namlen` and `d_namlen` is not widely supported or standard. It should be using `strlen(d_name)`. This addresses an issue mentioned in Interlisp/medley#103.
i spent some time with gdb documentation and stepping through main in gdb but couldn't get by the execvp |
You appear to have merged your cygwin3 branch into master without telling anyone? |
See https://jeffkreeftmeijer.com/git-rebase/ for an explanation of what you probably wanted to do (git rebase, to re-apply your local branch changes over a copy of the updated master branch, without merging your experiment back into master) |
time for me to go back through the git tutorials |
The current state of this is that it crashes on Do you have a stack trace? |
So, that's stack corruption it seems ... Looking at the code, we see something that seems dangerous:
That's quite a decently sized stack allocation there for You could try telling Cygwin to give it a bigger stack size via adding this to the gcc command line:
Alternatively, you could |
Now it compiles ok and doesn't crash and runs the opcode tests in test.vm, but doesn't recognize keypress or mouse clicks (same problem as with running under WSL1) |
Which fix did you apply to prevent the crash? |
I take back what I said:
I also added |
yes, fixes segv on startup. Now it's just hanging because it doesn't get mouse clicks or keystrokes |
Good news. Presumably that's after recompiling without the 32MB stack option. |
Steve reported having problems with running on WSL2 in his configuration -- screen comes up but no characters recognized. Is it possible to fork a little process to act as a keystroke forwarder that waits for the keyboard and sends events whenever it gets a keystroke or mouse move? |
We could use some documentation on what WSL2 (or cygwin) supports for polled or interrupt driven I/O, and then we can try to fix it. I don't have access to a WSL2 system (or one with cygwin), so there's not much I can do, or suggestions I can make to those who do, without some input... |
Hello, cygwin apparently does not support asynchronous i/o or a virtual timer, as the callback routines As work-around in my dodo-nethub-support branch of Maiko, i added simple count-down mechanism to the instruction dispatcher ( This variable is set in So i have now a working version of Maiko running natively on Windows10 as Cygwin executable which can do networking with Dodo XNS services and uses a local X11 server (VcXsrv 1.20.14.0). The Maiko process behaves normally in my understanding, the overall CPU load of the system is around 1-3% when the Medley environment is idle and goes up to ~15% (100% on about 1 out of 8 logical CPUs) when the right mouse button is pressed in Medley. So even if i/o is checked all 20.000 instructions, only minimal CPU resources are consumed when the Medley system is idle and only one CPU goes to 100% while a context menu is shown. However networking is a bit "lethargic" compared to async i/o on Linux, but it is usable. Maybe using a lower value for Greetings, Hans |
The configuration information that is specific to all instances of an OS like cygwin should be incorporated in the inc/maiko/platform.h -- we have carefully removed most of the system specific defines from the makefile fragments and I'd rather not move backwards there, if you don't mind. Since there are likely to be other systems where simulating the async timer would be useful, I would suggest that the #define not be CYGWIN_... but rather MAIKO_EMULATE_TIMER_INTERRUPTS (or similar) and look at how to integrate it should other systems need it. Oddly, cygwin defines FASYNC rather than O_ASYNC -- not sure what's going on there. |
Can you check if current cygwin supports ITIMER_REAL rather than ITIMER_VIRTUAL — I don’t have any Windows boxes to check this on, but chatter from about 17 years ago suggests that starting with cygwin version 1.5.16 it supported the realtime timer.
… On Oct 1, 2022, at 2:13 PM, devhawala ***@***.***> wrote:
Hello,
cygwin apparently does not support asynchronous i/o or a virtual timer, as the callback routines int_io_service resp. int_timer_service in timer.c are never called, so for example when pressing the right mouse button, the menu appears but then the system is stuck. (networking does not work either, as incoming packets are not noticed)
As work-around in my dodo-nethub-support <https://github.com/devhawala/maiko/tree/dodo-nethub-support> branch of Maiko, i added simple count-down mechanism to the instruction dispatcher (dispatch in xc.c): the compile variable CYGWIN_TIMER_ASYNC_EMULATION_INSNS_COUNTDOWN defines the interval as number of instructions for simulating an external i/o interrupt, so the interrupt checking machinery is fired in more or less regular intervals.
This variable is set in makefile-cygwin.x86_64-x (and only there) to 20000. To prevent compile errors, enabling async i/o in ether.c for the Nethub socket is made dependent of the presence of O_ASYNC (which is missing in Cygwin)
So i have now a working version of Maiko running natively on Windows10 as Cygwin executable which can do networking with Dodo XNS services and uses a local X11 server (VcXsrv 1.20.14.0). The Maiko process behaves normally in my understanding, the overall CPU load of the system is around 1-3% when the Medley environment is idle and goes up to ~15% (100% on about 1 out of 8 logical CPUs) when the right mouse button is pressed in Medley. So even if i/o is checked all 20.000 instructions, only minimal CPU resources are consumed when the Medley system is idle and only one CPU goes to 100% while a context menu is shown.
However networking is a bit "lethargic" compared to async i/o on Linux, but it is usable. Maybe using a lower value for CYGWIN_TIMER_ASYNC_EMULATION_INSNS_COUNTDOWN could make it more snappy, but this value must be adjusted to the local hardware anyway...
Greetings, Hans
—
Reply to this email directly, view it on GitHub <#103 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6DAWMY5GHPKW3ARV4FFZLWBCSPDANCNFSM4VF54H7A>.
You are receiving this because you commented.
|
Here some intermediate results:
Meaning the work-around simulating timer and i/o interrupts will be needed for the cygwin version. So next things will be incorporating the Addr68k/NativeAlignment{24} changes and moving cygwin-specific dependencies to |
I suspect that running with ITIMER_REAL may be causing an interrupt before the rest of the system is ready for it. I'll check out the situation with ITIMER_REAL on other systems and see if it's debuggable there. I also notice that looks as though you're making the ether fd async before the async signal handling is set up -- it can't be made to generate interrupts before int_io_init() is called -- which in the USE_DLPI case of raw ethernet is where the I_SETSIG is applied to the ether fd. |
OK -- the issue is probably that if you change to ITIMER_REAL you have to have a signal handler for SIGALRM instead of a handler for SIGVTALRM... did you change that too? |
Yes... with ITIMER_REAL and SIGALRM it works the same on macOS as it does with ITIMER_VIRTUAL/SIGVTALRM. |
well ... not on cygwin: the active section of
|
for "making the ether fd async": i removed that from |
You changed all the instances?
|
Inspecting the code, I believe the timer emulation code is going to fail if you compile with OPDISP. |
no, not all instances, but i think there was no need for:
These were the only instances of the string "ALRM" that i found (except for comments or strings) in those files. for the OPDISP: is this still used? |
OPDISP with the threaded dispatch is new. It improves the performance. |
OPDISP is not turned on by default yet, when we do turn it on, that could be done for systems other than Cygwin. BTW -- where do you want bug reports for Dodo services submitted? The ECHO XIP packets that are returned by, for example, the file server implementation, don't match the echo packets it receives (missing the data, 2 bytes shorter than the one original sent) |
See the commit log for
We replaced the assembler fast dispatch with gcc's (and clang's) computed goto extension. |
bug reports please directly to issues in the Dodo project. for OPDISP dispatch: if there is no common code segment where all instructions come through (i get lost each time i try to follow the |
Missing include for
|
added the include and just created the merge request Dodo Nethub support #445 |
Running with cygwin works fine now. I am closing this issue -- is it worth a mention in documentation or a special build ? |
Currently in maiko/cygwin2 branch:
*-*-cygwin*) echo cygwin ;;
len== strlen(dp->d_name)
would have been better (in dsk.c )now it compiles, but dies when run:
The text was updated successfully, but these errors were encountered: