Many web sites nowadays claim that 4.2.10 was the last COHERENT version.
This is wrong, there was 4.2.12 and 4.2.14. I do not have 4.2.12 disks,
because back then I had all sources needed to build a 4.2.12 system from
a 4.2.10 distribution. Nowadays you can do that too with everything open sourced.

In 4.2.14 there were so many changes that one really needs a complete distribution. I found time to fiddle (don't ask) with 25 year old floppy disks and got
them imaged. The 4.2.14 distributions disks are available at:

https://www.autometer.de/unix4fun/coherent/ftp/distrib/Coherent-4.2.14/

I have installed the base system on Virtualbox and it's working stable and solid.
When I have spare time I'll also install the DDK and the 4.2.14 kernel sources on the box, to see how and if the stuff works.

Anyway, you can install and examine the distribution your self :-)

Have fun,
Udo

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

Installed the 4.2.14 DDK, the kernel build with the DDK has same size as the kernel included on the installation disks and also works OK. Good, so at
least working driver sources for this release.

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

Put kernel 4.2.14 source from Steve's archive on 4.2.14 box, build kernel from source.

Works :)

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

Screenshot is here: https://www.autometer.de/unix4fun/coherent/news.html

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

Udo Munk <udo.munk@freenet.de> wrote:

Many web sites nowadays claim that 4.2.10 was the last
COHERENT version. This is wrong, there was 4.2.12 and
4.2.14. I do not have 4.2.12 disks, because back then I had
all sources needed to build a 4.2.12 system from a 4.2.10
distribution. Nowadays you can do that too with everything
open sourced.

In 4.2.14 there were so many changes that one really needs a
complete distribution. I found time to fiddle (don't ask)
with 25 year old floppy disks and got > them imaged. The
4.2.14 distributions disks are available at: https://www.autometer.de/unix4fun/coherent/ftp/distrib/Coherent-4.2.14/

I have installed the base system on Virtualbox and it's
working stable and solid. When I have spare time I'll also
install the DDK and the 4.2.14 kernel sources on the box, to
see how and if the stuff works.

Anyway, you can install and examine the distribution your self :-)

Thanks, just dounloaded and will give it a try

Have fun,
Udo

John

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

Couldn't remember anymore if MWC/RTR X11 works with 4.2.14. So installed the PS/2
mouse driver in DDK and kernel source kit, build kernels with the driver included.

Then I installed X11 from the distribution disks, the post installation needs a simple
hack to avoid a problem with finding a mouse. But after installation the X server
works OK on 4.2.14.

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

Thanks Udo! You rock :-)

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

The device driver for IDE hard disks has bugs in 4.2.14. The source for the AT driver
that corrects one of the bugs is available here:

https://www.autometer.de/unix4fun/coherent/ftp/distrib/Coherent-4.2.14/patches/

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

Udo Munk <udo.munk@freenet.de> wrote:

The device driver for IDE hard disks has bugs in 4.2.14. The source
for the AT driver that corrects one of the bugs is available here:

https://www.autometer.de/unix4fun/coherent/ftp/distrib/Coherent-4.2.14/patches/

I have not noticed any issues with 4.2.14.
But how would I apply the patch ?

Thanks
John

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

On Sunday, October 11, 2020 at 6:11:27 PM UTC+2, John McCue wrote:

I have not noticed any issues with 4.2.14.
But how would I apply the patch ?

Thanks
John

Connect a second IDE harddisk to the system and try to boot that.

Install the DDK. Now you have driver sources in /etc/conf, the at.c source is /etc/conf/at/src/at.c. Rename the file to at.c.4214, then copy the corrected version to there. Execute:

make clean
make
/etc/conf/bin/idmkcoh -o /coh.test

Reboot system and boot the coh.test kernel, problem gone.

If you use the full kernel source kit you need to repair it there too.

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

Udo Munk <udo.munk@freenet.de> wrote:

On Sunday, October 11, 2020 at 6:11:27 PM UTC+2, John McCue wrote:

[snip]

If you use the full kernel source kit you need to repair it there too.

Thanks for your help,
John

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

There is another problem somewhere, if you try to fsck the second hd the kernel will panic.
I suspected the IDE disk driver, but even on close inspection the fixed version looks good to me.

Then I tried the same with the IDE driver from r12, no problem. Do not do this if
you are not a kernel developer! I use cloned VM's for such things, just to have a look and
get an idea and then throw away such clones.

Then I copied the fsck sources from the 4.2.10 box to the 4.2.14 one, build fsck
from source and tried that, also no problem anymore. You can use this as a workaround
in case you need to repair filesystem on the second HD.

The 4.2.14 fsck binary is larger that the one build from the sources, the latest sources
I found are from 1993, I'm sure there were changes after this.

I have tortured both HD's with iozone, copied huge directories forth and back, ran large
build stuff, all rock solid. This problem will not be easy to locate and only can be reproduced
with the fsck binary from r14 so far.

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

I have narrowed this down some further:

With QEMU 5.1 you can fsck.r14 /dev/at1a as well as /dev/rat1a as much as you want, solid.
With Virtualbox 6.0.20 you can fsck.r14 /dev/at1a as much as you want, but not /dev/rat1a.
PCem v16 same.

These are IDE controllers and drives from different vendors, same as we had with real
hardware way back then. To me it looks like that some of the hardware provided to
the guest machines does some things in a way unexpected and unnoticed by the AT driver,
which results in a kernel page fault.

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

With the above dd one also kills the system running on QEMU.
The at driver is OK, this is a bug somewhere in the filesystem dealing
with raw disk devices.

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

Problem always happens if reading lots of data from a raw disk device and update
wants to sync the disks. So I tried:

dd if=/dev/rat1a of=/tmp/dump bs=512 count=80000

Sure thing, in the moment update tries to sync this also results in a kernel page fault.

Avoid using a raw disk device if you don't have to.

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

Udo Munk <udo.munk@freenet.de> wrote:

There is another problem somewhere, if you try to fsck the second hd
the kernel will panic. I suspected the IDE disk driver, but even on
close inspection the fixed version looks good to me.

Then I tried the same with the IDE driver from r12, no problem. Do not
do this if you are not a kernel developer! I use cloned VM's for such
things, just to have a look and get an idea and then throw away such
clones.

I am not a kernel developer, but if I think I need
to apply the patch I will use a clone. So far I
have not noticed anything in Virtual Box.

[snip]

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

On Tuesday, October 13, 2020 at 8:26:01 PM UTC+2, John McCue wrote:

I am not a kernel developer, but if I think I need
to apply the patch I will use a clone. So far I
have not noticed anything in Virtual Box.

Using the patch is not a problem, I meant using a 4.2.12 device driver with the 4.2.14
kernel. This likely will cause problems and things like this should be done with a test
system only.

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

Glad to hear that John, enjoy the system.

Udo

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

Udo Munk <udo.munk@freenet.de> wrote:

Problem always happens if reading lots of data from a raw
disk device and update wants to sync the disks. So I tried:

dd if=/dev/rat1a of=/tmp/dump bs=512 count=80000

Sure thing, in the moment update tries to sync this also results in a
kernel page fault.

Avoid using a raw disk device if you don't have to.

Hi Udo

Thanks for the info, on the VM I really have no need to use
the raw disk device, but will try and avoid that should a
case comes up were I need to.

But so faar so good with 4.2.14

John

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