Bug 36362

Summary: "Bad page state in process swapper" on EFI boot of Latitude E5520 (Sandy Bridge)
Product: Platform Specific/Hardware Reporter: Paul Gideon Dann (pdgiddie+kernel)
Component: x86-64Assignee: platform_ia-64
Status: RESOLVED CODE_FIX    
Severity: normal CC: platform_x86_64, skodabenz, the.ridikulus.rat
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.0.0-rc2 Tree: Mainline
Regression: No
Attachments: dmesg showing boot-time errors

Description Paul Gideon Dann 2011-05-31 13:34:07 UTC
Created attachment 60232 [details]
dmesg showing boot-time errors

With 2.6.39, my Latitude E5520 will not boot from EFI without the "noefi" option.

When booting 3.0.0-rc1 from Archlinux AUR (http://aur.archlinux.org/packages.php?ID=39965), my Latitude E5520 will now boot correctly from EFI, but a number of bugs were highlighted by the kernel.  An extract follows, and the full dmesg.txt is attached:

[    0.025993] BUG: Bad page state in process swapper  pfn:00000
[    0.025999] page:ffffea0000000000 count:0 mapcount:1 mapping:          (null) index:0x0
[    0.026002] page flags: 0x0()
[    0.026006] Pid: 0, comm: swapper Not tainted 3.0.0-rc1-mainline #1
[    0.026007] Call Trace:
[    0.026013]  [<ffffffff810edb03>] ? dump_page+0x93/0xd0
[    0.026015]  [<ffffffff810edc08>] bad_page+0xc8/0x120
[    0.026018]  [<ffffffff810edda8>] free_pages_prepare+0x148/0x160
[    0.026020]  [<ffffffff810efb84>] free_hot_cold_page+0x44/0x190
[    0.026023]  [<ffffffff810efcfd>] __free_pages+0x2d/0x40
[    0.026027]  [<ffffffff813bb7ae>] __free_pages_bootmem+0x25/0x65
[    0.026030]  [<ffffffff8174391c>] free_bootmem_late+0x3d/0x55
[    0.026033]  [<ffffffff8173bb8b>] efi_enter_virtual_mode+0x25a/0x349
[    0.026036]  [<ffffffff81722bac>] start_kernel+0x367/0x3e1
[    0.026038]  [<ffffffff81722347>] x86_64_start_reservations+0x132/0x136
[    0.026041]  [<ffffffff81722140>] ? early_idt_handlers+0x140/0x140
[    0.026043]  [<ffffffff8172244d>] x86_64_start_kernel+0x102/0x111
[    0.026044] Disabling lock debugging due to kernel taint

Let me know if there's anything else I can get you...
Comment 1 Keshav P R 2011-05-31 15:40:53 UTC
This bug should be assigned to x86_64 team, not IA-64 team.
Comment 2 Paul Gideon Dann 2011-06-09 10:50:54 UTC
This still happens with rc2.
Comment 4 Paul Gideon Dann 2011-06-09 13:12:31 UTC
BTW, I attempted to change the assigned-to field, but don't have the required permission.
Comment 6 Paul Gideon Dann 2011-06-13 11:22:01 UTC
Yes, with that patch the messages go away.  The thread is very relevant; thanks for posting it.
Comment 7 Paul Gideon Dann 2011-06-14 12:19:17 UTC
Sorry, although that patch silences the errors, it also results in me losing a whole chunk of RAM (several hundred MiB).  The discussion seems to be ongoing on the mailing list; I'm not aware of a conclusion or a working patch.
Comment 8 Paul Gideon Dann 2011-06-29 12:41:05 UTC
This seems to have been fixed in 3.0-rc5.  I'm getting no errors on bootup, and I seem to have all my RAM available; at least I'm only 236MiB shy of my full 4096MiB, which is probably normal, given I'm using integrated graphics.  Sweet :)

I won't say this is resolved just yet, in case I notice any related regressions.
Comment 9 Paul Gideon Dann 2011-07-12 15:47:08 UTC
I haven't had any problems, and I'm now on 3.0-rc7.  I think it's safe to say it's sorted, as far as my machine is concerned.