Philip Craig <[EMAIL PROTECTED]> :
[...]
> This patch caused a drop in throughput from 178 Mbits/sec to 135 Mbits/sec
> on an Intel XScale IXP465.
Which distribution of packet sizes ?
> It seems like there is some confusion about what the align parameter
> here means. It was originally an offset
* David Miller <[EMAIL PROTECTED]> [070213 00:53]:
> From: Baruch Even <[EMAIL PROTECTED]>
> Date: Tue, 13 Feb 2007 00:12:41 +0200
>
> > The problem is that you actually put a mostly untested algorithm as the
> > default for everyone to use. The BIC example is important, it was the
> > default alg
On Monday 12 February 2007 19:35, James Ketrenos wrote:
> Hesse, Christian wrote:
> > On Saturday 10 February 2007 14:23, Hesse, Christian wrote:
> >> On Friday 09 February 2007 22:12, James Ketrenos wrote:
> >>> We are pleased to announce the availability of a new driver for the
> >>> Intel PRO/Wi
TCP may advertize up to 16-bits window in SYN packets (no window
scaling allowed). At the same time, TCP may have rcv_wnd
(32-bits) that does not fit to 16-bits without window scaling
resulting in pseudo garbage into advertized window from the
low-order bits of rcv_wnd. This can happen at least whe
Herbert Xu wrote:
> Mike Accetta <[EMAIL PROTECTED]> wrote:
>
>>Obviously the code believes it can assume that there are always multiple
>>sk_buff's in the chain. The stack trace seems to implicate iptables in
>>the scenario (twice) if that means anything. Any ideas about what may
>>be going wro
[NET_SCHED]: sch_hfsc: replace ASSERT macro by WARN_ON
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit ee0d5b5b1a2f81dabd5189c6ac960e7cab40d8ff
tree 6975f4ea578fb1e86f8d9c7607fa08ec3a8c841f
parent 6e1d9d04c4004361fb327abcbde74a20e8dca2ff
author Patrick McHardy <[EMAIL PROTECTED]> Tu
Patrick McHardy writes:
> Herbert Xu wrote:
> > Mike Accetta <[EMAIL PROTECTED]> wrote:
> >
> >>Obviously the code believes it can assume that there are always multiple
> >>sk_buff's in the chain. The stack trace seems to implicate iptables in
> >>the scenario (twice) if that means anything. Any
Hi Baruch,
I would like to add some comments on your argument.
On 2/13/07, Baruch Even <[EMAIL PROTECTED]> wrote:
* David Miller <[EMAIL PROTECTED]> [070213 00:53]:
> From: Baruch Even <[EMAIL PROTECTED]>
> Date: Tue, 13 Feb 2007 00:12:41 +0200
>
> > The problem is that you actually put a mostl
* SANGTAE HA <[EMAIL PROTECTED]> [070213 18:50]:
> Hi Baruch,
>
> I would like to add some comments on your argument.
>
> On 2/13/07, Baruch Even <[EMAIL PROTECTED]> wrote:
> >* David Miller <[EMAIL PROTECTED]> [070213 00:53]:
> >> From: Baruch Even <[EMAIL PROTECTED]>
> >> Date: Tue, 13 Feb 2007
On Feb 13, 2007, at 4:56 AM, Baruch Even wrote:
According to claims of Doug Leith the cubic algorithm that is in the
kernel is different from what was proposed and tested. That's an
important issue which is deflected by personal attacks.
It is not the algorithm "untested" -- it is the implem
On Tue, Feb 13, 2007 at 03:34:43PM +0100, Patrick McHardy wrote:
>
> The callpath shows the REJECT target sending a TCP reset.
> I'm guessing it has something to do with skb_copy_expand
> copying the gso fields.
Indeed. We need to reset the GSO bits there since the new
packet is nothing like the
Hi,
On 2/13/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> You can disable it in /proc/sys/net/ipv6/conf/default/... and then
> reenable it on the interfaces that you actually want.
Is there any technical reason to not have the sysconf entries
available at interface creation? It seems to
* Injong Rhee <[EMAIL PROTECTED]> [070213 19:43]:
>
> On Feb 13, 2007, at 4:56 AM, Baruch Even wrote:
>
> >
> >According to claims of Doug Leith the cubic algorithm that is in the
> >kernel is different from what was proposed and tested. That's an
> >important issue which is deflected by personal
On Tue, Feb 13, 2007 at 08:27:59AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <[EMAIL PROTECTED]> (at Thu, 8 Feb 2007 08:07:15 -0500), Neil
> Horman <[EMAIL PROTECTED]> says:
>
> > > I still have a question. Now, who will install the kernel route for
> > > the incoming packet? Can we g
Neil,
On 2/13/07, Neil Horman <[EMAIL PROTECTED]> wrote:
Can't this simply be fixed by adding a custom udev rule? Correct me if I'm
wrong, but the only reason that interfaces come up automatically after their
appropriate module is inserted is because most distos udev rules issue an ifup
$DEVICE
[TG3]: Save MSI state before suspend.
This fixes the following problem:
http://bugzilla.kernel.org/show_bug.cgi?id=7969
The MSI state needs to be saved during suspend. PCI state saved
during tg3_init_one() does not contain valid MSI state because
MSI hasn't been enabled.
Signed-off-by: Michael
[TG3]: Use lower DMA watermark for 5703.
Set DMA read watermark to 4 on 5703 in PCIX mode. This is needed to
prevent some tx timeouts.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 0b5b8e7..2df343f 100644
--- a/drivers/net/tg3.c
+++ b/d
[TG3]: 5722/5756 don't need PHY jitter workaround.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 2df343f..fc94b19 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -10779,7 +10779,9 @@ static int __devinit tg3_get_invariants(
[TG3]: 5906 doesn't need to switch to slower clock.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index fc94b19..b6615f1 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -1340,7 +1340,8 @@ static int tg3_set_power_state(struct tg
[TG3]: Power down 5704 serdes transceiver when shutting down.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index b6615f1..604f308 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -1175,8 +1175,18 @@ static void tg3_nvram_unlock(struct
[TG3]: Use constant for PHY register 0x1e.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 604f308..a1aeba2 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -6594,8 +6594,9 @@ static int tg3_reset_hw(struct tg3 *tp,
[TG3]: Add some tx timeout debug messages.
Print the most useful information during tx timeout to help debug.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index a1aeba2..159570b 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -3735,
[TG3]: Update copyright, version, and reldate.
Update version to 3.73.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 159570b..81a1c2e 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -4,7 +4,7 @@
* Copyright (C) 2001, 2002, 20
On Tue, Feb 13, 2007 at 12:14:01PM -0800, Michael Chan wrote:
> [TG3]: Use lower DMA watermark for 5703.
>
> Set DMA read watermark to 4 on 5703 in PCIX mode. This is needed to
> prevent some tx timeouts.
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
ACK patches 2-8
-
To unsubscribe fro
On Tue, Feb 13, 2007 at 12:13:32PM -0800, Michael Chan wrote:
> [TG3]: Save MSI state before suspend.
>
> This fixes the following problem:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=7969
>
> The MSI state needs to be saved during suspend. PCI state saved
> during tg3_init_one() does not co
On Tue, Feb 13, 2007 at 07:24:32PM +, Hugo Santos wrote:
> Neil,
>
> On 2/13/07, Neil Horman <[EMAIL PROTECTED]> wrote:
> >Can't this simply be fixed by adding a custom udev rule? Correct me if I'm
> >wrong, but the only reason that interfaces come up automatically after
> >their
> >appropri
Yes, I understand that, but until the IFF_UP flag is set on the interface, it
doesn't really have any effect on the system as a whole. You should be able to
undo any default setting that you want before you call ifup on the interface, or
am I missing something?
If i understand what you are pro
On Tue, 2007-02-13 at 14:45 -0500, Jeff Garzik wrote:
>
> I'm curious if, after this patch is applied, all the pci_save_state()
> calls are truly necessary?
>
The others are necessary to save/restore the memory enable bit in the
PCI command register. This bit gets reset after chip reset.
-
To
This isn't really a reply to anyone in particular, but I wanted to touch
on a few points.
Reno. As Windows decided to go with "Compound TCP", why we want to
back to 80's algorithm?
It's worth noting that Microsoft is not using Compound TCP by default,
except in Beta versions so they can get
On Tue, 13 Feb 2007 07:26:51 +0100
Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 12, 2007 at 09:47:38AM -0800, Stephen Hemminger wrote:
> > On Mon, 12 Feb 2007 11:28:48 +0100
> > Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> >
> > > Here is my patch proposal for testing.
> > > If it doe
From: Baruch Even <[EMAIL PROTECTED]>
Date: Tue, 13 Feb 2007 11:56:13 +0200
> Do you still think that making Cubic the default is a good idea?
Can you propose a better alternative other than Reno?
You've cited only "unknown unknowns" and that's not something tangible
we can work with.
-
To unsub
On Tue, 13 Feb 2007 12:13:32 -0800
"Michael Chan" <[EMAIL PROTECTED]> wrote:
> [TG3]: Save MSI state before suspend.
>
> This fixes the following problem:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=7969
>
> The MSI state needs to be saved during suspend. PCI state saved
> during tg3_init_o
On Tue, Feb 13, 2007 at 11:58:25AM -0800, Stephen Hemminger wrote:
> I think you have to move the original pci_save_state call, otherwise
> you will call pci_save_state twice and leak memory. pci_save_state
> allocates memory to store MSI and other information. Look at
> pci_save_pcie_state
> etc
On Tue, Feb 13, 2007 at 04:00:36PM +, Ben Gamari wrote:
> That being said, now come the problems. When I first loaded the driver,
> I found that it had created two interfaces as mentioned in earlier
> threads. On my machine these are named eth1 and wlan0_rename (can
> someone confirm what the n
* David Miller <[EMAIL PROTECTED]> [070213 21:56]:
> From: Baruch Even <[EMAIL PROTECTED]>
> Date: Tue, 13 Feb 2007 11:56:13 +0200
>
> > Do you still think that making Cubic the default is a good idea?
>
> Can you propose a better alternative other than Reno?
The only other option would be HS-TC
From: "SANGTAE HA" <[EMAIL PROTECTED]>
Date: Tue, 13 Feb 2007 11:49:47 -0500
> I don't care what algorithm is default in kernel, however, it is not
> appropriate to get back to Reno. As Windows decided to go with
> "Compound TCP", why we want to back to 80's algorithm?
I want to re-emphasize this
On Tue, Feb 13, 2007 at 07:49:50PM +, Hugo Santos wrote:
> >Yes, I understand that, but until the IFF_UP flag is set on the interface,
> >it
> >doesn't really have any effect on the system as a whole. You should be
> >able to
> >undo any default setting that you want before you call ifup on
On Tue, 2007-02-13 at 11:58 -0800, Stephen Hemminger wrote:
>
> I think you have to move the original pci_save_state call, otherwise
> you will call pci_save_state twice and leak memory. pci_save_state
> allocates memory to store MSI and other information. Look at
> pci_save_pcie_state
> etc.
>
On 2/13/07, Neil Horman <[EMAIL PROTECTED]> wrote:
1) Kernel network driver X detects that it has hardware to drive, and
consequently calls register_netdev. This creates the network interface and
registers all the appropriate proc and sysfs files, which are now accessible in
user space.
The pr
On Tue, 2007-02-13 at 14:13 -0500, Jason Lunz wrote:
> The "_rename" suffix is an indication that you have udev rules that are
> attempting to assign the same name to two different netdevs. Try to
> disable udev device renaming, or make the rules more specific.
>
> The attached kernel patch makes
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Tue, 13 Feb 2007 12:13:32 -0800
> [TG3]: Save MSI state before suspend.
>
> This fixes the following problem:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=7969
>
> The MSI state needs to be saved during suspend. PCI state saved
> during tg3_init
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Tue, 13 Feb 2007 12:14:01 -0800
> [TG3]: Use lower DMA watermark for 5703.
>
> Set DMA read watermark to 4 on 5703 in PCIX mode. This is needed to
> prevent some tx timeouts.
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Applied.
-
To unsubs
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Tue, 13 Feb 2007 12:14:09 -0800
> [TG3]: 5722/5756 don't need PHY jitter workaround.
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Tue, 13 Feb 2007 12:14:20 -0800
> [TG3]: 5906 doesn't need to switch to slower clock.
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Tue, 13 Feb 2007 12:14:32 -0800
> [TG3]: Power down 5704 serdes transceiver when shutting down.
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Tue, 13 Feb 2007 12:14:43 -0800
> [TG3]: Use constant for PHY register 0x1e.
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTE
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Tue, 13 Feb 2007 12:14:50 -0800
> [TG3]: Add some tx timeout debug messages.
>
> Print the most useful information during tx timeout to help debug.
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send t
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Tue, 13 Feb 2007 12:14:58 -0800
> [TG3]: Update copyright, version, and reldate.
>
> Update version to 3.73.
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Also applied, thanks a lot Michael.
-
To unsubscribe from this list: send the line "uns
My somewhat biased capsule summary is:
Algorithms:
Reno: Linux never really implemented pure Reno anyway, see
http://www.cs.helsinki.fi/research/iwtcp/papers/linuxtcp.pdf
This makes anybody doing pure ns2 based comparisons suspect.
The problem is Reno rolls off
HSTCP: too aggressiv
On Fri, Feb 09, 2007 at 01:38:02PM -0800, Andrew Morton wrote:
>
> cond_resched() called from softirq, amongst other problems.
>
> On Fri, 9 Feb 2007 08:23:44 -0800
> [EMAIL PROTECTED] wrote:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=7974
> >
> >Summary: BUG: scheduling while
Neil Horman wrote:
> 5) the ifup $DEVICE from (4) goes through the network interface bring up
> process, and consequently sends the ioctl SIOCSIFFLAGS to the kernel, setting
> the IFF_UP flag on the appropriate interface, kicking of whatever default
> processes need to be as defined by the settings
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 14 Feb 2007 04:51:21 +1100
> On Tue, Feb 13, 2007 at 03:34:43PM +0100, Patrick McHardy wrote:
> >
> > The callpath shows the REJECT target sending a TCP reset.
> > I'm guessing it has something to do with skb_copy_expand
> > copying the gso fields.
>
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 13 Feb 2007 11:55:29 -0800
> On Tue, 13 Feb 2007 07:26:51 +0100
> Jarek Poplawski <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Feb 12, 2007 at 09:47:38AM -0800, Stephen Hemminger wrote:
> > > On Mon, 12 Feb 2007 11:28:48 +0100
> > > Jarek Poplaws
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Tue, 13 Feb 2007 16:20:07 +0100
> [NET_SCHED]: sch_hfsc: replace ASSERT macro by WARN_ON
>
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Applied, thanks Patrick.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Tue, 13 Feb 2007 15:08:34 +0200 (EET)
> TCP may advertize up to 16-bits window in SYN packets (no window
> scaling allowed). At the same time, TCP may have rcv_wnd
> (32-bits) that does not fit to 16-bits without window scaling
> resulting in pseudo
[Sorry, forgot to remove the obsolete regs argument from gfar_error() call,
call, so the previous version wasn't even compilable -- I've tested the patch
in the older kernel. :-<]
It was hardly necessary to repeat most of the code from gfar_error() in
gfar_interrupt(), especially having some incon
>I still have a question. Now, who will install the kernel route for
> > the incoming packet? Can we get packet for our unicast address during
> > optimistic DAD period?
As per Yoshifjui's observation, the current patch doesn't currently allow for
the reception of inbound packets to our optimis
In article <[EMAIL PROTECTED]> (at Tue, 13 Feb 2007 15:45:15 -0500), Neil
Horman <[EMAIL PROTECTED]> says:
> Signed-off-by: Neil Horman <[EMAIL PROTECTED]>
I'm starting regression tests now.
--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message
On Tue, Feb 13, 2007 at 12:34:13PM -0800, David Miller wrote:
>
> I'm kind of challenged for time as I'll be out of town from
> Wednesday until Sunday, so if someone could cook up the TSO
> variable of the patch for pre-GSO kernels I'd appreciate it.
Sure, here is the patch for any kernel prior to
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 14 Feb 2007 08:51:58 +1100
> On Tue, Feb 13, 2007 at 12:34:13PM -0800, David Miller wrote:
> >
> > I'm kind of challenged for time as I'll be out of town from
> > Wednesday until Sunday, so if someone could cook up the TSO
> > variable of the patch f
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Date: Wed, 14 Feb 2007 06:46:49 +0900 (JST)
> In article <[EMAIL PROTECTED]> (at Tue, 13 Feb 2007 15:45:15 -0500), Neil
> Horman <[EMAIL PROTECTED]> says:
>
> > Signed-off-by: Neil Horman <[EMAIL PROTECTED]>
>
> I'm starting regression tests now.
Tha
From: Kazunori MIYAZAWA <[EMAIL PROTECTED]>
Date: Fri, 9 Feb 2007 16:37:16 +0900
> [1/4] changing API of xfrm4_tunnel_register
> [2/4] make sit use the xfrm4_tunnel_register
> [3/4] changing API of xfrm6_tunnel_register
> [4/4] Fix the address family to refer encap_family
I've applied all 4 patch
Andy Gospodarek <[EMAIL PROTECTED]> wrote:
[...]
>I've been working off and on for a little while to resolve these issues
>and even posted a patch not long ago to address some these by removing
>the timers and using workqueues instead. This enabled resolution of
>quite a few of the issues with bo
From: Jay Vosburgh <[EMAIL PROTECTED]>
Date: Tue, 13 Feb 2007 14:26:28 -0800
> In reference to Andy's recent patch (which first did conditional
> locking for rtnl, then later acquired rtnl for every entry into the
> timer function), I know the conditional locking isn't popular, but it
> seem
Andy Gospodarek <[EMAIL PROTECTED]> wrote:
>On Tue, Feb 13, 2007 at 02:32:43PM -0800, David Miller wrote:
[...]
>> Maybe if you put the RTNL acquisition deeper into the call
>> path, ie. down into the code that knows RTNL is needed,
>> perhaps it won't be so ugly. Replace the conditions with
>> f
On Tue, Feb 13, 2007 at 02:32:43PM -0800, David Miller wrote:
> From: Jay Vosburgh <[EMAIL PROTECTED]>
> Date: Tue, 13 Feb 2007 14:26:28 -0800
>
> > In reference to Andy's recent patch (which first did conditional
> > locking for rtnl, then later acquired rtnl for every entry into the
> > time
On Tue, 13 Feb 2007, Francois Romieu wrote:
> Philip Craig <[EMAIL PROTECTED]> :
> [...]
> > This patch caused a drop in throughput from 178 Mbits/sec to 135 Mbits/sec
> > on an Intel XScale IXP465.
>
> Which distribution of packet sizes ?
>
> > It seems like there is some confusion about what t
> >/**
> > * bond_rtnl_wrapper - take the rtnl_lock if needed
> > * @x: function with args
> > *
> > */
> >#define RTNL_WRAPPER(x)\
> >({ \
> > int __rc__; \
> > if (rtnl_trylock()) { \
> >
Francois Romieu wrote:
> Philip Craig <[EMAIL PROTECTED]> :
> [...]
>> This patch caused a drop in throughput from 178 Mbits/sec to 135 Mbits/sec
>> on an Intel XScale IXP465.
>
> Which distribution of packet sizes ?
Just using iperf with the default options, MTU 1500,
forwarding between 2 PCs wi
On Wed, 07 Feb 2007 19:36:22 +0100
Rainer Baumann <[EMAIL PROTECTED]> wrote:
> Hi Stephen
>
> I just wanted to ask you, if you already had time to test our trace
> extension for netem as discussed on the 13th of December.
>
> Cheers
> Rainer
>
> Rainer Baumann wrote:
> > Hi Stephen
> >
> > As d
On Tue, Feb 13, 2007 at 03:54:46PM -0800, Stephen Hemminger wrote:
> >
> > The problem with this is that it'll cause failures in the case
> > that some other unrelated entity holds rtnl ("x" will be performed
> > concurrently with whomever actually holds rtnl).
> >
>
> It is also a crap macr
I think I may have found a deadlock bug in 2.6.18.2. This is
with my hacked kernel, but my binary module has not been loaded.
I have several bridges configured, including some containing
my redirect-device virtual devices and ethernet devices.
I believe the deadlock is this:
The work-queue pro
On Tue, Feb 13, 2007 at 03:33:00PM -0800, Jay Vosburgh wrote:
> Andy Gospodarek <[EMAIL PROTECTED]> wrote:
>
> >On Tue, Feb 13, 2007 at 02:32:43PM -0800, David Miller wrote:
> [...]
> >> Maybe if you put the RTNL acquisition deeper into the call
> >> path, ie. down into the code that knows RTNL is
Andy Gospodarek <[EMAIL PROTECTED]> wrote:
>This is exactly the problem I've got, Jay. I'd love to come up with
>something that will be a smaller patch to solve this in the near term
>and then focus on a larger set of changes down the road but it doesn't
>seem likely.
That's more or less
Hi, All
When I tested Linux-2.6.20 and found that counter "ipOutNoRoutes" can
not increase correctly.
The criteria is RFC2011
ipOutNoRoutes OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of IP datagrams discarded
Convert network devices to use struct device instead of class_device. Greg
missed this one in his cleanup path.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
Jeff,
Sorry my mailer was completely screwed. I thought I had fixed the
settings to turn of flowed text. I think this was why the
Linas-san, Jens-san,
> Tested this series of patches together with Jen's "version 3" patch,
> it worked for me. Code looks reasonable. Thus
We tried Jens-san's v3 patch on Celleb, and it works for us.
We also need Linas-san's patch set which includes bug-fix and makes
the code compilable etc. B
There is long standing issue in kernel which makes using /etc/sysctl.conf
useless for boottime configuration of specific interface properties and
breaks probably any software relying on unconditional existence of the
conf trees like it was in previous kernels (I alone have written several
pieces of
On Friday 09 February 2007 23:12:42 James Ketrenos wrote:
> Please hold all questions until I am done with this email. Thank you.
>
> We are pleased to announce the availability of a new driver for the
> Intel PRO/Wireless 3945ABG Network Connection adapter. This new driver
> uses the new d80211
On 2/13/07, Ismail Dönmez <[EMAIL PROTECTED]> wrote:
Tried this is on a patched 2.6.20 kernel with ipw3945 device and it always
puts the card in 802.11a mode instead of 802.11bg mode.
Ideas?
Before running "iwconfig wlan0 channel 8", the card is set to
802.11a mode. iwconfig shows rate at
On Tuesday 13 February 2007 17:10:24 Jeff Chua wrote:
> On 2/13/07, Ismail Dönmez <[EMAIL PROTECTED]> wrote:
> > Tried this is on a patched 2.6.20 kernel with ipw3945 device and it
> > always puts the card in 802.11a mode instead of 802.11bg mode.
> >
> > Ideas?
>
> Before running "iwconfig wlan0
On Tue, 13 Feb 2007 15:29:04 +0200
Hasso Tepper <[EMAIL PROTECTED]> wrote:
> There is long standing issue in kernel which makes using /etc/sysctl.conf
> useless for boottime configuration of specific interface properties and
> breaks probably any software relying on unconditional existence of the
Al Viro wrote:
Spot the bug...
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/atl1/atl1_hw.c b/drivers/net/atl1/atl1_hw.c
index 08b2d78..e28707a 100644
--- a/drivers/net/atl1/atl1_hw.c
+++ b/drivers/net/atl1/atl1_hw.c
@@ -357,7 +357,7 @@ void atl1_hash_set(struct atl1_h
Al Viro wrote:
> Spot the bug...
>
> Signed-off-by: Al Viro <[EMAIL PROTECTED]>
> ---
>
> diff --git a/drivers/net/atl1/atl1_hw.c b/drivers/net/atl1/atl1_hw.c
> index 08b2d78..e28707a 100644
> --- a/drivers/net/atl1/atl1_hw.c
> +++ b/drivers/net/atl1/atl1_hw.c
> @@ -357,7 +357,7 @@ void atl1_hash
Hi!
> Please hold all questions until I am done with this
> email. Thank you.
>
> We are pleased to announce the availability of a new
> driver for the Intel PRO/Wireless 3945ABG Network
> Connection adapter. This new driver uses the new d80211
> subsystem previously only available as part
Stephen Hemminger wrote:
On Tue, 13 Feb 2007 15:29:04 +0200
Hasso Tepper <[EMAIL PROTECTED]> wrote:
There is long standing issue in kernel which makes using /etc/sysctl.conf
useless for boottime configuration of specific interface properties and
breaks probably any software relying on unconditi
On Tue, 2007-02-13 at 18:13 +, Pavel Machek wrote:
> Yes... is there merged .git tree somewhere? I downloaded iwl git tree,
> but it did not contain d80211 stack. I'm now downloading wireless-dev
> git tree...
I would expect Intel to post patches some time soon to get into
wireless-dev.
joha
On Tue, Feb 13, 2007 at 03:29:04PM +0200, Hasso Tepper wrote:
> There is long standing issue in kernel which makes using /etc/sysctl.conf
> useless for boottime configuration of specific interface properties and
> breaks probably any software relying on unconditional existence of the
> conf trees l
Neil Horman wrote:
On Tue, Feb 13, 2007 at 03:29:04PM +0200, Hasso Tepper wrote:
There is long standing issue in kernel which makes using /etc/sysctl.conf
useless for boottime configuration of specific interface properties and
breaks probably any software relying on unconditional existence of th
John wrote:
> Jesse Brandeburg wrote:
>> What would you like to do? At this stage I would like e100 to work
>> better than it is, but I'm not sure what to do next.
>
> Hello everyone,
>
> I'm resurrecting this thread because it appears we'll need to support
> these motherboards for several month
On Tue, Feb 13, 2007 at 02:43:32PM -0500, Vlad Yasevich wrote:
> Neil Horman wrote:
> >On Tue, Feb 13, 2007 at 03:29:04PM +0200, Hasso Tepper wrote:
> >>There is long standing issue in kernel which makes using /etc/sysctl.conf
> >>useless for boottime configuration of specific interface properties
Stephen Hemminger wrote:
> > You can disable it in /proc/sys/net/ipv6/conf/default/... and then
> > reenable it on the interfaces that you actually want.
And YOSHIFUJI Hideaki answered to this:
> The point is:
>
> - Until we have live address(es), we do not create inet6_dev{} for that
>devi
Ismail Dönmez wrote:
On Tuesday 13 February 2007 17:10:24 Jeff Chua wrote:
On 2/13/07, Ismail Dönmez <[EMAIL PROTECTED]> wrote:
Tried this is on a patched 2.6.20 kernel with ipw3945 device and it
always puts the card in 802.11a mode instead of 802.11bg mode.
Ideas?
Before running "iwconfig w
Johannes Berg wrote:
On Tue, 2007-02-13 at 18:13 +, Pavel Machek wrote:
Yes... is there merged .git tree somewhere? I downloaded iwl git tree,
but it did not contain d80211 stack. I'm now downloading wireless-dev
git tree...
I would expect Intel to post patches some time soon to get into
Norbert Preining wrote:
...
Ahhh ... one thing: The LED on my Acer Laptop (TM3012) does not show up,
maybe because I have CONFIG_D80211_LEDS off?
The LED code in iwlwifi isn't hooked up to the D80211 LED code yet. If
you'd file a bug at http://bughost.org regarding the LEDs being broken
(if
Convert pci_module_init() to pci_register_driver().
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with "allyes", "allmod" & "allno" on i386
diff --git a/drivers/net/wan/pc300too.c b/drivers/net/wan/pc300too.c
index bc156b5..aff05db 100644
--- a/drivers/net/wan/pc300too.c
Pavel Machek wrote:
...
You can find the new driver, and additional information
about it, here:
http://intellinuxwireless.org/iwlwifi.
...
You can find that package at:
http://intellinuxwireless.org/d80211
Ok. Now... any questions?
Yes... is there merged .git tree somewhere? I downlo
97 matches
Mail list logo
