Hi.
On Mon, 2005-12-05 at 13:46 -0500, Jeff Garzik wrote:
> > Although I'm a bit biased towards MadWifi, I'd second your suggestion to
> > make use of the Devicescape code. The benefit of having a fully-blown
> > 802.11 stack in the kernel that drivers can make use of has been
> > discussed before
On Mon, 2005-12-05 at 21:43 -0800, David S. Miller wrote:
> From: Tom Young <[EMAIL PROTECTED]>
> Date: Tue, 06 Dec 2005 15:40:57 +1100
>
> > Remove unneeded call to tcp_vegas_rtt_calc. The more accurate
> > microsecond value has already been registered prior to calling
> > tcp_vegas_cong_avoid.
>
On Mon, 2005-12-05 at 21:40 -0800, David S. Miller wrote:
> From: Tom Young <[EMAIL PROTECTED]>
> Date: Tue, 06 Dec 2005 15:38:39 +1100
>
> > Do timestamping before cloneing.
> > This fixes the bug where the timestamp was performed in tcp_transmit_skb
> > on
> > the cloned skb leading to the times
From: Tom Young <[EMAIL PROTECTED]>
Date: Tue, 06 Dec 2005 15:40:57 +1100
> Remove unneeded call to tcp_vegas_rtt_calc. The more accurate
> microsecond value has already been registered prior to calling
> tcp_vegas_cong_avoid.
>
> Signed-off-by: Thomas Young <[EMAIL PROTECTED]>
This patch pretty
From: Tom Young <[EMAIL PROTECTED]>
Date: Tue, 06 Dec 2005 15:38:39 +1100
> Do timestamping before cloneing.
> This fixes the bug where the timestamp was performed in tcp_transmit_skb
> on
> the cloned skb leading to the timestamp being lost.
>
> Signed-off-by: Thomas Young <[EMAIL PROTECTED]>
E
From: Tom Young <[EMAIL PROTECTED]>
Date: Tue, 06 Dec 2005 15:37:22 +1100
> Move the resetting of rtt measurements to inside the once per RTT block
> of
> code.
>
> Signed-off-by: Thomas Young <[EMAIL PROTECTED]>
Stephen changed this purposefully in this change:
diff-tree 7faffa1c7fb9b8e8917e32
On Mon, Dec 05, 2005 at 11:48:52PM +0100, Jeroen Massar wrote:
> John Heffner wrote:
> > Jeroen Massar wrote:
> >> I wonder how many RFC's it violates. An interface must only answer ARP's
> >> on the interface that it is configured on, not anything else.
> >
> > Not true. See RFC 1122, section 3.
On Mon, Dec 05, 2005 at 06:03:02PM -0500, John Heffner wrote:
> Rick Jones wrote:
> >John Heffner wrote:
> >>Yes, but if an interface will accept packets for a certain IP address,
> >>and will send packets with that IP address, is there any reason it
> >>can't ARP for that address?
> >
> >
> >If
Remove unneeded call to tcp_vegas_rtt_calc. The more accurate
microsecond value has already been registered prior to calling
tcp_vegas_cong_avoid.
Signed-off-by: Thomas Young <[EMAIL PROTECTED]>
---
diff --git a/net/ipv4/tcp_vegas.c b/net/ipv4/tcp_vegas.c
--- a/net/ipv4/tcp_vegas.c
+++ b/net/ipv4
Move the resetting of rtt measurements to inside the once per RTT block
of
code.
Signed-off-by: Thomas Young <[EMAIL PROTECTED]>
---
diff --git a/net/ipv4/tcp_vegas.c b/net/ipv4/tcp_vegas.c
--- a/net/ipv4/tcp_vegas.c
+++ b/net/ipv4/tcp_vegas.c
@@ -333,11 +333,11 @@ static void tcp_vegas_cong_avoi
Do timestamping before cloneing.
This fixes the bug where the timestamp was performed in tcp_transmit_skb
on
the cloned skb leading to the timestamp being lost.
Signed-off-by: Thomas Young <[EMAIL PROTECTED]>
---
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
--- a/net/ipv4/tcp_output
Vegas RTT measurement currently seems quite broken.
I've identified three issues.
1) The reseting the rtt stats is for every call to cong_avoid rather
than at the end of the rtt.
2) Also, timestamping is being performed after the skb clone, leading
to non-sensical RTT estimates. The patch below
On Mon, Dec 05, 2005 at 06:48:15PM -0800, Jean Tourrilhes wrote:
> On Mon, Dec 05, 2005 at 03:51:36PM -0800, jt wrote:
> > Adrian Bunk wrote :
> > >
> > > Using WIRELESS_EXT instead of CONFIG_NET_RADIO is simply ugly.
> >
> > You are probably right that something need to be done about
> > it,
From: Horms <[EMAIL PROTECTED]>
Date: Tue, 6 Dec 2005 11:18:09 +0900
> ip_vs_app.c | 28
> ip_vs_lblc.c | 27 ---
> ip_vs_lblcr.c | 27 ---
> ip_vs_proto_tcp.c | 22 --
> 4 file
On Mon, Dec 05, 2005 at 03:51:36PM -0800, jt wrote:
> Adrian Bunk wrote :
> >
> > Using WIRELESS_EXT instead of CONFIG_NET_RADIO is simply ugly.
>
> You are probably right that something need to be done about
> it, but I believe this is the wrong direction. I would prefer you to
> replace W
ip_vs_app.c | 28
ip_vs_lblc.c | 27 ---
ip_vs_lblcr.c | 27 ---
ip_vs_proto_tcp.c | 22 --
4 files changed, 104 deletions(-)
Please apply
--
Horms
[IPVS] remove dead code
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Mon, 5 Dec 2005 16:37:53 -0800
> I assert that with lockless transmit (ie NETIF_F_LLTX) it is
> possible for two cpu's to race with the transmit flow control
> (netif_stop_queue/netif_wake_queue). I see it with sky2, and
> probably could reproduce
Arnd Bergmann writes:
> Uploading the device firmware may fail if wrong input data
> was provided by the user. This checks for the condition.
>
> From: [EMAIL PROTECTED]
> Cc: netdev@vger.kernel.org
This one should be sent to Jeff Garzik, along with patches 11, 13 and
14.
Paul.
-
To unsubscribe
I assert that with lockless transmit (ie NETIF_F_LLTX) it is possible
for two cpu's to race with the transmit flow control
(netif_stop_queue/netif_wake_queue).
I see it with sky2, and probably could reproduce with tg3 as well.
A. CPU is in middle of building up a transmit,
Mark Brown <[EMAIL PROTECTED]> :
[...]
> I had been under the impression that the stack was supposed to make sure
> that no poll() is running before the driver close() gets called ?
Not exactly. dev_close() waits a bit but it can not be sure that the
device driver will not schedule ->poll() from i
Adrian Bunk wrote :
>
> Using WIRELESS_EXT instead of CONFIG_NET_RADIO is simply ugly.
Sorry, but I did not see this e-mail in my inbox. Maybe my
spam filter is too agressive. I would prefer that to the
alternative...
You are probably right that something need to be done about
it
On Mon, Dec 05, 2005 at 12:12:09AM +0100, Francois Romieu wrote:
> -> netif_poll_disable() may sleep while a spinlock is held.
So it can, thanks.
> Btw, the poll/close routines seem racy with each other.
I had been under the impression that the stack was supposed to make sure
that no poll() is
Johannes Stezenbach wrote:
On Sat, Dec 03, 2005, Linus Torvalds wrote:
[EMAIL PROTECTED]:
sk98lin: fix checksumming code
sk98lin: add permanent address support
sk98lin: avoid message confusion with skge
I have an Asus P4P800 "Deluxe" with 3c940 LOM.
If I ping the box I get th
John Heffner wrote:
> Jeroen Massar wrote:
>> John Heffner wrote:
>>
>>> Jeroen Massar wrote:
>>>
I wonder how many RFC's it violates. An interface must only answer
ARP's
on the interface that it is configured on, not anything else.
>>>
>>> Not true. See RFC 1122, section 3.3.4. Th
Rick Jones wrote:
John Heffner wrote:
Yes, but if an interface will accept packets for a certain IP address,
and will send packets with that IP address, is there any reason it
can't ARP for that address?
If ARP RFC's say it shouldn't :) (I don't know that it does) ARP is ARP,
accepting IPs
Jeroen Massar wrote:
John Heffner wrote:
Jeroen Massar wrote:
I wonder how many RFC's it violates. An interface must only answer ARP's
on the interface that it is configured on, not anything else.
Not true. See RFC 1122, section 3.3.4. The standard leaves this
decision up to the implement
John Heffner wrote:
> Jeroen Massar wrote:
>> I wonder how many RFC's it violates. An interface must only answer ARP's
>> on the interface that it is configured on, not anything else.
>
> Not true. See RFC 1122, section 3.3.4. The standard leaves this
> decision up to the implementation, for goo
John Heffner wrote:
Rick Jones wrote:
That's the discussion related to things like the "Strong ES" (end
system) model right? As such, isn't that discussing what _IP_ may do
rather than what ARP may do? 1122 doesn't say much about the
interfaces/MAC's that should be part of a given ARP reply
Rick Jones wrote:
That's the discussion related to things like the "Strong ES" (end
system) model right? As such, isn't that discussing what _IP_ may do
rather than what ARP may do? 1122 doesn't say much about the
interfaces/MAC's that should be part of a given ARP reply. ARP seems to
be RF
John Heffner wrote:
Jeroen Massar wrote:
I wonder how many RFC's it violates. An interface must only answer ARP's
on the interface that it is configured on, not anything else.
Not true. See RFC 1122, section 3.3.4. The standard leaves this
decision up to the implementation, for good reaso
Jeroen Massar wrote:
I wonder how many RFC's it violates. An interface must only answer ARP's
on the interface that it is configured on, not anything else.
Not true. See RFC 1122, section 3.3.4. The standard leaves this
decision up to the implementation, for good reason.
From 1122 (note th
The driver incorrectly used dma_addr_t to describe
HW structures and consequently broke when that type
was changed in 2.6.15-rc.
This changed spidernet to use u32 for 32 bit HW defined
structure elements.
From: [EMAIL PROTECTED]
Cc: netdev@vger.kernel.org
Signed-off-by: Arnd Bergmann <[EMAIL PROT
We changed the name of the Kconfig symbols along with
the move to arch/powerpc. This one hunk got lost during
the conversion.
From: [EMAIL PROTECTED]
Cc: netdev@vger.kernel.org
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
Index: linux-2.6.15-rc1/drivers/net/Kconfig
===
Uploading the device firmware may fail if wrong input data
was provided by the user. This checks for the condition.
From: [EMAIL PROTECTED]
Cc: netdev@vger.kernel.org
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
Index: linux-2.6.15-rc/drivers/net/spider_net.c
=
request_firmware() is sometimes problematic, especially
in initramfs, reading the firmware from Open Firmware
is much preferrable.
We still try to get the firmware from the file system
first, in order to support old SLOF releases and to allow
updates of the spidernet firmware without reflashing
th
On Fri, Nov 18, 2005 at 06:24:10PM -0200, Arnaldo Carvalho de Melo wrote:
> On 11/18/05, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > On Mon, Nov 14, 2005 at 02:57:07AM +0100, Adrian Bunk wrote:
> > > On Fri, Nov 11, 2005 at 02:35:51AM -0600, Matt Mackall wrote:
> > > > trivial: drop unused 802.3 cod
On Mon, Dec 05, 2005 at 10:00:41AM -0800, Ben Greear wrote:
> >Precisely the case. It should be the case that a box response to an
> >arp on *any* interface for *any* IP address known to the box.
>
> I certainly don't mind if this is a configurable, or even default
> behaviour, but we also need t
On Mon, Dec 05, 2005 at 06:59:07PM +0100, Jeroen Massar wrote:
> Marc Singer wrote:
> > On Mon, Dec 05, 2005 at 09:01:00AM -0500, John W. Linville wrote:
> >> On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote:
>
> >> The association between IP addresses and links is already a bit murky.
>
John W. Linville wrote:
> > Al Boldi wrote:
> > >Here specifically, ip/ifconfig is implemented upside-down requiring a
> > >link/dev to exist for an address to be defined, in effect containing
> > > layer 3 inside layer 2, when an address should be allowed to be
> > > defined w/o a link/dev much li
On Mon, 5 Dec 2005 21:23:42 +0100, Michael Buesch wrote:
> This is __not__ "yet another stack". It is an _extension_.
> It is all about management frames, which the in-kernel code
> does not manage.
But this code should be part of the stack, as nearly every driver needs
it. Management handling sho
On Monday 05 December 2005 19:00, you wrote:
> On Sun, 04 Dec 2005 19:50:08 +0100, [EMAIL PROTECTED] wrote:
> > The team is in the progress of writing a SoftwareMAC layer,
> > which is needed for the bcm device. The SoftMAC is still very
> > incomplete. So do not expect to do any fancy stuff like W
On Mon, 5 Dec 2005 19:41:46 +, Christoph Hellwig wrote:
> None of them made it into the kernel tree. As soon as we'll have an
> acceptable one everyone will have to use and improve it. I personally
> couldn't care less what we start with.
Same with me.
> That's because you still don't get h
Dave Jones wrote:
On Mon, Dec 05, 2005 at 02:08:28PM -0500, Jeff Garzik wrote:
> Jiri Benc wrote:
> >On Mon, 05 Dec 2005 13:38:37 -0500, Joseph Jezak wrote:
> >
> >>We're not writing an entire stack. We're writing a layer that sits in
> >>between the current ieee80211 stack that's already
On Mon, Dec 05, 2005 at 10:00:41AM -0800, Ben Greear wrote:
> Marc Singer wrote:
> >On Mon, Dec 05, 2005 at 09:01:00AM -0500, John W. Linville wrote:
> >>The association between IP addresses and links is already a bit murky.
> >>Reference the arp_announce sysctl for what I mean. I recall Dave M.
On Mon, Dec 05, 2005 at 02:08:28PM -0500, Jeff Garzik wrote:
> Jiri Benc wrote:
> >On Mon, 05 Dec 2005 13:38:37 -0500, Joseph Jezak wrote:
> >
> >>We're not writing an entire stack. We're writing a layer that sits in
> >>between the current ieee80211 stack that's already present in the kerne
On Mon, Dec 05, 2005 at 08:31:21PM +0100, Jiri Benc wrote:
> > And Joseph &
> > friends are writing a module to support softmac cards in that framework,
> > which is one of the most urgently needed things right now, because all the
> > existing softmac frameworks don't work with that code.
>
> And
On Mon, 5 Dec 2005 19:10:08 +, Christoph Hellwig wrote:
> Please stop beeing a freaking jackass. There are various projects using
> the current code. It's not perfect but people are working on it.
Yes, and everyone implements his own softmac (this is the third one I
know about). I tried to p
On Mon, Dec 05, 2005, Stephen Hemminger wrote:
> The checksum offsets for receive offload were not being set correctly.
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
I can confirm that this patch fixes the problem for me.
Thanks,
Johannes
> Index: linux-2.6/drivers/net/sk98lin/skge.c
On Mon, 05 Dec 2005 14:08:28 -0500, Jeff Garzik wrote:
> Patently false.
>
> ieee80211 is used by Intel. Some bits used by HostAP, which also
> duplicates a lot of ieee80211 code. And bcm43xx. And another couple
> drivers found in -mm or out-of-tree.
Hostap uses only encryption code, which w
On Mon, Dec 05, 2005 at 07:55:43PM +0100, Jiri Benc wrote:
> Unfortunately, the only long-term solution is to rewrite completely the
> current in-kernel ieee80211 code (I would not call it a "stack") or
> replace it with something another. The current code was written for
> Intel devices and it doe
On Mon, 05 Dec 2005 13:54:00 -0500, Jeff Garzik wrote:
> Complete bullshit. There is obviously 802.11 generic code in the
> kernel, and that's what _I_ am saying, because it's true.
>
> If it doesn't support your favorite wireless chipset, then submit patches.
I have no favorite chipset. I read
Jiri Benc wrote:
On Mon, 05 Dec 2005 13:38:37 -0500, Joseph Jezak wrote:
We're not writing an entire stack. We're writing a layer that sits in
between the current ieee80211 stack that's already present in the kernel
and drivers that do not have a hardware MAC. Since ieee80211 is already
in
On Mon, 05 Dec 2005 13:38:37 -0500, Joseph Jezak wrote:
> We're not writing an entire stack. We're writing a layer that sits in
> between the current ieee80211 stack that's already present in the kernel
> and drivers that do not have a hardware MAC. Since ieee80211 is already
> in use in the k
The checksum offsets for receive offload were not being set correctly.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/net/sk98lin/skge.c
===
--- linux-2.6.orig/drivers/net/sk98lin/skge.c
+++ linux-2.6/
Jiri Benc wrote:
On Mon, 05 Dec 2005 13:46:43 -0500, Jeff Garzik wrote:
Use the stack that's already in the kernel.
Encouraging otherwise hinders continued wireless progress under Linux.
There is nothing like a "802.11 stack" currently in the kernel,
regardless what James Ketrenos is saying
On Mon, 05 Dec 2005 13:46:43 -0500, Jeff Garzik wrote:
> Use the stack that's already in the kernel.
>
> Encouraging otherwise hinders continued wireless progress under Linux.
There is nothing like a "802.11 stack" currently in the kernel,
regardless what James Ketrenos is saying. Sorry.
--
Ji
Michael Renzmann wrote:
Hi.
On Mon, 2005-12-05 at 19:00 +0100, Jiri Benc wrote:
Why yet another attempt to write 802.11 stack? Sure, the one currently
in the kernel is unusable and everybody knows about it. But why not to
improve code opensourced by Devicescape some time ago instead of
inventi
> Why yet another attempt to write 802.11 stack? Sure, the one currently
> in the kernel is unusable and everybody knows about it. But why not to
> improve code opensourced by Devicescape some time ago instead of
> inventing the wheel again and again? Yes, I know that code is not
> perfect and nee
Hi.
On Mon, 2005-12-05 at 19:00 +0100, Jiri Benc wrote:
> Why yet another attempt to write 802.11 stack? Sure, the one currently
> in the kernel is unusable and everybody knows about it. But why not to
> improve code opensourced by Devicescape some time ago instead of
> inventing the wheel again a
On Sun, Dec 04, 2005 at 06:14:09PM -0800, Jouni Malinen wrote:
> On Sat, Dec 03, 2005 at 01:23:09PM +0100, Adrian Bunk wrote:
> > This patch contains an attempt to properly build hostap.o without
> > #incude'ing C files.
>
> Looks good. However, I did not test this now since this did not apply to
On Sun, 04 Dec 2005 19:50:08 +0100, [EMAIL PROTECTED] wrote:
> The team is in the progress of writing a SoftwareMAC layer,
> which is needed for the bcm device. The SoftMAC is still very
> incomplete. So do not expect to do any fancy stuff like WPA
> or something line that with it.
Why yet another
Marc Singer wrote:
On Mon, Dec 05, 2005 at 09:01:00AM -0500, John W. Linville wrote:
On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote:
Al Boldi wrote:
Here specifically, ip/ifconfig is implemented upside-down requiring a
link/dev to exist for an address to be defined, in effect c
Marc Singer wrote:
> On Mon, Dec 05, 2005 at 09:01:00AM -0500, John W. Linville wrote:
>> On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote:
>> The association between IP addresses and links is already a bit murky.
>> Reference the arp_announce sysctl for what I mean. I recall Dave M.
>>
Am Donnerstag 01 Dezember 2005 13:48 schrieb Krzysztof Halasa:
> - kernel driver signals lower-level down
> - kernel driver signals lower-level up (dormant = 1)
> - slow userspace (in this case, could be a kernel module if strict
> serialization of all operational status changes isn't required)
On Mon, Dec 05, 2005 at 09:01:00AM -0500, John W. Linville wrote:
> On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote:
> > Al Boldi wrote:
> >
> > >Here specifically, ip/ifconfig is implemented upside-down requiring a
> > >link/dev to exist for an address to be defined, in effect contain
Hi,
I've just completed documentation for the RFC2863 patch. Jouni, can you take
the time to read this and check if there is anything missing to support
wpa_supplicant? I'm aware that you might rather listen to wireless events
instead of RTM_NEWLINK for wlan devices, but all in all it should wo
please take a look at belows BUG_ON()
at a quick glance didn't find a patch for that in git-commits-list.
belows kernel has all fixes from the latest 2.6.14.3 stable.
- Forwarded message from Frans Pop <[EMAIL PROTECTED]> -
Subject: Bug#341392: linux-2.6: kernel BUG at mm/slab.c:1807!
Da
John W. Linville wrote:
> Of course, patches would be helpful...
/sbin/ipadd
#!/bin/sh
ip addr add $1 dev lo
/sbin/ipdel
#!/bin/sh
ip addr del $1 dev lo
/sbin/ipactivate
#!/bin/sh
ip addr add $1 dev $2
/sbin/ipdeactivate
#!/bin/sh
ip addr del $1 dev $2
There are your 'patches'. Add -6'
On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote:
> Al Boldi wrote:
>
> >Here specifically, ip/ifconfig is implemented upside-down requiring a
> >link/dev to exist for an address to be defined, in effect containing layer
> >3 inside layer 2, when an address should be allowed to be defi
On Sat, 2005-03-12 at 14:58 -0700, Grant Grundler wrote:
> On Sat, Dec 03, 2005 at 02:37:59PM -0500, jamal wrote:
> > On Sat, 2005-03-12 at 12:00 -0700, Grant Grundler wrote:
> > > On Sat, Dec 03, 2005 at 09:20:52AM -0500, jamal wrote:
> > > > Ok, so you seem to be saying again that for case #b abo
On 12/5/05, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> On Sun, 4 Dec 2005 17:17:24 -0200
> Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> wrote:
> > Agreed, I was quite annoyed when this happened to me:
> >
> > [EMAIL PROTECTED] ~]# ip r s
> > Object "r" is unknown, try "ip help".
> > [EMAIL PROT
71 matches
Mail list logo
