* Re: [PATCH] bridge: Forward EAPOL when STP off
From: Stephen Hemminger @ 2011-06-04 13:42 UTC (permalink / raw)
To: Nick Carter; +Cc: netdev, benjamin.poirier, davem, shemminger
In-Reply-To: <BANLkTimdK-5tsWcTFbe_-82fHxr4TN4F_g@mail.gmail.com>
On Thu, 2 Jun 2011 16:59:13 +0100
Nick Carter <ncarter100@gmail.com> wrote:
> Signed-off-by: Nick Carter <ncarter100@gmail.com>
>
> If STP is disabled then forward frames destined to the 802.1X PAE group
> address (01-80-C2-00-00-03)
>
> This change is required to support virtual machines running an 802.1X
> supplicant and bridged to an ethernet interface.
>
> This change has been tested and works fine with a range of supplicants.
No. This is getting messy and starts down the path of the recent
802.3ad change which just got reverted. A better solution is needed
than individual hacky standards breaking. If you really need to do
this, use the "duct tape" of networking ebtables.
See also:
https://lists.linux-foundation.org/pipermail/bridge/2007-November/005638.html
^ permalink raw reply
* [PATCH] netfilter: nf_nat: avoid double nat for loopback
From: Julian Anastasov @ 2011-06-04 14:02 UTC (permalink / raw)
To: Patrick McHardy, Pablo Neira Ayuso, netfilter-devel, netdev
Avoid double NAT and seq adjustment for loopback
traffic because it causes silent repetition of TCP data. One
example is passive FTP with DNAT rule and difference in the
length of IP addresses.
This patch adds checks if packet is sent and
received via loopback device. As the same conntrack is used
both for outgoing and incoming direction, we restrict NAT,
seq adjustment and confirmation to happen only in
outgoing direction (OUTPUT and POSTROUTING).
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
As the check is not so cheap, another alternative
is to add new skb flag, eg. "loopback", that can be set in
drivers/net/loopback.c, loopback_xmit(). May be there is space
for it in flags2?
diff -urp v2.6.39/linux/include/net/netfilter/nf_conntrack.h linux/include/net/netfilter/nf_conntrack.h
--- v2.6.39/linux/include/net/netfilter/nf_conntrack.h 2011-05-20 10:38:04.000000000 +0300
+++ linux/include/net/netfilter/nf_conntrack.h 2011-06-04 14:53:54.636380393 +0300
@@ -308,6 +308,12 @@ static inline int nf_ct_is_untracked(con
return test_bit(IPS_UNTRACKED_BIT, &ct->status);
}
+/* Packet is received from loopback */
+static inline bool nf_is_loopback_packet(const struct sk_buff *skb)
+{
+ return skb->dev && skb->skb_iif && skb->dev->flags & IFF_LOOPBACK;
+}
+
extern int nf_conntrack_set_hashsize(const char *val, struct kernel_param *kp);
extern unsigned int nf_conntrack_htable_size;
extern unsigned int nf_conntrack_max;
diff -urp v2.6.39/linux/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c linux/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
--- v2.6.39/linux/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c 2010-08-02 09:37:49.000000000 +0300
+++ linux/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c 2011-06-04 14:17:28.223380526 +0300
@@ -99,6 +99,10 @@ static unsigned int ipv4_confirm(unsigne
const struct nf_conntrack_helper *helper;
unsigned int ret;
+ /* loopback traffic is confirmed only in outgoing direction */
+ if (unlikely(nf_is_loopback_packet(skb)))
+ return NF_ACCEPT;
+
/* This is where we call the helper: as the packet goes out. */
ct = nf_ct_get(skb, &ctinfo);
if (!ct || ctinfo == IP_CT_RELATED + IP_CT_IS_REPLY)
diff -urp v2.6.39/linux/net/ipv4/netfilter/nf_nat_standalone.c linux/net/ipv4/netfilter/nf_nat_standalone.c
--- v2.6.39/linux/net/ipv4/netfilter/nf_nat_standalone.c 2011-05-20 10:38:08.000000000 +0300
+++ linux/net/ipv4/netfilter/nf_nat_standalone.c 2011-06-04 14:55:02.542587345 +0300
@@ -86,6 +86,10 @@ nf_nat_fn(unsigned int hooknum,
/* maniptype == SRC for postrouting. */
enum nf_nat_manip_type maniptype = HOOK2MANIP(hooknum);
+ /* NAT for loopback traffic is done only in outgoing direction */
+ if (unlikely(nf_is_loopback_packet(skb)))
+ return NF_ACCEPT;
+
/* We never see fragments: conntrack defrags on pre-routing
and local-out, and nf_nat_out protects post-routing. */
NF_CT_ASSERT(!(ip_hdr(skb)->frag_off & htons(IP_MF | IP_OFFSET)));
^ permalink raw reply
* Re: pull request: wireless-2.6 2011-06-03
From: Rafał Miłecki @ 2011-06-04 14:36 UTC (permalink / raw)
To: John W. Linville
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110604130413.GA3929-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
W dniu 4 czerwca 2011 15:04 użytkownik John W. Linville
<linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> napisał:
> On Fri, Jun 03, 2011 at 11:24:49PM +0200, Rafał Miłecki wrote:
>> On Jun 3, 2011 10:03 PM, "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote:
>> >
>> > Dave,
>> >
>> > Here is a batch of fixes intended for 3.0 -- I guess I'll need to
>> > rename my tree eventually... :-)
>> >
>> > Included are a libertas fix to ensure proper sequence number assignment
>> > on transmitted frames, an ath9k fix that propogates an earlier fix to a
>> > few more places, a fix for a cfg80211 regression caused by some mesh
>> > code changes, a locking fix for the bluetooth l2cap code, a zd1211rw
>> > regression fix, a collection of small fixes for wl12xx, an iwl4965
>> > fix for a bad temperature check, an a device ID-related fix for iwlagn.
>> >
>> > Please let me know if there are problems!
>>
>> John, you didn't.take my fix for regression in ssb. I really want this for
>> 3.0.quickly, as few ppl already had problems with machine locking on boot.
>
> Yours isn't the only fix, and I had quite a few queued already. Patience.
OK, I was just afraid you missed this one :) Sorry if I meant rude.
--
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: software iwarp stack update
From: Bart Van Assche @ 2011-06-04 18:01 UTC (permalink / raw)
To: Bernard Metzler
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <OF64770AFC.B48EBEF2-ONC12577A6.002CC793-C12577A6.002DC569-Xeyd2O9EBijQT0dZR+AlfA@public.gmane.org>
On Wed, Sep 22, 2010 at 10:19 AM, Bernard Metzler <BMT-OA+xvbQnYDHMbYB6QlFGEg@public.gmane.org> wrote:
> Earlier this year, we announced the availability of an open source,
> full software implementation of the iWARP RDMA protocol stack - see
> my email "software iwarp stack" from March 14th at the linux-rdma list
> (http://www.mail-archive.com/linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg02940.html)
> While since then working on performance and stability, we provided
> some source code updates. Current user and kernel code is available at
> gitorious.org/softiwarp. Please see the CHANGES file in the
> kernel/ directory for a summary of the most recent changes.
(replying to an e-mail of about nine months ago)
Hello Bernard,
It has been pretty quiet recently around the "siw" driver. Have you
had the chance to make any progress recently on this driver ?
Thanks,
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: small RPS cache for fragments?
From: David Miller @ 2011-06-04 20:29 UTC (permalink / raw)
To: rick.jones2; +Cc: netdev
In-Reply-To: <1306273128.8149.1444.camel@tardy>
From: Rick Jones <rick.jones2@hp.com>
Date: Tue, 24 May 2011 14:38:48 -0700
> Isn't there still an issue (perhaps small) of traffic being sent through
> a mode-rr bond, either at the origin or somewhere along the way? At the
> origin point will depend on the presence of UFO and whether it is
> propagated up through the bond interface, but as a quick test, I
> disabled TSO, GSO and UFO on four e1000e driven interfaces, bonded them
> mode-rr and ran a netperf UDP_RR test with a 1473 byte request size and
> this is what they looked like at my un-bonded reciever at the other end:
>
> 14:31:01.011370 IP (tos 0x0, ttl 64, id 24960, offset 1480, flags
> [none], proto UDP (17), length 21)
> tardy.local > raj-8510w.local: udp
> 14:31:01.011420 IP (tos 0x0, ttl 64, id 24960, offset 0, flags [+],
> proto UDP (17), length 1500)
> tardy.local.36073 > raj-8510w.local.59951: UDP, length 1473
> 14:31:01.011514 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
> UDP (17), length 29)
> raj-8510w.local.59951 > tardy.local.36073: UDP, length 1
That's not good behavior, and it's of course going to cause sub-optimal
performance if we do the RPS fragment cache.
RR bond mode could do something similar, to alleviate this.
I assume it doesn't do this kind of reordering for TCP.
^ permalink raw reply
* Re: [PATCHv3] net: Define enum for the bits used in features.
From: David Miller @ 2011-06-04 20:34 UTC (permalink / raw)
To: maheshb; +Cc: netdev, therbert, mirqus, shemminger
In-Reply-To: <1306363336-13614-1-git-send-email-maheshb@google.com>
From: Mahesh Bandewar <maheshb@google.com>
Date: Wed, 25 May 2011 15:42:16 -0700
> Little bit cleanup by defining enum for all bits used. Also use those enum
> values to redefine flags.
>
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> ---
> Changes since v2:
> (1) Removed the include which was part of the other patch (split mishap).
> (2) Changed the enums to add NETIF_F_ prefix.
I hate to be a pain after you've put so much work into these patches,
but I simply don't like this approach.
I think the abstracted interfaces should come first. You don't need to
change any of the NETIF_F_* defines in order to do that. You should only
need to add the netdev_{set,clear,test}_*() macros.
If you want you can make the "bit" argument be the flag name after the
NETIF_F_ prefix, so "netdev_test_active_feature(dev, SG)"
Then you convert every single access.
Then you make the flags type opaque, which should at that point be a
6 line change at best.
And then you can implement the flags however you want.
^ permalink raw reply
* Re: [RFC] breakage in sysfs_readdir() and s_instances abuse in sysfs
From: Al Viro @ 2011-06-04 22:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric W. Biederman, linux-fsdevel, netdev
In-Reply-To: <BANLkTikChZuG4pOZ_ipDYaEv8VQ8omh-YQ@mail.gmail.com>
On Sun, Jun 05, 2011 at 06:55:12AM +0900, Linus Torvalds wrote:
> On Sun, Jun 5, 2011 at 6:22 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > Are you OK with the sketch above? ?I can probably cook a patch along those
> > lines by tomorrow...
>
> I'm ok with the sketch, but might think otherwise when actually seeing
> the patch. And I wish some namespace person would look at this issue.
> And the networking people would seem to need to be aware of it too,
> but you've only cc'd fsdevel, so they are entirely unaware of the
> whole thread..
Eh... The question had been to Eric, unless that pile is actually yours...
netdev Cc'd, and I'll forward the previous posting there in a few.
FWIW, reproducing that is trivial: on a box with netns enabled:
dizzy:~# unshare -n -- sh -c "mount -t sysfs none /mnt; ls -l /mnt/class/net; ls
-l /mnt/class/net/eth0"
[ 1301.429755] IPv4 FIB: Using LC-trie version 0.409
total 0
lrwxrwxrwx 1 root root 0 Jun 4 18:16 lo -> ../../devices/virtual/net/lo
lrwxrwxrwx 1 root root 0 Jun 4 18:16 sit0 -> ../../devices/virtual/net/sit0
ls: cannot access /mnt/class/net/eth0: No such file or directory
dizzy:~# ls -l /mnt/class/net/; ls -l /mnt/class/net/eth0
total 0
lrwxrwxrwx 1 root root 0 Jun 4 18:17 /mnt/class/net/eth0 -> ../../devices/pci00
00:00/0000:00:09.0/net/eth0
IOW, while netns is alive we get sane behaviour - lookup for class/net/eth0
fails, since there's no such object in that netns. Once it's gone, we get
class/net in that sysfs instance empty on readdir *and* lookup for
class/net/eth0 succeeds giving us an object from another netns.
Apologies for not adding netdev - it started as sysfs-internal race, so the
beginning of that thread went to fsdevel...
^ permalink raw reply
* Re: [RFC] breakage in sysfs_readdir() and s_instances abuse in sysfs
From: Al Viro @ 2011-06-04 22:25 UTC (permalink / raw)
To: netdev; +Cc: Eric W. Biederman, linux-fsdevel, Linus Torvalds
[Forwarded to netdev]
On Sat, Jun 04, 2011 at 01:15:19AM +0100, Al Viro wrote:
> Granted, sysfs_dir_pos() doesn't dereference ns; however, it does compare
> with it. And ns might have been freed and reused by that point.
>
> I don't like what's going on there; that code looks inherently racy.
> We never set ->ns[...] non-NULL outside of mount(). So it looks like
> the intended behaviour is to have all ns-specific entries of that type
> disappear forever from that fs instance. Having entries for _another_
> namespace to show up for a (short) while, and that only in readdir()
> (lookup runs completely under sysfs_mutex, so we don't have that race
> there)...
Eeep... We do not have a *race* in lookup. However, any lookup done
after that ->ns[...] = NULL is going to do the following:
mutex_lock(&sysfs_mutex);
type = sysfs_ns_type(parent_sd);
ns = sysfs_info(dir->i_sb)->ns[type];
/* i.e. ns = NULL */
sd = sysfs_find_dirent(parent_sd, ns, dentry->d_name.name);
which will do rather unpleasant things:
for (sd = parent_sd->s_dir.children; sd; sd = sd->s_sibling) {
if (ns && sd->s_ns && (sd->s_ns != ns))
continue;
if (!strcmp(sd->s_name, name))
return sd;
}
i.e. with ns == NULL it will outright ignore sd->s_ns and look for name
match and nothing else. Any sysfs node with that name will do, whatever
it might have in ->s_ns. E.g. for lookups in /sys/class/net it will find
the first sysfs node of network interface with that name in _some_ namespace.
Back to sysfs_lookup():
/* no such entry */
if (!sd) {
ret = ERR_PTR(-ENOENT);
goto out_unlock;
}
/* attach dentry and inode */
inode = sysfs_get_inode(dir->i_sb, sd);
if (!inode) {
ret = ERR_PTR(-ENOMEM);
goto out_unlock;
}
and if there was an entry from some surviving net_ns with that name,
sysfs_get_inode() will cheerfully allocate an inode for us and associate
it with that sd. Then we complete the lookup and return a shiny positive
dentry to caller...
Just what is that code supposed to do? Somehow I doubt that "after net_ns
is gone, lookups for class/net/name succeed when there is an interface called
name in at least one net_ns; resulting object refers to one of such
interfaces, with no promises regarding which net_ns it is about" is the
intended behaviour here, especially since readdir() called after that
will skip all sysfs nodes with non-NULL ->s_ns, i.e. show empty class/net.
Frankly, my preference would be to kill the void * nonsense, introduce a
structure we'll embed into struct net (and all future tags) containing
refcount and "it is doomed, skip it" flag. Purely passive refs - i.e. all
they guarantee is that memory won't be freed under you. Having *active* refs
(i.e. your current net->count being non-zero) contributes 1 to that counter,
kfree() is done when that counter reaches zero. With info->ns[] contributing
to passive refcount and exit_ns logics tagging the sucker as doomed and leaving
it at that. kill_sb() would drop references, lookup and readdir check if
ns is doomed and skip the entry in that case.
However, it's your code and I don't know in which direction do you plan to take
it. IMO it's badly overdesigned...
Are you OK with the sketch above? I can probably cook a patch along those
lines by tomorrow...
^ permalink raw reply
* [PATCH kernel 3.0-rc1] smc91c92_cs: set smc->base to NULL before iounmap
From: Ken Kawasaki @ 2011-06-04 23:20 UTC (permalink / raw)
To: netdev
In-Reply-To: <20110221000720.e93225c1.ken_kawasaki@spring.nifty.jp>
smc91c92_cs:
set smc->base to NULL before iounmap
to avoid writing to smc->base in smc_interrupt.
Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
---
--- linux-3.0-rc1/drivers/net/pcmcia/smc91c92_cs.c.orig 2011-06-04 19:38:07.000000000 +0900
+++ linux-3.0-rc1/drivers/net/pcmcia/smc91c92_cs.c 2011-06-05 07:59:51.000000000 +0900
@@ -315,6 +315,7 @@ static int smc91c92_probe(struct pcmcia_
smc = netdev_priv(dev);
smc->p_dev = link;
link->priv = dev;
+ smc->base = NULL;
spin_lock_init(&smc->lock);
@@ -954,11 +955,17 @@ config_failed:
static void smc91c92_release(struct pcmcia_device *link)
{
+ struct net_device *dev = link->priv;
+ struct smc_private *smc = netdev_priv(dev);
+
dev_dbg(&link->dev, "smc91c92_release\n");
- if (link->resource[2]->end) {
- struct net_device *dev = link->priv;
- struct smc_private *smc = netdev_priv(dev);
- iounmap(smc->base);
+
+ if (smc->base != NULL) {
+ u_char __iomem *tmp;
+
+ tmp = smc->base;
+ smc->base = NULL; /* set NULL before iounmap */
+ iounmap(tmp);
}
pcmcia_disable_device(link);
}
@@ -1444,7 +1451,7 @@ irq_done:
mask_bits(0x00ff, ioaddr-0x10+OSITECH_RESET_ISR);
set_bits(0x0300, ioaddr-0x10+OSITECH_RESET_ISR);
}
- if (smc->manfid == MANFID_MOTOROLA) {
+ if ((smc->base != NULL) && (smc->manfid == MANFID_MOTOROLA)) {
u_char cor;
cor = readb(smc->base + MOT_UART + CISREG_COR);
writeb(cor & ~COR_IREQ_ENA, smc->base + MOT_UART + CISREG_COR);
^ permalink raw reply
* [PATCH net-next] bonding: make 802.3ad use update lacp_rate (v2)
From: Weiping Pan @ 2011-06-05 3:16 UTC (permalink / raw)
Cc: Weiping Pan, Jay Vosburgh, Andy Gospodarek,
open list:BONDING DRIVER, open list
In-Reply-To: <19046.1307130148@death>
There is a bug that when you modify lacp_rate via sysfs,
802.3ad won't use the new value of lacp_rate to transmit packets.
That is because port->actor_oper_port_state isn't changed.
Change Notes:
v2)
1 Hold read_lock(&bond->lock) when iterate slaves, suggested by Jiri Pirko.
2 Modify actor_oper_port_state via a helper function in bond_3ad.c,
suggested by Jay Vosburgh.
3 Hold slave->state_machine_lock,
so we can modify port->actor_oper_port_state, no matter bond is up or down.
Signed-off-by: Weiping Pan <panweiping3@gmail.com>
---
drivers/net/bonding/bond_3ad.c | 27 +++++++++++++++++++++++++++
drivers/net/bonding/bond_3ad.h | 1 +
drivers/net/bonding/bond_sysfs.c | 1 +
3 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
index c7537abc..5111e0d 100644
--- a/drivers/net/bonding/bond_3ad.c
+++ b/drivers/net/bonding/bond_3ad.c
@@ -2473,3 +2473,30 @@ void bond_3ad_lacpdu_recv(struct sk_buff *skb, struct bonding *bond,
bond_3ad_rx_indication((struct lacpdu *) skb->data, slave, skb->len);
read_unlock(&bond->lock);
}
+
+/*
+ * When modify lacp_rate parameter via sysfs,
+ * update actor_oper_port_state of each port.
+ *
+ * Hold slave->state_machine_lock,
+ * so we can modify port->actor_oper_port_state,
+ * no matter bond is up or down.
+ */
+void bond_3ad_update_lacp_rate(struct bonding *bond)
+{
+ int i;
+ struct slave *slave;
+ struct port *port = NULL;
+
+ read_lock(&bond->lock);
+ bond_for_each_slave(bond, slave, i) {
+ port = &(slave->ad_info.port);
+ __get_state_machine_lock(port);
+ if (bond->params.lacp_fast)
+ port->actor_oper_port_state |= AD_STATE_LACP_TIMEOUT;
+ else
+ port->actor_oper_port_state &= ~AD_STATE_LACP_TIMEOUT;
+ __release_state_machine_lock(port);
+ }
+ read_unlock(&bond->lock);
+}
diff --git a/drivers/net/bonding/bond_3ad.h b/drivers/net/bonding/bond_3ad.h
index 0ee3f16..e466faf 100644
--- a/drivers/net/bonding/bond_3ad.h
+++ b/drivers/net/bonding/bond_3ad.h
@@ -282,5 +282,6 @@ int bond_3ad_xmit_xor(struct sk_buff *skb, struct net_device *dev);
void bond_3ad_lacpdu_recv(struct sk_buff *skb, struct bonding *bond,
struct slave *slave);
int bond_3ad_set_carrier(struct bonding *bond);
+void bond_3ad_update_lacp_rate(struct bonding *bond);
#endif //__BOND_3AD_H__
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 88fcb25..03d1196 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -804,6 +804,7 @@ static ssize_t bonding_store_lacp(struct device *d,
if ((new_value == 1) || (new_value == 0)) {
bond->params.lacp_fast = new_value;
+ bond_3ad_update_lacp_rate(bond);
pr_info("%s: Setting LACP rate to %s (%d).\n",
bond->dev->name, bond_lacp_tbl[new_value].modename,
new_value);
--
1.7.4
^ permalink raw reply related
* Re: ETH over USB: NFS state (seeking ARM platform for NFS-based builds)
From: Ming Lei @ 2011-06-05 5:13 UTC (permalink / raw)
To: Karel Gardas; +Cc: linux-kernel, linux-usb, Network Development
In-Reply-To: <4DEA5D78.5030402@centrum.cz>
Hi,
2011/6/5 Karel Gardas <karel.gardas@centrum.cz>:
> Hello,
>
> while searching for ARMv7/NEON platform for my own hacking I've found this
> interesting issue:
>
> [ 2945.114135] cc1: page allocation failure. order:3, mode:0x4020
Maybe the patch below can fix the issue, please try it:
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 9ab439d..f16e448 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -324,12 +324,20 @@ static int rx_submit (struct usbnet *dev, struct
urb *urb, gfp_t flags)
unsigned long lockflags;
size_t size = dev->rx_urb_size;
- if ((skb = alloc_skb (size + NET_IP_ALIGN, flags)) == NULL) {
- netif_dbg(dev, rx_err, dev->net, "no rx skb\n");
+ if (atomic_read(&dev->rx_skb_on_fly) > MAX_RX_SKB_ON_FLY &&
+ flags == GFP_ATOMIC) {
+ netif_dbg(dev, rx_err, dev->net, "too many rx skbs on the fly\n");
+fail_rx_memory:
usbnet_defer_kevent (dev, EVENT_RX_MEMORY);
usb_free_urb (urb);
return -ENOMEM;
}
+
+ if ((skb = alloc_skb (size + NET_IP_ALIGN, flags)) == NULL) {
+ netif_dbg(dev, rx_err, dev->net, "no rx skb\n");
+ goto fail_rx_memory;
+ }
+ atomic_inc(&dev->rx_skb_on_fly);
skb_reserve (skb, NET_IP_ALIGN);
entry = (struct skb_data *) skb->cb;
@@ -375,6 +383,7 @@ static int rx_submit (struct usbnet *dev, struct
urb *urb, gfp_t flags)
}
spin_unlock_irqrestore (&dev->rxq.lock, lockflags);
if (retval) {
+ atomic_dec(&dev->rx_skb_on_fly);
dev_kfree_skb_any (skb);
usb_free_urb (urb);
}
@@ -1177,8 +1186,9 @@ static void usbnet_bh (unsigned long param)
entry->state = rx_cleanup;
rx_process (dev, skb);
continue;
- case tx_done:
case rx_cleanup:
+ atomic_dec(&dev->rx_skb_on_fly);
+ case tx_done:
usb_free_urb (entry->urb);
dev_kfree_skb (skb);
continue;
diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
index 605b0aa..1dace0d 100644
--- a/include/linux/usb/usbnet.h
+++ b/include/linux/usb/usbnet.h
@@ -33,6 +33,8 @@ struct usbnet {
wait_queue_head_t *wait;
struct mutex phy_mutex;
unsigned char suspend_count;
+ atomic_t rx_skb_on_fly;
+# define MAX_RX_SKB_ON_FLY 2048
/* i/o info: pipes etc */
unsigned in, out;
thanks,
--
Ming Lei
^ permalink raw reply related
* Re: KVM induced panic on 2.6.38[2367] & 2.6.39
From: Avi Kivity @ 2011-06-05 8:14 UTC (permalink / raw)
To: Brad Campbell
Cc: CaT, Hugh Dickins, Andrea Arcangeli, Borislav Petkov,
linux-kernel, kvm, linux-mm, netdev
In-Reply-To: <4DE8E3ED.7080004@fnarfbargle.com>
On 06/03/2011 04:38 PM, Brad Campbell wrote:
>
> Is there anyone who can point me at the appropriate cage to rattle? I
> know it appears to be a netfilter issue, but I don't seem to be able
> to get a message to the list (and I am subscribed to it and have been
> getting mail for months) and I'm not sure who to pester. The other
> alternative is I just stop doing "that" and wait for it to bite
> someone else.
The mailing list might be set not to send your own mails back to you.
Check the list archive.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth
From: Petr Štetiar @ 2011-06-05 8:34 UTC (permalink / raw)
To: Mika Westerberg; +Cc: netdev, ryan, kernel, linux-arm-kernel, hsweeten
In-Reply-To: <f20d8fe52f823e7e65423720c53f2935d3e08967.1307040443.git.mika.westerberg@iki.fi>
Mika Westerberg <mika.westerberg@iki.fi> [2011-06-02 21:59:34]:
> As the driver is now passing platform device to the DMA mapping functions,
> we should give it valid DMA masks.
Hi Mika,
do you have the series available somewhere for pull? I would like to test the
changes for you on my ts7250/ts7300, but I'm quite lazy and would like to just
cherry-pick the changes if possible :-)
I also wonder, why this patch[1] from Herbert Valerio Riedel has never made it
upstream, this email[2] is the last trace of the patch I could find. Looks
like Herbert did few fixes to the driver and thanks to Matthieu, I'm using
this forward ported patch[3] since today, without any problems.
Do you personaly use the ethernet on the ep93xx/ts72xx heavily?
1. http://ynezz.ibawizard.net/ts72xx/linux-kernel/2.6.24.y/ep93xx-eth-phylib-framework.patch
2. http://www.mail-archive.com/netdev@vger.kernel.org/msg62550.html
3. https://github.com/ynezz/linux-2.6/commit/1dcf7aeb7ca4d7e441be2467926b606b46060a44
-- ynezz
^ permalink raw reply
* Re: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth
From: Mika Westerberg @ 2011-06-05 8:59 UTC (permalink / raw)
To: Petr Štetiar; +Cc: netdev, hsweeten, ryan, kernel, linux-arm-kernel, davem
In-Reply-To: <20110605083445.GT16318@ibawizard.net>
On Sun, Jun 05, 2011 at 10:34:45AM +0200, Petr Štetiar wrote:
>
> do you have the series available somewhere for pull? I would like to test the
> changes for you on my ts7250/ts7300, but I'm quite lazy and would like to just
> cherry-pick the changes if possible :-)
Unfortunately - no. But what's wrong with 'git am <mbox>'? ;-)
> I also wonder, why this patch[1] from Herbert Valerio Riedel has never made it
> upstream, this email[2] is the last trace of the patch I could find. Looks
> like Herbert did few fixes to the driver and thanks to Matthieu, I'm using
> this forward ported patch[3] since today, without any problems.
I have no idea.
It looks like David Miller (CC'd) has been taking care of ep93xx_eth.c maybe
he knows this better.
> Do you personaly use the ethernet on the ep93xx/ts72xx heavily?
Yes, I have NFS roots for the boards so it is essential for me.
^ permalink raw reply
* Re: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth
From: Petr Štetiar @ 2011-06-05 9:10 UTC (permalink / raw)
To: Mika Westerberg
Cc: Petr Štetiar, netdev, hsweeten, ryan, kernel,
linux-arm-kernel, davem
In-Reply-To: <20110605085948.GB16018@acer>
Mika Westerberg <mika.westerberg@iki.fi> [2011-06-05 11:59:48]:
> Unfortunately - no. But what's wrong with 'git am <mbox>'? ;-)
Nothing, it's just complicated if you don't read emails on the same machine as
you develop on. Just found patchwork thread, so it's solved[1]. Thanks.
1. https://patchwork.kernel.org/project/linux-arm-kernel/list/
-- ynezz
^ permalink raw reply
* [PATCH] get_net_ns_by_fd() oopses if proc_ns_fget() returns an error
From: Al Viro @ 2011-06-05 10:37 UTC (permalink / raw)
To: netdev; +Cc: Eric W. Biederman, linux-fsdevel, Linus Torvalds
In-Reply-To: <20110604222531.GA11521@ZenIV.linux.org.uk>
BTW, looking through the code related to struct net lifetime rules has
caught something else:
struct net *get_net_ns_by_fd(int fd)
{
...
file = proc_ns_fget(fd);
if (!file)
goto out;
ei = PROC_I(file->f_dentry->d_inode);
while in proc_ns_fget() we have two return ERR_PTR(...) and not a single
path that would return NULL. The other caller of proc_ns_fget() treats
ERR_PTR() correctly...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
[I don't know which tree should that go through; I'm throwing that into vfs-2.6
#for-linus, but if networking folks prefer that to go through their tree...]
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 6c6b86d..e41e511 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -310,19 +310,17 @@ struct net *get_net_ns_by_fd(int fd)
struct file *file;
struct net *net;
- net = ERR_PTR(-EINVAL);
file = proc_ns_fget(fd);
- if (!file)
- goto out;
+ if (IS_ERR(file))
+ return ERR_CAST(file);
ei = PROC_I(file->f_dentry->d_inode);
- if (ei->ns_ops != &netns_operations)
- goto out;
+ if (ei->ns_ops == &netns_operations)
+ net = get_net(ei->ns);
+ else
+ net = ERR_PTR(-EINVAL);
- net = get_net(ei->ns);
-out:
- if (file)
- fput(file);
+ fput(file);
return net;
}
^ permalink raw reply related
* [PATCH] fix return values of l2tp_dfs_seq_open()
From: Al Viro @ 2011-06-05 10:54 UTC (permalink / raw)
To: netdev; +Cc: James Chapman
In-Reply-To: <20110605103735.GB11521@ZenIV.linux.org.uk>
More fallout from struct net lifetime rules review: PTR_ERR() is *already*
negative and failing ->open() should return negatives on failure.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
diff --git a/net/l2tp/l2tp_debugfs.c b/net/l2tp/l2tp_debugfs.c
index b8dbae8..7613013 100644
--- a/net/l2tp/l2tp_debugfs.c
+++ b/net/l2tp/l2tp_debugfs.c
@@ -258,7 +258,7 @@ static int l2tp_dfs_seq_open(struct inode *inode, struct file *file)
*/
pd->net = get_net_ns_by_pid(current->pid);
if (IS_ERR(pd->net)) {
- rc = -PTR_ERR(pd->net);
+ rc = PTR_ERR(pd->net);
goto err_free_pd;
}
^ permalink raw reply related
* Re: [PATCH] fix return values of l2tp_dfs_seq_open()
From: James Chapman @ 2011-06-05 11:05 UTC (permalink / raw)
To: Al Viro; +Cc: netdev
In-Reply-To: <20110605105403.GC11521@ZenIV.linux.org.uk>
On 05/06/2011 11:54, Al Viro wrote:
> More fallout from struct net lifetime rules review: PTR_ERR() is *already*
> negative and failing ->open() should return negatives on failure.
>
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> ---
> diff --git a/net/l2tp/l2tp_debugfs.c b/net/l2tp/l2tp_debugfs.c
> index b8dbae8..7613013 100644
> --- a/net/l2tp/l2tp_debugfs.c
> +++ b/net/l2tp/l2tp_debugfs.c
> @@ -258,7 +258,7 @@ static int l2tp_dfs_seq_open(struct inode *inode, struct file *file)
> */
> pd->net = get_net_ns_by_pid(current->pid);
> if (IS_ERR(pd->net)) {
> - rc = -PTR_ERR(pd->net);
> + rc = PTR_ERR(pd->net);
> goto err_free_pd;
> }
>
Whoops. Thanks Al.
Signed-off-by: James Chapman <jchapman@katalix.com>
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* Re: KVM induced panic on 2.6.38[2367] & 2.6.39
From: Brad Campbell @ 2011-06-05 13:45 UTC (permalink / raw)
To: Avi Kivity
Cc: CaT, Hugh Dickins, Andrea Arcangeli, Borislav Petkov,
linux-kernel, kvm, linux-mm, netdev
In-Reply-To: <4DEB3AE4.8040700@redhat.com>
On 05/06/11 16:14, Avi Kivity wrote:
> On 06/03/2011 04:38 PM, Brad Campbell wrote:
>>
>> Is there anyone who can point me at the appropriate cage to rattle? I
>> know it appears to be a netfilter issue, but I don't seem to be able
>> to get a message to the list (and I am subscribed to it and have been
>> getting mail for months) and I'm not sure who to pester. The other
>> alternative is I just stop doing "that" and wait for it to bite
>> someone else.
>
> The mailing list might be set not to send your own mails back to you.
> Check the list archive.
Yep, I did that first..
Given the response to previous issues along the same line, it looks a
bit like I just remember not to actually use the system in the way that
triggers the bug and be happy that 99% of the time the kernel does not
panic, but have that lovely feeling in the back of the skull that says
"any time now, and without obvious reason the whole machine might just
come crashing down"..
I guess it's still better than running Xen or Windows..
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: KVM induced panic on 2.6.38[2367] & 2.6.39
From: Avi Kivity @ 2011-06-05 13:58 UTC (permalink / raw)
To: Brad Campbell
Cc: CaT, Hugh Dickins, Andrea Arcangeli, Borislav Petkov,
linux-kernel, kvm, linux-mm, netdev, netfilter-devel
In-Reply-To: <4DEB8872.2060801@fnarfbargle.com>
On 06/05/2011 04:45 PM, Brad Campbell wrote:
>> The mailing list might be set not to send your own mails back to you.
>> Check the list archive.
>
>
> Yep, I did that first..
>
> Given the response to previous issues along the same line, it looks a
> bit like I just remember not to actually use the system in the way
> that triggers the bug and be happy that 99% of the time the kernel
> does not panic, but have that lovely feeling in the back of the skull
> that says "any time now, and without obvious reason the whole machine
> might just come crashing down"..
>
> I guess it's still better than running Xen or Windows..
Not at all. Can some networking/netfilter expert look at this?
Please file a bug with all the relevant information in this thread. If
you can look for a previous version that worked, that might increase the
chances of the bug being resolved faster.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: iwlagn: Random "Time out reading EEPROM".
From: wwguy @ 2011-06-05 14:31 UTC (permalink / raw)
To: Nicolas de Pesloüan; +Cc: netdev@vger.kernel.org, wireless
In-Reply-To: <4DEA2FC1.2030104@gmail.com>
On Sat, 2011-06-04 at 06:14 -0700, Nicolas de Pesloüan wrote:
> Hi,
>
> From time to time, my Intel Wifi adapter fail on cold boot, with the following in dmesg:
>
> [ 7.442634] iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27ks
> [ 7.442636] iwlagn: Copyright(c) 2003-2009 Intel Corporation
> [ 7.442701] iwlagn 0000:05:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> [ 7.442708] iwlagn 0000:05:00.0: setting latency timer to 64
> [ 7.442788] iwlagn 0000:05:00.0: Detected Intel Wireless WiFi Link 5100AGN REV=0x54
> [ 7.455547] iwlagn 0000:05:00.0: Time out reading EEPROM[0]
> [ 7.455611] iwlagn 0000:05:00.0: Unable to init EEPROM
> [ 7.455678] iwlagn 0000:05:00.0: PCI INT A disabled
> [ 7.455685] iwlagn: probe of 0000:05:00.0 failed with error -110
>
> After "modprobe -r iwlagn ; modprobe iwlagn" or after a reboot, everything work fine:
>
> [ 346.332166] iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27ks
> [ 346.332169] iwlagn: Copyright(c) 2003-2009 Intel Corporation
> [ 346.332225] iwlagn 0000:05:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> [ 346.332234] iwlagn 0000:05:00.0: setting latency timer to 64
> [ 346.332277] iwlagn 0000:05:00.0: Detected Intel Wireless WiFi Link 5100AGN REV=0x54
> [ 346.365739] iwlagn 0000:05:00.0: Tunable channels: 13 802.11bg, 24 802.11a channels
> [ 346.365787] alloc irq_desc for 33 on node -1
> [ 346.365788] alloc kstat_irqs on node -1
> [ 346.365804] iwlagn 0000:05:00.0: irq 33 for MSI/MSI-X
> [ 346.449989] phy0: Selected rate control algorithm 'iwl-agn-rs'
>
> This happens using 2.6.32-5 from Debian. I didn't had the opportunity to reproduce it using recent
> kernel, but it occurs too rarely to conclude anything.
>
> I had a look at the git log, without finding something that seems related to this problem. Does this
> ring a bell for someone?
>
> Nicolas.
>
> 05:00.0 Network controller: Intel Corporation WiFi Link 5100
> Subsystem: Intel Corporation WiFi Link 5100 AGN
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR-
> FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR-
> <PERR- INTx-
> Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 33
> Region 0: Memory at d6d00000 (64-bit, non-prefetchable) [size=8K]
> Capabilities: [c8] Power Management version 3
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Address: 00000000fee0300c Data: 41c9
> Capabilities: [e0] Express (v1) Endpoint, MSI 00
> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 unlimited
> ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
> MaxPayload 128 bytes, MaxReadReq 128 bytes
> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <128ns, L1 <32us
> ClockPM+ Surprise- LLActRep- BwNot-
> LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
> Capabilities: [100 v1] Advanced Error Reporting
> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC-
> UnsupReq- ACSViol-
> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC-
> UnsupReq- ACSViol-
> UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC-
> UnsupReq- ACSViol-
> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
> AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
> Capabilities: [140 v1] Device Serial Number 00-22-fb-ff-ff-28-46-c8
> Kernel driver in use: iwlagn
>
no sure, you are the ONLY one report this issue, since the device works
after you reload the module, the HW/SW is ok. maybe the timing/sequence
have problem on the kernel you are using on your system. The bus is not
ready when you boot the system and access the EEPROM.
What model of the laptop you have? could you try to upgrade to newer
kernel?
Wey
^ permalink raw reply
* 3.0.0-rc1: dmesg shows 'wlan%d' instead of 'wlan0'
From: Sergei Trofimovich @ 2011-06-05 17:10 UTC (permalink / raw)
To: linux-wireless; +Cc: netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]
Recently I've noticed small discrepancy in dmesg:
$ { zcat messages.2.gz messages.1.gz; cat messages; } | egrep "(deauthen|Linux version)"
...
May 21 22:01:31 sf kernel: [ 0.000000] Linux version 2.6.39-00004-g29c77fa (slyfox@sf) (gcc version 4.4.5 (Gentoo 4.4.5 p1.2, pie-0.4.5) ) #116 SMP PREEMPT Thu May 19 22:46:16 EEST 2011
May 24 05:37:54 sf kernel: [81845.885094] wlan0: deauthenticated from ...
Jun 1 22:38:38 sf kernel: [ 0.000000] Linux version 3.0.0-rc1-00035-g79f3f61 (slyfox@sf) (gcc version 4.4.5 (Gentoo 4.4.5 p1.2, pie-0.4.5) ) #118 SMP PREEMPT Wed Jun 1 22:14:46 EEST 2011
Jun 1 23:41:23 sf kernel: [ 3877.773727] wlan%d: deauthenticating from ...
Jun 1 23:42:16 sf kernel: [ 0.000000] Linux version 3.0.0-rc1-00035-g79f3f61-dirty (slyfox@sf) (gcc version 4.4.5 (Gentoo 4.4.5 p1.2, pie-0.4.5) ) #119 SMP PREEMPT Wed Jun 1 23:35:43 EEST 2011
Jun 2 07:35:10 sf kernel: [ 5972.879970] wlan%d: deauthenticated from ...
Here we see 'wlan0' -> 'wlan%d' switch. I presume those lines go from firmware
(and not from userspace).
The card is an iwl4965
10:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection (rev 61)
--
Sergei
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: software iwarp stack update
From: Bernard Metzler @ 2011-06-05 17:39 UTC (permalink / raw)
To: Bart Van Assche
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <BANLkTikUWpf4iAQT-9DwL_qSCEcY7CPN6w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Bart,
many thanks for polling. About nine months ago we sent an initial
'softiwarp' patch to netdev and linux-rdma. We got encouraging
feedback including very helpful advice on how to improve that code.
I think we fixed all issues which were detected by the community
but somehow missed the point to feed back the code. Sorry about that.
Due to pressure from other projects softiwarp went a little
down on my priority list. But its immediately back when you are asking ;)
What we currently have is a stack which - due to requirements
from other projects - evolved further to now include also
some kernel client support (tested with NFSv4). We also fixed
issues in the connection management code path, which improved
stability. We also added some siw object statistics for debugging.
As mentioned, while keeping gitorious.org/softiwarp up to date
(it includes the latest changes) we missed to come back to the
list. I will now resume working on that, dedicating some more
of my time to it. Let me rebase the code with the current kernel
and send a new patch list later next week.
Many thanks, and sorry for the long-lasting silence,
Bernard.
linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org wrote on 06/04/2011 08:01:45 PM:
> Bart Van Assche <bvanassche-HInyCGIudOg@public.gmane.org>
> Sent by: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>
> 06/04/2011 08:02 PM
>
> To
>
> Bernard Metzler <BMT-OA+xvbQnYDHMbYB6QlFGEg@public.gmane.org>
>
> cc
>
> linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>
> Subject
>
> Re: software iwarp stack update
>
> On Wed, Sep 22, 2010 at 10:19 AM, Bernard Metzler <BMT-OA+xvbQnYDHMbYB6QlFGEg@public.gmane.org>
wrote:
> > Earlier this year, we announced the availability of an open source,
> > full software implementation of the iWARP RDMA protocol stack - see
> > my email "software iwarp stack" from March 14th at the linux-rdma list
> > (http://www.mail-archive.com/linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg02940.html)
> > While since then working on performance and stability, we provided
> > some source code updates. Current user and kernel code is available at
> > gitorious.org/softiwarp. Please see the CHANGES file in the
> > kernel/ directory for a summary of the most recent changes.
>
> (replying to an e-mail of about nine months ago)
>
> Hello Bernard,
>
> It has been pretty quiet recently around the "siw" driver. Have you
> had the chance to make any progress recently on this driver ?
>
> Thanks,
>
> Bart.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ethtool: Add support for 20G link speed
From: Yaniv Rosner @ 2011-06-05 17:39 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, eilong
Hi Ben,
I'm resubmitting the addition of 20G with your corrections to ethtool.
Thanks,
Yaniv
Signed-off-by: Yaniv Rosner <yanivr@broadcom.com>
---
ethtool.8.in | 2 ++
ethtool.c | 18 +++++++++++++++++-
2 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/ethtool.8.in b/ethtool.8.in
index 7b1cdf5..2983b3e 100644
--- a/ethtool.8.in
+++ b/ethtool.8.in
@@ -499,6 +499,8 @@ lB l lB.
0x020 1000 Full
0x8000 2500 Full (not supported by IEEE standards)
0x1000 10000 Full
+0x20000 20000MLD2 Full (not supported by IEEE standards)
+0x40000 20000KR2 Full (not supported by IEEE standards)
.TE
.TP
.BI phyad \ N
diff --git a/ethtool.c b/ethtool.c
index c189c78..35c3733 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -1244,6 +1244,20 @@ dump_link_caps(const char *prefix, const char *an_prefix, u32 mask)
if (mask & ADVERTISED_10000baseT_Full) {
did1++; fprintf(stdout, "10000baseT/Full ");
}
+ if (did1 && (mask & ADVERTISED_20000baseMLD2_Full)) {
+ fprintf(stdout, "\n");
+ fprintf(stdout, " %*s", indent, "");
+ }
+ if (mask & ADVERTISED_20000baseMLD2_Full) {
+ did1++; fprintf(stdout, "20000baseMLD2/Full ");
+ }
+ if (did1 && (mask & ADVERTISED_20000baseKR2_Full)) {
+ fprintf(stdout, "\n");
+ fprintf(stdout, " %*s", indent, "");
+ }
+ if (mask & ADVERTISED_20000baseKR2_Full) {
+ did1++; fprintf(stdout, "20000baseKR2/Full ");
+ }
if (did1 == 0)
fprintf(stdout, "Not reported");
fprintf(stdout, "\n");
@@ -2474,7 +2488,9 @@ static int do_sset(int fd, struct ifreq *ifr)
ADVERTISED_1000baseT_Half |
ADVERTISED_1000baseT_Full |
ADVERTISED_2500baseX_Full |
- ADVERTISED_10000baseT_Full);
+ ADVERTISED_10000baseT_Full |
+ ADVERTISED_20000baseMLD2_Full |
+ ADVERTISED_20000baseKR2_Full);
} else if (advertising_wanted > 0) {
ecmd.advertising = advertising_wanted;
}
--
1.7.1
^ permalink raw reply related
* [PATCH] ep93xx-eth: convert to phylib
From: Florian Fainelli @ 2011-06-05 17:57 UTC (permalink / raw)
To: netdev, Lennert Buytenhek, Mika Westerberg, hsweeten, ryan,
linux-arm-kernel
ep93xx-eth lacked support for monitoring link status changes, with this
patch, link changes are now watched and reported correctly.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
diff --git a/drivers/net/arm/Kconfig b/drivers/net/arm/Kconfig
index 39e1c0d..53d075e 100644
--- a/drivers/net/arm/Kconfig
+++ b/drivers/net/arm/Kconfig
@@ -51,7 +51,7 @@ config ARM_KS8695_ETHER
config EP93XX_ETH
tristate "EP93xx Ethernet support"
depends on ARM && ARCH_EP93XX
- select MII
+ select PHYLIB
help
This is a driver for the ethernet hardware included in EP93xx CPUs.
Say Y if you are building a kernel for EP93xx based devices.
diff --git a/drivers/net/arm/ep93xx_eth.c b/drivers/net/arm/ep93xx_eth.c
index 5a77001..4669b6c 100644
--- a/drivers/net/arm/ep93xx_eth.c
+++ b/drivers/net/arm/ep93xx_eth.c
@@ -24,6 +24,7 @@
#include <linux/delay.h>
#include <linux/io.h>
#include <linux/slab.h>
+#include <linux/phy.h>
#include <mach/hardware.h>
@@ -175,7 +176,11 @@ struct ep93xx_priv
struct net_device *dev;
struct napi_struct napi;
- struct mii_if_info mii;
+ struct mii_bus *mii_bus;
+ struct phy_device *phydev;
+ int old_link;
+ int old_duplex;
+ unsigned int phy_addr;
u8 mdc_divisor;
};
@@ -186,8 +191,9 @@ struct ep93xx_priv
#define wrw(ep, off, val) __raw_writew((val), (ep)->base_addr + (off))
#define wrl(ep, off, val) __raw_writel((val), (ep)->base_addr + (off))
-static int ep93xx_mdio_read(struct net_device *dev, int phy_id, int reg)
+static int ep93xx_mdiobus_read(struct mii_bus *bus, int phy_id, int reg)
{
+ struct net_device *dev = bus->priv;
struct ep93xx_priv *ep = netdev_priv(dev);
int data;
int i;
@@ -210,8 +216,9 @@ static int ep93xx_mdio_read(struct net_device *dev, int phy_id, int reg)
return data;
}
-static void ep93xx_mdio_write(struct net_device *dev, int phy_id, int reg, int data)
+static int ep93xx_mdiobus_write(struct mii_bus *bus, int phy_id, int reg, u16 data)
{
+ struct net_device *dev = bus->priv;
struct ep93xx_priv *ep = netdev_priv(dev);
int i;
@@ -224,8 +231,84 @@ static void ep93xx_mdio_write(struct net_device *dev, int phy_id, int reg, int d
msleep(1);
}
- if (i == 10)
+ if (i == 10) {
pr_info("mdio write timed out\n");
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+
+static int ep93xx_mdiobus_reset(struct mii_bus *bus)
+{
+ return 0;
+}
+
+static void ep93xx_adjust_link(struct net_device *dev)
+{
+ struct ep93xx_priv * ep = netdev_priv(dev);
+ struct phy_device *phydev = ep->phydev;
+ int status_changed = 0;
+
+ BUG_ON(!phydev);
+
+ if (ep->old_link != phydev->link) {
+ status_changed = 1;
+ ep->old_link = phydev->link;
+ }
+
+ if (phydev->link && (ep->old_duplex != phydev->duplex)) {
+ status_changed = 1;
+ ep->old_duplex = phydev->duplex;
+ }
+
+ if (status_changed) {
+ pr_info("%s: link %s", dev->name, phydev->link ?
+ "UP" : "DOWN");
+ if (phydev->link)
+ pr_cont(" - %d/%s", phydev->speed,
+ DUPLEX_FULL == phydev->duplex ? "full" : "half");
+ pr_cont("\n");
+ }
+}
+
+static int ep93xx_mii_probe(struct net_device *dev)
+{
+ struct ep93xx_priv * ep = netdev_priv(dev);
+ struct phy_device *phydev = NULL;
+
+ /* use platform supplied PHY address if valid */
+ if (ep->phy_addr)
+ phydev = ep->mii_bus->phy_map[ep->phy_addr];
+ else
+ phydev = phy_find_first(ep->mii_bus);
+
+ if (!phydev) {
+ pr_err("no PHY found\n");
+ return -ENODEV;
+ }
+
+ phydev = phy_connect(dev, dev_name(&phydev->dev), &ep93xx_adjust_link,
+ 0, PHY_INTERFACE_MODE_MII);
+ if (IS_ERR(phydev)) {
+ pr_err("could not attach to PHY\n");
+ return PTR_ERR(phydev);
+ }
+
+ /* mask with MAC supported features */
+ phydev->supported &= PHY_BASIC_FEATURES;
+ phydev->advertising = phydev->supported;
+ ep->phydev = phydev;
+ ep->old_link = 0;
+ ep->old_duplex = -1;
+
+ pr_info("attached PHY driver [%s] "
+ "(mii_bus:phy_addr=%s)\n",
+ phydev->drv->name, dev_name(&phydev->dev));
+
+ phy_start(phydev);
+
+ return 0;
}
static int ep93xx_rx(struct net_device *dev, int processed, int budget)
@@ -570,7 +653,7 @@ static int ep93xx_start_hw(struct net_device *dev)
wrl(ep, REG_SELFCTL, ((ep->mdc_divisor - 1) << 9));
/* Does the PHY support preamble suppress? */
- if ((ep93xx_mdio_read(dev, ep->mii.phy_id, MII_BMSR) & 0x0040) != 0)
+ if ((ep93xx_mdiobus_read(ep->mii_bus, ep->phy_addr, MII_BMSR) & 0x0040) != 0)
wrl(ep, REG_SELFCTL, ((ep->mdc_divisor - 1) << 9) | (1 << 8));
/* Receive descriptor ring. */
@@ -703,9 +786,11 @@ static int ep93xx_close(struct net_device *dev)
static int ep93xx_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
{
struct ep93xx_priv *ep = netdev_priv(dev);
- struct mii_ioctl_data *data = if_mii(ifr);
- return generic_mii_ioctl(&ep->mii, data, cmd, NULL);
+ if (!ep->phydev)
+ return -ENODEV;
+
+ return phy_mii_ioctl(ep->phydev, ifr, cmd);
}
static void ep93xx_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info)
@@ -717,25 +802,19 @@ static void ep93xx_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *i
static int ep93xx_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
{
struct ep93xx_priv *ep = netdev_priv(dev);
- return mii_ethtool_gset(&ep->mii, cmd);
+ return phy_ethtool_gset(ep->phydev, cmd);
}
static int ep93xx_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
{
struct ep93xx_priv *ep = netdev_priv(dev);
- return mii_ethtool_sset(&ep->mii, cmd);
+ return phy_ethtool_sset(ep->phydev, cmd);
}
static int ep93xx_nway_reset(struct net_device *dev)
{
struct ep93xx_priv *ep = netdev_priv(dev);
- return mii_nway_restart(&ep->mii);
-}
-
-static u32 ep93xx_get_link(struct net_device *dev)
-{
- struct ep93xx_priv *ep = netdev_priv(dev);
- return mii_link_ok(&ep->mii);
+ return phy_start_aneg(ep->phydev);
}
static const struct ethtool_ops ep93xx_ethtool_ops = {
@@ -743,7 +822,7 @@ static const struct ethtool_ops ep93xx_ethtool_ops = {
.get_settings = ep93xx_get_settings,
.set_settings = ep93xx_set_settings,
.nway_reset = ep93xx_nway_reset,
- .get_link = ep93xx_get_link,
+ .get_link = ethtool_op_get_link,
};
static const struct net_device_ops ep93xx_netdev_ops = {
@@ -789,6 +868,11 @@ static int ep93xx_eth_remove(struct platform_device *pdev)
/* @@@ Force down. */
unregister_netdev(dev);
+
+ mdiobus_unregister(ep->mii_bus);
+ kfree(ep->mii_bus->irq);
+ mdiobus_free(ep->mii_bus);
+
ep93xx_free_buffers(ep);
if (ep->base_addr != NULL)
@@ -811,7 +895,8 @@ static int ep93xx_eth_probe(struct platform_device *pdev)
struct ep93xx_priv *ep;
struct resource *mem;
int irq;
- int err;
+ int err = 0;
+ int i;
if (pdev == NULL)
return -ENODEV;
@@ -849,13 +934,41 @@ static int ep93xx_eth_probe(struct platform_device *pdev)
}
ep->irq = irq;
- ep->mii.phy_id = data->phy_id;
- ep->mii.phy_id_mask = 0x1f;
- ep->mii.reg_num_mask = 0x1f;
- ep->mii.dev = dev;
- ep->mii.mdio_read = ep93xx_mdio_read;
- ep->mii.mdio_write = ep93xx_mdio_write;
+ ep->mii_bus = mdiobus_alloc();
+ if (!ep->mii_bus) {
+ dev_err(&pdev->dev, "Failed to allocate mdiobus\n");
+ goto err_out;
+ }
+
+ ep->phy_addr = data->phy_id;
+ ep->mii_bus->priv = dev;
+ ep->mii_bus->read = ep93xx_mdiobus_read;
+ ep->mii_bus->write = ep93xx_mdiobus_write;
+ ep->mii_bus->reset = ep93xx_mdiobus_reset;
+ ep->mii_bus->name = "ep93xx_eth_mii";
ep->mdc_divisor = 40; /* Max HCLK 100 MHz, min MDIO clk 2.5 MHz. */
+ snprintf(ep->mii_bus->id, MII_BUS_ID_SIZE, "%x",
+ (pdev->id != -1) ? pdev->id : 0);
+ ep->mii_bus->irq = kmalloc(sizeof(int) * PHY_MAX_ADDR, GFP_KERNEL);
+ if (!ep->mii_bus->irq) {
+ dev_err(&pdev->dev, "mii_bus irq allocation failed\n");
+ goto err_out;
+ }
+
+ for (i = 0; i < PHY_MAX_ADDR; i++)
+ ep->mii_bus->irq[i] = PHY_POLL;
+
+ err = mdiobus_register(ep->mii_bus);
+ if (err) {
+ dev_err(&pdev->dev, "Failed to register MII bus\n");
+ goto err_out;
+ }
+
+ err = ep93xx_mii_probe(dev);
+ if (err) {
+ dev_err(&pdev->dev, "failed to probe MII bus\n");
+ goto err_out;
+ }
if (is_zero_ether_addr(dev->dev_addr))
random_ether_addr(dev->dev_addr);
--
1.7.4.1
^ permalink raw reply related
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