Bug 36362 - "Bad page state in process swapper" on EFI boot of Latitude E5520 (Sandy Bridge)
Summary: "Bad page state in process swapper" on EFI boot of Latitude E5520 (Sandy Bridge)
Status: RESOLVED CODE_FIX
Alias: None
Product: Platform Specific/Hardware
Classification: Unclassified
Component: x86-64 (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: platform_ia-64
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-31 13:34 UTC by Paul Gideon Dann
Modified: 2012-05-09 17:57 UTC (History)
3 users (show)

See Also:
Kernel Version: 3.0.0-rc2
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg showing boot-time errors (87.11 KB, text/plain)
2011-05-31 13:34 UTC, Paul Gideon Dann
Details

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.

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