amr(4) not dump(8)-safe? (5.3Betas and CURRENT)

Tue Nov 2 07:18:06 PST 2004

I'm replying to myself, heh.

This turned out to be a firmware bug that was fixed with LSI Logic's 
latest firmware for the MegaRAID 320-4X.

Sorry for the noise.

Andy

| Andre Guibert de Bruet | Enterprise Software Consultant >
| Silicon Landmark, LLC. | http://siliconlandmark.com/    >

On Tue, 26 Oct 2004, Andre Guibert de Bruet wrote:

> Hi,
>
> I see the following on both 5.3 and CURRENT, while attempting to dump my 
> raid5 filesystem (/dev/amrd0a, which is mounted as /mnt/amrd0a):
>
> bling# /sbin/dump -0uaL -f "/mnt/backups/`hostname -s`-`utime`-raid5.dump" 
> /mnt/amrd0a
>  DUMP: Date of this level 0 dump: Tue Oct 26 05:34:32 2004
>  DUMP: Date of last level 0 dump: the epoch
>  DUMP: Dumping snapshot of /dev/amrd0a (/mnt/amrd0a) to 
> /mnt/backups/bling-1098783057-raid5.dump
>  DUMP: mapping (Pass I) [regular files]
>  DUMP: mapping (Pass II) [directories]
>  DUMP: estimated 68389746 tape blocks.
>  DUMP: dumping (Pass III) [directories]
>  DUMP: dumping (Pass IV) [regular files]
>  DUMP: 3.32% done, finished in 2:25 at Tue Oct 26 08:05:12 2004
>  DUMP: 6.78% done, finished in 2:17 at Tue Oct 26 08:02:17 2004
> load: 0.07  cmd: dump 72547 [runnable] 18.73u 151.77s 0% 14216k
>
> The dump processes are wedged in this state:
>
> 72547 root       4    0 14824K 14228K sbwait 1   2:51  0.00%  0.00% dump
> 72548 root      20    0 14700K 14172K pause  1   2:31  0.00%  0.00% dump
> 72550 root      20    0 14700K 12504K pause  1   2:31  0.00%  0.00% dump
> 72549 root      -8    0 14700K 14172K physrd 1   2:30  0.00%  0.00% dump
>
> db> tr 72549
> sched_switch(66f9f900,0,1,11e,a4ba580c) at 0x60613480
> mi_switch(1,0,607fa11c,1b2,0) at 0x606083cc
> sleepq_switch(9500b408,607f68ec,18e,0,b06e2b3c) at 0x606234b4
> sleepq_wait(9500b408,0,607f7d36,da,0) at 0x60623721
> msleep(9500b408,60896c60,4c,607f6ca9,0) at 0x60607f95
> bwait(9500b408,4c,607f6ca9,2c,a36d0000) at 0x60657bd3
> physio(655b7800,b06e2c80,0,387,60835660) at 0x605f8246
> devfs_read(b06e2c0c,1020001,66f9f900,219,b06e2c80) at 0x605b006f
> vn_read(66d73880,b06e2c80,670f3b80,1,66f9f900) at 0x60670f78
> dofileread(66f9f900,66d73880,3,8d4c000,1800) at 0x6062a254
> pread(66f9f900,b06e2d14,18,431,6) at 0x6062a189
> syscall(2f,2f,2f,e,8d4c000) at 0x6079a232
> Xint0x80_syscall() at 0x607858af
> --- syscall (198, FreeBSD ELF32, nosys), eip = 0x480dba7f, esp = 0x5fbfdcfc, 
> ebp = 0x5fbfdd28 ---
> db> tr 72547
> sched_switch(67853480,0,1,11e,a953f90c) at 0x60613480
> mi_switch(1,0,607fa11c,1b2,0) at 0x606083cc
> sleepq_switch(66c22e84,1,607f68ec,18e,0) at 0x606234b4
> sleepq_wait_sig(66c22e84,0,607f7d36,da,0) at 0x60623762
> msleep(66c22e84,66c22e54,158,607fdb0c,0) at 0x60607f86
> sbwait(66c22e3c,1,607fd87d,426,b0730bf4) at 0x6064828e
> soreceive(66c22dec,0,b0730c80,0,0) at 0x60644f09
> soo_read(6525acc0,b0730c80,670f3b80,0,67853480) at 0x60631363
> dofileread(67853480,6525acc0,8,5fbed968,4) at 0x6062a254
> read(67853480,b0730d14,c,431,3) at 0x6062a0cb
> syscall(2f,2f,2f,8,5fbed968) at 0x6079a232
> Xint0x80_syscall() at 0x607858af
> --- syscall (3, FreeBSD ELF32, read), eip = 0x480dc85f, esp = 0x5fbed92c, ebp 
> = 0x5fbed948 ---
> db> tr 72548
> sched_switch(652bdd80,0,1,11e,49f71f0c) at 0x60613480
> mi_switch(1,0,607fa11c,1b2,0) at 0x606083cc
> sleepq_switch(652bcc38,1,607f68ec,18e,0) at 0x606234b4
> sleepq_wait_sig(652bcc38,0,607f7d36,da,0) at 0x60623762
> msleep(652bcc38,652bcc6c,168,607d7c83,0) at 0x60607f86
> kern_sigsuspend(652bdd80,0,0,0,0) at 0x60602b34
> sigsuspend(652bdd80,b05a4d14,4,431,1) at 0x60602a5f
> syscall(2f,2f,2f,5fbfde00,5fbfdd90) at 0x6079a232
> Xint0x80_syscall() at 0x607858af
> --- syscall (341, FreeBSD ELF32, sigsuspend), eip = 0x480db17f, esp = 
> 0x5fbfdd7c, ebp = 0x5fbfdda8 ---
> db> tr 72550
> sched_switch(67854480,0,1,11e,b3c5320c) at 0x60613480
> mi_switch(1,0,607fa11c,1b2,0) at 0x606083cc
> sleepq_switch(67852838,1,607f68ec,18e,0) at 0x606234b4
> sleepq_wait_sig(67852838,0,607f7d36,da,0) at 0x60623762
> msleep(67852838,6785286c,168,607d7c83,0) at 0x60607f86
> kern_sigsuspend(67854480,0,0,0,0) at 0x60602b34
> sigsuspend(67854480,b074ed14,4,431,1) at 0x60602a5f
> syscall(2f,2f,2f,5fbfde00,5fbfdd90) at 0x6079a232
> Xint0x80_syscall() at 0x607858af
> --- syscall (341, FreeBSD ELF32, sigsuspend), eip = 0x480db17f, esp = 
> 0x5fbfdd7c, ebp = 0x5fbfdda8 ---
> db> show lockedvnods
> Locked vnodes
> db>
>
> FreeBSD bling.home 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Fri Oct 22 15:04:44 
> EDT 2004     root at bling.home:/usr/CURRENT/sys/i386/compile/BLING  i386
>
> More information on the system (Including dmesg) can be found at:
> http://bling.properkernel.com/freebsd/
>
> I haven't otherwise spotted any problems with amr under 5/CURRENT. Any ideas?
>
> Regards,
> Andy
>
> | Andre Guibert de Bruet | Enterprise Software Consultant >
> | Silicon Landmark, LLC. | http://siliconlandmark.com/    >
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>