* 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
* Re: NULL pointer deref at wext ioctl (Re: [PATCH] compat-2.6: adding ethtool.h to compat-2.6.31.h)
From: Johannes Berg @ 2009-10-08 11:50 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Luis R. Rodriguez, John W. Linville, linux-wireless
In-Reply-To: <1254995514.3713.22.camel@johannes.local>
[-- Attachment #1: Type: text/plain, Size: 447 bytes --]
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.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Mike Galbraith @ 2009-10-08 11:24 UTC (permalink / raw)
To: Frans Pop
Cc: Arjan van de Ven, Linux Kernel Mailing List, Ingo Molnar,
Peter Zijlstra, linux-wireless
In-Reply-To: <200910072034.57511.elendil@planet.nl>
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.
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.
After on mostly idle NO_HZ box, was up to a second "waiting for cpu":
LatencyTOP version 0.5 (C) 2008 Intel Corporation
Cause Maximum Percentage
Scheduler: waiting for cpu 9.3 msec 50.3 %
[sysret_careful] 9.1 msec 21.6 %
Waiting for data on unix socket 7.9 msec 0.5 %
Waiting for event (select) 3.8 msec 21.8 %
[retint_careful] 1.2 msec 2.4 %
[] 0.4 msec 0.0 %
Waiting for event (poll) 0.4 msec 0.4 %
[__cond_resched] 0.4 msec 0.0 %
Userspace lock contention 0.2 msec 3.0 %
TODO: Examine migration, pull may create max latency fib.
TODO: Figure out where the heck empty braces come from.
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>
---
include/linux/latencytop.h | 6 +++---
kernel/latencytop.c | 19 +------------------
kernel/sched_fair.c | 16 +++++++++-------
3 files changed, 13 insertions(+), 28 deletions(-)
Index: linux-2.6/include/linux/latencytop.h
===================================================================
--- linux-2.6.orig/include/linux/latencytop.h
+++ linux-2.6/include/linux/latencytop.h
@@ -26,12 +26,12 @@ struct latency_record {
struct task_struct;
extern int latencytop_enabled;
-void __account_scheduler_latency(struct task_struct *task, int usecs, int inter);
+void __account_scheduler_latency(struct task_struct *task, unsigned long usecs);
static inline void
-account_scheduler_latency(struct task_struct *task, int usecs, int inter)
+account_scheduler_latency(struct task_struct *task, unsigned long usecs)
{
if (unlikely(latencytop_enabled))
- __account_scheduler_latency(task, usecs, inter);
+ __account_scheduler_latency(task, usecs);
}
void clear_all_latency_tracing(struct task_struct *p);
Index: linux-2.6/kernel/latencytop.c
===================================================================
--- linux-2.6.orig/kernel/latencytop.c
+++ linux-2.6/kernel/latencytop.c
@@ -157,34 +157,17 @@ static inline void store_stacktrace(stru
* __account_scheduler_latency - record an occured latency
* @tsk - the task struct of the task hitting the latency
* @usecs - the duration of the latency in microseconds
- * @inter - 1 if the sleep was interruptible, 0 if uninterruptible
*
* This function is the main entry point for recording latency entries
* as called by the scheduler.
- *
- * This function has a few special cases to deal with normal 'non-latency'
- * sleeps: specifically, interruptible sleep longer than 5 msec is skipped
- * since this usually is caused by waiting for events via select() and co.
- *
- * Negative latencies (caused by time going backwards) are also explicitly
- * skipped.
*/
void __sched
-__account_scheduler_latency(struct task_struct *tsk, int usecs, int inter)
+__account_scheduler_latency(struct task_struct *tsk, unsigned long usecs)
{
unsigned long flags;
int i, q;
struct latency_record lat;
- /* Long interruptible waits are generally user requested... */
- if (inter && usecs > 5000)
- return;
-
- /* Negative sleeps are time going backwards */
- /* Zero-time sleeps are non-interesting */
- if (usecs <= 0)
- return;
-
memset(&lat, 0, sizeof(lat));
lat.count = 1;
lat.time = usecs;
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
@@ -548,8 +550,11 @@ update_stats_wait_end(struct cfs_rq *cfs
rq_of(cfs_rq)->clock - se->wait_start);
#ifdef CONFIG_SCHEDSTATS
if (entity_is_task(se)) {
- trace_sched_stat_wait(task_of(se),
- rq_of(cfs_rq)->clock - se->wait_start);
+ struct task_struct *tsk = task_of(se);
+ u64 delta = rq_of(cfs_rq)->clock - se->wait_start;
+
+ trace_sched_stat_wait(tsk, delta);
+ account_scheduler_latency(tsk, delta >> 10);
}
#endif
schedstat_set(se->wait_start, 0);
@@ -643,10 +648,8 @@ static void enqueue_sleeper(struct cfs_r
se->sleep_start = 0;
se->sum_sleep_runtime += delta;
- if (tsk) {
- account_scheduler_latency(tsk, delta >> 10, 1);
+ if (tsk)
trace_sched_stat_sleep(tsk, delta);
- }
}
if (se->block_start) {
u64 delta = rq_of(cfs_rq)->clock - se->block_start;
@@ -677,7 +680,6 @@ static void enqueue_sleeper(struct cfs_r
(void *)get_wchan(tsk),
delta >> 20);
}
- account_scheduler_latency(tsk, delta >> 10, 0);
}
}
#endif
^ 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: Johannes Berg @ 2009-10-08 9:51 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Luis R. Rodriguez, John W. Linville, linux-wireless
In-Reply-To: <3ace41890910072328n1460ee34v1fe7ca9b78eb646f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]
On Thu, 2009-10-08 at 07:28 +0100, Hin-Tak Leung wrote:
> It looks like it is the 2nd of thes two lines around
> /usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:448
> which resulted in the null pointer dereference:
>
> if (index < dev->wireless_handlers->num_private)
> return dev->wireless_handlers->private[index];
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? You can figure that out with debug info,
presumably, but I'm not entirely sure how. Actually maybe nm would tell
you too, if you look for cfg80211_wext_handler.
What I mean is this -- cfg80211 defines cfg80211_wext_handler:
const struct iw_handler_def cfg80211_wext_handler
.num_standard
.standard
.get_wireless_stats
but the core expects
.num_standard
.standard
.num_private
.num_private_args
.private
.private_args
.get_wireless_stats
as such .num_private ends up non-zero because it's shadowed
by .get_wireles_stats.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ 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