Re: panic at serial boot

On Wed, Mar 27, 2013 at 01:56:29PM +0100, mh_at_kernel32.de wrote:
> Am 2013-03-27 06:54, schrieb Andriy Gapon:
> > on 27/03/2013 00:00 mh_at_kernel32.de said the following:
> >> Hi Ho,
> >>
> >> I'm trying to install FreeBSD 10.0-CURRENT snapshot from 23.03.2013 
> >> on a Dell
> >> M620 blade.
> >> However, I'm getting a panic and drop to db while booting.
> >>
> >> Looks like that:
> >>
> >> Root mount waiting for: usbus1 usbus0
> >> ugen0.2: <vendor 0x8087> at usbus0
> >> uhub2: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 
> >> 2> on usbus0
> >> ugen1.2: <vendor 0x8087> at usbus1
> >> uhub3: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 
> >> 2> on usbus1
> >> Root mount waiting for: usbus1 usbus0
> >> uhub2: 6 ports with 6 removable, self powered
> >> uhub3: 8 ports with 8 removable, self powered
> >> ugen0.3: <no manufacturer> at usbus0
> >> uhub4: <no manufacturer Gadget USB HUB, class 9/0, rev 2.00/0.00, 
> >> addr 3> on usbus0
> >> Root mount waiting for: usbus1 usbus0
> >> ugen1.3: <Avocent> at usbus1
> >> ukbd0: <EP1 Interrupt> on usbus1
> >> kbd0 at ukbd0
> >> kbd0: ukbd0, generic (0), config:0x0, flags:0x3d0000
> >> uhub4: 6 ports with 6 removable, self powered
> >> Root mount waiting for: usbus0
> >> ugen0.4: <Avocent> at usbus0
> >> ukbd1: <Keyboard> on usbus0
> >> kbd2 at ukbd1
> >> kbd2: ukbd1, generic (0), config:0x0, flags:0x3d0000
> >> Trying to mount root from ufs:/dev/md0 []...
> >> start_init: trying /sbin/init
> >> panic: vm_fault: fault on nofault entry, addr: ffffff80002be000
> >> cpuid = 15
> >> KDB: enter: panic
> >> [ thread pid 4 tid 100101 ]
> >> Stopped at      kdb_enter+0x3e: movq    $0,kdb_why
> >> db>
> >>
> >> Any idea where to go from here?
> >>
> >> initially I tried 9.1-STABLE snapshot from the same date, but that 
> >> one doesn't
> >> even give serial output while booting. odd thing, but that's another 
> >> story.
> >>
> >> I just thought since I'm giving -current on this hardware a short 
> >> and there is a
> >> problem, it might be worth reporting.
> >> Anything I should do?
> >
> > 'bt' command at the 'db>' prompt
> 
> Here we go:
> 
> db> bt
> Tracing pid 5 tid 100109 td 0xfffffe00466bf920
> kdb_enter() at kdb_enter+0x3e/frame 0xffffff8688d3e340
> vpanic() at vpanic+0x147/frame 0xffffff8688d3e380
> panic() at panic+0x43/frame 0xffffff8688d3e3e0
> vm_fault_hold() at vm_fault_hold+0x14ac/frame 0xffffff8688d3e630
> vm_fault() at vm_fault+0x77/frame 0xffffff8688d3e670
> trap_pfault() at trap_pfault+0x207/frame 0xffffff8688d3e720
> trap() at trap+0x659/frame 0xffffff8688d3e930
> calltrap() at calltrap+0x8/frame 0xffffff8688d3e930
> --- trap 0xc, rip = 0xffffffff80c1a396, rsp = 0xffffff8688d3e9f0, rbp = 
> 0xffffff8688d3ea20 ---
> bcopy() at bcopy+0x16/frame 0xffffff8688d3ea20
> md_kthread() at md_kthread+0x17d/frame 0xffffff8688d3ea70
> fork_exit() at fork_exit+0x84/frame 0xffffff8688d3eab0
> fork_trampoline() at fork_trampoline+0xe/frame 0xffffff8688d3eab0
> --- trap 0, rip = 0, rsp = 0xffffff8688d3eb70, rbp = 0 ---
> db>
> 
> where to go from now? :)

Do you use preload md(4) ? If yes, try the following patch:

diff --git a/sys/dev/md/md.c b/sys/dev/md/md.c
index d32ddb3..e871d8f 100644
--- a/sys/dev/md/md.c
+++ b/sys/dev/md/md.c
_at__at_ -1008,7 +1008,15 _at__at_ mdinit(struct md_s *sc)
 	pp = g_new_providerf(gp, "md%d", sc->unit);
 	pp->mediasize = sc->mediasize;
 	pp->sectorsize = sc->sectorsize;
-	pp->flags |= G_PF_ACCEPT_UNMAPPED;
+	switch (sc->type) {
+	case MD_MALLOC:
+	case MD_VNODE:
+	case MD_SWAP:
+		pp->flags |= G_PF_ACCEPT_UNMAPPED;
+		break;
+	case MD_PRELOAD:
+		break;
+	}
 	sc->gp = gp;
 	sc->pp = pp;
 	g_error_provider(pp, 0);