[arch-general] tpm and suspend issues [resolved]

Divan Santana Divan at s-tainment.co.za
Wed Jan 12 21:32:07 EST 2011


Hi All,

Firstly, I am a newbie :) Loving Arch Linux. Huge thank you and brilliant job 
on a great distro.

I was trying to set up suspend and noticed issues with tpm module. My problem 
is fixed but just wanted to share the info and seek advise if I should report 
this upstream (linux kernel) or what you guys think?

I try suspend and it fails and returns to normal, problem is shown below:
---
Jan 12 13:33:56 htf3333000l kernel: EXT4-fs (dm-3): re-mounted. Opts: commit=0
Jan 12 13:33:56 htf3333000l kernel: EXT4-fs (dm-2): re-mounted. Opts: commit=0
Jan 12 13:33:57 htf3333000l kernel: PM: Syncing filesystems ... done.
Jan 12 13:33:57 htf3333000l kernel: PM: Preparing system for mem sleep
Jan 12 13:33:59 htf3333000l kernel: Freezing user space processes ... (elapsed 
0.01 seconds) done.
Jan 12 13:33:59 htf3333000l kernel: Freezing remaining freezable tasks ... 
(elapsed 0.01 seconds) done.
Jan 12 13:33:59 htf3333000l kernel: PM: Entering mem sleep
Jan 12 13:33:59 htf3333000l kernel: Suspending console(s) (use 
no_console_suspend to debug)
Jan 12 13:33:59 htf3333000l kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache
Jan 12 13:33:59 htf3333000l kernel: sd 0:0:0:0: [sda] Stopping disk
Jan 12 13:33:59 htf3333000l kernel: tpm_tis 00:0a: tpm_transmit: tpm_send: 
error -5
Jan 12 13:33:59 htf3333000l kernel: legacy_suspend(): pnp_bus_suspend+0x0/0xa0 
returns -5
Jan 12 13:33:59 htf3333000l kernel: PM: Device 00:0a failed to suspend: error 
-5
Jan 12 13:33:59 htf3333000l kernel: PM: Some devices failed to suspend
Jan 12 13:33:59 htf3333000l kernel: sd 0:0:0:0: [sda] Starting disk
Jan 12 13:33:59 htf3333000l kernel: PM: resume of devices complete after 
708.504 msecs
Jan 12 13:33:59 htf3333000l kernel: PM: Finishing wakeup.
Jan 12 13:33:59 htf3333000l kernel: Restarting tasks ... done.
Jan 12 13:33:59 htf3333000l kernel: video LNXVIDEO:00: Restoring backlight 
state
Jan 12 13:33:59 htf3333000l kernel: EXT4-fs (dm-3): re-mounted. Opts: commit=0
Jan 12 13:33:59 htf3333000l kernel: EXT4-fs (dm-2): re-mounted. Opts: commit=0
---

I do the following:
sudo modprobe -r tpm tpm_bios tpm_tis
Which results in  the below, doesn't look good.
---
Jan 12 13:35:15 htf3333000l kernel: BUG: scheduling while atomic: 
modprobe/5333/0x00000002
Jan 12 13:35:15 htf3333000l kernel: Modules linked in: tpm_tis(-) tpm tpm_bios 
usbhid hid act_police 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_REDIRECT ipt_NETMAP 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 xt_TPROXY nf_tproxy_core xt_tcpmss 
ip6table_filter ip6_tables xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG 
nfnetlink_log xt_multiport xt_mark 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 ipt_MASQUERADE nfnetlink iptable_nat nf_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM 
iptable_mangle xt_tcpudp ipv6 iptable_filter ip_tables x_tables rfcomm sco bnep 
l2cap ext2 arc4 ecb snd_seq_dummy snd_seq_oss tun snd_seq_midi_event snd_seq 
snd_hda_codec_conexant bridge iwlagn snd_seq_device snd_hda_intel stp 
snd_hda_codec snd_pcm_oss llc iwlcore snd_mixer_oss kvm_intel joydev pcmcia 
kvm snd_hwdep snd_pcm mac80211 sdhci_pci snd_timer yenta_socket thinkpad_acpi 
cpufreq_ondemand btusb snd sdhci zaurus pcmcia_rsrc cfg80211 cdc_ether 
acpi_cpufreq usbnet mmc_core soundcore bluetooth e1000e i2c_i801 iTCO_wdt 
freq_table cdc_wdm cdc_acm wmi psmouse nvram pcspkr snd_page_alloc mii thermal 
pcmcia_core processor battery rfkill led_class ac sg serio_raw evdev 
iTCO_vendor_support mperf ext4 mbcache jbd2 crc16 cryptd aes_x86_64 
aes_generic xts gf128mul dm_crypt dm_mod sd_mod sr_mod cdrom ahci libahci 
uhci_hcd libata ehci_hcd scsi_mod usbcore i915 drm_kms_helper drm i2c_algo_bit 
button i2c_core video output intel_agp [last unloaded: tpm_bios]
Jan 12 13:35:15 htf3333000l kernel: Pid: 5333, comm: modprobe Not tainted 
2.6.36-ARCH #1
Jan 12 13:35:15 htf3333000l kernel: Call Trace:
Jan 12 13:35:15 htf3333000l kernel: [<ffffffff81045f61>] __schedule_bug+0x61/0x70
Jan 12 13:35:15 htf3333000l kernel: [<ffffffff81393cbb>] schedule+0x89b/0x9c0
Jan 12 13:35:15 htf3333000l kernel: [<ffffffff8139433d>] 
schedule_timeout+0x21d/0x360
Jan 12 13:35:15 htf3333000l kernel: [<ffffffff8139433d>] ? 
schedule_timeout+0x21d/0x360
Jan 12 13:35:15 htf3333000l kernel: [<ffffffff813932d0>] 
wait_for_common+0xc0/0x160
Jan 12 13:35:15 htf3333000l kernel: [<ffffffff8104e730>] ? 
default_wake_function+0x0/0x10
Jan 12 13:35:15 htf3333000l kernel: [<ffffffff81393418>] 
wait_for_completion+0x18/0x20
Jan 12 13:35:15 htf3333000l kernel: [<ffffffff810b96e0>] 
synchronize_sched+0x50/0x60
Jan 12 13:35:15 htf3333000l kernel: [<ffffffff81072d90>] ? 
wakeme_after_rcu+0x0/0x10
Jan 12 13:35:15 htf3333000l kernel: [<ffffffffa02678da>] 
tpm_remove_hardware+0x5a/0xb0 [tpm]
Jan 12 13:35:15 htf3333000l kernel: [<ffffffffa016d05d>] cleanup_tis+0x4b/0x14f 
[tpm_tis]
Jan 12 13:35:15 htf3333000l kernel: [<ffffffff8108f684>] 
sys_delete_module+0x194/0x290
Jan 12 13:35:15 htf3333000l kernel: [<ffffffff8100af42>] 
system_call_fastpath+0x16/0x1b
---

sudo lsmod|grep tpm
results in nothing.

I can then suspend successfully.

I wonder if this related to the marked as fixed bug in 2010-08 last year:
http://kerneltrap.org/mailarchive/linux-kernel/2010/7/8/4591885/thread
https://bugzilla.kernel.org/show_bug.cgi?id=16256

$ uname -a
Linux fakename 2.6.36-ARCH #1 SMP PREEMPT Sat Jan 8 14:15:27 CET 2011 x86_64 
Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz GenuineIntel GNU/Linux

I disabled this in rc.conf by adding this to MODULES !tpm !tpm_bios 
!tpm_tis however now I just disabled the security chip in the BIOS (lenovo 
W500).

It seems this tpm is for some chip that provides hardware crypt security 
features which I don't use.

I'm not sure if I should report this upstream or not, thought maybe you guys 
might have a better suggestion?

Any thoughts
--       
Divan Santana


More information about the arch-general mailing list