Bug 175391 - Linux kernel from 4.6.0 onwards doesn't initialise AMD "TURKS" graphics card properly. (also Ubuntu lauchpad bug #LP1627496)
Summary: Linux kernel from 4.6.0 onwards doesn't initialise AMD "TURKS" graphics card ...
Alias: None
Product: Drivers
Classification: Unclassified
Component: PCI (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: drivers_pci@kernel-bugs.osdl.org
Depends on:
Reported: 2016-10-02 10:38 UTC by Valentin QUEQUET
Modified: 2016-12-27 17:25 UTC (History)
6 users (show)

See Also:
Kernel Version: 4.6.0 and above, not lower
Tree: Mainline
Regression: Yes

Logs and more details (43.51 KB, application/gzip)
2016-10-02 10:38 UTC, Valentin QUEQUET
test patch #1 (1.52 KB, patch)
2016-10-26 21:35 UTC, Bjorn Helgaas
Details | Diff
Better Logs Attachment (43.58 KB, application/x-bzip)
2016-10-29 11:46 UTC, Valentin QUEQUET

Description Valentin QUEQUET 2016-10-02 10:38:43 UTC
Created attachment 240591 [details]
Logs and more details


I run both Ubuntu and Debian on amd64/x86-64 (PC) platform.

Linux kernel from 4.6.0 onwards doesn't initialise AMD "TURKS" graphics card properly while Linux 4.5.x was just fine. My graphics hardware is AMD TURKS (0x1002:0x6840 0x1179:0xFB41 0x00).

I already reported this bug on Ubuntu launchpad under bug ID #LP1627496 .
( https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1627496 )

With 4.6.0 I lost GPU-accelerated graphics and native screen resolution under Xorg ; I have lower resolution than my screen native one. (I get 1152x864 instead of 1600x900)

One might think this be an Xorg problem, but I don't think so and I'll tell you why :

  1) On my system, the sole kernel upgrade triggers this bug.
  2) Not only Xorg is affected, framebuffer/ubuntu-Plymouth boot splash also is : it doesn't show up on both system startup and shutdown.
  3) System logs (especially dmesg output) look rather scary.

I'd like to raise to your attention that I use multiple kernel sources, *including* pristine source code (Linus's branch), but I unfortunately failed to do a bissection (between 4.5.0 and 4.6.0). I will make another attempt soon.

Here follow additional details (dmesg output excerpts) :

[ 5.291603] [drm] Initialized drm 1.1.0 20060810
[ 5.353156] [drm] radeon kernel modesetting enabled.
[ 5.353216] call_modprobe: symbol:kgd2kfd_init 2
[ 5.359409] CRAT table not found
[ 5.359410] Finished initializing topology ret=0
[ 5.359425] kfd kfd: Initialized module
[ 5.359614] checking generic (b0000000 3cc000) vs hw (b0000000 10000000)
[ 5.359615] fb: switching to radeondrmfb from simple
[ 5.359644] Console: switching to colour dummy device 80x25
[ 5.359926] [drm] initializing kernel modesetting (TURKS 0x1002:0x6840 0x1179:0xFB41 0x00).
[ 5.359936] [drm] register mmio base: 0xC2000000
[ 5.359937] [drm] register mmio size: 131072
[ 5.359957] ------------[ cut here ]------------
[ 5.359961] WARNING: CPU: 0 PID: 116 at /build/linux-akdJXO/linux-4.8.0/arch/x86/mm/ioremap.c:121 __ioremap_caller+0x1ec/0x370
[ 5.359962] ioremap on RAM at 0x0000000000000000 - 0x000000000001ffff
[ 5.359963] Modules linked in: amdkfd radeon(+) r8169 mii i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ahci(+) libahci drm wmi ehci_pci xhci_pci fjes ehci_hcd video thermal xhci_hcd usbcore usb_common button
[ 5.359978] CPU: 0 PID: 116 Comm: systemd-udevd Not tainted 4.8.0-16-generic #17-Ubuntu
[ 5.359978] Hardware name: TOSHIBA SATELLITE L875-10G/Type2 - Board Product Name1, BIOS 6.50 3/25/2013
[ 5.359980] 0000000000000286 000000001712e9ce ffffffffbe973f14 ffff8b3f3cebf8c0
[ 5.359982] 0000000000000000 ffffffffbe67f93e 0000000000000000 ffff8b3f3cebf918
[ 5.359985] ffffffffbe9cf198 0000000000020000 0000000000000002 0000000000000000
[ 5.359987] Call Trace:
[ 5.359992] [<ffffffffbe973f14>] ? dump_stack+0x5c/0x78
[ 5.359995] [<ffffffffbe67f93e>] ? __warn+0xbe/0xe0
[ 5.359997] [<ffffffffbe9cf198>] ? pci_map_rom+0x58/0xd0
[ 5.359999] [<ffffffffbe67f9bf>] ? warn_slowpath_fmt+0x5f/0x80
[ 5.360040] [<ffffffffc0536877>] ? igp_read_bios_from_vram+0x57/0xa0 [radeon]
[ 5.360042] [<ffffffffbe66905c>] ? __ioremap_caller+0x1ec/0x370
[ 5.360044] [<ffffffffbe9cf198>] ? pci_map_rom+0x58/0xd0
[ 5.360075] [<ffffffffc05368f5>] ? radeon_read_bios.isra.2+0x35/0xc0 [radeon]
[ 5.360102] [<ffffffffc0536c0c>] ? radeon_get_bios+0x28c/0xfc0 [radeon]
[ 5.360105] [<ffffffffbe6d74ca>] ? vprintk_emit+0x35a/0x520
[ 5.360108] [<ffffffffbe7f1f0d>] ? kmem_cache_alloc_trace+0x18d/0x1d0
[ 5.360145] [<ffffffffc057410f>] ? evergreen_init+0xf/0x390 [radeon]
[ 5.360173] [<ffffffffc0502e2e>] ? radeon_device_init+0x87e/0xcb0 [radeon]
[ 5.360198] [<ffffffffc05056a5>] ? radeon_driver_load_kms+0x95/0x210 [radeon]
[ 5.360217] [<ffffffffc041326c>] ? drm_dev_register+0x9c/0xc0 [drm]
[ 5.360230] [<ffffffffc0415238>] ? drm_get_pci_dev+0x88/0x1d0 [drm]
[ 5.360232] [<ffffffffbe9cb72f>] ? local_pci_probe+0x3f/0x90
[ 5.360234] [<ffffffffbe9ccb09>] ? pci_device_probe+0x109/0x160
[ 5.360237] [<ffffffffbeac956a>] ? driver_probe_device+0x21a/0x420
[ 5.360240] [<ffffffffbeac984a>] ? __driver_attach+0xda/0xe0
[ 5.360242] [<ffffffffbeac9770>] ? driver_probe_device+0x420/0x420
[ 5.360244] [<ffffffffbeac7087>] ? bus_for_each_dev+0x67/0xb0
[ 5.360246] [<ffffffffbeac873a>] ? bus_add_driver+0x16a/0x260
[ 5.360248] [<ffffffffc066f000>] ? 0xffffffffc066f000
[ 5.360249] [<ffffffffbeaca1a7>] ? driver_register+0x57/0xc0
[ 5.360251] [<ffffffffc066f000>] ? 0xffffffffc066f000
[ 5.360253] [<ffffffffbe60218b>] ? do_one_initcall+0x4b/0x190
[ 5.360255] [<ffffffffbe7f1ed0>] ? kmem_cache_alloc_trace+0x150/0x1d0
[ 5.360258] [<ffffffffbe7887bc>] ? do_init_module+0x5b/0x1ed
[ 5.360261] [<ffffffffbe70ba58>] ? load_module+0x1938/0x1ca0
[ 5.360262] [<ffffffffbe707c00>] ? m_show+0x1b0/0x1b0
[ 5.360265] [<ffffffffbe70c006>] ? SYSC_finit_module+0xc6/0xf0
[ 5.360268] [<ffffffffbecfbfb6>] ? entry_SYSCALL_64_fastpath+0x1e/0xa8
[ 5.360270] ---[ end trace a3dcc2b343f5d80b ]---
[ 5.360304] [drm:radeon_get_bios [radeon]] *ERROR* Unable to locate a BIOS ROM
[ 5.360309] radeon 0000:01:00.0: Fatal error during GPU init
[ 5.360312] [drm] radeon: finishing device.
[ 5.360313] [TTM] Memory type 2 has not been initialized
[ 5.361148] scsi host0: ahci
[ 5.367568] radeon: probe of 0000:01:00.0 failed with error -22

I haven't got a peanut about what is happening since Linux 4.6.0 ; any idea ?

In hope this helps.

Valentin QUEQUET
Comment 1 Valentin QUEQUET 2016-10-12 09:59:08 UTC

I just finished bisecting again, this time taking care of kernel configuration throughout the full process.

I found the first bad commit : 30b5b8808c12bcd947dd474980482561b69c1bcb
( PCI: Restore inclusion of pci/hotplug Kconfig )

Now, at least, we know in which direction or subsystem to focus our attention.

I fear, though, this Kconfig include has been discarded for too long, allowing bugs to creep in silently ; now we (I) will have to do another bisect with this Kconfig stuff included throughout the whole process :-(

Here follows my git bisect log :

Note : I started bisect on a broader range of versions ( v4.5.0 ... v4.6-rc1 ), but due to corruptions, I had to resume the process halfway on a narrowed range ( 2e11590 ... 968f3e3 )

git bisect start
# bad: [2e11590171683c6b12193fe4b0ede1e6201b7f45] staging: fsl-mc: fix incorrect type passed to dev_err macros
git bisect bad 2e11590171683c6b12193fe4b0ede1e6201b7f45
# good: [968f3e374faf41e5e6049399eb7302777a09a1e8] Merge branch 'for-linus-4.6' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs
git bisect good 968f3e374faf41e5e6049399eb7302777a09a1e8
# bad: [5266e5b12c8b73587130325f7074d2f49ef9e427] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending
git bisect bad 5266e5b12c8b73587130325f7074d2f49ef9e427
# good: [b4af7f773ef79c479cc25ee26063821220150a8a] Merge tag 'iommu-updates-v4.6' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu
git bisect good b4af7f773ef79c479cc25ee26063821220150a8a
# good: [5adabdd122e471fe978d49471624bab08b5373a7] iser-target: Split and properly type the login buffer
git bisect good 5adabdd122e471fe978d49471624bab08b5373a7
# good: [4347ab5a086efcba449e7a6f0a14d1474060006b] target: Avoid DataIN transfers for non-GOOD SAM status
git bisect good 4347ab5a086efcba449e7a6f0a14d1474060006b
# good: [c64c1437afb14ebc900e40910f31ffb20bf652ad] ALSA: hda - Fix missing ELD update at unplugging
git bisect good c64c1437afb14ebc900e40910f31ffb20bf652ad
# bad: [9188269a2e8ea5b32affef99d42c5eda91c07fdf] Revert "PCI: dra7xx: Mark driver as broken"
git bisect bad 9188269a2e8ea5b32affef99d42c5eda91c07fdf
# bad: [30b5b8808c12bcd947dd474980482561b69c1bcb] PCI: Restore inclusion of pci/hotplug Kconfig
git bisect bad 30b5b8808c12bcd947dd474980482561b69c1bcb
# first bad commit: [30b5b8808c12bcd947dd474980482561b69c1bcb] PCI: Restore inclusion of pci/hotplug Kconfig

author	Tero Roponen <tero.roponen@gmail.com>	2016-03-21 07:26:41 (GMT)
committer	Bjorn Helgaas <bhelgaas@google.com>	2016-03-21 12:33:34 (GMT)
commit	30b5b8808c12bcd947dd474980482561b69c1bcb (patch)
tree	a4b2da457230e77144df046e0ea2b23891874792
parent	643ad15d47410d37d43daf3ef1c8ac52c281efa5 (diff)
PCI: Restore inclusion of pci/hotplug Kconfig
Commit e7e127e3c767 ("PCI: Include pci/hotplug Kconfig directly from
pci/Kconfig") added one line to pci/Kconfig.  However, for some mysterious
reason it isn't there now, even though there are no traces of removing it
in the git log.

I detected this issue when 'make oldconfig' removed all the options that
depended on HOTPLUG_PCI.

[bhelgaas: I botched the cfeb8139a1fb ("Merge branch 'pci/host-hv' into
next") merge.  "git diff cfeb8139a1fb^ cfeb8139a1fb" shows a conflict in
drivers/pci/Kconfig, and I mistakenly dropped the hotplug/Kconfig piece.]
Signed-off-by: Tero Roponen <tero.roponen@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-rw-r--r--	drivers/pci/Kconfig	1	
1 files changed, 1 insertions, 0 deletions
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index a1f37db..209292e 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -128,4 +128,5 @@ config PCI_HYPERV
           The PCI device frontend driver allows the kernel to import arbitrary
           PCI devices from a PCI backend to support PCI driver domains.
+source "drivers/pci/hotplug/Kconfig"
 source "drivers/pci/host/Kconfig"
generated by cgit v0.12 at 2016-10-12 09:26:36 (GMT)

In hope this helps.

Valentin QUEQUET
Comment 2 Valentin QUEQUET 2016-10-15 21:37:53 UTC
Hello, fellow Linux enthusiasts,

I've just finished another bisection upon revisions range e7e127e3c767094aca96ee976729dc5f756666df..30b5b8808c12bcd947dd474980482561b69c1bcb (inclusive) .

But, throughout this series of compiles, I didn't exactly compiled pristine code ; instead, I let git spit genuine code from Linus' repo, but for each single revision (commit), I reinstated the << source "drivers/pci/hotplug/Kconfig" >> stanza ( a 1-liner ) just above the << source "drivers/pci/host/Kconfig" >> stanza.

Thus I was able to test the kernel in real situation as though the << source "drivers/pci/hotplug/Kconfig" >> stanza had not been swept away by commit cfeb8139a1fbbbae3f1e986133f4e9e7833eeac4 ( "Merge branch 'pci/host-hv' into next" ).

In the end, I found that the real first bad commit for the bug we are talking about is :

[0c0e0736acad4e76e718456c75d78ad95eea0011] PCI: Set ROM shadow location in arch code, not in PCI core

Below follows my bisect log.

Any comment or suggestion much appreciated.

In hope this helps.

Valentin QUEQUET

My git bisect log :

( I will bisect from e7e127e3c7 to 30b5b8808c )

git bisect start
git bisect good  e7e127e3c767094aca96ee976729dc5f756666df
git bisect bad   30b5b8808c12bcd947dd474980482561b69c1bcb
Bisecting: 5880 revisions left to test after this (roughly 13 steps)
[3d15cfdb1b77536c205d8e49c0312219ddf162ec] Merge tag 'linux-kselftest-4.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
git bisect bad
Bisecting: 2899 revisions left to test after this (roughly 12 steps)
[710d60cbf1b312a8075a2158cbfbbd9c66132dcc] Merge branch 'smp-hotplug-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good
Bisecting: 1535 revisions left to test after this (roughly 11 steps)
[8759957b77ac1b5b5bdfac5ba049789107e85190] Merge tag 'libnvdimm-for-4.6' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
git bisect bad
Bisecting: 723 revisions left to test after this (roughly 10 steps)
[aa6865d836418eb2ba888a4cb1318a28e9aa2e0c] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k
git bisect good
Bisecting: 405 revisions left to test after this (roughly 9 steps)
[277edbabf6fece057b14fb6db5e3a34e00f42f42] Merge tag 'pm+acpi-4.6-rc1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect good
Bisecting: 202 revisions left to test after this (roughly 8 steps)
[dc183965282d28c82f192e39cbfa91da85505a6f] ncr5380: Forget aborted commands
git bisect good
Bisecting: 101 revisions left to test after this (roughly 7 steps)
[6e6f498b039aa5558c7377fbbe65f7421d34cea4] Merge branch 'pci/resource' into next
git bisect bad
Bisecting: a merge base must be tested
#### I don't see what this means

[92e963f50fc74041b5e9e744c330dca48e04f08d] Linux 4.5-rc1
git bisect good
Bisecting: 50 revisions left to test after this (roughly 6 steps)
[18e5e6913b1ae5c6f60390945d4c8446f5c40c89] Merge branches 'pci/aer', 'pci/enumeration', 'pci/kconfig', 'pci/misc', 'pci/virtualization' and 'pci/vpd' into next
#### This revision already have the << source "drivers/pci/hotplug/Kconfig" >> stanza !?!

git bisect good
Bisecting: 26 revisions left to test after this (roughly 5 steps)
[c334f9c89e40d2c9f4598e87e186bf3264d39e51] Merge branches 'pci/host-altera', 'pci/host-imx6', 'pci/host-keystone', 'pci/host-rcar', 'pci/host-tegra', 'pci/host-thunder', 'pci/host-vmd', 'pci/host-xilinx' and 'pci/host-xilinx-nwl' into next
#### This revision already have the << source "drivers/pci/hotplug/Kconfig" >> stanza !?!

git bisect good
Bisecting: 13 revisions left to test after this (roughly 4 steps)
[97f47e73c4a0dc2519276cd63274696c850e0613] MIPS: Loongson 3: Keep CPU physical (not virtual) addresses in shadow ROM resource
git bisect bad
Bisecting: 6 revisions left to test after this (roughly 3 steps)
[0c0e0736acad4e76e718456c75d78ad95eea0011] PCI: Set ROM shadow location in arch code, not in PCI core
git bisect bad
Bisecting: 2 revisions left to test after this (roughly 2 steps)
[63e22924f5dc08badf9870c4a52ef4e7f7cbf218] PCI: Mark shadow copy of VGA ROM as IORESOURCE_PCI_FIXED
git bisect good
Bisecting: 0 revisions left to test after this (roughly 1 step)
[4708f9a55b31062dd19b12788ecf614aa4e79bea] PCI: Don't enable/disable ROM BAR if we're using a RAM shadow copy
git bisect good
0c0e0736acad4e76e718456c75d78ad95eea0011 is the first bad commit
commit 0c0e0736acad4e76e718456c75d78ad95eea0011
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Tue Mar 1 11:38:46 2016 -0600

    PCI: Set ROM shadow location in arch code, not in PCI core
    IORESOURCE_ROM_SHADOW means there is a copy of a device's option ROM in
    RAM.  The existence of such a copy and its location are arch-specific.
    Previously the IORESOURCE_ROM_SHADOW flag was set in arch code, but the
    0xC0000-0xDFFFF location was hard-coded into the PCI core.
    If we're using a shadow copy in RAM, disable the ROM BAR and release the
    address space it was consuming.  Move the location information from the PCI
    core to the arch code that sets IORESOURCE_ROM_SHADOW.  Save the location
    of the RAM copy in the struct resource for PCI_ROM_RESOURCE.
    After this change, pci_map_rom() will call pci_assign_resource() and
    pci_enable_rom() for these IORESOURCE_ROM_SHADOW resources, which we did
    not do before.  This is safe because:
      - pci_assign_resource() will do nothing because the resource is marked
        IORESOURCE_PCI_FIXED, which means we can't move it, and
      - pci_enable_rom() will not turn on the ROM BAR's enable bit because the
        resource is marked IORESOURCE_ROM_SHADOW, which means it is in RAM
        rather than in PCI memory space.
    Storing the location in the struct resource means "lspci" will show the
    shadow location, not the value from the ROM BAR.
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

:040000 040000 4601affef3391dabaddfce6d524d472500dc3326 45c3e25596eee6dcf4c7750ecbb5b3609e38b2e2 M      arch
:040000 040000 bd66ba94908cff5d7075d9c1ed0710b92c0675ad e1140ff5839156dbe9a2a7812c9815538f7aead7 M      drivers
:040000 040000 fe8d48c0be131bfff93a9b72561e57c4b30849c3 95c8f356c7c7f51fe035be4680016fc87f5b2218 M      include
Comment 3 Knud 2016-10-23 21:25:30 UTC
same problem here

Comment 4 Bjorn Helgaas 2016-10-26 21:35:04 UTC
Created attachment 242851 [details]
test patch #1

Please test this patch.  I generated this against v4.9-rc1, but it should apply (possibly with minor offsets) to v4.6 or later.

I suspect you'll still see a warning like this:

  WARNING: CPU: 0 PID: 116 at /build/linux-akdJXO/linux-4.8.0/arch/x86/mm/ioremap.c:121 __ioremap_caller+0x1ec/0x370
  ioremap on RAM at 0x00000000000c0000 - 0x00000000000dffff

but it looks like you should see that warning even before 0c0e0736acad, because in the IORESOURCE_ROM_SHADOW case, pci_map_rom() called ioremap() with the [mem 0xc0000-0xdffff] range.

See pci_map_rom() prior to 0c0e0736acad here: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/rom.c?id=4708f9a55b31#n125

If you do see the warning, we should fix it, too, but separately.  If you can confirm whether the warning occurs with older kernels (e.g., v4.4 or v4.5), that would be great.
Comment 5 Knud 2016-10-27 19:54:18 UTC
As soon I have made setup for kernel build I will make the test
Comment 6 Valentin QUEQUET 2016-10-29 11:44:18 UTC
Attached : dmesg output plus kernel config.

Hello Bjorn,

I currently run my (Ubuntu) system with pristine Linux v4.6 (2dcd0af568) with your patch applied.

It works perfectly ; I have no ioremap.c -related runtime warning, however.

I will try to test some more versions, especially v4.4, v4.5, v4.6-rc1 ; more news on sunday.

And I am willing to do any test you would like me to do ...

In hope this helps.

Comment 7 Valentin QUEQUET 2016-10-29 11:46:43 UTC
Created attachment 243181 [details]
Better Logs Attachment

Attachment per se
Comment 8 Valentin QUEQUET 2016-10-29 13:24:46 UTC
Hi Bjorg,

Patched Linux v4.5 ( b562e44f50 ) also is fine : it functions perfectly and without ioremap.c -related runtime warning either.

Comment 9 Valentin QUEQUET 2016-10-29 14:12:11 UTC
Hi Bjorg,

Patched Linux v4.4 ( afd2ff9b7e ) also runs perfectly -- I forgot to check for the ioremap.c -related runtime warning thoug.

Comment 10 Valentin QUEQUET 2016-10-29 15:01:17 UTC
Hello Bjorg,

I re-run Linux v4.4 and it didn't spit any ioremap warning.

I am now currently running Linux v4.8.5 (stable branch, not mainline), which functions perfectly, with no ioremap warning either.

In hope this helps.

Comment 11 Valentin QUEQUET 2016-10-30 01:26:51 UTC
Hi Bjorn,

I write this message from Linux v4.9.0-rc3 ( mainline, a909d3e636 , plus your test patch applied ) which runs perfectly well on my system. Still without any ioremap runtime warning.

In hope this helps.

Comment 12 Valentin QUEQUET 2016-11-20 09:44:52 UTC
Hi Folks,

This bug seems to be solved upstream.

Bjorn's patch made it in both mainline (4.9-rc5) and Greg's -stable (4.8.9).

I'd suggest this bug be closed ; however, if the patch hinders other people experience, it might get reopened.

In hope this helps.

Valentin QUEQUET
Comment 13 Michael Schenaerts 2016-11-24 06:47:56 UTC
Hey Guys,

This bug looks like this one : Bug 141741

As this one(175391) seems to be fixed, maybe we can close the other one(141741).

Comment 14 Valentin QUEQUET 2016-11-24 10:18:52 UTC

I just notified bugs #141741 and #120321 that they very likely are siblings of this one and invited everybody to read all the three threads in their entirety.

Comment 15 Knud 2016-11-24 16:03:09 UTC
Tested 4.8.10-fc24 KDE spin....works perfect, solves problem

Comment 16 Bjorn Helgaas 2016-12-27 17:25:13 UTC
16d917b130d7 ("PCI: Don't attempt to claim shadow copies of ROM") appeared in v4.9-rc5 and was released in v4.9.  Closing this as fixed; please reopen if you still see the issue.


Note You need to log in before you can comment on or make changes to this bug.