* [PATCH 05/20] wl1271: Implement delayed entry into ELP
From: Luciano Coelho @ 2009-10-08 18:56 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Juuso Oikarinen
In-Reply-To: <1255028196-6565-1-git-send-email-luciano.coelho@nokia.com>
From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Implement delayed entry into ELP. This will promote the following:
- Less redundant sleep/wake cycles (better perf)
- Avoids known firmware issues with going to ELP too fast after an
operation
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Vidhya Govindan <vidhya.govindan@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
---
drivers/net/wireless/wl12xx/wl1271.h | 1 +
drivers/net/wireless/wl12xx/wl1271_main.c | 1 +
drivers/net/wireless/wl12xx/wl1271_ps.c | 46 ++++++++++++++++++++---------
drivers/net/wireless/wl12xx/wl1271_ps.h | 2 +-
4 files changed, 35 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271.h b/drivers/net/wireless/wl12xx/wl1271.h
index e575dcc..c455dcb 100644
--- a/drivers/net/wireless/wl12xx/wl1271.h
+++ b/drivers/net/wireless/wl12xx/wl1271.h
@@ -373,6 +373,7 @@ struct wl1271 {
bool elp;
struct completion *elp_compl;
+ struct delayed_work elp_work;
/* we can be in psm, but not in elp, we have to differentiate */
bool psm;
diff --git a/drivers/net/wireless/wl12xx/wl1271_main.c b/drivers/net/wireless/wl12xx/wl1271_main.c
index 3d629da..cc5c328 100644
--- a/drivers/net/wireless/wl12xx/wl1271_main.c
+++ b/drivers/net/wireless/wl12xx/wl1271_main.c
@@ -1226,6 +1226,7 @@ static int __devinit wl1271_probe(struct spi_device *spi)
skb_queue_head_init(&wl->tx_queue);
INIT_WORK(&wl->filter_work, wl1271_filter_work);
+ INIT_DELAYED_WORK(&wl->elp_work, wl1271_elp_work);
wl->channel = WL1271_DEFAULT_CHANNEL;
wl->scanning = false;
wl->default_key = 0;
diff --git a/drivers/net/wireless/wl12xx/wl1271_ps.c b/drivers/net/wireless/wl12xx/wl1271_ps.c
index 1dc74b0..0f6ea16 100644
--- a/drivers/net/wireless/wl12xx/wl1271_ps.c
+++ b/drivers/net/wireless/wl12xx/wl1271_ps.c
@@ -27,25 +27,43 @@
#define WL1271_WAKEUP_TIMEOUT 500
-/* Routines to toggle sleep mode while in ELP */
-void wl1271_ps_elp_sleep(struct wl1271 *wl)
+void wl1271_elp_work(struct work_struct *work)
{
+ struct delayed_work *dwork;
+ struct wl1271 *wl;
+
+ dwork = container_of(work, struct delayed_work, work);
+ wl = container_of(dwork, struct wl1271, elp_work);
+
+ wl1271_debug(DEBUG_PSM, "elp work");
+
+ mutex_lock(&wl->mutex);
+
/*
- * FIXME: due to a problem in the firmware (causing a firmware
- * crash), ELP entry is prevented below. Remove the "true" to
- * re-enable ELP entry.
+ * FIXME: below, by means of the "true", ELP has been disabled for now
+ * to work around a firmware bug. To be enabled upon receiving a new
+ * firmware version.
*/
if (true || wl->elp || !wl->psm)
- return;
+ goto out;
- /*
- * Go to ELP unless there is work already pending - pending work
- * will immediately wakeup the chipset anyway.
- */
- if (!work_pending(&wl->irq_work) && !work_pending(&wl->tx_work)) {
- wl1271_debug(DEBUG_PSM, "chip to elp");
- wl1271_write32(wl, HW_ACCESS_ELP_CTRL_REG_ADDR, ELPCTRL_SLEEP);
- wl->elp = true;
+ wl1271_debug(DEBUG_PSM, "chip to elp");
+ wl1271_write32(wl, HW_ACCESS_ELP_CTRL_REG_ADDR, ELPCTRL_SLEEP);
+ wl->elp = true;
+
+out:
+ mutex_unlock(&wl->mutex);
+}
+
+#define ELP_ENTRY_DELAY 5
+
+/* Routines to toggle sleep mode while in ELP */
+void wl1271_ps_elp_sleep(struct wl1271 *wl)
+{
+ if (wl->psm) {
+ cancel_delayed_work(&wl->elp_work);
+ ieee80211_queue_delayed_work(wl->hw, &wl->elp_work,
+ msecs_to_jiffies(ELP_ENTRY_DELAY));
}
}
diff --git a/drivers/net/wireless/wl12xx/wl1271_ps.h b/drivers/net/wireless/wl12xx/wl1271_ps.h
index de2bd3c..779653d 100644
--- a/drivers/net/wireless/wl12xx/wl1271_ps.h
+++ b/drivers/net/wireless/wl12xx/wl1271_ps.h
@@ -30,6 +30,6 @@
int wl1271_ps_set_mode(struct wl1271 *wl, enum wl1271_cmd_ps_mode mode);
void wl1271_ps_elp_sleep(struct wl1271 *wl);
int wl1271_ps_elp_wakeup(struct wl1271 *wl, bool chip_awake);
-
+void wl1271_elp_work(struct work_struct *work);
#endif /* __WL1271_PS_H__ */
--
1.5.6.5
^ permalink raw reply related
* [PATCH 04/20] wl1271: Correct TKIP header space handling in TX path
From: Luciano Coelho @ 2009-10-08 18:56 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Juuso Oikarinen
In-Reply-To: <1255028196-6565-1-git-send-email-luciano.coelho@nokia.com>
From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Correct the position to which TKIP header space is appended for TX
packets.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Vidhya Govindan <vidhya.govindan@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
---
drivers/net/wireless/wl12xx/wl1271_main.c | 9 +++------
drivers/net/wireless/wl12xx/wl1271_tx.c | 27 +++++++++++++++++----------
2 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_main.c b/drivers/net/wireless/wl12xx/wl1271_main.c
index bedd19b..3d629da 100644
--- a/drivers/net/wireless/wl12xx/wl1271_main.c
+++ b/drivers/net/wireless/wl12xx/wl1271_main.c
@@ -1160,12 +1160,9 @@ static int wl1271_register_hw(struct wl1271 *wl)
static int wl1271_init_ieee80211(struct wl1271 *wl)
{
- /*
- * The tx descriptor buffer and the TKIP space.
- *
- * FIXME: add correct 1271 descriptor size
- */
- wl->hw->extra_tx_headroom = WL1271_TKIP_IV_SPACE;
+ /* The tx descriptor buffer and the TKIP space. */
+ wl->hw->extra_tx_headroom = WL1271_TKIP_IV_SPACE +
+ sizeof(struct wl1271_tx_hw_descr);
/* unit us */
/* FIXME: find a proper value */
diff --git a/drivers/net/wireless/wl12xx/wl1271_tx.c b/drivers/net/wireless/wl12xx/wl1271_tx.c
index 162f026..1ad1bc3 100644
--- a/drivers/net/wireless/wl12xx/wl1271_tx.c
+++ b/drivers/net/wireless/wl12xx/wl1271_tx.c
@@ -92,6 +92,14 @@ static int wl1271_tx_fill_hdr(struct wl1271 *wl, struct sk_buff *skb,
desc = (struct wl1271_tx_hw_descr *) skb->data;
+ /* relocate space for security header */
+ if (extra) {
+ void *framestart = skb->data + sizeof(*desc);
+ u16 fc = *(u16 *)(framestart + extra);
+ int hdrlen = ieee80211_hdrlen(fc);
+ memmove(framestart, framestart + extra, hdrlen);
+ }
+
/* configure packet life time */
desc->start_time = jiffies_to_usecs(jiffies) - wl->time_offset;
desc->life_time = TX_HW_MGMT_PKT_LIFETIME_TU;
@@ -257,7 +265,6 @@ static void wl1271_tx_complete_packet(struct wl1271 *wl,
struct ieee80211_tx_info *info;
struct sk_buff *skb;
- u32 header_len;
u16 seq;
int id = result->id;
@@ -295,22 +302,22 @@ static void wl1271_tx_complete_packet(struct wl1271 *wl,
wl->tx_security_seq_32++;
wl->tx_security_seq_16 = seq;
- /* get header len */
+ /* remove private header from packet */
+ skb_pull(skb, sizeof(struct wl1271_tx_hw_descr));
+
+ /* remove TKIP header space if present */
if (info->control.hw_key &&
- info->control.hw_key->alg == ALG_TKIP)
- header_len = WL1271_TKIP_IV_SPACE +
- sizeof(struct wl1271_tx_hw_descr);
- else
- header_len = sizeof(struct wl1271_tx_hw_descr);
+ info->control.hw_key->alg == ALG_TKIP) {
+ int hdrlen = ieee80211_get_hdrlen_from_skb(skb);
+ memmove(skb->data + WL1271_TKIP_IV_SPACE, skb->data, hdrlen);
+ skb_pull(skb, WL1271_TKIP_IV_SPACE);
+ }
wl1271_debug(DEBUG_TX, "tx status id %u skb 0x%p failures %u rate 0x%x"
" status 0x%x",
result->id, skb, result->ack_failures,
result->rate_class_index, result->status);
- /* remove private header from packet */
- skb_pull(skb, header_len);
-
/* return the packet to the stack */
ieee80211_tx_status(wl->hw, skb);
wl->tx_frames[result->id] = NULL;
--
1.5.6.5
^ permalink raw reply related
* [PATCH 01/20] wl1271: remove unecessary qual parameter from rx status
From: Luciano Coelho @ 2009-10-08 18:56 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
In-Reply-To: <1255028196-6565-1-git-send-email-luciano.coelho@nokia.com>
The qual element in ieee80211_rx_status is not used anymore, so we don't need
to set it in the wl1271_rx_status() function. This saves a bit of time in
the RX path.
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
---
drivers/net/wireless/wl12xx/wl1271_rx.c | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_rx.c b/drivers/net/wireless/wl12xx/wl1271_rx.c
index ad8b690..5d8d401 100644
--- a/drivers/net/wireless/wl12xx/wl1271_rx.c
+++ b/drivers/net/wireless/wl12xx/wl1271_rx.c
@@ -91,12 +91,6 @@ static void wl1271_rx_status(struct wl1271 *wl,
*/
status->signal = desc->rssi;
- /* FIXME: Should this be optimized? */
- status->qual = (desc->rssi - WL1271_RX_MIN_RSSI) * 100 /
- (WL1271_RX_MAX_RSSI - WL1271_RX_MIN_RSSI);
- status->qual = min(status->qual, 100);
- status->qual = max(status->qual, 0);
-
/*
* FIXME: In wl1251, the SNR should be divided by two. In wl1271 we
* need to divide by two for now, but TI has been discussing about
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] wireless: make WEXT_SPY and WEXT_PRIV select WEXT_CORE
From: Johannes Berg @ 2009-10-08 18:29 UTC (permalink / raw)
To: Randy Dunlap
Cc: John W. Linville, linux-wireless, Stephen Rothwell, linux-next,
linux-kernel
In-Reply-To: <20091008080615.09c8b803.randy.dunlap@oracle.com>
On Thu, 2009-10-08 at 08:06 -0700, Randy Dunlap wrote:
> > It's kinda strange though that you can select wireless drivers without
> > selecting WIRELESS. Maybe the solution is as simple as making WLAN
> > (drivers/net/wireless/Kconfig) depend on WIRELESS?
>
> Yes, I think that would be a very good start.
On the other hand, of course, the whole WIRELESS thing is somewhat
stupid. How about this?
johannes
From: Johannes Berg <johannes@sipsolutions.net>
Subject: wireless: make wireless drivers select core
It is somewhat non-sensical to allow selecting wireless
drivers without showing wireless core code options, and
since the wext refactoring this has made it possible to
generate configurations that will not build. Avoid this
and make wireless drivers select the wireless options.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
drivers/net/wireless/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- wireless-testing.orig/drivers/net/wireless/Kconfig 2009-10-08 20:25:04.000000000 +0200
+++ wireless-testing/drivers/net/wireless/Kconfig 2009-10-08 20:27:38.000000000 +0200
@@ -5,6 +5,7 @@
menuconfig WLAN
bool "Wireless LAN"
depends on !S390
+ select WIRELESS
default y
---help---
This section contains all the pre 802.11 and 802.11 wireless
^ permalink raw reply
* Re: [PATCH 7/7] ath5k: enable Power-Save Polls by setting the association ID
From: Bob Copeland @ 2009-10-08 18:26 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless
In-Reply-To: <1254876274-1145-8-git-send-email-lrodriguez@atheros.com>
On Tue, Oct 6, 2009 at 8:44 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> @@ -3226,6 +3225,14 @@ static void ath5k_bss_info_changed(struct ieee80211_hw *hw,
> set_beacon_filter(hw, sc->assoc);
> ath5k_hw_set_ledstate(sc->ah, sc->assoc ?
> AR5K_LED_ASSOC : AR5K_LED_INIT);
> + if (bss_conf->assoc) {
> + ATH5K_DBG(sc, ATH5K_DEBUG_ANY,
> + "Bss Info ASSOC %d, bssid: %pM\n",
> + bss_conf->aid, common->curbssid);
> + common->curaid = bss_conf->aid;
> + ath5k_hw_set_associd(ah);
> + /* Once ANI is available you would start it here */
> + }
Just quick question - do we only want to call this if we are associated?
Or maybe we should call it to reset the mask if we are unassociated...
I wrote a patch a while ago to the ath5k list that did something similar,
but I did:
if (changes & (BSS_CHANGED_BSSID | BSS_CHANGED_ASSOC)) {
ath5k_hw_set_associd(ah, ah->ah_bssid, ah->ah_aid);
}
Thus if it changed regardless of the reason why, we update the mask.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Mike Galbraith @ 2009-10-08 18:23 UTC (permalink / raw)
To: Frans Pop
Cc: Arjan van de Ven, Linux Kernel Mailing List, Ingo Molnar,
Peter Zijlstra, linux-wireless
In-Reply-To: <200910081655.37485.elendil@planet.nl>
On Thu, 2009-10-08 at 16:55 +0200, Frans Pop wrote:
> On Thursday 08 October 2009, Arjan van de Ven wrote:
> > From: Arjan van de Ven <arjan@linux.intel.com>
> > Date: Thu, 24 Sep 2009 13:24:16 +0200
> > Subject: [PATCH] x86, timers: check for pending timers after (device)
> > interrupts
> >
> > Now that range timers and deferred timers are common, I found a
> > problem with these using the "perf timechart" tool.
> >
> > It turns out that on x86, these two 'opportunistic' timers only
> > get checked when another "real" timer happens.
> > These opportunistic timers have the objective to save power by
> > hitchhiking on other wakeups, as to avoid CPU wakeups by themselves
> > as much as possible.
>
> This patch makes quite a difference for me. iwlagn and phy0 now
> consistently show at ~10 ms or lower.
>
> I do still get occasional high latencies, but those are for things like
> "[rpc_wait_bit_killable]" or "Writing a page to disk", where I guess you'd
> expect them. Those high latencies are mostly only listed for "Global" and
> don't translate to individual processes.
I still see very high latencies coming out of idle (last noted was >
300ms, NO_HZ) with this patch, and wonder if the hunk below makes any
difference whatsoever for you. Here, it definitely does. (shouldn't)
Index: linux-2.6/kernel/sched_fair.c
===================================================================
--- linux-2.6.orig/kernel/sched_fair.c
+++ linux-2.6/kernel/sched_fair.c
@@ -495,8 +495,10 @@ static void update_curr(struct cfs_rq *c
u64 now = rq_of(cfs_rq)->clock;
unsigned long delta_exec;
- if (unlikely(!curr))
+ if (unlikely(!curr)) {
+ update_rq_clock(rq_of(cfs_rq));
return;
+ }
/*
* Get the amount of time the current task was running
^ permalink raw reply
* Re: [2.6.32-rc3] iwlagn lost connection after s2ram (with warnings)
From: Carlos R. Mafra @ 2009-10-08 18:15 UTC (permalink / raw)
To: reinette chatre
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
johannes
In-Reply-To: <1255023883.26521.13298.camel@rc-desk>
Hi Reinette,
On Thu 8.Oct'09 at 10:44:43 -0700, reinette chatre wrote:
> Hi Carlos,
>
> On Wed, 2009-10-07 at 07:20 -0700, Carlos R. Mafra wrote:
> > I just got these warnings after resuming from a suspend to RAM, and
> > the wireless connection was not resumed (now I am connected via eth0).
> > This is the first time I had a failed wireless resume since 2.6.32-rc1.
> >
> > The full dmesg is here: http://www.aei.mpg.de/~crmafra/dmesg-2.6.32-rc3-wifi.txt
> >
> > [ 3427.570113] Restarting tasks ...
> > [ 3427.585827] wlan0: deauthenticated from 00:0b:86:26:36:f1 (Reason: 6)
> > [ 3427.589451] done.
> > [ 3428.503203] input: PS/2 Mouse as /devices/platform/i8042/serio4/input/input15
> > [ 3428.521064] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio4/input/input16
> > [ 3434.504175] wlan0: direct probe to AP 00:0b:86:26:36:f1 (try 1)
> > [ 3434.507058] wlan0: direct probe responded
> > [ 3434.507062] wlan0: authenticate with AP 00:0b:86:26:36:f1 (try 1)
> > [ 3434.509000] wlan0: authenticated
> > [ 3434.509022] wlan0: associate with AP 00:0b:86:26:36:f1 (try 1)
> > [ 3434.512778] wlan0: RX ReassocResp from 00:0b:86:26:36:f1 (capab=0x431 status=0 aid=2)
> > [ 3434.512782] wlan0: associated
> > [ 3434.563942] wlan0: deauthenticating from 00:0b:86:26:36:f1 by local choice (reason=3)
>
> You mention you are trying to connect again after a resume. The message
> above indicates that userspace (maybe wpa_supplicant ?) requested that
> the connection be closed. Do you maybe know how this could have been
> triggered?
I have two processes that are always running,
/usr/sbin/wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant.conf -D wext
/sbin/ifplugd -I -b -i wlan0
and I guess they are the "userspace" that do automatic things to reconnect.
But I have no idea about what happened, or how it happened. I simply resumed from
s2ram like I always do and got those warnings and no connection.
Today I did the same (with the same kernel), and the connection was resumed just
fine and I got no warnings in dmesg. So it is not easily reproduced :-(
I will keep you informed if it happens again.
^ permalink raw reply
* Re: [ath5k-devel] Regarding changing channel widthlin
From: Bob Copeland @ 2009-10-08 18:15 UTC (permalink / raw)
To: Aditya Bhave; +Cc: Luis R. Rodriguez, ath5k-devel, linux-wireless
In-Reply-To: <4ACBF821.8030508@cmu.edu>
On Tue, Oct 6, 2009 at 10:08 PM, Aditya Bhave <aybhave@cmu.edu> wrote:
> Is there any detailed documentation on the internals of ath5k code?
>
> 1. Description of the data structures
> 2. Flow-diagram of function calls
> 3. What register is used for what aspect of WiFi etc etc
Nope (I think you'll find this is true of most/all drivers).
Most of the intelligence is in the upper layers (mac80211), which are
documented on http://wireless.kernel.org/. Most of the work to enable
it will be in those layers, as Luis said. BTW search the list, several
people have proposed ideas for an infrastructure for channel width
setting.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* compat-wireless-2009-09-23 kernel trace
From: Bringfried Stecklum @ 2009-10-08 17:38 UTC (permalink / raw)
To: linux-wireless
Hi,
below please find the first kernel trace I experienced with compat-wireless.
Regards, Bringfried
Oct 8 19:23:02 extragalactix kernel: [ 4024.700145] ------------[ cut here
]------------
Oct 8 19:23:02 extragalactix kernel: [ 4024.700152] WARNING: at
/home/stecklum/System/src/compat-wireless-2009-09-23/net/wireless/mlme.c:96
cfg80211_send_rx_assoc+0x194/0x230 [cfg80211]()
Oct 8 19:23:02 extragalactix kernel: oundcore snd_page_alloc nvidia(P) i2c_core
wmi button battery ac shpchp intel_agp pci_hotplug ext3 jbd mbcache sd_mod
crc_t10dif ata_generic pata_acpi sg firewire_ohci firewire_core crc_itu_t tg3
libphy thermal processor fan fuse ahci libata scsi_mod vesafb fbcon tileblit
font bitblit softcursor [last unloaded: uhci_hcd]
Oct 8 19:23:02 extragalactix kernel: [ 4024.700577] ---[ end trace
dee592989e451c3a ]---
Oct 8 19:23:02 extragalactix kernel: [ 4024.701580] Dumping ftrace buffer:
Oct 8 19:23:02 extragalactix kernel: [ 4024.701584] (ftrace buffer empty)
Oct 8 19:23:02 extragalactix kernel: oundcore snd_page_alloc nvidia(P) i2c_core
wmi button battery ac shpchp intel_agp pci_hotplug ext3 jbd mbcache sd_mod
crc_t10dif ata_generic pata_acpi sg firewire_ohci firewire_core crc_itu_t tg3
libphy thermal processor fan fuse ahci libata scsi_mod vesafb fbcon tileblit
font bitblit softcursor [last unloaded: uhci_hcd]
Oct 8 19:23:02 extragalactix kernel: [ 4024.701767] Pid: 21150, comm:
wpa_supplicant Tainted: P W 2.6.28-15-generic #51
Oct 8 19:23:02 extragalactix kernel: [ 4024.701772] RIP:
0010:[<ffffffffa0d16ff0>] [<ffffffffa0d16ff0>]
__cfg80211_mlme_deauth+0x70/0x140 [cfg80211]
Oct 8 19:23:02 extragalactix kernel: [ 4024.701797] RSP: 0018:ffff88011a4f5c18
EFLAGS: 00010286
Oct 8 19:23:02 extragalactix kernel: [ 4024.701801] RAX: 0000000000000000 RBX:
ffff88011d1bd810 RCX: 0000000000000006
Oct 8 19:23:02 extragalactix kernel: [ 4024.701806] RDX: 0000000000000000 RSI:
ffff88011a840448 RDI: 0000000000000000
Oct 8 19:23:02 extragalactix kernel: [ 4024.701810] RBP: ffff88011a4f5c78 R08:
ffff88011a840400 R09: ffff88011a4f5c28
Oct 8 19:23:02 extragalactix kernel: [ 4024.701815] R10: ffff88011d1bd000 R11:
ffff880112c90000 R12: 0000000000000000
Oct 8 19:23:02 extragalactix kernel: [ 4024.701819] R13: 0000000000000003 R14:
0000000000000000 R15: 0000000000000000
Oct 8 19:23:02 extragalactix kernel: [ 4024.701825] FS: 00007fe8313c16e0(0000)
GS:ffff88011fc01f00(0000) knlGS:0000000000000000
Oct 8 19:23:02 extragalactix kernel: [ 4024.701830] CS: 0010 DS: 0000 ES: 0000
CR0: 0000000080050033
Oct 8 19:23:02 extragalactix kernel: [ 4024.701834] CR2: 0000000000000000 CR3:
000000011a58a000 CR4: 00000000000006e0
Oct 8 19:23:02 extragalactix kernel: [ 4024.701839] DR0: 0000000000000000 DR1:
0000000000000000 DR2: 0000000000000000
Oct 8 19:23:02 extragalactix kernel: [ 4024.701844] DR3: 0000000000000000 DR6:
00000000ffff0ff0 DR7: 0000000000000400
Oct 8 19:23:02 extragalactix kernel: [ 4024.702120] ---[ end trace
dee592989e451c3a ]---
^ permalink raw reply
* Re: [2.6.32-rc3] iwlagn lost connection after s2ram (with warnings)
From: reinette chatre @ 2009-10-08 17:44 UTC (permalink / raw)
To: Carlos R. Mafra
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
johannes
In-Reply-To: <20091007142031.GA7495@Pilar.aei.mpg.de>
Hi Carlos,
On Wed, 2009-10-07 at 07:20 -0700, Carlos R. Mafra wrote:
> I just got these warnings after resuming from a suspend to RAM, and
> the wireless connection was not resumed (now I am connected via eth0).
> This is the first time I had a failed wireless resume since 2.6.32-rc1.
>
> The full dmesg is here: http://www.aei.mpg.de/~crmafra/dmesg-2.6.32-rc3-wifi.txt
>
> [ 3427.570113] Restarting tasks ...
> [ 3427.585827] wlan0: deauthenticated from 00:0b:86:26:36:f1 (Reason: 6)
> [ 3427.589451] done.
> [ 3428.503203] input: PS/2 Mouse as /devices/platform/i8042/serio4/input/input15
> [ 3428.521064] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio4/input/input16
> [ 3434.504175] wlan0: direct probe to AP 00:0b:86:26:36:f1 (try 1)
> [ 3434.507058] wlan0: direct probe responded
> [ 3434.507062] wlan0: authenticate with AP 00:0b:86:26:36:f1 (try 1)
> [ 3434.509000] wlan0: authenticated
> [ 3434.509022] wlan0: associate with AP 00:0b:86:26:36:f1 (try 1)
> [ 3434.512778] wlan0: RX ReassocResp from 00:0b:86:26:36:f1 (capab=0x431 status=0 aid=2)
> [ 3434.512782] wlan0: associated
> [ 3434.563942] wlan0: deauthenticating from 00:0b:86:26:36:f1 by local choice (reason=3)
You mention you are trying to connect again after a resume. The message
above indicates that userspace (maybe wpa_supplicant ?) requested that
the connection be closed. Do you maybe know how this could have been
triggered?
> [ 3434.564023] ------------[ cut here ]------------
> [ 3434.564039] WARNING: at net/wireless/mlme.c:96 cfg80211_send_rx_assoc+0x193/0x230()
This warning and the one below indicates that there is no information
available for this BSS. Maybe Johannes knows why this can be?
> [ 3434.564045] Hardware name: VGN-FZ240E
> [ 3434.564049] Modules linked in: usbhid nvram dvb_usb_dib0700 dib7000p dib7000m dib0070 dvb_usb dib3000mc dib8000 dibx000_common snd_hda_codec_idt uvcvideo snd_hda_intel snd_hda_codec ehci_hcd sg uhci_hcd snd_hwdep sky2 iwlagn i2c_i801 sr_mod evdev ata_piix ahci libata sd_mod scsi_mod
> [ 3434.564104] Pid: 2319, comm: phy0 Not tainted 2.6.32-rc3 #204
> [ 3434.564109] Call Trace:
> [ 3434.564119] [<ffffffff81420dd3>] ? cfg80211_send_rx_assoc+0x193/0x230
> [ 3434.564131] [<ffffffff81047cb8>] warn_slowpath_common+0x78/0xd0
> [ 3434.564139] [<ffffffff81047d1f>] warn_slowpath_null+0xf/0x20
> [ 3434.564147] [<ffffffff81420dd3>] cfg80211_send_rx_assoc+0x193/0x230
> [ 3434.564156] [<ffffffff814316cb>] ieee80211_sta_work+0x2fb/0x1100
> [ 3434.564166] [<ffffffff81453b1f>] ? _spin_unlock_bh+0xf/0x20
> [ 3434.564175] [<ffffffff8142802a>] ? ieee80211_configure_filter+0x11a/0x170
> [ 3434.564183] [<ffffffff814313d0>] ? ieee80211_sta_work+0x0/0x1100
> [ 3434.564193] [<ffffffff8105e9e2>] worker_thread+0x182/0x260
> [ 3434.564203] [<ffffffff81063320>] ? autoremove_wake_function+0x0/0x40
> [ 3434.564211] [<ffffffff8105e860>] ? worker_thread+0x0/0x260
> [ 3434.564219] [<ffffffff81062f06>] kthread+0x96/0xb0
> [ 3434.564229] [<ffffffff8100cd1a>] child_rip+0xa/0x20
> [ 3434.564237] [<ffffffff81062e70>] ? kthread+0x0/0xb0
> [ 3434.564245] [<ffffffff8100cd10>] ? child_rip+0x0/0x20
> [ 3434.564250] ---[ end trace 99d6122abfa316f7 ]---
> [ 3434.564272] ------------[ cut here ]------------
> [ 3434.564280] WARNING: at net/wireless/sme.c:417 __cfg80211_connect_result+0x343/0x380()
> [ 3434.564285] Hardware name: VGN-FZ240E
> [ 3434.564289] Modules linked in: usbhid nvram dvb_usb_dib0700 dib7000p dib7000m dib0070 dvb_usb dib3000mc dib8000 dibx000_common snd_hda_codec_idt uvcvideo snd_hda_intel snd_hda_codec ehci_hcd sg uhci_hcd snd_hwdep sky2 iwlagn i2c_i801 sr_mod evdev ata_piix ahci libata sd_mod scsi_mod
> [ 3434.564335] Pid: 2319, comm: phy0 Tainted: G W 2.6.32-rc3 #204
> [ 3434.564340] Call Trace:
> [ 3434.564347] [<ffffffff81453b1f>] ? _spin_unlock_bh+0xf/0x20
> [ 3434.564355] [<ffffffff814236e3>] ? __cfg80211_connect_result+0x343/0x380
> [ 3434.564364] [<ffffffff81047cb8>] warn_slowpath_common+0x78/0xd0
> [ 3434.564373] [<ffffffff81047d1f>] warn_slowpath_null+0xf/0x20
> [ 3434.564381] [<ffffffff814236e3>] __cfg80211_connect_result+0x343/0x380
> [ 3434.564389] [<ffffffff814509a2>] ? dump_stack+0x72/0x7b
> [ 3434.564397] [<ffffffff81420e10>] cfg80211_send_rx_assoc+0x1d0/0x230
> [ 3434.564405] [<ffffffff814316cb>] ieee80211_sta_work+0x2fb/0x1100
> [ 3434.564413] [<ffffffff81453b1f>] ? _spin_unlock_bh+0xf/0x20
> [ 3434.564421] [<ffffffff8142802a>] ? ieee80211_configure_filter+0x11a/0x170
> [ 3434.564429] [<ffffffff814313d0>] ? ieee80211_sta_work+0x0/0x1100
> [ 3434.564438] [<ffffffff8105e9e2>] worker_thread+0x182/0x260
> [ 3434.564447] [<ffffffff81063320>] ? autoremove_wake_function+0x0/0x40
> [ 3434.564455] [<ffffffff8105e860>] ? worker_thread+0x0/0x260
> [ 3434.564463] [<ffffffff81062f06>] kthread+0x96/0xb0
> [ 3434.564471] [<ffffffff8100cd1a>] child_rip+0xa/0x20
> [ 3434.564479] [<ffffffff81062e70>] ? kthread+0x0/0xb0
> [ 3434.564487] [<ffffffff8100cd10>] ? child_rip+0x0/0x20
> [ 3434.564492] ---[ end trace 99d6122abfa316f8 ]---
> [ 3434.962611] Registered led device: iwl-phy0::radio
> [ 3434.962629] Registered led device: iwl-phy0::assoc
> [ 3434.962645] Registered led device: iwl-phy0::RX
> [ 3434.962661] Registered led device: iwl-phy0::TX
> [ 3435.000526] ADDRCONF(NETDEV_UP): wlan0: link is not ready
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Prism54/p54pci
From: Larry Finger @ 2009-10-08 16:28 UTC (permalink / raw)
To: James Grossmann; +Cc: linux-wireless
In-Reply-To: <167ae39b0910071400n218d3d9ey7711b1011f290a73@mail.gmail.com>
On 10/07/2009 04:00 PM, James Grossmann wrote:
> I have the gigafast WF728-AEX, which doesn't seem to work with the
> p54pci drivers, I was previously using it with my Thinkpad T23 under
> Gentoo (gentoo kernels 2.6.29 and 2.6.30), and could only use the
> 1.0.4.3 firmware, now, I am using it under Ubuntu 9.04
> (2.6.28-15-generic kernel) on the same computer, and find that I have
> to load the prism54 driver to make it work.
> I noticed that you were considering this to be depricated, I hope that
> you can help me to make p54pci work!
As it works with 2.6.29 and 2.6.30 kernels, but not with 2.6.28, it
seems likely that you need a later version of the driver. Does Ubuntu
have a package for compat-wireless? If so, install it. If not, you
will need to install from source.
Larry
^ permalink raw reply
* Re: [PATCH] wireless: make WEXT_SPY and WEXT_PRIV select WEXT_CORE
From: Randy Dunlap @ 2009-10-08 15:06 UTC (permalink / raw)
To: Johannes Berg
Cc: John W. Linville, linux-wireless, Stephen Rothwell, linux-next,
linux-kernel
In-Reply-To: <1254995282.3713.18.camel@johannes.local>
On Thu, 08 Oct 2009 11:48:02 +0200 Johannes Berg wrote:
> On Wed, 2009-10-07 at 17:12 -0700, Randy Dunlap wrote:
>
> > > > # CONFIG_WIRELESS is not set
> > > > CONFIG_WIRELESS_EXT=y
> > > > CONFIG_WEXT_SPY=y
> > > > CONFIG_WEXT_PRIV=y
> > > >
> > > > WEXT_CORE is not enabled. I haven't found the culprit, but I suspect "select".
> > >
> > > Interesting.
> > >
> > > > but what in WIRELESS_EXT would also cause WEXT_CORE to be enabled?
> > >
> > > Well, the way WEXT_CORE is defined as def_bool y ought to, no?
> >
> > Ah, I see what you mean.
> >
> > Here's what's happening:
> >
> > net/wireless/Kconfig says:
> >
> > config WEXT_CORE
> > def_bool y
> > depends on CFG80211_WEXT || WIRELESS_EXT
> >
> >
> > and net/Kconfig says:
> >
> > if WIRELESS
> >
> > source "net/wireless/Kconfig"
> > source "net/mac80211/Kconfig"
> >
> > endif # WIRELESS
> >
> >
> > so WEXT_CORE actually depends on NET && WIRELESS && (CFG80211_WEXT || WIRELESS_EXT)
> > (that's what xconfig shows me).
> > But WIRELESS is not enabled. Pooh.
> >
> > I was already toying with making CONFIG_WIRELESS a real/usable kconfig symbol.
> > That may have to be done unless someone else comes up with another solution.
>
> Ah!
>
> It's kinda strange though that you can select wireless drivers without
> selecting WIRELESS. Maybe the solution is as simple as making WLAN
> (drivers/net/wireless/Kconfig) depend on WIRELESS?
Yes, I think that would be a very good start.
---
~Randy
^ permalink raw reply
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Arjan van de Ven @ 2009-10-08 15:09 UTC (permalink / raw)
To: Frans Pop
Cc: Mike Galbraith, Linux Kernel Mailing List, Ingo Molnar,
Peter Zijlstra, linux-wireless
In-Reply-To: <200910081655.37485.elendil@planet.nl>
On Thu, 8 Oct 2009 16:55:36 +0200
Frans Pop <elendil@planet.nl> wrote:
> > It turns out that on x86, these two 'opportunistic' timers only
> > get checked when another "real" timer happens.
> > These opportunistic timers have the objective to save power by
> > hitchhiking on other wakeups, as to avoid CPU wakeups by themselves
> > as much as possible.
>
> This patch makes quite a difference for me. iwlagn and phy0 now
> consistently show at ~10 ms or lower.\
most excellent
> I do still get occasional high latencies, but those are for things
> like "[rpc_wait_bit_killable]" or "Writing a page to disk", where I
> guess you'd expect them. Those high latencies are mostly only listed
> for "Global" and don't translate to individual processes.
and they're very different types of latencies, caused by disk and such.
> The ~10 ms I still get for iwlagn and phy0 (and sometimes higher (~30
> ms) for others like Xorg and artsd) is still "Scheduler: waiting for
> cpu'. If it is actually due to (un)interuptable sleep, isn't that a
> misleading label? I directly associated that with scheduler latency.
it's actually the time between wakeup and running, as measured by
scheduler statistics
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply
* Re: NULL pointer deref at wext ioctl (Re: [PATCH] compat-2.6: adding ethtool.h to compat-2.6.31.h)
From: Luis R. Rodriguez @ 2009-10-08 14:59 UTC (permalink / raw)
To: John W. Linville
Cc: Johannes Berg, reinette chatre, Hin-Tak Leung, linux-wireless
In-Reply-To: <20091008144352.GA2869@tuxdriver.com>
On Thu, Oct 8, 2009 at 10:43 AM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Thu, Oct 08, 2009 at 10:28:33AM -0400, Luis R. Rodriguez wrote:
>> On Thu, Oct 8, 2009 at 9:43 AM, Luis R. Rodriguez
>> <lrodriguez@atheros.com> wrote:
>> > On Thu, Oct 8, 2009 at 7:50 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
>> >> On Thu, 2009-10-08 at 11:51 +0200, Johannes Berg wrote:
>> >>
>> >>> Ok, that's odd. Is it possible that somehow cfg80211 is picking up an
>> >>> #ifdef'ed copy of "struct iw_handler_def", and thus the struct it is
>> >>> defining is simply too small?
>> >>
>> >> That is apparently what is happening since compat-wireless ships
>> >> iw_handler.h. This is wrong, as wext functionality is built into the
>> >> kernel image so you can't use a newer header file with it.
>> >
>> > Dah, thanks for looking into this! This must've been there this way
>> > for ages and we hadn't noticed until now. This is now fixed, and a new
>> > tarball pushed out. I'll fix on the stable stuff as well, although I
>> > doubt the header has changed much except now.
>>
>> OK so iw_handler added the libipw pointer, so libipw and friends are
>> now messed up on compat-wireless. Do we care? I'll disable them for
>> now. Can't think of a way to backport this easily.
>>
>> CC [M] /home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.o
>> /home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.c:
>> In function ‘ipw2100_alloc_device’:
>> /home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.c:6060:
>> error: ‘struct iw_public_data’ has no member named ‘libipw’
>> make[4]: *** [/home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.o]
>> Error 1
>
> - /* Structure managed by the in-kernel IEEE 802.11 layer */
> - struct ieee80211_device * ieee80211;
> + /* Legacy structure managed by the ipw2x00-specific IEEE 802.11 layer */
> + struct libipw_device * libipw;
>
> Really just a name change, FWIW...
oh ok thanks, thought the struct changed too -- then is be easy to backport
Luis
^ permalink raw reply
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Frans Pop @ 2009-10-08 14:55 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Mike Galbraith, Linux Kernel Mailing List, Ingo Molnar,
Peter Zijlstra, linux-wireless
In-Reply-To: <20091008064041.67219b13@infradead.org>
On Thursday 08 October 2009, Arjan van de Ven wrote:
> From: Arjan van de Ven <arjan@linux.intel.com>
> Date: Thu, 24 Sep 2009 13:24:16 +0200
> Subject: [PATCH] x86, timers: check for pending timers after (device)
> interrupts
>
> Now that range timers and deferred timers are common, I found a
> problem with these using the "perf timechart" tool.
>
> It turns out that on x86, these two 'opportunistic' timers only
> get checked when another "real" timer happens.
> These opportunistic timers have the objective to save power by
> hitchhiking on other wakeups, as to avoid CPU wakeups by themselves
> as much as possible.
This patch makes quite a difference for me. iwlagn and phy0 now
consistently show at ~10 ms or lower.
I do still get occasional high latencies, but those are for things like
"[rpc_wait_bit_killable]" or "Writing a page to disk", where I guess you'd
expect them. Those high latencies are mostly only listed for "Global" and
don't translate to individual processes.
On Thursday 08 October 2009, Arjan van de Ven wrote:
> On Thu, 08 Oct 2009 13:24:22 +0200 Mike Galbraith <efault@gmx.de> wrote:
> > Latencytop was accounting uninterruptible and interruptible sleep
> > time up to 5ms, which is not the latency the user is looking for.
>
> it is for everything but the scheduler latency!
>
> latencytop wants to show where you're waiting for disk, etc etc.
> that's not "time on runqueue".
The ~10 ms I still get for iwlagn and phy0 (and sometimes higher (~30 ms)
for others like Xorg and artsd) is still "Scheduler: waiting for cpu'. If
it is actually due to (un)interuptable sleep, isn't that a misleading
label? I directly associated that with scheduler latency.
Or are those that are left now real scheduler latencies? The values are now
low enough that they don't indicate a problem.
Thanks,
FJP
P.S. I may be seeing another issue in the latencytop GUI. Sometimes I see
"fsync() on a file (type 'F' for details)". But typing 'F' only gets me a
search for a target starting with "F", no details.
^ permalink raw reply
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Mike Galbraith @ 2009-10-08 14:54 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Frans Pop, Linux Kernel Mailing List, Ingo Molnar, Peter Zijlstra,
linux-wireless
In-Reply-To: <1255011186.7294.1.camel@marge.simson.net>
On Thu, 2009-10-08 at 16:13 +0200, Mike Galbraith wrote:
> On Thu, 2009-10-08 at 06:40 -0700, Arjan van de Ven wrote:
> > On Thu, 08 Oct 2009 06:05:43 +0200
> > Mike Galbraith <efault@gmx.de> wrote:
>
> > > OK, I see latencytop spikes here on an idle box too, to the tune of up
> > > to a _second_. Booting with nohz=off seems to have cured it.
> >
> > interesting..
> >
> >
> > by chance, does this patch fix it ?
>
> I haven't seen incredible yet, but with idle box, have seen > 200ms, so
> would say no.
But this dinky hunk of my patchlet does indeed still fix it right up.
Index: linux-2.6/kernel/sched_fair.c
===================================================================
--- linux-2.6.orig/kernel/sched_fair.c
+++ linux-2.6/kernel/sched_fair.c
@@ -495,8 +495,10 @@ static void update_curr(struct cfs_rq *c
u64 now = rq_of(cfs_rq)->clock;
unsigned long delta_exec;
- if (unlikely(!curr))
+ if (unlikely(!curr)) {
+ update_rq_clock(rq_of(cfs_rq));
return;
+ }
/*
* Get the amount of time the current task was running
We have a clock problem with NO_HZ coming out of idle, so we may well
have real latency issues at the same time, not bogons.
-Mike
^ permalink raw reply
* Re: NULL pointer deref at wext ioctl (Re: [PATCH] compat-2.6: adding ethtool.h to compat-2.6.31.h)
From: John W. Linville @ 2009-10-08 14:43 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Johannes Berg, reinette chatre, Hin-Tak Leung, linux-wireless
In-Reply-To: <43e72e890910080728ra63f1e7w6be3a2af65bc4766@mail.gmail.com>
On Thu, Oct 08, 2009 at 10:28:33AM -0400, Luis R. Rodriguez wrote:
> On Thu, Oct 8, 2009 at 9:43 AM, Luis R. Rodriguez
> <lrodriguez@atheros.com> wrote:
> > On Thu, Oct 8, 2009 at 7:50 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> >> On Thu, 2009-10-08 at 11:51 +0200, Johannes Berg wrote:
> >>
> >>> Ok, that's odd. Is it possible that somehow cfg80211 is picking up an
> >>> #ifdef'ed copy of "struct iw_handler_def", and thus the struct it is
> >>> defining is simply too small?
> >>
> >> That is apparently what is happening since compat-wireless ships
> >> iw_handler.h. This is wrong, as wext functionality is built into the
> >> kernel image so you can't use a newer header file with it.
> >
> > Dah, thanks for looking into this! This must've been there this way
> > for ages and we hadn't noticed until now. This is now fixed, and a new
> > tarball pushed out. I'll fix on the stable stuff as well, although I
> > doubt the header has changed much except now.
>
> OK so iw_handler added the libipw pointer, so libipw and friends are
> now messed up on compat-wireless. Do we care? I'll disable them for
> now. Can't think of a way to backport this easily.
>
> CC [M] /home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.o
> /home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.c:
> In function ‘ipw2100_alloc_device’:
> /home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.c:6060:
> error: ‘struct iw_public_data’ has no member named ‘libipw’
> make[4]: *** [/home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.o]
> Error 1
- /* Structure managed by the in-kernel IEEE 802.11 layer */
- struct ieee80211_device * ieee80211;
+ /* Legacy structure managed by the ipw2x00-specific IEEE 802.11 layer */
+ struct libipw_device * libipw;
Really just a name change, FWIW...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: NULL pointer deref at wext ioctl (Re: [PATCH] compat-2.6: adding ethtool.h to compat-2.6.31.h)
From: Luis R. Rodriguez @ 2009-10-08 14:28 UTC (permalink / raw)
To: Johannes Berg, reinette chatre
Cc: Hin-Tak Leung, John W. Linville, linux-wireless
In-Reply-To: <43e72e890910080643h282c4bf1xf972f15f13eae755@mail.gmail.com>
On Thu, Oct 8, 2009 at 9:43 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Thu, Oct 8, 2009 at 7:50 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
>> On Thu, 2009-10-08 at 11:51 +0200, Johannes Berg wrote:
>>
>>> Ok, that's odd. Is it possible that somehow cfg80211 is picking up an
>>> #ifdef'ed copy of "struct iw_handler_def", and thus the struct it is
>>> defining is simply too small?
>>
>> That is apparently what is happening since compat-wireless ships
>> iw_handler.h. This is wrong, as wext functionality is built into the
>> kernel image so you can't use a newer header file with it.
>
> Dah, thanks for looking into this! This must've been there this way
> for ages and we hadn't noticed until now. This is now fixed, and a new
> tarball pushed out. I'll fix on the stable stuff as well, although I
> doubt the header has changed much except now.
OK so iw_handler added the libipw pointer, so libipw and friends are
now messed up on compat-wireless. Do we care? I'll disable them for
now. Can't think of a way to backport this easily.
CC [M] /home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.o
/home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.c:
In function ‘ipw2100_alloc_device’:
/home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.c:6060:
error: ‘struct iw_public_data’ has no member named ‘libipw’
make[4]: *** [/home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.o]
Error 1
Luis
^ permalink raw reply
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Mike Galbraith @ 2009-10-08 14:15 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Frans Pop, Linux Kernel Mailing List, Ingo Molnar, Peter Zijlstra,
linux-wireless
In-Reply-To: <20091008064521.07fae137@infradead.org>
On Thu, 2009-10-08 at 06:45 -0700, Arjan van de Ven wrote:
> On Thu, 08 Oct 2009 13:24:22 +0200
> Mike Galbraith <efault@gmx.de> wrote:
> > Latencytop was accounting uninterruptible and interruptible sleep
> > time up to 5ms, which is not the latency the user is looking for.
>
> it is for everything but the scheduler latency!
>
> latencytop wants to show where you're waiting for disk, etc etc.
> that's not "time on runqueue".
>
> for the scheduler delays a whole different codepath is used!
That explains.. a few things.
-Mike
^ permalink raw reply
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Mike Galbraith @ 2009-10-08 14:13 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Frans Pop, Linux Kernel Mailing List, Ingo Molnar, Peter Zijlstra,
linux-wireless
In-Reply-To: <20091008064041.67219b13@infradead.org>
On Thu, 2009-10-08 at 06:40 -0700, Arjan van de Ven wrote:
> On Thu, 08 Oct 2009 06:05:43 +0200
> Mike Galbraith <efault@gmx.de> wrote:
> > OK, I see latencytop spikes here on an idle box too, to the tune of up
> > to a _second_. Booting with nohz=off seems to have cured it.
>
> interesting..
>
>
> by chance, does this patch fix it ?
I haven't seen incredible yet, but with idle box, have seen > 200ms, so
would say no.
-Mike
^ permalink raw reply
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Arjan van de Ven @ 2009-10-08 13:45 UTC (permalink / raw)
To: Mike Galbraith
Cc: Frans Pop, Linux Kernel Mailing List, Ingo Molnar, Peter Zijlstra,
linux-wireless
In-Reply-To: <1255001062.7500.1.camel@marge.simson.net>
On Thu, 08 Oct 2009 13:24:22 +0200
Mike Galbraith <efault@gmx.de> wrote:
> Latencytop was accounting uninterruptible and interruptible sleep
> time up to 5ms, which is not the latency the user is looking for.
it is for everything but the scheduler latency!
latencytop wants to show where you're waiting for disk, etc etc.
that's not "time on runqueue".
for the scheduler delays a whole different codepath is used!
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply
* Re: NULL pointer deref at wext ioctl (Re: [PATCH] compat-2.6: adding ethtool.h to compat-2.6.31.h)
From: Luis R. Rodriguez @ 2009-10-08 13:43 UTC (permalink / raw)
To: Johannes Berg; +Cc: Hin-Tak Leung, John W. Linville, linux-wireless
In-Reply-To: <1255002647.3713.25.camel@johannes.local>
On Thu, Oct 8, 2009 at 7:50 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Thu, 2009-10-08 at 11:51 +0200, Johannes Berg wrote:
>
>> Ok, that's odd. Is it possible that somehow cfg80211 is picking up an
>> #ifdef'ed copy of "struct iw_handler_def", and thus the struct it is
>> defining is simply too small?
>
> That is apparently what is happening since compat-wireless ships
> iw_handler.h. This is wrong, as wext functionality is built into the
> kernel image so you can't use a newer header file with it.
Dah, thanks for looking into this! This must've been there this way
for ages and we hadn't noticed until now. This is now fixed, and a new
tarball pushed out. I'll fix on the stable stuff as well, although I
doubt the header has changed much except now.
Luis
^ permalink raw reply
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Arjan van de Ven @ 2009-10-08 13:40 UTC (permalink / raw)
To: Mike Galbraith
Cc: Frans Pop, Linux Kernel Mailing List, Ingo Molnar, Peter Zijlstra,
linux-wireless
In-Reply-To: <1254974743.7797.21.camel@marge.simson.net>
On Thu, 08 Oct 2009 06:05:43 +0200
Mike Galbraith <efault@gmx.de> wrote:
> On Wed, 2009-10-07 at 20:34 +0200, Frans Pop wrote:
> > On Wednesday 07 October 2009, Frans Pop wrote:
> > > On Tuesday 06 October 2009, Frans Pop wrote:
> > > > I've checked for 2.6.31.1 now and iwlagn is listed high there
> > > > too when the system is idle, but with normal values of 60-100
> > > > ms. And phy0 has normal values of below 10 ms.
> > > > I've now rebooted with today's mainline git; phy0 now
> > > > frequently shows with values of around 100 ms too (i.e. higher
> > > > than last time).
> > >
> > > Mike privately sent me a script to try to capture the latencies
> > > with perf, but the perf output does not show any high latencies
> > > at all. It looks as if we may have found a bug in latencytop here
> > > instead.
> >
> > Not sure if it's relevant nor what it means, but I frequently see
> > two lines for iwlagn, e.g:
> >
> > Scheduler: waiting for cpu 102.4 msec 99.7
> > % . 3.3 msec 0.3 %
> >
> > I get the same results with both latencytop 0.4 and 0.5.
>
> OK, I see latencytop spikes here on an idle box too, to the tune of up
> to a _second_. Booting with nohz=off seems to have cured it.
interesting..
by chance, does this patch fix it ?
>From 33725d4939f457b12d7bc1bcbcc0dfb8b2f5bd48 Mon Sep 17 00:00:00 2001
From: Arjan van de Ven <arjan@linux.intel.com>
Date: Thu, 24 Sep 2009 13:24:16 +0200
Subject: [PATCH] x86, timers: check for pending timers after (device) interrupts
Now that range timers and deferred timers are common, I found a
problem with these using the "perf timechart" tool.
It turns out that on x86, these two 'opportunistic' timers only
get checked when another "real" timer happens.
These opportunistic timers have the objective to save power by
hitchhiking on other wakeups, as to avoid CPU wakeups by themselves
as much as possible.
The change in this patch runs this check not only at timer interrupts,
but at all (device) interrupts. The effect is that
1) the deferred timers/range timers get delayed less
2) the range timers cause less wakeups by themselves because
the percentage of hitchhiking on existing wakeup events goes up.
I've verified the working of the patch using "perf timechart",
the original exposed bug is gone with this patch.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
---
arch/x86/kernel/irq.c | 2 ++
arch/x86/kernel/smp.c | 1 +
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 74656d1..3912061 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -244,6 +244,7 @@ unsigned int __irq_entry do_IRQ(struct pt_regs *regs)
__func__, smp_processor_id(), vector, irq);
}
+ run_local_timers();
irq_exit();
set_irq_regs(old_regs);
@@ -268,6 +269,7 @@ void smp_generic_interrupt(struct pt_regs *regs)
if (generic_interrupt_extension)
generic_interrupt_extension();
+ run_local_timers();
irq_exit();
set_irq_regs(old_regs);
diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
index ec1de97..d915d95 100644
--- a/arch/x86/kernel/smp.c
+++ b/arch/x86/kernel/smp.c
@@ -198,6 +198,7 @@ void smp_reschedule_interrupt(struct pt_regs *regs)
{
ack_APIC_irq();
inc_irq_stat(irq_resched_count);
+ run_local_timers();
/*
* KVM uses this interrupt to force a cpu out of guest mode
*/
--
1.6.0.6
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply related
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Mike Galbraith @ 2009-10-08 13:18 UTC (permalink / raw)
To: Frans Pop
Cc: Arjan van de Ven, Linux Kernel Mailing List, Ingo Molnar,
Peter Zijlstra, linux-wireless
In-Reply-To: <200910081509.05394.elendil@planet.nl>
On Thu, 2009-10-08 at 15:09 +0200, Frans Pop wrote:
> On Thursday 08 October 2009, Mike Galbraith wrote:
> > Care to try a patch?
> >
> > latencytop: only account on-runqueue wait time as being scheduler
> > latency.
> >
> > Latencytop was accounting uninterruptible and interruptible sleep time
> > up to 5ms, which is not the latency the user is looking for. Account
> > time waiting on-runqueue instead. Also add a clock update to
> > update_curr() for the case where there's nobody home. When coming out
> > of idle with NO_HZ, not updating the clock leads to bogus max latency
> > report.
>
> With this patch the high values for iwlagn and phy0 are gone. The values
> now match roughly with the output of your script.
>
> If (un)interruptible sleep is worth displaying in latencytop then maybe it
> should be identified as a separate cause instead of lumped under "waiting
> for CPU"?
That's what I was just thing about trying, add a cause sleep.
> > TODO: Figure out where the heck empty braces come from.
>
> I also see these lines with "[]" sometimes; looks to come from 'sleep'.
>
> And I still see lines with only a "." as the cause; this seems specific to
> targets marked with the penguin (work queues?).
>
> > Signed-off-by: Mike Galbraith <efault@gmx.de>
> > Arjan van de Ven <arjan@infradead.org>
> > Cc: Ingo Molnar <mingo@elte.hu>
> > Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > LKML-Reference: <new-submission>
>
> If Arjan is happy with the patch, please add my:
Probably just a diagnostic, but...
> Reported-and-tested-by: Frans Pop <elendil@planet.nl>
Saved.
-Mike
^ permalink raw reply
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Frans Pop @ 2009-10-08 13:09 UTC (permalink / raw)
To: Mike Galbraith
Cc: Arjan van de Ven, Linux Kernel Mailing List, Ingo Molnar,
Peter Zijlstra, linux-wireless
In-Reply-To: <1255001062.7500.1.camel@marge.simson.net>
On Thursday 08 October 2009, Mike Galbraith wrote:
> Care to try a patch?
>
> latencytop: only account on-runqueue wait time as being scheduler
> latency.
>
> Latencytop was accounting uninterruptible and interruptible sleep time
> up to 5ms, which is not the latency the user is looking for. Account
> time waiting on-runqueue instead. Also add a clock update to
> update_curr() for the case where there's nobody home. When coming out
> of idle with NO_HZ, not updating the clock leads to bogus max latency
> report.
With this patch the high values for iwlagn and phy0 are gone. The values
now match roughly with the output of your script.
If (un)interruptible sleep is worth displaying in latencytop then maybe it
should be identified as a separate cause instead of lumped under "waiting
for CPU"?
> TODO: Figure out where the heck empty braces come from.
I also see these lines with "[]" sometimes; looks to come from 'sleep'.
And I still see lines with only a "." as the cause; this seems specific to
targets marked with the penguin (work queues?).
> Signed-off-by: Mike Galbraith <efault@gmx.de>
> Arjan van de Ven <arjan@infradead.org>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> LKML-Reference: <new-submission>
If Arjan is happy with the patch, please add my:
Reported-and-tested-by: Frans Pop <elendil@planet.nl>
Thanks,
FJP
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox