* Re: TCP sockets stalling - help! (long)
From: Frederic Leroy @ 2009-11-27 20:53 UTC (permalink / raw)
To: Asdo; +Cc: netdev, e1000-devel, Ilpo Järvinen
In-Reply-To: <4B0FCC6D.3050003@shiftmail.org>
Le Fri, 27 Nov 2009 13:56:13 +0100,
Asdo <asdo@shiftmail.org> a écrit :
> Frederic Leroy wrote:
> > Le Wed, 25 Nov 2009 05:25:28 +0100,
> > Asdo <asdo@shiftmail.org> a écrit :
> >
> >
> >> Hi netdev and e1000 people,
> >>
> >> I have a weird problem here.
> >> [...]
> > I have the same kind of problem at home. I can't copy big files over
> > [...]
> Good God it's true then!
Yes :)
> Still if I am right, with Netcat you might end up with a corrupted
> file on the other side (shorter). Or maybe not, depending on how
> exactly the bug is made. Could you check this? Filesize and md5sum.
md5sum are ok.
I can't reproduce the problem on wire with a switch ( using both
10 and 100Mbp FD )
> Do you have Intel network card, with e1000e driver on SG? (see lsmod)
> (sorry I was wrong before, it's e1000e in my case not e1000)
> Otherwise it's probably the TCP layer...
Sorry, I forgot to precise the network hardware.
I forgot a noname 100Mbp switch between the isv box and sg host.
SG:
00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
using module 8139cp
Devel:
02:02.0 Network controller: Broadcom Corporation BCM4306 802.11b/g
Wireless LAN Controller (rev 03)
using b43 driver.
02:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VE (MOB)
Ethernet Controller (rev 81)
using e100 in kernel ( no module )
My isv box is broadcom based, but I don't know which chipset for
wireless.
Since our hardware are different, I don't think it's coming from
hardware driver. I'm preparing traces for Ilpo
--
Frédéric Leroy
^ permalink raw reply
* Re: TCP sockets stalling - help! (long)
From: Ilpo Järvinen @ 2009-11-27 21:00 UTC (permalink / raw)
To: Frederic Leroy; +Cc: Asdo, Netdev, e1000-devel
In-Reply-To: <20091127215324.5f494a86@houba>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1910 bytes --]
On Fri, 27 Nov 2009, Frederic Leroy wrote:
> Le Fri, 27 Nov 2009 13:56:13 +0100,
> Asdo <asdo@shiftmail.org> a écrit :
>
> > Frederic Leroy wrote:
> > > Le Wed, 25 Nov 2009 05:25:28 +0100,
> > > Asdo <asdo@shiftmail.org> a écrit :
> > >
> > >
> > >> Hi netdev and e1000 people,
> > >>
> > >> I have a weird problem here.
> > >> [...]
> > > I have the same kind of problem at home. I can't copy big files over
> > > [...]
> > Good God it's true then!
>
> Yes :)
>
> > Still if I am right, with Netcat you might end up with a corrupted
> > file on the other side (shorter). Or maybe not, depending on how
> > exactly the bug is made. Could you check this? Filesize and md5sum.
>
> md5sum are ok.
> I can't reproduce the problem on wire with a switch ( using both
> 10 and 100Mbp FD )
>
> > Do you have Intel network card, with e1000e driver on SG? (see lsmod)
> > (sorry I was wrong before, it's e1000e in my case not e1000)
> > Otherwise it's probably the TCP layer...
>
> Sorry, I forgot to precise the network hardware.
> I forgot a noname 100Mbp switch between the isv box and sg host.
>
> SG:
>
> 00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL-8139/8139C/8139C+ (rev 10)
> using module 8139cp
>
> Devel:
>
> 02:02.0 Network controller: Broadcom Corporation BCM4306 802.11b/g
> Wireless LAN Controller (rev 03)
> using b43 driver.
>
> 02:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VE (MOB)
> Ethernet Controller (rev 81)
> using e100 in kernel ( no module )
>
> My isv box is broadcom based, but I don't know which chipset for
> wireless.
>
> Since our hardware are different, I don't think it's coming from
> hardware driver. I'm preparing traces for Ilpo
One worth of checking would be ssh versions if they match (if they have
broken something, though it's unlikely). I'm also relatively convinced
that hw issues are not what'll find.
--
i.
^ permalink raw reply
* scp stalls mysteriously
From: Frederic Leroy @ 2009-11-27 21:35 UTC (permalink / raw)
To: Netdev; +Cc: Ilpo Järvinen, Asdo
Ilpo,
I put traces of stall here :
http://www.starox.org/pub/scp_stall/
openssh versions :
houba tmp # equery l openssh
[ Searching for package 'openssh' in all categories among: ]
* installed packages
[I--] [ ] net-misc/openssh-5.2_p1-r3 (0)
fredo@sg:~$ dpkg -l | grep ssh
ii libssh2-1 0.18-1 SSH2 client-side library
ii openssh-blacklist 0.4.1 list of default blacklisted OpenSSH RSA and
ii openssh-client 1:5.1p1-5 secure shell client, an rlogin/rsh/rcp repla
ii openssh-server 1:5.1p1-5 secure shell server, an rshd replacement
ii ssh 1:5.1p1-5 secure shell client and server (metapackage)
I will downgrade gentoo ssh and give another try ...
--
Frédéric Leroy
^ permalink raw reply
* Re: large packet loss take2 2.6.31.x
From: Jarek Poplawski @ 2009-11-27 21:36 UTC (permalink / raw)
To: Caleb Cushing
Cc: e1000-devel, netdev, Frans Pop, Jesse Brandeburg, linux-kernel,
Andi Kleen, Jeff Kirsher
In-Reply-To: <81bfc67a0911271007o1fb8f8c2vdd36e8585280e4da@mail.gmail.com>
On Fri, Nov 27, 2009 at 01:07:53PM -0500, Caleb Cushing wrote:
> 2.6.32-rc8 seemed to be affected (guess. because my net didn't come up
> on reboot. further testing will likely verify) also during reboots I
> found out that the version I've been thinking is good is afflicted. I
> supposed maybe I should try bisecting again? starting with that point.
> not sure it'll do us much good if that version was able to slip by for
> so long. I really hate intermittent bugs.
I doubt bisecting is a good idea with so unpredictable bug. First, you
should make sure it's not a hardware problem, so go back to the kernel
you trust most, and give it a really long try with a few recompilations
after slightly changing the config. Btw, I wonder if you tried e1000e
module parameters like IntMode=0 or 1.
Jarek P.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply
* Re: scp stalls mysteriously
From: Ilpo Järvinen @ 2009-11-27 22:12 UTC (permalink / raw)
To: Frederic Leroy; +Cc: Netdev, Asdo
In-Reply-To: <20091127223545.2a752429@houba>
On Fri, 27 Nov 2009, Frederic Leroy wrote:
> Ilpo,
>
> I put traces of stall here :
> http://www.starox.org/pub/scp_stall/
>
> openssh versions :
>
> houba tmp # equery l openssh
> [ Searching for package 'openssh' in all categories among: ]
> * installed packages
> [I--] [ ] net-misc/openssh-5.2_p1-r3 (0)
>
> fredo@sg:~$ dpkg -l | grep ssh
> ii libssh2-1 0.18-1 SSH2 client-side library
> ii openssh-blacklist 0.4.1 list of default blacklisted OpenSSH RSA and
> ii openssh-client 1:5.1p1-5 secure shell client, an rlogin/rsh/rcp repla
> ii openssh-server 1:5.1p1-5 secure shell server, an rshd replacement
> ii ssh 1:5.1p1-5 secure shell client and server (metapackage)
>
> I will downgrade gentoo ssh and give another try ...
...I think we can drop ssh from suspect lists for now.
Your proc/net/tcp capture on houba was perhaps made too late? ...The
connection is missing already.
But anyway, at least the problem is visible... It seems that 3998:4046
gets never retransmitted, not even by RTO which seems very very strange
to me... And after this: 23:21:56.154269 IP 192.168.1.19.50028 >
192.168.1.15.22: . ack 3998 win 379 ... sack 3
{4238:4286}{4142:4190}{4046:4094}> also fast retransmit should have
already triggered. ...I'll look more into this if I can figure it out
from the current traces but it'll take a while.
--
i.
^ permalink raw reply
* [PATCH v2] netdevice: provide common routine for macvlan and vlan operstate management
From: Patrick Mullaney @ 2009-11-27 22:12 UTC (permalink / raw)
To: netdev; +Cc: kaber, arnd, linux-kernel, alacrityvm-devel
Applies to net-2.6.git/master:0135ae0b9)
Provide common routine for the transition of operational state for a leaf
device during a root device transition. This updates a previous patch in
my venet macvlan series and fixes the problems that Arnd pointed out.
Is submitting this applied to net-next a more better approach?
Signed-off-by: Patrick Mullaney <pmullaney@novell.com>
---
drivers/net/macvlan.c | 24 +++---------------------
include/linux/netdevice.h | 3 +++
net/8021q/vlan.c | 29 ++++-------------------------
net/core/dev.c | 27 +++++++++++++++++++++++++++
4 files changed, 37 insertions(+), 46 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 2490aa3..14f63ec 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -456,25 +456,6 @@ static void macvlan_port_destroy(struct net_device *dev)
kfree(port);
}
-static void macvlan_transfer_operstate(struct net_device *dev)
-{
- struct macvlan_dev *vlan = netdev_priv(dev);
- const struct net_device *lowerdev = vlan->lowerdev;
-
- if (lowerdev->operstate == IF_OPER_DORMANT)
- netif_dormant_on(dev);
- else
- netif_dormant_off(dev);
-
- if (netif_carrier_ok(lowerdev)) {
- if (!netif_carrier_ok(dev))
- netif_carrier_on(dev);
- } else {
- if (netif_carrier_ok(dev))
- netif_carrier_off(dev);
- }
-}
-
static int macvlan_validate(struct nlattr *tb[], struct nlattr *data[])
{
if (tb[IFLA_ADDRESS]) {
@@ -552,7 +533,7 @@ static int macvlan_newlink(struct net_device *dev,
return err;
list_add_tail(&vlan->list, &port->vlans);
- macvlan_transfer_operstate(dev);
+ netif_stacked_transfer_operstate(lowerdev, dev);
return 0;
}
@@ -592,7 +573,8 @@ static int macvlan_device_event(struct notifier_block *unused,
switch (event) {
case NETDEV_CHANGE:
list_for_each_entry(vlan, &port->vlans, list)
- macvlan_transfer_operstate(vlan->dev);
+ netif_stacked_transfer_operstate(vlan->lowerdev,
+ vlan->dev);
break;
case NETDEV_FEAT_CHANGE:
list_for_each_entry(vlan, &port->vlans, list) {
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 812a5f3..1587715 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1914,6 +1914,9 @@ unsigned long netdev_increment_features(unsigned long all, unsigned long one,
unsigned long mask);
unsigned long netdev_fix_features(unsigned long features, const char *name);
+void netif_stacked_transfer_operstate(const struct net_device *rootdev,
+ struct net_device *dev);
+
static inline int net_gso_ok(int features, int gso_type)
{
int feature = gso_type << NETIF_F_GSO_SHIFT;
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index a29c5ab..44f5751 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -183,27 +183,6 @@ void unregister_vlan_dev(struct net_device *dev)
dev_put(real_dev);
}
-static void vlan_transfer_operstate(const struct net_device *dev,
- struct net_device *vlandev)
-{
- /* Have to respect userspace enforced dormant state
- * of real device, also must allow supplicant running
- * on VLAN device
- */
- if (dev->operstate == IF_OPER_DORMANT)
- netif_dormant_on(vlandev);
- else
- netif_dormant_off(vlandev);
-
- if (netif_carrier_ok(dev)) {
- if (!netif_carrier_ok(vlandev))
- netif_carrier_on(vlandev);
- } else {
- if (netif_carrier_ok(vlandev))
- netif_carrier_off(vlandev);
- }
-}
-
int vlan_check_real_dev(struct net_device *real_dev, u16 vlan_id)
{
const char *name = real_dev->name;
@@ -261,7 +240,7 @@ int register_vlan_dev(struct net_device *dev)
/* Account for reference in struct vlan_dev_info */
dev_hold(real_dev);
- vlan_transfer_operstate(real_dev, dev);
+ netif_stacked_transfer_operstate(real_dev, dev);
linkwatch_fire_event(dev); /* _MUST_ call rfc2863_policy() */
/* So, got the sucker initialized, now lets place
@@ -450,7 +429,7 @@ static int vlan_device_event(struct notifier_block *unused, unsigned long event,
if (!vlandev)
continue;
- vlan_transfer_operstate(dev, vlandev);
+ netif_stacked_transfer_operstate(dev, vlandev);
}
break;
@@ -506,7 +485,7 @@ static int vlan_device_event(struct notifier_block *unused, unsigned long event,
continue;
dev_change_flags(vlandev, flgs & ~IFF_UP);
- vlan_transfer_operstate(dev, vlandev);
+ netif_stacked_transfer_operstate(dev, vlandev);
}
break;
@@ -522,7 +501,7 @@ static int vlan_device_event(struct notifier_block *unused, unsigned long event,
continue;
dev_change_flags(vlandev, flgs | IFF_UP);
- vlan_transfer_operstate(dev, vlandev);
+ netif_stacked_transfer_operstate(dev, vlandev);
}
break;
diff --git a/net/core/dev.c b/net/core/dev.c
index fe10551..8ece671 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4747,6 +4747,33 @@ unsigned long netdev_fix_features(unsigned long features, const char *name)
EXPORT_SYMBOL(netdev_fix_features);
/**
+ * netif_stacked_transfer_operstate - transfer operstate
+ * @rootdev: the root or lower level device to transfer state from
+ * @dev: the device to transfer operstate to
+ *
+ * Transfer operational state from root to device. This is normally
+ * called when a stacking relationship exists between the root
+ * device and the device(a leaf device).
+ */
+void netif_stacked_transfer_operstate(const struct net_device *rootdev,
+ struct net_device *dev)
+{
+ if (rootdev->operstate == IF_OPER_DORMANT)
+ netif_dormant_on(dev);
+ else
+ netif_dormant_off(dev);
+
+ if (netif_carrier_ok(rootdev)) {
+ if (!netif_carrier_ok(dev))
+ netif_carrier_on(dev);
+ } else {
+ if (netif_carrier_ok(dev))
+ netif_carrier_off(dev);
+ }
+}
+EXPORT_SYMBOL(netif_stacked_transfer_operstate);
+
+/**
* register_netdevice - register a network device
* @dev: device to register
*
^ permalink raw reply related
* Re: [PATCH 3/3] macvlan: allow in-kernel modules to create and manage macvlan devices
From: Arnd Bergmann @ 2009-11-27 22:14 UTC (permalink / raw)
To: Patrick Mullaney; +Cc: kaber, netdev, alacrityvm-devel, linux-kernel, bridge
In-Reply-To: <20091113195529.11184.19011.stgit@mimic.site>
On Friday 13 November 2009, Patrick Mullaney wrote:
>
> The macvlan driver didn't allow for creation/deletion of devices
> by other in-kernel modules. This patch provides common routines
> for both in-kernel and netlink based management. This patch
> also enables macvlan device support for gro for lower level
> devices that support gro.
I wonder if doing this way round is a good idea, why don't
you just use netlink to set up the endpoint device like
the current macvlan and macvtap do? I think doing it consistently
for all backends would be a significant advantage.
Arnd <><
^ permalink raw reply
* Re: [PATCH 3/3] macvlan: allow in-kernel modules to create and manage macvlan devices
From: Arnd Bergmann @ 2009-11-27 22:19 UTC (permalink / raw)
To: Patrick Mullaney; +Cc: kaber, netdev, alacrityvm-devel, linux-kernel, bridge
In-Reply-To: <20091113195529.11184.19011.stgit@mimic.site>
On Friday 13 November 2009, Patrick Mullaney wrote:
> @@ -318,7 +318,7 @@ static struct lock_class_key macvlan_netdev_addr_lock_key;
> #define MACVLAN_FEATURES \
> (NETIF_F_SG | NETIF_F_ALL_CSUM | NETIF_F_HIGHDMA | NETIF_F_FRAGLIST | \
> NETIF_F_GSO | NETIF_F_TSO | NETIF_F_UFO | NETIF_F_GSO_ROBUST | \
> - NETIF_F_TSO_ECN | NETIF_F_TSO6)
> + NETIF_F_TSO_ECN | NETIF_F_TSO6 | NETIF_F_GRO)
>
> #define MACVLAN_STATE_MASK \
> ((1<<__LINK_STATE_NOCARRIER) | (1<<__LINK_STATE_DORMANT))
This hunk looks like it should be a separate patch, because we will
want to have this independently of the rest. I have taken it into
a series I'm preparing for a new posting of macvtap based on the
current net-next tree with my bridge mode changes. I also have
your patch 1 (the fixed version) and 2 in there. It's currently
work in progress, but if you are interested, take a look at [1].
Arnd <><
[1] http://git.kernel.org/?p=linux/kernel/git/arnd/playground.git;a=shortlog;h=refs/heads/macvlan
^ permalink raw reply
* Re: scp stalls mysteriously
From: Frederic Leroy @ 2009-11-27 22:22 UTC (permalink / raw)
To: Frederic Leroy; +Cc: Netdev, Ilpo Järvinen, Asdo
In-Reply-To: <20091127223545.2a752429@houba>
Le Fri, 27 Nov 2009 22:35:45 +0100,
Frederic Leroy <fredo@starox.org> a écrit :
> openssh versions :
>
> houba tmp # equery l openssh
> [ Searching for package 'openssh' in all categories among: ]
> * installed packages
> [I--] [ ] net-misc/openssh-5.2_p1-r3 (0)
>
> fredo@sg:~$ dpkg -l | grep ssh
> ii libssh2-1 0.18-1 SSH2
> client-side library ii openssh-blacklist
> 0.4.1 list of default blacklisted OpenSSH RSA and
> ii openssh-client 1:5.1p1-5
> secure shell client, an rlogin/rsh/rcp repla ii
> openssh-server 1:5.1p1-5 secure
> shell server, an rshd replacement ii
> ssh 1:5.1p1-5 secure
> shell client and server (metapackage)
>
> I will downgrade gentoo ssh and give another try ...
Argh !!!
I emerged openssh-5.1_p1-r2 on houba.
Restarted ssh server (/etc/init.d/sshd restart)
Log on sg and make a scp as usual.
It worked fine.
Make a second copy, and It worked fine also.
Then, I emerged openssh-5.2_p1-r3 on houba, restarted sshd, make three
big copies ... and finally it worked fine.
The bug mysteriously escaped from the dungeon !
--
Frédéric Leroy
^ permalink raw reply
* Re: scp stalls mysteriously
From: Ilpo Järvinen @ 2009-11-27 22:28 UTC (permalink / raw)
To: Frederic Leroy; +Cc: Netdev, Asdo
In-Reply-To: <20091127232257.1c13ccde@houba>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1557 bytes --]
On Fri, 27 Nov 2009, Frederic Leroy wrote:
> Le Fri, 27 Nov 2009 22:35:45 +0100,
> Frederic Leroy <fredo@starox.org> a écrit :
> > openssh versions :
> >
> > houba tmp # equery l openssh
> > [ Searching for package 'openssh' in all categories among: ]
> > * installed packages
> > [I--] [ ] net-misc/openssh-5.2_p1-r3 (0)
> >
> > fredo@sg:~$ dpkg -l | grep ssh
> > ii libssh2-1 0.18-1 SSH2
> > client-side library ii openssh-blacklist
> > 0.4.1 list of default blacklisted OpenSSH RSA and
> > ii openssh-client 1:5.1p1-5
> > secure shell client, an rlogin/rsh/rcp repla ii
> > openssh-server 1:5.1p1-5 secure
> > shell server, an rshd replacement ii
> > ssh 1:5.1p1-5 secure
> > shell client and server (metapackage)
> >
> > I will downgrade gentoo ssh and give another try ...
>
> Argh !!!
>
> I emerged openssh-5.1_p1-r2 on houba.
> Restarted ssh server (/etc/init.d/sshd restart)
> Log on sg and make a scp as usual.
> It worked fine.
> Make a second copy, and It worked fine also.
>
> Then, I emerged openssh-5.2_p1-r3 on houba, restarted sshd, make three
> big copies ... and finally it worked fine.
>
> The bug mysteriously escaped from the dungeon !
...You probably just lacked the losses which are crucial so it certainly
hasn't escaped anywhere (I guess that due to some random factor you didn't
get the losses this time and all of course will then work).
--
i.
^ permalink raw reply
* Re: scp stalls mysteriously
From: Ilpo Järvinen @ 2009-11-27 22:30 UTC (permalink / raw)
To: Frederic Leroy; +Cc: Netdev, Asdo
In-Reply-To: <20091127232257.1c13ccde@houba>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1448 bytes --]
On Fri, 27 Nov 2009, Frederic Leroy wrote:
> Le Fri, 27 Nov 2009 22:35:45 +0100,
> Frederic Leroy <fredo@starox.org> a écrit :
> > openssh versions :
> >
> > houba tmp # equery l openssh
> > [ Searching for package 'openssh' in all categories among: ]
> > * installed packages
> > [I--] [ ] net-misc/openssh-5.2_p1-r3 (0)
> >
> > fredo@sg:~$ dpkg -l | grep ssh
> > ii libssh2-1 0.18-1 SSH2
> > client-side library ii openssh-blacklist
> > 0.4.1 list of default blacklisted OpenSSH RSA and
> > ii openssh-client 1:5.1p1-5
> > secure shell client, an rlogin/rsh/rcp repla ii
> > openssh-server 1:5.1p1-5 secure
> > shell server, an rshd replacement ii
> > ssh 1:5.1p1-5 secure
> > shell client and server (metapackage)
> >
> > I will downgrade gentoo ssh and give another try ...
>
> Argh !!!
>
> I emerged openssh-5.1_p1-r2 on houba.
> Restarted ssh server (/etc/init.d/sshd restart)
> Log on sg and make a scp as usual.
> It worked fine.
> Make a second copy, and It worked fine also.
>
> Then, I emerged openssh-5.2_p1-r3 on houba, restarted sshd, make three
> big copies ... and finally it worked fine.
>
> The bug mysteriously escaped from the dungeon !
...Anyway, I'll probably try to reproduce tomorrow myself based on the
patterns I see in your logs.
--
i.
^ permalink raw reply
* Re: [PATCH v2] netdevice: provide common routine for macvlan and vlan operstate management
From: Patrick McHardy @ 2009-11-27 22:30 UTC (permalink / raw)
To: Patrick Mullaney; +Cc: netdev, arnd, linux-kernel, alacrityvm-devel
In-Reply-To: <20091127220717.14078.6058.stgit@mimic.site>
Patrick Mullaney wrote:
> Applies to net-2.6.git/master:0135ae0b9)
>
> Provide common routine for the transition of operational state for a leaf
> device during a root device transition. This updates a previous patch in
> my venet macvlan series and fixes the problems that Arnd pointed out.
>
> Is submitting this applied to net-next a more better approach?
Yes, please base this patch on net-next.
> Signed-off-by: Patrick Mullaney <pmullaney@novell.com>
Acked-by: Patrick McHardy <kaber@trash.net>
^ permalink raw reply
* Re: [PATCH 1/3] X25: Move SYSCTL ifdefs into header
From: Eric W. Biederman @ 2009-11-27 22:34 UTC (permalink / raw)
To: andrew hendry; +Cc: netdev, linux-kernel, linux-x25
In-Reply-To: <d45a3acc0911241715jcb41224y7871ea0878b9df9e@mail.gmail.com>
andrew hendry <andrew.hendry@gmail.com> writes:
> Moves the CONFIG_SYSCTL ifdefs in x25_init into header.
This looks like a reasonable change and it doesn't conflict
with my pending changes in the sysctl tree.
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> Signed-off-by: Andrew Hendry <andrew.hendry@gmail.com>
>
> diff -uprN -X a/Documentation/dontdiff a/include/net/x25.h b/include/net/x25.h
> --- a/include/net/x25.h 2009-11-10 11:32:31.000000000 +1100
> +++ b/include/net/x25.h 2009-11-25 09:05:21.000000000 +1100
> @@ -287,8 +287,14 @@ extern unsigned long x25_display_timer(s
> extern void x25_check_rbuf(struct sock *);
>
> /* sysctl_net_x25.c */
> +#ifdef CONFIG_SYSCTL
> extern void x25_register_sysctl(void);
> extern void x25_unregister_sysctl(void);
> +#else
> +static inline void x25_register_sysctl(void) {};
> +static inline void x25_unregister_sysctl(void) {};
> +#endif /* CONFIG_SYSCTL */
> +
> struct x25_skb_cb {
> unsigned flags;
> };
> diff -uprN -X a/Documentation/dontdiff a/net/x25/af_x25.c b/net/x25/af_x25.c
> --- a/net/x25/af_x25.c 2009-11-17 10:30:18.000000000 +1100
> +++ b/net/x25/af_x25.c 2009-11-25 09:04:25.000000000 +1100
> @@ -1667,9 +1667,7 @@ static int __init x25_init(void)
>
> printk(KERN_INFO "X.25 for Linux Version 0.2\n");
>
> -#ifdef CONFIG_SYSCTL
> x25_register_sysctl();
> -#endif
> x25_proc_init();
> out:
> return rc;
> @@ -1682,9 +1680,7 @@ static void __exit x25_exit(void)
> x25_link_free();
> x25_route_free();
>
> -#ifdef CONFIG_SYSCTL
> x25_unregister_sysctl();
> -#endif
>
> unregister_netdevice_notifier(&x25_dev_notifier);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: large packet loss take2 2.6.31.x
From: Caleb Cushing @ 2009-11-27 22:35 UTC (permalink / raw)
To: Jarek Poplawski
Cc: e1000-devel, netdev, Frans Pop, Jesse Brandeburg, linux-kernel,
Andi Kleen, Jeff Kirsher
In-Reply-To: <20091127213640.GA2611@ami.dom.local>
> I doubt bisecting is a good idea with so unpredictable bug. First, you
> should make sure it's not a hardware problem, so go back to the kernel
> you trust most, and give it a really long try with a few recompilations
> after slightly changing the config. Btw, I wonder if you tried e1000e
> module parameters like IntMode=0 or 1.
no, how do I set those?
--
Caleb Cushing
http://xenoterracide.blogspot.com
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply
* Re: [PATCH v2] netdevice: provide common routine for macvlan and vlan operstate management
From: Arnd Bergmann @ 2009-11-27 22:38 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Patrick Mullaney, netdev, linux-kernel, alacrityvm-devel
In-Reply-To: <4B105311.1020005@trash.net>
On Friday 27 November 2009, Patrick McHardy wrote:
> > Signed-off-by: Patrick Mullaney <pmullaney@novell.com>
>
> Acked-by: Patrick McHardy <kaber@trash.net>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: large packet loss take2 2.6.31.x
From: Jarek Poplawski @ 2009-11-27 22:42 UTC (permalink / raw)
To: Caleb Cushing
Cc: Frans Pop, Andi Kleen, linux-kernel, netdev, Jeff Kirsher,
Jesse Brandeburg, e1000-devel
In-Reply-To: <81bfc67a0911271435g4106652bpe8c9ea07893d0ebd@mail.gmail.com>
On Fri, Nov 27, 2009 at 05:35:34PM -0500, Caleb Cushing wrote:
> > I doubt bisecting is a good idea with so unpredictable bug. First, you
> > should make sure it's not a hardware problem, so go back to the kernel
> > you trust most, and give it a really long try with a few recompilations
> > after slightly changing the config. Btw, I wonder if you tried e1000e
> > module parameters like IntMode=0 or 1.
>
> no, how do I set those?
modprobe -r e1000e
modprobe e1000e IntMode=0
Jarek P.
^ permalink raw reply
* Re: [PATCH 0/3] macvlan: support for guest vm direct rx/tx
From: Arnd Bergmann @ 2009-11-27 23:43 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Patrick Mullaney, kaber, netdev, alacrityvm-devel, linux-kernel,
bridge
In-Reply-To: <20091113132728.0f1db7c5@s6510>
On Friday 13 November 2009, Stephen Hemminger wrote:
> Also, macvlan should really being calling netif_receive_skb()
> not going through another queue/softirq cycle.
I've added a patch for this in my experimental queue now.
When I last tried this, I saw a kernel stack overflow
but it seems fine now.
I wonder if we can also return from the macvlan hook with
skb->dev changed to netif_receive_skb rather than calling it
recursively.
Arnd <><
^ permalink raw reply
* Re: [PATCH] sch_htb: ix the deficit overflows
From: Jarek Poplawski @ 2009-11-28 0:04 UTC (permalink / raw)
To: xiaosuo; +Cc: Jamal Hadi Salim, David S. Miller, netdev
In-Reply-To: <4B0F8A5D.1040806@gmail.com>
Changli Gao wrote, On 11/27/2009 09:14 AM:
> fix the deficit overflows.
>
> HTB uses WDRR(Weighted Deficit Round Robin) algorithm to schedule the spare
> bandwidth, but it doesn't check if the deficit is big enough for the skb when
> dequeuing skb from a class. In some case(the quantum is smaller than the
> packet size), the deficit will be decreased, even when it is smaller than
> ZERO. At last, the deficit will overflows, and become MAX_INT.
This case of the quantum smaller than the packet size should be treated
as a broken config, so I don't think it's worth to do such a deep change
with additional delays and cpu cycles for all to fix it. A warning or
lower limit should be enough (if necessary at all).
Jarek P.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
> ----
> sch_htb.c | 25 ++++++++++++++++++++-----
> 1 file changed, 20 insertions(+), 5 deletions(-)
> diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
> index 2e38d1a..293983e 100644
> --- a/net/sched/sch_htb.c
> +++ b/net/sched/sch_htb.c
> @@ -783,6 +783,7 @@ static struct sk_buff *htb_dequeue_tree(struct htb_sched *q, int prio,
> {
> struct sk_buff *skb = NULL;
> struct htb_class *cl, *start;
> + unsigned int len;
> /* look initial class up in the row */
> start = cl = htb_lookup_leaf(q->row[level] + prio, prio,
> q->ptr[level] + prio,
> @@ -815,9 +816,23 @@ next:
> goto next;
> }
>
> - skb = cl->un.leaf.q->dequeue(cl->un.leaf.q);
> - if (likely(skb != NULL))
> - break;
> + skb = cl->un.leaf.q->ops->peek(cl->un.leaf.q);
> + if (likely(skb != NULL)) {
> + len = qdisc_pkt_len(skb);
> + if (len <= cl->un.leaf.deficit[level]) {
> + skb = qdisc_dequeue_peeked(cl->un.leaf.q);
> + break;
> + }
> + skb = NULL;
> + cl->un.leaf.deficit[level] += cl->quantum;
> + htb_next_rb_node((level ? cl->parent->un.inner.ptr :
> + q->ptr[0]) + prio);
> + cl = htb_lookup_leaf(q->row[level] + prio, prio,
> + q->ptr[level] + prio,
> + q->last_ptr_id[level] + prio);
> + start = cl;
> + goto next;
> + }
>
> qdisc_warn_nonwc("htb", cl->un.leaf.q);
> htb_next_rb_node((level ? cl->parent->un.inner.ptr : q->
> @@ -829,8 +844,8 @@ next:
> } while (cl != start);
>
> if (likely(skb != NULL)) {
> - cl->un.leaf.deficit[level] -= qdisc_pkt_len(skb);
> - if (cl->un.leaf.deficit[level] < 0) {
> + cl->un.leaf.deficit[level] -= len;
> + if (cl->un.leaf.deficit[level] <= 0) {
> cl->un.leaf.deficit[level] += cl->quantum;
> htb_next_rb_node((level ? cl->parent->un.inner.ptr : q->
> ptr[0]) + prio);
>
> --
^ permalink raw reply
* Re: [PATCH 0/3] macvlan: support for guest vm direct rx/tx
From: David Miller @ 2009-11-28 0:19 UTC (permalink / raw)
To: arnd
Cc: shemminger, pmullaney, kaber, netdev, alacrityvm-devel,
linux-kernel, bridge
In-Reply-To: <200911280043.58784.arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Sat, 28 Nov 2009 00:43:58 +0100
> On Friday 13 November 2009, Stephen Hemminger wrote:
>> Also, macvlan should really being calling netif_receive_skb()
>> not going through another queue/softirq cycle.
>
> I've added a patch for this in my experimental queue now.
> When I last tried this, I saw a kernel stack overflow
> but it seems fine now.
I think it is unwise for any virtual device layer to use netif_receive_skb().
Just like tunnels they should always use netif_rx().
Otherwise stack overflow is a very real concern.
^ permalink raw reply
* netdev vger CVS git import...
From: David Miller @ 2009-11-28 1:19 UTC (permalink / raw)
To: netdev; +Cc: herbert, eric.dumazet
I've put up:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netdev-vger-cvs.git
which is a "git cvsimport" of the last snapshot I have of the vger.kernel.org
CVS tree we used for sparc and networking development for many users.
Herbert and others use it often for reference wrt. changes made a long long
time ago, in the days predating even bitkeeper.
I haven't validated the import very closely, so beware.
And also the changelog messages back in those days were often very meager at
best. They definitely pale in comparison to what gets written these days.
Anyways, just FYI...
^ permalink raw reply
* Re: netdev vger CVS git import...
From: Herbert Xu @ 2009-11-28 1:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev, eric.dumazet
In-Reply-To: <20091127.171930.170940977.davem@davemloft.net>
On Fri, Nov 27, 2009 at 05:19:30PM -0800, David Miller wrote:
>
> I've put up:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/netdev-vger-cvs.git
Thanks a lot for doing this!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 01/32] sfc: Simplify PHY polling
From: Ben Hutchings @ 2009-11-28 3:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
From: Steve Hodgson <shodgson@solarflare.com>
Falcon can generate events for LASI interrupts from the PHY, but in
practice we have never implemented this in reference designs. Instead
we have polled, inserted the appropriate events, and then handled the
events later. This is a waste of time and code.
Instead, make PHY poll functions update the link state synchronously
and report whether it changed. We can still make use of the LASI
registers as a shortcut on the SFT9001.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/efx.c | 35 +++++----------------
drivers/net/sfc/efx.h | 3 ++
drivers/net/sfc/falcon.c | 69 +++++++++++++++++++++++++----------------
drivers/net/sfc/falcon.h | 1 -
drivers/net/sfc/net_driver.h | 24 ++++++++------
drivers/net/sfc/qt202x_phy.c | 26 +++++----------
drivers/net/sfc/tenxpress.c | 69 ++++++++++++++++-------------------------
7 files changed, 103 insertions(+), 124 deletions(-)
diff --git a/drivers/net/sfc/efx.c b/drivers/net/sfc/efx.c
index 1009d1e..b5a7e91 100644
--- a/drivers/net/sfc/efx.c
+++ b/drivers/net/sfc/efx.c
@@ -583,7 +583,7 @@ void efx_schedule_slow_fill(struct efx_rx_queue *rx_queue, int delay)
* netif_carrier_on/off) of the link status, and also maintains the
* link status's stop on the port's TX queue.
*/
-static void efx_link_status_changed(struct efx_nic *efx)
+void efx_link_status_changed(struct efx_nic *efx)
{
struct efx_link_state *link_state = &efx->link_state;
@@ -675,19 +675,6 @@ void efx_reconfigure_port(struct efx_nic *efx)
mutex_unlock(&efx->mac_lock);
}
-/* Asynchronous efx_reconfigure_port work item. To speed up efx_flush_all()
- * we don't efx_reconfigure_port() if the port is disabled. Care is taken
- * in efx_stop_all() and efx_start_port() to prevent PHY events being lost */
-static void efx_phy_work(struct work_struct *data)
-{
- struct efx_nic *efx = container_of(data, struct efx_nic, phy_work);
-
- mutex_lock(&efx->mac_lock);
- if (efx->port_enabled)
- __efx_reconfigure_port(efx);
- mutex_unlock(&efx->mac_lock);
-}
-
/* Asynchronous work item for changing MAC promiscuity and multicast
* hash. Avoid a drain/rx_ingress enable by reconfiguring the current
* MAC directly. */
@@ -768,9 +755,6 @@ fail1:
return rc;
}
-/* Allow efx_reconfigure_port() to be scheduled, and close the window
- * between efx_stop_port and efx_flush_all whereby a previously scheduled
- * efx_phy_work()/efx_mac_work() may have been cancelled */
static void efx_start_port(struct efx_nic *efx)
{
EFX_LOG(efx, "start port\n");
@@ -787,10 +771,7 @@ static void efx_start_port(struct efx_nic *efx)
mutex_unlock(&efx->mac_lock);
}
-/* Prevent efx_phy_work, efx_mac_work, and efx_monitor() from executing,
- * and efx_set_multicast_list() from scheduling efx_phy_work. efx_phy_work
- * and efx_mac_work may still be scheduled via NAPI processing until
- * efx_flush_all() is called */
+/* Prevent efx_mac_work() and efx_monitor() from working */
static void efx_stop_port(struct efx_nic *efx)
{
EFX_LOG(efx, "stop port\n");
@@ -1188,8 +1169,6 @@ static void efx_flush_all(struct efx_nic *efx)
/* Stop scheduled port reconfigurations */
cancel_work_sync(&efx->mac_work);
- cancel_work_sync(&efx->phy_work);
-
}
/* Quiesce hardware and software without bringing the link down.
@@ -1227,7 +1206,7 @@ static void efx_stop_all(struct efx_nic *efx)
* window to loose phy events */
efx_stop_port(efx);
- /* Flush efx_phy_work, efx_mac_work, refill_workqueue, monitor_work */
+ /* Flush efx_mac_work(), refill_workqueue, monitor_work */
efx_flush_all(efx);
/* Isolate the MAC from the TX and RX engines, so that queue
@@ -1907,6 +1886,10 @@ void efx_port_dummy_op_void(struct efx_nic *efx) {}
void efx_port_dummy_op_set_id_led(struct efx_nic *efx, enum efx_led_mode mode)
{
}
+bool efx_port_dummy_op_poll(struct efx_nic *efx)
+{
+ return false;
+}
static struct efx_mac_operations efx_dummy_mac_operations = {
.reconfigure = efx_port_dummy_op_void,
@@ -1915,9 +1898,8 @@ static struct efx_mac_operations efx_dummy_mac_operations = {
static struct efx_phy_operations efx_dummy_phy_operations = {
.init = efx_port_dummy_op_int,
.reconfigure = efx_port_dummy_op_void,
- .poll = efx_port_dummy_op_void,
+ .poll = efx_port_dummy_op_poll,
.fini = efx_port_dummy_op_void,
- .clear_interrupt = efx_port_dummy_op_void,
};
/**************************************************************************
@@ -1957,7 +1939,6 @@ static int efx_init_struct(struct efx_nic *efx, struct efx_nic_type *type,
efx->mac_op = &efx_dummy_mac_operations;
efx->phy_op = &efx_dummy_phy_operations;
efx->mdio.dev = net_dev;
- INIT_WORK(&efx->phy_work, efx_phy_work);
INIT_WORK(&efx->mac_work, efx_mac_work);
atomic_set(&efx->netif_stop_count, 1);
diff --git a/drivers/net/sfc/efx.h b/drivers/net/sfc/efx.h
index 01b93f9..15edda2 100644
--- a/drivers/net/sfc/efx.h
+++ b/drivers/net/sfc/efx.h
@@ -90,6 +90,7 @@ extern int efx_port_dummy_op_int(struct efx_nic *efx);
extern void efx_port_dummy_op_void(struct efx_nic *efx);
extern void
efx_port_dummy_op_set_id_led(struct efx_nic *efx, enum efx_led_mode mode);
+extern bool efx_port_dummy_op_poll(struct efx_nic *efx);
/* MTD */
#ifdef CONFIG_SFC_MTD
@@ -113,4 +114,6 @@ static inline void efx_schedule_channel(struct efx_channel *channel)
napi_schedule(&channel->napi_str);
}
+extern void efx_link_status_changed(struct efx_nic *efx);
+
#endif /* EFX_EFX_H */
diff --git a/drivers/net/sfc/falcon.c b/drivers/net/sfc/falcon.c
index e26043e..e16faad 100644
--- a/drivers/net/sfc/falcon.c
+++ b/drivers/net/sfc/falcon.c
@@ -893,8 +893,7 @@ static void falcon_handle_global_event(struct efx_channel *channel,
if (EFX_QWORD_FIELD(*event, FSF_AB_GLB_EV_G_PHY0_INTR) ||
EFX_QWORD_FIELD(*event, FSF_AB_GLB_EV_XG_PHY0_INTR) ||
EFX_QWORD_FIELD(*event, FSF_AB_GLB_EV_XFP_PHY0_INTR)) {
- efx->phy_op->clear_interrupt(efx);
- queue_work(efx->workqueue, &efx->phy_work);
+ /* Ignored */
handled = true;
}
@@ -1140,20 +1139,6 @@ void falcon_generate_test_event(struct efx_channel *channel, unsigned int magic)
falcon_generate_event(channel, &test_event);
}
-void falcon_sim_phy_event(struct efx_nic *efx)
-{
- efx_qword_t phy_event;
-
- EFX_POPULATE_QWORD_1(phy_event, FSF_AZ_EV_CODE,
- FSE_AZ_EV_CODE_GLOBAL_EV);
- if (EFX_IS10G(efx))
- EFX_SET_QWORD_FIELD(phy_event, FSF_AB_GLB_EV_XG_PHY0_INTR, 1);
- else
- EFX_SET_QWORD_FIELD(phy_event, FSF_AB_GLB_EV_G_PHY0_INTR, 1);
-
- falcon_generate_event(&efx->channel[0], &phy_event);
-}
-
/**************************************************************************
*
* Flush handling
@@ -2063,6 +2048,25 @@ static void falcon_stats_timer_func(unsigned long context)
spin_unlock(&efx->stats_lock);
}
+static bool falcon_loopback_link_poll(struct efx_nic *efx)
+{
+ struct efx_link_state old_state = efx->link_state;
+
+ WARN_ON(!mutex_is_locked(&efx->mac_lock));
+ WARN_ON(!LOOPBACK_INTERNAL(efx));
+
+ efx->link_state.fd = true;
+ efx->link_state.fc = efx->wanted_fc;
+ efx->link_state.up = true;
+
+ if (efx->loopback_mode == LOOPBACK_GMAC)
+ efx->link_state.speed = 1000;
+ else
+ efx->link_state.speed = 10000;
+
+ return !efx_link_state_equal(&efx->link_state, &old_state);
+}
+
/**************************************************************************
*
* PHY access via GMII
@@ -2225,15 +2229,6 @@ int falcon_switch_mac(struct efx_nic *efx)
/* Don't try to fetch MAC stats while we're switching MACs */
falcon_stop_nic_stats(efx);
- /* Internal loopbacks override the phy speed setting */
- if (efx->loopback_mode == LOOPBACK_GMAC) {
- efx->link_state.speed = 1000;
- efx->link_state.fd = true;
- } else if (LOOPBACK_INTERNAL(efx)) {
- efx->link_state.speed = 10000;
- efx->link_state.fd = true;
- }
-
WARN_ON(!mutex_is_locked(&efx->mac_lock));
efx->mac_op = (EFX_IS10G(efx) ?
&falcon_xmac_operations : &falcon_gmac_operations);
@@ -2610,16 +2605,36 @@ fail5:
void falcon_monitor(struct efx_nic *efx)
{
+ bool link_changed;
int rc;
+ BUG_ON(!mutex_is_locked(&efx->mac_lock));
+
rc = falcon_board(efx)->type->monitor(efx);
if (rc) {
EFX_ERR(efx, "Board sensor %s; shutting down PHY\n",
(rc == -ERANGE) ? "reported fault" : "failed");
efx->phy_mode |= PHY_MODE_LOW_POWER;
- falcon_sim_phy_event(efx);
+ __efx_reconfigure_port(efx);
}
- efx->phy_op->poll(efx);
+
+ if (LOOPBACK_INTERNAL(efx))
+ link_changed = falcon_loopback_link_poll(efx);
+ else
+ link_changed = efx->phy_op->poll(efx);
+
+ if (link_changed) {
+ falcon_stop_nic_stats(efx);
+ falcon_deconfigure_mac_wrapper(efx);
+
+ falcon_switch_mac(efx);
+ efx->mac_op->reconfigure(efx);
+
+ falcon_start_nic_stats(efx);
+
+ efx_link_status_changed(efx);
+ }
+
if (EFX_IS10G(efx))
falcon_poll_xmac(efx);
}
diff --git a/drivers/net/sfc/falcon.h b/drivers/net/sfc/falcon.h
index c70bb08..a561f67 100644
--- a/drivers/net/sfc/falcon.h
+++ b/drivers/net/sfc/falcon.h
@@ -145,7 +145,6 @@ extern int falcon_init_interrupt(struct efx_nic *efx);
extern void falcon_enable_interrupts(struct efx_nic *efx);
extern void falcon_generate_test_event(struct efx_channel *channel,
unsigned int magic);
-extern void falcon_sim_phy_event(struct efx_nic *efx);
extern void falcon_generate_interrupt(struct efx_nic *efx);
extern void falcon_set_int_moderation(struct efx_channel *channel);
extern void falcon_disable_interrupts(struct efx_nic *efx);
diff --git a/drivers/net/sfc/net_driver.h b/drivers/net/sfc/net_driver.h
index ead1c98..fb9327c 100644
--- a/drivers/net/sfc/net_driver.h
+++ b/drivers/net/sfc/net_driver.h
@@ -503,6 +503,13 @@ struct efx_link_state {
unsigned int speed;
};
+static inline bool efx_link_state_equal(const struct efx_link_state *left,
+ const struct efx_link_state *right)
+{
+ return left->up == right->up && left->fd == right->fd &&
+ left->fc == right->fc && left->speed == right->speed;
+}
+
/**
* struct efx_mac_operations - Efx MAC operations table
* @reconfigure: Reconfigure MAC. Serialised by the mac_lock
@@ -520,8 +527,8 @@ struct efx_mac_operations {
* @init: Initialise PHY
* @fini: Shut down PHY
* @reconfigure: Reconfigure PHY (e.g. for new link parameters)
- * @clear_interrupt: Clear down interrupt
- * @poll: Poll for hardware state. Serialised by the mac_lock.
+ * @poll: Update @link_state and report whether it changed.
+ * Serialised by the mac_lock.
* @get_settings: Get ethtool settings. Serialised by the mac_lock.
* @set_settings: Set ethtool settings. Serialised by the mac_lock.
* @set_npage_adv: Set abilities advertised in (Extended) Next Page
@@ -538,8 +545,7 @@ struct efx_phy_operations {
int (*init) (struct efx_nic *efx);
void (*fini) (struct efx_nic *efx);
void (*reconfigure) (struct efx_nic *efx);
- void (*clear_interrupt) (struct efx_nic *efx);
- void (*poll) (struct efx_nic *efx);
+ bool (*poll) (struct efx_nic *efx);
void (*get_settings) (struct efx_nic *efx,
struct ethtool_cmd *ecmd);
int (*set_settings) (struct efx_nic *efx,
@@ -700,10 +706,10 @@ union efx_multicast_hash {
* @mac_lock: MAC access lock. Protects @port_enabled, @phy_mode,
* @port_inhibited, efx_monitor() and efx_reconfigure_port()
* @port_enabled: Port enabled indicator.
- * Serialises efx_stop_all(), efx_start_all(), efx_monitor(),
- * efx_phy_work(), and efx_mac_work() with kernel interfaces. Safe to read
- * under any one of the rtnl_lock, mac_lock, or netif_tx_lock, but all
- * three must be held to modify it.
+ * Serialises efx_stop_all(), efx_start_all(), efx_monitor() and
+ * efx_mac_work() with kernel interfaces. Safe to read under any
+ * one of the rtnl_lock, mac_lock, or netif_tx_lock, but all three must
+ * be held to modify it.
* @port_inhibited: If set, the netif_carrier is always off. Hold the mac_lock
* @port_initialized: Port initialized?
* @net_dev: Operating system network device. Consider holding the rtnl lock
@@ -729,7 +735,6 @@ union efx_multicast_hash {
* @promiscuous: Promiscuous flag. Protected by netif_tx_lock.
* @multicast_hash: Multicast hash table
* @wanted_fc: Wanted flow control flags
- * @phy_work: work item for dealing with PHY events
* @mac_work: Work item for changing MAC promiscuity and multicast hash
* @loopback_mode: Loopback status
* @loopback_modes: Supported loopback mode bitmask
@@ -802,7 +807,6 @@ struct efx_nic {
enum phy_type phy_type;
spinlock_t phy_lock;
- struct work_struct phy_work;
struct efx_phy_operations *phy_op;
void *phy_data;
struct mdio_if_info mdio;
diff --git a/drivers/net/sfc/qt202x_phy.c b/drivers/net/sfc/qt202x_phy.c
index f9c354e..1b174c3 100644
--- a/drivers/net/sfc/qt202x_phy.c
+++ b/drivers/net/sfc/qt202x_phy.c
@@ -167,29 +167,26 @@ static int qt202x_phy_init(struct efx_nic *efx)
return rc;
}
-static void qt202x_phy_clear_interrupt(struct efx_nic *efx)
-{
- /* Read to clear link status alarm */
- efx_mdio_read(efx, MDIO_MMD_PMAPMD, MDIO_PMA_LASI_STAT);
-}
-
static int qt202x_link_ok(struct efx_nic *efx)
{
return efx_mdio_links_ok(efx, QT202X_REQUIRED_DEVS);
}
-static void qt202x_phy_poll(struct efx_nic *efx)
+static bool qt202x_phy_poll(struct efx_nic *efx)
{
- int link_up = qt202x_link_ok(efx);
- /* Simulate a PHY event if link state has changed */
- if (link_up != efx->link_state.up)
- falcon_sim_phy_event(efx);
+ bool was_up = efx->link_state.up;
+
+ efx->link_state.up = qt202x_link_ok(efx);
+ efx->link_state.speed = 10000;
+ efx->link_state.fd = true;
+ efx->link_state.fc = efx->wanted_fc;
+
+ return efx->link_state.up != was_up;
}
static void qt202x_phy_reconfigure(struct efx_nic *efx)
{
struct qt202x_phy_data *phy_data = efx->phy_data;
- struct efx_link_state *link_state = &efx->link_state;
if (efx->phy_type == PHY_TYPE_QT2025C) {
/* There are several different register bits which can
@@ -216,10 +213,6 @@ static void qt202x_phy_reconfigure(struct efx_nic *efx)
efx_mdio_phy_reconfigure(efx);
phy_data->phy_mode = efx->phy_mode;
- link_state->up = qt202x_link_ok(efx);
- link_state->speed = 10000;
- link_state->fd = true;
- link_state->fc = efx->wanted_fc;
}
static void qt202x_phy_get_settings(struct efx_nic *efx, struct ethtool_cmd *ecmd)
@@ -240,7 +233,6 @@ struct efx_phy_operations falcon_qt202x_phy_ops = {
.reconfigure = qt202x_phy_reconfigure,
.poll = qt202x_phy_poll,
.fini = qt202x_phy_fini,
- .clear_interrupt = qt202x_phy_clear_interrupt,
.get_settings = qt202x_phy_get_settings,
.set_settings = efx_mdio_set_settings,
.mmds = QT202X_REQUIRED_DEVS,
diff --git a/drivers/net/sfc/tenxpress.c b/drivers/net/sfc/tenxpress.c
index e6232fe..1bd7965 100644
--- a/drivers/net/sfc/tenxpress.c
+++ b/drivers/net/sfc/tenxpress.c
@@ -503,7 +503,6 @@ static void tenxpress_low_power(struct efx_nic *efx)
static void tenxpress_phy_reconfigure(struct efx_nic *efx)
{
struct tenxpress_phy_data *phy_data = efx->phy_data;
- struct efx_link_state *link_state = &efx->link_state;
struct ethtool_cmd ecmd;
bool phy_mode_change, loop_reset;
@@ -544,53 +543,41 @@ static void tenxpress_phy_reconfigure(struct efx_nic *efx)
phy_data->loopback_mode = efx->loopback_mode;
phy_data->phy_mode = efx->phy_mode;
-
- if (efx->phy_type == PHY_TYPE_SFX7101) {
- link_state->speed = 10000;
- link_state->fd = true;
- link_state->up = sfx7101_link_ok(efx);
- } else {
- efx->phy_op->get_settings(efx, &ecmd);
- link_state->speed = ecmd.speed;
- link_state->fd = ecmd.duplex == DUPLEX_FULL;
- link_state->up = sft9001_link_ok(efx, &ecmd);
- }
- link_state->fc = efx_mdio_get_pause(efx);
}
-/* Poll PHY for interrupt */
-static void tenxpress_phy_poll(struct efx_nic *efx)
+static void
+tenxpress_get_settings(struct efx_nic *efx, struct ethtool_cmd *ecmd);
+
+/* Poll for link state changes */
+static bool tenxpress_phy_poll(struct efx_nic *efx)
{
- struct tenxpress_phy_data *phy_data = efx->phy_data;
- struct efx_link_state *link_state = &efx->link_state;
- bool change = false;
+ struct efx_link_state old_state = efx->link_state;
if (efx->phy_type == PHY_TYPE_SFX7101) {
- bool link_ok = sfx7101_link_ok(efx);
- if (link_ok != link_state->up) {
- change = true;
- } else {
- unsigned int link_fc = efx_mdio_get_pause(efx);
- if (link_fc != link_state->fc)
- change = true;
- }
- sfx7101_check_bad_lp(efx, link_ok);
- } else if (efx->loopback_mode) {
- bool link_ok = sft9001_link_ok(efx, NULL);
- if (link_ok != link_state->up)
- change = true;
+ efx->link_state.up = sfx7101_link_ok(efx);
+ efx->link_state.speed = 10000;
+ efx->link_state.fd = true;
+ efx->link_state.fc = efx_mdio_get_pause(efx);
+
+ sfx7101_check_bad_lp(efx, efx->link_state.up);
} else {
- int status = efx_mdio_read(efx, MDIO_MMD_PMAPMD,
- MDIO_PMA_LASI_STAT);
- if (status & MDIO_PMA_LASI_LSALARM)
- change = true;
- }
+ struct ethtool_cmd ecmd;
- if (change)
- falcon_sim_phy_event(efx);
+ /* Check the LASI alarm first */
+ if (efx->loopback_mode == LOOPBACK_NONE &&
+ !(efx_mdio_read(efx, MDIO_MMD_PMAPMD, MDIO_PMA_LASI_STAT) &
+ MDIO_PMA_LASI_LSALARM))
+ return false;
- if (phy_data->phy_mode != PHY_MODE_NORMAL)
- return;
+ tenxpress_get_settings(efx, &ecmd);
+
+ efx->link_state.up = sft9001_link_ok(efx, &ecmd);
+ efx->link_state.speed = ecmd.speed;
+ efx->link_state.fd = (ecmd.duplex == DUPLEX_FULL);
+ efx->link_state.fc = efx_mdio_get_pause(efx);
+ }
+
+ return !efx_link_state_equal(&efx->link_state, &old_state);
}
static void tenxpress_phy_fini(struct efx_nic *efx)
@@ -818,7 +805,6 @@ struct efx_phy_operations falcon_sfx7101_phy_ops = {
.reconfigure = tenxpress_phy_reconfigure,
.poll = tenxpress_phy_poll,
.fini = tenxpress_phy_fini,
- .clear_interrupt = efx_port_dummy_op_void,
.get_settings = tenxpress_get_settings,
.set_settings = tenxpress_set_settings,
.set_npage_adv = sfx7101_set_npage_adv,
@@ -835,7 +821,6 @@ struct efx_phy_operations falcon_sft9001_phy_ops = {
.reconfigure = tenxpress_phy_reconfigure,
.poll = tenxpress_phy_poll,
.fini = tenxpress_phy_fini,
- .clear_interrupt = efx_port_dummy_op_void,
.get_settings = tenxpress_get_settings,
.set_settings = tenxpress_set_settings,
.set_npage_adv = sft9001_set_npage_adv,
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* [PATCH 02/32] sfc: QT202x: Reset before reading PHY id
From: Ben Hutchings @ 2009-11-28 3:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
From: Steve Hodgson <shodgson@solarflare.com>
Reading standard registers on the QT2025C before its firmware has
booted may cause the boot process to fail. Therefore, follow the
recommended reset sequence before reading its id registers. Either
order works for the QT2022C2, so don't differentiate.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/qt202x_phy.c | 22 ++++++++--------------
1 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/drivers/net/sfc/qt202x_phy.c b/drivers/net/sfc/qt202x_phy.c
index 1b174c3..3d7370e 100644
--- a/drivers/net/sfc/qt202x_phy.c
+++ b/drivers/net/sfc/qt202x_phy.c
@@ -138,33 +138,27 @@ static int qt202x_reset_phy(struct efx_nic *efx)
static int qt202x_phy_init(struct efx_nic *efx)
{
struct qt202x_phy_data *phy_data;
- u32 devid = efx_mdio_read_id(efx, MDIO_MMD_PHYXS);
+ u32 devid;
int rc;
+ rc = qt202x_reset_phy(efx);
+ if (rc) {
+ EFX_ERR(efx, "PHY init failed\n");
+ return rc;
+ }
+
phy_data = kzalloc(sizeof(struct qt202x_phy_data), GFP_KERNEL);
if (!phy_data)
return -ENOMEM;
efx->phy_data = phy_data;
+ devid = efx_mdio_read_id(efx, MDIO_MMD_PHYXS);
EFX_INFO(efx, "PHY ID reg %x (OUI %06x model %02x revision %x)\n",
devid, efx_mdio_id_oui(devid), efx_mdio_id_model(devid),
efx_mdio_id_rev(devid));
phy_data->phy_mode = efx->phy_mode;
-
- rc = qt202x_reset_phy(efx);
-
- EFX_INFO(efx, "PHY init %s.\n",
- rc ? "failed" : "successful");
- if (rc < 0)
- goto fail;
-
return 0;
-
- fail:
- kfree(efx->phy_data);
- efx->phy_data = NULL;
- return rc;
}
static int qt202x_link_ok(struct efx_nic *efx)
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* [PATCH 03/32] sfc: Replace MDIO spinlock with mutex
From: Ben Hutchings @ 2009-11-28 3:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
From: Steve Hodgson <shodgson@solarflare.com>
We never use MDIO in atomic context, so we don't need to spin.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/efx.c | 2 +-
drivers/net/sfc/falcon.c | 12 ++++++------
drivers/net/sfc/net_driver.h | 4 ++--
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/sfc/efx.c b/drivers/net/sfc/efx.c
index b5a7e91..6338ad8 100644
--- a/drivers/net/sfc/efx.c
+++ b/drivers/net/sfc/efx.c
@@ -1922,7 +1922,7 @@ static int efx_init_struct(struct efx_nic *efx, struct efx_nic_type *type,
/* Initialise common structures */
memset(efx, 0, sizeof(*efx));
spin_lock_init(&efx->biu_lock);
- spin_lock_init(&efx->phy_lock);
+ mutex_init(&efx->mdio_lock);
mutex_init(&efx->spi_lock);
INIT_WORK(&efx->reset_work, efx_reset_work);
INIT_DELAYED_WORK(&efx->monitor_work, efx_monitor);
diff --git a/drivers/net/sfc/falcon.c b/drivers/net/sfc/falcon.c
index e16faad..372dbbc 100644
--- a/drivers/net/sfc/falcon.c
+++ b/drivers/net/sfc/falcon.c
@@ -2110,7 +2110,7 @@ static int falcon_mdio_write(struct net_device *net_dev,
EFX_REGDUMP(efx, "writing MDIO %d register %d.%d with 0x%04x\n",
prtad, devad, addr, value);
- spin_lock_bh(&efx->phy_lock);
+ mutex_lock(&efx->mdio_lock);
/* Check MDIO not currently being accessed */
rc = falcon_gmii_wait(efx);
@@ -2145,8 +2145,8 @@ static int falcon_mdio_write(struct net_device *net_dev,
udelay(10);
}
- out:
- spin_unlock_bh(&efx->phy_lock);
+out:
+ mutex_unlock(&efx->mdio_lock);
return rc;
}
@@ -2158,7 +2158,7 @@ static int falcon_mdio_read(struct net_device *net_dev,
efx_oword_t reg;
int rc;
- spin_lock_bh(&efx->phy_lock);
+ mutex_lock(&efx->mdio_lock);
/* Check MDIO not currently being accessed */
rc = falcon_gmii_wait(efx);
@@ -2194,8 +2194,8 @@ static int falcon_mdio_read(struct net_device *net_dev,
prtad, devad, addr, rc);
}
- out:
- spin_unlock_bh(&efx->phy_lock);
+out:
+ mutex_unlock(&efx->mdio_lock);
return rc;
}
diff --git a/drivers/net/sfc/net_driver.h b/drivers/net/sfc/net_driver.h
index fb9327c..0aeaeda 100644
--- a/drivers/net/sfc/net_driver.h
+++ b/drivers/net/sfc/net_driver.h
@@ -724,7 +724,7 @@ union efx_multicast_hash {
* @mac_op: MAC interface
* @mac_address: Permanent MAC address
* @phy_type: PHY type
- * @phy_lock: PHY access lock
+ * @mdio_lock: MDIO lock
* @phy_op: PHY interface
* @phy_data: PHY private data (including PHY-specific stats)
* @mdio: PHY MDIO interface
@@ -806,7 +806,7 @@ struct efx_nic {
unsigned char mac_address[ETH_ALEN];
enum phy_type phy_type;
- spinlock_t phy_lock;
+ struct mutex mdio_lock;
struct efx_phy_operations *phy_op;
void *phy_data;
struct mdio_if_info mdio;
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* [PATCH 04/32] sfc: Always start Falcon using the XMAC
From: Ben Hutchings @ 2009-11-28 3:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
From: Steve Hodgson <shodgson@solarflare.com>
The strap bits are only important on Falcon A and all production
boards using it have fixed-speed 10G PHYs.
Replace dummy MAC operations with default MAC operations.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/efx.c | 6 +-----
drivers/net/sfc/falcon.c | 15 ++++++++++++---
drivers/net/sfc/net_driver.h | 3 +++
3 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/net/sfc/efx.c b/drivers/net/sfc/efx.c
index 6338ad8..bed45a5 100644
--- a/drivers/net/sfc/efx.c
+++ b/drivers/net/sfc/efx.c
@@ -1891,10 +1891,6 @@ bool efx_port_dummy_op_poll(struct efx_nic *efx)
return false;
}
-static struct efx_mac_operations efx_dummy_mac_operations = {
- .reconfigure = efx_port_dummy_op_void,
-};
-
static struct efx_phy_operations efx_dummy_phy_operations = {
.init = efx_port_dummy_op_int,
.reconfigure = efx_port_dummy_op_void,
@@ -1936,7 +1932,7 @@ static int efx_init_struct(struct efx_nic *efx, struct efx_nic_type *type,
spin_lock_init(&efx->netif_stop_lock);
spin_lock_init(&efx->stats_lock);
mutex_init(&efx->mac_lock);
- efx->mac_op = &efx_dummy_mac_operations;
+ efx->mac_op = type->default_mac_ops;
efx->phy_op = &efx_dummy_phy_operations;
efx->mdio.dev = net_dev;
INIT_WORK(&efx->mac_work, efx_mac_work);
diff --git a/drivers/net/sfc/falcon.c b/drivers/net/sfc/falcon.c
index 372dbbc..9c4f898 100644
--- a/drivers/net/sfc/falcon.c
+++ b/drivers/net/sfc/falcon.c
@@ -2291,6 +2291,10 @@ int falcon_probe_port(struct efx_nic *efx)
efx->mdio.mdio_read = falcon_mdio_read;
efx->mdio.mdio_write = falcon_mdio_write;
+ /* Initial assumption */
+ efx->link_state.speed = 10000;
+ efx->link_state.fd = true;
+
/* Hardware flow ctrl. FalconA RX FIFO too small for pause generation */
if (falcon_rev(efx) >= FALCON_REV_B0)
efx->wanted_fc = EFX_FC_RX | EFX_FC_TX;
@@ -2809,6 +2813,10 @@ static int falcon_probe_nic_variant(struct efx_nic *efx)
return -ENODEV;
case FALCON_REV_A1:
+ if (EFX_OWORD_FIELD(nic_stat, FRF_AB_STRAP_10G) == 0) {
+ EFX_ERR(efx, "Falcon rev A1 1G not supported\n");
+ return -ENODEV;
+ }
if (EFX_OWORD_FIELD(nic_stat, FRF_AA_STRAP_PCIE) == 0) {
EFX_ERR(efx, "Falcon rev A1 PCI-X not supported\n");
return -ENODEV;
@@ -2823,9 +2831,6 @@ static int falcon_probe_nic_variant(struct efx_nic *efx)
return -ENODEV;
}
- /* Initial assumed speed */
- efx->link_state.speed = EFX_OWORD_FIELD(nic_stat, FRF_AB_STRAP_10G) ? 10000 : 1000;
-
return 0;
}
@@ -3238,6 +3243,8 @@ void falcon_stop_nic_stats(struct efx_nic *efx)
*/
struct efx_nic_type falcon_a_nic_type = {
+ .default_mac_ops = &falcon_xmac_operations,
+
.mem_map_size = 0x20000,
.txd_ptr_tbl_base = FR_AA_TX_DESC_PTR_TBL_KER,
.rxd_ptr_tbl_base = FR_AA_RX_DESC_PTR_TBL_KER,
@@ -3251,6 +3258,8 @@ struct efx_nic_type falcon_a_nic_type = {
};
struct efx_nic_type falcon_b_nic_type = {
+ .default_mac_ops = &falcon_xmac_operations,
+
/* Map everything up to and including the RSS indirection
* table. Don't map MSI-X table, MSI-X PBA since Linux
* requires that they not be mapped. */
diff --git a/drivers/net/sfc/net_driver.h b/drivers/net/sfc/net_driver.h
index 0aeaeda..57f8614 100644
--- a/drivers/net/sfc/net_driver.h
+++ b/drivers/net/sfc/net_driver.h
@@ -843,6 +843,7 @@ static inline const char *efx_dev_name(struct efx_nic *efx)
/**
* struct efx_nic_type - Efx device type definition
+ * @default_mac_ops: efx_mac_operations to set at startup
* @mem_map_size: Memory BAR mapped size
* @txd_ptr_tbl_base: TX descriptor ring base address
* @rxd_ptr_tbl_base: RX descriptor ring base address
@@ -857,6 +858,8 @@ static inline const char *efx_dev_name(struct efx_nic *efx)
* descriptors
*/
struct efx_nic_type {
+ struct efx_mac_operations *default_mac_ops;
+
unsigned int mem_map_size;
unsigned int txd_ptr_tbl_base;
unsigned int rxd_ptr_tbl_base;
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ 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