Re: 1.6.1: KASSERT in custom kernel triggered

[Gunther Nikl <gni%gecko.de@localhost>]

Hello,

On Sun, Jun 29, 2003 at 08:47:54PM +0200, Aymeric Vincent wrote:
> Gunther Nikl <gni%gecko.de@localhost> writes:
> >   I could nail the problem down. Apparently the arguments to pmap_bootstrap
> >   (start_c_pstart and start_c_fphystart) were zero... I don't know why that
> >   happend because eg. the boot_* flags were set properly. Moving the setup
> >   of these two variables before the possible kernel copy and MMU enable
> >   preparations solved it. A patch for this is included. I added another
> >   small modification. start_c() has now another parameter - loadbase. Since
> >   locore.s did already computed it, there is no need todo that in start_c()
> >   again.
> 
> I feel very sorry not to have read this thread thoroughly earlier. The bug
> you describe is actually one I introduced quite recently.

  I know :) Since I was using a custom loader, I thought I was on my own. When
  I recognized where the breakage came, I checked my maillog. I wish I would
  have tested your patch at the time you posted it :-( Luckily, the kernel
  was functional to a certain degree to make printf() debugging possible ;)

> Obviously, you are right: RELOC() must not be used after the MMU is
> enabled because they will duplicate each others' work, leading to
> accessing the wrong place in memory.

  Sounds logical. Do you have an idea why the bootblocks and loadbsd worked
  but my custom loader failed? BTW, I could get the failure with loadbsd too
  using the -Z flag. Since boot.amiga doesn't support -Z anymore, I guess its
  deprecated doing that.

> I have just checked in the fix you suggest in -current, and will be
> requesting a pullup to the 1.6.x branch soon.

  Thank you.

> Please note that I didn't check in the change to the start_c()
> prototype that you suggest. It looks fine and correct to me, but I
> can't hack on the Amiga right now, so... "one thing at a time". ;-)

  Since its an unrelated change, it should be committed separately. I added
  this change because the loadbase computation looked odd ;-)
  BTW, the modification to locore.s fixes a harmless bug. The stack cleanup
  after the call to start_c doesn't remove all arguments from the stack (the
  boot partition offset addition caused that). However, since sp is reloaded
  just before calling start_c_finish, it doesn't matter much.

  Gunther