Hi Ok, so I'm a fool for trashing my other server's disklabel, but my script for recovering the drive by finding the filesystem start highlighted this issue. Running this program, resulted in my server panicing after about 15 minutes (15000 iterations). Watching top, the 'wired' memory slowly increases increases until the system panics with the message below. It's very repeatable, so I can get a more detailed backtrace if required. Ian #! /usr/local/bin/perl # There must be a better way to do this for ($i = 345000; $i < 8538240; $i += 2) { open(FILE, ">newlabel"); print FILE <<END; <Snipped out rest of label> c: 8538240 0 unused 1024 8192 # (Cyl. 0 - 8893) e: 8538240 $i 4.2BSD 1024 8192 46208 # (Cyl. 0 - 8893) END close(FILE); system("disklabel -R /dev/ad2s1c newlabel"); $result = system("dumpfs /dev/ad2s1e|grep UFS1"); print "RESULT: $result\t $i\n"; last if ($result == 0); } panic: kmem_malloc(4096): kmem_map too small: 109064192 total allocated cpuid = 1; lapic.id = 01000000 boot() called on cpu#1 syncing disks, buffers remaining... 1423 1423 1422 1422 1422 1422 1422 1422 1422 1422 1422 1422 1422 1422 1422 1422 1422 1422 1422 1422 1422 1422 giving up on 910 buffers Uptime: 15m40s Dumping 191 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 (kgdb) bt #0 0xc01d8acb in doadump () #1 0xc01d916a in boot () #2 0xc01d94b0 in poweroff_wait () #3 0xc02b7e64 in kmem_malloc () #4 0xc02c8c87 in page_alloc () #5 0xc02c898c in slab_zalloc () #6 0xc02c9c68 in uma_zone_slab () #7 0xc02c9eb1 in uma_zalloc_bucket () #8 0xc02c9ae7 in uma_zalloc_arg () #9 0xc01ccd99 in malloc () #10 0xc01a6883 in g_slice_init () #11 0xc01a735c in g_slice_new () #12 0xc02dbfed in g_mbr_taste () #13 0xc01a5150 in g_do_event () #14 0xc01a5456 in one_event () #15 0xc01a54e5 in g_run_events () #16 0xc01a6495 in g_event_procbody () #17 0xc01c2b70 in fork_exit ()Received on Tue Apr 15 2003 - 11:40:26 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:03 UTC