Re: port-alpha/41106: GENERIC.MP memory management faults on API CS20/HP DS20L

["Michael L. Hitch" <mhitch%lightning.msu.montana.edu@localhost>]

The following reply was made to PR port-alpha/41106; it has been noted by GNATS.

From: "Michael L. Hitch" <mhitch%lightning.msu.montana.edu@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: port-alpha-maintainer%netbsd.org@localhost, 
gnats-admin%netbsd.org@localhost, 
    netbsd-bugs%netbsd.org@localhost
Subject: Re: port-alpha/41106: GENERIC.MP memory management faults on API
 CS20/HP DS20L
Date: Sun, 6 Sep 2009 11:46:28 -0600 (MDT)

 On Tue, 31 Mar 2009, dmarquess%gmail.com@localhost wrote:
 
 > db{1}> bt
 > cpu_Debugger() at netbsd:cpu_Debugger+0x4
 > panic() at netbsd:panic+0x244
 > trap() at netbsd:trap+0x35c
 > XentMM() at netbsd:XentMM+0x20
 > --- memory management fault (from ipl 5) ---
 > uvm_pagealloc_strat() at netbsd:uvm_pagealloc_strat+0x64
 ...
 > Problem does not occur with a GENERIC kernel, only GENERIC.MP
 
    It will also work with GENERIC.MP if you disable all the secondary cpus 
 (which rather defeats the purpose of GENERIC.MP).
 
    I finally got a chance to start looking into this and found out that 
 there's some per-cpu initialize going on before the secondary cpus are 
 told they can start running.  Prior to that point, only the primary cpu 
 has been added to the list of cpus, so the per-cpu setup doesn't occur on 
 the secondary cpus.  I've got a fix for that, which at least lets me boot 
 up and start running with multiple cpus, but eventually crashes later when 
 it gets busy.  I'm in the process of trying to track that down now.
 
 --
 Michael L. Hitch                       mhitch%montana.edu@localhost
 Computer Consultant
 Information Technology Center
 Montana State University       Bozeman, MT     USA