* Re: [PATCH] bridge: assign random address
From: Andrew Morton @ 2007-12-12 0:02 UTC (permalink / raw)
To: Stephen Hemminger
Cc: davem, netdev, bugme-daemon, berrange, jeff, herbert, rjw
In-Reply-To: <20071211154835.75ace6bc@freepuppy.rosehill>
On Tue, 11 Dec 2007 15:48:35 -0800
Stephen Hemminger <shemminger@linux-foundation.org> wrote:
> Assigning a valid random address to bridge device solves problems
> when bridge device is brought up before adding real device to bridge.
> When the first real device is added to the bridge, it's address
> will overide the bridges random address.
>
> Note: any device added to a bridge must already have a valid
> ethernet address.
> br_add_if -> br_fdb_insert -> fdb_insert -> is_valid_ether_addr
>
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
>
> --- a/net/bridge/br_device.c 2007-10-16 16:48:21.000000000 -0700
> +++ b/net/bridge/br_device.c 2007-12-11 15:36:52.000000000 -0800
> @@ -157,8 +157,7 @@ static struct ethtool_ops br_ethtool_ops
>
> void br_dev_setup(struct net_device *dev)
> {
> - memset(dev->dev_addr, 0, ETH_ALEN);
> -
> + random_ether_addr(dev->dev_addr);
> ether_setup(dev);
>
> dev->do_ioctl = br_dev_ioctl;
I'd have thought that a comment is needed here as it is rather unobvious
what that code is there for.
^ permalink raw reply
* [PATCH] bridge: assign random address
From: Stephen Hemminger @ 2007-12-11 23:48 UTC (permalink / raw)
To: Andrew Morton, David S. Miller
Cc: netdev, bugme-daemon, berrange, jeff, herbert, rjw
In-Reply-To: <20071211145921.11094ab8.akpm@linux-foundation.org>
Assigning a valid random address to bridge device solves problems
when bridge device is brought up before adding real device to bridge.
When the first real device is added to the bridge, it's address
will overide the bridges random address.
Note: any device added to a bridge must already have a valid
ethernet address.
br_add_if -> br_fdb_insert -> fdb_insert -> is_valid_ether_addr
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/net/bridge/br_device.c 2007-10-16 16:48:21.000000000 -0700
+++ b/net/bridge/br_device.c 2007-12-11 15:36:52.000000000 -0800
@@ -157,8 +157,7 @@ static struct ethtool_ops br_ethtool_ops
void br_dev_setup(struct net_device *dev)
{
- memset(dev->dev_addr, 0, ETH_ALEN);
-
+ random_ether_addr(dev->dev_addr);
ether_setup(dev);
dev->do_ioctl = br_dev_ioctl;
^ permalink raw reply
* Re: [PATCH] [NET]: Fix Ooops of napi net_rx_action.
From: Stephen Hemminger @ 2007-12-11 23:42 UTC (permalink / raw)
To: Joonwoo Park
Cc: Brandeburg, Jesse, David Miller, netdev, linux-kernel, herbert,
Kok, Auke-jan H
In-Reply-To: <b25c3fa70712111527p561b3e2i24ee0fdf3d61a98c@mail.gmail.com>
Perhaps we should change the warning to identify the guilty device.
--- a/net/core/dev.c 2007-11-19 09:09:57.000000000 -0800
+++ b/net/core/dev.c 2007-12-07 15:54:03.000000000 -0800
@@ -2196,7 +2196,13 @@ static void net_rx_action(struct softirq
if (test_bit(NAPI_STATE_SCHED, &n->state))
work = n->poll(n, weight);
- WARN_ON_ONCE(work > weight);
+ if (unlikely(work > weight)) {
+ if (net_ratelimit())
+ printk(KERN_WARNING
+ "%s: driver poll bug (work=%d weight=%d)\n",
+ work, weight);
+ work = weight;
+ }
budget -= work;
^ permalink raw reply
* delay via-rhine irq initialisation.
From: Dave Jones @ 2007-12-11 23:39 UTC (permalink / raw)
To: netdev
With CONFIG_DEBUG_SHIRQ set, via-rhine complains during init.
(See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=377721 for a report).
Does this diff look right?
(I don't have a via-rhine handy to test with)
We may be able to get away with moving the request_irq to just after the
alloc_tbufs(), but I feel if a real interrupt occured, this diff would
stand more chance of doing the right thing.
Comments?
Dave
Delay irq registration until after we've allocated ring buffers,
otherwise DEBUG_SHIRQ will complain.
Signed-off-by: Dave Jones <davej@redhat.com>
diff --git a/drivers/net/via-rhine.c b/drivers/net/via-rhine.c
index 07263cd..37b3efb 100644
--- a/drivers/net/via-rhine.c
+++ b/drivers/net/via-rhine.c
@@ -1151,24 +1151,28 @@ static int rhine_open(struct net_device *dev)
void __iomem *ioaddr = rp->base;
int rc;
- rc = request_irq(rp->pdev->irq, &rhine_interrupt, IRQF_SHARED, dev->name,
- dev);
- if (rc)
- return rc;
-
if (debug > 1)
printk(KERN_DEBUG "%s: rhine_open() irq %d.\n",
dev->name, rp->pdev->irq);
rc = alloc_ring(dev);
- if (rc) {
- free_irq(rp->pdev->irq, dev);
+ if (rc)
return rc;
- }
+
alloc_rbufs(dev);
alloc_tbufs(dev);
rhine_chip_reset(dev);
init_registers(dev);
+
+ rc = request_irq(rp->pdev->irq, &rhine_interrupt, IRQF_SHARED, dev->name,
+ dev);
+ if (rc) {
+ free_rbufs(dev);
+ free_tbufs(dev);
+ free_ring(dev);
+ return rc;
+ }
+
if (debug > 2)
printk(KERN_DEBUG "%s: Done rhine_open(), status %4.4x "
"MII status: %4.4x.\n",
--
http://www.codemonkey.org.uk
^ permalink raw reply related
* Re: [PATCH resent] virtio_net: Fix stalled inbound trafficon early packets
From: Dor Laor @ 2007-12-11 23:34 UTC (permalink / raw)
To: Christian Borntraeger
Cc: kvm-devel, netdev-u79uwXL29TY76Z2rM5mHXA,
virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
In-Reply-To: <200712111627.21364.borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
Christian Borntraeger wrote:
> Am Dienstag, 11. Dezember 2007 schrieb Christian Borntraeger:
>
>>> The way other physical NICs doing it is by dis/en/abling interrupt
>>> using registers (look at e1000).
>>> I suggest we can export add_status and use the original code but
>>> before enabling napi add a call to add_status(dev,
>>> VIRTIO_CONFIG_DEV_OPEN).
>>> The host won't trigger an irq until it sees the above.
>>>
>> That would also work. We already have VRING_AVAIL_F_NO_INTERRUPT in
>> virtio_ring.c - maybe we can use that. Its hidden in callback and
>> restart handling, what about adding an explicit startup?
>>
>
> Ok, just to give an example what I thought about:
> ---
> drivers/block/virtio_blk.c | 3 ++-
> drivers/net/virtio_net.c | 2 ++
> drivers/virtio/virtio_ring.c | 16 +++++++++++++---
> include/linux/virtio.h | 5 +++++
> 4 files changed, 22 insertions(+), 4 deletions(-)
>
> Index: kvm/drivers/virtio/virtio_ring.c
> ===================================================================
> --- kvm.orig/drivers/virtio/virtio_ring.c
> +++ kvm/drivers/virtio/virtio_ring.c
> @@ -241,6 +241,16 @@ static bool vring_restart(struct virtque
> return true;
> }
>
> +static void vring_startup(struct virtqueue *_vq)
> +{
> + struct vring_virtqueue *vq = to_vvq(_vq);
> + START_USE(vq);
> + if (vq->vq.callback)
> + vq->vring.avail->flags &= ~VRING_AVAIL_F_NO_INTERRUPT;
> + END_USE(vq);
> +}
> +
> +
> irqreturn_t vring_interrupt(int irq, void *_vq)
> {
> struct vring_virtqueue *vq = to_vvq(_vq);
> @@ -265,6 +275,7 @@ static struct virtqueue_ops vring_vq_ops
> .get_buf = vring_get_buf,
> .kick = vring_kick,
> .restart = vring_restart,
> + .startup = vring_startup,
> .shutdown = vring_shutdown,
> };
>
> @@ -299,9 +310,8 @@ struct virtqueue *vring_new_virtqueue(un
> vq->in_use = false;
> #endif
>
> - /* No callback? Tell other side not to bother us. */
> - if (!callback)
> - vq->vring.avail->flags |= VRING_AVAIL_F_NO_INTERRUPT;
> + /* disable interrupts until we enable them */
> + vq->vring.avail->flags |= VRING_AVAIL_F_NO_INTERRUPT;
>
> /* Put everything in free lists. */
> vq->num_free = num;
> Index: kvm/include/linux/virtio.h
> ===================================================================
> --- kvm.orig/include/linux/virtio.h
> +++ kvm/include/linux/virtio.h
> @@ -45,6 +45,9 @@ struct virtqueue
> * vq: the struct virtqueue we're talking about.
> * This returns "false" (and doesn't re-enable) if there are pending
> * buffers in the queue, to avoid a race.
> + * @startup: enable callbacks
> + * vq: the struct virtqueue we're talking abount
> + * Returns 0 or an error
> * @shutdown: "unadd" all buffers.
> * vq: the struct virtqueue we're talking about.
> * Remove everything from the queue.
> @@ -67,6 +70,8 @@ struct virtqueue_ops {
>
> bool (*restart)(struct virtqueue *vq);
>
> + void (*startup) (struct virtqueue *vq);
> +
> void (*shutdown)(struct virtqueue *vq);
> };
>
> Index: kvm/drivers/net/virtio_net.c
> ===================================================================
> --- kvm.orig/drivers/net/virtio_net.c
> +++ kvm/drivers/net/virtio_net.c
> @@ -292,6 +292,8 @@ static int virtnet_open(struct net_devic
> return -ENOMEM;
>
> napi_enable(&vi->napi);
> +
> + vi->rvq->vq_ops->startup(vi->rvq);
> return 0;
> }
>
> Index: kvm/drivers/block/virtio_blk.c
> ===================================================================
> --- kvm.orig/drivers/block/virtio_blk.c
> +++ kvm/drivers/block/virtio_blk.c
> @@ -183,7 +183,8 @@ static int virtblk_probe(struct virtio_d
> err = PTR_ERR(vblk->vq);
> goto out_free_vblk;
> }
> -
> + /* enable interrupts */
> + vblk->vq->vq_ops->startup(vblk->vq);
> vblk->pool = mempool_create_kmalloc_pool(1,sizeof(struct virtblk_req));
> if (!vblk->pool) {
> err = -ENOMEM;
>
>
>
> There is still one small problem: what if the host fills up all
> host-to-guest buffers before we call startup? So I start to think that your
> solution is better, given that the host is not only not sending interrupts
>
This is why initially I suggested another status code in order to split
the ring logic with driver status.
> but also not filling any buffers as long as VIRTIO_CONFIG_DEV_OPEN is not
> set. I will have a look but I think that add_status needs to be called
>
It can fill the buffers even without dev_open, when the dev is finally
opened the host will issue an interrupt
if there are pending buffers. (I'm not sure it's worth solving, maybe
just drop them like you suggested).
> after napi_enable, otherwise we have the same race.
>
>
You're right, my mistake.
> Christian
>
>
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
^ permalink raw reply
* Re: [PATCH] [NET]: Fix Ooops of napi net_rx_action.
From: Joonwoo Park @ 2007-12-11 23:27 UTC (permalink / raw)
To: Brandeburg, Jesse
Cc: David Miller, netdev, linux-kernel, herbert, Kok, Auke-jan H
In-Reply-To: <36D9DB17C6DE9E40B059440DB8D95F5203F82FC3@orsmsx418.amr.corp.intel.com>
2007/12/12, Brandeburg, Jesse <jesse.brandeburg@intel.com>:
> Joonwoo Park wrote:
> > /* If no Tx and not enough Rx work done, exit the polling mode */
> > if ((!tx_cleaned && (work_done == 0)) ||
> > !netif_running(poll_dev)) {
> > quit_polling:
> > if (likely(adapter->itr_setting & 3))
> > e1000_set_itr(adapter);
> > netif_rx_complete(poll_dev, napi);
> > e1000_irq_enable(adapter);
>
> all drivers using NAPI in 2.6.24+ (NNAPI??) must return zero here, after
> calling netif_rx_complete. netif_rx_complete plus work_done != 0 causes
> a bug.
>
> > }
> >
> > return work_done;
> > }
> >
>
I'm working another patch for drivers (maybe patches)
Thanks.
Joonwoo
^ permalink raw reply
* RE: [PATCH] [NET]: Fix Ooops of napi net_rx_action.
From: Brandeburg, Jesse @ 2007-12-11 23:12 UTC (permalink / raw)
To: Joonwoo Park, David Miller; +Cc: netdev, linux-kernel, herbert, Kok, Auke-jan H
In-Reply-To: <b25c3fa70712110457g2bf04c6flc387f2b9cb51cf3b@mail.gmail.com>
Joonwoo Park wrote:
> /* If no Tx and not enough Rx work done, exit the polling mode */
> if ((!tx_cleaned && (work_done == 0)) ||
> !netif_running(poll_dev)) {
> quit_polling:
> if (likely(adapter->itr_setting & 3))
> e1000_set_itr(adapter);
> netif_rx_complete(poll_dev, napi);
> e1000_irq_enable(adapter);
all drivers using NAPI in 2.6.24+ (NNAPI??) must return zero here, after
calling netif_rx_complete. netif_rx_complete plus work_done != 0 causes
a bug.
> }
>
> return work_done;
> }
>
^ permalink raw reply
* RE: [2.6 patch] drivers/net/s2io.c section fixes
From: Ramkrishna Vepa @ 2007-12-11 23:16 UTC (permalink / raw)
To: Adrian Bunk, jgarzik
Cc: netdev, linux-kernel, Rastapur Santosh, Sivakumar Subramani,
Sreenivasa Honnur
In-Reply-To: <20071211222306.GV14204@stusta.de>
Thanks. Patch looks good. Please accept.
Ram
> -----Original Message-----
> From: Adrian Bunk [mailto:bunk@kernel.org]
> Sent: Tuesday, December 11, 2007 2:23 PM
> To: ram.vepa@neterion.com; Rastapur Santosh; Sivakumar Subramani;
> Sreenivasa Honnur; jgarzik@pobox.com
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [2.6 patch] drivers/net/s2io.c section fixes
>
> Code used by the non-__devinit s2io_open() mustn't be __devinit.
>
> This patch fixes the following section mismatch with CONFIG_HOTPLUG=n:
>
> <-- snip -->
>
> ...
> WARNING: vmlinux.o(.text+0x6f6e3e): Section mismatch: reference to
> .init.text.20:s2io_test_intr (between 's2io_open' and
's2io_ethtool_sset')
> ...
>
> <-- snip -->
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
>
> ---
>
> drivers/net/s2io.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> 50fb761b99d7ee0b234359d02144f84a87e2faff
> diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
> index 121cb10..9d80f1c 100644
> --- a/drivers/net/s2io.c
> +++ b/drivers/net/s2io.c
> @@ -3737,7 +3737,7 @@ static int s2io_enable_msi_x(struct s2io_nic
*nic)
> }
>
> /* Handle software interrupt used during MSI(X) test */
> -static irqreturn_t __devinit s2io_test_intr(int irq, void *dev_id)
> +static irqreturn_t s2io_test_intr(int irq, void *dev_id)
> {
> struct s2io_nic *sp = dev_id;
>
> @@ -3748,7 +3748,7 @@ static irqreturn_t __devinit s2io_test_intr(int
irq,
> void *dev_id)
> }
>
> /* Test interrupt path by forcing a a software IRQ */
> -static int __devinit s2io_test_msi(struct s2io_nic *sp)
> +static int s2io_test_msi(struct s2io_nic *sp)
> {
> struct pci_dev *pdev = sp->pdev;
> struct XENA_dev_config __iomem *bar0 = sp->bar0;
^ permalink raw reply
* Re: 2.6.24-rc4-mm1
From: Randy Dunlap @ 2007-12-11 23:15 UTC (permalink / raw)
To: Kok, Auke; +Cc: Andrew Morton, mbligh, linux-kernel, apw, netdev, tglx, mingo
In-Reply-To: <475F0C6C.20900@intel.com>
On Tue, 11 Dec 2007 14:17:16 -0800 Kok, Auke wrote:
> Andrew Morton wrote:
> > On Tue, 11 Dec 2007 13:26:58 -0800
> > "Kok, Auke" <auke-jan.h.kok@intel.com> wrote:
> >
> >> Andrew Morton wrote:
> >>> On Tue, 11 Dec 2007 08:13:52 -0800 "Martin Bligh" <mbligh@google.com> wrote:
> >>>
> >>>>> - Lots of device IDs have been removed from the e1000 driver and moved
> >>>>> over
> >>>>> to e1000e. So if your e1000 stops working, you forgot to set
> >>>>> CONFIG_E1000E.
> >>>>>
> >>>>>
> >>>> Wouldn't it make sense to just default this to on if E1000 was on, rather
> >>>> than screwing
> >>>> everybody for no good reason (plus breaking all the automated testing, etc
> >>>> etc)?
> >>>> Much though I love random refactoring, it is fairly painful to just keep
> >>>> changing the
> >>>> names of things.
> >>> (cc netdev and Auke)
> >>>
> >>> Yes, that would be very sensible. CONFIG_E1000E should default to whatever
> >>> CONFIG_E1000 was set to.
> >> which is "y" for x86 and friends, ppc, arm and ia64 through 'defconfig'. the
> >> Kconfig files do not have defaults in them.
> >
> > I wouldn't be looking at defconfig files - I don't think many people use
> > them. Most people use their previous config, via oldconfig.
> >
> > So what we want here is to give them E1000E if they had previously been
> > using E1000. I don't know how one would do this in Kconfig.
>
> ditto. I doubt that "SELECT E1000E" would be a good idea here (maybe not even
> work), and I can't think of anything else.
"default E1000" in E1000E seems to work for me.
---
From: Randy Dunlap <randy.dunlap@oracle.com>
Make E1000E default to the same kconfig setting as E1000,
at least for -mm testing.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/net/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- linux-2.6.24-rc4-mm1.orig/drivers/net/Kconfig
+++ linux-2.6.24-rc4-mm1/drivers/net/Kconfig
@@ -1986,6 +1986,7 @@ config E1000_DISABLE_PACKET_SPLIT
config E1000E
tristate "Intel(R) PRO/1000 PCI-Express Gigabit Ethernet support"
depends on PCI
+ default E1000
---help---
This driver supports the PCI-Express Intel(R) PRO/1000 gigabit
ethernet family of adapters. For PCI or PCI-X e1000 adapters,
^ permalink raw reply
* sk_prot->sendmsg(...) giving me a kernel oops on kernels past 2.6.20
From: Kevin Wilson @ 2007-12-11 22:51 UTC (permalink / raw)
To: netdev
I've searched everywhere (including this list) for a report but couldn't
find anything that can tell me what implementation step(s) I am missing.
Essentially all the kernels past 2.6.20 gives me a kernel oops on the
sendmsg code.
I know the sk_buff changes worked things over quite a bit but I have (or
thought I did) those changes accounted for in our driver. Are there any
specific implementation changes we need to add that we didn't need prior
before we now use sendmsg()? Below is the general gist of the code I am
executing, any pointers to what I am missing would be very welcome.
Thanks a bunch.
Kevin
***************************************
done in userland and passed via ioctl:
***************************************
sk = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
tcp_params.boxid = boxIndex;
tcp_params.sk = sk;
tcp_params.rbuf = malloc(4096);
tcp_params.rbuf_size = 4096;
tcp_params.wbuf = malloc(1460);
tcp_params.wbuf_size = 1460;
rc = ioctl(fd, SI_SET_TCP, &tcp_params);
***************************************
done in kernel space:
***************************************
struct tcp_sock *tp;
struct sock *mysock;
tp = sockfd_lookup(tcp_params.sk, &i);
mysock = tp->sk;
mysock->sk_prot->sendmsg(...); <-- OOPS HERE
^ permalink raw reply
* Re: [Bugme-new] [Bug 9545] New: Cannot bring up a bridge interface without a MAC address set
From: Andrew Morton @ 2007-12-11 22:59 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, bugme-daemon, berrange, jeff, herbert, rjw
In-Reply-To: <20071211145243.66e1f66a@freepuppy.rosehill>
On Tue, 11 Dec 2007 14:52:43 -0800
Stephen Hemminger <shemminger@linux-foundation.org> wrote:
> On Tue, 11 Dec 2007 13:26:14 -0800
> Andrew Morton <akpm@linux-foundation.org> wrote:
>
> >
> > (please respond via emailed reply-to-all, not via the bugzilla web
> > interface).
> >
> > On Tue, 11 Dec 2007 11:04:55 -0800 (PST)
> > bugme-daemon@bugzilla.kernel.org wrote:
> >
> > > http://bugzilla.kernel.org/show_bug.cgi?id=9545
> > >
> > > Summary: Cannot bring up a bridge interface without a MAC address
> > > set
> > > Product: Networking
> > > Version: 2.5
> > > KernelVersion: 2.6.24-0.81.rc4.git7.fc9
> > > Platform: All
> > > OS/Version: Linux
> > > Tree: Fedora
> > > Status: NEW
> > > Severity: normal
> > > Priority: P1
> > > Component: Other
> > > AssignedTo: acme@ghostprotocols.net
> > > ReportedBy: berrange@redhat.com
> > >
> > >
> > > Most recent kernel where this bug did not occur: Any 2.6.23 or earlier
> > > Distribution: Fedora 9 rawhide
> > > Hardware Environment: Intel(R) Core(TM)2 Duo CPU E6850, x86_64
> > > Software Environment: 2.6.24-0.81.rc4.git7.fc9 #1 SMP x86_64 GNU/Linux
> > > Problem Description:
> > > It is not possible to bring up a bridge interface unless one first assigns a
> > > MAC address to it. This is a regression from earlier kernels where one could
> > > always bring up a bridge device immediately after creating it. The bridge
> > > should not require a MAC address because it is not going to be configured with
> > > any IP addr - in my scenario I merely wish to use it to connect a number of
> > > 'tap' devices associated with KVM guests.
> > >
> > > Steps to reproduce:
> > > # brctl addbr demobr
> > > # ifconfig demobr up
> > > SIOCSIFFLAGS: Invalid argument
>
> The tap devices have to have addresses don't they. So bringing up an empty
> bridge is meaningless. If you just add the device first then it will work.
>
> Could be fixed to prevent errors from existing scripts but it is not a complete showstopper.
> The problem is that when device is brought up it propogates events up to
> other layers and applications, these layers will then query and see a bogus
> address.
>
If the fix to make bridge compatible with 2.6.23 behaviour isn't too
gruesome then I'd have thought it'd be worth doing it?
^ permalink raw reply
* Re: [Bugme-new] [Bug 9545] New: Cannot bring up a bridge interface without a MAC address set
From: Stephen Hemminger @ 2007-12-11 22:52 UTC (permalink / raw)
To: Andrew Morton
Cc: netdev, bugme-daemon, berrange, Jeff Garzik, Herbert Xu,
Rafael J. Wysocki
In-Reply-To: <20071211132614.5854b0f1.akpm@linux-foundation.org>
On Tue, 11 Dec 2007 13:26:14 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:
>
> (please respond via emailed reply-to-all, not via the bugzilla web
> interface).
>
> On Tue, 11 Dec 2007 11:04:55 -0800 (PST)
> bugme-daemon@bugzilla.kernel.org wrote:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=9545
> >
> > Summary: Cannot bring up a bridge interface without a MAC address
> > set
> > Product: Networking
> > Version: 2.5
> > KernelVersion: 2.6.24-0.81.rc4.git7.fc9
> > Platform: All
> > OS/Version: Linux
> > Tree: Fedora
> > Status: NEW
> > Severity: normal
> > Priority: P1
> > Component: Other
> > AssignedTo: acme@ghostprotocols.net
> > ReportedBy: berrange@redhat.com
> >
> >
> > Most recent kernel where this bug did not occur: Any 2.6.23 or earlier
> > Distribution: Fedora 9 rawhide
> > Hardware Environment: Intel(R) Core(TM)2 Duo CPU E6850, x86_64
> > Software Environment: 2.6.24-0.81.rc4.git7.fc9 #1 SMP x86_64 GNU/Linux
> > Problem Description:
> > It is not possible to bring up a bridge interface unless one first assigns a
> > MAC address to it. This is a regression from earlier kernels where one could
> > always bring up a bridge device immediately after creating it. The bridge
> > should not require a MAC address because it is not going to be configured with
> > any IP addr - in my scenario I merely wish to use it to connect a number of
> > 'tap' devices associated with KVM guests.
> >
> > Steps to reproduce:
> > # brctl addbr demobr
> > # ifconfig demobr up
> > SIOCSIFFLAGS: Invalid argument
The tap devices have to have addresses don't they. So bringing up an empty
bridge is meaningless. If you just add the device first then it will work.
Could be fixed to prevent errors from existing scripts but it is not a complete showstopper.
The problem is that when device is brought up it propogates events up to
other layers and applications, these layers will then query and see a bogus
address.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: [PATCH 0/3] cxgb - driver fixes.
From: Greg KH @ 2007-12-11 22:47 UTC (permalink / raw)
To: Divy Le Ray; +Cc: Ben Greear, Jeff Garzik, NetDev, linux-kernel
In-Reply-To: <4751ED97.5090804@chelsio.com>
On Sat, Dec 01, 2007 at 03:26:15PM -0800, Divy Le Ray wrote:
> Ben Greear wrote:
>> Divy Le Ray wrote:
>>> Jeff,
>>>
>>> I'm submitting a patch series for inclusion in 2.6.24 for the cxgb
>>> driver.
>>> The patches are built against Linus'git tree.
>>>
>>> Here is a brief description:
>>> - Ensure that GSO skbs have enough headroom before encapsulating them,
>>> - Fix a crash in NAPI mode,
>>> - Fix statistics accounting and report.
>>
>> We ran pktgen overnight on 2.6.23 with patch 1 and 3 applied (patch 2
>> not needed on .23 it seems) and it was stable at about 1.5Gbps
>> bi-directional
>> using 1500 MTU sized frames.
>>
>> We'll run some more tests with user-space TCP & UDP today, but it looks
>> good
>> so far.
>>
>> Perhaps these patches should be considered for .23 stable as well?
>>
>> Thanks,
>> Ben
>>
>
> Yes, patches 1 and 3 could be considered for .22 and .23-stable, along with
> the previous fix:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7de6af0f23b25df8da9719ecae1916b669d0b03d
Can you send all of the individual patches you wish to have applied to
the -stable tree to stable@kernel.org so that we can properly determine
exactly which patches you are referring to?
Also, make sure they are already in Linus's tree before telling us about
them.
thanks,
greg k-h
^ permalink raw reply
* RFC: igb: Intel 82575 gigabit ethernet driver (take #2)
From: Kok, Auke @ 2007-12-11 22:34 UTC (permalink / raw)
To: NetDev, Jeff Garzik
Cc: Arjan van de Ven, Jesse Brandeburg, Ronciak, John, Mitch Williams
[-- Attachment #1: Type: text/plain, Size: 4144 bytes --]
All,
here is the second version of the igb (82575) ethernet controller driver. This
driver was previously posted 2007-07-13. Many comments received were addressed:
- removed indirection wrappers in the same way as e1000e and ixgbe.
- cleaned up largely against sparse, checkpatch
- removed module parameters and moved functionality to ethtool ioctls
- new NAPI API rewrites
- by default the driver runs in multiqueue mode with 2 to 40 RX queues enabled.
Since the driver is still too large (allthough the patch shrunk from 558k to 416k,
almost 34% of its size) to post to this list I am attaching the bzipped patch
here. You can get the same driver alternatively from here:
http://foo-projects.org/~sofar/0001-igb-PCI-Express-82575-Gigabit-Ethernet-driver.patch
[416k]
http://foo-projects.org/~sofar/0001-igb-PCI-Express-82575-Gigabit-Ethernet-driver.patch.bz2
[74k]
or through git:
git://lost.foo-projects.org/~ahkok/git/linux-2.6 #igb
There are several concerns still open for this driver:
- namespace collisions with e1000. Since there are cleanups planned for e1000
since pci-e hardware is now moved to e1000e, this might resolve them.
- hardware code is still a large API. we're expecting more hardware to be
supported by this driver in the future and it's not certain which parts we need to
keep or not.
Please review,
Cheers,
Auke
---
>From 02d13aaf92470678aaeb739f0b6e4c9f9687c7b8 Mon Sep 17 00:00:00 2001
From: Auke Kok <auke-jan.h.kok@intel.com>
Date: Thu, 6 Dec 2007 15:08:14 -0800
Subject: [PATCH] igb: PCI-Express 82575 Gigabit Ethernet driver
We are pleased to announce a new Gigabit Ethernet product and its
driver to the linux community. This product is the Intel(R) 82575
Gigabit Ethernet adapter family. Physical adapters will be available
to the public soon. These adapters come in 2- and 4-port versions
(copper PHY) currently. Other variants will be available later.
The 82575 chipset supports significantly different features that
warrant a new driver. The descriptor format is (just like the
ixgbe driver) different. The device can use multiple MSI-X vectors
and multiple queues for both send and receive. This allows us to
optimize some of the driver code specifically as well compared to
the e1000-supported devices.
This version of the igb driver no lnger uses fake netdevices and
incorporates napi_struct members for each ring to do the multi-
queue polling. multi-queue is enabled by default and the driver
supports NAPI mode only.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/Kconfig | 22 +
drivers/net/Makefile | 1 +
drivers/net/igb/Makefile | 37 +
drivers/net/igb/e1000_82575.c | 1269 ++++++++++++
drivers/net/igb/e1000_82575.h | 198 ++
drivers/net/igb/e1000_defines.h | 772 ++++++++
drivers/net/igb/e1000_hw.h | 599 ++++++
drivers/net/igb/e1000_mac.c | 1505 ++++++++++++++
drivers/net/igb/e1000_mac.h | 98 +
drivers/net/igb/e1000_nvm.c | 605 ++++++
drivers/net/igb/e1000_nvm.h | 40 +
drivers/net/igb/e1000_phy.c | 1807 +++++++++++++++++
drivers/net/igb/e1000_phy.h | 98 +
drivers/net/igb/e1000_regs.h | 277 +++
drivers/net/igb/igb.h | 300 +++
drivers/net/igb/igb_ethtool.c | 1926 ++++++++++++++++++
drivers/net/igb/igb_main.c | 4110 +++++++++++++++++++++++++++++++++++++++
17 files changed, 13664 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/igb/Makefile
create mode 100644 drivers/net/igb/e1000_82575.c
create mode 100644 drivers/net/igb/e1000_82575.h
create mode 100644 drivers/net/igb/e1000_defines.h
create mode 100644 drivers/net/igb/e1000_hw.h
create mode 100644 drivers/net/igb/e1000_mac.c
create mode 100644 drivers/net/igb/e1000_mac.h
create mode 100644 drivers/net/igb/e1000_nvm.c
create mode 100644 drivers/net/igb/e1000_nvm.h
create mode 100644 drivers/net/igb/e1000_phy.c
create mode 100644 drivers/net/igb/e1000_phy.h
create mode 100644 drivers/net/igb/e1000_regs.h
create mode 100644 drivers/net/igb/igb.h
create mode 100644 drivers/net/igb/igb_ethtool.c
create mode 100644 drivers/net/igb/igb_main.c
[-- Attachment #2: 0001-igb-PCI-Express-82575-Gigabit-Ethernet-driver.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 76046 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] cxgb3 - Parity initialization for T3C adapters
From: Junio C Hamano @ 2007-12-11 22:27 UTC (permalink / raw)
To: Divy Le Ray; +Cc: Jeff Garzik, netdev, linux-kernel, swise, wenxiong
In-Reply-To: <4759CD92.2070604@chelsio.com>
Divy Le Ray <divy@chelsio.com> writes:
> On this topic, I have a question: how do I get to see all the
> netdev-2.6 branches ?
> After cloning a free netdev-2.6 tree, 'git branch' shows only the
> master branch:
> ...
> Cloning
> "git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git"
> into "netdev-2.6-fresh"...
> Initialized empty Git repository in /opt/sources/netdev-2.6-fresh/.git/
> ...
> 100% (23058/23058) done
> done
> -bash-3.1$ cd netdev-2.6-fresh/
> -bash-3.1$ git branch
> * master
At this point,
$ git branch -r
will show you have copies of Jeff's branches in remotes/origin/.
$ git checkout -b upstream origin/upstream
would make your local upstream branch that forks from Jeff's upstream
branch.
^ permalink raw reply
* [2.6 patch] drivers/net/sis190.c section fix
From: Adrian Bunk @ 2007-12-11 22:23 UTC (permalink / raw)
To: romieu, jgarzik; +Cc: netdev, linux-kernel
This patch fixes the following section mismatch with CONFIG_HOTPLUG=n:
<-- snip -->
...
WARNING: vmlinux.o(.init.text.20+0x4cb25): Section mismatch: reference to .exit.text:sis190_mii_remove (between 'sis190_init_one' and 'read_eeprom')
...
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
29fae057ba15a552a7cad1e731d3238d567032ba
diff --git a/drivers/net/sis190.c b/drivers/net/sis190.c
index 7200883..49f767b 100644
--- a/drivers/net/sis190.c
+++ b/drivers/net/sis190.c
@@ -1381,7 +1381,7 @@ out:
return rc;
}
-static void __devexit sis190_mii_remove(struct net_device *dev)
+static void sis190_mii_remove(struct net_device *dev)
{
struct sis190_private *tp = netdev_priv(dev);
^ permalink raw reply related
* [2.6 patch] drivers/net/s2io.c section fixes
From: Adrian Bunk @ 2007-12-11 22:23 UTC (permalink / raw)
To: ram.vepa, santosh.rastapur, sivakumar.subramani,
sreenivasa.honnur, jgarzik
Cc: netdev, linux-kernel
Code used by the non-__devinit s2io_open() mustn't be __devinit.
This patch fixes the following section mismatch with CONFIG_HOTPLUG=n:
<-- snip -->
...
WARNING: vmlinux.o(.text+0x6f6e3e): Section mismatch: reference to .init.text.20:s2io_test_intr (between 's2io_open' and 's2io_ethtool_sset')
...
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
drivers/net/s2io.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
50fb761b99d7ee0b234359d02144f84a87e2faff
diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
index 121cb10..9d80f1c 100644
--- a/drivers/net/s2io.c
+++ b/drivers/net/s2io.c
@@ -3737,7 +3737,7 @@ static int s2io_enable_msi_x(struct s2io_nic *nic)
}
/* Handle software interrupt used during MSI(X) test */
-static irqreturn_t __devinit s2io_test_intr(int irq, void *dev_id)
+static irqreturn_t s2io_test_intr(int irq, void *dev_id)
{
struct s2io_nic *sp = dev_id;
@@ -3748,7 +3748,7 @@ static irqreturn_t __devinit s2io_test_intr(int irq, void *dev_id)
}
/* Test interrupt path by forcing a a software IRQ */
-static int __devinit s2io_test_msi(struct s2io_nic *sp)
+static int s2io_test_msi(struct s2io_nic *sp)
{
struct pci_dev *pdev = sp->pdev;
struct XENA_dev_config __iomem *bar0 = sp->bar0;
^ permalink raw reply related
* [2.6 patch] drivers/net/ipg.c: add __devexit annotation
From: Adrian Bunk @ 2007-12-11 22:20 UTC (permalink / raw)
To: romieu, sorbica, jesse; +Cc: netdev, linux-kernel
ipg_remove() can become __devexit.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
97ace7a0e52ceac30caae20e1a3fe72c4644bce7
diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
index dbd23bb..285ebbc 100644
--- a/drivers/net/ipg.c
+++ b/drivers/net/ipg.c
@@ -2214,7 +2214,7 @@ static struct ethtool_ops ipg_ethtool_ops = {
.nway_reset = ipg_nway_reset,
};
-static void ipg_remove(struct pci_dev *pdev)
+static void __devexit ipg_remove(struct pci_dev *pdev)
{
struct net_device *dev = pci_get_drvdata(pdev);
struct ipg_nic_private *sp = netdev_priv(dev);
^ permalink raw reply related
* Re: 2.6.24-rc4-mm1
From: Kok, Auke @ 2007-12-11 22:17 UTC (permalink / raw)
To: Andrew Morton; +Cc: mbligh, linux-kernel, apw, netdev, tglx, mingo
In-Reply-To: <20071211141040.a1c6f316.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Tue, 11 Dec 2007 13:26:58 -0800
> "Kok, Auke" <auke-jan.h.kok@intel.com> wrote:
>
>> Andrew Morton wrote:
>>> On Tue, 11 Dec 2007 08:13:52 -0800 "Martin Bligh" <mbligh@google.com> wrote:
>>>
>>>>> - Lots of device IDs have been removed from the e1000 driver and moved
>>>>> over
>>>>> to e1000e. So if your e1000 stops working, you forgot to set
>>>>> CONFIG_E1000E.
>>>>>
>>>>>
>>>> Wouldn't it make sense to just default this to on if E1000 was on, rather
>>>> than screwing
>>>> everybody for no good reason (plus breaking all the automated testing, etc
>>>> etc)?
>>>> Much though I love random refactoring, it is fairly painful to just keep
>>>> changing the
>>>> names of things.
>>> (cc netdev and Auke)
>>>
>>> Yes, that would be very sensible. CONFIG_E1000E should default to whatever
>>> CONFIG_E1000 was set to.
>> which is "y" for x86 and friends, ppc, arm and ia64 through 'defconfig'. the
>> Kconfig files do not have defaults in them.
>
> I wouldn't be looking at defconfig files - I don't think many people use
> them. Most people use their previous config, via oldconfig.
>
> So what we want here is to give them E1000E if they had previously been
> using E1000. I don't know how one would do this in Kconfig.
ditto. I doubt that "SELECT E1000E" would be a good idea here (maybe not even
work), and I can't think of anything else.
Auke
^ permalink raw reply
* Re: 2.6.24-rc4-mm1
From: Andrew Morton @ 2007-12-11 22:10 UTC (permalink / raw)
To: Kok, Auke; +Cc: mbligh, linux-kernel, apw, netdev, tglx, mingo
In-Reply-To: <475F00A2.6020406@intel.com>
On Tue, 11 Dec 2007 13:26:58 -0800
"Kok, Auke" <auke-jan.h.kok@intel.com> wrote:
> Andrew Morton wrote:
> > On Tue, 11 Dec 2007 08:13:52 -0800 "Martin Bligh" <mbligh@google.com> wrote:
> >
> >>>
> >>> - Lots of device IDs have been removed from the e1000 driver and moved
> >>> over
> >>> to e1000e. So if your e1000 stops working, you forgot to set
> >>> CONFIG_E1000E.
> >>>
> >>>
> >> Wouldn't it make sense to just default this to on if E1000 was on, rather
> >> than screwing
> >> everybody for no good reason (plus breaking all the automated testing, etc
> >> etc)?
> >> Much though I love random refactoring, it is fairly painful to just keep
> >> changing the
> >> names of things.
> >
> > (cc netdev and Auke)
> >
> > Yes, that would be very sensible. CONFIG_E1000E should default to whatever
> > CONFIG_E1000 was set to.
>
> which is "y" for x86 and friends, ppc, arm and ia64 through 'defconfig'. the
> Kconfig files do not have defaults in them.
I wouldn't be looking at defconfig files - I don't think many people use
them. Most people use their previous config, via oldconfig.
So what we want here is to give them E1000E if they had previously been
using E1000. I don't know how one would do this in Kconfig.
^ permalink raw reply
* Re: [Bug 9542] BUG: bad unlock balance detected!
From: Andrew Morton @ 2007-12-11 22:06 UTC (permalink / raw)
To: netdev; +Cc: bugme-daemon, Stephen Hemminger, olel
In-Reply-To: <20071211150313.EF4D210806E@picon.linux-foundation.org>
(switching to email - please respond via emailed reply-to-all, not via the
bugzilla web interface)
On Tue, 11 Dec 2007 07:03:13 -0800 (PST)
bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9542
>
>
>
>
>
> ------- Comment #2 from olel@ans.pl 2007-12-11 07:03 -------
> Still wrong.
So this appears to be a separate bug in either bonding or ipv6.
> =========================================================
> [ INFO: possible irq lock inversion dependency detected ]
> 2.6.24-rc4-git7 #1
> ---------------------------------------------------------
> events/0/9 just changed the state of lock:
> (&mc->mca_lock){-+..}, at: [<c0412602>] mld_ifc_timer_expire+0x130/0x1fb
> but this lock took another, soft-read-irq-unsafe lock in the past:
> (&bond->lock){-.--}
>
> and interrupts could create inverse lock ordering between them.
>
>
> other info that might help us debug this:
> 4 locks held by events/0/9:
> #0: (events){--..}, at: [<c0133c8b>] run_workqueue+0x87/0x1b6
> #1: ((linkwatch_work).work){--..}, at: [<c0133c8b>] run_workqueue+0x87/0x1b6
> #2: (rtnl_mutex){--..}, at: [<c03ac6d4>] linkwatch_event+0x5/0x22
> #3: (&ndev->lock){-.-+}, at: [<c04124e9>] mld_ifc_timer_expire+0x17/0x1fb
>
> the first lock's dependencies:
> -> (&mc->mca_lock){-+..} ops: 10 {
> initial-use at:
> [<c0104ee2>] dump_trace+0x83/0x8d
> [<c01428d0>] __lock_acquire+0x4ba/0xc07
> [<c0109eee>] save_stack_trace+0x20/0x3a
> [<c0142fd5>] __lock_acquire+0xbbf/0xc07
> [<c0412dda>] ipv6_dev_mc_inc+0x24d/0x31c
> [<c0143096>] lock_acquire+0x79/0x93
> [<c0412a5e>] igmp6_group_added+0x18/0x11d
> [<c043a6ea>] _spin_lock_bh+0x3b/0x64
> [<c0412a5e>] igmp6_group_added+0x18/0x11d
> [<c0412a5e>] igmp6_group_added+0x18/0x11d
> [<c0141fd3>] trace_hardirqs_on+0x122/0x14c
> [<c0412e30>] ipv6_dev_mc_inc+0x2a3/0x31c
> [<c0412dda>] ipv6_dev_mc_inc+0x24d/0x31c
> [<c0412e65>] ipv6_dev_mc_inc+0x2d8/0x31c
> [<c0412b8d>] ipv6_dev_mc_inc+0x0/0x31c
> [<c04021bc>] ipv6_add_dev+0x21c/0x24b
> [<c040ba05>] ndisc_ifinfo_sysctl_change+0x0/0x1ef
> [<c05c5b4d>] addrconf_init+0x13/0x193
> [<c019a95f>] proc_net_fops_create+0x10/0x21
> [<c041a4c0>] ip6_flowlabel_init+0x1e/0x20
> [<c05c5a2d>] inet6_init+0x1f0/0x2ad
> [<c05a9499>] kernel_init+0x150/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c0104baf>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
> in-softirq-W at:
> [<c0142856>] __lock_acquire+0x440/0xc07
> [<c0143096>] lock_acquire+0x79/0x93
> [<c0412602>] mld_ifc_timer_expire+0x130/0x1fb
> [<c04124d2>] mld_ifc_timer_expire+0x0/0x1fb
> [<c043a6ea>] _spin_lock_bh+0x3b/0x64
> [<c0412602>] mld_ifc_timer_expire+0x130/0x1fb
> [<c0412602>] mld_ifc_timer_expire+0x130/0x1fb
> [<c04124d2>] mld_ifc_timer_expire+0x0/0x1fb
> [<c0141fbd>] trace_hardirqs_on+0x10c/0x14c
> [<c04124d2>] mld_ifc_timer_expire+0x0/0x1fb
> [<c012df86>] run_timer_softirq+0xfa/0x15d
> [<c012a8da>] __do_softirq+0x56/0xdb
> [<c0141fbd>] trace_hardirqs_on+0x10c/0x14c
> [<c012a8ec>] __do_softirq+0x68/0xdb
> [<c012a995>] do_softirq+0x36/0x51
> [<c012ab3b>] irq_exit+0x43/0x4e
> [<c011411e>] smp_apic_timer_interrupt+0x74/0x80
> [<c012a8da>] __do_softirq+0x56/0xdb
> [<c0104a01>] apic_timer_interrupt+0x29/0x38
> [<c0104a0b>] apic_timer_interrupt+0x33/0x38
> [<c03b007b>] nl_pid_hash_rehash+0xc1/0x13f
> [<c03b00d8>] nl_pid_hash_rehash+0x11e/0x13f
> [<c012aea0>] local_bh_enable_ip+0xcf/0xed
> [<c03bfa8b>] rt_run_flush+0x64/0x8b
> [<c03e9c1e>] fib_netdev_event+0x61/0x65
> [<c013ac54>] notifier_call_chain+0x2a/0x52
> [<c013ac9e>] raw_notifier_call_chain+0x17/0x1a
> [<c03a3469>] netdev_state_change+0x18/0x29
> [<c03ac6a1>] __linkwatch_run_queue+0x150/0x17e
> [<c03ac6ec>] linkwatch_event+0x1d/0x22
> [<c0133cdf>] run_workqueue+0xdb/0x1b6
> [<c0133c8b>] run_workqueue+0x87/0x1b6
> [<c03ac6cf>] linkwatch_event+0x0/0x22
> [<c01346ff>] worker_thread+0x0/0x85
> [<c0134778>] worker_thread+0x79/0x85
> [<c01371ad>] autoremove_wake_function+0x0/0x35
> [<c01370f6>] kthread+0x38/0x5e
> [<c01370be>] kthread+0x0/0x5e
> [<c0104baf>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
> hardirq-on-W at:
> [<c0141822>] find_usage_backwards+0xbb/0xe2
> [<c0104ee2>] dump_trace+0x83/0x8d
> [<c014289e>] __lock_acquire+0x488/0xc07
> [<c0109eee>] save_stack_trace+0x20/0x3a
> [<c0142fd5>] __lock_acquire+0xbbf/0xc07
> [<c0412dda>] ipv6_dev_mc_inc+0x24d/0x31c
> [<c0143096>] lock_acquire+0x79/0x93
> [<c0412a5e>] igmp6_group_added+0x18/0x11d
> [<c043a6ea>] _spin_lock_bh+0x3b/0x64
> [<c0412a5e>] igmp6_group_added+0x18/0x11d
> [<c0412a5e>] igmp6_group_added+0x18/0x11d
> [<c0141fd3>] trace_hardirqs_on+0x122/0x14c
> [<c0412e30>] ipv6_dev_mc_inc+0x2a3/0x31c
> [<c0412dda>] ipv6_dev_mc_inc+0x24d/0x31c
> [<c0412e65>] ipv6_dev_mc_inc+0x2d8/0x31c
> [<c0412b8d>] ipv6_dev_mc_inc+0x0/0x31c
> [<c04021bc>] ipv6_add_dev+0x21c/0x24b
> [<c040ba05>] ndisc_ifinfo_sysctl_change+0x0/0x1ef
> [<c05c5b4d>] addrconf_init+0x13/0x193
> [<c019a95f>] proc_net_fops_create+0x10/0x21
> [<c041a4c0>] ip6_flowlabel_init+0x1e/0x20
> [<c05c5a2d>] inet6_init+0x1f0/0x2ad
> [<c05a9499>] kernel_init+0x150/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c0104baf>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
> }
> ... key at: [<c087e2d8>] __key.30799+0x0/0x8
> -> (_xmit_ETHER){-...} ops: 8 {
> initial-use at:
> [<c01428d0>] __lock_acquire+0x4ba/0xc07
> [<c0143096>] lock_acquire+0x79/0x93
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c043a6ea>] _spin_lock_bh+0x3b/0x64
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c0412a9c>] igmp6_group_added+0x56/0x11d
> [<c0412e30>] ipv6_dev_mc_inc+0x2a3/0x31c
> [<c0410100>] icmpv6_rcv+0x630/0x828
> [<c0412e65>] ipv6_dev_mc_inc+0x2d8/0x31c
> [<c0412b8d>] ipv6_dev_mc_inc+0x0/0x31c
> [<c04021bc>] ipv6_add_dev+0x21c/0x24b
> [<c040ba05>] ndisc_ifinfo_sysctl_change+0x0/0x1ef
> [<c040279f>] addrconf_notify+0x60/0x7b7
> [<c0142fd5>] __lock_acquire+0xbbf/0xc07
> [<c0141de0>] mark_held_locks+0x39/0x53
> [<c04399ee>] mutex_lock_nested+0x286/0x2ac
> [<c0141fd3>] trace_hardirqs_on+0x122/0x14c
> [<c0439a0c>] mutex_lock_nested+0x2a4/0x2ac
> [<c03a48d1>] register_netdevice_notifier+0xe/0x126
> [<c03a48d1>] register_netdevice_notifier+0xe/0x126
> [<c03a490c>] register_netdevice_notifier+0x49/0x126
> [<c05c5be7>] addrconf_init+0xad/0x193
> [<c05c5b55>] addrconf_init+0x1b/0x193
> [<c05c5a2d>] inet6_init+0x1f0/0x2ad
> [<c05a9499>] kernel_init+0x150/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c0104baf>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
> hardirq-on-W at:
> [<c01419ba>] mark_lock+0x64/0x451
> [<c014289e>] __lock_acquire+0x488/0xc07
> [<c0143096>] lock_acquire+0x79/0x93
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c043a6ea>] _spin_lock_bh+0x3b/0x64
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c0412a9c>] igmp6_group_added+0x56/0x11d
> [<c0412e30>] ipv6_dev_mc_inc+0x2a3/0x31c
> [<c0410100>] icmpv6_rcv+0x630/0x828
> [<c0412e65>] ipv6_dev_mc_inc+0x2d8/0x31c
> [<c0412b8d>] ipv6_dev_mc_inc+0x0/0x31c
> [<c04021bc>] ipv6_add_dev+0x21c/0x24b
> [<c040ba05>] ndisc_ifinfo_sysctl_change+0x0/0x1ef
> [<c040279f>] addrconf_notify+0x60/0x7b7
> [<c0142fd5>] __lock_acquire+0xbbf/0xc07
> [<c0141de0>] mark_held_locks+0x39/0x53
> [<c04399ee>] mutex_lock_nested+0x286/0x2ac
> [<c0141fd3>] trace_hardirqs_on+0x122/0x14c
> [<c0439a0c>] mutex_lock_nested+0x2a4/0x2ac
> [<c03a48d1>] register_netdevice_notifier+0xe/0x126
> [<c03a48d1>] register_netdevice_notifier+0xe/0x126
> [<c03a490c>] register_netdevice_notifier+0x49/0x126
> [<c05c5be7>] addrconf_init+0xad/0x193
> [<c05c5b55>] addrconf_init+0x1b/0x193
> [<c05c5a2d>] inet6_init+0x1f0/0x2ad
> [<c05a9499>] kernel_init+0x150/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c0104baf>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
> }
> ... key at: [<c087adc8>] netdev_xmit_lock_key+0x8/0x1c0
> ... acquired at:
> [<c0142e33>] __lock_acquire+0xa1d/0xc07
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c0143096>] lock_acquire+0x79/0x93
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c043a6ea>] _spin_lock_bh+0x3b/0x64
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c0412a9c>] igmp6_group_added+0x56/0x11d
> [<c0412e30>] ipv6_dev_mc_inc+0x2a3/0x31c
> [<c0410100>] icmpv6_rcv+0x630/0x828
> [<c0412e65>] ipv6_dev_mc_inc+0x2d8/0x31c
> [<c0412b8d>] ipv6_dev_mc_inc+0x0/0x31c
> [<c04021bc>] ipv6_add_dev+0x21c/0x24b
> [<c040ba05>] ndisc_ifinfo_sysctl_change+0x0/0x1ef
> [<c040279f>] addrconf_notify+0x60/0x7b7
> [<c0142fd5>] __lock_acquire+0xbbf/0xc07
> [<c0141de0>] mark_held_locks+0x39/0x53
> [<c04399ee>] mutex_lock_nested+0x286/0x2ac
> [<c0141fd3>] trace_hardirqs_on+0x122/0x14c
> [<c0439a0c>] mutex_lock_nested+0x2a4/0x2ac
> [<c03a48d1>] register_netdevice_notifier+0xe/0x126
> [<c03a48d1>] register_netdevice_notifier+0xe/0x126
> [<c03a490c>] register_netdevice_notifier+0x49/0x126
> [<c05c5be7>] addrconf_init+0xad/0x193
> [<c05c5b55>] addrconf_init+0x1b/0x193
> [<c05c5a2d>] inet6_init+0x1f0/0x2ad
> [<c05a9499>] kernel_init+0x150/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c0104baf>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
>
> -> (&bonding_netdev_xmit_lock_key){-...} ops: 6 {
> initial-use at:
> [<c01428d0>] __lock_acquire+0x4ba/0xc07
> [<c0143096>] lock_acquire+0x79/0x93
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c043a6ea>] _spin_lock_bh+0x3b/0x64
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c0412a9c>] igmp6_group_added+0x56/0x11d
> [<c0412e30>] ipv6_dev_mc_inc+0x2a3/0x31c
> [<c0410100>] icmpv6_rcv+0x630/0x828
> [<c0412e65>] ipv6_dev_mc_inc+0x2d8/0x31c
> [<c0412b8d>] ipv6_dev_mc_inc+0x0/0x31c
> [<c04021bc>] ipv6_add_dev+0x21c/0x24b
> [<c040ba05>] ndisc_ifinfo_sysctl_change+0x0/0x1ef
> [<c040279f>] addrconf_notify+0x60/0x7b7
> [<c0142fd5>] __lock_acquire+0xbbf/0xc07
> [<c0141de0>] mark_held_locks+0x39/0x53
> [<c04399ee>] mutex_lock_nested+0x286/0x2ac
> [<c0141fd3>] trace_hardirqs_on+0x122/0x14c
> [<c0439a0c>] mutex_lock_nested+0x2a4/0x2ac
> [<c03a48d1>] register_netdevice_notifier+0xe/0x126
> [<c03a48d1>] register_netdevice_notifier+0xe/0x126
> [<c03a490c>] register_netdevice_notifier+0x49/0x126
> [<c05c5be7>] addrconf_init+0xad/0x193
> [<c05c5b55>] addrconf_init+0x1b/0x193
> [<c05c5a2d>] inet6_init+0x1f0/0x2ad
> [<c05a9499>] kernel_init+0x150/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c0104baf>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
> hardirq-on-W at:
> [<c01419ba>] mark_lock+0x64/0x451
> [<c014289e>] __lock_acquire+0x488/0xc07
> [<c0143096>] lock_acquire+0x79/0x93
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c043a6ea>] _spin_lock_bh+0x3b/0x64
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c0412a9c>] igmp6_group_added+0x56/0x11d
> [<c0412e30>] ipv6_dev_mc_inc+0x2a3/0x31c
> [<c0410100>] icmpv6_rcv+0x630/0x828
> [<c0412e65>] ipv6_dev_mc_inc+0x2d8/0x31c
> [<c0412b8d>] ipv6_dev_mc_inc+0x0/0x31c
> [<c04021bc>] ipv6_add_dev+0x21c/0x24b
> [<c040ba05>] ndisc_ifinfo_sysctl_change+0x0/0x1ef
> [<c040279f>] addrconf_notify+0x60/0x7b7
> [<c0142fd5>] __lock_acquire+0xbbf/0xc07
> [<c0141de0>] mark_held_locks+0x39/0x53
> [<c04399ee>] mutex_lock_nested+0x286/0x2ac
> [<c0141fd3>] trace_hardirqs_on+0x122/0x14c
> [<c0439a0c>] mutex_lock_nested+0x2a4/0x2ac
> [<c03a48d1>] register_netdevice_notifier+0xe/0x126
> [<c03a48d1>] register_netdevice_notifier+0xe/0x126
> [<c03a490c>] register_netdevice_notifier+0x49/0x126
> [<c05c5be7>] addrconf_init+0xad/0x193
> [<c05c5b55>] addrconf_init+0x1b/0x193
> [<c05c5a2d>] inet6_init+0x1f0/0x2ad
> [<c05a9499>] kernel_init+0x150/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c0104baf>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
> }
> ... key at: [<c0877804>] bonding_netdev_xmit_lock_key+0x0/0x8
> -> (&bond->lock){-.--} ops: 103 {
> initial-use at:
> [<c013fe69>] put_lock_stats+0xa/0x1e
> [<c01428d0>] __lock_acquire+0x4ba/0xc07
> [<c0141de0>] mark_held_locks+0x39/0x53
> [<c043ad4d>] _spin_unlock_irqrestore+0x40/0x58
> [<c0143096>] lock_acquire+0x79/0x93
> [<c02ee6f1>] bond_get_stats+0x28/0xd0
> [<c043a876>] _read_lock_bh+0x3b/0x64
> [<c02ee6f1>] bond_get_stats+0x28/0xd0
> [<c02ee6f1>] bond_get_stats+0x28/0xd0
> [<c03aad6b>] rtnl_fill_ifinfo+0x2bf/0x563
> [<c03ab2e9>] rtmsg_ifinfo+0x5d/0xdf
> [<c03ab3aa>] rtnetlink_event+0x3f/0x42
> [<c013ac54>] notifier_call_chain+0x2a/0x52
> [<c013ac9e>] raw_notifier_call_chain+0x17/0x1a
> [<c03a3b62>] register_netdevice+0x2a7/0x2e7
> [<c02ee292>] bond_create+0x1f2/0x26a
> [<c05bedda>] bonding_init+0x761/0x7ea
> [<c05be642>] e1000_init_module+0x45/0x7c
> [<c05a9499>] kernel_init+0x150/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c0104baf>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
> hardirq-on-W at:
> [<c014289e>] __lock_acquire+0x488/0xc07
> [<c0141de0>] mark_held_locks+0x39/0x53
> [<c043ad85>] _spin_unlock_irq+0x20/0x41
> [<c0142fd5>] __lock_acquire+0xbbf/0xc07
> [<c043ad90>] _spin_unlock_irq+0x2b/0x41
> [<c012208a>] finish_task_switch+0x50/0x8c
> [<c0143096>] lock_acquire+0x79/0x93
> [<c02ee4a5>] bond_set_multicast_list+0x1d/0x241
> [<c043a7ad>] _write_lock_bh+0x3b/0x64
> [<c02ee4a5>] bond_set_multicast_list+0x1d/0x241
> [<c02ee4a5>] bond_set_multicast_list+0x1d/0x241
> [<c013fe69>] put_lock_stats+0xa/0x1e
> [<c03a1e5f>] __dev_set_rx_mode+0x7b/0x7d
> [<c03a1ff9>] dev_set_rx_mode+0x23/0x36
> [<c03a46d4>] dev_open+0x5e/0x77
> [<c03a33a3>] dev_change_flags+0x9d/0x14b
> [<c03a21a7>] __dev_get_by_name+0x68/0x73
> [<c03e41d8>] devinet_ioctl+0x22b/0x536
> [<c03a44c9>] dev_ioctl+0x46f/0x5b7
> [<c039a5fc>] sock_ioctl+0x167/0x18b
> [<c039a495>] sock_ioctl+0x0/0x18b
> [<c0172f97>] do_ioctl+0x1f/0x62
> [<c0173207>] vfs_ioctl+0x22d/0x23f
> [<c0141fd3>] trace_hardirqs_on+0x122/0x14c
> [<c017324c>] sys_ioctl+0x33/0x4b
> [<c0103e92>] sysenter_past_esp+0x5f/0xa5
> [<ffffffff>] 0xffffffff
> softirq-on-R at:
> [<c01419ba>] mark_lock+0x64/0x451
> [<c0135792>] __kernel_text_address+0x5/0xe
> [<c0104ee2>] dump_trace+0x83/0x8d
> [<c01428bd>] __lock_acquire+0x4a7/0xc07
> [<c013fcaa>] save_trace+0x37/0x89
> [<c0133c8b>] run_workqueue+0x87/0x1b6
> [<c0143096>] lock_acquire+0x79/0x93
> [<c02ef88d>] bond_mii_monitor+0x19/0x85
> [<c043a8d5>] _read_lock+0x36/0x5f
> [<c02ef88d>] bond_mii_monitor+0x19/0x85
> [<c02ef88d>] bond_mii_monitor+0x19/0x85
> [<c0133cdf>] run_workqueue+0xdb/0x1b6
> [<c0133c8b>] run_workqueue+0x87/0x1b6
> [<c02ef874>] bond_mii_monitor+0x0/0x85
> [<c01346ff>] worker_thread+0x0/0x85
> [<c0134778>] worker_thread+0x79/0x85
> [<c01371ad>] autoremove_wake_function+0x0/0x35
> [<c01370f6>] kthread+0x38/0x5e
> [<c01370be>] kthread+0x0/0x5e
> [<c0104baf>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
> hardirq-on-R at:
> [<c013fe3e>] get_lock_stats+0xd/0x2e
> [<c013fe69>] put_lock_stats+0xa/0x1e
> [<c0142878>] __lock_acquire+0x462/0xc07
> [<c0141de0>] mark_held_locks+0x39/0x53
> [<c043ad4d>] _spin_unlock_irqrestore+0x40/0x58
> [<c0143096>] lock_acquire+0x79/0x93
> [<c02ee6f1>] bond_get_stats+0x28/0xd0
> [<c043a876>] _read_lock_bh+0x3b/0x64
> [<c02ee6f1>] bond_get_stats+0x28/0xd0
> [<c02ee6f1>] bond_get_stats+0x28/0xd0
> [<c03aad6b>] rtnl_fill_ifinfo+0x2bf/0x563
> [<c03ab2e9>] rtmsg_ifinfo+0x5d/0xdf
> [<c03ab3aa>] rtnetlink_event+0x3f/0x42
> [<c013ac54>] notifier_call_chain+0x2a/0x52
> [<c013ac9e>] raw_notifier_call_chain+0x17/0x1a
> [<c03a3b62>] register_netdevice+0x2a7/0x2e7
> [<c02ee292>] bond_create+0x1f2/0x26a
> [<c05bedda>] bonding_init+0x761/0x7ea
> [<c05be642>] e1000_init_module+0x45/0x7c
> [<c05a9499>] kernel_init+0x150/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c0104baf>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
> }
> ... key at: [<c08777d0>] __key.32970+0x0/0x8
> -> (_xmit_ETHER){-...} ops: 8 {
> initial-use at:
> [<c01428d0>] __lock_acquire+0x4ba/0xc07
> [<c0143096>] lock_acquire+0x79/0x93
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c043a6ea>] _spin_lock_bh+0x3b/0x64
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c0412a9c>] igmp6_group_added+0x56/0x11d
> [<c0412e30>] ipv6_dev_mc_inc+0x2a3/0x31c
> [<c0410100>] icmpv6_rcv+0x630/0x828
> [<c0412e65>] ipv6_dev_mc_inc+0x2d8/0x31c
> [<c0412b8d>] ipv6_dev_mc_inc+0x0/0x31c
> [<c04021bc>] ipv6_add_dev+0x21c/0x24b
> [<c040ba05>] ndisc_ifinfo_sysctl_change+0x0/0x1ef
> [<c040279f>] addrconf_notify+0x60/0x7b7
> [<c0142fd5>] __lock_acquire+0xbbf/0xc07
> [<c0141de0>] mark_held_locks+0x39/0x53
> [<c04399ee>] mutex_lock_nested+0x286/0x2ac
> [<c0141fd3>] trace_hardirqs_on+0x122/0x14c
> [<c0439a0c>] mutex_lock_nested+0x2a4/0x2ac
> [<c03a48d1>]
> register_netdevice_notifier+0xe/0x126
> [<c03a48d1>]
> register_netdevice_notifier+0xe/0x126
> [<c03a490c>]
> register_netdevice_notifier+0x49/0x126
> [<c05c5be7>] addrconf_init+0xad/0x193
> [<c05c5b55>] addrconf_init+0x1b/0x193
> [<c05c5a2d>] inet6_init+0x1f0/0x2ad
> [<c05a9499>] kernel_init+0x150/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c0104baf>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
> hardirq-on-W at:
> [<c01419ba>] mark_lock+0x64/0x451
> [<c014289e>] __lock_acquire+0x488/0xc07
> [<c0143096>] lock_acquire+0x79/0x93
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c043a6ea>] _spin_lock_bh+0x3b/0x64
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c0412a9c>] igmp6_group_added+0x56/0x11d
> [<c0412e30>] ipv6_dev_mc_inc+0x2a3/0x31c
> [<c0410100>] icmpv6_rcv+0x630/0x828
> [<c0412e65>] ipv6_dev_mc_inc+0x2d8/0x31c
> [<c0412b8d>] ipv6_dev_mc_inc+0x0/0x31c
> [<c04021bc>] ipv6_add_dev+0x21c/0x24b
> [<c040ba05>] ndisc_ifinfo_sysctl_change+0x0/0x1ef
> [<c040279f>] addrconf_notify+0x60/0x7b7
> [<c0142fd5>] __lock_acquire+0xbbf/0xc07
> [<c0141de0>] mark_held_locks+0x39/0x53
> [<c04399ee>] mutex_lock_nested+0x286/0x2ac
> [<c0141fd3>] trace_hardirqs_on+0x122/0x14c
> [<c0439a0c>] mutex_lock_nested+0x2a4/0x2ac
> [<c03a48d1>]
> register_netdevice_notifier+0xe/0x126
> [<c03a48d1>]
> register_netdevice_notifier+0xe/0x126
> [<c03a490c>]
> register_netdevice_notifier+0x49/0x126
> [<c05c5be7>] addrconf_init+0xad/0x193
> [<c05c5b55>] addrconf_init+0x1b/0x193
> [<c05c5a2d>] inet6_init+0x1f0/0x2ad
> [<c05a9499>] kernel_init+0x150/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c0104baf>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
> }
> ... key at: [<c087adc8>] netdev_xmit_lock_key+0x8/0x1c0
> ... acquired at:
> [<c0142e33>] __lock_acquire+0xa1d/0xc07
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c043ad4d>] _spin_unlock_irqrestore+0x40/0x58
> [<c0109eee>] save_stack_trace+0x20/0x3a
> [<c0143096>] lock_acquire+0x79/0x93
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c043a6ea>] _spin_lock_bh+0x3b/0x64
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c02eeec2>] bond_change_active_slave+0x1a9/0x3bf
> [<c02ed1f3>] bond_update_speed_duplex+0x26/0x65
> [<c02ef3df>] bond_select_active_slave+0x95/0xcd
> [<c02edc5b>] bond_compute_features+0x45/0x84
> [<c02f03ee>] bond_enslave+0x6a7/0x884
> [<c0439a0c>] mutex_lock_nested+0x2a4/0x2ac
> [<c02f6b98>] bonding_store_slaves+0x1ae/0x2fb
> [<c02f69ea>] bonding_store_slaves+0x0/0x2fb
> [<c02cf307>] dev_attr_store+0x27/0x2c
> [<c019c6b5>] sysfs_write_file+0xad/0xe0
> [<c019c608>] sysfs_write_file+0x0/0xe0
> [<c0169770>] vfs_write+0x8a/0x10c
> [<c0118566>] do_page_fault+0x0/0x54a
> [<c0169cf5>] sys_write+0x41/0x67
> [<c0103e92>] sysenter_past_esp+0x5f/0xa5
> [<ffffffff>] 0xffffffff
>
> -> (lweventlist_lock){.+..} ops: 10 {
> initial-use at:
> [<c01419ba>] mark_lock+0x64/0x451
> [<c01428d0>] __lock_acquire+0x4ba/0xc07
> [<c02e408c>] e1000_read_phy_reg+0x1c7/0x1d3
> [<c02e3ebb>] e1000_write_phy_reg+0xb9/0xc3
> [<c024b1de>] delay_tsc+0x25/0x3b
> [<c0143096>] lock_acquire+0x79/0x93
> [<c03ac47b>] linkwatch_add_event+0xd/0x2c
> [<c043aa07>] _spin_lock_irqsave+0x3f/0x6c
> [<c03ac47b>] linkwatch_add_event+0xd/0x2c
> [<c03ac47b>] linkwatch_add_event+0xd/0x2c
> [<c03ac53f>] linkwatch_fire_event+0x25/0x37
> [<c02e2673>] e1000_probe+0xad1/0xbe8
> [<c025893f>] pci_device_probe+0x36/0x57
> [<c02d188f>] driver_probe_device+0xe1/0x15f
> [<c043ac81>] _spin_unlock+0x25/0x3b
> [<c0437f3a>] klist_next+0x58/0x6d
> [<c02d199f>] __driver_attach+0x0/0x7f
> [<c02d19e8>] __driver_attach+0x49/0x7f
> [<c02d0e33>] bus_for_each_dev+0x36/0x58
> [<c02d16e7>] driver_attach+0x16/0x18
> [<c02d199f>] __driver_attach+0x0/0x7f
> [<c02d112a>] bus_add_driver+0x6d/0x18d
> [<c0258a89>] __pci_register_driver+0x53/0x7f
> [<c05be642>] e1000_init_module+0x45/0x7c
> [<c05a9499>] kernel_init+0x150/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c0104baf>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
> in-softirq-W at:
> [<c011d20a>] __wake_up_common+0x32/0x5c
> [<c0142856>] __lock_acquire+0x440/0xc07
> [<c043ad4d>] _spin_unlock_irqrestore+0x40/0x58
> [<c0143096>] lock_acquire+0x79/0x93
> [<c03ac47b>] linkwatch_add_event+0xd/0x2c
> [<c02e0931>] e1000_watchdog+0x0/0x5c9
> [<c043aa07>] _spin_lock_irqsave+0x3f/0x6c
> [<c03ac47b>] linkwatch_add_event+0xd/0x2c
> [<c03ac47b>] linkwatch_add_event+0xd/0x2c
> [<c03ac53f>] linkwatch_fire_event+0x25/0x37
> [<c03af4c6>] netif_carrier_on+0x16/0x27
> [<c02e0b86>] e1000_watchdog+0x255/0x5c9
> [<c02e0931>] e1000_watchdog+0x0/0x5c9
> [<c012df86>] run_timer_softirq+0xfa/0x15d
> [<c012a8da>] __do_softirq+0x56/0xdb
> [<c0141fbd>] trace_hardirqs_on+0x10c/0x14c
> [<c012a8ec>] __do_softirq+0x68/0xdb
> [<c012a995>] do_softirq+0x36/0x51
> [<c012ae7e>] local_bh_enable_ip+0xad/0xed
> [<c03bfa8b>] rt_run_flush+0x64/0x8b
> [<c03e82d4>] ip_mc_inc_group+0x184/0x1c1
> [<c03e8352>] ip_mc_up+0x41/0x59
> [<c03e3c8c>] inetdev_event+0x257/0x465
> [<c03ab286>] rtnl_notify+0x3a/0x40
> [<c03ab343>] rtmsg_ifinfo+0xb7/0xdf
> [<c013ac54>] notifier_call_chain+0x2a/0x52
> [<c013ac9e>] raw_notifier_call_chain+0x17/0x1a
> [<c03a46e7>] dev_open+0x71/0x77
> [<c02f0056>] bond_enslave+0x30f/0x884
> [<c0439a0c>] mutex_lock_nested+0x2a4/0x2ac
> [<c02f6b8c>] bonding_store_slaves+0x1a2/0x2fb
> [<c02f6b98>] bonding_store_slaves+0x1ae/0x2fb
> [<c02f69ea>] bonding_store_slaves+0x0/0x2fb
> [<c02cf307>] dev_attr_store+0x27/0x2c
> [<c019c6b5>] sysfs_write_file+0xad/0xe0
> [<c019c608>] sysfs_write_file+0x0/0xe0
> [<c0169770>] vfs_write+0x8a/0x10c
> [<c0118566>] do_page_fault+0x0/0x54a
> [<c0169cf5>] sys_write+0x41/0x67
> [<c0103e92>] sysenter_past_esp+0x5f/0xa5
> [<ffffffff>] 0xffffffff
> }
> ... key at: [<c058a214>] lweventlist_lock+0x14/0x40
> ... acquired at:
> [<c0142e33>] __lock_acquire+0xa1d/0xc07
> [<c03ac47b>] linkwatch_add_event+0xd/0x2c
> [<c0142fd5>] __lock_acquire+0xbbf/0xc07
> [<c0143096>] lock_acquire+0x79/0x93
> [<c03ac47b>] linkwatch_add_event+0xd/0x2c
> [<c043aa07>] _spin_lock_irqsave+0x3f/0x6c
> [<c03ac47b>] linkwatch_add_event+0xd/0x2c
> [<c03ac47b>] linkwatch_add_event+0xd/0x2c
> [<c03ac53f>] linkwatch_fire_event+0x25/0x37
> [<c03af4c6>] netif_carrier_on+0x16/0x27
> [<c02ee85c>] bond_set_carrier+0x31/0x55
> [<c02ef3e6>] bond_select_active_slave+0x9c/0xcd
> [<c02edc5b>] bond_compute_features+0x45/0x84
> [<c02f03ee>] bond_enslave+0x6a7/0x884
> [<c0439a0c>] mutex_lock_nested+0x2a4/0x2ac
> [<c02f6b98>] bonding_store_slaves+0x1ae/0x2fb
> [<c02f69ea>] bonding_store_slaves+0x0/0x2fb
> [<c02cf307>] dev_attr_store+0x27/0x2c
> [<c019c6b5>] sysfs_write_file+0xad/0xe0
> [<c019c608>] sysfs_write_file+0x0/0xe0
> [<c0169770>] vfs_write+0x8a/0x10c
> [<c0118566>] do_page_fault+0x0/0x54a
> [<c0169cf5>] sys_write+0x41/0x67
> [<c0103e92>] sysenter_past_esp+0x5f/0xa5
> [<ffffffff>] 0xffffffff
>
> ... acquired at:
> [<c0142e33>] __lock_acquire+0xa1d/0xc07
> [<c02ee4a5>] bond_set_multicast_list+0x1d/0x241
> [<c0141de0>] mark_held_locks+0x39/0x53
> [<c0143096>] lock_acquire+0x79/0x93
> [<c02ee4a5>] bond_set_multicast_list+0x1d/0x241
> [<c043a7ad>] _write_lock_bh+0x3b/0x64
> [<c02ee4a5>] bond_set_multicast_list+0x1d/0x241
> [<c02ee4a5>] bond_set_multicast_list+0x1d/0x241
> [<c013fe69>] put_lock_stats+0xa/0x1e
> [<c03a1e5f>] __dev_set_rx_mode+0x7b/0x7d
> [<c03a1ff9>] dev_set_rx_mode+0x23/0x36
> [<c03a46d4>] dev_open+0x5e/0x77
> [<c03a33a3>] dev_change_flags+0x9d/0x14b
> [<c03a21a7>] __dev_get_by_name+0x68/0x73
> [<c03e41d8>] devinet_ioctl+0x22b/0x536
> [<c03a44c9>] dev_ioctl+0x46f/0x5b7
> [<c039a5fc>] sock_ioctl+0x167/0x18b
> [<c039a495>] sock_ioctl+0x0/0x18b
> [<c0172f97>] do_ioctl+0x1f/0x62
> [<c0173207>] vfs_ioctl+0x22d/0x23f
> [<c0141fd3>] trace_hardirqs_on+0x122/0x14c
> [<c017324c>] sys_ioctl+0x33/0x4b
> [<c0103e92>] sysenter_past_esp+0x5f/0xa5
> [<ffffffff>] 0xffffffff
>
> ... acquired at:
> [<c0142e33>] __lock_acquire+0xa1d/0xc07
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c0143096>] lock_acquire+0x79/0x93
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c043a6ea>] _spin_lock_bh+0x3b/0x64
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c0412a9c>] igmp6_group_added+0x56/0x11d
> [<c0412e30>] ipv6_dev_mc_inc+0x2a3/0x31c
> [<c0410100>] icmpv6_rcv+0x630/0x828
> [<c0412e65>] ipv6_dev_mc_inc+0x2d8/0x31c
> [<c0412b8d>] ipv6_dev_mc_inc+0x0/0x31c
> [<c04021bc>] ipv6_add_dev+0x21c/0x24b
> [<c040ba05>] ndisc_ifinfo_sysctl_change+0x0/0x1ef
> [<c040279f>] addrconf_notify+0x60/0x7b7
> [<c0142fd5>] __lock_acquire+0xbbf/0xc07
> [<c0141de0>] mark_held_locks+0x39/0x53
> [<c04399ee>] mutex_lock_nested+0x286/0x2ac
> [<c0141fd3>] trace_hardirqs_on+0x122/0x14c
> [<c0439a0c>] mutex_lock_nested+0x2a4/0x2ac
> [<c03a48d1>] register_netdevice_notifier+0xe/0x126
> [<c03a48d1>] register_netdevice_notifier+0xe/0x126
> [<c03a490c>] register_netdevice_notifier+0x49/0x126
> [<c05c5be7>] addrconf_init+0xad/0x193
> [<c05c5b55>] addrconf_init+0x1b/0x193
> [<c05c5a2d>] inet6_init+0x1f0/0x2ad
> [<c05a9499>] kernel_init+0x150/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c0104baf>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
>
>
> the second lock's dependencies:
> -> (&bond->lock){-.--} ops: 103 {
> initial-use at:
> [<c013fe69>] put_lock_stats+0xa/0x1e
> [<c01428d0>] __lock_acquire+0x4ba/0xc07
> [<c0141de0>] mark_held_locks+0x39/0x53
> [<c043ad4d>] _spin_unlock_irqrestore+0x40/0x58
> [<c0143096>] lock_acquire+0x79/0x93
> [<c02ee6f1>] bond_get_stats+0x28/0xd0
> [<c043a876>] _read_lock_bh+0x3b/0x64
> [<c02ee6f1>] bond_get_stats+0x28/0xd0
> [<c02ee6f1>] bond_get_stats+0x28/0xd0
> [<c03aad6b>] rtnl_fill_ifinfo+0x2bf/0x563
> [<c03ab2e9>] rtmsg_ifinfo+0x5d/0xdf
> [<c03ab3aa>] rtnetlink_event+0x3f/0x42
> [<c013ac54>] notifier_call_chain+0x2a/0x52
> [<c013ac9e>] raw_notifier_call_chain+0x17/0x1a
> [<c03a3b62>] register_netdevice+0x2a7/0x2e7
> [<c02ee292>] bond_create+0x1f2/0x26a
> [<c05bedda>] bonding_init+0x761/0x7ea
> [<c05be642>] e1000_init_module+0x45/0x7c
> [<c05a9499>] kernel_init+0x150/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c0104baf>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
> hardirq-on-W at:
> [<c014289e>] __lock_acquire+0x488/0xc07
> [<c0141de0>] mark_held_locks+0x39/0x53
> [<c043ad85>] _spin_unlock_irq+0x20/0x41
> [<c0142fd5>] __lock_acquire+0xbbf/0xc07
> [<c043ad90>] _spin_unlock_irq+0x2b/0x41
> [<c012208a>] finish_task_switch+0x50/0x8c
> [<c0143096>] lock_acquire+0x79/0x93
> [<c02ee4a5>] bond_set_multicast_list+0x1d/0x241
> [<c043a7ad>] _write_lock_bh+0x3b/0x64
> [<c02ee4a5>] bond_set_multicast_list+0x1d/0x241
> [<c02ee4a5>] bond_set_multicast_list+0x1d/0x241
> [<c013fe69>] put_lock_stats+0xa/0x1e
> [<c03a1e5f>] __dev_set_rx_mode+0x7b/0x7d
> [<c03a1ff9>] dev_set_rx_mode+0x23/0x36
> [<c03a46d4>] dev_open+0x5e/0x77
> [<c03a33a3>] dev_change_flags+0x9d/0x14b
> [<c03a21a7>] __dev_get_by_name+0x68/0x73
> [<c03e41d8>] devinet_ioctl+0x22b/0x536
> [<c03a44c9>] dev_ioctl+0x46f/0x5b7
> [<c039a5fc>] sock_ioctl+0x167/0x18b
> [<c039a495>] sock_ioctl+0x0/0x18b
> [<c0172f97>] do_ioctl+0x1f/0x62
> [<c0173207>] vfs_ioctl+0x22d/0x23f
> [<c0141fd3>] trace_hardirqs_on+0x122/0x14c
> [<c017324c>] sys_ioctl+0x33/0x4b
> [<c0103e92>] sysenter_past_esp+0x5f/0xa5
> [<ffffffff>] 0xffffffff
> softirq-on-R at:
> [<c01419ba>] mark_lock+0x64/0x451
> [<c0135792>] __kernel_text_address+0x5/0xe
> [<c0104ee2>] dump_trace+0x83/0x8d
> [<c01428bd>] __lock_acquire+0x4a7/0xc07
> [<c013fcaa>] save_trace+0x37/0x89
> [<c0133c8b>] run_workqueue+0x87/0x1b6
> [<c0143096>] lock_acquire+0x79/0x93
> [<c02ef88d>] bond_mii_monitor+0x19/0x85
> [<c043a8d5>] _read_lock+0x36/0x5f
> [<c02ef88d>] bond_mii_monitor+0x19/0x85
> [<c02ef88d>] bond_mii_monitor+0x19/0x85
> [<c0133cdf>] run_workqueue+0xdb/0x1b6
> [<c0133c8b>] run_workqueue+0x87/0x1b6
> [<c02ef874>] bond_mii_monitor+0x0/0x85
> [<c01346ff>] worker_thread+0x0/0x85
> [<c0134778>] worker_thread+0x79/0x85
> [<c01371ad>] autoremove_wake_function+0x0/0x35
> [<c01370f6>] kthread+0x38/0x5e
> [<c01370be>] kthread+0x0/0x5e
> [<c0104baf>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
> hardirq-on-R at:
> [<c013fe3e>] get_lock_stats+0xd/0x2e
> [<c013fe69>] put_lock_stats+0xa/0x1e
> [<c0142878>] __lock_acquire+0x462/0xc07
> [<c0141de0>] mark_held_locks+0x39/0x53
> [<c043ad4d>] _spin_unlock_irqrestore+0x40/0x58
> [<c0143096>] lock_acquire+0x79/0x93
> [<c02ee6f1>] bond_get_stats+0x28/0xd0
> [<c043a876>] _read_lock_bh+0x3b/0x64
> [<c02ee6f1>] bond_get_stats+0x28/0xd0
> [<c02ee6f1>] bond_get_stats+0x28/0xd0
> [<c03aad6b>] rtnl_fill_ifinfo+0x2bf/0x563
> [<c03ab2e9>] rtmsg_ifinfo+0x5d/0xdf
> [<c03ab3aa>] rtnetlink_event+0x3f/0x42
> [<c013ac54>] notifier_call_chain+0x2a/0x52
> [<c013ac9e>] raw_notifier_call_chain+0x17/0x1a
> [<c03a3b62>] register_netdevice+0x2a7/0x2e7
> [<c02ee292>] bond_create+0x1f2/0x26a
> [<c05bedda>] bonding_init+0x761/0x7ea
> [<c05be642>] e1000_init_module+0x45/0x7c
> [<c05a9499>] kernel_init+0x150/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c0104baf>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
> }
> ... key at: [<c08777d0>] __key.32970+0x0/0x8
> -> (_xmit_ETHER){-...} ops: 8 {
> initial-use at:
> [<c01428d0>] __lock_acquire+0x4ba/0xc07
> [<c0143096>] lock_acquire+0x79/0x93
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c043a6ea>] _spin_lock_bh+0x3b/0x64
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c0412a9c>] igmp6_group_added+0x56/0x11d
> [<c0412e30>] ipv6_dev_mc_inc+0x2a3/0x31c
> [<c0410100>] icmpv6_rcv+0x630/0x828
> [<c0412e65>] ipv6_dev_mc_inc+0x2d8/0x31c
> [<c0412b8d>] ipv6_dev_mc_inc+0x0/0x31c
> [<c04021bc>] ipv6_add_dev+0x21c/0x24b
> [<c040ba05>] ndisc_ifinfo_sysctl_change+0x0/0x1ef
> [<c040279f>] addrconf_notify+0x60/0x7b7
> [<c0142fd5>] __lock_acquire+0xbbf/0xc07
> [<c0141de0>] mark_held_locks+0x39/0x53
> [<c04399ee>] mutex_lock_nested+0x286/0x2ac
> [<c0141fd3>] trace_hardirqs_on+0x122/0x14c
> [<c0439a0c>] mutex_lock_nested+0x2a4/0x2ac
> [<c03a48d1>] register_netdevice_notifier+0xe/0x126
> [<c03a48d1>] register_netdevice_notifier+0xe/0x126
> [<c03a490c>] register_netdevice_notifier+0x49/0x126
> [<c05c5be7>] addrconf_init+0xad/0x193
> [<c05c5b55>] addrconf_init+0x1b/0x193
> [<c05c5a2d>] inet6_init+0x1f0/0x2ad
> [<c05a9499>] kernel_init+0x150/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c0104baf>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
> hardirq-on-W at:
> [<c01419ba>] mark_lock+0x64/0x451
> [<c014289e>] __lock_acquire+0x488/0xc07
> [<c0143096>] lock_acquire+0x79/0x93
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c043a6ea>] _spin_lock_bh+0x3b/0x64
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c0412a9c>] igmp6_group_added+0x56/0x11d
> [<c0412e30>] ipv6_dev_mc_inc+0x2a3/0x31c
> [<c0410100>] icmpv6_rcv+0x630/0x828
> [<c0412e65>] ipv6_dev_mc_inc+0x2d8/0x31c
> [<c0412b8d>] ipv6_dev_mc_inc+0x0/0x31c
> [<c04021bc>] ipv6_add_dev+0x21c/0x24b
> [<c040ba05>] ndisc_ifinfo_sysctl_change+0x0/0x1ef
> [<c040279f>] addrconf_notify+0x60/0x7b7
> [<c0142fd5>] __lock_acquire+0xbbf/0xc07
> [<c0141de0>] mark_held_locks+0x39/0x53
> [<c04399ee>] mutex_lock_nested+0x286/0x2ac
> [<c0141fd3>] trace_hardirqs_on+0x122/0x14c
> [<c0439a0c>] mutex_lock_nested+0x2a4/0x2ac
> [<c03a48d1>] register_netdevice_notifier+0xe/0x126
> [<c03a48d1>] register_netdevice_notifier+0xe/0x126
> [<c03a490c>] register_netdevice_notifier+0x49/0x126
> [<c05c5be7>] addrconf_init+0xad/0x193
> [<c05c5b55>] addrconf_init+0x1b/0x193
> [<c05c5a2d>] inet6_init+0x1f0/0x2ad
> [<c05a9499>] kernel_init+0x150/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c0104baf>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
> }
> ... key at: [<c087adc8>] netdev_xmit_lock_key+0x8/0x1c0
> ... acquired at:
> [<c0142e33>] __lock_acquire+0xa1d/0xc07
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c043ad4d>] _spin_unlock_irqrestore+0x40/0x58
> [<c0109eee>] save_stack_trace+0x20/0x3a
> [<c0143096>] lock_acquire+0x79/0x93
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c043a6ea>] _spin_lock_bh+0x3b/0x64
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c03a6425>] dev_mc_add+0x1a/0x6a
> [<c02eeec2>] bond_change_active_slave+0x1a9/0x3bf
> [<c02ed1f3>] bond_update_speed_duplex+0x26/0x65
> [<c02ef3df>] bond_select_active_slave+0x95/0xcd
> [<c02edc5b>] bond_compute_features+0x45/0x84
> [<c02f03ee>] bond_enslave+0x6a7/0x884
> [<c0439a0c>] mutex_lock_nested+0x2a4/0x2ac
> [<c02f6b98>] bonding_store_slaves+0x1ae/0x2fb
> [<c02f69ea>] bonding_store_slaves+0x0/0x2fb
> [<c02cf307>] dev_attr_store+0x27/0x2c
> [<c019c6b5>] sysfs_write_file+0xad/0xe0
> [<c019c608>] sysfs_write_file+0x0/0xe0
> [<c0169770>] vfs_write+0x8a/0x10c
> [<c0118566>] do_page_fault+0x0/0x54a
> [<c0169cf5>] sys_write+0x41/0x67
> [<c0103e92>] sysenter_past_esp+0x5f/0xa5
> [<ffffffff>] 0xffffffff
>
> -> (lweventlist_lock){.+..} ops: 10 {
> initial-use at:
> [<c01419ba>] mark_lock+0x64/0x451
> [<c01428d0>] __lock_acquire+0x4ba/0xc07
> [<c02e408c>] e1000_read_phy_reg+0x1c7/0x1d3
> [<c02e3ebb>] e1000_write_phy_reg+0xb9/0xc3
> [<c024b1de>] delay_tsc+0x25/0x3b
> [<c0143096>] lock_acquire+0x79/0x93
> [<c03ac47b>] linkwatch_add_event+0xd/0x2c
> [<c043aa07>] _spin_lock_irqsave+0x3f/0x6c
> [<c03ac47b>] linkwatch_add_event+0xd/0x2c
> [<c03ac47b>] linkwatch_add_event+0xd/0x2c
> [<c03ac53f>] linkwatch_fire_event+0x25/0x37
> [<c02e2673>] e1000_probe+0xad1/0xbe8
> [<c025893f>] pci_device_probe+0x36/0x57
> [<c02d188f>] driver_probe_device+0xe1/0x15f
> [<c043ac81>] _spin_unlock+0x25/0x3b
> [<c0437f3a>] klist_next+0x58/0x6d
> [<c02d199f>] __driver_attach+0x0/0x7f
> [<c02d19e8>] __driver_attach+0x49/0x7f
> [<c02d0e33>] bus_for_each_dev+0x36/0x58
> [<c02d16e7>] driver_attach+0x16/0x18
> [<c02d199f>] __driver_attach+0x0/0x7f
> [<c02d112a>] bus_add_driver+0x6d/0x18d
> [<c0258a89>] __pci_register_driver+0x53/0x7f
> [<c05be642>] e1000_init_module+0x45/0x7c
> [<c05a9499>] kernel_init+0x150/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c05a9349>] kernel_init+0x0/0x2b7
> [<c0104baf>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
> in-softirq-W at:
> [<c011d20a>] __wake_up_common+0x32/0x5c
> [<c0142856>] __lock_acquire+0x440/0xc07
> [<c043ad4d>] _spin_unlock_irqrestore+0x40/0x58
> [<c0143096>] lock_acquire+0x79/0x93
> [<c03ac47b>] linkwatch_add_event+0xd/0x2c
> [<c02e0931>] e1000_watchdog+0x0/0x5c9
> [<c043aa07>] _spin_lock_irqsave+0x3f/0x6c
> [<c03ac47b>] linkwatch_add_event+0xd/0x2c
> [<c03ac47b>] linkwatch_add_event+0xd/0x2c
> [<c03ac53f>] linkwatch_fire_event+0x25/0x37
> [<c03af4c6>] netif_carrier_on+0x16/0x27
> [<c02e0b86>] e1000_watchdog+0x255/0x5c9
> [<c02e0931>] e1000_watchdog+0x0/0x5c9
> [<c012df86>] run_timer_softirq+0xfa/0x15d
> [<c012a8da>] __do_softirq+0x56/0xdb
> [<c0141fbd>] trace_hardirqs_on+0x10c/0x14c
> [<c012a8ec>] __do_softirq+0x68/0xdb
> [<c012a995>] do_softirq+0x36/0x51
> [<c012ae7e>] local_bh_enable_ip+0xad/0xed
> [<c03bfa8b>] rt_run_flush+0x64/0x8b
> [<c03e82d4>] ip_mc_inc_group+0x184/0x1c1
> [<c03e8352>] ip_mc_up+0x41/0x59
> [<c03e3c8c>] inetdev_event+0x257/0x465
> [<c03ab286>] rtnl_notify+0x3a/0x40
> [<c03ab343>] rtmsg_ifinfo+0xb7/0xdf
> [<c013ac54>] notifier_call_chain+0x2a/0x52
> [<c013ac9e>] raw_notifier_call_chain+0x17/0x1a
> [<c03a46e7>] dev_open+0x71/0x77
> [<c02f0056>] bond_enslave+0x30f/0x884
> [<c0439a0c>] mutex_lock_nested+0x2a4/0x2ac
> [<c02f6b8c>] bonding_store_slaves+0x1a2/0x2fb
> [<c02f6b98>] bonding_store_slaves+0x1ae/0x2fb
> [<c02f69ea>] bonding_store_slaves+0x0/0x2fb
> [<c02cf307>] dev_attr_store+0x27/0x2c
> [<c019c6b5>] sysfs_write_file+0xad/0xe0
> [<c019c608>] sysfs_write_file+0x0/0xe0
> [<c0169770>] vfs_write+0x8a/0x10c
> [<c0118566>] do_page_fault+0x0/0x54a
> [<c0169cf5>] sys_write+0x41/0x67
> [<c0103e92>] sysenter_past_esp+0x5f/0xa5
> [<ffffffff>] 0xffffffff
> }
> ... key at: [<c058a214>] lweventlist_lock+0x14/0x40
> ... acquired at:
> [<c0142e33>] __lock_acquire+0xa1d/0xc07
> [<c03ac47b>] linkwatch_add_event+0xd/0x2c
> [<c0142fd5>] __lock_acquire+0xbbf/0xc07
> [<c0143096>] lock_acquire+0x79/0x93
> [<c03ac47b>] linkwatch_add_event+0xd/0x2c
> [<c043aa07>] _spin_lock_irqsave+0x3f/0x6c
> [<c03ac47b>] linkwatch_add_event+0xd/0x2c
> [<c03ac47b>] linkwatch_add_event+0xd/0x2c
> [<c03ac53f>] linkwatch_fire_event+0x25/0x37
> [<c03af4c6>] netif_carrier_on+0x16/0x27
> [<c02ee85c>] bond_set_carrier+0x31/0x55
> [<c02ef3e6>] bond_select_active_slave+0x9c/0xcd
> [<c02edc5b>] bond_compute_features+0x45/0x84
> [<c02f03ee>] bond_enslave+0x6a7/0x884
> [<c0439a0c>] mutex_lock_nested+0x2a4/0x2ac
> [<c02f6b98>] bonding_store_slaves+0x1ae/0x2fb
> [<c02f69ea>] bonding_store_slaves+0x0/0x2fb
> [<c02cf307>] dev_attr_store+0x27/0x2c
> [<c019c6b5>] sysfs_write_file+0xad/0xe0
> [<c019c608>] sysfs_write_file+0x0/0xe0
> [<c0169770>] vfs_write+0x8a/0x10c
> [<c0118566>] do_page_fault+0x0/0x54a
> [<c0169cf5>] sys_write+0x41/0x67
> [<c0103e92>] sysenter_past_esp+0x5f/0xa5
> [<ffffffff>] 0xffffffff
>
>
> stack backtrace:
> Pid: 9, comm: events/0 Not tainted 2.6.24-rc4-git7 #1
> [<c0140b6c>] print_irq_inversion_bug+0x108/0x112
> [<c0141951>] check_usage_forwards+0x3c/0x41
> [<c0141b3d>] mark_lock+0x1e7/0x451
> [<c0142856>] __lock_acquire+0x440/0xc07
> [<c0143096>] lock_acquire+0x79/0x93
> [<c0412602>] mld_ifc_timer_expire+0x130/0x1fb
> [<c04124d2>] mld_ifc_timer_expire+0x0/0x1fb
> [<c043a6ea>] _spin_lock_bh+0x3b/0x64
> [<c0412602>] mld_ifc_timer_expire+0x130/0x1fb
> [<c0412602>] mld_ifc_timer_expire+0x130/0x1fb
> [<c04124d2>] mld_ifc_timer_expire+0x0/0x1fb
> [<c0141fbd>] trace_hardirqs_on+0x10c/0x14c
> [<c04124d2>] mld_ifc_timer_expire+0x0/0x1fb
> [<c012df86>] run_timer_softirq+0xfa/0x15d
> [<c012a8da>] __do_softirq+0x56/0xdb
> [<c0141fbd>] trace_hardirqs_on+0x10c/0x14c
> [<c012a8ec>] __do_softirq+0x68/0xdb
> [<c012a995>] do_softirq+0x36/0x51
> [<c012ab3b>] irq_exit+0x43/0x4e
> [<c011411e>] smp_apic_timer_interrupt+0x74/0x80
> [<c012a8da>] __do_softirq+0x56/0xdb
> [<c0104a01>] apic_timer_interrupt+0x29/0x38
> [<c0104a0b>] apic_timer_interrupt+0x33/0x38
> [<c03b007b>] nl_pid_hash_rehash+0xc1/0x13f
> [<c03b00d8>] nl_pid_hash_rehash+0x11e/0x13f
> [<c012aea0>] local_bh_enable_ip+0xcf/0xed
> [<c03bfa8b>] rt_run_flush+0x64/0x8b
> [<c03e9c1e>] fib_netdev_event+0x61/0x65
> [<c013ac54>] notifier_call_chain+0x2a/0x52
> [<c013ac9e>] raw_notifier_call_chain+0x17/0x1a
> [<c03a3469>] netdev_state_change+0x18/0x29
> [<c03ac6a1>] __linkwatch_run_queue+0x150/0x17e
> [<c03ac6ec>] linkwatch_event+0x1d/0x22
> [<c0133cdf>] run_workqueue+0xdb/0x1b6
> [<c0133c8b>] run_workqueue+0x87/0x1b6
> [<c03ac6cf>] linkwatch_event+0x0/0x22
> [<c01346ff>] worker_thread+0x0/0x85
> [<c0134778>] worker_thread+0x79/0x85
> [<c01371ad>] autoremove_wake_function+0x0/0x35
> [<c01370f6>] kthread+0x38/0x5e
> [<c01370be>] kthread+0x0/0x5e
> [<c0104baf>] kernel_thread_helper+0x7/0x10
> =======================
> bonding: bond0: enslaving eth1 as a backup interface with a down link.
> bonding: bond0: Setting eth0 as primary slave.
> bond0: no IPv6 routers present
>
^ permalink raw reply
* Re: 2.6.24-rc4-mm1
From: Kok, Auke @ 2007-12-11 21:59 UTC (permalink / raw)
To: Kok, Auke
Cc: Andrew Morton, Martin Bligh, linux-kernel, Andy Whitcroft, netdev,
Thomas Gleixner, Ingo Molnar
In-Reply-To: <475F00A2.6020406@intel.com>
Kok, Auke wrote:
> Andrew Morton wrote:
>> On Tue, 11 Dec 2007 08:13:52 -0800 "Martin Bligh" <mbligh@google.com> wrote:
>>
>>>> - Lots of device IDs have been removed from the e1000 driver and moved
>>>> over
>>>> to e1000e. So if your e1000 stops working, you forgot to set
>>>> CONFIG_E1000E.
>>>>
>>>>
>>> Wouldn't it make sense to just default this to on if E1000 was on, rather
>>> than screwing
>>> everybody for no good reason (plus breaking all the automated testing, etc
>>> etc)?
>>> Much though I love random refactoring, it is fairly painful to just keep
>>> changing the
>>> names of things.
>> (cc netdev and Auke)
>>
>> Yes, that would be very sensible. CONFIG_E1000E should default to whatever
>> CONFIG_E1000 was set to.
>
> which is "y" for x86 and friends, ppc, arm and ia64 through 'defconfig'. the
> Kconfig files do not have defaults in them.
>
> I can send a patch to adjust the defconfig files, would that be OK? I certainly
> think that would be reasonable, I dislike setting defaults through defconfig for
> network drivers myself and rather would not do that.
that should read "dislike setting defaults through Kconfig ..."
Auke
^ permalink raw reply
* Re: net-2.6.25 being rebased...
From: Francois Romieu @ 2007-12-11 21:49 UTC (permalink / raw)
To: Joe Perches; +Cc: David Miller, netdev
In-Reply-To: <20071211213540.GA30706@electric-eye.fr.zoreil.com>
Francois Romieu <romieu@fr.zoreil.com> :
[...]
> [remote "origin"]
> url = git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
^^^^^^^
"net-2.6.25", sorry.
While reading the answers, I have the strange feeling that "remotes"
branches are not advertised a lot.
--
Ueimor
^ permalink raw reply
* Re: net-2.6.25 being rebased...
From: Francois Romieu @ 2007-12-11 21:35 UTC (permalink / raw)
To: Joe Perches; +Cc: David Miller, netdev
In-Reply-To: <1197407100.4911.150.camel@localhost>
Joe Perches <joe@perches.com> :
[...]
> I have an earlier unmodified git repository of net-2.6.25.
> Does anyone know the appropriate git commands to resync
> to the rebased content?
>
> $ git branch
> * master
> $ git-pull
> [...]
> Automatic merge failed; fix conflicts and then commit the result.
Assuming taht you initially cloned from davem's repo, your .git/config
could contain something along the lines of:
[remote "origin"]
url = git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
fetch = +refs/heads/*:refs/remotes/origin/*
(the "+" will update even non fast-forwarding branches)
Then:
$ git fetch origin
$ git fetch -u remotes/origin/master:master
You may then reset --hard to wipe out any leftover file.
If you cloned from somewhere else, replace "origin" with the label of
your choice to automate the process.
--
Ueimor
^ permalink raw reply
* [IPSEC] RFC 4301 PFP Support
From: Tyler Hicks @ 2007-12-11 21:34 UTC (permalink / raw)
To: netdev; +Cc: latten, herbert, davem
I'm working on adding populate from packet (PFP) support to the kernel,
as specified in RFC 4301. While testing with openswan (2.4.9), I
noticed that the state selector values in the SAD were empty. It seems
that when openswan sends a ALLOCSPI message, the kernel finds the larval
xfrm_state with selector fields filled in and passes it to openswan.
Openswan will then respond with an UPDSA message that includes an
xfrm_usersa_info that has empty selector values. The kernel assumes
that these selector values are valid and deletes the larval SA and
inserts the new SA containing empty selectors. We need SAs with valid
selectors in the SAD in order to implement PFP support.
Should we just use the larval selectors or should we assume that
openswan will begin to send valid selectors? I asked for the openswan
dev's opinions and they referred me to Herbert Xu. It seems as though
the correct solution would be for openswan to pass valid selectors in
UPDSA messages, even if it is the larval selectors we gave them.
On a side note, Joy Latten has reported to see the same behavior while
using ipsec-tools.
Thanks!
Tyler Hicks
^ 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