On Mon, 2 Apr 2007 11:43:19 +1000 CaT <[EMAIL PROTECTED]> wrote:
> I take minute by minute snapshots of network traffic by sampling
> /proc/net/dev and most of the time everything works fine. Occasionally
> though I get petabyte byte traffic and corresponding packet traffic.
How frequently?
Are
On Mon, Apr 02, 2007 at 12:13:00AM -0700, Andrew Morton wrote:
> On Mon, 2 Apr 2007 11:43:19 +1000 CaT <[EMAIL PROTECTED]> wrote:
>
> > I take minute by minute snapshots of network traffic by sampling
> > /proc/net/dev and most of the time everything works fine. Occasionally
> > though I get petab
On Sat, 31 Mar 2007, [EMAIL PROTECTED] wrote:
> On 3/31/2007, "David Miller" <[EMAIL PROTECTED]> wrote:
> > From: Thomas Graf <[EMAIL PROTECTED]>
> > Date: Sat, 31 Mar 2007 00:10:54 +0200
> >
> > > * David Miller <[EMAIL PROTECTED]> 2007-03-30 14:43
> > > > Let's not speculate, let's find out for
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Mon, 2 Apr 2007 11:38:51 +0300 (EEST)
> [PATCH] [TCP]: Fix invalid skb referencing in LOST marker code
>
> The after() referenced an invalid skb if loop exited when skb had
> reached sk_write_queue. I chose to move this part inside the loop
> where
I don't know if a me-too may help you, but I have exactly the same
trouble on a whole set of dell servers, all with bmx drivers (suse 10.1
kernel) and values fetched by an homebrew daemon and collected via rrd.
> uname -a
Linux toronto 2.6.16.27-0.6-smp #1 SMP Wed Dec 13 09:34:50 UTC
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> From: Ingo Molnar <[EMAIL PROTECTED]>
>
> work around a NULL skb dereference crash that occurs during high load.
>
> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
> Cc: Ayaz Abdulla <[EMAIL PROTECTED]>
> Cc: Jeff Garzik <[EMAIL PROTECTED]>
> Sig
Please send bugreports to [EMAIL PROTECTED]
Ole Reinartz wrote:
> I'm trying to get some DiffServ QoS shaping to work on an XScale
> machine, running big endian. I'm setting it up with tc. Using the
> tcindex filter I found that regardless what shift value I enter, only
> '0' is returned when I li
I noticed a problem with PMTUD between two IPsec tunnel endpoints.
When sending a packet larger than the PMTU with IP_DF from one
tunnel endpoint to the other, xfrm4_output sends an ICMP frag.
required with the IPsec MTU. Since the addresses match the tunnel
endpoints, this updates the MTU for the
On Sun, 2007-04-01 at 10:10 -0700, Bill Helfinstine wrote:
>
> If you set the IFF_ALLMULTI flag on a b44 device, or if you join more
> than
> B44_MCAST_TABLE_SIZE multicast groups, the device will stop receiving
> unicast
> messages. This is because the __b44_set_mac_addr call sets the zeroth
> C
I had responded eariler to the thread asking you to try out the patch
found in bug 8058:
http://bugzilla.kernel.org/show_bug.cgi?id=8058
I believe that is the caush of the NULL skb dereference issue.
Thanks,
Ayaz
-Original Message-
From: Ingo Molnar [mailto:[EMAIL PROTECTED]
Sent: Mond
I changed the title to be more accurate, and culled the distribution to
individuals and netdev
The mention of trying to turn-off CKO and see if the data corruption
goes away leads me to ask a possibly "delicate" question:
Should "Linux" only enable CKO on those NICs certified to have
ECC/
On Mon, Apr 02, 2007 at 10:46:00AM -0700, Rick Jones wrote:
> I changed the title to be more accurate, and culled the distribution to
> individuals and netdev
>
> The mention of trying to turn-off CKO and see if the data corruption
> goes away leads me to ask a possibly "delicate" question:
>
>
* Ayaz Abdulla <[EMAIL PROTECTED]> wrote:
> I had responded eariler to the thread asking you to try out the patch
> found in bug 8058:
> http://bugzilla.kernel.org/show_bug.cgi?id=8058
>
> I believe that is the caush of the NULL skb dereference issue.
ah, sorry - i checked the wrong thread for
On Mon, 2 Apr 2007 22:12:27 +0400
"Peter Trifonov" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I have got a PC based on Gigabyte GA-965P-S3 motherboard with an integrated
> Marvell Yukon 88E8056 PCI-E gigabit ethernet controller.
>
> I am using OpenSuSe Linux 10.2 x64/SMP with 2.6.18.2-34-default
On March 14, 2007 12:18:56 pm Alex Sidorenko wrote:
> On March 13, 2007 03:01:50 pm John Heffner wrote:
> > Sorry for the long delay in response, I've been on vacation. I'm okay
> > with your patch, and I can't think of any real problem with it, except
> > that the behavior is non-standard. Then
Hi there,
we have serious problems with 2 of our servers: both shiny new amd64
dual core, with both 2GB RAM, 32bit kernel+userland (Debian/testing).
Both servers have 2 NICs, RTL8139 (eth0, irq10) and RTL8169s
(eth1, irq11).
Both boxes are running fine but after "a while" they lock up and
ev
The irq handler schedules a NAPI poll request unconditionally as soon as
the status register is not clean. It has been there - and wrong - for
ages but a recent timing change made it apparently easier to trigger.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Jay Cliburn <[EMAIL PROTECTED]
Christian Kujau wrote:
>
> Please see http://nerdbynature.de/bits/2.6.20.4/ for details for both
> hosts and feel free to ask for more details. Although both boxes are in
> production we'll be happy test more bootoptions/patches and the like.
Where is the info from before you changed to "noapic"?
From: Alex Sidorenko <[EMAIL PROTECTED]>
Date: Mon, 2 Apr 2007 16:01:13 -0400
> our customer has tested your patch thoroughly and everything's working fine.
> Please apply the patch if this is not done yet.
Thanks for following through on this Alex, I've been waiting patiently
for your test resu
Francois Romieu <[EMAIL PROTECTED]> :
[...]
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index 521b5f0..990699f 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -64,8 +64,10 @@ VERSION 2.2LK <2005/01/25>
> #include
> #include
> #include
> +#include
> #i
The irq handler schedules a NAPI poll request unconditionally as soon as
the status register is not clean. It has been there - and wrong - for
ages but a recent timing change made it apparently easier to trigger.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Jay Cliburn <[EMAIL PROTECTED]
The PM hooks are no-op if the r8169 interface is down (i.e. !IFF_UP).
However, as the chipset is enabled, the device will not work after a
suspend/resume cycle. The patch always issue the required PCI suspend
sequence and removes the module unload/reload workaround.
Signed-off-by: Arnaud Patard <[
* David Miller <[EMAIL PROTECTED]> 2007-04-02 02:02
> From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
> Date: Mon, 2 Apr 2007 11:38:51 +0300 (EEST)
>
> > [PATCH] [TCP]: Fix invalid skb referencing in LOST marker code
> >
> > The after() referenced an invalid skb if loop exited when skb had
> > reached
On Mon, 2 Apr 2007, Chuck Ebbert wrote:
Please see http://nerdbynature.de/bits/2.6.20.4/ for details for both
hosts and feel free to ask for more details. Although both boxes are in
production we'll be happy test more bootoptions/patches and the like.
Where is the info from before you changed t
Chris Friesen wrote:
It behaved fairly well with standard networking, but its behaving
strangely with bonding added to the mix.
Thanks to everyone for the suggestions and help.
It turns out it was actually a driver problem that was more easily
manifested by the timing of the way bonding chan
The first of these patches together provide secure client-side RxRPC
connectivity as a Linux kernel socket family. Only the RxRPC transport/session
side is supplied - the presentation side (marshalling the data) is left to the
client. Copies of the patches can be found here:
http://peop
Move generic skbuff stuff from XFRM code to generic code so that AF_RXRPC can
use it too.
The kdoc comments I've attached to the functions needs to be checked by whoever
wrote them as I had to make some guesses about the workings of these functions.
Signed-Off-By: David Howells <[EMAIL PROTECTED]
Add blkcipher accessors for using kernel data directly without the use of
scatter lists.
Also add a CRYPTO_ALG_DMA algorithm capability flag to permit or deny the use
of DMA and hardware accelerators. A hardware accelerator may not be used to
access any arbitrary piece of kernel memory lest it no
Export try_to_del_timer_sync() for use by the RxRPC module.
Add a try_to_cancel_delayed_work() so that it is possible to merely attempt to
cancel a delayed work timer.
Signed-Off-By: David Howells <[EMAIL PROTECTED]>
---
include/linux/workqueue.h | 21 +
kernel/timer.c
Export the keyring key type definition and document its availability.
Add alternative types into the key's type_data union to make it more useful.
Not all users necessarily want to use it as a list_head (AF_RXRPC doesn't, for
example), so make it clear that it can be used in other ways.
Signed-Of
Add an interface to the AF_RXRPC module so that the AFS filesystem module can
more easily make use of the services available. AFS still opens a socket but
then uses the action functions in lieu of sendmsg() and registers an intercept
functions to grab messages before they're queued on the socket R
Preliminary version if TCP Illinois for 2.6.22.
It needs more testing and refinement but it captures the
basic concepts.
---
net/ipv4/Kconfig| 13 +++
net/ipv4/Makefile |1 +
net/ipv4/tcp_illinois.c | 238 +++
3 files changed, 252 i
From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Date: Sat, 31 Mar 2007 12:13:45 -0300
> Please consider pulling from:
>
> master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.22.git
Pulled, thanks Arnaldo.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the bo
From: David Howells <[EMAIL PROTECTED]>
Date: Mon, 02 Apr 2007 23:45:03 +0100
> Move generic skbuff stuff from XFRM code to generic code so that AF_RXRPC can
> use it too.
>
> The kdoc comments I've attached to the functions needs to be checked by
> whoever
> wrote them as I had to make some gue
From: David Howells <[EMAIL PROTECTED]>
Date: Mon, 02 Apr 2007 23:44:58 +0100
> Add blkcipher accessors for using kernel data directly without the
> use of scatter lists.
>
> Also add a CRYPTO_ALG_DMA algorithm capability flag to permit or deny the use
> of DMA and hardware accelerators. A hardwa
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Mon, 2 Apr 2007 20:15:25 -0700
> Preliminary version if TCP Illinois for 2.6.22.
> It needs more testing and refinement but it captures the
> basic concepts.
No objections from me and I don't see any obvious problems.
Would you like me to stuff t
On Mon, 02 Apr 2007 20:39:37 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Mon, 2 Apr 2007 20:15:25 -0700
>
> > Preliminary version if TCP Illinois for 2.6.22.
> > It needs more testing and refinement but it captures the
> > basic concep
On Mon, Apr 02, 2007 at 08:22:15PM -0700, David Miller wrote:
>
> I'll let Herbert, the crypto layer maintainer, decide on this one.
> I can put it into net-2.6.22 in order to make the RXRPC integration
> easier if Herbert is OK with this.
>
> Please be sure to CC: Herbert and/or the crypto lists
On Monday 02 April 2007 15:41, Christian Kujau wrote:
>
> Hi there,
>
> we have serious problems with 2 of our servers: both shiny new amd64
> dual core, with both 2GB RAM, 32bit kernel+userland (Debian/testing).
> Both servers have 2 NICs, RTL8139 (eth0, irq10) and RTL8169s
> (eth1, irq11).
>
On Mon, 2 Apr 2007, Chuck Ebbert wrote:
Where is the info from before you changed to "noapic"? Or were the
machines always using XT-PIC for all the interrupts???
XT-PIC is only used since we switched to noapic, before there was
IO-APIC-fasteoi on both ethernet cards and interrupts were balance
On Tue, 3 Apr 2007, Len Brown wrote:
Which increased stability, disabling ACPI, or disabling the IOAPIC?
To be honest, we're not sure. See below.
Your box has MPS, so you should be able to use the IOAPIC in either mode.
MPS - Multiprocessor Specification? SMP? Yes, it'd be good to use the
* Ayaz Abdulla <[EMAIL PROTECTED]> wrote:
> I had responded eariler to the thread asking you to try out the patch
> found in bug 8058:
> http://bugzilla.kernel.org/show_bug.cgi?id=8058
>
> I believe that is the caush of the NULL skb dereference issue.
there's a different type of regression now:
On 02-04-2007 21:41, Christian Kujau wrote:
>
> Hi there,
>
> we have serious problems with 2 of our servers: both shiny new amd64
> dual core, with both 2GB RAM, 32bit kernel+userland (Debian/testing).
> Both servers have 2 NICs, RTL8139 (eth0, irq10) and RTL8169s
> (eth1, irq11).
Hi,
Did you
43 matches
Mail list logo
