I'd move the loading segment to 128K (segment 0x2000). As long
as memory below 128K is not set up with the memory subsystem (not sure if
it is) the problem should go away. In fact I think what was happening
before was that BSS space was being corrupted by the BIOSs use of the
'video' memory, so it's likely the panic will go away.
- Chad
On Sun, 7 Feb 1999, Michael W. Shaffer wrote:
> > The display funniness would be caused by ELKS being ignorant about
> >clobbering the video memory. The kernel would have to be told not to use
> >the memory (might be tricky if it's in the area where the kernel is loaded
> >- quite likely since it's loaded at 64K unless that's changed). I dunno
> >about the kernel panic, although that stack dump feature looks interesting. :)
> >
>
> I have been reading the various manuals that came with the machine like the
> _Guide to Operations_ and _Compute's Mapping the IBM PC and PCjr_. I believe
> you are correct, and that sure looks like what is happening. After I
> scattered a bunch of printk()s throughtout init.c and sched.c, it looks like
> the kernel gets all the way to the first call to schedule() in
> kfork_process(). I am guessing that since the kernel is getting dumped into
> the video buffer it is being corrupted by the subsequent writes to this area
> from printk(), etc. and this results in the eventual crash.
>
> The _Guide_ goes on about a utility to be used with the Racore expansion to
> relocate the video buffer from the 112K - 128K region (its normal location)
> to a lower position at 24K to 40K (which it says is right after DOS). The
> _Guide_ says that this will allow DOS to recognize the full memory capacity
> of the machine with the expansion (which it could not if the buffer were
> left in the middle of memory at 112K). I have also been wandering through
> the boot loader code and config.h and have found a define called
> DEF_SETUPSEG which is 0x120, so I am just wondering now which of the two
> following approaches would be best:
>
> <> Change DEF_SETUPSEG (or some other parameter, I'm really not sure exactly
> what I'm talking about yet) to make the kernel load into a different area of
> memory. I don't know what the full implications of this are, and am not
> really sure where would be best to move it.
>
> <> Put together some little assembly language routine that could be called
> to 'move the video buffer' in a manner similar to the utility the Racore
> manual talks about. I am guessing that there is some BIOS call I could make
> early on in the bootloader code to accomplish this. I am not sure yet how
> The kernel is figuring out where video memory is for the purpose of doing
> pokeb() to it (in direct console mode), so I don't know if doing this would
> confuse the kernel and result in a blank screen later on.
>
> If no-one has any better guesses, I think I'll try the second approach
> first.
>
