Stefan Rompf wrote:
> the following patch should fix the problem. Patrick, can you give it a
> try? As the bug did not affect me through my testing, I want to be sure it
> works now. This is stuff for 2.6.18 and 2.6.17-stable.
I'm on my way out the door and will be gone for a couple of days,
so it
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Tue, 11 Jul 2006 21:53:42 -0700
> There is no reason to find out if ECN is enabled or not for any
> TCP connections. Hw just needs to watch the above bits in the
> incoming packets.
Correct, it can be done in a completely stateless manner.
-
To unsu
On Tue, 2006-07-11 at 07:15, Herbert Xu wrote:
> On Tue, Jul 11, 2006 at 03:57:31AM -0700, Andrew Morton wrote:
> >
> > > >> down_write(&listeners->sem);
> > > >> list_for_each_entry_safe(s, tmp, &listeners->list, list) {
> > > >> - ret = genlmsg_unicast(skb, s->pid);
> > >
Stephen Hemminger <[EMAIL PROTECTED]> wrote:
>
> Why not just use sscanf?
Better yet, use a better interface like netlink rather than module
parameters.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~
David Miller wrote:
> On receive? There is no reason for skb->sk to be anything other than
> NULL on receive, the networking stack hasn't even seen the packet yet.
> Only the driver has seen the skb.
>
>
Yeah, here's roughly how LRO should work for ECN:
If CE, ECE, or CWR is set on an incomi
On Wed, 12 Jul 2006 13:25:52 +0900
Tetsuo Takata <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
> I found this in drivers/net/bonding/bond_main.c.
> > /* not complete check, but should be good enough to
> > catch mistakes */
>
> I made a patch which I believe is little bit better than this,
> I hope.
On Tue, 2006-07-11 at 15:32 +0200, Pavel Machek wrote:
> Probably not. This (very dirty) hack implements that (with some level
> of success -- ifconfig down/ifconfig up is enough to get wireless
> working).
You just need to
$ iwpriv ethX reset
Thanks,
-yi
-
To unsubscribe from this list: send th
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 12 Jul 2006 14:30:00 +1000
> On Wed, Jul 12, 2006 at 03:17:43PM +1200, Ian McDonald wrote:
> >
> > I'm not saying the check is unneeded - just saying doing it twice is
> > unneeded.
>
> Right, got you this time.
>
> I don't think we need to worry
On Wed, Jul 12, 2006 at 03:17:43PM +1200, Ian McDonald wrote:
>
> I'm not saying the check is unneeded - just saying doing it twice is
> unneeded.
Right, got you this time.
I don't think we need to worry about people who use __sk_stream_mem_reclaim
when there is a perfectly good sk_stream_mem_re
Hi,
I found this in drivers/net/bonding/bond_main.c.
> /* not complete check, but should be good enough to
> catch mistakes */
I made a patch which I believe is little bit better than this,
I hope...
best regards,
---
Signed-off-by: Tetsuo Takata <[EMAIL PROTECTED]>
--- linux-2.6.17.3/dr
Andreas Kleen wrote:
If it helps I can do a proper patch that only bounces IO > 4GB through
the copy.
For the A8V series of boards, that will almost certainly be just fine,
because as far as I know you can't populate them with more than 4G of
memory anyway.
If someone has more than 4G of me
Dan Williams wrote:
NAK... remember, range->max_qual.level must be _0_ if you're in dBm,
I do not think this is right. From the comments in include/linux/wireless.h:
/* Quality of link & SNR stuff */
/* Quality range (link, level, noise)
* If the quality is absolute,
On 7/12/06, Herbert Xu <[EMAIL PROTECTED]> wrote:
Ian McDonald <[EMAIL PROTECTED]> wrote:
>
> It looks to me like this check here in net/core/stream.c for
> __sk_stream_mem_reclaim:
>if (sk->sk_forward_alloc >= SK_STREAM_MEM_QUANTUM) {
>
> is unnecessary.
It's needed after skb's have bee
Ian McDonald <[EMAIL PROTECTED]> wrote:
>
> It looks to me like this check here in net/core/stream.c for
> __sk_stream_mem_reclaim:
>if (sk->sk_forward_alloc >= SK_STREAM_MEM_QUANTUM) {
>
> is unnecessary.
It's needed after skb's have been freed which can push sk_forward_alloc
above a qu
Spamming bug robot dropped from cc list.
Am Mi 12.07.2006 04:46 schrieb Anthony DeRobertis <[EMAIL PROTECTED]>:
> OK, here are the results with iommu=force. All of these are copied
> down
> by hand, so please forgive any transcription errors:
You need to use iommu=soft swiotlb=force
The standa
OK, here are the results with iommu=force. All of these are copied down
by hand, so please forgive any transcription errors:
2.6.12[1]: Last line displayed on screen is "ata1: dev 0 ATA max
UDMA/133 390721968 sectors, lba48". Then it sits there. Scrolling with
shift-pgup/pgdown works. Control-Alt-
Folks,
It looks to me like this check here in net/core/stream.c for
__sk_stream_mem_reclaim:
if (sk->sk_forward_alloc >= SK_STREAM_MEM_QUANTUM) {
is unnecessary.
It is also done in include/net/sock.h for sk_stream_mem_reclaim which
if the test succeeds calls __sk_stream_mem_reclaim. Thi
From: "Ravinandan Arakali" <[EMAIL PROTECTED]>
Date: Tue, 11 Jul 2006 18:45:48 -0700
> tk = tcp_sk(skb->sk);
> if (tk->ecn_flags & TCP_ECN_OK)
>/* Check CE, ECE, CWR etc */
>
> I find that skb->sk is NULL. Is this the correct way to check the
> per-session
> ECN capability ? Why is skb->sk NU
Michael/David,
Thanks for the comments on LRO. The current LRO code in S2io driver is not
aware of ECN. While I was trying to fix this, the first thing I encountered
was to check, in the driver, if ECN is enabled for current session. To do
this, I try to get hold of the socket by doing something li
Pavel Machek wrote:
I'd actually like you to keep it, it does not seem ZyDas contacts are
going anywhere.
ZyDAS did not respond to me about this. At least we know more about the
problem now anyway :)
Daniel
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a
On Tue, 20 Jun 2006 10:50:13 -0400 jamal wrote:
>
> > > PS:- I dont have a good place to put this doc and point to, hence the
> > > 17K attachment
> > >
> >
> > http://www.kernel.org/pub/linux/kernel/people/hadi/ ?
> >
> > (unless your permissions have been revoked for lack of use ! :-)
> >
>
David Miller wrote:
From: Ben Greear <[EMAIL PROTECTED]>
Date: Tue, 11 Jul 2006 16:27:25 -0700
So, the question is: Should I be calling unregister_netdev from the
notifier callback?
Not really, as you saw it can be deadlock prone.
One idea is to run the unregister asynchronously via a work
From: Ben Greear <[EMAIL PROTECTED]>
Date: Tue, 11 Jul 2006 16:27:25 -0700
> So, the question is: Should I be calling unregister_netdev from the
> notifier callback?
Not really, as you saw it can be deadlock prone.
One idea is to run the unregister asynchronously via a workqueue.
That should be
Hello!
I'm working on stacking some virtual interfaces, and ran into a problem with
locking.
Basically, I have an ethernet-like device, and on top of that I am putting
802.1Q vlans..and on top of that, some other vlan (macvlan).
In the event notifier for the vlan, I attempt to delete all vlans
On Tue, Jul 11, 2006 at 04:22:17PM -0700, David Miller wrote:
>
> What ATM is doing here is charging the SKB to the virtual circuit
> sockets. At least in the few cases I've looked at just now, the
> skb is some private ATM level signalling message, and not part of
> a normal transmit/receive pac
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 12 Jul 2006 09:12:51 +1000
> On Tue, Jul 11, 2006 at 01:55:53PM -0700, David Miller wrote:
> >
> > I think it is possible cover a certain class of these situations
> > from within pskb_expand_head. For example, if skb->sk is NULL
> > we can prove t
john stultz <[EMAIL PROTECTED]> wrote:
> Both of these were seen on my laptop w/ the current (as of this writing)
> -git tree using the e1000 driver after a suspend/resume cycle.
It's just a reminder that we need to fix NAT to update checksums
incrementally. You'll only see it once per boot.
> B
On Tue, Jul 11, 2006 at 01:55:53PM -0700, David Miller wrote:
>
> I think it is possible cover a certain class of these situations
> from within pskb_expand_head. For example, if skb->sk is NULL
> we can prove that updating skb->truesize is safe since no
> socket's buffer accounting can possible
Both of these were seen on my laptop w/ the current (as of this writing)
-git tree using the e1000 driver after a suspend/resume cycle.
thanks
-john
BUG: warning at net/core/dev.c:1171/skb_checksum_help()
[] show_trace_log_lvl+0x149/0x170
[] show_trace+0x1b/0x20
[] dump_stack+0x24/0x30
[] skb
On Wednesday 12 July 2006 00:16, you wrote:
> Johann Uhrmann reported a bcm43xx crash and Michael Buesch tracked it down
> to a problem with the new shared key auth code (recursive calls into the
> driver)
>
> This patch (effectively Michael's patch with a couple of small modifications)
> solves
This happen to me with FC4 and 2.6.17-1.2141_FC4. I have eth0=e100,
eth1=8139too and wlan0=hostap_pci. When ACPI is enabled, all works. If
acpi=off it hangs for a minute (at stage: Bringing up interface eth1:
Determinig IP information for eth1...SIOCSIFFLAGS: Device of recource
busy) and then
Johann Uhrmann reported a bcm43xx crash and Michael Buesch tracked it down
to a problem with the new shared key auth code (recursive calls into the driver)
This patch (effectively Michael's patch with a couple of small modifications)
solves the problem by sending the authentication challenge respo
Am Dienstag, 11. Juli 2006 23:28 schrieb Stephen Hemminger:
> Untested, but here is the basic idea of how I think up/down should be
> handled. Basically, rather than changing the flags directly the VLAN code
> should call dev_open/dev_close. The notifier end's up recursively calling
> but this i
Ok,
the following patch should fix the problem. Patrick, can you give it a
try? As the bug did not affect me through my testing, I want to be sure it
works now. This is stuff for 2.6.18 and 2.6.17-stable.
Stefan
[VLAN]: Fix link state propagation
When the queue of the underlying device is stop
VLAN devices did not get registered as admin up in 2.6.16 and IMHO also
not in 2.6.17. So update patch description.
Ok,
the following patch should fix the problem. Patrick, can you give it a
try? As the bug did not affect me through my testing, I want to be sure it
works now. This is stuff for 2.
Le 11.07.2006 10:40, Arjan van de Ven a écrit :
>> Reversed (or previously applied) patch detected!
>>
>> Wrong patch ? This one won't apply, it seems to be already
>> applied to 2.6.18-rc1-mm1.
>
> ok these patches ought to fix this for real (sorry I don't have this
> hardware so I cannot actu
Hi Auke,
On Tuesday 11 July 2006 14:09, Auke Kok wrote:
>
> > that seems to address this problem by creating a
> >
> > tx_timeout_factor relative to the speed of the NIC. However, there is no
> > mention of this workaround/fix on the bug at the link above and I haven't
> > found any discussion o
On Tue, Jul 11, 2006 at 04:42:13PM +0200, Arjan van de Ven wrote:
> just load fakephp
Thanks! I'd never heard of it :-)
Joel
--
"The only way to get rid of a temptation is to yield to it."
- Oscar Wilde
Joel Becker
Principal Software Developer
Oracle
E-mail: [EMAIL PROTEC
Stephen Hemminger wrote:
Untested, but here is the basic idea of how I think up/down should be
handled. Basically, rather than changing the flags directly the VLAN code
should call dev_open/dev_close. The notifier end's up recursively calling
but this is okay.
--- vlan.orig/net/8021q/vlan.c
+
ipw2200 uses // comments, and uses them for removing unneeded
code. Clean it up a bit.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
diff --git a/drivers/net/wireless/ipw2200.c b/drivers/net/wireless/ipw2200.c
index b3300ff..758459e 100644
--- a/drivers/net/wireless/ipw2200.c
+++ b/drivers/net
On Mon 2006-07-10 23:05:06, Michael Buesch wrote:
> On Monday 10 July 2006 19:53, you wrote:
> > Pavel Machek wrote:
> > > Kconfig currently allows compiling IPW_2100 and IPW_2200 into kernel
> > > (not as a module). Unfortunately, such configuration does not work,
> > > because these drivers need
Untested, but here is the basic idea of how I think up/down should be
handled. Basically, rather than changing the flags directly the VLAN code
should call dev_open/dev_close. The notifier end's up recursively calling
but this is okay.
--- vlan.orig/net/8021q/vlan.c
+++ vlan/net/8021q/vlan.c
@@
Hi,
This patch converts generic HDLC (and WAN drivers using it) from
hdlc_set_carrier() to netif_dormant*() interface.
WAN hardware drivers should now use netif_carrier_on|off() like
other network drivers.
Please apply. Thanks.
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
diff --git a
[EMAIL PROTECTED] wrote:
I have an e1000 card periodically misbehaving with the message 'Detected Tx
unit hang'. I've noticed this problem come up on netdev a couple of times
and found the link to the bug tracking page--
http://sourceforge.net/tracker/index.php?func=detail&aid=1463045&group_i
Hi Str,
I came accross your info online and I wanted to know if you may be
interested in exploring some of the new opportunities we are working on. The
job market is back in full swing and we are working with a lot of interesting
companies.Specifically I was interested in the work you may
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Tue, 11 Jul 2006 21:45:44 +1000
> [IPCOMP]: Fix truesize after decompression
>
> The truesize check has uncovered the fact that we forgot to update truesize
> after pskb_expand_head. Unfortunately pskb_expand_head can't update it for
> us because it's u
Michael Buesch wrote:
Yes. We have a PROM that is readable without firmware.
(And we actually do this and did it forever. So I don't know
where your assumption comes from ;) )
It wasn't an assumption: I was stating something about the Intel cards.
It is not possible to determine the MAC addres
I apologize for the delay. Between the 2.6.18 merge window and things
heating up at the paying job, I've been a bit behind.
Along w/ pulling some updates from Jiri and some random bug fixes,
this includes the new d80211-based adm8211 driver from Michael Wu.
I'm sure he would love for anyone equip
On Tuesday 11 July 2006 13:53, you wrote:
> Michael Buesch wrote:
> > Does the ipw driver _really_ need the firmware on insmod time?
> > bcm43xx, for example, loads the firmware on "ifconfig up" time.
> > If ipw really needs the firmware on insmod, is it possible to
> > defer it to later at "ifconf
On Tue, 2006-07-11 at 11:04 -0500, Larry Finger wrote:
> This minor patch adjusts the parameters of the wireless statistics to improve
> the display of
> programs such as the "Wireless Network Information" applet of KDE.
>
> Signed-Off-By: Larry Finger <[EMAIL PROTECTED]>
>
> ==
Andrew> Sure. Although I am a little surprised to be be receiving
Andrew> them while Roland is in
Andrew> taking-time-off-but-not-really-doing-so mode.
Michael> Well, I don't know what's up either, but Roland acked
Michael> patches explicitly so I figured that's what he wants,
Hello All,
I have an e1000 card periodically misbehaving with the message 'Detected Tx
unit hang'. I've noticed this problem come up on netdev a couple of times
and found the link to the bug tracking page--
http://sourceforge.net/tracker/index.php?func=detail&aid=1463045&group_id=42302&atid=44
Herbert Xu wrote:
> On Tue, Jul 11, 2006 at 03:57:31AM -0700, Andrew Morton wrote:
>
> down_write(&listeners->sem);
> list_for_each_entry_safe(s, tmp, &listeners->list, list) {
>- ret = genlmsg_unicast(skb, s->pid);
>+ skb_next = NULL;
>+
This minor patch adjusts the parameters of the wireless statistics to improve the display of
programs such as the "Wireless Network Information" applet of KDE.
Signed-Off-By: Larry Finger <[EMAIL PROTECTED]>
==
diff --git a/drivers/
try latest -mm, latest ACPI patch, or
try CONFIG_ACPI_BATTERY=n
-Len
-
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
On Tue, 2006-07-11 at 13:27 +0200, Pavel Machek wrote:
> Hi!
>
> > > > >> Kconfig currently allows compiling IPW_2100 and IPW_2200 into kernel
> > > > >> (not as a module). Unfortunately, such configuration does not work,
> > > > >> because these drivers need a firmware, and it can't be loaded by
On Mon, 2006-07-10 at 13:56 -0700, Joel Becker wrote:
> On Mon, Jul 10, 2006 at 08:51:58PM +0200, Arjan van de Ven wrote:
> > > Besides, the initramfs runs long after the driver init routine
> > > runs which is when the firmware needs to be available.
> >
> > .. unless you use sysfs to do a fake h
Hi,
[snip]
> EIP: 0060:[] Tainted: P VLI
^^^
Just out of curiosity, what's tainting your kernel?
Hmm, no idea actually.
This trace came from a user who submitted a bugreport.
But I had a lot of traces for this bug, so I just selected one
to indicate what the probl
Ivo Van Doorn wrote:
[snip]
> EIP: 0060:[] Tainted: P VLI
^^^
Just out of curiosity, what's tainting your kernel?
-Alex
I code, therefore I am
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protectio
Andy Gay wrote:
Since 2.6.16 it's been necessary to add an ACCEPT rule for IPIP
(protocol 4) in the INPUT chain, otherwise IPsec tunnel mode packets get
dropped (if your INPUT policy is DROP).
I was wondering if that's the intended behavior.
No it isn't the desired behaviour. It is a know iss
Hi John,
This patch fixes a copy&paste error by correcting the name
for hardware button support in rt61pci.
Please apply to wireless-dev.
Thanks.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -uprN wireless-dev/drivers/net/wireless/d80211/rt2x00/Kconfig
wireless-dev-end/drivers/ne
Jay Vosburgh wrote:
Or Gerlitz <[EMAIL PROTECTED]> wrote:
What network device drivers are there that don't permit ever
changing the device MAC address?
I am thinking about what would it take to support active-backup/bonding
for IP over Infiniband (see Documentation/infiniband/ipoib.
Since 2.6.16 it's been necessary to add an ACCEPT rule for IPIP
(protocol 4) in the INPUT chain, otherwise IPsec tunnel mode packets get
dropped (if your INPUT policy is DROP).
I was wondering if that's the intended behavior. I did google around for
this, I found a few reports of the same thing bu
Jay Vosburgh wrote:
Or Gerlitz <[EMAIL PROTECTED]> wrote:
Looking on the linux bonding driver, it seems to unconditionally (*)
assume that the enslaved device supports the set_mac_address call.
From reading the doc (Documentation/networking/bonding.txt) i understand that
it is **not** a must p
On Tue, 2006-07-11 at 18:17 +1000, Herbert Xu wrote:
> On Fri, Jul 07, 2006 at 01:25:44PM -0500, Steve Wise wrote:
> >
> > Some IP networking is involved for this. IP addresses and port numbers
> > are used by the RDMA Connection Manager. The motivation for this was
> > two-fold, I think:
> >
>
On Wed, Jun 14, 2006 at 01:09:59PM +, Roar Bj?rgum Rotvik wrote:
>
> So I cannot make encrypted multicast traffic to flow both ways at the same
> time, and has no clue as to why the first packets after changing direction
> is dropped somewhere.
Sounds like conntrack. Check /proc/net/ip_con
On Mon, 10 Jul 2006 23:19:39 PDT, Andrew Morton said:
> > Any suggestions/hints (besides rebuilding the implicated .ko with debugging
> > symbols so oprofile can be more granular - that's already on the to-do
> > list)?
> >
>
> I'd suggest you whack sysrq-T 5-10 times when it happens, capture a
* Ralf Baechle <[EMAIL PROTECTED]> wrote:
> Bpqether is encapsulating AX.25 frames into ethernet frames. There is
> a virtual bpqether device paired with each ethernet devices, so it's
> normal to pass through dev_queue_xmit twice for each frame which
> triggers the locking detector.
>
> Sig
On Tue, Jul 11, 2006 at 12:32:45PM +0200, Marco Berizzi wrote:
> Running this on mimosa 'mitigates' the problem:
>
> ip addr add 172.29.128.1/28 dev eth2
>
> Connections are pretty slow but they aren't
> reseted anymore.
Hmm, I thought 172.29.128.1 was already a local address? What does
ip addr
Michael Buesch wrote:
Does the ipw driver _really_ need the firmware on insmod time?
bcm43xx, for example, loads the firmware on "ifconfig up" time.
If ipw really needs the firmware on insmod, is it possible to
defer it to later at "ifconfig up" time?
Is bcm43xx able to get the MAC address befo
On Thu, Jul 06, 2006 at 12:53:45PM +, Beschorner Daniel wrote:
> Does it harm?
>
> SKB BUG: Invalid truesize (380) len=1383, sizeof(sk_buff)=156
> SKB BUG: Invalid truesize (316) len=1383, sizeof(sk_buff)=156
> SKB BUG: Invalid truesize (348) len=1383, sizeof(sk_buff)=156
> SKB BUG: Invalid tr
Hi!
> > > >> Kconfig currently allows compiling IPW_2100 and IPW_2200 into kernel
> > > >> (not as a module). Unfortunately, such configuration does not work,
> > > >> because these drivers need a firmware, and it can't be loaded by
> > > >> userspace loader when userspace is not running.
> > > >
On Tue, Jul 11, 2006 at 11:31:33AM +0200, Marco Berizzi wrote:
>
> Me again. After a while here is:
>
> [EMAIL PROTECTED]:/tmp# ping 10.49.59.23
> PING 10.49.59.23 (10.49.59.23) 56(84) bytes of data.
>
> --- 10.49.59.23 ping statistics ---
> 4 packets transmitted, 0 received, 100% packet loss, t
On Tue, Jul 11, 2006 at 03:57:31AM -0700, Andrew Morton wrote:
>
> > >> down_write(&listeners->sem);
> > >> list_for_each_entry_safe(s, tmp, &listeners->list, list) {
> > >> - ret = genlmsg_unicast(skb, s->pid);
> > >> + skb_next = NULL;
> > >> + if (
On Tue, 11 Jul 2006 20:28:50 +1000
Herbert Xu <[EMAIL PROTECTED]> wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Tue, 11 Jul 2006 00:36:39 -0400
> > Shailabh Nagar <[EMAIL PROTECTED]> wrote:
> >
> >> down_write(&listeners->sem);
> >> list_for_each_entry_safe(s, tmp, &listene
On Tue, Jul 11, 2006 at 11:22:18AM +0200, Marco Berizzi wrote:
>
> I'm able to connect to a sap server connected to the milano network
> from a sapgui client connected to the venezia network. No problem.
> If packet loss is a problem it should be also a problem with this tunnel.
> Am I wrong?
It d
Running this on mimosa 'mitigates' the problem:
ip addr add 172.29.128.1/28 dev eth2
Connections are pretty slow but they aren't
reseted anymore.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vge
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Tue, 11 Jul 2006 00:36:39 -0400
> Shailabh Nagar <[EMAIL PROTECTED]> wrote:
>
>> down_write(&listeners->sem);
>> list_for_each_entry_safe(s, tmp, &listeners->list, list) {
>> - ret = genlmsg_unicast(skb, s->pid);
>> +
Michael Buesch <[EMAIL PROTECTED]> wrote:
> cancel_rearming_delayed_work{queue} is broken, because it is
> possible to enter an infinite loop if:
> We call the function on a work that is currently not executing or pending.
Why are you calling it on a work that was never scheduled? Sounds like
a bu
On Tuesday 11 July 2006 11:31, you wrote:
> On Tue, 11 Jul 2006 11:11:27 +0200
> Michael Buesch <[EMAIL PROTECTED]> wrote:
>
> > But I think the following is also broken in the old code:
> > A wq is not pending anymore, but just executing (before it reschedules
> > itself).
> > I think that would
On Tue, 11 Jul 2006 00:36:39 -0400
Shailabh Nagar <[EMAIL PROTECTED]> wrote:
> down_write(&listeners->sem);
> list_for_each_entry_safe(s, tmp, &listeners->list, list) {
> - ret = genlmsg_unicast(skb, s->pid);
> + skb_next = NULL;
> + if (!list_islast
Another tricky behaviour:
[EMAIL PROTECTED]:/tmp# telnet 10.49.59.23 3218
Trying 10.49.59.23...
Connected to 10.49.59.23.
Escape character is '^]'.
Connection closed by foreign host.
[EMAIL PROTECTED]:/tmp# tcpdump -p -n -v ip host 10.49.59.23 > HERBERT-20060711
&
[1] 4797
dport=1142 packets=37 bytes=38629 [ASSURED] mark=0 use=1
[EMAIL PROTECTED]:/tmp# tcpdump -v -p -n ip host 10.49.59.23 > HERBERT-20060711
&
[1] 4747
[EMAIL PROTECTED]:/tmp# tcpdump: listening on eth0, link-type EN10MB (Ethernet),
capture size 96 bytes
[EMAIL PROTECTED]:/tmp# grep 10.49.
On Tue, 11 Jul 2006 11:11:27 +0200
Michael Buesch <[EMAIL PROTECTED]> wrote:
> But I think the following is also broken in the old code:
> A wq is not pending anymore, but just executing (before it reschedules
> itself).
> I think that would also loop forever. I don't think that's what we want.
>
Herbert Xu wrote:
We can say these things for certain:
1) The path between mimosa and pleiadi has a packet loss problem. A small
burst of 10 or so fragments is enough to cause at least half of them to
be lost. This problem may be specific to IPsec traffic (ISPs often
discriminate aga
On Tuesday 11 July 2006 06:25, you wrote:
> On Tue, 11 Jul 2006 00:54:33 +0200
> Michael Buesch <[EMAIL PROTECTED]> wrote:
>
> > Please apply this to wireless-dev.
> > Note that this is the second try to submit this patch.
> > The first try contained a little bug. I'm sorry for that.
> > If you al
Herbert Xu wrote:
On Mon, May 08, 2006 at 08:28:32AM +, Marco Berizzi wrote:
>
> [EMAIL PROTECTED]:~# ping 10.49.59.23
> PING 10.49.59.23 (10.49.59.23) 56(84) bytes of data.
> 64 bytes from 10.49.59.23: icmp_seq=1 ttl=247 time=91.9 ms
> 64 bytes from 10.49.59.23: icmp_seq=2 ttl=247 time=49.3
Hi,
> Since I didn't want to loose any tested because of the new field in
> the net_device structure,
> I have used the base_addr field instead and used the following access
functions:
This will horribly fail when you send something to master device
(wmaster0) directly. For example, having ipv
> Reversed (or previously applied) patch detected!
>
> Wrong patch ? This one won't apply, it seems to be already
> applied to 2.6.18-rc1-mm1.
ok these patches ought to fix this for real (sorry I don't have this
hardware so I cannot actually do the testing)
I hope you have time to test these..
Herbert Xu wrote:
Hi Marco:
Hi Herbert, I'm very happy hearing you.
On Mon, Apr 24, 2006 at 09:23:00AM +, Marco Berizzi wrote:
>
> What should I do? Mangling MSS with iptables --set-mss ?
> Altering MSS to 1440 did the trick. See:
> http://marc.theaimsgroup.com/?l=linux-netdev&m=1143730
On Fri, Jul 07, 2006 at 01:25:44PM -0500, Steve Wise wrote:
>
> Some IP networking is involved for this. IP addresses and port numbers
> are used by the RDMA Connection Manager. The motivation for this was
> two-fold, I think:
>
> 1) to simplify the connection setup model. The IB CM model was
Sorry for the double mail.
Forgot to CC netdev list.
Hi,
> Since I didn't want to loose any tested because of the new field in
> the net_device structure,
> I have used the base_addr field instead and used the following access
functions:
This will horribly fail when you send something to mast
On Mon, May 08, 2006 at 08:28:32AM +, Marco Berizzi wrote:
>
> [EMAIL PROTECTED]:~# ping 10.49.59.23
> PING 10.49.59.23 (10.49.59.23) 56(84) bytes of data.
> 64 bytes from 10.49.59.23: icmp_seq=1 ttl=247 time=91.9 ms
> 64 bytes from 10.49.59.23: icmp_seq=2 ttl=247 time=49.3 ms
> 64 bytes from 1
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Tue, 11 Jul 2006 09:57:08 +0400
> Did you benchmarked such approach both with
> and without netchannel bound to the socket?
It is not meant to be used in "real life" :-)
So benchmark is quite useless.
We are starting simple, and eventually all typ
94 matches
Mail list logo
