[E1000-devel] [PATCH] igbvf: avoid name clash between PF and VF
From: Stefan Assmann It looks like the VFs get initialized before all the PFs are. Therefore the udev mapping MAC <-> ethX (for PFs) gets screwed because the VFs may grab the ethX interface names (reserved by udev) for the PFs. Example: igb max_vfs=0 eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E eth1 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F eth2 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0 eth3 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1 igb max_vfs=1 eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E eth1 Link encap:Ethernet HWaddr 0A:CF:41:69:F7:A9 eth2 Link encap:Ethernet HWaddr 3A:FE:20:4C:2A:3B eth3 Link encap:Ethernet HWaddr C6:C3:B1:56:C9:A4 eth3_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F eth4 Link encap:Ethernet HWaddr 6E:8A:8A:A3:5F:69 eth4_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0 eth5_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1 In the example above VF 0A:CF:41:69:F7:A9 grabs eth1 but udev has a rule that says eth1 should be assigned PF 00:13:20:F7:A5:9F (eth3_rename) and waits for the VF to disappear to rename eth3_rename to eth1. Unfortunately eth1 is not going to disappear. This is not a udev bug since udev doesn't create persistent rules for VFs as their MAC address changes every reboot. To avoid this problem we could change the kernel name for the VFs and thus avoid confusion between VFs and PFs. I've already discussed this with Alexander Duyck and Greg Rose, so far they have no objection. However this problem appears for all drivers that support PFs and VFs and thus the changes should be applied consistently to all of these drivers. Signed-off-by: Stefan Assmann --- drivers/net/igbvf/netdev.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/igbvf/netdev.c b/drivers/net/igbvf/netdev.c index 5e2b2a8..2fb665b 100644 --- a/drivers/net/igbvf/netdev.c +++ b/drivers/net/igbvf/netdev.c @@ -2787,7 +2787,7 @@ static int __devinit igbvf_probe(struct pci_dev *pdev, netif_carrier_off(netdev); netif_stop_queue(netdev); - strcpy(netdev->name, "eth%d"); + strcpy(netdev->name, "veth%d"); err = register_netdev(netdev); if (err) goto err_hw_init; -- 1.6.5.2 -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH] igbvf: avoid name clash between PF and VF
On 30.06.2010 12:44, Ben Hutchings wrote: > On Wed, 2010-06-30 at 10:53 +0200, Stefan Assmann wrote: >> From: Stefan Assmann >> >> It looks like the VFs get initialized before all the PFs are. Therefore >> the udev mapping MAC <-> ethX (for PFs) gets screwed because the VFs >> may grab the ethX interface names (reserved by udev) for the PFs. >> >> Example: >> igb max_vfs=0 >> eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E >> eth1 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F >> eth2 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0 >> eth3 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1 >> igb max_vfs=1 >> eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E >> eth1 Link encap:Ethernet HWaddr 0A:CF:41:69:F7:A9 >> eth2 Link encap:Ethernet HWaddr 3A:FE:20:4C:2A:3B >> eth3 Link encap:Ethernet HWaddr C6:C3:B1:56:C9:A4 >> eth3_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F >> eth4 Link encap:Ethernet HWaddr 6E:8A:8A:A3:5F:69 >> eth4_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0 >> eth5_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1 >> >> In the example above VF 0A:CF:41:69:F7:A9 grabs eth1 but udev >> has a rule that says eth1 should be assigned PF 00:13:20:F7:A5:9F >> (eth3_rename) and waits for the VF to disappear to rename eth3_rename >> to eth1. Unfortunately eth1 is not going to disappear. >> This is not a udev bug since udev doesn't create persistent rules for >> VFs as their MAC address changes every reboot. > [...] > > I think it is a bug in the udev rules: udev should rename the VFs even > though their names won't be persistent. In that case let's Cc udev people. Stefan -- Stefan Assmann | Red Hat GmbH Software Engineer | Otto-Hahn-Strasse 20, 85609 Dornach | HR: Amtsgericht Muenchen HRB 153243 | GF: Brendan Lane, Charlie Peters, sassmann at redhat.com | Michael Cunningham, Charles Cachera -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH] igbvf: avoid name clash between PF and VF
On Wed, 2010-06-30 at 10:53 +0200, Stefan Assmann wrote: > From: Stefan Assmann > > It looks like the VFs get initialized before all the PFs are. Therefore > the udev mapping MAC <-> ethX (for PFs) gets screwed because the VFs > may grab the ethX interface names (reserved by udev) for the PFs. > > Example: > igb max_vfs=0 > eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E > eth1 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F > eth2 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0 > eth3 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1 > igb max_vfs=1 > eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E > eth1 Link encap:Ethernet HWaddr 0A:CF:41:69:F7:A9 > eth2 Link encap:Ethernet HWaddr 3A:FE:20:4C:2A:3B > eth3 Link encap:Ethernet HWaddr C6:C3:B1:56:C9:A4 > eth3_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F > eth4 Link encap:Ethernet HWaddr 6E:8A:8A:A3:5F:69 > eth4_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0 > eth5_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1 > > In the example above VF 0A:CF:41:69:F7:A9 grabs eth1 but udev > has a rule that says eth1 should be assigned PF 00:13:20:F7:A5:9F > (eth3_rename) and waits for the VF to disappear to rename eth3_rename > to eth1. Unfortunately eth1 is not going to disappear. > This is not a udev bug since udev doesn't create persistent rules for > VFs as their MAC address changes every reboot. [...] I think it is a bug in the udev rules: udev should rename the VFs even though their names won't be persistent. Ben. -- 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. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH] igbvf: avoid name clash between PF and VF
On Wed, Jun 30, 2010 at 12:57, Stefan Assmann wrote: > On 30.06.2010 12:44, Ben Hutchings wrote: >> On Wed, 2010-06-30 at 10:53 +0200, Stefan Assmann wrote: >>> From: Stefan Assmann >>> >>> It looks like the VFs get initialized before all the PFs are. Therefore >>> the udev mapping MAC <-> ethX (for PFs) gets screwed because the VFs >>> may grab the ethX interface names (reserved by udev) for the PFs. >>> >>> Example: >>> igb max_vfs=0 >>> eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E >>> eth1 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F >>> eth2 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0 >>> eth3 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1 >>> igb max_vfs=1 >>> eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E >>> eth1 Link encap:Ethernet HWaddr 0A:CF:41:69:F7:A9 >>> eth2 Link encap:Ethernet HWaddr 3A:FE:20:4C:2A:3B >>> eth3 Link encap:Ethernet HWaddr C6:C3:B1:56:C9:A4 >>> eth3_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F >>> eth4 Link encap:Ethernet HWaddr 6E:8A:8A:A3:5F:69 >>> eth4_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0 >>> eth5_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1 >>> >>> In the example above VF 0A:CF:41:69:F7:A9 grabs eth1 but udev >>> has a rule that says eth1 should be assigned PF 00:13:20:F7:A5:9F >>> (eth3_rename) and waits for the VF to disappear to rename eth3_rename >>> to eth1. Unfortunately eth1 is not going to disappear. >>> This is not a udev bug since udev doesn't create persistent rules for >>> VFs as their MAC address changes every reboot. >> [...] >> >> I think it is a bug in the udev rules: udev should rename the VFs even >> though their names won't be persistent. Udev writes out these configs to a rules file, and therefore can never handle random MAC addresses, as they would just accumulate in the rules file with a new entry at every bootup. Stuff like this is just not supported at the moment with the rather simple logic it has, and there is no current plan/idea, or anybody working on changing/improving this at the moment. Kay -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
[E1000-devel] [PATCH net-next-2.6 1/3] ethtool: Change ethtool_op_set_flags to validate flags
ethtool_op_set_flags() does not check for unsupported flags, and has
no way of doing so. This means it is not suitable for use as a
default implementation of ethtool_ops::set_flags.
Add a 'supported' parameter specifying the flags that the driver and
hardware support, validate the requested flags against this, and
change all current callers to pass this parameter.
Change some other trivial implementations of ethtool_ops::set_flags to
call ethtool_op_set_flags().
Signed-off-by: Ben Hutchings
Reviewed-by: Stanislaw Gruszka
Acked-by: Jeff Garzik
---
drivers/net/cxgb4/cxgb4_main.c|9 +
drivers/net/enic/enic_main.c |1 -
drivers/net/ixgbe/ixgbe_ethtool.c |5 -
drivers/net/mv643xx_eth.c |7 ++-
drivers/net/myri10ge/myri10ge.c | 10 +++---
drivers/net/niu.c |9 +
drivers/net/sfc/ethtool.c |5 +
drivers/net/sky2.c| 16 ++--
include/linux/ethtool.h |2 +-
net/core/ethtool.c| 28 +---
10 files changed, 32 insertions(+), 60 deletions(-)
diff --git a/drivers/net/cxgb4/cxgb4_main.c b/drivers/net/cxgb4/cxgb4_main.c
index 6528167..55a720e 100644
--- a/drivers/net/cxgb4/cxgb4_main.c
+++ b/drivers/net/cxgb4/cxgb4_main.c
@@ -1799,14 +1799,7 @@ static int set_tso(struct net_device *dev, u32 value)
static int set_flags(struct net_device *dev, u32 flags)
{
- if (flags & ~ETH_FLAG_RXHASH)
- return -EOPNOTSUPP;
-
- if (flags & ETH_FLAG_RXHASH)
- dev->features |= NETIF_F_RXHASH;
- else
- dev->features &= ~NETIF_F_RXHASH;
- return 0;
+ return ethtool_op_set_flags(dev, flags, ETH_FLAG_RXHASH);
}
static struct ethtool_ops cxgb_ethtool_ops = {
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index 6c6795b..77a7f87 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -365,7 +365,6 @@ static const struct ethtool_ops enic_ethtool_ops = {
.get_coalesce = enic_get_coalesce,
.set_coalesce = enic_set_coalesce,
.get_flags = ethtool_op_get_flags,
- .set_flags = ethtool_op_set_flags,
};
static void enic_free_wq_buf(struct vnic_wq *wq, struct vnic_wq_buf *buf)
diff --git a/drivers/net/ixgbe/ixgbe_ethtool.c
b/drivers/net/ixgbe/ixgbe_ethtool.c
index 873b45e..7d2e5ea 100644
--- a/drivers/net/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ixgbe/ixgbe_ethtool.c
@@ -2205,8 +2205,11 @@ static int ixgbe_set_flags(struct net_device *netdev,
u32 data)
{
struct ixgbe_adapter *adapter = netdev_priv(netdev);
bool need_reset = false;
+ int rc;
- ethtool_op_set_flags(netdev, data);
+ rc = ethtool_op_set_flags(netdev, data, ETH_FLAG_LRO | ETH_FLAG_NTUPLE);
+ if (rc)
+ return rc;
/* if state changes we need to update adapter->flags and reset */
if (adapter->flags2 & IXGBE_FLAG2_RSC_CAPABLE) {
diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index e345ec8..82b720f 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -1636,6 +1636,11 @@ static void mv643xx_eth_get_ethtool_stats(struct
net_device *dev,
}
}
+static int mv643xx_eth_set_flags(struct net_device *dev, u32 data)
+{
+ return ethtool_op_set_flags(dev, data, ETH_FLAG_LRO);
+}
+
static int mv643xx_eth_get_sset_count(struct net_device *dev, int sset)
{
if (sset == ETH_SS_STATS)
@@ -1661,7 +1666,7 @@ static const struct ethtool_ops mv643xx_eth_ethtool_ops =
{
.get_strings= mv643xx_eth_get_strings,
.get_ethtool_stats = mv643xx_eth_get_ethtool_stats,
.get_flags = ethtool_op_get_flags,
- .set_flags = ethtool_op_set_flags,
+ .set_flags = mv643xx_eth_set_flags,
.get_sset_count = mv643xx_eth_get_sset_count,
};
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index e0b47cc..d771d16 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -1730,8 +1730,7 @@ static int myri10ge_set_rx_csum(struct net_device
*netdev, u32 csum_enabled)
if (csum_enabled)
mgp->csum_flag = MXGEFW_FLAGS_CKSUM;
else {
- u32 flags = ethtool_op_get_flags(netdev);
- err = ethtool_op_set_flags(netdev, (flags & ~ETH_FLAG_LRO));
+ netdev->features &= ~NETIF_F_LRO;
mgp->csum_flag = 0;
}
@@ -1900,6 +1899,11 @@ static u32 myri10ge_get_msglevel(struct net_device
*netdev)
return mgp->msg_enable;
}
+static int myri10ge_set_flags(struct net_device *netdev, u32 value)
+{
+ return ethtool_op_set_flags(netdev, value, ETH_FLAG_LRO);
+}
+
static const struct ethtool_ops myri10ge_ethtool_ops = {
.get_settings = myri10ge_get_settings,
.get_drvinfo = myri10ge_get_drvinfo,
Re: [E1000-devel] [PATCH] igbvf: avoid name clash between PF and VF
On 06/30/2010 01:11 PM, Kay Sievers wrote: > On Wed, Jun 30, 2010 at 12:57, Stefan Assmann wrote: >> On 30.06.2010 12:44, Ben Hutchings wrote: >>> On Wed, 2010-06-30 at 10:53 +0200, Stefan Assmann wrote: From: Stefan Assmann It looks like the VFs get initialized before all the PFs are. Therefore the udev mapping MAC<-> ethX (for PFs) gets screwed because the VFs may grab the ethX interface names (reserved by udev) for the PFs. Example: igb max_vfs=0 eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E eth1 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F eth2 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0 eth3 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1 igb max_vfs=1 eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E eth1 Link encap:Ethernet HWaddr 0A:CF:41:69:F7:A9 eth2 Link encap:Ethernet HWaddr 3A:FE:20:4C:2A:3B eth3 Link encap:Ethernet HWaddr C6:C3:B1:56:C9:A4 eth3_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F eth4 Link encap:Ethernet HWaddr 6E:8A:8A:A3:5F:69 eth4_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0 eth5_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1 In the example above VF 0A:CF:41:69:F7:A9 grabs eth1 but udev has a rule that says eth1 should be assigned PF 00:13:20:F7:A5:9F (eth3_rename) and waits for the VF to disappear to rename eth3_rename to eth1. Unfortunately eth1 is not going to disappear. This is not a udev bug since udev doesn't create persistent rules for VFs as their MAC address changes every reboot. >>> [...] >>> >>> I think it is a bug in the udev rules: udev should rename the VFs even >>> though their names won't be persistent. > > Udev writes out these configs to a rules file, and therefore can never > handle random MAC addresses, as they would just accumulate in the > rules file with a new entry at every bootup. > > Stuff like this is just not supported at the moment with the rather > simple logic it has, and there is no current plan/idea, or anybody > working on changing/improving this at the moment. > > Kay Solution: move away from the "eth*" namespace and use "net*" for configured interfaces. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] very weird dhcp problem ...
On 29/06/10 14:51, Allan, Bruce W wrote: > On Tuesday, June 29, 2010 9:14 AM, K. Posern wrote: >> Hi, >> >> I really hope you might give me a hint and/or can refer me to somebody >> to help me with the below problem. >> >> I am having a really weird problem with getting an IP with dhcp. >> BUT only at my work place - and it works fine for everybody else there >> AND it works fine for me if I MANUALLY run the dhcp-client! >> >> ... >> >> And honestly I have no clue anymore :( >> And I am beginning to think that this /must/ be a bug somewhere. But I >> have even no clue in which of the involded components the problem >> could reside (as P.S. to this mail I listed details about all involved >> components). >> >> So here are the 2 ways of invoking the dhcp client I am using: >> >> /1st/ >> I am using netplugd (see /// ABOUT MY MACHINE ///) to start either the >> gentoo startup-script /etc/init.d/net.eth0 which then starts the dhcp >> client /OR/ a script started by netplugd (both ran as root) to start >> the dhcp program. >> And this JUST DOES NOT WORK: >> >> I can see with ps the dhcp client running: >> pixel ~ # ps faux|grep -i dhc >> root 332 0.0 0.0 4200 616 pts/6S+ 22:22 0:00 >>| \_ grep --colour=auto -i dhc >> root 32751 0.0 0.0 1828 308 ?Ss 22:22 0:00 >> /sbin/dhcpcd eth0 >> >> And I see its output in the syslog: >> Jun 28 17:27:45 [dhcpcd] eth0: dhcpcd 4.0.15 starting >> Jun 28 17:27:45 [dhcpcd] eth0: broadcasting for a lease >> Jun 28 17:27:57 [acpid] ACPI Battery Event: 88% >> - Last output repeated 2 times - >> Jun 28 17:28:15 [dhcpcd] eth0: timed out >> >> And I can see the dhcp/bootp packets: >> I captured the attached network traffic with wireshark. >> >> There you can see: Repeated dhcp requests >> (until the dhcp times out), but no responses! >> >> /2nd/ >> As root I copy and paste the exact command I see in ps above and >> voila. >> In about 1 second I get my ip! >> >> Again the syslog: >> Jun 28 17:28:54 [dhcpcd] eth0: dhcpcd 4.0.15 starting >> Jun 28 17:28:55 [dhcpcd] eth0: broadcasting for a lease >> Jun 28 17:28:55 [dhcpcd] eth0: offered 192.168.0.64 from 192.168.0.1 >> Jun 28 17:28:55 [dhcpcd] eth0: acknowledged 192.168.0.64 from >> 192.168.0.1 Jun 28 17:28:55 [dhcpcd] eth0: checking 192.168.0.64 is >> available on attached networks >> >> In the attached wireshark capture I have two files: one complete >> capture and one filtered for bootp. For now I only attached the >> filtered one. >> In there you will find first the above failure and then the above >> success (to the LAST of the dhcp requests, is the one triggered by the >> /2nd/ trial all the other requests before belong to the failed /1st/ >> trial). I also (tried to) compare the packets (I picked the FIRST >> dhcp request (of the failed /1st/ trial) and the dhcp-request of the >> successful /2nd/ trial: I only see a different transactionID and >> thous two different hashsums, otherwise they seem bit for bit >> identical! >> >> As dhcp clients I already tried these both: dhcpcd and pump (see /// >> ABOUT MY MACHINE ///). >> --> Identical results. >> >> I also tried to invoke the dhcp client instead of just: >> /sbin/dhcpcd eth0 >> within a login shell to avoid any ENVIRONMENT differences: >> /bin/sh -l -c '/sbin/dhcpcd eth0' >> --> Identical results. >> >> In the P.S. you will find more details about "ALL THE INVOLVED >> COMPONENTS". >> >> So I honestly don't know what to do anymore. But I would like to >> UNDERSTAND WHY it is not working even though it should be working and >> even though I see the identical dhcp-request two times on the wire, >> but >> in only ONE case I get a response in the other I get seemingly nothing >> back!? >> >> Any help/hint is greatly appreciated. >> And of course I would be eager to provide you with any more debug >> information you could/would need! >> >> Thanks a lot!!! >> >> Best, >> >> Knuth >> >> >> P.S.: ALL THE INVOLVED COMPONENTS: >> >> / >> /// ABOUT MY MACHINE /// >> I am using a TOSHIBA notebook with an INTEL network adapter: >> 01:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet >> Controller >> >> Wireless is turned off. >> >> uname -a: >> Linux pixel 2.6.31.3-nogo-pixel #1 SMP PREEMPT Mon Dec 7 01:14:18 EST >> 2009 i686 Intel(R) Core(TM)2 CPU U7600 @ 1.20GHz GenuineIntel >> GNU/Linux >> >> Gentoo Linux 32-bit >> >> The dhcp clients I am using: >> [I] net-misc/dhcpcd >> Installed versions: 4.0.15(02:33:39 03/12/09)(compat -zeroconf) >> >> [I] net-misc/pump >> Installed versions: 0.8.24-r3(02:41:08 03/12/09) >> >> The netplug I am using: >> [I] sys-apps/netplug >> Installed versions: 1.2.9.1(20:57:30 27/09/09) >> >> When I am using netplugd it seems to work just fine: >> If I plug the network cable --> I see in the syslog: >> Jun 29 09:49:08 [netplugd] eth0:
Re: [E1000-devel] very weird dhcp problem ...
On Wednesday, June 30, 2010 10:09 AM, K. Posern wrote: > Hi, > > Thanks for the answer! > > Just to confirm that my problem is clear: > pump and dhcpcd work, but only when I invoke it on the command line. > > I checked what my colleagues with their Ubuntu distros use: > dhclient v3.1 > > I tried dhclient v3.1.2 --> it worked! Below you will see the syslog: > It > is *much* slower though than dhclient or pump when run from > commandline!? > > I just updated to the latest (available) version of dhcpcd (v5.2.5) > (Because the author of dhcpcd answered me: > ) > But it seems to have the SAME problem like the v4 I used before: > Jun 30 12:55:01 [dhcpcd] version 5.2.5 starting > Jun 30 12:55:02 [dhcpcd] eth0: broadcasting for a lease > Jun 30 12:55:12 [acpid] ACPI Battery Event: 50% > - Last output repeated twice - > Jun 30 12:55:32 [dhcpcd] timed out > > > Should I still look into the latest driver from > http://e1000.sourceforge.net driver (and see if this makes any > difference on the 3 dhcp clients at hand)? > > If you want I can help you debug some more! > Or does this mean that it *must* be a dhcpcd/pump client problem at > this point?! > > Thanks! > > Knuth > > P.S. > > Here is the successfull run of dhclient: > > Jun 30 13:00:12 [dhclient] Internet Systems Consortium DHCP Client > V3.1.2p1-Gentoo > Jun 30 13:00:12 [dhclient] Copyright 2004-2009 Internet Systems > Consortium. Jun 30 13:00:12 [dhclient] All rights reserved. > Jun 30 13:00:12 [dhclient] For info, please visit > http://www.isc.org/sw/dhcp/ > Jun 30 13:00:13 [dhclient] Listening on LPF/eth0/00:1c:7e:0e:f6:1e > Jun 30 13:00:13 [dhclient] Sending on LPF/eth0/00:1c:7e:0e:f6:1e > Jun 30 13:00:13 [dhclient] Sending on Socket/fallback > Jun 30 13:00:13 [dhclient] DHCPREQUEST on eth0 to 255.255.255.255 > port 67 Jun 30 13:00:14 [acpid] ACPI Battery Event: 53% > Jun 30 13:00:17 [dhclient] DHCPREQUEST on eth0 to 255.255.255.255 > port 67 Jun 30 13:00:27 [dhclient] DHCPDISCOVER on eth0 to > 255.255.255.255 port 67 interval 5 > Jun 30 13:00:30 [acpid] ACPI Battery Event: 53% > Jun 30 13:00:32 [dhclient] DHCPDISCOVER on eth0 to 255.255.255.255 > port 67 interval 6 > Jun 30 13:00:38 [dhclient] DHCPDISCOVER on eth0 to 255.255.255.255 > port 67 interval 14 > Jun 30 13:00:46 [acpid] ACPI Battery Event: 54% > Jun 30 13:00:52 [dhclient] DHCPDISCOVER on eth0 to 255.255.255.255 > port 67 interval 19 > Jun 30 13:00:52 [dhclient] DHCPOFFER from 192.168.0.1 > Jun 30 13:00:52 [dhclient] DHCPREQUEST on eth0 to 255.255.255.255 > port 67 Jun 30 13:00:52 [dhclient] DHCPACK from 192.168.0.1 > Jun 30 13:00:52 [dhclient] bound to 192.168.0.64 -- renewal in 2866 > seconds. If you have the time, it would be great if you could try the latest e1000e driver (vers 1.2.8) from e1000.sf.net - I am wondering if the changes to the driver's link reporting code (one change that went into the kernel for 2.6.29 and another that went in for 2.6.33) may have broken interoperability with dhcpcd. The sourceforge driver has yet another change that might fix any such issue. Thanks, Bruce. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH] igbvf: avoid name clash between PF and VF
| From: Stefan Assmann | Date: Wednesday, June 30, 2010 01:53 am | | This is not a udev bug since udev doesn't create persistent rules for | VFs as their MAC address changes every reboot. | | To avoid this problem we could change the kernel name for the VFs and | thus avoid confusion between VFs and PFs. | | I've already discussed this with Alexander Duyck and Greg Rose, so far | they have no objection. However this problem appears for all drivers that | support PFs and VFs and thus the changes should be applied consistently | to all of these drivers. I'm not sure that this problem affects "all drivers which support PFs and VFs." I think that you might mean "all drivers which support PFs and VFs with non- persistent MAC addresses for the VFs." For instance, the MAC addresses associated with the new cxgb4vf VFs are persistent so, from what I understand of the scenario you outlined, I don't think that they would trigger the problem you describe. Please correct me if I've missed something. Thanks. Casey -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net-next-2.6 1/3] ethtool: Change ethtool_op_set_flags to validate flags
From: Ben Hutchings Date: Wed, 30 Jun 2010 13:44:32 +0100 > ethtool_op_set_flags() does not check for unsupported flags, and has > no way of doing so. This means it is not suitable for use as a > default implementation of ethtool_ops::set_flags. > > Add a 'supported' parameter specifying the flags that the driver and > hardware support, validate the requested flags against this, and > change all current callers to pass this parameter. > > Change some other trivial implementations of ethtool_ops::set_flags to > call ethtool_op_set_flags(). > > Signed-off-by: Ben Hutchings > Reviewed-by: Stanislaw Gruszka > Acked-by: Jeff Garzik Applied. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] very weird dhcp problem ...
On 30/06/10 13:50, Allan, Bruce W wrote: > On Wednesday, June 30, 2010 10:09 AM, K. Posern wrote: >> Hi, >> >> Thanks for the answer! >> >> Just to confirm that my problem is clear: >> pump and dhcpcd work, but only when I invoke it on the command line. >> >> I checked what my colleagues with their Ubuntu distros use: >> dhclient v3.1 >> >> I tried dhclient v3.1.2 --> it worked! Below you will see the syslog: >> It >> is *much* slower though than dhclient or pump when run from >> commandline!? >> >> I just updated to the latest (available) version of dhcpcd (v5.2.5) >> (Because the author of dhcpcd answered me: >> ) >> But it seems to have the SAME problem like the v4 I used before: >> Jun 30 12:55:01 [dhcpcd] version 5.2.5 starting >> Jun 30 12:55:02 [dhcpcd] eth0: broadcasting for a lease >> Jun 30 12:55:12 [acpid] ACPI Battery Event: 50% >> - Last output repeated twice - >> Jun 30 12:55:32 [dhcpcd] timed out >> >> >> Should I still look into the latest driver from >> http://e1000.sourceforge.net driver (and see if this makes any >> difference on the 3 dhcp clients at hand)? >> >> If you want I can help you debug some more! >> Or does this mean that it *must* be a dhcpcd/pump client problem at >> this point?! >> >> Thanks! >> >> Knuth >> >> P.S. >> >> Here is the successfull run of dhclient: >> >> Jun 30 13:00:12 [dhclient] Internet Systems Consortium DHCP Client >> V3.1.2p1-Gentoo >> Jun 30 13:00:12 [dhclient] Copyright 2004-2009 Internet Systems >> Consortium. Jun 30 13:00:12 [dhclient] All rights reserved. >> Jun 30 13:00:12 [dhclient] For info, please visit >> http://www.isc.org/sw/dhcp/ >> Jun 30 13:00:13 [dhclient] Listening on LPF/eth0/00:1c:7e:0e:f6:1e >> Jun 30 13:00:13 [dhclient] Sending on LPF/eth0/00:1c:7e:0e:f6:1e >> Jun 30 13:00:13 [dhclient] Sending on Socket/fallback >> Jun 30 13:00:13 [dhclient] DHCPREQUEST on eth0 to 255.255.255.255 >> port 67 Jun 30 13:00:14 [acpid] ACPI Battery Event: 53% >> Jun 30 13:00:17 [dhclient] DHCPREQUEST on eth0 to 255.255.255.255 >> port 67 Jun 30 13:00:27 [dhclient] DHCPDISCOVER on eth0 to >> 255.255.255.255 port 67 interval 5 >> Jun 30 13:00:30 [acpid] ACPI Battery Event: 53% >> Jun 30 13:00:32 [dhclient] DHCPDISCOVER on eth0 to 255.255.255.255 >> port 67 interval 6 >> Jun 30 13:00:38 [dhclient] DHCPDISCOVER on eth0 to 255.255.255.255 >> port 67 interval 14 >> Jun 30 13:00:46 [acpid] ACPI Battery Event: 54% >> Jun 30 13:00:52 [dhclient] DHCPDISCOVER on eth0 to 255.255.255.255 >> port 67 interval 19 >> Jun 30 13:00:52 [dhclient] DHCPOFFER from 192.168.0.1 >> Jun 30 13:00:52 [dhclient] DHCPREQUEST on eth0 to 255.255.255.255 >> port 67 Jun 30 13:00:52 [dhclient] DHCPACK from 192.168.0.1 >> Jun 30 13:00:52 [dhclient] bound to 192.168.0.64 -- renewal in 2866 >> seconds. > > If you have the time, it would be great if you could try the latest e1000e > driver (vers 1.2.8) from e1000.sf.net - I am wondering if the changes to the > driver's link reporting code (one change that went into the kernel for 2.6.29 > and another that went in for 2.6.33) may have broken interoperability with > dhcpcd. The sourceforge driver has yet another change that might fix any > such issue. So here are the results with e100e v1.2.8 (details see below) - in comparison with the in-kernel 2.6.31.3 driver: * dhclient v3.1.2: Still working (when called within the init script /or/ via netplugd - only works, when called from a root terminal) - syslog details below But much slower than on the commandline - details below * dhcpcd v5.1.5: Still not working (when called within the init script /or/ via netplugd - only works, when called from a root terminal) - syslog details below * pump v0.8.24: Still not working (when called within the init script /or/ via netplugd - only works, when called from a root terminal) - syslog details below On Friday I might be able to get packet-dumps for the 3 dhcp-clients if this would help?! Best, Knuth P.S.: E1000E MODULE INIT Jun 30 18:07:25 [kernel] [ 2205.043312] e1000e: Intel(R) PRO/1000 Network Driver - 1.2.8-NAPI Jun 30 18:07:25 [kernel] [ 2205.043318] e1000e: Copyright(c) 1999 - 2010 Intel Corporation. Jun 30 18:07:25 [kernel] [ 2205.043482] e1000e :01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 Jun 30 18:07:25 [kernel] [ 2205.043613] e1000e :01:00.0: setting latency timer to 64 Jun 30 18:07:25 [kernel] [ 2205.044461] e1000e :01:00.0: (unregistered net_device): Failed to initialize MSI interrupts. Falling back to legacy interrupts. Jun 30 18:07:25 [kernel] [ 2205.044493] e1000e :01:00.0: Disabling ASPM L0s Jun 30 18:07:25 [kernel] [ 2205.165524] e1000e :01:00.0: eth0: (PCI Express:2.5GB/s:Width x1) 00:1c:7e:0e:f6:1e Jun 30 18:07:25 [kernel] [ 2205.165532] e1000e :01:00.0: eth0: Intel(R) PRO/1000 Network Connection Jun 30 18:07:25 [kernel] [ 2205.165655] e1000e :01:00.0: eth0: MAC: 3, PHY: 2, PBA No: ff-0ff DETAILS FOR DHCLIENT ///
Re: [E1000-devel] [PATCH] igbvf: avoid name clash between PF and VF
On 30.06.2010 18:59, Casey Leedom wrote: > | From: Stefan Assmann > | Date: Wednesday, June 30, 2010 01:53 am > | > | This is not a udev bug since udev doesn't create persistent rules for > | VFs as their MAC address changes every reboot. > | > | To avoid this problem we could change the kernel name for the VFs and > | thus avoid confusion between VFs and PFs. > | > | I've already discussed this with Alexander Duyck and Greg Rose, so far > | they have no objection. However this problem appears for all drivers that > | support PFs and VFs and thus the changes should be applied consistently > | to all of these drivers. > > I'm not sure that this problem affects "all drivers which support PFs and > VFs." > I think that you might mean "all drivers which support PFs and VFs with non- > persistent MAC addresses for the VFs." For instance, the MAC addresses > associated with the new cxgb4vf VFs are persistent so, from what I understand > of > the scenario you outlined, I don't think that they would trigger the problem > you > describe. Please correct me if I've missed something. Thanks. > > Casey You're correct, the problem shouldn't occur with cxgb4vf and therefore this change shouldn't be necessary. However we might consider a consistent naming scheme for VFs in all drivers. But I don't have a strong opinion about this, either way would be fine by me. Stefan -- Stefan Assmann | Red Hat GmbH Software Engineer | Otto-Hahn-Strasse 20, 85609 Dornach | HR: Amtsgericht Muenchen HRB 153243 | GF: Brendan Lane, Charlie Peters, sassmann at redhat.com | Michael Cunningham, Charles Cachera -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
