* Re: [2/3] 2.6.23-rc1: known regressions v2
From: Michal Piotrowski @ 2007-07-27 20:53 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, LKML, Eric Sesterhenn, Sid Boyce, linux-ide,
Bartlomiej Zolnierkiewicz, dth, Netdev, Stephen Hemminger,
Thomas Meyer, Florian Lohoff
In-Reply-To: <46AA581D.6080100@googlemail.com>
Hi all,
Here is a list of some known regressions in 2.6.23-rc1.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
Name Regressions fixed since 21-Jun-2007
Adrian Bunk 6
Andi Kleen 4
Andrew Morton 4
Linus Torvalds 4
Al Viro 3
Jens Axboe 3
Tejun Heo 3
David Woodhouse 2
Hugh Dickins 2
Unclassified
Subject : 2.6.23-rc1-git3 init failure
References : http://lkml.org/lkml/2007/7/26/467
Last known good : ?
Submitter : Sid Boyce <g3vbv@blueyonder.co.uk>
Caused-By : ?
Handled-By : ?
Status : unknown
Subject : Time Problems with 2.6.23-rc1-gf695baf2
References : http://lkml.org/lkml/2007/7/23/486
Last known good : ?
Submitter : Eric Sesterhenn <snakebyte@gmx.de>
Caused-By : ?
Handled-By : ?
Status : problem is being debugged
IDE
Subject : ide problems: 2.6.22-git17 working, 2.6.23-rc1* is not
References : http://lkml.org/lkml/2007/7/27/298
Last known good : ?
Submitter : dth <dth@dth.net>
Caused-By : ?
Handled-By : ?
Status : unknown
Networking
Subject : sky2 boot crash in sky2_mac_intr
References : http://lkml.org/lkml/2007/7/24/91
Last known good : ?
Submitter : Florian Lohoff <flo@rfc822.org>
Caused-By :
Handled-By : Stephen Hemminger <shemminger@osdl.org>
Status : unknown
Subject : New wake ups from sky2
References : http://lkml.org/lkml/2007/7/20/386
Last known good : ?
Submitter : Thomas Meyer <thomas@m3y3r.de>
Caused-By : Stephen Hemminger <shemminger@osdl.org>
commit eb35cf60e462491249166182e3e755d3d5d91a28
Handled-By : Stephen Hemminger <shemminger@osdl.org>
Status : unknown
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
^ permalink raw reply
* Re: [PATCH 0/2] HW VLAN filtering control
From: Ben Greear @ 2007-07-27 21:06 UTC (permalink / raw)
To: Mitch Williams; +Cc: netdev
In-Reply-To: <1185569723.28574.8.camel@strongmad>
Mitch Williams wrote:
> This patchset adds the capability to disable hardware VLAN filtering at
> runtime via the existing vconfig utility. It's useful for debugging
> purposes.
>
> The first patch modifies the VLAN subsystem to define the flag, and to
> support passing the flag on to the base driver.
>
> The second patch modifies e1000 to support the flag. Since it's only
> one function, other drivers can be easily modified to support this
> functionality.
>
> vconfig is used without modification to enable or disable filtering:
> # vconfig [vlan-interface] 2 1
> will disable filtering, and
> # vconfig [vlan-interface] 2 0
> will enable filtering.
This looks fine to me.
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* RFC/Progress update: e1000e pci-express -only e1000 driver
From: Kok, Auke @ 2007-07-27 21:12 UTC (permalink / raw)
To: Jeff Garzik, NetDev; +Cc: Arjan van de Ven, Ronciak, John
All,
Here's a short update on progress with e1000e, the future pci-express -only
version of the current e1000 driver. Since about a month ago, a lot has changed
so I'd like to keep everyone posted on progress and solicit ideas.
What happened since I posted "e1000new" ? Here's a summary:
* e1000new was renamed to e1000e and all non-pcie hardware support was dropped
from this driver (all 8254* chipsets).
* after this stage, I removed all code that handled the flags (32 or so) that
are no longer used or obsolete since they are always enabled (e.g. all devices
have msi)
* Removed non-essential module parameters (e.g. speed, duplex, flowcontrol)
* Removed all multi-queue code
* Filtered all unused macro's and define's out (about 700 or so)
* converted the bitfields into other flag types
* filtered out unreached code (for non-supported phy types, bus types in the
pci-e adapters)
Please note that I'm basically coding e1000e for all pcie adapters, but the
first merge will only enable ich9 devices (by masking the device IDs). This will
allow me to develop the code with an eye on all devices and structure, while not
removing code that we might need later anyway.
After that the main issue is the internal API. I've started to give it a diet
mainly for two reasons:
1) lots of obfuscating wrappers and indirection
2) once I remove the lot of those where possible, things should become a bit
more clear where we can go since it's going to be more easy to find the cases we
can eliminate or cleanup.
I'm now at this phase and still working on it, so this is all major work in
progress.
Since this obviously is going to take me more time, I hope to post these updates
every two weeks or so, so people can give the driver a try (it's largely
untested of course) and review the direction that I'm headed in.
The patches are available on http:
http://foo-projects.org/~sofar/e1000e-1.patch [585k]
http://foo-projects.org/~sofar/e1000e-1.patch.bz2 [93k]
Feel free to suggest and comment. Better now then later ;)
Cheers,
Auke
^ permalink raw reply
* Re: [PATCH 0/2] HW VLAN filtering control
From: Mitch Williams @ 2007-07-27 21:23 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <46AA5E4F.4090005@candelatech.com>
On Fri, 2007-07-27 at 14:06 -0700, Ben Greear wrote:
> This looks fine to me.
>
> Ben
>
Grr. Except that Evolution mangled them. I'll have to repost.
-Mitch
^ permalink raw reply
* [PATCH 0/2] HW VLAN filtering control (resend)
From: Mitch Williams @ 2007-07-27 21:30 UTC (permalink / raw)
To: netdev
This patchset adds the capability to disable hardware VLAN filtering at
runtime via the existing vconfig utility. It's useful for debugging
purposes.
The first patch modifies the VLAN subsystem to define the flag, and to
support passing the flag on to the base driver.
The second patch modifies e1000 to support the flag. Since it's only
one function, other drivers can be easily modified to support this
functionality.
vconfig is used without modification to enable or disable filtering:
# vconfig [vlan-interface] 2 1
will disable filtering, and
# vconfig [vlan-interface] 2 0
will enable filtering.
(Now with non-mangled goodness.)
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
^ permalink raw reply
* [PATCH 1/2] HW VLAN filtering control (resend)
From: Mitch Williams @ 2007-07-27 21:30 UTC (permalink / raw)
To: netdev
Add support to the VLAN subsystem for enabling/disabling hardware VLAN
filtering at runtime. This is useful for debugging purposes.
The existing vconfig utility can be used without modification.
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
diff -urpN -X dontdiff linux-2.6.22.1-clean/include/linux/if_vlan.h linux-2.6.22.1/include/linux/if_vlan.h
--- linux-2.6.22.1-clean/include/linux/if_vlan.h 2007-07-10 11:56:30.000000000 -0700
+++ linux-2.6.22.1/include/linux/if_vlan.h 2007-07-26 16:29:00.000000000 -0700
@@ -106,7 +106,20 @@ struct vlan_priority_tci_mapping {
*/
struct vlan_priority_tci_mapping *next;
};
-
+#define VLAN_FLAG_REORDER 1 /* (1 << 0) re_order_header This option will cause the
+ * VLAN code to move around the ethernet header on
+ * ingress to make the skb look **exactly** like it
+ * came in from an ethernet port. This destroys some of
+ * the VLAN information in the skb, but it fixes programs
+ * like DHCP that use packet-filtering and don't understand
+ * 802.1Q
+ */
+
+#define VLAN_FLAG_DISABLE_FILTER 2 /* (1 << 1) disable HW filtering. This flag allows
+ * devices that perform hardware filtering to
+ * turn off filtering. This may be useful for
+ * debugging or for sniffer applications.
+ */
/* Holds information that makes sense if this device is a VLAN device. */
struct vlan_dev_info {
/** This will be the mapping that correlates skb->priority to
@@ -116,14 +129,7 @@ struct vlan_dev_info {
struct vlan_priority_tci_mapping *egress_priority_map[16]; /* hash table */
unsigned short vlan_id; /* The VLAN Identifier for this interface. */
- unsigned short flags; /* (1 << 0) re_order_header This option will cause the
- * VLAN code to move around the ethernet header on
- * ingress to make the skb look **exactly** like it
- * came in from an ethernet port. This destroys some of
- * the VLAN information in the skb, but it fixes programs
- * like DHCP that use packet-filtering and don't understand
- * 802.1Q
- */
+ unsigned short flags;
struct dev_mc_list *old_mc_list; /* old multi-cast list for the VLAN interface..
* we save this so we can tell what changes were
* made, in order to feed the right changes down
diff -urpN -X dontdiff linux-2.6.22.1-clean/include/linux/netdevice.h linux-2.6.22.1/include/linux/netdevice.h
--- linux-2.6.22.1-clean/include/linux/netdevice.h 2007-07-10 11:56:30.000000000 -0700
+++ linux-2.6.22.1/include/linux/netdevice.h 2007-07-26 16:29:00.000000000 -0700
@@ -522,7 +522,9 @@ struct net_device
unsigned short vid);
void (*vlan_rx_kill_vid)(struct net_device *dev,
unsigned short vid);
-
+#define HAVE_VLAN_FLAGS
+ int (*vlan_set_flag)(struct net_device *dev,
+ unsigned int flag, int value);
int (*hard_header_parse)(struct sk_buff *skb,
unsigned char *haddr);
int (*neigh_setup)(struct net_device *dev, struct neigh_parms *);
diff -urpN -X dontdiff linux-2.6.22.1-clean/net/8021q/vlan_dev.c linux-2.6.22.1/net/8021q/vlan_dev.c
--- linux-2.6.22.1-clean/net/8021q/vlan_dev.c 2007-07-10 11:56:30.000000000 -0700
+++ linux-2.6.22.1/net/8021q/vlan_dev.c 2007-07-27 11:40:22.000000000 -0700
@@ -593,37 +593,58 @@ int vlan_dev_set_egress_priority(char *d
/* Flags are defined in the vlan_dev_info class in include/linux/if_vlan.h file. */
int vlan_dev_set_vlan_flag(char *dev_name, __u32 flag, short flag_val)
{
+ struct net_device *real_dev;
struct net_device *dev = dev_get_by_name(dev_name);
+ int ret = 0;
- if (dev) {
- if (dev->priv_flags & IFF_802_1Q_VLAN) {
- /* verify flag is supported */
- if (flag == 1) {
- if (flag_val) {
- VLAN_DEV_INFO(dev)->flags |= 1;
- } else {
- VLAN_DEV_INFO(dev)->flags &= ~1;
- }
- dev_put(dev);
- return 0;
- } else {
- printk(KERN_ERR "%s: flag %i is not valid.\n",
- __FUNCTION__, (int)(flag));
- dev_put(dev);
- return -EINVAL;
- }
- } else {
- printk(KERN_ERR
- "%s: %s is not a vlan device, priv_flags: %hX.\n",
- __FUNCTION__, dev->name, dev->priv_flags);
- dev_put(dev);
- }
- } else {
+ if (!dev) {
printk(KERN_ERR "%s: Could not find device: %s\n",
__FUNCTION__, dev_name);
+ ret = -EINVAL;
+ goto out_no_dev;
+ }
+
+ if (!(dev->priv_flags & IFF_802_1Q_VLAN)) {
+ printk(KERN_ERR
+ "%s: %s is not a vlan device, priv_flags: %hX.\n",
+ __FUNCTION__, dev->name, dev->priv_flags);
+ dev_put(dev);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ real_dev = VLAN_DEV_INFO(dev)->real_dev;
+ switch (flag) {
+ case VLAN_FLAG_REORDER:
+ if (flag_val)
+ VLAN_DEV_INFO(dev)->flags |= 1;
+ else
+ VLAN_DEV_INFO(dev)->flags &= ~1;
+ break;
+
+ case VLAN_FLAG_DISABLE_FILTER:
+ if (real_dev->vlan_set_flag)
+ ret = real_dev->vlan_set_flag(real_dev,
+ flag, flag_val);
+ else {
+ printk(KERN_ERR
+ "%s: VLAN flags not supported on base device %s.\n",
+ __FUNCTION__, real_dev->name);
+ ret = -EINVAL;
+ }
+ break;
+
+ default:
+ printk(KERN_ERR "%s: VLAN flag %d is invalid.\n",
+ __FUNCTION__, flag);
+ ret = -EINVAL;
+ break;
}
- return -EINVAL;
+out:
+ dev_put(dev);
+out_no_dev:
+ return ret;
}
^ permalink raw reply
* [PATCH 2/2] HW VLAN filtering control (resend)
From: Mitch Williams @ 2007-07-27 21:30 UTC (permalink / raw)
To: netdev
Add support to e1000 for enabling/disabling hardware VLAN filtering
at runtime.
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
diff -urpN -X dontdiff linux-2.6.22.1-clean/drivers/net/e1000/e1000_main.c linux-2.6.22.1/drivers/net/e1000/e1000_main.c
--- linux-2.6.22.1-clean/drivers/net/e1000/e1000_main.c 2007-07-10 11:56:30.000000000 -0700
+++ linux-2.6.22.1/drivers/net/e1000/e1000_main.c 2007-07-27 13:16:52.000000000 -0700
@@ -197,6 +197,9 @@ static void e1000_vlan_rx_register(struc
static void e1000_vlan_rx_add_vid(struct net_device *netdev, uint16_t vid);
static void e1000_vlan_rx_kill_vid(struct net_device *netdev, uint16_t vid);
static void e1000_restore_vlan(struct e1000_adapter *adapter);
+#ifdef HAVE_VLAN_FLAGS
+static int e1000_vlan_set_flag(struct net_device *netdev, unsigned int flag, int value);
+#endif
static int e1000_suspend(struct pci_dev *pdev, pm_message_t state);
#ifdef CONFIG_PM
@@ -938,6 +941,10 @@ e1000_probe(struct pci_dev *pdev,
netdev->vlan_rx_register = e1000_vlan_rx_register;
netdev->vlan_rx_add_vid = e1000_vlan_rx_add_vid;
netdev->vlan_rx_kill_vid = e1000_vlan_rx_kill_vid;
+#ifdef HAVE_VLAN_FLAGS
+ netdev->vlan_set_flag = e1000_vlan_set_flag;
+#endif
+
#ifdef CONFIG_NET_POLL_CONTROLLER
netdev->poll_controller = e1000_netpoll;
#endif
@@ -4973,7 +4980,42 @@ e1000_vlan_rx_register(struct net_device
e1000_irq_enable(adapter);
}
+#ifdef HAVE_VLAN_FLAGS
+static int
+e1000_vlan_set_flag(struct net_device *netdev, unsigned int flag, int value)
+{
+ struct e1000_adapter *adapter = netdev_priv(netdev);
+ uint32_t rctl;
+ /* The only flag we currently care about is bit 1,
+ which controls HW filtering. */
+ e1000_irq_disable(adapter);
+ if (adapter->hw.mac_type == e1000_ich8lan)
+ return -EPERM;
+
+ if (flag == VLAN_FLAG_DISABLE_FILTER) {
+ if (value) {
+ /* disable VLAN filtering */
+ rctl = E1000_READ_REG(&adapter->hw, RCTL);
+ rctl &= ~E1000_RCTL_VFE;
+ E1000_WRITE_REG(&adapter->hw, RCTL, rctl);
+ netdev->features &= ~NETIF_F_HW_VLAN_FILTER;
+ } else {
+ /* enable VLAN receive filtering */
+ rctl = E1000_READ_REG(&adapter->hw, RCTL);
+ rctl |= E1000_RCTL_VFE;
+ rctl &= ~E1000_RCTL_CFIEN;
+ E1000_WRITE_REG(&adapter->hw, RCTL, rctl);
+ netdev->features |= NETIF_F_HW_VLAN_FILTER;
+ e1000_restore_vlan(adapter);
+ e1000_update_mng_vlan(adapter);
+ }
+ }
+
+ e1000_irq_enable(adapter);
+ return 0;
+}
+#endif
static void
e1000_vlan_rx_add_vid(struct net_device *netdev, uint16_t vid)
{
^ permalink raw reply
* Re: Proposed interface for per-packet mesh-ttl
From: Dan Williams @ 2007-07-27 22:22 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Javier Cardona, netdev
In-Reply-To: <20070727195616.GA31510@infradead.org>
On Fri, 2007-07-27 at 20:56 +0100, Christoph Hellwig wrote:
> On Tue, Jul 03, 2007 at 12:29:24PM -0700, Javier Cardona wrote:
> > I'm currently working on per-packet mesh ttl. My plan is to register
> > new mesh sockopts through netfilter. The user interface will be:
>
> NACK. Drivers should never add sockopt, and drivers should not abuse
> netfilter hooks.
Do you have a suggestion for a better way to approach per-packet options
that userspace programs can set?
Thanks,
Dan
^ permalink raw reply
* Re: D-Link DFE-580TX 4 port NIC problems
From: Mario Doering @ 2007-07-27 23:41 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev
In-Reply-To: <46A9E029.4080200@anagramm.de>
On Fri, 27 Jul 2007 14:08:09 +0200
Clemens Koller <clemens.koller@anagramm.de> wrote:
> Hi, Mario!
>
> Mario Doering schrieb:
> > Hello,
> >
> > are there any news or questions on this issue?
>
> Can you try the latest kernel to see if the same problem
> persists?
> Is there any kernel version where it was working fine?
Hello Clemens,
I have tried different kernerls with no success so far. I have not
tried a 2.6.22 kernel yet, but I can do so of course.
It would take some time then again to wait for the error to arise ;-)
Bye,
Mario.
^ permalink raw reply
* [PATCH] forcedeth: mac address correct
From: Ayaz Abdulla @ 2007-07-27 3:33 UTC (permalink / raw)
To: Jeff Garzik, Manfred Spraul, Andrew Morton, netdev
[-- Attachment #1: Type: text/plain, Size: 285 bytes --]
In older chipsets, the mac address was stored in reversed order.
However, in newer chipsets, the mac address is in correct order. This
patch takes those newer chipsets into account and does not rely on a
special bit setup by BIOS'.
Signed-Off-By: Ayaz Abdulla <aabdulla@nvidia.com>
[-- Attachment #2: patch-forcedeth-macaddr --]
[-- Type: text/plain, Size: 9352 bytes --]
--- old/drivers/net/forcedeth.c 2007-07-26 23:09:31.000000000 -0400
+++ new/drivers/net/forcedeth.c 2007-07-26 23:11:04.000000000 -0400
@@ -178,6 +178,7 @@
#define DEV_HAS_STATISTICS_V2 0x0800 /* device supports hw statistics version 2 */
#define DEV_HAS_TEST_EXTENDED 0x1000 /* device supports extended diagnostic test */
#define DEV_HAS_MGMT_UNIT 0x2000 /* device supports management unit */
+#define DEV_HAS_CORRECT_MACADDR 0x4000 /* device supports correct mac address order */
enum {
NvRegIrqStatus = 0x000,
@@ -5172,7 +5173,8 @@
/* check the workaround bit for correct mac address order */
txreg = readl(base + NvRegTransmitPoll);
- if (txreg & NVREG_TRANSMITPOLL_MAC_ADDR_REV) {
+ if ((txreg & NVREG_TRANSMITPOLL_MAC_ADDR_REV) ||
+ (id->driver_data & DEV_HAS_CORRECT_MACADDR) {
/* mac address is already in correct order */
dev->dev_addr[0] = (np->orig_mac[0] >> 0) & 0xff;
dev->dev_addr[1] = (np->orig_mac[0] >> 8) & 0xff;
@@ -5500,67 +5502,67 @@
},
{ /* MCP61 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_16),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP61 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_17),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP61 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_18),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP61 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_19),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP65 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_20),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP65 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_21),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP65 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_22),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP65 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_23),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP67 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_24),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP67 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_25),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP67 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_26),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP67 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_27),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP73 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_28),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP73 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_29),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP73 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_30),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP73 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_31),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{0,},
};
^ permalink raw reply
* Re: [PATCH] forcedeth: mac address correct
From: Simon Arlott @ 2007-07-27 23:50 UTC (permalink / raw)
To: Ayaz Abdulla; +Cc: Jeff Garzik, Manfred Spraul, Andrew Morton, netdev
In-Reply-To: <46A96798.5000106@nvidia.com>
On 27/07/07 04:33, Ayaz Abdulla wrote:
> In older chipsets, the mac address was stored in reversed order.
> However, in newer chipsets, the mac address is in correct order. This
> patch takes those newer chipsets into account and does not rely on a
> special bit setup by BIOS'.
>
> Signed-Off-By: Ayaz Abdulla <aabdulla@nvidia.com>
>
>
- if (txreg & NVREG_TRANSMITPOLL_MAC_ADDR_REV) {
+ if ((txreg & NVREG_TRANSMITPOLL_MAC_ADDR_REV) ||
+ (id->driver_data & DEV_HAS_CORRECT_MACADDR) {
This will not compile.
--
Simon Arlott
^ permalink raw reply
* [PATCH] forcedeth: mac address correct
From: Ayaz Abdulla @ 2007-07-27 3:46 UTC (permalink / raw)
To: Jeff Garzik, Manfred Spraul, Andrew Morton, nedev
[-- Attachment #1: Type: text/plain, Size: 296 bytes --]
Resending:
In older chipsets, the mac address was stored in reversed order.
However, in newer chipsets, the mac address is in correct order. This
patch takes those newer chipsets into account and does not rely on a
special bit setup by BIOS'.
Signed-Off-By: Ayaz Abdulla <aabdulla@nvidia.com>
[-- Attachment #2: patch-forcedeth-macaddr --]
[-- Type: text/plain, Size: 9352 bytes --]
--- old/drivers/net/forcedeth.c 2007-07-26 23:09:31.000000000 -0400
+++ new/drivers/net/forcedeth.c 2007-07-26 23:43:09.000000000 -0400
@@ -178,6 +178,7 @@
#define DEV_HAS_STATISTICS_V2 0x0800 /* device supports hw statistics version 2 */
#define DEV_HAS_TEST_EXTENDED 0x1000 /* device supports extended diagnostic test */
#define DEV_HAS_MGMT_UNIT 0x2000 /* device supports management unit */
+#define DEV_HAS_CORRECT_MACADDR 0x4000 /* device supports correct mac address order */
enum {
NvRegIrqStatus = 0x000,
@@ -5172,7 +5173,8 @@
/* check the workaround bit for correct mac address order */
txreg = readl(base + NvRegTransmitPoll);
- if (txreg & NVREG_TRANSMITPOLL_MAC_ADDR_REV) {
+ if ((txreg & NVREG_TRANSMITPOLL_MAC_ADDR_REV) ||
+ (id->driver_data & DEV_HAS_CORRECT_MACADDR)) {
/* mac address is already in correct order */
dev->dev_addr[0] = (np->orig_mac[0] >> 0) & 0xff;
dev->dev_addr[1] = (np->orig_mac[0] >> 8) & 0xff;
@@ -5500,67 +5502,67 @@
},
{ /* MCP61 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_16),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP61 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_17),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP61 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_18),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP61 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_19),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP65 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_20),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP65 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_21),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP65 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_22),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP65 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_23),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP67 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_24),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP67 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_25),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP67 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_26),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP67 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_27),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP73 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_28),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP73 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_29),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP73 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_30),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP73 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_31),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{0,},
};
^ permalink raw reply
* Re: Proposed interface for per-packet mesh-ttl
From: Stephen Hemminger @ 2007-07-28 6:31 UTC (permalink / raw)
To: Dan Williams; +Cc: Christoph Hellwig, Javier Cardona, netdev
In-Reply-To: <1185574942.17934.9.camel@xo-13-A4-25.localdomain>
On Fri, 27 Jul 2007 18:22:22 -0400
Dan Williams <dcbw@redhat.com> wrote:
> On Fri, 2007-07-27 at 20:56 +0100, Christoph Hellwig wrote:
> > On Tue, Jul 03, 2007 at 12:29:24PM -0700, Javier Cardona wrote:
> > > I'm currently working on per-packet mesh ttl. My plan is to register
> > > new mesh sockopts through netfilter. The user interface will be:
> >
> > NACK. Drivers should never add sockopt, and drivers should not abuse
> > netfilter hooks.
>
> Do you have a suggestion for a better way to approach per-packet options
> that userspace programs can set?
>
> Thanks,
> Dan
In this case perhaps you can have a table that maps skb->priority to
mesh ttl? priorty can already by handled by existing setsockopt calls,
and modified by netfilter and QoS managements.
^ permalink raw reply
* Re: RFC/Progress update: e1000e pci-express -only e1000 driver
From: Andi Kleen @ 2007-07-28 13:52 UTC (permalink / raw)
To: Kok, Auke; +Cc: Jeff Garzik, NetDev, Arjan van de Ven, Ronciak, John
In-Reply-To: <46AA5FB8.9090600@intel.com>
"Kok, Auke" <auke-jan.h.kok@intel.com> writes:
> * Removed all multi-queue code
Why? With David's new multi NAPI work it will finally make sense, won't it?
-Andi (who would finally like to see a driver which is able to process
incoming packets and TX completion interrupts on multiple CPUs)
^ permalink raw reply
* Re: [PATCH RFX]: napi_struct V3
From: Roland Dreier @ 2007-07-28 15:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, shemminger, rusty, jgarzik
In-Reply-To: <20070723.210748.63127793.davem@davemloft.net>
I've been on vacation so I missed most of this thread. I'm just
catching up now...
> Ok I converted everything with Rusty's suggestion to move napi_struct
> out of net_device, this was mostly mechanical but some devices took
> some unanticipated amount of work.
Actually you missed drivers/infiniband/ulp/ipoib, which has used NAPI
since 2.6.22. I can take a stab at the conversion soon if you want...
> Another area of consternation are drivers that were using
> netif_rx_reschedule(), as that interface was removed because it
> doesn't fit well with the caller managing the dev->quota et al. I
> left race conditions in the drivers that were using that interface,
> but they should still basically work nonetheless.
...but this is a problem for IPoIB. The underlying IB stuff only
allows us to register what is essentially a one-shot edge-triggered
interrupt. So there is a race between calling netif_rx_complete() and
calling ib_req_notify_cq() (which enables the interrupt), since the
interrupt might never happen if a packet arrives between the two calls.
In the current driver we are OK because ib_req_notify_cq() can return
a hint if an event was missed, but to use this hint we need a way to
restart the NAPI poll without getting into trouble if the interrupt
handler calls netif_rx_schedule() too.
Thanks,
Roland
^ permalink raw reply
* Re: [PATCH RFC]: napi_struct V4
From: Roland Dreier @ 2007-07-28 15:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev, shemminger, jgarzik, hadi, rusty
In-Reply-To: <20070725.013154.34764933.davem@davemloft.net>
> Most drivers are in good shape, although some still have very
> questionable netif_rx_complete() handling, in that racy area that
> Rusty and myself were discussing today.
>
> My inclination is to wrap those sequences around with an IRQ
> safe spinlock to fix the race provably, and then if driver
> authors want to optimize that away with techniques like those
> that tg3, bnx2, sky2, skge et al. use, that's fine but can
> be done later.
Ouch... that extra lock seems pretty expensive. Also I'm having a
hard time understanding how the techniques you're alluding to apply to
devices that may miss events when enabling interrupts; the drivers you
mention all seem to be for devices that didn't have the race and
didn't use netif_rx_reschedule() in the old NAPI world. Can you
provide a little more detail on how the lock could be optimized away?
Thanks,
Roland
^ permalink raw reply
* NETPOLL=y , NETDEVICES=n compile error ( Re: 2.6.23-rc1-mm1 )
From: Gabriel C @ 2007-07-28 15:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, netdev, jason.wessel, amitkale
In-Reply-To: <20070725040304.111550f4.akpm@linux-foundation.org>
Hi,
I got this compile error with a randconfig ( http://194.231.229.228/MM/randconfig-auto-82.broken.netpoll.c ).
...
net/core/netpoll.c: In function 'netpoll_poll':
net/core/netpoll.c:155: error: 'struct net_device' has no member named 'poll_controller'
net/core/netpoll.c:159: error: 'struct net_device' has no member named 'poll_controller'
net/core/netpoll.c: In function 'netpoll_setup':
net/core/netpoll.c:670: error: 'struct net_device' has no member named 'poll_controller'
make[2]: *** [net/core/netpoll.o] Error 1
make[1]: *** [net/core] Error 2
make: *** [net] Error 2
make: *** Waiting for unfinished jobs....
...
I think is because KGDBOE selects just NETPOLL.
Regards,
Gabriel
^ permalink raw reply
* small bug in tcp
From: john @ 2007-07-28 16:07 UTC (permalink / raw)
To: netdev
When application closes socket with unread data in receive buffer, tcp
stack sends rst packet from the wrong source port, not the source port
of the socket being closed.
This is the same problem that was described in my first post, witch
unfortunately nobody cared to look into.
This problem appeared in 2.4.0-test9-pre3 and is still present in kernel.
^ permalink raw reply
* pcnet32 79C972 doesn't survive suspend to RAM
From: Andi Kleen @ 2007-07-28 16:56 UTC (permalink / raw)
To: pcnet32; +Cc: netdev
Hallo,
I tried suspend to RAM on my desktop. Surprisingly near everything worked
after the wakeup, except for the pcnet32 PCI card. Kernel is 2.6.23-rc1-git4
on x86_64.
Bootup:
pcnet32.c:v1.33-NAPI 27.Jun.2006 tsbogend@alpha.franken.de
IOAPIC[0]: Set routing entry (2-21 -> 0x81 -> IRQ 21 Mode:1 Active:1)
ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 21 (level, low) -> IRQ 21
pcnet32: PCnet/FAST+ 79C972 at 0x1100, 00 a0 d2 18 9d 21
tx_start_pt(0x0c00):~220 bytes, BCR18(9861):BurstWrEn BurstRdEn NoUFlow
SRAMSIZE=0x1700, SRAM_BND=0x0800, assigned IRQ 21.
pcnet32: Found PHY 7810:0003 at address 1.
eth1: registered as PCnet/FAST+ 79C972
pcnet32: 1 cards_found.
After the S3 wakeup I get:
NETDEV WATCHDOG: eth4: transmit timed out
eth4: transmit timed out, status 0053, resetting.
NETDEV WATCHDOG: eth4: transmit timed out
eth4: transmit timed out, status 0053, resetting.
NETDEV WATCHDOG: eth4: transmit timed out
eth4: transmit timed out, status 0053, resetting.
NETDEV WATCHDOG: eth4: transmit timed out
eth4: transmit timed out, status 0053, resetting.
NETDEV WATCHDOG: eth4: transmit timed out
eth4: transmit timed out, status 0053, resetting.
NETDEV WATCHDOG: eth4: transmit timed out
eth4: transmit timed out, status 0053, resetting.
... going on ...
And no packets are getting received either.
lspci -vvvxxx in the broken state:
05:00.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 36)
Subsystem: Allied Telesyn International AT-2700TX 10/100 Fast Ethernet
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (6000ns min, 6000ns max)
Interrupt: pin A routed to IRQ 21
Region 0: I/O ports at 1100 [size=32]
Region 1: Memory at e8004900 (32-bit, non-prefetchable) [size=32]
Expansion ROM at fff00000 [disabled] [size=1M]
Capabilities: [40] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
00: 22 10 00 20 07 00 90 02 36 00 00 02 00 20 00 00
10: 01 11 00 00 00 49 00 e8 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 59 12 00 27
30: 00 00 f0 ff 40 00 00 00 00 00 00 00 0b 01 18 18
40: 01 00 11 fe 00 20 00 14 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Interrupt is not shared:
21: 13292 0 IO-APIC-fasteoi eth4
-Andi
^ permalink raw reply
* Re: NETPOLL=y , NETDEVICES=n compile error ( Re: 2.6.23-rc1-mm1 )
From: Andrew Morton @ 2007-07-28 17:26 UTC (permalink / raw)
To: Gabriel C; +Cc: linux-kernel, netdev, jason.wessel, amitkale
In-Reply-To: <46AB646D.8020104@googlemail.com>
On Sat, 28 Jul 2007 17:44:45 +0200 Gabriel C <nix.or.die@googlemail.com> wrote:
> Hi,
>
> I got this compile error with a randconfig ( http://194.231.229.228/MM/randconfig-auto-82.broken.netpoll.c ).
>
> ...
>
> net/core/netpoll.c: In function 'netpoll_poll':
> net/core/netpoll.c:155: error: 'struct net_device' has no member named 'poll_controller'
> net/core/netpoll.c:159: error: 'struct net_device' has no member named 'poll_controller'
> net/core/netpoll.c: In function 'netpoll_setup':
> net/core/netpoll.c:670: error: 'struct net_device' has no member named 'poll_controller'
> make[2]: *** [net/core/netpoll.o] Error 1
> make[1]: *** [net/core] Error 2
> make: *** [net] Error 2
> make: *** Waiting for unfinished jobs....
>
> ...
>
>
> I think is because KGDBOE selects just NETPOLL.
>
Looks like it.
Select went and selected NETPOLL and NETPOLL_TRAP but things like
CONFIG_NETDEVICES and CONFIG_NET_POLL_CONTROLLER remain unset. `select'
remains evil.
Something like this..
--- a/lib/Kconfig.kgdb~kgdb-kconfig-fix
+++ a/lib/Kconfig.kgdb
@@ -175,8 +175,7 @@ endchoice
config KGDBOE
tristate "KGDB: On ethernet" if !KGDBOE_NOMODULE
depends on m && KGDB
- select NETPOLL
- select NETPOLL_TRAP
+ depends on NETPOLL_TRAP && NET_POLL_CONTROLLER
help
Uses the NETPOLL API to communicate with the host GDB via UDP.
In order for this to work, the ethernet interface specified must
_
^ permalink raw reply
* Re: RFC/Progress update: e1000e pci-express -only e1000 driver
From: Jeff Garzik @ 2007-07-28 18:07 UTC (permalink / raw)
To: Andi Kleen; +Cc: Kok, Auke, NetDev, Arjan van de Ven, Ronciak, John
In-Reply-To: <p73sl78r5yu.fsf@bingen.suse.de>
Andi Kleen wrote:
> "Kok, Auke" <auke-jan.h.kok@intel.com> writes:
>
>> * Removed all multi-queue code
>
> Why? With David's new multi NAPI work it will finally make sense, won't it?
It will come back, most definitely.
Not speaking for Auke, but I'm pretty sure this falls under the category
of "start small and simple, get it into the tree rapidly."
Jeff
^ permalink raw reply
* Re: [PATCH RFC]: napi_struct V4
From: Jeff Garzik @ 2007-07-28 18:08 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, netdev, hadi, rusty
In-Reply-To: <20070725.190245.68070169.davem@davemloft.net>
David Miller wrote:
> From: Jeff Garzik <jeff@garzik.org>
> Date: Wed, 25 Jul 2007 22:00:31 -0400
>
>> David Miller wrote:
>>> From: Jeff Garzik <jgarzik@pobox.com>
>>> Date: Wed, 25 Jul 2007 21:55:08 -0400
>>>
>>>> I don't see any logic to your request, only added overhead for no reason.
>>> There may be some flawed logic in what Stephen stated, but
>>> the change really is needed.
>>>
>>> It must be atomic to execute the:
>>>
>>> enable_interrupts();
>>> netif_rx_complete();
>>>
>>> sequence wrt. the same code path in the interrupt handler.
>> Sure. And how did the existing code fail to achieve that?
>
> The interrupt handler can run on another cpu in betwen those two
> statements, running the NAPI test-and-do-something operations in
> parallel with the netif_rx_complete() which causes problems as Rusty
> and I discussed yesterday.
That's a performance/parallelization regression from current NAPI :(
Jeff
^ permalink raw reply
* Re: RFC/Progress update: e1000e pci-express -only e1000 driver
From: Kok, Auke @ 2007-07-28 18:18 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Andi Kleen, NetDev, Arjan van de Ven, Ronciak, John
In-Reply-To: <46AB85FB.10102@pobox.com>
Jeff Garzik wrote:
> Andi Kleen wrote:
>> "Kok, Auke" <auke-jan.h.kok@intel.com> writes:
>>
>>> * Removed all multi-queue code
>> Why? With David's new multi NAPI work it will finally make sense, won't it?
>
> It will come back, most definitely.
>
> Not speaking for Auke, but I'm pretty sure this falls under the category
> of "start small and simple, get it into the tree rapidly."
on top of that it's trivial to add it back, is currently not even used (!) and
just a remnant of earlier efforts.
PJ is working on getting a consistent multiqueue patch out and he will (once
this driver is ready) write a proper patch to add it back after the driver gets
merged.
Auke
^ permalink raw reply
* Re: NETPOLL=y , NETDEVICES=n compile error ( Re: 2.6.23-rc1-mm1 )
From: Gabriel C @ 2007-07-28 18:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, netdev, jason.wessel, amitkale
In-Reply-To: <20070728102639.872ec9a0.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Sat, 28 Jul 2007 17:44:45 +0200 Gabriel C <nix.or.die@googlemail.com> wrote:
>
>> Hi,
>>
>> I got this compile error with a randconfig ( http://194.231.229.228/MM/randconfig-auto-82.broken.netpoll.c ).
>>
>> ...
>>
>> net/core/netpoll.c: In function 'netpoll_poll':
>> net/core/netpoll.c:155: error: 'struct net_device' has no member named 'poll_controller'
>> net/core/netpoll.c:159: error: 'struct net_device' has no member named 'poll_controller'
>> net/core/netpoll.c: In function 'netpoll_setup':
>> net/core/netpoll.c:670: error: 'struct net_device' has no member named 'poll_controller'
>> make[2]: *** [net/core/netpoll.o] Error 1
>> make[1]: *** [net/core] Error 2
>> make: *** [net] Error 2
>> make: *** Waiting for unfinished jobs....
>>
>> ...
>>
>>
>> I think is because KGDBOE selects just NETPOLL.
>>
>
> Looks like it.
>
> Select went and selected NETPOLL and NETPOLL_TRAP but things like
> CONFIG_NETDEVICES and CONFIG_NET_POLL_CONTROLLER remain unset. `select'
> remains evil.
>
> Something like this..
>
> --- a/lib/Kconfig.kgdb~kgdb-kconfig-fix
> +++ a/lib/Kconfig.kgdb
> @@ -175,8 +175,7 @@ endchoice
> config KGDBOE
> tristate "KGDB: On ethernet" if !KGDBOE_NOMODULE
> depends on m && KGDB
> - select NETPOLL
> - select NETPOLL_TRAP
> + depends on NETPOLL_TRAP && NET_POLL_CONTROLLER
> help
> Uses the NETPOLL API to communicate with the host GDB via UDP.
> In order for this to work, the ethernet interface specified must
> _
>
>
That doesn't fix it. With that patch an 'make oldconfig' all NETPOLL stuff gone and we end up with :
...
drivers/built-in.o: In function `option_setup':
/work/crazy/linux-git/MM/linux-2.6.23-rc1/drivers/net/kgdboe.c:160: undefined reference to `netpoll_parse_options'
drivers/built-in.o: In function `configure_kgdboe':
/work/crazy/linux-git/MM/linux-2.6.23-rc1/drivers/net/kgdboe.c:183: undefined reference to `netpoll_setup'
/work/crazy/linux-git/MM/linux-2.6.23-rc1/drivers/net/kgdboe.c:189: undefined reference to `netpoll_cleanup'
drivers/built-in.o: In function `eth_post_exception_handler':
/work/crazy/linux-git/MM/linux-2.6.23-rc1/drivers/net/kgdboe.c:119: undefined reference to `netpoll_set_trap'
drivers/built-in.o: In function `eth_pre_exception_handler':
/work/crazy/linux-git/MM/linux-2.6.23-rc1/drivers/net/kgdboe.c:111: undefined reference to `netpoll_set_trap'
drivers/built-in.o: In function `eth_flush_buf':
/work/crazy/linux-git/MM/linux-2.6.23-rc1/drivers/net/kgdboe.c:138: undefined reference to `netpoll_send_udp'
drivers/built-in.o: In function `eth_get_char':
/work/crazy/linux-git/MM/linux-2.6.23-rc1/drivers/net/kgdboe.c:127: undefined reference to `netpoll_poll'
drivers/built-in.o: In function `cleanup_kgdboe':
/work/crazy/linux-git/MM/linux-2.6.23-rc1/drivers/net/kgdboe.c:217: undefined reference to `netpoll_cleanup'
make: *** [.tmp_vmlinux1] Error 1
...
If I get that right select is needed here because all NETPOLL{_*} depends on if NETDEVICES && if NET_ETHERNET.
Also doing
...
select NETPOLL_TRAP
select NETPOLL
select NET_POLL_CONTROLLER
...
makes the driver happy and everything compiles fine.
I think there may be a logical issue ( again if I got it right ).
We need some ethernet card to work with kgdboe right ? but we don't have any if !NETDEVICES && !NET_ETHERNET.
So maybe some ' depends on ... && NETDEVICES!=n && NET_ETHERNET!=n ' is needed too ?
( really sory if I said something stupid these Kconfig depends are not really easy to figure for me )
Gabriel
^ permalink raw reply
* Removing the prism54 module
From: Edward Ando @ 2007-07-28 20:40 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA; +Cc: netdev-u79uwXL29TY76Z2rM5mHXA
Dear All,
I am trying to set up software suspend 2 (TuxOnIce now it seems). This
has decided it wants to remove the prism54 module before starting the
hibernate process.
When it tries to do this, (or when I manually do: "ifconfig eth1
down"), I start getting these messages on all terminals, ad infinitum:
kernel: unregister_netdevice: waiting for eth1 to become free. Usage
count = 4
I asked a bit on #prism54 on freenode, and so I upgraded to
linux 2.6.22.1 from kernel.org, always building prism54 as a module,
but the problem continues.
I have tried doing "ifconfig eth1 down" before rmmod, but this does not
help.
If you have any hints or answers as to what I should do, that would be
great. I am not subscribed, so could you answer to this address please.
Thanks in advance,
Yours,
Edward Ando
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox