| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
RE: [Xen-users] Attempt to allocate order 5 skbuff. Increase MAX_SKBUFF_
> Subject: RE: [Xen-users] Attempt to allocate order 5 skbuff. Increase
> MAX_SKBUFF_ORDER
>
> >> very few ports from accessing our site.
> >>
> >> I am not sure why the iptables_nat module would be loaded
> >> because we are not using NAT in our network configuration, at least
> we
> >> are
> >> not intending to do so.
> >
> > Well if you don't need it then just try and remove the NAT module
> using "modprobe -r iptable_nat". And see if that makes any difference.
> >
>
> Can't remove it, get the message
> "module is in use".. not sure by what.
Do you have any rules in the NAT table? E.g. check "iptables -t nat -L". Then
remove those rules and try removing the module again. I doubt that the NAT
module is the core of your problem though.
> >>> Now the issue about MAX_SKBUFF_ORDER should only show up when you
> are
> >> trying to send large packets. Do you use jumbo frames or something
> like
> >> that? What MTU sizes are set for the interfaces? As far as I know
> the
> >> message you get means that Xen is trying to allocate a buffer for
> the
> >> packet to send, but the packet size is too big for the buffer
> >> allocator.
> >>>
> >> [root@fg3x3 ~]# ifconfig
> >> eth0 Link encap:Ethernet HWaddr 00:16:3E:05:03:03
> >> inet addr:131.225.107.144 Bcast:131.225.107.255
> >> Mask:255.255.255.0
> >> inet6 addr: fe80::216:3eff:fe05:303/64 Scope:Link
> >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> >> RX packets:2971214615 errors:0 dropped:0 overruns:0
> frame:0
> >> TX packets:1576876803 errors:0 dropped:0 overruns:0
> >> carrier:0
> >> collisions:0 txqueuelen:1000
> >> RX bytes:2428856680 (2.2 GiB) TX bytes:4068069258 (3.7
> GiB)
> >>
> >> No--no jumbo frames anywhere. MTU size is the standard 1500.
> >
> > This is on all Dom0/DomU frontend and backend interfaces?
>
> That's right.
>
> >
> >
> >
> >
> >>> In general, you can configure the Xen kernel to use a Xen-specific
> >> buffer allocator, or the kernel's default buffer allocator. There is
> a
> >> kernel configuration option for that and it is called
> >> CONFIG_XEN_SKBUFF. You could try and switch that off, and recompile
> the
> >> kernel.
> >>>
> >> So CONFIG_XEN_SKBUFF is by default on?
> >
> CONFIG_XEN_SKBUFF is on in my config.
> There is no MAX_SKBUFF_ORDER parameter anywhere in my source tree,
> much less the config file.
MAX_SKUFF_ORDER is not a configuration option. It is part of the Dom0/DomU
kernel code.
Your posted kernel config is from your Dom0? You said before that you are
running a 64-bit Dom0. You need to check the CONFIG_XEN_SKBUFF option in the
Dom0 config. I am in general wondering if you might have issues with your
DomU/Dom0 configuration. How did you install those kernels? Did you install
them using the distro? Did you compile them yourself? I assume you also run a
64-bit hypervisor?
If it is easy for you to recompile DomU/Dom0 kernels then you could try and
recompile with CONFIG_XEN_SKBUFF, CONFIG_HAVE_ARCH_ALLOC_SKB and
CONFIG_HAVE_ARCH_DEV_ALLOC_SKB disabled, and see if it makes any difference.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
| |
|
Home