<div dir="ltr">Hello Paul,<div><br></div><div>Few observations:</div><div><br></div><div>[1] Lenovo X60t is 10.5 years old laptop, and I am really surprised that Kernels series 4.x still support it. I'll call it: miracle!</div><div><a href="http://www.tabletpcreview.com/tabletreview/lenovo-thinkpad-x60-tablet-pc-review/">http://www.tabletpcreview.com/tabletreview/lenovo-thinkpad-x60-tablet-pc-review/</a><br></div><div><br></div><div>[2] It is obvious (at least to me) what is happening to your Lenovo X60t: your DRAM is exhausted, thus no possible to add anymore Physical Table Entries, since no physical memory available in your system (this is the result of unknown root cause, which I'll try to discover from incomplete log you had posted):</div><div><span style="font-size:12.8px">12.951: [  350.898287] BUG: unable to handle kernel paging request at f8281008</span><br style="font-size:12.8px"><span style="font-size:12.8px">12.951: [  350.898346] IP: gen2_write32+0x62/0x130 [i915]</span><br style="font-size:12.8px"><span style="font-size:12.8px">12.951: [  350.898347] *pde = 34c88067</span><br style="font-size:12.8px"><span style="font-size:12.8px"><i><b><u><font color="#ff0000">12.951: [  350.898349] *pte = 00000000</font></u></b></i></span><br></div><div><span style="color:rgb(0,0,0);font-size:12.8px"><br></span></div><div><font color="#000000"><span style="font-size:12.8px">[3] Here is probable closer clue to root cause for [2]:</span></font></div><div><span style="font-size:12.8px">12.951: [  350.898429] CPU: 1 PID: 1113 Comm:<b><i><u> kworker/u4:<font color="#ff0000">32</font></u></i></b> Tainted: G            E   4.11.0-rc7 #23</span><br style="font-size:12.8px"><span style="font-size:12.8px">12.951: [  350.898431] Hardware name: LENOVO 636338U/636338U, BIOS CBET4000 4.5-1596-gccdb801 04/19/2017</span><br style="font-size:12.8px"><span style="font-size:12.8px">12.951: [  350.898436] Workqueue: events_unbound async_run_entry_fn</span><font color="#000000"><span style="font-size:12.8px"><br></span></font></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">32 is killing number, my best guess is that you have 32 k-processes calling 32 system calls at once (maybe the same syscall)!?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">[4] I will suggest to run as root ps -elf (capture traces of it), top, htop, and to read the following open net thread:</span></div><div><span style="font-size:12.8px"><a href="https://askubuntu.com/questions/33640/kworker-what-is-it-and-why-is-it-hogging-so-much-cpu">https://askubuntu.com/questions/33640/kworker-what-is-it-and-why-is-it-hogging-so-much-cpu</a></span><br></div><div><span style="font-size:12.8px">(especiall</span><span style="font-size:12.8px">y: </span><i><u><strong style="margin:0px;padding:0px;border:0px;font-size:15px;color:rgb(17,17,17);font-family:ubuntu,arial,"libra sans",sans-serif">Why does kworker hog your CPU?</strong><span style="color:rgb(17,17,17);font-family:ubuntu,arial,"libra sans",sans-serif;font-size:15px"> To find out why a kworker is wasting your CPU, you can create CPU backtraces: watch your processor load (with </span><code style="font-size:13px;margin:0px;padding:1px 5px;border:0px;font-family:consolas,menlo,monaco,"lucida console","liberation mono","dejavu sans mono","bitstream vera sans mono","courier new",monospace,sans-serif;background-color:rgb(239,240,241);white-space:pre-wrap;color:rgb(17,17,17)">top</code><span style="color:rgb(17,17,17);font-family:ubuntu,arial,"libra sans",sans-serif;font-size:15px"> or something) and in moments of high load through </span><code style="font-size:13px;margin:0px;padding:1px 5px;border:0px;font-family:consolas,menlo,monaco,"lucida console","liberation mono","dejavu sans mono","bitstream vera sans mono","courier new",monospace,sans-serif;background-color:rgb(239,240,241);white-space:pre-wrap;color:rgb(17,17,17)">kworker</code><span style="color:rgb(17,17,17);font-family:ubuntu,arial,"libra sans",sans-serif;font-size:15px">, execute </span><code style="font-size:13px;margin:0px;padding:1px 5px;border:0px;font-family:consolas,menlo,monaco,"lucida console","liberation mono","dejavu sans mono","bitstream vera sans mono","courier new",monospace,sans-serif;background-color:rgb(239,240,241);white-space:pre-wrap;color:rgb(17,17,17)">echo l > /proc/sysrq-trigger</code><span style="color:rgb(17,17,17);font-family:ubuntu,arial,"libra sans",sans-serif;font-size:15px"> to create a backtrace. (On Ubuntu, this needs you to login with </span><code style="font-size:13px;margin:0px;padding:1px 5px;border:0px;font-family:consolas,menlo,monaco,"lucida console","liberation mono","dejavu sans mono","bitstream vera sans mono","courier new",monospace,sans-serif;background-color:rgb(239,240,241);white-space:pre-wrap;color:rgb(17,17,17)">sudo -s</code></u></i><span style="color:rgb(17,17,17);font-family:ubuntu,arial,"libra sans",sans-serif;font-size:15px">).</span></div><div><br></div><div><span style="font-size:12.8px">Good Luck!</span></div><div><span style="font-size:12.8px">Zoran</span></div><div>_______</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 20, 2017 at 9:35 PM, Paul Menzel via coreboot <span dir="ltr"><<a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear coreboot folks,<br>
<br>
<br>
With Linux 4.11-rcX sometimes the Lenovo X60t doesn’t correctly resume<br>
anymore. I still have to do some more tests, but I believe I am unable<br>
to reproduce this issue with Linux 4.10.8. But as I also do not know<br>
how to reproduce it, despite doing suspend and resuming, and see how it<br>
goes, I cannot know for sure. With Linux 4.11-rcX, I’d say the issue<br>
happens one out of ten or 15 times.<br>
<br>
```<br>
12.951: [  350.898287] BUG: unable to handle kernel paging request at f8281008<br>
12.951: [  350.898346] IP: gen2_write32+0x62/0x130 [i915]<br>
12.951: [  350.898347] *pde = 34c88067<br>
12.951: [  350.898349] *pte = 00000000<br>
12.951: [  350.898349]<br>
12.951: [  350.898352] Oops: 0002 [#1] SMP<br>
12.951: [  350.898353] Modules linked in: joydev(E) wacom_w8001(E) serport(E) cpufreq_powersave(E) cpufreq_conservative(E) cpufreq_userspace(E) iTCO_wdt(E) iTCO_vendor_support(E) acpi_cpufreq(E) coretemp(E) arc4<br>
(E) kvm_intel(E) lpc_ich(E) kvm(E) mfd_core(E) irqbypass(E) iwl3945(E) iwlegacy(E) i915(E) evdev(E) snd_hda_codec_analog(E) snd_hda_codec_generic(E) snd_pcsp(E) pcmcia(E) serio_raw(E) mac80211(E) rng_core(E) snd<br>
_hda_intel(E) yenta_socket(E) pcmcia_rsrc(E) drm_kms_helper(E) pcmcia_core(E) snd_hda_codec(E) snd_hda_core(E) snd_hwdep(E) thinkpad_acpi(E) snd_pcm(E) drm(E) cfg80211(E) battery(E) nvram(E) i2c_algo_bit(E) snd_<br>
timer(E) fb_sys_fops(E) syscopyarea(E) sysfillrect(E) snd(E) rfkill(E) sysimgblt(E) soundcore(E) video(E) ac(E) button(E) shpchp(E) tpm_tis(E) tpm_tis_core(E) tpm(E) fuse(E) parport_pc(E)<br>
12.951: [  350.898397]  ppdev(E) lp(E) parport(E) autofs4(E) ext4(E) crc16(E) jbd2(E) fscrypto(E) mbcache(E) ecb(E) cbc(E) algif_skcipher(E) af_alg(E) dm_crypt(E) dm_mod(E) sg(E) sr_mod(E) sd_mod(E) cdrom(E) ata<br>
_generic(E) sdhci_pci(E) psmouse(E) sdhci(E) uhci_hcd(E) e1000e(E) ata_piix(E) ahci(E) ehci_pci(E) firewire_ohci(E) libahci(E) i2c_i801(E) libata(E) ehci_hcd(E) ptp(E) mmc_core(E) firewire_core(E) crc_itu_t(E) s<br>
csi_mod(E) usbcore(E) pps_core(E) thermal(E)<br>
12.951: [  350.898429] CPU: 1 PID: 1113 Comm: kworker/u4:32 Tainted: G            E   4.11.0-rc7 #23<br>
12.951: [  350.898431] Hardware name: LENOVO 636338U/636338U, BIOS CBET4000 4.5-1596-gccdb801 04/19/2017<br>
12.951: [  350.898436] Workqueue: events_unbound async_run_entry_fn<br>
12.951: [  350.898438] task: f2588480 task.stack: f258c000<br>
12.951: [  350.898483] EIP: gen2_write32+0x62/0x130 [i915]<br>
12.951: [  350.898484] EFLAGS: 00210282 CPU: 1<br>
12.951: [  350.898486] EAX: f8281008 EBX: f8d80eb0 ECX: 00000001 EDX: f8180000<br>
12.951: [  350.898487] ESI: f658403c EDI: 00000001 EBP: f258de44 ESP: f258de14<br>
12.951: [  350.898488]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068<br>
12.951: [  350.898490] CR0: 80050033 CR2: f8281008 CR3: 17589000 CR4: 000006d0<br>
12.951: [  350.898492] Call Trace:<br>
12.951: [  350.898537]  ? i915_gem_restore_gtt_mappings+<wbr>0x1ca/0x290 [i915]<br>
12.951: [  350.898581]  ? gen9_decoupled_read64+0x270/<wbr>0x270 [i915]<br>
12.951: [  350.898622]  ? gen6_ggtt_invalidate+0x25/0x30 [i915]<br>
12.951: [  350.898665]  ? i915_gem_resume+0x2d/0x80 [i915]<br>
12.951: [  350.898701]  ? i915_drm_resume+0x38/0x180 [i915]<br>
12.952: [  350.898705]  ? pci_pm_resume+0x4b/0xc0<br>
12.952: [  350.898709]  ? dpm_run_callback+0x53/0x150<br>
12.952: [  350.898713]  ? wait_for_completion+0x2a/0x140<br>
12.952: [  350.898716]  ? pci_pm_thaw+0x90/0x90<br>
12.952: [  350.898718]  ? device_resume+0x87/0x170<br>
12.952: [  350.898720]  ? async_resume+0x1e/0x50<br>
12.952: [  350.898722]  ? async_run_entry_fn+0x35/0x190<br>
12.952: [  350.898726]  ? process_one_work+0x15f/0x3a0<br>
12.952: [  350.898729]  ? worker_thread+0x39/0x470<br>
12.952: [  350.898732]  ? kthread+0xdb/0x110<br>
12.952: [  350.898734]  ? process_one_work+0x3a0/0x3a0<br>
12.952: [  350.898736]  ? kthread_create_on_node+0x30/<wbr>0x30<br>
12.952: [  350.898739]  ? ret_from_fork+0x1c/0x28<br>
12.952: [  350.898741] Code: d4 a6 e1 f8 bb 02 00 00 00 89 4c 24 08 89 5c 24 04 c7 04 24 49 d1 e0 f8 e8 bc 92 c8 ff 8b 97 d4 03 00 00 8b 45 e8 8b 7d e4 01 d0 <89> 38 83 c4 24 5b 5e 5f 5d c3 8d 74 26 00 64 8b 15 00 31 57 d7<br>
12.952: [  350.898813] EIP: gen2_write32+0x62/0x130 [i915] SS:ESP: 0068:f258de14<br>
12.952: [  350.898814] CR2: 00000000f8281008<br>
12.952: [  350.898817] ---[ end trace 478b15034b0b3e6a ]---<br>
```<br>
<br>
Ticket #100739 in the Freedesktop.org Bugzilla [1] tracks this issue.<br>
<br>
Chris Wilson replied already.<br>
<br>
> The stacktrace is mostly garbage. A register mmio goes wrong. One of<br>
> the suggestions is that the ioremap of the PCI bar is invalid upon<br>
> resume.<br>
<br>
coreboot has the TPM patches applied, and is built with native graphics<br>
initialization.<br>
<br>
Has anybody else experienced any issues on the Lenovo X60t?<br>
<br>
In #<a href="mailto:coreboot@irc.freenode.net">coreboot@irc.freenode.net</a> it was mentioned that there might be low<br>
memory corruptions on the Intel 945 devices.<br>
<br>
I’d welcome help also from “normal users” to reproduce this issue.<br>
<br>
<br>
Kind regards,<br>
<br>
Paul<br>
<br>
<br>
[1] <a href="https://bugs.freedesktop.org/show_bug.cgi?id=100739" rel="noreferrer" target="_blank">https://bugs.freedesktop.org/<wbr>show_bug.cgi?id=100739</a><br>--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
<a href="https://mail.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://mail.coreboot.org/<wbr>mailman/listinfo/coreboot</a><br></blockquote></div><br></div>