Opened 14 years ago
Closed 12 years ago
#8431 closed defect (fixed)
page allocation failure
Reported by: | BARTHES | Owned by: | |
---|---|---|---|
Component: | other | Version: | VirtualBox 4.0.4 |
Keywords: | Cc: | ||
Guest type: | Windows | Host type: | Linux |
Description (last modified by )
Hello everybody,
here is my host : ubuntu server 10.04LTS AMD64 - 1 XEONL5520 -MB SUPERMICRO X8ST3-F - 18GB of RAM)
I run virtualbox 4.04
From time to time, i've got a "page allocation failure". I use bonding in my network.
Is there a solution or a patch ?
Thanks in advance.
Chris.
Feb 25 12:39:51 hercules kernel: [423948.757566] VBoxHeadless: page allocation failure. order:4, mode:0x4020 Feb 25 12:39:51 hercules kernel: [423948.757570] Pid: 24533, comm: VBoxHeadless Not tainted 2.6.32-28-server #55-Ubuntu Feb 25 12:39:51 hercules kernel: [423948.757572] Call Trace: Feb 25 12:39:51 hercules kernel: [423948.757574] <IRQ> [<ffffffff810fa099>] __alloc_pages_slowpath+0x4a9/0x590 Feb 25 12:39:51 hercules kernel: [423948.757585] [<ffffffff810fa2f1>] __alloc_pages_nodemask+0x171/0x180 Feb 25 12:39:51 hercules kernel: [423948.757590] [<ffffffff81132732>] kmalloc_large_node+0x62/0xb0 Feb 25 12:39:51 hercules kernel: [423948.757593] [<ffffffff81136d49>] __kmalloc_node_track_caller+0x109/0x160 Feb 25 12:39:51 hercules kernel: [423948.757598] [<ffffffff8146ab86>] ? skb_copy+0x36/0xa0 Feb 25 12:39:51 hercules kernel: [423948.757600] [<ffffffff81469cc0>] __alloc_skb+0x80/0x190 Feb 25 12:39:51 hercules kernel: [423948.757602] [<ffffffff8146ab86>] skb_copy+0x36/0xa0 Feb 25 12:39:51 hercules kernel: [423948.757613] [<ffffffffa01a9d84>] vboxNetFltLinuxPacketHandler+0x64/0xd0 [vboxnetflt] Feb 25 12:39:51 hercules kernel: [423948.757616] [<ffffffff81474539>] dev_queue_xmit_nit+0x129/0x190 Feb 25 12:39:51 hercules kernel: [423948.757618] [<ffffffff814748af>] dev_hard_start_xmit+0x4f/0x1e0 Feb 25 12:39:51 hercules kernel: [423948.757621] [<ffffffff81477ad6>] dev_queue_xmit+0x3d6/0x4d0 Feb 25 12:39:51 hercules kernel: [423948.757625] [<ffffffff814a8f9c>] ip_finish_output+0x13c/0x310 Feb 25 12:39:51 hercules kernel: [423948.757627] [<ffffffff814a9228>] ip_output+0xb8/0xc0 Feb 25 12:39:51 hercules kernel: [423948.757630] [<ffffffff814a818f>] ? __ip_local_out+0x9f/0xb0 Feb 25 12:39:51 hercules kernel: [423948.757632] [<ffffffff814a81c5>] ip_local_out+0x25/0x30 Feb 25 12:39:51 hercules kernel: [423948.757635] [<ffffffff814a8a00>] ip_queue_xmit+0x190/0x420 Feb 25 12:39:51 hercules kernel: [423948.757638] [<ffffffff814bcfa3>] ? tcp_established_options+0x43/0xd0 Feb 25 12:39:51 hercules kernel: [423948.757640] [<ffffffff814bd07b>] ? tcp_current_mss+0x4b/0x70 Feb 25 12:39:51 hercules kernel: [423948.757643] [<ffffffff814bd751>] tcp_transmit_skb+0x3f1/0x790 Feb 25 12:39:51 hercules kernel: [423948.757645] [<ffffffff814c0063>] tcp_write_xmit+0x1d3/0x4b0 Feb 25 12:39:51 hercules kernel: [423948.757648] [<ffffffff814c04d0>] __tcp_push_pending_frames+0x30/0xa0 Feb 25 12:39:51 hercules kernel: [423948.757650] [<ffffffff814b8913>] tcp_data_snd_check+0x33/0x100 Feb 25 12:39:51 hercules kernel: [423948.757653] [<ffffffff814bc393>] tcp_rcv_established+0x583/0x730 Feb 25 12:39:51 hercules kernel: [423948.757655] [<ffffffff814c3d13>] tcp_v4_do_rcv+0xf3/0x160 Feb 25 12:39:51 hercules kernel: [423948.757658] [<ffffffff814c5465>] tcp_v4_rcv+0x5b5/0x7e0 Feb 25 12:39:51 hercules kernel: [423948.757660] [<ffffffff814a3270>] ? ip_local_deliver_finish+0x0/0x2d0 Feb 25 12:39:51 hercules kernel: [423948.757664] [<ffffffff8149ad14>] ? nf_hook_slow+0x74/0x100 Feb 25 12:39:51 hercules kernel: [423948.757666] [<ffffffff814a3270>] ? ip_local_deliver_finish+0x0/0x2d0 Feb 25 12:39:51 hercules kernel: [423948.757669] [<ffffffff814a334d>] ip_local_deliver_finish+0xdd/0x2d0 Feb 25 12:39:51 hercules kernel: [423948.757671] [<ffffffff814a35d0>] ip_local_deliver+0x90/0xa0 Feb 25 12:39:51 hercules kernel: [423948.757674] [<ffffffff814a2a8d>] ip_rcv_finish+0x12d/0x440 Feb 25 12:39:51 hercules kernel: [423948.757678] [<ffffffff8138c08a>] ? scsi_next_command+0x4a/0x60 Feb 25 12:39:51 hercules kernel: [423948.757680] [<ffffffff814a3015>] ip_rcv+0x275/0x360 Feb 25 12:39:51 hercules kernel: [423948.757684] [<ffffffffa01a9dad>] ? vboxNetFltLinuxPacketHandler+0x8d/0xd0 [vboxnetflt] Feb 25 12:39:51 hercules kernel: [423948.757687] [<ffffffff8147377a>] netif_receive_skb+0x38a/0x5d0 Feb 25 12:39:51 hercules kernel: [423948.757689] [<ffffffff81473a43>] process_backlog+0x83/0xe0 Feb 25 12:39:51 hercules kernel: [423948.757691] [<ffffffff8147427f>] net_rx_action+0x10f/0x250 Feb 25 12:39:51 hercules kernel: [423948.757695] [<ffffffff8106d637>] __do_softirq+0xb7/0x1e0 Feb 25 12:39:51 hercules kernel: [423948.757699] [<ffffffff810132ec>] ? call_softirq+0x1c/0x30 Feb 25 12:39:51 hercules kernel: [423948.757701] [<ffffffff810132ec>] call_softirq+0x1c/0x30 Feb 25 12:39:51 hercules kernel: [423948.757702] <EOI> [<ffffffff81014cb5>] do_softirq+0x65/0xa0 Feb 25 12:39:51 hercules kernel: [423948.757706] [<ffffffff81477ea8>] netif_rx_ni+0x28/0x30 Feb 25 12:39:51 hercules kernel: [423948.757710] [<ffffffffa01a8fc2>] vboxNetFltPortOsXmit+0xb2/0xd0 [vboxnetflt] Feb 25 12:39:51 hercules kernel: [423948.757713] [<ffffffffa01aa629>] vboxNetFltPortXmit+0x69/0x1d0 [vboxnetflt] Feb 25 12:39:51 hercules kernel: [423948.757724] [<ffffffffa01f23d6>] ? g_abExecMemory+0x26e96/0x180000 [vboxdrv] Feb 25 12:39:51 hercules kernel: [423948.757728] [<ffffffff8105a669>] ? update_curr+0x199/0x1e0 Feb 25 12:39:51 hercules kernel: [423948.757736] [<ffffffffa0216779>] g_abExecMemory+0x4b239/0x180000 [vboxdrv] Feb 25 12:39:51 hercules kernel: [423948.757740] [<ffffffff8155b4ef>] ? _spin_lock_irqsave+0x2f/0x40 Feb 25 12:39:51 hercules kernel: [423948.757750] [<ffffffffa01bd0d5>] ? RTSpinlockReleaseNoInts+0x15/0x20 [vboxdrv] Feb 25 12:39:51 hercules kernel: [423948.757758] [<ffffffffa02155b8>] ? g_abExecMemory+0x4a078/0x180000 [vboxdrv] Feb 25 12:39:51 hercules kernel: [423948.757766] [<ffffffffa021ab85>] g_abExecMemory+0x4f645/0x180000 [vboxdrv] Feb 25 12:39:51 hercules kernel: [423948.757774] [<ffffffffa01b1d60>] ? SUPR0ObjAddRefEx+0x130/0x240 [vboxdrv] Feb 25 12:39:51 hercules kernel: [423948.757783] [<ffffffffa01c47cc>] ? RTHandleTableLookupWithCtx+0x9c/0x130 [vboxdrv] Feb 25 12:39:51 hercules kernel: [423948.757792] [<ffffffffa021b8c9>] g_abExecMemory+0x50389/0x180000 [vboxdrv] Feb 25 12:39:51 hercules kernel: [423948.757800] [<ffffffffa02445cc>] g_abExecMemory+0x7908c/0x180000 [vboxdrv] Feb 25 12:39:51 hercules kernel: [423948.757808] [<ffffffffa02455b0>] g_abExecMemory+0x7a070/0x180000 [vboxdrv] Feb 25 12:39:51 hercules kernel: [423948.757815] [<ffffffffa024671f>] g_abExecMemory+0x7b1df/0x180000 [vboxdrv] Feb 25 12:39:51 hercules kernel: [423948.757823] [<ffffffffa01e98c1>] g_abExecMemory+0x1e381/0x180000 [vboxdrv] Feb 25 12:39:51 hercules kernel: [423948.757838] [<ffffffffa01dc601>] g_abExecMemory+0x110c1/0x180000 [vboxdrv] Feb 25 12:39:51 hercules kernel: [423948.757846] [<ffffffffa02127f9>] ? g_abExecMemory+0x472b9/0x180000 [vboxdrv] Feb 25 12:39:51 hercules kernel: [423948.757854] [<ffffffffa01dac00>] ? g_abExecMemory+0xf6c0/0x180000 [vboxdrv] Feb 25 12:39:51 hercules kernel: [423948.757862] [<ffffffffa01d994e>] ? g_abExecMemory+0xe40e/0x180000 [vboxdrv] Feb 25 12:39:51 hercules kernel: [423948.757870] [<ffffffffa01d4e0d>] g_abExecMemory+0x98cd/0x180000 [vboxdrv] Feb 25 12:39:51 hercules kernel: [423948.757878] [<ffffffffa0214db7>] g_abExecMemory+0x49877/0x180000 [vboxdrv] Feb 25 12:39:51 hercules kernel: [423948.757886] [<ffffffffa01e0773>] g_abExecMemory+0x15233/0x180000 [vboxdrv] Feb 25 12:39:51 hercules kernel: [423948.757894] [<ffffffffa01b096a>] supdrvIOCtlFast+0x7a/0x80 [vboxdrv] Feb 25 12:39:51 hercules kernel: [423948.757901] [<ffffffffa01b02ec>] VBoxDrvLinuxIOCtl+0x4c/0x1d0 [vboxdrv] Feb 25 12:39:51 hercules kernel: [423948.757904] [<ffffffff81052a70>] ? __dequeue_entity+0x30/0x50 Feb 25 12:39:51 hercules kernel: [423948.757908] [<ffffffff8101078c>] ? __switch_to+0x1ac/0x320 Feb 25 12:39:51 hercules kernel: [423948.757913] [<ffffffff81154472>] vfs_ioctl+0x22/0xa0 Feb 25 12:39:51 hercules kernel: [423948.757916] [<ffffffff815591e8>] ? thread_return+0x48/0x420 Feb 25 12:39:51 hercules kernel: [423948.757919] [<ffffffff81154611>] do_vfs_ioctl+0x81/0x410 Feb 25 12:39:51 hercules kernel: [423948.757922] [<ffffffff81154a21>] sys_ioctl+0x81/0xa0 Feb 25 12:39:51 hercules kernel: [423948.757924] [<ffffffff810121b2>] system_call_fastpath+0x16/0x1b
Attachments (4)
Change History (11)
comment:1 by , 14 years ago
comment:3 by , 14 years ago
I have 4 virtual machines running. I haven't noticed anything suspicious in the logs, nevertheless I included them below as m<num>.log.
When I have over 1GB RAM free then, despite of this error, everything seems to be running fine. (This is how I now operate)
I used to run 6 VMs 2 months ago (0.4GB RAM free) and then after such error I would get system freeze that required turning off the power.
I suspect it might be some kind of memory management fault in the kernel (?).
comment:4 by , 14 years ago
This is a log excerpt of a machine that is currently not running, but it seems interesting:
00:02:07.274 AUTH: Access granted. 00:02:07.288 VRDP: Enabling upstream audio. 00:02:07.288 VBVA: VRDP acceleration has been requested. 00:02:07.930 VMMDev::SetVideoModeHint: got a video mode hint (2048x1152x0) at 0 00:02:07.930 VRDP: SunFlsh disabled. 00:02:10.771 Guest Log: VBOXNP: DLL loaded. 00:02:12.261 Guest Log: VBoxTray: 3.2.12 r68302 started. 00:02:12.307 Audio: set_record_source ars=4 als=4 (not implemented) 00:02:12.332 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=00007f93647b3000 w=2048 h=1152 bpp=32 cbLine=0x2000, flags=0x1 00:02:12.368 Starting host clipboard service 00:02:12.368 ClipConstructX11: X11 DISPLAY variable not set -- disabling shared clipboard 00:02:12.410 Guest Log: VBoxDisp[0]: VBVA enabled 00:02:12.410 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=00007f93647b3000 w=2048 h=1152 bpp=32 cbLine=0x2000, flags=0x1 00:02:12.720 Guest Additions capability report: (0x5) seamless: yes, hostWindowMapping: no, graphics: yes 00:02:13.800 RTC: period=0x40 (64) 512 Hz 00:04:40.513 Audio: set_record_source ars=4 als=4 (not implemented) 00:04:40.538 RTC: period=0x20 (32) 1024 Hz 00:06:32.908 Audio: set_record_source ars=4 als=4 (not implemented) 00:06:44.905 Audio: set_record_source ars=4 als=4 (not implemented) 00:07:32.718 Audio: set_record_source ars=4 als=4 (not implemented) 00:09:48.775 PIIX3 ATA: execution time for ATA command 0xca was 10 seconds 00:10:11.295 PIIX3 ATA: Ctl#0: RESET, DevSel=0 AIOIf=0 CmdIf0=0xca (9334874 usec ago) CmdIf1=0x00 (-1 usec ago) 00:10:12.664 PIIX3 ATA: execution time for ATA command 0xca was 10 seconds 00:10:12.664 PIIX3 ATA: Ctl#0: finished processing RESET 00:10:16.490 ERROR [COM]: aRC=VBOX_E_IPRT_ERROR (0x80bb0005) aIID={05044a52-7811-4f00-ae3a-0ab7ff707b10} aComponent={Mouse} aText={Could not send the mouse event to the virtual mouse (VERR_PDM_NO_QUEUE_ITEMS)}, preserve=false 00:10:30.970 PIIX3 ATA: Ctl#0: RESET, DevSel=0 AIOIf=0 CmdIf0=0xc5 (11859081 usec ago) CmdIf1=0x00 (-1 usec ago) 00:10:31.321 PIIX3 ATA: Ctl#0: finished processing RESET 00:10:31.321 PIIX3 ATA: execution time for ATA command 0xc5 was 12 seconds 00:11:20.700 PIIX3 ATA: Ctl#0: RESET, DevSel=0 AIOIf=0 CmdIf0=0xca (11004869 usec ago) CmdIf1=0x00 (-1 usec ago) 00:11:20.752 PIIX3 ATA: execution time for ATA command 0xca was 11 seconds 00:11:20.752 PIIX3 ATA: Ctl#0: finished processing RESET 00:16:46.761 TM: Giving up catch-up attempt at a 60 043 357 940 ns lag; new total: 60 043 357 940 ns 00:18:11.834 TM: Giving up catch-up attempt at a 60 120 512 810 ns lag; new total: 120 163 870 750 ns 00:20:02.279 TM: Giving up catch-up attempt at a 60 000 721 656 ns lag; new total: 180 164 592 406 ns 00:21:56.197 TM: Giving up catch-up attempt at a 60 001 628 164 ns lag; new total: 240 166 220 570 ns 00:23:53.747 Guest Log: VBOXNP: DLL loaded. 00:24:02.120 TM: Giving up catch-up attempt at a 60 033 871 603 ns lag; new total: 300 200 092 173 ns
For all those logs to make sense I would have to clean them all, run all those machines and wait for an error.
But the problem is that it occurs randomly. I work on them and waiting for a total freeze while I won't be there to restart it is rather not possible now...
comment:5 by , 13 years ago
I have the same problem, using RHEL6 host, VirtualBox 4.1.2, and WindowsXP guest. The call trace is different each time, but the top of the call trace is identical:
kernel: [<ffffffff8112013e>] ? alloc_pages_nodemask+0x71e/0x8b0 kernel: [<ffffffff811599f2>] ? kmem_getpages+0x62/0x170 kernel: [<ffffffff8115a60a>] ? fallback_alloc+0x1ba/0x270 kernel: [<ffffffff8115a05f>] ? cache_grow+0x2cf/0x320 kernel: [<ffffffff8115a389>] ? cache_alloc_node+0x99/0x160 kernel: [<ffffffff8141473a>] ? alloc_skb+0x7a/0x180 kernel: [<ffffffff8115b22f>] ? kmem_cache_alloc_node_notrace+0x6f/0x130 kernel: [<ffffffff8115b46b>] ? kmalloc_node+0x7b/0x100 kernel: [<ffffffff8141473a>] ? alloc_skb+0x7a/0x180 kernel: [<ffffffff814164e6>] ? skb_copy+0x36/0xa0 kernel: [<ffffffffa023e3a8>] ? vboxNetFltLinuxPacketHandler+0x98/0x5b0 [vboxnetflt]
comment:6 by , 13 years ago
I have the same problem, using RHEL6 host, VirtualBox 4.1.2, and WindowsXP guest. The call trace is different each time, but the top of the call trace is identical:
kernel: [<ffffffff8112013e>] ? __alloc_pages_nodemask+0x71e/0x8b0 kernel: [<ffffffff811599f2>] ? kmem_getpages+0x62/0x170 kernel: [<ffffffff8115a60a>] ? fallback_alloc+0x1ba/0x270 kernel: [<ffffffff8115a05f>] ? cache_grow+0x2cf/0x320 kernel: [<ffffffff8115a389>] ? ____cache_alloc_node+0x99/0x160 kernel: [<ffffffff8141473a>] ? __alloc_skb+0x7a/0x180 kernel: [<ffffffff8115b22f>] ? kmem_cache_alloc_node_notrace+0x6f/0x130 kernel: [<ffffffff8115b46b>] ? __kmalloc_node+0x7b/0x100 kernel: [<ffffffff8141473a>] ? __alloc_skb+0x7a/0x180 kernel: [<ffffffff814164e6>] ? skb_copy+0x36/0xa0 kernel: [<ffffffffa023e3a8>] ? vboxNetFltLinuxPacketHandler+0x98/0x5b0 [vboxnetflt]
(re-pasting here, since the last one was badly formatted)
comment:7 by , 12 years ago
Description: | modified (diff) |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Please reopen if still relevant with VBox 4.2.10.
Hello
Host: Ubuntu 10.04.2 LTS AMD64 (kernel: 2.6.32-29-generic) - Core i3 530 - 6GB RAM
VirtualBox 4.0.4
Error: page allocation failure. order:9, mode:0x344d2
Same top and bottom of the call trace as in the case reported by cbarthes35.
I keep getting this error at random times.
Inner part of the call trace varies from case to case.
Example log below: