* Re: 2.6.35->2.6.36 regression, vanilla kernel panic, ppp or hrtimers crashing
From: Jarek Poplawski @ 2010-11-03 7:38 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: Thomas Gleixner, Paul Mackerras, linux-kernel, netdev
In-Reply-To: <201011021549.47466.nuclearcat@nuclearcat.com>
On Tue, Nov 02, 2010 at 03:49:47PM +0200, Denys Fedoryshchenko wrote:
> I didn't try yet, but i enable more debugs and catch linked list corruption.
It should be very useful but it seems there were no significant changes
in ppp locking between 2.6.35 and .36 except the patch I mentioned, so
it would be nice to check this first and try to fix it properly later.
Jarek P.
>
> Here is dumps from netconsole:
> http://www.nuclearcat.com/ll.txt
> http://www.nuclearcat.com/ll2.txt
>
> I have another PC, also fails to run 2.6.36, but netconsole don't give
> anything.
> Both PC's have strange issue with clock drifting away too much (on 2.6.35 and
> maybe even before).
>
>
> On Thursday 28 October 2010 10:05:50 Jarek Poplawski wrote:
> > On 2010-10-25 11:22, Denys Fedoryshchenko wrote:
> > > Hi
> > >
> > > Here is what i got from netconsole
> > >
> > > [ 259.238755] BUG: unable to handle kernel
> > > paging request
> > > at f8ba001c
> > > [ 259.238953] IP:
> > > [<c0199ebe>] do_select+0x2cc/0x502
> >
> > ...
> >
> > > It is not easy to do full git bisect(it is semi-embedded distro), but i
> > > can try reversing particular commits, if someone can give idea which
> > > one, and can try debug patches.
> >
> > Hi,
> > Nothing concrete, but you might try reverting this one:
> >
> > http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.36.y.git;a=commi
> > tdiff;h=15fd0cd9a2ad24a78fbee369dec8ca660979d57e
> >
> > Jarek P.
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ipv4: netfilter: arp_tables: fix information leak to userland
From: Patrick McHardy @ 2010-11-03 7:44 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: kernel-janitors, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
netfilter-devel, netfilter, coreteam, netdev, linux-kernel
In-Reply-To: <1288448806-6470-1-git-send-email-segooon@gmail.com>
On 30.10.2010 16:26, Vasiliy Kulikov wrote:
> Structure arpt_getinfo is copied to userland with the field "name"
> that has the last elements unitialized. It leads to leaking of
> contents of kernel stack memory.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ipv4: netfilter: ip_tables: fix information leak to userland
From: Patrick McHardy @ 2010-11-03 7:45 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: kernel-janitors, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
netfilter-devel, netfilter, coreteam, netdev, linux-kernel
In-Reply-To: <1288448810-6628-1-git-send-email-segooon@gmail.com>
On 30.10.2010 16:26, Vasiliy Kulikov wrote:
> Structure ipt_getinfo is copied to userland with the field "name"
> that has the last elements unitialized. It leads to leaking of
> contents of kernel stack memory.
Also applied, thanks.
^ permalink raw reply
* Re: 2.6.35->2.6.36 regression, vanilla kernel panic, ppp or hrtimers crashing
From: Denys Fedoryshchenko @ 2010-11-03 7:47 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Thomas Gleixner, Paul Mackerras, linux-kernel, netdev
In-Reply-To: <20101103073854.GA7279@ff.dom.local>
I try to reverse and got very weird lockups (no netconsole logs and no
watchdog triggered reboot on that remote machine).
I will try to cook something to reboot it, because it is very remote machine
On Wednesday 03 November 2010 09:38:54 Jarek Poplawski wrote:
> On Tue, Nov 02, 2010 at 03:49:47PM +0200, Denys Fedoryshchenko wrote:
> > I didn't try yet, but i enable more debugs and catch linked list
> > corruption.
>
> It should be very useful but it seems there were no significant changes
> in ppp locking between 2.6.35 and .36 except the patch I mentioned, so
> it would be nice to check this first and try to fix it properly later.
>
> Jarek P.
>
> > Here is dumps from netconsole:
> > http://www.nuclearcat.com/ll.txt
> > http://www.nuclearcat.com/ll2.txt
> >
> > I have another PC, also fails to run 2.6.36, but netconsole don't give
> > anything.
> > Both PC's have strange issue with clock drifting away too much (on 2.6.35
> > and maybe even before).
> >
> > On Thursday 28 October 2010 10:05:50 Jarek Poplawski wrote:
> > > On 2010-10-25 11:22, Denys Fedoryshchenko wrote:
> > > > Hi
> > > >
> > > > Here is what i got from netconsole
> > > >
> > > > [ 259.238755] BUG: unable to handle kernel
> > > > paging request
> > > > at f8ba001c9999
> > > > [ 259.238953] IP:
> > > > [<c0199ebe>] do_select+0x2cc/0x502
> > >
> > > ...
> > >
> > > > It is not easy to do full git bisect(it is semi-embedded distro), but
> > > > i can try reversing particular commits, if someone can give idea
> > > > which one, and can try debug patches.
> > >
> > > Hi,
> > > Nothing concrete, but you might try reverting this one:
> > >
> > > http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.36.y.git;a=c
> > > ommi tdiff;h=15fd0cd9a2ad24a78fbee369dec8ca660979d57e
> > >
> > > Jarek P.
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] virtio-net: init link state correctly
From: Michael S. Tsirkin @ 2010-11-03 8:00 UTC (permalink / raw)
To: Jason Wang; +Cc: rusty, davem, markmc, netdev, linux-kernel, kvm
In-Reply-To: <20101103070817.26272.31654.stgit@dhcp-91-158.nay.redhat.com>
On Wed, Nov 03, 2010 at 03:08:17PM +0800, Jason Wang wrote:
> We need call netif_carrier_off() and do not assume VIRTIO_NET_S_LINKUP
> before querying device state during probing, otherwise we may get
> wrong operstate after driver was loaded because the link watch event
> was not fired as expected.
>
> Since the device state changed could be caught through interrupt, the
> unconditional call to nerif_carrier_on() is also removed.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
OK, but this seems broken for hosts without VIRTIO_NET_F_STATUS. Right?
Probably
/* Assume link up if device can't report link status,
otherwise get link status from config. */
if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) {
vi->status = 0;
netif_carrier_off(dev);
virtnet_update_status(vi);
} else {
vi->status = VIRTIO_NET_S_LINK_UP;
netif_carrier_on(dev);
}
Makes sense?
> ---
> drivers/net/virtio_net.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index bb6b67f..0a0cd35 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -986,9 +986,8 @@ static int virtnet_probe(struct virtio_device *vdev)
> goto unregister;
> }
>
> - vi->status = VIRTIO_NET_S_LINK_UP;
> + netif_carrier_off(dev);
> virtnet_update_status(vi);
> - netif_carrier_on(dev);
>
> pr_debug("virtnet: registered device %s\n", dev->name);
> return 0;
^ permalink raw reply
* Re: 2.6.35->2.6.36 regression, vanilla kernel panic, ppp or hrtimers crashing
From: Jarek Poplawski @ 2010-11-03 8:02 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: Thomas Gleixner, Paul Mackerras, linux-kernel, netdev
In-Reply-To: <201011030947.54464.nuclearcat@nuclearcat.com>
On Wed, Nov 03, 2010 at 09:47:53AM +0200, Denys Fedoryshchenko wrote:
> I try to reverse and got very weird lockups (no netconsole logs and no
> watchdog triggered reboot on that remote machine).
> I will try to cook something to reboot it, because it is very remote machine
OK, I only wanted to know if reverting could be a fast fix. Since it
isn't, please stay with 2.6.35 until there is some new idea (patch).
Jarek P.
^ permalink raw reply
* Re: 2.6.35->2.6.36 regression, vanilla kernel panic, ppp or hrtimers crashing
From: Jarek Poplawski @ 2010-11-03 8:59 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: Thomas Gleixner, Paul Mackerras, linux-kernel, netdev
In-Reply-To: <201011031018.21178.nuclearcat@nuclearcat.com>
On Wed, Nov 03, 2010 at 10:18:20AM +0200, Denys Fedoryshchenko wrote:
>
> On Wednesday 03 November 2010 10:02:58 Jarek Poplawski wrote:
> > On Wed, Nov 03, 2010 at 09:47:53AM +0200, Denys Fedoryshchenko wrote:
> > > I try to reverse and got very weird lockups (no netconsole logs and no
> > > watchdog triggered reboot on that remote machine).
> > > I will try to cook something to reboot it, because it is very remote
> > > machine
> >
> > OK, I only wanted to know if reverting could be a fast fix. Since it
> > isn't, please stay with 2.6.35 until there is some new idea (patch).
> >
> Well, still i want to try (if i can) more debug, and maybe i'll catch
> something, also i have around 145 NAS servers to go, to try 2.6.36 :-)
I think the current debugging needs analyzing first. But here is
a patch which probably could matter at least wrt your first oopses.
(Please try this first on something you can easily reboot.)
Jarek P.
---
diff --git a/drivers/net/ppp_generic.c b/drivers/net/ppp_generic.c
index 09cf56d..1b98c4c 100644
--- a/drivers/net/ppp_generic.c
+++ b/drivers/net/ppp_generic.c
@@ -409,6 +409,8 @@ static ssize_t ppp_read(struct file *file, char __user *buf,
if (!pf)
return -ENXIO;
+
+ atomic_inc(&pf->refcnt);
add_wait_queue(&pf->rwait, &wait);
for (;;) {
set_current_state(TASK_INTERRUPTIBLE);
@@ -440,6 +442,17 @@ static ssize_t ppp_read(struct file *file, char __user *buf,
set_current_state(TASK_RUNNING);
remove_wait_queue(&pf->rwait, &wait);
+ if (atomic_dec_and_test(&pf->refcnt)) {
+ switch (pf->kind) {
+ case INTERFACE:
+ ppp_destroy_interface(PF_TO_PPP(pf));
+ break;
+ case CHANNEL:
+ ppp_destroy_channel(PF_TO_CHANNEL(pf));
+ break;
+ }
+ }
+
if (!skb)
goto out;
@@ -504,6 +517,8 @@ static unsigned int ppp_poll(struct file *file, poll_table *wait)
if (!pf)
return 0;
+
+ atomic_inc(&pf->refcnt);
poll_wait(file, &pf->rwait, wait);
mask = POLLOUT | POLLWRNORM;
if (skb_peek(&pf->rq))
@@ -518,6 +533,17 @@ static unsigned int ppp_poll(struct file *file, poll_table *wait)
mask |= POLLIN | POLLRDNORM;
}
+ if (atomic_dec_and_test(&pf->refcnt)) {
+ switch (pf->kind) {
+ case INTERFACE:
+ ppp_destroy_interface(PF_TO_PPP(pf));
+ break;
+ case CHANNEL:
+ ppp_destroy_channel(PF_TO_CHANNEL(pf));
+ break;
+ }
+ }
+
return mask;
}
^ permalink raw reply related
* RE: [Patch] netxen: remove unused firmware exports
From: Amit Salecha @ 2010-11-03 9:35 UTC (permalink / raw)
To: Amerigo Wang, linux-kernel@vger.kernel.org
Cc: Dhananjay Phadke, Narender Kumar, netdev@vger.kernel.org,
David S. Miller
In-Reply-To: <20101103043021.5321.73681.sendpatchset@localhost.localdomain>
> From: Amerigo Wang [amwang@redhat.com]
> Sent: Wednesday, November 03, 2010 9:55 AM
> To: linux-kernel@vger.kernel.org
> Cc: Dhananjay Phadke; Amit Salecha; Narender Kumar; netdev@vger.kernel.org; David S. Miller; Amerigo Wang
> Subject: [Patch] netxen: remove unused firmware exports
>
> Quote from Amit Salecha:
>
> "Actually I was not updated, NX_UNIFIED_ROMIMAGE_NAME (phanfw.bin) is already
> submitted and its present in linux-firmware.git.
>
> I will get back to you on NX_P2_MN_ROMIMAGE_NAME, NX_P3_CT_ROMIMAGE_NAME and
> NX_P3_MN_ROMIMAGE_NAME. Whether this will be submitted ?"
>
> We have to remove these, otherwise we will get wrong info from modinfo.
>
> Signed-off-by: WANG Cong <amwang@redhat.com>
> Cc: Amit Kumar Salecha <amit.salecha@qlogic.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Dhananjay Phadke <dhananjay.phadke@qlogic.com>
> Cc: Narender Kumar narender.kumar@qlogic.com
Acked-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
^ permalink raw reply
* Irish Lotto***You Earned £750,000***
From: Fiduciary Desk @ 2010-11-03 9:51 UTC (permalink / raw)
Send Names, Age, Occupation, Country.
^ permalink raw reply
* Re: [regression, 2.6.37-rc1] 'ip link tap0 up' stuck in do_exit()
From: Dave Chinner @ 2010-11-03 10:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, netdev
In-Reply-To: <1288768402.2467.665.camel@edumazet-laptop>
On Wed, Nov 03, 2010 at 08:13:22AM +0100, Eric Dumazet wrote:
> Le mercredi 03 novembre 2010 à 17:26 +1100, Dave Chinner a écrit :
> > Folks,
> >
> > Starting up KVM on a current mainline kernel using the tap
> > device for the networking is resulting in the ip process tryin gto
> > up the tap interface hanging. KVM is started with this networking
> > config:
> >
> > ....
> > -net nic,vlan=0,macaddr=00:e4:b6:63:63:6d,model=virtio \
> > -net tap,vlan=0,script=/vm-images/qemu-ifup,downscript=no \
> > ....
> >
> > And the script is effectively:
> >
> > switch=br0
> > if [ -n "$1" ];then
> > /usr/bin/sudo /sbin/ip link set $1 up
> > sleep 0.5s
> > /usr/bin/sudo /usr/sbin/brctl addif $switch $1
> > exit 0
> > fi
> > exit 1
> >
> > This is resulting in the command 'ip link set tap0 up' hanging as a zombie:
> >
> > root 3005 1 0 16:53 pts/3 00:00:00 /bin/sh /vm-images/qemu-ifup tap0
> > root 3011 3005 0 16:53 pts/3 00:00:00 /usr/bin/sudo /sbin/ip link set tap0 up
> > root 3012 3011 0 16:53 pts/3 00:00:00 [ip] <defunct>
> >
> > In do_exit() with this trace:
> >
> > [ 1630.782255] ip x ffff88063fcb3600 0 3012 3011 0x00000000
> > [ 1630.789121] ffff880631328000 0000000000000046 0000000000000000 ffff880633104380
> > [ 1630.796524] 0000000000013600 ffff88062f031fd8 0000000000013600 0000000000013600
> > [ 1630.803925] ffff8806313282d8 ffff8806313282e0 ffff880631328000 0000000000013600
> > [ 1630.811324] Call Trace:
> > [ 1630.813760] [<ffffffff8104a90d>] ? do_exit+0x716/0x724
> > [ 1630.818964] [<ffffffff8104a995>] ? do_group_exit+0x7a/0xa4
> > [ 1630.824512] [<ffffffff8104a9d1>] ? sys_exit_group+0x12/0x16
> > [ 1630.830149] [<ffffffff81009a82>] ? system_call_fastpath+0x16/0x1b
> >
> > The address comes down to the schedule() call:
> >
> > (gdb) l *(do_exit+0x716)
> > 0xffffffff8104a90d is in do_exit (kernel/exit.c:1034).
> > 1029 preempt_disable();
> > 1030 exit_rcu();
> > 1031 /* causes final put_task_struct in finish_task_switch(). */
> > 1032 tsk->state = TASK_DEAD;
> > 1033 schedule();
> > 1034 BUG();
> > 1035 /* Avoid "noreturn function does return". */
> > 1036 for (;;)
> > 1037 cpu_relax(); /* For when BUG is null */
> > 1038 }
> >
> > Needless to say, KVM is not starting up. This works just fine on
> > 2.6.35.1 and so is a regression. I can't do a lot of testing on this as
> > the host is the machine that hosts all my build and test environments....
> >
> > Cheers,
> >
> > Dave.
>
> Could it be the same problem than
>
> http://kerneltrap.com/mailarchive/linux-netdev/2010/10/23/6288128
>
> Try to revert bee31369ce16fc3898ec9a54161248c9eddb06bc ?
It's working fine on 2.6.36 right now, so it's something that came in
with the .37 merge cycle...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: [RFC PATCH 1/1] vhost: TX used buffer guest signal accumulation
From: Michael S. Tsirkin @ 2010-11-03 10:48 UTC (permalink / raw)
To: Shirley Ma; +Cc: David Miller, netdev, kvm, linux-kernel
In-Reply-To: <1288642673.19173.8.camel@localhost.localdomain>
On Mon, Nov 01, 2010 at 01:17:53PM -0700, Shirley Ma wrote:
> On Sat, 2010-10-30 at 22:06 +0200, Michael S. Tsirkin wrote:
> > On Fri, Oct 29, 2010 at 08:43:08AM -0700, Shirley Ma wrote:
> > > On Fri, 2010-10-29 at 10:10 +0200, Michael S. Tsirkin wrote:
> > > > Hmm. I don't yet understand. We are still doing copies into the
> > per-vq
> > > > buffer, and the data copied is really small. Is it about cache
> > line
> > > > bounces? Could you try figuring it out?
> > >
> > > per-vq buffer is much less expensive than 3 put_copy() call. I will
> > > collect the profiling data to show that.
> >
> > What about __put_user? Maybe the access checks are the ones
> > that add the cost here? I attach patches to strip access checks:
> > they are not needed as we do them on setup time already, anyway.
> > Can you try them out and see if performance is improved for you
> > please?
> > On top of this, we will need to add some scheme to accumulate signals,
> > but that is a separate issue.
>
> Yes, moving from put_user/get_user to __put_user/__get_user does improve
> the performance by removing the checking.
I mean in practice, you see a benefit from this patch?
> My concern here is whether checking only in set up would be sufficient
> for security?
It better be sufficient because the checks that put_user does
are not effictive when run from the kernel thread, anyway.
> Would be there is a case guest could corrupt the ring
> later? If not, that's OK.
You mean change the pointer after it's checked?
If you see such a case, please holler.
> > > > > > 2. How about flushing out queued stuff before we exit
> > > > > > the handle_tx loop? That would address most of
> > > > > > the spec issue.
> > > > >
> > > > > The performance is almost as same as the previous patch. I will
> > > > resubmit
> > > > > the modified one, adding vhost_add_used_and_signal_n after
> > handle_tx
> > > > > loop for processing pending queue.
> > > > >
> > > > > This patch was a part of modified macvtap zero copy which I
> > haven't
> > > > > submitted yet. I found this helped vhost TX in general. This
> > pending
> > > > > queue will be used by DMA done later, so I put it in vq instead
> > of a
> > > > > local variable in handle_tx.
> > > > >
> > > > > Thanks
> > > > > Shirley
> > > >
> > > > BTW why do we need another array? Isn't heads field exactly what
> > we
> > > > need
> > > > here?
> > >
> > > head field is only for up to 32, the more used buffers add and
> > signal
> > > accumulated the better performance is from test results.
> >
> > I think we should separate the used update and signalling. Interrupts
> > are expensive so I can believe accumulating even up to 100 of them
> > helps. But used head copies are already prety cheap. If we cut the
> > overhead by x32, that should make them almost free?
>
> I can separate the used update and signaling to see the best
> performance.
>
> > > That's was one
> > > of the reason I didn't use heads. The other reason was I used these
> > > buffer for pending dma done in mavctap zero copy patch. It could be
> > up
> > > to vq->num in worse case.
> >
> > We can always increase that, not an issue.
>
> Good, I will change heads up to vq->num and use it.
>
> Thanks
> Shirley
To clarify: the combination of __put_user and separate
signalling is giving the same performance benefit as your
patch?
I am mostly concerned with adding code that seems to help
speed for reasons we don't completely understand, because
then we might break the optimization easily without noticing.
--
MST
^ permalink raw reply
* Re: [regression, 2.6.37-rc1] 'ip link tap0 up' stuck in do_exit()
From: Dave Chinner @ 2010-11-03 11:29 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, netdev
In-Reply-To: <20101103103448.GA9169@dastard>
On Wed, Nov 03, 2010 at 09:34:48PM +1100, Dave Chinner wrote:
> On Wed, Nov 03, 2010 at 08:13:22AM +0100, Eric Dumazet wrote:
> > Le mercredi 03 novembre 2010 à 17:26 +1100, Dave Chinner a écrit :
> > > Folks,
> > >
> > > Starting up KVM on a current mainline kernel using the tap
> > > device for the networking is resulting in the ip process tryin gto
> > > up the tap interface hanging. KVM is started with this networking
> > > config:
> > >
> > > ....
> > > -net nic,vlan=0,macaddr=00:e4:b6:63:63:6d,model=virtio \
> > > -net tap,vlan=0,script=/vm-images/qemu-ifup,downscript=no \
> > > ....
> > >
> > > And the script is effectively:
> > >
> > > switch=br0
> > > if [ -n "$1" ];then
> > > /usr/bin/sudo /sbin/ip link set $1 up
> > > sleep 0.5s
> > > /usr/bin/sudo /usr/sbin/brctl addif $switch $1
> > > exit 0
> > > fi
> > > exit 1
> > >
> > > This is resulting in the command 'ip link set tap0 up' hanging as a zombie:
> > >
> > > root 3005 1 0 16:53 pts/3 00:00:00 /bin/sh /vm-images/qemu-ifup tap0
> > > root 3011 3005 0 16:53 pts/3 00:00:00 /usr/bin/sudo /sbin/ip link set tap0 up
> > > root 3012 3011 0 16:53 pts/3 00:00:00 [ip] <defunct>
> > >
> > > In do_exit() with this trace:
> > >
> > > [ 1630.782255] ip x ffff88063fcb3600 0 3012 3011 0x00000000
> > > [ 1630.789121] ffff880631328000 0000000000000046 0000000000000000 ffff880633104380
> > > [ 1630.796524] 0000000000013600 ffff88062f031fd8 0000000000013600 0000000000013600
> > > [ 1630.803925] ffff8806313282d8 ffff8806313282e0 ffff880631328000 0000000000013600
> > > [ 1630.811324] Call Trace:
> > > [ 1630.813760] [<ffffffff8104a90d>] ? do_exit+0x716/0x724
> > > [ 1630.818964] [<ffffffff8104a995>] ? do_group_exit+0x7a/0xa4
> > > [ 1630.824512] [<ffffffff8104a9d1>] ? sys_exit_group+0x12/0x16
> > > [ 1630.830149] [<ffffffff81009a82>] ? system_call_fastpath+0x16/0x1b
> > >
> > > The address comes down to the schedule() call:
> > >
> > > (gdb) l *(do_exit+0x716)
> > > 0xffffffff8104a90d is in do_exit (kernel/exit.c:1034).
> > > 1029 preempt_disable();
> > > 1030 exit_rcu();
> > > 1031 /* causes final put_task_struct in finish_task_switch(). */
> > > 1032 tsk->state = TASK_DEAD;
> > > 1033 schedule();
> > > 1034 BUG();
> > > 1035 /* Avoid "noreturn function does return". */
> > > 1036 for (;;)
> > > 1037 cpu_relax(); /* For when BUG is null */
> > > 1038 }
> > >
> > > Needless to say, KVM is not starting up. This works just fine on
> > > 2.6.35.1 and so is a regression. I can't do a lot of testing on this as
> > > the host is the machine that hosts all my build and test environments....
> > >
> > > Cheers,
> > >
> > > Dave.
> >
> > Could it be the same problem than
> >
> > http://kerneltrap.com/mailarchive/linux-netdev/2010/10/23/6288128
> >
> > Try to revert bee31369ce16fc3898ec9a54161248c9eddb06bc ?
>
> It's working fine on 2.6.36 right now, so it's something that came in
> with the .37 merge cycle...
Actually, the machine isn't running a 2.6.36 kernel (it had booted
to the working .35 kernel and I didn't notice). So i've just tested
a 2.6.36 kernel, and the problem _is present_ in 2.6.36. I've
reverted the above commit but that does not fix the problem.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] be2net: Adding an option to use INTx instead of MSI-X
From: Michael Ellerman @ 2010-11-03 12:45 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: David Miller, bhutchings, somnath.kotur, netdev, linux-pci
In-Reply-To: <20101030232155.GA14129@parisc-linux.org>
[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]
On Sat, 2010-10-30 at 17:21 -0600, Matthew Wilcox wrote:
> On Tue, Oct 26, 2010 at 05:52:08PM +1100, Michael Ellerman wrote:
> > That horse has really really bolted, it's gawn.
> >
> > I count 26 drivers with "disable MSI/X" parameters. Some even have more
> > than one.
>
> That's 26 patches someone needs to write, then. You can put my Acked-by
> on all of them.
Bah, come on it's hardly the most horrendous sin committed by driver
writers. And removing them risks breaking someone's system, even if they
are clueless, should RTFM etc.
> > I agree it's a mess for users, but it's probably preferable to a
> > non-working driver.
>
> What more drivers need is an automatic detection of a non-working
> interrupt situation, great big warning messages, and fallback to an
> alternate interrupt mechanism. Doing it for one driver, then generalising
> as much of it into the core as possible would be nice.
More detection would be good.
I don't see much potential for generalising it though. Looking at e1000e
and tg3 there is really not much in common except the very basic idea.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] r6040: fix multicast operations
From: Shawn Lin @ 2010-11-03 12:51 UTC (permalink / raw)
To: netdev, Marc Leclerc, Albert Chen, David Miller, Florian Fainelli
In-Reply-To: <201010202309.43812.florian@openwrt.org>
On Wed, 2010-10-20 at 23:09 +0200, Florian Fainelli wrote:
> This patch fixes the following issues with the r6040 NIC operating in
> multicast:
>
> 1) When the IFF_ALLMULTI flag is set, we should write 0xffff to the NIC hash
> table registers to make it process multicast traffic
> 2) When the number of multicast address to handle is smaller than MCAST_MAX
> we should use the NIC multicast registers MID1_{L,M,H}.
> 3) The hashing of the address was not correct, due to an invalid substraction
> (15 - (crc & 0x0f)) instead of (crc & 0x0f)
I suggest to modify the comment as follows.
3) The hashing of the address was not correct, due to an invalid
substraction (15 - (crc & 0x0f)) instead of (crc & 0x0f) and an
incorrect crc algorithm (ether_crc_le) instead of (ether_crc).
[...]
The original code I submitted to Florian has some issues mentioned by Ben Hutchings.
This revision fixes these issues and another issue about the sequence of configuring multicast hash table registers.
The correct sequence is to enable multicast function before write values to hash table registers. I have verified it on my platform.
The hash algorithm is provided by hardware designers. I also re-confirmed it with RDC's engineer.
Please let me know if anyone has questions.
The version is for net-next-2.6:
---
diff --git a/drivers/net/r6040.c b/drivers/net/r6040.c
index 0b014c8..e88e171 100644
--- a/drivers/net/r6040.c
+++ b/drivers/net/r6040.c
@@ -69,6 +69,8 @@
/* MAC registers */
#define MCR0 0x00 /* Control register 0 */
+#define PROMISC 0x0020 /* Promiscuous mode */
+#define HASH_EN 0x0100 /* Enable multicast hash table function */
#define MCR1 0x04 /* Control register 1 */
#define MAC_RST 0x0001 /* Reset the MAC */
#define MBCR 0x08 /* Bus control */
@@ -851,77 +853,84 @@ static void r6040_multicast_list(struct net_device *dev)
{
struct r6040_private *lp = netdev_priv(dev);
void __iomem *ioaddr = lp->base;
- u16 *adrp;
- u16 reg;
unsigned long flags;
struct netdev_hw_addr *ha;
int i;
+ u16 hash_table[4] = { 0, };
- /* MAC Address */
- adrp = (u16 *)dev->dev_addr;
- iowrite16(adrp[0], ioaddr + MID_0L);
- iowrite16(adrp[1], ioaddr + MID_0M);
- iowrite16(adrp[2], ioaddr + MID_0H);
-
- /* Promiscous Mode */
spin_lock_irqsave(&lp->lock, flags);
/* Clear AMCP & PROM bits */
- reg = ioread16(ioaddr) & ~0x0120;
+ lp->mcr0 = ioread16(ioaddr + MCR0) & ~(PROMISC | HASH_EN);
+
+ /* Promiscuous Mode */
if (dev->flags & IFF_PROMISC) {
- reg |= 0x0020;
- lp->mcr0 |= 0x0020;
+ lp->mcr0 |= PROMISC;
}
- /* Too many multicast addresses
- * accept all traffic */
- else if ((netdev_mc_count(dev) > MCAST_MAX) ||
- (dev->flags & IFF_ALLMULTI))
- reg |= 0x0020;
-
- iowrite16(reg, ioaddr);
- spin_unlock_irqrestore(&lp->lock, flags);
+ /* Enable multicast hash table function to
+ * receive all multicast packets. */
+ else if (dev->flags & IFF_ALLMULTI) {
+ lp->mcr0 |= HASH_EN;
+
+ for (i = 0; i < MCAST_MAX ; i++) {
+ iowrite16(0, ioaddr + MID_1L + 8 * i);
+ iowrite16(0, ioaddr + MID_1M + 8 * i);
+ iowrite16(0, ioaddr + MID_1H + 8 * i);
+ }
- /* Build the hash table */
- if (netdev_mc_count(dev) > MCAST_MAX) {
- u16 hash_table[4];
+ for (i = 0; i < 4; i++)
+ hash_table[i] = 0xffff;
+ }
+ /* Use internal multicast address registers if the number of
+ * multicast addresses is not greater than MCAST_MAX. */
+ else if (netdev_mc_count(dev) <= MCAST_MAX) {
+ i = 0;
+ netdev_for_each_mc_addr(ha, dev) {
+ u16 *adrp = (u16 *) ha->addr;
+ iowrite16(adrp[0], ioaddr + MID_1L + 8 * i);
+ iowrite16(adrp[1], ioaddr + MID_1M + 8 * i);
+ iowrite16(adrp[2], ioaddr + MID_1H + 8 * i);
+ i++;
+ }
+ while (i < MCAST_MAX) {
+ iowrite16(0, ioaddr + MID_1L + 8 * i);
+ iowrite16(0, ioaddr + MID_1M + 8 * i);
+ iowrite16(0, ioaddr + MID_1H + 8 * i);
+ i++;
+ }
+ }
+ /* Otherwise, Enable multicast hash table function. */
+ else {
u32 crc;
- for (i = 0; i < 4; i++)
- hash_table[i] = 0;
+ lp->mcr0 |= HASH_EN;
- netdev_for_each_mc_addr(ha, dev) {
- char *addrs = ha->addr;
+ for (i = 0; i < MCAST_MAX ; i++) {
+ iowrite16(0, ioaddr + MID_1L + 8 * i);
+ iowrite16(0, ioaddr + MID_1M + 8 * i);
+ iowrite16(0, ioaddr + MID_1H + 8 * i);
+ }
- if (!(*addrs & 1))
- continue;
+ /* Build multicast hash table */
+ netdev_for_each_mc_addr(ha, dev) {
+ u8 *addrs = ha->addr;
- crc = ether_crc_le(6, addrs);
+ crc = ether_crc(ETH_ALEN, addrs);
crc >>= 26;
- hash_table[crc >> 4] |= 1 << (15 - (crc & 0xf));
+ hash_table[crc >> 4] |= 1 << (crc & 0xf);
}
- /* Fill the MAC hash tables with their values */
+ }
+ iowrite16(lp->mcr0, ioaddr + MCR0);
+
+ /* Fill the MAC hash tables with their values */
+ if (lp->mcr0 && HASH_EN) {
iowrite16(hash_table[0], ioaddr + MAR0);
iowrite16(hash_table[1], ioaddr + MAR1);
iowrite16(hash_table[2], ioaddr + MAR2);
iowrite16(hash_table[3], ioaddr + MAR3);
}
- /* Multicast Address 1~4 case */
- i = 0;
- netdev_for_each_mc_addr(ha, dev) {
- if (i >= MCAST_MAX)
- break;
- adrp = (u16 *) ha->addr;
- iowrite16(adrp[0], ioaddr + MID_1L + 8 * i);
- iowrite16(adrp[1], ioaddr + MID_1M + 8 * i);
- iowrite16(adrp[2], ioaddr + MID_1H + 8 * i);
- i++;
- }
- while (i < MCAST_MAX) {
- iowrite16(0xffff, ioaddr + MID_1L + 8 * i);
- iowrite16(0xffff, ioaddr + MID_1M + 8 * i);
- iowrite16(0xffff, ioaddr + MID_1H + 8 * i);
- i++;
- }
+
+ spin_unlock_irqrestore(&lp->lock, flags);
}
static void netdev_get_drvinfo(struct net_device *dev,
---
The version is for 2.6.32.y and 2.6.27.y:
---
diff --git a/drivers/net/r6040.c b/drivers/net/r6040.c
index 9ee9f01..f9af419 100644
--- a/drivers/net/r6040.c
+++ b/drivers/net/r6040.c
@@ -69,6 +69,8 @@
/* MAC registers */
#define MCR0 0x00 /* Control register 0 */
+#define PROMISC 0x0020 /* Promiscuous mode */
+#define HASH_EN 0x0100 /* Enable multicast hash table function */
#define MCR1 0x04 /* Control register 1 */
#define MAC_RST 0x0001 /* Reset the MAC */
#define MBCR 0x08 /* Bus control */
@@ -935,76 +937,88 @@ static void r6040_multicast_list(struct net_device *dev)
{
struct r6040_private *lp = netdev_priv(dev);
void __iomem *ioaddr = lp->base;
- u16 *adrp;
- u16 reg;
unsigned long flags;
struct dev_mc_list *dmi = dev->mc_list;
int i;
+ u16 hash_table[4] = { 0, };
- /* MAC Address */
- adrp = (u16 *)dev->dev_addr;
- iowrite16(adrp[0], ioaddr + MID_0L);
- iowrite16(adrp[1], ioaddr + MID_0M);
- iowrite16(adrp[2], ioaddr + MID_0H);
-
- /* Promiscous Mode */
spin_lock_irqsave(&lp->lock, flags);
/* Clear AMCP & PROM bits */
- reg = ioread16(ioaddr) & ~0x0120;
+ lp->mcr0 = ioread16(ioaddr + MCR0) & ~(PROMISC | HASH_EN);
+
+ /* Promiscuous Mode */
if (dev->flags & IFF_PROMISC) {
- reg |= 0x0020;
- lp->mcr0 |= 0x0020;
+ lp->mcr0 |= PROMISC;
}
- /* Too many multicast addresses
- * accept all traffic */
- else if ((dev->mc_count > MCAST_MAX)
- || (dev->flags & IFF_ALLMULTI))
- reg |= 0x0020;
+ /* Enable multicast hash table function to
+ * receive all multicast packets. */
+ else if (dev->flags & IFF_ALLMULTI) {
+ lp->mcr0 |= HASH_EN;
+
+ for (i = 0; i < MCAST_MAX ; i++) {
+ iowrite16(0, ioaddr + MID_1L + 8 * i);
+ iowrite16(0, ioaddr + MID_1M + 8 * i);
+ iowrite16(0, ioaddr + MID_1H + 8 * i);
+ }
- iowrite16(reg, ioaddr);
- spin_unlock_irqrestore(&lp->lock, flags);
+ for (i = 0; i < 4; i++)
+ hash_table[i] = 0xffff;
+ }
+ /* Use internal multicast address registers if the number of
+ * multicast addresses is not greater than MCAST_MAX. */
+ else if (dev->mc_count <= MCAST_MAX) {
+ i = 0;
+ while (i < dev->mc_count) {
+ u16 *adrp = (u16 *) dmi->dmi_addr;
+ dmi = dmi->next;
- /* Build the hash table */
- if (dev->mc_count > MCAST_MAX) {
- u16 hash_table[4];
+ iowrite16(adrp[0], ioaddr + MID_1L + 8 * i);
+ iowrite16(adrp[1], ioaddr + MID_1M + 8 * i);
+ iowrite16(adrp[2], ioaddr + MID_1H + 8 * i);
+ i++;
+ }
+ while (i < MCAST_MAX) {
+ iowrite16(0, ioaddr + MID_1L + 8 * i);
+ iowrite16(0, ioaddr + MID_1M + 8 * i);
+ iowrite16(0, ioaddr + MID_1H + 8 * i);
+ i++;
+ }
+ }
+ /* Otherwise, Enable multicast hash table function. */
+ else {
u32 crc;
- for (i = 0; i < 4; i++)
- hash_table[i] = 0;
+ lp->mcr0 |= HASH_EN;
- for (i = 0; i < dev->mc_count; i++) {
- char *addrs = dmi->dmi_addr;
+ for (i = 0; i < MCAST_MAX ; i++) {
+ iowrite16(0, ioaddr + MID_1L + 8 * i);
+ iowrite16(0, ioaddr + MID_1M + 8 * i);
+ iowrite16(0, ioaddr + MID_1H + 8 * i);
+ }
+ /* Build multicast hash table */
+ for (i = 0; i < dev->mc_count; i++) {
+ u8 *addrs = dmi->dmi_addr;
dmi = dmi->next;
- if (!(*addrs & 1))
- continue;
-
- crc = ether_crc_le(6, addrs);
+ crc = ether_crc(ETH_ALEN, addrs);
crc >>= 26;
- hash_table[crc >> 4] |= 1 << (15 - (crc & 0xf));
+ hash_table[crc >> 4] |= 1 << (crc & 0xf);
}
- /* Fill the MAC hash tables with their values */
+
+ }
+ iowrite16(lp->mcr0, ioaddr + MCR0);
+
+ /* Fill the MAC hash tables with their values */
+ if (lp->mcr0 && HASH_EN) {
iowrite16(hash_table[0], ioaddr + MAR0);
iowrite16(hash_table[1], ioaddr + MAR1);
iowrite16(hash_table[2], ioaddr + MAR2);
iowrite16(hash_table[3], ioaddr + MAR3);
}
- /* Multicast Address 1~4 case */
- dmi = dev->mc_list;
- for (i = 0, dmi; (i < dev->mc_count) && (i < MCAST_MAX); i++) {
- adrp = (u16 *)dmi->dmi_addr;
- iowrite16(adrp[0], ioaddr + MID_1L + 8*i);
- iowrite16(adrp[1], ioaddr + MID_1M + 8*i);
- iowrite16(adrp[2], ioaddr + MID_1H + 8*i);
- dmi = dmi->next;
- }
- for (i = dev->mc_count; i < MCAST_MAX; i++) {
- iowrite16(0xffff, ioaddr + MID_1L + 8*i);
- iowrite16(0xffff, ioaddr + MID_1M + 8*i);
- iowrite16(0xffff, ioaddr + MID_1H + 8*i);
- }
+
+ spin_unlock_irqrestore(&lp->lock, flags);
}
static void netdev_get_drvinfo(struct net_device *dev,
---
===========================================================================================
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email.
If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately.
Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of DM&P Group is strictly prohibited; and any information in this email irrelevant to the official business of DM&P Group shall be deemed as neither given nor endorsed by DM&P Group.
===========================================================================================
^ permalink raw reply related
* FINAL NOTIFICATION
From: W.I.N.S @ 2010-11-03 14:20 UTC (permalink / raw)
I am pleased to inform you of the just concluded promotions
that was conducted on the 2nd NOVEMBER in regards to the
EU award promo. in this view you are to collect the
sum of one million Dollars. grant number.
(CT-222-6747,FGN/P-900-56).
Please contact Thomas Herman with the following detail Below
1) Full Names, 2) Full Addresss, 3) Sex, 4) Phone Number,
5) Occupation, 6) Nationality, 7) Age, 8) Country.
Email:
thomasherman@onfruit.cn
Sophia Bufford,
Promo Announcer.
^ permalink raw reply
* [PATCH] xfrm: use gre key as flow upper protocol info
From: Timo Teräs @ 2010-11-03 14:41 UTC (permalink / raw)
To: netdev, Herbert Xu; +Cc: Timo Teräs
The GRE Key field is intended to be used for identifying an individual
traffic flow within a tunnel. It is useful to be able to have XFRM
policy selector matches to have different policies for different
GRE tunnels.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
---
Basic testing done, but more knowledgeable should check that I did
not miss anything essential.
include/net/flow.h | 2 ++
include/net/xfrm.h | 6 ++++++
net/ipv4/ip_gre.c | 12 +++++++-----
net/ipv4/xfrm4_policy.c | 15 +++++++++++++++
4 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/include/net/flow.h b/include/net/flow.h
index 0ac3fb5..7196e68 100644
--- a/include/net/flow.h
+++ b/include/net/flow.h
@@ -67,6 +67,7 @@ struct flowi {
} dnports;
__be32 spi;
+ __be32 gre_key;
struct {
__u8 type;
@@ -78,6 +79,7 @@ struct flowi {
#define fl_icmp_code uli_u.icmpt.code
#define fl_ipsec_spi uli_u.spi
#define fl_mh_type uli_u.mht.type
+#define fl_gre_key uli_u.gre_key
__u32 secid; /* used by xfrm; see secid.txt */
} __attribute__((__aligned__(BITS_PER_LONG/8)));
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index bcfb6b2..54b2832 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -805,6 +805,9 @@ __be16 xfrm_flowi_sport(struct flowi *fl)
case IPPROTO_MH:
port = htons(fl->fl_mh_type);
break;
+ case IPPROTO_GRE:
+ port = htonl(fl->fl_gre_key) >> 16;
+ break;
default:
port = 0; /*XXX*/
}
@@ -826,6 +829,9 @@ __be16 xfrm_flowi_dport(struct flowi *fl)
case IPPROTO_ICMPV6:
port = htons(fl->fl_icmp_code);
break;
+ case IPPROTO_GRE:
+ port = htonl(fl->fl_gre_key) & 0xffff;
+ break;
default:
port = 0; /*XXX*/
}
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 70ff77f..ffc78e8 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -779,9 +779,9 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
.tos = RT_TOS(tos)
}
},
- .proto = IPPROTO_GRE
- }
-;
+ .proto = IPPROTO_GRE,
+ .fl_gre_key = tunnel->parms.o_key
+ };
if (ip_route_output_key(dev_net(dev), &rt, &fl)) {
dev->stats.tx_carrier_errors++;
goto tx_error;
@@ -958,7 +958,8 @@ static int ipgre_tunnel_bind_dev(struct net_device *dev)
.tos = RT_TOS(iph->tos)
}
},
- .proto = IPPROTO_GRE
+ .proto = IPPROTO_GRE,
+ .fl_gre_key = tunnel->parms.o_key
};
struct rtable *rt;
@@ -1223,7 +1224,8 @@ static int ipgre_open(struct net_device *dev)
.tos = RT_TOS(t->parms.iph.tos)
}
},
- .proto = IPPROTO_GRE
+ .proto = IPPROTO_GRE,
+ .fl_gre_key = t->parms.o_key
};
struct rtable *rt;
diff --git a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c
index 4464f3b..57af4bd 100644
--- a/net/ipv4/xfrm4_policy.c
+++ b/net/ipv4/xfrm4_policy.c
@@ -11,6 +11,7 @@
#include <linux/err.h>
#include <linux/kernel.h>
#include <linux/inetdevice.h>
+#include <linux/if_tunnel.h>
#include <net/dst.h>
#include <net/xfrm.h>
#include <net/ip.h>
@@ -158,6 +159,20 @@ _decode_session4(struct sk_buff *skb, struct flowi *fl, int reverse)
fl->fl_ipsec_spi = htonl(ntohs(ipcomp_hdr[1]));
}
break;
+
+ case IPPROTO_GRE:
+ if (pskb_may_pull(skb, xprth + 12 - skb->data)) {
+ __be16 *greflags = (__be16 *)xprth;
+ __be32 *gre_hdr = (__be32 *)xprth;
+
+ if (greflags[0] & GRE_KEY) {
+ if (greflags[0] & GRE_CSUM)
+ gre_hdr++;
+ fl->fl_gre_key = gre_hdr[1];
+ }
+ }
+ break;
+
default:
fl->fl_ipsec_spi = 0;
break;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 1/2] ixgb: Don't check for vlan group on transmit.
From: Jeff Kirsher @ 2010-11-03 14:55 UTC (permalink / raw)
To: Jesse Gross
Cc: David Miller, netdev@vger.kernel.org, Brandeburg, Jesse,
Waskiewicz Jr, Peter P
In-Reply-To: <1288464591-31528-1-git-send-email-jesse@nicira.com>
[-- Attachment #1: Type: text/plain, Size: 830 bytes --]
On Sat, 2010-10-30 at 11:49 -0700, Jesse Gross wrote:
>
> On transmit, the ixgb driver will only use vlan acceleration if a
> vlan group is configured. This can lead to tags getting dropped
> when bridging because the networking core assumes that a driver
> that claims vlan acceleration support can do it at all times. This
> change should have been part of commit eab6d18d "vlan: Don't check for
> vlan group before vlan_tx_tag_present." but was missed.
>
> Signed-off-by: Jesse Gross <jesse@nicira.com>
> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
> CC: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
> ---
> drivers/net/ixgb/ixgb_main.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Thanks Jesse, I have added this to my queue.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] igb: Don't depend on vlan group for receive size.
From: Jeff Kirsher @ 2010-11-03 14:55 UTC (permalink / raw)
To: Jesse Gross
Cc: David Miller, netdev@vger.kernel.org, Brandeburg, Jesse,
Waskiewicz Jr, Peter P
In-Reply-To: <1288464591-31528-2-git-send-email-jesse@nicira.com>
[-- Attachment #1: Type: text/plain, Size: 676 bytes --]
On Sat, 2010-10-30 at 11:49 -0700, Jesse Gross wrote:
> The igb driver currently sets its maximum receive size based on
> whether a vlan group is configured. However, this causes it to
> completely drop MTU sized vlan packets when there is no vlan
> group, preventing them from showing up in tcpdump, etc.
>
> Signed-off-by: Jesse Gross <jesse@nicira.com>
> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
> CC: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
> ---
> drivers/net/igb/igb_main.c | 5 +----
> 1 files changed, 1 insertions(+), 4 deletions(-)
Thanks, I have added this patch to my queue.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] be2net: Adding an option to use INTx instead of MSI-X
From: David Miller @ 2010-11-03 15:28 UTC (permalink / raw)
To: michael; +Cc: matthew, bhutchings, somnath.kotur, netdev, linux-pci
In-Reply-To: <1288788357.989.77.camel@concordia>
From: Michael Ellerman <michael@ellerman.id.au>
Date: Wed, 03 Nov 2010 23:45:57 +1100
> On Sat, 2010-10-30 at 17:21 -0600, Matthew Wilcox wrote:
>> On Tue, Oct 26, 2010 at 05:52:08PM +1100, Michael Ellerman wrote:
>> > That horse has really really bolted, it's gawn.
>> >
>> > I count 26 drivers with "disable MSI/X" parameters. Some even have more
>> > than one.
>>
>> That's 26 patches someone needs to write, then. You can put my Acked-by
>> on all of them.
>
> Bah, come on it's hardly the most horrendous sin committed by driver
> writers.
Yes but it's pretty high on the list because it deteriorates the
user experience.
It's a real selfish move to try and "fix" things in this way and
we've established that this isn't acceptable in the past.
^ permalink raw reply
* Unaligned accesses in AVR32 kernel
From: Ralf Baechle @ 2010-11-03 15:32 UTC (permalink / raw)
To: Hans-Christian Egtvedt; +Cc: linux-kernel, netdev, linux-hams, Simon Eatough
Hans-Christian,
I received a bug report for some networking code from which it seems as
if the AVR32 kernel doesn't fixup exceptions caused by missaligned kernel
accesses either in software or hardware. This is a problem as there in
the networking stack there is no general guarantee that all multi-byte
header fields such as ARP or IP headers will aligned. Networking drivers
are supposed to make a decent attempt to place packets at a suitable
address but there is no guarantee. The mkiss.c driver gets that wrong
which I'm fixing but fundamentally you want to add automated fixing of
unaligned exception to the AVR32 kernel. See arch/mips/kernel/unaligned.c.
Cheers,
Ralf
^ permalink raw reply
* [PATCH] mpc52xx: cleanup locking
From: Eric Dumazet @ 2010-11-03 15:56 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Asier Llano, Grant Likely, Jean-Michel Hautbois
commit 1e4e0767ecb1 (Fix locking on fec_mpc52xx driver) assumed IRQ are
enabled when an IRQ handler is called.
It is not the case anymore (IRQF_DISABLED is deprecated), so we can use
regular spin_lock(), no need for spin_lock_irqsave().
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Tested-by: Jean-Michel Hautbois <jhautbois@gmail.com>
Cc: Asier Llano <a.llano@ziv.es>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
drivers/net/fec_mpc52xx.c | 19 ++++++++-----------
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index e9f5d03..50c1213 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -366,9 +366,8 @@ static irqreturn_t mpc52xx_fec_tx_interrupt(int irq, void *dev_id)
{
struct net_device *dev = dev_id;
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
- unsigned long flags;
- spin_lock_irqsave(&priv->lock, flags);
+ spin_lock(&priv->lock);
while (bcom_buffer_done(priv->tx_dmatsk)) {
struct sk_buff *skb;
struct bcom_fec_bd *bd;
@@ -379,7 +378,7 @@ static irqreturn_t mpc52xx_fec_tx_interrupt(int irq, void *dev_id)
dev_kfree_skb_irq(skb);
}
- spin_unlock_irqrestore(&priv->lock, flags);
+ spin_unlock(&priv->lock);
netif_wake_queue(dev);
@@ -395,9 +394,8 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void *dev_id)
struct bcom_fec_bd *bd;
u32 status, physaddr;
int length;
- unsigned long flags;
- spin_lock_irqsave(&priv->lock, flags);
+ spin_lock(&priv->lock);
while (bcom_buffer_done(priv->rx_dmatsk)) {
@@ -429,7 +427,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void *dev_id)
/* Process the received skb - Drop the spin lock while
* calling into the network stack */
- spin_unlock_irqrestore(&priv->lock, flags);
+ spin_unlock(&priv->lock);
dma_unmap_single(dev->dev.parent, physaddr, rskb->len,
DMA_FROM_DEVICE);
@@ -438,10 +436,10 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void *dev_id)
rskb->protocol = eth_type_trans(rskb, dev);
netif_rx(rskb);
- spin_lock_irqsave(&priv->lock, flags);
+ spin_lock(&priv->lock);
}
- spin_unlock_irqrestore(&priv->lock, flags);
+ spin_unlock(&priv->lock);
return IRQ_HANDLED;
}
@@ -452,7 +450,6 @@ static irqreturn_t mpc52xx_fec_interrupt(int irq, void *dev_id)
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
struct mpc52xx_fec __iomem *fec = priv->fec;
u32 ievent;
- unsigned long flags;
ievent = in_be32(&fec->ievent);
@@ -470,9 +467,9 @@ static irqreturn_t mpc52xx_fec_interrupt(int irq, void *dev_id)
if (net_ratelimit() && (ievent & FEC_IEVENT_XFIFO_ERROR))
dev_warn(&dev->dev, "FEC_IEVENT_XFIFO_ERROR\n");
- spin_lock_irqsave(&priv->lock, flags);
+ spin_lock(&priv->lock);
mpc52xx_fec_reset(dev);
- spin_unlock_irqrestore(&priv->lock, flags);
+ spin_unlock(&priv->lock);
return IRQ_HANDLED;
}
^ permalink raw reply related
* Re: [PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Fix build warnings
From: Wolfgang Grandegger @ 2010-11-03 16:15 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Samuel Ortiz,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w, Masayuki Ohtake,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w, Christian Pellegrin,
David S. Miller, joel.clark-ral2JQCrhuEAvxtiuMwx3w,
qi.wang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <4CCE9F0B.1000901-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 11/01/2010 12:05 PM, Marc Kleine-Budde wrote:
> Hello,
>
> On 10/29/2010 09:32 PM, Wolfgang Grandegger wrote:
>
> some comments inline.
>
> [...]
...
>>>> + if (status & PCH_LEC_ALL) {
>>>> + priv->can.can_stats.bus_error++;
>>>> + stats->rx_errors++;
>>>> + switch (status & PCH_LEC_ALL) {
>>>
>>> I suggest to convert to a if-bit-set because there might be more than
>>> one bit set.
>>
>> Marc, what do you mean here. It's an enumeraton. Maybe the following
>> code is more clear:
>
> Oh, I haven't looked this one up in the datasheet.
>>
>> lec = status & PCH_LEC_ALL;
>> if (lec > 0) {
>
> or "if (lec)", YMMV
>
>> switch (lec) {
>>
>>>> + case PCH_STUF_ERR:
>>>> + cf->data[2] |= CAN_ERR_PROT_STUFF;
>>>> + break;
>>>> + case PCH_FORM_ERR:
>>>> + cf->data[2] |= CAN_ERR_PROT_FORM;
>>>> + break;
>>>> + case PCH_ACK_ERR:
>>>> + cf->data[2] |= CAN_ERR_PROT_LOC_ACK |
>>>> + CAN_ERR_PROT_LOC_ACK_DEL;
>>
>> Could you check what that type of bus error that is? Usually it's a ack
>> lost error.
>>
>>>> + break;
>>>> + case PCH_BIT1_ERR:
>>>> + case PCH_BIT0_ERR:
>>>> + cf->data[2] |= CAN_ERR_PROT_BIT;
>>>> + break;
>>>> + case PCH_CRC_ERR:
>>>> + cf->data[2] |= CAN_ERR_PROT_LOC_CRC_SEQ |
>>>> + CAN_ERR_PROT_LOC_CRC_DEL;
>>>> + break;
>>>> + default:
>>>> + iowrite32(status | PCH_LEC_ALL, &priv->regs->stat);
>>>> + break;
>>>> + }
>>>> +
>>>> + }
At a closer look, I doubt that the above LEC handling is correct.
According to the manual: "when the LEC shows the value “7,” this value
was written to the LEC by the CPU; thus, no CAN bus event was detected"
Therefore the LEC bits should be properly *initialized* and *reset* to
0x7, which I do not find in the code.
Wolfgang.
^ permalink raw reply
* [PATCH 0/1] UDEV - Rename onboard network interfaces to lomN if the user so desires
From: Narendra_K @ 2010-11-03 16:49 UTC (permalink / raw)
To: linux-hotplug; +Cc: netdev, Matt_Domsch, Jordan_Hargrave, Charles_Rose
Hello,
This patch adds support to udev's dynamic rule generation mechanism to
rename onboard network interfaces to lom1, lom2 etc if the user so
desires. (Please refer to this for more information -
http://marc.info/?l=linux-netdev&m=128646170613973&w=3).
From: Narendra K <narendra_k@dell.com>
Subject: [PATCH] UDEV - Rename onboard network interfaces to lomN if the user so desires
This patch adds support to udev's dynamic rule generation mechanism to
rename onboard network interfaces to lom1, lom2 etc if the user so
desires. (Please refer to this for more information -
http://marc.info/?l=linux-netdev&m=128646170613973&w=3).
It introduces a commad line parameter 'udevlom', which when passed
would rename onboard network interfaces to lomN. It would also generate
corresponding rules to make the names persistent across reboots.
With this patch, interface with firmware index=1 will be renamed to lom1,
index=2 will be rename to lom2 etc.(lom - Lan-On-Motherboard)
This patch is against Fedora 14 udev (version:161 release:4.fc14).
It requires the upstream commit 911e1c9b05a8e3559a7aa89083930700a0b9e7ee
for the firmware index to be available in sysfs.
With the patch applied, the network interfaces look like this on a
Dell PowerEdge R710 with four BCM5709 onboard NICs with firmware
indexes and four add-in interfaces.
[root@fedora-14-r710 ~]# ls /sys/class/net/
eth4 eth5 eth6 eth7 eth8 lo lom1 lom2 lom3 lom4
/etc/udev/rules.d/70-persistent-net.rules would look like this -
[snippet attched]
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:24:e8:2e:df:01", ATTR{dev_id}=="0x0", ATTR{type}=="1", ATTRS{index}=="2", KERNEL=="eth*", NAME="lom2"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:17:15:9b:eb", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:24:e8:2e:df:05", ATTR{dev_id}=="0x0", ATTR{type}=="1", ATTRS{index}=="4", KERNEL=="eth*", NAME="lom4"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:24:e8:2e:df:03", ATTR{dev_id}=="0x0", ATTR{type}=="1", ATTRS{index}=="3", KERNEL=="eth*", NAME="lom3"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:24:e8:2e:de:ff", ATTR{dev_id}=="0x0", ATTR{type}=="1", ATTRS{index}=="1", KERNEL=="eth*", NAME="lom1"
Signed-off-by: Narendra K <narendra_k@dell.com>
---
.../75-persistent-net-generator.rules | 4 ++++
| 15 ++++++++++++++-
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/extras/rule_generator/75-persistent-net-generator.rules b/extras/rule_generator/75-persistent-net-generator.rules
index 8119d0e..e138bd3 100644
--- a/extras/rule_generator/75-persistent-net-generator.rules
+++ b/extras/rule_generator/75-persistent-net-generator.rules
@@ -7,6 +7,7 @@
# MATCHID bus_id used for the match
# MATCHDRV driver name used for the match
# MATCHIFTYPE interface type match
+# MATCHINDEX firmware index used for the match
# COMMENT comment to add to the generated rule
# INTERFACE_NAME requested name supplied by external tool
# INTERFACE_NEW new interface name returned by rule writer
@@ -29,6 +30,9 @@ ENV{MATCHADDR}="$attr{address}"
# match interface type
ENV{MATCHIFTYPE}="$attr{type}"
+#read firmware index
+ATTRS{index}=="?*", ENV{MATCHINDEX}="$attr{index}"
+
# ignore KVM virtual interfaces
ENV{MATCHADDR}=="54:52:00:*", GOTO="persistent_net_generator_end"
--git a/extras/rule_generator/write_net_rules b/extras/rule_generator/write_net_rules
index 4379792..40aaa4b 100644
--- a/extras/rule_generator/write_net_rules
+++ b/extras/rule_generator/write_net_rules
@@ -11,6 +11,7 @@
# MATCHDEVID dev_id used for the match
# MATCHDRV driver name used for the match
# MATCHIFTYPE interface type match
+# MATCHINDEX firmware index used for the match
# COMMENT comment to add to the generated rule
# INTERFACE_NAME requested name supplied by external tool
# INTERFACE_NEW new interface name returned by rule writer
@@ -72,7 +73,11 @@ write_rule() {
echo ""
[ "$comment" ] && echo "# $comment"
- echo "SUBSYSTEM==\"net\", ACTION==\"add\"$match, NAME=\"$name\""
+ if [ "$MATCHINDEX" -a "$UDEVLOM" ]; then
+ echo "SUBSYSTEM==\"net\", ACTION==\"add\"$match, NAME=\"lom$MATCHINDEX\""
+ else
+ echo "SUBSYSTEM==\"net\", ACTION==\"add\"$match, NAME=\"$name\""
+ fi
} >> $RULES_FILE
}
@@ -108,6 +113,10 @@ if [ "$MATCHIFTYPE" ]; then
match="$match, ATTR{type}==\"$MATCHIFTYPE\""
fi
+if [ "$MATCHINDEX" -a "$UDEVLOM" ]; then
+ match="$match, ATTRS{index}==\"$MATCHINDEX\""
+fi
+
if [ -z "$match" ]; then
echo "missing valid match" >&2
unlock_rules_file
@@ -134,6 +143,10 @@ else
fi
fi
+if [ "$MATCHINDEX" -a "$UDEVLOM" ]; then
+ echo "INTERFACE_NEW=lom$MATCHINDEX"
+fi
+
write_rule "$match" "$INTERFACE" "$COMMENT"
unlock_rules_file
--
1.7.3.1
With regards,
Narendra K
^ permalink raw reply related
* [PATCH 1/1] UDEV - Add 'udevlom' command line param to start_udev
From: Narendra_K @ 2010-11-03 16:55 UTC (permalink / raw)
To: linux-hotplug; +Cc: netdev, Matt_Domsch, Jordan_Hargrave, Charles_Rose
Hello,
This patch allows users to specify if they want the onboard network
interfaces to be renamed to lomN by implementing a command line param
'udevlom'.
From: Narendra K <narendra_k@dell.com>
Subject: [PATCH] UDEV - Add 'udevlom' command line param to start_udev
This patch implements 'udevlom' command line parameter, which
when passed, results in onboard network interfaces getting
renamed to lomN.
Signed-off-by: Narendra K <narendra_k@dell.com>
---
start_udev | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/start_udev b/start_udev
index 49fc286..57d60c9 100755
--- a/start_udev
+++ b/start_udev
@@ -32,6 +32,7 @@ export TZ=/etc/localtime
. /etc/init.d/functions
prog=udev
+cmdline=`cat /proc/cmdline`
touch_recursive() {
( cd $1;
@@ -60,6 +61,10 @@ fi
ret=$[$ret + $?]
+if strstr "$cmdline" udevlom; then
+ /sbin/udevadm control --env=UDEVLOM="y"
+fi
+
/sbin/udevadm trigger --type=subsystems --action=add
/sbin/udevadm trigger --type=devices --action=add
/sbin/udevadm settle
--
1.7.3.1
With regards,
Narendra K
^ permalink raw reply related
* Re: [PATCH] drivers/net/tile/: on-chip network drivers for the tile architecture
From: Stephen Hemminger @ 2010-11-03 16:59 UTC (permalink / raw)
To: Chris Metcalf; +Cc: linux-kernel, netdev
In-Reply-To: <201011012107.oA1L7TGd031588@farm-0027.internal.tilera.com>
On Mon, 1 Nov 2010 17:00:37 -0400
Chris Metcalf <cmetcalf@tilera.com> wrote:
> This change adds the first network driver for the tile architecture,
> supporting the on-chip XGBE and GBE shims.
>
> The infrastructure is present for the TILE-Gx networking drivers (another
> three source files in the new directory) but for now the the actual
> tilegx sources are waiting on releasing hardware to initial customers.
>
> Note that arch/tile/include/hv/* are "upstream" headers from the
> Tilera hypervisor and will probably benefit less from LKML review.
>
> Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
> +typedef struct {
> + /** Byte offset of the next notify packet to be written: zero for the first
> + * packet on the queue, sizeof (netio_pkt_t) for the second packet on the
> + * queue, etc. */
> + volatile uint32_t __packet_write;
> +
> + /** Offset of the packet after the last valid packet (i.e., when any
> + * pointer is incremented to this value, it wraps back to zero). */
> + uint32_t __last_packet_plus_one;
> +}
> +__netio_packet_queue_t;
1. MUST not use volatile, see volatile-considered-harmful.txt
2. SHOULD use __u32 rather than uint32_t in kernel structures
3. MUST not introduce typedef's; use structures
4. SHOULD use proper kernel implementation
If you use scripts/checkpatch.pl it will tell you about these.
^ 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