This is a known limitation. Currently I keep track of the physical pages of the new kernel and boot archive using a contiguous array under physical address 1G for simplicity. I did notice that on certain systems, after the boot archives are updated, we consistently fail to find even 16 pages of physically contiguous memory under 1G. When you encountered the problem, did you happen to have just rebuilt the boot archive?
In any case, this is something I need to look into. I do have a quick fixes for this particular problem (basically map the bottom 2G instead of 1G). I also have panic fast reboot changes on the way which would make this less of an issue, if not a non-issue completely. I would happy to fix one way or the other. Thanks, Sherry On Tue, Nov 11, 2008 at 01:42:01PM -0800, Antonello Cruz wrote: > J?rgen Keil wrote: >> Antonello Cruz wrote: >>> J?rgen Keil wrote: >>>> Antonello Cruz wrote: >>>>> J?rgen Keil wrote: >>>>>> And how does it fail? >>>>> It drops to regular *slow* reboot. >>>> Hmm, in about 30% of the fast reboots I get a warning >>>> that the kernel is unable to allocate 64kbytes of contiguous >>>> memory (needed for page tables?) and falls back to a >>>> regular boot. >>> I've never seen this, but I have 4GB of RAM... >> >> I've seen this failure on two boxes; one has 2GB and the other >> has 8GB of RAM. The exact message by the kernel is >> >> WARNING: Fastboot: Couldn't allocate 0x10000 bytes below 1G to do fast >> reboot > That may be because your boot-archives are too big to fit under the > available memory under 1GB. I am cc'ing Sherry Moore because she would know > the specifics better. > > Antonello -- Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
