From: Andrew M. <ak...@os...> - 2005-03-25 04:31:44
|
(Added the mailing list - trust that's ok) Miles Lane <mil...@gm...> wrote: > > 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 > > >> 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. > CONFIG_AGP_NVIDIA=y > CONFIG_I2C=y > CONFIG_I2C_CHARDEV=m > CONFIG_I2C_ALGOBIT=y > CONFIG_I2C_ALGOPCF=m > CONFIG_I2C_ALGOPCA=m > CONFIG_I2C_ISA=m > CONFIG_I2C_NFORCE2=m > > CONFIG_FB=y > CONFIG_FB_CFB_FILLRECT=y > CONFIG_FB_CFB_COPYAREA=y > CONFIG_FB_CFB_IMAGEBLIT=y > CONFIG_FB_SOFT_CURSOR=y > CONFIG_FB_MODE_HELPERS=y > CONFIG_FB_TILEBLITTING=y > CONFIG_VIDEO_SELECT=y > CONFIG_FB_NVIDIA=y > CONFIG_FB_NVIDIA_I2C=y > CONFIG_FRAMEBUFFER_CONSOLE=y |
From: Randy.Dunlap <rdd...@os...> - 2005-03-28 17:17:04
|
Miles Lane wrote: > On Thu, 24 Mar 2005 20:31:18 -0800, Andrew Morton <ak...@os...> wrote: > >>(Added the mailing list - trust that's ok) >> >>Miles Lane <mil...@gm...> wrote: >> >>>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 >>> >>> >>>>>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. > > > 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. 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? -- ~Randy |
From: Miles L. <mil...@gm...> - 2005-03-29 00:23:28
|
I am looking forward to having something to test. Please keep me posted. Miles |
From: Randy.Dunlap <rdd...@os...> - 2005-03-29 00:37:29
|
Miles Lane wrote: > 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. -- ~Randy |
From: Miles L. <mil...@gm...> - 2005-03-29 00:56:55
|
On Mon, 28 Mar 2005 09:12:49 -0800, Randy.Dunlap <rdd...@os...> 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. > 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. > 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. > Is that in the exposed source code? I have no idea. How would I find out? > If so, where is that source code? I have no clue. > 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. > Or should I just make a io_remap debug 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 |
From: Randy.Dunlap <rdd...@os...> - 2005-03-29 01:02:55
|
Miles Lane wrote: > On Mon, 28 Mar 2005 09:12:49 -0800, Randy.Dunlap <rdd...@os...> 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. > > >>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. :) > >>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. > > >>Is that in the exposed source code? > > > I have no idea. How would I find out? > >>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? >>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. > >>Or should I just make a io_remap debug 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. -- ~Randy |
From: Miles L. <mil...@gm...> - 2005-03-29 01:12:12
|
On Mon, 28 Mar 2005 17:02:38 -0800, Randy.Dunlap <rdd...@os...> wrote: > Miles Lane wrote: > > On Mon, 28 Mar 2005 09:12:49 -0800, Randy.Dunlap <rdd...@os...> 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. > > > > > >>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. :) > > > > >>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. > > > > > >>Is that in the exposed source code? > > > > > > I have no idea. How would I find out? > > > >>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 kh...@li... is the author. I have reproduced this problem with both mm2 and mm3. Do you need my .config file? > 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. > Where can I get it? Build it? > >>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. > > Your humble tester (remember me from the early USB days?), > > Sure I do. :) > I'll make a patch, probably tonight Pacific time. Great! Miles |
From: Randy.Dunlap <rdd...@os...> - 2005-03-29 03:01:44
|
Miles Lane wrote: > On Mon, 28 Mar 2005 17:02:38 -0800, Randy.Dunlap <rdd...@os...> wrote: > >>Miles Lane wrote: >> >>>On Mon, 28 Mar 2005 09:12:49 -0800, Randy.Dunlap <rdd...@os...> 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. >>> >>> >>> >>>>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. :) >> >> >>>>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. >> >> > >> >>>>Is that in the exposed source code? >>> >>> >>>I have no idea. How would I find out? >>> >>> >>>>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 > kh...@li... 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. > >>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. > > >>Where can I get it? > > > Build it? > > >>>>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. > > >>>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. -- ~Randy |
From: Jean D. <kh...@li...> - 2005-03-29 09:21:13
|
Hi gentle folks, > 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 > kh...@li... 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 |
From: Andrew M. <ak...@os...> - 2005-03-29 01:14:21
|
"Randy.Dunlap" <rdd...@os...> wrote: > > >>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 |
From: Miles L. <mil...@gm...> - 2005-03-29 03:56:18
|
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 |
From: Antonino A. D. <ad...@ho...> - 2005-04-14 05:52:14
|
On Friday 25 March 2005 12:31, Andrew Morton wrote: > (Added the mailing list - trust that's ok) > > Miles Lane <mil...@gm...> wrote: > > 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 > > > > >> 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 <ad...@po...> Signed-off-by: Antonino Daplas <ad...@po...> --- nvidia.c | 13 ++++++++++++- 1 files changed, 12 insertions(+), 1 deletion(-) diff -Nru a/drivers/video/nvidia/nvidia.c b/drivers/video/nvidia/nvidia.c --- a/drivers/video/nvidia/nvidia.c 2005-04-14 12:44:06 +08:00 +++ b/drivers/video/nvidia/nvidia.c 2005-04-14 13:33:38 +08:00 @@ -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) " |
From: Jean D. <kh...@li...> - 2005-04-14 17:06:32
|
Hi Tony, > 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. > 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. -- Jean Delvare |
From: Antonino A. D. <ad...@ho...> - 2005-04-15 03:08:43
|
On Friday 15 April 2005 01:06, Jean Delvare wrote: > Hi Tony, > > > 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). > a lot for confirming and fixing the problem. Well, not yet confirmed, I'll wait for Miles to do so. Tony |
From: Antonino A. D. <ad...@ho...> - 2005-04-14 05:52:35
|
On Friday 25 March 2005 12:31, Andrew Morton wrote: > > > > 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 <ad...@po...> Signed-off-by: Antonino Daplas <ad...@po...> --- nvidia.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletion(-) diff -Nru a/drivers/video/nvidia/nvidia.c b/drivers/video/nvidia/nvidia.c --- a/drivers/video/nvidia/nvidia.c 2005-04-14 13:33:38 +08:00 +++ b/drivers/video/nvidia/nvidia.c 2005-04-14 13:44:15 +08:00 @@ -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 : |
From: Jean D. <kh...@li...> - 2005-04-14 17:13:20
|
Hi Tony, > 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. > diff -Nru a/drivers/video/nvidia/nvidia.c b/drivers/video/nvidia/nvidia.c > --- a/drivers/video/nvidia/nvidia.c 2005-04-14 13:33:38 +08:00 > +++ b/drivers/video/nvidia/nvidia.c 2005-04-14 13:44:15 +08:00 > @@ -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, -- Jean Delvare |
From: Miles L. <mil...@gm...> - 2005-04-14 18:19:58
|
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 |
From: Antonino A. D. <ad...@ho...> - 2005-04-15 03:08:39
|
On Friday 15 April 2005 02:19, Miles Lane wrote: > 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. > 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 |
From: Antonino A. D. <ad...@ho...> - 2005-04-15 03:08:44
|
On Friday 15 April 2005 01:13, Jean Delvare wrote: > Hi Tony, > > > 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. > > 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 |
From: Miles L. <mil...@gm...> - 2005-04-16 08:21:43
|
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=3D is specified. I'll try to get to this tomorrow. So far, so goo= d. Miles |
From: Miles L. <mil...@gm...> - 2005-04-21 05:52:35
|
Your patches seem to have fixed the Oops with I2C, but=20 nvidiafb is not working unless I specify more than vmalloc=3D128M 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=3DLinux ro root=3D306 video=3Dnvidiafb:1280x1024-16@85 vmalloc=3D 128M init=3D/etc/init lang=3Dus apm=3Dpower-off nomce nvidiafb: nVidia device/chipset 10DE0312 nvidiafb: nVidia Corporation NV31 [GeForce FX 5600] i2c_adapter i2c-0: registered as adapter #0 i2c_adapter i2c-1: registered as adapter #1 i2c_adapter i2c-2: registered as adapter #2 nvidiafb: CRTC0 found nvidiafb: CRTC1 not found i2c_adapter i2c-0: master_xfer[0] W, addr=3D0x50, len=3D1 i2c_adapter i2c-0: master_xfer[1] R, addr=3D0x50, len=3D128 nvidiafb: EDID found from BUS1 i2c_adapter i2c-1: master_xfer[0] W, addr=3D0x50, len=3D1 i2c_adapter i2c-1: master_xfer[1] R, addr=3D0x50, len=3D128 i2c_adapter i2c-1: master_xfer[0] W, addr=3D0x50, len=3D1 i2c_adapter i2c-1: master_xfer[1] R, addr=3D0x50, len=3D128 i2c_adapter i2c-1: master_xfer[0] W, addr=3D0x50, len=3D1 i2c_adapter i2c-1: master_xfer[1] R, addr=3D0x50, len=3D128 nvidiafb: CRTC 0 appears to have a CRT attached nvidiafb: Using CRT on CRTC 0 allocation failed: out of vmalloc space - use vmalloc=3D<size> to increase = size. nvidiafb: cannot ioremap FB base When I boot, the screen stays black until XFree86 starts up. |
From: Randy.Dunlap <rdd...@os...> - 2005-04-21 16:23:12
|
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 |
From: Randy.Dunlap <rdd...@os...> - 2005-04-21 18:37:13
|
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 <rdd...@os...> 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. Signed-off-by: Randy Dunlap <rdd...@os...> --- arch/i386/mm/init.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletion(-) diff -Naurp ./arch/i386/mm/init.c~vmalloc_guard ./arch/i386/mm/init.c --- ./arch/i386/mm/init.c~vmalloc_guard 2005-04-21 08:15:35.000000000 -0700 +++ ./arch/i386/mm/init.c 2005-04-21 10:50:55.000000000 -0700 @@ -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; |
From: Miles L. <mil...@gm...> - 2005-04-23 00:03:21
|
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=3D in the boot arguments is that the screen is still black: allocation failed: out of vmalloc space - use vmalloc=3D<size> to increase = size. nvidiafb: cannot ioremap FB base I will try again with Antonio's patches added. Miles |
From: Miles L. <mil...@gm...> - 2005-04-23 00:12:27
|
Okay, it also fails with Antonio's patches applied in addition to yours. Thanks, Miles On 4/22/05, Miles Lane <mil...@gm...> wrote: > Hi Randy, >=20 > 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=3D in the boot > arguments is that the screen is still black: >=20 > allocation failed: out of vmalloc space - use vmalloc=3D<size> to increas= e size. > nvidiafb: cannot ioremap FB base >=20 > I will try again with Antonio's patches added. >=20 > Miles |