Saw the following show up in my dmesg: resource sanity check: requesting [mem 0xfed40040-0xfed4103f], which spans more than MSFT0101:00 [mem 0xfed40000-0xfed4087f] ------------[ cut here ]------------ WARNING: CPU: 1 PID: 201 at arch/x86/mm/ioremap.c:198 __ioremap_caller+0x234/0x390() Info: mapping multiple BARs. Your kernel is fine. Modules linked in: tpm_crb(+) processor_thermal_device int3400_thermal snd_hwdep intel_soc_dts_iosf snd_pcm video snd_timer snd rfkill dell_smo8800 pinctrl_sunrisepoint shpchp pinctrl_intel soundcore battery ac acpi_thermal_rel iosf_mbi i2c_i801 i2c_algo_bit acpi_pad button tpm_tis tpm acpi_als kfifo_buf industrialio processor int3402_thermal int340x_thermal_zone fjes sch_fq_codel ip_tables x_tables ext4 crc16 mbcache jbd2 hid_multitouch hid_sensor_hub usbhid hid sd_mod atkbd libps2 ahci libahci libata xhci_pci xhci_hcd scsi_mod usbcore usb_common i8042 serio CPU: 1 PID: 201 Comm: systemd-udevd Tainted: G W 4.4.0-4-ARCH #1 Hardware name: Dell Inc. Inspiron 13-7359/0JTM4R, BIOS 01.00.00 08/07/2015 0000000000000000 00000000bef8f678 ffff88007e1bf9a0 ffffffff812c8a99 ffff88007e1bf9e8 ffff88007e1bf9d8 ffffffff810771c2 00000000fed40040 ffffc90000690040 0000000000001000 0000000000000040 ffff88007ddb2ac0 Call Trace: [<ffffffff812c8a99>] dump_stack+0x4b/0x72 [<ffffffff810771c2>] warn_slowpath_common+0x82/0xc0 [<ffffffff8107725c>] warn_slowpath_fmt+0x5c/0x80 [<ffffffff8107d837>] ? iomem_map_sanity_check+0x97/0xd0 [<ffffffff81064a84>] __ioremap_caller+0x234/0x390 [<ffffffff81064bf7>] ioremap_nocache+0x17/0x20 [<ffffffff812e15e2>] devm_ioremap_nocache+0x42/0x80 [<ffffffffa02c1238>] crb_acpi_add+0x108/0x2d0 [tpm_crb] [<ffffffff8134c214>] acpi_device_probe+0x4f/0xf5 [<ffffffff813ec1b2>] driver_probe_device+0x222/0x4a0 [<ffffffff813ec4b4>] __driver_attach+0x84/0x90 [<ffffffff813ec430>] ? driver_probe_device+0x4a0/0x4a0 [<ffffffff813e9dec>] bus_for_each_dev+0x6c/0xc0 [<ffffffff813eb96e>] driver_attach+0x1e/0x20 [<ffffffff813eb4bb>] bus_add_driver+0x1eb/0x280 [<ffffffffa0006000>] ? 0xffffffffa0006000 [<ffffffff813ecdc0>] driver_register+0x60/0xe0 [<ffffffff8134c0e3>] acpi_bus_register_driver+0x3b/0x43 [<ffffffffa0006010>] crb_acpi_driver_init+0x10/0x1000 [tpm_crb] [<ffffffff81002123>] do_one_initcall+0xb3/0x200 [<ffffffff81162537>] do_init_module+0x5f/0x1e8 [<ffffffff810fcb8f>] load_module+0x219f/0x27e0 [<ffffffff810f9a80>] ? symbol_put_addr+0x50/0x50 [<ffffffff810fd31e>] SyS_init_module+0x14e/0x190 [<ffffffff815925ae>] entry_SYSCALL_64_fastpath+0x12/0x71 ---[ end trace a386ec65af3d81c3 ]--- uname: Linux ... 4.4.0-4-ARCH #1 SMP PREEMPT Wed Jan 20 07:42:27 CET 2016 x86_64 GNU/Linux Possibly related to https://bugzilla.kernel.org/show_bug.cgi?id=98181 . I will email Jarkko my ACPI dump.
Thanks for the dumps and reporting this!
Root cause identified with 90% certainty. This should not be a critical bug or risk the driver stability. I'll test my assumption before stating anything further.
In machines that I've tested 4.4 driver this does not occur although buffers that the driver maps do interleave. The reason for this is that in Linux 4.4 tpm_crb does not use devm_ioremap_resource() and therefore it does not add anything to iomem_resource tree.
As we discussed in the ML control area falsely maps 0x1000 and surpasses a resource boundary.
Jethro, is it too much trouble to you to test a fix I push it to my master branch? I don't have hardware where the mappings go like they go on your hardware.
$ lsmod|grep tpm tpm_crb 16384 0 tpm_tis 20480 0 tpm 36864 2 tpm_crb,tpm_tis If I can test the fix with building just a module for my current kernel I'm happy to test it in the near future. If I need to build a full kernel it might be a while before I can get to it.
(In reply to Jethro Beekman from comment #6) > $ lsmod|grep tpm > tpm_crb 16384 0 > tpm_tis 20480 0 > tpm 36864 2 tpm_crb,tpm_tis > > If I can test the fix with building just a module for my current kernel I'm > happy to test it in the near future. If I need to build a full kernel it > might be a while before I can get to it. Thank you, appreciate this! I have this project that is still WiP: http://git.infradead.org/users/jjs/buildroot-tpmdd.git The idea is to take my subsystem tree and bundle simple user space to initramfs and produce an image that you can write an USB stick. For this bug module compilation should be sufficient but in future this BR environment should provide much more convenient environment for peer testing so that one does not have hose her host environment...
Chiming in here, would be happy to test any fix as it becomes available. I already have a setup for testing 4.5-rcX tree, so any patch on top of that would be easy for me to test. Although the buildroot-based option sounds nice and cozy as well :)
This went from "working but potentially broken" in 4.4 to "doesn't work at all" in 4.7: tpm_crb MSFT0101:00: can't request region for resource [mem 0xfed40040-0xfed4103f] tpm_crb: probe of MSFT0101:00 failed with error -16 Building the 4.4 driver on 4.7 continues to work without issue (but does emit the original error message). Let me know if you need more information.
It's actually a different regression even though the output looks the same :) Anyway, it looks like that the commit 422eac3f7dea did not make into 4.7. I really hope I had authority to close these bugs so that they don't get reused for different bugs. Anyway, thank you for your bug report. I'll try to get this fixed.
I sent some days ago commit IDs to stable@vger.kernel.org for the fixes. Hopefully come to next 4.7 update.
http://www.spinics.net/lists/stable/msg142584.html
http://www.spinics.net/lists/stable/msg146718.html