話說最近換了新的 Thinkpad X200，剛拿到換裝了 Debian Sid 後，發現一個問題，重度使用的休眠功能在第二次喚醒時，系統只亮了一下硬碟燈號，然後就停止了。必須重新「冷」開機後，系統才會恢復正常。

之前查找了 ThinkWiki 還沒有人說明這類休眠的問題，而且硬體在第一次重新開機時，是絲毫沒有問題的。心中一直懷疑是某個軟體/硬體元件出了問題，怎麼會休眠一次就失敗 ?

於是便開始從 GNOME PowerManager 一路查到 hal 跟 pm-utils (README.debugging, /var/log/pm-suspend.log)。然後配合 Documentation/kernel-parameters.txt 與 Documentation/power/basic-pm-debugging.txt 文件中說明的方法，重複開關機，試用不同的 acpi 參數，絲毫看不出端倪。重開機前後，acpidump 與 dmidecode 的資料大同小異。

再瞎子摸象的鑽進 kernel acpi driver 翻找，也將 DSDT 轉成 ACPI Source Language (ASL) 來檢查，kernel 也上了 ACPI DSDT in initrd patch。差點就要開始讀 Shaohua Li 在 Linux 內核開發中文社群上寫的一篇 ACPI 除錯的技巧中的延伸參考訊息。

結果才在 bugzilla 上發現有人回報了類似的問題 Bug 11963 – S3: second resume fails unless BIOS “Intel TXT Feature” disabled。我的症狀跟回報人一模一樣，只要將 Intel TXT (Trusted Execution Technology) 關閉，系統就可以隨意的休眠、喚醒。

我手上的這台 Thinkpad X200, 使用的是 Intel Centrion 2 vPro，依照 Intel 的新聞稿，vPro (白皮書) 包含了 Trusted Execution Technology, 改良型系統防禦過濾器, 信任機制代理程式, 主動式管理技術 等等。從展示中，你可以看到 vPro 提供了強大的管理能力，資訊管理人員可以遠端的開機、收集資訊，使用 remote console 修復作業系統問題，甚至可以抓小偷 (Anti-Theft Technology)。

而造成我的問題的是 TXT，TXT 的功能是用於保護虛擬機器中的資訊，藉由 TPM 與 SME 指令集的運用，可以避免虛擬機器開機時的記憶體或儲存資料被竊取。

Intel 為了此功能開發了一個開放原碼的 tboot (Trusted Boot) 專案，可搭配 Xen 使用，Intel 的 Joseph Cihula 在 Xen Summit November 2007 時分享了一份關於 Trusted Boot 的簡報 (Trusted Boot:  Verifying the Xen Launch) 。

不過對我這種個人使用者來講，真是可怕到了極點，根本是一台內建後門的筆記型電腦。既然這些功能會影響我休眠，不如一股腦全把他們關了。或許我該寫封信問問 Joseph 看看他是不是知道為什麽 TXT 會防止我重新開機。

話說這台新電腦真是多災多難，最早拿到的時候，試玩新硬體，前後嘗試 Windows Vista 會頻繁出現藍屏當機，心想這大約是正常的Vista 該死問題。結果裝了 MacOS 也會 Kernel Panic，這才開始覺的真有問題。前後用微軟的記憶體測試程式跟 Memtest86+ 測試，才證明廠商贈送的 2G 記憶體有問題，多浪費了許多時間。