On Mar 29, 2006, at 4:55 PM, Chris Leech wrote:
Provides an API for offloading memory copies to DMA devices
Signed-off-by: Chris Leech [EMAIL PROTECTED]
---
drivers/Kconfig |2
drivers/Makefile |1
drivers/dma/Kconfig | 13 +
drivers/dma/Makefile |
On Mar 29, 2006, at 5:05 PM, Andrew Grover wrote:
On 3/28/06, Kumar Gala [EMAIL PROTECTED] wrote:
Do you only get callback when a channel is available?
Yes
How do you
decide to do to provide PIO to the client?
The client is responsible for using any channels it gets, or falling
back to
From: Denis Vlasenko [EMAIL PROTECTED]
Date: Thu, 30 Mar 2006 10:26:24 +0300
We have 200+ byte inlines in sock.h. That's way too large
in my opinion.
In Linus's tree already.
Would you please check the relevant trees before re-posting patches?
Thanks a lot.
-
To unsubscribe from this list:
Hi !
Yes, we still have these errors ... but then, we have not changed the running
kernel version for some time now ;)
---
Linux version 2.6.14-rc2-mm2 ([EMAIL PROTECTED]) (gcc version 3.4.4 20050721
(Red Hat 3.4.4-2)) #2 SMP Thu Dec 15 19:06:21 CET 2005
BIOS-provided physical RAM map:
On 29 Mar 2006, Brandeburg, Jesse wrote:
What I need from you is a reproducible test, and some information. I
have never been able to reproduce this, and I'm trying to isolate the
problem a bit. What motherboards are you using? What seems to cause
this problem? Are you all using iptables?
Hello, Brandeburg, Jesse.
On 30.03.2006 06:53 you said the following:
Hi all, I've identified you as people who have at some point in the past
emailed one of the Linux lists with problems with e1000 and
sk_forward_alloc. It seems to be fairly widespread, but only seems to
have appeared with
Hi,
What seems to cause this problem?
That I cannot say but the problem was fixed by removing one e1000 card
from the server (I initially had two e1000 cards installed in addition
to the two tg3 cards on the board).
Another fix was to disable TSO with ethtool.
What motherboards are you using?
On Wed, Mar 29, 2006 at 08:44:09PM -0800, David S. Miller wrote:
Herbert do you see any holes here?
Well I started from the beginning again, and found this. This may be
the smoking gun that we're after :)
The xmit routine is lockless but checks last_tx_tso outside the locked
section. So if
Hello, Herbert Xu.
On 30.03.2006 13:52 you said the following:
On Wed, Mar 29, 2006 at 08:44:09PM -0800, David S. Miller wrote:
Herbert do you see any holes here?
Well I started from the beginning again, and found this. This may be
the smoking gun that we're after :)
The xmit routine is
On Thu, Mar 30, 2006 at 12:26:58AM +0200, Andi Kleen wrote:
dentry_cache 999168 1024594208 191 : tunables 120 608 :
slabdata 53926 53926 0 : shrinker stat 18522624 8871000
Hrm interesting is this one:
sock_inode_cache 996784 99680570451 : tunables
On Thursday 30 March 2006 11:08, David S. Miller wrote:
From: Denis Vlasenko [EMAIL PROTECTED]
Date: Thu, 30 Mar 2006 10:26:24 +0300
We have 200+ byte inlines in sock.h. That's way too large
in my opinion.
In Linus's tree already.
Would you please check the relevant trees before
On Thu, Mar 30, 2006 at 10:50:48AM +0100, Al Viro wrote:
FWIW... One thing that might be useful here:
Here's what I had in mind:
Allow explictly mark allocated objects as allocated here, so that they'll
show up that way for all slab debugging purposes. New helpers:
On Thu, Mar 30, 2006 at 10:02:01AM +, Boris B. Zhmurov wrote:
[EMAIL PROTECTED] linux-2.6.16]$ patch -p1
../../../SOURCES/linux-2.6.16-e1000-try-to-fix-assertion_sk_forward_alloc_failed_by_Herbert_Xu.patch
patching file drivers/net/e1000/e1000_main.c
Reversed (or previously
On Wed, 29 Mar 2006, Brandeburg, Jesse wrote:
Hi all, I've identified you as people who have at some point in the past
emailed one of the Linux lists with problems with e1000 and
sk_forward_alloc. It seems to be fairly widespread, but only seems to
have appeared with recent kernel changes
On Thu, 30 Mar 2006, Mark Nipper wrote:
On 29 Mar 2006, Brandeburg, Jesse wrote:
What I need from you is a reproducible test, and some information. I
have never been able to reproduce this, and I'm trying to isolate the
problem a bit. What motherboards are you using? What seems to cause
BTW, it allows even funnier stuff: instead of I'd been allocated by place
you can do I'd passed through place. E.g. if object has different states
you can slap slab_charge_here() in state transitions and /proc/slab_allocators
will count them separately, showing how many objects are in which
Hello,
Motherboard?
Intel SE7520AF2 (Dual Xeon)
Are you all using iptables?
YES
Are you all routing?
NO
From the reports I assume none of you are using an 82571/2/3 (pci express)?
08:04.0 Ethernet controller: Intel Corp.: Unknown device 1079 (rev 03)
Subsystem: Intel Corp.:
Hello, Herbert Xu.
On 30.03.2006 14:12 you said the following:
On Thu, Mar 30, 2006 at 10:02:01AM +, Boris B. Zhmurov wrote:
[EMAIL PROTECTED] linux-2.6.16]$ patch -p1
../../../SOURCES/linux-2.6.16-e1000-try-to-fix-assertion_sk_forward_alloc_failed_by_Herbert_Xu.patch
patching file
Hi,
I ran into a got query but cannot answer problem.
How to retrieve the kernel's IPv6 routing cache table with a userland
tool? I would expect data like MTU of PMTUD, next hop, usage and so on.
IPv6:
# ip -6 route show table cache
ff02::1 via ff02::1 dev eth0 metric 0
cache mtu 1280
Hello everybody.
I have a problem with a sapgui-sapserver connection after
I have migrated an ipsec gateway, from linux 2.4.29/KLIPS
FreeS/SWAN 2.05 to linux 2.6.16.1/NETKEY Openswan 2.4.5rc6
Here is my network schema (I hope it is clear):
customer private network 10.0.0.0/8
|
|
+ipsec customer
Hello.
In article [EMAIL PROTECTED] (at Thu, 30 Mar 2006 16:39:14 +0200), Peter
Bieringer [EMAIL PROTECTED] says:
IPv6:
# ip -6 route show table cache
ff02::1 via ff02::1 dev eth0 metric 0
cache mtu 1280 advmss 1220 metric 10 4294967295
ff02::1:ffea:7781 via ff02::1:ffea:7781 dev
Hi,
Jeff Garzik [EMAIL PROTECTED] writes:
Patch OK but please resend per guidelines. Most importantly, include
the signed-off-by line, and include patch inline rather than as an
attachment.
See http://linux.yyz.us/patch-format.html
You have been around a while, you should already know
Balbir Singh wrote:
Hi, Andrew
On Wed, Mar 29, 2006 at 09:04:06PM -0800, Andrew Morton wrote:
Shailabh Nagar [EMAIL PROTECTED] wrote:
delayacct-genetlink.patch
Create a generic netlink interface (NETLINK_GENERIC family),
called taskstats, for getting delay and cpu statistics of
On 29 Mar 2006, Brandeburg, Jesse wrote:
What I need from you is a reproducible test, and some information. I
From all the reports which have come in thus far, it seems everyone
has 1 e1000. One person even reported that removing one of the two
nics solved the problem for him. Does this
On Thu, 30 Mar 2006, Phil Oester wrote:
On 29 Mar 2006, Brandeburg, Jesse wrote:
What I need from you is a reproducible test, and some information. I
From all the reports which have come in thus far, it seems everyone
has 1 e1000. One person even reported that removing one of the two
On 3/30/06, Kumar Gala [EMAIL PROTECTED] wrote:
I was under the impression that the DMA engine would provide a sync
cpu based memcpy (PIO) if a real HW channel wasn't avail, if this is
left to the client that's fine. So how does the client know he
should use normal memcpy()?
It has to keep
On 3/30/06, Kumar Gala [EMAIL PROTECTED] wrote:
What is the utility of exporting memcpy_count, and bytes_transferred
to userspace via sysfs? Is this really for debug (and thus should be
under debugfs?)
Wellit's true they're useful for debugging but I would put them in
the category of
Fix broken networking for older 10base2 NICs.
Signed-off-by: Steffen Klassert [EMAIL PROTECTED]
--- linux-2.6.16-git12/drivers/net/3c59x.c 2006-03-30 14:16:23.0
+0200
+++ linux-2.6.16-git12-sk/drivers/net/3c59x.c 2006-03-30 15:27:13.0
+0200
@@ -788,7 +788,7 @@
Begin forwarded message:
Date: Thu, 30 Mar 2006 09:06:52 -0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 6308] New: Bug in ip_route_input_slow()
http://bugzilla.kernel.org/show_bug.cgi?id=6308
Summary: Bug in ip_route_input_slow()
Kernel Version:
On Mar 30, 2006, at 12:36 PM, Andrew Grover wrote:
On 3/30/06, Kumar Gala [EMAIL PROTECTED] wrote:
What is the utility of exporting memcpy_count, and bytes_transferred
to userspace via sysfs? Is this really for debug (and thus should be
under debugfs?)
Wellit's true they're useful for
This has been this way for centuries and it's the correct behavior.
We double it on the way in to account for struct sk_buff etc.
overhead, applications assume that the SO_RCVBUF setting they make
will allow that much actual data to be received on that socket.
Applications are unaware that
Please review, sign-off/ack, and forward upstream.
--linas
[PATCH]: e1000: prevent statistics from getting garbled during reset.
If a PCI bus error/fault triggers a PCI bus reset, attempts to get the
ethernet packet count statistics from the hardware will fail, returning
garbage data upstream.
David S. Miller wrote:
This has been this way for centuries and it's the correct behavior.
We double it on the way in to account for struct sk_buff etc.
overhead, applications assume that the SO_RCVBUF setting they make
will allow that much actual data to be received on that socket.
Folks,
I've just posted a patch at
http://wand.net.nz/~iam4/software/congestion-iperf-2.0.2-1.diff which
adds being able to select the TCP congestion control mechanism to
iperf for TCP performance testing. Thanks to Angelo Castellani for
writing this which I have tidied up a little and merged
This patch fixes the nic initialization. If the nic was in low power
mode, it brings it back to normal power. Also, it utilizes a new
hardware reset during the init.
Signed-Off-By: Ayaz Abdulla [EMAIL PROTECTED]
This patch fixes the issues with multiple irqs.
Thanks to Manfred for catching the spin lock problem.
Signed-Off-By: Ayaz Abdulla [EMAIL PROTECTED]
---
This email message is for the sole use of the intended
This patch adds flow control support for tx and rx pause frames in
forcedeth.
Signed-Off-By: Ayaz Abdulla [EMAIL PROTECTED]
---
This email message is for the sole use of the intended recipient(s) and may
contain
We've had reports from customers of boxes with a week's uptime and 32k MTUs
getting failed order-3 allocs under:
udp_sendmsg .. ip_append_data .. {sock_wmalloc, sock_alloc_send_skb}
I came up with the following which seems to do the right thing in a trivial
test. It clamps the size of
+ /* watch out for trailer_len */
+ if (datalen == length)
+ datalen -= 2;
Hmm, that probably needs to be more careful :/
- z
-
To unsubscribe from this list: send the line unsubscribe netdev in
the
On Thu, Mar 30, 2006 at 03:39:28PM -0600, Linas Vepstas wrote:
Please review, sign-off/ack, and forward upstream.
--linas
Per feedback, here's a slightly more human-readable version.
--linas
[PATCH]: e1000: prevent statistics from getting garbled during reset.
If a PCI bus error/fault
Linas Vepstas wrote:
On Thu, Mar 30, 2006 at 03:39:28PM -0600, Linas Vepstas wrote:
Please review, sign-off/ack, and forward upstream.
--linas
Per feedback, here's a slightly more human-readable version.
--linas
[PATCH]: e1000: prevent statistics from getting garbled during reset.
On Thu, Mar 30, 2006 at 06:05:45PM -0700, Jeff V. Merkey wrote:
Linas Vepstas wrote:
Well, these comments have nothing to do with my patch, but ...
anyway ...
The driver also needs to be fixed to allow clearing of the stats (like
all the other adapter drivers). At present, when I run
Linas Vepstas wrote:
On Thu, Mar 30, 2006 at 06:05:45PM -0700, Jeff V. Merkey wrote:
Linas Vepstas wrote:
Well, these comments have nothing to do with my patch, but ...
anyway ...
The driver also needs to be fixed to allow clearing of the stats (like
all the other adapter
On Thu, Mar 30, 2006 at 06:02:08PM -0600, Linas Vepstas wrote:
- /* Prevent stats update while adapter is being reset */
+ /* Prevent stats update while adapter is being reset,
+ * or if the pci connection is down. */
if (adapter-link_speed == 0)
return;
+
On Thu, 30 Mar 2006, Mark Butler wrote:
David S. Miller wrote:
This has been this way for centuries and it's the correct behavior.
We double it on the way in to account for struct sk_buff etc.
overhead, applications assume that the SO_RCVBUF setting they make
will allow that much actual
From: Bill Fink [EMAIL PROTECTED]
Date: Fri, 31 Mar 2006 01:58:35 -0500
I don't think it makes perfect sense. If there's overhead, fine go
ahead and add the overhead, but do it under the covers and invisible
to the user.
How in the world would you ever be able to figure out what
value the
- Original Message -
From: BRM [EMAIL PROTECTED]
To: JaniD++ [EMAIL PROTECTED]
Sent: Friday, March 31, 2006 12:05 AM
Subject: Re: e1000 - packet lost bug in 6.3.9 (old version :NETDEV WATCHDOG:
eth0: transmit timed out)
I saw your message below and was wondering if the
symptoms I
47 matches
Mail list logo
