* [Patch] netxen: remove unused firmware exports
From: Amerigo Wang @ 2010-11-03 4:25 UTC (permalink / raw)
To: linux-kernel
Cc: Dhananjay Phadke, Amit Kumar Salecha, Narender Kumar, netdev,
David S. Miller, Amerigo Wang
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>
---
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 50820be..5ddf112 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -41,9 +41,6 @@
MODULE_DESCRIPTION("QLogic/NetXen (1/10) GbE Converged Ethernet Driver");
MODULE_LICENSE("GPL");
MODULE_VERSION(NETXEN_NIC_LINUX_VERSIONID);
-MODULE_FIRMWARE(NX_P2_MN_ROMIMAGE_NAME);
-MODULE_FIRMWARE(NX_P3_CT_ROMIMAGE_NAME);
-MODULE_FIRMWARE(NX_P3_MN_ROMIMAGE_NAME);
MODULE_FIRMWARE(NX_UNIFIED_ROMIMAGE_NAME);
char netxen_nic_driver_name[] = "netxen_nic";
^ permalink raw reply related
* Re: [PATCH] net dst: fix percpu_counter list corruption and poison overwritten
From: Eric Dumazet @ 2010-11-03 5:22 UTC (permalink / raw)
To: Xiaotian Feng
Cc: netdev, linux-kernel, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy
In-Reply-To: <1288750265-17664-1-git-send-email-dfeng@redhat.com>
Le mercredi 03 novembre 2010 à 10:11 +0800, Xiaotian Feng a écrit :
> There're some percpu_counter list corruption and poison overwritten warnings
> in recent kernel, which is resulted by fc66f95c.
>
> commit fc66f95c switches to use percpu_counter, in ip6_route_net_init, kernel
> init the percpu_counter for dst entries, but, the percpu_counter is never destroyed
> in ip6_route_net_exit. So if the related data is freed by kernel, the freed percpu_counter
> is still on the list, then if we insert/remove other percpu_counter, list corruption
> resulted. Also, if the insert/remove option modifies the ->prev,->next pointer of
> the freed value, the poison overwritten is resulted then.
>
> With the following patch, the percpu_counter list corruption and poison overwritten
> warnings disappeared.
>
> Signed-off-by: Xiaotian Feng <dfeng@redhat.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> Cc: "Pekka Savola (ipv6)" <pekkas@netcore.fi>
> Cc: James Morris <jmorris@namei.org>
> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
> Cc: Patrick McHardy <kaber@trash.net>
> ---
Good catch, thanks !
Any reason you didnt Cc me (the author of the patch) ?
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [PATCH] net dst: fix percpu_counter list corruption and poison overwritten
From: Xiaotian Feng @ 2010-11-03 5:25 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, linux-kernel, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy
In-Reply-To: <1288761773.2467.535.camel@edumazet-laptop>
On 11/03/2010 01:22 PM, Eric Dumazet wrote:
> Le mercredi 03 novembre 2010 à 10:11 +0800, Xiaotian Feng a écrit :
>> There're some percpu_counter list corruption and poison overwritten warnings
>> in recent kernel, which is resulted by fc66f95c.
>>
>> commit fc66f95c switches to use percpu_counter, in ip6_route_net_init, kernel
>> init the percpu_counter for dst entries, but, the percpu_counter is never destroyed
>> in ip6_route_net_exit. So if the related data is freed by kernel, the freed percpu_counter
>> is still on the list, then if we insert/remove other percpu_counter, list corruption
>> resulted. Also, if the insert/remove option modifies the ->prev,->next pointer of
>> the freed value, the poison overwritten is resulted then.
>>
>> With the following patch, the percpu_counter list corruption and poison overwritten
>> warnings disappeared.
>>
>> Signed-off-by: Xiaotian Feng<dfeng@redhat.com>
>> Cc: "David S. Miller"<davem@davemloft.net>
>> Cc: Alexey Kuznetsov<kuznet@ms2.inr.ac.ru>
>> Cc: "Pekka Savola (ipv6)"<pekkas@netcore.fi>
>> Cc: James Morris<jmorris@namei.org>
>> Cc: Hideaki YOSHIFUJI<yoshfuji@linux-ipv6.org>
>> Cc: Patrick McHardy<kaber@trash.net>
>> ---
>
> Good catch, thanks !
>
> Any reason you didnt Cc me (the author of the patch) ?
Sorry, I just used get_maintainer.pl to get the cc list...
>
> Acked-by: Eric Dumazet<eric.dumazet@gmail.com>
>
>
>
>
^ permalink raw reply
* [regression, 2.6.37-rc1] 'ip link tap0 up' stuck in do_exit()
From: Dave Chinner @ 2010-11-03 6:26 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev
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.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
From: Pavel Machek @ 2010-11-02 1:21 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greg KH, Oliver Neukum, Valdis.Kletnieks, Dave Airlie, codalist,
ksummit-2010-discuss, autofs, Jan Harkes, Samuel Ortiz, Jan Kara,
Arnaldo Carvalho de Melo, netdev, Anders Larsen, linux-kernel,
dri-devel, Bryan Schumaker, Christoph Hellwig, Petr Vandrovec,
Mikulas Patocka, linux-fsdevel, Evgeniy Dushistov, Ingo Molnar,
Andrew Hendry, linux-media
In-Reply-To: <201010192244.41913.arnd@arndb.de>
Hi!
> @@ -79,6 +79,10 @@ static struct drm_driver driver = {
>
> static int __init i810_init(void)
> {
> + if (num_present_cpus() > 1) {
> + pr_err("drm/i810 does not support SMP\n");
> + return -EINVAL;
> + }
> driver.num_ioctls = i810_max_ioctl;
> return drm_init(&driver);
Umm, and now someone onlines second cpu?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
From: Pekka Enberg @ 2010-11-03 6:58 UTC (permalink / raw)
To: Pavel Machek
Cc: Arnd Bergmann, Greg KH, Oliver Neukum, Valdis.Kletnieks,
Dave Airlie, codalist, ksummit-2010-discuss, autofs, Jan Harkes,
Samuel Ortiz, Jan Kara, Arnaldo Carvalho de Melo, netdev,
Anders Larsen, linux-kernel, dri-devel, Bryan Schumaker,
Christoph Hellwig, Petr Vandrovec, Mikulas Patocka, linux-fsdevel,
Evgeniy Dushistov, Ingo Molnar, Andrew Hendry, linux-media
In-Reply-To: <20101102012135.GB2648@ucw.cz>
On Tue, Nov 2, 2010 at 3:21 AM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> @@ -79,6 +79,10 @@ static struct drm_driver driver = {
>>
>> static int __init i810_init(void)
>> {
>> + if (num_present_cpus() > 1) {
>> + pr_err("drm/i810 does not support SMP\n");
>> + return -EINVAL;
>> + }
>> driver.num_ioctls = i810_max_ioctl;
>> return drm_init(&driver);
>
> Umm, and now someone onlines second cpu?
Well, I see it's being fixed in a different way but yeah,
num_possible_cpus() would be more appropriate here.
^ permalink raw reply
* Re: [v3 RFC PATCH 0/4] Implement multiqueue virtio-net
From: Michael S. Tsirkin @ 2010-11-03 7:01 UTC (permalink / raw)
To: Krishna Kumar2
Cc: anthony, arnd, avi, davem, eric.dumazet, kvm, netdev, rusty
In-Reply-To: <OFE75E1E91.9722BFB3-ON652577CA.00256D94-652577CA.0027E1CE@in.ibm.com>
On Thu, Oct 28, 2010 at 12:48:57PM +0530, Krishna Kumar2 wrote:
> > Krishna Kumar2/India/IBM wrote on 10/28/2010 10:44:14 AM:
> >
> > > > > > Results for UDP BW tests (unidirectional, sum across
> > > > > > 3 iterations, each iteration of 45 seconds, default
> > > > > > netperf, vhosts bound to cpus 0-3; no other tuning):
> > > > >
> > > > > Is binding vhost threads to CPUs really required?
> > > > > What happens if we let the scheduler do its job?
> > > >
> > > > Nothing drastic, I remember BW% and SD% both improved a
> > > > bit as a result of binding.
> > >
> > > If there's a significant improvement this would mean that
> > > we need to rethink the vhost-net interaction with the scheduler.
> >
> > I will get a test run with and without binding and post the
> > results later today.
>
> Correction: The result with binding is is much better for
> SD/CPU compared to without-binding:
Something that was suggested to me off-list is
trying to set smp affinity for NIC: in host to guest
case probably virtio-net, for external to guest
the host NIC as well.
--
MST
^ permalink raw reply
* [PATCH] virtio-net: init link state correctly
From: Jason Wang @ 2010-11-03 7:08 UTC (permalink / raw)
To: rusty, davem; +Cc: markmc, netdev, linux-kernel, kvm, mst
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>
---
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 related
* Re: [regression, 2.6.37-rc1] 'ip link tap0 up' stuck in do_exit()
From: Eric Dumazet @ 2010-11-03 7:13 UTC (permalink / raw)
To: Dave Chinner; +Cc: linux-kernel, netdev
In-Reply-To: <20101103062609.GB31163@dastard>
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 ?
Thanks
^ permalink raw reply
* Re: tc action mirred packet lost
From: Nieścierowicz Adam @ 2010-11-03 7:16 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev
In-Reply-To: <4CCEA16B.1050603@gmail.com>
On Mon, 01 Nov 2010 12:15:55 +0100, Jarek Poplawski <jarkao2@gmail.com>
wrote:
> Nieścierowicz Adam wrote:
>> Hello,
>> recently there was a need to create 3-4 copies of the data sent to
>> the
>> router, I decided to use the tc action mirred.
>>
>>
>> Ingress traficn on eth1 copies to eth1 eth2, eth3, eth4, eth5 using:
>> ---
>> tc qdisc add dev eth1 ingress
>>
>> tc filter add dev eth1 parent ffff: protocol ip prio 10 u32 match ip
>> src
>> 0/0 flowid 1:1 action mirred egress mirror dev eth2 pipe action
>> mirred
>> egress mirror dev eth3 pipe action mirred egress mirror dev eth4
>> pipe
>> action mirred egress mirror dev eth5
>> --
>>
>>
>> Unfortunately the number of packets seen on eth1 qdisc is different
>> than
>> the eth [2-5]
>
> Hi,
> Usually the reason for such differences is arp or other non-ip
> protocols. Try a filter with "protocol all" to check this.
>
> 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
Thanks, it works
^ permalink raw reply
* 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
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