Re: Random comments

Hi,

Jeremy Fitzhardinge wrote:
>
> In the course of doing that, I thnk I found a kernel bug with
> executable caching, or perhaps a filesystem bug. For a while I
> was being confused because none of my changes were taking place -
> I even put a 'printf("FOO!");' at the start of main. Even if I
> rm'd the binary and all the .o's, remade and typed "./ls", I got
> the old version. A file called "ls~" appeared which I couldn't
> delete ("cannot unlink: busy", but if I "mv ls~ .." I could make
> a new one which worked. Once I'd finished and copied it into
> /vsta/bin, the same thing happened. This was on a dos filesystem.

>From discussions I've had with Andy this could be a kernel problem -
executables don't get uncached correctly. There's also was a problem with
the FID code a couple of months back that I seem to remember was related. I
didn't try to create a fix as at the time it triggered a kernel trap and I
was more interested in fixing the kernel (Andy did this with his mmap()
changes). If memory serves, the problem is that if we change a file's
contents we don't change it's FID so the kernel doesn't realise there's any
difference.

FWIW the "xxx~" files are created by strip, and using cp to copy the new
version of the file over the old one still leaves the file with the same
FID.

> I changed the idle loop to use the "hlt" instruction rather than just
> busy-waiting. This keeps CPUs much cooler on fast machines and saves
> batteries on my notebook.

This is true for most CPUs, but it breaks other systems (they lock up).
Linux now defaults to using hlt, but has to provide a boot-time switch to
disable it for some systems. I just took a quick look at the Linux kernel
and it would appear that the kernel will hang with the message "Checking
'hlt' instruction... " if this doesn't work.

                        Regards,
                        Dave
Received on Wed Nov 2 00:28:16 1994