6.2-st panic w/ ggate [Was: Re: kernel panic on 6.2-RC2 with GENERIC.]

[Scott Long]

Harald Schmalzbauer wrote:
> Am Sun, 07 Jan 2007 19:58:23 -0800
> schrieb Scott Long <scottl at samsco.org>:
> 
> [...]
>>>> 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