linux-kernel - Regression between 2.6.35 and 2.6.38 (freeze at resume)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <201109170935.17777.Eric.Brunet@lps.ens.fr>
Date:	Sat, 17 Sep 2011 09:35:17 +0200
From:	Éric Brunet <Eric.Brunet@....ens.fr>
To:	linux-kernel@...r.kernel.org
Subject: Regression between 2.6.35 and 2.6.38 (freeze at resume)

Hello,

Since I upgraded my Dell E4200 laptop to Fedora 15, I have had some problem 
with suspend/resume: occasionaly, the computer would freeze on resume. 
(I suspend by pressing fn-F1. My power manager is the kde plasmoid. I am not 
completely sure which program(s) get(s) launched with what options when I 
press fn-F1...)

Most of the times when it happens, it freezes before leaving anything 
interesting in the logs, and, on some rare occasion, there is a series of 
WARNING: and a BUG: in the log. 

The computer was working fine with Fedora 14, and is working fine while 
running Fedora 15 with the latest Fedora 14 kernel (2.6.35.6), so the problem 
is kernel related. I have seen it with all the Fedora 15 kernels that I have 
installed from the first one (2.6.38.6) to the latest one (2.6.40.4). I have 
also seen it with a vanilla 3.0.4 kernel that I compiled, so it is not a 
problem specific to fedora.

The bug does not occur every time. The frequency of occurence depends on the 
kernel version (nearly always on 2.6.38 and 3.04, every 5 or 10 times on 
2.6.38).

The full relevant logs are on 
https://bugzilla.redhat.com/show_bug.cgi?id=735404

but in short, the first warning is

WARNING: at lib/list_debug.c:47 __list_del_entry+0x8d/0x98()
Hardware name: Latitude E4200                  
list_del corruption, ffff88008b410bb0->next is LIST_POISON1 (dead000000100100)
Modules linked in: ppdev parport_pc lp parport cpufreq_ondemand acpi_cpufreq 
freq_table mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter 
ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack arc4 
dell_wmi sparse_keymap snd_hda_codec_hdmi snd_hda_codec_idt dell_laptop 
microcode dcdbas snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device 
iwlagn uvcvideo i2c_i801 snd_pcm videodev iTCO_wdt joydev iTCO_vendor_support 
media v4l2_compat_ioctl32 mac80211 e1000e cfg80211 snd_timer snd rfkill 
soundcore snd_page_alloc ipv6 firewire_ohci sdhci_pci sdhci mmc_core 
firewire_core crc_itu_t wmi i915 drm_kms_helper drm i2c_algo_bit i2c_core 
video [last unloaded: scsi_wait_scan]
Pid: 8798, comm: pm-suspend Not tainted 2.6.40.3-0.fc15.x86_64 #1
Call Trace:
 [<ffffffff81054c8e>] warn_slowpath_common+0x83/0x9b
 [<ffffffff81054d49>] warn_slowpath_fmt+0x46/0x48
 [<ffffffff812457bd>] __list_del_entry+0x8d/0x98
 [<ffffffff812457d6>] list_del+0xe/0x2d
 [<ffffffff813b0b3d>] led_trigger_unregister+0x29/0x9c
 [<ffffffff813b0bc9>] led_trigger_unregister_simple+0x19/0x26
 [<ffffffff8138c69e>] power_supply_remove_triggers+0x21/0x8f
 [<ffffffff8138bafe>] power_supply_unregister+0x1f/0x2c
 [<ffffffff812af9b2>] sysfs_remove_battery+0x2f/0x3e
 [<ffffffff812b0461>] battery_notify+0x21/0x2f
 [<ffffffff8148ad8b>] notifier_call_chain+0x37/0x63
 [<ffffffff810747a3>] __blocking_notifier_call_chain+0x4b/0x60
 [<ffffffff810747cc>] blocking_notifier_call_chain+0x14/0x16
 [<ffffffff81089023>] pm_notifier_call_chain+0x1a/0x33
 [<ffffffff810898f1>] enter_state+0x10a/0x137
 [<ffffffff81088f42>] state_store+0xaf/0xc5
 [<ffffffff81237bd3>] kobj_attr_store+0x17/0x19
 [<ffffffff8117fe80>] sysfs_write_file+0x111/0x14d
 [<ffffffff811271ad>] vfs_write+0xac/0xf3
 [<ffffffff8112739c>] sys_write+0x4a/0x6e
 [<ffffffff8148e182>] system_call_fastpath+0x16/0x1b

and then all hell breaks loose. 

The warning seems related to battery, and I just want to mention a point which 
is or is not relevant: when I wake up from the working kernel (2.6.35), the 
kde battery plasmoid shows the correct power level instantaneously. When I 
wake up from the non working kernel (2.6.40), the battery plasmoid first 
displays an empty battery for about one second before displaying the correct 
power level.

Does that ring a bell to someone ? What could I do to help debug this ?

Thanks

	Eric Brunet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/