On Tuesday 21 February 2006 06:31, Stephen Hemminger wrote:
> Equivalent code is in 1.0-rc1 version just sent out to netdev.
1.0-rc1 still hangs here. Is there anything I should try or look at?
Wolfgang
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message t
Stephen Hemminger <[EMAIL PROTECTED]> wrote:
>On Tue, 21 Feb 2006 16:36:44 -0800
>Jay Vosburgh <[EMAIL PROTECTED]> wrote:
[...]
>> +if (dev->master->priv_flags & IFF_MASTER_8023AD &&
>> +skb->protocol == __constant_htons(ETH_P_SLOW))
>
>Don't use the __c
David S. Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Tue, 21 Feb 2006 17:10:59 -0800
Didn't Jesse say something about the 2.4 stack being "ok" wrt
growing the window beyond 32767 bytes? 2.4 has had lots of exposure
right? Isn't that something of an existence proof that the issue
Herbert Xu wrote:
> On Wed, Feb 22, 2006 at 07:36:00AM +1100, herbert wrote:
>
>>Good point. I had forgotten that we still haven't moved the bundles into
>>the flow cache yet.
>
>
> OK that was still broken for forwarded packets since we don't actually
> put the tos into the flow when we decode
From: Rick Jones <[EMAIL PROTECTED]>
Date: Tue, 21 Feb 2006 17:21:30 -0800
> My point (perhaps not as well expressed as the one on the top of my
> head :) was that if 2.4 is "OK" with extending the window beyond
> 32767 without adding additional semantics on those options, why
> should 2.6 need to
On Wed, Feb 22, 2006 at 07:36:00AM +1100, herbert wrote:
>
> Good point. I had forgotten that we still haven't moved the bundles into
> the flow cache yet.
OK that was still broken for forwarded packets since we don't actually
put the tos into the flow when we decode the packet for xfrm. So her
David S. Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Tue, 21 Feb 2006 17:10:59 -0800
Didn't Jesse say something about the 2.4 stack being "ok" wrt
growing the window beyond 32767 bytes? 2.4 has had lots of exposure
right? Isn't that something of an existence proof that the issue
From: Rick Jones <[EMAIL PROTECTED]>
Date: Tue, 21 Feb 2006 17:10:59 -0800
> Didn't Jesse say something about the 2.4 stack being "ok" wrt
> growing the window beyond 32767 bytes? 2.4 has had lots of exposure
> right? Isn't that something of an existence proof that the issue
> with older DOS TCP
David S. Miller wrote:
HP printers had a different TCP bug :-)
The workaround for that is enabled by setting tcp_retrans_collapse to
zero.
If you resegment the queue during retransmits the old printer TCP
stacks refuse to take the retransmitted data.
The 16-bit signed window bug exists in some
Some of the really old stacks were embedded devices (like printers).
Rick, can you see if old HP printers work right?
The default TCP window size for HP-UX has been 32768 since IIRC HP-UX 10.20 ca
1995 (if not earler) and I've not heard of anything tripping-up wrt other stacks
- in printers or
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 21 Feb 2006 16:51:21 -0800
> Some of the really old stacks were embedded devices (like printers).
> Rick, can you see if old HP printers work right?
HP printers had a different TCP bug :-)
The workaround for that is enabled by setting tcp_re
On Tue, 21 Feb 2006 16:36:44 -0800
Jay Vosburgh <[EMAIL PROTECTED]> wrote:
>
> Originally submitted by Kenzo Iwami; his original description is:
>
> The current bonding driver receives duplicate packets when broadcast/
> multicast packets are sent by other devices or packets are flooded by
On Tue, 21 Feb 2006 16:37:46 -0800 (PST)
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> From: Rick Jones <[EMAIL PROTECTED]>
> Date: Tue, 21 Feb 2006 15:48:57 -0800
>
> > I disagree as to whether it is "foolhardy" but regardless, they are
> > perfectly _legal_ whereas a TCP stack interpreting the
Ulrich Kunitz wrote:
On Mon, 20 Feb 2006, Larry Finger wrote:
802.11 B/G
Locale Valid Channels
Americas1 - 11
Japan 1 - 14
Israel 1 - 9
China 1 - 11
Rest of World 1 - 13
BTW
France10 - 13
Spain
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Tue, 21 Feb 2006 13:57:28 -0800
> On Tue, 2006-02-21 at 17:41 -0500, Jeff Mahoney wrote:
>
> > dmesg after modprobe tg3:
> > tg3.c:v3.49 (Feb 2, 2006)
> > ACPI: PCI Interrupt :0a:02.0[A] -> GSI 24 (level, low) -> IRQ 201
> > Uhhuh. NMI received f
From: Rick Jones <[EMAIL PROTECTED]>
Date: Tue, 21 Feb 2006 15:48:57 -0800
> I disagree as to whether it is "foolhardy" but regardless, they are
> perfectly _legal_ whereas a TCP stack interpreting the window field
> as a signed quantity is most certainly _illegal_. So the Linux
> stack as it beh
From: Suresh Bhogavilli <[EMAIL PROTECTED]>
Date: Tue, 21 Feb 2006 18:55:48 -0500
> [PATCH] Fix garbage collection of multipath route entries
>
> When garbage collecting route cache entries of multipath routes in
> rt_garbage_collect(), entries were deleted from the hash bucket 'i'
> while holdin
Originally submitted by Kenzo Iwami; his original description is:
The current bonding driver receives duplicate packets when broadcast/
multicast packets are sent by other devices or packets are flooded by the
switch. In this patch, new flags are added in priv_flags of net_device
structur
On Mon, 20 Feb 2006, Larry Finger wrote:
> 802.11 B/G
>
> Locale Valid Channels
>
> Americas1 - 11
> Japan 1 - 14
> Israel 1 - 9
> China 1 - 11
> Rest of World 1 - 13
BTW
France10 - 13
Spain
Sorry. I am Outlook challenged.
This new mailer works for me. I hope it works for you.
[PATCH] Fix garbage collection of multipath route entries
When garbage collecting route cache entries of multipath routes in
rt_garbage_collect(), entries were deleted from the hash bucket 'i'
while holding
David S. Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Tue, 21 Feb 2006 15:11:52 -0800
Window scaling on is certainly goodness, but it seems that
ass-u-me-ing that !winscale == signed windows is overly
conservative.
I think we are making the correct conservative choice here.
I
(owner of http://bugzilla.kernel.org/show_bug.cgi?id=5681 Cc:ed)
Nikolaus Filus <[EMAIL PROTECTED]> :
[...]
> I'm using linux 2.6.14.3 with swsusp2 2.2rc14 (not the most new ones).
> Since I'm using NetworkManager, which switches and manages my wired and
> wireless devices, I have to reload 8139t
On Tue, 2006-02-21 at 17:41 -0500, Jeff Mahoney wrote:
>
> dmesg after modprobe tg3:
> tg3.c:v3.49 (Feb 2, 2006)
> ACPI: PCI Interrupt :0a:02.0[A] -> GSI 24 (level, low) -> IRQ 201
> Uhhuh. NMI received for unknown reason 21 on CPU 0.
> Dazed and confused, but trying to continue
> Do you have
From: Rick Jones <[EMAIL PROTECTED]>
Date: Tue, 21 Feb 2006 15:11:52 -0800
> Window scaling on is certainly goodness, but it seems that
> ass-u-me-ing that !winscale == signed windows is overly
> conservative.
I think we are making the correct conservative choice here.
Stacks that don't advertis
David S. Miller wrote:
From: Jesse Brandeburg <[EMAIL PROTECTED]>
Date: Tue, 21 Feb 2006 13:55:49 -0800 (Pacific Standard Time)
In this configuration, with e100, e1000, and others, I see the window size
grow to 32767 and stop.
Without window scaling enabled, this is the largest window we ca
On Tue, Feb 21, 2006 at 11:43:08PM +0100, Beschorner Daniel wrote:
> > [IPSEC] Use TOS when doing tunnel lookups
> >
> > We should use the TOS because it's one of the routing keys. It also
> > means that we update the correct routing cache entry when PMTU occurs.
>
> > Signed-off-by: Herbert Xu
> [IPSEC] Use TOS when doing tunnel lookups
>
> We should use the TOS because it's one of the routing keys. It also
> means that we update the correct routing cache entry when PMTU occurs.
> Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
> Daniel, please let me know if this patch fixes it or not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David S. Miller wrote:
> From: "Michael Chan" <[EMAIL PROTECTED]>
> Date: Tue, 21 Feb 2006 08:44:20 -0800
>
>> On Mon, 2006-02-20 at 14:43 -0500, Jeff Mahoney wrote:
>>> This patch moves the netif_carrier_off() call from tg3_init_one()->
>>> tg3_ini
On Tuesday 21 February 2006 01:40, Carl-Daniel Hailfinger wrote:
> Ian Kumlien schrieb:
> > On Sun, 2006-02-19 at 14:20 +0100, Wolfgang Hoffmann wrote:
> >>On Saturday 18 February 2006 18:00, Carl-Daniel Hailfinger wrote:
> >>>Hi,
> >>>
> >>>Stephen Hemminger schrieb:
> Could everyone who has p
Hi,
I'm using linux 2.6.14.3 with swsusp2 2.2rc14 (not the most new ones).
Since I'm using NetworkManager, which switches and manages my wired and
wireless devices, I have to reload 8139too after resume, before plugin
events of wired network are recognized. Some other users of NM are
reporting
From: Jesse Brandeburg <[EMAIL PROTECTED]>
Date: Tue, 21 Feb 2006 13:55:49 -0800 (Pacific Standard Time)
> In this configuration, with e100, e1000, and others, I see the window size
> grow to 32767 and stop.
Without window scaling enabled, this is the largest window we can
use in order to intero
I've run into what appears on the surface to be an issue with window
growth when window scaling is disabled.
I've turned off window scaling by
echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
echo 0 > /proc/sys/net/ipv4/tcp_adv_window_scale
In this configuration, with e100, e1000, and others, I
From: "Bhogavilli, Suresh" <[EMAIL PROTECTED]>
Date: Tue, 21 Feb 2006 11:38:06 -0500
> When garbage collecting route cache entries of multipath routes
> in rt_garbage_collect(), entries were deleted from the hash bucket
> 'i' while holding a spin lock on bucket 'k' resulting in a system
> hang. D
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Tue, 21 Feb 2006 08:44:20 -0800
> On Mon, 2006-02-20 at 14:43 -0500, Jeff Mahoney wrote:
> > This patch moves the netif_carrier_off() call from tg3_init_one()->
> > tg3_init_link_config() to tg3_open() as is the convention for most
> > other networ
Add missing netif_running() checks in tg3's dev->set_multicast_list()
and dev->set_mac_address(). If not netif_running(), these 2 calls can
simply return 0 after storing the new settings if required.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3
Fix-up tg3_get_ringparam() to return the correct parameters.
Set the jumbo rx ring parameter only if it is supported by the chip
and currently in use.
Add missing value for tx_max_pending, noticed by Rick Jones.
Update version to 3.51.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --gi
Using that driver version on kernel 2.6.14 does not have an issue. It
seems to have been introduced since 2.6.15 kernel.
Ayaz
-Original Message-
From: John W. Linville [mailto:[EMAIL PROTECTED]
Sent: Monday, February 20, 2006 2:34 PM
To: Jeff Garzik
Cc: Ayaz Abdulla; netdev@vger.kernel.
On Tuesday 21 February 2006 21:32, Christoph Hellwig wrote:
> On Tue, Feb 21, 2006 at 09:24:23PM +0100, Carlos Mart?n wrote:
> > Wouldn't this lead to duplicated function definitions at link time if both
are
> > compiled-in? From your module split above I understood you wanted
acx-common
> > to
Hello!
-
Please, even if nobody is interested in this patch or if it has no chance to get
into the kernel, tell me why!
-
I implemented a
On Tue, Feb 21, 2006 at 02:25:31PM +0100, Patrick McHardy wrote:
>
> I think you also need to add tos to the keys used in __xfrm4_find_bundle
> to avoid using a cached bundle with an incorrect tos value.
Good point. I had forgotten that we still haven't moved the bundles into
the flow cache yet.
On Tue, Feb 21, 2006 at 09:24:23PM +0100, Carlos Mart?n wrote:
> > acx-common-y+= wlan.o conv.o ioctl.o common.o
> > acx-pci-y += pci.o
> > acx-usb-y += usb.o
> >
> > obj-$(CONFIG_ACX_PCI) += acx-common.o acx-pci.o
> > obj-$(CONFIG_ACX_USB) += acx-co
On Tuesday 21 February 2006 20:26, Christoph Hellwig wrote:
> On Sat, Feb 18, 2006 at 11:35:21PM +0100, Carlos Martin wrote:
> > [PATCH] acxsm: Fix Kconfig option check
> >
> > This check never actually worked because CONFIG_ACX_{ACX,USB} are
> > tristate. With Adrian Bunk's patch to the Kconfig,
On Sat, Feb 18, 2006 at 11:35:21PM +0100, Carlos Martin wrote:
> [PATCH] acxsm: Fix Kconfig option check
>
> This check never actually worked because CONFIG_ACX_{ACX,USB} are
> tristate. With Adrian Bunk's patch to the Kconfig, this works with the
> _BOOL hidden Kconfig options.
> Also update erro
On Mon, 2006-02-20 at 14:43 -0500, Jeff Mahoney wrote:
> This patch moves the netif_carrier_off() call from tg3_init_one()->
> tg3_init_link_config() to tg3_open() as is the convention for most
> other network drivers.
I think moving netif_carrier_off() later is the right thing to do. We
can al
When garbage collecting route cache entries of multipath routes
in rt_garbage_collect(), entries were deleted from the hash bucket
'i' while holding a spin lock on bucket 'k' resulting in a system
hang. Delete entries, if any, from bucket 'k' instead.
Signed-off-by: Suresh Bhogavilli <[EMAIL PROT
Thanks to Herbert & Ilia (You mentioned your patch on the Openswan list, I
should have tried earlier)!
Results after a quick test: Ilia's patch works for me, Herbert's doesn't.
Daniel
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
On Tue, 2006-21-02 at 22:03 +1100, Herbert Xu wrote:
> On Tue, Feb 21, 2006 at 12:00:56PM +0100, Patrick McHardy wrote:
> >
> > With tunnel mode, yes, but with transport mode you can have one policy
> > for many peers. In that case you will have false positives as long as
> > a single peer is aliv
On Tuesday 21 February 2006 07:17, Denis Vlasenko wrote:
>
> allmodconfig for acx is:
>
> CONFIG_ACX=m
> CONFIG_ACX_PCI=y
> CONFIG_ACX_USB=y
>
> and it compiles for me just fine. Please send me your .config.
> Mine is attached.
My bad, sorry. I forgot to copy the Kconfig file over, so I was get
On Tue, 2006-21-02 at 13:17 +1100, Herbert Xu wrote:
> Michael Richardson <[EMAIL PROTECTED]> wrote:
> > I'll regenerate the patch? Who is the prime on this file?
>
> Send all networking patches to [EMAIL PROTECTED] with a cc to
> this list.
Michael,
The comments from Patrick are also valuable.
On Mon, 2006-20-02 at 15:05 -0800, David S. Miller wrote:
> From: jamal <[EMAIL PROTECTED]>
> Date: Mon, 20 Feb 2006 08:10:44 -0500
>
> > Explain the rules to me: is it because the alignment in xfrm_usersa_id
> > may change in the future?
>
> Alignment on x86 of u64 is different from x86_64 and i
Herbert Xu wrote:
> [IPSEC] Use TOS when doing tunnel lookups
>
> We should use the TOS because it's one of the routing keys. It also
> means that we update the correct routing cache entry when PMTU occurs.
>
> Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
>
> Cheers,
>
>
> --
On Tue, Feb 21, 2006 at 11:16:14PM +1100, herbert wrote:
>
> Here is a patch that you can try. It's not perfect since it may
> extend a single bucket to as many as 16 entries if someone tries
> to attack you with different TOS values. However, it should solve
> your specific issue.
Actually, he
On 2/21/06, Herbert Xu <[EMAIL PROTECTED]> wrote:
> Here is a patch that you can try. It's not perfect since it may
> extend a single bucket to as many as 16 entries if someone tries
> to attack you with different TOS values. However, it should solve
> your specific issue.
Not exactly - this sec
On Tue, Feb 21, 2006 at 12:53:28PM +0100, Beschorner Daniel wrote:
> Here is a log since the last ipsec start, do you need more?
> "koeln-os" is the affected connection, system seems ok.
Thanks. This and the packet dump confirms that it is the TOS bug
I mentioned earlier.
When we get an ICMP pay
On 2/20/06, Larry Finger <[EMAIL PROTECTED]> wrote:
> I am working with the softmac - bcm43xx project, and am trying to make the
> code conform to
> regulations imposed by the country of usage. From the various IEEE 802.11
> documents and various
> sources, I have deduced the following channel li
On Tue, Feb 21, 2006 at 12:00:56PM +0100, Patrick McHardy wrote:
>
> With tunnel mode, yes, but with transport mode you can have one policy
> for many peers. In that case you will have false positives as long as
> a single peer is alive.
That only happens with racoon I think :)
In any case, I do
Herbert Xu wrote:
> On Tue, Feb 21, 2006 at 11:39:05AM +0100, Patrick McHardy wrote:
>
>>The idle time expiration of policies is used for DPD, right? I wonder
>>why the SAs aren't used for this (also with idle time expiration),
>>unlike the policy they are directly related to a peer.
>
>
> For I
On Tue, Feb 21, 2006 at 11:39:05AM +0100, Patrick McHardy wrote:
>
> The idle time expiration of policies is used for DPD, right? I wonder
> why the SAs aren't used for this (also with idle time expiration),
> unlike the policy they are directly related to a peer.
For IKE IPsec usage there is usua
Herbert Xu wrote:
> Kristian Slavov <[EMAIL PROTECTED]> wrote:
>
>>I noticed that the SA's curlft->usetime is only updated once (time of the
>>first packet). Is this the intended behaviour, or should it be the time
>>the SA was last used? SPs, on the other hand, are constantly updated as
>>pack
Kristian Slavov <[EMAIL PROTECTED]> wrote:
>
> I noticed that the SA's curlft->usetime is only updated once (time of the
> first packet). Is this the intended behaviour, or should it be the time
> the SA was last used? SPs, on the other hand, are constantly updated as
> packets flow.
Yes this
Hi,
I noticed that the SA's curlft->usetime is only updated once (time of the
first packet). Is this the intended behaviour, or should it be the time
the SA was last used? SPs, on the other hand, are constantly updated as
packets flow.
Tested on 2.6.15.2.
BR,
--
Krisu
-
To unsubscribe from
61 matches
Mail list logo