On Wed, Aug 16, 2006 at 11:22:28AM -0600, Eric W. Biederman wrote:
> Stephen Hemminger <[EMAIL PROTECTED]> writes:
>
> > On Tue, 15 Aug 2006 18:48:43 +0400
> > Andrey Savochkin <[EMAIL PROTECTED]> wrote:
> >
> >> Temporary code to play with network namespaces in the simplest way.
> >> Do
> >>
On Wed, 16 Aug 2006 20:58:28 -0700
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> >>Testcase:
> >>
> >>Mount an NBD device as sole swap device and mmap > physical RAM, then
> >>loop through touching pages only once.
> >
> > Fix: d
On Wed, Aug 16, 2006 at 09:48:37PM -0700, Daniel Phillips ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> >On Sun, Aug 13, 2006 at 01:16:15PM -0700, Daniel Phillips
> >([EMAIL PROTECTED]) wrote:
> >>Indeed. The rest of the corner cases like netfilter, layered protocol and
> >>so on need t
Evgeniy Polyakov wrote:
On Mon, Aug 14, 2006 at 08:45:43AM +0200, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
Just pure openssh for control connection (admin should be able to
login).
These periods of degenerated functionality should be short and
infrequent albeit critical for machine recovery.
The patches have been tested with allmodconfig and allmodconfig.
drivers/message/fusion/linux_compat.h |9 -
drivers/mtd/nand/au1550nd.c | 11 --
drivers/net/acenic.c |4 --
drivers/net/irda/vlsi_ir.h| 17 -
drivers/net/tokenring/lans
The patches have been tested with allmodconfig and allmodconfig.
drivers/message/fusion/linux_compat.h |9 -
drivers/mtd/nand/au1550nd.c | 11 --
drivers/net/acenic.c |4 --
drivers/net/irda/vlsi_ir.h| 17 -
drivers/net/tokenring/lans
Evgeniy Polyakov wrote:
On Sun, Aug 13, 2006 at 01:16:15PM -0700, Daniel Phillips ([EMAIL PROTECTED])
wrote:
Indeed. The rest of the corner cases like netfilter, layered protocol and
so on need to be handled, however they do not need to be handled right now
in order to make remote storage on a
Andrew Morton wrote:
What is a "socket wait queue" and how/why can it consume so much memory?
Two things:
1) sk_buffs in flight between device receive interrupt and layer 3
protocol/socket identification.
2) sk_buffs queued onto a particular socket waiting for some task to
come
Andrew Morton wrote:
Peter Zijlstra <[EMAIL PROTECTED]> wrote:
Testcase:
Mount an NBD device as sole swap device and mmap > physical RAM, then
loop through touching pages only once.
Fix: don't try to swap over the network. Yes, there may be some scenarios
where people have no local storage,
possible PCI posting bug?
--- linux-2.6.orig/drivers/net/skge.c
+++ linux-2.6/drivers/net/skge.c
@@ -2745,7 +2745,7 @@ static int skge_poll(struct net_device *
spin_lock_irq(&hw->hw_lock);
hw->intr_mask |= rxirqmask[skge->port];
skge_write32(hw, B0_IMSK, hw->intr_mask);
-
On Wed, 2006-08-16 at 18:33 -0700, Piet Delaney wrote:
> I came across your Sept 2005 LKML and NetDev posting:
>
> http://lwn.net/Articles/152989/
>
> and was wondering what's been going on with this
> since your posting. Looks like an interesting
> patch that may be useful in our environme
On Wed, Aug 16, 2006 at 04:32:52PM -0700, David Miller wrote:
> From: [EMAIL PROTECTED] (Linas Vepstas)
> > Why would you want to do this? It seems like a cruddier strategy
> > than what we can already do (which is to never get an transmit
> > interrupt, as long as the kernel can shove data into
On Wed, Aug 16, 2006 at 11:06:31AM -0700, Stephen Hemminger wrote:
>
> agree. I assume this came in with the new GSO for 2.6.18 or do we need
> to fix 2.6.17 as well.
I think 2.6.17 should be fine because it would only happen there if
the underlying device itself had an inconsistent configuration
On Fri, 2006-08-11 at 12:08 -0500, Linas Vepstas wrote:
>
> Implement basic low-watermark support for the transmit queue.
>
> The basic idea of a low-watermark interrupt is as follows.
> The device driver queues up a bunch of packets for the hardware
> to transmit, and then kicks he hardware to g
On Thu, Aug 17, 2006 at 01:03:20AM +0200, Arnd Bergmann wrote:
>
> Could well be related to latencies when going to the remote
> node for descriptor DMAs. Have you tried if the hch's NUMA
> patch or using numactl makes a difference here?
No. I guess I should try.
> > > sounds like the right appr
Same approach as for IPv4, simplifies the interface
and makes it extendable without breaking the ioctl
interface.
Same memory corruption fixes in RTM_GETROUTE as for IPv4.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majord
Fixes various unvalidated netlink attributes causing memory
corruptions when left empty by userspace applications.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19.git/net/ipv6/route.c
===
--- net-2.6.19.git.orig/net/
Provide a simple ip6_del_rt() for the majority of users and
an alternative for the exception via netlink. Avoids code
obfuscation.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19.git/include/net/ip6_route.h
===
--- n
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19.git/net/core/rtnetlink.c
===
--- net-2.6.19.git.orig/net/core/rtnetlink.c
+++ net-2.6.19.git/net/core/rtnetlink.c
@@ -188,22 +188,27 @@ void rtnl_set_sk_err(u32 group, i
Provide a simple ip6_ins_rt() for the majority of users and
an alternative for the exception via netlink. Avoids code
obfuscation.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.19.git/include/net/ip6_route.h
===
--- n
Replaces the struct in6_rtmsg based interface orignating from
the ioctl interface with a struct fib6_config based on. Allows
changing the interface without breaking the ioctl interface
and avoids passing on tons of parameters.
The recently introduced struct nl_info is used to pass on
netlink autho
From: [EMAIL PROTECTED] (Linas Vepstas)
Date: Wed, 16 Aug 2006 18:30:28 -0500
> Why would you want o do this? It seems like a cruddier strategy
> than what we can already do (which is to never get an transmit
> interrupt, as long as the kernel can shove data into the device fast
> enough to keep
On Thu, Aug 17, 2006 at 12:16:46AM +0200, Arnd Bergmann wrote:
> Am Wednesday 16 August 2006 23:32 schrieb David Miller:
> > Can spidernet be told these kinds of parameters? "N packets or
> > X usecs"?
>
> It can not do exactly this but probably we can get close to it by
Why would you want o do
On Wed, Aug 16, 2006 at 02:32:03PM -0700, David Miller wrote:
>
> The best schemes seem to be to interrupt mitigate using a combination
> of time and number of TX entries pending to be purged. This is what
> most gigabit chips seem to offer.
I seem to be having a multi-hour delay for email deliv
Linas Vepstas wrote:
On Wed, Aug 16, 2006 at 11:24:46PM +0200, Arnd Bergmann wrote:
it only
seems to be hard to make it go fast using any of them.
Last round of measurements seemed linear for packet sizes between
60 and 600 bytes, suggesting that the hardware can handle a
maximum of 120K d
Am Thursday 17 August 2006 00:55 schrieb Linas Vepstas:
> > it only
> > seems to be hard to make it go fast using any of them.
>
> Last round of measurements seemed linear for packet sizes between
> 60 and 600 bytes, suggesting that the hardware can handle a
> maximum of 120K descriptors/second, in
On Wed, 16 Aug 2006 23:50:26 +0100
Ritesh Taank <[EMAIL PROTECTED]> wrote:
> Hi there,
>
> I am currently using netem that has been packaged with my linux kernel
> 2.6.17 (as part of the Knoppix 5.0.1 Boot CD), and the 'corrupt'
> parameter is not being recognised as a valid argument.
>
> Havi
Ritesh Taank wrote:
Hi there,
I am currently using netem that has been packaged with my linux kernel
2.6.17 (as part of the Knoppix 5.0.1 Boot CD), and the 'corrupt'
parameter is not being recognised as a valid argument.
Having read many posts online, it appears that the Packet Corruption
f
On Wed, Aug 16, 2006 at 11:24:46PM +0200, Arnd Bergmann wrote:
>
> it only
> seems to be hard to make it go fast using any of them.
Last round of measurements seemed linear for packet sizes between
60 and 600 bytes, suggesting that the hardware can handle a
maximum of 120K descriptors/second, i
I thought that support statement sounded familiar, large portions of
the source code and documentation are modified from an older release
of e1000. Nothing wrong with that as it's released under the GPL,
except that the copyright statements have mostly just been switched
from Intel to Attansic.
Hi there,
I am currently using netem that has been packaged with my linux kernel
2.6.17 (as part of the Knoppix 5.0.1 Boot CD), and the 'corrupt'
parameter is not being recognised as a valid argument.
Having read many posts online, it appears that the Packet Corruption
feature should be supp
Am Thursday 17 August 2006 00:29 schrieb David Miller:
> Didn't you say spidernet's facilities were sophisticated? :)
> This Tigon3 stuff is like 5+ year old technology.
I was rather overwhelmed by the 34 different interrupts that
the chip can create, that does not mean they chose the right
events
Hello!
> send out any delayed ACKs when it is clear that the receiving process is
> waiting for more data?
It has just be done in tcp_cleanup_rbuf() a few lines before your chunk.
There is some somplex condition to be satisfied there and it is
impossible to relax it any further.
I do not know w
From: Arnd Bergmann <[EMAIL PROTECTED]>
Date: Thu, 17 Aug 2006 00:16:46 +0200
> Am Wednesday 16 August 2006 23:32 schrieb David Miller:
> > Can spidernet be told these kinds of parameters? "N packets or
> > X usecs"?
>
> It can not do exactly this but probably we can get close to it by
Oh, you
Am Wednesday 16 August 2006 23:32 schrieb David Miller:
> Can spidernet be told these kinds of parameters? "N packets or
> X usecs"?
It can not do exactly this but probably we can get close to it by
1.) Setting a one-time interrupt to fire x*10µs after putting a
packet into the TX queue.
and
Kernel 2.4.32 r8169 driver was missing change MTU.
It is back-ported from the kernel 2.6.16 r8169 driver.
Performance went from 40 megabyte/second (MTU 1500) to 58 megabyte/second
(MTU 7200) when testing with custom http server and wget for client.
Target and destination were both tmpfs volumes.
On Wed, Aug 16, 2006 at 01:46:40PM -0700, David Miller wrote:
> From: Jeff Garzik <[EMAIL PROTECTED]>
> Date: Wed, 16 Aug 2006 16:34:31 -0400
>
> > Linas Vepstas wrote:
> > > I was under the impression that NAPI was for the receive side only.
> >
> > That depends on the driver implementation.
>
>> Stephen,
>>
>> the reproducible crashes with all skge versions (where sk98lin works
>> fine) on my box are SMP related.
>> I booted with maxcpus=1 and the box survived my usual crash test, I will
>> keep an eye.
>>
>> Daniel
>>
> Is this P3 SMP?
> What form of IRQ balance are you using?
Ind
Signed-off-by: Manasi Deval <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/ixgb/ixgb_hw.c | 11 +++
drivers/net/ixgb/ixgb_ids.h |1 +
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_hw.c b/drivers/net/ixgb/ixgb
Reduce writeback threshold by 1. We were instructing the hardware to
wait until the 17th descriptor which went over the cache line limit.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/ixgb/ixgb_main.c | 12 ++--
1 files
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/ixgb/ixgb_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index 770eef2..b1cf852 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ix
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 978e3b7..815abe5 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/driver
Disable aggressive clocking on esb2 with SERDES port as it causes
hardware problems.
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/n
Remove pci ID 8086:1000 from the list fo supported devices. This device
has not functioned with the driver for very long (since v. 5.2.4!)
and we lack the resources to come with a substantial fix. There are only
few cards of this type out there.
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Sig
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_hw.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_hw.c b/drivers/net/e1000/e1000_hw.c
index 3728f33..8eddfdf 1006
Hi,
Here are updates targeted to branch #upstream-fixes from netdev-2.6, including
fixes to e100, e1000 and ixgb.
Summary:
---
Manasi Deval
ixgb: Add CX4 PHY type detection and subdevice ID.
Jesse Brandeburg
e1000: Explicitly power up the PHY during loopback testing.
e1000: Explici
Explicitly lock two more ethtool entry points completely instead
of the hardware reset only to prevent a race condition.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_ethtool.c | 33 +++--
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_ethtool.c |7 +++
drivers/net/e1000/e1000_main.c|2 +-
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000/e1000_ethtool.c
b/dr
MDIO/MDIO-X was broken due to a wrong errata. Removing the workaround
code fixes for affected NICs.
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e100.c | 14 +-
1 files changed, 5 insertions(+), 9 deletions(-)
diff --
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 627f224..ea3d504 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/driver
Increment the version of e100 to 3.5.10-k4, increment dates.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e100.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index 5de9843..e208c09 100644
--- a/drivers/net
Allow NVM to setup LPLU for IGP2 and IGP3. Only IGP needs LPLU D3
disabled during init here.
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_hw.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff
On Wed, Aug 16, 2006 at 12:11:12PM -0700, Stephen Hemminger wrote:
> > is throttled waiting for ACKs to arrive. The problem is exacerbated when
> > the sender is using a small send buffer -- running netperf -C -c -- -s 1024
> > show a miserable 420Kbit/s at essentially 0% CPU usage. Tests over
The point of delayed ack's was to merge the response and the ack on
request/response
protocols like NFS or telnet. It does make sense to get it out sooner though.
Well, to a point at least - I wouldn't go so far as to suggest immediate
ACKs.
However, I was always under the impression that AC
From: Arnd Bergmann <[EMAIL PROTECTED]>
Date: Wed, 16 Aug 2006 23:24:46 +0200
> We first had an interrupt per descriptor, then got rid of all TX
> interrupts and replaced them by timers to reduce the interrupt load,
> but reducing throughput in the case where user space sleeps on a full
> socket b
Am Wednesday 16 August 2006 22:46 schrieb David Miller:
> I'm not familiar with the spidernet TX side interrupt capabilities
> so I can't say whether that is something that can be directly
> implied. In fact, I get the impression that spidernet is limited
> in some way and that's where all the str
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 16 Aug 2006 12:11:12 -0700
> What ethernet hardware? The defaults are often not big enough
> for full speed on gigabit hardware. I need increase rmem/wmem to allow
> for more buffering.
Current kernels allow the TCP send and receive socket b
On Wed, 16 Aug 2006 13:44:43 -0500
John Haller <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote:
> > On Tue, 15 Aug 2006 18:23:19 -0500
> > Jay Cliburn <[EMAIL PROTECTED]> wrote:
> >
> >> Stephen Hemminger wrote:
> >>> On Sun, 13 Aug 2006 19:11:42 -0500
> >>> Jay Cliburn <[EMAIL PROTECTED]> w
On Wed, 16 Aug 2006 16:55:32 -0400
Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
> Hello folks,
>
> In looking at a few benchmarks (especially netperf) run locally, it seems
> that tcp is unable to make full use of available CPU cycles as the sender
> is throttled waiting for ACKs to arrive. The
Last year I reported to the linux-hams list and to Tom Sailer
that I could not get AX25 to work using a serial baycom modem with
baycom_ser_fdx under vanilla kernel 2.6.11.6 although it ran fine
under kernel 2.4.30:
http://he.fi/archive/linux-hams/200505/0021.html
I got no answer, but other people
Hello folks,
In looking at a few benchmarks (especially netperf) run locally, it seems
that tcp is unable to make full use of available CPU cycles as the sender
is throttled waiting for ACKs to arrive. The problem is exacerbated when
the sender is using a small send buffer -- running netperf -
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Wed, 16 Aug 2006 16:34:31 -0400
> Linas Vepstas wrote:
> > I was under the impression that NAPI was for the receive side only.
>
> That depends on the driver implementation.
What Jeff is trying to say is that TX reclaim can occur in
the NAPI poll routi
Linas Vepstas wrote:
I was under the impression that NAPI was for the receive side only.
That depends on the driver implementation.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vg
On Wed, Aug 16, 2006 at 12:30:29PM -0400, Jeff Garzik wrote:
> Linas Vepstas wrote:
> >
> >The recent set of low-waterark patches for the spider result in a
>
> Let's not reinvented NAPI, shall we...
??
I was under the impression that NAPI was for the receive side only.
This round of patches we
On Wed, Aug 16, 2006 at 12:45:54PM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> > >>> + for (i=0; ikevent_list); ++i)
> > >> for (i = 0; i < ARRAY_SIZE(u->kevent_list); i++)
> > >
> > > Ugh, no. It reduces readability due to exessive number of spaces.
> >
> > Ihavetoverystronglydisagr
Nicolas Pitre wrote:
On Mon, 14 Aug 2006, [EMAIL PROTECTED] wrote:
From: Russell King <[EMAIL PROTECTED]>
When booting using root-nfs, I'm seeing (independently) two lockdep dumps
in the smc91x driver. The patch below fixes both. Both dumps look like
real locking issues.
Nico - please revie
From: Zach Brown <[EMAIL PROTECTED]>
Date: Wed, 16 Aug 2006 11:08:41 -0700
> >>> + for (i=0; ikevent_list); ++i)
> >>for (i = 0; i < ARRAY_SIZE(u->kevent_list); i++)
> >
> > Ugh, no. It reduces readability due to exessive number of spaces.
>
> Ihavetoverystronglydisagree.
Metoo. :-)
Spaces
On Mon, 14 Aug 2006, [EMAIL PROTECTED] wrote:
> From: Russell King <[EMAIL PROTECTED]>
>
> When booting using root-nfs, I'm seeing (independently) two lockdep dumps
> in the smc91x driver. The patch below fixes both. Both dumps look like
> real locking issues.
>
> Nico - please review and ack
On Wed, Aug 16, 2006 at 09:57:12AM -0700, Stephen Hemminger ([EMAIL PROTECTED])
wrote:
> IMHO the network memory allocator is being a little too focused on one
> problem,
> rather than looking at a general enhancement.
>
> Have you looked into something like the talloc used by Samba (and others)
This patch is still being white space munged so it doesn't apply.
The context is being shifted over 1 column. All your other patches add
new files so there is no context and hence they apply.
Mikey
In message <[EMAIL PROTECTED]> you wrote:
> Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]
On Mon, 14 Aug 2006, David Miller wrote:
From: Jay Vosburgh <[EMAIL PROTECTED]>
Date: Thu, 03 Aug 2006 18:01:35 -0700
In this case (bond0.555 above bond0 above eth0,eth1,etc),
skb_bond doesn't suppress duplicates because skb_bond is called with the
skb->dev set to the bond0.555 dev,
On Wed, Aug 16, 2006 at 11:08:41AM -0700, Zach Brown ([EMAIL PROTECTED]) wrote:
>
> >>> + for (i=0; ikevent_list); ++i)
> >>for (i = 0; i < ARRAY_SIZE(u->kevent_list); i++)
> >
> > Ugh, no. It reduces readability due to exessive number of spaces.
>
> Ihavetoverystronglydisagree.
W e l l , i
Michal,
I believe the patch I submitted yesterday fixes this
problem, and in a simpler way.
+-DLS
-
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.k
Stephen Hemminger wrote:
On Tue, 15 Aug 2006 18:23:19 -0500
Jay Cliburn <[EMAIL PROTECTED]> wrote:
Stephen Hemminger wrote:
On Sun, 13 Aug 2006 19:11:42 -0500
Jay Cliburn <[EMAIL PROTECTED]> wrote:
...snip...
I've read the LKML FAQ regarding new driver submissions, but it implies
that the su
Brandeburg, Jesse <[EMAIL PROTECTED]> wrote:
>Kok, Auke-jan H wrote:
>> Auke Kok wrote:
>>> Jay Vosburgh wrote:
Running both 2.6.17.6 plus the e1000 7.2.7 from sourceforge, or
the e1000 in netdev-2.6#upstream (7.1.9-k4).
Starting up "ethtool -p ethX" then unplugging the
> It is done by scripts using list of files generated by git-diff, but I
> can reformat them to be in a way:
Perhaps you should think about maintaining them as an explicit series of
patches, say with quilt or mq, instead of as one repository that you try
and cut up into separate patches.
- z
-
T
On Wed, 16 Aug 2006 11:29:00 +1000
Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 15, 2006 at 11:29:59AM -0700, [EMAIL PROTECTED] wrote:
> > http://bugzilla.kernel.org/show_bug.cgi?id=6936
>
> It's actually a bug in the bridging code :)
>
> [BRIDGE]: Disable SG/GSO if TX checksum is off
>
>>> + for (i=0; ikevent_list); ++i)
>> for (i = 0; i < ARRAY_SIZE(u->kevent_list); i++)
>
> Ugh, no. It reduces readability due to exessive number of spaces.
Ihavetoverystronglydisagree.
- z
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [
On Tue, 15 Aug 2006 18:23:19 -0500
Jay Cliburn <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote:
> > On Sun, 13 Aug 2006 19:11:42 -0500
> > Jay Cliburn <[EMAIL PROTECTED]> wrote:
> ...snip...
> >> I've read the LKML FAQ regarding new driver submissions, but it implies
> >> that the submitter b
On Wed, 16 Aug 2006 19:47:08 +0200
"Beschorner Daniel" <[EMAIL PROTECTED]> wrote:
> Stephen,
>
> the reproducible crashes with all skge versions (where sk98lin works
> fine) on my box are SMP related.
> I booted with maxcpus=1 and the box survived my usual crash test, I will
> keep an eye.
>
> D
I'd suggest that the new signal strength measure should be defined as
'RCPI' - the 'Received Channel Power Indicator' - which is defined in
IEEE 802.11k (the Radio Measurements amendment to 802.11). Here is the
full text of the definition from 802.11k draft 5.0:
received channel power indicator (
Stephen,
the reproducible crashes with all skge versions (where sk98lin works
fine) on my box are SMP related.
I booted with maxcpus=1 and the box survived my usual crash test, I will
keep an eye.
Daniel
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message
Alexey Kuznetsov <[EMAIL PROTECTED]> writes:
> Hello!
>
>> (application) containers. Performance aside, are there any reasons why
>> this approach would be problematic for c/r?
>
> This approach is just perfect for c/r.
Yes. For c/r you need to take your state with you.
> Probably, this is the
On Tue, 8 Aug 2006 16:30:12 +0200, Ivo van Doorn wrote:
> This will add the rfkill driver to the input/misc section of the kernel.
> rfkill is usefull for newtwork devices that contain a hardware button
> to enable or disable the radio.
> With rfkill a generic interface is created for the network d
Stephen Hemminger <[EMAIL PROTECTED]> writes:
> On Tue, 15 Aug 2006 18:48:43 +0400
> Andrey Savochkin <[EMAIL PROTECTED]> wrote:
>
>> Temporary code to play with network namespaces in the simplest way.
>> Do
>> exec 7< /proc/net/net_ns
>> in your bash shell and you'll get a brand new netwo
On Mon, 14 Aug 2006 10:12:01 +0200, Johannes Berg wrote:
> I'd like to see a link from the wiphy to the master interface that
> belongs to it so one can tell this easily on systems that have multiple
> wireless devices.
As wiphy and master interface are closely bind to each other, this makes
sen
IMHO the network memory allocator is being a little too focused on one problem,
rather than looking at a general enhancement.
Have you looked into something like the talloc used by Samba (and others)?
http://talloc.samba.org/
http://samba.org/ftp/unpacked/samba4/source/lib/talloc/t
On Tue, 15 Aug 2006 18:48:43 +0400
Andrey Savochkin <[EMAIL PROTECTED]> wrote:
> Temporary code to play with network namespaces in the simplest way.
> Do
> exec 7< /proc/net/net_ns
> in your bash shell and you'll get a brand new network namespace.
> There you can, for example, do
>
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
MAINTAINERS | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 21116cc..2d484aa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -881,6 +881,12 @@ M: [EMAIL PROTECTED]
L: linux-k
On Wed, 16 Aug 2006 07:46:43 -0700
Dave Hansen <[EMAIL PROTECTED]> wrote:
> On Tue, 2006-08-15 at 18:48 +0400, Andrey Savochkin wrote:
> >
> > /* Can survive without statistics */
> > stats = kmalloc(sizeof(struct net_device_stats), GFP_KERNEL);
> > if (stats) {
> >
Arjan van de Ven wrote:
> On Wed, 2006-08-16 at 18:06 +0200, Michael Buesch wrote:
>> On Wednesday 16 August 2006 05:54, Larry Finger wrote:
>>>
>>> I'm at a loss here. Can anyone explain how to interpret this dump? I
>>> think I see a general protection fault, but what to do from there is a
>>> my
Michael Buesch wrote:
>
> Hm, weird bug.
> I can't reproduce this on i386 or PPC.
> Could it be a bug in the lockdep code?
>
It could be. I'll send it on to LKML. Perhaps one of the experts
there can tell us. It doesn't seem to cause any trouble, but I get
one of these when bcm43xx starts.
Are
Linas Vepstas wrote:
Please apply and forward upstream. This patch requires the previous
sequence of 4 spidernet patches to be applied.
--linas
The recent set of low-waterark patches for the spider result in a
significant amount of computing being done in an interrupt context.
This patch moves
On Wed, 2006-08-16 at 18:06 +0200, Michael Buesch wrote:
> On Wednesday 16 August 2006 05:54, Larry Finger wrote:
> > Using vanilla wireless-2.6 from Linville's tree as updated today, I
> > get a warning generated by the statement
> > if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
> > in kerne
Please apply and forward upstream. This patch requires the previous
sequence of 4 spidernet patches to be applied.
--linas
The recent set of low-waterark patches for the spider result in a
significant amount of computing being done in an interrupt context.
This patch moves this to a "bottom hal
John,
Please pull this patch by MB for the wireless-2.6 tree. It
replaces the one sent earlier today. Somehow, I managed to mangle
it by deleting a semicolon.
Larry
This patch depends on the 64bit DMA patch, which is already
submitted for
On Wednesday 16 August 2006 05:54, Larry Finger wrote:
> Using vanilla wireless-2.6 from Linville's tree as updated today, I
> get a warning generated by the statement
> if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
> in kernel.lockdep.c. This warning only occurs when my wireless
> interface
On Wednesday 16 August 2006 17:52, Larry Finger wrote:
> Johannes Berg wrote:
> > On Wed, 2006-08-16 at 10:36 -0500, Larry Finger wrote:
> >> + /* Boolean. Is this a TX ring? */
> >> + u8 tx
> >> + /* Boolean. 64bit DMA if true, 32bit DMA otherwise. */
> >> + u8 dma64;
> >
> > does that compil
Michael Buesch wrote:
> On Wednesday 16 August 2006 17:52, Larry Finger wrote:
>> Johannes Berg wrote:
>>> On Wed, 2006-08-16 at 10:36 -0500, Larry Finger wrote:
+ /* Boolean. Is this a TX ring? */
+ u8 tx
+ /* Boolean. 64bit DMA if true, 32bit DMA otherwise. */
+ u8 dma64;
Johannes Berg wrote:
> On Wed, 2006-08-16 at 10:36 -0500, Larry Finger wrote:
>> +/* Boolean. Is this a TX ring? */
>> +u8 tx
>> +/* Boolean. 64bit DMA if true, 32bit DMA otherwise. */
>> +u8 dma64;
>
> does that compile?
>
> johannes
>
Yes, it did here. Did you have a problem?
1 - 100 of 175 matches
Mail list logo
