info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
COHERENT 4.2.14 distribution disks available
72 views
Skip to first unread message
Udo Munk
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
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
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.
kernel included on the installation disks and also works OK. Good, so at
least working driver sources for this release.
Udo Munk
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 :)
Works :)
Udo Munk
Oct 5, 2020, 2:31:04 PM10/5/20
to
Screenshot is here: https://www.autometer.de/unix4fun/coherent/news.html
John McCue
Oct 5, 2020, 3:47:48 PM10/5/20
to
> Have fun,
> Udo
John
Udo Munk
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.
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
Oct 6, 2020, 11:24:39 AM10/6/20
to
Thanks Udo! You rock :-)
Udo Munk
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/
that corrects one of the bugs is available here:
https://www.autometer.de/unix4fun/coherent/ftp/distrib/Coherent-4.2.14/patches/
John McCue
Oct 11, 2020, 12:11:27 PM10/11/20
to
But how would I apply the patch ?
Thanks
John
Udo Munk
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.
> I have not noticed any issues with 4.2.14.
> But how would I apply the patch ?
>
> Thanks
> John
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
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]
> On Sunday, October 11, 2020 at 6:11:27 PM UTC+2, John McCue wrote:
>
>
> If you use the full kernel source kit you need to repair it there too.
Thanks for your help,
> If you use the full kernel source kit you need to repair it there too.
John
Udo Munk
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.
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
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.
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
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.
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
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.
The at driver is OK, this is a bug somewhere in the filesystem dealing
with raw disk devices.
John McCue
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
> 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.
to apply the patch I will use a clone. So far I
have not noticed anything in Virtual Box.
[snip]
Udo Munk
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
> 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.
kernel. This likely will cause problems and things like this should be done with a test
system only.
John McCue
Oct 20, 2020, 9:55:57 AM10/20/20
to
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
Oct 20, 2020, 10:05:36 AM10/20/20
to
Glad to hear that John, enjoy the system.
Udo
Udo
0 new messages