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
