On 20/11/2011 16:41, Jeremy Chadwick wrote:
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).
Haven't tried mfs. But r226617 was MFC'd only yesterday, so I'd guess it
would not include it.
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/
RC2 crashes for me, i.e. does not fix the issue (but otoh does not
include r226617 either).
(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).
The build finished eventually. It was just a one-time crash but I
thought might as well report it here. Seems like it is entirely Vbox's
fault though: my update to 4.1.6 was prob not a good idea. There are
other things that are wonky... (it just trashed the disk image is used
to build a new release).
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
