* Re: [PATCH] iwlagn: check for !priv->txq in iwlagn_wait_tx_queue_empty
2011-07-25 19:38 [PATCH] iwlagn: check for !priv->txq in iwlagn_wait_tx_queue_empty Keith Packard
@ 2011-07-25 19:21 ` Guy, Wey-Yi
2011-07-25 20:03 ` Keith Packard
2011-07-25 19:36 ` wwguy
1 sibling, 1 reply; 9+ messages in thread
From: Guy, Wey-Yi @ 2011-07-25 19:21 UTC (permalink / raw)
To: Keith Packard
Cc: Intel Linux Wireless, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org
On Mon, 2011-07-25 at 12:38 -0700, Keith Packard wrote:
> If the interface is down, txq is NULL. iwlagn_wait_tx_queue_empty
> needs to check for this case to avoid dereferencing that pointer.
>
> Signed-off-by: Keith Packard <keithp@keithp.com>
> ---
>
> This is on top of v3.0
>
> drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> index f803fb6..d6ae444 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> @@ -1487,6 +1487,9 @@ int iwlagn_wait_tx_queue_empty(struct iwl_priv *priv)
> unsigned long now = jiffies;
> int ret = 0;
>
> + if (!priv->txq)
> + return 0;
> +
> /* waiting for all the tx frames complete might take a while */
> for (cnt = 0; cnt < priv->hw_params.max_txq_num; cnt++) {
> if (cnt == priv->cmd_queue)
but why you need it?, "start device" call will fail if can not allocate
priv->txq
Thanks
Wey
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] iwlagn: check for !priv->txq in iwlagn_wait_tx_queue_empty
2011-07-25 19:38 [PATCH] iwlagn: check for !priv->txq in iwlagn_wait_tx_queue_empty Keith Packard
2011-07-25 19:21 ` Guy, Wey-Yi
@ 2011-07-25 19:36 ` wwguy
2011-07-25 19:43 ` Keith Packard
1 sibling, 1 reply; 9+ messages in thread
From: wwguy @ 2011-07-25 19:36 UTC (permalink / raw)
To: Keith Packard
Cc: Intel Linux Wireless, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org
On Mon, 2011-07-25 at 12:38 -0700, Keith Packard wrote:
> If the interface is down, txq is NULL. iwlagn_wait_tx_queue_empty
> needs to check for this case to avoid dereferencing that pointer.
>
> Signed-off-by: Keith Packard <keithp@keithp.com>
> ---
>
> This is on top of v3.0
>
> drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> index f803fb6..d6ae444 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> @@ -1487,6 +1487,9 @@ int iwlagn_wait_tx_queue_empty(struct iwl_priv *priv)
> unsigned long now = jiffies;
> int ret = 0;
>
> + if (!priv->txq)
> + return 0;
> +
> /* waiting for all the tx frames complete might take a while */
> for (cnt = 0; cnt < priv->hw_params.max_txq_num; cnt++) {
> if (cnt == priv->cmd_queue)
is this against any bug in bugzilla? please include the information in
description
Thanks
Wey
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] iwlagn: check for !priv->txq in iwlagn_wait_tx_queue_empty
@ 2011-07-25 19:38 Keith Packard
2011-07-25 19:21 ` Guy, Wey-Yi
2011-07-25 19:36 ` wwguy
0 siblings, 2 replies; 9+ messages in thread
From: Keith Packard @ 2011-07-25 19:38 UTC (permalink / raw)
To: Wey-Yi Guy, Intel Linux Wireless
Cc: linux-wireless, linux-kernel, Keith Packard
If the interface is down, txq is NULL. iwlagn_wait_tx_queue_empty
needs to check for this case to avoid dereferencing that pointer.
Signed-off-by: Keith Packard <keithp@keithp.com>
---
This is on top of v3.0
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
index f803fb6..d6ae444 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
@@ -1487,6 +1487,9 @@ int iwlagn_wait_tx_queue_empty(struct iwl_priv *priv)
unsigned long now = jiffies;
int ret = 0;
+ if (!priv->txq)
+ return 0;
+
/* waiting for all the tx frames complete might take a while */
for (cnt = 0; cnt < priv->hw_params.max_txq_num; cnt++) {
if (cnt == priv->cmd_queue)
--
1.7.5.4
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] iwlagn: check for !priv->txq in iwlagn_wait_tx_queue_empty
2011-07-25 19:36 ` wwguy
@ 2011-07-25 19:43 ` Keith Packard
0 siblings, 0 replies; 9+ messages in thread
From: Keith Packard @ 2011-07-25 19:43 UTC (permalink / raw)
To: wwguy
Cc: Intel Linux Wireless, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 349 bytes --]
On Mon, 25 Jul 2011 12:36:34 -0700, wwguy <wey-yi.w.guy@intel.com> wrote:
> is this against any bug in bugzilla? please include the information in
> description
I looked in bugzilla and didn't find anything matching -- the only
iwlagn suspend bug I could find was already resolved and completely
different.
--
keith.packard@intel.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] iwlagn: check for !priv->txq in iwlagn_wait_tx_queue_empty
2011-07-25 19:21 ` Guy, Wey-Yi
@ 2011-07-25 20:03 ` Keith Packard
2011-07-25 20:59 ` wwguy
0 siblings, 1 reply; 9+ messages in thread
From: Keith Packard @ 2011-07-25 20:03 UTC (permalink / raw)
To: Guy, Wey-Yi
Cc: Intel Linux Wireless, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 357 bytes --]
On Mon, 25 Jul 2011 12:21:55 -0700, "Guy, Wey-Yi" <wey-yi.w.guy@intel.com> wrote:
> but why you need it?, "start device" call will fail if can not allocate
> priv->txq
The device is down, so start_device was never called. At least, that's
my assumption -- I've got the wireless device 'disabled' in
NetworkManager.
--
keith.packard@intel.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] iwlagn: check for !priv->txq in iwlagn_wait_tx_queue_empty
2011-07-25 20:03 ` Keith Packard
@ 2011-07-25 20:59 ` wwguy
2011-07-26 6:45 ` Keith Packard
0 siblings, 1 reply; 9+ messages in thread
From: wwguy @ 2011-07-25 20:59 UTC (permalink / raw)
To: Keith Packard
Cc: Intel Linux Wireless, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org
On Mon, 2011-07-25 at 13:03 -0700, Keith Packard wrote:
> On Mon, 25 Jul 2011 12:21:55 -0700, "Guy, Wey-Yi" <wey-yi.w.guy@intel.com> wrote:
>
> > but why you need it?, "start device" call will fail if can not allocate
> > priv->txq
>
> The device is down, so start_device was never called. At least, that's
> my assumption -- I've got the wireless device 'disabled' in
> NetworkManager.
>
the iwlagn_wait_tx_queue_empty() function only can be call from either
"flush" operation or from debugfs. I agree it is a problem if call from
debugfs. did you actually see the problem when it is not from debugfs().
there is a recent patch in mac80211 to make sure do not call "flush" is
not needed.
Thanks
Wey
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] iwlagn: check for !priv->txq in iwlagn_wait_tx_queue_empty
2011-07-25 20:59 ` wwguy
@ 2011-07-26 6:45 ` Keith Packard
2011-07-26 13:22 ` Guy, Wey-Yi
0 siblings, 1 reply; 9+ messages in thread
From: Keith Packard @ 2011-07-26 6:45 UTC (permalink / raw)
To: wwguy
Cc: Intel Linux Wireless, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 5166 bytes --]
On Mon, 25 Jul 2011 13:59:07 -0700, wwguy <wey-yi.w.guy@intel.com> wrote:
> On Mon, 2011-07-25 at 13:03 -0700, Keith Packard wrote:
> > On Mon, 25 Jul 2011 12:21:55 -0700, "Guy, Wey-Yi" <wey-yi.w.guy@intel.com> wrote:
> >
> > > but why you need it?, "start device" call will fail if can not allocate
> > > priv->txq
> >
> > The device is down, so start_device was never called. At least, that's
> > my assumption -- I've got the wireless device 'disabled' in
> > NetworkManager.
> >
> the iwlagn_wait_tx_queue_empty() function only can be call from either
> "flush" operation or from debugfs. I agree it is a problem if call from
> debugfs. did you actually see the problem when it is not from
> debugfs().
Yes. Here's the stack trace, which is from a suspend operation:
[ 503.649555] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
[ 503.649713] IP: [<ffffffffa025d83b>] iwlagn_wait_tx_queue_empty+0x4b/0xe0 [iwlagn]
[ 503.649824] PGD 21ded3067 PUD 223bc9067 PMD 0
[ 503.649906] Oops: 0000 [#1] SMP
[ 503.649969] CPU 0
[ 503.649997] Modules linked in: netconsole configfs cpufreq_stats rfcomm bnep binfmt_misc decnet uinput fuse nfsd expo
rtfs nfs lockd fscache auth_rpcgss nfs_acl sunrpc firewire_sbp2 firewire_core crc_itu_t loop acpi_cpufreq mperf usbhid h
id snd_hda_codec_hdmi snd_hda_codec_conexant btusb bluetooth snd_hda_intel snd_hda_codec snd_hwdep arc4 snd_pcm_oss snd_
mixer_oss snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event battery snd_seq thinkpad_acpi nvram ac snd_timer power_sup
ply snd_seq_device tpm_tis tpm tpm_bios iwlagn psmouse snd evdev i915 mac80211 serio_raw i2c_i801 cfg80211 drm_kms_helpe
r drm rfkill ehci_hcd sdhci_pci sdhci i2c_algo_bit soundcore i2c_core usbcore mmc_core snd_page_alloc e1000e button vide
o thermal processor thermal_sys
[ 503.651329]
[ 503.651357] Pid: 3122, comm: bash Not tainted 3.0.0-00141-g2bb84e0 #110 LENOVO 4286CTO/4286CTO
[ 503.651478] RIP: 0010:[<ffffffffa025d83b>] [<ffffffffa025d83b>] iwlagn_wait_tx_queue_empty+0x4b/0xe0 [iwlagn]
[ 503.651603] RSP: 0018:ffff88022388dce8 EFLAGS: 00010202
[ 503.651666] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 503.651744] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88022f741ce0
[ 503.651823] RBP: 0000000100031d64 R08: dead000000200200 R09: 0000000000000001
[ 503.651900] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
[ 503.651977] R13: ffff88022f741ce0 R14: 0000000000000000 R15: ffff88022f740768
[ 503.652056] FS: 0000000000000000(0000) GS:ffff88023e200000(0063) knlGS:00000000f757c6c0
[ 503.652144] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
[ 503.652208] CR2: 0000000000000004 CR3: 000000021ddf0000 CR4: 00000000000406f0
[ 503.652285] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 503.652362] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 503.652441] Process bash (pid: 3122, threadinfo ffff88022388c000, task ffff88021ddae770)
[ 503.652526] Stack:
[ 503.652557] ffffffff81885740 ffff88022f741ce0 ffff88022f742718 0000000000000000
[ 503.652671] ffff88022f740798 ffffffffa0250772 ffff88022f740798 ffff88022f740520
[ 503.652784] 0000000000000000 ffffffffa0230521 ffffffff81983e40 ffff88022f740288
[ 503.652895] Call Trace:
[ 503.652941] [<ffffffffa0250772>] ? iwlagn_mac_flush+0x72/0xb0 [iwlagn]
[ 503.653028] [<ffffffffa0230521>] ? __ieee80211_suspend+0x51/0x300 [mac80211]
[ 503.653119] [<ffffffffa014dd78>] ? wiphy_suspend+0x48/0x60 [cfg80211]
[ 503.653198] [<ffffffff8131a570>] ? device_pm_wait_for_dev+0x30/0x30
[ 503.653278] [<ffffffffa014dd30>] ? index_show+0x30/0x30 [cfg80211]
[ 503.653351] [<ffffffff8131aa61>] ? legacy_suspend+0x31/0x70
[ 503.653419] [<ffffffff8131abcf>] ? __device_suspend+0x12f/0x170
[ 503.653489] [<ffffffff8131b9c8>] ? dpm_suspend+0x48/0x1b0
[ 503.653559] [<ffffffff8108deef>] ? suspend_devices_and_enter+0x7f/0x2c0
[ 503.653636] [<ffffffff8108e24d>] ? enter_state+0x11d/0x150
[ 503.656541] [<ffffffff8108d742>] ? state_store+0xc2/0x100
[ 503.659454] [<ffffffff811999f1>] ? sysfs_write_file+0xe1/0x170
[ 503.662310] [<ffffffff8113354e>] ? vfs_write+0xae/0x180
[ 503.665125] [<ffffffff81133877>] ? sys_write+0x47/0x90
[ 503.667903] [<ffffffff8146f455>] ? page_fault+0x25/0x30
[ 503.671084] [<ffffffff81477a00>] ? sysenter_dispatch+0x7/0x2e
[ 503.673924] Code: 31 e4 66 0f 1f 44 00 00 41 0f b6 85 69 0a 00 00 44 39 e0 74 56 49 8b b5 08 3f 00 00 49 63 c4 48 8d
14 80 48 8d 1c 50 48 8d 1c de <8b> 43 04 39 43 08 75 17 eb 36 0f 1f 00 bf 01 00 00 00 e8 be 1e
[ 503.680651] RIP [<ffffffffa025d83b>] iwlagn_wait_tx_queue_empty+0x4b/0xe0 [iwlagn]
[ 503.683809] RSP <ffff88022388dce8>
[ 503.686906] CR2: 0000000000000004
[ 503.690267] ---[ end trace 513210ed9b54a44b ]---
> there is a recent patch in mac80211 to make sure do not call "flush" is
> not needed.
If that avoids calling iwlagn_mac_flush when the interface isn't
running, that should work. I'd appreciate a pointer to the patch so I
can test it.
--
keith.packard@intel.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] iwlagn: check for !priv->txq in iwlagn_wait_tx_queue_empty
2011-07-26 6:45 ` Keith Packard
@ 2011-07-26 13:22 ` Guy, Wey-Yi
2011-07-30 0:52 ` Keith Packard
0 siblings, 1 reply; 9+ messages in thread
From: Guy, Wey-Yi @ 2011-07-26 13:22 UTC (permalink / raw)
To: Keith Packard
Cc: Intel Linux Wireless, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org
On Mon, 2011-07-25 at 23:45 -0700, Keith Packard wrote:
> On Mon, 25 Jul 2011 13:59:07 -0700, wwguy <wey-yi.w.guy@intel.com> wrote:
> > On Mon, 2011-07-25 at 13:03 -0700, Keith Packard wrote:
> > > On Mon, 25 Jul 2011 12:21:55 -0700, "Guy, Wey-Yi" <wey-yi.w.guy@intel.com> wrote:
> > >
> > > > but why you need it?, "start device" call will fail if can not allocate
> > > > priv->txq
> > >
> > > The device is down, so start_device was never called. At least, that's
> > > my assumption -- I've got the wireless device 'disabled' in
> > > NetworkManager.
> > >
>
> > the iwlagn_wait_tx_queue_empty() function only can be call from either
> > "flush" operation or from debugfs. I agree it is a problem if call from
> > debugfs. did you actually see the problem when it is not from
> > debugfs().
>
> Yes. Here's the stack trace, which is from a suspend operation:
>
> [ 503.649555] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
> [ 503.649713] IP: [<ffffffffa025d83b>] iwlagn_wait_tx_queue_empty+0x4b/0xe0 [iwlagn]
> [ 503.649824] PGD 21ded3067 PUD 223bc9067 PMD 0
> [ 503.649906] Oops: 0000 [#1] SMP
> [ 503.649969] CPU 0
> [ 503.649997] Modules linked in: netconsole configfs cpufreq_stats rfcomm bnep binfmt_misc decnet uinput fuse nfsd expo
> rtfs nfs lockd fscache auth_rpcgss nfs_acl sunrpc firewire_sbp2 firewire_core crc_itu_t loop acpi_cpufreq mperf usbhid h
> id snd_hda_codec_hdmi snd_hda_codec_conexant btusb bluetooth snd_hda_intel snd_hda_codec snd_hwdep arc4 snd_pcm_oss snd_
> mixer_oss snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event battery snd_seq thinkpad_acpi nvram ac snd_timer power_sup
> ply snd_seq_device tpm_tis tpm tpm_bios iwlagn psmouse snd evdev i915 mac80211 serio_raw i2c_i801 cfg80211 drm_kms_helpe
> r drm rfkill ehci_hcd sdhci_pci sdhci i2c_algo_bit soundcore i2c_core usbcore mmc_core snd_page_alloc e1000e button vide
> o thermal processor thermal_sys
> [ 503.651329]
> [ 503.651357] Pid: 3122, comm: bash Not tainted 3.0.0-00141-g2bb84e0 #110 LENOVO 4286CTO/4286CTO
> [ 503.651478] RIP: 0010:[<ffffffffa025d83b>] [<ffffffffa025d83b>] iwlagn_wait_tx_queue_empty+0x4b/0xe0 [iwlagn]
> [ 503.651603] RSP: 0018:ffff88022388dce8 EFLAGS: 00010202
> [ 503.651666] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
> [ 503.651744] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88022f741ce0
> [ 503.651823] RBP: 0000000100031d64 R08: dead000000200200 R09: 0000000000000001
> [ 503.651900] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
> [ 503.651977] R13: ffff88022f741ce0 R14: 0000000000000000 R15: ffff88022f740768
> [ 503.652056] FS: 0000000000000000(0000) GS:ffff88023e200000(0063) knlGS:00000000f757c6c0
> [ 503.652144] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
> [ 503.652208] CR2: 0000000000000004 CR3: 000000021ddf0000 CR4: 00000000000406f0
> [ 503.652285] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 503.652362] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 503.652441] Process bash (pid: 3122, threadinfo ffff88022388c000, task ffff88021ddae770)
> [ 503.652526] Stack:
> [ 503.652557] ffffffff81885740 ffff88022f741ce0 ffff88022f742718 0000000000000000
> [ 503.652671] ffff88022f740798 ffffffffa0250772 ffff88022f740798 ffff88022f740520
> [ 503.652784] 0000000000000000 ffffffffa0230521 ffffffff81983e40 ffff88022f740288
> [ 503.652895] Call Trace:
> [ 503.652941] [<ffffffffa0250772>] ? iwlagn_mac_flush+0x72/0xb0 [iwlagn]
> [ 503.653028] [<ffffffffa0230521>] ? __ieee80211_suspend+0x51/0x300 [mac80211]
> [ 503.653119] [<ffffffffa014dd78>] ? wiphy_suspend+0x48/0x60 [cfg80211]
> [ 503.653198] [<ffffffff8131a570>] ? device_pm_wait_for_dev+0x30/0x30
> [ 503.653278] [<ffffffffa014dd30>] ? index_show+0x30/0x30 [cfg80211]
> [ 503.653351] [<ffffffff8131aa61>] ? legacy_suspend+0x31/0x70
> [ 503.653419] [<ffffffff8131abcf>] ? __device_suspend+0x12f/0x170
> [ 503.653489] [<ffffffff8131b9c8>] ? dpm_suspend+0x48/0x1b0
> [ 503.653559] [<ffffffff8108deef>] ? suspend_devices_and_enter+0x7f/0x2c0
> [ 503.653636] [<ffffffff8108e24d>] ? enter_state+0x11d/0x150
> [ 503.656541] [<ffffffff8108d742>] ? state_store+0xc2/0x100
> [ 503.659454] [<ffffffff811999f1>] ? sysfs_write_file+0xe1/0x170
> [ 503.662310] [<ffffffff8113354e>] ? vfs_write+0xae/0x180
> [ 503.665125] [<ffffffff81133877>] ? sys_write+0x47/0x90
> [ 503.667903] [<ffffffff8146f455>] ? page_fault+0x25/0x30
> [ 503.671084] [<ffffffff81477a00>] ? sysenter_dispatch+0x7/0x2e
> [ 503.673924] Code: 31 e4 66 0f 1f 44 00 00 41 0f b6 85 69 0a 00 00 44 39 e0 74 56 49 8b b5 08 3f 00 00 49 63 c4 48 8d
> 14 80 48 8d 1c 50 48 8d 1c de <8b> 43 04 39 43 08 75 17 eb 36 0f 1f 00 bf 01 00 00 00 e8 be 1e
> [ 503.680651] RIP [<ffffffffa025d83b>] iwlagn_wait_tx_queue_empty+0x4b/0xe0 [iwlagn]
> [ 503.683809] RSP <ffff88022388dce8>
> [ 503.686906] CR2: 0000000000000004
> [ 503.690267] ---[ end trace 513210ed9b54a44b ]---
>
> > there is a recent patch in mac80211 to make sure do not call "flush" is
> > not needed.
>
> If that avoids calling iwlagn_mac_flush when the interface isn't
> running, that should work. I'd appreciate a pointer to the patch so I
> can test it.
please apply this patch in wireless-next-2.6
commit 94f9b97be5b3bf67392e43fb7f567721b09142c2
Author: Johannes Berg <johannes.berg@intel.com>
Date: Thu Jul 14 16:48:54 2011 +0200
mac80211: be more careful in suspend/resume
Thanks
Wey
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] iwlagn: check for !priv->txq in iwlagn_wait_tx_queue_empty
2011-07-26 13:22 ` Guy, Wey-Yi
@ 2011-07-30 0:52 ` Keith Packard
0 siblings, 0 replies; 9+ messages in thread
From: Keith Packard @ 2011-07-30 0:52 UTC (permalink / raw)
To: Guy, Wey-Yi
Cc: Intel Linux Wireless, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 367 bytes --]
On Tue, 26 Jul 2011 06:22:08 -0700, "Guy, Wey-Yi" <wey-yi.w.guy@intel.com> wrote:
> commit 94f9b97be5b3bf67392e43fb7f567721b09142c2
> Author: Johannes Berg <johannes.berg@intel.com>
> Date: Thu Jul 14 16:48:54 2011 +0200
>
> mac80211: be more careful in suspend/resume
Yup, that fixed it. Thanks for figuring it out.
--
keith.packard@intel.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-07-30 0:52 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-07-25 19:38 [PATCH] iwlagn: check for !priv->txq in iwlagn_wait_tx_queue_empty Keith Packard
2011-07-25 19:21 ` Guy, Wey-Yi
2011-07-25 20:03 ` Keith Packard
2011-07-25 20:59 ` wwguy
2011-07-26 6:45 ` Keith Packard
2011-07-26 13:22 ` Guy, Wey-Yi
2011-07-30 0:52 ` Keith Packard
2011-07-25 19:36 ` wwguy
2011-07-25 19:43 ` Keith Packard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).