Re: [REGRESSION] v3.12-rc1: i915_driver_load oopses when sysfb enabled

2013-10-02 Thread David Herrmann 
Hi Tom

On Sun, Sep 8, 2013 at 11:38 AM, Tom Gundersen t...@jklm.no wrote:
 On Sun, Sep 8, 2013 at 2:13 AM, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 On Sun, Sep 8, 2013 at 1:22 AM, Tom Gundersen t...@jklm.no wrote:
 Hi David,

 On Sat, Sep 7, 2013 at 11:57 PM, Tom Gundersen t...@jklm.no wrote:
 On Sat, Sep 7, 2013 at 4:30 PM, David Herrmann dh.herrm...@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 mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[REGRESSION] v3.12-rc1: i915_driver_load oopses when sysfb enabled

2013-09-08 Thread Tom Gundersen 
Hi David,

On Sat, Sep 7, 2013 at 4:30 PM, David Herrmann  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
-- next part --
A non-text attachment was scrubbed...
Name: dmesg-i915-oops
Type: application/octet-stream
Size: 141121 bytes
Desc: not available
URL:

Re: [REGRESSION] v3.12-rc1: i915_driver_load oopses when sysfb enabled

2013-09-08 Thread Tom Gundersen 
On Sun, Sep 8, 2013 at 2:13 AM, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 On Sun, Sep 8, 2013 at 1:22 AM, Tom Gundersen t...@jklm.no wrote:
 Hi David,

 On Sat, Sep 7, 2013 at 11:57 PM, Tom Gundersen t...@jklm.no wrote:
 On Sat, Sep 7, 2013 at 4:30 PM, David Herrmann dh.herrm...@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;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [REGRESSION] v3.12-rc1: i915_driver_load oopses when sysfb enabled

2013-09-07 Thread David Herrmann 
Hi

On Fri, Sep 6, 2013 at 2:10 PM, Tom Gundersen t...@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]  0009 880168f87898 8145be63
 880168f878e0
 [5.434394]  880168f878d0 8104b17d c9000c08
 a000
 [5.434398]  c9000c08 c9000c08 1000
 880168f87930
 [5.434403] Call Trace:
 [5.434409]  [8145be63] dump_stack+0x54/0x8d
 [5.434413]  [8104b17d] warn_slowpath_common+0x7d/0xa0
 [5.434417]  [8104b1ec] warn_slowpath_fmt+0x4c/0x50
 [5.434421]  [81051fdc] ? iomem_map_sanity_check+0xac/0xe0
 [5.434425]  [8103e8b3] __ioremap_caller+0x2e3/0x390
 [5.434430]  [8103e9f2] ioremap_wc+0x32/0x40
 [5.434450]  [a043f960] i915_driver_load+0x670/0xf50 [i915]
 [5.434467]  [8131540d] ? drm_get_minor+0x1ad/0x200
 [5.434471]  [81317509] drm_get_pci_dev+0x129/0x2f0
 [5.434487]  [a043c63c] i915_pci_probe+0x2c/0x70 [i915]
 [5.434493]  [8127f624] pci_device_probe+0x84/0xe0
 [5.434502]  [81331977] driver_probe_device+0x87/0x3a0
 [5.434509]  [81331d63] __driver_attach+0x93/0xa0
 [5.434516]  [81331cd0] ? __device_attach+0x40/0x40
 [5.434521]  [8132f813] bus_for_each_dev+0x63/0xa0
 [5.434525]  [813313ce] driver_attach+0x1e/0x20
 [5.434529]  [81330f40] bus_add_driver+0x200/0x2d0
 [5.434533]  [a04dc000] ? 0xa04dbfff
 [5.434538]  [813323e4] driver_register+0x64/0xf0
 [5.434541]  [a04dc000] ? 0xa04dbfff
 [5.434545]  [8127f45d] __pci_register_driver+0x4d/0x50
 [5.434549]  [813177e5] drm_pci_init+0x115/0x130
 [5.434552]  [a04dc000] ? 0xa04dbfff
 [5.434567]  [a04dc066] i915_init+0x66/0x68 [i915]
 [5.434570]  [8100022a] do_one_initcall+0x5a/0x1b0
 [5.434575]  [81071588] ? 
 __blocking_notifier_call_chain+0x58/0x70
 [5.434581]  [810af52a] load_module+0x1b0a/0x25a0
 [5.434584]  [810abf70] ? store_uevent+0x40/0x40
 [5.434589]  [810b0136] SyS_finit_module+0x86/0xb0
 [5.434594]  [81463da7] 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [REGRESSION] v3.12-rc1: i915_driver_load oopses when sysfb enabled

2013-09-07 Thread Tom Gundersen 
On Sat, Sep 7, 2013 at 2:40 PM, David Herrmann dh.herrm...@gmail.com wrote:
 On Fri, Sep 6, 2013 at 2:10 PM, Tom Gundersen t...@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]  0009 880168f87898 8145be63
 880168f878e0
 [5.434394]  880168f878d0 8104b17d c9000c08
 a000
 [5.434398]  c9000c08 c9000c08 1000
 880168f87930
 [5.434403] Call Trace:
 [5.434409]  [8145be63] dump_stack+0x54/0x8d
 [5.434413]  [8104b17d] warn_slowpath_common+0x7d/0xa0
 [5.434417]  [8104b1ec] warn_slowpath_fmt+0x4c/0x50
 [5.434421]  [81051fdc] ? iomem_map_sanity_check+0xac/0xe0
 [5.434425]  [8103e8b3] __ioremap_caller+0x2e3/0x390
 [5.434430]  [8103e9f2] ioremap_wc+0x32/0x40
 [5.434450]  [a043f960] i915_driver_load+0x670/0xf50 [i915]
 [5.434467]  [8131540d] ? drm_get_minor+0x1ad/0x200
 [5.434471]  [81317509] drm_get_pci_dev+0x129/0x2f0
 [5.434487]  [a043c63c] i915_pci_probe+0x2c/0x70 [i915]
 [5.434493]  [8127f624] pci_device_probe+0x84/0xe0
 [5.434502]  [81331977] driver_probe_device+0x87/0x3a0
 [5.434509]  [81331d63] __driver_attach+0x93/0xa0
 [5.434516]  [81331cd0] ? __device_attach+0x40/0x40
 [5.434521]  [8132f813] bus_for_each_dev+0x63/0xa0
 [5.434525]  [813313ce] driver_attach+0x1e/0x20
 [5.434529]  [81330f40] bus_add_driver+0x200/0x2d0
 [5.434533]  [a04dc000] ? 0xa04dbfff
 [5.434538]  [813323e4] driver_register+0x64/0xf0
 [5.434541]  [a04dc000] ? 0xa04dbfff
 [5.434545]  [8127f45d] __pci_register_driver+0x4d/0x50
 [5.434549]  [813177e5] drm_pci_init+0x115/0x130
 [5.434552]  [a04dc000] ? 0xa04dbfff
 [5.434567]  [a04dc066] i915_init+0x66/0x68 [i915]
 [5.434570]  [8100022a] do_one_initcall+0x5a/0x1b0
 [5.434575]  [81071588] ? 
 __blocking_notifier_call_chain+0x58/0x70
 [5.434581]  [810af52a] load_module+0x1b0a/0x25a0
 [5.434584]  [810abf70] ? store_uevent+0x40/0x40
 [5.434589]  [810b0136] SyS_finit_module+0x86/0xb0
 [5.434594]  [81463da7] 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
___
dri-devel mailing list

Re: [REGRESSION] v3.12-rc1: i915_driver_load oopses when sysfb enabled

2013-09-07 Thread David Herrmann 
Hi

On Sat, Sep 7, 2013 at 3:45 PM, Tom Gundersen t...@jklm.no wrote:
 On Sat, Sep 7, 2013 at 2:40 PM, David Herrmann dh.herrm...@gmail.com wrote:
 On Fri, Sep 6, 2013 at 2:10 PM, Tom Gundersen t...@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]  0009 880168f87898 8145be63
 880168f878e0
 [5.434394]  880168f878d0 8104b17d c9000c08
 a000
 [5.434398]  c9000c08 c9000c08 1000
 880168f87930
 [5.434403] Call Trace:
 [5.434409]  [8145be63] dump_stack+0x54/0x8d
 [5.434413]  [8104b17d] warn_slowpath_common+0x7d/0xa0
 [5.434417]  [8104b1ec] warn_slowpath_fmt+0x4c/0x50
 [5.434421]  [81051fdc] ? iomem_map_sanity_check+0xac/0xe0
 [5.434425]  [8103e8b3] __ioremap_caller+0x2e3/0x390
 [5.434430]  [8103e9f2] ioremap_wc+0x32/0x40
 [5.434450]  [a043f960] i915_driver_load+0x670/0xf50 [i915]
 [5.434467]  [8131540d] ? drm_get_minor+0x1ad/0x200
 [5.434471]  [81317509] drm_get_pci_dev+0x129/0x2f0
 [5.434487]  [a043c63c] i915_pci_probe+0x2c/0x70 [i915]
 [5.434493]  [8127f624] pci_device_probe+0x84/0xe0
 [5.434502]  [81331977] driver_probe_device+0x87/0x3a0
 [5.434509]  [81331d63] __driver_attach+0x93/0xa0
 [5.434516]  [81331cd0] ? __device_attach+0x40/0x40
 [5.434521]  [8132f813] bus_for_each_dev+0x63/0xa0
 [5.434525]  [813313ce] driver_attach+0x1e/0x20
 [5.434529]  [81330f40] bus_add_driver+0x200/0x2d0
 [5.434533]  [a04dc000] ? 0xa04dbfff
 [5.434538]  [813323e4] driver_register+0x64/0xf0
 [5.434541]  [a04dc000] ? 0xa04dbfff
 [5.434545]  [8127f45d] __pci_register_driver+0x4d/0x50
 [5.434549]  [813177e5] drm_pci_init+0x115/0x130
 [5.434552]  [a04dc000] ? 0xa04dbfff
 [5.434567]  [a04dc066] i915_init+0x66/0x68 [i915]
 [5.434570]  [8100022a] do_one_initcall+0x5a/0x1b0
 [5.434575]  [81071588] ? 
 __blocking_notifier_call_chain+0x58/0x70
 [5.434581]  [810af52a] load_module+0x1b0a/0x25a0
 [5.434584]  [810abf70] ? store_uevent+0x40/0x40
 [5.434589]  [810b0136] SyS_finit_module+0x86/0xb0
 [5.434594]  [81463da7] 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

Re: [REGRESSION] v3.12-rc1: i915_driver_load oopses when sysfb enabled

2013-09-07 Thread Tom Gundersen 
Hi David,

On Sat, Sep 7, 2013 at 11:57 PM, Tom Gundersen t...@jklm.no wrote:
 On Sat, Sep 7, 2013 at 4:30 PM, David Herrmann dh.herrm...@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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [REGRESSION] v3.12-rc1: i915_driver_load oopses when sysfb enabled

2013-09-07 Thread David Herrmann 
Hi

On Sun, Sep 8, 2013 at 1:22 AM, Tom Gundersen t...@jklm.no wrote:
 Hi David,

 On Sat, Sep 7, 2013 at 11:57 PM, Tom Gundersen t...@jklm.no wrote:
 On Sat, Sep 7, 2013 at 4:30 PM, David Herrmann dh.herrm...@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;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[REGRESSION] v3.12-rc1: i915_driver_load oopses when sysfb enabled

2013-09-06 Thread Tom Gundersen 
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]  0009 880168f87898 8145be63
880168f878e0
[5.434394]  880168f878d0 8104b17d c9000c08
a000
[5.434398]  c9000c08 c9000c08 1000
880168f87930
[5.434403] Call Trace:
[5.434409]  [8145be63] dump_stack+0x54/0x8d
[5.434413]  [8104b17d] warn_slowpath_common+0x7d/0xa0
[5.434417]  [8104b1ec] warn_slowpath_fmt+0x4c/0x50
[5.434421]  [81051fdc] ? iomem_map_sanity_check+0xac/0xe0
[5.434425]  [8103e8b3] __ioremap_caller+0x2e3/0x390
[5.434430]  [8103e9f2] ioremap_wc+0x32/0x40
[5.434450]  [a043f960] i915_driver_load+0x670/0xf50 [i915]
[5.434467]  [8131540d] ? drm_get_minor+0x1ad/0x200
[5.434471]  [81317509] drm_get_pci_dev+0x129/0x2f0
[5.434487]  [a043c63c] i915_pci_probe+0x2c/0x70 [i915]
[5.434493]  [8127f624] pci_device_probe+0x84/0xe0
[5.434502]  [81331977] driver_probe_device+0x87/0x3a0
[5.434509]  [81331d63] __driver_attach+0x93/0xa0
[5.434516]  [81331cd0] ? __device_attach+0x40/0x40
[5.434521]  [8132f813] bus_for_each_dev+0x63/0xa0
[5.434525]  [813313ce] driver_attach+0x1e/0x20
[5.434529]  [81330f40] bus_add_driver+0x200/0x2d0
[5.434533]  [a04dc000] ? 0xa04dbfff
[5.434538]  [813323e4] driver_register+0x64/0xf0
[5.434541]  [a04dc000] ? 0xa04dbfff
[5.434545]  [8127f45d] __pci_register_driver+0x4d/0x50
[5.434549]  [813177e5] drm_pci_init+0x115/0x130
[5.434552]  [a04dc000] ? 0xa04dbfff
[5.434567]  [a04dc066] i915_init+0x66/0x68 [i915]
[5.434570]  [8100022a] do_one_initcall+0x5a/0x1b0
[5.434575]  [81071588] ? __blocking_notifier_call_chain+0x58/0x70
[5.434581]  [810af52a] load_module+0x1b0a/0x25a0
[5.434584]  [810abf70] ? store_uevent+0x40/0x40
[5.434589]  [810b0136] SyS_finit_module+0x86/0xb0
[5.434594]  [81463da7] 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel