fedora 14 kernel performance with ip forwarding workload
by Jesse Brandeburg
The other day I was running the stock fedora kernel on my ip
forwarding setup, to see what the performance was, and the performance
wasn't very good.
system is S5520HC dual socket 2.93GHz Xeon 5570 (Nehalem) with 3 quad
port 82580 adapters (12 ports). Traffic is bidirectional 64 byte
packets being forwarded and received on each port, basically port to
port routing. I am only using 12 flows currently.
The driver is igb, and I am using an affinity script that lines up
each pair of ports that are forwarding traffic into optimal
configurations for cache locality. I am also disabling
remote_node_defrag_ratio to stop cross node traffic.
With the fedora default kernel from F14 it appears that
CONFIG_NETFILTER=y means that I cannot unload all of netfilter even if
I stop iptables service.
perf showed netfilter being prominent, and removing it gives me much
higher throughput. Is there a reason CONFIG_NETFILTER=y ? Isn't it a
good thing to be able to disable netfilter if you want to?
Jesse
8 years, 5 months
[PATCH 2.6.38 0/4] iwlwifi: fix hw scan related problems
by Stanislaw Gruszka
This patchset fixes several problems related with hw scanning
on 3945 (see patch 3 for details). It is intended to 2.6.38,
on older kernels software scanning does not work. All patches
are currently in Linus' tree.
12 years, 7 months
[PATCH stable v2] iwlagn: Support new 5000 microcode.
by Stanislaw Gruszka
From: Don Fry <donald.h.fry(a)intel.com>
commit 41504cce240f791f1e16561db95728c5537fbad9 upstream.
New iwlwifi-5000 microcode requires driver support for API version 5.
Signed-off-by: Don Fry <donald.h.fry(a)intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy(a)intel.com>
Signed-off-by: Stanislaw Gruszka <sgruszka(a)redhat.com>
---
Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=695712
drivers/net/wireless/iwlwifi/iwl-5000.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-5000.c b/drivers/net/wireless/iwlwifi/iwl-5000.c
index a28af7e..0a67558 100644
--- a/drivers/net/wireless/iwlwifi/iwl-5000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-5000.c
@@ -51,7 +51,7 @@
#include "iwl-agn-debugfs.h"
/* Highest firmware API version supported */
-#define IWL5000_UCODE_API_MAX 2
+#define IWL5000_UCODE_API_MAX 5
#define IWL5150_UCODE_API_MAX 2
/* Lowest firmware API version supported */
--
1.7.1
12 years, 7 months
[PATCH stable] iwlagn: Support new 5000 microcode.
by Stanislaw Gruszka
From: Don Fry <donald.h.fry(a)intel.com>
commit 41504cce240f791f1e16561db95728c5537fbad9 upstream.
New iwlwifi-5000 microcode requires driver support for API version 5.
Signed-off-by: Don Fry <donald.h.fry(a)intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy(a)intel.com>
Signed-off-by: Stanislaw Gruszka <sgruszka(a)redhat.com>
---
Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=695712
drivers/net/wireless/iwlwifi/iwl-5000.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 3 +--
net/mac80211/cfg.c | 1 +
net/mac80211/chan.c | 3 +++
net/mac80211/mlme.c | 6 ++----
5 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-5000.c b/drivers/net/wireless/iwlwifi/iwl-5000.c
index a28af7e..0a67558 100644
--- a/drivers/net/wireless/iwlwifi/iwl-5000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-5000.c
@@ -51,7 +51,7 @@
#include "iwl-agn-debugfs.h"
/* Highest firmware API version supported */
-#define IWL5000_UCODE_API_MAX 2
+#define IWL5000_UCODE_API_MAX 5
#define IWL5150_UCODE_API_MAX 2
/* Lowest firmware API version supported */
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-tx.c b/drivers/net/wireless/iwlwifi/iwl-agn-tx.c
index 3a3d27c..5e0e631 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-tx.c
@@ -1253,8 +1253,7 @@ void iwlagn_hwrate_to_tx_control(struct iwl_priv *priv, u32 rate_n_flags,
* Handles block-acknowledge notification from device, which reports success
* of frames sent via aggregation.
*/
-void iwlagn_rx_reply_compressed_ba(struct iwl_priv *priv,
- struct iwl_rx_mem_buffer *rxb)
+void iwlagn_rx_reply_compressed_ba(struct iwl_priv *priv, struct iwl_rx_mem_buffer *rxb)
{
struct iwl_rx_packet *pkt = rxb_addr(rxb);
struct iwl_compressed_ba_resp *ba_resp = &pkt->u.compressed_ba;
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index e8f3545..43088fe 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1221,6 +1221,7 @@ static int ieee80211_scan(struct wiphy *wiphy,
sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+ if
if (sdata->vif.type != NL80211_IFTYPE_STATION &&
sdata->vif.type != NL80211_IFTYPE_ADHOC &&
sdata->vif.type != NL80211_IFTYPE_MESH_POINT &&
diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
index 32be11e..f0d80d4 100644
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -77,6 +77,9 @@ bool ieee80211_set_channel_type(struct ieee80211_local *local,
switch (tmp->vif.bss_conf.channel_type) {
case NL80211_CHAN_NO_HT:
case NL80211_CHAN_HT20:
+ if (superchan > tmp->vif.bss_conf.channel_type)
+ break;
+
superchan = tmp->vif.bss_conf.channel_type;
break;
case NL80211_CHAN_HT40PLUS:
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 090b3e6..e716b9e 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2407,10 +2407,8 @@ int ieee80211_mgd_action(struct ieee80211_sub_if_data *sdata,
struct sk_buff *skb;
/* Check that we are on the requested channel for transmission */
- if ((chan != local->tmp_channel ||
- channel_type != local->tmp_channel_type) &&
- (chan != local->oper_channel ||
- channel_type != local->_oper_channel_type))
+ if ((chan != local->tmp_channel || channel_type != local->tmp_channel_type) &&
+ (chan != local->oper_channel || channel_type != local->_oper_channel_type))
return -EBUSY;
skb = dev_alloc_skb(local->hw.extra_tx_headroom + len);
--
1.7.1
12 years, 7 months
Custom kernel building
by Guilherme Patriota
What's the difference between building custom kernel with Fedora and
building a kernel with the sources from kernel.org? Building with rpmbuild
takes way longer to build than the normal source code from kernel.org which
is wierd. I've set it to build with rpmbuild for about 3h ago and it's still
building taking about 90% ~ 100% of both cores.
12 years, 7 months
Re: [kernel] Add a no lvds quirk for the Asus EB1007 to the i915 drm
by Kyle McMartin
On Thu, Apr 07, 2011 at 11:59:41AM +0000, Hans de Goede wrote:
> commit 042ba03b683a8705f44d86b5283cb84de54d4970
> Author: Hans de Goede <hdegoede(a)redhat.com>
> Date: Thu Apr 7 14:01:43 2011 +0200
>
> Add a no lvds quirk for the Asus EB1007 to the i915 drm driver,
> this fixes gnome-shell not working on it
>
Just curious, have you submitted it upstream? I don't see it on
intel-gfx@ or linux-kernel@.
--Kyle
12 years, 7 months
Odd rebalancing behavior
by Michel Alexandre Salim
I have an external 4-disk enclosure, connected through USB 2.0 (my
laptop does not have a USB 3.0 connector, and the eSATA connector
somehow does not work); it initially had a 2-disk btrfs soft-RAID1 file
system (both data and metadata are RAID1).
I recently added two more disks and did a rebalance. To my surprise it
went past the point where all four disks have the same amount of disk
usage, and went all the way to the original disks being empty, and the
new disks having all the data!
Label: 'media.store' uuid: 4cfd3551-aa85-4399-b872-9238ddb14c97
Total devices 4 FS bytes used 1.22TB
devid 3 size 1.82TB used 1.24TB path /dev/sdb
devid 4 size 1.82TB used 1.24TB path /dev/sdc
devid 2 size 1.82TB used 8.00MB path /dev/sde
devid 1 size 1.82TB used 12.00MB path /dev/sdd
Is this to be expected? Would another rebalance fix it, or should I
force-stop it by shutting down when the disk usage is roughly balanced?
This is on Fedora 15 pre-release, x86_64, fully updated, kernel
2.6.38.2-9 and btrfs-progs 0.19-13
Thanks,
--
Michel Alexandre Salim
GPG key ID: 78884778
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
12 years, 8 months
[PATCH v2.6.38.y] rt2x00: Fix radio off hang issue for PCIE interface
by Stanislaw Gruszka
From: RA-Jay Hung <jay_hung(a)ralinktech.com>
commit 7f6e144fb99a4a70d3c5ad5f074204c5b89a6f65 upstream.
PCI/PCIE radio off behavior is different from SOC/USB.
They mainly use MCU command to disable DMA, TX/RX and enter power saving mode.
Resolves hang during suspend:
https://bugzilla.redhat.com/show_bug.cgi?id=691128
Reported-by: Bastiaan Jacques <bastiaan(a)bjacques.org>
Signed-off-by: RA-Jay Hung <jay_hung(a)ralinktech.com>
Signed-off-by: Ivo van Doorn <IvDoorn(a)gmail.com>
Signed-off-by: John W. Linville <linville(a)tuxdriver.com>
Signed-off-by: Stanislaw Gruszka <sgruszka(a)redhat.com>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 6 -----
drivers/net/wireless/rt2x00/rt2800pci.c | 36 ++++++++----------------------
2 files changed, 10 insertions(+), 32 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 54917a2..e2a528d 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -2810,10 +2810,7 @@ void rt2800_disable_radio(struct rt2x00_dev *rt2x00dev)
rt2800_register_read(rt2x00dev, WPDMA_GLO_CFG, ®);
rt2x00_set_field32(®, WPDMA_GLO_CFG_ENABLE_TX_DMA, 0);
- rt2x00_set_field32(®, WPDMA_GLO_CFG_TX_DMA_BUSY, 0);
rt2x00_set_field32(®, WPDMA_GLO_CFG_ENABLE_RX_DMA, 0);
- rt2x00_set_field32(®, WPDMA_GLO_CFG_RX_DMA_BUSY, 0);
- rt2x00_set_field32(®, WPDMA_GLO_CFG_TX_WRITEBACK_DONE, 1);
rt2800_register_write(rt2x00dev, WPDMA_GLO_CFG, reg);
/* Wait for DMA, ignore error */
@@ -2823,9 +2820,6 @@ void rt2800_disable_radio(struct rt2x00_dev *rt2x00dev)
rt2x00_set_field32(®, MAC_SYS_CTRL_ENABLE_TX, 0);
rt2x00_set_field32(®, MAC_SYS_CTRL_ENABLE_RX, 0);
rt2800_register_write(rt2x00dev, MAC_SYS_CTRL, reg);
-
- rt2800_register_write(rt2x00dev, PWR_PIN_CFG, 0);
- rt2800_register_write(rt2x00dev, TX_PIN_CFG, 0);
}
EXPORT_SYMBOL_GPL(rt2800_disable_radio);
diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
index 3b3f1e4..37a38b5 100644
--- a/drivers/net/wireless/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/rt2x00/rt2800pci.c
@@ -475,39 +475,23 @@ static int rt2800pci_enable_radio(struct rt2x00_dev *rt2x00dev)
static void rt2800pci_disable_radio(struct rt2x00_dev *rt2x00dev)
{
- u32 reg;
-
- rt2800_disable_radio(rt2x00dev);
-
- rt2800_register_write(rt2x00dev, PBF_SYS_CTRL, 0x00001280);
-
- rt2800_register_read(rt2x00dev, WPDMA_RST_IDX, ®);
- rt2x00_set_field32(®, WPDMA_RST_IDX_DTX_IDX0, 1);
- rt2x00_set_field32(®, WPDMA_RST_IDX_DTX_IDX1, 1);
- rt2x00_set_field32(®, WPDMA_RST_IDX_DTX_IDX2, 1);
- rt2x00_set_field32(®, WPDMA_RST_IDX_DTX_IDX3, 1);
- rt2x00_set_field32(®, WPDMA_RST_IDX_DTX_IDX4, 1);
- rt2x00_set_field32(®, WPDMA_RST_IDX_DTX_IDX5, 1);
- rt2x00_set_field32(®, WPDMA_RST_IDX_DRX_IDX0, 1);
- rt2800_register_write(rt2x00dev, WPDMA_RST_IDX, reg);
-
- rt2800_register_write(rt2x00dev, PBF_SYS_CTRL, 0x00000e1f);
- rt2800_register_write(rt2x00dev, PBF_SYS_CTRL, 0x00000e00);
+ if (rt2x00_is_soc(rt2x00dev)) {
+ rt2800_disable_radio(rt2x00dev);
+ rt2800_register_write(rt2x00dev, PWR_PIN_CFG, 0);
+ rt2800_register_write(rt2x00dev, TX_PIN_CFG, 0);
+ }
}
static int rt2800pci_set_state(struct rt2x00_dev *rt2x00dev,
enum dev_state state)
{
- /*
- * Always put the device to sleep (even when we intend to wakeup!)
- * if the device is booting and wasn't asleep it will return
- * failure when attempting to wakeup.
- */
- rt2800_mcu_request(rt2x00dev, MCU_SLEEP, 0xff, 0xff, 2);
-
if (state == STATE_AWAKE) {
- rt2800_mcu_request(rt2x00dev, MCU_WAKEUP, TOKEN_WAKUP, 0, 0);
+ rt2800_mcu_request(rt2x00dev, MCU_WAKEUP, TOKEN_WAKUP, 0, 0x02);
rt2800pci_mcu_status(rt2x00dev, TOKEN_WAKUP);
+ } else if (state == STATE_SLEEP) {
+ rt2800_register_write(rt2x00dev, H2M_MAILBOX_STATUS, 0xffffffff);
+ rt2800_register_write(rt2x00dev, H2M_MAILBOX_CID, 0xffffffff);
+ rt2800_mcu_request(rt2x00dev, MCU_SLEEP, 0x01, 0xff, 0x01);
}
return 0;
--
1.7.1
12 years, 8 months
2.6.38.2-10 + nouveau
by Genes MailLists
Generally had no issues with this kernel except for this one:
I notice when I logout there are dropped random "bites" of little sets
of pixels which appear .. perhaps 10-30 of them .. these are small black
squares against the blue background.
Nouveau driver (on f14 fully updated).
I see that there is a patch in the -11 kernel on koji - I'll try that
and see if it goes away.
gene/
12 years, 8 months