Hi guys,
With current git (v3.11-5058-g57d7309) I get the following oops:
[ 5.434312] ------------[ cut here ]------------ [ 5.434318] WARNING: CPU: 2 PID: 199 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x2e3/0x390() [ 5.434321] Info: mapping multiple BARs. Your kernel is fine. [ 5.434323] Modules linked in: [ 5.434326] arc4 coretemp x86_pkg_temp_thermal intel_powerclamp brcmsmac kvm_intel kvm cordic brcmutil crc32_pclmul mac80211 crc32c_intel ghash_clmulni_intel cfg80211 rfkill iTCO_wdt evdev iTCO_vendor_support aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd applesmc input_polldev hwmon microcode bcma snd_hda_codec_hdmi snd_hda_codec_cirrus fbcon bitblit fbcon_rotate fbcon_ccw fbcon_ud fbcon_cw softcursor font i915(+) snd_hda_intel snd_hda_codec ac video snd_hwdep intel_agp apple_bl battery button snd_pcm intel_gtt snd_page_alloc drm_kms_helper shpchp backlight snd_timer i2c_i801 lpc_ich snd mfd_core soundcore processor ext4 crc16 mbcache jbd2 sd_mod crc_t10dif ahci libahci libata ehci_pci scsi_mod xhci_hcd ehci_hcd usbcore usb_common [ 5.434383] CPU: 2 PID: 199 Comm: systemd-udevd Not tainted 3.11.0-TEG-05060-g0312d0c #81 [ 5.434386] Hardware name: Apple Inc. MacBookAir5,1/Mac-66F35F19FE2A0D05, BIOS MBA51.88Z.00EF.B01.1207271122 07/27/2012 [ 5.434390] 0000000000000009 ffff880168f87898 ffffffff8145be63 ffff880168f878e0 [ 5.434394] ffff880168f878d0 ffffffff8104b17d ffffc9000c080000 00000000a0000000 [ 5.434398] ffffc9000c080000 ffffc9000c080000 0000000010000000 ffff880168f87930 [ 5.434403] Call Trace: [ 5.434409] [<ffffffff8145be63>] dump_stack+0x54/0x8d [ 5.434413] [<ffffffff8104b17d>] warn_slowpath_common+0x7d/0xa0 [ 5.434417] [<ffffffff8104b1ec>] warn_slowpath_fmt+0x4c/0x50 [ 5.434421] [<ffffffff81051fdc>] ? iomem_map_sanity_check+0xac/0xe0 [ 5.434425] [<ffffffff8103e8b3>] __ioremap_caller+0x2e3/0x390 [ 5.434430] [<ffffffff8103e9f2>] ioremap_wc+0x32/0x40 [ 5.434450] [<ffffffffa043f960>] i915_driver_load+0x670/0xf50 [i915] [ 5.434467] [<ffffffff8131540d>] ? drm_get_minor+0x1ad/0x200 [ 5.434471] [<ffffffff81317509>] drm_get_pci_dev+0x129/0x2f0 [ 5.434487] [<ffffffffa043c63c>] i915_pci_probe+0x2c/0x70 [i915] [ 5.434493] [<ffffffff8127f624>] pci_device_probe+0x84/0xe0 [ 5.434502] [<ffffffff81331977>] driver_probe_device+0x87/0x3a0 [ 5.434509] [<ffffffff81331d63>] __driver_attach+0x93/0xa0 [ 5.434516] [<ffffffff81331cd0>] ? __device_attach+0x40/0x40 [ 5.434521] [<ffffffff8132f813>] bus_for_each_dev+0x63/0xa0 [ 5.434525] [<ffffffff813313ce>] driver_attach+0x1e/0x20 [ 5.434529] [<ffffffff81330f40>] bus_add_driver+0x200/0x2d0 [ 5.434533] [<ffffffffa04dc000>] ? 0xffffffffa04dbfff [ 5.434538] [<ffffffff813323e4>] driver_register+0x64/0xf0 [ 5.434541] [<ffffffffa04dc000>] ? 0xffffffffa04dbfff [ 5.434545] [<ffffffff8127f45d>] __pci_register_driver+0x4d/0x50 [ 5.434549] [<ffffffff813177e5>] drm_pci_init+0x115/0x130 [ 5.434552] [<ffffffffa04dc000>] ? 0xffffffffa04dbfff [ 5.434567] [<ffffffffa04dc066>] i915_init+0x66/0x68 [i915] [ 5.434570] [<ffffffff8100022a>] do_one_initcall+0x5a/0x1b0 [ 5.434575] [<ffffffff81071588>] ? __blocking_notifier_call_chain+0x58/0x70 [ 5.434581] [<ffffffff810af52a>] load_module+0x1b0a/0x25a0 [ 5.434584] [<ffffffff810abf70>] ? store_uevent+0x40/0x40 [ 5.434589] [<ffffffff810b0136>] SyS_finit_module+0x86/0xb0 [ 5.434594] [<ffffffff81463da7>] tracesys+0xdd/0xe2 [ 5.434599] ---[ end trace 4f93e77fcaaac9b7 ]---
This only happens when either simplefb or efifb is enabled. I can not reproduce the problem on v3.11 with efifb enabled so it appears to be new.
Let me know if there is any more info I could provide.
Cheers,
Tom
Hi
On Fri, Sep 6, 2013 at 2:10 PM, Tom Gundersen teg@jklm.no wrote:
Hi guys,
With current git (v3.11-5058-g57d7309) I get the following oops:
[ 5.434312] ------------[ cut here ]------------ [ 5.434318] WARNING: CPU: 2 PID: 199 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x2e3/0x390() [ 5.434321] Info: mapping multiple BARs. Your kernel is fine. [ 5.434323] Modules linked in: [ 5.434326] arc4 coretemp x86_pkg_temp_thermal intel_powerclamp brcmsmac kvm_intel kvm cordic brcmutil crc32_pclmul mac80211 crc32c_intel ghash_clmulni_intel cfg80211 rfkill iTCO_wdt evdev iTCO_vendor_support aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd applesmc input_polldev hwmon microcode bcma snd_hda_codec_hdmi snd_hda_codec_cirrus fbcon bitblit fbcon_rotate fbcon_ccw fbcon_ud fbcon_cw softcursor font i915(+) snd_hda_intel snd_hda_codec ac video snd_hwdep intel_agp apple_bl battery button snd_pcm intel_gtt snd_page_alloc drm_kms_helper shpchp backlight snd_timer i2c_i801 lpc_ich snd mfd_core soundcore processor ext4 crc16 mbcache jbd2 sd_mod crc_t10dif ahci libahci libata ehci_pci scsi_mod xhci_hcd ehci_hcd usbcore usb_common [ 5.434383] CPU: 2 PID: 199 Comm: systemd-udevd Not tainted 3.11.0-TEG-05060-g0312d0c #81 [ 5.434386] Hardware name: Apple Inc. MacBookAir5,1/Mac-66F35F19FE2A0D05, BIOS MBA51.88Z.00EF.B01.1207271122 07/27/2012 [ 5.434390] 0000000000000009 ffff880168f87898 ffffffff8145be63 ffff880168f878e0 [ 5.434394] ffff880168f878d0 ffffffff8104b17d ffffc9000c080000 00000000a0000000 [ 5.434398] ffffc9000c080000 ffffc9000c080000 0000000010000000 ffff880168f87930 [ 5.434403] Call Trace: [ 5.434409] [<ffffffff8145be63>] dump_stack+0x54/0x8d [ 5.434413] [<ffffffff8104b17d>] warn_slowpath_common+0x7d/0xa0 [ 5.434417] [<ffffffff8104b1ec>] warn_slowpath_fmt+0x4c/0x50 [ 5.434421] [<ffffffff81051fdc>] ? iomem_map_sanity_check+0xac/0xe0 [ 5.434425] [<ffffffff8103e8b3>] __ioremap_caller+0x2e3/0x390 [ 5.434430] [<ffffffff8103e9f2>] ioremap_wc+0x32/0x40 [ 5.434450] [<ffffffffa043f960>] i915_driver_load+0x670/0xf50 [i915] [ 5.434467] [<ffffffff8131540d>] ? drm_get_minor+0x1ad/0x200 [ 5.434471] [<ffffffff81317509>] drm_get_pci_dev+0x129/0x2f0 [ 5.434487] [<ffffffffa043c63c>] i915_pci_probe+0x2c/0x70 [i915] [ 5.434493] [<ffffffff8127f624>] pci_device_probe+0x84/0xe0 [ 5.434502] [<ffffffff81331977>] driver_probe_device+0x87/0x3a0 [ 5.434509] [<ffffffff81331d63>] __driver_attach+0x93/0xa0 [ 5.434516] [<ffffffff81331cd0>] ? __device_attach+0x40/0x40 [ 5.434521] [<ffffffff8132f813>] bus_for_each_dev+0x63/0xa0 [ 5.434525] [<ffffffff813313ce>] driver_attach+0x1e/0x20 [ 5.434529] [<ffffffff81330f40>] bus_add_driver+0x200/0x2d0 [ 5.434533] [<ffffffffa04dc000>] ? 0xffffffffa04dbfff [ 5.434538] [<ffffffff813323e4>] driver_register+0x64/0xf0 [ 5.434541] [<ffffffffa04dc000>] ? 0xffffffffa04dbfff [ 5.434545] [<ffffffff8127f45d>] __pci_register_driver+0x4d/0x50 [ 5.434549] [<ffffffff813177e5>] drm_pci_init+0x115/0x130 [ 5.434552] [<ffffffffa04dc000>] ? 0xffffffffa04dbfff [ 5.434567] [<ffffffffa04dc066>] i915_init+0x66/0x68 [i915] [ 5.434570] [<ffffffff8100022a>] do_one_initcall+0x5a/0x1b0 [ 5.434575] [<ffffffff81071588>] ? __blocking_notifier_call_chain+0x58/0x70 [ 5.434581] [<ffffffff810af52a>] load_module+0x1b0a/0x25a0 [ 5.434584] [<ffffffff810abf70>] ? store_uevent+0x40/0x40 [ 5.434589] [<ffffffff810b0136>] SyS_finit_module+0x86/0xb0 [ 5.434594] [<ffffffff81463da7>] tracesys+0xdd/0xe2 [ 5.434599] ---[ end trace 4f93e77fcaaac9b7 ]---
This only happens when either simplefb or efifb is enabled. I can not reproduce the problem on v3.11 with efifb enabled so it appears to be new.
It seems to be unrelated to the x86-sysfb changes. The WARN_ON triggered here obviously means that i915 remaps VMEM before removing efifb. So either i915 now calls ioremap and friends _before_ calling remove_conflicting_framebuffers(), or efifb is not unloaded correctly.
Daniel, any ideas?
Tom, some things off the top of my head: - Is efifb still running after i915 loaded? You can see that via: cat /sys/class/graphics/fb0/name (and also fb1, fb2, ... whatever is there) If it's not running, anymore, then it's quite likely an i915 issue. - Do you get a "fb: conflicting hw usage ..." in your dmesg log? - Do you get the same errors if you copy efifb.c from 3.11 over and use it instead of the new efifb.c?
Thanks David
On Sat, Sep 7, 2013 at 2:40 PM, David Herrmann dh.herrmann@gmail.com wrote:
On Fri, Sep 6, 2013 at 2:10 PM, Tom Gundersen teg@jklm.no wrote:
Hi guys,
With current git (v3.11-5058-g57d7309) I get the following oops:
[ 5.434312] ------------[ cut here ]------------ [ 5.434318] WARNING: CPU: 2 PID: 199 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x2e3/0x390() [ 5.434321] Info: mapping multiple BARs. Your kernel is fine. [ 5.434323] Modules linked in: [ 5.434326] arc4 coretemp x86_pkg_temp_thermal intel_powerclamp brcmsmac kvm_intel kvm cordic brcmutil crc32_pclmul mac80211 crc32c_intel ghash_clmulni_intel cfg80211 rfkill iTCO_wdt evdev iTCO_vendor_support aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd applesmc input_polldev hwmon microcode bcma snd_hda_codec_hdmi snd_hda_codec_cirrus fbcon bitblit fbcon_rotate fbcon_ccw fbcon_ud fbcon_cw softcursor font i915(+) snd_hda_intel snd_hda_codec ac video snd_hwdep intel_agp apple_bl battery button snd_pcm intel_gtt snd_page_alloc drm_kms_helper shpchp backlight snd_timer i2c_i801 lpc_ich snd mfd_core soundcore processor ext4 crc16 mbcache jbd2 sd_mod crc_t10dif ahci libahci libata ehci_pci scsi_mod xhci_hcd ehci_hcd usbcore usb_common [ 5.434383] CPU: 2 PID: 199 Comm: systemd-udevd Not tainted 3.11.0-TEG-05060-g0312d0c #81 [ 5.434386] Hardware name: Apple Inc. MacBookAir5,1/Mac-66F35F19FE2A0D05, BIOS MBA51.88Z.00EF.B01.1207271122 07/27/2012 [ 5.434390] 0000000000000009 ffff880168f87898 ffffffff8145be63 ffff880168f878e0 [ 5.434394] ffff880168f878d0 ffffffff8104b17d ffffc9000c080000 00000000a0000000 [ 5.434398] ffffc9000c080000 ffffc9000c080000 0000000010000000 ffff880168f87930 [ 5.434403] Call Trace: [ 5.434409] [<ffffffff8145be63>] dump_stack+0x54/0x8d [ 5.434413] [<ffffffff8104b17d>] warn_slowpath_common+0x7d/0xa0 [ 5.434417] [<ffffffff8104b1ec>] warn_slowpath_fmt+0x4c/0x50 [ 5.434421] [<ffffffff81051fdc>] ? iomem_map_sanity_check+0xac/0xe0 [ 5.434425] [<ffffffff8103e8b3>] __ioremap_caller+0x2e3/0x390 [ 5.434430] [<ffffffff8103e9f2>] ioremap_wc+0x32/0x40 [ 5.434450] [<ffffffffa043f960>] i915_driver_load+0x670/0xf50 [i915] [ 5.434467] [<ffffffff8131540d>] ? drm_get_minor+0x1ad/0x200 [ 5.434471] [<ffffffff81317509>] drm_get_pci_dev+0x129/0x2f0 [ 5.434487] [<ffffffffa043c63c>] i915_pci_probe+0x2c/0x70 [i915] [ 5.434493] [<ffffffff8127f624>] pci_device_probe+0x84/0xe0 [ 5.434502] [<ffffffff81331977>] driver_probe_device+0x87/0x3a0 [ 5.434509] [<ffffffff81331d63>] __driver_attach+0x93/0xa0 [ 5.434516] [<ffffffff81331cd0>] ? __device_attach+0x40/0x40 [ 5.434521] [<ffffffff8132f813>] bus_for_each_dev+0x63/0xa0 [ 5.434525] [<ffffffff813313ce>] driver_attach+0x1e/0x20 [ 5.434529] [<ffffffff81330f40>] bus_add_driver+0x200/0x2d0 [ 5.434533] [<ffffffffa04dc000>] ? 0xffffffffa04dbfff [ 5.434538] [<ffffffff813323e4>] driver_register+0x64/0xf0 [ 5.434541] [<ffffffffa04dc000>] ? 0xffffffffa04dbfff [ 5.434545] [<ffffffff8127f45d>] __pci_register_driver+0x4d/0x50 [ 5.434549] [<ffffffff813177e5>] drm_pci_init+0x115/0x130 [ 5.434552] [<ffffffffa04dc000>] ? 0xffffffffa04dbfff [ 5.434567] [<ffffffffa04dc066>] i915_init+0x66/0x68 [i915] [ 5.434570] [<ffffffff8100022a>] do_one_initcall+0x5a/0x1b0 [ 5.434575] [<ffffffff81071588>] ? __blocking_notifier_call_chain+0x58/0x70 [ 5.434581] [<ffffffff810af52a>] load_module+0x1b0a/0x25a0 [ 5.434584] [<ffffffff810abf70>] ? store_uevent+0x40/0x40 [ 5.434589] [<ffffffff810b0136>] SyS_finit_module+0x86/0xb0 [ 5.434594] [<ffffffff81463da7>] tracesys+0xdd/0xe2 [ 5.434599] ---[ end trace 4f93e77fcaaac9b7 ]---
This only happens when either simplefb or efifb is enabled. I can not reproduce the problem on v3.11 with efifb enabled so it appears to be new.
It seems to be unrelated to the x86-sysfb changes. The WARN_ON triggered here obviously means that i915 remaps VMEM before removing efifb. So either i915 now calls ioremap and friends _before_ calling remove_conflicting_framebuffers(), or efifb is not unloaded correctly.
I redid all the tests, and I'm now not able to reproduce this with efifb, only with simplefb (not sure if I made a mistake before or if some config changed). I attached the two different dmesg outputs (only difference is X86_SYSFB).
Tom, some things off the top of my head:
- Is efifb still running after i915 loaded? You can see that via: cat /sys/class/graphics/fb0/name (and also fb1, fb2, ... whatever is there) If it's not running, anymore, then it's quite likely an i915 issue.
I only have /sys/class/graphics/fb0/name and it says inteldrmfb (this is after i915 has taken over from simplefb).
- Do you get a "fb: conflicting hw usage ..." in your dmesg log?
Yes: "fb: conflicting fb hw usage inteldrmfb vs simple - removing generic driver"
-t
Hi
On Sat, Sep 7, 2013 at 3:45 PM, Tom Gundersen teg@jklm.no wrote:
On Sat, Sep 7, 2013 at 2:40 PM, David Herrmann dh.herrmann@gmail.com wrote:
On Fri, Sep 6, 2013 at 2:10 PM, Tom Gundersen teg@jklm.no wrote:
Hi guys,
With current git (v3.11-5058-g57d7309) I get the following oops:
[ 5.434312] ------------[ cut here ]------------ [ 5.434318] WARNING: CPU: 2 PID: 199 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x2e3/0x390() [ 5.434321] Info: mapping multiple BARs. Your kernel is fine. [ 5.434323] Modules linked in: [ 5.434326] arc4 coretemp x86_pkg_temp_thermal intel_powerclamp brcmsmac kvm_intel kvm cordic brcmutil crc32_pclmul mac80211 crc32c_intel ghash_clmulni_intel cfg80211 rfkill iTCO_wdt evdev iTCO_vendor_support aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd applesmc input_polldev hwmon microcode bcma snd_hda_codec_hdmi snd_hda_codec_cirrus fbcon bitblit fbcon_rotate fbcon_ccw fbcon_ud fbcon_cw softcursor font i915(+) snd_hda_intel snd_hda_codec ac video snd_hwdep intel_agp apple_bl battery button snd_pcm intel_gtt snd_page_alloc drm_kms_helper shpchp backlight snd_timer i2c_i801 lpc_ich snd mfd_core soundcore processor ext4 crc16 mbcache jbd2 sd_mod crc_t10dif ahci libahci libata ehci_pci scsi_mod xhci_hcd ehci_hcd usbcore usb_common [ 5.434383] CPU: 2 PID: 199 Comm: systemd-udevd Not tainted 3.11.0-TEG-05060-g0312d0c #81 [ 5.434386] Hardware name: Apple Inc. MacBookAir5,1/Mac-66F35F19FE2A0D05, BIOS MBA51.88Z.00EF.B01.1207271122 07/27/2012 [ 5.434390] 0000000000000009 ffff880168f87898 ffffffff8145be63 ffff880168f878e0 [ 5.434394] ffff880168f878d0 ffffffff8104b17d ffffc9000c080000 00000000a0000000 [ 5.434398] ffffc9000c080000 ffffc9000c080000 0000000010000000 ffff880168f87930 [ 5.434403] Call Trace: [ 5.434409] [<ffffffff8145be63>] dump_stack+0x54/0x8d [ 5.434413] [<ffffffff8104b17d>] warn_slowpath_common+0x7d/0xa0 [ 5.434417] [<ffffffff8104b1ec>] warn_slowpath_fmt+0x4c/0x50 [ 5.434421] [<ffffffff81051fdc>] ? iomem_map_sanity_check+0xac/0xe0 [ 5.434425] [<ffffffff8103e8b3>] __ioremap_caller+0x2e3/0x390 [ 5.434430] [<ffffffff8103e9f2>] ioremap_wc+0x32/0x40 [ 5.434450] [<ffffffffa043f960>] i915_driver_load+0x670/0xf50 [i915] [ 5.434467] [<ffffffff8131540d>] ? drm_get_minor+0x1ad/0x200 [ 5.434471] [<ffffffff81317509>] drm_get_pci_dev+0x129/0x2f0 [ 5.434487] [<ffffffffa043c63c>] i915_pci_probe+0x2c/0x70 [i915] [ 5.434493] [<ffffffff8127f624>] pci_device_probe+0x84/0xe0 [ 5.434502] [<ffffffff81331977>] driver_probe_device+0x87/0x3a0 [ 5.434509] [<ffffffff81331d63>] __driver_attach+0x93/0xa0 [ 5.434516] [<ffffffff81331cd0>] ? __device_attach+0x40/0x40 [ 5.434521] [<ffffffff8132f813>] bus_for_each_dev+0x63/0xa0 [ 5.434525] [<ffffffff813313ce>] driver_attach+0x1e/0x20 [ 5.434529] [<ffffffff81330f40>] bus_add_driver+0x200/0x2d0 [ 5.434533] [<ffffffffa04dc000>] ? 0xffffffffa04dbfff [ 5.434538] [<ffffffff813323e4>] driver_register+0x64/0xf0 [ 5.434541] [<ffffffffa04dc000>] ? 0xffffffffa04dbfff [ 5.434545] [<ffffffff8127f45d>] __pci_register_driver+0x4d/0x50 [ 5.434549] [<ffffffff813177e5>] drm_pci_init+0x115/0x130 [ 5.434552] [<ffffffffa04dc000>] ? 0xffffffffa04dbfff [ 5.434567] [<ffffffffa04dc066>] i915_init+0x66/0x68 [i915] [ 5.434570] [<ffffffff8100022a>] do_one_initcall+0x5a/0x1b0 [ 5.434575] [<ffffffff81071588>] ? __blocking_notifier_call_chain+0x58/0x70 [ 5.434581] [<ffffffff810af52a>] load_module+0x1b0a/0x25a0 [ 5.434584] [<ffffffff810abf70>] ? store_uevent+0x40/0x40 [ 5.434589] [<ffffffff810b0136>] SyS_finit_module+0x86/0xb0 [ 5.434594] [<ffffffff81463da7>] tracesys+0xdd/0xe2 [ 5.434599] ---[ end trace 4f93e77fcaaac9b7 ]---
This only happens when either simplefb or efifb is enabled. I can not reproduce the problem on v3.11 with efifb enabled so it appears to be new.
It seems to be unrelated to the x86-sysfb changes. The WARN_ON triggered here obviously means that i915 remaps VMEM before removing efifb. So either i915 now calls ioremap and friends _before_ calling remove_conflicting_framebuffers(), or efifb is not unloaded correctly.
I redid all the tests, and I'm now not able to reproduce this with efifb, only with simplefb (not sure if I made a mistake before or if some config changed). I attached the two different dmesg outputs (only difference is X86_SYSFB).
Tom, some things off the top of my head:
- Is efifb still running after i915 loaded? You can see that via: cat /sys/class/graphics/fb0/name (and also fb1, fb2, ... whatever is there) If it's not running, anymore, then it's quite likely an i915 issue.
I only have /sys/class/graphics/fb0/name and it says inteldrmfb (this is after i915 has taken over from simplefb).
- Do you get a "fb: conflicting hw usage ..." in your dmesg log?
Yes: "fb: conflicting fb hw usage inteldrmfb vs simple - removing generic driver"
Ok, now this makes sense. simplefb lacks the ->fb_destroy() callback so it does not correctly react to remove_conflicting_framebuffer(). But you can safely ignore the warning as simplefb is still unloaded. So it cannot be accessed anymore. It just leaks the remapping.
I will send a patch later today which adds the fb_destroy() callback.
Thanks David
Hi Tom
On Sat, Sep 7, 2013 at 3:52 PM, David Herrmann dh.herrmann@gmail.com wrote:
Hi
On Sat, Sep 7, 2013 at 3:45 PM, Tom Gundersen teg@jklm.no wrote:
On Sat, Sep 7, 2013 at 2:40 PM, David Herrmann dh.herrmann@gmail.com wrote:
It seems to be unrelated to the x86-sysfb changes. The WARN_ON triggered here obviously means that i915 remaps VMEM before removing efifb. So either i915 now calls ioremap and friends _before_ calling remove_conflicting_framebuffers(), or efifb is not unloaded correctly.
I redid all the tests, and I'm now not able to reproduce this with efifb, only with simplefb (not sure if I made a mistake before or if some config changed). I attached the two different dmesg outputs (only difference is X86_SYSFB).
Tom, some things off the top of my head:
- Is efifb still running after i915 loaded? You can see that via: cat /sys/class/graphics/fb0/name (and also fb1, fb2, ... whatever is there) If it's not running, anymore, then it's quite likely an i915 issue.
I only have /sys/class/graphics/fb0/name and it says inteldrmfb (this is after i915 has taken over from simplefb).
- Do you get a "fb: conflicting hw usage ..." in your dmesg log?
Yes: "fb: conflicting fb hw usage inteldrmfb vs simple - removing generic driver"
Ok, now this makes sense. simplefb lacks the ->fb_destroy() callback so it does not correctly react to remove_conflicting_framebuffer(). But you can safely ignore the warning as simplefb is still unloaded. So it cannot be accessed anymore. It just leaks the remapping.
I will send a patch later today which adds the fb_destroy() callback.
Attached are two patches. The first one should fix this issue, the second one is the rebased ioremap_wc() patch from the other thread.
Does this fix the issue (and the speed-problems)?
Thanks David
Hi David,
On Sat, Sep 7, 2013 at 4:30 PM, David Herrmann dh.herrmann@gmail.com wrote:
Attached are two patches. The first one should fix this issue, the second one is the rebased ioremap_wc() patch from the other thread.
Does this fix the issue (and the speed-problems)?
Sadly, no. I added a few printk's to verify that the function you added is called (it is), but still the same oops.
The slowdown is (still) fixed though :-)
dmesg attached.
Cheers,
Tom
Hi David,
On Sat, Sep 7, 2013 at 11:57 PM, Tom Gundersen teg@jklm.no wrote:
On Sat, Sep 7, 2013 at 4:30 PM, David Herrmann dh.herrmann@gmail.com wrote:
Attached are two patches. The first one should fix this issue, the second one is the rebased ioremap_wc() patch from the other thread.
Does this fix the issue (and the speed-problems)?
Sadly, no. I added a few printk's to verify that the function you added is called (it is), but still the same oops.
A few more datapoints:
Triggers: X86_SYSFB=y and FB_SIMPLE=n (so no fbdev until i915 is loaded) X86_SYSFB=y and FB_SIMPLE=y
Does not trigger: X86_SYSFB=y, FB_EFI=yes, and without the overflow fix (i.e., so we fall back to efifb) X86_SYSFB=n and FB_EFI=y X86_SYSFB=n and FB_EFI=n (so no fbdev until i915 is loaded)
Does this make any sense?
Cheers,
Tom
Hi
On Sun, Sep 8, 2013 at 1:22 AM, Tom Gundersen teg@jklm.no wrote:
Hi David,
On Sat, Sep 7, 2013 at 11:57 PM, Tom Gundersen teg@jklm.no wrote:
On Sat, Sep 7, 2013 at 4:30 PM, David Herrmann dh.herrmann@gmail.com wrote:
Attached are two patches. The first one should fix this issue, the second one is the rebased ioremap_wc() patch from the other thread.
Does this fix the issue (and the speed-problems)?
Sadly, no. I added a few printk's to verify that the function you added is called (it is), but still the same oops.
A few more datapoints:
Triggers: X86_SYSFB=y and FB_SIMPLE=n (so no fbdev until i915 is loaded) X86_SYSFB=y and FB_SIMPLE=y
Does not trigger: X86_SYSFB=y, FB_EFI=yes, and without the overflow fix (i.e., so we fall back to efifb) X86_SYSFB=n and FB_EFI=y X86_SYSFB=n and FB_EFI=n (so no fbdev until i915 is loaded)
Does this make any sense?
Thanks a lot for these results. I think I got it know. I will write a patch that marks the resource as busy. See: kernel/resource.c iomem_map_sanity_check() It also contains a hint that we should set this for driver-resources which not directly map to hardware resources (such as veasfb and, obviously, simplefb).
Following a diff which hopefully fixes this. The other two patches should still be required, though. I will try to write a proper patch tomorrow.
Thanks a lot for these extensive tests, Tom! David
diff --git a/arch/x86/kernel/sysfb_simplefb.c b/arch/x86/kernel/sysfb_simplefb.c index 22513e9..b7bb615 100644 --- a/arch/x86/kernel/sysfb_simplefb.c +++ b/arch/x86/kernel/sysfb_simplefb.c @@ -79,7 +79,7 @@ __init int create_simplefb(const struct screen_info *si,
/* setup IORESOURCE_MEM as framebuffer memory */ memset(&res, 0, sizeof(res)); - res.flags = IORESOURCE_MEM; + res.flags = IORESOURCE_MEM | IORESOURCE_BUSY; res.name = simplefb_resname; res.start = si->lfb_base; res.end = si->lfb_base + len - 1;
On Sun, Sep 8, 2013 at 2:13 AM, David Herrmann dh.herrmann@gmail.com wrote:
Hi
On Sun, Sep 8, 2013 at 1:22 AM, Tom Gundersen teg@jklm.no wrote:
Hi David,
On Sat, Sep 7, 2013 at 11:57 PM, Tom Gundersen teg@jklm.no wrote:
On Sat, Sep 7, 2013 at 4:30 PM, David Herrmann dh.herrmann@gmail.com wrote:
Attached are two patches. The first one should fix this issue, the second one is the rebased ioremap_wc() patch from the other thread.
Does this fix the issue (and the speed-problems)?
Sadly, no. I added a few printk's to verify that the function you added is called (it is), but still the same oops.
A few more datapoints:
Triggers: X86_SYSFB=y and FB_SIMPLE=n (so no fbdev until i915 is loaded) X86_SYSFB=y and FB_SIMPLE=y
Does not trigger: X86_SYSFB=y, FB_EFI=yes, and without the overflow fix (i.e., so we fall back to efifb) X86_SYSFB=n and FB_EFI=y X86_SYSFB=n and FB_EFI=n (so no fbdev until i915 is loaded)
Does this make any sense?
Thanks a lot for these results. I think I got it know. I will write a patch that marks the resource as busy. See: kernel/resource.c iomem_map_sanity_check() It also contains a hint that we should set this for driver-resources which not directly map to hardware resources (such as veasfb and, obviously, simplefb).
Following a diff which hopefully fixes this. The other two patches should still be required, though. I will try to write a proper patch tomorrow.
Thanks a lot for these extensive tests, Tom!
No problem. Thanks for the fix, it works for me!
Cheers,
Tom
diff --git a/arch/x86/kernel/sysfb_simplefb.c b/arch/x86/kernel/sysfb_simplefb.c index 22513e9..b7bb615 100644 --- a/arch/x86/kernel/sysfb_simplefb.c +++ b/arch/x86/kernel/sysfb_simplefb.c @@ -79,7 +79,7 @@ __init int create_simplefb(const struct screen_info *si,
/* setup IORESOURCE_MEM as framebuffer memory */ memset(&res, 0, sizeof(res));
res.flags = IORESOURCE_MEM;
res.flags = IORESOURCE_MEM | IORESOURCE_BUSY; res.name = simplefb_resname; res.start = si->lfb_base; res.end = si->lfb_base + len - 1;
Hi Tom
On Sun, Sep 8, 2013 at 11:38 AM, Tom Gundersen teg@jklm.no wrote:
On Sun, Sep 8, 2013 at 2:13 AM, David Herrmann dh.herrmann@gmail.com wrote:
Hi
On Sun, Sep 8, 2013 at 1:22 AM, Tom Gundersen teg@jklm.no wrote:
Hi David,
On Sat, Sep 7, 2013 at 11:57 PM, Tom Gundersen teg@jklm.no wrote:
On Sat, Sep 7, 2013 at 4:30 PM, David Herrmann dh.herrmann@gmail.com wrote:
Attached are two patches. The first one should fix this issue, the second one is the rebased ioremap_wc() patch from the other thread.
Does this fix the issue (and the speed-problems)?
Sadly, no. I added a few printk's to verify that the function you added is called (it is), but still the same oops.
A few more datapoints:
Triggers: X86_SYSFB=y and FB_SIMPLE=n (so no fbdev until i915 is loaded) X86_SYSFB=y and FB_SIMPLE=y
Does not trigger: X86_SYSFB=y, FB_EFI=yes, and without the overflow fix (i.e., so we fall back to efifb) X86_SYSFB=n and FB_EFI=y X86_SYSFB=n and FB_EFI=n (so no fbdev until i915 is loaded)
Does this make any sense?
Thanks a lot for these results. I think I got it know. I will write a patch that marks the resource as busy. See: kernel/resource.c iomem_map_sanity_check() It also contains a hint that we should set this for driver-resources which not directly map to hardware resources (such as veasfb and, obviously, simplefb).
Following a diff which hopefully fixes this. The other two patches should still be required, though. I will try to write a proper patch tomorrow.
Thanks a lot for these extensive tests, Tom!
No problem. Thanks for the fix, it works for me!
I finally got time to send the patches out. You're on CC on all of them. They're unmodified so no need to test again.
Thanks for the feedback! David
dri-devel@lists.freedesktop.org
-
David Herrmann -
Tom Gundersen