Setting to NEEDINFO since I fear I did not provide enough information and this should remind me to send them...

Please try again without the WLAN card. There's an open bug for the
ipw2200 driver in 10.0 (see bug #133513) - and this problem may still
be present in the current wireless-tools.

I'm using an the atheros driver - and this worked fine with 10.0 out of the box.

Ok, I'll try to test with ethernet as well...

It's an OOPS in the ath driver, so I'm not testing with ethernet right now.

OOPS is:

Oops: 0000 [#1]

Modules linked in: deflate zlib_deflate twofish serpent blowfish sha256 crypto_null aes sha1 xfrm_user xfrm4_tunnel ipcomp esp4 ah4 af_key cpufreq_ondemand cpufreq_userspace cpufreq_powersave i915 drm speedstep_centrino freq_table ipv6 af_packet snd_pcm_oss edd snd_mixer_oss snd_seq snd_seq_device ibm_acpi button battery ac pcmcia wlan_scan_sta firmware_class ath_pci ath_rate_sample wlan ath_hal e1000 yenta_socket rsrc_nonstatic pcmcia_core snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc hw_random uhci_hcd ehci_hcd shpchp usbcore i2c_i801 intel_agp pci_hotplug agpgart i2c_core tsdev generic i8xx_tco ide_cd cdrom parport_pc lp parport ext3 jbd fan thermal processor piix ide_disk ide_core

CPU:    0

EIP:    0060:[<f9309f7a>]    Tainted: P     U VLI

EFLAGS: 00010046   (2.6.15-20060109222015-default) 

EIP is at ath_tx_uapsdqueue+0x100/0x22c [ath_pci]

eax: 00000000   ebx: e64d4000   ecx: c1b6c7e0   edx: e64d4000

esi: 00000000   edi: c1b6c7e0   ebp: f7cde260   esp: f13bbb0c

ds: 007b   es: 007b   ss: 0068

Process ping (pid: 5211, threadinfo=f13ba000 task=f0fbc580)

Stack: e64d4000 00000000 f7cde260 00000000 f930ac0f 00000002 00000000 00000000 

       c1b6c7e0 e64d4000 f7cde000 f7e30800 f9376039 f7e30840 00000000 f7e30870 

       00000000 f934d32c 00000022 e64d4000 000000a8 00000000 c1a0d260 f7cde260 

Call Trace:

 [<f930ac0f>] ath_tx_start+0xb69/0xd9e [ath_pci]

 [<f9376039>] ieee80211_encap+0x350/0xcf7 [wlan]

 [<f934d32c>] zz00b7177d+0x0/0x134 [ath_hal]

 [<f9305e5b>] ath_hardstart+0x7a2/0x892 [ath_pci]

 [<c0232507>] qdisc_restart+0xa7/0x13b

 [<c0226008>] dev_queue_xmit+0xfe/0x1e3

 [<f93753e1>] ieee80211_hardstart+0x1c5/0x201 [wlan]

 [<c0226060>] dev_queue_xmit+0x156/0x1e3

 [<c022a71e>] neigh_resolve_output+0xe1/0x125

 [<c0240912>] ip_output+0x1c7/0x20e

 [<c024256f>] ip_push_pending_frames+0x2d0/0x382

 [<c0256810>] raw_sendmsg+0x30c/0x3c9

 [<c025d437>] inet_sendmsg+0x35/0x3f

 [<c021e20b>] sock_sendmsg+0xca/0xe4

 [<c0220f9d>] lock_sock+0x8/0x30

 [<c011504a>] __wake_up_common+0x2e/0x4d

 [<c01260c1>] autoremove_wake_function+0x0/0x2d

 [<c01ebe69>] n_tty_receive_buf+0x9f2/0xa21

 [<c01a4c19>] copy_from_user+0x36/0x65

 [<c01a4c19>] copy_from_user+0x36/0x65

 [<c0223812>] verify_iovec+0x3e/0x6d

 [<c021f6fa>] sys_sendmsg+0x188/0x1e1

 [<c0135d3a>] buffered_rmqueue+0x157/0x187

 [<c0135d3a>] buffered_rmqueue+0x157/0x187

 [<c0135e7a>] get_page_from_freelist+0x78/0x90

 [<c0135eea>] __alloc_pages+0x58/0x25b

 [<c013e886>] do_anonymous_page+0x12f/0x149

 [<c021fa8f>] sys_socketcall+0x187/0x1a2

 [<c0102a9b>] sysenter_past_esp+0x54/0x79

Code: 01 00 00 50 8b 47 14 ff 70 68 68 60 e7 30 f9 68 98 fd 30 f9 e9 31 01 00 00 39 83 d8 02 00 00 0f 85 cf 00 00 00 8b b3 c4 02 00 00 <8b> 06 89 83 c4 02 00 00 85 c0 75 0c 8d 83 c4 02 00 00 89 83 c8 

 <0>Kernel panic - not syncing: Fatal exception in interrupt

 

Created attachment 62535 [details]
console log

My, those wireless drivers aren't in very good shape at the moment :-(
See also bug #141612

Some obervations from my side:
I also see this crash as soon as some traffic is sent over the VPN tunnel. Tunnel setup itself is working.
I bet it is a bug in the madwifi-ng driver. 10.0 is shipped with madwifi-old driver. There VPN is working. As soon as I compile the madwifi-ng modules on a 10.0 (with 2.6.13-15.7) system crashes when the first packet is sent via the VPN tunnel.
So only changing the atheros driver triggers the bug.

BTW: Bug is know to madwifi developers. http://madwifi.org/ticket/196

Crash described in Comment #7 is fixed in madwifi-ng revision r1396.

Latest kernels should have madwifi-ng r1401. Can you confirm that the oops is gone?

This is fixed for me.