Created attachment 1073725 [details]
File: dmesg

I have the same problem with Fedora 23 kernel and it happens at least twice a day, making the system very unstable.


Sep 23 21:16:24 onega.vda.li kernel: ------------[ cut here ]------------
Sep 23 21:16:24 onega.vda.li kernel: WARNING: CPU: 1 PID: 1 at arch/x86/mm/ioremap.c:198 __ioremap_caller+0x2c5/0x380()
Sep 23 21:16:24 onega.vda.li kernel: Info: mapping multiple BARs. Your kernel is fine.
Sep 23 21:16:24 onega.vda.li kernel: Modules linked in:
Sep 23 21:16:24 onega.vda.li kernel: 
Sep 23 21:16:24 onega.vda.li kernel: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.2.0-300.fc23.x86_64 #1
Sep 23 21:16:24 onega.vda.li kernel: Hardware name: LENOVO 20ARS19C05/20ARS19C05, BIOS GJET75WW (2.25 ) 03/28/2014
Sep 23 21:16:24 onega.vda.li kernel:  0000000000000000 00000000d380476a ffff88030fdb7a78 ffffffff817712aa
Sep 23 21:16:24 onega.vda.li kernel:  0000000000000000 ffff88030fdb7ad0 ffff88030fdb7ab8 ffffffff8109e466
Sep 23 21:16:24 onega.vda.li kernel:  ffff88030fdb7ae8 00000000fed10000 ffffc900018c8000 0000000000006000
Sep 23 21:16:24 onega.vda.li kernel: Call Trace:
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff817712aa>] dump_stack+0x45/0x57
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff8109e466>] warn_slowpath_common+0x86/0xc0
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff8109e4f5>] warn_slowpath_fmt+0x55/0x70
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff81065ba5>] __ioremap_caller+0x2c5/0x380
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff81065c77>] ioremap_nocache+0x17/0x20
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff81039bf9>] snb_uncore_imc_init_box+0x79/0xb0
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff810383a4>] uncore_pci_probe+0xd4/0x1a0
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff813e5be5>] local_pci_probe+0x45/0xa0
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff8129a49d>] ? sysfs_do_create_link_sd.isra.2+0x6d/0xb0
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff813e6ddd>] pci_device_probe+0xed/0x140
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff814d00c4>] driver_probe_device+0x1f4/0x450
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff814d03b0>] __driver_attach+0x90/0xa0
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff814d0320>] ? driver_probe_device+0x450/0x450
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff814cdb8c>] bus_for_each_dev+0x6c/0xc0
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff814cf8ce>] driver_attach+0x1e/0x20
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff814cf41b>] bus_add_driver+0x1eb/0x280
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff81d65149>] ? uncore_cpu_setup+0x12/0x12
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff814d0c20>] driver_register+0x60/0xe0
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff813e54cc>] __pci_register_driver+0x4c/0x50
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff81d6521b>] intel_uncore_init+0xd2/0x2be
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff81d65149>] ? uncore_cpu_setup+0x12/0x12
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff81002123>] do_one_initcall+0xb3/0x200
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff810bbe91>] ? parse_args+0x271/0x4a0
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff81777600>] ? ldsem_down_write+0xd0/0x199
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff81d571dc>] kernel_init_freeable+0x18e/0x228
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff81767a00>] ? rest_init+0x80/0x80
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff81767a0e>] kernel_init+0xe/0xe0
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff8177809f>] ret_from_fork+0x3f/0x70
Sep 23 21:16:24 onega.vda.li kernel:  [<ffffffff81767a00>] ? rest_init+0x80/0x80
Sep 23 21:16:24 onega.vda.li kernel: ---[ end trace e7f6d9c2fabac8fd ]---

Looks like bug #517949, in a blast from the past.

abrt brought me here:  F23, this seems to happen on every new boot, when the machine is on a docking station with an external display attached.

Thinkpad X250, Ultradock, and:

$ xrandr -q
Screen 0: minimum 8 x 8, current 3840 x 1200, maximum 32767 x 32767
eDP1 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 276mm x 156mm
   1920x1080     60.04*+
   1400x1050     59.98  
   1600x900      60.00  
   1280x1024     60.02  
   1280x960      60.00  
   1368x768      60.00  
   1280x720      60.00  
   1024x768      60.00  
   1024x576      60.00  
   960x540       60.00  
   800x600       60.32    56.25  
   864x486       60.00  
   640x480       59.94  
   720x405       60.00  
   640x360       60.00  
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
DP2-1 disconnected (normal left inverted right x axis y axis)
DP2-2 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
   1920x1200     59.95*+
   1920x1080     60.00  
   1600x1200     60.00  
   1680x1050     59.88  
   1280x1024     60.02  
   1280x960      60.00  
   1024x768      60.00  
   800x600       60.32  
   640x480       60.00  
   720x400       70.08  
DP2-3 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

This is especially bad because it pretty much stops people from reporting bugs via ABRT (which whines about the tainted kernel).  This is despite the line that very clearly says "Your kernel is fine."... which seems somewhat confusing, considering that it then counts as "tainted".

Case in point: I've run into a number of freezes that are new with F23... but I can't report them automatically, courtesy of this bug.

(In reply to Rob Tomsick from comment #5)
> This is especially bad because it pretty much stops people from reporting
> bugs via ABRT (which whines about the tainted kernel).  This is despite the
> line that very clearly says "Your kernel is fine."... which seems somewhat
> confusing, considering that it then counts as "tainted".
> 
> Case in point: I've run into a number of freezes that are new with F23...
> but I can't report them automatically, courtesy of this bug.
If you are not using ethernet and only rely on wifi, try to disable 'e1000e' driver with 
-----------------
# cat /etc/modprobe.d/blacklist.conf 
blacklist e1000e
-----------------

I stopped getting lockups once I did so. The reason is discussed in the  https://lkml.org/lkml/2015/10/12/51 thread.

(In reply to Rob Tomsick from comment #5)
> This is especially bad because it pretty much stops people from reporting
> bugs via ABRT (which whines about the tainted kernel).  This is despite the
> line that very clearly says "Your kernel is fine."... which seems somewhat
> confusing, considering that it then counts as "tainted".
> 
> Case in point: I've run into a number of freezes that are new with F23...
> but I can't report them automatically, courtesy of this bug.

The extent of the taint happens.  IIRC, this module triggers flags GW.

It's not stock kernel.org, but it is stock Fedora.

I agree that ABRT should report this to Fedora, but not kernel.org.  There needs to be a better way to handle this.

"The extent of the taint matters."

Just like using the right word matters, and choosing the wrong word happens...

Still occuring on Linux version 4.4.0-0.rc5.git1.2.fc24.x86_64. 

Still taints the kernel

0.816824] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G        W       4.4.0-0.rc5.git1.2.fc24.x86_64 #1

Similar issue here;

Experiencing complete system freezes in a Asus Zenbook UX303UA with bios 202

Dec 21 08:13:31 localhost kernel: ------------[ cut here ]------------
Dec 21 08:13:31 localhost kernel: WARNING: CPU: 0 PID: 1339 at arch/x86/mm/ioremap.c:198 __ioremap_caller+0x2c5/0x380()
Dec 21 08:13:31 localhost kernel: Info: mapping multiple BARs. Your kernel is fine.
Dec 21 08:13:31 localhost kernel: Modules linked in:
Dec 21 08:13:31 localhost kernel: tpm_crb(+) nfsd auth_rpcgss ecryptfs nfs_acl lockd encrypted_keys grace sunrpc trusted tpm binfmt_misc dm_crypt i915 crct10dif_pclmul crc32
_pclmul crc32c_intel i2c_algo_bit drm_kms_helper drm serio_raw video i2c_hid
Dec 21 08:13:31 localhost kernel: CPU: 0 PID: 1339 Comm: systemd-udevd Not tainted 4.2.7-300.fc23.x86_64 #1
Dec 21 08:13:31 localhost kernel: Hardware name: ASUSTeK COMPUTER INC. UX303UA/UX303UA, BIOS UX303UA.202 08/27/2015
Dec 21 08:13:31 localhost kernel: 0000000000000000 00000000fc4c72e6 ffff8802684bb938 ffffffff81772baa
Dec 21 08:13:31 localhost kernel: 0000000000000000 ffff8802684bb990 ffff8802684bb978 ffffffff8109e4b6
Dec 21 08:13:31 localhost kernel: ffff8802684bb9a8 00000000fed40040 ffffc90000cb4040 0000000000001000
Dec 21 08:13:31 localhost kernel: Call Trace:
Dec 21 08:13:31 localhost kernel: [<ffffffff81772baa>] dump_stack+0x45/0x57
Dec 21 08:13:31 localhost kernel: [<ffffffff8109e4b6>] warn_slowpath_common+0x86/0xc0
Dec 21 08:13:31 localhost kernel: [<ffffffff8109e545>] warn_slowpath_fmt+0x55/0x70
Dec 21 08:13:31 localhost kernel: [<ffffffff81065b95>] __ioremap_caller+0x2c5/0x380
Dec 21 08:13:31 localhost kernel: [<ffffffff81065c67>] ioremap_nocache+0x17/0x20
Dec 21 08:13:31 localhost kernel: [<ffffffff813b5754>] devm_ioremap_nocache+0x44/0x80
Dec 21 08:13:31 localhost kernel: [<ffffffffa0240235>] crb_acpi_add+0x105/0x2c0 [tpm_crb]
Dec 21 08:13:31 localhost kernel: [<ffffffff81424560>] acpi_device_probe+0x50/0xf7
Dec 21 08:13:31 localhost kernel: [<ffffffff814d0974>] driver_probe_device+0x1f4/0x450
Dec 21 08:13:31 localhost kernel: [<ffffffff814d0c60>] __driver_attach+0x90/0xa0
Dec 21 08:13:31 localhost kernel: [<ffffffff814d0bd0>] ? driver_probe_device+0x450/0x450
Dec 21 08:13:31 localhost kernel: [<ffffffff814ce43c>] bus_for_each_dev+0x6c/0xc0
Dec 21 08:13:31 localhost kernel: [<ffffffff814d017e>] driver_attach+0x1e/0x20
Dec 21 08:13:31 localhost kernel: [<ffffffff814cfccb>] bus_add_driver+0x1eb/0x280
Dec 21 08:13:31 localhost kernel: [<ffffffffa0006000>] ? 0xffffffffa0006000
Dec 21 08:13:31 localhost kernel: [<ffffffff814d14d0>] driver_register+0x60/0xe0
Dec 21 08:13:31 localhost kernel: [<ffffffff81424d7a>] acpi_bus_register_driver+0x3b/0x43
Dec 21 08:13:31 localhost kernel: [<ffffffffa0006010>] crb_acpi_driver_init+0x10/0x1000 [tpm_crb]
Dec 21 08:13:31 localhost kernel: [<ffffffff81002123>] do_one_initcall+0xb3/0x200
Dec 21 08:13:31 localhost kernel: [<ffffffff811ffd4e>] ? kmem_cache_alloc_trace+0x19e/0x220
Dec 21 08:13:31 localhost kernel: [<ffffffff81771ddc>] ? do_init_module+0x28/0x1e7
Dec 21 08:13:31 localhost kernel: [<ffffffff81771e14>] do_init_module+0x60/0x1e7
Dec 21 08:13:31 localhost kernel: [<ffffffff8112312f>] load_module+0x20ef/0x2730
Dec 21 08:13:31 localhost kernel: [<ffffffff8111f4d0>] ? __symbol_put+0x60/0x60
Dec 21 08:13:31 localhost kernel: [<ffffffff811238c4>] SyS_init_module+0x154/0x1a0
Dec 21 08:13:31 localhost kernel: [<ffffffff81023925>] ? syscall_trace_leave+0xb5/0x110
Dec 21 08:13:31 localhost kernel: [<ffffffff817795ae>] entry_SYSCALL_64_fastpath+0x12/0x71
Dec 21 08:13:31 localhost kernel: ---[ end trace a98f42daa1051189 ]---

Very similar to https://bugzilla.kernel.org/show_bug.cgi?id=98181

I guess this Fedora 23 ticket can be closed as wontfix. I do not get this error with the recent kernels (F37)