On Sun, Nov 18, 2007 at 12:41:25PM +0100, Martin Husemann wrote:

> pool_cache_bootstrap() needs to access all cpu_info's. Unfortunately it
> is called from multiple places early in initialization, while the cpu
> infos are not yet available.
>
> For example the first place where this hits on sparc is pmap_init()
> calling pool_cahce_bootstrap() for the pmap_cache.
> 
> Even if I avoid that path by defering the initialization of that
> cache, it is hit next here:
> 
> pool_cache_bootstrap(0xe80672c4, 0x10, 0x0, 0xe81ae400, 0xe81ae400, 0x0) at netbsd:uvm_anon_init+0x44
> uvm_anon_init(0xe819d788, 0x16000, 0x8, 0xe819dec0, 0xe81a8a60, 0xe818e000) at netbsd:uvm_init+0x9c
> uvm_init(0xe81997b4, 0xe8199788, 0x0, 0x4, 0x0, 0xfe015000) at netbsd:main+0x54
> main(0x0, 0xfffffff8, 0x0, 0x0, 0x2ffc04, 0xe80022d8) at netbsd:sparc_interrupt4
> 
> I bet more would follow if we work around this one.

It seems likely.
 
> It seems bogus to rely on info about more then curcpu() to be available before
> autoconfig has had a chance to attach the cpus.

[Working CPU_INFO_FOREACH before autoconf, and a cpu_info address for the
boot CPU that is stable from locore through autoconf]

I don't agree, because otherwise it involves special-casing things: it's
one reason the cpu_info is available before the boot CPU is attached by
autoconf. It has caused us problems before with sparc if you remember.

> Any ideas?

I'd like to fix sparc but I don't have a machine any more and I'm not
confident about doing that without testing. I think it can be coded around
in MI code so I'll do that now.

Thanks,
Andrew