decoded problem in 2.4.22-pre10

One more thing. VMware creates file in /tmp, unlinks it, and then file gradually expands as VM is initialized, so it grews from 0 to your guest memory size + videoram size + ~5MB, while at same time all portions of that file are MAP_SHARED to several processes.

And at exit VMware does ftruncate(xxx,0) to throw away unneeded data, preventing them from hitting disk on subsequent (f)sync(), and this ftruncate() happens while other processes which have mmapped file are doing munmap or exit, finding dirty pages which have no underlying storage anymore during cleanup...

Both these operations were observed to cause problems in the past -
- on startup long ago reiserfs had problems with grewing unlinked files, on shutdown kernel's mm raced with ftruncate. Both these problems are currently fixed, but maybe some other race appeared somewhere? Best regards, Petr Vandrovec

I can tell you this for sure: I don't need to start the app, only loading the modules with their usual script is enough to shoot the box during heavy network load.

At the moment I only have a partly decoded oops at hand where all the vmware-modules symbols are missing (network action is Gig btw):

ksymoops 2.4.8 on i686 2.4.22-pre10. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.22-pre10/ (default) -m /boot/System.map-2.4.22-pre10 (default)

Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options.

Unable to handle kernel paging request at virtual address 80f00064
c01d428b
*pde = 00000000   
Oops: 0000
CPU:    1
EIP:    0010:[<c01d428b>]    Tainted: PF  

Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax: 00000642 ebx: 00010000 ecx: 275da012 edx: 00000000
esi: 80f00000 edi: 00000090 ebp: f5dd5200 esp: f5603cb8
ds: 0018 es: 0018 ss: 0018
Process nfsd (pid: 2049, stackpage=f5603000)

Stack: c34e3d60 00010000 00000090 007c3758 000003be c34e3da0 000003ba 00000001
       00000291 007c3690 00010000 00000040 c34e3d60 00000292 c34e3c00 c01d457e
       c34e3d60 0000003f 00000001 c34e3cc0 c34e3c00 c034ffdc c034ffc0 c02539d2
Call Trace:    [<c01d457e>] [<c02539d2>] [<c01222d6>] [<c0109508>] [<c010c048>]
  [<c0130018>] [<c0138d70>] [<c0130c86>] [<c0133d4a>] [<c013431a>] [<f8c92419>]
  [<f8c98a3a>] [<f8c9f1fc>] [<f8c8d699>] [<f8c72938>] [<f8c9f1fc>] [<f8c9ea38>]
  [<f8c9ea58>] [<f8c8d411>] [<c010592e>] [<f8c8d210>]
Code: 8b 5e 64 85 db 0f 85 48 02 00 00 8b 44 24 18 8b 8e 88 00 00

Trace; c01d457e <tg3_poll+8e/150>
Trace; c02539d2 <net_rx_action+e2/160>
Trace; c01222d6 <do_softirq+76/e0>
Trace; c0109508 <do_IRQ+d8/f0>
Trace; c010c048 <call_do_IRQ+5/d>
Trace; c0130018 <.text.lock.mmap+b7/cf> Trace; c0138d70 <lru_cache_add+10/70>
Trace; c0130c86 <add_to_page_cache_unique+56/90> Trace; c0133d4a <do_generic_file_write+1ba/4b0> Trace; c013431a <generic_file_write+8a/150> Trace; f8c92419 <[nfsd]nfsd_procedures3+319/320> Trace; f8c98a3a <.data.end+65db/????>
Trace; f8c9f1fc <END_OF_CODE+cd9d/????> Trace; f8c8d699 <[nfsd]nfs3svc_decode_readargs+a9/100> Trace; f8c72938 <[lockd]nlmclnt_lookup_host+18/30> Trace; f8c9f1fc <END_OF_CODE+cd9d/????> Trace; f8c9ea38 <END_OF_CODE+c5d9/????> Trace; f8c9ea58 <END_OF_CODE+c5f9/????> Trace; f8c8d411 <[nfsd]nfs3svc_decode_sattrargs+c1/f0> Trace; c010592e <arch_kernel_thread+2e/40> Trace; f8c8d210 <[nfsd]encode_wcc_data+50/f0>

Code; c01d428b <tg3_rx+14b/3b0>
00000000 <_EIP>:
Code; c01d428b <tg3_rx+14b/3b0> <=====
0: 8b 5e 64 mov 0x64(%esi),%ebx <=====
Code; c01d428e <tg3_rx+14e/3b0>
3: 85 db test %ebx,%ebx
Code; c01d4290 <tg3_rx+150/3b0>
5: 0f 85 48 02 00 00 jne 253 <_EIP+0x253>
Code; c01d4296 <tg3_rx+156/3b0>
b: 8b 44 24 18 mov 0x18(%esp,1),%eax
Code; c01d429a <tg3_rx+15a/3b0>
f: 8b 8e 88 00 00 00 mov 0x88(%esi),%ecx

<0>Kernel panic: Aiee, killing interrupt handler!

1 warning issued. Results may not be reliable.

Regards,
Stephan