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 co
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
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: sen
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 / HTTP/1.1
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 Poplaws
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 c
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
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 c
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
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
> -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
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 b
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
> > > d
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 82311e12d4e4e006fba1688cb
> 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
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 packet
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 a
On Mon, 2006-11-06 at 21:01 +0100, Jiri Benc wrote:
> This definitely breaks AP mode. In the code, there is heavily (ab)used
> the fact that the master device is in fact an AP device. I tried to fix
> that but it was so difficult I gave up. It is needed to rewrite the
> whole RX path (and even tha
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 lin
O
> > > > But the spin is still there, just more complex..
> > > > In qdisc_restart() processing of NETDEV_TX_LOCKED causes:
> > > > spin_lock(dev->xmit_lock)
> > > >
> > > > q->requeue()
> > > > netif_schedule(dev);
> > > >
> > > > SOFTIRQ:
> > > > net_tx_action()
>
Jeff Garzik <[EMAIL PROTECTED]> :
[...]
> This warrants much more testing than pushing into 2.6.19-rc4 would give
> us, so I'm pulling it into #upstream.
>
> In the past, with 10/100 hubs or ancient Cisco switches, we really
> didn't want to reset the phy and restart autonegotiation, because tha
Spider net should be using netdev->irq to find irq not "dumpster diving"
off into the PCI device. This code breaks in -mm when class_device
is eliminated.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/drivers/net/spider_net.c 2006-11-06 13:11:48.0 -0800
+++ b/drivers/net/sp
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
> >
> > O
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: powerpc
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
[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 hap
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 S
> 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 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
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
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
inherentl
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 ieee802
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
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.
>
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 u
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 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
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 @@ vo
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 S
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/s
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 h
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 configuri
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 "
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 PROTEC
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.
Sign
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 t
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
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.
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 mat
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 gi
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 1
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...
> >
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));
> > +
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
--- linux-2.6.19-rc4-git10-/net/sched/sch_h
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: powerpc/drivers/net/gianfar.c
=
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 rea
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.
Ac
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 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 act
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));
> >
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
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 usi
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 oper
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 ge
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
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 overal
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 PC
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; ) {
unsi
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,
> whet
[ 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, as
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
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 wa
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 /proc/budd
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 ".ipv4.sixxs.
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 c
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 /proc/bu
> 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-b
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 agree.
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 +
drivers/net/ehea/eh
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 m
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 fro
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 based
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 [EMA
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 P
> 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 cas
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
John W. Linville wrote:
The following changes since commit ff584489917961599b9044584bb8ba6fd5d8f11b:
John W. Linville:
Merge branch 'upstream-fixes' into upstream
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream
C
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
--
89 matches
Mail list logo
