Fatal double fault while copy to NFS filesystems

[Alex Keda]

Kostik Belousov пишет:
> On Fri, Jul 06, 2007 at 10:23:55PM +0400, Alex Keda wrote:
>   
>> Kostik Belousov пишет:
>>     
>>> On Fri, Jul 06, 2007 at 07:07:00PM +0400, Alex Keda wrote:
>>>  
>>>       
>>>> When I copy files to NFS on another host kernel crash:
>>>> Fatal double fault:
>>>> eip = 0xc07e9e29
>>>> esp = 0xe31a3000
>>>> ebp = 0xe31a3000
>>>> cpuid = 1; apic id = 01
>>>> panic: double fault
>>>> cpuid = 1
>>>> =======================
>>>> before this, I see on /var/log/messages
>>>> nve0: device timeout
>>>> =======================
>>>> how repeat problem:
>>>> ussr# df -h
>>>> Filesystem     Size    Used   Avail Capacity  Mounted on
>>>> /dev/ad0s1a     72G    6.1G     60G     9%    /
>>>> devfs          1.0K    1.0K      0B   100%    /dev
>>>> ussr# dd if=/dev/zero of=file_20mb bs=1m count=20
>>>> ussr# mount 192.168.254.254:/shares /mnt/
>>>> ussr# df -h
>>>> Filesystem                 Size    Used   Avail Capacity  Mounted on
>>>> /dev/ad0s1a                 72G    6.1G     60G     9%    /
>>>> devfs                      1.0K    1.0K      0B   100%    /dev
>>>> 192.168.254.254:/shares    271G    179G     89G    67%    /mnt
>>>> ussr# cp file_20mb /mnt/
>>>> then, after 3-5 second I see "device timeout", and later, after 5-7 
>>>> seconds - system crash
>>>> =====================
>>>> another information - this problem appearance after I upgrade remote 
>>>> machine (6.2-RELEASE-p5), I change CPU from Celeron 466 to PIII 800.
>>>> interface on remote machine - 3com509b
>>>> if I slow copy to remote machine (~100kb/s - 10% interface usage) - all 
>>>> good. System not crash...
>>>> if I copy from remote machine - all good - system not crash...
>>>> on logs on remote machine - all clean.
>>>> =====================
>>>> 3 days ago I upgrade my system to 6.2-RELEASE-p5, but - problem exists...
>>>>    
>>>>         
>>> Double fault issue might be the problem that is fixed in CURRENT/RELENG_6.
>>> To confirm this, ddb backtrace after the panic will be helpful. You will
>>> need to compile DDB into the kernel, obtain DDB prompt after the panic
>>> and issue "bt" command.
>>>  
>>>       
>> Fatal double fault:
>> eip = 0xc07e8bd9
>> esp = 0xe3793000
>> ebp = 0xe3793020
>> cpuid = 0; apic id = 00
>> panic:double fault
>> cpuid = 0
>> KDB: enter: panic
>> [thread pid 25 tid 100019]
>> Stopped at kdb_enter+0x2b:nop
>>
>> Tracing pid 25 tid 100019 td 0xc527b600
>> kdb_enter(c090f266) at kdb_enter+0x2b
>> panic(c092d4c9,c092d671,0,0,0,...) at panic+0x127
>> dblfault_handler() at dblfault_handler+0x7a
>> --- trap 0x17, eip = 0xc07e88bd9, esp = 0xe3793000, ebp = 0xe3793020 ---
>> uma_zfree_arg(c1857960,c5718900,0) at uma_zfree_arg+0x21
>> m_freem(c5718900,e54ad000,e52ac65c,c543e810,1,...) at m_freem+0x2e
>> nve_ospackettx(c543e800,e52ac65c,1,e54ad000,0,...) at nve_ospackettx+0x57
>> UpdateTransmitDescRingData() at UpdateTransmitDescRingData+0xd3
>>     
> Is this the full trace ? It seems to be unlikely that this is a problem I
> thought of.
>   
Yes. this - output 'bt' command:

Tracing pid 25 tid 100019 td 0xc527b600
kdb_enter(c090f266) at kdb_enter+0x2b
panic(c092d4c9,c092d671,0,0,0,...) at panic+0x127
dblfault_handler() at dblfault_handler+0x7a
--- trap 0x17, eip = 0xc07e88bd9, esp = 0xe3793000, ebp = 0xe3793020 ---
uma_zfree_arg(c1857960,c5718900,0) at uma_zfree_arg+0x21
m_freem(c5718900,e54ad000,e52ac65c,c543e810,1,...) at m_freem+0x2e
nve_ospackettx(c543e800,e52ac65c,1,e54ad000,0,...) at nve_ospackettx+0x57
UpdateTransmitDescRingData() at UpdateTransmitDescRingData+0xd3

============
but there I see path to solution my problem (nve_ospackettx - i think - 
driver problem?) - tomorrow I insert fxp card and test again.