On Thu, 16 Jun 2005, Stephane E. Potvin wrote: >>> I did a binary search to find the offending commit. Reverting the changes >>> to kern_malloc.c and malloc.h locally did fix the problem. That's what >>> I'm >>> currently using to type this message. I also had to revert the changes to >>> vmstat to make the world compile. >>> >>> Using head sources from yesterday (Jun 15) exhibit the same problem >>> unfortunately. >> >> Hmm.. It looks like Alan Cox just committed the attached patch to >> uma_int.h to modify UMA_BOOT_PAGES following a report of a panic at a >> similar point in the boot process. Could you try updating to the latest >> uma_int.h or trying the patch below to see if it makes a difference? >> > > Great :) It did the trick. The laptop is happily booting with the new > allocator now. Thanks a lot to you and Alan Cox. Looks like what basically happened is this these kern_malloc.c changes increase the memory burden on UMA as statistics structures for malloc types now get allocated from UMA. It looks like, from your dmesg, you have a fair number of modules loaded, so the storage for the statistics comes out of the early UMA page pool, whereas before it came out of BSS. We'll see if further tuning is required or not with large numbers of modules. The thing that surprised me, though, is the unclean failure mode. The other report saw a clean panic which presumably made debugging it much easier... Robert N M WatsonReceived on Thu Jun 16 2005 - 15:42:05 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:36 UTC