Re: [MiNT] FreeMiNT 1.18 release coming up.

["Helmut Karlowski" <helmut.karlowski@ish.de>]

Alan Hourihane, 04.03.2013 10:20:08:

> On 03/04/13 08:39, Helmut Karlowski wrote:
> > Alan Hourihane, 04.03.2013 09:09:35:
> >
> > > > Nonsense! It only fails with EmuTOS, but you may go ahead!
> > > It would be nicer if you started offering up some solutions Helmut.
> >
> > Do you read my posts at all?
>
> I do all of them, and they don't provide a valid fix that avoids  
> violating supervisor mode.

1. Who says it's a violation at all? Compendium? come on ... POSIX?

> > I've made already several suggestions with 0 feedback.
>
> If there were posts with 0 feedback, it's probably because they're  
> invalid. But please point out posts where you have made a valid patch  
> that avoids violating supervisor mode.

Sorry that's all I can (and will) do. You may do what you want though.

I quote the message again for you here and won't contribute to this topic  
any more:

Vincent Rivière, 27.02.2013 14:16:32:

Did you try my suggestion to leave out appl_init in XaAES?

I didn't try, but that's a good solution, since the whole point is to not  
call the AES from supervisor mode.

XaAES runs from EmuTOS but then EmuTOS crashes when XaaES exits. It's
not the appl_exit later I think.

EmuTOS may have additional bugs when closing the VDI workstation, etc.  
Anyway, calling appl_exit() from supervisor mode is forbidden, too.

That's why I asked you to run this XaAES - maybe there's a bug in EmuTOS  
that can easily be fixed. It says:

pid  12 (GEM): BUS ERROR: User PC=E03362, Address: F1C00008  
(basepage=254000, text=E03488, data=0, bss=0)
pid   1 (GEM): BUS ERROR: User PC=E030B6, Address: F1C00008  
(basepage=1076000, text=E02F10, data=0, bss=0)

Maybe it helps. If you can't compile yourself I can upload an xaaes040.km.

Your patch was actually detecting the presence of FreeMiNT, then

No. It avoided to set the clipboard to u:/clipbrd which is nonsense anyway.

I fixed the u:/clipbrd nonsense by fixing FreeMiNT to run GEM= using the  
boot drive as default drive. It prevented the AES to find the accessories,  
anyway (both TOS and EmuTOS).

In EmuTOS, it crashes when calling scrp_write() from appl_init() in  
supervisor mode, whatever the path exists or not. It is not supposed to

Ok, then that's what my patch actually did. I remember it did not work  
anymore with the current trunk-kernel.

I'm in the mood of adding an explicit panic message in EmuTOS if someone  
tries to call the AES from supervisor mode (after the 0.9.0 release).

You could test for super and if so not call scrp_write. But again just a  
hack.

BTW: The whole point is to determine if the VDI physical workstation must  
be opened or not at XaAES startup, we should focus on that.

It could check if it's run from a process (i.e.ppid) called GEM but if it  
works at all it will again have to be tested on all relevant platforms.

--
Helmut Karlowski