On Aug 28, 11:04pm, Mark Brinicombe wrote:
> Subject: Re: v1.2 Questions
> >What are the main improvements in v1.2 againgst v1.1 ?
>
> Ok this is difficult as there have been so many. Kernel changes are not so
> significant as the kernels I have put online have been following
NetBSD-current
> anyway.
> but there have been loads of changes system wide ...
>
> The NetBSD CHANGES doc contains all the details (I will not post it here
> as it is big).
>
> >Isn't it so that the unstability of the Xarm is based on the 'floating
> >point exeptions' errors made by the FPE ?
> Nope
> 99% of Xarm crashes are SEGV's and not FP exceptions. The most common
> SEGVS are caused by solid window drags and the cause of the SEGV has been
> identified. The solution is being worked on atm

I should point out that these comments do not apply to the 1.1 version of X
which is X11R6. The causes of SEGVs in 1.1 were completely different and the
majority were FPE related until Mark fixed the problem (I don't know how or
when, just that the FPE problem went away somewhere in the 1.2 release cycle -
or I can't reproduce it any more with an X11R6 build based on 1.2 using the
Wakefield snapshot of the source tree with a new kernel).

The SEGVs in 1.2 are a bug which appears to have been introduced by the X
consortium in the move from X11R6 to X11R6.1 - I know the cause but not the
solution. Currently I have a work-around which puts white lines at the top and
bottom of the screen.

In both releases there are problems with virtual console switching which can
occasionally cause a crash. These have not changed.

To summarise:

1) There were FPE related crashes in X running under 1.1. These have gone away
because of changes in the kernel (I don't think anyone knows quite which
changes fixed it).

2) There were crashes caused by a race condition when you switch virtual
terminal. These can still happen. I am working on a way to reduce the
occurence. Fixing it will need major work which I haven't figured out how to do
cleanly.

3) X has been upgraded to X11R6.1 which appears to have introduced a new bug in
the machine independant part of X. This may be caused by a bug in gcc. There is
a workaround which puts white lines at the top and bottom of the screen.
Alternatively avoiding solid window drags reduces the chance of hitting it.

4) Bits of the old X distribution are known to have been miscompiled by gcc
causing random bugs. These problems are now fixed.

5) There was a race condition on start up which could crash X before the
keyboard and mouse were turned on. This has been fixed.

> >If this is the case I think nothing will change until there is a new
> >FPE (or the communication between FPU and FPE is improved) or a FPA.
>
> The FPE cannot be improved very much as it is ARM Ltd FPE core.
>
> Also changes to the FPE and handling FPE exceptions is probably more kernel
> related.
> >I've got some (v1.1) binaries which compiled but don't run (on
> >v1.1) because of the 'floating point exeption'. Any suggests ???
>
> What is the number of the floating point exeption ?
> doing things with NaN's Inf or divide by zero will cause exceptions.
> On a number of systems there errors do not cause exceptions and you just
> get NaN or Inf results.
>
> One thing that needs to be sorted is the fpsetmask() and associated
> functions. These allow the fp expection masks to be changed. This could
> be used to allow divide by zeros etc. not to cause an exception.
>
> Part of the problem is that masking FP exceptions is system wide with the
> ARM FPA/FPE. To support different exception masks for different processes
> would mean FP instructions to save and load the FP control register on every
> context switch.
> I suppose one solution would be a way of setting the behaviour system wide.

This isn't a solution. At best its a kludge.

> The exception number is the key. In my book divide be zero exceptions etc
> are ok as the result is undefined.
>
> >Is it worth the work to install it and have I to install everything
> >from scratch ?
>
> If you have a 1.1 instalation it should not be too much work.
> You may want to wait for the 1.2 final release though.
> Things like the base set should install over the 1.1 base set.
> (Don't reinstall etc or you loose your config stuff)
>
> similarly the text and man sets install over the existing versions.
>
> For the comp set you will need to remove the as252 and cc272 sets and can
> then install the 1.2 comp set over the existing comp set.
>
> The 1.2 comp set has a number of libc bug fixes in it.
>
> Whether you want to upgrade X is another Q ..

Of course if you want to use a new Xarm then you have to upgrade the lot and
the old versions of Xarm, xterm and xconsole have some pretty vicious
incompatibilities with 1.2. If you don't upgrade X you're either very brave or
very foolish.

> >I think if shared libaries become available I have to reinstall obviosly
> >everything new from scratch.
> >Can someone tell me the current state of shared libaries ?
>
> Non-existant ....
>
> Ok The stumbling block on shared libraries is -fpic.
> To build shared libraries we need position independant code. Currently
> GCC/arm does not support the -fpic options so we cannot do this.
>
> Solution: Somebody needs to write PIC support for GCC/arm
>
> In the kernel team it would be either me or Rob who would look at that.
> I have the kernel, 1.2 and everything else to do
> rob has X11 to do so neither of us has the time.

This isn't the reason I'm not working on it - I'm not doing much because the
ARM backend of gcc is being rewritten and so the shared library stuff would
need a complete rewrite in the near future anyway. Banging my head against a
brick wall and piping the result to /dev/null isn't my idea of fun :)

At the current rate I'm estimating Q2 97 for shared libs but a lot of that
depends on how much of the work gets done by the port maintainer (if we're
lucky he might do PIC support himself).

Cheers

Rob

--