the README in flashboot has some information about this..
On 2010/08/22 10:05, Chris Cappuccio wrote: > Adding a 7480-block ramdisk to i386 GENERIC/GENERIC.MP and amd64 > GENERIC/GENERIC.MP used to "work" in 4.5, 4.6 and 4.7 but it has "broke" in > 4.8 for i386 GENERIC.MP and amd64 GENERIC (haven't yet tested amd64 > GENERIC.MP) > > At this point i'm wondering if some part of the system fails to take into > account the extended size of the kernel with the ramdisk added (not a problem > for bsd.rd since it's so small), and I've just gotten lucky doing this in the > past (exceeding limiations of the ramdisk implementation?) I'm hoping > someone could peek at this for a minute and point me in the right direction. > > > 1. Begin: > > I tried adding a ramdisk to amd64 GENERIC but it fails to boot early on. > When I've seen the kernel stop booting early on, I always assumed that either > the kernel or the ramdisk needs to shrink. This is nothing new. A ramdisk > of this size (7480 512-byte blocks) works with 4.7 GENERIC, a larger one > fails to boot early on, and with the kernel growth in 4.8, this size ramdisk > does not work in 4.8 either, it fails early on. > > http://www.nmedia.net/GENERICRD > > Unfortunately I can't reproduce the exact panic messages until tomorrow. My > amd64 desktop has a usb keyboard and doesn't work at boot> prompt (only works > after the kernel initializes). Most BIOS provide some ps/2 emulation that > works at boot> but not this one. > > > 2. Next attempt: > > So then I tried to trim some fat and get the kernel+ramdisk to shrink. I > deleted some devices that were totally irrelevant for my application and > bring the total amd64 kernel+rd to almost 10MB. > > http://www.nmedia.net/TESTRD > > This kernelgives me a "panic: uvm_pglistalloc returned too many" during > isadma attach (with OPENBSD_4_8 tagged sources). > > bus_dmamem_alloc_range+0x192 > isadmaattach+0x54 > config_attach+0x150 > isascan+0x14c > config_scan+0xb3 > config_attach+0x150 > > What's odd about the traceback is that isadmaattach in > /usr/src/sys/dev/isa/isadma.c doesn't call bus_dmamem_alloc_range, like the > trace shows. It calls bus_dmamap_create > > if ((bus_dmamap_create(sc->sc_dmat, sz, 1, sz, sz, > BUS_DMA_24BIT|BUS_DMA_NOWAIT|BUS_DMA_ALLOCNOW, > &isadma_dmam[i])) != 0) > > which then calls malloc, not bus_dmamem_alloc_range! > > /* Allocate and initialize DMA map. > .... > mapsize = sizeof(struct bus_dmamap) + > (sizeof(bus_dma_segment_t) * (nsegments - 1)); > if ((mapstore = malloc(mapsize, M_DEVBUF, > (flags & BUS_DMA_NOWAIT) ? > (M_NOWAIT|M_ZERO) : (M_WAITOK|M_ZERO))) == NULL) > return (ENOMEM); > > So I wonder if my trace is bogus. Obviously bsd.rd works, where kernel and > ramdisk are much smaller. > > > 3. Test attempt > > I wanted to make sure that my device removal wasn't bringing out some > previously unidentified issue. So I booted a kernel with the same devices > removed from GENERIC, but without any ramdisk, just normal config bsd swap > generic. It boots properly as expected. > > http://www.nmedia.net/TEST > > > 4. Back to step 1, but on i386 > > So as I compile this information, I created two more kernels that are > essentially like the amd64 GENERICRD above, but on i386 instead. > > http://www.nmedia.net/I386RD > http://www.nmedia.net/I386RD.MP > > Both kernels+rd end up around 12MB > > Non-MP boots fine... yet the MP version panics before the Copyright > displays!! It triggers this panic in sys/arch/i386/i386/pmap.c: > > /* sanity check: kernel PTPs should already have been pre-allocated */ > if (va >= VM_MIN_KERNEL_ADDRESS && > !pmap_valid_entry(pmap->pm_pdir[pdei(va)])) > panic("pmap_enter: missing kernel PTP!"); > > Because the panic is so early, the traceback shows (null) function names. > > Hmmm.... > > Chris
