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 writ
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 handl
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 instan
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 "unsu
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 w
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 instan
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 1
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_sycnhroni
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:
[PATC
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
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 u
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
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 kin
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 netde
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 S
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
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 wil
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 star
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 th
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 netde
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
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 tha
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
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-of
> > 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 li
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
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 th
> 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.
C
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/ne
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/ethto
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]>
> ---
> d
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.
>
>
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
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/driv
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 wit
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:c0026
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-h830
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
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-
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 li
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.
>
> Signe
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
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 t
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 <[E
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
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
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 actua
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
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
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 activ
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.
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
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 Stef
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 a
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
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]
M
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.
Sign
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]
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 unsubscri
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 [EM
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]
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: prev
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
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: Va
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
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
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
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.
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
driver
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
1
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 PRO
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] "\
* 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(+)
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
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-
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*\
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
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
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 s
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 {
>>>
>>> #i
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.
>
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
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 b
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
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 +--
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
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/bon
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 a
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_
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 appro
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 fro
> 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 th
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 th
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 wo
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/i
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
> > #defi
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=1172
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)
>
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
> >
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
1 - 100 of 168 matches
Mail list logo
