- 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
> sympt
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 th
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
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;
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 drive
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 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 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 tri
> + /* 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
t
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 t
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 recip
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
contai
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]>
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 into
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.
Applicati
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.
I'm working on a driver for a 10GbE nic. I've just gotten to the point where I
am verifying that 802.1q vlans work without hardware vlan offload. It
seems like
the netdev features flags (NETIF_F_SG|NETIF_F_IP_CSUM|NETIF_F_TSO) are not
being inherited by the vlan device. This leads to very high
On Thu, Mar 30, 2006 at 12:19:52PM -0800, Andrew Morton wrote:
> Steffen Klassert <[EMAIL PROTECTED]> wrote:
> >
> > Fix broken networking for older 10base2 NICs.
>
> Could we have a bit more description please? What was broken, how was it
> fixed?
>
> Thanks.
The "3c59x: use mii_check_media"
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 "str
Steffen Klassert <[EMAIL PROTECTED]> wrote:
>
> Fix broken networking for older 10base2 NICs.
Could we have a bit more description please? What was broken, how was it
fixed?
Thanks.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
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
Begin forwarded message:
Date: Thu, 30 Mar 2006 09:33:54 -0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 6309] New: SO_RCVBUF doubled on set not halved on get
http://bugzilla.kernel.org/show_bug.cgi?id=6309
Summary: SO_RCVBUF doubled on set not halved
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:
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 @@
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
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
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
nic
> 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
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
Hello, list,
I have one big raid array from 4 nbd device.
If i use the 2.6.15.7 i get this message sometimes:
NETDEV WATCHDOG: eth0: transmit timed out
e1000: eth0: e1000_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex
After this message (and some minute) usually the packet is retried, and
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
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
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 a
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 d
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.: Unk
BTW, it allows even funnier stuff: instead of "I'd been allocated by "
you can do "I'd passed through ". 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 state, etc.
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
th
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 (af
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:
slab_charge_here(
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 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
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 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
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 : tun
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?
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 re
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 iptable
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:
BIOS-e8
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:
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
52 matches
Mail list logo
