Hi,

I tried the ova file for Coherent 4.2.10 from http://www.autometer.de/unix4fun/coherent/ and then tried installing from scratch. Both systems take a very long time to check filesystems /dev/rhome and /dev/ru1 - more than 30 minutes in total. Is this
normal or is it something I can fix?

I'm running VirtualBox 5.2.0 on MacOS Sierra 10.12.6. My drive is as specified in the install instructions 500MB Fixed size. The VM is configured exactly as the instructions.


Thanks,
Will

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

There is an issue with OS X, which I have not seen running the VM under Windows and Linux.
It can be worked around by converting the disk as follows, after importing the appliance.

Go into the directory with the VM's, by default it is in $HOME/VirtualBox\ VMs. Convert the disk drive to a fixed one:

VBoxManage clonehd COHERENT\ 4.2.10-disk1.vmdk disk1.vmdk --variant Fixed

Go into the settings for the VM under Storage and remove the disk image from the
IDE controller and add a new existing disk, disk1.vmdk.

I just tried this again, I'm using OS X 10.9.5 and VirtualBox 5.1.30, the system boots
in a few seconds. Without cloning the disk image to a fixed one the fsck needs ages.

If nothing helps you could comment out the fsck's in /etc/checklist for /dev/rhome
and /dev/ru1, but leave it active for /dev/root. If you do this make sure to shutdown
the OS properly, don't just switch the VM off.

PS: one probably should open a ticket at Oracle for the issue, something seems to be
wrong with the IDE controller under OS X, if the disk images are not fixed size.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I had some time to examine this problem more detailed. The Vbox log is full with AT reset commands,
seems the controller hangs very often and doesn't answer anymore, so the driver sends a reset after
a while. You also see that at the slow blink frequency of the disk access icon, while top shows 100%
usage of one CPU.

Using a fixed size disk and activating the buffer cache for the IDE controller seems to help a bit, but
not reliable. I destroyed and re-imported the VM dozens times and often it would just be slow.

This looks like a timing problem, so I got the idea to force the VM a bit more to the ancient hardware we
were using way back then. After importing the VM do this:

VBoxManage modifyvm "COHERENT 4.2.10" --cpu-profile "Intel 80386"

Now fsck runs more steady all the time and the AT reset happens much less often after every
import I tried.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

For investigating further what is happening I enabled some more verbose debug output in the at driver and build a new kernel with it.

What happens are atwatch TIMEOUT's, after a read request the driver doesn't receive
an IRQ and times out after 6 seconds, and then resets the AT controller, which one
sees in the Vbox logs. That is why fsck runs so slow and needs ages.

Setting the CPU to i386 as described above significantly reduces the events, so I
also enabled the I/O APIC for the VM, just to see what would happen. COHERENT doesn't know about such a thing and won't use it, but interestingly this reduces
the missing IRQ's further, so less timeouts and less waiting.

The 4.2.10 at.c driver still is pretty shitty, I added a busyWait for reading csr,
but it doesn't help. Still not certain if the driver confuses the emulated chipset,
or if the VM stuff just is buggy.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Tested the new kernel also with qemu on OS X, to see what the at driver does there.

To install qemu on OS X install Homebrew if you haven't already from:

https://brew.sh

Then do:

brew install qemu

Go have a beer or two.

Convert Vbox image to raw disk format:

qemu-img convert -f vmdk -O raw ~/VirtualBox\ VMs/COHERENT\ 4.2.10/disk1.vmdk ~/coherent/coh.img

Then run it with qemu:

qemu-system-i386 -hda ~/coherent/coh.img -m 16

System boots in seconds, no issues with the at driver, so probably the PIIX3 emulation in Virtualbox is buggy. Updated to Virtualbox 5.2.0, still buggy.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Tried it with the current bochs version on OS X:

[HD ] write cmd 0x31 (WRITE SECTORS NO RETRY) not supported

and plenty of atwatch timeouts, not working at all.

I don't know what is so difficult to emulate a primitive IDE controller,
a Cromemco FDC16 is more complicated than that and I got it working
perfectly running Cromix ;-P

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

There is another thing you can do to improve things a bit. The default wait timeout
in the at driver watchdog is 6 seconds. One can modify the timeout to 1 second, less
waiting when the drive hangs and emulated drives should respond immediately.

You do this by adding the configuration parameter to /etc/conf/stune, add this line:

ATSECS_SPEC 1

Then rebuild kernel.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, November 8, 2017 at 11:07:28 PM UTC-6, Udo Munk wrote:

Tested the new kernel also with qemu on OS X, to see what the at driver does there.

To install qemu on OS X install Homebrew if you haven't already from:

https://brew.sh

Then do:

brew install qemu

Go have a beer or two.

Convert Vbox image to raw disk format:

qemu-img convert -f vmdk -O raw ~/VirtualBox\ VMs/COHERENT\ 4.2.10/disk1.vmdk ~/coherent/coh.img

Then run it with qemu:

qemu-system-i386 -hda ~/coherent/coh.img -m 16

System boots in seconds, no issues with the at driver, so probably the PIIX3 emulation in Virtualbox is buggy. Updated to Virtualbox 5.2.0, still buggy.

Works fine!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I tried to file a bug report for quemu not running the MWC i386 compiler correct,
but one has to register for Ubuntu Linux for that. No thanks, I'm not interested,
if anyone is going to do this feel free to pass my email address, I might be able
to help with the issue from the MWC side of things.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)