Re: [Xen-devel] Re: 2.6.38 x86_64 domU null pointer in xennet_alloc_rx_buffers

[retsyx <retsyx@xxxxxxxxx>]

Sorry about that.

Yes, for me it happens very consistently when the machine is configured as a 
PPTP server and a particular OS X client (over a transcontinental link) 
attempts to establish a VPN connection. The PPTP configuration is very simple. 
PPTP with the standard options delta these changes which I don't think are 
important but am including for completeness.

In pptpd-options, relative to the default config file:

require-mppe-128 is commented out.

Add options:
noipx
mtu 1490
mru 1490

chap-secrets is configured with the equivalent of:

username * password *

The OS X client is configured to connect with PPTP, the username/password and 
no encryption. I have two OS X clients, one is across the Peninsula from the 
machine in question, the second is in the Middle East. The local client has 
never caused a panic when connecting while the remote client (in the ME) will 
almost always cause a panic.

One item which appears to have some effect on the frequency of panics and their 
nature is the vm.min_free_kbytes sysctl. When left to its own devices on this 
particular machine it defaults to the 2900 region and the panic detailed 
earlier happens every time. When vm.min_free_kbytes is manually set to 16384, 
it can take a couple tries before the machine panics and the trace of the panic 
seems to vary.

Thanks.

On May 24, 2011, at 8:43 AM, Konrad Rzeszutek Wilk wrote:

> On Mon, May 23, 2011 at 09:19:54AM -0700, retsyx wrote:
>> Here is a similar kernel panic on a 32-bit system. I can get this to
>> consistently happen when the panicked machine is being used a PPTP server.
>> The panic is triggered instantly when a particular PPTP client attempts to
>> establish a tunnel (encryption is off BTW):
> 
> Great.
> 
> Do you have a step-by-step instruction on how to reproduce this failure?
> The more details the better.
> 
>> 
>> 
>> BUG: unable to handle kernel NULL pointer dereference at   (null)
>> IP: [<c0193144>] page_address+0x14/0xe0
>> *pdpt = 000000001eaf3007 *pde = 0000000000000000 
>> Oops: 0000 [#1] SMP 
>> last sysfs file: /sys/kernel/uevent_seqnum
>> Modules linked in:
>> 
>> Pid: 0, comm: swapper Not tainted 2.6.38.3-linode32 #1  
>> EIP: 0061:[<c0193144>] EFLAGS: 00010286 CPU: 0
>> EIP is at page_address+0x14/0xe0
>> EAX: 00000000 EBX: 00000000 ECX: 00000251 EDX: 00000250
>> ESI: 00000250 EDI: de6b7980 EBP: 20411000 ESP: df40feb4
>> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069
>> Process swapper (pid: 0, ti=df40e000 task=c079df20 task.ti=c0788000)
>> Stack:
>> deb58340 00000250 de6b7980 20411000 c049e742 00000000 000000d0 dee8a000
>> 00d02280 deb58be4 00000010 deb58000 deb59010 000000c0 deb58340 00000001
>> deb58340 de6af8d8 c049fcff 00000000 00000001 df40ff9c dfbba380 df40ff78
>> Call Trace:
>> [<c049e742>] ? xennet_alloc_rx_buffers+0x1c2/0x300
>> [<c049fcff>] ? xennet_poll+0x4df/0xc20
>> [<c04fc43a>] ? net_rx_action+0x9a/0x130
>> [<c01380ec>] ? __do_softirq+0x7c/0x130
>> [<c0138070>] ? __do_softirq+0x0/0x130
>> <IRQ> 
>> [<c0137fe5>] ? irq_exit+0x65/0x70
>> [<c043a03d>] ? xen_evtchn_do_upcall+0x1d/0x30
>> [<c0109487>] ? xen_do_upcall+0x7/0xc
>> [<c01013a7>] ? hypercall_page+0x3a7/0x1010
>> [<c0105b8f>] ? xen_safe_halt+0xf/0x20
>> [<c010f66f>] ? default_idle+0x2f/0x60
>> [<c0107ed2>] ? cpu_idle+0x42/0x70
>> [<c07ca8ac>] ? start_kernel+0x2da/0x2df
>> [<c07ca410>] ? unknown_bootoption+0x0/0x190
>> [<c07cdaa5>] ? xen_start_kernel+0x530/0x538
>> Code: 89 c2 b8 2c 1e 85 c0 e9 3f ff ff ff 0f 0b eb fe 8d b4 26 00 00 00 00
>> 83 ec 10 89 1c 24 89 c3 89 74 24 04 89 7c 24 08 89 6c 24 0c <8b> 00 c1 e8 1e
>> 69 c0 80 03 00 00 05 40 05 7c c0 2b 80 4c 03 00 
>> EIP: [<c0193144>] page_address+0x14/0xe0 SS:ESP 0069:df40feb4
>> CR2: 0000000000000000
>> ---[ end trace 19ddaabd0d19ad12 ]---
>> Kernel panic - not syncing: Fatal exception in interrupt
>> Pid: 0, comm: swapper Tainted: G      D     2.6.38.3-linode32 #1
>> Call Trace:
>> [<c063cfbf>] ? panic+0x57/0x13e
>> [<c010bec6>] ? oops_end+0x96/0xa0
>> [<c011e362>] ? no_context+0xc2/0x190
>> [<c011e58f>] ? bad_area_nosemaphore+0xf/0x20
>> [<c011e943>] ? do_page_fault+0x223/0x3e0
>> [<c0184325>] ? __alloc_pages_nodemask+0xf5/0x670
>> [<c011e720>] ? do_page_fault+0x0/0x3e0
>> [<c063fea6>] ? error_code+0x5a/0x60
>> [<c011e720>] ? do_page_fault+0x0/0x3e0
>> [<c0193144>] ? page_address+0x14/0xe0
>> [<c049e742>] ? xennet_alloc_rx_buffers+0x1c2/0x300
>> [<c049fcff>] ? xennet_poll+0x4df/0xc20
>> [<c04fc43a>] ? net_rx_action+0x9a/0x130
>> [<c01380ec>] ? __do_softirq+0x7c/0x130
>> [<c0138070>] ? __do_softirq+0x0/0x130
>> <IRQ>  [<c0137fe5>] ? irq_exit+0x65/0x70
>> [<c043a03d>] ? xen_evtchn_do_upcall+0x1d/0x30
>> [<c0109487>] ? xen_do_upcall+0x7/0xc
>> [<c01013a7>] ? hypercall_page+0x3a7/0x1010
>> [<c0105b8f>] ? xen_safe_halt+0xf/0x20
>> [<c010f66f>] ? default_idle+0x2f/0x60
>> [<c0107ed2>] ? cpu_idle+0x42/0x70
>> [<c07ca8ac>] ? start_kernel+0x2da/0x2df
>> [<c07ca410>] ? unknown_bootoption+0x0/0x190
>> [<c07cdaa5>] ? xen_start_kernel+0x530/0x538
>> 
>> 
>> --
>> View this message in context: 
>> http://xen.1045712.n5.nabble.com/2-6-38-x86-64-domU-null-pointer-in-xennet-alloc-rx-buffers-tp4298573p4419471.html
>> Sent from the Xen - Dev mailing list archive at Nabble.com.
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel