Re: Poor UDP performance using 2.6.21-rc5-rt5

* Ingo Molnar <[EMAIL PROTECTED]> wrote: > one thing to check would be whether both kernels use the same > clocksource, via: > > cat /sys/devices/system/clocksource/clocksource0/current_clocksource > > but at first sight there's no clocksource related overhead in the > oprofile. i've starte

Re: Poor UDP performance using 2.6.21-rc5-rt5

* Nivedita Singhvi <[EMAIL PROTECTED]> wrote: > Dave Sperry wrote: > >Hi > > (adding netdev to cc list) in general (except of course those netdev folks that are interested in -rt+networking performance matters) i'd suggest we analyze this in an -rt specific way - netdev shouldnt have to bothe

[PATCH linux1394-2.6.git 01/15] ieee1394: eth1394: coding style

Adjust white space and line wraps. Remove unnecessary parentheses and braces, unused macros, and some of the more redundant comments. Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> --- drivers/ieee1394/eth1394.c | 426 + drivers/ieee1394/eth1394.h | 24 -

[PATCH linux1394-2.6.git 03/15] eth1394: refactor .probe and .update

Move common code into an extra function. This implicitly adds a missing node_info->fifo = CSR1212_INVALID_ADDR_SPACE; to .update. Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> --- drivers/ieee1394/eth1394.c | 48 - 1 file changed, 16 insertions(+), 32 de

[PATCH linux1394-2.6.git 05/15] ieee1394: eth1394: shorter error messages

Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> --- drivers/ieee1394/eth1394.c | 40 ++--- 1 file changed, 16 insertions(+), 24 deletions(-) Index: linux/drivers/ieee1394/eth1394.c === --- linux.or

[PATCH linux1394-2.6.git 06/15] ieee1394: eth1394: contain host reset

Call only eth1394's own host reset handler from .tx_timeout, not the reset hooks of all other IEEE 1394 drivers. A minor drawback of this patch is that ether1394_host_reset by timeout is not serialized against ether1394_host_reset by bus reset. Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> --

[PATCH linux1394-2.6.git 02/15] ieee1394: eth1394: .probe and .update may sleep

Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> --- drivers/ieee1394/eth1394.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) Index: linux/drivers/ieee1394/eth1394.c === --- linux.orig/drivers/ieee1394/eth1394

[PATCH linux1394-2.6.git 04/15] ieee1394: eth1394: correct a memset argument

The old argument calculated the correct value in a wrong way. Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> --- drivers/ieee1394/eth1394.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux/drivers/ieee1394/eth1394.c

[PATCH linux1394-2.6.git 00/15] ieee1394: eth1394: cleanups and small fixes

01/15 ieee1394: eth1394: coding style 02/15 ieee1394: eth1394: .probe and .update may sleep 03/15 ieee1394: eth1394: refactor .probe and .update 04/15 ieee1394: eth1394: correct a memset argument 05/15 ieee1394: eth1394: shorter error messages 06/15 ieee1394: eth1394: contain host reset 07/15 ieee1

Re: [RFC] rfkill - Add support for input key to control wireless radio

On Saturday 31 March 2007 08:49, Ivo van Doorn wrote: > > Well that would mean rfkill would be ready to applied to one of the kernel > trees right? :) Well, that would be up to that particular tree maintainer. I am not sure who maintains the net/... David Miller maybe? Anyway, below is the same

[PATCH linux1394-2.6.git 15/15] ieee1394: eth1394: check for kmem_cache_create failure

Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> --- drivers/ieee1394/eth1394.c |2 ++ 1 file changed, 2 insertions(+) Index: linux/drivers/ieee1394/eth1394.c === --- linux.orig/drivers/ieee1394/eth1394.c +++ linux/drivers/ieee1

[PATCH linux1394-2.6.git 14/15] ieee1394: eth1394: correct return codes in hard_start_xmit

This patch actually doesn't change anything because there was always 0 == NETDEV_TX_OK returned before. TODO: Return NETDEV_TX_BUSY in error case and test in different error conditions. Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> --- drivers/ieee1394/eth1394.c | 34 --

[PATCH linux1394-2.6.git 13/15] ieee1394: eth1394: hard_start_xmit is called in atomic context

Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> --- drivers/ieee1394/eth1394.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) Index: linux/drivers/ieee1394/eth1394.c === --- linux.orig/drivers/ieee1394/eth1394.c +++

[PATCH linux1394-2.6.git 12/15] ieee1394: eth1394: some conditions are unlikely

Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> --- drivers/ieee1394/eth1394.c |8 1 file changed, 4 insertions(+), 4 deletions(-) Index: linux/drivers/ieee1394/eth1394.c === --- linux.orig/drivers/ieee1394/eth1394.c +

[PATCH linux1394-2.6.git 11/15] ieee1394: eth1394: clean up fragment_overlap

offset > fi->offset + fi->len - 1 == !(offset < fi->offset + fi->len) offset + len - 1 < fi->offset == !(offset + len > fi->offset) !(A || B) == (!A && !B) Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> --- drivers/ieee1394/eth1394.c |8 1 file changed, 4 insertions(+),

[PATCH linux1394-2.6.git 10/15] ieee1394: eth1394: don't use alloc_etherdev

Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> --- drivers/ieee1394/eth1394.c | 20 +--- 1 file changed, 5 insertions(+), 15 deletions(-) Index: linux/drivers/ieee1394/eth1394.c === --- linux.orig/drivers/ieee139

[PATCH linux1394-2.6.git 09/15] ieee1394: eth1394: omit useless set_mac_address callback

We can't reconfigure the MAC address, hence we don't need the callback. Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> --- drivers/ieee1394/eth1394.c | 14 +- 1 file changed, 1 insertion(+), 13 deletions(-) Index: linux/drivers/ieee1394/eth1394.c

[PATCH linux1394-2.6.git 08/15] eth1394: CONFIG_INET is always defined

because CONFIG_IEEE1394_ETH1394 depends on it. Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> --- drivers/ieee1394/eth1394.c | 16 1 file changed, 4 insertions(+), 12 deletions(-) Index: linux/drivers/ieee1394/eth1394.c ==

[PATCH linux1394-2.6.git 07/15] ieee1394: eth1394: make MTU configurable

Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> --- drivers/ieee1394/eth1394.c | 20 ++-- 1 file changed, 14 insertions(+), 6 deletions(-) Index: linux/drivers/ieee1394/eth1394.c === --- linux.orig/drivers/ieee139

Re: Poor UDP performance using 2.6.21-rc5-rt5

Nivedita Singhvi wrote: Dave Sperry wrote: Hi (adding netdev to cc list) I have a dual core Opteron machine that exhibits poor UDP performance (RT consumes more than 2X cpu) with the 2.6.21-rc5-rt5 as compared to 2.6.21-rc5. Top shows the IRQ handler consuming a lot of CPU. Dave, any chan

Re: Poor UDP performance using 2.6.21-rc5-rt5

Dave Sperry wrote: Hi (adding netdev to cc list) I have a dual core Opteron machine that exhibits poor UDP performance (RT consumes more than 2X cpu) with the 2.6.21-rc5-rt5 as compared to 2.6.21-rc5. Top shows the IRQ handler consuming a lot of CPU. Dave, any chance you've got oprofile wo

[PATCH 2.6.21-rc5] b44: fix IFF_ALLMULTI handling of CAM slots

If you set the IFF_ALLMULTI flag on a b44 device, or if you join more than B44_MCAST_TABLE_SIZE multicast groups, the device will stop receiving unicast messages. This is because the __b44_set_mac_addr call sets the zeroth CAM entry to the MAC address of the device, and then the loop at line 1722

Re: Silent corruption on AMD64

Aaron Lehmann <[EMAIL PROTECTED]> writes: [adding netdev] [meta-comment: I wish people wouldn't use such unnecessarily broad subjects -- how is it the x86-64 port's or AMD's fault when you have broken hardware? Would anybody write "Silent corruption on i386" or "Silent corruption on Intel" or "

Re: r8169 null pointer dereference

On Sun, 1 Apr 2007 12:00:00 +0200 Francois Romieu <[EMAIL PROTECTED]> wrote: > Jay Cliburn <[EMAIL PROTECTED]> : > > Francois, > > > > I get this on 2.6.21-rc5 and earlier kernels going back to at least > > 2.6.20-git14, both i386 and x86_64, dual-core AM2 and LGA775 > > motherboards, using two d

Re: r8169 null pointer dereference

Jay Cliburn <[EMAIL PROTECTED]> : > Francois, > > I get this on 2.6.21-rc5 and earlier kernels going back to at least > 2.6.20-git14, both i386 and x86_64, dual-core AM2 and LGA775 > motherboards, using two different RTL8169 PCI add-in cards. Has anyone > else reported it? No. It does not look l