Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 20 Nov 2011 08:41:28 -0800
From:      Jeremy Chadwick <freebsd@jdc.parodius.com>
To:        Johannes Totz <johannes@jo-t.de>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: panic: make_dev_credv: bad si_name (error=17, si_name=pass2)
Message-ID:  <20111120164128.GA29952@icarus.home.lan>
In-Reply-To: <jaba31$fqn$1@dough.gmane.org>
References:  <jab6mc$phv$1@dough.gmane.org> <20111120160307.GA20262@icarus.home.lan> <jaba31$fqn$1@dough.gmane.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Nov 20, 2011 at 04:32:33PM +0000, Johannes Totz wrote:
> On 20/11/2011 16:03, Jeremy Chadwick wrote:
> >On Sun, Nov 20, 2011 at 03:34:36PM +0000, Johannes Totz wrote:
> >>(Sent twice, first one bounced...)
> >>Just got a panic on 9-stable, running inside VirtualBox, trying to
> >>build a release-set. Don't know yet if reproducable, just happened a
> >>few minutes ago.
> >>The whole core.txt stuff follows below (beware of line-breaks):
> >>
> >>...
> >>Unread portion of the kernel message buffer:
> >>(ada1:ahcich0:0:0:0): lost device
> >>panic: make_dev_credv: bad si_name (error=17, si_name=pass2)
> >>cpuid = 0
> >>KDB: stack backtrace:
> >>#0 0xc0a4aff7 at kdb_backtrace+0x47
> >>#1 0xc0a185c7 at panic+0x117
> >>#2 0xc09d05de at make_dev_credv+0x9e
> >>#3 0xc09d080a at make_dev+0x4a
> >>#4 0xc04b79e0 at passregister+0x230
> >>#5 0xc048ece3 at cam_periph_alloc+0x4e3
> >>#6 0xc04b7525 at passasync+0x85
> >>#7 0xc0490442 at xpt_async_bcast+0x32
> >>#8 0xc0492715 at xpt_async+0x105
> >>#9 0xc04991f3 at probedone+0xc33
> >>#10 0xc04958a1 at camisr_runqueue+0x2e1
> >>#11 0xc04959ff at camisr+0x13f
> >>#12 0xc09ed69b at intr_event_execute_handlers+0x13b
> >>#13 0xc09eee5a at ithread_loop+0x7a
> >>#14 0xc09ea8a7 at fork_exit+0x97
> >>#15 0xc0d32734 at fork_trampoline+0x8
> >>...
> >>Uptime: 7m57s
> >>(ada1:ahcich0:0:0:0): Synchronize cache failed
> >
> >According to the above, your ada1 "virtual disk" fell off the bus
> >entirely.  Relevant storage bits taken from your dmesg:
> >
> >>atapci0:<Intel PIIX4 UDMA33 controller>  port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd000-0xd00f at device 1.1 on pci0
> >>ata0:<ATA channel 0>  on atapci0
> >>ata1:<ATA channel 1>  on atapci0
> >>ahci0:<Intel ICH8M AHCI SATA controller>  port 0xd040-0xd047,0xd050-0xd057,0xd060-0xd06f mem 0xf0806000-0xf0807fff irq 5 at device 13.0 on pci0
> >>ahci0: AHCI v1.10 with 1 3Gbps ports, Port Multiplier not supported
> >>ahcich0:<AHCI channel>  at channel 0 on ahci0
> >>...
> >>ada0 at ata0 bus 0 scbus0 target 0 lun 0
> >>ada0:<VBOX HARDDISK 1.0>  ATA-6 device
> >>ada0: 33.300MB/s transfers (UDMA2, PIO 65536bytes)
> >>ada0: 20480MB (41943040 512 byte sectors: 16H 63S/T 16383C)
> >>ada0: Previously was known as ad0
> >>ada1 at ahcich0 bus 0 scbus2 target 0 lun 0
> >>ada1:<VBOX HARDDISK 1.0>  ATA-6 SATA 2.x device
> >>ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
> >>ada1: Command Queueing enabled
> >>ada1: 20480MB (41943040 512 byte sectors: 16H 63S/T 16383C)
> >>ada1: Previously was known as ad4
> >
> >My recommendation is to remove VirtualBox from the picture entirely and
> >instead do whatever you were doing (running zfstest) on bare metal.
> 
> Yeah, would love to.
> But http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/155587 prevents
> me from doing so. I'm trying to build a live-disc that includes
> http://svnweb.freebsd.org/base?view=revision&revision=226617 so I
> can recover the pool.

Can you not use mfsBSD for this task?

http://mfsbsd.vx.sk/

The 9.0-RELEASE image provided by mm@ on his site is dated 2011/10/26,
while SVN rev 226617 was committed on 2011/10/21 (5 days prior).

You might also want to try a 9.0-RC2 build, which was just announced and
put on the mirrors a couple days ago:

ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/
ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/

(Comment in passing: I still have no idea why the architecture
directories for 9.0 are "doubled up" like that; it almost looks like
the result of someone using rsync with a missing trailing slash on the
source directory).

I can't explain why your ada1 "virtual disk" would drop off the bus
entirely.  Possibly too much I/O and stress via VirtualBox causes too
long a delay, resulting in ahci.ko or CAM bits dropping the idsk from
the bus.  kern.cam.ada.default_timeout is, by default, 30 seconds, which
is an awful long time, but I don't know if that is the only timeout
available (e.g. no idea what ahci.ko uses internally, I'd need to check
the code).

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                   Mountain View, CA, US |
| Making life hard for others since 1977.               PGP 4BD6C0CB |




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111120164128.GA29952>