Re: shared memory conundrum

Peter T. Breuer (ptb@it.uc3m.es)
Sun, 29 Jun 1997 15:13:21 +0200 (MET DST)


"A month of sundays ago Trevor Johnson wrote:"
>
> Peter T. Breuer wrote:
>
> > I patched my 2.0.25 kernel with the IPC patches ("dipc") for
> > intercommunication amongst several machines and it works ...
> >
> > ... but loadlin (1.6) won't load the new kernel. It gives a "Less
> > than 4M memory" error. Lilo (2.0) loads it fine. I don't get it. How
>
> Try updating loadlin as well, to at least version 1.6a. The location
> recommended by Hans Lernen is
> ftp://ftp.suse.com/pub/loadlin/update-1.6a/loadlin.exe.gz, which is

Yep. That fixed it! THANKS!

I still don't get it, however - the patch for loadlin alongside the .exe
shows that the only change was to remove the test for less than 4M of
memory because the 2.1.* series does something new and excitingly
different:

+#if 0 /* this won;t work any more, because 2.1.22 changed the format
+ of EXT_MEM_K, see STANDARD_MEMORY_BIOS_CALL in setup.S
+ */
if (EXT_MEM_K < (3*1024)) error("Less than 4MB of memory.\n");
+#endif

I patched a 2.0.25 kernel. One would think from the comment that the
patch I applied (which was aimed at the 2.0.* series) changed EXT_MEM_K
also. But it didn't. I just did several greps through
dipc-2.0.29-{kernel|headers}.diff. Now, as I recall, EXT_MEM_K is a
macro in misc.c:

#define EXT_MEM_K (*(unsigned short *)0x90002)

which looks at the contents of 0x90002. I think that is filled in
setup.S, but I can't make too much of the assembler. I think that
it is filled by a

mov [2],ax

since the whole code seems to be located at 0x90000 according to the
comments, presumably via an offset in some register I don't know heck
about. Now, if STANDARD_MEMORY_BIOS_CALL is set, the memory size is
loaded via an int 0x15. If it's not set, varous strange things go on to
get the extended memory size and then that is added to conventional
memory and stored via mov [2],.. after dividing by 64. I don't know if
the divide by 64 is not necessary if STAN..CALL is set.

Personally, I think someone should comment this code :-).

What has changed? The patches I applied changed only kernel/sys_i386.c and
mm/fault.c. Nothing in the area I am looking at (setup.S) seems to have
changed. So how can loadlin be affected? Is there some global change of
state in the processor, perhaps?

Thanks again for the curative magic, but I would love an explanation!

---------------------------------------------------------------------
Peter T. Breuer MA CASM PhD. Ing., Prof. Asoc.
Area de Ingenieria Telematica E-mail: ptb@it.uc3m.es
Dpto. Ingenieria Tel: +34 1 624 99 53
Universidad Carlos III de Madrid Fax: +34 1 624 94 30/65
Butarque 15, E-28911 Leganes URL: http://www.it.uc3m.es/~ptb
Spain