Created attachment 240591 [details] Logs and more details Hello, 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. Sincerely, Valentin QUEQUET
Hello, 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> Diffstat -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. Sincerely, Valentin QUEQUET
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. Sincerely, 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
same problem here https://bugzilla.redhat.com/show_bug.cgi?id=1352272
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.
As soon I have made setup for kernel build I will make the test
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. Sincerely, Valentin
Created attachment 243181 [details] Better Logs Attachment Attachment per se
Hi Bjorg, Patched Linux v4.5 ( b562e44f50 ) also is fine : it functions perfectly and without ioremap.c -related runtime warning either. Regards, Valentin
Hi Bjorg, Patched Linux v4.4 ( afd2ff9b7e ) also runs perfectly -- I forgot to check for the ioremap.c -related runtime warning thoug. Regards, Valentin
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. Sincerely, Valentin
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. Regards, Valentin QUEQUIET
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. Regards, Valentin QUEQUET
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). Regards, Mike
Hi, 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. Regards, Valentin
Tested 4.8.10-fc24 KDE spin....works perfect, solves problem Br Knud
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. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=16d917b130d7