Francois Romieu wrote:
Please pull from tag 'jg-20061103-00' in repository
git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git jg-20061103-00
to get the changes below.
Distance from 'upstream-fixes'
-
17fddc34b36fc26aa8b5f130fe32b446d9d88fa2
Diffstat
pulled.
still waiting on those changes to better modularize the feature
detection, etc.
-
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
This seems a bit ugly. Could you add
#define readq readq
to your platform instead?
That's ugly too imho but I suppose I can do it :-)
I generally think it's a bug in the kernel-wide API, if use of said API
requires arch-specific ifdefs.
Yes. I agree. In that specific case, I
Ayaz Abdulla wrote:
This patch adds support to recover from a previously fatal MAC error. In
the past the MAC would be hung on an internal fatal error. On new
chipsets, the MAC has the ability to enter a non-fatal state and allow
the driver to re-init it.
Signed-Off-By: Ayaz Abdulla [EMAIL
Ayaz Abdulla wrote:
This patch adds pci device ids for the NVIDIA MCP67 chip.
Signed-Off-By: Ayaz Abdulla [EMAIL PROTECTED]
ACK, but please rediff and resend against netdev-2.6.git#upstream
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
Maciej W. Rozycki wrote:
The PDQ DMA engine requires a different byte-swapping mode for big-endian
hosts; also the MAC address which is read from a register through PIO has
to be byte-swapped. These changes have been verified with DEFPA-DC (PCI)
boards and a Broadcom BCM91250A (MIPS CPU
Ayaz Abdulla wrote:
This patch adds support for the mgmt unit in certain chipsets. The MAC
and the mgmt unit share the PHY and therefore proper intialization
procedures are needed for them to maintain coexistense.
Signed-Off-By: Ayaz Abdulla [EMAIL PROTECTED]
applied
-
To unsubscribe from
Ayaz Abdulla wrote:
This patch adds support for the new mcp67 device into forcedeth.
Signed-Off-By: Ayaz Abdulla [EMAIL PROTECTED]
ACK, but please rediff and resend against latest netdev-2.6.git#upstream
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a
Benjamin Herrenschmidt wrote:
This seems a bit ugly. Could you add
#define readq readq
to your platform instead?
That's ugly too imho but I suppose I can do it :-)
I generally think it's a bug in the kernel-wide API, if use of said API
requires arch-specific ifdefs.
Yes. I
This is why I said good enough for drivers. This is _key_.
I have run into several [PCI] devices with 64-bit registers, and
__none__ of them had requirements such that the Linux platform code
-must- provide an atomic readq/writeq. Probably because everybody wants
to support 32-bit
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/Kconfig |4 ++--
drivers/net/ehea/ehea.h |5 +
2006/11/6, Eric Dumazet [EMAIL PROTECTED]:
We dont know. You might post some data so that we can have some ideas.
Also, these kind of question is better handled by linux netdev mailing list,
so I added a CC to this list.
cat /proc/slabinfo
cat /proc/meminfo
cat /proc/net/sockstat
cat
2006/11/6, Eric Dumazet [EMAIL PROTECTED]:
Slab: 293952 kB
So 292 MB used by slab for 2000 sessions.
Expect 600 MB used by slab for 4000 sessions.
So your precious LOWMEM is not gone at all. It *IS* used by SLAB.
You forgot to send
cat /proc/slabinfo
sorry I didn't make myself
The host testlab.linux-ipv6.org doesn't seem to be visible to the
outside world so could you post the results somewhere where I could take
a closer look at the results?
It is visible world-wide, assuming you have IPv6 connection.
With IPv4-only connection, one can try to append
Benjamin Herrenschmidt wrote:
This is why I said good enough for drivers. This is _key_.
I have run into several [PCI] devices with 64-bit registers, and
__none__ of them had requirements such that the Linux platform code
-must- provide an atomic readq/writeq. Probably because everybody
On Mon, 6 Nov 2006, Jeff Garzik wrote:
This seems a bit ugly. Could you add
#define readq readq
to your platform instead?
Heartily agreed. MUCH better than adding unrelated #if defined() stuff,
whether arch-related or otherwise.
Linus
-
To unsubscribe from this
[ reposted, with better subject ]
http://testlab.linux-ipv6.org/tahi-autorun.2/net-2.6_20061018/
The host testlab.linux-ipv6.org doesn't seem to be visible to the
outside world so could you post the results somewhere where I could take
a closer look at the results?
It is visible world-wide,
On Mon, 2006-11-06 at 01:37 -0800, Linus Torvalds wrote:
On Mon, 6 Nov 2006, Jeff Garzik wrote:
This seems a bit ugly. Could you add
#define readq readq
to your platform instead?
Heartily agreed. MUCH better than adding unrelated #if defined() stuff,
whether arch-related
On Mon, 6 Nov 2006, Benjamin Herrenschmidt wrote:
Anyway, what do you think of Jeff proposal to just implement them as two
32 bits operations ? My arch guy side screams at the idea, but if,
indeed, drivers generally cope fine with it, I suppose that's ok.
Last I saw, that's how normal PCI
On Mon, 2006-11-06 at 01:50 -0800, Linus Torvalds wrote:
On Mon, 6 Nov 2006, Benjamin Herrenschmidt wrote:
Anyway, what do you think of Jeff proposal to just implement them as two
32 bits operations ? My arch guy side screams at the idea, but if,
indeed, drivers generally cope fine with
Benjamin Herrenschmidt wrote:
On Mon, 2006-11-06 at 01:50 -0800, Linus Torvalds wrote:
On Mon, 6 Nov 2006, Benjamin Herrenschmidt wrote:
Anyway, what do you think of Jeff proposal to just implement them as two
32 bits operations ? My arch guy side screams at the idea, but if,
indeed, drivers
On Mon, 2006-11-06 at 04:55 -0500, Jeff Garzik wrote:
Benjamin Herrenschmidt wrote:
On Mon, 2006-11-06 at 01:50 -0800, Linus Torvalds wrote:
On Mon, 6 Nov 2006, Benjamin Herrenschmidt wrote:
Anyway, what do you think of Jeff proposal to just implement them as two
32 bits operations ? My
Hi,
Here is a patch which fixes some endianess problems. Patrick: since you
have both big little endian machines at your disposal, can you test to
ensure this is ok? Thanks,
Steve.
From ed3de950e89f8b02302308a2bedd59123ff3b88e Mon Sep 17 00:00:00 2001
From: Steven Whitehouse [EMAIL PROTECTED]
On Mon, Nov 06, 2006 at 10:32:43AM +, Al Viro wrote:
On Mon, Nov 06, 2006 at 10:31:02AM +, Steven Whitehouse wrote:
+ opt-opt_optl = dn_htons((__u16)*ptr++);
Lose that cast; it's only confusing the things...
+ memcpy(opt-opt_data, ptr, dn_ntohs(opt-opt_optl));
+
On Mon, Nov 06, 2006 at 10:31:02AM +, Steven Whitehouse wrote:
+ opt-opt_optl = dn_htons((__u16)*ptr++);
Lose that cast; it's only confusing the things...
+ memcpy(opt-opt_data, ptr, dn_ntohs(opt-opt_optl));
+ skb_pull(skb, dn_ntohs(opt-opt_optl) + 1);
... and I'd actually
On Monday 06 November 2006 09:59, Zhao Xiaoming wrote:
Thank you again for your help. To have more detailed statistic data, I
did another round of test and gathered some data. I give the overall
description here and detailed /proc/net/sockstat, /proc/meminfo,
/proc/slabinfo and
The Coverity checker noted the following in drivers/net/tg3.c:
-- snip --
...
static void __devinit tg3_read_partno(struct tg3 *tp)
{
unsigned char vpd_data[256];
int i;
...
/* Now parse and find the part number. */
for (i = 0; i 256; ) {
2006/11/6, Zhao Xiaoming [EMAIL PROTECTED]:
2006/11/6, Eric Dumazet [EMAIL PROTECTED]:
On Monday 06 November 2006 09:59, Zhao Xiaoming wrote:
Thank you again for your help. To have more detailed statistic data, I
did another round of test and gathered some data. I give the overall
2006/11/6, Arjan van de Ven [EMAIL PROTECTED]:
On Mon, 2006-11-06 at 14:07 +0800, Zhao Xiaoming wrote:
Dears,
I'm running a linux box with kernel version 2.6.16. The hardware
has 2 Woodcrest Xeon CPUs (2 cores each) and 4G RAM. The NIC cards is
Intel 82571 on PCI-e bus.
are you using a
2006/11/6, Eric Dumazet [EMAIL PROTECTED]:
On Monday 06 November 2006 09:59, Zhao Xiaoming wrote:
Thank you again for your help. To have more detailed statistic data, I
did another round of test and gathered some data. I give the overall
description here and detailed /proc/net/sockstat,
On Sat, 2006-11-04 at 13:29 -0600, Larry Finger wrote:
SoftMAC contains a number of debug-type messages that continue to print
even when debugging is turned off. This patch substitutes dprintkl for
printkl for those lines.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
Fine with me.
Hello,
Preferred source address selection in the routing table (src field)
currently does not work properly with multicast destination adresses:
it leads packets to be routed through the wrong network device (see
http://bugzilla.kernel.org/show_bug.cgi?id=7398).
It seems to me that the main
After hlist_del() next and pprev pointers are not NULL
so hlist_unhashed() doesn't work properly.
Signed-off-by: Jarek Poplawski [EMAIL PROTECTED]
---
diff -Nurp linux-2.6.19-rc4-git10-/net/sched/sch_htb.c
linux-2.6.19-rc4-git10/net/sched/sch_htb.c
---
Hi,
On Mon, 2006-11-06 at 10:32 +, Al Viro wrote:
On Mon, Nov 06, 2006 at 10:31:02AM +, Steven Whitehouse wrote:
+ opt-opt_optl = dn_htons((__u16)*ptr++);
Lose that cast; it's only confusing the things...
+ memcpy(opt-opt_data, ptr, dn_ntohs(opt-opt_optl));
+
Hi,
On Mon, 2006-11-06 at 10:34 +, Al Viro wrote:
On Mon, Nov 06, 2006 at 10:32:43AM +, Al Viro wrote:
On Mon, Nov 06, 2006 at 10:31:02AM +, Steven Whitehouse wrote:
+ opt-opt_optl = dn_htons((__u16)*ptr++);
Lose that cast; it's only confusing the things...
+
32 bit. Of course 64 bit kernel can help me overcome the 900M
barrier. However, if I can't find the reason why so much memory
getting 'lost', it will be difficult to support more heavy loadded
concurrent TCP connections.
2006/11/6, Arjan van de Ven [EMAIL PROTECTED]:
On Mon, 2006-11-06 at
On Monday 06 November 2006 10:46, Zhao Xiaoming wrote:
2006/11/6, Eric Dumazet [EMAIL PROTECTED]:
On Monday 06 November 2006 09:59, Zhao Xiaoming wrote:
Thank you again for your help. To have more detailed statistic data, I
did another round of test and gathered some data. I give the
jamal writes:
If you are listening then start with:
1) Do a simple test with just udp traffic as above, doing simple
accounting. This helps you to get a feel on how things work.
2) modify the matching rules to match your magic cookie
3) write a simple action invoked by your matching
Ben Greear writes:
Changes:
* use a nano-second timer based on the scheduler timer (TSC) for relative
times, instead of get_time_of_day.
Seems I missed to set tsc as clocksource. It makes a difference. Performance is
normal and I'm less confused.
e1000 82546GB @ 1.6 GHz Opteron.
Jeff Garzik wrote:
pulled.
still waiting on those changes to better modularize the feature
detection, etc.
that will start coming in early januari I think. We're currently validating all silicon
that the code supports against the old and new code, and that is going to take quite
some time
The Coverity checker noted that these if (err)'s couldn't ever be
true.
It seems the intention was to check the return values of the
bcm43xx_pci_write_config32()'s?
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/net/wireless/bcm43xx/bcm43xx_main.c |4 ++--
1 file changed, 2
This patch fixes a use-after-free for skb spotted by the Coverity
checker.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
--- linux-2.6/drivers/net/wireless/hostap/hostap_80211_rx.c.old 2006-11-06
14:51:36.0 +0100
+++ linux-2.6/drivers/net/wireless/hostap/hostap_80211_rx.c 2006-11-06
Adrian Bunk wrote:
The Coverity checker noted that these if (err)'s couldn't ever be
true.
It seems the intention was to check the return values of the
bcm43xx_pci_write_config32()'s?
Exactly. This patch sent to wireless-2.6.
Thanks,
Larry
-
To unsubscribe from this list: send the line
Eric Dumazet wrote:
Zhao Xiaoming a écrit :
Dears,
I'm running a linux box with kernel version 2.6.16. The hardware
has 2 Woodcrest Xeon CPUs (2 cores each) and 4G RAM. The NIC cards is
Intel 82571 on PCI-e bus.
The box is acting as ethernet bridge between 2 Gigabit Ethernets.
By
On Mon, 6 Nov 2006 12:33:53 +0100
Jarek Poplawski [EMAIL PROTECTED] wrote:
After hlist_del() next and pprev pointers are not NULL
so hlist_unhashed() doesn't work properly.
Signed-off-by: Jarek Poplawski [EMAIL PROTECTED]
---
diff -Nurp linux-2.6.19-rc4-git10-/net/sched/sch_htb.c
On Sun, 5 Nov 2006 21:11:34 +0100
Eric Lemoine [EMAIL PROTECTED] wrote:
On 11/5/06, Stephen Hemminger [EMAIL PROTECTED] wrote:
On Sun, 5 Nov 2006 18:52:45 +0100
Eric Lemoine [EMAIL PROTECTED] wrote:
On 11/5/06, Stephen Hemminger [EMAIL PROTECTED] wrote:
On Sun, 5 Nov 2006 18:28:33
On Sat, 4 Nov 2006 22:08:55 +0100
Willy Tarreau [EMAIL PROTECTED] wrote:
Hi Stephen,
I don't know if you received my mail since I got no reply.
Thanks in advance for your comments,
Willy
On Sat, Oct 28, 2006 at 10:57:07PM +0200, Willy Tarreau wrote:
Hi Stephen,
In my own
Hi all,
I managed to get a backtrace for the Invalid truesize bug. The trigger is
running LMbench2, but it's rater intermittent. Traffic should be going
over the loopback interface, but the main nic on the machine is e1000.
Let me know if anyone has any ideas for things to try.
On Mon, Nov 06, 2006 at 07:07:26PM +, Benjamin LaHaise wrote:
I managed to get a backtrace for the Invalid truesize bug. The trigger is
running LMbench2, but it's rater intermittent. Traffic should be going
over the loopback interface, but the main nic on the machine is e1000.
Let
On Sun, 05 Nov 2006 16:39:34 +0100, Johannes Berg wrote:
003-d80211-cookie.patch
d80211: change the cookie to be opaque
This changes the 'cookie' that d80211 returns from alloc_hw
to be an opaque value to the driver. Turned out that it wasn't
such a great idea but since it was
On Fri, 03 Nov 2006 11:48:22 +0800, Hong Liu wrote:
It seems we don't have any protection when accessing the key.
The RX/TX path may acquire a key which can be freed by the
ioctl cmd.
I put a key_lock spinlock to protect all the accesses to the key
(whether the sta_info-key or
The 64 bit io operation on the IA64 platform is a 64 bit transaction on
the pci bus and is optimal to leave it as such. I prefer Jeff's
suggestion -
guaranteeing that a good enough for drivers readq() and writeq() exist
on all platforms even 32-bit platforms where the operation isn't
inherently
On Mon, Nov 06, 2006 at 03:33:19PM -0500, Ramkrishna Vepa wrote:
The 64 bit io operation on the IA64 platform is a 64 bit transaction on
the pci bus and is optimal to leave it as such. I prefer Jeff's
suggestion -
guaranteeing that a good enough for drivers readq() and writeq() exist
on
On 11/6/06, Stephen Hemminger [EMAIL PROTECTED] wrote:
On Sun, 5 Nov 2006 21:11:34 +0100
Eric Lemoine [EMAIL PROTECTED] wrote:
On 11/5/06, Stephen Hemminger [EMAIL PROTECTED] wrote:
On Sun, 5 Nov 2006 18:52:45 +0100
Eric Lemoine [EMAIL PROTECTED] wrote:
On 11/5/06, Stephen Hemminger
For consistencies sake we really want to have readq() and writeq() available
on all platforms. I remember that some IB cards require it to actually
be a 64bit transactions, otherwise they have to do funny workarounds.
I think the best solution is to define ARCH_HAS_ATOMIC_READQ_WRITEQ
On Mon, 6 Nov 2006 21:55:20 +0100
Eric Lemoine [EMAIL PROTECTED] wrote:
On 11/6/06, Stephen Hemminger [EMAIL PROTECTED] wrote:
On Sun, 5 Nov 2006 21:11:34 +0100
Eric Lemoine [EMAIL PROTECTED] wrote:
On 11/5/06, Stephen Hemminger [EMAIL PROTECTED] wrote:
On Sun, 5 Nov 2006 18:52:45
On Mon, Nov 06, 2006 at 03:21:48PM +0100, Adrian Bunk wrote:
This patch fixes a use-after-free for skb spotted by the Coverity
checker.
--- linux-2.6/drivers/net/wireless/hostap/hostap_80211_rx.c.old
+++ linux-2.6/drivers/net/wireless/hostap/hostap_80211_rx.c
@@ -1004,10 +1004,10 @@ void
On Mon, 2006-11-06 at 10:45 +0100, Adrian Bunk wrote:
The Coverity checker noted the following in drivers/net/tg3.c:
-- snip --
The problem is that vpd_data[i + 2] could be vpd_data[255 + 2].
Thanks. This should fix it:
[TG3]: Fix array overrun in tg3_read_partno().
Use proper upper
From: Michael Buesch [EMAIL PROTECTED]
Drain the Microcode TX-status-FIFO before we enable IRQs.
This is required, because the FIFO may still have entries left
from a previous run. Those would immediately fire after enabling
IRQs and would lead to an oops in the DMA TXstatus handling code.
From: Adrian Bunk [EMAIL PROTECTED]
The Coverity checker noted that these if (err)'s couldn't ever be
true.
It seems the intention was to check the return values of the
bcm43xx_pci_write_config32()'s?
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Signed-off-by: Larry Finger [EMAIL PROTECTED]
On Monday 06 November 2006 16:48, Larry Finger wrote:
From: Adrian Bunk [EMAIL PROTECTED]
The Coverity checker noted that these if (err)'s couldn't ever be
true.
It seems the intention was to check the return values of the
bcm43xx_pci_write_config32()'s?
Whoops, I thought I had fixed
[reordering a bit]
This changes the 'cookie' that d80211 returns from alloc_hw
to be an opaque value to the driver. Turned out that it wasn't
such a great idea but since it was generally a clean up I kept
this patch to base my other patches on.
ACK.
What did happen with
On 11/6/06, Stephen Hemminger [EMAIL PROTECTED] wrote:
On Mon, 6 Nov 2006 21:55:20 +0100
Eric Lemoine [EMAIL PROTECTED] wrote:
On 11/6/06, Stephen Hemminger [EMAIL PROTECTED] wrote:
On Sun, 5 Nov 2006 21:11:34 +0100
Eric Lemoine [EMAIL PROTECTED] wrote:
On 11/5/06, Stephen Hemminger
On Mon, Nov 06, 2006 at 10:56:09AM -0800, Stephen Hemminger wrote:
On Sat, 4 Nov 2006 22:08:55 +0100
Willy Tarreau [EMAIL PROTECTED] wrote:
Hi Stephen,
I don't know if you received my mail since I got no reply.
Thanks in advance for your comments,
Willy
On Sat, Oct 28, 2006
On Nov 6, 2006, at 05:19, Vitaly Wool wrote:
The patch inlined below adds NET_POLL_CONTROLLER support for
gianfar network driver.
drivers/net/gianfar.c | 34 ++
1 file changed, 34 insertions(+)
Signed-off-by: Vitaly Wool [EMAIL PROTECTED]
Index:
Hello,
I was reading some tcpdump's of netdump traffic today, and I realized
that all of the packets that go from the crashing machine to the netdump server
have a zero checksum. Looking at the code, it looks like netconsole/netdump
use the function netpoll_send_udp to send out the
Generally the kernel code should write the two 32-bit chunks to the
memory-mapped region in order (low dword first), and let things take
care of themselves from there.
That's pretty much the implementation that -every- driver copies, when
they need readq/writeq to work on a 32-bit
From: Jeff Garzik [EMAIL PROTECTED]
Date: Mon, 06 Nov 2006 02:52:02 -0500
ACK from me, though I think that since it relates to traffic schedulers
I think this patch should be merged through DaveM...
I've merged it into my tree, thanks everyone.
-
To unsubscribe from this list: send the line
On Sun, Nov 05, 2006 at 12:22:37AM -0800, David Miller wrote:
Looks good to me.
So what's the right path to get this in? There's one patch touching
MM code, one adding something to the driver core and then finally a
networking patch depending on the previous two. Do you want to take
them all
This patch removes consideration of high memory when determining TCP hash
table sizes. Taking into account high memory results in tcp_mem values that
are too large.
Signed-off-by: John Heffner [EMAIL PROTECTED]
---
commit ea55b7c31b47edf90132baea9a088da3bbe2bb5c
tree
-Original Message-
From: Roland Dreier [mailto:[EMAIL PROTECTED]
Sent: Monday, November 06, 2006 12:55 PM
To: Christoph Hellwig
Cc: Ramkrishna Vepa; Benjamin Herrenschmidt; Jeff Garzik; Linus
Torvalds;
netdev@vger.kernel.org; [EMAIL PROTECTED]
Subject: Re: [PATCH] s2io ppc64 fix
On 11/6/06, Eric Dumazet [EMAIL PROTECTED] wrote:
On Monday 06 November 2006 10:46, Zhao Xiaoming wrote:
2006/11/6, Eric Dumazet [EMAIL PROTECTED]:
On Monday 06 November 2006 09:59, Zhao Xiaoming wrote:
Thank you again for your help. To have more detailed statistic data, I
did another
On 11/7/06, Stephen Hemminger [EMAIL PROTECTED] wrote:
Eric Dumazet wrote:
Zhao Xiaoming a écrit :
Dears,
I'm running a linux box with kernel version 2.6.16. The hardware
has 2 Woodcrest Xeon CPUs (2 cores each) and 4G RAM. The NIC cards is
Intel 82571 on PCI-e bus.
The box is acting
Zhao Xiaoming a écrit :
On 11/6/06, Eric Dumazet [EMAIL PROTECTED] wrote:
In fact, your kernel has CONFIG_4KSTACKS, kernel thread stacks use 4K
instead
of 8K.
If you want to increase LOWMEM, (and keep 32bits kernel), you can chose a
2G/2G user/kernel split, instead of the 3G/1G default split.
The latest update:
It seems that Linux kernel memory management mechanisms including
buddy and slab algorisms are not very efficient under my test
conditions that tcp stack requires a lot of (hundreds of MB) packet
buffers and release them very frequently.
Here is the proof. After change my
On 11/7/06, Eric Dumazet [EMAIL PROTECTED] wrote:
Zhao Xiaoming a écrit :
On 11/6/06, Eric Dumazet [EMAIL PROTECTED] wrote:
In fact, your kernel has CONFIG_4KSTACKS, kernel thread stacks use 4K
instead
of 8K.
If you want to increase LOWMEM, (and keep 32bits kernel), you can chose a
2G/2G
On Sun, Nov 05, 2006 at 12:53:23AM +0100, Christoph Hellwig wrote:
On Sat, Nov 04, 2006 at 06:06:48PM -0500, Dave Jones wrote:
On Sat, Nov 04, 2006 at 11:56:29PM +0100, Christoph Hellwig wrote:
This will break the compile for !NUMA if someone ends up doing a bisect
and lands here as a
I upgraded my notebook from 2.6.16 to 2.6.18 recently and noticed that
I couldn't talk to my VOIP device (which has a WEB interface).
Watching traffic I see the three-way-handshake working perfectly, and
then the first data packet is sent (a partial HTTP request:
GET / HTTP/1.1 ) and an ACK
On Mon, Nov 06, 2006 at 09:44:49AM -0800, Stephen Hemminger wrote:
On Mon, 6 Nov 2006 12:33:53 +0100
Jarek Poplawski [EMAIL PROTECTED] wrote:
After hlist_del() next and pprev pointers are not NULL
so hlist_unhashed() doesn't work properly.
Signed-off-by: Jarek Poplawski [EMAIL
Thanks very much for catching this John, patch applied.
Guess what? Nobody uses HASH_HIGHMEM after this change, and
frankly I can't think of any valid use of it besides perhaps
something such as a page cache hash table but that's irrelevant
since we use a per-object tree data structure for that
From: Chris Lalancette [EMAIL PROTECTED]
Date: Mon, 06 Nov 2006 18:40:59 -0500
Assuming that this is just an oversight, attached is a simple
patch to compute the UDP checksum in netpoll_send_udp.
If the resulting checksum is zero, you should set it to
all 1's, like the real UDP code
Neil Brown wrote:
I upgraded my notebook from 2.6.16 to 2.6.18 recently and noticed that
I couldn't talk to my VOIP device (which has a WEB interface).
Watching traffic I see the three-way-handshake working perfectly, and
then the first data packet is sent (a partial HTTP request:
GET /
Window scaling... there is some intermediate device which is
trying to prevent out of window segments from passing through,
but it is not taking the negotiated window scale into account.
So it thinks that segments are outside of the window, when they
are not.
-
To unsubscribe from this list: send
83 matches
Mail list logo
