Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes
On Mon, Oct 15, 2007 at 06:03:20PM +0100, Maciej W. Rozycki wrote: > On Mon, 15 Oct 2007, Jarek Poplawski wrote: > > > Could you explain why cancel_work_sync() is better here than > > flush_scheduled_work() wrt. rtnl_lock()? > > Well, this is actually the bit that made cancel_work_sync() be written in > the first place. The short story is the netlink lock is most probably > held at this point (depending on the usage of phy_disconnect()) and there > is also an event waiting in the queue that requires the lock, so if > flush_scheduled_work() is called here a deadlock will happen. > > Let me find a reference for a longer story...: > > http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=Pine.LNX.4.64N.0610031509380.4642%40blysk.ds.pg.gda.pl > > and then discussed again: > > http://www.uwsg.indiana.edu/hypermail/linux/kernel/0612.0/0593.html > Yes, it's all right here. Sorry for bothering - I should've found this by myself. I've still some doubts about this possible enable_irq() after free_irq(). If it's the only handler the status would be changed again and at least some of this code in check_irq_resend() would be run, but I can miss something again or/and this doesn't matter, as well. Thanks, Jarek P. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> Note: I use msleep_interruptible(1); just like napi_disable(). However
> I'm not too happy that the "hot" loop that results of a pending signal
> here will spin without even a cpu_relax ... what do you guys think would
> be the best way to handle this ?
Well since the loop does not check signals at all, it should
just use msleep.
Granted the process will end up in the D state and contribute
to the load average. But if this loop executes long enough
for that to be noticed then we've got bigger problems to worry
about.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
net: Add __napi_sycnhronize() to sync with napi poll
The EMAC driver which needs to handle multiple devices with one
NAPI instance implements its own per-channel disable bit. However,
when setting such a bit, it needs to synchronize with the poller
(that is make sure that any pending poller instance has completed,
or is started late enough to see that disable bit).
This implements a low level __napi_synchronize() function to acheive
that. The underscores are to emphasis the low level aspect of it and
to discourage driver writers who don't know what they are doing to
use it (to please DaveM :-)
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
(Use correct address for Stephen this time)
If the approach is accepted, I would like to have this merged now
so the EMAC patch to make it work again can follow :-)
Note: I use msleep_interruptible(1); just like napi_disable(). However
I'm not too happy that the "hot" loop that results of a pending signal
here will spin without even a cpu_relax ... what do you guys think would
be the best way to handle this ?
Index: linux-work/include/linux/netdevice.h
===
--- linux-work.orig/include/linux/netdevice.h 2007-10-16 15:27:27.0
+1000
+++ linux-work/include/linux/netdevice.h2007-10-16 15:27:38.0
+1000
@@ -394,6 +394,21 @@ static inline void napi_disable(struct n
}
/**
+ * __napi_synchronize - synchronize with a concurrent poll
+ * @n: napi context
+ *
+ * Synchronizes with a concurrent poll. Not to be used in normal
+ * drivers, mostly useful if you end up with multiple interfaces
+ * on one NAPI instance.
+ */
+static inline void __napi_synchronize(struct napi_struct *n)
+{
+ smp_mb();
+ while (test_bit(NAPI_STATE_SCHED, &n->state))
+ msleep_interruptible(1);
+}
+
+/**
* napi_enable - enable NAPI scheduling
* @n: napi context
*
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gianfar: Fix compile regression caused by 09f75cd7
Kumar Gala wrote: On Fri, 12 Oct 2007, Li Yang wrote: Signed-off-by: Li Yang <[EMAIL PROTECTED]> --- drivers/net/gianfar.c |7 +++ 1 files changed, 3 insertions(+), 4 deletions(-) this patch got lost. can someone resend, then? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
netif_napi_add vs. multiple netdev's
Hi Stehphen ! The new netif_napi_add() function takes a netdev argument. In the EMAC case, there is one NAPI instance working on behalf of multiple netdev's, so that isn't very useful. For my EMAC patch (just posted to you & the list), I'm not passing NULL, but I'm wondering what would be a good way to handle netpoll here... The way it's currently implemented, there's a list of NAPI's attached to the netdev, so obviously, that won't work for my usage scenario. I'm not sure what's the best data structure that would be suitable for both N ndev's for 1 NAPI and 1 ndev for N NAPI's though... I could allocate "stub" list heads and queue those up, but that's a bit gross... Any better idea ? Cheers, Ben. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
net: Add __napi_sycnhronize() to sync with napi poll
The EMAC driver which needs to handle multiple devices with one
NAPI instance implements its own per-channel disable bit. However,
when setting such a bit, it needs to synchronize with the poller
(that is make sure that any pending poller instance has completed,
or is started late enough to see that disable bit).
This implements a low level __napi_synchronize() function to acheive
that. The underscores are to emphasis the low level aspect of it and
to discourage driver writers who don't know what they are doing to
use it (to please DaveM :-)
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
If the approach is accepted, I would like to have this merged now
so the EMAC patch to make it work again can follow :-)
Note: I use msleep_interruptible(1); just like napi_disable(). However
I'm not too happy that the "hot" loop that results of a pending signal
here will spin without even a cpu_relax ... what do you guys think would
be the best way to handle this ?
Index: linux-work/include/linux/netdevice.h
===
--- linux-work.orig/include/linux/netdevice.h 2007-10-16 15:27:27.0
+1000
+++ linux-work/include/linux/netdevice.h2007-10-16 15:27:38.0
+1000
@@ -394,6 +394,21 @@ static inline void napi_disable(struct n
}
/**
+ * __napi_synchronize - synchronize with a concurrent poll
+ * @n: napi context
+ *
+ * Synchronizes with a concurrent poll. Not to be used in normal
+ * drivers, mostly useful if you end up with multiple interfaces
+ * on one NAPI instance.
+ */
+static inline void __napi_synchronize(struct napi_struct *n)
+{
+ smp_mb();
+ while (test_bit(NAPI_STATE_SCHED, &n->state))
+ msleep_interruptible(1);
+}
+
+/**
* napi_enable - enable NAPI scheduling
* @n: napi context
*
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gianfar: Fix compile regression caused by 09f75cd7
On Fri, 12 Oct 2007, Li Yang wrote:
> Signed-off-by: Li Yang <[EMAIL PROTECTED]>
> ---
> drivers/net/gianfar.c |7 +++
> 1 files changed, 3 insertions(+), 4 deletions(-)
this patch got lost.
- k
>
> diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
> index 2b758fa..6d1456a 100644
> --- a/drivers/net/gianfar.c
> +++ b/drivers/net/gianfar.c
> @@ -1228,8 +1228,6 @@ static int gfar_change_mtu(struct net_device *dev, int
> new_mtu)
> * starting over will fix the problem. */
> static void gfar_timeout(struct net_device *dev)
> {
> - struct gfar_private *priv = netdev_priv(dev);
> -
> dev->stats.tx_errors++;
>
> if (dev->flags & IFF_UP) {
> @@ -1335,8 +1333,9 @@ struct sk_buff * gfar_new_skb(struct net_device *dev,
> struct rxbd8 *bdp)
> return skb;
> }
>
> -static inline void count_errors(unsigned short status, struct gfar_private
> *priv)
> +static inline void count_errors(unsigned short status, struct net_device
> *dev)
> {
> + struct gfar_private *priv = netdev_priv(dev);
> struct net_device_stats *stats = &dev->stats;
> struct gfar_extra_stats *estats = &priv->extra_stats;
>
> @@ -1530,7 +1529,7 @@ int gfar_clean_rx_ring(struct net_device *dev, int
> rx_work_limit)
>
> dev->stats.rx_bytes += pkt_len;
> } else {
> - count_errors(bdp->status, priv);
> + count_errors(bdp->status, dev);
>
> if (skb)
> dev_kfree_skb_any(skb);
> --
> 1.5.3.2.104.g41ef
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] net: Fix new EMAC driver for NAPI changes
net: Fix new EMAC driver for NAPI changes
This fixes the new EMAC driver for the NAPI updates. The previous patch
by Roland Dreier (already applied) to do that doesn't actually work. This
applies on top of it makes it work on my test Ebony machine.
This patch depends on "net: Add __napi_sycnhronize() to sync with napi poll"
posted previously.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
The old EMAC driver does things a bit differently (doesn't do useful
locking :-) and seems to work with Roland patch. So I'm not going to
touch it unless somebody reports me that it has problems
Index: linux-work/drivers/net/ibm_newemac/mal.c
===
--- linux-work.orig/drivers/net/ibm_newemac/mal.c 2007-10-16
14:51:11.0 +1000
+++ linux-work/drivers/net/ibm_newemac/mal.c2007-10-16 14:59:23.0
+1000
@@ -45,6 +45,8 @@ int __devinit mal_register_commac(struct
return -EBUSY;
}
+ if (list_empty(&mal->list))
+ napi_enable(&mal->napi);
mal->tx_chan_mask |= commac->tx_chan_mask;
mal->rx_chan_mask |= commac->rx_chan_mask;
list_add(&commac->list, &mal->list);
@@ -67,6 +69,8 @@ void __devexit mal_unregister_commac(str
mal->tx_chan_mask &= ~commac->tx_chan_mask;
mal->rx_chan_mask &= ~commac->rx_chan_mask;
list_del_init(&commac->list);
+ if (list_empty(&mal->list))
+ napi_disable(&mal->napi);
spin_unlock_irqrestore(&mal->lock, flags);
}
@@ -182,7 +186,7 @@ static inline void mal_enable_eob_irq(st
set_mal_dcrn(mal, MAL_CFG, get_mal_dcrn(mal, MAL_CFG) | MAL_CFG_EOPIE);
}
-/* synchronized by __LINK_STATE_RX_SCHED bit in ndev->state */
+/* synchronized by NAPI state */
static inline void mal_disable_eob_irq(struct mal_instance *mal)
{
// XXX might want to cache MAL_CFG as the DCR read can be slow
@@ -317,8 +321,8 @@ void mal_poll_disable(struct mal_instanc
while (test_and_set_bit(MAL_COMMAC_POLL_DISABLED, &commac->flags))
msleep(1);
- /* Synchronize with the MAL NAPI poller. */
- napi_disable(&mal->napi);
+ /* Synchronize with the MAL NAPI poller */
+ __napi_synchronize(&mal->napi);
}
void mal_poll_enable(struct mal_instance *mal, struct mal_commac *commac)
@@ -326,7 +330,12 @@ void mal_poll_enable(struct mal_instance
smp_wmb();
clear_bit(MAL_COMMAC_POLL_DISABLED, &commac->flags);
- // XXX might want to kick a poll now...
+ /* Feels better to trigger a poll here to catch up with events that
+* may have happened on this channel while disabled. It will most
+* probably be delayed until the next interrupt but that's mostly a
+* non-issue in the context where this is called.
+*/
+ napi_schedule(&mal->napi);
}
static int mal_poll(struct napi_struct *napi, int budget)
@@ -336,8 +345,7 @@ static int mal_poll(struct napi_struct *
int received = 0;
unsigned long flags;
- MAL_DBG2(mal, "poll(%d) %d ->" NL, *budget,
-rx_work_limit);
+ MAL_DBG2(mal, "poll(%d)" NL, budget);
again:
/* Process TX skbs */
list_for_each(l, &mal->poll_list) {
@@ -528,11 +536,12 @@ static int __devinit mal_probe(struct of
}
INIT_LIST_HEAD(&mal->poll_list);
- mal->napi.weight = CONFIG_IBM_NEW_EMAC_POLL_WEIGHT;
- mal->napi.poll = mal_poll;
INIT_LIST_HEAD(&mal->list);
spin_lock_init(&mal->lock);
+ netif_napi_add(NULL, &mal->napi, mal_poll,
+ CONFIG_IBM_NEW_EMAC_POLL_WEIGHT);
+
/* Load power-on reset defaults */
mal_reset(mal);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gianfar: Cleanup compile warning caused by 0795af57
On Mon, 15 Oct 2007, Jeff Garzik wrote: > Li Yang wrote: > > Signed-off-by: Li Yang <[EMAIL PROTECTED]> > > --- > > drivers/net/gianfar.c |1 - > > 1 files changed, 0 insertions(+), 1 deletions(-) > > applied all three gianfar patches > Jeff, You seem to have lost one of the patches: [PATCH] gianfar: Fix compile regression caused by 09f75cd7 http://marc.info/?l=linux-netdev&m=119219683128258&w=2 - k - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: question on sky2 driver panic
From: "Chris Friesen" <[EMAIL PROTECTED]> Date: Mon, 15 Oct 2007 23:16:16 -0600 > Our version of the e1000 passes 200 bytes in the initial chunk, and the > rest in fragments. tipc currently handles that without any difficulty. There is no requirement for any bytes to be in the initial skb->data chunk, in fact the Neptune NIU driver only pulls the ethernet header into there for example. net/tipc/eth_media.c:recv_msg() seems to dereference buf->data directly without making any pskb_may_pull() checks, and that is a bug. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: question on sky2 driver panic
Stephen Hemminger wrote: Maybe TIPC can't handle fragmented receive buffers. The sky2 driver generates skb's with header and multiple pages if MTU is big enough. For 9K MTU that would be 1K of data + 2 4K pages. The protocols are supposed to be smart enough to handle this, but TIPC is rarely used. We already had to modify tipc to handle fragmented receive buffers when we had memory allocation errors on the e1000 and moved to fragmented skbs in that driver. Our version of the e1000 passes 200 bytes in the initial chunk, and the rest in fragments. tipc currently handles that without any difficulty. I was just checking more to see if there were any known issues in this area that have been fixed in more recent driver versions. Chris - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Will RFC1146 (tcp alternative checksum options) be implemented in Linux tcp stack ?
Yanping Du wrote: Hi, We found the standard 16-bit tcp checksum is not strong enough in some cases. Is there any roadmap on implementing RFC1146 (tcp alternative checksum options) in Linux tcp stack ? If yes, how soon will that be in ? Please kindly copy reply to my email address as I've not subscribed the netdev@ mailing list at present. http://www.faqs.org/rfcs/rfc1146.html You would of course lose all the hardware offload of checksumming since no hardware supports alternative checksums. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Will RFC1146 (tcp alternative checksum options) be implemented in Linux tcp stack ?
On 10/16/07, Yanping Du <[EMAIL PROTECTED]> wrote: > Hi, > > We found the standard 16-bit tcp checksum is not > strong enough in some cases. Is there any roadmap on > implementing RFC1146 (tcp alternative checksum > options) in Linux tcp stack ? If yes, how soon will > that be in ? > > Please kindly copy reply to my email address as I've > not subscribed the netdev@ mailing list at present. > > http://www.faqs.org/rfcs/rfc1146.html > > Thanks! > -Yanping > > Yanping, The way that features get added to Linux is that someone interested writes it. You can't just say - is this on the roadmap, as there is no roadmap really! I have been interested in network features from an academic point of view and so I wrote what I needed (along with others) and that was added to the Linux kernel. So have a go at implementing it if you consider it important and come back here with some patches. Then others will help review it until the patches are good. I will let others comment on whether the checksums are a good idea or not. Ian -- Web1: http://wand.net.nz/~iam4/ Web2: http://www.jandi.co.nz Blog: http://iansblog.jandi.co.nz - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Will RFC1146 (tcp alternative checksum options) be implemented in Linux tcp stack ?
Hi, We found the standard 16-bit tcp checksum is not strong enough in some cases. Is there any roadmap on implementing RFC1146 (tcp alternative checksum options) in Linux tcp stack ? If yes, how soon will that be in ? Please kindly copy reply to my email address as I've not subscribed the netdev@ mailing list at present. http://www.faqs.org/rfcs/rfc1146.html Thanks! -Yanping Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH linux-2.6] bonding: two small fixes for IPoIB support
Two small fixes to IPoIB support for bonding:
1- copy header_ops from slave to bonding for IPoIB slaves
2- move release and destroy logic to UNREGISTER from GOING_DOWN
notifier to avoid double release
Set bonding to version 3.2.1.
Signed-off-by: Moni Shoua
Signed-off-by: Jay Vosburgh <[EMAIL PROTECTED]>
---
drivers/net/bonding/bond_main.c | 11 +--
drivers/net/bonding/bonding.h |4 ++--
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index db80f24..6f85cc3 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1263,6 +1263,7 @@ static void bond_setup_by_slave(struct net_device
*bond_dev,
struct bonding *bond = bond_dev->priv;
bond_dev->neigh_setup = slave_dev->neigh_setup;
+ bond_dev->header_ops= slave_dev->header_ops;
bond_dev->type = slave_dev->type;
bond_dev->hard_header_len = slave_dev->hard_header_len;
@@ -3351,7 +3352,10 @@ static int bond_slave_netdev_event(unsigned long event,
struct net_device *slave
switch (event) {
case NETDEV_UNREGISTER:
if (bond_dev) {
- bond_release(bond_dev, slave_dev);
+ if (bond->setup_by_slave)
+ bond_release_and_destroy(bond_dev, slave_dev);
+ else
+ bond_release(bond_dev, slave_dev);
}
break;
case NETDEV_CHANGE:
@@ -3366,11 +3370,6 @@ static int bond_slave_netdev_event(unsigned long event,
struct net_device *slave
* ... Or is it this?
*/
break;
- case NETDEV_GOING_DOWN:
- dprintk("slave %s is going down\n", slave_dev->name);
- if (bond->setup_by_slave)
- bond_release_and_destroy(bond_dev, slave_dev);
- break;
case NETDEV_CHANGEMTU:
/*
* TODO: Should slaves be allowed to
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index a8bbd56..b818060 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -22,8 +22,8 @@
#include "bond_3ad.h"
#include "bond_alb.h"
-#define DRV_VERSION"3.2.0"
-#define DRV_RELDATE"September 13, 2007"
+#define DRV_VERSION"3.2.1"
+#define DRV_RELDATE"October 15, 2007"
#define DRV_NAME "bonding"
#define DRV_DESCRIPTION"Ethernet Channel Bonding Driver"
--
1.5.3.1
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
On Tue, 2007-10-16 at 07:05 +1000, Benjamin Herrenschmidt wrote: > On Mon, 2007-10-15 at 15:04 -0400, Jeff Garzik wrote: > > I would ideally like a single active patch generator (even if they > > are > > merely reviewed others work sometimes). > > > > Outside of that, I'm hoping you and the other people listed making > > changes will self-organize without my help :) > > Josh, do you want to be the central point / maintainer for it or do you > want me to do it ? There's a lot of code from me in there and I did this > fork in the first place so I have a pretty good idea of what's going on > in this driver and what still needs to be done :-) As always, you're welcome to it. You probably don't want to own it long term, but I'd appreciate the help for the time being. josh - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MSI interrupts and disable_irq
Manfred Spraul wrote: Jeff Garzik wrote: I think the scenario you outline is an illustration of the approach's fragility: disable_irq() is a heavy hammer that originated with INTx, and it relies on a chip-specific disable method (kernel/irq/manage.c) that practically guarantees behavior will vary across MSI/INTx/etc. I checked the code: IRQ_DISABLE is implemented in software, i.e. handle_level_irq() only calls handle_IRQ_event() [and then the nic irq handler] if IRQ_DISABLE is not set. OTHO: The last trace looks as if nv_do_nic_poll() is interrupted by an irq. Perhaps something corrupts dev->irq? The irq is requested with request_irq(np->pci_dev->irq, handler, IRQF_SHARED, dev->name, dev) and disabled with disable_irq_lockdep(dev->irq); Someone around with a MSI capable board? The forcedeth driver does dev->irq = pci_dev->irq in nv_probe(), especially before pci_enable_msi(). Does pci_enable_msi() change pci_dev->irq? Then we would disable the wrong interrupt Remember, fundamentally MSI-X is a one-to-many relationship, when you consider a single PCI device might have multiple vectors. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
On Mon, 15 Oct 2007 15:00:22 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: > From: Stephen Hemminger <[EMAIL PROTECTED]> > Date: Mon, 15 Oct 2007 14:58:29 -0700 > > > What about using loadable firmware rather than building it into the driver? > > Stephen, do me a huge favor, and don't start down that path. > > Please... I know the history, loadable firmware is a maintenance nuisance/nightmare. And it often leads to stupid license crap. --- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: question on sky2 driver panic
On Mon, 15 Oct 2007 14:17:50 -0600 "Chris Friesen" <[EMAIL PROTECTED]> wrote: > > Hi, > > We're using Yukon-XL (0xb3) rev 3 hardware with a vendor-supplied > 2.6.14. BAsed on suggestions here, I backported the sky2 driver (v1.10 > from 2.6.20.6) to 2.6.14. > > Unfortunately, when I booted this I got the following: > > > skb_over_panic: text:d00d4e14 len:60 put:60 > head:c00264920770 data:c00264920720 tail:c00264920720 > end:c002649207a0 dev: > kernel BUG in skb_over_panic at > /usr/local/src/2.6.14/gd/linux/net/core/skbuff.c:94! > Oops: Exception in kernel mode, sig: 5 [#1] > SMP NR_CPUS=2 > Modules linked in: tipc bond1 bond0 ipmi_devintf ipmi_msghandler > NIP: C020D7E8 XER: LR: C020D7E4 CTR: > C01C210C > REGS: c0025c2aefe0 TRAP: 0700 Not tainted (2.6.14-pne) > MSR: 90029032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 CR: 28008022 > DAR: DSISR: c0025c2af1c0 > TASK: cfec2940[2107] 'insmod' THREAD: c0025c2ac000 CPU: 0 > GPR00: C020D7E4 C0025C2AF300 C041DA08 009C > GPR04: 90009032 0030 C037C428 > GPR08: C037EEF0 C043AD68 C043AC88 > GPR12: 0010 C0374000 100D47E8 > GPR16: 100D55A0 > GPR20: 0001 > GPR24: B6AA7FFF > GPR28: 003C CFEF5B10 C03BB778 003C > NIP [c020d7e8] .skb_over_panic+0x50/0x68 > LR [c020d7e4] .skb_over_panic+0x4c/0x68 > Call Trace: > [c0025c2af300] [c020d7e4] .skb_over_panic+0x4c/0x68 (unreliable) > [c0025c2af390] [d00d4e20] .named_prepare_buf+0x298/0x2a8 [tipc] > [c0025c2af450] [d00d4e90] .named_publish+0x60/0xe4 [tipc] > [c0025c2af4e0] [d00d80a8] .nametbl_publish+0x128/0x198 [tipc] > [c0025c2af590] [d00de7dc] .tipc_publish+0xe8/0x188 [tipc] > [c0025c2af650] [d00d7f4c] .nametbl_publish_rsv+0x30/0x64 [tipc] > [c0025c2af6e0] [d00d2600] .cfg_init+0x120/0x150 [tipc] > [c0025c2af7a0] [d00e31ac] .process_signal_queue+0xa4/0x100 > [tipc] > [c0025c2af8/0x1ec [tipc] > [c0025c2afcf0] [c00685ec] .sys_init_module+0x28c/0x510 > [c0025c2afd90] [c0009b9c] syscall_exit+0x0/0x18 > > > > Now granted it looks like this was triggered by tipc, but is there > anything that you can think of in the sky2 driver that may have been > related? Maybe due to the fragmented buffer handling? The link would > have been using an mtu of 9KB. > > Thanks, > > Chris Maybe TIPC can't handle fragmented receive buffers. The sky2 driver generates skb's with header and multiple pages if MTU is big enough. For 9K MTU that would be 1K of data + 2 4K pages. The protocols are supposed to be smart enough to handle this, but TIPC is rarely used. -- Stephen Hemminger <[EMAIL PROTECTED]> -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Mon, 15 Oct 2007 14:58:29 -0700 > What about using loadable firmware rather than building it into the driver? Stephen, do me a huge favor, and don't start down that path. Please... - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
On Mon, 15 Oct 2007 12:38:50 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: > From: "Eliezer Tamir" <[EMAIL PROTECTED]> > Date: Mon, 15 Oct 2007 17:27:29 +0200 > > > Unfortunately, the firmware code is different for LE and BE machines. > > We had issues with the BE firmware that appear to be resolved. > > Hopefully, the next version will have both. > > If this means we get two copies of the firmware, this should be > rethought. The space cost of the firmware (both in terms of source > code size and object code size) is already enormous. > > I would definitely prefer if there were only little-endian firmware, > and the driver uses "cpu_to_le32()" and friends to access chip shared > data structures. > > Most cpus have endian swapping loads and stores, accessible via > cpu_to_le32p() and similar interfaces, so the cost on big-endian of > doing things this way is very close to zero. > - > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html What about using loadable firmware rather than building it into the driver? -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 0/8] net/bonding: ADD IPoIB support for the bonding driver
Jay Vosburgh wrote: Jeff Garzik <[EMAIL PROTECTED]> wrote: Jay Vosburgh wrote: Since I see you've just pushed it, do you want a patch to correct just the two individual things, or would you rather have new patches? On top of what was just pushed, please. Ok, I'll figure that out and then rebase the locking stuff on top of that. FWIW Linus just pulled, so you may diff against mainline if you wish. Whatever is easiest for you... Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 0/8] net/bonding: ADD IPoIB support for the bonding driver
Jeff Garzik <[EMAIL PROTECTED]> wrote: >Jay Vosburgh wrote: >> Since I see you've just pushed it, do you want a patch to >> correct just the two individual things, or would you rather have new >> patches? > > >On top of what was just pushed, please. Ok, I'll figure that out and then rebase the locking stuff on top of that. -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] e1000e: don't poke PHY registers to retreive link status
Apparently poking the link status registers when autonegotiation
is running on the PHY might botch the PHY link on 80003es2lan
devices. While this is a very rare condition we can completely
avoid it alltogether by just using the MAC link bits to provide
the proper information to ethtool.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000e/ethtool.c | 31 +--
1 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/net/e1000e/ethtool.c b/drivers/net/e1000e/ethtool.c
index b7a7e2a..983b031 100644
--- a/drivers/net/e1000e/ethtool.c
+++ b/drivers/net/e1000e/ethtool.c
@@ -110,6 +110,7 @@ static int e1000_get_settings(struct net_device *netdev,
{
struct e1000_adapter *adapter = netdev_priv(netdev);
struct e1000_hw *hw = &adapter->hw;
+ u32 status;
if (hw->media_type == e1000_media_type_copper) {
@@ -147,16 +148,16 @@ static int e1000_get_settings(struct net_device *netdev,
ecmd->transceiver = XCVR_EXTERNAL;
}
- if (er32(STATUS) & E1000_STATUS_LU) {
-
- adapter->hw.mac.ops.get_link_up_info(hw, &adapter->link_speed,
- &adapter->link_duplex);
- ecmd->speed = adapter->link_speed;
-
- /* unfortunately FULL_DUPLEX != DUPLEX_FULL
-*and HALF_DUPLEX != DUPLEX_HALF */
+ status = er32(STATUS);
+ if (status & E1000_STATUS_LU) {
+ if (status & E1000_STATUS_SPEED_1000)
+ ecmd->speed = 1000;
+ else if (status & E1000_STATUS_SPEED_100)
+ ecmd->speed = 100;
+ else
+ ecmd->speed = 10;
- if (adapter->link_duplex == FULL_DUPLEX)
+ if (status & E1000_STATUS_FD)
ecmd->duplex = DUPLEX_FULL;
else
ecmd->duplex = DUPLEX_HALF;
@@ -170,6 +171,16 @@ static int e1000_get_settings(struct net_device *netdev,
return 0;
}
+static u32 e1000_get_link(struct net_device *netdev)
+{
+ struct e1000_adapter *adapter = netdev_priv(netdev);
+ struct e1000_hw *hw = &adapter->hw;
+ u32 status;
+
+ status = er32(STATUS);
+ return (status & E1000_STATUS_LU);
+}
+
static int e1000_set_spd_dplx(struct e1000_adapter *adapter, u16 spddplx)
{
struct e1000_mac_info *mac = &adapter->hw.mac;
@@ -1751,7 +1762,7 @@ static const struct ethtool_ops e1000_ethtool_ops = {
.get_msglevel = e1000_get_msglevel,
.set_msglevel = e1000_set_msglevel,
.nway_reset = e1000_nway_reset,
- .get_link = ethtool_op_get_link,
+ .get_link = e1000_get_link,
.get_eeprom_len = e1000_get_eeprom_len,
.get_eeprom = e1000_get_eeprom,
.set_eeprom = e1000_set_eeprom,
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re[2]: Kernel panic (network stack)
> > Hello! > > I develop network driver. > > It works fine while less then 100 network interfaces exists. > > Then i give kernel panic. What could cause it ? > > > > Since it probably in your code. Please code (or place to download) > the driver code. fixed in 0.7.9 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
On Mon, 2007-10-15 at 15:04 -0400, Jeff Garzik wrote: > I would ideally like a single active patch generator (even if they > are > merely reviewed others work sometimes). > > Outside of that, I'm hoping you and the other people listed making > changes will self-organize without my help :) Josh, do you want to be the central point / maintainer for it or do you want me to do it ? There's a lot of code from me in there and I did this fork in the first place so I have a pretty good idea of what's going on in this driver and what still needs to be done :-) Cheers, Ben. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
On Mon, 2007-10-15 at 14:53 -0400, Jeff Garzik wrote: > Roland Dreier (2): >ibm_new_emac: Nuke SET_MODULE_OWNER() use >ibm_emac: Convert to use napi_struct independent of struct > net_device > Wow, I'd have loved to be CCed at least on the last one since I was about to do just that ... Heh. Ben. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Undocumented IPv6 options
> It really looks like time for major overhaul of that (and related) man-pages > is needed... Yes. Andi Kleen did a good job of putting some pages together in the 2.2 timeframe, but no-one else carried on the work since then, and there is much that sould be updated in the *.7 networking pages. Cheers, Michael - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] e1000e: Fix debug printk macro
Spotted by Joe Perches.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000e/hw.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000e/hw.h b/drivers/net/e1000e/hw.h
index aa82f1a..6451578 100644
--- a/drivers/net/e1000e/hw.h
+++ b/drivers/net/e1000e/hw.h
@@ -852,7 +852,7 @@ struct e1000_hw {
#ifdef DEBUG
#define hw_dbg(hw, format, arg...) \
- printk(KERN_DEBUG, "%s: " format, e1000e_get_hw_dev_name(hw), ##arg);
+ printk(KERN_DEBUG "%s: " format, e1000e_get_hw_dev_name(hw), ##arg)
#else
static inline int __attribute__ ((format (printf, 2, 3)))
hw_dbg(struct e1000_hw *hw, const char *format, ...)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] e1000e: fix error checks
From: Adrian Bunk <[EMAIL PROTECTED]> Spotted by the Coverity checker. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Signed-off-by: Auke Kok <[EMAIL PROTECTED]> --- drivers/net/e1000e/ethtool.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/e1000e/ethtool.c b/drivers/net/e1000e/ethtool.c index b7a7e2a..ca06c35 100644 --- a/drivers/net/e1000e/ethtool.c +++ b/drivers/net/e1000e/ethtool.c @@ -1451,11 +1451,11 @@ static int e1000_loopback_test(struct e1000_adapter *adapter, u64 *data) } *data = e1000_setup_desc_rings(adapter); - if (data) + if (*data) goto out; *data = e1000_setup_loopback_test(adapter); - if (data) + if (*data) goto err_loopback; *data = e1000_run_loopback_test(adapter); - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] NEW EMAC Fix RGMII build error: use of_device_is_compatible
On Fri, 2007-10-12 at 17:04 +0400, Valentine Barshak wrote: > Fix build RGMII error: use of_device_is_compatible() > insteadof now deprecated device_is_compatible() function. > > Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]> Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > --- > drivers/net/ibm_newemac/rgmii.c |2 +- > 1 files changed, 1 insertion(+), 1 deletion(-) > > diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/rgmii.c > linux-2.6/drivers/net/ibm_newemac/rgmii.c > --- linux-2.6.orig/drivers/net/ibm_newemac/rgmii.c2007-10-12 > 16:02:41.0 +0400 > +++ linux-2.6/drivers/net/ibm_newemac/rgmii.c 2007-10-12 16:49:07.0 > +0400 > @@ -251,7 +251,7 @@ static int __devinit rgmii_probe(struct > } > > /* Check for RGMII type */ > - if (device_is_compatible(ofdev->node, "ibm,rgmii-axon")) > + if (of_device_is_compatible(ofdev->node, "ibm,rgmii-axon")) > dev->type = RGMII_AXON; > else > dev->type = RGMII_STANDARD; > ___ > Linuxppc-dev mailing list > [EMAIL PROTECTED] > https://ozlabs.org/mailman/listinfo/linuxppc-dev - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] r8169 Fix hang in rtl8169_down (NAPI)
From: Markus Trippelsdorf <[EMAIL PROTECTED]>
Date: Mon, 15 Oct 2007 22:25:46 +0200
> commit bea3348eef27e6044b6161fd04c3152215f96411 :
> [NET]: Make NAPI polling independent of struct net_device objects.
> causes my machine to hang on shutdown. The following patch fixes the
> problem for me.
>
> Signed-off-by: Markus Trippelsdorf <[EMAIL PROTECTED]>
This change doesn't make any sense.
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index 419c00c..2cddbf8 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -2888,10 +2888,12 @@ core_down:
>
> synchronize_irq(dev->irq);
>
> +#ifdef CONFIG_R8169_NAPI
> if (!poll_locked) {
> napi_disable(&tp->napi);
> poll_locked++;
> }
> +#endif
>
> /* Give a racing hard_start_xmit a few cycles to complete. */
> synchronize_sched(); /* FIXME: should this be synchronize_irq()? */
If anything the test should be the other way around, use of
napi interfaces should be used when R8169_NAPI is set.
You're just papering around some other bug in the NAPI support
of this driver, which someone will need to figure out and fix
correctly.
But thanks for the report, and the patch, whilst bogus, might
provide a clue.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 0/8] net/bonding: ADD IPoIB support for the bonding driver
Jay Vosburgh wrote: Since I see you've just pushed it, do you want a patch to correct just the two individual things, or would you rather have new patches? On top of what was just pushed, please. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] r8169 Fix hang in rtl8169_down (NAPI)
commit bea3348eef27e6044b6161fd04c3152215f96411 :
[NET]: Make NAPI polling independent of struct net_device objects.
causes my machine to hang on shutdown. The following patch fixes the
problem for me.
Signed-off-by: Markus Trippelsdorf <[EMAIL PROTECTED]>
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 419c00c..2cddbf8 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -2888,10 +2888,12 @@ core_down:
synchronize_irq(dev->irq);
+#ifdef CONFIG_R8169_NAPI
if (!poll_locked) {
napi_disable(&tp->napi);
poll_locked++;
}
+#endif
/* Give a racing hard_start_xmit a few cycles to complete. */
synchronize_sched(); /* FIXME: should this be synchronize_irq()? */
--
Markus
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 0/8] net/bonding: ADD IPoIB support for the bonding driver
Jeff Garzik <[EMAIL PROTECTED]> wrote: >Moni Shoua wrote: >> This is the 7th version of this patch series. See link to V6 below. >> >> Changes from the previous version >> - >> >> * Some patches required modifications to remove offsets so they can be >> applied with git-apply >> * Patch #3 was first modified by Jay and later by me to make it work with >> header_ops >> * patch #8 was changed to fix the problem that caused 'ifconfig down' to >> stuck (dev_close was called twice) > >I just applied the latest version Jay sent, are there any remaining changes? Yes, Moni changed patches 3 and 8 from the series I posted to fix a couple of problems. The others aren't changed from my posting of the series. Since I see you've just pushed it, do you want a patch to correct just the two individual things, or would you rather have new patches? -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
question on sky2 driver panic
Hi, We're using Yukon-XL (0xb3) rev 3 hardware with a vendor-supplied 2.6.14. BAsed on suggestions here, I backported the sky2 driver (v1.10 from 2.6.20.6) to 2.6.14. Unfortunately, when I booted this I got the following: skb_over_panic: text:d00d4e14 len:60 put:60 head:c00264920770 data:c00264920720 tail:c00264920720 end:c002649207a0 dev: kernel BUG in skb_over_panic at /usr/local/src/2.6.14/gd/linux/net/core/skbuff.c:94! Oops: Exception in kernel mode, sig: 5 [#1] SMP NR_CPUS=2 Modules linked in: tipc bond1 bond0 ipmi_devintf ipmi_msghandler NIP: C020D7E8 XER: LR: C020D7E4 CTR: C01C210C REGS: c0025c2aefe0 TRAP: 0700 Not tainted (2.6.14-pne) MSR: 90029032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 CR: 28008022 DAR: DSISR: c0025c2af1c0 TASK: cfec2940[2107] 'insmod' THREAD: c0025c2ac000 CPU: 0 GPR00: C020D7E4 C0025C2AF300 C041DA08 009C GPR04: 90009032 0030 C037C428 GPR08: C037EEF0 C043AD68 C043AC88 GPR12: 0010 C0374000 100D47E8 GPR16: 100D55A0 GPR20: 0001 GPR24: B6AA7FFF GPR28: 003C CFEF5B10 C03BB778 003C NIP [c020d7e8] .skb_over_panic+0x50/0x68 LR [c020d7e4] .skb_over_panic+0x4c/0x68 Call Trace: [c0025c2af300] [c020d7e4] .skb_over_panic+0x4c/0x68 (unreliable) [c0025c2af390] [d00d4e20] .named_prepare_buf+0x298/0x2a8 [tipc] [c0025c2af450] [d00d4e90] .named_publish+0x60/0xe4 [tipc] [c0025c2af4e0] [d00d80a8] .nametbl_publish+0x128/0x198 [tipc] [c0025c2af590] [d00de7dc] .tipc_publish+0xe8/0x188 [tipc] [c0025c2af650] [d00d7f4c] .nametbl_publish_rsv+0x30/0x64 [tipc] [c0025c2af6e0] [d00d2600] .cfg_init+0x120/0x150 [tipc] [c0025c2af7a0] [d00e31ac] .process_signal_queue+0xa4/0x100 [tipc] [c0025c2af8/0x1ec [tipc] [c0025c2afcf0] [c00685ec] .sys_init_module+0x28c/0x510 [c0025c2afd90] [c0009b9c] syscall_exit+0x0/0x18 Now granted it looks like this was triggered by tipc, but is there anything that you can think of in the sky2 driver that may have been related? Maybe due to the fragmented buffer handling? The link would have been using an mtu of 9KB. Thanks, Chris - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] netdev: convert non-obvious instances to use ARRAY_SIZE()
Alejandro Martinez Ruiz wrote: This will convert remaining non-obvious or naive calculations of array sizes to use ARRAY_SIZE() macro. Signed-off-by: Alejandro Martinez Ruiz <[EMAIL PROTECTED]> --- drivers/net/cassini.c |2 +- drivers/net/irda/donauboe.c |2 +- drivers/net/ne-h8300.c |4 ++-- drivers/net/tg3.c |2 +- drivers/net/tulip/de4x5.c |4 ++-- drivers/net/wan/sdla.c |8 6 files changed, 11 insertions(+), 11 deletions(-) applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Consolidate the ip6_pol_route_(input|output) pair
From: Pavel Emelyanov <[EMAIL PROTECTED]> Date: Mon, 15 Oct 2007 15:55:21 +0400 > The difference in both functions is in the "id" passed to > the rt6_select, so just pass it as an extra argument from > two outer helpers. > > This is minus 60 lines of code and 360 bytes of .text > > Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> Excellent cleanup, applied! - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [TCP]: Make snd_cwnd_cnt 32-bit
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> Date: Mon, 15 Oct 2007 18:57:31 +0300 (EEST) > > Very little point of having 32-bit snd_cnwd if this is not > 32-bit as well, as a number of snd_cwnd incrementation formulas > assume that snd_cwnd_cnt can be at least as large as snd_cwnd. > > Whether 32-bit is useful was discussed when e0ef57cc56c3c96 > was made: > http://marc.info/?l=linux-netdev&m=117218144409825&w=2 > > Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> Applied, and I intend to push this to -stable as well. Thanks! - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Update the /proc/net/tcp documentation
From: Jean Delvare <[EMAIL PROTECTED]> Date: Mon, 15 Oct 2007 19:15:07 +0200 > * Say that this interface is deprecated. > * Update function name references to match the current code. > > Signed-off-by: Jean Delvare <[EMAIL PROTECTED]> Applied, thanks! - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][NETNS] Don't panic on creating the namespace's loopback
From: Pavel Emelyanov <[EMAIL PROTECTED]> Date: Mon, 15 Oct 2007 14:23:13 +0400 > When the loopback device is failed to initialize inside the new > namespaces, panic() is called. Do not do it when the namespace > in question is not the init_net. > > Plus cleanup the error path a bit. > > Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> Fair enough, applied. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ensure that pneigh_lookup is protected with RTNL
From: Pavel Emelyanov <[EMAIL PROTECTED]> Date: Mon, 15 Oct 2007 17:38:57 +0400 > The pnigh_lookup is used to lookup proxy entries and to > create them in case lookup failed. > > However, the "creation" code does not perform the re-lookup > after GFP_KERNEL allocation. This is done because the code > is expected to be protected with the RTNL lock, so add the > assertion (mainly to address future questions from new network > developers like me :) ). > > Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> Thanks for this patch, applied. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kmalloc+memset -> kzalloc in frag_alloc_queue
From: "Denis V. Lunev" <[EMAIL PROTECTED]> Date: Mon, 15 Oct 2007 18:48:41 +0400 > kmalloc + memset -> kzalloc in frag_alloc_queue > > Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]> Applied, thanks! - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] isdn compile fix (resend)
From: Karsten Keil <[EMAIL PROTECTED]> Date: Mon, 15 Oct 2007 18:02:02 +0200 > On Mon, Oct 15, 2007 at 06:44:56PM +0400, Denis V. Lunev wrote: > Compilation fix. The problem appears after > 7c076d1de869256848dacb8de0050a3a390f95df by Karsten Keil <[EMAIL PROTECTED]> > > Acked-by: Karsten Keil <[EMAIL PROTECTED]> > Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]> Applied, thanks everyone. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
From: "Eliezer Tamir" <[EMAIL PROTECTED]> Date: Mon, 15 Oct 2007 18:22:03 +0200 > On Mon, 2007-10-15 at 18:05 +0200, Andi Kleen wrote: > > > This is not a driver issue. > > > Unfortunately, the firmware code is different for LE and BE machines. > > > We had issues with the BE firmware that appear to be resolved. > > > Hopefully, the next version will have both. > > > > If the firmware is big it might be better to just add the necessary > > conversions to the driver and always use BE. Endian conversions > > tend to be very cheap. > > For a given architecture, only the right version of the microcode is > compiled, so the binary only contains one copy of the microcode. But it still takes up source tree space. > The good news is that future versions of the device will not have this > issue. > The better news is that you only need the little-endian firmware even with these chips, simple assume little-endian for all chip shared data-structures and swap in the driver as we've explained to you. The cost for big-endian cpus is almost nothing. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
From: "Eliezer Tamir" <[EMAIL PROTECTED]> Date: Mon, 15 Oct 2007 17:27:29 +0200 > Unfortunately, the firmware code is different for LE and BE machines. > We had issues with the BE firmware that appear to be resolved. > Hopefully, the next version will have both. If this means we get two copies of the firmware, this should be rethought. The space cost of the firmware (both in terms of source code size and object code size) is already enormous. I would definitely prefer if there were only little-endian firmware, and the driver uses "cpu_to_le32()" and friends to access chip shared data structures. Most cpus have endian swapping loads and stores, accessible via cpu_to_le32p() and similar interfaces, so the cost on big-endian of doing things this way is very close to zero. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] FEC - fast ethernet controller for mpc52xx
On 10/15/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: > Domen Puncer wrote: > > Hello! > > > > If there are no objections, I would like to get this merged > > when bestcomm goes in (any time now?). > > > > It's split into four parts: > > 1 - device tree > > 2 - small bestcomm change > > 3 - the actual driver > > 4 - phy part of the driver > > patches #3 and #4 need to be combined together. > > Are the arch people OK with patches #1 and #2? Yes, I'll be pushing both to Paulus shortly. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] forcedeth: Fix MAC address detection on network card (regression in 2.6.23)
Jeff Garzik wrote:
Michael Pyne wrote:
Partially revert a change to mac address detection introduced to the
forcedeth driver. The change was intended to correct mac address
detection for newer nVidia chipsets where the mac address was stored
in reverse order. One of those chipsets appears to still have the mac
address in reverse order (or at least, it does on my system).
Signed-off-by: Michael J. Pyne <[EMAIL PROTECTED]>
---
The change that broke mac address detection for my card was commit
ef756b3e56c68a4d76d9d7b9a73fa8f4f739180f "forcedeth: mac address correct"
My network card is an nVidia built-in Ethernet card, output from lspci
as follows (with text and numeric ids):
$ lspci | grep Ethernet
00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2)
$ lspci -n | grep 07.0
00:07.0 0680: 10de:03ef (rev a2)
The vendor id is, of course, nVidia. The device id corresponds to the
NVIDIA_NVENET_19 entry.
The included patch fixes the MAC address detection on my system.
Interestingly, the MAC address appears to be in the range reserved for
my motherboard manufacturer (Gigabyte) and not nVidia.
If you need any further information about my hardware configuration
just let me know.
Regards,
- Michael Pyne
--- a/drivers/net/forcedeth.c 2007-10-11 22:01:26 -0400
+++ b/drivers/net/forcedeth-new.c 2007-10-11 22:06:52 -0400
@@ -5513,7 +5513,7 @@ static struct pci_device_id pci_tbl[] = },
{/* 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|DEV_HAS_CORRECT_MACADDR,
+.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,
},
{/* MCP65 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NVENET_20),
your patch is word-wrapped. Anyway...
Ayaz -- ACK this patch?
ASUS should be contacted to fix their SBIOS instead of patching the driver.
MCP61 reference has the correct address programmed by SBIOS. There are
other vendor boards that will have correct address (as defined by MCP61
reference).
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] Convert bonding timers to workqueues
Jeff Garzik <[EMAIL PROTECTED]> wrote: >Jay Vosburgh wrote: >> Convert bonding timers to workqueues. This converts the various >> monitor functions to run in periodic work queues instead of timers. This >> patch introduces the framework and convers the calls, but does not resolve >> various locking issues, and does not stand alone. >> >> Signed-off-by: Andy Gospodarek <[EMAIL PROTECTED]> >> Signed-off-by: Jay Vosburgh <[EMAIL PROTECTED]> > >"does not stand alone" == it is not bisectable? That's a problem. The patch will compile fine (this is true for any point in the series), but it's possible for bonding to deadlock or misbehave when doing certain operations. Those problems are addressed in the later patches. I didn't want to just vomit out one big mega-patch that has the whole set of changes, because that's harder to understand, and the later patches generally address discrete issues. Does that make you more or less nervous about its bisectability? I can repost the whole thing as a big blob if that's what you'd prefer. >Anyway, we have more fun fish to fry: after applying the IPoIB bonding >patchset, this no longer applies... Yah, I'll rebase it (once I know your blob vs. not-blob preference). I wasn't sure how long the IPoIB mystery bug hunt was going to take. -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
Josh Boyer wrote: On Mon, 15 Oct 2007 14:53:26 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote: Seems sane to me -- ACK -- but we have multiple people sending me patches for a single driver. That's normal for janitorial cleanups across the whole tree, but discouraged when multiple people are actively working on the same driver. Please coordinate, and have ONE person send me patches... Who else is sending you patches? Valentine is the only one I've seen send patches recently... It's a zoo :) Wow, indeed. Al Viro (3): typo in ibm_newemac/rgmii.c Val sent this as well. Either one works. skb->tail in ibm_newemac should be skb_tail_pointer() ibm_newemac annotations (iomem, NULL noise) Ack on those. David Gibson (1): Device tree aware EMAC driver That's the initial commit :) Michael Ellerman (3): Update ibm_newemac to use dcr_host_t.base Add dcr_host_t.base in dcr_read()/dcr_write() Use dcr_host_t.base in dcr_unmap() Missed those, but I see you applied them which is good. Roland Dreier (2): ibm_new_emac: Nuke SET_MODULE_OWNER() use ibm_emac: Convert to use napi_struct independent of struct net_device I never saw either of these. I'm also beginning to wonder if one of them broke things because I can't currently get ibm_newemac to work. [EMAIL PROTECTED] (1): Fix typo in new EMAC driver. Same fix as Al's. All those are what's upstream, except for the Michael Ellerman patches. FWIW it was generated using git log drivers/net/ibm_newemac | git shortlog Anyway, we can queue patches to this through me if you'd like. I would ideally like a single active patch generator (even if they are merely reviewed others work sometimes). Outside of that, I'm hoping you and the other people listed making changes will self-organize without my help :) Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] FEC - fast ethernet controller for mpc52xx
Domen Puncer wrote: Hello! If there are no objections, I would like to get this merged when bestcomm goes in (any time now?). It's split into four parts: 1 - device tree 2 - small bestcomm change 3 - the actual driver 4 - phy part of the driver patches #3 and #4 need to be combined together. Are the arch people OK with patches #1 and #2? Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
On Mon, 15 Oct 2007 14:53:26 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote: > >> Seems sane to me -- ACK -- but we have multiple people sending me > >> patches for a single driver. That's normal for janitorial cleanups > >> across the whole tree, but discouraged when multiple people are actively > >> working on the same driver. > >> > >> Please coordinate, and have ONE person send me patches... > > > > Who else is sending you patches? Valentine is the only one I've seen > > send patches recently... > > It's a zoo :) Wow, indeed. > Al Viro (3): >typo in ibm_newemac/rgmii.c Val sent this as well. Either one works. >skb->tail in ibm_newemac should be skb_tail_pointer() >ibm_newemac annotations (iomem, NULL noise) Ack on those. > David Gibson (1): >Device tree aware EMAC driver That's the initial commit :) > Michael Ellerman (3): >Update ibm_newemac to use dcr_host_t.base >Add dcr_host_t.base in dcr_read()/dcr_write() >Use dcr_host_t.base in dcr_unmap() Missed those, but I see you applied them which is good. > Roland Dreier (2): >ibm_new_emac: Nuke SET_MODULE_OWNER() use >ibm_emac: Convert to use napi_struct independent of struct net_device I never saw either of these. I'm also beginning to wonder if one of them broke things because I can't currently get ibm_newemac to work. > [EMAIL PROTECTED] (1): >Fix typo in new EMAC driver. Same fix as Al's. Anyway, we can queue patches to this through me if you'd like. josh - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
Josh Boyer wrote:
On Mon, 15 Oct 2007 14:27:23 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
Valentine Barshak wrote:
This patch adds BCM5248 and Marvell 88E PHY support to NEW EMAC driver.
These PHY chips are used on PowerPC 440EPx boards.
The PHY code is based on the previous work by Stefan Roese <[EMAIL PROTECTED]>
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/phy.c | 39 +++
1 files changed, 39 insertions(+)
--- linux.orig/drivers/net/ibm_newemac/phy.c2007-06-15 21:45:18.0
+0400
+++ linux/drivers/net/ibm_newemac/phy.c 2007-06-15 20:45:15.0 +0400
@@ -306,8 +306,47 @@
.ops= &cis8201_phy_ops
};
+static struct mii_phy_def bcm5248_phy_def = {
+
+ .phy_id = 0x0143bc00,
+ .phy_id_mask= 0x0ff0,
+ .name = "BCM5248 10/100 SMII Ethernet",
+ .ops= &generic_phy_ops
+};
+
+static int m88e_init(struct mii_phy *phy)
+{
+ printk("%s: Marvell 88E Ethernet\n", __FUNCTION__);
+ phy_write(phy, 0x14, 0x0ce3);
+ phy_write(phy, 0x18, 0x4101);
+ phy_write(phy, 0x09, 0x0e00);
+ phy_write(phy, 0x04, 0x01e1);
+ phy_write(phy, 0x00, 0x9140);
+ phy_write(phy, 0x00, 0x1140);
+
+ return 0;
+}
+
+static struct mii_phy_ops m88e_phy_ops = {
+ .init = m88e_init,
+ .setup_aneg = genmii_setup_aneg,
+ .setup_forced = genmii_setup_forced,
+ .poll_link = genmii_poll_link,
+ .read_link = genmii_read_link
+};
+
+static struct mii_phy_def m88e_phy_def = {
+
+ .phy_id = 0x01410CC0,
+ .phy_id_mask= 0x0ff0,
+ .name = "Marvell 88E Ethernet",
+ .ops= &m88e_phy_ops,
+};
+
static struct mii_phy_def *mii_phy_table[] = {
&cis8201_phy_def,
+ &bcm5248_phy_def,
+ &m88e_phy_def,
&genmii_phy_def,
Seems sane to me -- ACK -- but we have multiple people sending me
patches for a single driver. That's normal for janitorial cleanups
across the whole tree, but discouraged when multiple people are actively
working on the same driver.
Please coordinate, and have ONE person send me patches...
Who else is sending you patches? Valentine is the only one I've seen
send patches recently...
It's a zoo :)
Al Viro (3):
typo in ibm_newemac/rgmii.c
skb->tail in ibm_newemac should be skb_tail_pointer()
ibm_newemac annotations (iomem, NULL noise)
David Gibson (1):
Device tree aware EMAC driver
Michael Ellerman (3):
Update ibm_newemac to use dcr_host_t.base
Add dcr_host_t.base in dcr_read()/dcr_write()
Use dcr_host_t.base in dcr_unmap()
Roland Dreier (2):
ibm_new_emac: Nuke SET_MODULE_OWNER() use
ibm_emac: Convert to use napi_struct independent of struct net_device
[EMAIL PROTECTED] (1):
Fix typo in new EMAC driver.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] [POWERPC] ucc_geth: Fix build break introduced by commit 09f75cd7bf13720738e6a196cc0107ce9a5bd5a0
Emil Medve wrote: drivers/net/ucc_geth.c: In function 'ucc_geth_rx': drivers/net/ucc_geth.c:3483: error: 'dev' undeclared (first use in this function) drivers/net/ucc_geth.c:3483: error: (Each undeclared identifier is reported only once drivers/net/ucc_geth.c:3483: error: for each function it appears in.) make[2]: *** [drivers/net/ucc_geth.o] Error 1 Signed-off-by: Emil Medve <[EMAIL PROTECTED]> --- Here is a convenient link for the culprit patch: http://git.kernel.org/?p=linux/kernel/git/jgarzik/netdev-2.6.git;a=commit;h=09f75cd7bf13720738e6a196cc0107ce9a5bd5a0 netdev-2.6> scripts/checkpatch.pl 0001-POWERPC-ucc_geth-Fix-build-break-introduced-by-co.patch Your patch has no obvious style problems and is ready for submission. applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
On Mon, 15 Oct 2007 14:27:23 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Valentine Barshak wrote:
> > This patch adds BCM5248 and Marvell 88E PHY support to NEW EMAC driver.
> > These PHY chips are used on PowerPC 440EPx boards.
> > The PHY code is based on the previous work by Stefan Roese <[EMAIL
> > PROTECTED]>
> >
> > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> > Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
> > ---
> > drivers/net/ibm_newemac/phy.c | 39
> > +++
> > 1 files changed, 39 insertions(+)
> >
> > --- linux.orig/drivers/net/ibm_newemac/phy.c2007-06-15
> > 21:45:18.0 +0400
> > +++ linux/drivers/net/ibm_newemac/phy.c 2007-06-15 20:45:15.0
> > +0400
> > @@ -306,8 +306,47 @@
> > .ops= &cis8201_phy_ops
> > };
> >
> > +static struct mii_phy_def bcm5248_phy_def = {
> > +
> > + .phy_id = 0x0143bc00,
> > + .phy_id_mask= 0x0ff0,
> > + .name = "BCM5248 10/100 SMII Ethernet",
> > + .ops= &generic_phy_ops
> > +};
> > +
> > +static int m88e_init(struct mii_phy *phy)
> > +{
> > + printk("%s: Marvell 88E Ethernet\n", __FUNCTION__);
> > + phy_write(phy, 0x14, 0x0ce3);
> > + phy_write(phy, 0x18, 0x4101);
> > + phy_write(phy, 0x09, 0x0e00);
> > + phy_write(phy, 0x04, 0x01e1);
> > + phy_write(phy, 0x00, 0x9140);
> > + phy_write(phy, 0x00, 0x1140);
> > +
> > + return 0;
> > +}
> > +
> > +static struct mii_phy_ops m88e_phy_ops = {
> > + .init = m88e_init,
> > + .setup_aneg = genmii_setup_aneg,
> > + .setup_forced = genmii_setup_forced,
> > + .poll_link = genmii_poll_link,
> > + .read_link = genmii_read_link
> > +};
> > +
> > +static struct mii_phy_def m88e_phy_def = {
> > +
> > + .phy_id = 0x01410CC0,
> > + .phy_id_mask= 0x0ff0,
> > + .name = "Marvell 88E Ethernet",
> > + .ops= &m88e_phy_ops,
> > +};
> > +
> > static struct mii_phy_def *mii_phy_table[] = {
> > &cis8201_phy_def,
> > + &bcm5248_phy_def,
> > + &m88e_phy_def,
> > &genmii_phy_def,
>
> Seems sane to me -- ACK -- but we have multiple people sending me
> patches for a single driver. That's normal for janitorial cleanups
> across the whole tree, but discouraged when multiple people are actively
> working on the same driver.
>
> Please coordinate, and have ONE person send me patches...
Who else is sending you patches? Valentine is the only one I've seen
send patches recently...
josh
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gianfar: Cleanup compile warning caused by 0795af57
Li Yang wrote: Signed-off-by: Li Yang <[EMAIL PROTECTED]> --- drivers/net/gianfar.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) applied all three gianfar patches - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] Convert bonding timers to workqueues
Jay Vosburgh wrote: Convert bonding timers to workqueues. This converts the various monitor functions to run in periodic work queues instead of timers. This patch introduces the framework and convers the calls, but does not resolve various locking issues, and does not stand alone. Signed-off-by: Andy Gospodarek <[EMAIL PROTECTED]> Signed-off-by: Jay Vosburgh <[EMAIL PROTECTED]> "does not stand alone" == it is not bisectable? That's a problem. Anyway, we have more fun fish to fry: after applying the IPoIB bonding patchset, this no longer applies... - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET] MIPSsim: General cleanup
Ralf Baechle wrote: General cleanups mostly as suggested by checkpatch plus getting rid of homebrew version of offsetof(). Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]> applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tehuti: possible leak in bdx_probe
Florin Malita wrote: If pci_enable_device fails, bdx_probe returns without freeing the allocated pci_nic structure. Coverity CID 1908. Signed-off-by: Florin Malita <[EMAIL PROTECTED]> --- drivers/net/tehuti.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET] Jazzsonic: Fix warning about unused variable.
Ralf Baechle wrote: Caused by "[NET]: Introduce and use print_mac() and DECLARE_MAC_BUF()" aka 0795af5729b18218767fab27c44b1384f72dc9ad. Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]> applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET] SAA9730: Fix build
Ralf Baechle wrote: Fix build breakage by the recent statistics cleanup in cset 09f75cd7bf13720738e6a196cc0107ce9a5bd5a0. Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]> applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET] TC35815: Fix build
Ralf Baechle wrote: bea3348eef27e6044b6161fd04c3152215f96411 broke the build of tc35815.c for the non-NAPI case: CC drivers/net/tc35815.o drivers/net/tc35815.c: In function 'tc35815_interrupt': drivers/net/tc35815.c:1464: error: redefinition of 'lp' drivers/net/tc35815.c:1443: error: previous definition of 'lp' was here Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]> applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] forcedeth: Fix MAC address detection on network card (regression in 2.6.23)
Michael Pyne wrote:
Partially revert a change to mac address detection introduced to the forcedeth
driver. The change was intended to correct mac address detection for newer
nVidia chipsets where the mac address was stored in reverse order. One of
those chipsets appears to still have the mac address in reverse order (or at
least, it does on my system).
Signed-off-by: Michael J. Pyne <[EMAIL PROTECTED]>
---
The change that broke mac address detection for my card was commit
ef756b3e56c68a4d76d9d7b9a73fa8f4f739180f "forcedeth: mac address correct"
My network card is an nVidia built-in Ethernet card, output from lspci as
follows (with text and numeric ids):
$ lspci | grep Ethernet
00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2)
$ lspci -n | grep 07.0
00:07.0 0680: 10de:03ef (rev a2)
The vendor id is, of course, nVidia. The device id corresponds to the
NVIDIA_NVENET_19 entry.
The included patch fixes the MAC address detection on my system.
Interestingly, the MAC address appears to be in the range reserved for my
motherboard manufacturer (Gigabyte) and not nVidia.
If you need any further information about my hardware configuration just let
me know.
Regards,
- Michael Pyne
--- a/drivers/net/forcedeth.c 2007-10-11 22:01:26 -0400
+++ b/drivers/net/forcedeth-new.c 2007-10-11 22:06:52 -0400
@@ -5513,7 +5513,7 @@ static struct pci_device_id pci_tbl[] =
},
{ /* 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|DEV_HAS_CORRECT_MACADDR,
+ .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,
},
{ /* MCP65 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NVENET_20),
your patch is word-wrapped. Anyway...
Ayaz -- ACK this patch?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
Valentine Barshak wrote:
This patch adds BCM5248 and Marvell 88E PHY support to NEW EMAC driver.
These PHY chips are used on PowerPC 440EPx boards.
The PHY code is based on the previous work by Stefan Roese <[EMAIL PROTECTED]>
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/phy.c | 39 +++
1 files changed, 39 insertions(+)
--- linux.orig/drivers/net/ibm_newemac/phy.c2007-06-15 21:45:18.0
+0400
+++ linux/drivers/net/ibm_newemac/phy.c 2007-06-15 20:45:15.0 +0400
@@ -306,8 +306,47 @@
.ops= &cis8201_phy_ops
};
+static struct mii_phy_def bcm5248_phy_def = {
+
+ .phy_id = 0x0143bc00,
+ .phy_id_mask= 0x0ff0,
+ .name = "BCM5248 10/100 SMII Ethernet",
+ .ops= &generic_phy_ops
+};
+
+static int m88e_init(struct mii_phy *phy)
+{
+ printk("%s: Marvell 88E Ethernet\n", __FUNCTION__);
+ phy_write(phy, 0x14, 0x0ce3);
+ phy_write(phy, 0x18, 0x4101);
+ phy_write(phy, 0x09, 0x0e00);
+ phy_write(phy, 0x04, 0x01e1);
+ phy_write(phy, 0x00, 0x9140);
+ phy_write(phy, 0x00, 0x1140);
+
+ return 0;
+}
+
+static struct mii_phy_ops m88e_phy_ops = {
+ .init = m88e_init,
+ .setup_aneg = genmii_setup_aneg,
+ .setup_forced = genmii_setup_forced,
+ .poll_link = genmii_poll_link,
+ .read_link = genmii_read_link
+};
+
+static struct mii_phy_def m88e_phy_def = {
+
+ .phy_id = 0x01410CC0,
+ .phy_id_mask= 0x0ff0,
+ .name = "Marvell 88E Ethernet",
+ .ops= &m88e_phy_ops,
+};
+
static struct mii_phy_def *mii_phy_table[] = {
&cis8201_phy_def,
+ &bcm5248_phy_def,
+ &m88e_phy_def,
&genmii_phy_def,
Seems sane to me -- ACK -- but we have multiple people sending me
patches for a single driver. That's normal for janitorial cleanups
across the whole tree, but discouraged when multiple people are actively
working on the same driver.
Please coordinate, and have ONE person send me patches...
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][MIPS] AR7 ethernet
applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 0/8] net/bonding: ADD IPoIB support for the bonding driver
Moni Shoua wrote: This is the 7th version of this patch series. See link to V6 below. Changes from the previous version - * Some patches required modifications to remove offsets so they can be applied with git-apply * Patch #3 was first modified by Jay and later by me to make it work with header_ops * patch #8 was changed to fix the problem that caused 'ifconfig down' to stuck (dev_close was called twice) I just applied the latest version Jay sent, are there any remaining changes? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] myri10ge: fix some indentation, white spaces, and comments
Brice Goglin wrote: Fix one comment in myri10ge.c and update indendation and white spaces to match the code generated by indent from upstream CVS. Signed-off-by: Brice Goglin <[EMAIL PROTECTED]> --- drivers/net/myri10ge/myri10ge.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) applied 1-5 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] IB/ipoib: Bound the net device to the ipoib_neigh structue
Jay Vosburgh wrote: From: Moni Shoua <[EMAIL PROTECTED]> IPoIB uses a two layer neighboring scheme, such that for each struct neighbour whose device is an ipoib one, there is a struct ipoib_neigh buddy which is created on demand at the tx flow by an ipoib_neigh_alloc(skb->dst->neighbour) call. When using the bonding driver, neighbours are created by the net stack on behalf of the bonding (master) device. On the tx flow the bonding code gets an skb such that skb->dev points to the master device, it changes this skb to point on the slave device and calls the slave hard_start_xmit function. Under this scheme, ipoib_neigh_destructor assumption that for each struct neighbour it gets, n->dev is an ipoib device and hence netdev_priv(n->dev) can be casted to struct ipoib_dev_priv is buggy. To fix it, this patch adds a dev field to struct ipoib_neigh which is used instead of the struct neighbour dev one, when n->dev->flags has the IFF_MASTER bit set. Signed-off-by: Moni Shoua Signed-off-by: Or Gerlitz Acked-by: Roland Dreier <[EMAIL PROTECTED]> applied 1-9, yay! - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] natsemi: Use round_jiffies() for slow timers
Mark Brown wrote: Unless we have failed to fill the RX ring the timer used by the natsemi driver is not particularly urgent and can use round_jiffies() to allow grouping with other timers. Signed-off-by: Mark Brown <[EMAIL PROTECTED]> --- Rediffed against current netdev-2.6.git#upstream drivers/net/natsemi.c | 10 +++--- 1 files changed, 7 insertions(+), 3 deletions(-) applied and the pci_enabie_device() return value patch - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] PowerPC: Enable NEW EMAC support for Sequoia 440EPx.
This patch enables NEW EMAC support for PowerPC 440EPx Sequoia board. Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]> --- arch/powerpc/platforms/44x/Kconfig |7 +++ 1 files changed, 3 insertions(+), 4 deletions(-) --- linux.orig/arch/powerpc/platforms/44x/Kconfig 2007-07-30 15:05:50.0 +0400 +++ linux/arch/powerpc/platforms/44x/Kconfig2007-07-30 17:59:05.0 +0400 @@ -48,10 +48,9 @@ config 440EPX bool select PPC_FPU -# Disabled until the new EMAC Driver is merged. -# select IBM_NEW_EMAC_EMAC4 -# select IBM_NEW_EMAC_RGMII -# select IBM_NEW_EMAC_ZMII + select IBM_NEW_EMAC_EMAC4 + select IBM_NEW_EMAC_RGMII + select IBM_NEW_EMAC_ZMII config 440GP bool - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
This patch adds BCM5248 and Marvell 88E PHY support to NEW EMAC driver.
These PHY chips are used on PowerPC 440EPx boards.
The PHY code is based on the previous work by Stefan Roese <[EMAIL PROTECTED]>
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/phy.c | 39 +++
1 files changed, 39 insertions(+)
--- linux.orig/drivers/net/ibm_newemac/phy.c2007-06-15 21:45:18.0
+0400
+++ linux/drivers/net/ibm_newemac/phy.c 2007-06-15 20:45:15.0 +0400
@@ -306,8 +306,47 @@
.ops= &cis8201_phy_ops
};
+static struct mii_phy_def bcm5248_phy_def = {
+
+ .phy_id = 0x0143bc00,
+ .phy_id_mask= 0x0ff0,
+ .name = "BCM5248 10/100 SMII Ethernet",
+ .ops= &generic_phy_ops
+};
+
+static int m88e_init(struct mii_phy *phy)
+{
+ printk("%s: Marvell 88E Ethernet\n", __FUNCTION__);
+ phy_write(phy, 0x14, 0x0ce3);
+ phy_write(phy, 0x18, 0x4101);
+ phy_write(phy, 0x09, 0x0e00);
+ phy_write(phy, 0x04, 0x01e1);
+ phy_write(phy, 0x00, 0x9140);
+ phy_write(phy, 0x00, 0x1140);
+
+ return 0;
+}
+
+static struct mii_phy_ops m88e_phy_ops = {
+ .init = m88e_init,
+ .setup_aneg = genmii_setup_aneg,
+ .setup_forced = genmii_setup_forced,
+ .poll_link = genmii_poll_link,
+ .read_link = genmii_read_link
+};
+
+static struct mii_phy_def m88e_phy_def = {
+
+ .phy_id = 0x01410CC0,
+ .phy_id_mask= 0x0ff0,
+ .name = "Marvell 88E Ethernet",
+ .ops= &m88e_phy_ops,
+};
+
static struct mii_phy_def *mii_phy_table[] = {
&cis8201_phy_def,
+ &bcm5248_phy_def,
+ &m88e_phy_def,
&genmii_phy_def,
NULL
};
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] e1000e: fix debugging printout code
Joe Perches wrote: > On Mon, 2007-10-15 at 09:20 -0700, Kok, Auke wrote: >>> Instead the fix should be for the 2 existing bugs on macro: >>> o Comma after KERN_DEBUG >>> o Semicolon in macro >> will push a patch, thanks. > > Perhaps you could fix this one too? > > $ grep -P -r --include=*.[ch] "\bprintk\s*\(\s*KERN_[A-Z]+\s*\," * > drivers/net/ucc_geth_mii.c:#define vdbg(format, arg...) printk(KERN_DEBUG , > format "\n" , ## arg) Just send a patch yourself... :) Auke - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Update the /proc/net/tcp documentation
* Say that this interface is deprecated. * Update function name references to match the current code. Signed-off-by: Jean Delvare <[EMAIL PROTECTED]> --- Second version, updated based on Rick Jones' comments. Documentation/networking/proc_net_tcp.txt |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- linux-2.6.23-rc0.orig/Documentation/networking/proc_net_tcp.txt 2007-10-15 10:12:39.0 +0200 +++ linux-2.6.23-rc0/Documentation/networking/proc_net_tcp.txt 2007-10-15 19:11:57.0 +0200 @@ -1,8 +1,9 @@ This document describes the interfaces /proc/net/tcp and /proc/net/tcp6. +Note that these interfaces are deprecated in favor of tcp_diag. These /proc interfaces provide information about currently active TCP -connections, and are implemented by tcp_get_info() in net/ipv4/tcp_ipv4.c and -tcp6_get_info() in net/ipv6/tcp_ipv6.c, respectively. +connections, and are implemented by tcp4_seq_show() in net/ipv4/tcp_ipv4.c +and tcp6_seq_show() in net/ipv6/tcp_ipv6.c, respectively. It will first list all listening TCP sockets, and next list all established TCP connections. A typical entry of /proc/net/tcp would look like this (split -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] [IPV6]: Add skb_is_gso_v6
David Miller wrote: From: Brice Goglin <[EMAIL PROTECTED]> Date: Sat, 13 Oct 2007 12:33:32 +0200 Add skb_is_gso_v6(). Signed-off-by: Brice Goglin <[EMAIL PROTECTED]> No objections from me: Acked-by: David S. Miller <[EMAIL PROTECTED]> Jeff, it's simplest if you just merge this in with the rest of the myri10ge patches, so please do so. Thanks! Already in the queue (though waiting on an email like this) Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
ip_gre: sendto/recvfrom NBMA address
When GRE tunnel is in NBMA mode, this patch allows an application to use
a PF_PACKET socket to:
- send a packet to specific NBMA address with sendto()
- use recvfrom() to receive packet and check which NBMA address it came from
This is required to implement properly NHRP over GRE tunnel.
Signed-off-by: Timo Teras <[EMAIL PROTECTED]>
---
commit 14ebc80596af5e8422b5db2120cf3e0d801ddd3a
tree b9fc7b2b8465d506deb5a5f05f22c04f5049cd5f
parent 4271e0f7e12bdbbd7ce131187aaae2ba5233a309
author Timo Teras <[EMAIL PROTECTED]> Mon, 15 Oct 2007 19:49:52 +0300
committer Timo Teras <[EMAIL PROTECTED]> Mon, 15 Oct 2007 19:49:52 +0300
net/ipv4/ip_gre.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index f151900..b1e3816 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -1033,7 +1033,6 @@ static int ipgre_tunnel_change_mtu(struct net_device
*dev, int new_mtu)
return 0;
}
-#ifdef CONFIG_NET_IPGRE_BROADCAST
/* Nice toy. Unfortunately, useless in real life :-)
It allows to construct virtual multiprotocol broadcast "LAN"
over the Internet, provided multicast routing is tuned.
@@ -1092,10 +1091,19 @@ static int ipgre_header(struct sk_buff *skb, struct
net_device *dev,
return -t->hlen;
}
+static int ipgre_header_parse(const struct sk_buff *skb, unsigned char *haddr)
+{
+ struct iphdr *iph = (struct iphdr*) skb_mac_header(skb);
+ memcpy(haddr, &iph->saddr, 4);
+ return 4;
+}
+
static const struct header_ops ipgre_header_ops = {
.create = ipgre_header,
+ .parse = ipgre_header_parse,
};
+#ifdef CONFIG_NET_IPGRE_BROADCAST
static int ipgre_open(struct net_device *dev)
{
struct ip_tunnel *t = netdev_priv(dev);
@@ -1197,6 +1205,8 @@ static int ipgre_tunnel_init(struct net_device *dev)
dev->stop = ipgre_close;
}
#endif
+ } else {
+ dev->header_ops = &ipgre_header_ops;
}
if (!tdev && tunnel->parms.link)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] e1000e: fix debugging printout code
On Mon, 2007-10-15 at 09:20 -0700, Kok, Auke wrote: > > Instead the fix should be for the 2 existing bugs on macro: > > o Comma after KERN_DEBUG > > o Semicolon in macro > will push a patch, thanks. Perhaps you could fix this one too? $ grep -P -r --include=*.[ch] "\bprintk\s*\(\s*KERN_[A-Z]+\s*\," * drivers/net/ucc_geth_mii.c:#define vdbg(format, arg...) printk(KERN_DEBUG , format "\n" , ## arg) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes
On Mon, 15 Oct 2007, Jarek Poplawski wrote: > Could you explain why cancel_work_sync() is better here than > flush_scheduled_work() wrt. rtnl_lock()? Well, this is actually the bit that made cancel_work_sync() be written in the first place. The short story is the netlink lock is most probably held at this point (depending on the usage of phy_disconnect()) and there is also an event waiting in the queue that requires the lock, so if flush_scheduled_work() is called here a deadlock will happen. Let me find a reference for a longer story...: http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=Pine.LNX.4.64N.0610031509380.4642%40blysk.ds.pg.gda.pl and then discussed again: http://www.uwsg.indiana.edu/hypermail/linux/kernel/0612.0/0593.html Maciej - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bonding support for eth1394?
Failover between disparate link-types sounds like a job for IP and routing. rick jones - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
r8169 Driver History
I'm maintaining a CentOS wiki page for the RTL8110 NIC: http://wiki.centos.org/HardwareList/RealTekr1000 I don't think I have the version history quite right between the 2.2LK-NAPI version of the driver that's included in the kernel and the 6.003.00-NAPI version that Realtek has posted on their site. Can anyone point me to correct information that I can post on the wiki. On a related issue, I also have a page for the RTL8111 NIC that requires Realtek's r8168 driver. What are the plans for adding that driver to the kernel? Thanks for your help. Kirk Bocek - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] e1000e: fix debugging printout code
Joe Perches wrote:
> On Fri, 2007-10-05 at 13:53 -0400, Jeff Garzik wrote:
>>> diff --git a/drivers/net/e1000e/hw.h b/drivers/net/e1000e/hw.h
>>> index 848217a..aa82f1a 100644
>>> --- a/drivers/net/e1000e/hw.h
>>> +++ b/drivers/net/e1000e/hw.h
>>> @@ -852,7 +852,7 @@ struct e1000_hw {
>>>
>>> #ifdef DEBUG
>>> #define hw_dbg(hw, format, arg...) \
>>> - printk(KERN_DEBUG, "%s: " format, e1000_get_hw_dev_name(hw), ##arg);
>>> + printk(KERN_DEBUG, "%s: " format, e1000e_get_hw_dev_name(hw), ##arg);
>> I will apply this, but, I strongly encourage deletion of this in favor
>> of the existing dev_dbg()
>
> Instead the fix should be for the 2 existing bugs on macro:
>
> o Comma after KERN_DEBUG
> o Semicolon in macro
will push a patch, thanks.
Auke
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
On Mon, Oct 15, 2007 at 06:22:03PM +0200, Eliezer Tamir wrote: > On Mon, 2007-10-15 at 18:05 +0200, Andi Kleen wrote: > > > This is not a driver issue. > > > Unfortunately, the firmware code is different for LE and BE machines. > > > We had issues with the BE firmware that appear to be resolved. > > > Hopefully, the next version will have both. > > > > If the firmware is big it might be better to just add the necessary > > conversions to the driver and always use BE. Endian conversions > > tend to be very cheap. > > For a given architecture, only the right version of the microcode is > compiled, so the binary only contains one copy of the microcode. But we still have source code bloat. drivers/net already has too much binary gibberish in hex; no need to add to it unnecessarily. -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] e1000e/ethtool.c: fix error checks
Adrian Bunk wrote: > You want to check for the value, not for the address. > > Spotted by the Coverity checker. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > --- > --- a/drivers/net/e1000e/ethtool.c > +++ b/drivers/net/e1000e/ethtool.c > @@ -1451,11 +1451,11 @@ static int e1000_loopback_test(struct e1000_adapter > *adapter, u64 *data) > } > > *data = e1000_setup_desc_rings(adapter); > - if (data) > + if (*data) > goto out; > > *data = e1000_setup_loopback_test(adapter); > - if (data) > + if (*data) > goto err_loopback; > > *data = e1000_run_loopback_test(adapter); I'll forward this to Jeff, thanks. Auke - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
On Mon, 2007-10-15 at 18:05 +0200, Andi Kleen wrote: > > This is not a driver issue. > > Unfortunately, the firmware code is different for LE and BE machines. > > We had issues with the BE firmware that appear to be resolved. > > Hopefully, the next version will have both. > > If the firmware is big it might be better to just add the necessary > conversions to the driver and always use BE. Endian conversions > tend to be very cheap. For a given architecture, only the right version of the microcode is compiled, so the binary only contains one copy of the microcode. The good news is that future versions of the device will not have this issue. I can complain all day about hardware designers not listening to the software guys but then they just might stop talking to me altogether ;-) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V7 8/8] net/bonding: Destroy bonding master when last slave is gone
When bonding enslaves non Ethernet devices it takes pointers to functions
in the module that owns the slaves. In this case it becomes unsafe
to keep the bonding master registered after last slave was unenslaved
because we don't know if the pointers are still valid. Destroying the bond
when slave_cnt is zero
ensures that these functions be used anymore.
Signed-off-by: Moni Shoua
---
drivers/net/bonding/bond_main.c | 37 -
drivers/net/bonding/bond_sysfs.c |9 +
drivers/net/bonding/bonding.h|3 +++
3 files changed, 44 insertions(+), 5 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index c017042..23edf18 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1257,6 +1257,7 @@ static int bond_compute_features(struct
static void bond_setup_by_slave(struct net_device *bond_dev,
struct net_device *slave_dev)
{
+ struct bonding *bond = bond_dev->priv;
bond_dev->neigh_setup = slave_dev->neigh_setup;
bond_dev->type = slave_dev->type;
@@ -1266,6 +1267,7 @@ static void bond_setup_by_slave(struct n
memcpy(bond_dev->broadcast, slave_dev->broadcast,
slave_dev->addr_len);
+ bond->setup_by_slave = 1;
}
/* enslave device to bond device */
@@ -1829,6 +1831,35 @@ int bond_release(struct net_device *bond
}
/*
+* Destroy a bonding device.
+* Must be under rtnl_lock when this function is called.
+*/
+void bond_destroy(struct bonding *bond)
+{
+ bond_deinit(bond->dev);
+ bond_destroy_sysfs_entry(bond);
+ unregister_netdevice(bond->dev);
+}
+
+/*
+* First release a slave and than destroy the bond if no more slaves iare left.
+* Must be under rtnl_lock when this function is called.
+*/
+int bond_release_and_destroy(struct net_device *bond_dev, struct net_device
*slave_dev)
+{
+ struct bonding *bond = bond_dev->priv;
+ int ret;
+
+ ret = bond_release(bond_dev, slave_dev);
+ if ((ret == 0) && (bond->slave_cnt == 0)) {
+ printk(KERN_INFO DRV_NAME ": %s: destroying bond %s.\n",
+ bond_dev->name, bond_dev->name);
+ bond_destroy(bond);
+ }
+ return ret;
+}
+
+/*
* This function releases all slaves.
*/
static int bond_release_all(struct net_device *bond_dev)
@@ -3311,7 +3342,10 @@ static int bond_slave_netdev_event(unsig
switch (event) {
case NETDEV_UNREGISTER:
if (bond_dev) {
- bond_release(bond_dev, slave_dev);
+ if (bond->setup_by_slave)
+ bond_release_and_destroy(bond_dev, slave_dev);
+ else
+ bond_release(bond_dev, slave_dev);
}
break;
case NETDEV_CHANGE:
@@ -4299,6 +4333,7 @@ static int bond_init(struct net_device *
bond->primary_slave = NULL;
bond->dev = bond_dev;
bond->send_grat_arp = 0;
+ bond->setup_by_slave = 0;
INIT_LIST_HEAD(&bond->vlan_list);
/* Initialize the device entry points */
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 583c568..b5d2a13 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -164,9 +164,7 @@ static ssize_t bonding_store_bonds(struc
printk(KERN_INFO DRV_NAME
": %s is being deleted...\n",
bond->dev->name);
- bond_deinit(bond->dev);
- bond_destroy_sysfs_entry(bond);
- unregister_netdevice(bond->dev);
+ bond_destroy(bond);
rtnl_unlock();
goto out;
}
@@ -363,7 +361,10 @@ static ssize_t bonding_store_slaves(stru
printk(KERN_INFO DRV_NAME ": %s: Removing slave %s\n",
bond->dev->name, dev->name);
rtnl_lock();
- res = bond_release(bond->dev, dev);
+ if (bond->setup_by_slave)
+ res = bond_release_and_destroy(bond->dev, dev);
+ else
+ res = bond_release(bond->dev, dev);
rtnl_unlock();
if (res) {
ret = res;
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index e0e06a8..85e579b 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -188,6 +188,7 @@ struct bonding {
s8 kill_timers;
s8 do_set_mac_addr;
s8 send_grat_arp;
+ s8 setup_by_sla
PATCH V6 7/8] net/bonding: Delay sending of gratuitous ARP to avoid failure
Delay sending a gratuitous_arp when LINK_STATE_LINKWATCH_PENDING bit
in dev->state field is on. This improves the chances for the arp packet to
be transmitted.
Signed-off-by: Moni Shoua
Acked-by: Jay Vosburgh <[EMAIL PROTECTED]>
---
drivers/net/bonding/bond_main.c | 24 +---
drivers/net/bonding/bonding.h |1 +
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 3f082dc..c017042 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1103,8 +1103,14 @@ void bond_change_active_slave(struct bon
if (new_active && !bond->do_set_mac_addr)
memcpy(bond->dev->dev_addr, new_active->dev->dev_addr,
new_active->dev->addr_len);
-
- bond_send_gratuitous_arp(bond);
+ if (bond->curr_active_slave &&
+ test_bit(__LINK_STATE_LINKWATCH_PENDING,
+ &bond->curr_active_slave->dev->state)) {
+ dprintk("delaying gratuitous arp on %s\n",
+ bond->curr_active_slave->dev->name);
+ bond->send_grat_arp = 1;
+ } else
+ bond_send_gratuitous_arp(bond);
}
}
@@ -2074,6 +2080,17 @@ void bond_mii_monitor(struct net_device
* program could monitor the link itself if needed.
*/
+ if (bond->send_grat_arp) {
+ if (bond->curr_active_slave &&
test_bit(__LINK_STATE_LINKWATCH_PENDING,
+ &bond->curr_active_slave->dev->state))
+ dprintk("Needs to send gratuitous arp but not yet\n");
+ else {
+ dprintk("sending delayed gratuitous arp on on %s\n",
+ bond->curr_active_slave->dev->name);
+ bond_send_gratuitous_arp(bond);
+ bond->send_grat_arp = 0;
+ }
+ }
read_lock(&bond->curr_slave_lock);
oldcurrent = bond->curr_active_slave;
read_unlock(&bond->curr_slave_lock);
@@ -2475,7 +2492,7 @@ static void bond_send_gratuitous_arp(str
if (bond->master_ip) {
bond_arp_send(slave->dev, ARPOP_REPLY, bond->master_ip,
- bond->master_ip, 0);
+ bond->master_ip, 0);
}
list_for_each_entry(vlan, &bond->vlan_list, vlan_list) {
@@ -4281,6 +4298,7 @@ static int bond_init(struct net_device *
bond->current_arp_slave = NULL;
bond->primary_slave = NULL;
bond->dev = bond_dev;
+ bond->send_grat_arp = 0;
INIT_LIST_HEAD(&bond->vlan_list);
/* Initialize the device entry points */
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index ad9c632..e0e06a8 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -187,6 +187,7 @@ struct bonding {
struct timer_list arp_timer;
s8 kill_timers;
s8 do_set_mac_addr;
+ s8 send_grat_arp;
struct net_device_stats stats;
#ifdef CONFIG_PROC_FS
struct proc_dir_entry *proc_entry;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V7 5/8] net/bonding: Enable IP multicast for bonding IPoIB devices
Allow to enslave devices when the bonding device is not up. Over the discussion
held at the previous post this seemed to be the most clean way to go, where it
is not expected to cause instabilities.
Normally, the bonding driver is UP before any enslavement takes place.
Once a netdevice is UP, the network stack acts to have it join some multicast
groups
(eg the all-hosts 224.0.0.1). Now, since ether_setup() have set the bonding
device
type to be ARPHRD_ETHER and address len to be ETHER_ALEN, the net core code
computes a wrong multicast link address. This is b/c ip_eth_mc_map() is called
where for multicast joins taking place after the enslavement another
ip_xxx_mc_map()
is called (eg ip_ib_mc_map() when the bond type is ARPHRD_INFINIBAND)
Signed-off-by: Moni Shoua
Signed-off-by: Or Gerlitz
Acked-by: Jay Vosburgh <[EMAIL PROTECTED]>
---
drivers/net/bonding/bond_main.c |5 +++--
drivers/net/bonding/bond_sysfs.c |6 ++
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 32dc75e..d7e43ba 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1281,8 +1281,9 @@ int bond_enslave(struct net_device *bond
/* bond must be initialized by bond_open() before enslaving */
if (!(bond_dev->flags & IFF_UP)) {
- dprintk("Error, master_dev is not up\n");
- return -EPERM;
+ printk(KERN_WARNING DRV_NAME
+ " %s: master_dev is not up in bond_enslave\n",
+ bond_dev->name);
}
/* already enslaved */
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 6f49ca7..ca4e429 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -266,11 +266,9 @@ static ssize_t bonding_store_slaves(stru
/* Quick sanity check -- is the bond interface up? */
if (!(bond->dev->flags & IFF_UP)) {
- printk(KERN_ERR DRV_NAME
- ": %s: Unable to update slaves because interface is
down.\n",
+ printk(KERN_WARNING DRV_NAME
+ ": %s: doing slave updates when interface is down.\n",
bond->dev->name);
- ret = -EPERM;
- goto out;
}
/* Note: We can't hold bond->lock here, as bond_create grabs it. */
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V7 6/8] net/bonding: Handlle wrong assumptions that slave is always an Ethernet device
bonding sometimes uses Ethernet constants (such as MTU and address length) which
are not good when it enslaves non Ethernet devices (such as InfiniBand).
Signed-off-by: Moni Shoua
Acked-by: Jay Vosburgh <[EMAIL PROTECTED]>
---
drivers/net/bonding/bond_main.c |3 ++-
drivers/net/bonding/bond_sysfs.c | 10 --
drivers/net/bonding/bonding.h|1 +
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index d7e43ba..3f082dc 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1225,7 +1225,8 @@ static int bond_compute_features(struct
struct slave *slave;
struct net_device *bond_dev = bond->dev;
unsigned long features = bond_dev->features;
- unsigned short max_hard_header_len = ETH_HLEN;
+ unsigned short max_hard_header_len = max((u16)ETH_HLEN,
+ bond_dev->hard_header_len);
int i;
features &= ~(NETIF_F_ALL_CSUM | BOND_VLAN_FEATURES);
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index ca4e429..583c568 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -260,6 +260,7 @@ static ssize_t bonding_store_slaves(stru
char command[IFNAMSIZ + 1] = { 0, };
char *ifname;
int i, res, found, ret = count;
+ u32 original_mtu;
struct slave *slave;
struct net_device *dev = NULL;
struct bonding *bond = to_bond(d);
@@ -325,6 +326,7 @@ static ssize_t bonding_store_slaves(stru
}
/* Set the slave's MTU to match the bond */
+ original_mtu = dev->mtu;
if (dev->mtu != bond->dev->mtu) {
if (dev->change_mtu) {
res = dev->change_mtu(dev,
@@ -339,6 +341,9 @@ static ssize_t bonding_store_slaves(stru
}
rtnl_lock();
res = bond_enslave(bond->dev, dev);
+ bond_for_each_slave(bond, slave, i)
+ if (strnicmp(slave->dev->name, ifname, IFNAMSIZ) == 0)
+ slave->original_mtu = original_mtu;
rtnl_unlock();
if (res) {
ret = res;
@@ -351,6 +356,7 @@ static ssize_t bonding_store_slaves(stru
bond_for_each_slave(bond, slave, i)
if (strnicmp(slave->dev->name, ifname, IFNAMSIZ) == 0) {
dev = slave->dev;
+ original_mtu = slave->original_mtu;
break;
}
if (dev) {
@@ -365,9 +371,9 @@ static ssize_t bonding_store_slaves(stru
}
/* set the slave MTU to the default */
if (dev->change_mtu) {
- dev->change_mtu(dev, 1500);
+ dev->change_mtu(dev, original_mtu);
} else {
- dev->mtu = 1500;
+ dev->mtu = original_mtu;
}
}
else {
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 5011ba9..ad9c632 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -156,6 +156,7 @@ struct slave {
s8 link;/* one of BOND_LINK_ */
s8 state; /* one of BOND_STATE_ */
u32original_flags;
+ u32original_mtu;
u32link_failure_count;
u16speed;
u8 duplex;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V7 4/8] net/bonding: Enable bonding to enslave netdevices not supporting set_mac_address()
This patch allows for enslaving netdevices which do not support
the set_mac_address() function. In that case the bond mac address is the one
of the active slave, where remote peers are notified on the mac address
(neighbour) change by Gratuitous ARP sent by bonding when fail-over occurs
(this is already done by the bonding code).
Signed-off-by: Moni Shoua
Signed-off-by: Or Gerlitz
Acked-by: Jay Vosburgh <[EMAIL PROTECTED]>
---
drivers/net/bonding/bond_main.c | 87 +++-
drivers/net/bonding/bonding.h |1
2 files changed, 60 insertions(+), 28 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 4f61958..32dc75e 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1096,6 +1096,14 @@ void bond_change_active_slave(struct bon
if (new_active) {
bond_set_slave_active_flags(new_active);
}
+
+ /* when bonding does not set the slave MAC address, the bond MAC
+* address is the one of the active slave.
+*/
+ if (new_active && !bond->do_set_mac_addr)
+ memcpy(bond->dev->dev_addr, new_active->dev->dev_addr,
+ new_active->dev->addr_len);
+
bond_send_gratuitous_arp(bond);
}
}
@@ -1347,13 +1355,22 @@ int bond_enslave(struct net_device *bond
}
if (slave_dev->set_mac_address == NULL) {
- printk(KERN_ERR DRV_NAME
- ": %s: Error: The slave device you specified does "
- "not support setting the MAC address. "
- "Your kernel likely does not support slave "
- "devices.\n", bond_dev->name);
- res = -EOPNOTSUPP;
- goto err_undo_flags;
+ if (bond->slave_cnt == 0) {
+ printk(KERN_WARNING DRV_NAME
+ ": %s: Warning: The first slave device you "
+ "specified does not support setting the MAC "
+ "address. This bond MAC address would be that "
+ "of the active slave.\n", bond_dev->name);
+ bond->do_set_mac_addr = 0;
+ } else if (bond->do_set_mac_addr) {
+ printk(KERN_ERR DRV_NAME
+ ": %s: Error: The slave device you specified "
+ "does not support setting the MAC addres,."
+ "but this bond uses this practice. \n"
+ , bond_dev->name);
+ res = -EOPNOTSUPP;
+ goto err_undo_flags;
+ }
}
new_slave = kzalloc(sizeof(struct slave), GFP_KERNEL);
@@ -1374,16 +1391,18 @@ int bond_enslave(struct net_device *bond
*/
memcpy(new_slave->perm_hwaddr, slave_dev->dev_addr, ETH_ALEN);
- /*
-* Set slave to master's mac address. The application already
-* set the master's mac address to that of the first slave
-*/
- memcpy(addr.sa_data, bond_dev->dev_addr, bond_dev->addr_len);
- addr.sa_family = slave_dev->type;
- res = dev_set_mac_address(slave_dev, &addr);
- if (res) {
- dprintk("Error %d calling set_mac_address\n", res);
- goto err_free;
+ if (bond->do_set_mac_addr) {
+ /*
+* Set slave to master's mac address. The application already
+* set the master's mac address to that of the first slave
+*/
+ memcpy(addr.sa_data, bond_dev->dev_addr, bond_dev->addr_len);
+ addr.sa_family = slave_dev->type;
+ res = dev_set_mac_address(slave_dev, &addr);
+ if (res) {
+ dprintk("Error %d calling set_mac_address\n", res);
+ goto err_free;
+ }
}
res = netdev_set_master(slave_dev, bond_dev);
@@ -1608,9 +1627,11 @@ err_close:
dev_close(slave_dev);
err_restore_mac:
- memcpy(addr.sa_data, new_slave->perm_hwaddr, ETH_ALEN);
- addr.sa_family = slave_dev->type;
- dev_set_mac_address(slave_dev, &addr);
+ if (bond->do_set_mac_addr) {
+ memcpy(addr.sa_data, new_slave->perm_hwaddr, ETH_ALEN);
+ addr.sa_family = slave_dev->type;
+ dev_set_mac_address(slave_dev, &addr);
+ }
err_free:
kfree(new_slave);
@@ -1783,10 +1804,12 @@ int bond_release(struct net_device *bond
/* close slave before restoring its mac address */
dev_close(slave_dev);
- /* restore original ("permanent") mac address */
- memcpy(addr.sa_data, slave->perm_hwaddr, ETH_ALEN);
- addr.sa_family = slave_dev->type;
- dev_set_mac_addre
[PATCH V7 2/8] IB/ipoib: Verify address handle validity on send
When the bonding device senses a carrier loss of its active slave it replaces
that slave with a new one. In between the times when the carrier of an IPoIB
device goes down and ipoib_neigh is destroyed, it is possible that the
bonding driver will send a packet on a new slave that uses an old ipoib_neigh.
This patch detects and prevents this from happenning.
Signed-off-by: Moni Shoua
Signed-off-by: Or Gerlitz
Acked-by: Roland Dreier <[EMAIL PROTECTED]>
---
drivers/infiniband/ulp/ipoib/ipoib_main.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index cae026c..362610d 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -692,9 +692,10 @@ static int ipoib_start_xmit(struct sk_bu
goto out;
}
} else if (neigh->ah) {
- if (unlikely(memcmp(&neigh->dgid.raw,
+ if (unlikely((memcmp(&neigh->dgid.raw,
skb->dst->neighbour->ha + 4,
- sizeof(union ib_gid {
+ sizeof(union ib_gid))) ||
+(neigh->dev != dev))) {
spin_lock(&priv->lock);
/*
* It's safe to call ipoib_put_ah() inside
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V7 3/8] net/bonding: Enable bonding to enslave non ARPHRD_ETHER
This patch changes some of the bond netdevice attributes and functions
to be that of the active slave for the case of the enslaved device not being
of ARPHRD_ETHER type. Basically it overrides those setting done by
ether_setup(),
which are netdevice **type** dependent and hence might be not appropriate for
devices of other types. It also enforces mutual exclusion on bonding slaves
from dissimilar ether types, as was concluded over the v1 discussion.
IPoIB (see Documentation/infiniband/ipoib.txt) MAC address is made of a 3 bytes
IB QP (Queue Pair) number and 16 bytes IB port GID (Global ID) of the port this
IPoIB device is bounded to. The QP is a resource created by the IB HW and the
GID is an identifier burned into the HCA (i have omitted here some details which
are not important for the bonding RFC).
Signed-off-by: Moni Shoua
Signed-off-by: Or Gerlitz
---
drivers/net/bonding/bond_main.c | 34 ++
1 files changed, 34 insertions(+)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 64bfec3..4f61958 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1238,6 +1238,21 @@ static int bond_compute_features(struct
return 0;
}
+
+static void bond_setup_by_slave(struct net_device *bond_dev,
+ struct net_device *slave_dev)
+{
+ bond_dev->neigh_setup = slave_dev->neigh_setup;
+
+ bond_dev->type = slave_dev->type;
+ bond_dev->hard_header_len = slave_dev->hard_header_len;
+ bond_dev->addr_len = slave_dev->addr_len;
+ bond_dev->header_ops= slave_dev->header_ops;
+
+ memcpy(bond_dev->broadcast, slave_dev->broadcast,
+ slave_dev->addr_len);
+}
+
/* enslave device to bond device */
int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
{
@@ -1312,6 +1327,25 @@ int bond_enslave(struct net_device *bond
goto err_undo_flags;
}
+ /* set bonding device ether type by slave - bonding netdevices are
+* created with ether_setup, so when the slave type is not ARPHRD_ETHER
+* there is a need to override some of the type dependent attribs/funcs.
+*
+* bond ether type mutual exclusion - don't allow slaves of dissimilar
+* ether type (eg ARPHRD_ETHER and ARPHRD_INFINIBAND) share the same
bond
+*/
+ if (bond->slave_cnt == 0) {
+ if (slave_dev->type != ARPHRD_ETHER)
+ bond_setup_by_slave(bond_dev, slave_dev);
+ } else if (bond_dev->type != slave_dev->type) {
+ printk(KERN_ERR DRV_NAME ": %s ether type (%d) is different "
+ "from other slaves (%d), can not enslave it.\n",
+ slave_dev->name,
+ slave_dev->type, bond_dev->type);
+ res = -EINVAL;
+ goto err_undo_flags;
+ }
+
if (slave_dev->set_mac_address == NULL) {
printk(KERN_ERR DRV_NAME
": %s: Error: The slave device you specified does "
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ofa-general] [PATCH V7 0/8] net/bonding: ADD IPoIB support for the bonding driver
Moni Shoua wrote: > This is the 7th version of this patch series. See link to V6 below. > I forgot to mention that the patches are relative to jgarzik/netdev-2.6.git#master. I couldn't compile the 2.6.24 or the upstream branches so I used master branch to test the fixes. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BNX2X] round three
> This is not a driver issue. > Unfortunately, the firmware code is different for LE and BE machines. > We had issues with the BE firmware that appear to be resolved. > Hopefully, the next version will have both. If the firmware is big it might be better to just add the necessary conversions to the driver and always use BE. Endian conversions tend to be very cheap. Also we probably should have BE/LE Kconfig symbol for this to handle such cases more elegantly in the future. -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V7 1/8] IB/ipoib: Bound the net device to the ipoib_neigh structue
IPoIB uses a two layer neighboring scheme, such that for each struct neighbour
whose device is an ipoib one, there is a struct ipoib_neigh buddy which is
created on demand at the tx flow by an ipoib_neigh_alloc(skb->dst->neighbour)
call.
When using the bonding driver, neighbours are created by the net stack on behalf
of the bonding (master) device. On the tx flow the bonding code gets an skb such
that skb->dev points to the master device, it changes this skb to point on the
slave device and calls the slave hard_start_xmit function.
Under this scheme, ipoib_neigh_destructor assumption that for each struct
neighbour it gets, n->dev is an ipoib device and hence netdev_priv(n->dev)
can be casted to struct ipoib_dev_priv is buggy.
To fix it, this patch adds a dev field to struct ipoib_neigh which is used
instead of the struct neighbour dev one, when n->dev->flags has the
IFF_MASTER bit set.
Signed-off-by: Moni Shoua
Signed-off-by: Or Gerlitz
Acked-by: Roland Dreier <[EMAIL PROTECTED]>
---
drivers/infiniband/ulp/ipoib/ipoib.h |4 +++-
drivers/infiniband/ulp/ipoib/ipoib_main.c | 24 +++-
drivers/infiniband/ulp/ipoib/ipoib_multicast.c |3 ++-
3 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib.h
b/drivers/infiniband/ulp/ipoib/ipoib.h
index 6545fa7..1b3327a 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib.h
+++ b/drivers/infiniband/ulp/ipoib/ipoib.h
@@ -349,6 +349,7 @@ #endif
struct sk_buff_head queue;
struct neighbour *neighbour;
+ struct net_device *dev;
struct list_headlist;
};
@@ -365,7 +366,8 @@ static inline struct ipoib_neigh **to_ip
INFINIBAND_ALEN, sizeof(void *));
}
-struct ipoib_neigh *ipoib_neigh_alloc(struct neighbour *neigh);
+struct ipoib_neigh *ipoib_neigh_alloc(struct neighbour *neigh,
+ struct net_device *dev);
void ipoib_neigh_free(struct net_device *dev, struct ipoib_neigh *neigh);
extern struct workqueue_struct *ipoib_workqueue;
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index e072f3c..cae026c 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -517,7 +517,7 @@ static void neigh_add_path(struct sk_buf
struct ipoib_path *path;
struct ipoib_neigh *neigh;
- neigh = ipoib_neigh_alloc(skb->dst->neighbour);
+ neigh = ipoib_neigh_alloc(skb->dst->neighbour, skb->dev);
if (!neigh) {
++dev->stats.tx_dropped;
dev_kfree_skb_any(skb);
@@ -817,6 +817,13 @@ static void ipoib_neigh_cleanup(struct n
unsigned long flags;
struct ipoib_ah *ah = NULL;
+ neigh = *to_ipoib_neigh(n);
+ if (neigh) {
+ priv = netdev_priv(neigh->dev);
+ ipoib_dbg(priv, "neigh_destructor for bonding device: %s\n",
+ n->dev->name);
+ } else
+ return;
ipoib_dbg(priv,
"neigh_cleanup for %06x " IPOIB_GID_FMT "\n",
IPOIB_QPN(n->ha),
@@ -824,13 +831,10 @@ static void ipoib_neigh_cleanup(struct n
spin_lock_irqsave(&priv->lock, flags);
- neigh = *to_ipoib_neigh(n);
- if (neigh) {
- if (neigh->ah)
- ah = neigh->ah;
- list_del(&neigh->list);
- ipoib_neigh_free(n->dev, neigh);
- }
+ if (neigh->ah)
+ ah = neigh->ah;
+ list_del(&neigh->list);
+ ipoib_neigh_free(n->dev, neigh);
spin_unlock_irqrestore(&priv->lock, flags);
@@ -838,7 +842,8 @@ static void ipoib_neigh_cleanup(struct n
ipoib_put_ah(ah);
}
-struct ipoib_neigh *ipoib_neigh_alloc(struct neighbour *neighbour)
+struct ipoib_neigh *ipoib_neigh_alloc(struct neighbour *neighbour,
+ struct net_device *dev)
{
struct ipoib_neigh *neigh;
@@ -847,6 +852,7 @@ struct ipoib_neigh *ipoib_neigh_alloc(st
return NULL;
neigh->neighbour = neighbour;
+ neigh->dev = dev;
*to_ipoib_neigh(neighbour) = neigh;
skb_queue_head_init(&neigh->queue);
ipoib_cm_set(neigh, NULL);
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
index 827820e..9bcfc7a 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -705,7 +705,8 @@ out:
if (skb->dst&&
skb->dst->neighbour &&
!*to_ipoib_neigh(skb->dst->neighbour)) {
- struct ipoib_neigh *neigh =
ipoib_neigh_alloc(skb->dst->neighbour);
+ struct ipoib_neigh *neigh =
ipoib_neigh_alloc(skb->dst->neighbour,
+
[PATCH V7 0/8] net/bonding: ADD IPoIB support for the bonding driver
This is the 7th version of this patch series. See link to V6 below. Changes from the previous version - * Some patches required modifications to remove offsets so they can be applied with git-apply * Patch #3 was first modified by Jay and later by me to make it work with header_ops * patch #8 was changed to fix the problem that caused 'ifconfig down' to stuck (dev_close was called twice) Jay, I removed the Acked-by lines from patches 3 & 8. Can you please add them back after you approve? thanks MoniS Link to V6: http://lists.openfabrics.org/pipermail/general/2007-September/041139.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] isdn compile fix (resend)
On Mon, Oct 15, 2007 at 06:44:56PM +0400, Denis V. Lunev wrote: Compilation fix. The problem appears after 7c076d1de869256848dacb8de0050a3a390f95df by Karsten Keil <[EMAIL PROTECTED]> Acked-by: Karsten Keil <[EMAIL PROTECTED]> Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]> --- ./drivers/isdn/i4l/isdn_net.c.isdn2 2007-10-15 13:55:24.0 +0400 +++ ./drivers/isdn/i4l/isdn_net.c 2007-10-15 18:19:11.0 +0400 @@ -2713,7 +2713,7 @@ isdn_net_setcfg(isdn_net_ioctl_cfg * cfg case ISDN_NET_ENCAP_X25IFACE: #ifndef CONFIG_ISDN_X25 printk(KERN_WARNING "%s: isdn-x25 support not configured\n", - p->local->name); + p->dev->name); return -EINVAL; #else p->dev->type = ARPHRD_X25; /* change ARP type */ -- Karsten Keil SuSE Labs ISDN and VOIP development SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] e1000e: fix debugging printout code
On Fri, 2007-10-05 at 13:53 -0400, Jeff Garzik wrote:
> > diff --git a/drivers/net/e1000e/hw.h b/drivers/net/e1000e/hw.h
> > index 848217a..aa82f1a 100644
> > --- a/drivers/net/e1000e/hw.h
> > +++ b/drivers/net/e1000e/hw.h
> > @@ -852,7 +852,7 @@ struct e1000_hw {
> >
> > #ifdef DEBUG
> > #define hw_dbg(hw, format, arg...) \
> > - printk(KERN_DEBUG, "%s: " format, e1000_get_hw_dev_name(hw), ##arg);
> > + printk(KERN_DEBUG, "%s: " format, e1000e_get_hw_dev_name(hw), ##arg);
>
> I will apply this, but, I strongly encourage deletion of this in favor
> of the existing dev_dbg()
Instead the fix should be for the 2 existing bugs on macro:
o Comma after KERN_DEBUG
o Semicolon in macro
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [TCP]: Make snd_cwnd_cnt 32-bit
Very little point of having 32-bit snd_cnwd if this is not
32-bit as well, as a number of snd_cwnd incrementation formulas
assume that snd_cwnd_cnt can be at least as large as snd_cwnd.
Whether 32-bit is useful was discussed when e0ef57cc56c3c96
was made:
http://marc.info/?l=linux-netdev&m=117218144409825&w=2
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/linux/tcp.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index c5b94c1..997b349 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -315,7 +315,7 @@ struct tcp_sock {
*/
u32 snd_ssthresh; /* Slow start size threshold*/
u32 snd_cwnd; /* Sending congestion window*/
- u16 snd_cwnd_cnt; /* Linear increase counter */
+ u32 snd_cwnd_cnt; /* Linear increase counter */
u32 snd_cwnd_clamp; /* Do not allow snd_cwnd to grow above this */
u32 snd_cwnd_used;
u32 snd_cwnd_stamp;
--
1.5.0.6
k i.
Re: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
On Mon, 15 Oct 2007 21:59:49 +0900 Komuro <[EMAIL PROTECTED]> wrote: > Dear shemminger > > >In which case it is zero because that is the default value. > > The default value of snd_ssthresh is 0x7fff, isn't it? > > [linux/net/ipv4/tcp_ipv4.c] > static int tcp_v4_init_sock(struct sock *sk) > ... > tp->snd_ssthresh = 0x7fff; /* Infinity */ > ... > > Best Regards > Komuro > > Yes that value means that TCP stays in slow start until the first loss. This makes TCP behave as expected in the RFC's. -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tcp bw in 2.6
On Mon, 15 Oct 2007 14:40:25 +0200 Daniel Schaffrath <[EMAIL PROTECTED]> wrote: > On 2007/10/02 , at 18:47, Stephen Hemminger wrote: > > > On Tue, 2 Oct 2007 09:25:34 -0700 > > [EMAIL PROTECTED] (Larry McVoy) wrote: > > > >>> If the server side is the source of the data, i.e, it's transfer > >>> is a > >>> write loop, then I get the bad behaviour. > >>> ... > >>> So is this a bug or intentional? > >> > >> For whatever it is worth, I believed that we used to get better > >> performance > >> from the same hardware. My guess is that it changed somewhere > >> between > >> 2.6.15-1-k7 and 2.6.18-5-k7. > > > > For the period from 2.6.15 to 2.6.18, the kernel by default enabled > > TCP > > Appropriate Byte Counting. This caused bad performance on > > applications that > > did small writes. > Stephen, maybe you can provide me with some specifics here? > > Thanks a lot!! > Daniel > Read the RFC3465 for explanation of TCP ABC. What happens is that applications that do multiple small writes will end up using up their window. Typically these applications are not streaming enough data to grow the congestion window so they get held after 4 writes until an ACK comes back. The fix for the application (which also helps on all OS's and TCP versions as well) is to use a call like writev() or sendmsg() to aggregate the small header blocks together into a single send. -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Oops in 2.6.21-rc4, 2.6.23
Hello, after recent upgrade to kernel 2.6.23 (from 2.6.20) I have started seeing kernel oops-es in networking code. The problem is 100% reproducible in my environment. I've seen two slightly different backtraces but both seem to be caused by the same commit. Please put me on Cc: on replies. I've performed the git bisect and tracked down the problem to the commit: 53cdcc04c1e85d4e423b2822b66149b6f2e52c2c [TCP]: Fix tcp_mem[] initialization Once I reverse this commit in 2.6.23 the problem goes away (this is true also for the kernel version generated by git bisect, 2.6.21-rc4). Description of my machine: Athlon XP1700, VIA KT-333 chipset, 512MB RAM, VIA rhine on-board NIC. The problem appears when approximately 70% of RAM is in use and I start a large file transfer (via FTP) from another machine on the LAN. Sample output from free command: total used free shared buffers cached Mem: 516508 510600 590801004 154084 -/+ buffers/cache: 355512 160996 Swap: 899600 25240 874360 Backtrace #1: page allocation failure. order:1, mode:0x20 [] __alloc_pages+0x2e1/0x300 [] cache_alloc_refill+0x29e/0x4b0 [] __kmalloc+0x6e/0x80 [] __alloc_skb+0x53/0x110 [] tcp_collapse+0x1ac/0x370 [] tcp_prune_queue+0xfd/0x2c0 [] tcp_data_queue+0x7cd/0xbb0 [] skb_checksum+0x4d/0x2a0 [] tcp_rcv_established+0x36e/0x6a0 [] tcp_v4_do_rcv+0xb4/0x2a0 [] __alloc_pages+0xd9/0x300 [] tcp_v4_rcv+0x6a9/0x6c0 [] ip_local_deliver+0x91/0x110 [] ip_rcv+0x230/0x3c0 [] __alloc_skb+0x53/0x110 [] netif_receive_skb+0x152/0x1e0 [] process_backlog+0x6f/0xe0 [] net_rx_action+0x5c/0xf0 [] __do_softirq+0x42/0x90 [] do_softirq+0x27/0x30 [] do_IRQ+0x3d/0x70 [] sys_gettimeofday+0x28/0x80 [] common_interrupt+0x23/0x28 === Mem-info: DMA per-cpu: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Normal per-cpu: CPU 0: Hot: hi: 186, btch: 31 usd: 138 Cold: hi: 62, btch: 15 usd: 58 Active:92274 inactive:30728 dirty:12731 writeback:792 unstable:0 free:763 slab:4365 mapped:9796 pagetables:624 bounce:0 DMA free:2004kB min:88kB low:108kB high:132kB active:7956kB inactive:3640kB present:16256kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 492 Normal free:1048kB min:2792kB low:3488kB high:4188kB active:361140kB inactive:119272kB present:503876kB pages_scanned:64 all_unreclaimable? no lowmem_reserve[]: 0 0 DMA: 1*4kB 0*8kB 1*16kB 0*32kB 1*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 2004kB Normal: 0*4kB 1*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 1048kB Swap cache: add 17156, delete 14173, find 11/14, race 0+0 Free swap = 831072kB Total swap = 899600kB Free swap: 831072kB 131056 pages of RAM 0 pages of HIGHMEM 1729 reserved pages 75636 pages shared 2983 pages swap cached 12731 pages dirty 792 pages writeback 9796 pages mapped 4365 pages slab 624 pages pagetables Backtrace #2: klogd: page allocation failure. order:1, mode:0x4020 [] __alloc_pages+0x2e2/0x300 [] __slab_alloc+0x177/0x400 [] rhine_interrupt+0x637/0xae0 [via_rhine] [] __kmalloc_track_caller+0x7f/0xb0 [] rhine_interrupt+0x637/0xae0 [via_rhine] [] __alloc_skb+0x57/0x120 [] rhine_interrupt+0x637/0xae0 [via_rhine] [] schedule+0x13b/0x2e0 [] handle_IRQ_event+0x25/0x50 [] handle_level_irq+0x42/0xa0 [] do_IRQ+0x42/0x80 [] proc_reg_read+0x4b/0x70 [] common_interrupt+0x23/0x28 [] sys_time+0x0/0x30 [] syscall_call+0x7/0xb === My kernel configuration: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc4 # Sun Oct 14 15:11:07 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_
