Latest working kernel version:2.6.29-rc5 Earliest failing kernel version:not tested Distribution:debian lenny Hardware Environment:asus f3jc Software Environment: Problem Description: s2disk hangs before switching to console ("s2disk: Snapshotting system" message ->REISUB) with nvidiafb. Device Drivers -> Graphics support -> Support for frame buffer devices -> [*] nVidia Framebuffer Support dmesg.0 | grep buf [ 1.658735] Console: switching to colour frame buffer device 160x50 [ 1.659929] nvidiafb: PCI nVidia NV1d framebuffer (64MB @ 0xC0000000) [ 1.660386] vesafb: framebuffer at 0xc0000000, mapped to 0xfd180000, using 6144k, total 131072k [ 1.660825] fb1: VESA VGA frame buffer device hangs. Device Drivers -> Graphics support -> Support for frame buffer devices -> [] nVidia Framebuffer Support dmesg | grep buf [ 0.802424] vesafb: framebuffer at 0xc0000000, mapped to 0xf8080000, using 6144k, total 131072k [ 0.862236] Console: switching to colour frame buffer device 128x48 [ 0.922487] fb0: VESA VGA frame buffer device in this case everything works OK.
Created attachment 20255 [details] .config 2.6.29-rc5 without nvidiafb with the attached .config s2disk works OK (nvidia framebuf disabled)
Tested on 2.6.27.14 with nvidiafb. [ 1.651258] Console: switching to colour frame buffer device 160x50 [ 1.652466] nvidiafb: PCI nVidia NV1d framebuffer (64MB @ 0xC0000000) [ 1.652846] vesafb: framebuffer at 0xc0000000, mapped to 0xfd980000, using 6144k, total 131072k [ 1.653320] fb1: VESA VGA frame buffer device s2disk hangs.
Reply-To: akpm@linux-foundation.org (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Sun, 15 Feb 2009 09:41:11 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=12712 > > Summary: s2disk hangs with nvidiafb > Product: Drivers > Version: 2.5 > KernelVersion: 2.6.29-rc5 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: high > Priority: P1 > Component: Video(AGP) > AssignedTo: airlied@linux.ie > ReportedBy: bender.rodriguez@open.by This is an fbdev problem, I guess. I'll reassign the report. > > Latest working kernel version:2.6.29-rc5 > Earliest failing kernel version:not tested I assume what you mean here is that 2.6.29-rc5 fails, and that you're not aware of any earlier kernel version which did not fail. > Distribution:debian lenny > Hardware Environment:asus f3jc > Software Environment: > Problem Description: s2disk hangs before switching to console ("s2disk: > Snapshotting system" message ->REISUB) with nvidiafb. > > Device Drivers -> Graphics support -> Support for frame buffer devices -> [*] > nVidia Framebuffer Support > dmesg.0 | grep buf > [ 1.658735] Console: switching to colour frame buffer device 160x50 > [ 1.659929] nvidiafb: PCI nVidia NV1d framebuffer (64MB @ 0xC0000000) > [ 1.660386] vesafb: framebuffer at 0xc0000000, mapped to 0xfd180000, using > 6144k, total 131072k > [ 1.660825] fb1: VESA VGA frame buffer device > > hangs. > > Device Drivers -> Graphics support -> Support for frame buffer devices -> [] > nVidia Framebuffer Support > > dmesg | grep buf > [ 0.802424] vesafb: framebuffer at 0xc0000000, mapped to 0xf8080000, using > 6144k, total 131072k > [ 0.862236] Console: switching to colour frame buffer device 128x48 > [ 0.922487] fb0: VESA VGA frame buffer device > > in this case everything works OK. >
Sun, 15 Feb 2009 11:17:20 -0800 Andrew Morton <akpm@linux-foundation.org> wrote: Hello. > > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > On Sun, 15 Feb 2009 09:41:11 -0800 (PST) bugme-daemon@bugzilla.kernel.org > wrote: > >> http://bugzilla.kernel.org/show_bug.cgi?id=12712 >> >> Summary: s2disk hangs with nvidiafb >> Product: Drivers >> Version: 2.5 >> KernelVersion: 2.6.29-rc5 >> Platform: All >> OS/Version: Linux >> Tree: Mainline >> Status: NEW >> Severity: high >> Priority: P1 >> Component: Video(AGP) >> AssignedTo: airlied@linux.ie >> ReportedBy: bender.rodriguez@open.by > > This is an fbdev problem, I guess. I'll reassign the report. OK. (This is my first bug-report) > >> >> Latest working kernel version:2.6.29-rc5 >> Earliest failing kernel version:not tested > > I assume what you mean here is that 2.6.29-rc5 fails, and that you're > not aware of any earlier kernel version which did not fail. > I've tested 2.6.27-14, 2.6.29-rc4 (git-5, git-7), 2.6.29-rc5 all of them fails to s2disk with nvidiafb. dmesg | grep buf [ 1.651258] Console: switching to colour frame buffer device 160x50 [ 1.652466] nvidiafb: PCI nVidia NV1d framebuffer (64MB @ 0xC0000000) [ 1.652846] vesafb: framebuffer at 0xc0000000, mapped to 0xfd980000, using 6144k, total 131072k [ 1.653320] fb1: VESA VGA frame buffer device s2disk works ok with: dmesg | grep buf [ 0.802424] vesafb: framebuffer at 0xc0000000, mapped to 0xf8080000, using 6144k, total 131072k [ 0.862236] Console: switching to colour frame buffer device 128x48 [ 0.922487] fb0: VESA VGA frame buffer device you can download my .config here: http://bugzilla.kernel.org/attachment.cgi?id=20255&action=view > >> Distribution:debian lenny >> Hardware Environment:asus f3jc >> Software Environment: >> Problem Description: s2disk hangs before switching to console ("s2disk: >> Snapshotting system" message ->REISUB) with nvidiafb. >> >> Device Drivers -> Graphics support -> Support for frame buffer devices -> >> [*] >> nVidia Framebuffer Support >> dmesg.0 | grep buf >> [ 1.658735] Console: switching to colour frame buffer device 160x50 >> [ 1.659929] nvidiafb: PCI nVidia NV1d framebuffer (64MB @ 0xC0000000) >> [ 1.660386] vesafb: framebuffer at 0xc0000000, mapped to 0xfd180000, >> using >> 6144k, total 131072k >> [ 1.660825] fb1: VESA VGA frame buffer device >> >> hangs. >> >> Device Drivers -> Graphics support -> Support for frame buffer devices -> [] >> nVidia Framebuffer Support >> >> dmesg | grep buf >> [ 0.802424] vesafb: framebuffer at 0xc0000000, mapped to 0xf8080000, >> using >> 6144k, total 131072k >> [ 0.862236] Console: switching to colour frame buffer device 128x48 >> [ 0.922487] fb0: VESA VGA frame buffer device >> >> in this case everything works OK. >> > ---------------------------------------------------- ...
Reply-To: krzysztof.h1@poczta.fm On Sun, 15 Feb 2009 23:11:26 +0200 "Sergei S." <bender.rodriguez@open.by> wrote: > > I've tested > 2.6.27-14, 2.6.29-rc4 (git-5, git-7), 2.6.29-rc5 > > all of them fails to s2disk with nvidiafb. > > dmesg | grep buf > [ 1.651258] Console: switching to colour frame buffer device 160x50 > [ 1.652466] nvidiafb: PCI nVidia NV1d framebuffer (64MB @ 0xC0000000) > [ 1.652846] vesafb: framebuffer at 0xc0000000, mapped to 0xfd980000, using > 6144k, total 131072k > [ 1.653320] fb1: VESA VGA frame buffer device > Interesting, you have two framebuffers running on a single card. Does the s2disk works for you if you select nvidiafb and turn off vesa framebuffer? Can you post the same lines for the latest working kernel with both vesa and nvidia framebuffers selected? Regards, Krzysztof ---------------------------------------------------------------------- Zostan mistrzem parkowania w Bombaju! Zagraj >> http://link.interia.pl/f204e
Mon, 16 Feb 2009 20:59:47 +0100 Krzysztof Helt <krzysztof.h1@poczta.fm> wrote: Hello. > On Sun, 15 Feb 2009 23:11:26 +0200 > "Sergei S." <bender.rodriguez@open.by> wrote: >> >> I've tested >> 2.6.27-14, 2.6.29-rc4 (git-5, git-7), 2.6.29-rc5 >> >> all of them fails to s2disk with nvidiafb. >> >> dmesg | grep buf >> [ 1.651258] Console: switching to colour frame buffer device 160x50 >> [ 1.652466] nvidiafb: PCI nVidia NV1d framebuffer (64MB @ 0xC0000000) >> [ 1.652846] vesafb: framebuffer at 0xc0000000, mapped to 0xfd980000, >> using >> 6144k, total 131072k >> [ 1.653320] fb1: VESA VGA frame buffer device >> > > Interesting, you have two framebuffers running on a single card. Does the > s2disk > works for you if you select nvidiafb and turn off vesa framebuffer? > 2.6.29-rc5 (vesafb, no nvidiafb) dmesg | grep buf [ 0.779860] vesafb: framebuffer at 0xc0000000, mapped to 0xf8080000, using 6144k, total 131072k [ 0.839688] Console: switching to colour frame buffer device 128x48 [ 0.899922] fb0: VESA VGA frame buffer device s2disk works ok. 2.6.29-rc5 (no vesafb, nvidiafb) dmesg | grep buf [ 1.556692] Console: switching to colour frame buffer device 160x50 [ 1.558905] nvidiafb: PCI nVidia NV1d framebuffer (64MB @ 0xC0000000) s2disk doesn't work with nvidiafb. > Can you post the same lines for the latest working kernel with both vesa and > nvidia > framebuffers selected? > Sure. [!!!Copy-paste from prev. posts] working kernel with vesafb and nvidifb selected (s2disk fails). 2.6.29-rc5 dmesg | grep buf [ 1.658735] Console: switching to colour frame buffer device 160x50 [ 1.659929] nvidiafb: PCI nVidia NV1d framebuffer (64MB @ 0xC0000000) [ 1.660386] vesafb: framebuffer at 0xc0000000, mapped to 0xfd180000, using 6144k, total 131072k [ 1.660825] fb1: VESA VGA frame buffer device 2.6.27-14 dmesg | grep buf [ 1.651258] Console: switching to colour frame buffer device 160x50 [ 1.652466] nvidiafb: PCI nVidia NV1d framebuffer (64MB @ 0xC0000000) [ 1.652846] vesafb: framebuffer at 0xc0000000, mapped to 0xfd980000, using 6144k, total 131072k [ 1.653320] fb1: VESA VGA frame buffer device [!!] current build (2.6.29-rc5 vesafb, nvidiafb) dmesg | grep buf [ 0.944049] Console: switching to colour frame buffer device 160x50 [ 0.945233] nvidiafb: PCI nVidia NV1d framebuffer (64MB @ 0xC0000000) [ 0.945675] vesafb: framebuffer at 0xc0000000, mapped to 0xfd180000, using 6144k, total 131072k [ 0.946119] fb1: VESA VGA frame buffer device s2disk fails. Regards, Sergey > Regards, > Krzysztof > > > ---------------------------------------------------------------------- > Zostan mistrzem parkowania w Bombaju! > Zagraj >> http://link.interia.pl/f204e > ---------------------------------------------------- ...
Mon, 16 Feb 2009 20:59:47 +0100 Krzysztof Helt <krzysztof.h1@poczta.fm> wrote: > Interesting, you have two framebuffers running on a single card. Does the > s2disk > works for you if you select nvidiafb and turn off vesa framebuffer? > Hello. Let's see dmesg: [ 1.502011] nvidiafb: CRTC 0 is currently programmed for DFP [ 1.502022] nvidiafb: Using DFP on CRTC 0 [ 1.502031] nvidiafb: Panel size is 1280 x 800 [ 1.502040] nvidiafb: Panel is LVDS [ 1.505580] nvidiafb: MTRR set to ON [ 1.505599] fbcvt: 1280x800@60: CVT Name - 1.024MA-R [ 1.505856] fbcon: NV1d (fb0) is primary device [ 1.657379] nvidiafb: Flat panel dithering disabled [ 1.658735] Console: switching to colour frame buffer device 160x50 [ 1.659929] nvidiafb: PCI nVidia NV1d framebuffer (64MB @ 0xC0000000) [ 1.660099] vesafb: cannot reserve video memory at 0xc0000000 [ 1.660386] vesafb: framebuffer at 0xc0000000, mapped to 0xfd180000, using 6144k, total 131072k [ 1.660419] vesafb: mode is 1024x768x32, linelength=4096, pages=1 [ 1.660445] vesafb: protected mode interface info at c000:d5d0 [ 1.660471] vesafb: pmi: set display start = c00cd606, set palette = c00cd670 [ 1.660498] vesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da [ 1.660714] vesafb: scrolling: redraw [ 1.660734] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0 [ 1.660825] fb1: VESA VGA frame buffer device The problem ("two framebuffers running on a single card") is at drivers/video/vesafb.c static int __init vesafb_probe(struct platform_device *dev) vesafb ignores allocation failure at 0xc0000000. 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 */ } So, my proposal is something like this: 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 */ /*NOTE : discuss*/ if(num_registered_fb) { printk(KERN_ERR "vesafb: abort, cannot reserve video memory at 0x%lx. registered framebuffers count %d\n", vesafb_fix.smem_start, num_registered_fb); return -EBUSY; } } num_registered_fb is declared in fbmem.c Is that acceptable solution? I can't make all tests, since I have PC with single video card. 2.6.29-rc5-git3 dmesg with vesafb and nvidiafb: [ 1.492009] nvidiafb: CRTC 0 is currently programmed for DFP [ 1.492020] nvidiafb: Using DFP on CRTC 0 [ 1.492029] nvidiafb: Panel size is 1280 x 800 [ 1.492038] nvidiafb: Panel is LVDS [ 1.495566] nvidiafb: MTRR set to ON [ 1.495585] fbcvt: 1280x800@60: CVT Name - 1.024MA-R [ 1.495838] fbcon: NV1d (fb0) is primary device [ 1.647295] nvidiafb: Flat panel dithering disabled [ 1.648649] Console: switching to colour frame buffer device 160x50 [ 1.649847] nvidiafb: PCI nVidia NV1d framebuffer (64MB @ 0xC0000000) [ 1.650028] vesafb: cannot reserve video memory at 0xc0000000 [ 1.650054] vesafb: abort, cannot reserve video memory at 0xc0000000. registered framebuffers count 1 [ 1.650092] vesafb: probe of vesafb.0 failed with error -16 s2disk still fails (it works OK without nvidiafb). System just hangs before switching to console. I'll try to figure out. dmesg with vesafb only: [ 0.769928] vesafb: framebuffer at 0xc0000000, mapped to 0xf8080000, using 6144k, total 131072k [ 0.769946] vesafb: mode is 1024x768x32, linelength=4096, pages=1 [ 0.769957] vesafb: protected mode interface info at c000:d5d0 [ 0.769968] vesafb: pmi: set display start = c00cd606, set palette = c00cd670 [ 0.769980] vesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da [ 0.770013] vesafb: scrolling: redraw [ 0.770021] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0 [ 0.829735] Console: switching to colour frame buffer device 128x48 [ 0.889953] fb0: VESA VGA frame buffer device s2disk - OK. Best regards, Sergey ---------------------------------------------------- ...
Mon, 16 Feb 2009 20:59:47 +0100 Krzysztof Helt <krzysztof.h1@poczta.fm> wrote: > Interesting, you have two framebuffers running on a single card. Does the > s2disk > works for you if you select nvidiafb and turn off vesa framebuffer? Hello. Let's see dmesg: [ 1.502011] nvidiafb: CRTC 0 is currently programmed for DFP [ 1.502022] nvidiafb: Using DFP on CRTC 0 [ 1.502031] nvidiafb: Panel size is 1280 x 800 [ 1.502040] nvidiafb: Panel is LVDS [ 1.505580] nvidiafb: MTRR set to ON [ 1.505599] fbcvt: 1280x800@60: CVT Name - 1.024MA-R [ 1.505856] fbcon: NV1d (fb0) is primary device [ 1.657379] nvidiafb: Flat panel dithering disabled [ 1.658735] Console: switching to colour frame buffer device 160x50 [ 1.659929] nvidiafb: PCI nVidia NV1d framebuffer (64MB @ 0xC0000000) [ 1.660099] vesafb: cannot reserve video memory at 0xc0000000 [ 1.660386] vesafb: framebuffer at 0xc0000000, mapped to 0xfd180000, using 6144k, total 131072k [ 1.660419] vesafb: mode is 1024x768x32, linelength=4096, pages=1 [ 1.660445] vesafb: protected mode interface info at c000:d5d0 [ 1.660471] vesafb: pmi: set display start = c00cd606, set palette = c00cd670 [ 1.660498] vesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da [ 1.660714] vesafb: scrolling: redraw [ 1.660734] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0 [ 1.660825] fb1: VESA VGA frame buffer device The problem ("two framebuffers running on a single card") is at drivers/video/vesafb.c static int __init vesafb_probe(struct platform_device *dev) vesafb ignores allocation failure at 0xc0000000. 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 */ } So, my proposal is something like this: 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 */ /*NOTE : discuss*/ if(num_registered_fb) { printk(KERN_ERR "vesafb: abort, cannot reserve video memory at 0x%lx. registered framebuffers count %d\n", vesafb_fix.smem_start, num_registered_fb); return -EBUSY; } } num_registered_fb is declared in fbmem.c Is that acceptable solution? I can't make all tests, since I have PC with single video card. 2.6.29-rc5-git3 dmesg with vesafb and nvidiafb: [ 1.492009] nvidiafb: CRTC 0 is currently programmed for DFP [ 1.492020] nvidiafb: Using DFP on CRTC 0 [ 1.492029] nvidiafb: Panel size is 1280 x 800 [ 1.492038] nvidiafb: Panel is LVDS [ 1.495566] nvidiafb: MTRR set to ON [ 1.495585] fbcvt: 1280x800@60: CVT Name - 1.024MA-R [ 1.495838] fbcon: NV1d (fb0) is primary device [ 1.647295] nvidiafb: Flat panel dithering disabled [ 1.648649] Console: switching to colour frame buffer device 160x50 [ 1.649847] nvidiafb: PCI nVidia NV1d framebuffer (64MB @ 0xC0000000) [ 1.650028] vesafb: cannot reserve video memory at 0xc0000000 [ 1.650054] vesafb: abort, cannot reserve video memory at 0xc0000000. registered framebuffers count 1 [ 1.650092] vesafb: probe of vesafb.0 failed with error -16 s2disk still fails (it works OK without nvidiafb). System just hangs before switching to console. I'll try to figure out. dmesg with vesafb only: [ 0.769928] vesafb: framebuffer at 0xc0000000, mapped to 0xf8080000, using 6144k, total 131072k [ 0.769946] vesafb: mode is 1024x768x32, linelength=4096, pages=1 [ 0.769957] vesafb: protected mode interface info at c000:d5d0 [ 0.769968] vesafb: pmi: set display start = c00cd606, set palette = c00cd670 [ 0.769980] vesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da [ 0.770013] vesafb: scrolling: redraw [ 0.770021] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0 [ 0.829735] Console: switching to colour frame buffer device 128x48 [ 0.889953] fb0: VESA VGA frame buffer device s2disk - OK. Best regards, Sergey p.s. Sorry for responding via the bugzilla web interface, simply have no messages from bugme-daemon@bugzilla.kernel.org on the server.
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? ---------------------------------------------------- ...
Reply-To: krzysztof.h1@poczta.fm 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? 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. 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. This is probably not a regression - you can check if your older kernel works with only the nvidiafb selected. 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. Kind regards, Krzysztof ---------------------------------------------------------------------- Strzelec, Byk, a moze Panna? Wszystkich 12 znakow zodiaku! Sprawd
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
Hello. Sorry, I've been a bit busy. So, back to the s2disk problem. For 2.6.29-rc6-git1 strace s2disk shows: ------------------------------------------------------ execve("/usr/sbin/s2disk", ["s2disk"], [/* 37 vars */]) = 0 brk(0) = 0x8e9f000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fad000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=77137, ...}) = 0 mmap2(NULL, 77137, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f9a000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/liblzo2.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320#\0\0004\0\0\0\24"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=124924, ...}) = 0 mmap2(NULL, 127840, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7f7a000 mmap2(0xb7f99000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e) = 0xb7f99000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libgcrypt.so.11", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240D\0\0004\0\0\0\314"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=425220, ...}) = 0 mmap2(NULL, 424676, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7f12000 mmap2(0xb7f78000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x66) = 0xb7f78000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libsplashy.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\17\0\0004\0\0\0004"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=18716, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f11000 mmap2(NULL, 21828, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7f0b000 mmap2(0xb7f10000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4) = 0xb7f10000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libgcc_s.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\34\0\0004\0\0\0\254"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=50916, ...}) = 0 mmap2(NULL, 49928, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7efe000 mmap2(0xb7f0a000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xc) = 0xb7f0a000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/i686/cmov/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260e\1\0004\0\0\0\4"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1413540, ...}) = 0 mmap2(NULL, 1418864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7da3000 mmap2(0xb7ef8000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x155) = 0xb7ef8000 mmap2(0xb7efb000, 9840, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7efb000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libgpg-error.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\6\0\0004\0\0\0\214"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=11556, ...}) = 0 mmap2(NULL, 14568, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7d9f000 mmap2(0xb7da2000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0xb7da2000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libglib-2.0.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\25\1\0004\0\0\0\24"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=736588, ...}) = 0 mmap2(NULL, 740420, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7cea000 mmap2(0xb7d9e000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xb3) = 0xb7d9e000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libsplashycnf.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \v\0\0004\0\0\0P"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=7696, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ce9000 mmap2(NULL, 10684, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ce6000 mmap2(0xb7ce8000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7ce8000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libdirectfb-1.0.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\274\0\0004\0\0\0\314"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=421300, ...}) = 0 mmap2(NULL, 421540, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7c7f000 mmap2(0xb7ce4000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x65) = 0xb7ce4000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libpcre.so.3", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\17\0\0004\0\0\0@"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=162088, ...}) = 0 mmap2(NULL, 164984, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7c56000 mmap2(0xb7c7e000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x27) = 0xb7c7e000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libdirect-1.0.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\2602\0\0004\0\0\0t"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=76932, ...}) = 0 mmap2(NULL, 81836, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7c42000 mmap2(0xb7c55000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12) = 0xb7c55000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libfusion-1.0.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20$\0\0004\0\0\0\370"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=28344, ...}) = 0 mmap2(NULL, 31328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7c3a000 mmap2(0xb7c41000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0xb7c41000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/i686/cmov/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\n\0\0004\0\0\0H"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=9680, ...}) = 0 mmap2(NULL, 12412, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7c36000 mmap2(0xb7c38000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7c38000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/i686/cmov/libpthread.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000H\0\0004\0\0\0\330"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=116414, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c35000 mmap2(NULL, 98784, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7c1c000 mmap2(0xb7c31000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14) = 0xb7c31000 mmap2(0xb7c33000, 4576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7c33000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c1b000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7c1b6b0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0xb7ef8000, 4096, PROT_READ) = 0 munmap(0xb7f9a000, 77137) = 0 set_tid_address(0xb7c1b6f8) = 3293 set_robust_list(0xb7c1b700, 0xc) = 0 futex(0xbfcc9770, FUTEX_WAKE_PRIVATE, 1) = 0 rt_sigaction(SIGRTMIN, {0xb7c202e0, [], SA_SIGINFO}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0xb7c20720, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 uname({sys="Linux", node="swordfish", ...}) = 0 brk(0) = 0x8e9f000 brk(0x8ec0000) = 0x8ec0000 open("/dev/null", O_RDWR) = 3 close(3) = 0 stat64("/etc/uswsusp.conf", {st_mode=S_IFREG|0644, st_size=204, ...}) = 0 open("/etc/uswsusp.conf", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=204, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fac000 read(3, "# /etc/uswsusp.conf(8) -- Configu"..., 4096) = 204 read(3, ""..., 4096) = 0 close(3) = 0 munmap(0xb7fac000, 4096) = 0 mmap2(NULL, 212992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7be7000 mlockall(MCL_CURRENT|MCL_FUTURE) = 0 mount("none", "/proc/3293", "tmpfs", 0, NULL) = 0 stat64("/dev/sda5", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 5), ...}) = 0 chdir("/proc/3293") = 0 mknod("resume", S_IFBLK|0600, makedev(8, 5)) = 0 open("resume", O_RDWR) = 3 stat64("/dev/snapshot", {st_mode=S_IFCHR|0660, st_rdev=makedev(10, 231), ...}) = 0 open("/dev/snapshot", O_RDONLY) = 4 ioctl(4, 0x400c330d, 0xbfcc9714) = 0 open("/dev/console", O_RDONLY) = 5 ioctl(5, KDGKBTYPE, 0xbfcc9748) = 0 ioctl(5, TIOCLINUX, 0xbfcc9766) = 0 ioctl(5, VT_GETSTATE, 0xbfcc973e) = 0 ioctl(5, VIDIOC_QUERYCAP or VT_OPENQRY, 0xbfcc9744) = 0 close(5) = 0 open("/dev/tty8", O_RDWR) = 5 ioctl(5, VIDIOC_G_COMP or VT_ACTIVATE, 0x8) = 0 ioctl(5, VIDIOC_S_COMP or VT_WAITACTIVE drivers/char/vt_ioctl.c int vt_ioctl(struct tty_struct *tty, struct file * file, unsigned int cmd, unsigned long arg) ... case VT_WAITACTIVE: if (!perm) goto eperm; if (arg == 0 || arg > MAX_NR_CONSOLES) ret = -ENXIO; else ret = vt_waitactive(arg - 1); break; "Never" returns: int vt_waitactive(int vt) { int retval; DECLARE_WAITQUEUE(wait, current); add_wait_queue(&vt_activate_queue, &wait); for (;;) { retval = 0; /* * Synchronize with redraw_screen(). By acquiring the console * semaphore we make sure that the console switch is completed * before we return. If we didn't wait for the semaphore, we * could return at a point where fg_console has already been * updated, but the console switch hasn't been completed. */ acquire_console_sem(); set_current_state(TASK_INTERRUPTIBLE); if (vt == fg_console) { release_console_sem(); break; } release_console_sem(); retval = -ERESTARTNOHAND; if (signal_pending(current)) break; schedule(); ^^^^^^^^^^^ } remove_wait_queue(&vt_activate_queue, &wait); __set_current_state(TASK_RUNNING); return retval; } Best regards, Sergey.
Hello, bug seems to be "distr"/"user space app" specific, as it's not reproducible on my Arch Linux (and reproducible on Debian 5). Happy New Year! Sergey