kldload g_md.ko panics -CURRENT GENERIC kernel

Hi,

  With recent 6-CURRENT cvsup'ed on Aug-24-2004, manually kldload g_md
after booting the GENERIC kernel:

This GDB was configured as "i386-portbld-freebsd5.2"...
panic: The GEOM class MD already loaded
panic messages:
---
panic: The GEOM class MD already loaded
cpuid = 0
KDB: enter: panic
panic: from debugger
cpuid = 0
Uptime: 1m1s
Dumping 255 MB
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
#0  doadump () at pcpu.h:159
159	pcpu.h: No such file or directory.
	in pcpu.h
doadump () at pcpu.h:159
159	in pcpu.h
(kgdb) where
#0  doadump () at pcpu.h:159
#1  0xc0600918 in boot (howto=260) at ../../../kern/kern_shutdown.c:396
#2  0xc0600c2d in panic (fmt=0xc07c3302 "from debugger")
    at ../../../kern/kern_shutdown.c:552
#3  0xc04604f9 in db_panic (addr=-1067354761, have_addr=0, count=-1,
    modif=0xcbcf7b28 "") at ../../../ddb/db_command.c:435
#4  0xc0460490 in db_command (last_cmdp=0xc089c164, cmd_table=0x0,
    aux_cmd_tablep=0xc081c9cc, aux_cmd_tablep_end=0xc081c9e8)
    at ../../../ddb/db_command.c:349
#5  0xc0460558 in db_command_loop () at ../../../ddb/db_command.c:455
#6  0xc04620bd in db_trap (type=3, code=0) at ../../../ddb/db_main.c:221
#7  0xc0617813 in kdb_trap (type=3, code=0, tf=0x1)
    at ../../../kern/subr_kdb.c:418
#8  0xc078da24 in trap (frame=
      {tf_fs = -875626472, tf_es = -1067384816, tf_ds = -1065418736, tf_edi = -1065407312, tf_esi = 1, tf_ebp = -875594584, tf_isp = -875594604, tf_ebx = -875594540, tf_edx = 0, tf_ecx = -1056882688, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1067354761, tf_cs = 8, tf_eflags = 642, tf_esp = -875594552, tf_ss = -1067447329}) at ../../../i386/i386/trap.c:576
#9  0xc077c31a in calltrap () at ../../../i386/i386/exception.s:140
#10 0xcbcf0018 in ?? ()
#11 0xc0610010 in sched_interact_score (kg=0x1)
    at ../../../kern/sched_ule.c:1084
#12 0xc0600bdf in panic (fmt=0xc07f2cb0 "The GEOM class %s already loaded")
    at ../../../kern/kern_shutdown.c:536
#13 0xc05d2f94 in g_load_class (arg=0xc162a900, flag=0)
    at ../../../geom/geom_subr.c:89
#14 0xc05d0c5f in one_event () at ../../../geom/geom_event.c:180
#15 0xc05d0ce9 in g_run_events () at ../../../geom/geom_event.c:200
#16 0xc05d20a9 in g_event_procbody () at ../../../geom/geom_kern.c:134
#17 0xc05ed9b0 in fork_exit (callout=0xc05d206c <g_event_procbody>, arg=0x0,
    frame=0xcbcf7d48) at ../../../kern/kern_fork.c:820
#18 0xc077c37c in fork_trampoline () at ../../../i386/i386/exception.s:209
(kgdb)

  If g_md_load="YES" was in /boot/loader.conf:

	panic: The GEOM class MD already loaded
	cpuid = 0
	KDB: enter: panic
	[thread 100031]
	Stopped at	kdb_enter+0x2b: nop
	db> where
	kdb_enter
	panic
	g_load_class
	one_event
	g_run_events
	g_event_procbody
	fork_exit
	fork_trampoline

  Since I always left g_md as a kernel module and load it in loader.conf,
the system always panics if I forget to unload the module before booting
the latest GENERIC kernel(for testing purpose). I'm aware of that the answer
may be "don't do it, use static compiled md device instead!" However,
shouldn't there be any foot-shooting prevention mechanism in the md device?

  I'm wondering about why this module loading panicked instead of bailing out
with something like "kldload: can't load g_md: File exists?" Does the
MODULE_VERSION workaround in random device also work in this case?