| Message ID | 20191211071501.7846-2-hui.wang@canonical.com |
|---|---|
| State | New |
| Headers | show |
| Series | fbdev: dmesg prints calltrace when continuous memory allocation fails | expand |
On 11.12.19 08:15, Hui Wang wrote: > BugLink: https://bugs.launchpad.net/bugs/1855990 > > When we boot the kernel on the rpi4/3/2, we sometimes could see the > warning calltrace like below: > > bcm2708_fb soc:fb: FB found 1 display(s) > cma: cma_alloc: alloc failed, req-size: 1753 pages, ret: -12 > WARNING: CPU: 2 PID: 1 at mm/page_alloc.c:4702 __alloc_pages_nodemask+0x284/0x2c8 > Modules linked in: > CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.3.0-1013-raspi2 #15-Ubuntu > Hardware name: Raspberry Pi 3 Model B Plus Rev 1.3 (DT) > pstate: 20400005 (nzCv daif +PAN -UAO) > pc : __alloc_pages_nodemask+0x284/0x2c8 > lr : __dma_direct_alloc_pages+0x100/0x1e8 > sp : ffff0000100238a0 > x29: ffff0000100238a0 x28: 0000000000000000 > x27: ffffa7c578867580 x26: ffffa7c57786a080 > ... > > After investigation, I found there are two situations which could > introduce this calltrace. > 1) booting the arm64 kernel on rpi4 boards without the monitor > connected, in this situation, the xres and yres euqal to 0, so the > dma_alloc_coherent wants to alloc a memory region with 0 size, this > will result the get_order() returns (BITS_PER_LONG - PAGE_SHIFT), > then it will introduce the calltrace because > unlikely(order >= MAX_ORDER) is true (mm/page_alloc.c) > 2) booting the kernel on rpi2/3 boards with a high resolution monitor > connected, in this case the xres * yres is too big, the cma_alloc > doens't have enough memory for it, and finally it will also introduce > the calltrace by unlikely(order >= MAX_ORDER) is true. > > The bcm2708_fb could handle the situation of failure on calling > dma_alloc_coherent, and the driver itself will print some log to > notify users that this alloc fails. So we don't need the mm/page_alloc > to print that calltrace anymore, printing a calltrace when booting > usually makes users think the kernel has a critical problem. > > Signed-off-by: Hui Wang <hui.wang@canonical.com> > (cherry picked from commit 373a1ab55a8ef178fbe9f4d505c4714c3f7b3e9e > https://github.com/raspberrypi/linux.git rpi-5.3.y) > Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> > --- > drivers/video/fbdev/bcm2708_fb.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/video/fbdev/bcm2708_fb.c b/drivers/video/fbdev/bcm2708_fb.c > index 59443f79f228..efbcc1f803bc 100644 > --- a/drivers/video/fbdev/bcm2708_fb.c > +++ b/drivers/video/fbdev/bcm2708_fb.c > @@ -410,7 +410,8 @@ static int bcm2708_fb_set_par(struct fb_info *info) > } > > fb->cpuaddr = dma_alloc_coherent(info->device, image_size, > - &fb->dma_addr, GFP_KERNEL); > + &fb->dma_addr, > + GFP_KERNEL | __GFP_NOWARN); > > if (!fb->cpuaddr) { > fb->dma_addr = 0; >
On 2019-12-11 08:15, Hui Wang wrote: > BugLink: https://bugs.launchpad.net/bugs/1855990 > > When we boot the kernel on the rpi4/3/2, we sometimes could see the > warning calltrace like below: > > bcm2708_fb soc:fb: FB found 1 display(s) > cma: cma_alloc: alloc failed, req-size: 1753 pages, ret: -12 > WARNING: CPU: 2 PID: 1 at mm/page_alloc.c:4702 __alloc_pages_nodemask+0x284/0x2c8 > Modules linked in: > CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.3.0-1013-raspi2 #15-Ubuntu > Hardware name: Raspberry Pi 3 Model B Plus Rev 1.3 (DT) > pstate: 20400005 (nzCv daif +PAN -UAO) > pc : __alloc_pages_nodemask+0x284/0x2c8 > lr : __dma_direct_alloc_pages+0x100/0x1e8 > sp : ffff0000100238a0 > x29: ffff0000100238a0 x28: 0000000000000000 > x27: ffffa7c578867580 x26: ffffa7c57786a080 > ... > > After investigation, I found there are two situations which could > introduce this calltrace. > 1) booting the arm64 kernel on rpi4 boards without the monitor > connected, in this situation, the xres and yres euqal to 0, so the > dma_alloc_coherent wants to alloc a memory region with 0 size, this > will result the get_order() returns (BITS_PER_LONG - PAGE_SHIFT), > then it will introduce the calltrace because > unlikely(order >= MAX_ORDER) is true (mm/page_alloc.c) > 2) booting the kernel on rpi2/3 boards with a high resolution monitor > connected, in this case the xres * yres is too big, the cma_alloc > doens't have enough memory for it, and finally it will also introduce > the calltrace by unlikely(order >= MAX_ORDER) is true. > > The bcm2708_fb could handle the situation of failure on calling > dma_alloc_coherent, and the driver itself will print some log to > notify users that this alloc fails. So we don't need the mm/page_alloc > to print that calltrace anymore, printing a calltrace when booting > usually makes users think the kernel has a critical problem. > > Signed-off-by: Hui Wang <hui.wang@canonical.com> > (cherry picked from commit 373a1ab55a8ef178fbe9f4d505c4714c3f7b3e9e > https://github.com/raspberrypi/linux.git rpi-5.3.y) > Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> > --- > drivers/video/fbdev/bcm2708_fb.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/video/fbdev/bcm2708_fb.c b/drivers/video/fbdev/bcm2708_fb.c > index 59443f79f228..efbcc1f803bc 100644 > --- a/drivers/video/fbdev/bcm2708_fb.c > +++ b/drivers/video/fbdev/bcm2708_fb.c > @@ -410,7 +410,8 @@ static int bcm2708_fb_set_par(struct fb_info *info) > } > > fb->cpuaddr = dma_alloc_coherent(info->device, image_size, > - &fb->dma_addr, GFP_KERNEL); > + &fb->dma_addr, > + GFP_KERNEL | __GFP_NOWARN); > > if (!fb->cpuaddr) { > fb->dma_addr = 0; >
diff --git a/drivers/video/fbdev/bcm2708_fb.c b/drivers/video/fbdev/bcm2708_fb.c index 59443f79f228..efbcc1f803bc 100644 --- a/drivers/video/fbdev/bcm2708_fb.c +++ b/drivers/video/fbdev/bcm2708_fb.c @@ -410,7 +410,8 @@ static int bcm2708_fb_set_par(struct fb_info *info) } fb->cpuaddr = dma_alloc_coherent(info->device, image_size, - &fb->dma_addr, GFP_KERNEL); + &fb->dma_addr, + GFP_KERNEL | __GFP_NOWARN); if (!fb->cpuaddr) { fb->dma_addr = 0;