On Sun, Apr 16, 2006 at 10:32:03PM -0700, David S. Miller wrote:
>
> Let me save you some time, later in the thread you'll find
> out that this whole thing is a dead end.
Thanks. I even read the message but managed to miss your conclusion :)
> So it nearly has to be a send side issue that can o
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sun, 16 Apr 2006 21:18:31 +1000
> Great eyes! Yes that bug seems to have been around forever. I'll
> look over the patch tomorrow as right now I'm still on west-coast
> time :)
Let me save you some time, later in the thread you'll find
out that this who
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Sun, 16 Apr 2006 17:16:31 +0200
> On Sunday 16 April 2006 14:56, Hisham Kotry wrote:
> > > Linux 2.0 did something like this, but that was removed for good
> > > reasons. Now TCP always clones skbs before sending it out.
> >
> > Do you remember what those
On Fri, 2006-04-14 at 09:33 -0700, Stephen Hemminger wrote:
> I meant get rid of CONFIG_IPW2200_DEBUG completely. Having the debug code
> isn't
> bad, and there is no reason not to have it always there.
There are lots of IPW_DEBUG_XXX in the driver, even in TX and RX paths.
It cause extra cycles
On 4/17/06, George P Nychis <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am using iproute2 to setup fowarding, adding routes like "ip route add
> 192.168.1.3 via 192.168.1.2"
>
> I was wondering where in the kernel I can insert probabilistic packet loss
> only for forwarded packets? So that for instan
On Fri, Apr 14, 2006 at 05:59:11PM -0400, Pavel Roskin wrote:
> The original code was doing arithmetics on a little-endian value.
John, please apply this to wireless-2.6 tree. This code is triggered at
least for the case where WPA is not used. I had noticed it before, but I
think I've only tested
Ulrich Kunitz wrote:
I just wanted to say, I agree with the approach, but wonder how
transmission timeouts come into play here, which should lead to a
decrease of the tranmission rate.
That's a separate issue, to do with rate management, which I'm not
tackling yet. Note that the functions in
On Mon, 17 Apr 2006, Ulrich Kunitz wrote:
Oops! Sorry, but sometime ^X and ^C are to near to each other.
I just wanted to say, I agree with the approach, but wonder how
transmission timeouts come into play here, which should lead to a
decrease of the tranmission rate.
Daniel the patches on bran
On Mon, 17 Apr 2006, Daniel Drake wrote:
> While developing the ZD1211 driver we realised how much we'd like to be
> advised from the upper layers which rate to transmit a packet at.
>
> An example: We have a frame to transmit. What rate should we transmit it at?
> While taking any user-specified
While developing the ZD1211 driver we realised how much we'd like to be
advised from the upper layers which rate to transmit a packet at.
An example: We have a frame to transmit. What rate should we transmit it
at? While taking any user-specified rate into account too, we want to
transmit it a
> How much long was the card under load ? A few seconds ?
> The same 1500 bytes mtu is used everywhere and the issue can not be
> reproduced with a simple ping -f -q -l 64 -s what_you_want aimed at
> the 8169, right ?
Correct,
> > What next?
>
> ethtool -d/-S before and after failure, .confi
Hi,
I am using iproute2 to setup fowarding, adding routes like "ip route add
192.168.1.3 via 192.168.1.2"
I was wondering where in the kernel I can insert probabilistic packet loss only
for forwarded packets? So that for instance I can drop 5% of all forwarded
packets?
I don't need help with
Thomas A. Oehser <[EMAIL PROTECTED]> :
[...]
> > I'll welcome a complete dmesg after you have recovered through
> > ifconfig down/up though.
>
> _Nothing_ on dmesg.
Huh... Nothing appears when you issue 'dmesg' ?
[...]
> eth1 Link encap:Ethernet HWaddr 00:E0:4C:13:A9:56
> inet
On Sun, 2006-04-16 at 19:37 +0100, Alan Cox wrote:
> On Sul, 2006-04-16 at 19:46 +0200, Arjan van de Ven wrote:
> > > Personally, I don't see what this patch buy us...
> >
> > all the unused exports in the kernel together make a binary kernel 100Kb
> > bigger. It's a case of a lot of little step
On Sul, 2006-04-16 at 19:46 +0200, Arjan van de Ven wrote:
> > Personally, I don't see what this patch buy us...
>
> all the unused exports in the kernel together make a binary kernel 100Kb
> bigger. It's a case of a lot of little steps I suppose (each export
> taking like 100 to 150 bytes dep
> Personally, I don't see what this patch buy us...
all the unused exports in the kernel together make a binary kernel 100Kb
bigger. It's a case of a lot of little steps I suppose (each export
taking like 100 to 150 bytes depending on the size of the function name)
-
To unsubscribe from th
Willy TARREAU wrote:
Recent patch cb764326dff0ee51aca0d450e1a292de65661055 introduced
a thinko in e1000_main.c : e1000_media_type_copper is compared
to hw.phy_type instead of hw.media_type. Original patch proposed
by Jesse Brandeburg was correct, but what has been merged is not.
Indeed this see
> I'll welcome a complete dmesg after you have recovered through
> ifconfig down/up though.
_Nothing_ on dmesg.
> No problem. One more question: have you enabled NAPI ? If not, you
> should.
Doesn't seem to make a difference. Here, with it on, after failing it:
--- 192.168.99.100 ping stati
On Sun, 16 Apr 2006, Johannes Berg wrote:
> > - If the flag IW_FREQ_FIXED is set, should all activitity
> > including scanning only be allowed on this frequency? (Actually
> > a better would even be to work with channel/frequency sets.
> > These sets would make a lot of sense for parallel sc
On Sunday 16 April 2006 14:56, Hisham Kotry wrote:
> > Where would that tag list be stored if you want to remove the
> > 40 bytes of ->cb?
>
> I apologize if I wasn't clear, the tag list would go in a new
> skb->tags field replacing the existsing skb->cb array, so the skb
> would lose 40-sizeof(voi
Thomas A. Oehser <[EMAIL PROTECTED]> :
[...]
> I tested with everything turned off (no SMP, no swap, no
> USB, no firewire, no iptables, no lmsensors, flat 1G memory,
> etc. etc. etc.) except the bare minimum (LSI new Megaraid for the
> SCSI and SATA raid arrays, both of which use the same driver,
> Which motherboard and filesystem do you use ?
It's an MSI using EXT3.
> Can you send before and after the ping takes 9000 ms:
> - ifconfig output
> - registers dump via ethtool
>
> 9000ms seems quite close to the watchdog timeout (6 s) + ping
> interval. Complete dmesg and .config will be we
> Where would that tag list be stored if you want to remove the
> 40 bytes of ->cb?
I apologize if I wasn't clear, the tag list would go in a new
skb->tags field replacing the existsing skb->cb array, so the skb
would lose 40-sizeof(void*) bytes wich seems reasonable to me.
> Linux 2.0 did someth
[breaking out to a new thread so discussion on this doesn't get too
hidden, CC Jean since he designed this]
> - Is SIOCSIWFREQ allowed while associated?
No idea.
> - If the flag IW_FREQ_FIXED is set, should all activitity
> including scanning only be allowed on this frequency? (Actually
> a
On Sat, Apr 15, 2006 at 09:22:01PM +0200, Andi Kleen wrote:
> And optimizing for uncommon cases (not TCP) doesn't seem too useful.
There are servers that do tens of megabits of UDP these days (think VoIP, or
in my case, DNS), so it not that uncommon.
Bert
--
http://www.PowerDNS.com
Hi,
I'm just reviewing the zd1211 code and I'm wondering about the
semantics of SIOCSIWFREQ and actually, what is good for. It looks
like that softmac's set_channel can be called at any time and will
ignore any settings of SIOCSIWFREQ even it is has been given the
flag IW_FREQ_FIXED.
Following q
Hi David:
I've been flying on and off for the last two days so I only saw this now.
On Fri, Apr 14, 2006 at 08:59:27PM -0700, David S. Miller wrote:
>
> Herbert, as you may have noticed we found some missing
> locking in sk_stream_rfree(). It could explain the
> "!sk_forward_alloc" BUG() we tho
27 matches
Mail list logo
