On Friday 19 October 2012 17:16:10 Tony Molloy wrote:
> On Friday 19 October 2012 15:27:52 m.roth@xxxxxxxxx wrote:
> > Tim Nelson wrote:
> > > ----- Original Message -----
> > >
> > >> On Thursday 18 October 2012 21:44:30 Tim Nelson wrote:
> > >> > I see this ocasionally on one of my CentOS 6.3 x64 systems:
> > >> >
> > >> > Oct 18 03:10:52 backup kernel: swapper: page allocation
> > >> > failure. order:1, mode:0x20 Oct 18 03:10:52 backup kernel:
> > >> > Pid: 0, comm: swapper Not tainted 2.6.32-279.9.1.el6.x86_64
> > >> > #1 Oct 18 03:10:52 backup kernel: Call Trace:
> > >> > Oct 18 03:10:52 backup kernel: <IRQ> [<ffffffff8112789f>] ?
> > >> > __alloc_pages_nodemask+0x77f/0x940 Oct 18 03:10:52 backup
> > >> > kernel:
> > >>
> > >> <snip>
> > >>
> > >> > Any thoughts on the cause? The system has 16GB of RAM, and
> > >> > whenever checked, there is no swap usage. Is this a memory
> > >> > error (bad RAM)?
> > >>
> > >> I have the same problem on a Dell PE R720 with 16GB of RAM
> > >> doing lots of networking. It's a file server. It was discussed
> > >> on the dell-poweredge mailing list last week
> > >> <linux-poweredge@xxxxxxxx>
> > >>
> > >> The conclusion was that it was harmless but for a discussion
> > >> and possible workaround see
> > >> <https://bugzilla.redhat.com/show_bug.cgi?id=770545#c16>
> > >>
> > >> Hope this helps,
> >
> > Thanks, but I agree with the person in the bugzilla thread, this
> > is not "just harmless" - when I see one in the logs, I usually
> > see several within a single hour. I *think* that it seems to
> > happen more when someone's copying or d/l large datasets, and it
> > makes me extrememly worried about the consistency of the data.
>
> Agree it happens when there is a lot of network activity. My box
> during the day is a student fileserver and at night it does backups
> using BackupPC so a lot of network activity. I haven't seen any
> ill-effects but would obviously be happy to get it sorted. I tried
> the workaround suggested in the bugzilla thread so I'll see if it
> has any effect.
>
> Tony
>
Ok I tried that workaround
set vm.zone_reclaim_mode = 1 in /etc/sysctl.conf
and the message has gone.
It even survived booting into the latest kernel
2.6.32-279.11.1.el6.x86_64
Tony
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
