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 wi
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, bu
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 PROTE
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 deter
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() wi
Improve ethtool loopback self test by adding PHY loopback to the
existing MAC loopback test.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff -urp c/drivers/net/tg3.c d/drivers/net/tg3.c
--- c/drivers/net/tg3.c 2005-09-02 14:49:47.0 -0700
+++ d/drivers/net/tg3.c 2005-09-02 14:51:11.0
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_
}
}
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
@@ -59
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
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]>
---
include/net/irda/irlan_filte
Every file should #include the header files containing the prototypes of
it's global functions.
sctp.h contains the prototypes of sctp_sysctl_{,un}register().
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.13-mm1-full/net/sctp/sysctl.c.old 2005-09-03 02:29:54.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(-)
--- linux-2.6.13-mm1-full/net/netfilter/nfnetlink.c.
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
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 broke
Hi Alexey,
On Sat, 3 Sep 2005, Alexey Kuznetsov wrote:
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
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: tbl
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
Don't ask.
The patch is based on SiS's GPLed driver.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
diff -puN a/drivers/net/sis190.c~sis190-200 b/drivers/net/sis190.c
--- a/drivers/net/sis190.c~sis190-200 2005-09-02 23:27:58.126761637 +0200
+++ b/drivers/net/sis190.c 2005-09-02 23:27:5
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 re
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.
Signed-off-by:
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 23:27:
(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
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 i
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
+++ linux-2.6.13-
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 (DF) (ttl 64, id
60946)
19:34:54.532432
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 db
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 >
Hi Alexey,
On Fri, 2 Sep 2005, Alexey Kuznetsov wrote:
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 st
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 obtainabl
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
===
--- linux-2.6.13-mm1-mv643xx-enet.orig/drivers/ne
mv643xx_eth_get_config_reg() was reading the wrong register.
mv643xx_eth_set_config_reg() was or'ing instead of setting the
register. These functions are trivial and both are called only from
mv643xx_eth_set_rx_mode() when changing to/from promiscuous mode.
Remove both functions and do the operati
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
===
The server socket sockopt are all default, except for the
TCP_WINDOW_CLAMP which is set to 1400 (application specific).
Guillaume.
Alexey Kuznetsov wrote:
Hello!
Do you think this will also fix Ion's issue with small window size never
going back up ?
I was wrong even about this on
Hi Jeff,
Dan Williams already included most parts of my WE-19 patch for
the airo driver in the kernel. There was just a few bits he could not
do because WE-19 itself was not in the kernel. Those are the missing
bits.
Tested with 2.6.13 (with real HW).
Regards,
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 <[EMA
Hi Jeff,
This adds support for WE-17 to the ray_cs driver. Tested
with 2.6.13 (with real HW).
Regards,
Jean
Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]>
diff -u -p linux/drivers/net/wireless/ray_cs.18.h
linux/drivers/net/wireless/ray_cs.h
--- linux/drivers
Hi Jeff,
This adds support for WE-17 to the netwave_cs driver. Tested
with 2.6.13 (with real HW).
Regards,
Jean
Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]>
diff -u -p linux/drivers/net/wireless/netwave_cs.18.c
linux/drivers/net/wireless/netwave_cs.c
--- l
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
linux/drivers/net/wire
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 n
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
--- linux/drivers
On Fri, Sep 02, 2005 at 11:32:28AM -0700, jt wrote:
> Hi Jeff,
>
> This is version 19 of the Wireless Extensions.
Just forgot :
Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]>
I'm getting rusted, sorry...
Jean
-
To unsubscribe from this list: send the line
Hi Jeff,
This is version 19 of the Wireless Extensions. It was supposed
to be the fallback of the WPA API changes, but people seem quite happy
about it (especially Jouni), so the patch is rather small.
The patch has been fully tested with 2.6.13 and various
wireless drivers
FYI to all, ieee80211-wifi branch is now in the upstream kernel.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
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 drive
Hello!
> Do you think this will also fix Ion's issue with small window size never
> going back up ?
I was wrong even about this one. That bad case, which I rememebered,
is not triggered here. And even if packet lengths and windows were modified
to trigger it, the effect would not be so pathologi
This patch corrects the accounting of outstanding tx skbs. It fixes
a bug that causes "Error on Queue Full" messages seen since scatter-gather
was enabled by using the hardware tcp/udp checksum generator.
Signed-off-by: Dale Farnsworth <[EMAIL PROTECTED]>
Index: linux-2.6.13-mm1-mv643xx-enet/dri
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 rfcnt_i
Hi Alexey,
Do you think this will also fix Ion's issue with small window size never
going back up ?
Thanks
Guillaume.
Alexey Kuznetsov wrote:
Hello!
Here are the dumps...
I see. It has nothing to do with clamping. Indeed this is a very old bug.
Frankly speaking I even was aware
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!
> I wonder if clamping the window though is too harsh. Maybe just
> setting the rcv_ssthresh down is better?
It is too harsh. This was invented before we learned how to collapse
received data, that time tiny segments were fatal and clamping was
the last weapon against misbehaving connec
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
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 if
that's simply because it has a _lot_ of memory now t
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 an
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
m
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 stream
Hi David,
On Thu, 1 Sep 2005, David S. Miller wrote:
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. C
Hello, developers.
sock_sendfile() and generic_file_sendpage() were implemented
and presented in the attached patch.
Such methods allows to use sendfile() for any file descriptor <-> file
descriptor usage, especially usefull it is in the case socket -> file,
when there are no copy_from_user() case
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 confu
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 i
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 is
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
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 ca
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 issue or is it more intermittent ?
Best regar
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 all
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 carrier event. Instead it seems
> to muck around looking at MII, wirel
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
From: Ben Greear <[EMAIL PROTECTED]>
Date: Thu, 01 Sep 2005 23:55:53 -0700
> Ok, so each object that now has a net_device* dev pointer instead
> gets this netdev_pointer object. When a reference is taken,
> this netdev_pointer object is linked into the netdevice object
> in a list. This requires
67 matches
Mail list logo
