> Michael Ellerman <[EMAIL PROTECTED]> wrote on 02.11.2007 07:30:08:
>
> > On Wed, 2007-10-31 at 20:48 +0100, Christoph Raisch wrote:
> > > Michael Ellerman <[EMAIL PROTECTED]> wrote on 30.10.2007 23:50:36:
> > If that's really the way it works then eHEA is more or less broken for
> > kdump I'm af
On Fri, 2007-02-11 at 18:31 +0100, Jarek Poplawski wrote:
> Radu Rendec wrote:
>
> > Hi,
> >
> > While trying to implement u32 hashes in my shaping machine I ran into a
> > possible bug in the u32 hash/bucket computing algorithm
> > (net/sched/cls_u32.c).
> >
> > The problem occurs only with ha
On Sun, 2007-10-28 at 22:17 +0200, Eliezer Tamir wrote:
> Dave,
>
> Please take a look and tell me if this is better than the last attempt.
>
> Main changes:
>
> * Rewrite of the init code:
> 1. Full rewrite of the generated code into something easier to read.
> 2. Removed zeroes by
Thus spake Rick Jones ([EMAIL PROTECTED]):
> Past performance is no guarantee of current correctness :) And over an
> Ethernet, there will be a very different set of both timings and TCP
> segment sizes compared to loopback.
> My guess is that you will find setting the lo mtu to 1500 a very
>
ICMP message type and/or code may be value "0" when
used as selector.
Currently, if you specify SPD entry with upper layer
protocol set as icmp, specify message type is 0 and
code is 0, then all icmp messages get
mapped to this. It appears value 0 for port is
interpreted to mean ANY, which is no
Felix von Leitner wrote:
Thus spake Rick Jones ([EMAIL PROTECTED]):
Oh I'm pretty sure it's not my application, because my application performs
well over ethernet, which is after all its purpose. Also I see the
write, the TCP uncork, then a pause, and then the packet leaving.
Well, a wise ol
Thus spake Rick Jones ([EMAIL PROTECTED]):
> >Oh I'm pretty sure it's not my application, because my application performs
> >well over ethernet, which is after all its purpose. Also I see the
> >write, the TCP uncork, then a pause, and then the packet leaving.
> Well, a wise old engineer tried to
Felix von Leitner wrote:
Thus spake Rick Jones ([EMAIL PROTECTED]):
How could I test this theory?
Can you take another trace that isn't so "cooked?" One that just sticks
with TCP-level and below stuff?
Sorry for taking so long. Here is a tcpdump. The side on port 445 is
the SMB server
Thus spake Eric Dumazet ([EMAIL PROTECTED]):
> 1) Setting a timeout in a millisecond range (< 1000) is not very good
> because some clients may need much more time to send your server the data
> (very long distance). So a second granularity is OK.
I want millisecond accuracy for consistency. se
Thus spake Rick Jones ([EMAIL PROTECTED]):
> >How could I test this theory?
> Can you take another trace that isn't so "cooked?" One that just sticks
> with TCP-level and below stuff?
Sorry for taking so long. Here is a tcpdump. The side on port 445 is
the SMB server using TCP_CORK.
23:03:20.
From: Chuck Lever <[EMAIL PROTECTED]>
Date: Fri, 02 Nov 2007 15:14:26 -0400
> The (int) type cast in skb_truesize_check() is unneeded: without it, all
> the variable types in the conditional expression are unsigned integers. As
> it stands, the type cast causes a comparison between a signed and a
From: Dave Johnson <[EMAIL PROTECTED]>
Date: Fri, 2 Nov 2007 14:08:32 -0400
> These changes seems to cause this issue:
>
> > [BNX2]: Fix VLAN on ASF
> >
> > Always set up the device to strip incoming VLAN tags when ASF is
> > enabled. ASF firmware will not parse packets correctly if VLAN tag
On Fri, 2007-11-02 at 14:08 -0400, Dave Johnson wrote:
> >
> > *2: If chip supports 'ASF', tag is always stripped (see *1 above).
> > Looks ok if ASF is not supported.
>
> Michael,
>
> These changes seems to cause this issue:
>
> > [BNX2]: Fix VLAN on ASF
> >
> > Always set up the d
The get_seconds() function now returns an unsigned long. K&R states
that comparing a signed long with an unsigned long implicitly converts
the signed long to unsigned long [1].
Thus ts_recent_stamp and tw_ts_recent_stamp are already implicitly
converted to unsigned long in every comparison with g
On Fri, Nov 02, 2007 at 11:45:15AM -0700, David Brownell wrote:
>...
> --- a.orig/drivers/net/usb/usbnet.c 2007-10-13 15:16:10.0 -0700
> +++ a/drivers/net/usb/usbnet.c2007-11-02 11:39:59.0 -0700
> @@ -682,10 +682,17 @@ done_nopm:
> /* ethtool methods; minidrivers may need
On Fri, Nov 02, 2007 at 12:30:22PM -0700, David Brownell wrote:
> On Friday 02 November 2007, Adrian Bunk wrote:
> > This approach has two disadvantages:
> > - it's complicated
>
> No more so than the problem itself.
>
>
> > - the MII stuff is an implementation detail, and we shouldn't bother
>
On Friday 02 November 2007, Adrian Bunk wrote:
> This approach has two disadvantages:
> - it's complicated
No more so than the problem itself.
> - the MII stuff is an implementation detail, and we shouldn't bother
> the user with it (especially since we can do better)
That's a Kconfig policy
The (int) type cast in skb_truesize_check() is unneeded: without it, all
the variable types in the conditional expression are unsigned integers. As
it stands, the type cast causes a comparison between a signed and an
unsigned integer, which can produce unexpected results.
Signed-off-by: Chuck Lev
On Fri, Nov 02, 2007 at 11:45:15AM -0700, David Brownell wrote:
> On Thursday 01 November 2007, Adrian Bunk wrote:
> > The following combination of options is simply an unusual one:
> >
> > CONFIG_MII=m
> > CONFIG_USB_USBNET=y
> > CONFIG_USB_USBNET_MII=n
>
> I though that had been fixed for ages
On Thursday 01 November 2007, Adrian Bunk wrote:
> The following combination of options is simply an unusual one:
>
> CONFIG_MII=m
> CONFIG_USB_USBNET=y
> CONFIG_USB_USBNET_MII=n
I though that had been fixed for ages ...
This should do a better job of it.
- Dave
== CUT HERE
Simpli
Dave Johnson writes:
> Ben Greear writes:
> > Currently, VLAN devices offer the ability to 'reorder' the header
> > and explicitly remove the VLAN header. I assume we keep this
> > feature and have the AF_PACKET logic check the device flags to see
> > if it should insert the VLAN header for hw-acc
Pavel Emelyanov wrote:
> Roel Kluin wrote:
>> Roel Kluin wrote:
>>> I got this bug recently, I am not sure whether this is related to any
>>> previously
>>> reported ones. It was a recently pulled git kernel. Also I have been
>>> hacking my
>>> kernel a bit lately, but I think that I haven't got
Radu Rendec wrote:
> Hi,
>
> While trying to implement u32 hashes in my shaping machine I ran into a
> possible bug in the u32 hash/bucket computing algorithm
> (net/sched/cls_u32.c).
>
> The problem occurs only with hash masks that extend over the octet
> boundary, on little endian machines (wh
Hi!
> > 2) Nonetheless, swap over NFS is a pretty rare case. I view this work
> > as interesting, but I really don't see a huge need, for swapping over
> > NBD or swapping over NFS. I tend to think swapping to a remote resource
> > starts to approach "migration" rather than merely swapping.
Kok, Auke wrote:
David Acker wrote:
On the systems that have cache incoherent DMA, including ARM, there is a
race condition between software allocating a new receive buffer and hardware
writing into a buffer. The two race on touching the last Receive Frame
Descriptor (RFD). It has its el-bit s
David Acker wrote:
> On the systems that have cache incoherent DMA, including ARM, there is a
> race condition between software allocating a new receive buffer and hardware
> writing into a buffer. The two race on touching the last Receive Frame
> Descriptor (RFD). It has its el-bit set and its n
The ip6_push_pending_frames and ip6_flush_pending_frames do the
same things to flush the sock's cork. Move this into a separate
function and save ~100 bytes from the .text
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 653f
The ip_push_pending_frames and ip_flush_pending_frames do the
same things to flush the sock's cork. Move this into a separate
function and save ~80 bytes from the .text
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index e5f7dc2..
On Fri, Nov 02, 2007 at 08:14:43AM +0100, Stefan Roese wrote:
> This patch adds support for the 405EX to the new EMAC driver. Some as on
> AXON, the 405EX handles the MDIO via the RGMII bridge.
Hi,
This isn't feedback on your patch as much as on "new-emac" in general:
Isn't this the case where t
Hello,
I'm sorry to not respond quickly.
Bill Fink wrote:
On Mon, 29 Oct 2007, Hideo AOKI wrote:
This patch added /proc/sys/net/udp_rmem and /proc/sys/net/udp_rmem.
Each UDP packet is drooped when the number of pages for socket buffer
is beyond the limit and the socket already consumes minimu
On Thu, Nov 01, 2007 at 04:52:39PM -0700, David Brownell wrote:
> On Thursday 01 November 2007, Adrian Bunk wrote:
> > All this USB_USBNET_MII trickery is simply not worth it considering how
> > few code it saves.
>
> Depends on what systems you're talking about. Forcing unused
> code into the k
This patch #if 0's the following unused functions:
- espi.c:t1_espi_set_misc_ctrl()
- sge.c:t1_sched_set_max_avail_bytes()
- sge.c:t1_sched_set_drain_bits_per_us()
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/chelsio/espi.c |2 ++
drivers/net/chelsio/espi.h |1 -
drive
On the systems that have cache incoherent DMA, including ARM, there is a
race condition between software allocating a new receive buffer and hardware
writing into a buffer. The two race on touching the last Receive Frame
Descriptor (RFD). It has its el-bit set and its next link equal to 0.
When h
Pavel Emelyanov wrote:
> Roel Kluin wrote:
>> I got this bug recently, I am not sure whether this is related to any
>> previously
>> reported ones. It was a recently pulled git kernel. Also I have been hacking
>> my
>> kernel a bit lately, but I think that I haven't got any changes in the
>> cu
Patrick McHardy wrote:
> Pavel Emelyanov wrote:
>> Both lookup the nf_sockopt_ops object to call the get/set callbacks
>> from, but they perform it in a completely similar way.
>>
>> Introduce the helper for finding the ops.
>>
>> Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED] >
>
>
> This con
Pavel Emelyanov wrote:
Both lookup the nf_sockopt_ops object to call the get/set callbacks
from, but they perform it in a completely similar way.
Introduce the helper for finding the ops.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED] >
This conflicts with a cleanup patch from Alexey Dobr
Michael Ellerman <[EMAIL PROTECTED]> wrote on 02.11.2007 07:30:08:
> On Wed, 2007-10-31 at 20:48 +0100, Christoph Raisch wrote:
> > Michael Ellerman <[EMAIL PROTECTED]> wrote on 30.10.2007 23:50:36:
> If that's really the way it works then eHEA is more or less broken for
> kdump I'm afraid.
We t
Roel Kluin wrote:
> I got this bug recently, I am not sure whether this is related to any
> previously
> reported ones. It was a recently pulled git kernel. Also I have been hacking
> my
> kernel a bit lately, but I think that I haven't got any changes in the
> currently
> running kernel.
>
>
I should have been very tired to miss this one when I looked at the
patch...
I looked again in the version I have tested. For some
reason/net/ipv4/ipvs/ip_vs_sync.c is not patched at all, this is what I
have missed.
Rumen
On Fri, 2007-11-02 at 09:53 +0900, Simon Horman wrote:
> On Fri, Nov 02, 2
Roel Kluin wrote:
> Roel Kluin wrote:
>> I got this bug recently, I am not sure whether this is related to any
>> previously
>> reported ones. It was a recently pulled git kernel. Also I have been hacking
>> my
>> kernel a bit lately, but I think that I haven't got any changes in the
>> current
40 matches
Mail list logo
