David S. Miller wrote:
From: Ben Greear [EMAIL PROTECTED]
Date: Mon, 29 Aug 2005 16:01:11 -0700
Latest netdevice ref-count debugging patch is up. The
patch is against 2.6.13:
http://www.candelatech.com/oss/rfcnt.patch
I reviewed this, and I think the approach can be refined and made more
From: Ben Greear [EMAIL PROTECTED]
Date: Thu, 01 Sep 2005 23:11:28 -0700
A quick optimization is to kmalloc chunks of 1000 or so structs at once
and then write a cheap foomalloc method to grab and release them. We
already take a lock (at least in my implementation), so this should be
small
On Thu, Sep 01, 2005 at 08:00:33PM -0400, Pavel Roskin wrote:
Hello!
Following 8 patches bring orinoco drivers in the kernel fully in-sync
with the CVS repository at http://savannah.nongnu.org/projects/orinoco/
(for_linus branch).
The patches include 2 new front-end drivers:
From: John Heffner [EMAIL PROTECTED]
Date: Thu, 1 Sep 2005 22:51:48 -0400
I have an idea why this is going on. Packets are pre-allocated by the
driver to be a max packet size, so when you send small packets, it
wastes a lot of memory. Currently Linux uses the packets at the
beginning of
David S. Miller wrote:
From: Ben Greear [EMAIL PROTECTED]
Date: Thu, 01 Sep 2005 23:11:28 -0700
A quick optimization is to kmalloc chunks of 1000 or so structs at once
and then write a cheap foomalloc method to grab and release them. We
already take a lock (at least in my implementation), so
David S. Miller wrote:
From: Ben Greear [EMAIL PROTECTED]
All the list stuff gets compiled out unless we're debugging.
So this netdev_pointer degenerates into a fancy pointer.
We can use a struct list_head to avoid the unlink complexity.
Ok, glad to see it can be compiled away as needed.
On Fri, 2005-02-09 at 02:42 +0200, Patrick McHardy wrote:
Ben Greear wrote:
At about line 132 of mirred.c, there is this code:
if (parm-ifindex) {
p-ifindex = parm-ifindex;
if (ret != ACT_P_CREATED)
*** It appears that this check could allow over-writing of
Hello!
+ tp-lost_out -= diff;
+ if ((int)tp-lost_out 0)
+ tp-lost_out = 0;
These checks aren't necessary.
Are you sure this can't happen if the MSS changes?
Anyway, I think this cannot be correct.
On Fri, 02.09.05 11:40, Jiri Benc ([EMAIL PROTECTED]) wrote:
On Thu, 1 Sep 2005 10:04:22 -0700, Stephen Hemminger wrote:
By the way, last time I looked at the ifplugd source it was using
outdated and incorrect ways to detect carrier. It should just
open a netlink socket and wait for
On Fri, 2 Sep 2005, Guillaume Autran wrote:
I experienced the very same problem but with window size going all the way
down to just a few bytes (14 bytes). dump files available upon requests :)
Ion, how were you able to reproduce the issue ? Can the same type of traffice
always reproduce the
Hello!
If you overflow the socket's memory bound, it ends up calling
tcp_clamp_window(). (I'm not sure this is really the right thing to do
here before trying to collapse the queue.)
Collapsing is too expensive procedure, it is rather an emergency measure.
So, tcp collapses queue, when it
Hello!
I experienced the very same problem but with window size going all the
way down to just a few bytes (14 bytes). dump files available upon
requests :)
I do request.
TCP is not allowed to reduce window to a value less than 2*MSS no matter
how hard network device or peer try to confuse
On Sep 2, 2005, at 10:05 AM, [EMAIL PROTECTED] wrote:
This particular Win2k sender sends _only_ real-time data, it's not
capable of rewinding. So it's always sending small packets, from start
to finish, yet the problem still occurs.
Note that even real-time data can end up generating a
On Sep 2, 2005, at 9:52 AM, Alexey Kuznetsov wrote:
Hello!
I experienced the very same problem but with window size going all the
way down to just a few bytes (14 bytes). dump files available upon
requests :)
I do request.
TCP is not allowed to reduce window to a value less than 2*MSS no
On Sep 2, 2005, at 9:48 AM, Alexey Kuznetsov wrote:
Hello!
If you overflow the socket's memory bound, it ends up calling
tcp_clamp_window(). (I'm not sure this is really the right thing to
do
here before trying to collapse the queue.)
Collapsing is too expensive procedure, it is rather
On Sep 2, 2005, at 10:33 AM, [EMAIL PROTECTED] wrote:
On Fri, 2 Sep 2005, John Heffner wrote:
Have you tried increasing the size of the receive buffer yet?
Actually, I just did. I changed rmem_max and rmem_default to 4MB and
tcp_rmem to 64k 4MB 4MB. It did seem to help, but I'm wondering
After some sleep, I have an idea:
Is there any reason we couldn't create a method:
void dev_hold_ref(struct dbg_dev_rfcnt_info* i, netdevice* dev, void* key);
This would be virtual identical to the __debug_dev_hold(netdevice* dev, void*
key)
that I currently have, but it would use the
Lennart Poettering wrote :
It is simply not true that all current
network drivers set IFF_RUNNING correctly. ifplugd does the best it
can to detect the carrier, but is still incompatible out of the box
with some drivers. To write carrier detection code that works reliably
on most drivers
Hi Jeff,
This adds support for WE-17 to the atmel_cs driver. Not
tested, I don't have the HW.
Regards,
Jean
Signed-off-by: Jean Tourrilhes [EMAIL PROTECTED]
diff -u -p linux/drivers/net/wireless/atmel.18.c
linux/drivers/net/wireless/atmel.c
---
Hi Jeff,
wl3501_cs won't compile with WE-19. This patches fixes it.
Regards,
Jean
Signed-off-by: Jean Tourrilhes [EMAIL PROTECTED]
Acked-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
diff -u -p linux/drivers/net/wireless/wl3501.18.h
Hi Jeff,
My patch that adds WE-17 support to the Prism54 driver went
already in the kernel, except for a tiny bit that was dropped on the
way. This is the missing bit
Tested with 2.6.13 (with real HW).
Regards,
Jean
Signed-off-by: Jean Tourrilhes
The mv643xx chips support per port bandwith limits. This patch
disables the bandwidth limits by clearing the MTU register.
Signed-off-by: Dale Farnsworth [EMAIL PROTECTED]
Index: linux-2.6.13-mm1-mv643xx-enet/drivers/net/mv643xx_eth.c
Add support for the netpoll api for use by netconsole, kgdb, etc.
Signed-off-by: Dale Farnsworth [EMAIL PROTECTED]
Index: linux-2.6.13-mm1-mv643xx-enet/drivers/net/mv643xx_eth.c
===
---
From: Ben Greear [EMAIL PROTECTED]
Date: Fri, 02 Sep 2005 13:53:58 -0700
I'm trying to write some code to walk all of the places where
routes might exist and find any that reference a particular
net-device.
Man, good luck. The IPSEC destination cache entries live in
chains only obtainable
From: Ben Greear [EMAIL PROTECTED]
Date: Fri, 02 Sep 2005 09:35:59 -0700
Is there any reason we couldn't create a method:
void dev_hold_ref(struct dbg_dev_rfcnt_info* i, netdevice* dev, void* key);
Please strongly consider my netdev_pointer idea,
and drop this dynamically allocated
David S. Miller wrote:
From: Ben Greear [EMAIL PROTECTED]
Date: Fri, 02 Sep 2005 13:53:58 -0700
I'm trying to write some code to walk all of the places where
routes might exist and find any that reference a particular
net-device.
Man, good luck. The IPSEC destination cache entries live in
(Full bug record. All replies will go into bugzilla - please trim text)
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=5175
Summary: Kernel 2.6.13 breaks libpcap (at least on ppp)
Kernel Version: 2.6.13
Status: NEW
Severity:
link changes reporting does not work when the driver masks its irq event
Signed-off-by: Arnaud Patard [EMAIL PROTECTED]
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
diff -puN a/drivers/net/sis190.c~sis190-170 b/drivers/net/sis190.c
--- a/drivers/net/sis190.c~sis190-170 2005-09-02
The sis191 is the gigabit brother of the sis190. SiS's driver suggests
that the register set is backward compatible: this should hopefully
give a basic driver.
The device should allow the usual features from a modern ethernet
adapter (802.1q, SG, Jumbo frames, TSO, checksum offload). So far
the
Extracted from SiS's GPLed driver. From the few pdf available at SiS's,
it seems that the 965 and the 966 south bridge include this interface
whereas the 965L (and anything below) does not. It is expected to be a
sis191 related feature and should not hurt the existing sis190 driver.
David S. Miller wrote:
It is better to implement this via backpointers in the
debugging information, perhaps.
This appears to be the neighbour struct that holds the leaked
reference:
Sep 2 16:11:27 sb65g2 kernel: Leaked neighbor structure:
Sep 2 16:11:27 sb65g2 kernel: next:
Hello!
The server socket sockopt are all default, except for the
TCP_WINDOW_CLAMP which is set to 1400 (application specific).
It is definitely not all. If you do not fiddle with SO_RCVBUF also,
you will always have receiver advertising window of 1400.
11:15:00.922119 IP 10.10.10.3.1150
This patch does three things:
- widen the access to the StationControl register (note the SIS_W16
versus SIS_W32 change);
- default to 10Mbps half duplex when the LPA can not be evaluated
(reg31-ctl is identical for both). It can be argued that it makes
sense as the lowest common denominator
Every file should #include the header files containing the prototypes of
it's global functions.
common.h contains the prototype for vcc_ioctl().
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
--- linux-2.6.13-mm1-full/net/atm/ioctl.c.old 2005-09-02 23:01:46.0
+0200
+++
On Fri, 2 Sep 2005, John Heffner wrote:
If it is window clamping, then you should be asymptotically approaching a
ratio between receive buffer and window that corresponds (with a fudge
factor) to the ratio between TCP segment data size and allocated packet size.
If you make the receive buffer
Hello!
This is where things start going bad. The window starts shrinking from
15340 all the way down to 2355 over the course of 0.3 seconds. Notice the
many duplicate acks that serve no purpose
These are not duplicate, TCP_NODELAY sender just starts flooding
tiny segments, and those are
Hello!
Well, take a look at the double acks for 84439343, 84440447 and 84441059,
they seem pretty much identical to me.
It is just a little tcpdump glitch.
19:34:54.532271 10.2.20.246.33060 65.171.224.182.8700: . 44:44(0) ack
84439343 win 24544 nop,nop,timestamp 226080638 99717832 (DF)
John McGowan [EMAIL PROTECTED] wrote:
Kernel 2.6.13. Breaks libpcap.
Fedora Core 2, gcc 3.3.3, Pentium III (933MHz)
I had written about my dismay that traceproto and tcptraceroute
no longer worked and suspected that libnet was broken.
It seems that it is libpcap that is broken by
Every file should #include the header files containing the prototypes of
it's global functions.
nfs_fs.h contains the prototype of root_nfs_parse_addr().
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
--- linux-2.6.13-mm1-full/net/ipv4/ipconfig.c.old 2005-09-03
02:18:06.0 +0200
This patch makes needlessly global functions static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
net/netfilter/nfnetlink.c |4 ++--
net/netfilter/nfnetlink_queue.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
---
Every file should #include the header files containing the prototypes of
it's global functions.
In this case this showed that the prototype of irlan_print_filter() was
wrong which is also corrected in this patch.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
On Fri, Sep 02, 2005 at 10:34:03AM -0700, Jean Tourrilhes wrote:
Another part of the problem is that the notion of carrier
detection only apply to some technology (mostly Ethernet). With
Wireless, there is no notion of carrier. You can somewhat *emulate* it
using the association, but
Minor SerDes bug fixes for 5780S and nvram bug fixes for 5780 and
5752.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff -urp a/drivers/net/tg3.c b/drivers/net/tg3.c
--- a/drivers/net/tg3.c 2005-09-02 14:42:39.0 -0700
+++ b/drivers/net/tg3.c 2005-09-02 14:47:31.0 -0700
@@
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff -urp b/drivers/net/tg3.c c/drivers/net/tg3.c
--- b/drivers/net/tg3.c 2005-09-02 14:47:31.0 -0700
+++ c/drivers/net/tg3.c 2005-09-02 14:49:47.0 -0700
@@ -7559,6 +7559,38 @@ static void tg3_get_strings (struct net_
}
}
Remove unnecessary status block accesses in tg3_msi(). Since MSI is
not shared, it is unnecessary to read the status block to determine if
there are any new events in the MSI handler. It is also unnecessary to
clear the updated bit in the status block.
Since the poll list is per-cpu, tg3_poll()
Use the status tag to determine if there are new events in
tg3_interrupt_tagged(). We discussed about this a while ago with Grant
Grundler and DaveM. This scheme makes it unnecessary to clear the
updated bit in the status block when using tagged mode, and only
a simple comparison is needed to
Michael Chan wrote:
Minor SerDes bug fixes for 5780S and nvram bug fixes for 5780 and
5752.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
Patches 1-5 seem OK to me...
Jeff
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
Hello,
since I yesterday upgraded kernel on my box at home, it keeps dying in few
minutes due to deadlock in destroy_conntrack, acquiring ip_conntrack_lock which
was already acquired by ip_ct_refresh_acct. Box setup is quite simple: there
are no iptable rules, just ip_conntrack is loaded,
Quoting Pavel Roskin [EMAIL PROTECTED]:
Just to preempt possible objections ...
Remove entry for Intel PRO/Wireless 2011B.
It is not supported by this driver because it has no firmware in
flash. spectrum_cs is needed for this device.
As it turns out, there are two cards with
49 matches
Mail list logo
