Harald Schmalzbauer wrote:
Am Sun, 07 Jan 2007 19:58:23 -0800
schrieb Scott Long <[EMAIL PROTECTED]>:
[...]
machine is opteron hardware, but running a regular i386/SMP
kernel/world. With everything at 6.2RC2 (as of 29th of December)
except the areca driver the machine is rock solid, with the 29th
of december version of the areca driver the box will crash on
extract of a large tar file, removal
of a large directory structure, or pretty much anything that
does a lot
of disk io to different files/locations. There is no error
log prior to
seeing the following messages..
Dec 29 14:26:44 aleph kernel:
g_vfs_done():da0s1g[WRITE(offset=433078272, length=8192)]error = 5
Dec 29 14:26:44 aleph kernel:
g_vfs_done():da0s1g[WRITE(offset=433111040, length=16384)]error = 5
Dec 29 14:26:44 aleph kernel:
g_vfs_done():da0s1g[WRITE(offset=433209344, length=16384)]error = 5
Dec 29 14:26:44 aleph kernel:
g_vfs_done():da0s1g[WRITE(offset=433242112, length=32768)]error = 5
Dec 29 14:26:44 aleph kernel:
g_vfs_done():da0s1g[WRITE(offset=437612544, length=4096)]error = 5
Dec 29 14:26:44 aleph kernel:
g_vfs_done():da0s1g[WRITE(offset=437616640, length=12288)]error = 5
Dec 29 14:26:44 aleph kernel:
g_vfs_done():da0s1g[WRITE(offset=437633024, length=6144)]error = 5
Dec 29 14:26:44 aleph kernel:
g_vfs_done():da0s1g[WRITE(offset=437639168, length=2048)]error = 5
Dec 29 14:26:44 aleph kernel:
g_vfs_done():da0s1g[WRITE(offset=437641216, length=6144)]error = 5
There are a string of these, followed by a crash and reboot.
The file system
[...]
Areca 1.20.00.13 (as currently in the tree) does not seem to have
data corruption problems, but I can trigger g_vfs_done failures
under heavy I/O.
I have raised this with Areca support, and I'm waiting to hear back
from Erich Chen.
Regards,
Jan Mikkelsen
I discussed this issue in length with the release engineering team
today, and we're going to go ahead with keeping the .013 version in
6.2 since it has been working very reliably for a number of other
testers, and reverting it at this late stage of the release represents
Mybe it's unrelated to the areca driver, I can reproduce a similar
panic with ggate:
gune:/etc#46: ggatec create -u 1 -t 30 192.168.0.2 /dev/ad2p6
gune:/etc#47: mount /dev/gg
ggate1% ggctl%
gune:/etc#47: mount /dev/ggate1 /mnt
gune:/etc#48: cd /mnt/
gune:/mnt#49: l
.snap
gune:/mnt#50: dd if=/dev/null of=testfile bs=4k
0+0 records in
0+0 records out
0 bytes transferred in 0.000090 secs (0 bytes/sec)
gune:/mnt#51: dd if=/dev/zero of=testfile bs=4k
g_vfs_done():ggate1[WRITE(offset=6815744, length=131072)]error = 5
g_vfs_done():ggate1[WRITE(offset=6946816, length=131072)]error = 5
g_vfs_done():ggate1[WRITE(offset=7077888, length=131072)]error = 5
g_vfs_done():ggate1[WRITE(offset=7208960, length=131072)]error = 5
g_vfs_done():ggate1[WRITE(offset=7340032, length=131072)]error = 5
g_vfs_done():ggate1[WRITE(offset=98304, length=16384)]error = 5
panic: softdep_move_dependencies: need merge code
Uptime: 6h59m0s
Cannot dump. No dump device defined.
Automatic reboot in 15 seconds - press a key on the console to abort
Unfortunately I have only this production machine...
Thanks,
-Harry
I don't see how they could be related. I've committed a fix for the
Areca problem.
Scott
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
