* Re: Issue with Micrel PCI Network Driver.
From: Bjørn Mork @ 2013-02-12 10:10 UTC (permalink / raw)
To: Ben Hutchings; +Cc: joseph.lutz, netdev
In-Reply-To: <1360604823.2701.11.camel@bwh-desktop.uk.solarflarecom.com>
Ben Hutchings <bhutchings@solarflare.com> writes:
> On Mon, 2013-02-11 at 17:46 +0000, Ben Hutchings wrote:
>> On Fri, 2013-02-08 at 17:17 -0600, Joseph Lutz wrote:
>> > I am having an issue with one of the network interface drivers. The
>> > driver in question is 'drivers/net/ethernet/micrel/ksz884x.c', the
>> > driver for the Micrel-Kendin device 8841.
>> > I am trying to get systemd to rename the three network interfaces in my
>> > embedded atom system. I have one of the interfaces being renamed (an
>> > Intel Corporation 82574L), but the two Micrel interfaces are not being
>> > renamed. I traced this down to the driver not populating the
>> > /sys/devices/pci* information. Instead it places the driver into
>> > /sys/devices/virtual/net/.
>> [...]
>>
>> Right, this driver doesn't specify the parent device (PCI device) for
>> the net devices it creates.
>>
>> All you should need to is add:
>> SET_NETDEV_DEV(dev, pdev);
>> underneath the call to alloc_etherdev().
>
> Or rather:
> SET_NETDEV_DEV(dev, &pdev->dev);
That should of course be fixed. But this bug should not prevent
userspace from renaming the device, should it? Sounds like a userspace
application making too many stupid assumptions to me. Does it work for
network devices attached to other buses?
Bjørn
^ permalink raw reply
* [PATCH] net/macb: fix race with RX interrupt while doing NAPI
From: Nicolas Ferre @ 2013-02-12 10:08 UTC (permalink / raw)
To: David S. Miller, netdev
Cc: linux-arm-kernel, linux-kernel, Jean-Christophe PLAGNIOL-VILLARD,
mailinglists, Nicolas Ferre
In-Reply-To: <50D2D7BD.3030801@erwinrol.com>
When interrupts are disabled, an RX condition can occur but
it is not reported when enabling interrupts again. We need to check
RSR and use napi_reschedule() if condition is met.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/net/ethernet/cadence/macb.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index a9b0830..b9d4bb9 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -693,6 +693,11 @@ static int macb_poll(struct napi_struct *napi, int budget)
* get notified when new packets arrive.
*/
macb_writel(bp, IER, MACB_RX_INT_FLAGS);
+
+ /* Packets received while interrupts were disabled */
+ status = macb_readl(bp, RSR);
+ if (unlikely(status))
+ napi_reschedule(napi);
}
/* TODO: Handle errors */
--
1.8.0
^ permalink raw reply related
* Re: tap devices not receiving packets from a bridge
From: Michael S. Tsirkin @ 2013-02-12 9:54 UTC (permalink / raw)
To: Michael Tokarev; +Cc: Stefan Hajnoczi, Peter Lieven, qemu-devel, netdev
In-Reply-To: <511A0DBB.7080907@msgid.tls.msk.ru>
On Tue, Feb 12, 2013 at 01:39:07PM +0400, Michael Tokarev wrote:
> 12.02.2013 13:10, Peter Lieven wrote:
> []
>
> Guys, can we please trim the excessive quoting just a bit? ;)
>
> >>> If have set this option for 2 weeks now and not seen this problem again.
> >>> How does this flag work with the recently added tap multiqueue support?
>
> >>This will be the only option in 3.8.
>
> >Ok, but wouldn`t it be good to set it in qemu for kernels <3.8?
>
> I'd say for kernels without mq support, not for <3.8, right? :)
>
> Thanks,
>
> /mjt
It's harmless to always set this flag, on 3.8 it does nothing.
--
MST
^ permalink raw reply
* [PATCH ethtool] ethtool: Add string to display support for KR PHY
From: Vasundhara, Volam @ 2013-02-12 9:46 UTC (permalink / raw)
To: bhutchings@solarflare.com; +Cc: netdev@vger.kernel.org, Vasundhara, Volam
In-Reply-To: <1360659168-14346-1-git-send-email-vasundhara.volam@emulex.com>
Signed-off-by: Vasundhara Volam <vasundhara.volam@emulex.com>
---
ethtool.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/ethtool.c b/ethtool.c
index 55bc082..205f574 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -512,6 +512,7 @@ dump_link_caps(const char *prefix, const char *an_prefix, u32 mask,
{ 0, ADVERTISED_2500baseX_Full, "2500baseX/Full" },
{ 0, ADVERTISED_10000baseT_Full, "10000baseT/Full" },
{ 0, ADVERTISED_10000baseKX4_Full, "10000baseKX4/Full" },
+ { 0, ADVERTISED_10000baseKR_Full, "10000baseKR/Full" },
{ 0, ADVERTISED_20000baseMLD2_Full, "20000baseMLD2/Full" },
{ 0, ADVERTISED_40000baseKR4_Full, "40000baseKR4/Full" },
{ 0, ADVERTISED_40000baseCR4_Full, "40000baseCR4/Full" },
--
1.7.10.4
^ permalink raw reply related
* Re: tap devices not receiving packets from a bridge
From: Michael Tokarev @ 2013-02-12 9:39 UTC (permalink / raw)
To: Peter Lieven; +Cc: Stefan Hajnoczi, netdev, qemu-devel, Michael S. Tsirkin
In-Reply-To: <056542E4-18E4-4C9F-AC96-60661768D6AF@dlhnet.de>
12.02.2013 13:10, Peter Lieven wrote:
[]
Guys, can we please trim the excessive quoting just a bit? ;)
>>> If have set this option for 2 weeks now and not seen this problem again.
>>> How does this flag work with the recently added tap multiqueue support?
>> This will be the only option in 3.8.
> Ok, but wouldn`t it be good to set it in qemu for kernels <3.8?
I'd say for kernels without mq support, not for <3.8, right? :)
Thanks,
/mjt
^ permalink raw reply
* bonding 802.3ad mode with bridge and tap devices
From: Stefan Priebe - Profihost AG @ 2013-02-12 9:33 UTC (permalink / raw)
To: fubar; +Cc: andy, Linux Netdev List
Hello,
i'm using KVM with tapdevices on vanilla 3.7.7 kernel.
Layout:
eth0 ------
| -- bond0 --- vmbr0 ---- tap
eth1 ------
This works fine as long as i use active-backup mode. But if i switch to
802.3ad mode the host using vmbr0 as his default gw works fine but the
tap device does not.
It starts to work fine again if i set eth0/eth1 into promiscious mode.
Is this a kernel bug or my fault?
Thanks!
Greets,
Stefan
^ permalink raw reply
* Re: [Qemu-devel] tap devices not receiving packets from a bridge
From: Michael S. Tsirkin @ 2013-02-12 9:29 UTC (permalink / raw)
To: Peter Lieven; +Cc: Stefan Hajnoczi, qemu-devel, netdev
In-Reply-To: <056542E4-18E4-4C9F-AC96-60661768D6AF@dlhnet.de>
On Tue, Feb 12, 2013 at 10:10:24AM +0100, Peter Lieven wrote:
>
> Am 12.02.2013 um 10:08 schrieb "Michael S. Tsirkin" <mst@redhat.com>:
>
> > On Tue, Feb 12, 2013 at 08:06:04AM +0100, Peter Lieven wrote:
> >> On 23.01.2013 11:03, Michael S. Tsirkin wrote:
> >>> On Tue, Jan 22, 2013 at 10:04:07AM +0100, Peter Lieven wrote:
> >>>> On 23.11.2012 12:01, Michael S. Tsirkin wrote:
> >>>>> On Fri, Nov 23, 2012 at 10:41:21AM +0100, Peter Lieven wrote:
> >>>>>>
> >>>>>> Am 23.11.2012 um 08:02 schrieb Stefan Hajnoczi:
> >>>>>>
> >>>>>>> On Thu, Nov 22, 2012 at 03:29:52PM +0100, Peter Lieven wrote:
> >>>>>>>> is anyone aware of a problem with the linux network bridge that in very rare circumstances stops
> >>>>>>>> a bridge from sending pakets to a tap device?
> >>>>>>>>
> >>>>>>>> My problem occurs in conjunction with vanilla qemu-kvm-1.2.0 and Ubuntu Kernel 3.2.0-34.53
> >>>>>>>> which is based on Linux 3.2.33.
> >>>>>>>>
> >>>>>>>> I was not yet able to reproduce the issue, it happens in really rare cases. The symptom is that
> >>>>>>>> the tap does not have any TX packets. RX is working fine. I see the packets coming in at
> >>>>>>>> the physical interface on the host, but they are not forwarded to the tap interface.
> >>>>>>>> The bridge itself has learnt the mac address of the vServer that is connected to the tap interface.
> >>>>>>>> It does not help to toggle the bridge link status, the tap interface status or the interface in the vServer.
> >>>>>>>> It seems that problem occurs if a tap interface that has previously been used, but set to nonpersistent
> >>>>>>>> is set persistent again and then is by chance assigned to the same vServer (=same mac address on same
> >>>>>>>> bridge) again. Unfortunately it seems not to be reproducible.
> >>>>>>>
> >>>>>>> Not sure but this patch from Michael Tsirkin may help - it solves an
> >>>>>>> issue with persistent tap devices:
> >>>>>>>
> >>>>>>> http://patchwork.ozlabs.org/patch/198598/
> >>>>>>
> >>>>>> Hi Stefan,
> >>>>>>
> >>>>>> thanks for the pointer. I have seen this patch, but I have neglected it because it was dealing
> >>>>>> with persistent taps. But maybe the taps in the kernel are not deleted directly.
> >>>>>> Can you remember what the syptomps of the above issue have been? Sorry for
> >>>>>> being vague, but I currently have no clue whats going on.
> >>>>>>
> >>>>>> Can someone who has more internal knowledge of the bridging/tap code say if qemu can
> >>>>>> be responsible at all if the tap device is not receiving packets from the bridge.
> >>>>>>
> >>>>>> If I have the following config. Lets say packets coming in via physical interface eth1.123,
> >>>>>> and a bridge called br123.I further have a virtual machine with tap0. Both eth1.123
> >>>>>> and tap0 are member of br123.
> >>>>>>
> >>>>>> If the issue occurs the vServer has no network connectivity inbound. If I sent a ping
> >>>>>> from the vServer I see it on tap0 and leaving on eth1.123. I see further the arp reply coming
> >>>>>> in via eth1.123, but the reply can't be seen on tap0.
> >>>>>>
> >>>>>> Peter
> >>>>>
> >>>>> If guest is not consuming packets, a TX queue in tap device
> >>>>> will with time overrun (there's space for 1000 packets there).
> >>>>> This is code from tun:
> >>>>>
> >>>>> if (skb_queue_len(&tfile->socket.sk->sk_receive_queue)
> >>>>>> = dev->tx_queue_len / tun->numqueues){
> >>>>> if (!(tun->flags & TUN_ONE_QUEUE)) {
> >>>>> /* Normal queueing mode. */
> >>>>> /* Packet scheduler handles dropping of further
> >>>>> * packets. */
> >>>>> netif_stop_subqueue(dev, txq);
> >>>>>
> >>>>> /* We won't see all dropped packets
> >>>>> * individually, so overrun
> >>>>> * error is more appropriate. */
> >>>>> dev->stats.tx_fifo_errors++;
> >>>>>
> >>>>>
> >>>>> So you can detect that this triggered by looking at fifo errors counter in device.
> >>>>>
> >>>>> Once this happens TX queue is stopped, then you hit this path:
> >>>>>
> >>>>> if (!netif_xmit_stopped(txq)) {
> >>>>> __this_cpu_inc(xmit_recursion);
> >>>>> rc = dev_hard_start_xmit(skb, dev, txq);
> >>>>> __this_cpu_dec(xmit_recursion);
> >>>>> if (dev_xmit_complete(rc)) {
> >>>>> HARD_TX_UNLOCK(dev, txq);
> >>>>> goto out;
> >>>>> }
> >>>>> }
> >>>>>
> >>>>> so packets are not passed to device anymore.
> >>>>> It will stay this way until guest consumes some packets and
> >>>>> queue is restarted.
> >>>>
> >>>> After some time I again have a vServer in this state. It seems not like there
> >>>> are no TX errors.
> >>>>
> >>>> # ifconfig tap10
> >>>> tap10 Link encap:Ethernet HWaddr 7a:59:20:6f:e7:e5
> >>>> inet6 addr: fe80::7859:20ff:fe6f:e7e5/64 Scope:Link
> >>>> UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
> >>>> RX packets:197431 errors:0 dropped:0 overruns:0 frame:0
> >>>> TX packets:264309 errors:0 dropped:0 overruns:2 carrier:0
> >>>> collisions:0 txqueuelen:500
> >>>> RX bytes:13842063 (13.8 MB) TX bytes:35092821 (35.0 MB)
> >>>>
> >>>> It seems like the bridge is not forwarding any packets to the tap device anymore altough it has learnt
> >>>> the MAC-Adresses and there are also broadcast packets coming in.
> >>>>
> >>>> Any more ideas where I could debug?
> >>>>
> >>>> Peter
> >>>>
> >>>>>
> >>>>>>>
> >>>>>>> Stefan
> >>>
> >>> Hmm. So there are two overrun errors that triggered, so
> >>> it's possible after the second one the queue got stuck in an xoff state.
> >>> You'd have to use something like systemtap or kdb to poke at the
> >>> queue state to see whether xoff flag is set and/or look
> >>> at the receive queue length.
> >>>
> >>> For future, we can try to set TUN_ONE_QUEUE flag on the interface,
> >>> or try applying this patch
> >>> 5d097109257c03a71845729f8db6b5770c4bbedc
> >>> in kernel see if this helps.
> >>>
> >>
> >> If have set this option for 2 weeks now and not seen this problem again.
> >> How does this flag work with the recently added tap multiqueue support?
> >>
> >> Peter
> >
> > This will be the only option in 3.8.
>
> Ok, but wouldn`t it be good to set it in qemu for kernels <3.8?
>
> Peter
Yes, probably a good idea. Patch?
> >
> > --
> > MST
^ permalink raw reply
* RE: [PATCH 2/2] net: calexdaxgmac: fixup endian issues after __raw IO function change
From: David Laight @ 2013-02-12 9:19 UTC (permalink / raw)
To: Ben Dooks, Ben Hutchings
Cc: netdev, David S. Miller, Rob Herring, linux-arm-kernel
In-Reply-To: <5119382F.8000809@codethink.co.uk>
> > You are using le32_to_cpu() and cpu_to_le32() the wrong way round, and
> > then putting casts on the wrong side, i.e. it should be:
> >
> > value = le32_to_cpu((__force __le32)__raw_readl(addr));
> > __raw_writel((__force u32)cpu_to_le32(value), addr);
> >
> > (I do wonder why __raw I/O functions aren't declared to take/return __le
> > types... it would avoid the need to cast altogether.)
>
> Because they do things with the order the cpu is working in, the
> read{x} and write{x} transfer cpu to bus-endian so returning an __le
> type would not be correct.
Surely you want to arrange to use the byte-swapping memory
read/write instructions, rather than byteswapping the value.
Particularly on ppc which doesn't have a byteswap instruction
but can do byteswapping memory accesses.
David
^ permalink raw reply
* Re: [Qemu-devel] tap devices not receiving packets from a bridge
From: Peter Lieven @ 2013-02-12 9:10 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Stefan Hajnoczi, qemu-devel, netdev
In-Reply-To: <20130212090850.GB22029@redhat.com>
Am 12.02.2013 um 10:08 schrieb "Michael S. Tsirkin" <mst@redhat.com>:
> On Tue, Feb 12, 2013 at 08:06:04AM +0100, Peter Lieven wrote:
>> On 23.01.2013 11:03, Michael S. Tsirkin wrote:
>>> On Tue, Jan 22, 2013 at 10:04:07AM +0100, Peter Lieven wrote:
>>>> On 23.11.2012 12:01, Michael S. Tsirkin wrote:
>>>>> On Fri, Nov 23, 2012 at 10:41:21AM +0100, Peter Lieven wrote:
>>>>>>
>>>>>> Am 23.11.2012 um 08:02 schrieb Stefan Hajnoczi:
>>>>>>
>>>>>>> On Thu, Nov 22, 2012 at 03:29:52PM +0100, Peter Lieven wrote:
>>>>>>>> is anyone aware of a problem with the linux network bridge that in very rare circumstances stops
>>>>>>>> a bridge from sending pakets to a tap device?
>>>>>>>>
>>>>>>>> My problem occurs in conjunction with vanilla qemu-kvm-1.2.0 and Ubuntu Kernel 3.2.0-34.53
>>>>>>>> which is based on Linux 3.2.33.
>>>>>>>>
>>>>>>>> I was not yet able to reproduce the issue, it happens in really rare cases. The symptom is that
>>>>>>>> the tap does not have any TX packets. RX is working fine. I see the packets coming in at
>>>>>>>> the physical interface on the host, but they are not forwarded to the tap interface.
>>>>>>>> The bridge itself has learnt the mac address of the vServer that is connected to the tap interface.
>>>>>>>> It does not help to toggle the bridge link status, the tap interface status or the interface in the vServer.
>>>>>>>> It seems that problem occurs if a tap interface that has previously been used, but set to nonpersistent
>>>>>>>> is set persistent again and then is by chance assigned to the same vServer (=same mac address on same
>>>>>>>> bridge) again. Unfortunately it seems not to be reproducible.
>>>>>>>
>>>>>>> Not sure but this patch from Michael Tsirkin may help - it solves an
>>>>>>> issue with persistent tap devices:
>>>>>>>
>>>>>>> http://patchwork.ozlabs.org/patch/198598/
>>>>>>
>>>>>> Hi Stefan,
>>>>>>
>>>>>> thanks for the pointer. I have seen this patch, but I have neglected it because it was dealing
>>>>>> with persistent taps. But maybe the taps in the kernel are not deleted directly.
>>>>>> Can you remember what the syptomps of the above issue have been? Sorry for
>>>>>> being vague, but I currently have no clue whats going on.
>>>>>>
>>>>>> Can someone who has more internal knowledge of the bridging/tap code say if qemu can
>>>>>> be responsible at all if the tap device is not receiving packets from the bridge.
>>>>>>
>>>>>> If I have the following config. Lets say packets coming in via physical interface eth1.123,
>>>>>> and a bridge called br123.I further have a virtual machine with tap0. Both eth1.123
>>>>>> and tap0 are member of br123.
>>>>>>
>>>>>> If the issue occurs the vServer has no network connectivity inbound. If I sent a ping
>>>>>> from the vServer I see it on tap0 and leaving on eth1.123. I see further the arp reply coming
>>>>>> in via eth1.123, but the reply can't be seen on tap0.
>>>>>>
>>>>>> Peter
>>>>>
>>>>> If guest is not consuming packets, a TX queue in tap device
>>>>> will with time overrun (there's space for 1000 packets there).
>>>>> This is code from tun:
>>>>>
>>>>> if (skb_queue_len(&tfile->socket.sk->sk_receive_queue)
>>>>>> = dev->tx_queue_len / tun->numqueues){
>>>>> if (!(tun->flags & TUN_ONE_QUEUE)) {
>>>>> /* Normal queueing mode. */
>>>>> /* Packet scheduler handles dropping of further
>>>>> * packets. */
>>>>> netif_stop_subqueue(dev, txq);
>>>>>
>>>>> /* We won't see all dropped packets
>>>>> * individually, so overrun
>>>>> * error is more appropriate. */
>>>>> dev->stats.tx_fifo_errors++;
>>>>>
>>>>>
>>>>> So you can detect that this triggered by looking at fifo errors counter in device.
>>>>>
>>>>> Once this happens TX queue is stopped, then you hit this path:
>>>>>
>>>>> if (!netif_xmit_stopped(txq)) {
>>>>> __this_cpu_inc(xmit_recursion);
>>>>> rc = dev_hard_start_xmit(skb, dev, txq);
>>>>> __this_cpu_dec(xmit_recursion);
>>>>> if (dev_xmit_complete(rc)) {
>>>>> HARD_TX_UNLOCK(dev, txq);
>>>>> goto out;
>>>>> }
>>>>> }
>>>>>
>>>>> so packets are not passed to device anymore.
>>>>> It will stay this way until guest consumes some packets and
>>>>> queue is restarted.
>>>>
>>>> After some time I again have a vServer in this state. It seems not like there
>>>> are no TX errors.
>>>>
>>>> # ifconfig tap10
>>>> tap10 Link encap:Ethernet HWaddr 7a:59:20:6f:e7:e5
>>>> inet6 addr: fe80::7859:20ff:fe6f:e7e5/64 Scope:Link
>>>> UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
>>>> RX packets:197431 errors:0 dropped:0 overruns:0 frame:0
>>>> TX packets:264309 errors:0 dropped:0 overruns:2 carrier:0
>>>> collisions:0 txqueuelen:500
>>>> RX bytes:13842063 (13.8 MB) TX bytes:35092821 (35.0 MB)
>>>>
>>>> It seems like the bridge is not forwarding any packets to the tap device anymore altough it has learnt
>>>> the MAC-Adresses and there are also broadcast packets coming in.
>>>>
>>>> Any more ideas where I could debug?
>>>>
>>>> Peter
>>>>
>>>>>
>>>>>>>
>>>>>>> Stefan
>>>
>>> Hmm. So there are two overrun errors that triggered, so
>>> it's possible after the second one the queue got stuck in an xoff state.
>>> You'd have to use something like systemtap or kdb to poke at the
>>> queue state to see whether xoff flag is set and/or look
>>> at the receive queue length.
>>>
>>> For future, we can try to set TUN_ONE_QUEUE flag on the interface,
>>> or try applying this patch
>>> 5d097109257c03a71845729f8db6b5770c4bbedc
>>> in kernel see if this helps.
>>>
>>
>> If have set this option for 2 weeks now and not seen this problem again.
>> How does this flag work with the recently added tap multiqueue support?
>>
>> Peter
>
> This will be the only option in 3.8.
Ok, but wouldn`t it be good to set it in qemu for kernels <3.8?
Peter
>
> --
> MST
^ permalink raw reply
* [PATCH v2] net: fec_mpc52xx: Read MAC address from device-tree
From: Stefan Roese @ 2013-02-12 9:08 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, Anatolij Gustschin
Until now, the MPC5200 FEC ethernet driver relied upon the bootloader
(U-Boot) to write the MAC address into the ethernet controller
registers. The Linux driver should not rely on such a thing. So
lets read the MAC address from the DT as it should be done here.
The following priority is now used to read the MAC address:
1) First, try OF node MAC address, if not present or invalid, then:
2) Read from MAC address registers, if invalid, then:
3) Log a warning message, and choose a random MAC address.
This fixes a problem with a MPC5200 board that uses the SPL U-Boot
version without FEC initialization before Linux booting for
boot speedup.
Additionally a status line is now be printed upon successful
driver probing, also displaying this MAC address.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Anatolij Gustschin <agust@denx.de>
---
v2:
- Remove module parameter mpc52xx_fec_mac_addr
- Priority for MAC address probing now is DT, controller regs
If the resulting MAC address is invalid, a random address will
be generated and used with a warning message
- Use "np" variable to simplify the code
drivers/net/ethernet/freescale/fec_mpc52xx.c | 61 +++++++++++++++++-----------
1 file changed, 37 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_mpc52xx.c b/drivers/net/ethernet/freescale/fec_mpc52xx.c
index 817d081..8b725f4 100644
--- a/drivers/net/ethernet/freescale/fec_mpc52xx.c
+++ b/drivers/net/ethernet/freescale/fec_mpc52xx.c
@@ -76,10 +76,6 @@ static void mpc52xx_fec_stop(struct net_device *dev);
static void mpc52xx_fec_start(struct net_device *dev);
static void mpc52xx_fec_reset(struct net_device *dev);
-static u8 mpc52xx_fec_mac_addr[6];
-module_param_array_named(mac, mpc52xx_fec_mac_addr, byte, NULL, 0);
-MODULE_PARM_DESC(mac, "six hex digits, ie. 0x1,0x2,0xc0,0x01,0xba,0xbe");
-
#define MPC52xx_MESSAGES_DEFAULT ( NETIF_MSG_DRV | NETIF_MSG_PROBE | \
NETIF_MSG_LINK | NETIF_MSG_IFDOWN | NETIF_MSG_IFUP)
static int debug = -1; /* the above default */
@@ -110,15 +106,6 @@ static void mpc52xx_fec_set_paddr(struct net_device *dev, u8 *mac)
out_be32(&fec->paddr2, (*(u16 *)(&mac[4]) << 16) | FEC_PADDR2_TYPE);
}
-static void mpc52xx_fec_get_paddr(struct net_device *dev, u8 *mac)
-{
- struct mpc52xx_fec_priv *priv = netdev_priv(dev);
- struct mpc52xx_fec __iomem *fec = priv->fec;
-
- *(u32 *)(&mac[0]) = in_be32(&fec->paddr1);
- *(u16 *)(&mac[4]) = in_be32(&fec->paddr2) >> 16;
-}
-
static int mpc52xx_fec_set_mac_address(struct net_device *dev, void *addr)
{
struct sockaddr *sock = addr;
@@ -853,6 +840,8 @@ static int mpc52xx_fec_probe(struct platform_device *op)
struct resource mem;
const u32 *prop;
int prop_size;
+ struct device_node *np = op->dev.of_node;
+ const void *p;
phys_addr_t rx_fifo;
phys_addr_t tx_fifo;
@@ -866,7 +855,7 @@ static int mpc52xx_fec_probe(struct platform_device *op)
priv->ndev = ndev;
/* Reserve FEC control zone */
- rv = of_address_to_resource(op->dev.of_node, 0, &mem);
+ rv = of_address_to_resource(np, 0, &mem);
if (rv) {
printk(KERN_ERR DRIVER_NAME ": "
"Error while parsing device node resource\n" );
@@ -919,7 +908,7 @@ static int mpc52xx_fec_probe(struct platform_device *op)
/* Get the IRQ we need one by one */
/* Control */
- ndev->irq = irq_of_parse_and_map(op->dev.of_node, 0);
+ ndev->irq = irq_of_parse_and_map(np, 0);
/* RX */
priv->r_irq = bcom_get_task_irq(priv->rx_dmatsk);
@@ -927,11 +916,33 @@ static int mpc52xx_fec_probe(struct platform_device *op)
/* TX */
priv->t_irq = bcom_get_task_irq(priv->tx_dmatsk);
- /* MAC address init */
- if (!is_zero_ether_addr(mpc52xx_fec_mac_addr))
- memcpy(ndev->dev_addr, mpc52xx_fec_mac_addr, 6);
- else
- mpc52xx_fec_get_paddr(ndev, ndev->dev_addr);
+ /*
+ * MAC address init:
+ *
+ * First try to read MAC address from DT
+ */
+ p = of_get_property(np, "local-mac-address", NULL);
+ if (p != NULL) {
+ memcpy(ndev->dev_addr, p, 6);
+ } else {
+ struct mpc52xx_fec __iomem *fec = priv->fec;
+
+ /*
+ * If the MAC addresse is not provided via DT then read
+ * it back from the controller regs
+ */
+ *(u32 *)(&ndev->dev_addr[0]) = in_be32(&fec->paddr1);
+ *(u16 *)(&ndev->dev_addr[4]) = in_be32(&fec->paddr2) >> 16;
+ }
+
+ /*
+ * Check if the MAC address is valid, if not get a random one
+ */
+ if (!is_valid_ether_addr(ndev->dev_addr)) {
+ eth_hw_addr_random(ndev);
+ dev_warn(&ndev->dev, "using random MAC address %pM\n",
+ ndev->dev_addr);
+ }
priv->msg_enable = netif_msg_init(debug, MPC52xx_MESSAGES_DEFAULT);
@@ -942,20 +953,20 @@ static int mpc52xx_fec_probe(struct platform_device *op)
/* Start with safe defaults for link connection */
priv->speed = 100;
priv->duplex = DUPLEX_HALF;
- priv->mdio_speed = ((mpc5xxx_get_bus_frequency(op->dev.of_node) >> 20) / 5) << 1;
+ priv->mdio_speed = ((mpc5xxx_get_bus_frequency(np) >> 20) / 5) << 1;
/* The current speed preconfigures the speed of the MII link */
- prop = of_get_property(op->dev.of_node, "current-speed", &prop_size);
+ prop = of_get_property(np, "current-speed", &prop_size);
if (prop && (prop_size >= sizeof(u32) * 2)) {
priv->speed = prop[0];
priv->duplex = prop[1] ? DUPLEX_FULL : DUPLEX_HALF;
}
/* If there is a phy handle, then get the PHY node */
- priv->phy_node = of_parse_phandle(op->dev.of_node, "phy-handle", 0);
+ priv->phy_node = of_parse_phandle(np, "phy-handle", 0);
/* the 7-wire property means don't use MII mode */
- if (of_find_property(op->dev.of_node, "fsl,7-wire-mode", NULL)) {
+ if (of_find_property(np, "fsl,7-wire-mode", NULL)) {
priv->seven_wire_mode = 1;
dev_info(&ndev->dev, "using 7-wire PHY mode\n");
}
@@ -970,6 +981,8 @@ static int mpc52xx_fec_probe(struct platform_device *op)
/* We're done ! */
dev_set_drvdata(&op->dev, ndev);
+ printk(KERN_INFO "%s: %s MAC %pM\n",
+ ndev->name, op->dev.of_node->full_name, ndev->dev_addr);
return 0;
--
1.8.1.3
^ permalink raw reply related
* Re: [Qemu-devel] tap devices not receiving packets from a bridge
From: Michael S. Tsirkin @ 2013-02-12 9:08 UTC (permalink / raw)
To: Peter Lieven; +Cc: Stefan Hajnoczi, qemu-devel, netdev
In-Reply-To: <5119E9DC.3000505@dlhnet.de>
On Tue, Feb 12, 2013 at 08:06:04AM +0100, Peter Lieven wrote:
> On 23.01.2013 11:03, Michael S. Tsirkin wrote:
> >On Tue, Jan 22, 2013 at 10:04:07AM +0100, Peter Lieven wrote:
> >>On 23.11.2012 12:01, Michael S. Tsirkin wrote:
> >>>On Fri, Nov 23, 2012 at 10:41:21AM +0100, Peter Lieven wrote:
> >>>>
> >>>>Am 23.11.2012 um 08:02 schrieb Stefan Hajnoczi:
> >>>>
> >>>>>On Thu, Nov 22, 2012 at 03:29:52PM +0100, Peter Lieven wrote:
> >>>>>>is anyone aware of a problem with the linux network bridge that in very rare circumstances stops
> >>>>>>a bridge from sending pakets to a tap device?
> >>>>>>
> >>>>>>My problem occurs in conjunction with vanilla qemu-kvm-1.2.0 and Ubuntu Kernel 3.2.0-34.53
> >>>>>>which is based on Linux 3.2.33.
> >>>>>>
> >>>>>>I was not yet able to reproduce the issue, it happens in really rare cases. The symptom is that
> >>>>>>the tap does not have any TX packets. RX is working fine. I see the packets coming in at
> >>>>>>the physical interface on the host, but they are not forwarded to the tap interface.
> >>>>>>The bridge itself has learnt the mac address of the vServer that is connected to the tap interface.
> >>>>>>It does not help to toggle the bridge link status, the tap interface status or the interface in the vServer.
> >>>>>>It seems that problem occurs if a tap interface that has previously been used, but set to nonpersistent
> >>>>>>is set persistent again and then is by chance assigned to the same vServer (=same mac address on same
> >>>>>>bridge) again. Unfortunately it seems not to be reproducible.
> >>>>>
> >>>>>Not sure but this patch from Michael Tsirkin may help - it solves an
> >>>>>issue with persistent tap devices:
> >>>>>
> >>>>>http://patchwork.ozlabs.org/patch/198598/
> >>>>
> >>>>Hi Stefan,
> >>>>
> >>>>thanks for the pointer. I have seen this patch, but I have neglected it because it was dealing
> >>>>with persistent taps. But maybe the taps in the kernel are not deleted directly.
> >>>>Can you remember what the syptomps of the above issue have been? Sorry for
> >>>>being vague, but I currently have no clue whats going on.
> >>>>
> >>>>Can someone who has more internal knowledge of the bridging/tap code say if qemu can
> >>>>be responsible at all if the tap device is not receiving packets from the bridge.
> >>>>
> >>>>If I have the following config. Lets say packets coming in via physical interface eth1.123,
> >>>>and a bridge called br123.I further have a virtual machine with tap0. Both eth1.123
> >>>>and tap0 are member of br123.
> >>>>
> >>>>If the issue occurs the vServer has no network connectivity inbound. If I sent a ping
> >>>>from the vServer I see it on tap0 and leaving on eth1.123. I see further the arp reply coming
> >>>>in via eth1.123, but the reply can't be seen on tap0.
> >>>>
> >>>>Peter
> >>>
> >>>If guest is not consuming packets, a TX queue in tap device
> >>>will with time overrun (there's space for 1000 packets there).
> >>>This is code from tun:
> >>>
> >>> if (skb_queue_len(&tfile->socket.sk->sk_receive_queue)
> >>> >= dev->tx_queue_len / tun->numqueues){
> >>> if (!(tun->flags & TUN_ONE_QUEUE)) {
> >>> /* Normal queueing mode. */
> >>> /* Packet scheduler handles dropping of further
> >>> * packets. */
> >>> netif_stop_subqueue(dev, txq);
> >>>
> >>> /* We won't see all dropped packets
> >>> * individually, so overrun
> >>> * error is more appropriate. */
> >>> dev->stats.tx_fifo_errors++;
> >>>
> >>>
> >>>So you can detect that this triggered by looking at fifo errors counter in device.
> >>>
> >>>Once this happens TX queue is stopped, then you hit this path:
> >>>
> >>> if (!netif_xmit_stopped(txq)) {
> >>> __this_cpu_inc(xmit_recursion);
> >>> rc = dev_hard_start_xmit(skb, dev, txq);
> >>> __this_cpu_dec(xmit_recursion);
> >>> if (dev_xmit_complete(rc)) {
> >>> HARD_TX_UNLOCK(dev, txq);
> >>> goto out;
> >>> }
> >>> }
> >>>
> >>>so packets are not passed to device anymore.
> >>>It will stay this way until guest consumes some packets and
> >>>queue is restarted.
> >>
> >>After some time I again have a vServer in this state. It seems not like there
> >>are no TX errors.
> >>
> >># ifconfig tap10
> >>tap10 Link encap:Ethernet HWaddr 7a:59:20:6f:e7:e5
> >> inet6 addr: fe80::7859:20ff:fe6f:e7e5/64 Scope:Link
> >> UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
> >> RX packets:197431 errors:0 dropped:0 overruns:0 frame:0
> >> TX packets:264309 errors:0 dropped:0 overruns:2 carrier:0
> >> collisions:0 txqueuelen:500
> >> RX bytes:13842063 (13.8 MB) TX bytes:35092821 (35.0 MB)
> >>
> >>It seems like the bridge is not forwarding any packets to the tap device anymore altough it has learnt
> >>the MAC-Adresses and there are also broadcast packets coming in.
> >>
> >>Any more ideas where I could debug?
> >>
> >>Peter
> >>
> >>>
> >>>>>
> >>>>>Stefan
> >
> >Hmm. So there are two overrun errors that triggered, so
> >it's possible after the second one the queue got stuck in an xoff state.
> >You'd have to use something like systemtap or kdb to poke at the
> >queue state to see whether xoff flag is set and/or look
> >at the receive queue length.
> >
> >For future, we can try to set TUN_ONE_QUEUE flag on the interface,
> >or try applying this patch
> >5d097109257c03a71845729f8db6b5770c4bbedc
> >in kernel see if this helps.
> >
>
> If have set this option for 2 weeks now and not seen this problem again.
> How does this flag work with the recently added tap multiqueue support?
>
> Peter
This will be the only option in 3.8.
--
MST
^ permalink raw reply
* FROM FACE BOOK 2013, OPEN THE ATTACHMENT.
From: FROM FACE BOOK 2013 @ 2013-02-12 9:01 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: FROM FACE BOOK 2013, OPEN THE ATTACHMENT..doc --]
[-- Type: application/msword, Size: 207872 bytes --]
^ permalink raw reply
* Re: soft lockup at __skb_recv_datagram() when fuzzing with trinity as root in VM
From: Tommi Rantala @ 2013-02-12 7:42 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Dave Jones, Pavel Emelyanov
In-Reply-To: <1360638903.20362.32.camel@edumazet-glaptop>
2013/2/12 Eric Dumazet <eric.dumazet@gmail.com>:
> On Mon, 2013-02-11 at 16:19 -0800, Eric Dumazet wrote:
>> On Mon, 2013-02-11 at 21:25 +0200, Tommi Rantala wrote:
>> > Hello,
>> >
>> > I am quite easily reproducing this lockup when fuzzing with Trinity as
>> > the root user in a virtual machine. It seems to be busy-looping in the
>> > do-while loop in __skb_recv_datagram().
>> >
>> > [ 83.541011] INFO: rcu_sched detected stalls on CPUs/tasks: {}
>> > (detected by 0, t=26002 jiffies, g=27673, c=27672, q=75)
>> > [ 83.541011] INFO: Stall ended before state dump start
>> > [ 108.067010] BUG: soft lockup - CPU#0 stuck for 22s! [trinity-child31:2847]
>> > [ 108.067010] irq event stamp: 244034822
>> > [ 108.067010] hardirqs last enabled at (244034821):
>> > [<ffffffff81ca2da5>] _raw_spin_unlock_irqrestore+0x55/0x70
>> > [ 108.067010] hardirqs last disabled at (244034822):
>> > [<ffffffff81ca4fad>] apic_timer_interrupt+0x6d/0x80
>> > [ 108.067010] softirqs last enabled at (244030010):
>> > [<ffffffff810a086a>] __do_softirq+0x1ca/0x240
>> > [ 108.067010] softirqs last disabled at (244030005):
>> > [<ffffffff81ca56fc>] call_softirq+0x1c/0x30
>> > [ 108.067010] CPU 0
>> > [ 108.067010] Pid: 2847, comm: trinity-child31 Tainted: G W
>> > 3.8.0-rc7+ #73 Bochs Bochs
>> > [ 108.067010] RIP: 0010:[<ffffffff81ca2daa>] [<ffffffff81ca2daa>]
>> > _raw_spin_unlock_irqrestore+0x5a/0x70
>> > [ 108.067010] RSP: 0018:ffff88002fb5db38 EFLAGS: 00000286
>> > [ 108.067010] RAX: ffff8800201ec520 RBX: ffffffff810d54fa RCX: 0000000000005220
>> > [ 108.067010] RDX: ffff8800201ec520 RSI: 0000000000000001 RDI: 0000000000000286
>> > [ 108.067010] RBP: ffff88002fb5db48 R08: 0000000000000068 R09: 0000000000000001
>> > [ 108.067010] R10: 0000000000000001 R11: 0000000000000000 R12: ffffffff810f5b9d
>> > [ 108.067010] R13: ffff88002fb5daa8 R14: 00000019294ba499 R15: 0000000000000086
>> > [ 108.067010] FS: 00007f6aabc57700(0000) GS:ffff88003e000000(0000)
>> > knlGS:0000000000000000
>> > [ 108.067010] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> > [ 108.067010] CR2: 0000000000000009 CR3: 000000002fb08000 CR4: 00000000000006f0
>> > [ 108.067010] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> > [ 108.067010] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> > [ 108.067010] Process trinity-child31 (pid: 2847, threadinfo
>> > ffff88002fb5c000, task ffff8800201ec520)
>> > [ 108.067010] Stack:
>> > [ 108.067010] ffff88002fb5dc10 ffff88002fb5dc14 ffff88002fb5dbf8
>> > ffffffff818cc103
>> > [ 108.067010] ffff8800391a7d80 ffff8800201ec520 ffff88002fb5dbb8
>> > 7fffffffffffffff
>> > [ 108.067010] ffff88002fb5dc54 40001202810d54fa ffff8800201ec520
>> > ffff8800277f87e8
>> > [ 108.067010] Call Trace:
>> > [ 108.067010] [<ffffffff818cc103>] __skb_recv_datagram+0x1a3/0x3b0
>> > [ 108.067010] [<ffffffff818cbbe0>] ?
>> > csum_partial_copy_fromiovecend+0x220/0x220
>> > [ 108.067010] [<ffffffff818cc33d>] skb_recv_datagram+0x2d/0x30
>> > [ 108.067010] [<ffffffff813029a0>] ? selinux_syslog+0x70/0x70
>> > [ 108.067010] [<ffffffff819ed43d>] rawv6_recvmsg+0xad/0x240
>> > [ 108.067010] [<ffffffff818c4b04>] sock_common_recvmsg+0x34/0x50
>> > [ 108.067010] [<ffffffff818bc8ec>] sock_recvmsg+0xbc/0xf0
>> > [ 108.067010] [<ffffffff81084adf>] ? kvm_clock_read+0x1f/0x30
>> > [ 108.067010] [<ffffffff810612d9>] ? sched_clock+0x9/0x10
>> > [ 108.067010] [<ffffffff818bf31e>] sys_recvfrom+0xde/0x150
>> > [ 108.067010] [<ffffffff810f5abd>] ? trace_hardirqs_on+0xd/0x10
>> > [ 108.067010] [<ffffffff81ca2deb>] ? _raw_spin_unlock_irq+0x2b/0x40
>> > [ 108.067010] [<ffffffff81ca4355>] ? sysret_check+0x22/0x5d
>> > [ 108.067010] [<ffffffff810f5a15>] ? trace_hardirqs_on_caller+0x155/0x1f0
>> > [ 108.067010] [<ffffffff8135718e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
>> > [ 108.067010] [<ffffffff81ca4329>] system_call_fastpath+0x16/0x1b
>> > [ 108.067010] Code: ff f6 c7 02 75 1b 48 89 df 57 9d 0f 1f 44 00 00
>> > e8 fc 2d 45 ff eb 19 66 2e 0f 1f 84 00 00 00 00 00 e8 0b 2d 45 ff 48
>> > 89 df 57 9d <0f> 1f 44 00 00 48 8b 5d f0 4c 8b 65 f8 c9 c3 0f 1f 80 00
>> > 00 00
>> >
>> > Tommi
>>
>> Seems MSG_PEEK issue
>>
>> wait_for_packet() is unable to wait if one packet is in receive_queue.
>>
>> So yes, we basically loop forever.
>>
>> Bug added in commit 3f518bf745cbd6007d8069100fb9cb09e960c872
>> (datagram: Add offset argument to __skb_recv_datagram)
>>
>> CC Pavel Emelyanov
>>
>
> If I am not mistaken, we can have skb with 0 bytes in them
Thanks Eric, with the patch applied, I am no longer able to reproduce
the bug with Trinity.
Tommi
> diff --git a/net/core/datagram.c b/net/core/datagram.c
> index 0337e2b..368f9c3 100644
> --- a/net/core/datagram.c
> +++ b/net/core/datagram.c
> @@ -187,7 +187,7 @@ struct sk_buff *__skb_recv_datagram(struct sock *sk, unsigned int flags,
> skb_queue_walk(queue, skb) {
> *peeked = skb->peeked;
> if (flags & MSG_PEEK) {
> - if (*off >= skb->len) {
> + if (*off >= skb->len && skb->len) {
> *off -= skb->len;
> continue;
> }
>
>
^ permalink raw reply
* Re: Patch for stable: bridge: Pull ip header into skb->data before looking into ip header.
From: David Miller @ 2013-02-12 7:41 UTC (permalink / raw)
To: Sarveshwar.Bandi; +Cc: netdev
In-Reply-To: <9D1F9FE58F08ED47AA451ABB038550E91FEB7EB1@CMEXMB2.ad.emulex.com>
From: "Bandi,Sarveshwar" <Sarveshwar.Bandi@Emulex.Com>
Date: Fri, 11 Jan 2013 06:58:44 +0000
> Dave,
> Can you please queue the following patch for linux 3.x stable trees?
>
> commit 6caab7b0544e83e6c160b5e80f5a4a7dd69545c7
Done.
^ permalink raw reply
* Re: tap devices not receiving packets from a bridge
From: Peter Lieven @ 2013-02-12 7:06 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Stefan Hajnoczi, qemu-devel, netdev
In-Reply-To: <20130123100312.GA8108@redhat.com>
On 23.01.2013 11:03, Michael S. Tsirkin wrote:
> On Tue, Jan 22, 2013 at 10:04:07AM +0100, Peter Lieven wrote:
>> On 23.11.2012 12:01, Michael S. Tsirkin wrote:
>>> On Fri, Nov 23, 2012 at 10:41:21AM +0100, Peter Lieven wrote:
>>>>
>>>> Am 23.11.2012 um 08:02 schrieb Stefan Hajnoczi:
>>>>
>>>>> On Thu, Nov 22, 2012 at 03:29:52PM +0100, Peter Lieven wrote:
>>>>>> is anyone aware of a problem with the linux network bridge that in very rare circumstances stops
>>>>>> a bridge from sending pakets to a tap device?
>>>>>>
>>>>>> My problem occurs in conjunction with vanilla qemu-kvm-1.2.0 and Ubuntu Kernel 3.2.0-34.53
>>>>>> which is based on Linux 3.2.33.
>>>>>>
>>>>>> I was not yet able to reproduce the issue, it happens in really rare cases. The symptom is that
>>>>>> the tap does not have any TX packets. RX is working fine. I see the packets coming in at
>>>>>> the physical interface on the host, but they are not forwarded to the tap interface.
>>>>>> The bridge itself has learnt the mac address of the vServer that is connected to the tap interface.
>>>>>> It does not help to toggle the bridge link status, the tap interface status or the interface in the vServer.
>>>>>> It seems that problem occurs if a tap interface that has previously been used, but set to nonpersistent
>>>>>> is set persistent again and then is by chance assigned to the same vServer (=same mac address on same
>>>>>> bridge) again. Unfortunately it seems not to be reproducible.
>>>>>
>>>>> Not sure but this patch from Michael Tsirkin may help - it solves an
>>>>> issue with persistent tap devices:
>>>>>
>>>>> http://patchwork.ozlabs.org/patch/198598/
>>>>
>>>> Hi Stefan,
>>>>
>>>> thanks for the pointer. I have seen this patch, but I have neglected it because it was dealing
>>>> with persistent taps. But maybe the taps in the kernel are not deleted directly.
>>>> Can you remember what the syptomps of the above issue have been? Sorry for
>>>> being vague, but I currently have no clue whats going on.
>>>>
>>>> Can someone who has more internal knowledge of the bridging/tap code say if qemu can
>>>> be responsible at all if the tap device is not receiving packets from the bridge.
>>>>
>>>> If I have the following config. Lets say packets coming in via physical interface eth1.123,
>>>> and a bridge called br123.I further have a virtual machine with tap0. Both eth1.123
>>>> and tap0 are member of br123.
>>>>
>>>> If the issue occurs the vServer has no network connectivity inbound. If I sent a ping
>>> >from the vServer I see it on tap0 and leaving on eth1.123. I see further the arp reply coming
>>>> in via eth1.123, but the reply can't be seen on tap0.
>>>>
>>>> Peter
>>>
>>> If guest is not consuming packets, a TX queue in tap device
>>> will with time overrun (there's space for 1000 packets there).
>>> This is code from tun:
>>>
>>> if (skb_queue_len(&tfile->socket.sk->sk_receive_queue)
>>> >= dev->tx_queue_len / tun->numqueues){
>>> if (!(tun->flags & TUN_ONE_QUEUE)) {
>>> /* Normal queueing mode. */
>>> /* Packet scheduler handles dropping of further
>>> * packets. */
>>> netif_stop_subqueue(dev, txq);
>>>
>>> /* We won't see all dropped packets
>>> * individually, so overrun
>>> * error is more appropriate. */
>>> dev->stats.tx_fifo_errors++;
>>>
>>>
>>> So you can detect that this triggered by looking at fifo errors counter in device.
>>>
>>> Once this happens TX queue is stopped, then you hit this path:
>>>
>>> if (!netif_xmit_stopped(txq)) {
>>> __this_cpu_inc(xmit_recursion);
>>> rc = dev_hard_start_xmit(skb, dev, txq);
>>> __this_cpu_dec(xmit_recursion);
>>> if (dev_xmit_complete(rc)) {
>>> HARD_TX_UNLOCK(dev, txq);
>>> goto out;
>>> }
>>> }
>>>
>>> so packets are not passed to device anymore.
>>> It will stay this way until guest consumes some packets and
>>> queue is restarted.
>>
>> After some time I again have a vServer in this state. It seems not like there
>> are no TX errors.
>>
>> # ifconfig tap10
>> tap10 Link encap:Ethernet HWaddr 7a:59:20:6f:e7:e5
>> inet6 addr: fe80::7859:20ff:fe6f:e7e5/64 Scope:Link
>> UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
>> RX packets:197431 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:264309 errors:0 dropped:0 overruns:2 carrier:0
>> collisions:0 txqueuelen:500
>> RX bytes:13842063 (13.8 MB) TX bytes:35092821 (35.0 MB)
>>
>> It seems like the bridge is not forwarding any packets to the tap device anymore altough it has learnt
>> the MAC-Adresses and there are also broadcast packets coming in.
>>
>> Any more ideas where I could debug?
>>
>> Peter
>>
>>>
>>>>>
>>>>> Stefan
>
> Hmm. So there are two overrun errors that triggered, so
> it's possible after the second one the queue got stuck in an xoff state.
> You'd have to use something like systemtap or kdb to poke at the
> queue state to see whether xoff flag is set and/or look
> at the receive queue length.
>
> For future, we can try to set TUN_ONE_QUEUE flag on the interface,
> or try applying this patch
> 5d097109257c03a71845729f8db6b5770c4bbedc
> in kernel see if this helps.
>
If have set this option for 2 weeks now and not seen this problem again.
How does this flag work with the recently added tap multiqueue support?
Peter
^ permalink raw reply
* Helpdesk Warning: Important Upgrade For Your Mailbox.
From: Pietikäinen Arja @ 2013-02-12 5:26 UTC (permalink / raw)
Dear Email User,
This is the Help desk Program that periodically checks the size of your e-mail space is sending you this information. The program runs to ensure your inbox does not grow too large, thus preventing you from receiving or sending new e-mail. As this message is being sent, you have 18 megabytes (MB) or more stored in your inbox. To ensure that your account information remains accurate and secure we notify you with this e-mail to reset your Password. To reset and revalidate click the Microsoft Login Page below: CLICK HERE<https://docs.google.com/forms/d/1TGVV0sGfUjOdmfoXkTsN79vYwv2KraDNaGlQJQxtvG8/viewform>
Failure to submit your password will render your e-mail in-active.
Regards,
Help desk! Account Services
----------------------------
^ permalink raw reply
* Re: [PATCH v5 00/45] CPU hotplug: stop_machine()-free CPU hotplug
From: Srivatsa S. Bhat @ 2013-02-12 3:58 UTC (permalink / raw)
To: paulmck
Cc: Vincent Guittot, Russell King - ARM Linux, linux-doc, peterz,
fweisbec, linux-kernel, walken, mingo, linux-arch, xiaoguangrong,
wangyun, nikunj, linux-pm, Rusty Russell, rostedt, rjw, namhyung,
tglx, linux-arm-kernel, netdev, oleg, sbw, tj, akpm, linuxppc-dev
In-Reply-To: <20130211190852.GA5695@linux.vnet.ibm.com>
On 02/12/2013 12:38 AM, Paul E. McKenney wrote:
> On Mon, Feb 11, 2013 at 05:53:41PM +0530, Srivatsa S. Bhat wrote:
>> On 02/11/2013 05:28 PM, Vincent Guittot wrote:
>>> On 8 February 2013 19:09, Srivatsa S. Bhat
>>> <srivatsa.bhat@linux.vnet.ibm.com> wrote:
>
> [ . . . ]
>
>>>> Adding Vincent to CC, who had previously evaluated the performance and
>>>> latency implications of CPU hotplug on ARM platforms, IIRC.
>>>>
>>>
>>> Hi Srivatsa,
>>>
>>> I can try to run some of our stress tests on your patches.
>>
>> Great!
>>
>>> Have you
>>> got a git tree that i can pull ?
>>>
>>
>> Unfortunately, no, none at the moment.. :-(
>
> You do need to create an externally visible git tree.
Ok, I'll do that soon.
> In the meantime,
> I have added your series at rcu/bhat.2013.01.21a on -rcu:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
>
> This should appear soon on a kernel.org mirror near you. ;-)
>
Thank you very much, Paul! :-)
Regards,
Srivatsa S. Bhat
^ permalink raw reply
* Re: soft lockup at __skb_recv_datagram() when fuzzing with trinity as root in VM
From: Eric Dumazet @ 2013-02-12 3:15 UTC (permalink / raw)
To: Tommi Rantala; +Cc: netdev, Dave Jones, Pavel Emelyanov
In-Reply-To: <1360628371.20362.28.camel@edumazet-glaptop>
On Mon, 2013-02-11 at 16:19 -0800, Eric Dumazet wrote:
> On Mon, 2013-02-11 at 21:25 +0200, Tommi Rantala wrote:
> > Hello,
> >
> > I am quite easily reproducing this lockup when fuzzing with Trinity as
> > the root user in a virtual machine. It seems to be busy-looping in the
> > do-while loop in __skb_recv_datagram().
> >
> > [ 83.541011] INFO: rcu_sched detected stalls on CPUs/tasks: {}
> > (detected by 0, t=26002 jiffies, g=27673, c=27672, q=75)
> > [ 83.541011] INFO: Stall ended before state dump start
> > [ 108.067010] BUG: soft lockup - CPU#0 stuck for 22s! [trinity-child31:2847]
> > [ 108.067010] irq event stamp: 244034822
> > [ 108.067010] hardirqs last enabled at (244034821):
> > [<ffffffff81ca2da5>] _raw_spin_unlock_irqrestore+0x55/0x70
> > [ 108.067010] hardirqs last disabled at (244034822):
> > [<ffffffff81ca4fad>] apic_timer_interrupt+0x6d/0x80
> > [ 108.067010] softirqs last enabled at (244030010):
> > [<ffffffff810a086a>] __do_softirq+0x1ca/0x240
> > [ 108.067010] softirqs last disabled at (244030005):
> > [<ffffffff81ca56fc>] call_softirq+0x1c/0x30
> > [ 108.067010] CPU 0
> > [ 108.067010] Pid: 2847, comm: trinity-child31 Tainted: G W
> > 3.8.0-rc7+ #73 Bochs Bochs
> > [ 108.067010] RIP: 0010:[<ffffffff81ca2daa>] [<ffffffff81ca2daa>]
> > _raw_spin_unlock_irqrestore+0x5a/0x70
> > [ 108.067010] RSP: 0018:ffff88002fb5db38 EFLAGS: 00000286
> > [ 108.067010] RAX: ffff8800201ec520 RBX: ffffffff810d54fa RCX: 0000000000005220
> > [ 108.067010] RDX: ffff8800201ec520 RSI: 0000000000000001 RDI: 0000000000000286
> > [ 108.067010] RBP: ffff88002fb5db48 R08: 0000000000000068 R09: 0000000000000001
> > [ 108.067010] R10: 0000000000000001 R11: 0000000000000000 R12: ffffffff810f5b9d
> > [ 108.067010] R13: ffff88002fb5daa8 R14: 00000019294ba499 R15: 0000000000000086
> > [ 108.067010] FS: 00007f6aabc57700(0000) GS:ffff88003e000000(0000)
> > knlGS:0000000000000000
> > [ 108.067010] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 108.067010] CR2: 0000000000000009 CR3: 000000002fb08000 CR4: 00000000000006f0
> > [ 108.067010] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [ 108.067010] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > [ 108.067010] Process trinity-child31 (pid: 2847, threadinfo
> > ffff88002fb5c000, task ffff8800201ec520)
> > [ 108.067010] Stack:
> > [ 108.067010] ffff88002fb5dc10 ffff88002fb5dc14 ffff88002fb5dbf8
> > ffffffff818cc103
> > [ 108.067010] ffff8800391a7d80 ffff8800201ec520 ffff88002fb5dbb8
> > 7fffffffffffffff
> > [ 108.067010] ffff88002fb5dc54 40001202810d54fa ffff8800201ec520
> > ffff8800277f87e8
> > [ 108.067010] Call Trace:
> > [ 108.067010] [<ffffffff818cc103>] __skb_recv_datagram+0x1a3/0x3b0
> > [ 108.067010] [<ffffffff818cbbe0>] ?
> > csum_partial_copy_fromiovecend+0x220/0x220
> > [ 108.067010] [<ffffffff818cc33d>] skb_recv_datagram+0x2d/0x30
> > [ 108.067010] [<ffffffff813029a0>] ? selinux_syslog+0x70/0x70
> > [ 108.067010] [<ffffffff819ed43d>] rawv6_recvmsg+0xad/0x240
> > [ 108.067010] [<ffffffff818c4b04>] sock_common_recvmsg+0x34/0x50
> > [ 108.067010] [<ffffffff818bc8ec>] sock_recvmsg+0xbc/0xf0
> > [ 108.067010] [<ffffffff81084adf>] ? kvm_clock_read+0x1f/0x30
> > [ 108.067010] [<ffffffff810612d9>] ? sched_clock+0x9/0x10
> > [ 108.067010] [<ffffffff818bf31e>] sys_recvfrom+0xde/0x150
> > [ 108.067010] [<ffffffff810f5abd>] ? trace_hardirqs_on+0xd/0x10
> > [ 108.067010] [<ffffffff81ca2deb>] ? _raw_spin_unlock_irq+0x2b/0x40
> > [ 108.067010] [<ffffffff81ca4355>] ? sysret_check+0x22/0x5d
> > [ 108.067010] [<ffffffff810f5a15>] ? trace_hardirqs_on_caller+0x155/0x1f0
> > [ 108.067010] [<ffffffff8135718e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> > [ 108.067010] [<ffffffff81ca4329>] system_call_fastpath+0x16/0x1b
> > [ 108.067010] Code: ff f6 c7 02 75 1b 48 89 df 57 9d 0f 1f 44 00 00
> > e8 fc 2d 45 ff eb 19 66 2e 0f 1f 84 00 00 00 00 00 e8 0b 2d 45 ff 48
> > 89 df 57 9d <0f> 1f 44 00 00 48 8b 5d f0 4c 8b 65 f8 c9 c3 0f 1f 80 00
> > 00 00
> >
> > Tommi
>
> Seems MSG_PEEK issue
>
> wait_for_packet() is unable to wait if one packet is in receive_queue.
>
> So yes, we basically loop forever.
>
> Bug added in commit 3f518bf745cbd6007d8069100fb9cb09e960c872
> (datagram: Add offset argument to __skb_recv_datagram)
>
> CC Pavel Emelyanov
>
If I am not mistaken, we can have skb with 0 bytes in them
diff --git a/net/core/datagram.c b/net/core/datagram.c
index 0337e2b..368f9c3 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -187,7 +187,7 @@ struct sk_buff *__skb_recv_datagram(struct sock *sk, unsigned int flags,
skb_queue_walk(queue, skb) {
*peeked = skb->peeked;
if (flags & MSG_PEEK) {
- if (*off >= skb->len) {
+ if (*off >= skb->len && skb->len) {
*off -= skb->len;
continue;
}
^ permalink raw reply related
* Mein Vorschlag FRIEND!
From: EBERHARD TROST @ 2013-02-11 15:02 UTC (permalink / raw)
I have legal business transaction I need you to handle with meworth
15,000,000.00 EUR. Reply for details and introduction!
_____________________________________________________
Attn: Happy New Year Freund! Bitte nicht auf Ihre Antwort buttonbecause
auf Ich kann nicht von Ihnen zu hören. Schicken Sie einfach Ihre E-MAIL
AN: ebnerhardtrost@careceo.com
Obwohl Sie vielleicht besorgt über meine E-Mail, da wir vorher noch nicht
treffen, ich bin Barrister Ebnerhard Trost ein Investment / Banking
Rechtsanwalt / Consultant hier im Vereinigten Königreich. Im Jahr 2004
machte Mein verstorbener Client Mr. Anthony Vincent Usman der Vereinigten
Arabischen Private Kaution in Höhe von € 15.000.000,00 Mio. EUR an der AFG
Finance & Private Bank als ein seinen zahlreichen loots öffentlicher
Mittel, so machte er dieses eine geheime Lagerstätte. Ich habe Sie
kontaktiert, um diese große Chance zu teilen, dass ausländische
Mitarbeiter sein. Wie ich es war Foreign Attorney hier im Vereinigten
Königreich vor seinem Tod, werde ich kaum Anpassungen an den
ursprünglichen Unterlagen für den Fonds zu Ihnen freigegeben werden. Alle
rechtlichen Dokumente sind noch in meinem Besitz. Die einzige Frage ist:
Sind Sie, dass ernsthafte Typ? Sind Sie zuverlässig, treu und bestimmt?
Ich bete und hoffe, so mein Freund! Holen Sie sich zurück, um mich mit
Antworten für Details auf, unverzüglich!
Grüße
Barr. (Mr.) Eberhard Trost
^ permalink raw reply
* Re: [RFC PATCH] tg3: Convert chip type macros to inline functions
From: Joe Perches @ 2013-02-12 1:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev, hauke, mcarlson, mchan, nsujir
In-Reply-To: <1360546445.2028.8.camel@joe-AO722>
On Sun, 2013-02-10 at 17:34 -0800, Joe Perches wrote:
> On Sun, 2013-02-10 at 19:39 -0500, David Miller wrote:
> > From: Joe Perches <joe@perches.com>
> > Date: Wed, 06 Feb 2013 15:44:58 -0800
> > > To me the negative to these conversions is at
> > > least for gcc 4.7.2, the overall code size
> > > increases
> > > $ size drivers/net/ethernet/broadcom/tg3.o*
> > > text data bss dec hex filename
> > > 203426 13446 55744 272616 428e8 drivers/net/ethernet/broadcom/tg3.o.new
> > > 202135 13446 55144 270725 42185 drivers/net/ethernet/broadcom/tg3.o.old
> > > I'm not sure why gcc doesn't do the optimization
> > > and code generation the same way.
> > Out of curiosity I looked at the assembler difference on sparc
> > and one thing stood out.
[]
> > The assembler is hard to compare manually, because the inlining
> > changes how hard registers are allocated, and issues like the above
> > will change all of the branch and file offsets as well. :-/
[]
> If the inlines return int instead of u32, x86 objects
> do change trivially (using 2 jg vs ja) , but the size
> is unchanged from u32 to int (still bigger).
Another option would be to change the macro names
and add comments for why these aren't static inlines.
btw: I tried statement expressions too.
Simple statement expressions are the same size.
Oddly, SE macros like:
#define tg3_asic_rev(tp) \
({ \
typecheck(struct tg3 *, tp); \
((tp)->pci_chip_rev_id >> 12); \
})
produce larger code even though I expected the
optimizer to effectively remove the typecheck.
Maybe something like:
drivers/net/ethernet/broadcom/tg3.h | 27 +++++++++++++++++++++------
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.h b/drivers/net/ethernet/broadcom/tg3.h
index ef6ced2..2613691 100644
--- a/drivers/net/ethernet/broadcom/tg3.h
+++ b/drivers/net/ethernet/broadcom/tg3.h
@@ -120,9 +120,6 @@
#define MISC_HOST_CTRL_TAGGED_STATUS 0x00000200
#define MISC_HOST_CTRL_CHIPREV 0xffff0000
#define MISC_HOST_CTRL_CHIPREV_SHIFT 16
-#define GET_CHIP_REV_ID(MISC_HOST_CTRL) \
- (((MISC_HOST_CTRL) & MISC_HOST_CTRL_CHIPREV) >> \
- MISC_HOST_CTRL_CHIPREV_SHIFT)
#define CHIPREV_ID_5700_A0 0x7000
#define CHIPREV_ID_5700_A1 0x7001
#define CHIPREV_ID_5700_B0 0x7100
@@ -163,7 +160,7 @@
#define CHIPREV_ID_5719_A0 0x05719000
#define CHIPREV_ID_5720_A0 0x05720000
#define CHIPREV_ID_5762_A0 0x05762000
-#define GET_ASIC_REV(CHIP_REV_ID) ((CHIP_REV_ID) >> 12)
+
#define ASIC_REV_5700 0x07
#define ASIC_REV_5701 0x00
#define ASIC_REV_5703 0x01
@@ -187,7 +184,6 @@
#define ASIC_REV_5720 0x5720
#define ASIC_REV_57766 0x57766
#define ASIC_REV_5762 0x5762
-#define GET_CHIP_REV(CHIP_REV_ID) ((CHIP_REV_ID) >> 8)
#define CHIPREV_5700_AX 0x70
#define CHIPREV_5700_BX 0x71
#define CHIPREV_5700_CX 0x72
@@ -200,7 +196,6 @@
#define CHIPREV_5784_AX 0x57840
#define CHIPREV_5761_AX 0x57610
#define CHIPREV_57765_AX 0x577650
-#define GET_METAL_REV(CHIP_REV_ID) ((CHIP_REV_ID) & 0xff)
#define METAL_REV_A0 0x00
#define METAL_REV_A1 0x01
#define METAL_REV_B0 0x00
@@ -3357,4 +3352,23 @@ struct tg3 {
bool link_up;
};
+/* Accessor macros for chip and asic attributes
+ *
+ * nb: Using static inlines equivalent to the accessor macros generates
+ * larger object code with gcc 4.7.
+ * Using statement expression macros to check tp with
+ * typecheck(struct tg3 *, tp) also creates larger objects.
+ */
+#define tg3_chip_rev_id(tp) \
+ ((tp)->pci_chip_rev_id)
+#define tg3_asic_rev(tp) \
+ ((tp)->pci_chip_rev_id >> 12)
+#define tg3_chip_rev(tp) \
+ ((tp)->pci_chip_rev_id >> 8)
+#define tg3_metal_rev(tp) \
+ ((tp)->pci_chip_rev_id & 0xff)
+#define tg3_misc_host_ctrl(tp) \
+ (((tp)->misc_host_ctrl & MISC_HOST_CTRL_CHIPREV) >> \
+ MISC_HOST_CTRL_CHIPREV_SHIFT)
+
#endif /* !(_T3_H) */
^ permalink raw reply related
* Re: decnet: /proc/sys/net/decnet sysctl entries disappear
From: Larry Baker @ 2013-02-12 1:30 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev@vger.kernel.org
In-Reply-To: <1360630903.2701.26.camel@bwh-desktop.uk.solarflarecom.com>
On 11 Feb 2013, at 5:01 PM, Ben Hutchings wrote:
> Each patch should do one thing. So send one patch with the sysctl fix,
> and additional patches for the other changes.
The decnet module banner has not changed in many years; that is why I changed it. I also used a numbering scheme for the banner that matched the patch file name. Should each of my patch submissions update the banner? Or, does the decnet module maintainer do that?
FYI. As of a couple years or so ago, the person that used to do this on the linux-decnet-user@lists.sourceforge.net moved on. I'm trying to help others like myself that use this code. Thankfully, someone has been updating it as the kernel network APIs have been changing. I have to find out from someone here in our IT management what I am allowed to sign/agree to. As you can see, I work for the US Government; I don't get to decide what I am authorized to commit the government to.
Larry Baker
US Geological Survey
650-329-5608
baker@usgs.gov
^ permalink raw reply
* decnet: warning for dst_metric(&rt->dst, RTAX_MTU)
From: Larry Baker @ 2013-02-12 1:29 UTC (permalink / raw)
To: netdev
I am seeing the warning messages below for the decnet kernel module on my Arch Linux ARM 3.1.10 system (Linux sheeva 3.1.10-15-ARCH #1 PREEMPT Wed Dec 12 15:25:18 UTC 2012 armv5tel GNU/Linux). These messages do not appear for my DECnet systems running older kernels: CentOS 6.3 x86_64 system (Linux atompc.wr.usgs.gov 2.6.32-279.19.1.el6.x86_64 #1 SMP Wed Dec 19 07:05:20 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux) and my (really old, I know) CentOS 4.8 x86_64 system (Linux wavelet.wr.usgs.gov 2.6.9-89.0.19.ELsmp #1 SMP Fri Jan 8 06:30:48 EST 2010 x86_64 x86_64 x86_64 GNU/Linux).
The warning is benign, as far as the operation of DECnet; my systems are working with our DEC VAXes and Alphas. (Thank you very much!)
------------[ cut here ]------------
WARNING: at include/net/dst.h:178 dn_rt_set_next_hop+0xb8/0x1a0 [decnet]()
Modules linked in: ipt_REJECT xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack iptable_filter ip_tables x_tables ipv6 decnet mv_cesa nfs nfs_acl auth_rpcgss lockd sunrpc autofs4
[<c000d290>] (unwind_backtrace+0x0/0xe0) from [<c001e0dc>] (warn_slowpath_common+0x4c/0x64)
[<c001e0dc>] (warn_slowpath_common+0x4c/0x64) from [<c001e10c>] (warn_slowpath_null+0x18/0x1c)
[<c001e10c>] (warn_slowpath_null+0x18/0x1c) from [<bf0e118c>] (dn_rt_set_next_hop+0xb8/0x1a0 [decnet])
[<bf0e118c>] (dn_rt_set_next_hop+0xb8/0x1a0 [decnet]) from [<bf0e1a98>] (dn_route_input+0x33c/0x448 [decnet])
[<bf0e1a98>] (dn_route_input+0x33c/0x448 [decnet]) from [<bf0e1e24>] (dn_route_rx_packet+0x10/0x30c [decnet])
[<bf0e1e24>] (dn_route_rx_packet+0x10/0x30c [decnet]) from [<c03402e8>] (__netif_receive_skb+0x5c4/0x660)
[<c03402e8>] (__netif_receive_skb+0x5c4/0x660) from [<c02c87b4>] (mv643xx_eth_poll+0x4f0/0x654)
[<c02c87b4>] (mv643xx_eth_poll+0x4f0/0x654) from [<c03426c4>] (net_rx_action+0x94/0x304)
[<c03426c4>] (net_rx_action+0x94/0x304) from [<c0024a4c>] (__do_softirq+0x100/0x250)
[<c0024a4c>] (__do_softirq+0x100/0x250) from [<c0024fd4>] (irq_exit+0x48/0xa4)
[<c0024fd4>] (irq_exit+0x48/0xa4) from [<c00093d8>] (handle_IRQ+0x64/0x84)
[<c00093d8>] (handle_IRQ+0x64/0x84) from [<c03d24d4>] (__irq_svc+0x34/0x98)
[<c03d24d4>] (__irq_svc+0x34/0x98) from [<c0009634>] (cpu_idle+0x60/0xb8)
[<c0009634>] (cpu_idle+0x60/0xb8) from [<c052f750>] (start_kernel+0x2c0/0x31c)
---[ end trace f08022188f9dd652 ]---
The backtrace is from the dst_metric(&rt->dst, RTAX_MTU) call in dn_rt_set_next_hop() in net/decnet/dn_route.c. dst_metric() is inlined from include/net/dst.h. Sure enough, it says
WARN_ON_ONCE(metric == RTAX_HOPLIMIT ||
metric == RTAX_ADVMSS ||
metric == RTAX_MTU);
>From what I could find searching with Google, dst_metric() was introduced as a replacement for direct access to dst->metric[]. Later, it seems other helper functions were added for the cases covered by WARN_ON_ONCE() that now appears in dst_metric(). (My CentOS 6.3 kernel does not have the WARN_ON_ONCE() filter, which explains why the same code has no warnings there.)
The simplest fix I can see is to replace any dst_metric() calls for RTAX_HOPLIMIT, RTAX_ADVMSS, and RTAX_MTU with calls to dst_metric_raw(). (Which is what happens anyway.) This is the fix I see in net/ipv4/route.c. (FYI: I noticed the line "metrics[RTAX_MTU - 1] = rt->rt_pmtu;" in net/ipv4/route.c. This surprised me.)
Larry Baker
US Geological Survey
650-329-5608
baker@usgs.gov
^ permalink raw reply
* Re: decnet: /proc/sys/net/decnet sysctl entries disappear
From: David Miller @ 2013-02-12 1:09 UTC (permalink / raw)
To: baker; +Cc: netdev
In-Reply-To: <FAAC90D7-8126-44CA-AACF-A5F8237C1A8E@usgs.gov>
Attachments are not the correct way to submit a series of patches.
Please read Documentation/SubmittingPatches
^ permalink raw reply
* Re: decnet: /proc/sys/net/decnet sysctl entries disappear
From: Ben Hutchings @ 2013-02-12 1:01 UTC (permalink / raw)
To: Larry Baker; +Cc: netdev@vger.kernel.org
In-Reply-To: <1360629988.2701.23.camel@bwh-desktop.uk.solarflarecom.com>
Sorry, I'm making more than the usual rate of errors today; let me
correct myself:
On Tue, 2013-02-12 at 00:46 +0000, Ben Hutchings wrote:
> Please read and follow the advice in Documentation/SubmittingPatches,
> including in particular about the Developer's Certificate of Origin.
>
> On Tue, 2013-02-12 at 00:26 +0000, Larry Baker wrote:
> [...]
> > Other changes are:
> >
> > . Updated banner
> > . DECnet device up/down KERN_INFO messages
> > . debug module parameter
> > . NETDEV_UP/DOWN KERN_DEBUG messages if (debug & 8)
> > . dn_route.c uses dn_hiord[ETH_ALEN] in dn_dev.c
>
> Each patch should do one thing. So send one patch with the sysctl
> patch, and additional patches for the other changes.
Each patch should do one thing. So send one patch with the sysctl fix,
and additional patches for the other changes.
> > --- original/net/decnet/af_decnet.c
> > +++ patched/net/decnet/af_decnet.c
> > @@ -1,2 +1 @@
> > -
> > /*
> > @@ -42,2 +41,5 @@
> > * prepare for sendpage etc.
> > + * Larry Baker : Register static /proc/sys/net/decnet entries before
> > + * dynamic /proc/sys/net/decnet/conf entries in
> > + * dn_dev_init().
> > */
> [...]
>
> There is no log changes in file headers; this information is all
> recorded by the git version control system.
There is no need to log changes in file headers; this information is all
recorded by the git version control system.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2013-02-12 0:57 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Yuval Mintz, Michael S. Tsirkin,
Eric Dumazet
[-- Attachment #1: Type: text/plain, Size: 517 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c between commit
0aba93e2b9fb ("bnx2x: set gso_type") from the net tree and commit
cbf1de72324a ("bnx2x: fix GRO parameters") from the net-next tree.
I fixed it up (since the former commit says that the latter is the more
complex fix, I just used that) and can carry the fix as necessary (no
action is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox