From: "Leigh Brown" <[EMAIL PROTECTED]>
Date: Sun, 17 Dec 2006 18:13:06 - (GMT)
> It was all going so well, and then it deadlocked. What can be done
> about this?
Sorry for taking so long about this.
The problem is that tcp_md5sig_pool_lock is taken in both
software-interrupt and non-softwa
From: Divy Le Ray <[EMAIL PROTECTED]>
Date: Tue, 20 Feb 2007 23:39:55 -0800
> I applied the patch to test the chelsio drivers.
> The compilation of the forcedeth driver fails if CONFIG_FORCEDETH_NAPI
> is not set.
> /opt/sources/linux-2.6/drivers/net/forcedeth.c: In function `nv_nic_irq':
> /opt/
Hi,
> This looks great! Two questions. I would assume that the of_device
> results in a "devspec" file in the sysfs directory for the port? Also,
yes, that is true. There is a devspec file containing the ofdt path in the
port directory.
> is there a way to correlate a logical port to an ether
David Miller wrote:
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 13 Dec 2006 15:46:35 -0800
Split off NAPI part from network device, this patch is build tested
only! It breaks kernel API for network devices, and only three examples
are fixed (skge, sky2, and tg3).
1. Decomposition
On Tue, 20 Feb 2007 22:23:21 -0800 Stephen Hemminger wrote:
> BUilding with sparse shows lots of warnings.
>
>
> $ make C=1
> Checking kernel compatibility in:
> /lib/modules/2.6.20.1/source
> * Kernel supports required features for 'tip' version.
> Building compatibility version in 'compat
SPX was removed in early 2.5. How to connect to a Mac or the other OS isn't
hard to find out these days.
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
---
commit 0566e9a5f19ca9fe1982e2b4a89aff131cc6525b
tree 20b72b4e347a0ff926f82188bb296c2b3a8911f5
parent ce4e52a8be675c1724fa3af503ff1c75478ff
Who cares about stuff describing what happened in early 2.5 days? Even worse
is to reference Kconfig options removed back then. Go, rest in pieces.
Eike
pgpWbqv7vWWdc.pgp
Description: PGP signature
[IPX] Remove ancient changelog
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
---
commit 6b8afc66b9d6893d3fa292b75769b58539836ff3
tree 9078513bb6727e61aee238da153d9b3358a1d817
parent 0566e9a5f19ca9fe1982e2b4a89aff131cc6525b
author Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 20 Feb 2007 19:45:03 +0
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Fri, 16 Feb 2007 19:39:43 -0800
> [SCTP]: Implement SCTP_FRAGMENT_INTERLEAVE socket option.
Sorry, these patches missed the merge window.
Patches 4 and 5 are bug fixes, so I could apply just those if you
want me to, just let me know and you don't
From: Jason Lunz <[EMAIL PROTECTED]>
Date: Wed, 14 Feb 2007 18:35:58 -0500
> packet_lookup_frame() always returns tpacket_hdr*, so there's no reason
> to return char* and require casting by callers.
>
> Also, remove a cast of void*.
>
> Signed-off-by: Jason Lunz <[EMAIL PROTECTED]>
Applied, tha
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Date: Thu, 15 Feb 2007 02:35:14 +0900 (JST)
> Please consider pulling the following changesets available on the
> 2.6.20-net-2.6-20070214-FOR_DAVEM
> branch at
>
> (on top of commit 928ba4169dc1d82c83105831f5ddb5472379b440).
Unfortunately,
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Tue, 20 Feb 2007 19:50:15 -0800
> [TG3]: TSO workaround fixes.
>
> 1. Add race condition check after netif_stop_queue(). tg3_tx() runs
> without netif_tx_lock and can race with tg3_start_xmit_dma_bug() ->
> tg3_tso_bug().
>
> 2. Firmware
BUilding with sparse shows lots of warnings.
$ make C=1
Checking kernel compatibility in:
/lib/modules/2.6.20.1/source
* Kernel supports required features for 'tip' version.
Building compatibility version in 'compatible/' directory:
Copying compatible/ from origin/...done
make -C /lib/modules
Hi,
Thank you for your comment.
> this looks a lot better than the previous patch!! However, we already have a
> state marker for _down_ that we should probably reuse. Can you try the
> attached
> patch and see if it works for you? It's basically your patch without the
> added
> remove flag
[TG3]: TSO workaround fixes.
1. Add race condition check after netif_stop_queue(). tg3_tx() runs
without netif_tx_lock and can race with tg3_start_xmit_dma_bug() ->
tg3_tso_bug().
2. Firmware TSO in 5703/5704/5705 also have the same TSO limitation,
i.e. they cannot handle TSO heade
On Mon, Feb 19, 2007 at 11:15:02PM -0800, Chris Wedgwood wrote:
> On Sun, Feb 11, 2007 at 04:57:55PM +0200, Matti Aarnio wrote:
> > With the skge driver there seems to be some sort of problem to work
> > in a system with memory above the 4 GB of PCI address space.
>
> The chipset (apparently) does
On Wed, 21 Feb 2007 01:19:41 +0300
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> If del_nbp()->cancel_delayed_work(carrier_check) fails, port_carrier_check()
> may run later and access an already freed container (struct net_bridge_port).
>
> With this patch, carrier_check owns a reference to "struct
If del_nbp()->cancel_delayed_work(carrier_check) fails, port_carrier_check()
may run later and access an already freed container (struct net_bridge_port).
With this patch, carrier_check owns a reference to "struct net_bridge_port",
not net_device, so it is always safe to acces the container.
port
Convert some initialized structures to C99 style.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/chelsio/subr.c | 195 ++---
1 file changed, 134 insertions(+), 61 deletions(-)
--- chelsio.orig/drivers/net/chelsio/subr.c
+++ chelsio/
There are several uses of _ops structure in this driver that
can be converted to const.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/chelsio/common.h|6 +++---
drivers/net/chelsio/cphy.h | 16 +++-
drivers/net/chelsio/gmac.h | 10 +++-
Some code for Chelsio 1G boards was put in the driver
based on the vendor version (minus TOE). Well some of those board
versions are only supported with TOE on the vendor driver, so additional
dead code was added.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/chelsio/Makef
Some janitorial type house cleaning of the Chelsio 10G driver.
Remove dead code spotted by Adrian and make iniatialization
logic clearer.
--
-
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
Hi!
> >>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 tre
On 2/21/07, bert hubert <[EMAIL PROTECTED]> wrote:
I'm trying to figure out which processes have the most impact, I had already
killed anything non-essential. But that still leaves 140 pids.
Bert
That sounds way too many pids. I run a script to shut down processes
when I do testing as
Update driver support contact info.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: Jens Osterkamp <[EMAIL PROTECTED]>
Cc: Kou Ishizaki <[EMAIL PROTECTED]>
MAINTAINERS |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.20-git16/MAINTAINERS
=
Janitorial patch. Undo long lines, fix typo in err msg.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: Jens Osterkamp <[EMAIL PROTECTED]>
Cc: Kou Ishizaki <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 13 +++--
drivers/net/spider_net.h |2 +-
2 files changed, 8 insert
Multiple threads performing a transmit can race into
the spidernet tx ring cleanup code. This puts the
relevant check under a lock.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: Jens Osterkamp <[EMAIL PROTECTED]>
Cc: Kou Ishizaki <[EMAIL PROTECTED]>
drivers/net/spider_net.c |6
This patch separates the hardware descriptor state from the
driver descriptor state, per (old) suggestion from Ben Herrenschmidt.
This compiles and boots and seems to work.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: Jens Osterkamp <[EMAIL PROTECTED]>
Cc: Kou Ishizaki <[EMAIL PROTECTED
It appears that under certain circumstances, a race will result
in a double-free of an skb. This patch null's out the skb pointer
upon the skb free, avoiding the inadvertent deref of bogus data.
The next patch fixes the actual race.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: Jens Osterk
From: Jens Osterkamp <[EMAIL PROTECTED]>
This moves the medium variable into the spidernet card structure.
It renames the GMII_ variables to BCM54XX specific ones.
Signed-off-by: Jens Osterkamp <[EMAIL PROTECTED]>
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c |
From: Ishizaki Kou <[EMAIL PROTECTED]>
This patches removes logging for SPIDER_NET_GTMFLLINT interrupts.
Since the interrupts are not irregular, and they happen frequently
when using 100Mbps network switches.
Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]>
Signed-off-by: Linas Vepstas <[EMAIL PR
From: Kou Ishizaki <[EMAIL PROTECTED]>
This patch adds or changes some HW specific settings for spider_net on
Celleb.
Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]>
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/Kconfig |2 +-
drivers/net/spider_net.c |8 ++
From: Kou Ishizaki <[EMAIL PROTECTED]>
This patch moves calling init_firmware() from spider_net_probe() to
spider_net_open() so as to use the driver by built-in.
Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]>
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 24
From: Kou Ishizaki <[EMAIL PROTECTED]>
Add auto negotiation support for Celleb.
Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]>
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 176 ++-
drivers/net/spider_net.h | 1
As of 2.6.20-git4, the spider_net driver does not compile.
This appears to be due to some archaic usage involving kobjects.
It also fixes a nasty double-free during ifdown of the interface.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: Jens Osterkamp <[EMAIL PROTECTED]>
Cc: Kou Ishizaki
From: Jens Osterkamp <[EMAIL PROTECTED]>
This version moves the medium variable to the card specific structure and
changes the GMII_* to BCM54XX_* #defines.
This patch adds improved version of enable_fiber for both the 5421 and
the 5461 phy. It is now possible to specify with these wether you wa
> I'm trying to figure out which processes have the most impact, I had already
> killed anything non-essential. But that still leaves 140 pids.
btw if you have systemtap on your system you can see who is doing evil
with
http://www.fenrus.org/cstop.stp
also.. running "vmstat 3" and looking at th
On Tue, Feb 20, 2007 at 02:02:00PM -0800, Rick Jones wrote:
> The slope appears to be flattening-out the farther out to the right it
> goes. Perhaps that is the length of time it takes to take all the
> requisite cache misses.
The rate of flattening out appears to correlate with the number of
Jeff,
Please apply and forward upstream this patch series.
This is the followup to the collision of patches that
landed on your doorstep last week. It rolls up the
patches from Jens and Kou.
--linas
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message
On Tue, Feb 20, 2007 at 01:31:32PM -0800, Stephen Hemminger wrote:
> On Tue, 20 Feb 2007 01:02:14 +0100
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Nov 28, 2006 at 11:47:19PM -0800, Andrew Morton wrote:
> > > On Wed, 29 Nov 2006 08:36:09 +0100
> > > Adrian Bunk <[EMAIL PROTECTED]> wrote
I measure a huge slope, however. Starting at 1usec for back-to-back system
calls, it rises to 2usec after interleaving calls with a count to 20
million.
4usec is hit after 110 million.
The graph, with semi-scientific error-bars is on
http://ds9a.nl/tmp/recvfrom-usec-vs-wait.png
The code to gene
On Mon, Feb 19, 2007 at 06:59:16PM -0500, Lennart Sorensen wrote:
> I am also noticing the receive error count going up, and the source is
> this code:
>
> if (status & 0x01) /* Only count a general error at the */
>lp->stats.rx_errors++; /* end of a packet. */
>
> It appears this m
On Tue, 20 Feb 2007 01:02:14 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 28, 2006 at 11:47:19PM -0800, Andrew Morton wrote:
> > On Wed, 29 Nov 2006 08:36:09 +0100
> > Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> > > On Mon, Nov 27, 2006 at 10:24:55AM -0800, Stephen Hemminger wrote:
On Tue, 20 Feb 2007 21:45:05 +0100
bert hubert <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 20, 2007 at 02:40:40PM -0500, Benjamin LaHaise wrote:
>
> > Make sure your system is idle. Userspace bloat means that *lots* of idle
> > activity occurs in between timer ticks on recent distributions -- all
On Tue, Feb 20, 2007 at 02:40:40PM -0500, Benjamin LaHaise wrote:
> Make sure your system is idle. Userspace bloat means that *lots* of idle
> activity occurs in between timer ticks on recent distributions -- all those
You hit the nail on the head. I had previously measured with X shut down,
b
On 2/20/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
Correct. That's called a "weak hash", and Jenkins is known to be a
thoroughly weak hash. That's why you never, ever use it without a
salt, and you don't let an attacker inspect the hash output either.
Weak in a cryptographic sense, of
On 2/20/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
How I like personal insults - it is always fun to read about myself from
people who never knew me :)
On this occasion, I did not set out to insult you. I set out to
suggest an explanation for why cooler and grayer heads than mine are
not
On Mon, 19 Feb 2007 23:15:02 -0800
Chris Wedgwood <[EMAIL PROTECTED]> wrote:
> On Sun, Feb 11, 2007 at 04:57:55PM +0200, Matti Aarnio wrote:
>
> > With the skge driver there seems to be some sort of problem to work
> > in a system with memory above the 4 GB of PCI address space.
>
> The chipset
On Tue, Feb 20, 2007 at 08:17:31PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> I shown your test was bogus. All your claims are just bogus.
> I claim your 'true random data' is a joke. rand() in your program is a pure
> joke.
Care to reread your mail about your true random case with hash ch
On Tue, Feb 20, 2007 at 11:13:50AM -0800, Michael K. Edwards ([EMAIL
PROTECTED]) wrote:
> On 2/20/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >And here are another ones which produce the same hash value.
> >Of course searching for pair for jhash('jhash is broken')
> >will require more steps,
All right, Eric, you and me so clevvah, let's embarrass our own selves
designing this thing in public instead of picking on poor Evgeniy.
Which would you rather RCU, a 2-left hash or a splay tree? 2-left
hash gets you excellent occupation fraction before the first real
collision, so you can be ut
On Tue, Feb 20, 2007 at 08:33:20PM +0100, bert hubert wrote:
> I'm investigating this further for other system calls. It might be that my
> measurements are off, but it appears even a slight delay between calls
> incurs a large penalty.
Make sure your system is idle. Userspace bloat means that *l
On Tue, Feb 20, 2007 at 09:48:59PM +0300, Evgeniy Polyakov wrote:
> Likely first overhead related to cache population or gamma-ray radiation.
> If it happens only one (it does in my test), then everything is ok I
> think. Bert, how frequently you get that long recvfrom()?
I have plotted the avera
On Tuesday 20 February 2007 20:06, Evgeniy Polyakov wrote:
> > I added to my 'simulator_plugged_on_real_server' the average cost
> > calculation, relative to number of cache line per lookup.
> >
> > ehash_size=2^20
> > xor hash :
> > 386290 sockets, Avg lookup cost=3.2604 cache lines/lookup
> > 39
On 2/20/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
And here are another ones which produce the same hash value.
Of course searching for pair for jhash('jhash is broken')
will require more steps, but it is doable.
That means that if attacker has a full control over one host, it can
create a
On Tue, Feb 20, 2007 at 07:55:15PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> On Tuesday 20 February 2007 19:00, Evgeniy Polyakov wrote:
> > As you can see, jhash has problems in a really trivial case of 2^16,
> > which in local lan is a disaster. The only reason jenkins hash is good
> > for
On Fri, Feb 02, 2007 at 11:28:46AM -0800, Stephen Hemminger wrote:
> This patch does the Marvell errata before auto negotiation
> (from drivers/phy/marvell.c). The Yukon II chips have an internal
> version of the same PHY, so perhaps this errata is necessary for them
> as well.
>
> For test only,
You need the flow control fix and the tx_timeout fix posted for 2.6.20 (stable)
and current git tree.
-
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 Tuesday 20 February 2007 19:00, Evgeniy Polyakov wrote:
> As you can see, jhash has problems in a really trivial case of 2^16,
> which in local lan is a disaster. The only reason jenkins hash is good
> for hashing purposes is that is it more complex than xor one, and thus
> it is harder to find
Max Krasnyansky wrote:
Fixes an oops in the non-blocking mode.
Signed-off-by: Max Krasnyansky <[EMAIL PROTECTED]>
---
net/tipc/socket.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 2a6a5a6..767f791 100644
--- a/net/tipc/
Dave, Alan, Jon,
Max Krasnyansky wrote:
TIPC code is a bit inconsistent in masking out upper bits of various
message fields when packing them into the headers. For the most part
things seem to be ok but we happened to hit a corner case in our labs
when broadcast counter reached certain value (do
There seems to be an issue when both MSI-X is enabled and NAPI is
configured. This patch disables MSI-X until the issue is root caused.
Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
--- orig/drivers/net/forcedeth.c2007-02-20 03:29:04.0 -0500
+++ new/drivers/net/forcedeth.c 200
This patch removes checksum offload feature in mcp65 chipsets as they
are not supported in hw.
Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
--- orig/drivers/net/forcedeth.c2007-02-20 03:30:16.0 -0500
+++ new/drivers/net/forcedeth.c 2007-02-20 03:30:29.0 -0500
@@ -5374,
The napi poll routine was missing the call to the optimized rx process
routine. This patch adds the missing call for the optimized path.
Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
--- orig/drivers/net/forcedeth.c2007-02-20 03:17:21.0 -0500
+++ new/drivers/net/forcedeth.c 20
On Tue, Feb 20, 2007 at 01:42:42PM -0500, Josef Sipek ([EMAIL PROTECTED]) wrote:
> A better thing would be to use getuid - it turns into just a return with a
> memory dereference). I ran it on my 3.06GHz P4 (HT, but only UP kernel),
> PREEMPT, HZ=1000...
>
> 3.290196 0.470588 0.402614 0.396078 0.3
On Tue, Feb 20, 2007 at 07:41:25PM +0300, Evgeniy Polyakov wrote:
> On Tue, Feb 20, 2007 at 05:27:14PM +0100, bert hubert ([EMAIL PROTECTED])
> wrote:
> > I've done so, with some interesting results. Source on
> > http://ds9a.nl/tmp/recvtimings.c - be careful to adjust the '3000' divider
> > to yo
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/8139too.c | 40 ++---
drivers/net/hamradio/baycom_epp.c | 13 +--
drivers/net/
On Tue, Feb 20, 2007 at 08:55:50PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> Here is a dump of possible addr/port pairs which end up badly
> distributed:
>
> 8e363a50:27652 -> c0a80001:20480
> 8e363a50:35529 -> c0a80001:20480
> 8e363a50:40919 -> c0a80001:20480
> 8e363a50:46720 -> c0a80
On Tue, Feb 20, 2007 at 06:53:59PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> > > I've attached source code and running script.
> > > $ ./run.sh
> >
> > Yep, of course.
>
> Your test program is just bogus. artefacts come from your 'random' generator.
>
> You just increment a counter, assum
Hi Jan-
> Would that interface be sufficient for the userspace application?
This looks great! Two questions. I would assume that the of_device
results in a "devspec" file in the sysfs directory for the port? Also,
is there a way to correlate a logical port to an ethernet interface
(eth0, etc)?
On Tue, Feb 20, 2007 at 06:20:26PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> > Hmm, I've just ran following test:
> > 1. created 2^20 hash table.
> > 2. ran in loop (100*(2^20) iterations) following hashes:
> > a. xor hash (const_ip, const_ip, random_word)
>
> So what ? to attack me you w
On Tuesday 20 February 2007 18:05, Evgeniy Polyakov wrote:
> On Tue, Feb 20, 2007 at 07:59:07PM +0300, Evgeniy Polyakov
([EMAIL PROTECTED]) wrote:
> > I've attached source code and running script.
> > $ ./run.sh
>
> Yep, of course.
Your test program is just bogus. artefacts come from your 'random
Hi,
This patch enables dynamic adding / removing of ehea ports
by DLPAR tool. It creates a subnode for each logical port
in the sysfs. Furthermore, it has attributes that show
the associated eth device, the logical port number, and the
path in the open firmware device tree.
Logical ports can be a
On Tuesday 20 February 2007 17:59, Evgeniy Polyakov wrote:
> On Tue, Feb 20, 2007 at 05:38:19PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> > > It is secrecy, not security - attacker will check the source and find
> > > where constant per-boot value is added and recalculate attack vector -
>
On Tue, Feb 20, 2007 at 08:11:20PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> I would try it today - but it is a bit late in Moscow already - and
> there are some things to complete yet. So, tomorrow I will create a patch
> and run it, but I seriously doubt that there is _that_ high per-
On Tue, Feb 20, 2007 at 06:02:32PM +0100, bert hubert ([EMAIL PROTECTED]) wrote:
> On Tue, Feb 20, 2007 at 07:41:25PM +0300, Evgeniy Polyakov wrote:
>
> > It can be recvfrom only problem - syscall overhead on my p4 (core duo,
> > debian testing) is bout 300 usec - to test I ran read('dev/zero', &d
On Tue, Feb 20, 2007 at 07:59:07PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> I've attached source code and running script.
> $ ./run.sh
Yep, of course.
--
Evgeniy Polyakov
#include
#include
#include
#include
#include
#include
#include
typedef unsigned int u32;
typede
On Tue, Feb 20, 2007 at 07:41:25PM +0300, Evgeniy Polyakov wrote:
> It can be recvfrom only problem - syscall overhead on my p4 (core duo,
> debian testing) is bout 300 usec - to test I ran read('dev/zero', &data,
> 0) in a loop.
nsec I assume?
The usec numbers for read(fd, &c, 0) where fd is /d
On Tue, Feb 20, 2007 at 05:38:19PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> > It is secrecy, not security - attacker will check the source and find
> > where constant per-boot value is added and recalculate attack vector -
> > we all were college students, it would be even more fun to crac
On Tue, Feb 20, 2007 at 11:27:30AM -0500, Jeff Garzik wrote:
> >It was a mis-feature that the supported ports were ever user-selectable.
> >Which ports the hardware supports should be specified by platform-specific
> >code, not by the user.
> >
> > arch/mips/momentum/jaguar_atx/platform.c | 21 -
On Tuesday 20 February 2007 17:27, bert hubert wrote:
> On Tue, Feb 20, 2007 at 11:50:13AM +0100, Andi Kleen wrote:
> > P4s are pretty slow at taking locks (or rather doing atomical operations)
> > and there are several of them in this path. You could try it with a UP
> > kernel. Actually hotunplug
On Tue, Feb 20, 2007 at 05:27:14PM +0100, bert hubert ([EMAIL PROTECTED]) wrote:
> I've done so, with some interesting results. Source on
> http://ds9a.nl/tmp/recvtimings.c - be careful to adjust the '3000' divider
> to your CPU frequency if you care about absolute numbers!
>
> These are two group
On Tuesday 20 February 2007 17:20, Evgeniy Polyakov wrote:
> On Tue, Feb 20, 2007 at 05:08:12PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> > > Adding XOR with constant value does not change distribution.
> > > Variable salt will end up with differnet buckets for the same flow.
> > > It is fo
Dale Farnsworth wrote:
From: Dale Farnsworth <[EMAIL PROTECTED]>
Remove the use of CONFIG_MV643XX_ETH_[012] variables on most
platforms. Instead, platform-specific code enables the ports
supported by the hardware. After this patch, these config
variables are only used in arch/ppc, so also move
Ayaz Abdulla wrote:
There seems to be an issue when both MSI-X is enabled and NAPI is
configured. This patch disables MSI-X until the issue is root caused.
Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
ACK patches 2-3
Will await resend of entire patch series, after patch #1 is updated
-
On Tue, Feb 20, 2007 at 11:50:13AM +0100, Andi Kleen wrote:
> P4s are pretty slow at taking locks (or rather doing atomical operations)
> and there are several of them in this path. You could try it with a UP
> kernel. Actually hotunplugging the other virtual CPU should be sufficient
> with recent
Ayaz Abdulla wrote:
The napi poll routine was missing the call to the optimized rx process
routine. This patch adds the missing call for the optimized path.
Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
--- orig/drive
On Tue, Feb 20, 2007 at 05:08:12PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> > Adding XOR with constant value does not change distribution.
> > Variable salt will end up with differnet buckets for the same flow.
> > It is forbidden - it is not the situation created for passwd/des decades
>
applied to #vioc branch of netdev-2.6.git, which will be merged into
#ALL for a period of review and testing.
-
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
Mark Brown wrote:
This patch provides code paths which allow the natsemi driver to use the
external MII port on the chip but ignore any PHYs that may be attached to it.
The link state will be left as it was when the driver started and can be
configured via ethtool. Any PHYs that are present can
Ralf Baechle wrote:
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
applied
-
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
Stephen Hemminger wrote:
If a workqueue function that needs RTNL is running when skge_down
is called then a deadlock is possible. Fix by only clearing the timer,
and handling the flush_scheduled_work on removal. This work queue is only
ever used for the old fiber based boards.
Signed-off-by: Ste
Francois Romieu wrote:
flush_scheduled_work() in net_device->close has a slight tendency
to deadlock with tasks on the workqueue that hold RTNL.
rtl8169_close/down simply need the recovery tasks to not meddle
with the hardware while the device is going down.
Signed-off-by: Francois Romieu <[EMA
Kenzo Iwami wrote:
Hi,
I created a patch that uses watchdog_task but fixes the race condition
that occurred in old the e1000 driver.
I've obtained information about the panic caused by the old e1000 driver
using e1000_watchdog_task. According to the crash dump, the panic was
caused by a timer_l
On Tuesday 20 February 2007 16:59, Evgeniy Polyakov wrote:
> On Tue, Feb 20, 2007 at 07:49:11AM -0800, Michael K. Edwards
([EMAIL PROTECTED]) wrote:
> > On 2/20/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > >Jenkins _does_ have them, I showed tests half a year ago and in this
> > >thread too
On Tuesday 20 February 2007 16:49, Michael K. Edwards wrote:
> On 2/20/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > Jenkins _does_ have them, I showed tests half a year ago and in this
> > thread too. Actually _any_ hash has them it is just a matter of time
> > to find one.
>
> I think you m
On Tue, Feb 20, 2007 at 07:49:11AM -0800, Michael K. Edwards ([EMAIL
PROTECTED]) wrote:
> On 2/20/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >Jenkins _does_ have them, I showed tests half a year ago and in this
> >thread too. Actually _any_ hash has them it is just a matter of time
> >to fi
On 2/20/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
Jenkins _does_ have them, I showed tests half a year ago and in this
thread too. Actually _any_ hash has them it is just a matter of time
to find one.
I think you misunderstood me. If you are trying to DoS me from
outside with a hash coll
In general, TCP code uses "sk" for struct sock pointer.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/ipv4/tcp_ipv4.c | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 0ba74bb..f6793b4 100644
On 2/8/07, Greg KH <[EMAIL PROTECTED]> wrote:
And it should also alow for proper power management functionality, using
the changes that Linus put into the driver core about 8 months ago.
Don't worry, I have input patches queued up next for you Dmitry :)
Greg,
Could you please forward me the
1 - 100 of 134 matches
Mail list logo
