[RFC] Old paca being written by firmware after kexec
Michael Ellerman
michael at ellerman.id.au
Fri Oct 7 12:03:30 EST 2005
Hi,
I'm seeing a bug of sorts when I kexec some kernels. It's exhibiting as page
structs being corrupted early during boot:
freeing bootmem node 0
Bad page state at __free_pages_ok (in process 'swapper', page
c0000000005a7408)
flags:0x0000000000020004 mapping:0000000000000000 mapcount:0 count:0
Backtrace:
Call Trace:
[c00000000257bc00] [c000000002089c54] .bad_page+0x90/0xec (unreliable)
[c00000000257bc80] [c00000000208a26c] .__free_pages_ok+0x170/0x174
[c00000000257bd50] [c0000000025385e8] .free_all_bootmem_core+0x3e8/0x404
[c00000000257be30] [c000000002534188] .mem_init+0xe0/0x1d8
[c00000000257bed0] [c00000000252082c] .start_kernel+0x1f8/0x328
[c00000000257bf90] [c000000002008684] .hmt_init+0x0/0x7c
Trying to fix it up, but a reboot is needed
What's happening is that firmware is writing into the lppaca of the old
kernel, which is now being used by the second kernel for page structs.
It seems to be writing into the word starting at paca[x].lppaca.reserved2,
which I guess it's allowed to do seeing as it's reserved.
For kdump this isn't an issue, as the second kernel doesn't reuse the first
kernel's memory.
But for regular kexec it can be a problem. I think we're getting away with it
most of the time because a) if you kexec the same kernel then the paca will
land in the same spot, b) it only seems to write into those locations for a
short while early during boot (presumably until we've set up pointers to the
new paca?).
The only solution I can see is to always allocate the paca in the same place.
So that a kexec from one kernel to another always results in the paca landing
in the same spot.
Any other ideas?
cheers
--
Michael Ellerman
IBM OzLabs
email: michael:ellerman.id.au
inmsg: mpe:jabber.org
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20051007/ea234682/attachment.pgp
More information about the Linuxppc64-dev
mailing list