* Re: [PATCH] Add mac driver for w90p910
From: Trilok Soni @ 2009-07-20 17:49 UTC (permalink / raw)
To: David Miller; +Cc: mcuos.com, netdev, linux-arm-kernel, eric.y.miao
In-Reply-To: <20090720.074554.16551322.davem@davemloft.net>
Hi David,
On Mon, Jul 20, 2009 at 8:15 PM, David Miller<davem@davemloft.net> wrote:
> From: Wan ZongShun <mcuos.com@gmail.com>
> Date: Thu, 16 Jul 2009 20:55:05 +0800
>
>> Add mac driver support for evaluation board based on w90p910.
>>
>> Signed-off-by: Wan ZongShun <mcuos.com@gmail.com>
>
> Applied, thanks.
I thought Wan will send us the updated patch with fixing comments as
pointed by Russell.
Wan, could you please send updated patch.
--
---Trilok Soni
http://triloksoni.wordpress.com
http://www.linkedin.com/in/triloksoni
^ permalink raw reply
* Re: bonding: bug in balance-alb mode (incorrect update-ARP-replies)
From: Franck Chionna @ 2009-07-20 17:12 UTC (permalink / raw)
To: netdev
In-Reply-To: <FA8270F9F8D35946ADDBC0F36E6667CE0175C9B8@nts27.saarstahl.de>
JUNG, Christian wrote:
>
> Hello,
>
> I've discovered a bug in the bonding module of the Linux Kernel, which
> appears
> only in bonding-mode balance-alb.
>
> Description:
>
> You have to setup a box with at least two NICs, a bonding device
> enslaving
> those, assign at least two IPs to the bond and make some traffic from
> a
> different machine to one of those IPs.
>
> If you delete that IP, the box will regardlessly send ARP-replies to
> the
> machine which communicated to that IP before removing it.
>
> This comes from the rx_hashtbl and the receive load balancing
> algorithm.
>
> The bug is very serious if bonding is used in a cluster-environment
> using
> two nodes which are connected to the same subnet. If an IP-bound
> service
> has
> to failover to the other node, the old node would announce its
> MAC-address
> for the IP which isn't owned by the node anymore. So client-traffic in
> the
> same net would hit the old node.
>
> A possible workaround could be the usage of balance-tlb instead of
> balance-alb.
>
> I've made a little patch which removes every entry from the rx_hashtbl, if
> the
> according IP is removed from the bond. The patch was made for Linux Kernel
> version 2.6.19.
>
> ---8<---
> diff -ur linux-2.6.19/drivers/net/bonding/bond_alb.c
> linux/drivers/net/bonding/bond_alb.c
> --- linux-2.6.19/drivers/net/bonding/bond_alb.c 2006-11-29
> 22:57:37.000000000 +0100
> +++ linux/drivers/net/bonding/bond_alb.c 2007-01-16
> 17:23:53.000000000 +0100
> @@ -1677,3 +1677,38 @@
> }
> }
>
> +void bond_alb_remove_ip_from_rlb(struct bonding *bond, u32 ip) {
> + struct alb_bond_info *bond_info = &(BOND_ALB_INFO(bond));
> + u32 curr_index;
> +
> + dprintk("%s: removing entries from rx_hashtbl for IP %lx\n",
> bond->dev->name, ip);
> + _lock_rx_hashtbl(bond);
> +
> + curr_index = bond_info->rx_hashtbl_head;
> + while (curr_index != RLB_NULL_INDEX) {
> + struct rlb_client_info *curr =
> &(bond_info->rx_hashtbl[curr_index]);
> + u32 next_index = bond_info->rx_hashtbl[curr_index].next;
> + u32 prev_index = bond_info->rx_hashtbl[curr_index].prev;
> +
> + if (curr->ip_src == ip) {
> + dprintk("%s: entry %u matched\n", bond->dev->name,
> curr_index);
> +
> + if (curr_index == bond_info->rx_hashtbl_head) {
> + bond_info->rx_hashtbl_head = next_index;
> + }
> + if (prev_index != RLB_NULL_INDEX) {
> + bond_info->rx_hashtbl[prev_index].next =
> next_index;
> + }
> + if (next_index != RLB_NULL_INDEX) {
> + bond_info->rx_hashtbl[next_index].prev =
> prev_index;
> + }
> +
> + rlb_init_table_entry(curr);
> + }
> +
> + curr_index = next_index;
> + }
> +
> + _unlock_rx_hashtbl(bond);
> +}
> +
> diff -ur linux-2.6.19/drivers/net/bonding/bond_alb.h
> linux/drivers/net/bonding/bond_alb.h
> --- linux-2.6.19/drivers/net/bonding/bond_alb.h 2006-11-29
> 22:57:37.000000000 +0100
> +++ linux/drivers/net/bonding/bond_alb.h 2007-01-16
> 17:23:53.000000000 +0100
> @@ -128,5 +128,6 @@
> void bond_alb_monitor(struct bonding *bond);
> int bond_alb_set_mac_address(struct net_device *bond_dev, void *addr);
> void bond_alb_clear_vlan(struct bonding *bond, unsigned short vlan_id);
> +void bond_alb_remove_ip_from_rlb(struct bonding *bond, u32 ip);
> #endif /* __BOND_ALB_H__ */
>
> diff -ur linux-2.6.19/drivers/net/bonding/bond_main.c
> linux/drivers/net/bonding/bond_main.c
> --- linux-2.6.19/drivers/net/bonding/bond_main.c 2006-11-29
> 22:57:37.000000000 +0100
> +++ linux/drivers/net/bonding/bond_main.c 2007-01-16
> 17:30:49.000000000 +0100
> @@ -3356,6 +3356,12 @@
> return NOTIFY_OK;
> case NETDEV_DOWN:
> bond->master_ip =
> bond_glean_dev_ip(bond->dev);
> +
> + /* remove IP from RLB hashtable if using
> balance-alb mode: */
> + if (bond->params.mode == BOND_MODE_ALB) {
> + bond_alb_remove_ip_from_rlb(bond,
> ifa->ifa_local);
> + }
> +
> return NOTIFY_OK;
> default:
> return NOTIFY_DONE;
> ---8<---
>
> The function bond_alb_remove_ip_from_rlb is heavily based on the function
> rlb_clear_vlan.
>
> And here's a useful patch for debugging purposes (it outputs the
> rx_hashtbl
> in
> the proc-file of the bond):
>
> ---8<---
> diff -ur linux-2.6.19/drivers/net/bonding/bond_alb.c
> linux/drivers/net/bonding/bond_alb.c
> --- linux-2.6.19/drivers/net/bonding/bond_alb.c 2007-01-16
> 18:59:32.000000000 +0100
> +++ linux/drivers/net/bonding/bond_alb.c 2007-01-16
> 18:48:15.000000000 +0100
> @@ -26,6 +26,7 @@
> #include <linux/netdevice.h>
> #include <linux/etherdevice.h>
> #include <linux/pkt_sched.h>
> +#include <linux/seq_file.h>
> #include <linux/spinlock.h>
> #include <linux/slab.h>
> #include <linux/timer.h>
> @@ -1677,6 +1678,45 @@
> }
> }
>
> +void bond_alb_info_show(struct seq_file *seq) {
> + struct bonding *bond = seq->private;
> + struct alb_bond_info *bond_info = &(BOND_ALB_INFO(bond));
> + struct rlb_client_info *rx_hash_table;
> + u32 index;
> + u32 src, dst;
> +
> + seq_puts(seq, "\nALB info\n\n");
> + seq_puts(seq, " Receive Load Balancing table:\n\n");
> + seq_puts(seq, " Index Slave Server Client
> Client-MAC Asgnd\n");
> +
> + _lock_rx_hashtbl(bond);
> +
> + rx_hash_table = bond_info->rx_hashtbl;
> +
> + if (rx_hash_table != NULL) {
> + for (index = bond_info->rx_hashtbl_head;
> + index != RLB_NULL_INDEX;
> + index = rx_hash_table[index].next) {
> + src = ntohl(rx_hash_table[index].ip_src);
> + dst = ntohl(rx_hash_table[index].ip_dst);
> +
> + seq_printf(seq,
> + " %03u %8s %03u.%03u.%03u.%03u
> %03u.%03u.%03u.%03u %02x:%02x:%02x:%02x:%02x:%02x %3s\n",
> + index,
> + (rx_hash_table[index].slave != NULL
> ? rx_hash_table[index].slave->dev->name : "none"),
> + ((src >> 24) & 0xff), ((src >> 16) &
> 0xff), ((src >> 8) & 0xff), (src & 0xff),
> + ((dst >> 24) & 0xff), ((dst >> 16) &
> 0xff), ((dst >> 8) & 0xff), (dst & 0xff),
> + rx_hash_table[index].mac_dst[0],
> rx_hash_table[index].mac_dst[1],
> + rx_hash_table[index].mac_dst[2],
> rx_hash_table[index].mac_dst[3],
> + rx_hash_table[index].mac_dst[4],
> rx_hash_table[index].mac_dst[5],
> + (rx_hash_table[index].assigned ?
> "yes" : "no")
> + );
> + }
> + }
> +
> + _unlock_rx_hashtbl(bond);
> +}
> +
> void bond_alb_remove_ip_from_rlb(struct bonding *bond, u32 ip) {
> struct alb_bond_info *bond_info = &(BOND_ALB_INFO(bond));
> u32 curr_index;
> diff -ur linux-2.6.19/drivers/net/bonding/bond_alb.h
> linux/drivers/net/bonding/bond_alb.h
> --- linux-2.6.19/drivers/net/bonding/bond_alb.h 2007-01-16
> 18:59:32.000000000 +0100
> +++ linux/drivers/net/bonding/bond_alb.h 2007-01-16
> 19:01:46.000000000 +0100
> @@ -128,6 +128,7 @@
> void bond_alb_monitor(struct bonding *bond);
> int bond_alb_set_mac_address(struct net_device *bond_dev, void *addr);
> void bond_alb_clear_vlan(struct bonding *bond, unsigned short vlan_id);
> +void bond_alb_info_show(struct seq_file *seq);
> void bond_alb_remove_ip_from_rlb(struct bonding *bond, u32 ip);
> #endif /* __BOND_ALB_H__ */
>
> diff -ur linux-2.6.19/drivers/net/bonding/bond_main.c
> linux/drivers/net/bonding/bond_main.c
> --- linux-2.6.19/drivers/net/bonding/bond_main.c 2007-01-16
> 18:59:32.000000000 +0100
> +++ linux/drivers/net/bonding/bond_main.c 2007-01-16
> 18:48:15.000000000 +0100
> @@ -3048,6 +3048,10 @@
> ad_info.partner_system[5]);
> }
> }
> + else
> + if (bond->params.mode == BOND_MODE_ALB) {
> + bond_alb_info_show(seq);
> + }
> }
>
> static void bond_info_show_slave(struct seq_file *seq, const struct slave
> *slave)
> ---8<---
>
> I attach this example to visualize the bug. The box is named 'linux'
> (which
> has
> the two IPs 10.0.91.128 and 10.0.91.129) and the other machine (which
> makes
> some traffic) is called 'dave'. Their clocks are synchronized via NTP.
>
> ---8<---
> linux:~ # modprobe bonding miimon=100 updelay=200 mode=balance-alb
> use_carrier=0
> linux:~ # ifconfig bond0 10.0.91.128 netmask 255.255.255.0 up
> linux:~ # ifenslave bond0 eth1
> linux:~ # ifenslave bond0 eth2
> linux:~ # ip addr add 10.0.91.129 dev bond0
> linux:~ # ip addr sh bond0
> 18: bond0: <BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue
> link/ether 00:02:b3:55:2e:b1 brd ff:ff:ff:ff:ff:ff
> inet 10.0.91.128/24 brd 10.255.255.255 scope global bond0
> inet 10.0.91.129/32 scope global bond0
> inet6 fe80::200:ff:fe00:0/64 scope link
> valid_lft forever preferred_lft forever
> ---
>
> dave:~ # ping 10.0.91.129
> PING 10.0.91.129 (10.0.91.129) 56(84) bytes of data.
> 64 bytes from 10.0.91.129: icmp_seq=1 ttl=64 time=3.83 ms
> 64 bytes from 10.0.91.129: icmp_seq=2 ttl=64 time=0.205 ms
> [...]
> dave:~ # tcpdump -i bond0 arp host 10.0.91.129
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on bond0, link-type EN10MB (Ethernet), capture size 96 bytes
> 11:55:41.829735 arp reply 10.0.91.129 is-at 00:02:b3:55:2e:b1 (oui
> Unknown)
> 11:55:41.830993 arp reply 10.0.91.129 is-at 00:02:b3:55:2e:b1 (oui
> Unknown)
> 11:55:44.047261 arp reply 10.0.91.129 is-at 00:02:b3:55:2e:b1 (oui
> Unknown)
> 11:55:44.047276 arp reply 10.0.91.129 is-at 00:02:b3:55:2e:b1 (oui
> Unknown)
> [...]
>
> ---
>
> linux:~ # ip addr del 10.0.91.129 dev bond0
> linux:~ # ip addr sh bond0
> 18: bond0: <BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue
> link/ether 00:02:b3:55:2e:b1 brd ff:ff:ff:ff:ff:ff
> inet 10.0.91.128/24 brd 10.255.255.255 scope global bond0
> inet6 fe80::200:ff:fe00:0/64 scope link
> valid_lft forever preferred_lft forever
> linux:~ # date
> Tue Jan 16 11:55:57 CET 2007
>
> ---
>
> dave:~ # date
> Tue Jan 16 11:56:59 CET 2007
> dave:~ # tcpdump -i bond0 arp host 10.0.91.129
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on bond0, link-type EN10MB (Ethernet), capture size 96 bytes
> 11:57:04.305078 arp reply 10.0.91.129 is-at 00:02:b3:55:2e:b1 (oui
> Unknown)
> 11:57:04.306248 arp reply 10.0.91.129 is-at 00:02:b3:55:2e:b1 (oui
> Unknown)
> 11:57:06.704552 arp reply 10.0.91.129 is-at 00:02:b3:55:2e:b1 (oui
> Unknown)
> 11:57:06.704569 arp reply 10.0.91.129 is-at 00:02:b3:55:2e:b1 (oui
> Unknown)
> [...]
> ---8<---
>
>
> Bye
> Christian Jung
>
> PS I'm sorry but I have to use a mailer which has some handicaps. If the
> whitespaces of the patches are munged in any way I can send you the
> patches
> as
> attachment.
>
> Another thing: When shutting down a bond (e.g. ifconfig bond0 0.0.0.0
> down)
> the
> slaves keep the master IP address of the bond. Is there a special reason
> for
> this behaviour?
>
> phone: +49 6898/10-4987
> fax: +49 6898/10-54987
> http://www.saarstahl.de
> -
> 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
>
>
The problem seems to be existing yet in the last kernel today (2.6.30.1)
why your patch has not been integrated in kernel community ?
--
View this message in context: http://www.nabble.com/bonding%3A-bug-in-balance-alb-mode-%28incorrect-update-ARP-replies%29-tp8527082p24573842.html
Sent from the netdev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: regression: wireless authentication
From: Noah Watkins @ 2009-07-20 16:49 UTC (permalink / raw)
To: John W. Linville
Cc: linux-next, LKML, netdev, David S. Miller, Stephen Rothwell
In-Reply-To: <20090720162919.GE2775@tuxdriver.com>
Yeh, sorry--I forgot to mention I'm just now getting started
with linux-next, so I haven't successfully used wireless with
linux-next. I began to do a bisect and got preempted by the
weekend.
-n
----- Original Message -----
From: "John W. Linville" <linville@tuxdriver.com>
To: "Noah Watkins" <jayhawk@soe.ucsc.edu>
Cc: linux-next@vger.kernel.org, "LKML" <linux-kernel@vger.kernel.org>, netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>, "Stephen Rothwell" <sfr@canb.auug.org.au>
Sent: Monday, July 20, 2009 9:29:19 AM GMT -08:00 US/Canada Pacific
Subject: Re: regression: wireless authentication
On Mon, Jul 20, 2009 at 09:19:00AM -0700, Noah Watkins wrote:
> The latest version I've tried that works fine is Linus' 2.6.31-rc3
> with the latest commit being:
>
> commit 35b5c55fee08e6e4001ba98060a2d0b82f70b5f4
> Merge: e9e961c... b2dde6a...
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Wed Jul 15 10:29:09 2009 -0700
>
> I encountered the problem I described when I booted:
>
> 2.6.31-rc3-next-20090716
That's cool, but it is a bit "apples and oranges"... What was the
last -next version that was working for you?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
¡Viva Honduras Libre!
^ permalink raw reply
* Re: regression: wireless authentication
From: Jeff Chua @ 2009-07-20 16:32 UTC (permalink / raw)
To: Noah Watkins
Cc: John W. Linville, linux-next, LKML, netdev, David S. Miller,
Stephen Rothwell
In-Reply-To: <1198385022.260301248106740802.JavaMail.root@mail-01.cse.ucsc.edu>
On Tue, Jul 21, 2009 at 12:19 AM, Noah Watkins<jayhawk@soe.ucsc.edu> wrote:
> The latest version I've tried that works fine is Linus' 2.6.31-rc3
> with the latest commit being:
>
> commit 35b5c55fee08e6e4001ba98060a2d0b82f70b5f4
Mine says 78af08d90b8f745044b1274430bc4bc6b2b27aca which is later than
yours. Wireless working with iwl4965 including WPA2.
Jeff.
^ permalink raw reply
* Re: regression: wireless authentication
From: John W. Linville @ 2009-07-20 16:29 UTC (permalink / raw)
To: Noah Watkins; +Cc: linux-next, LKML, netdev, David S. Miller, Stephen Rothwell
In-Reply-To: <1198385022.260301248106740802.JavaMail.root@mail-01.cse.ucsc.edu>
On Mon, Jul 20, 2009 at 09:19:00AM -0700, Noah Watkins wrote:
> The latest version I've tried that works fine is Linus' 2.6.31-rc3
> with the latest commit being:
>
> commit 35b5c55fee08e6e4001ba98060a2d0b82f70b5f4
> Merge: e9e961c... b2dde6a...
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Wed Jul 15 10:29:09 2009 -0700
>
> I encountered the problem I described when I booted:
>
> 2.6.31-rc3-next-20090716
That's cool, but it is a bit "apples and oranges"... What was the
last -next version that was working for you?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
¡Viva Honduras Libre!
^ permalink raw reply
* Re: regression: wireless authentication
From: Noah Watkins @ 2009-07-20 16:19 UTC (permalink / raw)
To: John W. Linville
Cc: linux-next, LKML, netdev, David S. Miller, Stephen Rothwell
In-Reply-To: <1279186756.260191248106587108.JavaMail.root@mail-01.cse.ucsc.edu>
The latest version I've tried that works fine is Linus' 2.6.31-rc3
with the latest commit being:
commit 35b5c55fee08e6e4001ba98060a2d0b82f70b5f4
Merge: e9e961c... b2dde6a...
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed Jul 15 10:29:09 2009 -0700
I encountered the problem I described when I booted:
2.6.31-rc3-next-20090716
-n
----- Original Message -----
From: "John W. Linville" <linville@tuxdriver.com>
To: "Stephen Rothwell" <sfr@canb.auug.org.au>
Cc: "Noah Watkins" <jayhawk@soe.ucsc.edu>, linux-next@vger.kernel.org, "LKML" <linux-kernel@vger.kernel.org>, netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>
Sent: Monday, July 20, 2009 7:59:34 AM GMT -08:00 US/Canada Pacific
Subject: Re: regression: wireless authentication
On Fri, Jul 17, 2009 at 02:10:47PM +1000, Stephen Rothwell wrote:
> Hi Noah,
>
> Lets cc some people who may be able to help ...
>
> On Thu, 16 Jul 2009 20:57:06 -0700 Noah Watkins <jayhawk@soe.ucsc.edu> wrote:
> >
> > With 2.6.31-rc3-next-20090716 all wireless access points are detected, but
> > authentication fails. I haven't verified on an access point w/o WPA.
> >
> > 2.6.31-rc3 functions fine. I haven't been able to complete a bisect yet.
> >
> > 05:01.0 Network controller: Atheros Communications Inc. AR5008 Wireless Network
> > Adapter (rev 01)
Odd...have you (i.e. Noah) been using -next trees all along? What was
the last previous one that worked? I didn't push anything out for
-next to pick-up all last week...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
¡Viva Honduras Libre!
^ permalink raw reply
* Re: [PATCH] 3c589_cs: re-initialize the multicast in the tc589_reset
From: David Miller @ 2009-07-20 15:29 UTC (permalink / raw)
To: ken_kawasaki; +Cc: netdev
In-Reply-To: <20090720080812.49633622.ken_kawasaki@spring.nifty.jp>
From: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Date: Mon, 20 Jul 2009 08:08:12 +0900
>
> 3c589_cs:
> re-initialize the multicast in the tc589_reset,
> and spin_lock the set_multicast_list function.
>
> Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Applied, but you really need to fix your coding style.
I know perhaps you were trying to be consistent with the
rest of this driver, but when adding completely new code
the conventions of the rest of the kernel ought to be
followed, for example:
> +static void set_multicast_list(struct net_device *dev)
> +{
> + struct el3_private *priv = netdev_priv(dev);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&priv->lock, flags);
> + set_rx_mode(dev);
> + spin_unlock_irqrestore(&priv->lock, flags);
> +}
One tab should begin each statement in this function, and
spin_lock and spin_unlock lines had unnecessary trailing
whitespace.
I fixed all of this up when applying your patch, but I
absolutely will not do so next time.
Thank you.
^ permalink raw reply
* Re: [PATCH] New device ID for sc92031 [1088:2031]
From: David Miller @ 2009-07-20 15:27 UTC (permalink / raw)
To: cesarb; +Cc: netdev, rain_maker
In-Reply-To: <1248026612-12792-1-git-send-email-cesarb@cesarb.net>
From: Cesar Eduardo Barros <cesarb@cesarb.net>
Date: Sun, 19 Jul 2009 15:03:32 -0300
> rain_maker@root-forum.org wrote:
>> Hello cesar,
>>
>> In a recent thread in a german linux forum, a user reported his PIC
>> NIC not being recognized by the kernel.
>>
>> Fortunately he provided enough information and I was able to help him
>> and get the device working with the sc92031 driver.
>>
>> The device ID is [1088:2031] (Vendor is called "Microcomputer Systems
>> (M) Son"), here is the respective thread in "ubuntuusers.de"
>>
>> http://forum.ubuntuusers.de/topic/lankarte-unter-xubuntu-wird-nicht-erkannt/
>>
>> (Although you might not speak german, the code provided will show
>> you, that the device is actually working with your driver).
>>
>> It would be nice, if you include this new device ID to the
>> sc92031-driver.
>>
>> Regards,
>>
>> Axel Köllhofer (aka Rain_Maker)
>
> Cc: rain_maker@root-forum.org
> Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.net>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] Fix error return for setsockopt(SO_TIMESTAMPING)
From: David Miller @ 2009-07-20 15:24 UTC (permalink / raw)
To: remi.denis-courmont; +Cc: netdev
In-Reply-To: <1248086824-18836-1-git-send-email-remi.denis-courmont@nokia.com>
From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Date: Mon, 20 Jul 2009 13:47:04 +0300
> From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
>
> I guess it should be -EINVAL rather than EINVAL. I have not checked
> when the bug came in. Perhaps a candidate for -stable?
>
> Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/3] netxen bug fixes
From: David Miller @ 2009-07-20 15:23 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1247880428-4895-1-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Fri, 17 Jul 2009 18:27:05 -0700
> Set of 3 critical bug fixes for 2.6.31, including a fix for
> intermittant deadlock on dev close.
Applied, thanks.
^ permalink raw reply
* Re: net: Micrel KS8851 SPI network driver
From: David Miller @ 2009-07-20 15:23 UTC (permalink / raw)
To: ben; +Cc: netdev
In-Reply-To: <20090716152407.854086020@fluff.org.uk>
From: Ben Dooks <ben@simtec.co.uk>
Date: Thu, 16 Jul 2009 16:24:08 +0100
> Network driver for the SPI version of the Micrel KS8851
> network chip.
>
> Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/15] RDS updates for net-next
From: David Miller @ 2009-07-20 15:04 UTC (permalink / raw)
To: andy.grover; +Cc: netdev, rds-devel
In-Reply-To: <1247872416-17834-1-git-send-email-andy.grover@oracle.com>
From: Andy Grover <andy.grover@oracle.com>
Date: Fri, 17 Jul 2009 16:13:21 -0700
> These are some assorted RDS updates to net-next, please review and
> apply if they look ok.
All applied to net-next-2.6, thanks!
^ permalink raw reply
* Re: [PATCH] net: explain netns notifiers a little better
From: David Miller @ 2009-07-20 15:04 UTC (permalink / raw)
To: johannes; +Cc: netdev, ebiederm
In-Reply-To: <1247674594.10754.20.camel@johannes.local>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Wed, 15 Jul 2009 18:16:34 +0200
> Eric explained this to me -- and afterwards the comment
> made sense, but not before. Add the the critical point
> about interfaces having to be gone from the netns before
> subsys notifiers are called.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH] b44: strncpy does not null terminate string
From: David Miller @ 2009-07-20 15:04 UTC (permalink / raw)
To: roel.kluin; +Cc: zambrano, netdev, akpm
In-Reply-To: <4A60BC92.7030406@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Fri, 17 Jul 2009 20:01:54 +0200
> strlcpy() will always null terminate the string. Also use the
> sizeof(version) to strlcopy() the version string.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: regression: wireless authentication
From: John W. Linville @ 2009-07-20 14:59 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Noah Watkins, linux-next, LKML, netdev, David S. Miller
In-Reply-To: <20090717141047.7ce77136.sfr@canb.auug.org.au>
On Fri, Jul 17, 2009 at 02:10:47PM +1000, Stephen Rothwell wrote:
> Hi Noah,
>
> Lets cc some people who may be able to help ...
>
> On Thu, 16 Jul 2009 20:57:06 -0700 Noah Watkins <jayhawk@soe.ucsc.edu> wrote:
> >
> > With 2.6.31-rc3-next-20090716 all wireless access points are detected, but
> > authentication fails. I haven't verified on an access point w/o WPA.
> >
> > 2.6.31-rc3 functions fine. I haven't been able to complete a bisect yet.
> >
> > 05:01.0 Network controller: Atheros Communications Inc. AR5008 Wireless Network
> > Adapter (rev 01)
Odd...have you (i.e. Noah) been using -next trees all along? What was
the last previous one that worked? I didn't push anything out for
-next to pick-up all last week...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
¡Viva Honduras Libre!
^ permalink raw reply
* Re: [RFC/PATCH] net: Rework mdio-ofgpio driver to use of_mdio infrastructure
From: Grant Likely @ 2009-07-20 14:59 UTC (permalink / raw)
To: Mark Ware; +Cc: netdev, linuxppc-dev
In-Reply-To: <4A646117.1030409@elphinstone.net>
(adding cc:linuxppc-dev@ozlabs.org)
On Mon, Jul 20, 2009 at 6:20 AM, Mark Ware<mware@elphinstone.net> wrote:
> Changes to the fs_enet driver (aa73832c5a80d6c52c69b18af858d88fa595dd3c)
> cause kernel crashes when using the mdio-ofgpio driver.
>
> The following patch is a fairly naive attempt to replicate similar changes
> made to the fs_enet mii-bitbang drivers.
For a naive attempt, it's really quite good. However, I'd do it
slightly differently.
You should refactor mdio_gpio_bus_init() to not call
mdiobus_register() at all, and instead just return a pointer to the
unregistered new_bus. Then mdio_gpio_probe() and mdio_ofgpio_probe()
can call the correct register variant directly. Fewer ugly #ifdefs
this way. It also eliminates the need to cast the void* pointer.
Thanks for catching this.
g.
> drivers/net/phy/mdio-gpio.c | 39 +++++++++++++--------------------------
> 1 files changed, 13 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
> index 33984b7..6568176 100644
> --- a/drivers/net/phy/mdio-gpio.c
> +++ b/drivers/net/phy/mdio-gpio.c
> @@ -30,6 +30,7 @@
>
> #ifdef CONFIG_OF_GPIO
> #include <linux/of_gpio.h>
> +#include <linux/of_mdio.h>
> #include <linux/of_platform.h>
> #endif
>
> @@ -83,7 +84,8 @@ static struct mdiobb_ops mdio_gpio_ops = {
>
> static int __devinit mdio_gpio_bus_init(struct device *dev,
> struct mdio_gpio_platform_data
> *pdata,
> - int bus_id)
> + int bus_id,
> + void *ofdev)
> {
> struct mii_bus *new_bus;
> struct mdio_gpio_info *bitbang;
> @@ -129,7 +131,14 @@ static int __devinit mdio_gpio_bus_init(struct device
> *dev,
>
> dev_set_drvdata(dev, new_bus);
>
> - ret = mdiobus_register(new_bus);
> +#ifdef CONFIG_OF_GPIO
> + if (ofdev)
> + ret = of_mdiobus_register(new_bus, ((struct of_device *)
> ofdev)->node);
> + else
> +#else
> + ret = mdiobus_register(new_bus);
> +#endif
> +
> if (ret)
> goto out_free_all;
>
> @@ -168,7 +177,7 @@ static int __devinit mdio_gpio_probe(struct
> platform_device *pdev)
> if (!pdata)
> return -ENODEV;
>
> - return mdio_gpio_bus_init(&pdev->dev, pdata, pdev->id);
> + return mdio_gpio_bus_init(&pdev->dev, pdata, pdev->id, NULL);
> }
>
> static int __devexit mdio_gpio_remove(struct platform_device *pdev)
> @@ -179,28 +188,10 @@ static int __devexit mdio_gpio_remove(struct
> platform_device *pdev)
> }
>
> #ifdef CONFIG_OF_GPIO
> -static void __devinit add_phy(struct mdio_gpio_platform_data *pdata,
> - struct device_node *np)
> -{
> - const u32 *data;
> - int len, id, irq;
> -
> - data = of_get_property(np, "reg", &len);
> - if (!data || len != 4)
> - return;
> -
> - id = *data;
> - pdata->phy_mask &= ~(1 << id);
> -
> - irq = of_irq_to_resource(np, 0, NULL);
> - if (irq)
> - pdata->irqs[id] = irq;
> -}
>
> static int __devinit mdio_ofgpio_probe(struct of_device *ofdev,
> const struct of_device_id *match)
> {
> - struct device_node *np = NULL;
> struct mdio_gpio_platform_data *pdata;
> int ret;
>
> @@ -218,11 +209,7 @@ static int __devinit mdio_ofgpio_probe(struct of_device
> *ofdev,
> goto out_free;
> pdata->mdio = ret;
>
> - while ((np = of_get_next_child(ofdev->node, np)))
> - if (!strcmp(np->type, "ethernet-phy"))
> - add_phy(pdata, np);
> -
> - return mdio_gpio_bus_init(&ofdev->dev, pdata, pdata->mdc);
> + return mdio_gpio_bus_init(&ofdev->dev, pdata, pdata->mdc, ofdev);
>
> out_free:
> kfree(pdata);
> --
> 1.5.6.5
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] USB host CDC Phonet network interface driver
From: David Miller @ 2009-07-20 14:55 UTC (permalink / raw)
To: remi.denis-courmont; +Cc: oliver, netdev, linux-usb
In-Reply-To: <200907200935.19103.remi.denis-courmont@nokia.com>
From: "Rémi Denis-Courmont" <remi.denis-courmont@nokia.com>
Date: Mon, 20 Jul 2009 09:35:18 +0300
> In the racy case, tx_complete() fires, incrementation in
> usbpn_xmit() and decrementation in tx_complete() will cancel each
> other. So, regardless of their respective order, tx_queue will be
> unchanged, and the assertion remains valid. A fortiori, it works
> fine if usbpn_xmit() races with more than one call of tx_complete().
You can only do the wakeup race free without deadlocking the TX queue
state if you grab the TX path lock, as TG3 does:
/* Need to make the tx_cons update visible to tg3_start_xmit()
* before checking for netif_queue_stopped(). Without the
* memory barrier, there is a small possibility that tg3_start_xmit()
* will miss it and cause the queue to be stopped forever.
*/
smp_mb();
if (unlikely(netif_queue_stopped(tp->dev) &&
(tg3_tx_avail(tp) > TG3_TX_WAKEUP_THRESH(tp)))) {
netif_tx_lock(tp->dev);
if (netif_queue_stopped(tp->dev) &&
(tg3_tx_avail(tp) > TG3_TX_WAKEUP_THRESH(tp)))
netif_wake_queue(tp->dev);
netif_tx_unlock(tp->dev);
}
^ permalink raw reply
* Re: [PATCH] tcp: Use correct peer adr when copying MD5 keys
From: David Miller @ 2009-07-20 14:50 UTC (permalink / raw)
To: john.dykstra1; +Cc: shemminger, netdev, agl, yoshfuji
In-Reply-To: <1247858602.8509.7.camel@Maple>
From: John Dykstra <john.dykstra1@gmail.com>
Date: Fri, 17 Jul 2009 19:23:22 +0000
> [PATCH] tcp: Use correct peer adr when copying MD5 keys
>
> When the TCP connection handshake completes on the passive
> side, a variety of state must be set up in the "child" sock,
> including the key if MD5 authentication is being used. Fix TCP
> for both address families to label the key with the peer's
> destination address, rather than the address from the listening
> sock, which is usually the wildcard.
>
> Reported-by: Stephen Hemminger <shemminger@vyatta.com>
> Signed-off-by: John Dykstra <john.dykstra1@gmail.com>
Also applied, thanks!
^ permalink raw reply
* Re: [RFC][PATCH 1/2] mcastv6: Local variable shadows function argument
From: David Stevens @ 2009-07-20 14:50 UTC (permalink / raw)
To: Gerrit Renker; +Cc: davem, Gerrit Renker, netdev, netdev-owner
In-Reply-To: <1248028721-24244-2-git-send-email-gerrit@erg.abdn.ac.uk>
pmc->idev should be equal to idev, so you should be able
to simply remove the extra declaration and leave the other
code as it is-- i.e., a 1-line change.
+-DLS
^ permalink raw reply
* Re: [PATCHv2] tcp: Fix MD5 signature checking on IPv4 mapped sockets
From: David Miller @ 2009-07-20 14:50 UTC (permalink / raw)
To: john.dykstra1; +Cc: netdev, shemminger
In-Reply-To: <1247756691.7627.5.camel@Maple>
From: John Dykstra <john.dykstra1@gmail.com>
Date: Thu, 16 Jul 2009 10:04:51 -0500
> Fix MD5 signature checking so that an IPv4 active open
> to an IPv6 socket can succeed. In particular, use the
> correct address family's signature generation function
> for the SYN/ACK.
>
> Reported-by: Stephen Hemminger <shemminger@vyatta.com>
> Signed-off-by: John Dykstra <john.dykstra1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] Add mac driver for w90p910
From: David Miller @ 2009-07-20 14:45 UTC (permalink / raw)
To: mcuos.com; +Cc: netdev, linux-arm-kernel, eric.y.miao
In-Reply-To: <4A5F2329.9090901@gmail.com>
From: Wan ZongShun <mcuos.com@gmail.com>
Date: Thu, 16 Jul 2009 20:55:05 +0800
> Add mac driver support for evaluation board based on w90p910.
>
> Signed-off-by: Wan ZongShun <mcuos.com@gmail.com>
Applied, thanks.
^ permalink raw reply
* Greetings.
From: glevy @ 2009-07-20 14:33 UTC (permalink / raw)
Greetings.
You have a bank draft of $78,000USD with TNT company,which await the
outstanding payment of $135USD Contact the TNT courier company for
claims with your personnal Details.Contact person :Mr west Oduduwa
Email: www.tntwestafricanzone@hotmail.com Tel:+234 808 904 8721
^ permalink raw reply
* Re: [PATCH net-next] ipv4: fib_trie: Use tnode_get_child_rcu() and node_parent_rcu() in lookups
From: David Miller @ 2009-07-20 14:41 UTC (permalink / raw)
To: jarkao2; +Cc: paulmck, pstaszewski, netdev, robert
In-Reply-To: <20090714212032.GB7952@ami.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Tue, 14 Jul 2009 23:20:32 +0200
>
> While looking for other fib_trie problems reported by Pawel Staszewski
> I noticed there are a few uses of tnode_get_child() and node_parent()
> in lookups instead of their rcu versions.
>
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] Re: rib_trie / Fix inflate_threshold_root. Now=15 size=11 bits
From: David Miller @ 2009-07-20 14:41 UTC (permalink / raw)
To: jarkao2; +Cc: pstaszewski, netdev, robert, jorge
In-Reply-To: <20090714194100.GA7952@ami.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Tue, 14 Jul 2009 21:41:00 +0200
> ipv4: Fix inflate_threshold_root automatically
>
> During large updates there could be triggered warnings like: "Fix
> inflate_threshold_root. Now=25 size=11 bits" if inflate() of the root
> node isn't finished in 10 loops. It should be much rarer now, after
> changing the threshold from 15 to 25, and a temporary problem, so
> this patch tries to handle it automatically using a fix variable to
> increase by one inflate threshold for next root resizes (up to the 35
> limit, max fix = 10). The fix variable is decreased when root's
> inflate() finishes below 7 loops (even if some other, smaller table/
> trie is updated -- for simplicity the fix variable is global for now).
>
> Reported-by: Pawel Staszewski <pstaszewski@itcare.pl>
> Reported-by: Jorge Boncompte [DTI2] <jorge@dti2.net>
> Tested-by: Pawel Staszewski <pstaszewski@itcare.pl>
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] Re: rib_trie / Fix inflate_threshold_root. Now=15 size=11 bits
From: David Miller @ 2009-07-20 14:41 UTC (permalink / raw)
To: jarkao2; +Cc: paulmck, pstaszewski, netdev, robert
In-Reply-To: <20090714183308.GB3090@ami.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Tue, 14 Jul 2009 20:33:08 +0200
> ipv4: Use synchronize_rcu() during trie_rebalance()
>
> During trie_rebalance() we free memory after resizing with call_rcu(),
> but large updates, especially with PREEMPT_NONE configs, can cause
> memory stresses, so this patch calls synchronize_rcu() in
> tnode_free_flush() after each sync_pages to guarantee such freeing
> (especially before resizing the root node).
>
> The value of sync_pages = 128 is based on Pawel Staszewski's tests as
> the lowest which doesn't hinder updating times. (For testing purposes
> there was a sysfs module parameter to change it on demand, but it's
> removed until we're sure it could be really useful.)
>
> The patch is based on suggestions by: Paul E. McKenney
> <paulmck@linux.vnet.ibm.com>
>
> Reported-by: Pawel Staszewski <pstaszewski@itcare.pl>
> Tested-by: Pawel Staszewski <pstaszewski@itcare.pl>
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Applied.
^ 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