On Tuesday 10 January 2006 00:39, Denis Vlasenko wrote:
How are we going to find out which stack is best and which stack
we should concentrate our efforts on? In an absense of wifi maintainer,
maybe we should throw _all stacks_ (currently two) into the mainline,
and evolution will find the
The PRIO queuing discipline currently initializes only the bands
that appear in the priomap. It should instead initialize all the
configured bands.
Signed-off-by: Amnon Aaronsohn [EMAIL PROTECTED]
---
--- linux-2.6.14/net/sched/sch_prio.c 2005-10-28 02:02:08.0 +0200
+++
Hi,
On Tue, Jan 10, 2006 at 08:39:25AM +0200, Denis Vlasenko wrote:
On Friday 06 January 2006 06:22, Jeff Garzik wrote:
State of the Union - Wireless
January 5, 2006
[ snip ]
* Wireless drivers and the wireless stack need to be maintained IN-TREE
On Tuesday 10 January 2006 05:31, Shaun Pereira wrote:
--- linux-2.6.15-vanilla/include/net/x25.h2006-01-03 14:21:10.0
+1100
+++ linux-2.6.15/include/net/x25.h2006-01-10 16:15:16.0 +1100
@@ -223,6 +223,18 @@ extern struct x25_route *x25_get_route(s
extern struct
Denis Vlasenko wrote:
I am confused.
Which isn't really all that surprising.
ftp://ftp.berlios.de/pub/bcm43xx/snapshots/softmac/ieee80211softmac-20060107.tar.bz2
which is not the same. For example, ieee80211softmac.h file exists in both
tarballs but is not identical.
Suppose one wants to
lkml trimmed off.
On Tue, 2006-10-01 at 12:30 +0200, Amnon Aaronsohn wrote:
The PRIO queuing discipline currently initializes only the bands
that appear in the priomap. It should instead initialize all the
configured bands.
Did you actually run into some issues that prompted you to produce
Have you tried enabling the NMI watchdog? Enable CONFIG_X86_LOCAL_APIC
and
boot with `nmi_watchdog=1' on the command line, make sure that the NMI
line
of /proc/interrupts is incrementing.
I'll give it a try. I've added it to the append-line in the lilo config.
Am now
--- jamal [EMAIL PROTECTED] wrote:
Did you actually run into some issues that prompted
you to produce this
patch? Why would you want to have something not in
the priomap to
do any queueing of packets?
I wrote this patch because the qdisc wasn't running
correctly when I used priorities that
On Fri, 2006-01-06 at 18:08 -0500, Mike Kershaw wrote:
Two things to inject, from my own little corner of userspace:
Thanks.
I don't know if the solution to this is a warning, marking non-rfmon
virtual interfaces down, or just saying they'll figure it out, but I
figured it's worth
I don't know if the solution to this is a warning, marking non-rfmon
virtual interfaces down, or just saying they'll figure it out, but I
figured it's worth considering at an early stage.
I think the solution lies with the driver: It just doesn't allow
creating an rfmon virtual interface
On Sat, 2006-01-07 at 20:17 +0100, Stefan Rompf wrote:
Caveats:
-rfmon can affect all virtual devices as Mike pointed out
See my reply to him.
-As a matter of fact, virtual devices are not independant eveb without rfmon,
simply because one physical device can only tune to one channel at a
On Tue, 2006-01-10 at 11:09 -0500, Mike Kershaw wrote:
I don't think that I really agree with that. I don't, as a user or as a
programmer, want to unconfigure all my existing stuff just to drop into
rfmon for a few minutes. I'd definitely prefer that they stop working,
than have to remember
Jean-Luc Leger [EMAIL PROTECTED] reported this alternative
dependency on a non-existing symbol.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
--- linux-2.6.15-mm2-full/drivers/net/irda/Kconfig.old 2006-01-10
17:48:41.0 +0100
+++ linux-2.6.15-mm2-full/drivers/net/irda/Kconfig
On Wed, 11 Jan 2006 01:48:16 +1100
Joel Sing [EMAIL PROTECTED] wrote:
Hi Stephen,
I've just tracked down a bug that appears to have been introduced in the
2.6.15 kernel. Within the TCP Vegas implementation the slow start congestion
window increase code has been replaced with a call to
On Tue, 10 Jan 2006, Erik Mouw wrote:
I have lots of transmit timeouts with an Intel E1000 card during large
TCP transmissions (remotely viewing a 3000x2000 jpeg image using XV is
an excellent way to trigger it). This is what I get in linux-2.6.8.1:
sorry to hear you're having a problem, and
On Mon, 9 Jan 2006, Robin Humble wrote:
until we turned off tso on our cluster using
ethtool -K eth0 tso off
ethtool -K eth1 tso off
then for certain sized runs of some codes we were getting:
KERNEL: assertion (!sk-sk_forward_alloc) failed at net/core/stream.c (279)
KERNEL: assertion
From: Adrian Bunk [EMAIL PROTECTED]
Date: Tue, 10 Jan 2006 18:09:03 +0100
Jean-Luc Leger [EMAIL PROTECTED] reported this alternative
dependency on a non-existing symbol.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Applied, thanks.
-
To unsubscribe from this list: send the line unsubscribe
On Wed, 2006-01-11 at 01:37 +0100, Adrian Bunk wrote:
shadow.cabi.net does no longer exist.
Surely it would be better to point to the new home of these tools rather
than removing the reference to them entirely?
--
dwmw2
-
To unsubscribe from this list: send the line unsubscribe netdev in
the
On Wed, 2006-01-11 at 01:08 +, Alan Cox wrote:
I don't think they have a current home as such. I've got the scarabd
tar ball here so you can archive that somewhere on infradead if you'd
rather a reference remain.
ftp.uk.linux.org would probably make more sense.
--
dwmw2
-
To unsubscribe
On Mer, 2006-01-11 at 00:46 +, David Woodhouse wrote:
On Wed, 2006-01-11 at 01:37 +0100, Adrian Bunk wrote:
shadow.cabi.net does no longer exist.
Surely it would be better to point to the new home of these tools rather
than removing the reference to them entirely?
I don't think they
On Wed, Jan 11, 2006 at 12:46:48AM +, David Woodhouse wrote:
On Wed, 2006-01-11 at 01:37 +0100, Adrian Bunk wrote:
shadow.cabi.net does no longer exist.
Surely it would be better to point to the new home of these tools rather
than removing the reference to them entirely?
If you know
On Wednesday 11 January 2006 01:46, David Woodhouse wrote:
On Wed, 2006-01-11 at 01:37 +0100, Adrian Bunk wrote:
shadow.cabi.net does no longer exist.
Surely it would be better to point to the new home of these tools rather
than removing the reference to them entirely?
shaper is completely
On Mer, 2006-01-11 at 01:53 +0100, Andi Kleen wrote:
shaper is completely obsolete and it's probably best to just remove
all references to it and the kernel driver too.
I would agree with that but it nees to go through a proper obsolesence
and obliteration cycle not just vanish.
-
To
A few days ago, Jeff Garzik reminded us all of the grossly imperfect
state of wireless (802.11 aka WiFi) networking in Linux. First in
his list of key issues was the lack of a permanent maintainer for the
kernel wireless code. Jeff approached me to see if I was interested
in that role, and after
On Tue, 2006-10-01 at 07:18 -0800, Amnon Aaronsohn wrote:
[..]
Anyway, even when all the bands appear in the priomap,
it makes more sense to go over each band only once as
the patch does, instead of multiple times as the
current implementation.
So it is an optimization - not a bug then,
On Tue, Jan 10, 2006 at 10:16:23AM -0800, Jesse Brandeburg wrote:
On Mon, 9 Jan 2006, Robin Humble wrote:
until we turned off tso on our cluster using
ethtool -K eth0 tso off
ethtool -K eth1 tso off
...
the major problems only happen for 32 cpu parallel runs. smaller runs
work fine.
From: jamal [EMAIL PROTECTED]
Date: Tue, 10 Jan 2006 23:02:45 -0500
So it is an optimization - not a bug then, correct?
It is only an optimization in as much as it avoids duplicate
work during initialization.
Like you I don't see how this patch fixes anything.
No matter what you set
From: John W. Linville [EMAIL PROTECTED]
Date: Tue, 10 Jan 2006 21:05:36 -0500
I hereby claim responsibility for the state of wireless networking
support in the Linux kernel.
Thanks for taking on this important role John. It is truly
appreciated. Even though it may end up feeling like a
Hi Arnd
Thanks for reviewing those patches, and your feedback. I have made the
changes recommended. If these are acceptable, I will build a proper
[PATCH] for submission.Is there anyone in particular that I need to mail
in order that these patches go into the next release?
Here is the updated
And the correct x.25 patch, (will build a [PATCH] if this is ok).
Tested with with xot to a Cisco box.
Thanks once again for your help
/Shaun
Index: linux-2.6.15/net/x25/af_x25.c
===
--- linux-2.6.15.orig/net/x25/af_x25.c
+++
On Tuesday 10 January 2006 17:11, Andreas Mohr wrote:
Hi all,
this patch adds support for configopt parsing for ACX100 EEPROM version v5
(please report whether ACX100 v5 now works, preferrably with logs showing
configopt activity).
Also, we now only start another radio recalibration
31 matches
Mail list logo
