The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
---- File information -----------
File: errorreport.txt
Date: 30 Aug 2002, 9:00
Size: 28231 bytes.
Type: Text
On Fri, 2002-08-30 at 08:02, Pedro M. Rodrigues wrote:
> Hello to all! While preparing to migrate some servers to Redhat
> 7.3 and doing some nfs tests before deployment i came across this
> "Warning - running *really* short on DMA buffers" error message
> repeated several times in dmesg and /var/log/messages. Something like
> this:
They are warnings not fatal, at most they slowed you down due to lack of
resources. You might want to tune the vm settings to keep more pages
reserved for atomic allocation
I do wan't to tune the vm settings, these warnings may not be
fatal but it's not pretty to have hundreds of those in the console
and log files. Bear with me on this one, but i remember doing exactly
that in the past, tuning /proc/sys/vm/freepages. How does one
acomplish that nowadays? I looked at the kernel source documentation
and still found references to freepages, but vm/freepages doesn't
exist anymore. Kernel is 2.4.18-10 from Redhat.
Regards,
Pedro
On 30 Aug 2002 at 11:58, Alan Cox wrote:
> On Fri, 2002-08-30 at 08:02, Pedro M. Rodrigues wrote:
> > Hello to all! While preparing to migrate some servers to Redhat
> > 7.3 and doing some nfs tests before deployment i came across this
> > "Warning - running *really* short on DMA buffers" error message
> > repeated several times in dmesg and /var/log/messages. Something
> > like this:
>
> They are warnings not fatal, at most they slowed you down due to lack
> of resources. You might want to tune the vm settings to keep more
> pages reserved for atomic allocation
>
>
On Fri, 30 Aug 2002, Pedro M. Rodrigues wrote:
> I do wan't to tune the vm settings, these warnings may not be
> fatal but it's not pretty to have hundreds of those in the console
> and log files. Bear with me on this one, but i remember doing exactly
> that in the past, tuning /proc/sys/vm/freepages. How does one
> acomplish that nowadays? I looked at the kernel source documentation
> and still found references to freepages, but vm/freepages doesn't
> exist anymore. Kernel is 2.4.18-10 from Redhat.
For fundamental reasons it's always possible for non-sleeping
allocations to fail. I think this warning just needs to be
rate-limited, if it isn't already ...
OTOH, failed allocations could serve as a hint for kswapd to
try to keep more memory free. I should look into that for some
next version.
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
It doesn't seem rate limited to me, it floods the console and log
files. If i can't tune the vm settings to decrease the likelyhood of
this error message, what can i do? Is rate limiting the error message
at scsi_merge.c a good idea?
Thanks,
Pedro
On 30 Aug 2002 at 9:18, Rik van Riel wrote:
> On Fri, 30 Aug 2002, Pedro M. Rodrigues wrote:
>
> > I do wan't to tune the vm settings, these warnings may not be
> > fatal but it's not pretty to have hundreds of those in the console
> > and log files. Bear with me on this one, but i remember doing
> > exactly that in the past, tuning /proc/sys/vm/freepages. How does
> > one acomplish that nowadays? I looked at the kernel source
> > documentation and still found references to freepages, but
> > vm/freepages doesn't exist anymore. Kernel is 2.4.18-10 from Redhat.
>
> For fundamental reasons it's always possible for non-sleeping
> allocations to fail. I think this warning just needs to be
> rate-limited, if it isn't already ...
>
> OTOH, failed allocations could serve as a hint for kswapd to
> try to keep more memory free. I should look into that for some
> next version.
>
> regards,
>
> Rik
> --
> Bravely reimplemented by the knights who say "NIH".
>
> http://www.surriel.com/ http://distro.conectiva.com/
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Replying to myself, i found out that in kernel 2.4.20-pre5, the
section responsible for the warning has a #if 0 #endif around it .
This was not the case in 2.4.19 btw. I had rate limited the warning,
but it's not needed.
Thanks to everybody,
Pedro
On 31 Aug 2002 at 15:29, Pedro M. Rodrigues wrote:
> It doesn't seem rate limited to me, it floods the console and log
> files. If i can't tune the vm settings to decrease the likelyhood of
> this error message, what can i do? Is rate limiting the error message
> at scsi_merge.c a good idea?
>
>
> Thanks,
> Pedro
>
> On 30 Aug 2002 at 9:18, Rik van Riel wrote:
>
> > On Fri, 30 Aug 2002, Pedro M. Rodrigues wrote:
> >
> > > I do wan't to tune the vm settings, these warnings may not be
> > > fatal but it's not pretty to have hundreds of those in the console
> > > and log files. Bear with me on this one, but i remember doing
> > > exactly that in the past, tuning /proc/sys/vm/freepages. How does
> > > one acomplish that nowadays? I looked at the kernel source
> > > documentation and still found references to freepages, but
> > > vm/freepages doesn't exist anymore. Kernel is 2.4.18-10 from
> > > Redhat.
> >
> > For fundamental reasons it's always possible for non-sleeping
> > allocations to fail. I think this warning just needs to be
> > rate-limited, if it isn't already ...
> >
> > OTOH, failed allocations could serve as a hint for kswapd to
> > try to keep more memory free. I should look into that for some
> > next version.
> >
> > regards,
> >
> > Rik
> > --
> > Bravely reimplemented by the knights who say "NIH".
> >
> > http://www.surriel.com/ http://distro.conectiva.com/
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-kernel" in the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>