On Thu, Aug 03, 2006 at 01:32:10PM -0700, Chris Leech ([EMAIL PROTECTED]) wrote:
> >Maximum e1000 frame is 16128 bytes, which is enough before being rounded
> >to 16k to have a space for shared info.
> >My patch just tricks refilling logic to request to allocate slightly less
> >than was setup when
On Fri, Aug 04, 2006 at 03:59:37PM +1000, Herbert Xu ([EMAIL PROTECTED]) wrote:
> Chris Leech <[EMAIL PROTECTED]> wrote:
> >
> > We could try and only use page allocations for older e1000 devices,
> > putting headers and payload into skb->frags and copying the headers
> > out into the skb->data ar
On Thu, Aug 03, 2006 at 10:55:01PM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Fri, 04 Aug 2006 15:52:40 +1000
>
> > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > >
> > > But it does not support splitting them into page sized chunks, so it
> >
-stable review patch. If anyone has any objections, please let us know.
--
From: Herbert Xu <[EMAIL PROTECTED]>
[NET]: Update frag_list in pskb_trim
When pskb_trim has to defer to ___pksb_trim to trim the frag_list part of
the packet, the frag_list is not updated to reflect the
Chris Leech <[EMAIL PROTECTED]> wrote:
>
> We could try and only use page allocations for older e1000 devices,
> putting headers and payload into skb->frags and copying the headers
> out into the skb->data area as needed for processing. That would do
> away with large allocations, but in Jesse's
-stable review patch. If anyone has any objections, please let us know.
--
From: Auke Kok <[EMAIL PROTECTED]>
The Intel(R) PRO/1000 82572EI card is fully supported by 7.0.33-k2 and
onward. Add the device ID so this card works with 2.6.17.y onward. This
device ID was accidentally
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> But it does not support splitting them into page sized chunks, so it
> requires the whole jumbo frame allocation in one contiguous chunk, 9k
> will be transferred into 16k allocation (order 3), since SLAB uses
> power-of-2 allocation.
Actually order
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Fri, 04 Aug 2006 15:52:40 +1000
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> > But it does not support splitting them into page sized chunks, so it
> > requires the whole jumbo frame allocation in one contiguous chunk, 9k
> > will be transferred i
Jamal wrote:
> tg3_start_xmit():
>
> prepare skb
> grab ring tx lock irq safe
> put skb on ring
> if (full-ring)
> stop
> release ring tx lock and restore flags blah
The whole point of doing things the way it is done in tg3
Theodore Tso wrote:
> Parden me for asking a dumb question, but what's being accomplished by
> resetting the chip if the system has crashed? Why not reset the chip
> when the system reboots and it sees the PCI bus reset? I guess I'm
> missing the purpose of the ASF heartbeat; why does the networ
On Thu, Aug 03, 2006 at 04:28:19PM -0700, Michael Chan wrote:
> True. But they also have ASF enabled which requires tg3_timer() to send
> the heartbeat periodically. If the heartbeat is late, ASF may reset the
> chip believing that the system has crashed.
Parden me for asking a dumb question, bu
-- Forwarded message --
Date: Thu, 3 Aug 2006 18:35:45 -0700
From: "Siddha, Suresh B" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], linux-kernel@vger.kernel.org
Subject: [Patch] fix potential stack overflow in net/core/utils.c
On High end systems (1024 or so cpus
On Mon, 31 Jul 2006 10:35:26 -0700
Auke Kok <[EMAIL PROTECTED]> wrote:
> We've recently seen a number of user bug reports against e1000 that the
> in-kernel irqbalance code is detrimental to network latency. The algorithm
> keeps swapping irq's for NICs from cpu to cpu causing extremely high net
On Thu, 2006-08-03 at 15:53 -0400, John W. Linville wrote:
> On Thu, Aug 03, 2006 at 11:54:41PM +1000, Herbert Xu wrote:
> Arjan, did you convince yourself whether or not this patch actually
> resolves the problem at hand? Applying it makes sense to me either
> way, but it would be nice to believe
On Fri, 04 Aug 2006 00:33:32 +0300
Ilpo Järvinen <[EMAIL PROTECTED]> wrote:
> Overflow can occur very easily with 32 bits, e.g., with 1 second
> us_idle is approx. 2^20, which leaves only 11-Wlog bits for queue
> length. Since the EWMA exponent is typically around 9, queue
> lengths larger than 2
On Fri, 04 Aug 2006 00:32:36 +0300
Ilpo Järvinen <[EMAIL PROTECTED]> wrote:
> Whenever a transfer is application limited, we are allowed at least
> initial window worth of data per window unless cwnd is previously
> less than that.
>
> Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
> ---
> ne
On Fri, 2006-04-08 at 11:18 +1000, Herbert Xu wrote:
> On Thu, Aug 03, 2006 at 09:16:04PM -0400, jamal wrote:
> >
> > and in tg3_tx():
> >
> > if likely(stopped) {
> >// essentially no lock needed here
> >prune tx ring
> >if prunned > threshold
> >w
On Thu, Aug 03, 2006 at 09:16:04PM -0400, jamal wrote:
>
> and in tg3_tx():
>
> if likely(stopped) {
>// essentially no lock needed here
>prune tx ring
>if prunned > threshold
>wake
> } else if not stopped {
> // need a lock here ...
On Thu, 2006-03-08 at 17:09 -0700, Michael Chan wrote:
> On Thu, 2006-08-03 at 18:08 -0400, jamal wrote:
>
> >
> > Yes in your case you need to hold the lock but not in the e1000 case.
> > I dont understand though why you need to check for wake in the tx path.
> >
>
> tg3_start_xmit()
>
>
On Thu, Aug 03, 2006 at 05:09:57PM -0700, Michael Chan wrote:
>
> tg3_start_xmit()
>
> if (tx_ring_empty)
> <- tg3_tx()
> netif_stop_queue()
Good point. I missed that. However, this only goes to show that
even the current code (e1000 that is,
On Thu, Aug 03, 2006 at 03:53:13PM -0400, John W. Linville wrote:
>
> Does anyone have any objection to Herbert's patch? It seems
> appropriate to me.
I have no objections!
:)
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondo
On Thu, Aug 03, 2006 at 08:22:58AM -0700, Arjan van de Ven wrote:
>
> however I'm not quite yet convinced that this patch is going to solve
> this particular deadlock.
> (I agree with the principle of it and I think it's really needed,
> I just don't yet see how it's going to solve this specific de
David Miller <[EMAIL PROTECTED]> wrote:
>> The same struct vlan_group is assigned to all slave devices and so the only
>> vlan subinterfaces that exist in this case are the bond.
>> subinterfaces, and the vlan path for both slaves will assign the
>> bond. interface to skb->dev, thereby erasing
Lennert Buytenhek wrote:
> On Thu, Aug 03, 2006 at 07:14:59PM +1000, Philip Craig wrote:
>
>>> So now you _need_ bridging in the middle to send ethernet traffic over
>>> a GRE tunnel? Ugh.
>> Agreed that would not be nice. What is the usage scenario for this?
>> At least one end of the tunnel wi
Or Gerlitz <[EMAIL PROTECTED]> wrote:
>First, i'd like to verify what is the parameter setting to have the
>bonding driver use netif_carrier_ok(slave_device) as the means for
>link detection. Is setting use_carrier = 1 enough or one needs to set
>miimon to non-zero as well??? (where the value of m
Theodore Tso wrote:
Removing the timer-based "ping" might be a good thing to do from the
point of view of reducing power utilization of laptops (but hey, I
don't have a tg3 in my laptop, so I won't worry about it a whole lot :-),
but I agree that in general the RT patches need to be able to
cal
From: Theodore Tso <[EMAIL PROTECTED]>
Date: Thu, 3 Aug 2006 20:07:07 -0400
> Removing the timer-based "ping" might be a good thing to do from the
> point of view of reducing power utilization of laptops (but hey, I
> don't have a tg3 in my laptop, so I won't worry about it a whole lot :-),
You
On Thu, 2006-08-03 at 17:01 -0700, David Miller wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Fri, 4 Aug 2006 09:59:27 +1000
>
> > Watchdogs usually require one heartbeat every 30 seconds or so. Does
> > the ASF heartbeat need to be that frequent?
>
> The ASF heartbeat needs to be sent e
On Thu, Aug 03, 2006 at 04:43:11PM -0700, David Miller wrote:
> From: "Michael Chan" <[EMAIL PROTECTED]>
> Date: Thu, 03 Aug 2006 16:28:19 -0700
>
> > > eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[0]
> > > TSOcap[0]
> >
> > We'll see if we can do away with the timer-based h
On Thu, 2006-08-03 at 18:08 -0400, jamal wrote:
>
> Yes in your case you need to hold the lock but not in the e1000 case.
> I dont understand though why you need to check for wake in the tx path.
>
tg3_start_xmit()
if (tx_ring_empty)
<- tg3_tx()
On Thu, 2006-08-03 at 16:56 -0700, David Miller wrote:
> From: Theodore Tso <[EMAIL PROTECTED]>
> Date: Thu, 3 Aug 2006 19:53:26 -0400
>
> > Any suggestions on how I could figure out what was really going on and
> > what would be a better fix would be greatly appreciated.
>
> As Michael explained
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Fri, 4 Aug 2006 09:59:27 +1000
> Watchdogs usually require one heartbeat every 30 seconds or so. Does
> the ASF heartbeat need to be that frequent?
The ASF heartbeat needs to be sent every 2 seconds.
-
To unsubscribe from this list: send the line "unsub
From: [EMAIL PROTECTED]
Date: Thu, 03 Aug 2006 16:09:28 -0400
> This is the NetLabel patchset backed against DaveM's net-2.6.19
> tree. The major changes from the last version have been the
> conversion to the new LSM hooks that were introduced with the
> MLSXFRM patchset and the shift to using N
On Thu, Aug 03, 2006 at 04:56:54PM -0700, David Miller wrote:
>
> As Michael explained, it's the ASF heartbeat sent by tg3_timer() that
> must be delivered to the chip within certain timing constraints.
>
> If you had any watchdog devices on this machine, they would likely
> trigger too and reset
From: Theodore Tso <[EMAIL PROTECTED]>
Date: Thu, 3 Aug 2006 19:53:26 -0400
> Any suggestions on how I could figure out what was really going on and
> what would be a better fix would be greatly appreciated.
As Michael explained, it's the ASF heartbeat sent by tg3_timer() that
must be delivered t
On Thu, Aug 03, 2006 at 02:48:45PM -0700, David Miller wrote:
> > eth0: Tigon3 [partno(BCM95704s) rev 2100 PHY(serdes)] (PCIX:100MHz:64-bit)
> > 10/100/1000BaseT Ethernet 00:14:5e:86:44:24
>
> The 5704 chip will set TG3_FLAG_TAGGED_STATUS, and therefore
> doesn't need the periodic poking done by
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Thu, 03 Aug 2006 16:28:19 -0700
> > eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[0]
> > TSOcap[0]
>
> We'll see if we can do away with the timer-based heartbeat. That's
> probably the best solution.
The tg3 driver is not the o
From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Date: Thu, 03 Aug 2006 13:38:51 -0300
> Dave, please apply.
>
> Acked-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Applied, thanks everyone.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMA
From: jamal <[EMAIL PROTECTED]>
Date: Thu, 03 Aug 2006 09:20:10 -0400
> Old patch - didnt see it reflected in this mornings sync with linus tree
> and dont wanna loose it (git is great at reminding me); if queued
> already, just ignore.
Applied, thanks Jamal.
-
To unsubscribe from this list: sen
From: Wei Yongjun <[EMAIL PROTECTED]>
Date: Thu, 03 Aug 2006 11:46:58 -0400
> I modified my patch by add a flag to sacked when retransmit, and it
> work well.
This is the most timing critical code path of the TCP stack output
packet processing, and you're adding a read-modify-write operation
just
On Thu, 2006-08-03 at 14:48 -0700, David Miller wrote:
> From: Theodore Tso <[EMAIL PROTECTED]>
> Date: Thu, 3 Aug 2006 16:17:41 -0400
>
> > eth0: Tigon3 [partno(BCM95704s) rev 2100 PHY(serdes)] (PCIX:100MHz:64-bit)
> > 10/100/1000BaseT Ethernet 00:14:5e:86:44:24
>
> The 5704 chip will set TG3_F
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Thu, 3 Aug 2006 11:19:59 +1000
> (To recap our sha256 IPsec implementation truncates the output to 96
> bits while the last IETF draft on sha256 and the general HMAC RFC
> requires 128 bits)
>
> Yes I agree with your assessment.
>
> Changing it is nasty
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 2 Aug 2006 16:53:23 -0700
> Fix code that passes back netlink status messages about
> bridge changes. Submitted by [EMAIL PROTECTED]
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Applied, thanks Stephen.
-
To unsubscribe from this
On Thu, 2006-03-08 at 11:05 -0700, Michael Chan wrote:
> On Thu, 2006-08-03 at 09:36 -0700, Brandeburg, Jesse wrote:
>
> > I followed the example of tg3 when attempting to optimize this code. For
> > the normal case we remove a lock acquisition. Jamals case is not normal.
> > :-)
> >
> > we s
Jesse,
On Thu, 2006-03-08 at 09:36 -0700, Brandeburg, Jesse wrote:
> On Fri, 4 Aug 2006, Herbert Xu wrote:
> > jamal <[EMAIL PROTECTED]> wrote:
> > >
> > > There is no need for tx_locking if you are already netif stopped
> > > (transmit path will never be entered).
> > > With this change under hi
On Thu, Aug 03, 2006 at 09:21:17AM -0700, Stephen Hemminger wrote:
> The datagram interface of LLC is broken in a couple of ways.
> These were discovered when trying to use it to build an out-of-kernel
> version of STP.
>
> First it didn't pass the source address of the received packet
> in recvfr
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/myri10ge/myri10ge.c | 24 -
drivers/net/phy/phy.c |8
drivers/net/s2io.c
From: Theodore Tso <[EMAIL PROTECTED]>
Date: Thu, 3 Aug 2006 16:17:41 -0400
> eth0: Tigon3 [partno(BCM95704s) rev 2100 PHY(serdes)] (PCIX:100MHz:64-bit)
> 10/100/1000BaseT Ethernet 00:14:5e:86:44:24
The 5704 chip will set TG3_FLAG_TAGGED_STATUS, and therefore
doesn't need the periodic poking don
From: Theodore Tso <[EMAIL PROTECTED]>
Date: Thu, 3 Aug 2006 13:17:31 -0400
> The tg3_timer() code, for example, is trigger by the device driver but
> isn't associated with a process for boosting purposes, and creating a
> process just so that tg3_timer() can be boosted seems like the Wrong
Ted p
From: Alistair John Strachan <[EMAIL PROTECTED]>
Date: Thu, 3 Aug 2006 18:04:55 +0100
> Probably. I have an NC6000 with a tg3 and have never experienced
> link failure problems, even under -rt.
And note that the "poke the chip N times a second to avoid lockup"
issue only matters on very very old
Evgeniy Polyakov wrote:
> On Thu, Aug 03, 2006 at 08:09:07PM +0200, Arnd Hannemann ([EMAIL PROTECTED])
> wrote:
>> Evgeniy Polyakov schrieb:
>>> On Thu, Aug 03, 2006 at 07:16:31PM +0400, Evgeniy Polyakov ([EMAIL
>>> PROTECTED]) wrote:
>> then skb_alloc adds a little
>> (sizeof(struct skb_
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
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Thu, 3 Aug 2006 18:55:57 +0400
> I would not call that wrong - system prevents some threads from removing
> kevents which are counted to be transfered to the userspace, i.e. when
> dequeuing was awakened and it had seen some events it is possible,
Overflow can occur very easily with 32 bits, e.g., with 1 second
us_idle is approx. 2^20, which leaves only 11-Wlog bits for queue
length. Since the EWMA exponent is typically around 9, queue
lengths larger than 2^2 cause overflow. Whether the affected
branch is taken when us_idle is as high as 1 s
Whenever a transfer is application limited, we are allowed at least
initial window worth of data per window unless cwnd is previously
less than that.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/ipv4/tcp_input.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git
applied 1-2
-
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
applied 1-2
-
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
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
pulled
-
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
pulled
-
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
On Thu, 3 Aug 2006, [EMAIL PROTECTED] wrote:
Hi Scott,
I think the main concern that my co-workers here at SOMA Networks
and I have is that having two drivers dilutes the community effort.
There's also the fact that smc911x seems to have DMA support, which
smsc911x does not. Unless there are
---
drivers/infiniband/hw/amso1100/c2_mq.c | 175
drivers/infiniband/hw/amso1100/c2_mq.h | 107
2 files changed, 282 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/amso1100/c2_mq.c
b/drivers/infiniband/hw/amso1100/c2_mq
---
drivers/infiniband/Kconfig |1 +
drivers/infiniband/Makefile|1 +
drivers/infiniband/hw/amso1100/Kbuild | 10 ++
drivers/infiniband/hw/amso1100/Kconfig | 15 +++
drivers/infiniband/hw/amso1100/README | 11 +++
5 files chang
---
drivers/infiniband/hw/amso1100/c2_vq.c | 260
drivers/infiniband/hw/amso1100/c2_vq.h | 63
2 files changed, 323 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/amso1100/c2_vq.c
b/drivers/infiniband/hw/amso1100/c2_vq.c
new file
Roland, here is the updated Ammasso 1100 iWARP Driver.
This patchset implements the iWARP provider driver for the Ammasso
1100 RNIC. It is dependent on the "iWARP Core Support" patch set.
The patchset consists of 7 patches:
1 - Low-level device interface and native stack support
---
drivers/infiniband/hw/amso1100/c2_alloc.c | 144 +++
drivers/infiniband/hw/amso1100/c2_mm.c| 375 +
2 files changed, 519 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/amso1100/c2_alloc.c
b/drivers/infiniband/hw/amso1100/c2_alloc
This patch provides the new files implementing the iWARP Connection
Manager.
This module is a logical instance of the xx_cm where xx is the transport
type (ib or iw). The symbols exported are used by the transport
independent rdma_cm module, and are available also for transport
dependent ULPs.
--
Modifications to the existing rdma header files, core files, drivers,
and ulp files to support iWARP.
---
drivers/infiniband/core/Makefile |4
drivers/infiniband/core/addr.c | 18 +
drivers/infiniband/core/cache.c |7 -
drivers/infiniband/core/cm
With Seans comments resolved...
I also changed iw_addr_get_dgid() to memcpy the gid like the other
functions do.
This patchset defines the modifications to the Linux infiniband subsystem
to support iWARP devices.
The patchset consists of 2 patches:
1 - New iWARP CM implementati
Maximum e1000 frame is 16128 bytes, which is enough before being rounded
to 16k to have a space for shared info.
My patch just tricks refilling logic to request to allocate slightly less
than was setup when mtu was changed.
The maximum supported MTU size differs between e1000 devices due to
diff
On 8/3/06, Arnd Hannemann <[EMAIL PROTECTED]> wrote:
Well you say "if a single buffer per frame is going to be used". Well,
if I understood you correctly i could set the MTU to, lets say 4000.
Then the driver would enable the "jumbo frame bit" of the hardware, and
allocate only a 4k rx buffer, ri
Documentation for the NetLabel system, this includes a basic overview of how
NetLabel works, how LSM developers can integrate it into their favorite
LSM, as well as documentation on the CIPSO related sysctl variables. Also,
due to the difficulty of finding expired IETF drafts, I am including the I
Add NetLabel support to the SELinux LSM and modify the socket_post_create() LSM
hook to return an error code. The most significant part of this patch is the
addition of NetLabel hooks into the following SELinux LSM hooks:
* selinux_file_permission()
* selinux_socket_sendmsg()
* selinux_socket_
Add CIPSO/IPv4 and unlabeled packet management to the NetLabel subsystem. The
CIPSO/IPv4 changes allow the configuration of CIPSO/IPv4 within the overall
NetLabel framework. The unlabeled packet changes allows NetLabel to pass
unlabeled packets without error.
Signed-off-by: Paul Moore <[EMAIL PR
This is the NetLabel patchset backed against DaveM's net-2.6.19 tree. The
major changes from the last version have been the conversion to the new LSM
hooks that were introduced with the MLSXFRM patchset and the shift to using
Netlink attributes. I've also done some work to reduce the amount of ov
Add support for the Commercial IP Security Option (CIPSO) to the IPv4 network
stack. CIPSO has become a de-facto standard for trusted/labeled networking
amongst existing Trusted Operating Systems such as Trusted Solaris, HP-UX CMW,
etc. This implementation is designed to be used with the NetLabel
On Thu, Aug 03, 2006 at 11:36:47AM -0700, Michael Chan wrote:
> On Thu, 2006-08-03 at 20:00 +1000, Herbert Xu wrote:
> > Theodore Tso <[EMAIL PROTECTED]> wrote:
> > >
> > > I'm sending this on mostly because it was a bit of a pain to track down,
> > > and hopefully it will save time if anyone else
Changes to the core network stack to support the NetLabel subsystem. This
includes changes to the IPv4 option handling to support CIPSO labels.
Signed-off-by: Paul Moore <[EMAIL PROTECTED]>
---
include/linux/ip.h |1
include/net/cipso_ipv4.h | 250
Modify the net/Kconfig file to enable selecting the NetLabel Kconfig options.
Signed-off-by: Paul Moore <[EMAIL PROTECTED]>
---
net/Kconfig |2 ++
1 files changed, 2 insertions(+)
Index: net-2.6.19/net/Kconfig
===
--- net-2.6.19
On Thu, Aug 03, 2006 at 11:54:41PM +1000, Herbert Xu wrote:
> Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> >
> > this is another one of those nasty buggers;
>
> Good catch. It's really time that we fix this properly rather than
> adding more kludges to the core code.
>
> Dave, once this goes i
Jean Tourrilhes wrote:
Jean
P.S. : By the way, don't ask me why it took four years for this bug to
get discovered...
that I could answer: Only from 2.6.18-rc1 onwards does the kernel have a built
in deadlock finder :)
-
To unsubscribe from this list: send the line "unsubscribe netdev"
On Thu, Aug 03, 2006 at 07:14:59PM +1000, Philip Craig wrote:
> > So now you _need_ bridging in the middle to send ethernet traffic over
> > a GRE tunnel? Ugh.
>
> Agreed that would not be nice. What is the usage scenario for this?
> At least one end of the tunnel will be bridged?
For example
On Thu, Aug 03, 2006 at 02:59:58PM -0400, Dave Jones wrote:
> On Thu, Aug 03, 2006 at 11:58:00AM -0700, Jean Tourrilhes wrote:
> > On Thu, Aug 03, 2006 at 03:11:53PM +0100, Christoph Hellwig wrote:
> > > On Thu, Aug 03, 2006 at 11:54:41PM +1000, Herbert Xu wrote:
> > > > Arjan van de Ven <[EMAIL
On Wed, 2006-08-02 at 21:08 -0700, Stephen J. Bevan wrote:
> Balazs Scheidler writes:
> > I would like to easily match a set of dynamically created interfaces
> > from my packet filter rules. The attached patch forms the basis of my
> > implementation and I would like to know whether something l
On Thu, Aug 03, 2006 at 03:11:53PM +0100, Christoph Hellwig wrote:
> Could we please just get rid of the wireless extensions over netlink code
> again? It doesn't help to solve anything and just creates a bigger mess
> to untangle when switching to a fully fledged wireless stack.
If we're goi
On Thu, Aug 03, 2006 at 11:58:00AM -0700, Jean Tourrilhes wrote:
> On Thu, Aug 03, 2006 at 03:11:53PM +0100, Christoph Hellwig wrote:
> > On Thu, Aug 03, 2006 at 11:54:41PM +1000, Herbert Xu wrote:
> > > Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > > >
> > > > this is another one of those
On Thu, Aug 03, 2006 at 03:11:53PM +0100, Christoph Hellwig wrote:
> On Thu, Aug 03, 2006 at 11:54:41PM +1000, Herbert Xu wrote:
> > Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > >
> > > this is another one of those nasty buggers;
> >
> > Good catch. It's really time that we fix this properly
On Thu, Aug 03, 2006 at 11:54:41PM +1000, Herbert Xu wrote:
> Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> >
> > this is another one of those nasty buggers;
>
> Good catch. It's really time that we fix this properly rather than
> adding more kludges to the core code.
>
> Dave, once this goes i
Roland/Sean,
I'll fix all these and retest, then resubmit...
Comments below...
Steve.
On Thu, 2006-08-03 at 11:11 -0700, Sean Hefty wrote:
> Steve Wise wrote:
> > diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
> > index d294bbc..83f84ef 100644
> > --- a/drivers/i
On Thu, Aug 03, 2006 at 08:09:07PM +0200, Arnd Hannemann ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov schrieb:
> > On Thu, Aug 03, 2006 at 07:16:31PM +0400, Evgeniy Polyakov ([EMAIL
> > PROTECTED]) wrote:
> then skb_alloc adds a little
> (sizeof(struct skb_shared_info)) at the end, and
On Thu, 2006-08-03 at 20:00 +1000, Herbert Xu wrote:
> Theodore Tso <[EMAIL PROTECTED]> wrote:
> >
> > I'm sending this on mostly because it was a bit of a pain to track down,
> > and hopefully it will save time if anyone else hits this while playing
> > with the -rt kernel. It is NOT the right w
On Thu, 2006-08-03 at 10:40 -0700, Roland Dreier wrote:
> Steve> Here is the iWARP Core Support patchset merged to your
> Steve> latest for-2.6.19 branch. It has gone through 3 reviews on
> Steve> lklm and netdev a while ago, and I think its ready to be
> Steve> pulled in.
>
> I a
Steve Wise wrote:
diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
index d294bbc..83f84ef 100644
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -32,6 +32,7 @@ #include
#include
#include
#include
+#include
File is included 3 lines
Evgeniy Polyakov schrieb:
> On Thu, Aug 03, 2006 at 07:16:31PM +0400, Evgeniy Polyakov ([EMAIL
> PROTECTED]) wrote:
then skb_alloc adds a little
(sizeof(struct skb_shared_info)) at the end, and this ends up
in 32k request just for 9k jumbo frame.
>>> Strange, why this skb_shared_inf
On Thu, 2006-08-03 at 09:36 -0700, Brandeburg, Jesse wrote:
> I followed the example of tg3 when attempting to optimize this code. For
> the normal case we remove a lock acquisition. Jamals case is not normal.
> :-)
>
> we specifically added this lock originally to fix a problem we saw where
Steve> Here is the iWARP Core Support patchset merged to your
Steve> latest for-2.6.19 branch. It has gone through 3 reviews on
Steve> lklm and netdev a while ago, and I think its ready to be
Steve> pulled in.
I agree. I'll read this over and queue it for 2.6.19 unless someone
ob
On Thu, Aug 03, 2006 at 09:49:17AM -0700, Randy.Dunlap wrote:
> Interesting. On my Dell D610 notebook with tg3 and vpn,
> I have to ping a server on the vpn to keep it alive, otherwise
> it disappears soon and I have to restart the vpn. Of course,
> this could just be the vpn or some other softwa
On Thu, Aug 03, 2006 at 09:46:37AM -0700, Daniel Walker wrote:
> There is some form of priority inheritance on the timer softirq. It said
> in the patch header that the right fix was for the timer softirq to
> change priorities. Which Real Time patch are you using? Or is the
> current system not su
On Thu, Aug 03, 2006 at 10:04:36AM -0700, Badari Pulavarty ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> >AIO, aio_sendfile() implementation.
> >
> >This patch includes asynchronous propagation of file's data into VFS
> >cache and aio_sendfile() implementation.
> >Network aio_sendfile() w
Fix from [EMAIL PROTECTED], STP packets are incorrectly received on all
LLC datagram sockets, whichever interface they are bound to.
The llc_sap datagram receive logic sends packets with a unicast destination
MAC to one socket bound to that SAP and MAC, and multicast packets to all
sockets
bound
1 - 100 of 185 matches
Mail list logo
