Coherent on QEMU is now acceptably fast.

[cro...@gmail.com]

I just thought that I'd mention in case some folks had not tried to run Coherent under QEMU recently that it is now acceptably fast. The slowdowns associated with simulated noted a few years ago seems to have been addressed in recent versions; I just tried version 2.0.0 on Mac OS X. Further, it runs on 64-bit host systems (no more installing a 32-bit guest machine to install VirtualBox to run Coherent!) and probably on non-x86 machines as well; I'm hoping to run it on ARM but haven't tried yet; I suspect it will "just work." Have fun!

Side note...I was never heavily involved in the Coherent community, but I have a soft spot for it in my heart: it was basically my introduction to Unix back in the early 1990s when I was still in high school. I stole 20 megabytes of hard drive space from DOS on my 486, scraped up $100, bought and installed it so I could learn how to use Unix and program in C. I'm glad I did that. It only lasted a year or so before I wiped the entire machine and installed NetBSD, but it got me started. To those who built it who may eventually read this: thanks.

- Dan C.

[frasc]

On Saturday, June 28, 2014 6:24:34 PM UTC-7, cro...@gmail.com wrote:
> I just thought that I'd mention in case some folks had not tried to run Coherent under QEMU recently that it is now acceptably fast.

Thanks for your post Dan.

I came as well to (almost) the same conclusion as you, running qemu-system-i386 on Ubuntu 14.04.

The problem I'm having is that disk read sometimes returns corrupted data, and maybe writes too. So it's basically unusable.

Could you post the command line parameters you used as well as the configuration, like disk image format and size.

All in all that sounds like a great progress.

Thanks in advance

--Frederic

[the.bee...@gmail.com]

On Sunday, October 26, 2014 11:04:18 PM UTC+1, frasc wrote:
> The problem I'm having is that disk read sometimes returns corrupted data, and maybe writes too. So it's basically unusable.

That was my conclusion as well, most notably when using the C-compiler. QEMU 1.4 at least seems stable - but slow: it helps though if you use a raw image. I've not found a "hack" to make more recent versions somewhat usable. Woulbe be nice indeed.

Hans Bezemer

[cro...@gmail.com]

Sorry, I rarely read USENET these days, and only saw this follow-up just now. :-/

I'm afraid I haven't had much time to really exercise COHERENT under qemu, so I haven't noticed any reliability problems. I believe the commands I used to start at were those listed here:

http://thebeezspeaks.blogspot.com/2012/05/my-life-with-coherent-part-2.html

Good luck!

[andrzej Popielewicz]

W dniu 2014-06-29 o 03:24, cro...@gmail.com pisze:

> I just thought that I'd mention in case some folks had not tried to run Coherent under QEMU recently that it is now acceptably fast. The slowdowns associated with simulated noted a few years ago seems to have been addressed in recent versions; I just tried version 2.0.0 on Mac OS X. Further, it runs on 64-bit host systems (no more installing a 32-bit guest machine to install VirtualBox to run Coherent!) and probably on non-x86 machines as well; I'm hoping to run it on ARM but haven't tried yet; I suspect it will "just work." Have fun!
>
> Side note...I was never heavily involved in the Coherent community, but I have a soft spot for it in my heart: it was basically my introduction to Unix back in the early 1990s when I was still in high school. I stole 20 megabytes of hard drive space from DOS on my 486, scraped up $100, bought and installed it so I could learn how to use Unix and program in C. I'm glad I did that. It only lasted a year or so before I wiped the entire machine and installed NetBSD, but it got me started. To those who built it who may eventually read this: thanks.
>
> - Dan C.
>

I have just upgraded VirtualBox to 4.3.20 on XP running on Core2Duo
Optiplex 755. Coherent virtual machine
crashes with "critical error".

Andrzej

[Udo Munk]

On Tuesday, January 13, 2015 at 9:57:17 AM UTC+1, andrzej Popielewicz wrote:

> I have just upgraded VirtualBox to 4.3.20 on XP running on Core2Duo
> Optiplex 755. Coherent virtual machine
> crashes with "critical error".

Doesn't work anymore since 4.2.18 or so and crashes since then. I filed
a bug report at Oracle some month ago, but it was ignored. Probably it
needs to be resolved the other way arround, means to modify the 386
startup code in the kernel, so that it won't crash VM's.

[cro...@gmail.com]

That makes more sense. Perhaps the disk stability issues with qemu could be similarly resolved. Udo, do you have any ideas what's wrong with the current code (or, more importantly, how to fix it?).

- Dan C.

[va...@icpnet.pl]

I suspect the problem is with tboot ??

Andrzej

[andrzej Popielewicz]

W dniu 2015-01-20 o 21:41, va...@icpnet.pl pisze:

> I suspect the problem is with tboot ??
>
> Andrzej
>

Perhaps too early conclusion. Quick look in VirtualBox log shows no
conclusive(?) message at the point of crash. Just after "Please wait
..." message we see empty lines and the general error message. It is in
fact ,as Udo noticed, at the moment when kernel should be loaded.

Some error messages like

fatal error in recompiler cpu: Trying to execute code with memory type
addr_code=0000000100002020 addend=0000000011847000 at 000000010000213f.
(iHandlerMemType=0x38 iMMIOMemType=0x30)

appear much earlier in the log .

BUT i have checked also my another XP box, with older VirtualBox
4.1.12.x running on 32 bit P4 ThinkCentre . I was suprised , the
Coherent was very fast. Last time I have tested it was in 2012, and I do
not remember that is was so fast. The only hardware I have changed in
the meantime was graphic card, now it is Matrox G450 32 MB PCI.But I
doubt it could be a reason. I will have to check it in more detail.

Andrzej

[andrzej Popielewicz]

W dniu 2015-01-13 o 11:02, Udo Munk pisze:

Well, Coherent works in many emulators correctly , and natively on many
platforms ,even on Xeon 64 bit machines. This is why I do not think
startup code in Coherent is in some way buggy. I assume that they have
made some simplifying restrictive assumptions about startup code of
guest OS , fullfiled by Linux, Windows or MacX.
Or VirtualBox has bugs in the code not used by these OS's but used by
Coherent.

The source code of VirtualBox should be avaialable , one could check
what they have changed from 4.1.12 to 4.2.18 , it would be the quite
reasonable way to solve this problem although quite a hard job for us,
but probably piece of cake for maintainers.

Otherwise we have to guess what they have done and what we can do in
response in startup code of Coherent. Tedious work.

And no warranty of success for the next upgrade of VirtualBox.

Has anyone checked in 64 bit VMware ?

Andrzej

[Andrzej Popielewicz]

W dniu 2015-01-21 09:03, andrzej Popielewicz pisze:

> >
> BUT i have checked also my another XP box, with older VirtualBox
> 4.1.12.x running on 32 bit P4 ThinkCentre . I was suprised , the
> Coherent was very fast. Last time I have tested it was in 2012, and I do
> not remember that is was so fast. The only hardware I have changed in
> the meantime was graphic card, now it is Matrox G450 32 MB PCI.But I
> doubt it could be a reason. I will have to check it in more detail.
>
> Andrzej
>

OK, now I know why it is so fast, or much faster than expected.


I have used yesterday one of my newest kernels from 2012, with UDMA at
(for ATA devices)) driver. Standard generic kernel is as before slow.

Using kernel from 2014 (few minutes ago) makes things still faster.


So it helps to understand what is slow in this emulator, it is namely as
expected PIO mode .

Andrzej

[Udo Munk]

The kernel startup code is not buggy, it ran on every 386/486/Pentium1 board
available at the time when Coherent was under development.

There is some bug in Virtualbox, Oracle is not interested in locating it, so one would
have to build it from sources self, and add enough trace stuff to figure out what is
going wrong. Oracle then might accept a patch to fix the problem and if not, it
doesn't matter if one can fix it self in the virtual box sources.

This probably is not trivial to figure out, because Virtualbox in general runs
almost everything. But I think it would be worth the effort to try, because
it worked OK on older releases and it would provide a good platform to improve
the OS, if one wants to do so.

[andrzej Popielewicz]

W dniu 2015-01-13 o 11:02, Udo Munk pisze:

> Doesn't work anymore since 4.2.18 or so and crashes since then. I filed

I have tested all 4.2.x versions ,from 4.2.16 to 4.2.28 (this from
January 2015).
All work fine. Good news.

But it crashes beginning from 4.3.0 . It is new version with many
rewrites of code .
It seems it will be not so easy (?) .
Andrzej

[andrzej Popielewicz]

W dniu 2015-02-04 o 14:03, andrzej Popielewicz pisze:

> I have tested all 4.2.x versions ,from 4.2.16 to 4.2.28 (this from
> January 2015).
> All work fine. Good news.
>
> But it crashes beginning from 4.3.0 .

Let us be more precise.

Version 4.3.0 was released on 15.10.2013
Version 4.2.28 was released on 17.1.2015

It means both branches 4.3 and 4.2 are developed/maintained in parallel.
Which is quite typical for Oracle products. We can expect that branch
4.2 will be still maintained for a while.
Branch 4.2.x seems to be faster than branch 4.1.x
HTH
Andrzej

[Thorsten Glaser]

Udo Munk dixit:

>There is some bug in Virtualbox, Oracle is not interested in locating it, so one would

FWIW: VirtualBox is buggy to the amount that I had to add code
to the MirBSD installer refusing service if it detects it.

I did manage to get a Sun engineer working on VirtualBox at
some conference, and he told me that yes, the bugs are known,
and no, they couldn’t fix it (mostly money/political reasons),
so we can emulate MirBSD/i386 in all things (bochs, qemu, qemu
with kqemu, qemu with linux-kvm, Microsoft VirtualPC, VMware,
etc.) *except* VirtualBox now. I expect this to prevent lots
of other “alternative” OSes from working in it, too.

bye,
//mirabilos
--
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh

[Udo Munk]

Booting now is very fast, the harddisk emulation is working OK now, but the CPU's are not:

https://youtu.be/UKLVO5N31HI

[Udo Munk]

QEMU 2.12.0 is released, installed it on OSX and did a few tests. COHERENT 4.2 boots very fast,
but still the odd errors with the MWC compiler. The vgalib graphics programs run very fast,
seems that the VGA hardware was improved some.

This release also boots COHERENT 4.0.1 and 4.0.1r68 (DDK version), but not the later
r74 upgrade, HD controller not working.

NEW: The COHERENT 3.2 image boots in one second, now that is fast. For 3.2 I'm using:

-----
#!/bin/sh

exec qemu-system-i386 -cpu 486 -M isapc -vga std -drive format=raw,file=$HOME/coherent/qemu-coherent-3.2.img -m 2 &
-----

I've not tried to access floppy disk drives etc. more testing is needed sometime...

[Udo Munk]

QEMU 3.1.0 still has a buggy CPU. Is not related to the 4.x monolithic compiler, the
traditional 16bit compiler running the passes connected via pipes shows the same problem.

[Udo Munk]

In QEMU 5.1 the buggy CPU was fixed, this version now runs 3.2 and 4.2 OK without
compilers/interpreters aborting with errors.

[Nils M Holm]

Udo Munk <udo....@freenet.de> wrote:
> In QEMU 5.1 the buggy CPU was fixed, this version now runs 3.2 and 4.2 OK
> without compilers/interpreters aborting with errors.

Must be a recent bug! I am running QEMU 0.11.1 and never had any trouble
with any of your images or various compilers and interpreters.

--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org

[Udo Munk]

The problem was with releases 2.x - 5.0, I made a video showing the problem:
https://youtu.be/UKLVO5N31HI
C compilers aborted, Basic interpreter aborted ...