On Sat Jan 03 2004 at 04:37:17 +0000, port-sgimips@NetBSD.org wrote:
> port-sgimips-owner-mark=nellemann.nu@NetBSD.org writes:
> 
> > On Wed Dec 31 2003 at 12:43:03 +0200, Ilpo Ruotsalainen wrote:
> > > A very -current kernel hangs early on my Indy.
> > > 
> > > I traced it dying inside the uvm_pageboot_alloc() in mach_init()
> > > (allocating USPACE). The funny thing is, it seems we end up
> > > pmap_steal_memory()ing our own boot stack, because it *does* return from
> > > pmap_steal_memory() with correct looking pointers around (and clears the
> > > allocated memory) but it never gets back to uvm_pageboot_alloc() from
> > > where it was called... (Yup; printing a pointer to a stack variable
> > > yields a pointer near the address pmap_steal_memory() is returning.)
> > > 
> > > I guess ARCS either doesn't inform us about it's stack as being
> > > "non-free" memory or we use much more stack than ARCS allocates...
> > 
> > Okay, there were 2 different bugs here. First, the ARCS on my Indy
> > doesn't bother to report the region immediately before kernel as
> > FreeContiguous like ARCS spec says it should (to inform us it contains
> > the stack). Second, we would have ignored ARCS telling us about the
> > stack being there anyway...
> > 
> > I committed changes to sys/arch/sgimips/sgimips/machdep.c to leave 1
> > page before kernel untouched so we won't stomp our own stack (it would
> > be possible to free the page later in cpu_startup() since we're running
> > on proc0 stack at that point) and to fix the memory detection to cope
> > with the fact that kernel isn't completely inside one ARCS "block" of
> > memory anymore. My Indy boots happily with a very small kernel (that
> > would crash before these fixes) now.
> > 
> > This *might* fix some similar ("strange crash in mach_init()") problems.
> > 
> > -- 
> > Ilpo Ruotsalainen - <lonewolf@iki.fi> - http://www.iki.fi/lonewolf/
> 
> *** CONFIRMATION NEEDED ***
> 
> The e-mail address you have just sent mail to requires a one-time
> authentication to deliver your message.  In order for your original
> e-mail to be delivered, simply reply to this message keeping the
> Subject line intact (the additional "Re:" is ok).
> 
> Please note that if you are a vendor attempting to send unsolicited
> spam and you choose to reply to this e-mail, your address will be
> permanently banned from this server.

Okay, consider this both a confirmation and a flame.

First of all, it's "a tad hard" to send a confirmation mail when your
antispam system has such a fscked up configuration that the "request for
confirmation" mail doesn't even have your address anywhere.

Secondly, why on earth require confirmation for mails sent to lists,
especially lists that are very carefully filtered for spam already? If
everyone followed the same model I wouldn't have time to do anything but
send confirmation mails all day long...

-- 
Ilpo Ruotsalainen - <lonewolf@iki.fi> - http://www.iki.fi/lonewolf/