We compiled kernel 4.6.6 for our nas devices running on ARM kirkwood cpu’s. These nas devices have only 256 MB of RAM so limited memory resources When we fully load the cpu and are copying files via the interface we get frequently this “ error” message in dmesg log

[ 1978.149929] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize skb with tiny unaligned fragment [ 1978.150138] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize skb with tiny unaligned fragment [ 1978.150318] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize skb with tiny unaligned fragment [ 1978.150360] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize skb with tiny unaligned fragment

...

CPU[|||||||||||||||||||||||||||||||||||98.9%] Tasks: 29, 0 thr; 2 running Mem[||||||||||||||||||||||||||||||||30/244MB] Load average: 1.36 1.29 0.92
 Swp[                                 0/511MB]     Uptime: 00:38:11

We analyzed the driver code code and think that it does not seems to be an error but a warning, this we want to verify and if this warning can be taken out without risk

The message originates from this part of the code of the driver

1023 if (has_tiny_unaligned_frags(skb) && __skb_linearize(skb)) {
1024                 netdev_printk(KERN_DEBUG, dev,
1025 "failed to linearize skb with tiny unaligned fragment\n");
1026                 return NETDEV_TX_BUSY;
1027         }

__skb_linearize is set in skbuff.h and comments are useful

static inline int __skb_linearize(struct sk_buff *skb)
1636 {
1637         return __pskb_pull_tail(skb, skb->data_len) ? 0 : -ENOMEM;
1638 }
1639
1640 /**
1641  *      skb_linearize - convert paged skb to linear one
1642  *      @skb: buffer to linarize
1643  *
1644  *      If there is no free memory -ENOMEM is returned, otherwise zero
1645  *      is returned and the old skb data released.
1646  */
1647 static inline int skb_linearize(struct sk_buff *skb)
1648 {

So return a false state (0) if there is enough free memory and true on the other case.

Please to note mv643xx_eth.c returns also a busy state. So I assume on this case the driver repeats this step up to success

So in my opinion, this is not an error message but a warning and does not mean corrupted data and I think is should be possible to remove it.
Is conclusion is correct ?

Reply via email to