> On 03/01/2013 09:36 AM, Simon Matter wrote: >>> hi, >>> >>> By now most people would have seen or atleast have spotted the 6.3/cr/ >>> repos are populated and updates there announced to the cr-announce >>> list. >>> >>> 6.4 is a big release, lots of changes and lots of feedback about things >>> ( also, we found in our limited testing that there are some surprises >>> around the corners! ) >> >> I've updated some hosts on real hardware and vms on KVM. >> There were no big surprises but the following things showed up: >> >> 1) On a KVM server, using macvtap with SELinux enabled work now out of >> the >> box, with 6.3 it didn't. >> >> 2) This bug should now be fixed >> >> https://bugzilla.redhat.com/show_bug.cgi?id=713546 > > I can't see this one ^^ Ops, you're right it's also 'private' now. Don't remember how I came on the CC list which is why I can see it I guess. > >> however, instead of the one above I see new issues like described here >> >> https://bugzilla.redhat.com/show_bug.cgi?id=767127 > > > Is this with kernel-2.6.32-358.0.1.el6 or kernel-2.6.32-358.el6? > > >> >> and >> >> https://bugzilla.redhat.com/show_bug.cgi?id=770545 > > I can't see this one ^^ Yes, me too, that's why I was interested to know what it is. I'm running 2.6.32-358.0.1.el6.x86_64 and I see crap like this in my logs: Mar 1 17:21:16 archive01 kernel: swapper: page allocation failure. order:1, mode:0x20 Mar 1 17:21:16 archive01 kernel: Pid: 0, comm: swapper Not tainted 2.6.32-358.0.1.el6.x86_64 #1 Mar 1 17:21:16 archive01 kernel: Call Trace: Mar 1 17:21:16 archive01 kernel: <IRQ> [<ffffffff8112c207>] ? __alloc_pages_nodemask+0x757/0x8d0 Mar 1 17:21:16 archive01 kernel: [<ffffffff81166ab2>] ? kmem_getpages+0x62/0x170 Mar 1 17:21:16 archive01 kernel: [<ffffffff811676ca>] ? fallback_alloc+0x1ba/0x270 Mar 1 17:21:16 archive01 kernel: [<ffffffff8116711f>] ? cache_grow+0x2cf/0x320 Mar 1 17:21:16 archive01 kernel: [<ffffffff81167449>] ? ____cache_alloc_node+0x99/0x160 Mar 1 17:21:16 archive01 kernel: [<ffffffff811683cb>] ? kmem_cache_alloc+0x11b/0x190 Mar 1 17:21:16 archive01 kernel: [<ffffffff81439c18>] ? sk_prot_alloc+0x48/0x1c0 Mar 1 17:21:16 archive01 kernel: [<ffffffff8143acf2>] ? sk_clone+0x22/0x2e0 Mar 1 17:21:16 archive01 kernel: [<ffffffff81489bc6>] ? inet_csk_clone+0x16/0xd0 Mar 1 17:21:16 archive01 kernel: [<ffffffff814a2ad3>] ? tcp_create_openreq_child+0x23/0x450 Mar 1 17:21:16 archive01 kernel: [<ffffffff814a02cd>] ? tcp_v4_syn_recv_sock+0x4d/0x310 Mar 1 17:21:16 archive01 kernel: [<ffffffff814a2876>] ? tcp_check_req+0x226/0x460 Mar 1 17:21:16 archive01 kernel: [<ffffffff8149fd6b>] ? tcp_v4_do_rcv+0x35b/0x430 Mar 1 17:21:16 archive01 kernel: [<ffffffff81065c54>] ? enqueue_task_fair+0x64/0x100 Mar 1 17:21:16 archive01 kernel: [<ffffffff814a157e>] ? tcp_v4_rcv+0x4fe/0x8d0 Mar 1 17:21:16 archive01 kernel: [<ffffffff8147f36d>] ? ip_local_deliver_finish+0xdd/0x2d0 Mar 1 17:21:16 archive01 kernel: [<ffffffff8147f5f8>] ? ip_local_deliver+0x98/0xa0 Mar 1 17:21:16 archive01 kernel: [<ffffffff8147eabd>] ? ip_rcv_finish+0x12d/0x440 Mar 1 17:21:16 archive01 kernel: [<ffffffff8147f045>] ? ip_rcv+0x275/0x350 Mar 1 17:21:16 archive01 kernel: [<ffffffff8144827b>] ? __netif_receive_skb+0x4ab/0x750 Mar 1 17:21:16 archive01 kernel: [<ffffffff8149e89a>] ? tcp4_gro_receive+0x5a/0xd0 Mar 1 17:21:16 archive01 kernel: [<ffffffff8144a658>] ? netif_receive_skb+0x58/0x60 Mar 1 17:21:16 archive01 kernel: [<ffffffff8144a760>] ? napi_skb_finish+0x50/0x70 Mar 1 17:21:16 archive01 kernel: [<ffffffff8144cd09>] ? napi_gro_receive+0x39/0x50 Mar 1 17:21:16 archive01 kernel: [<ffffffffa0115bb8>] ? tg3_poll_work+0x788/0xe50 [tg3] Mar 1 17:21:16 archive01 kernel: [<ffffffff810a7b05>] ? tick_dev_program_event+0x65/0xc0 Mar 1 17:21:16 archive01 kernel: [<ffffffffa011df10>] ? tg3_poll+0x70/0x440 [tg3] Mar 1 17:21:16 archive01 kernel: [<ffffffff81076d58>] ? irq_exit+0x48/0x90 Mar 1 17:21:16 archive01 kernel: [<ffffffff8144ce23>] ? net_rx_action+0x103/0x2f0 Mar 1 17:21:16 archive01 kernel: [<ffffffff81076fb1>] ? __do_softirq+0xc1/0x1e0 Mar 1 17:21:16 archive01 kernel: [<ffffffff810e1720>] ? handle_IRQ_event+0x60/0x170 Mar 1 17:21:16 archive01 kernel: [<ffffffff8100c1cc>] ? call_softirq+0x1c/0x30 Mar 1 17:21:16 archive01 kernel: [<ffffffff8100de05>] ? do_softirq+0x65/0xa0 Mar 1 17:21:16 archive01 kernel: [<ffffffff81076d95>] ? irq_exit+0x85/0x90 Mar 1 17:21:16 archive01 kernel: [<ffffffff81516d75>] ? do_IRQ+0x75/0xf0 Mar 1 17:21:16 archive01 kernel: [<ffffffff8100b9d3>] ? ret_from_intr+0x0/0x11 Mar 1 17:21:16 archive01 kernel: <EOI> [<ffffffff8103b90b>] ? native_safe_halt+0xb/0x10 Mar 1 17:21:16 archive01 kernel: [<ffffffff8101495d>] ? default_idle+0x4d/0xb0 Mar 1 17:21:16 archive01 kernel: [<ffffffff81014a5d>] ? c1e_idle+0x9d/0x120 Mar 1 17:21:16 archive01 kernel: [<ffffffff81009fc6>] ? cpu_idle+0xb6/0x110 Mar 1 17:21:16 archive01 kernel: [<ffffffff814f300a>] ? rest_init+0x7a/0x80 Mar 1 17:21:16 archive01 kernel: [<ffffffff81c27f7b>] ? start_kernel+0x424/0x430 Mar 1 17:21:16 archive01 kernel: [<ffffffff81c2733a>] ? x86_64_start_reservations+0x125/0x129 Mar 1 17:21:16 archive01 kernel: [<ffffffff81c27438>] ? x86_64_start_kernel+0xfa/0x109 [root at archive01 ~]# free total used free shared buffers cached Mem: 8059636 7755352 304284 0 6879212 93708 -/+ buffers/cache: 782432 7277204 Swap: 4095992 20432 4075560 I was having this in sysctl.conf for some time without any problems and have removed it now. # Workaround for https://bugzilla.redhat.com/show_bug.cgi?id=713546 vm.min_free_kbytes = 512000 vm.zone_reclaim_mode = 1 Regards, Simon