[PATCH] Power Manager suspend-hybrid warn on systemlog

[PATCH] Power Manager suspend-hybrid warn on systemlog

[Alexandre Felipe Muller de Souza]

I'm not shure if it's a correct solution, or if it breaks something on a
specific situation. So I decided to send it to the list, to someone more
experienced if that code send their opinion. I realized that
pm-suspend-hybrid generates a warning on system log (at least in intel
arch):

WARNING: at mm/page_alloc.c:122 pm_restrict_gfp_mask+0x4e/0x50()
Call Trace:
[<c0150f12>] warn_slowpath_common+0x72/0xa0
[<c01da71e>] ? pm_restrict_gfp_mask+0x4e/0x50
[<c01da71e>] ? pm_restrict_gfp_mask+0x4e/0x50
[<c0150f62>] warn_slowpath_null+0x22/0x30
[<c01da71e>] pm_restrict_gfp_mask+0x4e/0x50
[<c018a822>] suspend_devices_and_enter+0x52/0x1d0
[<c015be25>] ? capable+0x15/0x50
[<c018fe30>] snapshot_ioctl+0x2b0/0x5c0
[<c017e3c2>] ? tick_dev_program_event+0x42/0x150
[<c018fb80>] ? snapshot_ioctl+0x0/0x5c0
[<c02269bd>] do_vfs_ioctl+0x8d/0x5b0
[<c029e216>] ? tomoyo_init_request_info+0x46/0x50
[<c029bceb>] ? tomoyo_path_number_perm+0x2b/0xe0
[<c017911d>] ? ktime_get_ts+0xed/0x120
[<c029dad7>] ? tomoyo_file_ioctl+0x17/0x20
[<c0226f47>] sys_ioctl+0x67/0x80
[<c010ae5f>] sysenter_do_call+0x12/0x28

So I put some debugs, and saw 2 sequential calls for
pm_restrict_gfp_mask (in hibernate) that the second call warns it. So I
removed it, and made some tests and seens to work without warn (suspend,
hybrid, hibernate). So my question is: is it safe to do that?
The "problem" was tested and occurs on 2.6.37 and 2.6.38-rc5.
---

diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
--- a/kernel/power/suspend.c 2011-01-04 22:50:19.000000000 -0200
+++ b/kernel/power/suspend.c 2011-02-21 15:39:16.000000000 -0300
@@ -207,7 +207,6 @@
goto Close;
}
suspend_console();
- pm_restrict_gfp_mask();
suspend_test_start();
error = dpm_suspend_start(PMSG_SUSPEND);
if (error) { 

Re: [PATCH] Power Manager suspend-hybrid warn on systemlog

[Pavel Machek]

On Tue 2011-02-22 11:16:15, Alexandre Felipe Muller de Souza wrote:
> I'm not shure if it's a correct solution, or if it breaks something on a
> specific situation. So I decided to send it to the list, to someone more
> experienced if that code send their opinion. I realized that
> pm-suspend-hybrid generates a warning on system log (at least in intel
> arch):

cc: maintainers gets you faster response...

> WARNING: at mm/page_alloc.c:122 pm_restrict_gfp_mask+0x4e/0x50()
> Call Trace:
> [<c0150f12>] warn_slowpath_common+0x72/0xa0
> [<c01da71e>] ? pm_restrict_gfp_mask+0x4e/0x50
> [<c01da71e>] ? pm_restrict_gfp_mask+0x4e/0x50
> [<c0150f62>] warn_slowpath_null+0x22/0x30
> [<c01da71e>] pm_restrict_gfp_mask+0x4e/0x50
> [<c018a822>] suspend_devices_and_enter+0x52/0x1d0
> [<c015be25>] ? capable+0x15/0x50
> [<c018fe30>] snapshot_ioctl+0x2b0/0x5c0
> [<c017e3c2>] ? tick_dev_program_event+0x42/0x150
> [<c018fb80>] ? snapshot_ioctl+0x0/0x5c0
> [<c02269bd>] do_vfs_ioctl+0x8d/0x5b0
> [<c029e216>] ? tomoyo_init_request_info+0x46/0x50
> [<c029bceb>] ? tomoyo_path_number_perm+0x2b/0xe0
> [<c017911d>] ? ktime_get_ts+0xed/0x120
> [<c029dad7>] ? tomoyo_file_ioctl+0x17/0x20
> [<c0226f47>] sys_ioctl+0x67/0x80
> [<c010ae5f>] sysenter_do_call+0x12/0x28
> 
> So I put some debugs, and saw 2 sequential calls for
> pm_restrict_gfp_mask (in hibernate) that the second call warns it. So I
> removed it, and made some tests and seens to work without warn (suspend,
> hybrid, hibernate). So my question is: is it safe to do that?
> The "problem" was tested and occurs on 2.6.37 and 2.6.38-rc5.
> ---
> 
> diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
> --- a/kernel/power/suspend.c 2011-01-04 22:50:19.000000000 -0200
> +++ b/kernel/power/suspend.c 2011-02-21 15:39:16.000000000 -0300
> @@ -207,7 +207,6 @@
> goto Close;
> }
> suspend_console();
> - pm_restrict_gfp_mask();
> suspend_test_start();
> error = dpm_suspend_start(PMSG_SUSPEND);
> if (error) { 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] Power Manager suspend-hybrid warn on systemlog

[Rafael J. Wysocki]

On Tuesday, April 05, 2011, Pavel Machek wrote:
> On Tue 2011-02-22 11:16:15, Alexandre Felipe Muller de Souza wrote:
> > I'm not shure if it's a correct solution, or if it breaks something on a
> > specific situation. So I decided to send it to the list, to someone more
> > experienced if that code send their opinion. I realized that
> > pm-suspend-hybrid generates a warning on system log (at least in intel
> > arch):
> 
> cc: maintainers gets you faster response...
> 
> > WARNING: at mm/page_alloc.c:122 pm_restrict_gfp_mask+0x4e/0x50()
> > Call Trace:
> > [<c0150f12>] warn_slowpath_common+0x72/0xa0
> > [<c01da71e>] ? pm_restrict_gfp_mask+0x4e/0x50
> > [<c01da71e>] ? pm_restrict_gfp_mask+0x4e/0x50
> > [<c0150f62>] warn_slowpath_null+0x22/0x30
> > [<c01da71e>] pm_restrict_gfp_mask+0x4e/0x50
> > [<c018a822>] suspend_devices_and_enter+0x52/0x1d0
> > [<c015be25>] ? capable+0x15/0x50
> > [<c018fe30>] snapshot_ioctl+0x2b0/0x5c0
> > [<c017e3c2>] ? tick_dev_program_event+0x42/0x150
> > [<c018fb80>] ? snapshot_ioctl+0x0/0x5c0
> > [<c02269bd>] do_vfs_ioctl+0x8d/0x5b0
> > [<c029e216>] ? tomoyo_init_request_info+0x46/0x50
> > [<c029bceb>] ? tomoyo_path_number_perm+0x2b/0xe0
> > [<c017911d>] ? ktime_get_ts+0xed/0x120
> > [<c029dad7>] ? tomoyo_file_ioctl+0x17/0x20
> > [<c0226f47>] sys_ioctl+0x67/0x80
> > [<c010ae5f>] sysenter_do_call+0x12/0x28
> > 
> > So I put some debugs, and saw 2 sequential calls for
> > pm_restrict_gfp_mask (in hibernate) that the second call warns it. So I
> > removed it, and made some tests and seens to work without warn (suspend,
> > hybrid, hibernate). So my question is: is it safe to do that?
> > The "problem" was tested and occurs on 2.6.37 and 2.6.38-rc5.
> > ---
> > 
> > diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
> > --- a/kernel/power/suspend.c 2011-01-04 22:50:19.000000000 -0200
> > +++ b/kernel/power/suspend.c 2011-02-21 15:39:16.000000000 -0300
> > @@ -207,7 +207,6 @@
> > goto Close;
> > }
> > suspend_console();
> > - pm_restrict_gfp_mask();
> > suspend_test_start();
> > error = dpm_suspend_start(PMSG_SUSPEND);
> > if (error) { 
> > 

The problem is real, but the fix is not the right one.

Alexandre, please check if the appended patch fixes the warning for you too.

Thanks,
Rafael


---
 kernel/power/user.c |    1 +
 1 file changed, 1 insertion(+)

Index: linux-2.6/kernel/power/user.c
===================================================================
--- linux-2.6.orig/kernel/power/user.c
+++ linux-2.6/kernel/power/user.c
@@ -378,6 +378,7 @@ static long snapshot_ioctl(struct file *
 		 * Tasks are frozen and the notifiers have been called with
 		 * PM_HIBERNATION_PREPARE
 		 */
+		pm_restore_gfp_mask();
 		error = suspend_devices_and_enter(PM_SUSPEND_MEM);
 		break;
 

Re: [PATCH] Power Manager suspend-hybrid warn on systemlog

[Rafael J. Wysocki]

On Monday, April 25, 2011, Rafael J. Wysocki wrote:
> On Tuesday, April 05, 2011, Pavel Machek wrote:
> > On Tue 2011-02-22 11:16:15, Alexandre Felipe Muller de Souza wrote:
> > > I'm not shure if it's a correct solution, or if it breaks something on a
> > > specific situation. So I decided to send it to the list, to someone more
> > > experienced if that code send their opinion. I realized that
> > > pm-suspend-hybrid generates a warning on system log (at least in intel
> > > arch):
> > 
> > cc: maintainers gets you faster response...
> > 
> > > WARNING: at mm/page_alloc.c:122 pm_restrict_gfp_mask+0x4e/0x50()
> > > Call Trace:
> > > [<c0150f12>] warn_slowpath_common+0x72/0xa0
> > > [<c01da71e>] ? pm_restrict_gfp_mask+0x4e/0x50
> > > [<c01da71e>] ? pm_restrict_gfp_mask+0x4e/0x50
> > > [<c0150f62>] warn_slowpath_null+0x22/0x30
> > > [<c01da71e>] pm_restrict_gfp_mask+0x4e/0x50
> > > [<c018a822>] suspend_devices_and_enter+0x52/0x1d0
> > > [<c015be25>] ? capable+0x15/0x50
> > > [<c018fe30>] snapshot_ioctl+0x2b0/0x5c0
> > > [<c017e3c2>] ? tick_dev_program_event+0x42/0x150
> > > [<c018fb80>] ? snapshot_ioctl+0x0/0x5c0
> > > [<c02269bd>] do_vfs_ioctl+0x8d/0x5b0
> > > [<c029e216>] ? tomoyo_init_request_info+0x46/0x50
> > > [<c029bceb>] ? tomoyo_path_number_perm+0x2b/0xe0
> > > [<c017911d>] ? ktime_get_ts+0xed/0x120
> > > [<c029dad7>] ? tomoyo_file_ioctl+0x17/0x20
> > > [<c0226f47>] sys_ioctl+0x67/0x80
> > > [<c010ae5f>] sysenter_do_call+0x12/0x28
> > > 
> > > So I put some debugs, and saw 2 sequential calls for
> > > pm_restrict_gfp_mask (in hibernate) that the second call warns it. So I
> > > removed it, and made some tests and seens to work without warn (suspend,
> > > hybrid, hibernate). So my question is: is it safe to do that?
> > > The "problem" was tested and occurs on 2.6.37 and 2.6.38-rc5.
> > > ---
> > > 
> > > diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
> > > --- a/kernel/power/suspend.c 2011-01-04 22:50:19.000000000 -0200
> > > +++ b/kernel/power/suspend.c 2011-02-21 15:39:16.000000000 -0300
> > > @@ -207,7 +207,6 @@
> > > goto Close;
> > > }
> > > suspend_console();
> > > - pm_restrict_gfp_mask();
> > > suspend_test_start();
> > > error = dpm_suspend_start(PMSG_SUSPEND);
> > > if (error) { 
> > > 
> 
> The problem is real, but the fix is not the right one.
> 
> Alexandre, please check if the appended patch fixes the warning for you too.

Sorry, we actually shouldn't restore the GFP mask while the hibernate image
hasn't been saved yet, so your fix goes into the right direction, but the
pm_restrict_gfp_mask() is needed for the "pure" suspend-to-RAM case.

Please check if the appended patch works for you.

Thanks,
Rafael

---
From: Rafael J. Wysocki <rjw@sisk.pl>
Subject: PM: Fix warning in pm_restrict_gfp_mask() during SNAPSHOT_S2RAM ioctl

A warning is printed by pm_restrict_gfp_mask() while the
SNAPSHOT_S2RAM ioctl is being executed after creating a hibernation
image, because pm_restrict_gfp_mask() has been called once already
before the image creation and suspend_devices_and_enter() calls it
once again.  This happens after commit 452aa6999e6703ffbddd7f6ea124d3
(mm/pm: force GFP_NOIO during suspend/hibernation and resume).

To avoid this issue, move pm_restrict_gfp_mask() and
pm_restore_gfp_mask() from suspend_devices_and_enter() to its caller
in kernel/power/suspend.c.

Reported-by: Alexandre Felipe Muller de Souza <alexandrefm@mandriva.com.br>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 kernel/power/suspend.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: linux-2.6/kernel/power/suspend.c
===================================================================
--- linux-2.6.orig/kernel/power/suspend.c
+++ linux-2.6/kernel/power/suspend.c
@@ -210,7 +210,6 @@ int suspend_devices_and_enter(suspend_st
 			goto Close;
 	}
 	suspend_console();
-	pm_restrict_gfp_mask();
 	suspend_test_start();
 	error = dpm_suspend_start(PMSG_SUSPEND);
 	if (error) {
@@ -227,7 +226,6 @@ int suspend_devices_and_enter(suspend_st
 	suspend_test_start();
 	dpm_resume_end(PMSG_RESUME);
 	suspend_test_finish("resume devices");
-	pm_restore_gfp_mask();
 	resume_console();
  Close:
 	if (suspend_ops->end)
@@ -288,7 +286,9 @@ int enter_state(suspend_state_t state)
 		goto Finish;
 
 	pr_debug("PM: Entering %s sleep\n", pm_states[state]);
+	pm_restrict_gfp_mask();
 	error = suspend_devices_and_enter(state);
+	pm_restore_gfp_mask();
 
  Finish:
 	pr_debug("PM: Finishing wakeup.\n");

Re: [PATCH] Power Manager suspend-hybrid warn on systemlog

[Alexandre Felipe Muller de Souza]

Rafael, thank you a lot for your reply.

Unfortunately something strange occurred when I applied any one of this
2 patches you sent.

The network interface flooded the demsg with many times of that:
WARNING: at net/mac80211/iface.c:718 ieee80211_iface_work+0x305/0x310
[mac80211]()
Hardware name: P MOBILE
interface work scheduled while going to suspend
Modules linked in: option usb_wwan usbserial sit tunnel4 fuse ipt_IFWLOG
ipt_psd cls_flow cls_fw cls_u32 sch_htb sch_hfsc sch_ingress sch_sfq
xt_time xt_connlimit xt_realm iptable_raw xt_comment xt_recent xt_policy
ipt_ULOG ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_ECN
ipt_ecn ipt_CLUSTERIP ipt_ah ipt_addrtype nf_nat_tftp nf_nat_snmp_basic
nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323
nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane
nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp
nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink
nf_conntrack_netbios_ns nf_conntrack_irc nf_conntrack_h323
nf_conntrack_ftp ipt_set ipt_SET ip_set_nethash ip_set_iptreemap
ip_set_iptree ip_set_ipporthash ip_set_portmap ip_set_macipmap
ip_set_ipmap ip_set_iphash ip_set xt_TPROXY nf_tproxy_core ip6_tables
nf_defrag_ipv6 xt_tcpmss xt_pkttype xt_physdev xt_owner xt_NFQUEUE
xt_NFLOG nfnetlink_log xt_multiport xt_mark af_packet xt_mac xt_limit
xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp
xt_conntrack xt_connmark xt_CLASSIFY ipt_LOG xt_tcpudp xt_state
iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack
iptable_mangle nfnetlink iptable_filter ip_tables x_tables ipv6 i915
drm_kms_helper drm i2c_algo_bit binfmt_misc loop dm_mirror
dm_region_hash dm_log dm_mod uvcvideo videodev i2c_core cpufreq_ondemand
cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table mperf
nvram snd_hda_codec_hdmi usbhid hid uas usb_storage
snd_hda_codec_realtek snd_hda_intel arc4 snd_hda_codec snd_hwdep ecb
snd_seq_dummy rtl8192ce snd_seq_oss snd_seq_midi_event snd_seq
snd_seq_device pciehp pci_hotplug snd_pcm_oss snd_pcm rtlwifi snd_timer
snd_mixer_oss snd iTCO_wdt soundcore ehci_hcd iTCO_vendor_support
mac80211 sparse_keymap sg sr_mod r8169 battery mii cfg80211 rfkill
serio_raw wmi snd_page_alloc evdev ac processor thermal button video
usbcore ata_piix ahci libahci libata sd_mod scsi_mod crc_t10dif ext4
jbd2 crc16 [last unloaded: scsi_wait_scan]
Pid: 6209, comm: kworker/u:11 Tainted: G        W
2.6.38.3-server-1mnb2 #1
Call Trace:
 [<c0151a72>] ? warn_slowpath_common+0x72/0xa0
 [<f847f735>] ? ieee80211_iface_work+0x305/0x310 [mac80211]
 [<f847f735>] ? ieee80211_iface_work+0x305/0x310 [mac80211]
 [<c0151b43>] ? warn_slowpath_fmt+0x33/0x40
 [<f847f735>] ? ieee80211_iface_work+0x305/0x310 [mac80211]
 [<c0168cf2>] ? cwq_dec_nr_in_flight+0x52/0x90
 [<c016a300>] ? process_one_work+0x100/0x3a0
 [<c014bd94>] ? wake_up_process+0x14/0x20
 [<c01681f5>] ? start_worker+0x25/0x30
 [<f847f430>] ? ieee80211_iface_work+0x0/0x310 [mac80211]
 [<c016b0ba>] ? worker_thread+0x12a/0x2e0
 [<c016af90>] ? worker_thread+0x0/0x2e0
 [<c016e9ed>] ? kthread+0x6d/0x80
 [<c016e980>] ? kthread+0x0/0x80
 [<c010b43e>] ? kernel_thread_helper+0x6/0x10
---[ end trace bbe4a610450faaf0 ]---
WARNING: at net/mac80211/work.c:904 ieee80211_work_work+0x2bf/0x10e0
[mac80211]()
Hardware name: P MOBILE
work scheduled while going to suspend
Modules linked in: option usb_wwan usbserial sit tunnel4 fuse ipt_IFWLOG
ipt_psd cls_flow cls_fw cls_u32 sch_htb sch_hfsc sch_ingress sch_sfq
xt_time xt_connlimit xt_realm iptable_raw xt_comment xt_recent xt_policy
ipt_ULOG ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_ECN
ipt_ecn ipt_CLUSTERIP ipt_ah ipt_addrtype nf_nat_tftp nf_nat_snmp_basic
nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323
nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane
nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp
nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink
nf_conntrack_netbios_ns nf_conntrack_irc nf_conntrack_h323
nf_conntrack_ftp ipt_set ipt_SET ip_set_nethash ip_set_iptreemap
ip_set_iptree ip_set_ipporthash ip_set_portmap ip_set_macipmap
ip_set_ipmap ip_set_iphash ip_set xt_TPROXY nf_tproxy_core ip6_tables
nf_defrag_ipv6 xt_tcpmss xt_pkttype xt_physdev xt_owner xt_NFQUEUE
xt_NFLOG nfnetlink_log xt_multiport xt_mark af_packet xt_mac xt_limit
xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp
xt_conntrack xt_connmark xt_CLASSIFY ipt_LOG xt_tcpudp xt_state
iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack
iptable_mangle nfnetlink iptable_filter ip_tables x_tables ipv6 i915
drm_kms_helper drm i2c_algo_bit binfmt_misc loop dm_mirror
dm_region_hash dm_log dm_mod uvcvideo videodev i2c_core cpufreq_ondemand
cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table mperf
nvram snd_hda_codec_hdmi usbhid hid uas usb_storage
snd_hda_codec_realtek snd_hda_intel arc4 snd_hda_codec snd_hwdep ecb
snd_seq_dummy rtl8192ce snd_seq_oss snd_seq_midi_event snd_seq
snd_seq_device pciehp pci_hotplug snd_pcm_oss snd_pcm rtlwifi snd_timer
snd_mixer_oss snd iTCO_wdt soundcore ehci_hcd iTCO_vendor_support
mac80211 sparse_keymap sg sr_mod r8169 battery mii cfg80211 rfkill
serio_raw wmi snd_page_alloc evdev ac processor thermal button video
usbcore ata_piix ahci libahci libata sd_mod scsi_mod crc_t10dif ext4
jbd2 crc16 [last unloaded: scsi_wait_scan]
Pid: 6209, comm: kworker/u:11 Tainted: G        W
2.6.38.3-server-1mnb2 #1
Call Trace:
 [<c0151a72>] ? warn_slowpath_common+0x72/0xa0
 [<f847dc1f>] ? ieee80211_work_work+0x2bf/0x10e0 [mac80211]
 [<f847dc1f>] ? ieee80211_work_work+0x2bf/0x10e0 [mac80211]
 [<c0151b43>] ? warn_slowpath_fmt+0x33/0x40
 [<f847dc1f>] ? ieee80211_work_work+0x2bf/0x10e0 [mac80211]
 [<f847f735>] ? ieee80211_iface_work+0x305/0x310 [mac80211]
 [<f847f735>] ? ieee80211_iface_work+0x305/0x310 [mac80211]
 [<c016a300>] ? process_one_work+0x100/0x3a0
 [<c014bd94>] ? wake_up_process+0x14/0x20
 [<c01681f5>] ? start_worker+0x25/0x30
 [<f847d960>] ? ieee80211_work_work+0x0/0x10e0 [mac80211]
 [<c016b0ba>] ? worker_thread+0x12a/0x2e0
 [<c016af90>] ? worker_thread+0x0/0x2e0
 [<c016e9ed>] ? kthread+0x6d/0x80
 [<c016e980>] ? kthread+0x0/0x80
 [<c010b43e>] ? kernel_thread_helper+0x6/0x10
---[ end trace bbe4a610450faaf1 ]---

With the stupid hack I posted first It does not occurs.

Thanks
Alexandre

Em Seg, 2011-04-25 às 23:47 +0200, Rafael J. Wysocki escreveu:
> into the right direction, but the
> pm_restrict_gfp_mask() is needed for the "pure" suspend-to-RAM case.
> 
> Please check if the appended patch works for you. 

Re: [PATCH] Power Manager suspend-hybrid warn on systemlog

[Rafael J. Wysocki]

On Tuesday, April 26, 2011, Alexandre Felipe Muller de Souza wrote:
> Rafael, thank you a lot for your reply.
> 
> Unfortunately something strange occurred when I applied any one of this
> 2 patches you sent.
> 
> The network interface flooded the demsg with many times of that:
> WARNING: at net/mac80211/iface.c:718 ieee80211_iface_work+0x305/0x310
> [mac80211]()
> Hardware name: P MOBILE
> interface work scheduled while going to suspend
> Modules linked in: option usb_wwan usbserial sit tunnel4 fuse ipt_IFWLOG
> ipt_psd cls_flow cls_fw cls_u32 sch_htb sch_hfsc sch_ingress sch_sfq
> xt_time xt_connlimit xt_realm iptable_raw xt_comment xt_recent xt_policy
> ipt_ULOG ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_ECN
> ipt_ecn ipt_CLUSTERIP ipt_ah ipt_addrtype nf_nat_tftp nf_nat_snmp_basic
> nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323
> nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane
> nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp
> nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink
> nf_conntrack_netbios_ns nf_conntrack_irc nf_conntrack_h323
> nf_conntrack_ftp ipt_set ipt_SET ip_set_nethash ip_set_iptreemap
> ip_set_iptree ip_set_ipporthash ip_set_portmap ip_set_macipmap
> ip_set_ipmap ip_set_iphash ip_set xt_TPROXY nf_tproxy_core ip6_tables
> nf_defrag_ipv6 xt_tcpmss xt_pkttype xt_physdev xt_owner xt_NFQUEUE
> xt_NFLOG nfnetlink_log xt_multiport xt_mark af_packet xt_mac xt_limit
> xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp
> xt_conntrack xt_connmark xt_CLASSIFY ipt_LOG xt_tcpudp xt_state
> iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack
> iptable_mangle nfnetlink iptable_filter ip_tables x_tables ipv6 i915
> drm_kms_helper drm i2c_algo_bit binfmt_misc loop dm_mirror
> dm_region_hash dm_log dm_mod uvcvideo videodev i2c_core cpufreq_ondemand
> cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table mperf
> nvram snd_hda_codec_hdmi usbhid hid uas usb_storage
> snd_hda_codec_realtek snd_hda_intel arc4 snd_hda_codec snd_hwdep ecb
> snd_seq_dummy rtl8192ce snd_seq_oss snd_seq_midi_event snd_seq
> snd_seq_device pciehp pci_hotplug snd_pcm_oss snd_pcm rtlwifi snd_timer
> snd_mixer_oss snd iTCO_wdt soundcore ehci_hcd iTCO_vendor_support
> mac80211 sparse_keymap sg sr_mod r8169 battery mii cfg80211 rfkill
> serio_raw wmi snd_page_alloc evdev ac processor thermal button video
> usbcore ata_piix ahci libahci libata sd_mod scsi_mod crc_t10dif ext4
> jbd2 crc16 [last unloaded: scsi_wait_scan]
> Pid: 6209, comm: kworker/u:11 Tainted: G        W
> 2.6.38.3-server-1mnb2 #1
> Call Trace:
>  [<c0151a72>] ? warn_slowpath_common+0x72/0xa0
>  [<f847f735>] ? ieee80211_iface_work+0x305/0x310 [mac80211]
>  [<f847f735>] ? ieee80211_iface_work+0x305/0x310 [mac80211]
>  [<c0151b43>] ? warn_slowpath_fmt+0x33/0x40
>  [<f847f735>] ? ieee80211_iface_work+0x305/0x310 [mac80211]
>  [<c0168cf2>] ? cwq_dec_nr_in_flight+0x52/0x90
>  [<c016a300>] ? process_one_work+0x100/0x3a0
>  [<c014bd94>] ? wake_up_process+0x14/0x20
>  [<c01681f5>] ? start_worker+0x25/0x30
>  [<f847f430>] ? ieee80211_iface_work+0x0/0x310 [mac80211]
>  [<c016b0ba>] ? worker_thread+0x12a/0x2e0
>  [<c016af90>] ? worker_thread+0x0/0x2e0
>  [<c016e9ed>] ? kthread+0x6d/0x80
>  [<c016e980>] ? kthread+0x0/0x80
>  [<c010b43e>] ? kernel_thread_helper+0x6/0x10
> ---[ end trace bbe4a610450faaf0 ]---
> WARNING: at net/mac80211/work.c:904 ieee80211_work_work+0x2bf/0x10e0
> [mac80211]()
> Hardware name: P MOBILE
> work scheduled while going to suspend
> Modules linked in: option usb_wwan usbserial sit tunnel4 fuse ipt_IFWLOG
> ipt_psd cls_flow cls_fw cls_u32 sch_htb sch_hfsc sch_ingress sch_sfq
> xt_time xt_connlimit xt_realm iptable_raw xt_comment xt_recent xt_policy
> ipt_ULOG ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_ECN
> ipt_ecn ipt_CLUSTERIP ipt_ah ipt_addrtype nf_nat_tftp nf_nat_snmp_basic
> nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323
> nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane
> nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp
> nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink
> nf_conntrack_netbios_ns nf_conntrack_irc nf_conntrack_h323
> nf_conntrack_ftp ipt_set ipt_SET ip_set_nethash ip_set_iptreemap
> ip_set_iptree ip_set_ipporthash ip_set_portmap ip_set_macipmap
> ip_set_ipmap ip_set_iphash ip_set xt_TPROXY nf_tproxy_core ip6_tables
> nf_defrag_ipv6 xt_tcpmss xt_pkttype xt_physdev xt_owner xt_NFQUEUE
> xt_NFLOG nfnetlink_log xt_multiport xt_mark af_packet xt_mac xt_limit
> xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp
> xt_conntrack xt_connmark xt_CLASSIFY ipt_LOG xt_tcpudp xt_state
> iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack
> iptable_mangle nfnetlink iptable_filter ip_tables x_tables ipv6 i915
> drm_kms_helper drm i2c_algo_bit binfmt_misc loop dm_mirror
> dm_region_hash dm_log dm_mod uvcvideo videodev i2c_core cpufreq_ondemand
> cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table mperf
> nvram snd_hda_codec_hdmi usbhid hid uas usb_storage
> snd_hda_codec_realtek snd_hda_intel arc4 snd_hda_codec snd_hwdep ecb
> snd_seq_dummy rtl8192ce snd_seq_oss snd_seq_midi_event snd_seq
> snd_seq_device pciehp pci_hotplug snd_pcm_oss snd_pcm rtlwifi snd_timer
> snd_mixer_oss snd iTCO_wdt soundcore ehci_hcd iTCO_vendor_support
> mac80211 sparse_keymap sg sr_mod r8169 battery mii cfg80211 rfkill
> serio_raw wmi snd_page_alloc evdev ac processor thermal button video
> usbcore ata_piix ahci libahci libata sd_mod scsi_mod crc_t10dif ext4
> jbd2 crc16 [last unloaded: scsi_wait_scan]
> Pid: 6209, comm: kworker/u:11 Tainted: G        W
> 2.6.38.3-server-1mnb2 #1
> Call Trace:
>  [<c0151a72>] ? warn_slowpath_common+0x72/0xa0
>  [<f847dc1f>] ? ieee80211_work_work+0x2bf/0x10e0 [mac80211]
>  [<f847dc1f>] ? ieee80211_work_work+0x2bf/0x10e0 [mac80211]
>  [<c0151b43>] ? warn_slowpath_fmt+0x33/0x40
>  [<f847dc1f>] ? ieee80211_work_work+0x2bf/0x10e0 [mac80211]
>  [<f847f735>] ? ieee80211_iface_work+0x305/0x310 [mac80211]
>  [<f847f735>] ? ieee80211_iface_work+0x305/0x310 [mac80211]
>  [<c016a300>] ? process_one_work+0x100/0x3a0
>  [<c014bd94>] ? wake_up_process+0x14/0x20
>  [<c01681f5>] ? start_worker+0x25/0x30
>  [<f847d960>] ? ieee80211_work_work+0x0/0x10e0 [mac80211]
>  [<c016b0ba>] ? worker_thread+0x12a/0x2e0
>  [<c016af90>] ? worker_thread+0x0/0x2e0
>  [<c016e9ed>] ? kthread+0x6d/0x80
>  [<c016e980>] ? kthread+0x0/0x80
>  [<c010b43e>] ? kernel_thread_helper+0x6/0x10
> ---[ end trace bbe4a610450faaf1 ]---
> 
> With the stupid hack I posted first It does not occurs.

At which point exactly has this happened?

Rafael