Re: [Bugme-new] [Bug 12712] New: s2disk hangs with nvidiafb

["Bender aka Sergei S." <bender.rodriguez@open.by>]

On Sunday, February 22, 2009, 4:05:04 PM, Krzysztof wrote:

> On Sun, 22 Feb 2009 12:47:11 +0200
> "Sergei S." <bender.rodriguez@open.by> wrote:

>> Hello.
>> 
>> By the way.
>> 
>> [drivers/video/vesafb.c
>> static int __init vesafb_probe(struct platform_device *dev)]
>> 
>>       if (!request_mem_region(vesafb_fix.smem_start, size_total, "vesafb")) {
>>               printk(KERN_WARNING
>>                      "vesafb: cannot reserve video memory at 0x%lx\n",
>>                       vesafb_fix.smem_start);
>>               /* We cannot make this fatal. Sometimes this comes from magic
>>                  spaces our resource handlers simply don't know about */
>>       }
>> 
>> Is there any reason not to make vesafb request_mem_region fail fatal?
>> 
>> In case we already have framebuffer at 0xc0000000 and framebuffer_alloc failed -
>> we'll release non-vesafb memory region.
>> 
>>       info = framebuffer_alloc(sizeof(u32) * 256, &dev->dev);
>>       if (!info) {
>>               release_mem_region(vesafb_fix.smem_start, size_total);
>>               return -ENOMEM;
>>       }
>> 
>> 
>> So, what do you think about the idea to check num_registered_fb when request_mem_region 
>> fails?


Hello.

> I am not sure. Each request is done by a driver and it is assigned to it. Someone
> with more knowledge should clear this doubts. I suppose if a driver does not
>  request a resource releasing it should be void.

I think we should do some work at request_mem_region instead of simple
printk KERN_WARNING (I may be wrong).


And what about:
> In case we already have framebuffer at 0xc0000000 and framebuffer_alloc failed -
> we'll release non-vesafb memory region.
>
>       info = framebuffer_alloc(sizeof(u32) * 256, &dev->dev);
>       if (!info) {
>               release_mem_region(vesafb_fix.smem_start, size_total);
>               return -ENOMEM;
>       }

IMHO at least we should have some bit showing that
request_mem_region(vesafb_fix.smem_start, size_total, "vesafb")
was successful. Just to call release_mem_region is not correct since
we can release nvidiafb's (etc.) memory region.


> Your case is more simple - nvidiafb does not suspend/resume correctly. This
> is easy to check - if only the nvidiafb is selected the s2disk does not work.

Well, it's not so simple, I guess. Looks like s2disk works with
nvidiafb built with "Lots of debug messages" and doesn't work
otherwise.

Before hibernation we create virtual console and make switch to it (am
I right?). I'm not sure, but it seems I have problems in switching to
virtual console (or even earlier).
I'll try to figure out.


> This is probably not a regression - you can check if your older kernel
> works with only the nvidiafb selected.
I've tested 2.6.27.11. It seems a bit senseless to test kernels earlier than 2.6.27
(it can be difficult to find out the problem).


> Unfortunately, I have no card to reproduce this and I don't know what
> is wrong with the nvidiafb suspend/resume functions.

> I hope someone will help you.

Thanks.


Best regards,
Sergey


> Kind regards,
> Krzysztof


------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H