Bug 81321 - WARNING: CPU: 0 PID: 0 at mm/page_alloc.c:2522
Summary: WARNING: CPU: 0 PID: 0 at mm/page_alloc.c:2522
Status: RESOLVED CODE_FIX
Alias: None
Product: EFI
Classification: Unclassified
Component: Boot (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: EFI Virtual User
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-29 10:37 UTC by Srihari Vijayaraghavan
Modified: 2014-08-21 19:09 UTC (History)
5 users (show)

See Also:
Kernel Version: 3.16.0-rc7
Subsystem:
Regression: No
Bisected commit-id:


Attachments
.config, dmesg & lspci (220.00 KB, application/x-tar)
2014-07-29 10:37 UTC, Srihari Vijayaraghavan
Details
complete output of acpidump (100.83 KB, application/gzip)
2014-07-30 10:40 UTC, Srihari Vijayaraghavan
Details
dump-bgrt-image-size (502 bytes, patch)
2014-07-30 10:56 UTC, Matt Fleming
Details | Diff
dmesg bgrt table reporting (18.76 KB, application/gzip)
2014-07-30 11:45 UTC, Srihari Vijayaraghavan
Details

Description Srihari Vijayaraghavan 2014-07-29 10:37:39 UTC
Created attachment 144601 [details]
.config, dmesg & lspci

Right after kernel starts loading this warning is reported:

[    0.029994] ------------[ cut here ]------------
[    0.030005] WARNING: CPU: 0 PID: 0 at mm/page_alloc.c:2522 __alloc_pages_nodemask+0x350/0xab0()
[    0.030008] Modules linked in:
[    0.030016] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.0-rc7 #1
[    0.030019] Hardware name: GIGABYTE P35V2/P35V2, BIOS FB0A 07/14/2014
[    0.030022]  0000000000000000 c19854425dd38f65 ffffffff81c03c78 ffffffff8167c05f
[    0.030029]  0000000000000000 ffffffff81c03cb0 ffffffff8106ec4d 0000000000024000
[    0.030034]  0000000000004000 000000000000000b 0000000000000000 0000000000000000
[    0.030040] Call Trace:
[    0.030051]  [<ffffffff8167c05f>] dump_stack+0x45/0x56
[    0.030058]  [<ffffffff8106ec4d>] warn_slowpath_common+0x7d/0xa0
[    0.030063]  [<ffffffff8106ed7a>] warn_slowpath_null+0x1a/0x20
[    0.030068]  [<ffffffff81163240>] __alloc_pages_nodemask+0x350/0xab0
[    0.030078]  [<ffffffff81193f3e>] ? __insert_vmap_area+0x8e/0xc0
[    0.030086]  [<ffffffff81194f20>] ? alloc_vmap_area+0x2b0/0x310
[    0.030096]  [<ffffffff811a433a>] alloc_page_interleave+0x3a/0x90
[    0.030104]  [<ffffffff811a4a65>] alloc_pages_current+0xf5/0x170
[    0.030113]  [<ffffffff8115f4eb>] alloc_kmem_pages+0x3b/0xf0
[    0.030121]  [<ffffffff8117c238>] kmalloc_order+0x18/0x50
[    0.030128]  [<ffffffff8117c296>] kmalloc_order_trace+0x26/0xa0
[    0.030136]  [<ffffffff811af111>] __kmalloc+0x221/0x240
[    0.030146]  [<ffffffff81d23830>] efi_bgrt_init+0xce/0x13d
[    0.030154]  [<ffffffff81d22d6d>] efi_late_init+0x9/0xb
[    0.030160]  [<ffffffff81d0eff0>] start_kernel+0x43a/0x46a
[    0.030164]  [<ffffffff81d0e9bf>] ? set_init_arg+0x53/0x53
[    0.030173]  [<ffffffff81d0e5ad>] x86_64_start_reservations+0x2a/0x2c
[    0.030180]  [<ffffffff81d0e6a0>] x86_64_start_kernel+0xf1/0xf4
[    0.030190] ---[ end trace 712843818c3ab590 ]---

Actually, this neither is this 3.16.0-rc7 specific (i.e., happens on Fedora's 3.15.16 based kernel nor is it causing any actual problem. So system continues to work fine. I thought it wise to report it nonetheless.

I've attached my complete dmesg, lspci & .config as tar file. Please feel free to ask for more info.
Comment 1 xerofoify 2014-07-30 02:49:22 UTC
Hey Srihari ,
If you want I can email the maintainers or try to fix it myself.
Regards Nick
Comment 2 Srihari Vijayaraghavan 2014-07-30 08:39:53 UTC
Hello Nick, if you have some update patch and/or procedure that you'd like me to try, I'm very happy to try & report back.
Comment 3 Matt Fleming 2014-07-30 10:19:42 UTC
It looks like the bgrt image size is large (and potentially bogus) and kmalloc() is complaining.

It would be good to get the size of the bgrt image, if you could dump that. I'm not sure whether acpidump will do that for you or not.
Comment 4 Srihari Vijayaraghavan 2014-07-30 10:38:01 UTC
Thanks Matt. Here is BGRT table grabbed using acpidump tool:
BGRT @ 0x00000000DB370FE8
  0000: 42 47 52 54 38 00 00 00 00 F8 47 42 54 20 20 20  BGRT8.....GBT   
  0010: 47 42 54 55 41 43 50 49 09 20 07 01 41 4D 49 20  GBTUACPI. ..AMI 
  0020: 13 00 01 00 01 00 01 00 18 90 57 D8 00 00 00 00  ..........W.....
  0030: 00 00 00 00 00 00 00 00                          ........

I hope that's what you're after. The complete acpidump will be attached as the next entry in this report.
Comment 5 Srihari Vijayaraghavan 2014-07-30 10:40:43 UTC
Created attachment 144691 [details]
complete output of acpidump
Comment 6 Matt Fleming 2014-07-30 10:55:36 UTC
Srihari, actually could you try the attached patch? We need to dereference the pointer to the BGRT image that's in the ACPI BGRT table in order to get the image size.
Comment 7 Matt Fleming 2014-07-30 10:56:06 UTC
Created attachment 144701 [details]
dump-bgrt-image-size
Comment 8 Srihari Vijayaraghavan 2014-07-30 11:43:34 UTC
Matt, here's what you're looking for:

[    0.029998] efi_bgrt_init: [19778] bgrt_image_size=6220854

The complete dmesg will be attached as the next entry here.

Thanks
Comment 9 Srihari Vijayaraghavan 2014-07-30 11:45:19 UTC
Created attachment 144711 [details]
dmesg bgrt table reporting
Comment 10 Josh Triplett 2014-07-30 19:24:17 UTC
I submitted a patch fixing this issue; see "[PATCH] efi-bgrt: Add error handling; inform the user when ignoring the BGRT" on LKML.
Comment 11 Srihari Vijayaraghavan 2014-07-30 21:29:13 UTC
Thank you Josh. Yes, I can confirm that the patch you've submitted at LKML indeed works & no more WARNING reported during kernel boot up.
Comment 12 Mateusz Jończyk 2014-08-03 11:15:27 UTC
Hello,
Please note that there is another issue on this laptop: the touchpad does not work. It is probably related to ACPI.

See:
https://bugzilla.kernel.org/show_bug.cgi?id=81331

Note You need to log in before you can comment on or make changes to this bug.