2.6.12-rc1-mm2 -- nvidiafb driver gives black screen
A message that is not in the archive (sent off-list or not yet received): [email protected]
(Added the mailing list - trust that's ok)
Quoted 11 lines · Miles Lane
Kernel command line: BOOT_IMAGE=Linux ro root=306 video=nvidiafb init=/etc/init lang=us apm=power-off nomce
nvidiafb: nVidia device/chipset 10DE0312
nvidiafb: nVidia Corporation NV31 [GeForce FX 5600]
nvidiafb: CRTC0 found
nvidiafb: CRTC1 not found
nvidiafb: EDID found from BUS1
nvidiafb: CRTC 0 appears to have a CRT attached
nvidiafb: Using CRT on CRTC 0
Quoted 4 lines
Quoted 1 line
Quoted 1 line
I am wondering whether the following two lines point to the problem.
allocation failed: out of vmalloc space - use vmalloc=<size> to increase size.
nvidiafb: cannot ioremap FB base
Quite possibly.
I'll do rc2-mm3 tonight - please test that. It has fixes.
Quoted 9 lines
CONFIG_AGP_NVIDIA=yCONFIG_I2C=yCONFIG_I2C_CHARDEV=mCONFIG_I2C_ALGOBIT=yCONFIG_I2C_ALGOPCF=mCONFIG_I2C_ALGOPCA=mCONFIG_I2C_ISA=mCONFIG_I2C_NFORCE2=m
Quoted 11 lines
CONFIG_FB=yCONFIG_FB_CFB_FILLRECT=yCONFIG_FB_CFB_COPYAREA=yCONFIG_FB_CFB_IMAGEBLIT=yCONFIG_FB_SOFT_CURSOR=yCONFIG_FB_MODE_HELPERS=yCONFIG_FB_TILEBLITTING=yCONFIG_VIDEO_SELECT=yCONFIG_FB_NVIDIA=yCONFIG_FB_NVIDIA_I2C=yCONFIG_FRAMEBUFFER_CONSOLE=y
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Quoted 15 lines · Andrew Morton
(Added the mailing list - trust that's ok)
Quoted 11 lines · Miles Lane
Kernel command line: BOOT_IMAGE=Linux ro root=306 video=nvidiafb init=/etc/init lang=us apm=power-off nomce
nvidiafb: nVidia device/chipset 10DE0312
nvidiafb: nVidia Corporation NV31 [GeForce FX 5600]
nvidiafb: CRTC0 found
nvidiafb: CRTC1 not found
nvidiafb: EDID found from BUS1
nvidiafb: CRTC 0 appears to have a CRT attached
nvidiafb: Using CRT on CRTC 0
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
I am wondering whether the following two lines point to the problem.
allocation failed: out of vmalloc space - use vmalloc=<size> to increase size.
nvidiafb: cannot ioremap FB baseQuite possibly.
I'll do rc2-mm3 tonight - please test that. It has fixes.
Hello Andrew,
mm3 did not fix the problem. I still get a blank framebuffer console. I still get these two errors:
allocation failed: out of vmalloc space - use vmalloc=<size> to increase size.
nvidiafb: cannot ioremap FB base
Also, I still get the /sys listing Oops when listing the i2c entries for the nvidiafb.
Lastly, I get the Oops that halts booting if I include certain other i2c drivers in the build.
Removing nvidiafb from the build allows me to get a completely usable build of 2.6.12-rc1-mm3.
I haven't heard anything from the author of the nvidiafb driver about the various issues I have reported.
Thanks,
Miles
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Quoted 40 lines · Miles Lane
Quoted 15 lines · Andrew Morton
(Added the mailing list - trust that's ok)
Quoted 11 lines · Miles Lane
Kernel command line: BOOT_IMAGE=Linux ro root=306 video=nvidiafb init=/etc/init lang=us apm=power-off nomce
nvidiafb: nVidia device/chipset 10DE0312
nvidiafb: nVidia Corporation NV31 [GeForce FX 5600]
nvidiafb: CRTC0 found
nvidiafb: CRTC1 not found
nvidiafb: EDID found from BUS1
nvidiafb: CRTC 0 appears to have a CRT attached
nvidiafb: Using CRT on CRTC 0Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
I am wondering whether the following two lines point to the problem.
allocation failed: out of vmalloc space - use vmalloc=<size> to increase size.
nvidiafb: cannot ioremap FB baseQuite possibly.
I'll do rc2-mm3 tonight - please test that. It has fixes.
Hello Andrew,
mm3 did not fix the problem. I still get a blank framebuffer console. I still get these two errors:
allocation failed: out of vmalloc space - use vmalloc=<size> to increase size.
nvidiafb: cannot ioremap FB base
Also, I still get the /sys listing Oops when listing the i2c entries for the nvidiafb.
Lastly, I get the Oops that halts booting if I include certain other i2c drivers in the build.
Removing nvidiafb from the build allows me to get a completely usable build of 2.6.12-rc1-mm3.
Quoted 2 lines
I haven't heard anything from the author of the nvidiafb driver about the various issues I have reported.
I guess that there is some chance that the io_remap_pfn* patches
are involved with this. Is there some way to determine exactly which
io remap kernel calls are involved in "nvidiafb: cannot ioremap FB base" ? Is that in the exposed source code? If so, where is that source code? If not, can we determine from the binary which calls
are being made? Or should I just make a io_remap debug patch that
prints out lots of debug info so that we can track this down?
Signature · 8 lines
~Randy ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
I am looking forward to having something to test. Please keep me posted.
Miles
-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
Quoted 3 lines · Miles Lane
I am looking forward to having something to test. Please keep me posted.
Miles
Well, you didn't answer any of my questions..... :(
and you dropped akpm from the cc: list, which is a nono.
I'll make some debug patch, but it would help if you answered my questions.
Signature · 8 lines
~Randy ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
On Mon, 28 Mar 2005 09:12:49 -0800, Randy.Dunlap <[email protected]> wrote:
By the why, I don't know why Andrew got dropped from my previous message list. Also, I thought you were asking these questions of the fbdev and vidiafb developers.
Quoted 2 lines
I guess that there is some chance that the io_remap_pfn* patches are involved with this.
I am a tester, so I don't have knowledge about this.
Quoted 3 lines
Is there some way to determine exactly which
io remap kernel calls are involved in "nvidiafb: cannot ioremap FB base" ?
I don't know. Someone who does, please tell me. If someone will tell me how, I'll be happy to gather the information.
Quoted 1 line
Is that in the exposed source code?
I have no idea. How would I find out?
Quoted 1 line
If so, where is that source code?
I have no clue.
Quoted 2 lines
If not, can we determine from the binary which calls are being made?
Uhhh. I have delivered the Oops info and a bunch of other information. I have given you whatever I thought might be helpful. I need guidance here.
Quoted 2 lines
Or should I just make a
io_remapdebug patch that prints out lots of debug info so that we can track this down?
I thought you would determine this with input from developers.
Your humble tester (remember me from the early USB days?),
Miles
-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
Quoted 7 lines · Miles Lane
On Mon, 28 Mar 2005 09:12:49 -0800, Randy.Dunlap <[email protected]> wrote:
By the why, I don't know why Andrew got dropped from my previous message list. Also, I thought you were asking these questions of the fbdev and vidiafb developers.
Quoted 5 lines
Quoted 2 lines
I guess that there is some chance that the io_remap_pfn* patches are involved with this.
I am a tester, so I don't have knowledge about this.
Sure, it wasn't a question. :)
Quoted 13 lines
Quoted 4 lines
Is there some way to determine exactly which
io remap kernel calls are involved in "nvidiafb: cannot ioremap FB base" ?I don't know. Someone who does, please tell me. If someone will tell me how, I'll be happy to gather the information.
Quoted 1 line
Is that in the exposed source code?
Quoted 6 lines
I have no idea. How would I find out?
Quoted 1 line
If so, where is that source code?
I have no clue.
Where did you get the nvidia wrapper?
Where can I find it?
Where did you get the nvidia binary blob?
Where can I get it?
Quoted 7 lines
Quoted 2 lines
If not, can we determine from the binary which calls are being made?
Uhhh. I have delivered the Oops info and a bunch of other information. I have given you whatever I thought might be helpful. I need guidance here.
Sure, but the part that I really need to see is likely partially hidden in some binary blob. We'll see.
Quoted 8 lines
Quoted 3 lines
Or should I just make a
io_remapdebug patch that prints out lots of debug info so that we can track this down?I thought you would determine this with input from developers.
Your humble tester (remember me from the early USB days?),
Sure I do. :)
I'll make a patch, probably tonight Pacific time.
Signature · 8 lines
~Randy ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Quoted 31 lines · Randy.Dunlap
Quoted 7 lines · Miles Lane
On Mon, 28 Mar 2005 09:12:49 -0800, Randy.Dunlap <[email protected]> wrote:
By the why, I don't know why Andrew got dropped from my previous message list. Also, I thought you were asking these questions of the fbdev and vidiafb developers.
Quoted 5 lines
Quoted 2 lines
I guess that there is some chance that the io_remap_pfn* patches are involved with this.
I am a tester, so I don't have knowledge about this.
Sure, it wasn't a question. :)
Quoted 15 lines
Quoted 4 lines
Is there some way to determine exactly which
io remap kernel calls are involved in "nvidiafb: cannot ioremap FB base" ?I don't know. Someone who does, please tell me. If someone will tell me how, I'll be happy to gather the information.
Quoted 1 line
Is that in the exposed source code?
I have no idea. How would I find out?
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
If so, where is that source code?
I have no clue.
Where did you get the nvidia wrapper?
Where can I find it?
Perhaps you are thinking I am using the NVidia binary driver? This is not the case. nvidiafb is a recently added framebuffer driver (IIRC, first showing up in 2.6.12-rc1-mm2). I believe [email protected] is the author. I have reproduced this problem with both mm2 and mm3.
Do you need my .config file?
Quoted 1 line
Where did you get the nvidia binary blob?
If you had my .config file, couldn't you build the driver into the kernel, as I have? I don't know what a driver blob is. I haven't built the driver as a module.
Quoted 1 line
Where can I get it?
Build it?
Quoted 10 lines
Quoted 7 lines
Quoted 2 lines
If not, can we determine from the binary which calls are being made?
Uhhh. I have delivered the Oops info and a bunch of other information. I have given you whatever I thought might be helpful. I need guidance here.
Sure, but the part that I really need to see is likely partially hidden in some binary blob. We'll see.
Blob? Well, I have some i2c built as modules.
Quoted 4 lines
Quoted 1 line
Your humble tester (remember me from the early USB days?),
Sure I do. :)
I'll make a patch, probably tonight Pacific time.
Great!
Miles
-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
Quoted 46 lines · Miles Lane
Quoted 35 lines · Randy.Dunlap
Quoted 8 lines · Miles Lane
On Mon, 28 Mar 2005 09:12:49 -0800, Randy.Dunlap <[email protected]> wrote:
By the why, I don't know why Andrew got dropped from my previous message list. Also, I thought you were asking these questions of the fbdev and vidiafb developers.
Quoted 5 lines
Quoted 2 lines
I guess that there is some chance that the io_remap_pfn* patches are involved with this.
I am a tester, so I don't have knowledge about this.
Sure, it wasn't a question. :)
Quoted 16 lines
Quoted 3 lines
Is there some way to determine exactly which
io remap kernel calls are involved in "nvidiafb: cannot ioremap FB base" ?I don't know. Someone who does, please tell me. If someone will tell me how, I'll be happy to gather the information.
Quoted 1 line
Is that in the exposed source code?
I have no idea. How would I find out?
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
If so, where is that source code?
I have no clue.
Where did you get the nvidia wrapper?
Where can I find it?
Quoted 6 lines
Perhaps you are thinking I am using the NVidia binary driver?
This is not the case. nvidiafb is a recently added framebuffer
driver (IIRC, first showing up in 2.6.12-rc1-mm2). I believe [email protected] is the author. I have reproduced this problem with both mm2 and mm3.Do you need my .config file?
I'll let you know.
I wondered while driving home if you were using the (new) in-kernel nv driver. Thanks for you and Andrew confirming that. Looks like I didn't go back far enough in the thread history.
Quoted 23 lines
Quoted 2 lines
Where did you get the nvidia binary blob?
If you had my .config file, couldn't you build the driver into the kernel, as I have? I don't know what a driver blob is. I haven't built the driver as a module.
Quoted 1 line
Where can I get it?
Build it?
Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
If not, can we determine from the binary which calls are being made?
Uhhh. I have delivered the Oops info and a bunch of other information. I have given you whatever I thought might be helpful. I need guidance here.
Quoted 11 lines
Quoted 2 lines
Sure, but the part that I really need to see is likely partially hidden in some binary blob. We'll see.
Blob? Well, I have some i2c built as modules.
Quoted 4 lines
Quoted 1 line
Your humble tester (remember me from the early USB days?),
Sure I do. :)
I'll make a patch, probably tonight Pacific time.
I send you something later tonight.
Signature · 8 lines
~Randy ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Hi gentle folks,
Quoted 4 lines
Perhaps you are thinking I am using the NVidia binary driver? This is not the case. nvidiafb is a recently added framebuffer driver (IIRC, first showing up in 2.6.12-rc1-mm2). I believe [email protected] is the author.
I am not! Antonino Daplas is. Adding him to the CC list, although I guess he reads linux-fbdev-devel.
The only part I can help with is the i2c stuff, which caused trouble already, but so far I couldn't find anything relevant. The nvidiafb driver is quite new, and it's natural that it needs some debugging. I suspect that the driver has some severe problem with the way it handles resources, as was suggested by our previous (failed) attempts to debug it. I'd be happy to help with the debugging but unfortunately (no quite so) I don't have any nvidia device in my machines anymore.
Somewhere else in this thread, Randy suggested that some __devinit stuff wasn't really. I think it would be worth investigating this first, and make sure that nothing is incorrectly tagged. The oops reported by Miles sounded like large memory chunks had been freed when they shouldn't have. I think I understand that erroneously tagging things __init might lead to that kind of trouble. But maybe it's a completely different problem, I'm really only suggesting this because I don't get what's going on either.
Thanks,
--
Jean Delvare
-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
Quoted 11 lines · Randy.Dunlap
Quoted 5 lines
Quoted 2 lines
If so, where is that source code?
I have no clue.
Where did you get the nvidia wrapper?
Where can I find it?Where did you get the nvidia binary blob?
Where can I get it?
Miles is using drivers/video/nvidia/nvidiafb.o
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Here is some of the background on this problem:
http://marc.theaimsgroup.com/?l=linux-kernel&m=111076667232062&w=2
http://marc.theaimsgroup.com/?t=111172432600001&r=1&w=4
http://marc.theaimsgroup.com/?l=linux-kernel&m=111145286407616&w=2
-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
Quoted 17 lines · Miles Lane
Quoted 15 lines · Andrew Morton
(Added the mailing list - trust that's ok)
Quoted 11 lines · Miles Lane
Kernel command line: BOOT_IMAGE=Linux ro root=306 video=nvidiafb init=/etc/init lang=us apm=power-off nomce
nvidiafb: nVidia device/chipset 10DE0312
nvidiafb: nVidia Corporation NV31 [GeForce FX 5600]
nvidiafb: CRTC0 found
nvidiafb: CRTC1 not found
nvidiafb: EDID found from BUS1
nvidiafb: CRTC 0 appears to have a CRT attached
nvidiafb: Using CRT on CRTC 0
Quoted 6 lines
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
I am wondering whether the following two lines point to the problem.
allocation failed: out of vmalloc space - use vmalloc=<size> to increase size.
nvidiafb: cannot ioremap FB baseQuite possibly.
Sure, without the FB memory, video won't show up.
And the 2 lines are directly related -- same error printed from 2 different places.
Quoted 16 lines
Quoted 1 line
I'll do rc2-mm3 tonight - please test that. It has fixes.
Hello Andrew,
mm3 did not fix the problem. I still get a blank framebuffer console. I still get these two errors:
allocation failed: out of vmalloc space - use vmalloc=<size> to increase size.
nvidiafb: cannot ioremap FB base
Also, I still get the /sys listing Oops when listing the i2c entries for the nvidiafb.
Lastly, I get the Oops that halts booting if I include certain other i2c drivers in the build.
Removing nvidiafb from the build allows me to get a completely usable build of 2.6.12-rc1-mm3.
Quoted 2 lines
I haven't heard anything from the author of the nvidiafb driver about the various issues I have reported.
Here's a tiny patch to get started. Hopefully it will show us why ioremap is failing...
Another issue while looking at this code:
there is some __initdata in nvidia.c that should be __devinitdata (deja vu)
Miles, after using this patch, please also test by booting with "vmalloc=512M" (or "vmalloc=256M" if you don't have 512 MB to spare).
Signature · 1 line
~Randy
linux-2612-rc1-mm3
Add a little debug printk to try to find out why ioremap fails.
diffstat:=
drivers/video/nvidia/nvidia.c | 2 ++ 1 files changed, 2 insertions(+)
drivers/video/nvidia/nvidia.c renamed from drivers/video/nvidia/nvidia.c~nv_test_remap +2 -0
@@ -1511,6 +1511,8 @@ static int __devinit nvidiafb_probe(stru par->ScratchBufferSize = (par->Architecture <NV_ARCH_10 ) ?8 *1024 :16 *1024 ; par->ScratchBufferStart = par->FbUsableSize - par->ScratchBufferSize; + printk(KERN_ERR PFX "calling ioremap(smem_start = 0x%p, size = 0x%lx)\n", + nvidiafb_fix.smem_start, par->FbMapSize); info->screen_base =ioremap (nvidiafb_fix.smem_start, par->FbMapSize); nvidiafb_fix.smem_len = par->FbUsableSize;
PATCH 1/1 nvidiafb: fix section references
Quoted 57 lines · Randy.Dunlap
Quoted 17 lines · Miles Lane
Quoted 15 lines · Andrew Morton
(Added the mailing list - trust that's ok)
Quoted 11 lines · Miles Lane
Kernel command line: BOOT_IMAGE=Linux ro root=306 video=nvidiafb init=/etc/init lang=us apm=power-off nomce
nvidiafb: nVidia device/chipset 10DE0312
nvidiafb: nVidia Corporation NV31 [GeForce FX 5600]
nvidiafb: CRTC0 found
nvidiafb: CRTC1 not found
nvidiafb: EDID found from BUS1
nvidiafb: CRTC 0 appears to have a CRT attached
nvidiafb: Using CRT on CRTC 0Quoted 8 lines
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
Quoted 1 line
I am wondering whether the following two lines point to the problem.
allocation failed: out of vmalloc space - use vmalloc=<size> to increase size.
nvidiafb: cannot ioremap FB baseQuite possibly.
Sure, without the FB memory, video won't show up.
And the 2 lines are directly related -- same error printed from 2 different places.Quoted 17 lines
Quoted 1 line
I'll do rc2-mm3 tonight - please test that. It has fixes.
Hello Andrew,
mm3 did not fix the problem. I still get a blank framebuffer console. I still get these two errors:
allocation failed: out of vmalloc space - use vmalloc=<size> to increase size.
nvidiafb: cannot ioremap FB base
Also, I still get the /sys listing Oops when listing the i2c entries for the nvidiafb.
Lastly, I get the Oops that halts booting if I include certain other i2c drivers in the build.
Removing nvidiafb from the build allows me to get a completely usable build of 2.6.12-rc1-mm3.Quoted 2 lines
I haven't heard anything from the author of the nvidiafb driver about the various issues I have reported.
Here's a tiny patch to get started. Hopefully it will show us why ioremap is failing...
Quoted 7 lines
Another issue while looking at this code:
there is some__initdatainnvidia.cthat should be__devinitdata(deja vu)Miles, after using this patch, please also test by booting with "vmalloc=512M" (or "vmalloc=256M" if you don't have 512 MB to spare).
and here are the section usage fixes.
Miles, please apply and test with this also.
Andrew, I think you and Tony want this.
Signature · 1 line
~Randy
linux-2612-rc1-mm3
Fix section usage in nvidiafb driver.
diffstat:=
drivers/video/nvidia/nvidia.c | 22 +++++++++++----------- 1 files changed, 11 insertions(+), 11 deletions(-)
drivers/video/nvidia/nvidia.c renamed from drivers/video/nvidia/nvidia.c~nvid_sections +11 -11
@@ -402,25 +402,25 @@ static struct pci_device_id nvidiafb_pciMODULE_DEVICE_TABLE (pci, nvidiafb_pci_tbl);/* command line data, set in nvidiafb_setup() */ -static int flatpanel__initdata =-1 ;/* Autodetect later */ -static int forceCRTC__initdata =-1 ; -static int hwcur__initdata =0 ; -static int noaccel__initdata =0 ; -static int noscale__initdata =0 ; -static int paneltweak__initdata =0 ; +static int flatpanel__devinitdata =-1 ;/* Autodetect later */ +static int forceCRTC__devinitdata =-1 ; +static int hwcur__devinitdata =0 ; +static int noaccel__devinitdata =0 ; +static int noscale__devinitdata =0 ; +static int paneltweak__devinitdata =0 ;#ifdef CONFIG_MTRR -static int nomtrr__initdata =0 ; +static int nomtrr__devinitdata =0 ;#endif -static char *mode_option__initdata =NULL ; +static char *mode_option__devinitdata =NULL ; -static struct fb_fix_screeninfo __initdata nvidiafb_fix = { +static struct fb_fix_screeninfo __devinitdata nvidiafb_fix = { .type =FB_TYPE_PACKED_PIXELS , .xpanstep =8 , .ypanstep =1 , }; -static struct fb_var_screeninfo __initdata nvidiafb_default_var = { +static struct fb_var_screeninfo __devinitdata nvidiafb_default_var = { .xres =640 , .yres =480 , .xres_virtual =640 ,
@@ -1617,7 +1617,7 @@ static void __exit nvidiafb_remove(struc* ------------------------------------------------------------------------- */ #ifndef MODULE -static int __init nvidiafb_setup (char *options) +static int __devinit nvidiafb_setup (char *options) {char *this_opt;
Quoted 18 lines · Andrew Morton
(Added the mailing list - trust that's ok)
Quoted 14 lines · Miles Lane
Kernel command line: BOOT_IMAGE=Linux ro root=306 video=nvidiafb init=/etc/init lang=us apm=power-off nomce
nvidiafb: nVidia device/chipset 10DE0312
nvidiafb: nVidia Corporation NV31 [GeForce FX 5600]
nvidiafb: CRTC0 found
nvidiafb: CRTC1 not found
nvidiafb: EDID found from BUS1
nvidiafb: CRTC 0 appears to have a CRT attached
nvidiafb: Using CRT on CRTC 0Quoted 1 line
Quoted 1 line
I am wondering whether the following two lines point to the problem.
allocation failed: out of vmalloc space - use vmalloc=<size> to increase size. nvidiafb: cannot ioremap FB base
Sorry for answering very, very late. I have been busy for the past 2 weeks and still am busy.
I'm attaching a patch that adds a vram option that allows the user to specify the amount of video ram to remap. This is useful for cards with huge amounts of vram.
You can use, for example:
video=nvidiafb:vram:8
to remap only 8 MiB of video RAM.
(Or perhaps, we can always limit the amount to not more than 128 MiB? I'm attaching an incremental patch in another mail, if people want this).
As for the i2c problem, this is probably due to a misplaced label in the failure path, and the reason why I had a difficult time reproducing this bug. When nvidiafb failed with the ioremap, it skipped deletion of the i2c busses causing the crash whenever the bus created by nvidiafb is read. The fix is also included in this patch.
So, can you test this patch and see if it helps?
From: Antonino Daplas <[email protected]>
---
nvidia.c | 13 ++++++++++++- 1 files changed, 12 insertions(+), 1 deletion(-)
drivers/video/nvidia/nvidia.c +12 -1
@@ -408,6 +408,7 @@static int noaccel__devinitdata =0 ;static int noscale__devinitdata =0 ;static int paneltweak__devinitdata =0 ; +static int vram__devinitdata =0 ;#ifdef CONFIG_MTRR static int nomtrr__devinitdata =0 ;#endif
@@ -1507,6 +1508,10 @@ par->FbAddress = nvidiafb_fix.smem_start; par->FbMapSize = par->RamAmountKBytes *1024 ; + +if (vram && vram *1024 *1024 < par->FbMapSize) + par->FbMapSize = vram *1024 *1024 ; + par->FbUsableSize = par->FbMapSize - (128 *1024 ); par->ScratchBufferSize = (par->Architecture <NV_ARCH_10 ) ?8 *1024 :16 *1024 ;
@@ -1566,9 +1571,9 @@ err_out_iounmap_fb:iounmap (info->screen_base); + err_out_free_base1:fb_destroy_modedb (info->monspecs.modedb);nvidia_delete_i2c_busses (par); - err_out_free_base1:iounmap (par->REGS); err_out_free_base0:pci_release_regions (pd);
@@ -1645,6 +1650,8 @@ noscale =1 ; }else if (!strncmp (this_opt,"paneltweak:" ,11 )) { paneltweak =simple_strtoul (this_opt+11 ,NULL ,0 ); + }else if (!strncmp (this_opt,"vram:" ,5 )) { + vram =simple_strtoul (this_opt+5 ,NULL ,0 ); #ifdef CONFIG_MTRR }else if (!strncmp (this_opt,"nomtrr" ,6 )) { nomtrr =1 ;
@@ -1716,6 +1723,10 @@MODULE_PARM_DESC (forceCRTC,"Forces usage of a particular CRTC in case autodetection " "fails. (0 or 1) (default=autodetect)" ); +module_param (vram, int,0 ); +MODULE_PARM_DESC (vram, +"amount of framebuffer memory to remap in MiB" +"(default=0 - remap entire memory)" );#ifdef CONFIG_MTRR module_param (nomtrr, bool,0 ); MODULE_PARM_DESC(nomtrr, "Disables MTRR support (0 or 1=disabled) "
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Hi Tony,
Quoted 5 lines
As for the i2c problem, this is probably due to a misplaced label in the failure path, and the reason why I had a difficult time reproducing this bug. When nvidiafb failed with the ioremap, it skipped deletion of the i2c busses causing the crash whenever the bus created by nvidiafb is read. The fix is also included in this patch.
Exactly what I suspected from the very beginning, but I did not investigate the error path back then - in fact I can't remember Miles telling me that the the driver was actually not working for him. Thanks a lot for confirming and fixing the problem.
Quoted 1 line
So, can you test this patch and see if it helps?
I can't - I have no compatible hardware - but hopefully Miles will be able to test.
Signature · 8 lines
Jean Delvare ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Quoted 11 lines · Jean Delvare
Hi Tony,
Quoted 5 lines
As for the i2c problem, this is probably due to a misplaced label in the failure path, and the reason why I had a difficult time reproducing this bug. When nvidiafb failed with the ioremap, it skipped deletion of the i2c busses causing the crash whenever the bus created by nvidiafb is read. The fix is also included in this patch.
Exactly what I suspected from the very beginning, but I did not investigate the error path back then - in fact I can't remember Miles telling me that the the driver was actually not working for him. Thanks
He didn't. I just assumed that it did because he also reported that nvidiafb failed to load due to an ioremap problem (too much video RAM).
Quoted 1 line
a lot for confirming and fixing the problem.
Well, not yet confirmed, I'll wait for Miles to do so.
Tony
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Quoted 4 lines · Andrew Morton
Quoted 3 lines
allocation failed: out of vmalloc space - use vmalloc=<size> to increase size. nvidiafb: cannot ioremap FB base
This patch will always limit the amount of video RAM to remap at 128 MiB.
From: Antonino Daplas <[email protected]>
---
nvidia.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletion(-)
drivers/video/nvidia/nvidia.c +5 -1
@@ -1510,7 +1510,11 @@ par->FbMapSize = par->RamAmountKBytes *1024 ;if (vram && vram *1024 *1024 < par->FbMapSize) - par->FbMapSize = vram *1024 *1024 ; + par->FbMapSize = vram *1024 *1024 ; + +/* Limit amount of vram to 128 MB */ +if (par->FbMapSize >128 *1024 *1024 ) + par->FbMapSize =128 *1024 *1024 ; par->FbUsableSize = par->FbMapSize - (128 *1024 ); par->ScratchBufferSize = (par->Architecture < NV_ARCH_10) ? 8 * 1024 :
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Hi Tony,
Quoted 2 lines
This patch will always limit the amount of video RAM to remap at 128 MiB.
I don't much get the idea. What are you trying to prevent?
128 MiB seems a rather low limit. Graphics adapters with 256 MiB, 512 MiB or even 640 MiB exist, and I see little reason why it would stop increasing.
drivers/video/nvidia/nvidia.c line 1513
Quoted 9 lines
diff -Nru
a/drivers/video/nvidia/nvidia.cb/drivers/video/nvidia/nvidia.cdrivers/video/nvidia/nvidia.c +1
-1@@ -1510,7 +1510,11 @@ par->FbMapSize = par->RamAmountKBytes *1024 ;if (vram && vram *1024 *1024 < par->FbMapSize) - par->FbMapSize = vram *1024 *1024 ; + par->FbMapSize = vram *1024 *1024 ;
You're fixing an indentation error you just introduced in the previous patch. Maybe you could fix the first patch instead?
Thanks,
Signature · 8 lines
Jean Delvare ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Perhaps I am mistaken, but I thought Andrew wanted to see the nvidiafb driver work with a default X86 kernel configuration (which allows for up to 128M to be allocated). Is the driver attempting to allocate exactly 128M because that is how much video ram is present in my video card?
If lots of video cards exist that have more than 128M of video ram, won't we be seeing many boot problems with the default kernel configuration? Does this point to a problem in the kernel design? Is this limitation in the kernel's default configuration advantageous?
Thanks,
Miles
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
Quoted 6 lines · Miles Lane
Perhaps I am mistaken, but I thought Andrew wanted to see the nvidiafb driver work with a default X86 kernel configuration (which allows for up to 128M to be allocated). Is the driver attempting to allocate exactly 128M because that is how much video ram is present in my video card?
Not allocation, as standalone cards have already a fixed amount of RAM. The patch will limit the amount of video RAM that the kernel can access to a maximum of 128 MiB.
Quoted 5 lines
If lots of video cards exist that have more than 128M of video ram, won't we be seeing many boot problems with the default kernel configuration? Does this point to a problem in the kernel design? Is this limitation in the kernel's default configuration advantageous?
The patch is a short-term workaround where cards with large amounts of video RAM eat a large amount of the kernel's address space.
What I intend to do is to mimic what radeonfb is doing. Ie, info->screen_size points to the actual vram, while fix->smem_len points to ioremapped area only. I'll do some testing first since nvidiafb uses the last chunk of the ioremapped vram for the DMA buffer, and I don't know the consequence if this buffer is unintentionally exported to user space, from the security point of view.
Tony
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Quoted 6 lines · Jean Delvare
Hi Tony,
Quoted 2 lines
This patch will always limit the amount of video RAM to remap at 128 MiB.
I don't much get the idea. What are you trying to prevent?
I'm preventing ioremap failures when the driver tries to remap a large chunk of the graphics aperture.
Quoted 4 lines
128 MiB seems a rather low limit. Graphics adapters with 256 MiB, 512 MiB or even 640 MiB exist, and I see little reason why it would stop increasing.
For fbcon use, such a large amount of RAM does not help significantly with performance. Also, nvidiafb cannot use the entire video RAM as framebuffer space since it's 2D drawing functions are limited by the clipping coordinates which is set at 0x7fff, x and y, ie, one can only do blits within the range of 0x0-0x7fff.
Tony
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Hello Tony,
So far no Oops messages while testing your patches to nvidiafb. I have tried compiling all the I2C drivers into the kernel and then booting with vesafb as the console graphics driver. So far it looks good. I need to do more careful testing of the case where no vmalloc= is specified. I'll try to get to this tomorrow. So far, so good.
Miles
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
Your patches seem to have fixed the Oops with I2C, but nvidiafb is not working unless I specify more than vmalloc=128M in the append options. That is, the default kernel options do not provide for a working nvidiafb display.
Here's what I get when testing 2.6.12-rc2-mm3
(I verified that your two patches have been applied in my tree):
Kernel command line: BOOT_IMAGE=Linux ro root=306
video=nvidiafb:1280x1024-16@85 vmalloc=
128M init=/etc/init lang=us apm=power-off nomce
nvidiafb: nVidia device/chipset 10DE0312
nvidiafb: nVidia Corporation NV31 [GeForce FX 5600]i2c_adapter i2c-0: registered as adapter #0i2c_adapter i2c-1: registered as adapter #1i2c_adapter i2c-2: registered as adapter #2
nvidiafb: CRTC0 found
nvidiafb: CRTC1 not foundi2c_adapter i2c-0: master_xfer[0] W, addr=0x50, len=1i2c_adapter i2c-0: master_xfer[1] R, addr=0x50, len=128
nvidiafb: EDID found from BUS1i2c_adapter i2c-1: master_xfer[0] W, addr=0x50, len=1i2c_adapter i2c-1: master_xfer[1] R, addr=0x50, len=128 i2c_adapter i2c-1: master_xfer[0] W, addr=0x50, len=1i2c_adapter i2c-1: master_xfer[1] R, addr=0x50, len=128 i2c_adapter i2c-1: master_xfer[0] W, addr=0x50, len=1i2c_adapter i2c-1: master_xfer[1] R, addr=0x50, len=128
nvidiafb: CRTC 0 appears to have a CRT attached
nvidiafb: Using CRT on CRTC 0
allocation failed: out of vmalloc space - use vmalloc=<size> to increase size.
nvidiafb: cannot ioremap FB base
When I boot, the screen stays black until XFree86 starts up.
-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728
On Thu, 21 Apr 2005 01:51:12 -0400 Miles Lane wrote:
| Your patches seem to have fixed the Oops with I2C, but | nvidiafb is not working unless I specify more than vmalloc=128M | in the append options. That is, the default kernel options | do not provide for a working nvidiafb display. | | Here's what I get when testing 2.6.12-rc2-mm3 | (I verified that your two patches have been applied in my | tree): | | Kernel command line: BOOT_IMAGE=Linux ro root=306 | video=nvidiafb:1280x1024-16@85 vmalloc= | 128M init=/etc/init lang=us apm=power-off nomce | ... | allocation failed: out of vmalloc space - use vmalloc=<size> to increase size. | nvidiafb: cannot ioremap FB base | | When I boot, the screen stays black until XFree86 starts up.
Tony,
As I wrote to Miles a few weeks ago:
"I started looking at vmalloc() and what it calls (which is __get_vm_area). _get_vm_area() always allocates one extra page (called a "guard page") between all vmalloc allocations, so even though 128 MB is the default amount and the amount that nvidiafb wants to use, the kernel wants to allocate 128 MB + PAGE_SIZE (4 KB on x86; are you on x86?), so even if nvidiafb is the only caller, the vmalloc() call will fail."
This means that the default kernel vmalloc size of 128MB cannot be totally (fully) allocated due to this code:
/* * We always allocate a guard page. */ size += PAGE_SIZE;
IMO we (somebody) should add the guard page into the default vmalloc size so that the full 128MB can be allocated. I'll take a look at doing that... no promises.
---
~Randy
-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728
On Thu, 21 Apr 2005 09:22:15 -0700 Randy.Dunlap wrote:
| On Thu, 21 Apr 2005 01:51:12 -0400 Miles Lane wrote: | | | Here's what I get when testing 2.6.12-rc2-mm3 | | (I verified that your two patches have been applied in my | | tree): | | | | Kernel command line: BOOT_IMAGE=Linux ro root=306 | | video=nvidiafb:1280x1024-16@85 vmalloc= | | 128M init=/etc/init lang=us apm=power-off nomce | | | ... | | allocation failed: out of vmalloc space - use vmalloc=<size> to increase size. | | nvidiafb: cannot ioremap FB base | | | | When I boot, the screen stays black until XFree86 starts up. | | Tony, | | As I wrote to Miles a few weeks ago: | "I started looking at vmalloc() and what it calls (which is | __get_vm_area). _get_vm_area() always allocates one extra | page (called a "guard page") between all vmalloc allocations, | so even though 128 MB is the default amount and the amount | that nvidiafb wants to use, the kernel wants to allocate | 128 MB + PAGE_SIZE (4 KB on x86; are you on x86?), so even | if nvidiafb is the only caller, the vmalloc() call will | fail." | | This means that the default kernel vmalloc size of 128MB | cannot be totally (fully) allocated due to this code: | /* | * We always allocate a guard page. | */ | size += PAGE_SIZE; | | IMO we (somebody) should add the guard page into the default | vmalloc size so that the full 128MB can be allocated. | I'll take a look at doing that... no promises.
Miles,
Can you test this patch, please?
(against 2.6.12-rc3 if it matters)
Don't use "vmalloc=size" on the kernel boot line. The driver should still be able to allocate 128 MB without using that.
From: Randy Dunlap <[email protected]>
Include a guard page in the default vmalloc reserved size so that a vmalloc() of 128 MB will succeed. Useful for framebuffer drivers that vmalloc() 128 MB but that currently fails. Specifying "vmalloc=size" on the kernel command line still allocates exactly that requested size, with no extra for a guard page.
---
arch/i386/mm/init.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletion(-)
arch/i386/mm/init.c renamed from arch/i386/mm/init.c~vmalloc_guard +2 -1
@@ -31,6 +31,7 @@#include <asm/processor.h> #include <asm/system.h> #include <asm/uaccess.h> +#include <asm/page.h> #include <asm/pgtable.h> #include <asm/dma.h> #include <asm/fixmap.h>
@@ -40,7 +41,7 @@#include <asm/tlbflush.h> #include <asm/sections.h> -unsigned int __VMALLOC_RESERVE =128 <<20 ; +unsigned int __VMALLOC_RESERVE = (128 <<20 ) +PAGE_SIZE ; DEFINE_PER_CPU(struct mmu_gather, mmu_gathers);unsigned long highstart_pfn, highend_pfn;
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Hi Randy,
I tried your patch to a clean 2.6.12-rc2-mm3 tree (I backed out Antonio's patches). The result of not having a vmalloc= in the boot arguments is that the screen is still black:
allocation failed: out of vmalloc space - use vmalloc=<size> to increase size.
nvidiafb: cannot ioremap FB base
I will try again with Antonio's patches added.
Miles
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
Okay, it also fails with Antonio's patches applied in addition to yours.
Thanks,
Miles
Quoted 6 lines · Miles Lane
Hi Randy,
I tried your patch to a clean 2.6.12-rc2-mm3 tree (I backed out Antonio's patches). The result of not having a vmalloc= in the boot arguments is that the screen is still black:
Quoted 6 lines
allocation failed: out of vmalloc space - use vmalloc=<size> to increase size.
nvidiafb: cannot ioremap FB baseI will try again with Antonio's patches added.
Miles
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
Quoted 1 line · Miles Lane
Okay, it also fails with Antonio's patches applied in addition to yours.
I know I implied this in my previous message, but I want to make it explicit. This combination of patches also fails to give a working framebuffer console when I specify vmalloc=128M. I only get a working framebuffer console by specifying vmalloc=256M.
Miles
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
Quoted 9 lines · Miles Lane
Quoted 1 line · Miles Lane
Okay, it also fails with Antonio's patches applied in addition to yours.
I know I implied this in my previous message, but I want to make it explicit. This combination of patches also fails to give a working framebuffer console when I specify vmalloc=128M. I only get a working framebuffer console by specifying vmalloc=256M.
Miles
Can you try this patch? This limits the amount of RAM that nvidiafb will remap to 64 MiB. This is on top of another patch I sent to Andrew:
"[Linux-fbdev-devel] [PATCH 1/6] nvidiafb: ioremap and i2c fixes"
Tony
drivers/video/nvidia/nvidia.c +3 -3
@@ -1511,9 +1511,9 @@if (vram && vram *1024 *1024 < par->FbMapSize) par->FbMapSize = vram *1024 *1024 ; -/* Limit amount of vram to 128 MB */ -if (par->FbMapSize >128 *1024 *1024 ) - par->FbMapSize =128 *1024 *1024 ; +/* Limit amount of vram to 64 MB */ +if (par->FbMapSize >64 *1024 *1024 ) + par->FbMapSize =64 *1024 *1024 ; par->FbUsableSize = par->FbMapSize - (128 *1024 ); par->ScratchBufferSize = (par->Architecture < NV_ARCH_10) ? 8 * 1024 :
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Yep, that seems to have fixed it.
Thanks!
Miles
Quoted 25 lines · Antonino A. Daplas
Can you try this patch? This limits the amount of RAM that nvidiafb will remap to 64 MiB. This is on top of another patch I sent to Andrew:
"[Linux-fbdev-devel] [PATCH 1/6] nvidiafb: ioremap and i2c fixes"Tony
diff -Nru
a/drivers/video/nvidia/nvidia.cb/drivers/video/nvidia/nvidia.cdrivers/video/nvidia/nvidia.c 2005-04-25 10:39:45 +08:00 renamed from drivers/video/nvidia/nvidia.c 2005-04-16 11:54:44 +08:00 +3
-4@@ -1511,9 +1511,9 @@ if (vram && vram * 1024 * 1024 < par->FbMapSize) par->FbMapSize = vram * 1024 * 1024; - /* Limit amount of vram to 128 MB */ - if (par->FbMapSize > 128 * 1024 * 1024) - par->FbMapSize = 128 * 1024 * 1024; + /* Limit amount of vram to 64 MB */ + if (par->FbMapSize > 64 * 1024 * 1024) + par->FbMapSize = 64 * 1024 * 1024; par->FbUsableSize = par->FbMapSize - (128 * 1024); par->ScratchBufferSize = (par->Architecture < NV_ARCH_10) ? 8 * 1024 : -------------------------------------------------------
Quoted 9 lines
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Linux-fbdev-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
Oops. Sorry some of you will get this twice.
Yes, that patch fixed the problem. I was able to get a usable framebuffer console without specifying the vmalloc boot parameter.
Thanks!
Miles
Quoted 25 lines · Antonino A. Daplas
Can you try this patch? This limits the amount of RAM that nvidiafb will remap to 64 MiB. This is on top of another patch I sent to Andrew:
"[Linux-fbdev-devel] [PATCH 1/6] nvidiafb: ioremap and i2c fixes"Tony
diff -Nru
a/drivers/video/nvidia/nvidia.cb/drivers/video/nvidia/nvidia.cdrivers/video/nvidia/nvidia.c 2005-04-25 10:39:45 +08:00 renamed from drivers/video/nvidia/nvidia.c 2005-04-16 11:54:44 +08:00 +3
-4@@ -1511,9 +1511,9 @@ if (vram && vram * 1024 * 1024 < par->FbMapSize) par->FbMapSize = vram * 1024 * 1024; - /* Limit amount of vram to 128 MB */ - if (par->FbMapSize > 128 * 1024 * 1024) - par->FbMapSize = 128 * 1024 * 1024; + /* Limit amount of vram to 64 MB */ + if (par->FbMapSize > 64 * 1024 * 1024) + par->FbMapSize = 64 * 1024 * 1024; par->FbUsableSize = par->FbMapSize - (128 * 1024); par->ScratchBufferSize = (par->Architecture < NV_ARCH_10) ? 8 * 1024 : -------------------------------------------------------
Quoted 9 lines
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Linux-fbdev-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click