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-64	Assignee:	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	Subsystem:
Regression:	No	Bisected commit-id:
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 3 Keshav P R 2011-06-09 13:04:50 UTC

The same bug is being discussed at http://groups.google.com/group/linux.kernel/browse_thread/thread/9230ce8bb985917c/303c34b442d2c205?pli=1 and http://groups.google.com/group/linux.kernel/browse_thread/thread/9230ce8bb985917c/a090ae147fa349bc .

Also change the "Assigned to" field to platform_x86_64@kernel-bugs.osdl.org .

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 5 Keshav P R 2011-06-12 12:27:52 UTC

Apply https://patchwork.kernel.org/patch/852462/ on top of 3.0-rc2 and recompile the kernel. See discussion at http://groups.google.com/group/linux.kernel/browse_thread/thread/9230ce8bb985917c/cc8a59229a9561aa?lnk=raot&pli=1 .

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.