COHERENT 4.2.14 distribution disks available

54 views
Skip to first unread message

Udo Munk

unread,
Oct 5, 2020, 10:40:48 AM10/5/20
to
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

Udo Munk

unread,
Oct 5, 2020, 12:37:06 PM10/5/20
to
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.

Udo Munk

unread,
Oct 5, 2020, 1:17:39 PM10/5/20
to
Put kernel 4.2.14 source from Steve's archive on 4.2.14 box, build kernel from source.

Works :)

Udo Munk

unread,
Oct 5, 2020, 2:31:04 PM10/5/20
to

John McCue

unread,
Oct 5, 2020, 3:47:48 PM10/5/20
to
Thanks, just dounloaded and will give it a try

> Have fun,
> Udo

John

Udo Munk

unread,
Oct 6, 2020, 6:02:51 AM10/6/20
to
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.

frasc

unread,
Oct 6, 2020, 11:24:39 AM10/6/20
to
Thanks Udo! You rock :-)

Udo Munk

unread,
Oct 11, 2020, 11:09:53 AM10/11/20
to
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/

John McCue

unread,
Oct 11, 2020, 12:11:27 PM10/11/20
to
I have not noticed any issues with 4.2.14.
But how would I apply the patch ?

Thanks
John

Udo Munk

unread,
Oct 11, 2020, 12:33:29 PM10/11/20
to
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.

John McCue

unread,
Oct 11, 2020, 5:10:40 PM10/11/20
to
Udo Munk <udo....@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

Udo Munk

unread,
Oct 12, 2020, 7:29:13 AM10/12/20
to
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.

Udo Munk

unread,
Oct 12, 2020, 10:57:52 AM10/12/20
to
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.

Udo Munk

unread,
Oct 12, 2020, 2:43:07 PM10/12/20
to
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.

Udo Munk

unread,
Oct 12, 2020, 2:50:00 PM10/12/20
to
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.

John McCue

unread,
Oct 13, 2020, 2:26:01 PM10/13/20
to
Udo Munk <udo....@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]

Udo Munk

unread,
Oct 13, 2020, 3:07:28 PM10/13/20
to
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.

John McCue

unread,
Oct 20, 2020, 9:55:57 AM10/20/20
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

Udo Munk

unread,
Oct 20, 2020, 10:05:36 AM10/20/20
to
Glad to hear that John, enjoy the system.

Udo
Reply all
Reply to author
Forward
0 new messages