diff mbox

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

Message ID CANq1E4QLCp4xzGsgceuGgX-k7JpiA_ayJy3e0iYoWAMAsc7fCA@mail.gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

David Herrmann Sept. 8, 2013, 12:13 a.m. UTC
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

Comments

Tom Gundersen Sept. 8, 2013, 9:38 a.m. UTC | #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;
David Herrmann Oct. 2, 2013, 3 p.m. UTC | #2
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
diff mbox

Patch

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;