After upgrading my Dell laptop, both OS+kernel the i8k interface was giving
nonsensical output. As it turned out it's not the kernel but compiler
upgrade which broke this.
Guys at Archlinux have found the underlying cause (but don't seem to have
submitted a patch yet):
https://bbs.archlinux.org/viewtopic.php?pid=780692#p780692
gcc seems to optimize the assembly statements away.
And indeed, applying this patch makes the i8k interface work again,
i.e. replacing the asm(..) construct by asm volatile(..)
--- i8k.c.ORIG 2010-08-02 17:20:46.000000000 +0200
+++ i8k.c 2010-10-30 13:03:07.000000000 +0200
@@ -119,7 +119,7 @@
int eax = regs->eax;
#if defined(CONFIG_X86_64)
- asm("pushq %%rax\n\t"
+ asm volatile("pushq %%rax\n\t"
"movl 0(%%rax),%%edx\n\t"
"pushq %%rdx\n\t"
"movl 4(%%rax),%%ebx\n\t"
@@ -145,7 +145,7 @@
: "a"(regs)
: "%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");
#else
- asm("pushl %%eax\n\t"
+ asm volatile("pushl %%eax\n\t"
"movl 0(%%eax),%%edx\n\t"
"push %%edx\n\t"
"movl 4(%%eax),%%ebx\n\t"
gcc version:
Reading specs from /usr/lib/gcc/i486-slackware-linux/4.5.1/specs
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i486-slackware-linux/4.5.1/lto-wrapper
Target: i486-slackware-linux
Configured with: ../gcc-4.5.1/configure --prefix=/usr --libdir=/usr/lib
--mandir=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap
--enable-languages=ada,c,c++,fortran,java,objc --enable-threads=posix
--enable-checking=release --with-system-zlib
--with-python-dir=/lib/python2.6/site-packages
--disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp
--with-gnu-ld --verbose --with-arch=i486 --target=i486-slackware-linux
--build=i486-slackware-linux --host=i486-slackware-linux
Thread model: posix
gcc version 4.5.1 (GCC)
as version:
GNU assembler (Linux/GNU Binutils) 2.20.51.0.11.20100810
Copyright 2010 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `i486-slackware-linux'.
I would be happy to submit a proper patch if I new this is actually the
correct fix, also there might be other places in the kernel source
suffering from this ??
Thanks,
Jim Bos
Jim <[email protected]> writes:
> After upgrading my Dell laptop, both OS+kernel the i8k interface was giving
> nonsensical output. As it turned out it's not the kernel but compiler
> upgrade which broke this.
>
> Guys at Archlinux have found the underlying cause (but don't seem to have
> submitted a patch yet):
> https://bbs.archlinux.org/viewtopic.php?pid=780692#p780692
> gcc seems to optimize the assembly statements away.
>
> And indeed, applying this patch makes the i8k interface work again,
> i.e. replacing the asm(..) construct by asm volatile(..)
The compiler really should not optimize the asm away, because
it has both input and output arguments which are later used.
"asm volatile" normally just means "don't move significantly"
I tested it with gcc version 4.5.0 20100604 [gcc-4_5-branch revision
160292] (SUSE Linux)
and the asm statement is there for both 32bit and 64bit
(with an allmodconfig, with both -O2 and -Os)
If gcc 4.5.1 broke that over 4.5.0 you should really file a bug report
for the compiler, it seems like a serious regression in 4.5.1
-Andi
--
[email protected] -- Speaking for myself only.
Andi Kleen <[email protected]> writes:
> Jim <[email protected]> writes:
>
>> After upgrading my Dell laptop, both OS+kernel the i8k interface was giving
>> nonsensical output. As it turned out it's not the kernel but compiler
>> upgrade which broke this.
>>
>> Guys at Archlinux have found the underlying cause (but don't seem to have
>> submitted a patch yet):
>> https://bbs.archlinux.org/viewtopic.php?pid=780692#p780692
>> gcc seems to optimize the assembly statements away.
>>
>> And indeed, applying this patch makes the i8k interface work again,
>> i.e. replacing the asm(..) construct by asm volatile(..)
>
> The compiler really should not optimize the asm away, because
> it has both input and output arguments which are later used.
> "asm volatile" normally just means "don't move significantly"
The asm fails to mention that it modifies *regs.
Andreas.
--
Andreas Schwab, [email protected]
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Andreas Schwab <[email protected]> writes:
>
> The asm fails to mention that it modifies *regs.
It has a memory clobber, that should be enough, no?
Besides in any case it cannot be eliminated because it has
valid non dead inputs and outputs.
-Andi
--
[email protected] -- Speaking for myself only.
On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen <[email protected]> wrote:
> Andreas Schwab <[email protected]> writes:
>>
>> The asm fails to mention that it modifies *regs.
>
> It has a memory clobber, that should be enough, no?
No. A memory clobber does not cover automatic storage.
Btw, I can't see a testcase anywhere so I just assume Andreas got
it right as usual.
Richard.
> Besides in any case it cannot be eliminated because it has
> valid non dead inputs and outputs.
>
> -Andi
> --
> [email protected] -- Speaking for myself only.
>
Richard Guenther <[email protected]> writes:
> On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen <[email protected]> wrote:
>> Andreas Schwab <[email protected]> writes:
>>>
>>> The asm fails to mention that it modifies *regs.
>>
>> It has a memory clobber, that should be enough, no?
>
> No. A memory clobber does not cover automatic storage.
That's a separate problem.
> Btw, I can't see a testcase anywhere so I just assume Andreas got
> it right as usual.
An asm with live inputs and outputs should never be optimized
way. If 4.5.1 started doing that it's seriously broken.
-Andi
--
[email protected] -- Speaking for myself only.
On Mon, Nov 8, 2010 at 12:20 PM, Andi Kleen <[email protected]> wrote:
> Richard Guenther <[email protected]> writes:
>
>> On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen <[email protected]> wrote:
>>> Andreas Schwab <[email protected]> writes:
>>>>
>>>> The asm fails to mention that it modifies *regs.
>>>
>>> It has a memory clobber, that should be enough, no?
>>
>> No. ?A memory clobber does not cover automatic storage.
>
> That's a separate problem.
>
>> Btw, I can't see a testcase anywhere so I just assume Andreas got
>> it right as usual.
>
> An asm with live inputs and outputs should never be optimized
> way. If 4.5.1 started doing that it's seriously broken.
Please provide a testcase, such asms can be optimized if the
outputs are dead.
Richard.
> -Andi
>
> --
> [email protected] -- Speaking for myself only.
>
On Nov 8, 2010, at 6:20 AM, Richard Guenther wrote:
> On Mon, Nov 8, 2010 at 12:20 PM, Andi Kleen <[email protected]> wrote:
>> Richard Guenther <[email protected]> writes:
>>
>>> On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen <[email protected]> wrote:
>>>> Andreas Schwab <[email protected]> writes:
>>>>>
>>>>> The asm fails to mention that it modifies *regs.
>>>>
>>>> It has a memory clobber, that should be enough, no?
>>>
>>> No. A memory clobber does not cover automatic storage.
>>
>> That's a separate problem.
>>
>>> Btw, I can't see a testcase anywhere so I just assume Andreas got
>>> it right as usual.
>>
>> An asm with live inputs and outputs should never be optimized
>> way. If 4.5.1 started doing that it's seriously broken.
>
> Please provide a testcase, such asms can be optimized if the
> outputs are dead.
I don't know about 4.5, but I noticed that with 4.6 (trunk), testcasese like gcc.c-torture/compile/20000804-1.c optimize away the asm and all the operand generation except for -O0.
paul
Hi,
On Mon, 8 Nov 2010, Andi Kleen wrote:
> Richard Guenther <[email protected]> writes:
>
> > On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen <[email protected]> wrote:
> >> Andreas Schwab <[email protected]> writes:
> >>>
> >>> The asm fails to mention that it modifies *regs.
> >>
> >> It has a memory clobber, that should be enough, no?
> >
> > No. A memory clobber does not cover automatic storage.
>
> That's a separate problem.
>
> > Btw, I can't see a testcase anywhere so I just assume Andreas got
> > it right as usual.
>
> An asm with live inputs and outputs should never be optimized
> way. If 4.5.1 started doing that it's seriously broken.
You know the drill: testcase -> gcc.gnu.org/bugzilla/
(In particular up to now it's only speculation in some forum that the asm
really is optimized away, which I agree would be a bug, or if it isn't
merely that regs->eax isn't reloaded after the asm(), which would be
caused by the problem Andreas mentioned)
Ciao,
Michael.
On Mon, Nov 08, 2010 at 06:47:59AM -0500, Paul Koning wrote:
> I don't know about 4.5, but I noticed that with 4.6 (trunk), testcasese
> like gcc.c-torture/compile/20000804-1.c optimize away the asm and all the
> operand generation except for -O0.
That's fine, the asm isn't volatile and the output is not used.
Jakub
On 08/11/2010 11:20, Andi Kleen wrote:
> An asm with live inputs and outputs should never be optimized
> way. If 4.5.1 started doing that it's seriously broken.
I don't see that. Consider:
void foo (void)
{
int x, y, z;
x = 23;
y = x + 1;
z = y + 1;
}
So far, you'd agree the compiler may optimise the entire function away? So
why not this:
void foo (void)
{
int x, y, z;
x = 23;
asm ("do something" : "=r" (y) : "r" (x) );
z = y + 1;
}
?
cheers,
DaveK
Hi,
On Mon, 8 Nov 2010, Dave Korn wrote:
> void foo (void)
> {
> int x, y, z;
> x = 23;
> asm ("do something" : "=r" (y) : "r" (x) );
> z = y + 1;
> }
The case in i8k.c really is different. It does use the value by
influencing the return value and the callers use the returned value in
conditionals and the like. It really, really _is_ used :-) and if GCC
removes the asm (which up to now is only speculation) then it's a GCC bug.
The code outlines like so:
int i8k_smm (regs) {
int rc;
asm (... : "=r"(rc) ...);
if (rc != 0 || ...)
return -EINVAL;
return 0;
}
...
struct regs regs = {.eax = ...}
return i8k_smm(regs) ?: regs.eax;
...
My speculation is, that the asm is not removed but rather that regs.eax
isn't reloaded after the asm because the memory clobber doesn't clobber
automatic variables.
Ciao,
Michael.
> My speculation is, that the asm is not removed but rather that regs.eax
> isn't reloaded after the asm because the memory clobber doesn't clobber
> automatic variables.
Yes that makes sense. I wasn't able to verify it so far though.
Maybe the original poster could try the obvious patch
instead of the volatile change.
i8k: tell gcc that regs gets clobbered
Signed-off-by: Andi Kleen <[email protected]>
diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
index 3bc0eef..f3bbf73 100644
--- a/drivers/char/i8k.c
+++ b/drivers/char/i8k.c
@@ -142,7 +142,7 @@ static int i8k_smm(struct smm_regs *regs)
"lahf\n\t"
"shrl $8,%%eax\n\t"
"andl $1,%%eax\n"
- :"=a"(rc)
+ :"=a"(rc), "=m" (*regs)
: "a"(regs)
: "%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");
#else
@@ -167,7 +167,7 @@ static int i8k_smm(struct smm_regs *regs)
"movl %%edx,0(%%eax)\n\t"
"lahf\n\t"
"shrl $8,%%eax\n\t"
- "andl $1,%%eax\n":"=a"(rc)
+ "andl $1,%%eax\n":"=a"(rc), "=m" (*regs)
: "a"(regs)
: "%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");
#endif
-Andi
Andi Kleen <[email protected]> writes:
> @@ -142,7 +142,7 @@ static int i8k_smm(struct smm_regs *regs)
> "lahf\n\t"
> "shrl $8,%%eax\n\t"
> "andl $1,%%eax\n"
> - :"=a"(rc)
> + :"=a"(rc), "=m" (*regs)
I think this should be "+m".
Andreas.
--
Andreas Schwab, [email protected]
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something completely different."
On 11/09/2010 02:57 PM, Andreas Schwab wrote:
> Andi Kleen <[email protected]> writes:
>
>> @@ -142,7 +142,7 @@ static int i8k_smm(struct smm_regs *regs)
>> "lahf\n\t"
>> "shrl $8,%%eax\n\t"
>> "andl $1,%%eax\n"
>> - :"=a"(rc)
>> + :"=a"(rc), "=m" (*regs)
>
> I think this should be "+m".
>
> Andreas.
>
Just tested Andi's patch with Andreas' suggestion to make it +m,
i.e. like attached and can confirm it solves the issue.
Thanks guys,
Jim Bos
More recent GCC caused the i8k driver to stop working, on Slackware
compiler was upgraded from gcc-4.4.4 to gcc-4.5.1 after which it
didn't work anymore, meaning the driver didn't load or gave total
nonsensical output.
As it turned out the asm(..) statement forgot to mention it modifies
the *regs variable.
Credits to Andi Kleen <[email protected]> and Andreas Schwab
<[email protected]> for providing the fix.
Signed-off-by: Jim Bos <[email protected]>
Gcc 4.5.1 running on an amd64 box "cross"-compiling for a P3 i8k fails
to compile the module since commit 6b4e81db2552bad04100e7d5ddeed7e848f53b48
with:
CC drivers/char/i8k.o
drivers/char/i8k.c: In function ‘i8k_smm’:
drivers/char/i8k.c:149:2: error: can't find a register in class ‘GENERAL_REGS’ while reloading ‘asm’
drivers/char/i8k.c:149:2: error: ‘asm’ operand has impossible constraints
-JimC
--
James Cloos <[email protected]> OpenPGP: 1024D/ED7DAEA6
On Sun, Nov 14, 2010 at 4:52 PM, James Cloos <[email protected]> wrote:
> Gcc 4.5.1 running on an amd64 box "cross"-compiling for a P3 i8k fails
> to compile the module since commit 6b4e81db2552bad04100e7d5ddeed7e848f53b48
> with:
>
> ?CC ? ? ?drivers/char/i8k.o
> drivers/char/i8k.c: In function ?i8k_smm?:
> drivers/char/i8k.c:149:2: error: can't find a register in class ?GENERAL_REGS? while reloading ?asm?
> drivers/char/i8k.c:149:2: error: ?asm? operand has impossible constraints
At this point, I think this falls clearly under "unresolvable gcc bug".
Quite frankly, I think gcc was buggy to begin with: since we had a
memory clobber, the "+m" (*regs) should not have mattered. The fact
that "*regs" may be some local variable doesn't make any difference
what-so-ever, since we took the address of the variable. So the memory
clobber _clearly_ can change that variable.
So when Richard Gunther says "a memory clobber doesn't cover automatic
storage", to me that very clearly spells "gcc is buggy as hell".
Because automatic storage with its address taken _very_ much gets
clobbered by things like memset etc. If the compiler doesn't
understand that, the compiler is just broken.
And now, if even the (superfluous) "+m" isn't working, it sounds like
we have no sane options left. Except to say that gcc-4.5.1 is totally
broken wrt asms.
Can we just get gcc to realize that when you pass the address of
automatic storage to an asm, that means that "memory" really does
clobber it? Because clearly that is the case.
Linus
On Sun, Nov 14, 2010 at 07:21:50PM -0800, Linus Torvalds wrote:
> So when Richard Gunther says "a memory clobber doesn't cover automatic
> storage", to me that very clearly spells "gcc is buggy as hell".
> Because automatic storage with its address taken _very_ much gets
> clobbered by things like memset etc. If the compiler doesn't
> understand that, the compiler is just broken.
I'll leave the discussion about meaning of "memory" clobber aside to
Richard,
> And now, if even the (superfluous) "+m" isn't working, it sounds like
> we have no sane options left. Except to say that gcc-4.5.1 is totally
just to say that of course there are sane options left.
:"=a"(rc), "+m" (*regs)
: "a"(regs)
: "%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");
is simply too high register pressure for i386 if you force also
-fno-omit-frame-pointer, there is not a single register left.
Yes, reload should figure out it has address of regs already tied to %eax,
unfortunately starting with IRA it doesn't (I'll file a GCC bug about that;
so that leaves 4.4/4.5/4.6 currently not being able to compile it).
That said, changing the inline asm to just clobber one less register
would be completely sufficient to make it work well with all gccs out there,
just push/pop one of the register around the whole body. I doubt calling
out SMM BIOS is actually so performance critical that one push and one pop
would ruin it. Of course x86_64 version can stay as is, there are enough
registers left...
Jakub
> That said, changing the inline asm to just clobber one less register
> would be completely sufficient to make it work well with all gccs out there,
> just push/pop one of the register around the whole body. I doubt calling
> out SMM BIOS is actually so performance critical that one push and one pop
> would ruin it. Of course x86_64 version can stay as is, there are enough
> registers left...
Yes traditionally clobbering all registers has been dangerous
and it clearly can be done inside the asm too.
Here's a untested patch to do some manual push/pops too. Could someone with
the hardware please test it? (running a 32bit kernel)
-Andi
---
i8k: Clobber less registers
gcc doesn't like inline assembler statements that clobber nearly
all registers. Save a few registers manually on i386 to avoid this
problem.
Fix suggested by Jakub Jelinek
Signed-off-by: Andi Kleen <[email protected]>
diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
index f0863be..a2da38b 100644
--- a/drivers/char/i8k.c
+++ b/drivers/char/i8k.c
@@ -146,7 +146,10 @@ static int i8k_smm(struct smm_regs *regs)
: "a"(regs)
: "%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");
#else
- asm("pushl %%eax\n\t"
+ asm("pushl %%ebx\n\t"
+ "pushl %%ecx\n\t"
+ "pushl %%edx\n\t"
+ "pushl %%eax\n\t"
"movl 0(%%eax),%%edx\n\t"
"push %%edx\n\t"
"movl 4(%%eax),%%ebx\n\t"
@@ -167,10 +170,13 @@ static int i8k_smm(struct smm_regs *regs)
"movl %%edx,0(%%eax)\n\t"
"lahf\n\t"
"shrl $8,%%eax\n\t"
- "andl $1,%%eax\n"
+ "andl $1,%%eax\n\t"
+ "popl %%edx\n\t"
+ "popl %%ecx\n\t"
+ "popl %%ebx\n"
:"=a"(rc), "+m" (*regs)
: "a"(regs)
- : "%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");
+ : "%esi", "%edi", "memory");
#endif
if (rc != 0 || (regs->eax & 0xffff) == 0xffff || regs->eax == eax)
return -EINVAL;
--
[email protected] -- Speaking for myself only.
On Mon, Nov 15, 2010 at 09:56:05AM +0100, Jakub Jelinek wrote:
> Yes, reload should figure out it has address of regs already tied to %eax,
> unfortunately starting with IRA it doesn't (I'll file a GCC bug about that;
http://gcc.gnu.org/PR46479
Jakub
On Mon, Nov 15, 2010 at 09:56:05AM +0100, Jakub Jelinek wrote:
> On Sun, Nov 14, 2010 at 07:21:50PM -0800, Linus Torvalds wrote:
> > So when Richard Gunther says "a memory clobber doesn't cover automatic
> > storage", to me that very clearly spells "gcc is buggy as hell".
> > Because automatic storage with its address taken _very_ much gets
> > clobbered by things like memset etc. If the compiler doesn't
> > understand that, the compiler is just broken.
>
> I'll leave the discussion about meaning of "memory" clobber aside to
> Richard,
And for this the starting point should be what has been requested,
i.e. preprocessed source + gcc options + gcc version and some hints what
actually misbehaves (with the , "+m" (*regs) change reverted)
in gcc bugzilla. Only with that we can actually look at what has been
happening, see whether it is the tree optimizations or RTL and which one
makes a difference.
If I've missed a PR about this I apologize.
Jakub
On Mon, Nov 15, 2010 at 9:56 AM, Jakub Jelinek <[email protected]> wrote:
> On Sun, Nov 14, 2010 at 07:21:50PM -0800, Linus Torvalds wrote:
>> So when Richard Gunther says "a memory clobber doesn't cover automatic
>> storage", to me that very clearly spells "gcc is buggy as hell".
>> Because automatic storage with its address taken _very_ much gets
>> clobbered by things like memset etc. If the compiler doesn't
>> understand that, the compiler is just broken.
>
> I'll leave the discussion about meaning of "memory" clobber aside to
> Richard,
Of course GCC handles memset just fine. Note that I was refering
to non-address taken automatic storage for "memory" (even though
when double-checking the current implementation GCC even thinks
that all address-taken memory is clobbered by asms as soon as
they have at least one memory operand or a "memory" clobber).
It's just that in future we might want to improve this and I think
not covering non-address taken automatic storage for "memory"
is sensible. And I see that you don't see address-taken automatic
storage as a sensible choice to exclude from "memory", and I
have noted that.
Btw, I still haven't seen an testcase for the actual problem we are
talking about.
Richard.
> And for this the starting point should be what has been requested,
> i.e. preprocessed source + gcc options + gcc version and some hints what
> actually misbehaves (with the , "+m" (*regs) change reverted)
> in gcc bugzilla. Only with that we can actually look at what has been
> happening, see whether it is the tree optimizations or RTL and which one
> makes a difference.
> If I've missed a PR about this I apologize.
I tried to file one, but I can't reproduce it currently
(I don't have hardware, so have to rely on code reading and the 32bit
code looks correct to me even without the additional +m)
The preprocessed source is at
http://halobates.de/tmp/i8k.i
Options I used:
-D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -m32 -msoft-float -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium3 -mtune=generic -maccumulate-outgoing-args -Wa,-mtune=generic32 -ffreestanding -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Wframe-larger-than=2048 -fno-stack-protector -fno-omit-frame-pointer -fno-optimize-sibling-calls -pg -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack
-Andi
--
[email protected] -- Speaking for myself only.
On Mon, Nov 15, 2010 at 11:54:46AM +0100, Andi Kleen wrote:
> > And for this the starting point should be what has been requested,
> > i.e. preprocessed source + gcc options + gcc version and some hints what
> > actually misbehaves (with the , "+m" (*regs) change reverted)
> > in gcc bugzilla. Only with that we can actually look at what has been
> > happening, see whether it is the tree optimizations or RTL and which one
> > makes a difference.
> > If I've missed a PR about this I apologize.
>
> I tried to file one, but I can't reproduce it currently
> (I don't have hardware, so have to rely on code reading and the 32bit
> code looks correct to me even without the additional +m)
>
> The preprocessed source is at
> http://halobates.de/tmp/i8k.i
>
> Options I used:
>
> -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -m32 -msoft-float -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium3 -mtune=generic -maccumulate-outgoing-args -Wa,-mtune=generic32 -ffreestanding -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Wframe-larger-than=2048 -fno-stack-protector -fno-omit-frame-pointer -fno-optimize-sibling-calls -pg -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack
Indeed, with this and 4.5.2 20101111 (prerelease) from SVN as well as
gcc-4.5.1-5.fc14:
...
movl %eax, -16(%ebp) # regs, %sfp
movl (%eax), %eax # regs_2(D)->eax,
movl %eax, -20(%ebp) #, %sfp
movl -16(%ebp), %eax # %sfp,
#APP
# 149 "/home/lsrc/git/linux-work2/drivers/char/i8k.c" 1
...
#NO_APP
testl %eax, %eax #
movl $-22, %edx #, D.18378
movl %eax, -24(%ebp) #, %sfp
je .L7 #,
.L2:
movl -12(%ebp), %ebx #,
movl %edx, %eax # D.18378,
movl -8(%ebp), %esi #,
movl -4(%ebp), %edi #,
movl %ebp, %esp #,
popl %ebp #
ret
.p2align 4,,7
.p2align 3
.L7:
movl -16(%ebp), %eax # %sfp,
movl (%eax), %ecx # regs_2(D)->eax, D.18371
cmpw $-1, %cx #, D.18371
je .L2 #,
cmpl %ecx, -20(%ebp) # D.18371, %sfp
cmovne -24(%ebp), %edx # %sfp,, D.18378
jmp .L2 #
.size i8k_smm, .-i8k_smm
I don't see any problems on the assembly level. i8k_smm is
not inlined in this case and checks all 3 conditions.
Guess we need somebody who actually reported the problem, state what
gcc was actually used and post preprocessed source, gcc options
from his case.
Jakub
> Guess we need somebody who actually reported the problem, state what
> gcc was actually used and post preprocessed source, gcc options
> from his case.
Jim Bos,
Can you please supply that?
Please use
rm drivers/char/i8k.o
make V=1 drivers/char/i8k.o
make drivers/char/i8k.i
and supply the .i file and the output of the first make line
Thanks,
-Andi
--
[email protected] -- Speaking for myself only.
On Mon, Nov 15, 2010 at 3:16 AM, Jakub Jelinek <[email protected]> wrote:
>
> I don't see any problems on the assembly level. ?i8k_smm is
> not inlined in this case and checks all 3 conditions.
If it really is related to gcc not understanding that "*regs" has
changed due to the memory being an automatic variable, and passing in
"regs" itself as a pointer to that automatic variable together with
the "memory" clobber not being sufficient, than I think it's the lack
of inlining that will automatically hide the bug.
(Side note: and I think this does show how much of a gcc bug it is not
to consider "memory" together with passing in a pointer to an asm to
always be a clobber).
Because if it isn't inlined, then "regs" will be seen a a real pointer
to some external memory (the caller) rather than being optimized to
just be the auto structure on the stack. Because *mem is auto only
within the context of the caller.
Which actually points to a possible simpler:
- remove the "+m" since it adds too much register pressure
- mark the i8k_smm() as "noinline" instead.
Quite frankly, I'd hate to add even more crud to that inline asm (to
save/restore the registers manually). It's already not the prettiest
thing around.
So does the attached patch work for everybody?
Linus
On 11/15/2010 12:37 PM, Andi Kleen wrote:
>> Guess we need somebody who actually reported the problem, state what
>> gcc was actually used and post preprocessed source, gcc options
>> from his case.
>
> Jim Bos,
> Can you please supply that?
>
> Please use
>
> rm drivers/char/i8k.o
> make V=1 drivers/char/i8k.o
> make drivers/char/i8k.i
>
> and supply the .i file and the output of the first make line
>
> Thanks,
> -Andi
>
Andi,
See attached, note this is the vanilla 2.6.36 i8k.c (without any patch).
And to be 100% sure, if I build this (make drivers/char/i8k.ko) it won't
work.
[ The i8k.i is rather big, even gzipped 80k, not sure if it'll bounce ]
_
Jim
On 11/15/2010 05:04 PM, Linus Torvalds wrote:
> On Mon, Nov 15, 2010 at 3:16 AM, Jakub Jelinek <[email protected]> wrote:
>>
>> I don't see any problems on the assembly level. i8k_smm is
>> not inlined in this case and checks all 3 conditions.
>
> If it really is related to gcc not understanding that "*regs" has
> changed due to the memory being an automatic variable, and passing in
> "regs" itself as a pointer to that automatic variable together with
> the "memory" clobber not being sufficient, than I think it's the lack
> of inlining that will automatically hide the bug.
>
> (Side note: and I think this does show how much of a gcc bug it is not
> to consider "memory" together with passing in a pointer to an asm to
> always be a clobber).
>
> Because if it isn't inlined, then "regs" will be seen a a real pointer
> to some external memory (the caller) rather than being optimized to
> just be the auto structure on the stack. Because *mem is auto only
> within the context of the caller.
>
> Which actually points to a possible simpler:
> - remove the "+m" since it adds too much register pressure
> - mark the i8k_smm() as "noinline" instead.
>
> Quite frankly, I'd hate to add even more crud to that inline asm (to
> save/restore the registers manually). It's already not the prettiest
> thing around.
>
> So does the attached patch work for everybody?
>
> Linus
Hmm, that doesn't work.
[ Not sure if you read to whole thread but initial workaround was to
change the asm(..) to asm volatile(..) which did work. ]
Jim.
On Mon, Nov 15, 2010 at 06:36:06PM +0100, Jim Bos wrote:
> On 11/15/2010 12:37 PM, Andi Kleen wrote:
> See attached, note this is the vanilla 2.6.36 i8k.c (without any patch).
> And to be 100% sure, if I build this (make drivers/char/i8k.ko) it won't
> work.
>
> [ The i8k.i is rather big, even gzipped 80k, not sure if it'll bounce ]
Please also say which exact gcc you are using.
Note, I've compiled it with current 4.5 branch and made the function
always_inline and still didn't see any issues in the *.optimized dump,
regs.eax after the inline asm has always been compared to the constant
that has been stored into regs.eax before the inline asm.
Jakub
On Mon, Nov 15, 2010 at 9:40 AM, Jim Bos <[email protected]> wrote:
>
> Hmm, that doesn't work.
>
> [ Not sure if you read to whole thread but initial workaround was to
> change the asm(..) to asm volatile(..) which did work. ]
Since I have a different gcc than yours (and I'm not going to compile
my own), have you posted your broken .s file anywhere? In fact, with
the noinline (and the removal of the "+m" thing - iow just the patch
you tried), what does just the "i8k_smm" function assembly look like
for you after you've done a "make drivers/char/i8k.s"?
If the asm just doesn't exist AT ALL, that's just odd. Because every
single call-site of i8k_smm() clearly looks at the return value. So
the volatile really shouldn't make any difference from that
standpoint. Odd.
Linus
On 11/15/2010 06:44 PM, Jakub Jelinek wrote:
> On Mon, Nov 15, 2010 at 06:36:06PM +0100, Jim Bos wrote:
>> On 11/15/2010 12:37 PM, Andi Kleen wrote:
>> See attached, note this is the vanilla 2.6.36 i8k.c (without any patch).
>> And to be 100% sure, if I build this (make drivers/char/i8k.ko) it won't
>> work.
>>
>> [ The i8k.i is rather big, even gzipped 80k, not sure if it'll bounce ]
>
> Please also say which exact gcc you are using.
>
> Note, I've compiled it with current 4.5 branch and made the function
> always_inline and still didn't see any issues in the *.optimized dump,
> regs.eax after the inline asm has always been compared to the constant
> that has been stored into regs.eax before the inline asm.
>
> Jakub
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
# gcc -v
Reading specs from /usr/lib/gcc/i486-slackware-linux/4.5.1/specs
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i486-slackware-linux/4.5.1/lto-wrapper
Target: i486-slackware-linux
Configured with: ../gcc-4.5.1/configure --prefix=/usr --libdir=/usr/lib
--mandir=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap
--enable-languages=ada,c,c++,fortran,java,objc --enable-threads=posix
--enable-checking=release --with-system-zlib
--with-python-dir=/lib/python2.6/site-packages
--disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp
--with-gnu-ld --verbose --with-arch=i486 --target=i486-slackware-linux
--build=i486-slackware-linux --host=i486-slackware-linux
Thread model: posix
gcc version 4.5.1 (GCC)
I'm re-reading this thread where I found the asm-> asm volatine suggestion:
https://bbs.archlinux.org/viewtopic.php?pid=752099#p752099
but nobody there reported their gcc version (but apparently first
people started complaining May 1st).
_
Jim
On Mon, Nov 15, 2010 at 07:17:31PM +0100, Jim Bos wrote:
> # gcc -v
> Reading specs from /usr/lib/gcc/i486-slackware-linux/4.5.1/specs
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i486-slackware-linux/4.5.1/lto-wrapper
> Target: i486-slackware-linux
> Configured with: ../gcc-4.5.1/configure --prefix=/usr --libdir=/usr/lib
> --mandir=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap
> --enable-languages=ada,c,c++,fortran,java,objc --enable-threads=posix
> --enable-checking=release --with-system-zlib
> --with-python-dir=/lib/python2.6/site-packages
> --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp
> --with-gnu-ld --verbose --with-arch=i486 --target=i486-slackware-linux
> --build=i486-slackware-linux --host=i486-slackware-linux
> Thread model: posix
> gcc version 4.5.1 (GCC)
Does it have any patches applied? The gcc options look the same as what
I've been already trying earlier.
Thus, can you run gcc with those options on i8k.i and add -fverbose-asm
to make it easier to read and post i8k.s you get?
Jakub
On 11/15/2010 07:08 PM, Linus Torvalds wrote:
> On Mon, Nov 15, 2010 at 9:40 AM, Jim Bos <[email protected]> wrote:
>>
>> Hmm, that doesn't work.
>>
>> [ Not sure if you read to whole thread but initial workaround was to
>> change the asm(..) to asm volatile(..) which did work. ]
>
> Since I have a different gcc than yours (and I'm not going to compile
> my own), have you posted your broken .s file anywhere? In fact, with
> the noinline (and the removal of the "+m" thing - iow just the patch
> you tried), what does just the "i8k_smm" function assembly look like
> for you after you've done a "make drivers/char/i8k.s"?
>
> If the asm just doesn't exist AT ALL, that's just odd. Because every
> single call-site of i8k_smm() clearly looks at the return value. So
> the volatile really shouldn't make any difference from that
> standpoint. Odd.
>
> Linus
>
Attached version with plain 2.6.36 source and version with the committed
patch, i.e with the '"+m" (*regs)'
_
Jim
On 11/15/2010 07:30 PM, Jim Bos wrote:
> On 11/15/2010 07:08 PM, Linus Torvalds wrote:
>> On Mon, Nov 15, 2010 at 9:40 AM, Jim Bos <[email protected]> wrote:
>>>
>>> Hmm, that doesn't work.
>>>
>>> [ Not sure if you read to whole thread but initial workaround was to
>>> change the asm(..) to asm volatile(..) which did work. ]
>>
>> Since I have a different gcc than yours (and I'm not going to compile
>> my own), have you posted your broken .s file anywhere? In fact, with
>> the noinline (and the removal of the "+m" thing - iow just the patch
>> you tried), what does just the "i8k_smm" function assembly look like
>> for you after you've done a "make drivers/char/i8k.s"?
>>
>> If the asm just doesn't exist AT ALL, that's just odd. Because every
>> single call-site of i8k_smm() clearly looks at the return value. So
>> the volatile really shouldn't make any difference from that
>> standpoint. Odd.
>>
>> Linus
>>
>
> Attached version with plain 2.6.36 source and version with the committed
> patch, i.e with the '"+m" (*regs)'
>
>
> _
> Jim
>
>
And I just tried with your noninline patch which results in exactly the
same .s file as with plain 2.6.36 source, i.e. the noninline patch is
not doing anything here.
_
Jim
On 11/07/10 15:41, Andreas Schwab wrote:
> Andi Kleen<[email protected]> writes:
>
>> Jim<[email protected]> writes:
>>
>>> After upgrading my Dell laptop, both OS+kernel the i8k interface was giving
>>> nonsensical output. As it turned out it's not the kernel but compiler
>>> upgrade which broke this.
>>>
>>> Guys at Archlinux have found the underlying cause (but don't seem to have
>>> submitted a patch yet):
>>> https://bbs.archlinux.org/viewtopic.php?pid=780692#p780692
>>> gcc seems to optimize the assembly statements away.
>>>
>>> And indeed, applying this patch makes the i8k interface work again,
>>> i.e. replacing the asm(..) construct by asm volatile(..)
>> The compiler really should not optimize the asm away, because
>> it has both input and output arguments which are later used.
>> "asm volatile" normally just means "don't move significantly"
> The asm fails to mention that it modifies *regs.
But there's a memory clobber, that should be sufficient to indicate
*regs is modified.
jeff
On 11/08/10 03:49, Richard Guenther wrote:
> On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen<[email protected]> wrote:
>> Andreas Schwab<[email protected]> writes:
>>> The asm fails to mention that it modifies *regs.
>> It has a memory clobber, that should be enough, no?
> No. A memory clobber does not cover automatic storage.
A memory clobber should clobber anything in memory, including autos in
memory; if it doesn't, then that seems like a major problem. I'd like
to see the rationale behind not clobbering autos in memory.
Jeff
On Mon, Nov 15, 2010 at 10:30 AM, Jim Bos <[email protected]> wrote:
>
> Attached version with plain 2.6.36 source and version with the committed
> patch, i.e with the '"+m" (*regs)'
Looks 100% identical in i8k_smm() itself, and I'm not seeing anything
bad. The asm has certainly not been optimized away as implied in the
archlinux thread.
There are differences, but they are with code generation *elsewhere*.
To me it is starting to look like the real problem is that gcc has
decided that the "i8k_smm()" function is "__attribute__((const))".
Which is clearly totally bogus. If a function has an inline asm that
has a memory clobber, it is clearly *not* 'const'. But that does
explain the bug, and does explain why "+m" makes a difference and why
"noinline" does not.
So what I _think_ happens is that
- gcc logic for the automatic 'const' attribute for functions is
broken, so it marks that function 'const'.
- since the rule for a const function is that it only _looks_ at its
attributes and has no side effects, now the callers will decide that
'i8k_smm()' cannot change the passed-in structure, so they'll happily
optimize away all the accesses to it.
Linus
On Mon, Nov 15, 2010 at 07:30:35PM +0100, Jim Bos wrote:
> On 11/15/2010 07:08 PM, Linus Torvalds wrote:
> > On Mon, Nov 15, 2010 at 9:40 AM, Jim Bos <[email protected]> wrote:
> >>
> >> Hmm, that doesn't work.
> >>
> >> [ Not sure if you read to whole thread but initial workaround was to
> >> change the asm(..) to asm volatile(..) which did work. ]
> >
> > Since I have a different gcc than yours (and I'm not going to compile
> > my own), have you posted your broken .s file anywhere? In fact, with
> > the noinline (and the removal of the "+m" thing - iow just the patch
> > you tried), what does just the "i8k_smm" function assembly look like
> > for you after you've done a "make drivers/char/i8k.s"?
> >
> > If the asm just doesn't exist AT ALL, that's just odd. Because every
> > single call-site of i8k_smm() clearly looks at the return value. So
> > the volatile really shouldn't make any difference from that
> > standpoint. Odd.
> >
> > Linus
> >
>
> Attached version with plain 2.6.36 source and version with the committed
> patch, i.e with the '"+m" (*regs)'
Thanks, this actually helped to see the problem.
The problem is not inside of i8k_smm, which is not inlined, but in the
callers.
ipa-pure-const.c pass thinks i8k_smm is a pure function, thus
regs = {};
regs.eax = 166;
x = i8k_smm (®s);
if (!x) x = regs.eax;
in the callers is optimized into
regs = {}
regs.eax = 166;
x = i8k_smm (®s);
if (!x) x = 166;
Now, not sure why this happens, as there is
case GIMPLE_ASM:
for (i = 0; i < gimple_asm_nclobbers (stmt); i++)
{
tree op = gimple_asm_clobber_op (stmt, i);
if (simple_cst_equal(TREE_VALUE (op), memory_identifier_string) == 1)
{
if (dump_file)
fprintf (dump_file, " memory asm clobber is not const/pure");
/* Abandon all hope, ye who enter here. */
local->pure_const_state = IPA_NEITHER;
}
}
Debugging...
Jakub
On 11/15/2010 07:26 PM, Jakub Jelinek wrote:
> On Mon, Nov 15, 2010 at 07:17:31PM +0100, Jim Bos wrote:
>> # gcc -v
>> Reading specs from /usr/lib/gcc/i486-slackware-linux/4.5.1/specs
>> COLLECT_GCC=gcc
>> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i486-slackware-linux/4.5.1/lto-wrapper
>> Target: i486-slackware-linux
>> Configured with: ../gcc-4.5.1/configure --prefix=/usr --libdir=/usr/lib
>> --mandir=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap
>> --enable-languages=ada,c,c++,fortran,java,objc --enable-threads=posix
>> --enable-checking=release --with-system-zlib
>> --with-python-dir=/lib/python2.6/site-packages
>> --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp
>> --with-gnu-ld --verbose --with-arch=i486 --target=i486-slackware-linux
>> --build=i486-slackware-linux --host=i486-slackware-linux
>> Thread model: posix
>> gcc version 4.5.1 (GCC)
>
> Does it have any patches applied? The gcc options look the same as what
> I've been already trying earlier.
> Thus, can you run gcc with those options on i8k.i and add -fverbose-asm
> to make it easier to read and post i8k.s you get?
>
> Jakub
>
Slackware is typically not patching much (and I'm just using the
pre-compiled binary). Here is the link to how it's built:
http://slackware.osuosl.org/slackware-current/source/d/gcc/
there doesn't appear to be anything relevant changed.
I already posted the .s files, plain 2.6.36 and the one with working
patch, I =think= that's already using -fverbose-asm, at least that shows
in the output.
_
Jim
On Mon, Nov 15, 2010 at 07:58:48PM +0100, Jakub Jelinek wrote:
> Now, not sure why this happens, as there is
> case GIMPLE_ASM:
> for (i = 0; i < gimple_asm_nclobbers (stmt); i++)
> {
> tree op = gimple_asm_clobber_op (stmt, i);
> if (simple_cst_equal(TREE_VALUE (op), memory_identifier_string) == 1)
> {
> if (dump_file)
> fprintf (dump_file, " memory asm clobber is not const/pure");
> /* Abandon all hope, ye who enter here. */
> local->pure_const_state = IPA_NEITHER;
> }
> }
> Debugging...
Ah, the problem is that memory_identifier_string is only initialized in
ipa-reference.c's initialization, so it can be (and is in this case) NULL in
ipa-pure-const.c.
Two possible fixes (the latter is apparently what is used in
tree-ssa-operands.c, so is probably sufficient). Guess ipa-reference.c
should be changed to do the same and just drop memory_identifier_string.
Jakub
On Mon, Nov 15, 2010 at 10:45 AM, Jeff Law <[email protected]> wrote:
>
> A memory clobber should clobber anything in memory, including autos in
> memory; if it doesn't, then that seems like a major problem. ?I'd like to
> see the rationale behind not clobbering autos in memory.
Yes. It turns out that the "asm optimized away" was entirely wrong (we
never saw that, it was just a report on another mailing list).
Looking at the asm posted, it seems to me that gcc actually compiles
the asm itself 100% correctly, and the "memory" clobber is working
fine inside that function. So the code generated for i8k_smm() itself
is all good.
But _while_ generating the good code, gcc doesn't seem to realize that
it writes to anything, so it decides to mark the function
"__attribute__((const))", which is obviously wrong (a memory clobber
definitely implies that it's not const). And as a result, the callers
will be mis-optimized, because they do things like
static int i8k_get_bios_version(void)
{
struct smm_regs regs = { .eax = I8K_SMM_BIOS_VERSION, };
return i8k_smm(®s) ? : regs.eax;
}
and since gcc has (incorrectly) decided that "i8k_smm()" is a const
function, it thinks that "regs.eax" hasn't changed, so it doesn't
bother to reload it: it "knows" that it is still I8K_SMM_BIOS_VERSION
that it initialized it with. So it will basically have rewritten that
final return statement as
return i8k_smm(®s) ? : I8K_SMM_BIOS_VERSION;
which obviously doesn't really work.
This also explains why adding "volatile" worked. The "asm volatile"
triggered "this is not a const function".
Similarly, the "+m" works, because it also makes clear that the asm is
writing to memory, and isn't a const function.
Now, the "memory" clobber should clearly also have done that, but I'd
be willing to bet that some version of gcc (possibly extra slackware
patches) had forgotten the trivial logic to say "a memory clobber also
makes the user function non-const".
Linus
On Mon, Nov 15, 2010 at 11:12 AM, Jakub Jelinek <[email protected]> wrote:
>
> Ah, the problem is that memory_identifier_string is only initialized in
> ipa-reference.c's initialization, so it can be (and is in this case) NULL in
> ipa-pure-const.c.
Ok. And I guess you can verify that all versions of gcc do this
correctly for "asm volatile"?
Because since we'll have to work around this problem in the kernel, I
suspect the simplest solution is to remove the "+m" that causes
register pressure problems, and then use "asm volatile" to work around
the const-function bug.
And add a large comment about why "asm volatile" is probably always a
good idea when you have a memory clobber and don't have any other
visible memory modifications.
I do wonder if this explains some of the problems we had with the
bitop asms too.
Hmm?
Linus
On Mon, Nov 15, 2010 at 11:21:30AM -0800, Linus Torvalds wrote:
> On Mon, Nov 15, 2010 at 11:12 AM, Jakub Jelinek <[email protected]> wrote:
> >
> > Ah, the problem is that memory_identifier_string is only initialized in
> > ipa-reference.c's initialization, so it can be (and is in this case) NULL in
> > ipa-pure-const.c.
>
> Ok. And I guess you can verify that all versions of gcc do this
> correctly for "asm volatile"?
Yes, reading 4.1/4.2/4.3/4.4/4.5/4.6 code ipa-pure-const.c handles
asm volatile correctly, in each case the function is no longer assumed to be
pure or const in the discovery (of course, user can still say the
function is const or pure). 4.0 and earlier didn't have ipa-pure-const.c.
Using the simplified
extern void abort (void);
__attribute__((noinline)) int
foo (int *p)
{
int r;
asm ("movl $6, (%1)\n\txorl %0, %0" : "=r" (r) : "r" (p) : "memory");
return r;
}
int
main (void)
{
int p = 8;
if ((foo (&p) ? : p) != 6)
abort ();
return 0;
}
testcase shows that in 4.1/4.2/4.3/4.4 this is miscompiled only when using
-fno-ipa-reference, in 4.5 it is miscompiled always when optimizing
unless -fno-ipa-pure-const (as 4.5 added local-pure-const pass which is run
before ipa-reference) and in 4.6 this has been fixed by Honza when
doing ipa cleanups.
> Because since we'll have to work around this problem in the kernel, I
> suspect the simplest solution is to remove the "+m" that causes
> register pressure problems, and then use "asm volatile" to work around
> the const-function bug.
Yes.
Jakub
On 11/15/2010 11:12 AM, Jakub Jelinek wrote:
> - if (simple_cst_equal(TREE_VALUE (op), memory_identifier_string) == 1)
> + if (strcmp (TREE_STRING_POINTER (TREE_VALUE (link)), "memory") == 0)
I prefer this solution. I think memory_identifier_string is over-engineering.
Patch to remove it entirely is pre-approved.
r~
On 11/15/2010 08:51 PM, Jakub Jelinek wrote:
> On Mon, Nov 15, 2010 at 11:21:30AM -0800, Linus Torvalds wrote:
>> On Mon, Nov 15, 2010 at 11:12 AM, Jakub Jelinek <[email protected]> wrote:
>>>
>>> Ah, the problem is that memory_identifier_string is only initialized in
>>> ipa-reference.c's initialization, so it can be (and is in this case) NULL in
>>> ipa-pure-const.c.
>>
>> Ok. And I guess you can verify that all versions of gcc do this
>> correctly for "asm volatile"?
>
> Yes, reading 4.1/4.2/4.3/4.4/4.5/4.6 code ipa-pure-const.c handles
> asm volatile correctly, in each case the function is no longer assumed to be
> pure or const in the discovery (of course, user can still say the
> function is const or pure). 4.0 and earlier didn't have ipa-pure-const.c.
>
> Using the simplified
>
> extern void abort (void);
>
> __attribute__((noinline)) int
> foo (int *p)
> {
> int r;
> asm ("movl $6, (%1)\n\txorl %0, %0" : "=r" (r) : "r" (p) : "memory");
> return r;
> }
>
> int
> main (void)
> {
> int p = 8;
> if ((foo (&p) ? : p) != 6)
> abort ();
> return 0;
> }
>
> testcase shows that in 4.1/4.2/4.3/4.4 this is miscompiled only when using
> -fno-ipa-reference, in 4.5 it is miscompiled always when optimizing
> unless -fno-ipa-pure-const (as 4.5 added local-pure-const pass which is run
> before ipa-reference) and in 4.6 this has been fixed by Honza when
> doing ipa cleanups.
>
>> Because since we'll have to work around this problem in the kernel, I
>> suspect the simplest solution is to remove the "+m" that causes
>> register pressure problems, and then use "asm volatile" to work around
>> the const-function bug.
>
> Yes.
>
> Jakub
>
Linus,
In case you didn't already fixed this, here's the follow-up patch.
---
The fix to work around the gcc miscompiling i8k.c to add "+m (*regs)"
caused register pressure problems. Changing the 'asm' statement to
'asm volatile' instead should prevent that and works around the gcc
bug as well.
Signed-off-by: Jim Bos <[email protected]>
On Mon, Nov 15, 2010 at 7:45 PM, Jeff Law <[email protected]> wrote:
> On 11/08/10 03:49, Richard Guenther wrote:
>>
>> On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen<[email protected]> ?wrote:
>>>
>>> Andreas Schwab<[email protected]> ?writes:
>>>>
>>>> The asm fails to mention that it modifies *regs.
>>>
>>> It has a memory clobber, that should be enough, no?
>>
>> No. ?A memory clobber does not cover automatic storage.
>
> A memory clobber should clobber anything in memory, including autos in
> memory; if it doesn't, then that seems like a major problem. ?I'd like to
> see the rationale behind not clobbering autos in memory.
Non-address taken automatic storage. (note that we don't excercise this
in optimization yet)
It's difficult to model thins kind of non-aliased memory with this kind
of aliasing mechanism (apart from taking all asms as clobbering
everything as we currently do).
Richard.
> Jeff
>
> testcase shows that in 4.1/4.2/4.3/4.4 this is miscompiled only when using
> -fno-ipa-reference, in 4.5 it is miscompiled always when optimizing
> unless -fno-ipa-pure-const (as 4.5 added local-pure-const pass which is run
> before ipa-reference) and in 4.6 this has been fixed by Honza when
> doing ipa cleanups.
Maybe it would be better to simply change the kernel Makefiles to pass
-fno-ipa-pure-const instead of adding volatiles everywhere.
-Andi
On Mon, Nov 15, 2010 at 11:43:22PM +0100, Andi Kleen wrote:
> > testcase shows that in 4.1/4.2/4.3/4.4 this is miscompiled only when using
> > -fno-ipa-reference, in 4.5 it is miscompiled always when optimizing
> > unless -fno-ipa-pure-const (as 4.5 added local-pure-const pass which is run
> > before ipa-reference) and in 4.6 this has been fixed by Honza when
> > doing ipa cleanups.
>
> Maybe it would be better to simply change the kernel Makefiles to pass
> -fno-ipa-pure-const instead of adding volatiles everywhere.
If you do this, please do it for 4.5.[012] only. If you disable all gcc
passes that ever had any bugs in it, you'd need to disable most of them if
not all.
Jakub
On 11/15/10 15:07, Richard Guenther wrote:
> On Mon, Nov 15, 2010 at 7:45 PM, Jeff Law<[email protected]> wrote:
>> On 11/08/10 03:49, Richard Guenther wrote:
>>> On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen<[email protected]> wrote:
>>>> Andreas Schwab<[email protected]> writes:
>>>>> The asm fails to mention that it modifies *regs.
>>>> It has a memory clobber, that should be enough, no?
>>> No. A memory clobber does not cover automatic storage.
>> A memory clobber should clobber anything in memory, including autos in
>> memory; if it doesn't, then that seems like a major problem. I'd like to
>> see the rationale behind not clobbering autos in memory.
> Non-address taken automatic storage. (note that we don't excercise this
> in optimization yet)
If the address of the auto isn't taken, then why is the object in memory
to begin with (with the obvious exception for aggregates).
Jeff
On Mon, Nov 15, 2010 at 11:58 PM, Jeff Law <[email protected]> wrote:
> On 11/15/10 15:07, Richard Guenther wrote:
>>
>> On Mon, Nov 15, 2010 at 7:45 PM, Jeff Law<[email protected]> ?wrote:
>>>
>>> On 11/08/10 03:49, Richard Guenther wrote:
>>>>
>>>> On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen<[email protected]>
>>>> ?wrote:
>>>>>
>>>>> Andreas Schwab<[email protected]> ? ?writes:
>>>>>>
>>>>>> The asm fails to mention that it modifies *regs.
>>>>>
>>>>> It has a memory clobber, that should be enough, no?
>>>>
>>>> No. ?A memory clobber does not cover automatic storage.
>>>
>>> A memory clobber should clobber anything in memory, including autos in
>>> memory; if it doesn't, then that seems like a major problem. ?I'd like to
>>> see the rationale behind not clobbering autos in memory.
>>
>> Non-address taken automatic storage. ?(note that we don't excercise this
>> in optimization yet)
>
> If the address of the auto isn't taken, then why is the object in memory to
> begin with (with the obvious exception for aggregates).
Exactly sort of my point. If people pass the address of &x to an asm
and modify &x + 8 expecting the "adjacent" stack location to be changed
I want to tell them that's not a supported way to get to another stack
variable (even if they clobber "memory"). Or consider the C-decl guy
who wants to access adjacent parameters by address arithmetic on
the address of the first param ...
Richard.
> Jeff
>
On 11/15/10 16:07, Richard Guenther wrote:
>>
>> If the address of the auto isn't taken, then why is the object in memory to
>> begin with (with the obvious exception for aggregates).
> Exactly sort of my point. If people pass the address of&x to an asm
> and modify&x + 8 expecting the "adjacent" stack location to be changed
> I want to tell them that's not a supported way to get to another stack
> variable (even if they clobber "memory"). Or consider the C-decl guy
> who wants to access adjacent parameters by address arithmetic on
> the address of the first param ...
Well, in that case, I think we can easily say that the programmer has
gone off the deep end and has entered the realm of undefined behavior.
Presumably we rooted out all relevant instances of the latter over the
last 20 years... It was fairly common in the past, but I doubt anyone
worth caring about is still writing code assuming they can take the
address of parameter A, offset it and get parameters B, C, D, etc.
jeff
*,
Just applied 2.6.39.1 but my system: 64-bit SLackware, 8GB RAM, MSI mobo
P67A-C45 bios V1.9. previously happily booting via EFI (nice to see
Linux and the other OS actually NOT overwriting each others boot
loaders!) immediately re-booted just after loading the kernel.
Not even a single message is making it on the console, almost immediate
system reset. As I noticed there are several EFI related patches, I
first tried to backout the change to setup.c but that didn't help so
backing out all the efi changes in the 2.6.39.1 patch, i.e. the files:
- arch/x86/kernel/setup.c
- arch/x86/platform/efi/efi.c
- arch/x86/platform/efi/efi_64.c
and sure enough system is booting on 2.6.39.1 with these changes removed.
Attached dmesg+config from the system on 2.6.39.1 =without= the changes
to efi.
Anything I can do to further narrow down what's causing this?
Thanks,
Jim
On Fri, Jun 03, 2011 at 03:05:26PM +0200, Jim Bos wrote:
>
> *,
>
> Just applied 2.6.39.1 but my system: 64-bit SLackware, 8GB RAM, MSI mobo
> P67A-C45 bios V1.9. previously happily booting via EFI (nice to see
> Linux and the other OS actually NOT overwriting each others boot
> loaders!) immediately re-booted just after loading the kernel.
>
> Not even a single message is making it on the console, almost immediate
> system reset. As I noticed there are several EFI related patches, I
> first tried to backout the change to setup.c but that didn't help so
> backing out all the efi changes in the 2.6.39.1 patch, i.e. the files:
> - arch/x86/kernel/setup.c
> - arch/x86/platform/efi/efi.c
> - arch/x86/platform/efi/efi_64.c
> and sure enough system is booting on 2.6.39.1 with these changes removed.
Can you try just reverting
"x86, efi: Retain boot service code until after switching to virtual mode"
? You've got 143 boot services/code regions, which is more than I'd
tested against, so I'm unsure whether we're overflowing something here.
--
Matthew Garrett | [email protected]
On 06/03/2011 03:33 PM, Matthew Garrett wrote:
> On Fri, Jun 03, 2011 at 03:05:26PM +0200, Jim Bos wrote:
>>
>> *,
>>
>> Just applied 2.6.39.1 but my system: 64-bit SLackware, 8GB RAM, MSI mobo
>> P67A-C45 bios V1.9. previously happily booting via EFI (nice to see
>> Linux and the other OS actually NOT overwriting each others boot
>> loaders!) immediately re-booted just after loading the kernel.
>>
>> Not even a single message is making it on the console, almost immediate
>> system reset. As I noticed there are several EFI related patches, I
>> first tried to backout the change to setup.c but that didn't help so
>> backing out all the efi changes in the 2.6.39.1 patch, i.e. the files:
>> - arch/x86/kernel/setup.c
>> - arch/x86/platform/efi/efi.c
>> - arch/x86/platform/efi/efi_64.c
>> and sure enough system is booting on 2.6.39.1 with these changes removed.
>
> Can you try just reverting
>
> "x86, efi: Retain boot service code until after switching to virtual mode"
>
> ? You've got 143 boot services/code regions, which is more than I'd
> tested against, so I'm unsure whether we're overflowing something here.
>
That's seems to be the only EFI patch in 2.6.39.1 and I effectively
removed by =not= applying (skipping) the parts of the 2.6.39.1 patch to
above 3 files.
So yes removing "x86, efi: Retain boot service code until after
switching to virtual mode" indeed fixes the problem for me.
Jim
On Fri, Jun 03, 2011 at 04:26:27PM +0200, Jim Bos wrote:
> On 06/03/2011 03:33 PM, Matthew Garrett wrote:
> > ? You've got 143 boot services/code regions, which is more than I'd
> > tested against, so I'm unsure whether we're overflowing something here.
> >
>
> That's seems to be the only EFI patch in 2.6.39.1 and I effectively
> removed by =not= applying (skipping) the parts of the 2.6.39.1 patch to
> above 3 files.
> So yes removing "x86, efi: Retain boot service code until after
> switching to virtual mode" indeed fixes the problem for me.
Ok, thanks. I'll look into that. Might be best to drop it from stable
for the moment until I've made sure it works on machines with excessive
maps.
--
Matthew Garrett | [email protected]
On 06/03/2011 04:46 PM, Matthew Garrett wrote:
> On Fri, Jun 03, 2011 at 04:26:27PM +0200, Jim Bos wrote:
>> On 06/03/2011 03:33 PM, Matthew Garrett wrote:
>>> ? You've got 143 boot services/code regions, which is more than I'd
>>> tested against, so I'm unsure whether we're overflowing something here.
>>>
>>
>> That's seems to be the only EFI patch in 2.6.39.1 and I effectively
>> removed by =not= applying (skipping) the parts of the 2.6.39.1 patch to
>> above 3 files.
>> So yes removing "x86, efi: Retain boot service code until after
>> switching to virtual mode" indeed fixes the problem for me.
>
> Ok, thanks. I'll look into that. Might be best to drop it from stable
> for the moment until I've made sure it works on machines with excessive
> maps.
>
Matthew,
Another datapoint, just tried a 3.0.0-rc1 kernel, good news is that it
boots. Maybe the "x86, efi: Merge contiguous memory regions of the same
type" helps with these large number of maps?
However, there seems to be something else wrong as I get several "BUG:
Bad page state in process swapper pfn:00000" which have efi functions
on the stack, see dmesg output.
Jim
Hi,
2011/6/5 Jim Bos <[email protected]>:
> On 06/03/2011 04:46 PM, Matthew Garrett wrote:
>> On Fri, Jun 03, 2011 at 04:26:27PM +0200, Jim Bos wrote:
>>> On 06/03/2011 03:33 PM, Matthew Garrett wrote:
>>>> ? You've got 143 boot services/code regions, which is more than I'd
>>>> tested against, so I'm unsure whether we're overflowing something here.
>>>>
>>>
>>> That's seems to be the only EFI patch in 2.6.39.1 and I effectively
>>> removed by =not= applying (skipping) the parts of the 2.6.39.1 patch to
>>> above 3 files.
>>> So yes removing "x86, efi: Retain boot service code until after
>>> switching to virtual mode" indeed fixes the problem for me.
>>
>> Ok, thanks. I'll look into that. Might be best to drop it from stable
>> for the moment until I've made sure it works on machines with excessive
>> maps.
>>
>
> Matthew,
>
> Another datapoint, just tried a 3.0.0-rc1 kernel, good news is that it
> boots. Â Maybe the "x86, efi: Merge contiguous memory regions of the same
> type" helps with these large number of maps?
>
> However, there seems to be something else wrong as I get several "BUG:
> Bad page state in process swapper  pfn:00000" which have efi functions
> on the stack, see dmesg output.
For what it's worth, I have noticed the exact same problems here when
booting 2.6.39.1 on an asrock P67 chipset. The reboot on 2.6.39.1 and
the bag page states. I also noticed some instability with 3.0 with it
freezing up, but that's probably related to broken binary nvidia
drivers.
~Maarten
Hi Matthew,
2011/6/3 Matthew Garrett <[email protected]>:
> On Fri, Jun 03, 2011 at 04:26:27PM +0200, Jim Bos wrote:
>> On 06/03/2011 03:33 PM, Matthew Garrett wrote:
>> > ? You've got 143 boot services/code regions, which is more than I'd
>> > tested against, so I'm unsure whether we're overflowing something here.
>> >
>>
>> That's seems to be the only EFI patch in 2.6.39.1 and I effectively
>> removed by =not= applying (skipping) the parts of the 2.6.39.1 patch to
>> above 3 files.
>> So yes removing "x86, efi: Retain boot service code until after
>> switching to virtual mode" indeed fixes the problem for me.
>
> Ok, thanks. I'll look into that. Might be best to drop it from stable
> for the moment until I've made sure it works on machines with excessive
> maps.
Looking at your patch in 2.6.39.1
I see:
+ memblock_x86_reserve_range(start, start + size, "EFI Boot");
and to free it:
+ free_bootmem_late(start, size);
Maybe this is causing the pager issue on 3.0, can you test this patch?
efi: free memory with the correct call
Commit 916f676f8dc introduced a call to free_bootmem_late while it
reserves memory with memblock_x64_reserve_range
Fix this call to silence the swapper BUGs:
BUG: Bad page state in process swapper pfn:00000
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 0d3a4fa..d2eefaa 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -29,7 +29,6 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/efi.h>
-#include <linux/bootmem.h>
#include <linux/memblock.h>
#include <linux/spinlock.h>
#include <linux/uaccess.h>
@@ -334,7 +333,7 @@ static void __init efi_free_boot_services(void)
md->type != EFI_BOOT_SERVICES_DATA)
continue;
- free_bootmem_late(start, size);
+ memblock_x86_free_memory_in_range(start, start + size);
}
}
--
~Maarten
Hi Jim,
2011/6/3 Jim Bos <[email protected]>:
> On 06/03/2011 03:33 PM, Matthew Garrett wrote:
>> On Fri, Jun 03, 2011 at 03:05:26PM +0200, Jim Bos wrote:
>>>
>>> *,
>>>
>>> Just applied 2.6.39.1 but my system: 64-bit SLackware, 8GB RAM, MSI mobo
>>> P67A-C45 bios V1.9. previously happily booting via EFI (nice to see
>>> Linux and the other OS actually NOT overwriting each others boot
>>> loaders!) immediately re-booted just after loading the kernel.
>>>
>>> Not even a single message is making it on the console, almost immediate
>>> system reset. Â As I noticed there are several EFI related patches, I
>>> first tried to backout the change to setup.c but that didn't help so
>>> backing out all the efi changes in the 2.6.39.1 patch, i.e. the files:
>>> Â - arch/x86/kernel/setup.c
>>> Â - arch/x86/platform/efi/efi.c
>>> Â - arch/x86/platform/efi/efi_64.c
>>> and sure enough system is booting on 2.6.39.1 with these changes removed.
>>
>> Can you try just reverting
>>
>> "x86, efi: Retain boot service code until after switching to virtual mode"
>>
>> ? You've got 143 boot services/code regions, which is more than I'd
>> tested against, so I'm unsure whether we're overflowing something here.
>>
>
> That's seems to be the only EFI patch in 2.6.39.1 and I effectively
> removed by =not= applying (skipping) the parts of the 2.6.39.1 patch to
> above 3 files.
> So yes removing "x86, efi: Retain boot service code until after
> switching to virtual mode" indeed fixes the problem for me.
Does manually applying commit 9cd2b07c1 fix things for 2.6.39.1?
commit is: x86, efi: Consolidate EFI nx control
There will be 1 apply failure, need to change the call to
early_mapping_set_exec in early_runtime_code_mapping_set_exec to
efi_set_executable.
~Maarten
On 06/06/2011 05:01 PM, Maarten Lankhorst wrote:
> Hi Matthew,
>
> 2011/6/3 Matthew Garrett <[email protected]>:
>> On Fri, Jun 03, 2011 at 04:26:27PM +0200, Jim Bos wrote:
>>> On 06/03/2011 03:33 PM, Matthew Garrett wrote:
>>>> ? You've got 143 boot services/code regions, which is more than I'd
>>>> tested against, so I'm unsure whether we're overflowing something here.
>>>>
>>>
>>> That's seems to be the only EFI patch in 2.6.39.1 and I effectively
>>> removed by =not= applying (skipping) the parts of the 2.6.39.1 patch to
>>> above 3 files.
>>> So yes removing "x86, efi: Retain boot service code until after
>>> switching to virtual mode" indeed fixes the problem for me.
>>
>> Ok, thanks. I'll look into that. Might be best to drop it from stable
>> for the moment until I've made sure it works on machines with excessive
>> maps.
>
> Looking at your patch in 2.6.39.1
>
> I see:
> + memblock_x86_reserve_range(start, start + size, "EFI Boot");
>
> and to free it:
> + free_bootmem_late(start, size);
>
> Maybe this is causing the pager issue on 3.0, can you test this patch?
>
>
> efi: free memory with the correct call
>
> Commit 916f676f8dc introduced a call to free_bootmem_late while it
> reserves memory with memblock_x64_reserve_range
> Fix this call to silence the swapper BUGs:
>
> BUG: Bad page state in process swapper pfn:00000
>
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 0d3a4fa..d2eefaa 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -29,7 +29,6 @@
> #include <linux/kernel.h>
> #include <linux/init.h>
> #include <linux/efi.h>
> -#include <linux/bootmem.h>
> #include <linux/memblock.h>
> #include <linux/spinlock.h>
> #include <linux/uaccess.h>
> @@ -334,7 +333,7 @@ static void __init efi_free_boot_services(void)
> md->type != EFI_BOOT_SERVICES_DATA)
> continue;
>
> - free_bootmem_late(start, size);
> + memblock_x86_free_memory_in_range(start, start + size);
> }
> }
>
>
> --
> ~Maarten
>
For me that indeed gets rid of the "BUG Bad page state...", ie. all is
fine on 3.0-rc1 with this patch on top.
Tested-By: Jim Bos <[email protected]>
Jim.
On Mon, Jun 06, 2011 at 05:01:58PM +0200, Maarten Lankhorst wrote:
> Maybe this is causing the pager issue on 3.0, can you test this patch?
Looks good to me. Can you post this to x86@ ?
--
Matthew Garrett | [email protected]
On 06/06/2011 05:27 PM, Maarten Lankhorst wrote:
> Hi Jim,
>
> 2011/6/3 Jim Bos <[email protected]>:
>> On 06/03/2011 03:33 PM, Matthew Garrett wrote:
>>> On Fri, Jun 03, 2011 at 03:05:26PM +0200, Jim Bos wrote:
>>>>
>>>> *,
>>>>
>>>> Just applied 2.6.39.1 but my system: 64-bit SLackware, 8GB RAM, MSI mobo
>>>> P67A-C45 bios V1.9. previously happily booting via EFI (nice to see
>>>> Linux and the other OS actually NOT overwriting each others boot
>>>> loaders!) immediately re-booted just after loading the kernel.
>>>>
>>>> Not even a single message is making it on the console, almost immediate
>>>> system reset. As I noticed there are several EFI related patches, I
>>>> first tried to backout the change to setup.c but that didn't help so
>>>> backing out all the efi changes in the 2.6.39.1 patch, i.e. the files:
>>>> - arch/x86/kernel/setup.c
>>>> - arch/x86/platform/efi/efi.c
>>>> - arch/x86/platform/efi/efi_64.c
>>>> and sure enough system is booting on 2.6.39.1 with these changes removed.
>>>
>>> Can you try just reverting
>>>
>>> "x86, efi: Retain boot service code until after switching to virtual mode"
>>>
>>> ? You've got 143 boot services/code regions, which is more than I'd
>>> tested against, so I'm unsure whether we're overflowing something here.
>>>
>>
>> That's seems to be the only EFI patch in 2.6.39.1 and I effectively
>> removed by =not= applying (skipping) the parts of the 2.6.39.1 patch to
>> above 3 files.
>> So yes removing "x86, efi: Retain boot service code until after
>> switching to virtual mode" indeed fixes the problem for me.
> Does manually applying commit 9cd2b07c1 fix things for 2.6.39.1?
> commit is: x86, efi: Consolidate EFI nx control
>
> There will be 1 apply failure, need to change the call to
> early_mapping_set_exec in early_runtime_code_mapping_set_exec to
> efi_set_executable.
>
> ~Maarten
>
Maarten,
Yes that boots, but with the "BUG Bad page state .." as well (so would
need you other patch).
Jim
Hi Jim,
Op 06-06-11 18:11, Jim Bos schreef:
> On 06/06/2011 05:27 PM, Maarten Lankhorst wrote:
>> Hi Jim,
>>
>> 2011/6/3 Jim Bos <[email protected]>:
>>> On 06/03/2011 03:33 PM, Matthew Garrett wrote:
>>>> On Fri, Jun 03, 2011 at 03:05:26PM +0200, Jim Bos wrote:
>>>>> *,
>>>>>
>>>>> Just applied 2.6.39.1 but my system: 64-bit SLackware, 8GB RAM, MSI mobo
>>>>> P67A-C45 bios V1.9. previously happily booting via EFI (nice to see
>>>>> Linux and the other OS actually NOT overwriting each others boot
>>>>> loaders!) immediately re-booted just after loading the kernel.
>>>>>
>>>>> Not even a single message is making it on the console, almost immediate
>>>>> system reset. As I noticed there are several EFI related patches, I
>>>>> first tried to backout the change to setup.c but that didn't help so
>>>>> backing out all the efi changes in the 2.6.39.1 patch, i.e. the files:
>>>>> - arch/x86/kernel/setup.c
>>>>> - arch/x86/platform/efi/efi.c
>>>>> - arch/x86/platform/efi/efi_64.c
>>>>> and sure enough system is booting on 2.6.39.1 with these changes removed.
>>>> Can you try just reverting
>>>>
>>>> "x86, efi: Retain boot service code until after switching to virtual mode"
>>>>
>>>> ? You've got 143 boot services/code regions, which is more than I'd
>>>> tested against, so I'm unsure whether we're overflowing something here.
>>>>
>>> That's seems to be the only EFI patch in 2.6.39.1 and I effectively
>>> removed by =not= applying (skipping) the parts of the 2.6.39.1 patch to
>>> above 3 files.
>>> So yes removing "x86, efi: Retain boot service code until after
>>> switching to virtual mode" indeed fixes the problem for me.
>> Does manually applying commit 9cd2b07c1 fix things for 2.6.39.1?
>> commit is: x86, efi: Consolidate EFI nx control
>>
>> There will be 1 apply failure, need to change the call to
>> early_mapping_set_exec in early_runtime_code_mapping_set_exec to
>> efi_set_executable.
>>
>> ~Maarten
>>
> Maarten,
>
> Yes that boots, but with the "BUG Bad page state .." as well (so would
> need you other patch).
>
> Jim
So the options are applying that patch + free fix to stable,
or revert the change. Also looking at the comments of the
original patch, it seems it was changed because of Yinghai's comments:
> No, at that point memblock is not used any more. after mm_init()/mem_init()
> need to use free_bootmem_late() in free_efi_boot_services
But that appears to have been incorrect now, seeing that
commit 774ea0bcb27f57b removed that transition
~Maarten
On Mon, Jun 6, 2011 at 9:43 AM, Maarten Lankhorst
<[email protected]> wrote:
> Hi Jim,
>
> Op 06-06-11 18:11, Jim Bos schreef:
>> On 06/06/2011 05:27 PM, Maarten Lankhorst wrote:
>>> Hi Jim,
>>>
>>> 2011/6/3 Jim Bos <[email protected]>:
>>>> On 06/03/2011 03:33 PM, Matthew Garrett wrote:
>>>>> On Fri, Jun 03, 2011 at 03:05:26PM +0200, Jim Bos wrote:
>>>>>> *,
>>>>>>
>>>>>> Just applied 2.6.39.1 but my system: 64-bit SLackware, 8GB RAM, MSI mobo
>>>>>> P67A-C45 bios V1.9. previously happily booting via EFI (nice to see
>>>>>> Linux and the other OS actually NOT overwriting each others boot
>>>>>> loaders!) immediately re-booted just after loading the kernel.
>>>>>>
>>>>>> Not even a single message is making it on the console, almost immediate
>>>>>> system reset. ?As I noticed there are several EFI related patches, I
>>>>>> first tried to backout the change to setup.c but that didn't help so
>>>>>> backing out all the efi changes in the 2.6.39.1 patch, i.e. the files:
>>>>>> ?- arch/x86/kernel/setup.c
>>>>>> ?- arch/x86/platform/efi/efi.c
>>>>>> ?- arch/x86/platform/efi/efi_64.c
>>>>>> and sure enough system is booting on 2.6.39.1 with these changes removed.
>>>>> Can you try just reverting
>>>>>
>>>>> "x86, efi: Retain boot service code until after switching to virtual mode"
>>>>>
>>>>> ? You've got 143 boot services/code regions, which is more than I'd
>>>>> tested against, so I'm unsure whether we're overflowing something here.
>>>>>
>>>> That's seems to be the only EFI patch in 2.6.39.1 and I effectively
>>>> removed by =not= applying (skipping) the parts of the 2.6.39.1 patch to
>>>> above 3 files.
>>>> So yes removing "x86, efi: Retain boot service code until after
>>>> switching to virtual mode" indeed fixes the problem for me.
>>> Does manually applying commit 9cd2b07c1 fix things for 2.6.39.1?
>>> commit is: x86, efi: Consolidate EFI nx control
>>>
>>> There will be 1 apply ?failure, need to change the call to
>>> early_mapping_set_exec in early_runtime_code_mapping_set_exec to
>>> efi_set_executable.
>>>
>>> ~Maarten
>>>
>> Maarten,
>>
>> Yes that boots, but with the "BUG Bad page state .." as well (so would
>> need you other patch).
that is not right fix.
>>
>> Jim
> So the options are applying that patch + free fix to stable,
> or revert the change. Also looking at the comments of the
> original patch, it seems it was changed because of Yinghai's comments:
>> No, at that point memblock is not used any more. after mm_init()/mem_init()
>> need to use free_bootmem_late() in free_efi_boot_services
>
> But that appears to have been incorrect now, seeing that
> commit 774ea0bcb27f57b removed that transition
free_bootmem_late() mean free early reserved pages (from memblock or
bootmem) after slab is available.
assume EFI in ram is not page-aligned?
Thanks
Yinghai Lu
On Mon, Jun 06, 2011 at 05:19:17PM -0700, Yinghai Lu wrote:
> assume EFI in ram is not page-aligned?
They'll be 4K aligned at least.
--
Matthew Garrett | [email protected]
On 06/06/2011 06:41 PM, Matthew Garrett wrote:
> On Mon, Jun 06, 2011 at 05:19:17PM -0700, Yinghai Lu wrote:
>
>> assume EFI in ram is not page-aligned?
>
> They'll be 4K aligned at least.
>
can you get boot log with "memblock=debug"?
wonder if
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 4be9b39..c6724e4 100644 (file)
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -912,6 +912,13 @@ void __init setup_arch(char **cmdline_p)
memblock.current_limit = get_max_mapped();
memblock_x86_fill();
+ /*
+ * The EFI specification says that boot service code won't be called
+ * after ExitBootServices(). This is, in fact, a lie.
+ */
+ if (efi_enabled)
+ efi_reserve_boot_services(
wonder if double memblock ram array in memblock_x86_fill() that is overlapping with boot services.
Thanks
Yinghai
Hi,
Op 07-06-11 04:05, Yinghai Lu schreef:
> On 06/06/2011 06:41 PM, Matthew Garrett wrote:
>> On Mon, Jun 06, 2011 at 05:19:17PM -0700, Yinghai Lu wrote:
>>
>>> assume EFI in ram is not page-aligned?
>> They'll be 4K aligned at least.
>>
>
> can you get boot log with "memblock=debug"?
>
> wonder if
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 4be9b39..c6724e4 100644 (file)
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -912,6 +912,13 @@ void __init setup_arch(char **cmdline_p)
> memblock.current_limit = get_max_mapped();
> memblock_x86_fill();
>
> + /*
> + * The EFI specification says that boot service code won't be called
> + * after ExitBootServices(). This is, in fact, a lie.
> + */
> + if (efi_enabled)
> + efi_reserve_boot_services(
>
> wonder if double memblock ram array in memblock_x86_fill() that is overlapping with boot services.
Seems that numa's NODE_DATA beats the boot services to reserving the boot block, and it's already being reserved. Kinda makes my previous patch miss the point. :-)
Is moving efi_reserve_boot_memory to inside efi_init(); allowed?
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.0.0-rc1-patser+ ([email protected]) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) ) #27 SMP PREEMPT Tue Jun 7 09:49:18 CEST 2011
[ 0.000000] Command line: ro rootflags=ssd,discard root=/dev/sdb2 devtmpfs.mount=1 video=efifb reboot=a,e,p init=/init quiet splash vt.handoff=7 memblock=debug
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000100 - 00000000000a0000 (usable)
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000befa5000 (usable)
[ 0.000000] BIOS-e820: 00000000befa5000 - 00000000bf2c0000 (reserved)
[ 0.000000] BIOS-e820: 00000000bf2c0000 - 00000000bf311000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000bf311000 - 00000000bf60c000 (reserved)
[ 0.000000] BIOS-e820: 00000000bf60c000 - 00000000bf60d000 (usable)
[ 0.000000] BIOS-e820: 00000000bf60d000 - 00000000bf60e000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000bf60e000 - 00000000bf618000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000bf618000 - 00000000bf63d000 (reserved)
[ 0.000000] BIOS-e820: 00000000bf63d000 - 00000000bf680000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000bf680000 - 00000000bf800000 (usable)
[ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed40000 (reserved)
[ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
[ 0.000000] BIOS-e820: 0000000100000000 - 000000023f800000 (usable)
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] DMI not present or invalid.
[ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
[ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
[ 0.000000] No AGP bridge found
[ 0.000000] last_pfn = 0x23f800 max_arch_pfn = 0x400000000
[ 0.000000] MTRR default type: uncachable
[ 0.000000] MTRR fixed ranges enabled:
[ 0.000000] 00000-9FFFF write-back
[ 0.000000] A0000-BFFFF uncachable
[ 0.000000] C0000-CFFFF write-protect
[ 0.000000] D0000-DFFFF uncachable
[ 0.000000] E0000-E7FFF write-through
[ 0.000000] E8000-FFFFF write-protect
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 base 000000000 mask E00000000 write-back
[ 0.000000] 1 base 200000000 mask FC0000000 write-back
[ 0.000000] 2 base 0C0000000 mask FC0000000 uncachable
[ 0.000000] 3 base 23F800000 mask FFF800000 uncachable
[ 0.000000] 4 disabled
[ 0.000000] 5 disabled
[ 0.000000] 6 disabled
[ 0.000000] 7 disabled
[ 0.000000] 8 disabled
[ 0.000000] 9 disabled
[ 0.000000] x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106
[ 0.000000] e820 update range: 00000000c0000000 - 0000000100000000 (usable) ==> (reserved)
[ 0.000000] last_pfn = 0xbf800 max_arch_pfn = 0x400000000
[ 0.000000] found SMP MP-table at [ffff8800000fcf50] fcf50
[ 0.000000] memblock_x86_reserve_range: [0x000fcf50-0x000fcf5f] * MP-table mpf
[ 0.000000] memblock_x86_reserve_range: [0x000fcbf0-0x000fced3] * MP-table mpc
[ 0.000000] MEMBLOCK configuration:
[ 0.000000] memory size = 0x1fe8b6000
[ 0.000000] memory.cnt = 0x5
[ 0.000000] memory[0x0] [0x00000000010000-0x0000000009ffff], 0x90000 bytes
[ 0.000000] memory[0x1] [0x00000000100000-0x000000befa4fff], 0xbeea5000 bytes
[ 0.000000] memory[0x2] [0x000000bf60c000-0x000000bf60cfff], 0x1000 bytes
[ 0.000000] memory[0x3] [0x000000bf680000-0x000000bf7fffff], 0x180000 bytes
[ 0.000000] memory[0x4] [0x00000100000000-0x0000023f7fffff], 0x13f800000 bytes
[ 0.000000] reserved.cnt = 0x2
[ 0.000000] reserved[0x0] [0x0000000009d800-0x000000000fffff], 0x62800 bytes
[ 0.000000] reserved[0x1] [0x00000001000000-0x00000001c67fff], 0xc68000 bytes
[ 0.000000] initial memory mapped : 0 - 20000000
[ 0.000000] memblock_x86_reserve_range: [0x00098000-0x0009cfff] TRAMPOLINE
[ 0.000000] Base memory trampoline at [ffff880000098000] 98000 size 20480
[ 0.000000] init_memory_mapping: 0000000000000000-00000000bf800000
[ 0.000000] 0000000000 - 00bf800000 page 2M
[ 0.000000] kernel direct mapping tables up to bf800000 @ bf7fc000-bf800000
[ 0.000000] memblock_x86_reserve_range: [0xbf7fc000-0xbf7fdfff] PGTABLE
[ 0.000000] init_memory_mapping: 0000000100000000-000000023f800000
[ 0.000000] 0100000000 - 023f800000 page 2M
[ 0.000000] kernel direct mapping tables up to 23f800000 @ 23f7f6000-23f800000
[ 0.000000] memblock_x86_reserve_range: [0x23f7f6000-0x23f7fafff] PGTABLE
[ 0.000000] ACPI: RSDP 00000000000fcf60 00024 (v02 ALASKA)
[ 0.000000] ACPI: XSDT 00000000bf309070 0005C (v01 ALASKA A M I 01072009 AMI 00010013)
[ 0.000000] ACPI: FACP 00000000bf310048 000F4 (v04 ALASKA A M I 01072009 AMI 00010013)
[ 0.000000] ACPI: DSDT 00000000bf309158 06EED (v02 ALASKA A M I 00000000 INTL 20051117)
[ 0.000000] ACPI: FACS 00000000bf60ff80 00040
[ 0.000000] ACPI: APIC 00000000bf310140 00072 (v03 ALASKA A M I 01072009 AMI 00010013)
[ 0.000000] ACPI: SSDT 00000000bf3101b8 00102 (v01 AMICPU PROC 00000001 MSFT 03000001)
[ 0.000000] ACPI: MCFG 00000000bf3102c0 0003C (v01 ALASKA A M I 01072009 MSFT 00000097)
[ 0.000000] ACPI: AAFT 00000000bf310300 0006F (v01 ALASKA OEMAAFT 01072009 MSFT 00000097)
[ 0.000000] ACPI: HPET 00000000bf310370 00038 (v01 ALASKA A M I 01072009 AMI. 00000004)
[ 0.000000] ACPI: DMAR 00000000bf3103a8 000B0 (v01 ALASKA A M I 00000001 INTL 00000001)
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] No NUMA configuration found
[ 0.000000] Faking a node at 0000000000000000-000000023f800000
[ 0.000000] Initmem setup node 0 0000000000000000-000000023f800000
[ 0.000000] memblock_x86_reserve_range: [0x23f7fb000-0x23f7fffff] NODE_DATA
[ 0.000000] NODE_DATA [000000023f7fb000 - 000000023f7fffff]
[ 0.000000] memblock_x86_reserve_range: [0x23f7f5000-0x23f7f5fff] BOOTMEM
[ 0.000000] memblock_x86_reserve_range: [0x23f3f5000-0x23f7f4fff] BOOTMEM
[ 0.000000] memblock_x86_reserve_range: [0x23f3f4a00-0x23f3f4fff] BOOTMEM
[ 0.000000] memblock_x86_reserve_range: [0x23eff4a00-0x23f3f49ff] BOOTMEM
[ 0.000000] memblock_x86_reserve_range: [0x236e00000-0x23edfffff] BOOTMEM
[ 0.000000] memblock_x86_reserve_range: [0x23eff3000-0x23eff3fff] BOOTMEM
[ 0.000000] memblock_x86_reserve_range: [0x23eff2000-0x23eff2fff] BOOTMEM
[ 0.000000] memblock_x86_free_range: [0x23de00000-0x23edfffff]
[ 0.000000] [ffffea0000000000-ffffea0007dfffff] PMD -> [ffff880236e00000-ffff88023ddfffff] on node 0
[ 0.000000] memblock_x86_free_range: [0x23eff4a00-0x23f3f49ff]
[ 0.000000] memblock_x86_free_range: [0x23f3f5000-0x23f7f4fff]
~Maarten
Hi,
Op 07-06-11 04:05, Yinghai Lu schreef:
> On 06/06/2011 06:41 PM, Matthew Garrett wrote:
>> On Mon, Jun 06, 2011 at 05:19:17PM -0700, Yinghai Lu wrote:
>>
>>> assume EFI in ram is not page-aligned?
>> They'll be 4K aligned at least.
>>
>
> can you get boot log with "memblock=debug"?
Well that definitely helped me isolate things. It seems some ranges are reserved already.
I added a simple patch to ignore the reservations there. Just a proof of concept,
don't rate for style. :-)
diff --git a/arch/x86/mm/memblock.c b/arch/x86/mm/memblock.c
index aa11693..013ecf5 100644
--- a/arch/x86/mm/memblock.c
+++ b/arch/x86/mm/memblock.c
@@ -8,7 +8,7 @@
#include <linux/range.h>
/* Check for already reserved areas */
-static bool __init check_with_memblock_reserved_size(u64 *addrp, u64 *sizep, u64 align)
+bool __init check_with_memblock_reserved_size(u64 *addrp, u64 *sizep, u64 align)
{
struct memblock_region *r;
u64 addr = *addrp, last;
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 0d3a4fa..eb3a4d9 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -304,20 +304,29 @@ static void __init print_efi_memmap(void)
}
#endif /* EFI_DEBUG */
+extern bool __init check_with_memblock_reserved_size(u64 *addrp,
+ u64 *sizep,
+ u64 align);
+
void __init efi_reserve_boot_services(void)
{
void *p;
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
efi_memory_desc_t *md = p;
- unsigned long long start = md->phys_addr;
- unsigned long long size = md->num_pages << EFI_PAGE_SHIFT;
+ u64 start = md->phys_addr;
+ u64 size = md->num_pages << EFI_PAGE_SHIFT;
if (md->type != EFI_BOOT_SERVICES_CODE &&
md->type != EFI_BOOT_SERVICES_DATA)
continue;
-
- memblock_x86_reserve_range(start, start + size, "EFI Boot");
+ if (check_with_memblock_reserved_size(&start, &size, 1<<EFI_PAGE_SHIFT)) {
+ /* Could not reserve, skip it */
+ md->num_pages = 0;
+ printk(KERN_INFO PFX "Could not reserve boot area "
+ "[0x%llx - 0x%llx]\n", start, start+size);
+ } else
+ memblock_x86_reserve_range(start, start+size, "EFI Boot");
}
}
@@ -334,6 +343,10 @@ static void __init efi_free_boot_services(void)
md->type != EFI_BOOT_SERVICES_DATA)
continue;
+ /* Could not reserve boot area */
+ if (size)
+ continue;
+
free_bootmem_late(start, size);
}
}
Op 07-06-11 11:08, Maarten Lankhorst schreef:
> Hi,
>
> Op 07-06-11 04:05, Yinghai Lu schreef:
>> On 06/06/2011 06:41 PM, Matthew Garrett wrote:
>>> On Mon, Jun 06, 2011 at 05:19:17PM -0700, Yinghai Lu wrote:
>>>
>>>> assume EFI in ram is not page-aligned?
>>> They'll be 4K aligned at least.
>>>
>> can you get boot log with "memblock=debug"?
> Well that definitely helped me isolate things. It seems some ranges are reserved already.
> I added a simple patch to ignore the reservations there. Just a proof of concept,
> don't rate for style. :-)
>
> @@ -334,6 +343,10 @@ static void __init efi_free_boot_services(void)
> md->type != EFI_BOOT_SERVICES_DATA)
> continue;
>
> + /* Could not reserve boot area */
> + if (size)
Oops.
> + continue;
> +
> free_bootmem_late(start, size);
> }
> }
>
>
It seems the error still occurs when calling free_bootmem_late
even if I only reserve blocks that haven't been reserved yet.
~Maarten
On 06/07/2011 01:25 AM, Maarten Lankhorst wrote:
> Hi,
>
> Op 07-06-11 04:05, Yinghai Lu schreef:
>> On 06/06/2011 06:41 PM, Matthew Garrett wrote:
>>> On Mon, Jun 06, 2011 at 05:19:17PM -0700, Yinghai Lu wrote:
>>>
>>>> assume EFI in ram is not page-aligned?
>>> They'll be 4K aligned at least.
>>>
>>
>> can you get boot log with "memblock=debug"?
>>
>> wonder if
>>
>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>> index 4be9b39..c6724e4 100644 (file)
>> --- a/arch/x86/kernel/setup.c
>> +++ b/arch/x86/kernel/setup.c
>> @@ -912,6 +912,13 @@ void __init setup_arch(char **cmdline_p)
>> memblock.current_limit = get_max_mapped();
>> memblock_x86_fill();
>>
>> + /*
>> + * The EFI specification says that boot service code won't be called
>> + * after ExitBootServices(). This is, in fact, a lie.
>> + */
>> + if (efi_enabled)
>> + efi_reserve_boot_services(
>>
>> wonder if double memblock ram array in memblock_x86_fill() that is overlapping with boot services.
> Seems that numa's NODE_DATA beats the boot services to reserving the boot block, and it's already being reserved. Kinda makes my previous patch miss the point. :-)
NODE_DATA are get allocated from initmem_init() and it is rather later after efi_reserve_boot_services()
>
> Is moving efi_reserve_boot_memory to inside efi_init(); allowed?
no, memblock reserved array can not be resized yet at that point, so if you have too many entries for efi entries, will have problem.
>
> [ 0.000000] Initializing cgroup subsys cpuset
> [ 0.000000] Initializing cgroup subsys cpu
> [ 0.000000] Linux version 3.0.0-rc1-patser+ ([email protected]) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) ) #27 SMP PREEMPT Tue Jun 7 09:49:18 CEST 2011
> [ 0.000000] Command line: ro rootflags=ssd,discard root=/dev/sdb2 devtmpfs.mount=1 video=efifb reboot=a,e,p init=/init quiet splash vt.handoff=7 memblock=debug
> [ 0.000000] BIOS-provided physical RAM map:
> [ 0.000000] BIOS-e820: 0000000000000100 - 00000000000a0000 (usable)
> [ 0.000000] BIOS-e820: 0000000000100000 - 00000000befa5000 (usable)
> [ 0.000000] BIOS-e820: 00000000befa5000 - 00000000bf2c0000 (reserved)
> [ 0.000000] BIOS-e820: 00000000bf2c0000 - 00000000bf311000 (ACPI NVS)
> [ 0.000000] BIOS-e820: 00000000bf311000 - 00000000bf60c000 (reserved)
> [ 0.000000] BIOS-e820: 00000000bf60c000 - 00000000bf60d000 (usable)
> [ 0.000000] BIOS-e820: 00000000bf60d000 - 00000000bf60e000 (ACPI data)
> [ 0.000000] BIOS-e820: 00000000bf60e000 - 00000000bf618000 (ACPI NVS)
> [ 0.000000] BIOS-e820: 00000000bf618000 - 00000000bf63d000 (reserved)
> [ 0.000000] BIOS-e820: 00000000bf63d000 - 00000000bf680000 (ACPI NVS)
> [ 0.000000] BIOS-e820: 00000000bf680000 - 00000000bf800000 (usable)
> [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed40000 (reserved)
> [ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
> [ 0.000000] BIOS-e820: 0000000100000000 - 000000023f800000 (usable)
> [ 0.000000] NX (Execute Disable) protection: active
> [ 0.000000] DMI not present or invalid.
> [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
> [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
> [ 0.000000] No AGP bridge found
> [ 0.000000] last_pfn = 0x23f800 max_arch_pfn = 0x400000000
> [ 0.000000] MTRR default type: uncachable
> [ 0.000000] MTRR fixed ranges enabled:
> [ 0.000000] 00000-9FFFF write-back
> [ 0.000000] A0000-BFFFF uncachable
> [ 0.000000] C0000-CFFFF write-protect
> [ 0.000000] D0000-DFFFF uncachable
> [ 0.000000] E0000-E7FFF write-through
> [ 0.000000] E8000-FFFFF write-protect
> [ 0.000000] MTRR variable ranges enabled:
> [ 0.000000] 0 base 000000000 mask E00000000 write-back
> [ 0.000000] 1 base 200000000 mask FC0000000 write-back
> [ 0.000000] 2 base 0C0000000 mask FC0000000 uncachable
> [ 0.000000] 3 base 23F800000 mask FFF800000 uncachable
> [ 0.000000] 4 disabled
> [ 0.000000] 5 disabled
> [ 0.000000] 6 disabled
> [ 0.000000] 7 disabled
> [ 0.000000] 8 disabled
> [ 0.000000] 9 disabled
> [ 0.000000] x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106
> [ 0.000000] e820 update range: 00000000c0000000 - 0000000100000000 (usable) ==> (reserved)
> [ 0.000000] last_pfn = 0xbf800 max_arch_pfn = 0x400000000
> [ 0.000000] found SMP MP-table at [ffff8800000fcf50] fcf50
> [ 0.000000] memblock_x86_reserve_range: [0x000fcf50-0x000fcf5f] * MP-table mpf
> [ 0.000000] memblock_x86_reserve_range: [0x000fcbf0-0x000fced3] * MP-table mpc
> [ 0.000000] MEMBLOCK configuration:
> [ 0.000000] memory size = 0x1fe8b6000
> [ 0.000000] memory.cnt = 0x5
> [ 0.000000] memory[0x0] [0x00000000010000-0x0000000009ffff], 0x90000 bytes
> [ 0.000000] memory[0x1] [0x00000000100000-0x000000befa4fff], 0xbeea5000 bytes
> [ 0.000000] memory[0x2] [0x000000bf60c000-0x000000bf60cfff], 0x1000 bytes
> [ 0.000000] memory[0x3] [0x000000bf680000-0x000000bf7fffff], 0x180000 bytes
> [ 0.000000] memory[0x4] [0x00000100000000-0x0000023f7fffff], 0x13f800000 bytes
> [ 0.000000] reserved.cnt = 0x2
> [ 0.000000] reserved[0x0] [0x0000000009d800-0x000000000fffff], 0x62800 bytes
> [ 0.000000] reserved[0x1] [0x00000001000000-0x00000001c67fff], 0xc68000 bytes
should have some
memblock_x86_reserve_range: [xxxxx-xxxx] EFI Boot
...
> [ 0.000000] initial memory mapped : 0 - 20000000
> [ 0.000000] memblock_x86_reserve_range: [0x00098000-0x0009cfff] TRAMPOLINE
> [ 0.000000] Base memory trampoline at [ffff880000098000] 98000 size 20480
> [ 0.000000] init_memory_mapping: 0000000000000000-00000000bf800000
> [ 0.000000] 0000000000 - 00bf800000 page 2M
> [ 0.000000] kernel direct mapping tables up to bf800000 @ bf7fc000-bf800000
> [ 0.000000] memblock_x86_reserve_range: [0xbf7fc000-0xbf7fdfff] PGTABLE
> [ 0.000000] init_memory_mapping: 0000000100000000-000000023f800000
> [ 0.000000] 0100000000 - 023f800000 page 2M
> [ 0.000000] kernel direct mapping tables up to 23f800000 @ 23f7f6000-23f800000
> [ 0.000000] memblock_x86_reserve_range: [0x23f7f6000-0x23f7fafff] PGTABLE
> [ 0.000000] ACPI: RSDP 00000000000fcf60 00024 (v02 ALASKA)
> [ 0.000000] ACPI: XSDT 00000000bf309070 0005C (v01 ALASKA A M I 01072009 AMI 00010013)
> [ 0.000000] ACPI: FACP 00000000bf310048 000F4 (v04 ALASKA A M I 01072009 AMI 00010013)
> [ 0.000000] ACPI: DSDT 00000000bf309158 06EED (v02 ALASKA A M I 00000000 INTL 20051117)
> [ 0.000000] ACPI: FACS 00000000bf60ff80 00040
> [ 0.000000] ACPI: APIC 00000000bf310140 00072 (v03 ALASKA A M I 01072009 AMI 00010013)
> [ 0.000000] ACPI: SSDT 00000000bf3101b8 00102 (v01 AMICPU PROC 00000001 MSFT 03000001)
> [ 0.000000] ACPI: MCFG 00000000bf3102c0 0003C (v01 ALASKA A M I 01072009 MSFT 00000097)
> [ 0.000000] ACPI: AAFT 00000000bf310300 0006F (v01 ALASKA OEMAAFT 01072009 MSFT 00000097)
> [ 0.000000] ACPI: HPET 00000000bf310370 00038 (v01 ALASKA A M I 01072009 AMI. 00000004)
> [ 0.000000] ACPI: DMAR 00000000bf3103a8 000B0 (v01 ALASKA A M I 00000001 INTL 00000001)
> [ 0.000000] ACPI: Local APIC address 0xfee00000
> [ 0.000000] No NUMA configuration found
> [ 0.000000] Faking a node at 0000000000000000-000000023f800000
> [ 0.000000] Initmem setup node 0 0000000000000000-000000023f800000
> [ 0.000000] memblock_x86_reserve_range: [0x23f7fb000-0x23f7fffff] NODE_DATA
> [ 0.000000] NODE_DATA [000000023f7fb000 - 000000023f7fffff]
> [ 0.000000] memblock_x86_reserve_range: [0x23f7f5000-0x23f7f5fff] BOOTMEM
> [ 0.000000] memblock_x86_reserve_range: [0x23f3f5000-0x23f7f4fff] BOOTMEM
> [ 0.000000] memblock_x86_reserve_range: [0x23f3f4a00-0x23f3f4fff] BOOTMEM
> [ 0.000000] memblock_x86_reserve_range: [0x23eff4a00-0x23f3f49ff] BOOTMEM
> [ 0.000000] memblock_x86_reserve_range: [0x236e00000-0x23edfffff] BOOTMEM
> [ 0.000000] memblock_x86_reserve_range: [0x23eff3000-0x23eff3fff] BOOTMEM
> [ 0.000000] memblock_x86_reserve_range: [0x23eff2000-0x23eff2fff] BOOTMEM
> [ 0.000000] memblock_x86_free_range: [0x23de00000-0x23edfffff]
> [ 0.000000] [ffffea0000000000-ffffea0007dfffff] PMD -> [ffff880236e00000-ffff88023ddfffff] on node 0
> [ 0.000000] memblock_x86_free_range: [0x23eff4a00-0x23f3f49ff]
> [ 0.000000] memblock_x86_free_range: [0x23f3f5000-0x23f7f4fff]
>
> ~Maarten
On 06/07/2011 05:22 AM, Maarten Lankhorst wrote:
> It seems the error still occurs when calling free_bootmem_late
> even if I only reserve blocks that haven't been reserved yet.
please check this one.
---
arch/x86/platform/efi/efi.c | 2 +-
include/linux/mm.h | 2 ++
mm/page_alloc.c | 32 ++++++++++++++++++++++++++++++++
3 files changed, 35 insertions(+), 1 deletion(-)
Index: linux-2.6/arch/x86/platform/efi/efi.c
===================================================================
--- linux-2.6.orig/arch/x86/platform/efi/efi.c
+++ linux-2.6/arch/x86/platform/efi/efi.c
@@ -368,7 +368,7 @@ static void __init efi_free_boot_service
md->type != EFI_BOOT_SERVICES_DATA)
continue;
- free_bootmem_late(start, size);
+ free_bootmem_late_with_active_regions(start, size);
}
}
Index: linux-2.6/include/linux/mm.h
===================================================================
--- linux-2.6.orig/include/linux/mm.h
+++ linux-2.6/include/linux/mm.h
@@ -1322,6 +1322,8 @@ extern void get_pfn_range_for_nid(unsign
extern unsigned long find_min_pfn_with_active_regions(void);
extern void free_bootmem_with_active_regions(int nid,
unsigned long max_low_pfn);
+void free_bootmem_late_with_active_regions(unsigned long addr,
+ unsigned long size);
int add_from_early_node_map(struct range *range, int az,
int nr_range, int nid);
u64 __init find_memory_core_early(int nid, u64 size, u64 align,
Index: linux-2.6/mm/page_alloc.c
===================================================================
--- linux-2.6.orig/mm/page_alloc.c
+++ linux-2.6/mm/page_alloc.c
@@ -3828,6 +3828,38 @@ void __init free_bootmem_with_active_reg
}
}
+/**
+ * free_bootmem_late_with_active_regions - Call free_bootmem_late for each active range
+ * @addr: starting address of the range
+ * @size: size of the range in bytes
+ *
+ * this function make sure on active regions only
+ */
+void __init free_bootmem_late_with_active_regions(unsigned long addr,
+ unsigned long size)
+{
+ int i;
+ int nid = MAX_NUMNODES;
+ unsigned long start_pfn = PFN_UP(addr);
+ unsigned long end_pfn = PFN_DOWN(addr + size);
+
+ if (start_pfn >= end_pfn)
+ return;
+
+ for_each_active_range_index_in_nid(i, nid) {
+ unsigned long common_start, common_end;
+
+ common_start = max(start_pfn, early_node_map[i].start_pfn);
+ common_end = min(end_pfn, early_node_map[i].end_pfn);
+
+ if (common_start >= common_end)
+ continue;
+
+ free_bootmem_late(common_start << PAGE_SHIFT,
+ (common_end - common_start) << PAGE_SHIFT);
+ }
+}
+
#ifdef CONFIG_HAVE_MEMBLOCK
/*
* Basic iterator support. Return the last range of PFNs for a node
On 06/08/2011 12:25 AM, Yinghai Lu wrote:
> On 06/07/2011 05:22 AM, Maarten Lankhorst wrote:
>> It seems the error still occurs when calling free_bootmem_late
>> even if I only reserve blocks that haven't been reserved yet.
>
> please check this one.
>
> ---
> arch/x86/platform/efi/efi.c | 2 +-
> include/linux/mm.h | 2 ++
> mm/page_alloc.c | 32 ++++++++++++++++++++++++++++++++
> 3 files changed, 35 insertions(+), 1 deletion(-)
>
> Index: linux-2.6/arch/x86/platform/efi/efi.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/platform/efi/efi.c
> +++ linux-2.6/arch/x86/platform/efi/efi.c
> @@ -368,7 +368,7 @@ static void __init efi_free_boot_service
> md->type != EFI_BOOT_SERVICES_DATA)
> continue;
>
> - free_bootmem_late(start, size);
> + free_bootmem_late_with_active_regions(start, size);
> }
> }
>
> Index: linux-2.6/include/linux/mm.h
> ===================================================================
> --- linux-2.6.orig/include/linux/mm.h
> +++ linux-2.6/include/linux/mm.h
> @@ -1322,6 +1322,8 @@ extern void get_pfn_range_for_nid(unsign
> extern unsigned long find_min_pfn_with_active_regions(void);
> extern void free_bootmem_with_active_regions(int nid,
> unsigned long max_low_pfn);
> +void free_bootmem_late_with_active_regions(unsigned long addr,
> + unsigned long size);
> int add_from_early_node_map(struct range *range, int az,
> int nr_range, int nid);
> u64 __init find_memory_core_early(int nid, u64 size, u64 align,
> Index: linux-2.6/mm/page_alloc.c
> ===================================================================
> --- linux-2.6.orig/mm/page_alloc.c
> +++ linux-2.6/mm/page_alloc.c
> @@ -3828,6 +3828,38 @@ void __init free_bootmem_with_active_reg
> }
> }
>
> +/**
> + * free_bootmem_late_with_active_regions - Call free_bootmem_late for each active range
> + * @addr: starting address of the range
> + * @size: size of the range in bytes
> + *
> + * this function make sure on active regions only
> + */
> +void __init free_bootmem_late_with_active_regions(unsigned long addr,
> + unsigned long size)
> +{
> + int i;
> + int nid = MAX_NUMNODES;
> + unsigned long start_pfn = PFN_UP(addr);
> + unsigned long end_pfn = PFN_DOWN(addr + size);
> +
> + if (start_pfn >= end_pfn)
> + return;
> +
> + for_each_active_range_index_in_nid(i, nid) {
> + unsigned long common_start, common_end;
> +
> + common_start = max(start_pfn, early_node_map[i].start_pfn);
> + common_end = min(end_pfn, early_node_map[i].end_pfn);
> +
> + if (common_start >= common_end)
> + continue;
> +
> + free_bootmem_late(common_start << PAGE_SHIFT,
> + (common_end - common_start) << PAGE_SHIFT);
> + }
> +}
> +
> #ifdef CONFIG_HAVE_MEMBLOCK
> /*
> * Basic iterator support. Return the last range of PFNs for a node
>
I applied this on top of 3.0-rc1 (with offsets), kernels boots but see
now in dmesg output a new 'BUG: Bad page state in process swapper
pfn:01800' see attached dmesg output.
Jim
On 06/08/2011 09:44 AM, Jim Bos wrote:
> On 06/08/2011 12:25 AM, Yinghai Lu wrote:
>> On 06/07/2011 05:22 AM, Maarten Lankhorst wrote:
>>> It seems the error still occurs when calling free_bootmem_late
>>> even if I only reserve blocks that haven't been reserved yet.
>>
>> please check this one.
>>
>> ---
>> arch/x86/platform/efi/efi.c | 2 +-
>> include/linux/mm.h | 2 ++
>> mm/page_alloc.c | 32 ++++++++++++++++++++++++++++++++
>> 3 files changed, 35 insertions(+), 1 deletion(-)
>>
>> Index: linux-2.6/arch/x86/platform/efi/efi.c
>> ===================================================================
>> --- linux-2.6.orig/arch/x86/platform/efi/efi.c
>> +++ linux-2.6/arch/x86/platform/efi/efi.c
>> @@ -368,7 +368,7 @@ static void __init efi_free_boot_service
>> md->type != EFI_BOOT_SERVICES_DATA)
>> continue;
>>
>> - free_bootmem_late(start, size);
>> + free_bootmem_late_with_active_regions(start, size);
>> }
>> }
>>
>> Index: linux-2.6/include/linux/mm.h
>> ===================================================================
>> --- linux-2.6.orig/include/linux/mm.h
>> +++ linux-2.6/include/linux/mm.h
>> @@ -1322,6 +1322,8 @@ extern void get_pfn_range_for_nid(unsign
>> extern unsigned long find_min_pfn_with_active_regions(void);
>> extern void free_bootmem_with_active_regions(int nid,
>> unsigned long max_low_pfn);
>> +void free_bootmem_late_with_active_regions(unsigned long addr,
>> + unsigned long size);
>> int add_from_early_node_map(struct range *range, int az,
>> int nr_range, int nid);
>> u64 __init find_memory_core_early(int nid, u64 size, u64 align,
>> Index: linux-2.6/mm/page_alloc.c
>> ===================================================================
>> --- linux-2.6.orig/mm/page_alloc.c
>> +++ linux-2.6/mm/page_alloc.c
>> @@ -3828,6 +3828,38 @@ void __init free_bootmem_with_active_reg
>> }
>> }
>>
>> +/**
>> + * free_bootmem_late_with_active_regions - Call free_bootmem_late for each active range
>> + * @addr: starting address of the range
>> + * @size: size of the range in bytes
>> + *
>> + * this function make sure on active regions only
>> + */
>> +void __init free_bootmem_late_with_active_regions(unsigned long addr,
>> + unsigned long size)
>> +{
>> + int i;
>> + int nid = MAX_NUMNODES;
>> + unsigned long start_pfn = PFN_UP(addr);
>> + unsigned long end_pfn = PFN_DOWN(addr + size);
>> +
>> + if (start_pfn >= end_pfn)
>> + return;
>> +
>> + for_each_active_range_index_in_nid(i, nid) {
>> + unsigned long common_start, common_end;
>> +
>> + common_start = max(start_pfn, early_node_map[i].start_pfn);
>> + common_end = min(end_pfn, early_node_map[i].end_pfn);
>> +
>> + if (common_start >= common_end)
>> + continue;
>> +
>> + free_bootmem_late(common_start << PAGE_SHIFT,
>> + (common_end - common_start) << PAGE_SHIFT);
>> + }
>> +}
>> +
>> #ifdef CONFIG_HAVE_MEMBLOCK
>> /*
>> * Basic iterator support. Return the last range of PFNs for a node
>>
>
> I applied this on top of 3.0-rc1 (with offsets), kernels boots but see
> now in dmesg output a new 'BUG: Bad page state in process swapper
> pfn:01800' see attached dmesg output.
that is 24M...
also looks like boot services will overlapped with kernel and ramdisk...
we will reserve boot service again, and later if free boot service range, will free up some kernel or ramdisk range.
[ 0.000000] EFI: mem00: type=3, attr=0xf, range=[0x0000000000000000-0x0000000000008000) (0MB)
[ 0.000000] EFI: mem01: type=7, attr=0xf, range=[0x0000000000008000-0x0000000000075000) (0MB)
[ 0.000000] EFI: mem02: type=2, attr=0xf, range=[0x0000000000075000-0x0000000000077000) (0MB)
[ 0.000000] EFI: mem03: type=4, attr=0xf, range=[0x0000000000077000-0x0000000000078000) (0MB)
[ 0.000000] EFI: mem04: type=3, attr=0xf, range=[0x0000000000078000-0x00000000000a0000) (0MB)
[ 0.000000] EFI: mem05: type=7, attr=0xf, range=[0x0000000000100000-0x0000000001000000) (15MB)
[ 0.000000] EFI: mem06: type=2, attr=0xf, range=[0x0000000001000000-0x0000000001100000) (1MB)
[ 0.000000] EFI: mem07: type=4, attr=0xf, range=[0x0000000001100000-0x000000000133a000) (2MB)
[ 0.000000] EFI: mem08: type=3, attr=0xf, range=[0x000000000133a000-0x000000000133e000) (0MB)
[ 0.000000] EFI: mem09: type=4, attr=0xf, range=[0x000000000133e000-0x0000000001342000) (0MB)
[ 0.000000] EFI: mem10: type=3, attr=0xf, range=[0x0000000001342000-0x0000000001345000) (0MB)
[ 0.000000] EFI: mem11: type=4, attr=0xf, range=[0x0000000001345000-0x000000000135b000) (0MB)
[ 0.000000] EFI: mem12: type=3, attr=0xf, range=[0x000000000135b000-0x000000000135d000) (0MB)
[ 0.000000] EFI: mem13: type=4, attr=0xf, range=[0x000000000135d000-0x00000000013c5000) (0MB)
[ 0.000000] EFI: mem14: type=3, attr=0xf, range=[0x00000000013c5000-0x00000000013c7000) (0MB)
[ 0.000000] EFI: mem15: type=4, attr=0xf, range=[0x00000000013c7000-0x00000000013ca000) (0MB)
[ 0.000000] EFI: mem16: type=3, attr=0xf, range=[0x00000000013ca000-0x00000000013d2000) (0MB)
[ 0.000000] EFI: mem17: type=4, attr=0xf, range=[0x00000000013d2000-0x00000000013d3000) (0MB)
[ 0.000000] EFI: mem18: type=3, attr=0xf, range=[0x00000000013d3000-0x00000000013d4000) (0MB)
[ 0.000000] EFI: mem19: type=4, attr=0xf, range=[0x00000000013d4000-0x00000000013d8000) (0MB)
[ 0.000000] EFI: mem20: type=3, attr=0xf, range=[0x00000000013d8000-0x00000000013da000) (0MB)
[ 0.000000] EFI: mem21: type=4, attr=0xf, range=[0x00000000013da000-0x00000000013dc000) (0MB)
[ 0.000000] EFI: mem22: type=3, attr=0xf, range=[0x00000000013dc000-0x00000000013de000) (0MB)
[ 0.000000] EFI: mem23: type=4, attr=0xf, range=[0x00000000013de000-0x00000000013df000) (0MB)
[ 0.000000] EFI: mem24: type=3, attr=0xf, range=[0x00000000013df000-0x00000000013e0000) (0MB)
[ 0.000000] EFI: mem25: type=4, attr=0xf, range=[0x00000000013e0000-0x0000000002334000) (15MB)
we need to revert patch from mjg.
>From 916f676f8dc016103f983c7ec54c18ecdbb6e349 Mon Sep 17 00:00:00 2001
From: Matthew Garrett <[email protected]>
Date: Wed, 25 May 2011 09:53:13 -0400
Subject: [PATCH] x86, efi: Retain boot service code until after switching to
virtual mode
Thanks
Yinghai
On Wed, Jun 08, 2011 at 12:17:52PM -0700, Yinghai Lu wrote:
> we need to revert patch from mjg.
>
> From 916f676f8dc016103f983c7ec54c18ecdbb6e349 Mon Sep 17 00:00:00 2001
> From: Matthew Garrett <[email protected]>
> Date: Wed, 25 May 2011 09:53:13 -0400
> Subject: [PATCH] x86, efi: Retain boot service code until after switching to
> virtual mode
That's not a long-term option, since we have no way to distinguish
between a machine that requires boot services code to be mapped and a
machine that doesn't. Reverting just breaks the former set again. We
need to ensure that the kernel isn't overlapping boot services code.
--
Matthew Garrett | [email protected]
On 06/08/2011 12:23 PM, Matthew Garrett wrote:
> On Wed, Jun 08, 2011 at 12:17:52PM -0700, Yinghai Lu wrote:
>> we need to revert patch from mjg.
>>
>> From 916f676f8dc016103f983c7ec54c18ecdbb6e349 Mon Sep 17 00:00:00 2001
>> From: Matthew Garrett <[email protected]>
>> Date: Wed, 25 May 2011 09:53:13 -0400
>> Subject: [PATCH] x86, efi: Retain boot service code until after switching to
>> virtual mode
>
> That's not a long-term option, since we have no way to distinguish
> between a machine that requires boot services code to be mapped and a
> machine that doesn't. Reverting just breaks the former set again.
what former? you can not fix some corner case by breaking most other cases.
> We need to ensure that the kernel isn't overlapping boot services code.
bootloader will put kernel from 16M, and boot services are on those area already.
Yinghai
On Wed, Jun 08, 2011 at 12:27:03PM -0700, Yinghai Lu wrote:
> On 06/08/2011 12:23 PM, Matthew Garrett wrote:
> > On Wed, Jun 08, 2011 at 12:17:52PM -0700, Yinghai Lu wrote:
> >> we need to revert patch from mjg.
> >>
> >> From 916f676f8dc016103f983c7ec54c18ecdbb6e349 Mon Sep 17 00:00:00 2001
> >> From: Matthew Garrett <[email protected]>
> >> Date: Wed, 25 May 2011 09:53:13 -0400
> >> Subject: [PATCH] x86, efi: Retain boot service code until after switching to
> >> virtual mode
> >
> > That's not a long-term option, since we have no way to distinguish
> > between a machine that requires boot services code to be mapped and a
> > machine that doesn't. Reverting just breaks the former set again.
>
> what former? you can not fix some corner case by breaking most other cases.
All Dell laptops, all new Apples, some Lenovos, various Intel server
platforms. That I've found so far.
> > We need to ensure that the kernel isn't overlapping boot services code.
>
> bootloader will put kernel from 16M, and boot services are on those area already.
And we need to be able to map the boot services code, so we can't put
the kernel on top of it.
--
Matthew Garrett | [email protected]
On 06/08/2011 12:29 PM, Matthew Garrett wrote:
> On Wed, Jun 08, 2011 at 12:27:03PM -0700, Yinghai Lu wrote:
>> On 06/08/2011 12:23 PM, Matthew Garrett wrote:
>>> On Wed, Jun 08, 2011 at 12:17:52PM -0700, Yinghai Lu wrote:
>>>> we need to revert patch from mjg.
>>>>
>>>> From 916f676f8dc016103f983c7ec54c18ecdbb6e349 Mon Sep 17 00:00:00 2001
>>>> From: Matthew Garrett <[email protected]>
>>>> Date: Wed, 25 May 2011 09:53:13 -0400
>>>> Subject: [PATCH] x86, efi: Retain boot service code until after switching to
>>>> virtual mode
>>>
>>> That's not a long-term option, since we have no way to distinguish
>>> between a machine that requires boot services code to be mapped and a
>>> machine that doesn't. Reverting just breaks the former set again.
>>
>> what former? you can not fix some corner case by breaking most other cases.
>
> All Dell laptops, all new Apples, some Lenovos, various Intel server
> platforms. That I've found so far.
do you mean before that patch, all those machine will not boot linux kernel with UEFI support?
>
>>> We need to ensure that the kernel isn't overlapping boot services code.
>>
>> bootloader will put kernel from 16M, and boot services are on those area already.
>
> And we need to be able to map the boot services code, so we can't put
> the kernel on top of it.
after bootloader, those area should be free already.
Yinghai
On Wed, Jun 08, 2011 at 12:35:54PM -0700, Yinghai Lu wrote:
> On 06/08/2011 12:29 PM, Matthew Garrett wrote:
> >> what former? you can not fix some corner case by breaking most other cases.
> >
> > All Dell laptops, all new Apples, some Lenovos, various Intel server
> > platforms. That I've found so far.
>
> do you mean before that patch, all those machine will not boot linux kernel with UEFI support?
Correct.
> > And we need to be able to map the boot services code, so we can't put
> > the kernel on top of it.
>
> after bootloader, those area should be free already.
That's what the spec says. Reality says differently. We need those
ranges to be available to the kernel until after SetVirtualAddressMap()
has been called, which means we need to avoid putting the kernel on top
of them.
--
Matthew Garrett | [email protected]
On 06/08/2011 12:38 PM, Matthew Garrett wrote:
> On Wed, Jun 08, 2011 at 12:35:54PM -0700, Yinghai Lu wrote:
>> On 06/08/2011 12:29 PM, Matthew Garrett wrote:
>>>> what former? you can not fix some corner case by breaking most other cases.
>>>
>>> All Dell laptops, all new Apples, some Lenovos, various Intel server
>>> platforms. That I've found so far.
>>
>> do you mean before that patch, all those machine will not boot linux kernel with UEFI support?
>
> Correct.
good, they never test that. just let them to use bootcamp.
>
>>> And we need to be able to map the boot services code, so we can't put
>>> the kernel on top of it.
>>
>> after bootloader, those area should be free already.
>
> That's what the spec says. Reality says differently. We need those
> ranges to be available to the kernel until after SetVirtualAddressMap()
> has been called, which means we need to avoid putting the kernel on top
> of them.
bootloader will load kernel (bzImage) high, and it will decompressed to 16M ram position.
can you call SetVirtualAddressMap before you exit bootloader instead?
Yinghai
On 06/08/2011 12:38 PM, Matthew Garrett wrote:
> On Wed, Jun 08, 2011 at 12:35:54PM -0700, Yinghai Lu wrote:
>> On 06/08/2011 12:29 PM, Matthew Garrett wrote:
>>>> what former? you can not fix some corner case by breaking most other cases.
>>>
>>> All Dell laptops, all new Apples, some Lenovos, various Intel server
>>> platforms. That I've found so far.
>>
>> do you mean before that patch, all those machine will not boot linux kernel with UEFI support?
>
> Correct.
with or without EFI runtime services?
Yinghai
On Wed, Jun 08, 2011 at 12:46:04PM -0700, Yinghai Lu wrote:
> On 06/08/2011 12:38 PM, Matthew Garrett wrote:
> >>> All Dell laptops, all new Apples, some Lenovos, various Intel server
> >>> platforms. That I've found so far.
> >>
> >> do you mean before that patch, all those machine will not boot linux kernel with UEFI support?
> >
> > Correct.
>
> good, they never test that. just let them to use bootcamp.
If you'd like to tell Intel to stop filing bugs about Intel SDVs that
won't boot via EFI, be my guest. These are systems that have no problem
booting Windows because SetVirtualAddressMap() is called in the Windows
bootloader rather than in the Windows kernel.
> >> after bootloader, those area should be free already.
> >
> > That's what the spec says. Reality says differently. We need those
> > ranges to be available to the kernel until after SetVirtualAddressMap()
> > has been called, which means we need to avoid putting the kernel on top
> > of them.
>
> bootloader will load kernel (bzImage) high, and it will decompressed to 16M ram position.
Well that's a problem.
> can you call SetVirtualAddressMap before you exit bootloader instead?
No. We don't know where the kernel will map the runtime regions.
--
Matthew Garrett | [email protected]
On Wed, Jun 08, 2011 at 12:48:48PM -0700, Yinghai Lu wrote:
> On 06/08/2011 12:38 PM, Matthew Garrett wrote:
> > On Wed, Jun 08, 2011 at 12:35:54PM -0700, Yinghai Lu wrote:
> >> On 06/08/2011 12:29 PM, Matthew Garrett wrote:
> >>>> what former? you can not fix some corner case by breaking most other cases.
> >>>
> >>> All Dell laptops, all new Apples, some Lenovos, various Intel server
> >>> platforms. That I've found so far.
> >>
> >> do you mean before that patch, all those machine will not boot linux kernel with UEFI support?
> >
> > Correct.
>
> with or without EFI runtime services?
They'll boot with noefi, but that's useless because there's then no way
to configure a bootloader.
--
Matthew Garrett | [email protected]
On 06/08/2011 12:52 PM, Matthew Garrett wrote:
> On Wed, Jun 08, 2011 at 12:48:48PM -0700, Yinghai Lu wrote:
>> On 06/08/2011 12:38 PM, Matthew Garrett wrote:
>>> On Wed, Jun 08, 2011 at 12:35:54PM -0700, Yinghai Lu wrote:
>>>> On 06/08/2011 12:29 PM, Matthew Garrett wrote:
>>>>>> what former? you can not fix some corner case by breaking most other cases.
>>>>>
>>>>> All Dell laptops, all new Apples, some Lenovos, various Intel server
>>>>> platforms. That I've found so far.
>>>>
>>>> do you mean before that patch, all those machine will not boot linux kernel with UEFI support?
>>>
>>> Correct.
>>
>> with or without EFI runtime services?
>
> They'll boot with noefi, but that's useless because there's then no way
> to configure a bootloader.
efibootmgr will need boot services in addition to run-time services?
if really need some info from boot services, could let bootloader to get them and pass them to kernel.
Yinghai
On Wed, Jun 08, 2011 at 01:03:25PM -0700, Yinghai Lu wrote:
> On 06/08/2011 12:52 PM, Matthew Garrett wrote:
> > On Wed, Jun 08, 2011 at 12:48:48PM -0700, Yinghai Lu wrote:
> >> On 06/08/2011 12:38 PM, Matthew Garrett wrote:
> >>> On Wed, Jun 08, 2011 at 12:35:54PM -0700, Yinghai Lu wrote:
> >>>> On 06/08/2011 12:29 PM, Matthew Garrett wrote:
> >>>>>> what former? you can not fix some corner case by breaking most other cases.
> >>>>>
> >>>>> All Dell laptops, all new Apples, some Lenovos, various Intel server
> >>>>> platforms. That I've found so far.
> >>>>
> >>>> do you mean before that patch, all those machine will not boot linux kernel with UEFI support?
> >>>
> >>> Correct.
> >>
> >> with or without EFI runtime services?
> >
> > They'll boot with noefi, but that's useless because there's then no way
> > to configure a bootloader.
>
> efibootmgr will need boot services in addition to run-time services?
No, SetVirtualAddressMap() calls into boot services. This is code, not
data. We have no control over what it does.
--
Matthew Garrett | [email protected]
On 06/08/2011 01:09 PM, Matthew Garrett wrote:
> On Wed, Jun 08, 2011 at 01:03:25PM -0700, Yinghai Lu wrote:
>> On 06/08/2011 12:52 PM, Matthew Garrett wrote:
>>> On Wed, Jun 08, 2011 at 12:48:48PM -0700, Yinghai Lu wrote:
>>>> On 06/08/2011 12:38 PM, Matthew Garrett wrote:
>>>>> On Wed, Jun 08, 2011 at 12:35:54PM -0700, Yinghai Lu wrote:
>>>>>> On 06/08/2011 12:29 PM, Matthew Garrett wrote:
>>>>>>>> what former? you can not fix some corner case by breaking most other cases.
>>>>>>>
>>>>>>> All Dell laptops, all new Apples, some Lenovos, various Intel server
>>>>>>> platforms. That I've found so far.
>>>>>>
>>>>>> do you mean before that patch, all those machine will not boot linux kernel with UEFI support?
>>>>>
>>>>> Correct.
>>>>
>>>> with or without EFI runtime services?
>>>
>>> They'll boot with noefi, but that's useless because there's then no way
>>> to configure a bootloader.
>>
>> efibootmgr will need boot services in addition to run-time services?
>
> No, SetVirtualAddressMap() calls into boot services. This is code, not
> data. We have no control over what it does.
Maybe you can parse efimeminfo in arch/x86/boot/compressed/head_64.S to find right decompress position for kernel.
Yinghai
On Wed, Jun 08, 2011 at 01:23:38PM -0700, Yinghai Lu wrote:
> On 06/08/2011 01:09 PM, Matthew Garrett wrote:
> > On Wed, Jun 08, 2011 at 01:03:25PM -0700, Yinghai Lu wrote:
> >> On 06/08/2011 12:52 PM, Matthew Garrett wrote:
> >>> On Wed, Jun 08, 2011 at 12:48:48PM -0700, Yinghai Lu wrote:
> >>>> On 06/08/2011 12:38 PM, Matthew Garrett wrote:
> >>>>> On Wed, Jun 08, 2011 at 12:35:54PM -0700, Yinghai Lu wrote:
> >>>>>> On 06/08/2011 12:29 PM, Matthew Garrett wrote:
> >>>>>>>> what former? you can not fix some corner case by breaking most other cases.
> >>>>>>>
> >>>>>>> All Dell laptops, all new Apples, some Lenovos, various Intel server
> >>>>>>> platforms. That I've found so far.
> >>>>>>
> >>>>>> do you mean before that patch, all those machine will not boot linux kernel with UEFI support?
> >>>>>
> >>>>> Correct.
> >>>>
> >>>> with or without EFI runtime services?
> >>>
> >>> They'll boot with noefi, but that's useless because there's then no way
> >>> to configure a bootloader.
> >>
> >> efibootmgr will need boot services in addition to run-time services?
> >
> > No, SetVirtualAddressMap() calls into boot services. This is code, not
> > data. We have no control over what it does.
>
> Maybe you can parse efimeminfo in arch/x86/boot/compressed/head_64.S to find right decompress position for kernel.
Hm. I'll take a look into that. Thanks!
--
Matthew Garrett | [email protected]
On 06/08/2011 01:30 PM, Matthew Garrett wrote:
> On Wed, Jun 08, 2011 at 01:23:38PM -0700, Yinghai Lu wrote:
>> On 06/08/2011 01:09 PM, Matthew Garrett wrote:
>>> On Wed, Jun 08, 2011 at 01:03:25PM -0700, Yinghai Lu wrote:
>>>> On 06/08/2011 12:52 PM, Matthew Garrett wrote:
>>>>> On Wed, Jun 08, 2011 at 12:48:48PM -0700, Yinghai Lu wrote:
>>>>>> On 06/08/2011 12:38 PM, Matthew Garrett wrote:
>>>>>>> On Wed, Jun 08, 2011 at 12:35:54PM -0700, Yinghai Lu wrote:
>>>>>>>> On 06/08/2011 12:29 PM, Matthew Garrett wrote:
>>>>>>>>>> what former? you can not fix some corner case by breaking most other cases.
>>>>>>>>>
>>>>>>>>> All Dell laptops, all new Apples, some Lenovos, various Intel server
>>>>>>>>> platforms. That I've found so far.
>>>>>>>>
>>>>>>>> do you mean before that patch, all those machine will not boot linux kernel with UEFI support?
>>>>>>>
>>>>>>> Correct.
>>>>>>
>>>>>> with or without EFI runtime services?
>>>>>
>>>>> They'll boot with noefi, but that's useless because there's then no way
>>>>> to configure a bootloader.
>>>>
>>>> efibootmgr will need boot services in addition to run-time services?
>>>
>>> No, SetVirtualAddressMap() calls into boot services. This is code, not
>>> data. We have no control over what it does.
>>
>> Maybe you can parse efimeminfo in arch/x86/boot/compressed/head_64.S to find right decompress position for kernel.
>
> Hm. I'll take a look into that. Thanks!
or just let bootloader to mark those boot services just like run-time services in e820 table or setupdata?
Yinghai
On Wed, Jun 08, 2011 at 01:36:57PM -0700, Yinghai Lu wrote:
> or just let bootloader to mark those boot services just like run-time services in e820 table or setupdata?
That was my original approach, but if there's boot services code at the
top of RAM it means that max_pfn is wrong and it's difficult to recover
the memory.
--
Matthew Garrett | [email protected]
On 06/08/2011 01:42 PM, Matthew Garrett wrote:
> On Wed, Jun 08, 2011 at 01:36:57PM -0700, Yinghai Lu wrote:
>
>> or just let bootloader to mark those boot services just like run-time services in e820 table or setupdata?
>
> That was my original approach, but if there's boot services code at the
> top of RAM it means that max_pfn is wrong and it's difficult to recover
> the memory.
not all boot services ram. just those are called by run-time services code.
Yinghai
On Wed, Jun 8, 2011 at 1:42 PM, Matthew Garrett <[email protected]> wrote:
> On Wed, Jun 08, 2011 at 01:36:57PM -0700, Yinghai Lu wrote:
>
>> or just let bootloader to mark those boot services just like run-time services in e820 table or setupdata?
>
> That was my original approach, but if there's boot services code at the
> top of RAM it means that max_pfn is wrong and it's difficult to recover
> the memory.
WHO CARES if the memory is difficult to recover? Just let it be. EFI
is an abomination in the eyes of God, and we sure as hell shouldn't
bend over backwards over the stupidities in it. If it means that you
lose a meg of RAM when you use EFI, that's the least of our problems.
F*%#ing morons who thought that we wanted some kind of extensible
firmware interface. We want a *cut-down* firmware interface, not the
crazy thing that is EFI. A boot loader, not some kind of run-time
services crap. And we definitely don't want to make it any more
complex than we need to.
So just turn the EFI stuff into the memory map, and let the kernel do
as little as possible with it.
Linus
On Wed, Jun 08, 2011 at 01:46:45PM -0700, Yinghai Lu wrote:
> On 06/08/2011 01:42 PM, Matthew Garrett wrote:
> > On Wed, Jun 08, 2011 at 01:36:57PM -0700, Yinghai Lu wrote:
> >
> >> or just let bootloader to mark those boot services just like run-time services in e820 table or setupdata?
> >
> > That was my original approach, but if there's boot services code at the
> > top of RAM it means that max_pfn is wrong and it's difficult to recover
> > the memory.
>
> not all boot services ram. just those are called by run-time services code.
We have no way of telling which regions those are until they've been
called.
--
Matthew Garrett | [email protected]
On Wed, Jun 08, 2011 at 02:06:21PM -0700, Linus Torvalds wrote:
> On Wed, Jun 8, 2011 at 1:42 PM, Matthew Garrett <[email protected]> wrote:
> > On Wed, Jun 08, 2011 at 01:36:57PM -0700, Yinghai Lu wrote:
> >
> >> or just let bootloader to mark those boot services just like run-time services in e820 table or setupdata?
> >
> > That was my original approach, but if there's boot services code at the
> > top of RAM it means that max_pfn is wrong and it's difficult to recover
> > the memory.
>
> WHO CARES if the memory is difficult to recover? Just let it be. EFI
> is an abomination in the eyes of God, and we sure as hell shouldn't
> bend over backwards over the stupidities in it. If it means that you
> lose a meg of RAM when you use EFI, that's the least of our problems.
Boot services data includes everything that was allocated by the EFI
memory allocator. Depending on what the system decided to do before
deigning to run our code, that might be a meg - or it might be several
hundred. And in the process it's probably fragmented RAM into god knows
how many small chunks.
E820 limits us to 128 ranges, and systems I'm looking at right now are
already using over 140 boot services regions. Some of them are
contiguous and we could just merge them for e820, but that leaves us at
the whim of whoever wrote the allocator for the firmware. And do you
want to bet on them having done this sanely?
--
Matthew Garrett | [email protected]
On 06/08/2011 02:28 PM, Matthew Garrett wrote:
>
> E820 limits us to 128 ranges, and systems I'm looking at right now are
> already using over 140 boot services regions. Some of them are
> contiguous and we could just merge them for e820, but that leaves us at
> the whim of whoever wrote the allocator for the firmware. And do you
> want to bet on them having done this sanely?
>
No, we're not limited to 128. We're limited to 128 in the boot
structure, but more can be passed via the linked list.
-hpa
On Wed, Jun 8, 2011 at 2:28 PM, Matthew Garrett <[email protected]> wrote:
>
> Boot services data includes everything that was allocated by the EFI
> memory allocator. Depending on what the system decided to do before
> deigning to run our code, that might be a meg - or it might be several
> hundred. And in the process it's probably fragmented RAM into god knows
> how many small chunks.
In reality?
Whatever. I really think our EFI support is just fundamnetally broken.
We should do *everything* in the bootloader, and nothing at all in the
kernel. IOW, I think doing the whole "SetVirtualAddrMap()" (or
whatever) in the boot loader too, and just promise to neve rever call
any EFI routines from the kernel.
IOW, a sane EFI boot loader should just make things look like a
regular BIOS, and not bother the kernel with the EFI crap.
EFI was misdesigned. That doesn't mean that _we_ should then
mis-design our support for it.
Linus
On Wed, Jun 08, 2011 at 02:31:38PM -0700, H. Peter Anvin wrote:
> On 06/08/2011 02:28 PM, Matthew Garrett wrote:
> >
> > E820 limits us to 128 ranges, and systems I'm looking at right now are
> > already using over 140 boot services regions. Some of them are
> > contiguous and we could just merge them for e820, but that leaves us at
> > the whim of whoever wrote the allocator for the firmware. And do you
> > want to bet on them having done this sanely?
> >
>
> No, we're not limited to 128. We're limited to 128 in the boot
> structure, but more can be passed via the linked list.
Oh, ok, that's not as bad as I thought. We're still potentially losing a
pile of memory, but...
--
Matthew Garrett | [email protected]
On 06/08/2011 02:28 PM, Matthew Garrett wrote:
> E820 limits us to 128 ranges, and systems I'm looking at right now are
> already using over 140 boot services regions.
parse_setup_data() is used to handle entries above 128.
Yinghai
On Wed, Jun 08, 2011 at 02:31:55PM -0700, Linus Torvalds wrote:
> On Wed, Jun 8, 2011 at 2:28 PM, Matthew Garrett <[email protected]> wrote:
> >
> > Boot services data includes everything that was allocated by the EFI
> > memory allocator. Depending on what the system decided to do before
> > deigning to run our code, that might be a meg - or it might be several
> > hundred. And in the process it's probably fragmented RAM into god knows
> > how many small chunks.
>
> In reality?
>
> Whatever. I really think our EFI support is just fundamnetally broken.
> We should do *everything* in the bootloader, and nothing at all in the
> kernel. IOW, I think doing the whole "SetVirtualAddrMap()" (or
> whatever) in the boot loader too, and just promise to neve rever call
> any EFI routines from the kernel.
Windows and MacOS both do all the EFI setup in their bootloader, and it
obviously makes a lot of things much easier. But unfortunately even in
that case we still need to make EFI calls from runtime, because there's
no other way to tell the firmware where we put the bootloader...
--
Matthew Garrett | [email protected]
On 06/08/2011 02:31 PM, Linus Torvalds wrote:
> On Wed, Jun 8, 2011 at 2:28 PM, Matthew Garrett <[email protected]> wrote:
>>
>> Boot services data includes everything that was allocated by the EFI
>> memory allocator. Depending on what the system decided to do before
>> deigning to run our code, that might be a meg - or it might be several
>> hundred. And in the process it's probably fragmented RAM into god knows
>> how many small chunks.
>
> In reality?
>
> Whatever. I really think our EFI support is just fundamnetally broken.
> We should do *everything* in the bootloader, and nothing at all in the
> kernel. IOW, I think doing the whole "SetVirtualAddrMap()" (or
> whatever) in the boot loader too, and just promise to neve rever call
> any EFI routines from the kernel.
>
> IOW, a sane EFI boot loader should just make things look like a
> regular BIOS, and not bother the kernel with the EFI crap.
>
> EFI was misdesigned. That doesn't mean that _we_ should then
> mis-design our support for it.
>
No argument that our EFI support is misdesigned.
However, I suspect that what we *should* do is carry an kernel EFI stub
to go along with the BIOS stub... otherwise we're forever at mercy of
getting all the boot loader authors to change in lockstep, and there are
specific ones which are notoriously hard to work with.
The "kernel carries its own stub" approach been very successful in
dealing with BIOS, and would make a lot of sense to me for EFI as well.
-hpa
On Wed, Jun 8, 2011 at 2:51 PM, H. Peter Anvin <[email protected]> wrote:
>
> However, I suspect that what we *should* do is carry an kernel EFI stub
> to go along with the BIOS stub... otherwise we're forever at mercy of
> getting all the boot loader authors to change in lockstep, and there are
> specific ones which are notoriously hard to work with.
Yes, that would probably be a good approach. We obviously have some
low-level asm code for the BIOS case that is technically linked into
the kernel, but is running before the kernel boots and not really
"part" of the kernel. Doing something similar for EFI support sounds
entirely sane to me.
Linus
Hey,
Op 09-06-11 00:57, Linus Torvalds schreef:
> On Wed, Jun 8, 2011 at 2:51 PM, H. Peter Anvin <[email protected]> wrote:
>> However, I suspect that what we *should* do is carry an kernel EFI stub
>> to go along with the BIOS stub... otherwise we're forever at mercy of
>> getting all the boot loader authors to change in lockstep, and there are
>> specific ones which are notoriously hard to work with.
> Yes, that would probably be a good approach. We obviously have some
> low-level asm code for the BIOS case that is technically linked into
> the kernel, but is running before the kernel boots and not really
> "part" of the kernel. Doing something similar for EFI support sounds
> entirely sane to me.
I agree that's a long term solution, meanwhile can we just hope
that not too much boot memory is reserved and not free
that memory so it at least boots for more people?
Maybe add a printk of 'X amount of boot memory will not freed',
so at least people can quantify and judge for themselves whether
it's worth disabling kernel efi support or not.
~Maarten
So this is obviously even more of a hack, but before you check whether
the memblock has already been reserved could you __check_region it as
well? That ought to avoid us touching the kernel. I've got a patch for
grub that'll avoid the situation where we load the kernel on top of an
existing resource and I'll port that to grub2, but that's still going to
be awkward for existing bootloaders.
--
Matthew Garrett | [email protected]
Well,
Op 10-06-11 18:47, Matthew Garrett schreef:
> So this is obviously even more of a hack, but before you check whether
> the memblock has already been reserved could you __check_region it as
> well? That ought to avoid us touching the kernel. I've got a patch for
> grub that'll avoid the situation where we load the kernel on top of an
> existing resource and I'll port that to grub2, but that's still going to
> be awkward for existing bootloaders.
>
Erm, __check_region calls __requestion_region which does a kzalloc,
if I call __check_region it doesn't boot, probably because of that.
Do you want me to manually run through iomem_resource? Is it even available up at that point?
~Maarten
On Fri, Jun 10, 2011 at 07:51:46PM +0200, Maarten Lankhorst wrote:
> Well,
>
> Op 10-06-11 18:47, Matthew Garrett schreef:
> > So this is obviously even more of a hack, but before you check whether
> > the memblock has already been reserved could you __check_region it as
> > well? That ought to avoid us touching the kernel. I've got a patch for
> > grub that'll avoid the situation where we load the kernel on top of an
> > existing resource and I'll port that to grub2, but that's still going to
> > be awkward for existing bootloaders.
> >
> Erm, __check_region calls __requestion_region which does a kzalloc,
> if I call __check_region it doesn't boot, probably because of that.
Oh, bother.
> Do you want me to manually run through iomem_resource? Is it even available up at that point?
Should be - we've already called insert_resource to set up the kernel at
this point.
--
Matthew Garrett | [email protected]
Op 10-06-11 19:54, Matthew Garrett schreef:
> On Fri, Jun 10, 2011 at 07:51:46PM +0200, Maarten Lankhorst wrote:
>> Well,
>>
>> Op 10-06-11 18:47, Matthew Garrett schreef:
>>> So this is obviously even more of a hack, but before you check whether
>>> the memblock has already been reserved could you __check_region it as
>>> well? That ought to avoid us touching the kernel. I've got a patch for
>>> grub that'll avoid the situation where we load the kernel on top of an
>>> existing resource and I'll port that to grub2, but that's still going to
>>> be awkward for existing bootloaders.
>>>
>> Erm, __check_region calls __requestion_region which does a kzalloc,
>> if I call __check_region it doesn't boot, probably because of that.
> Oh, bother.
>
>> Do you want me to manually run through iomem_resource? Is it even available up at that point?
> Should be - we've already called insert_resource to set up the kernel at
> this point.
>
Version with yinghai's free_bootmem_late_with_active_regions.
Still has an issue though, I'm getting 2 warnings from swapper:
[ 2.867034] BUG: Bad page state in process swapper pfn:01900
[ 2.867303] page:ffffea0000057800 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.867683] page flags: 0x100000000000000()
[ 2.867887] Pid: 1, comm: swapper Not tainted 2.6.39.1-patser+ #15
[ 2.867888] Call Trace:
[ 2.867893] [<ffffffff810f349b>] ? dump_page+0x9b/0xd0
[ 2.867894] [<ffffffff810f3599>] bad_page+0xc9/0x120
[ 2.867896] [<ffffffff810f36af>] free_pages_prepare+0xbf/0x110
[ 2.867898] [<ffffffff810f4fa9>] free_hot_cold_page+0x49/0x440
[ 2.867899] [<ffffffff810f59fd>] __free_pages+0x2d/0x40
[ 2.867900] [<ffffffff810f5a53>] free_pages+0x43/0x50
[ 2.867903] [<ffffffff81029542>] free_init_pages+0x132/0x1c0
[ 2.867904] [<ffffffff81029cd3>] mark_rodata_ro+0x143/0x150
[ 2.867906] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.867909] [<ffffffff81ab7d45>] kernel_init+0x158/0x163
[ 2.867911] [<ffffffff815688d4>] kernel_thread_helper+0x4/0x10
[ 2.867913] [<ffffffff81ab7bed>] ? start_kernel+0x3dc/0x3dc
[ 2.867914] [<ffffffff815688d0>] ? gs_change+0xb/0xb
[ 2.867915] Disabling lock debugging due to kernel taint
[ 2.867922] BUG: Bad page state in process swapper pfn:01910
[ 2.868187] page:ffffea0000057b80 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.868567] page flags: 0x100000000000000()
[ 2.868769] Pid: 1, comm: swapper Tainted: G B 2.6.39.1-patser+ #15
[ 2.868770] Call Trace:
[ 2.868771] [<ffffffff810f349b>] ? dump_page+0x9b/0xd0
[ 2.868773] [<ffffffff810f3599>] bad_page+0xc9/0x120
[ 2.868774] [<ffffffff810f36af>] free_pages_prepare+0xbf/0x110
[ 2.868775] [<ffffffff810f4fa9>] free_hot_cold_page+0x49/0x440
[ 2.868777] [<ffffffff810f59fd>] __free_pages+0x2d/0x40
[ 2.868778] [<ffffffff810f5a53>] free_pages+0x43/0x50
[ 2.868779] [<ffffffff81029542>] free_init_pages+0x132/0x1c0
[ 2.868781] [<ffffffff81029cd3>] mark_rodata_ro+0x143/0x150
[ 2.868782] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.868784] [<ffffffff81ab7d45>] kernel_init+0x158/0x163
[ 2.868785] [<ffffffff815688d4>] kernel_thread_helper+0x4/0x10
[ 2.868787] [<ffffffff81ab7bed>] ? start_kernel+0x3dc/0x3dc
[ 2.868788] [<ffffffff815688d0>] ? gs_change+0xb/0xb
Also don't rate for style, that wasn't the scope of this patch. This is just to have something to test with ;)
diff --git a/arch/x86/include/asm/memblock.h b/arch/x86/include/asm/memblock.h
index 19ae14b..0cd3800 100644
--- a/arch/x86/include/asm/memblock.h
+++ b/arch/x86/include/asm/memblock.h
@@ -4,7 +4,6 @@
#define ARCH_DISCARD_MEMBLOCK
u64 memblock_x86_find_in_range_size(u64 start, u64 *sizep, u64 align);
-void memblock_x86_to_bootmem(u64 start, u64 end);
void memblock_x86_reserve_range(u64 start, u64 end, char *name);
void memblock_x86_free_range(u64 start, u64 end);
@@ -19,5 +18,6 @@ u64 memblock_x86_hole_size(u64 start, u64 end);
u64 memblock_x86_find_in_range_node(int nid, u64 start, u64 end, u64 size, u64 align);
u64 memblock_x86_free_memory_in_range(u64 addr, u64 limit);
u64 memblock_x86_memory_in_range(u64 addr, u64 limit);
+bool memblock_x86_check_reserved_size(u64 *addrp, u64 *sizep, u64 align);
#endif
diff --git a/arch/x86/mm/memblock.c b/arch/x86/mm/memblock.c
index aa11693..992da5e 100644
--- a/arch/x86/mm/memblock.c
+++ b/arch/x86/mm/memblock.c
@@ -8,7 +8,7 @@
#include <linux/range.h>
/* Check for already reserved areas */
-static bool __init check_with_memblock_reserved_size(u64 *addrp, u64 *sizep, u64 align)
+bool __init memblock_x86_check_reserved_size(u64 *addrp, u64 *sizep, u64 align)
{
struct memblock_region *r;
u64 addr = *addrp, last;
@@ -59,7 +59,7 @@ u64 __init memblock_x86_find_in_range_size(u64 start, u64 *sizep, u64 align)
if (addr >= ei_last)
continue;
*sizep = ei_last - addr;
- while (check_with_memblock_reserved_size(&addr, sizep, align))
+ while (memblock_x86_check_reserved_size(&addr, sizep, align))
;
if (*sizep)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 02b48dc..46e63ad 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -315,20 +315,85 @@ static void __init print_efi_memmap(void)
}
#endif /* EFI_DEBUG */
+static struct resource * __available_resource(struct resource *root, struct resource *new)
+{
+ resource_size_t start = new->start;
+ resource_size_t end = new->end;
+ struct resource *tmp, **p;
+
+ if (end < start)
+ return root;
+ if (start < root->start)
+ return root;
+ if (end > root->end)
+ return root;
+ p = &root->child;
+ for (;;) {
+ tmp = *p;
+ if (!tmp || tmp->start > end)
+ return NULL;
+ p = &tmp->sibling;
+ if (tmp->end < start)
+ continue;
+ return tmp;
+ }
+}
+
+static int is_used_region(struct resource *parent, struct resource *new)
+{
+ struct resource *first, *next;
+
+ for (;; parent = first) {
+ first = __available_resource(parent, new);
+ if (!first)
+ return 0;
+
+ if (first == parent)
+ return 1;
+ if (WARN_ON(first == new)) /* duplicated insertion */
+ return 1;
+
+ if ((first->start > new->start) || (first->end < new->end))
+ break;
+ if ((first->start == new->start) && (first->end == new->end))
+ break;
+ }
+
+ for (next = first; ; next = next->sibling) {
+ if (next->start < new->start || next->end > new->end)
+ return 1;
+ if (!next->sibling)
+ break;
+ if (next->sibling->start > new->end)
+ break;
+ }
+
+ return 0;
+}
+
+
void __init efi_reserve_boot_services(void)
{
void *p;
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
efi_memory_desc_t *md = p;
- unsigned long long start = md->phys_addr;
- unsigned long long size = md->num_pages << EFI_PAGE_SHIFT;
+ u64 start = md->phys_addr;
+ u64 size = md->num_pages << EFI_PAGE_SHIFT;
+ struct resource dummy = { .start = start, .end = start + size };
if (md->type != EFI_BOOT_SERVICES_CODE &&
md->type != EFI_BOOT_SERVICES_DATA)
continue;
-
- memblock_x86_reserve_range(start, start + size, "EFI Boot");
+ if (is_used_region(&iomem_resource, &dummy) ||
+ memblock_x86_check_reserved_size(&start, &size,
+ 1<<EFI_PAGE_SHIFT)) {
+ /* Could not reserve, skip it */
+ md->num_pages = 0;
+ printk(KERN_INFO PFX "Could not reserve boot area "
+ "[0x%llx-0x%llx)\n", start, start+size);
+ } else
+ memblock_x86_reserve_range(start, start+size, "EFI Boot");
}
}
@@ -345,7 +410,11 @@ static void __init efi_free_boot_services(void)
md->type != EFI_BOOT_SERVICES_DATA)
continue;
- free_bootmem_late(start, size);
+ /* Could not reserve boot area */
+ if (!size)
+ continue;
+
+ free_bootmem_late_with_active_regions(start, size);
}
}
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 6507dde..713287f 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1352,6 +1352,8 @@ extern void get_pfn_range_for_nid(unsigned int nid,
extern unsigned long find_min_pfn_with_active_regions(void);
extern void free_bootmem_with_active_regions(int nid,
unsigned long max_low_pfn);
+void free_bootmem_late_with_active_regions(unsigned long addr,
+ unsigned long size);
int add_from_early_node_map(struct range *range, int az,
int nr_range, int nid);
u64 __init find_memory_core_early(int nid, u64 size, u64 align,
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index e78b324..4c3bcd7a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3790,6 +3790,38 @@ void __init free_bootmem_with_active_regions(int nid,
}
}
+/**
+ * free_bootmem_late_with_active_regions - Call free_bootmem_late for each active range
+ * @addr: starting address of the range
+ * @size: size of the range in bytes
+ *
+ * this function make sure on active regions only
+ */
+void __init free_bootmem_late_with_active_regions(unsigned long addr,
+ unsigned long size)
+{
+ int i;
+ int nid = MAX_NUMNODES;
+ unsigned long start_pfn = PFN_UP(addr);
+ unsigned long end_pfn = PFN_DOWN(addr + size);
+
+ if (start_pfn >= end_pfn)
+ return;
+
+ for_each_active_range_index_in_nid(i, nid) {
+ unsigned long common_start, common_end;
+
+ common_start = max(start_pfn, early_node_map[i].start_pfn);
+ common_end = min(end_pfn, early_node_map[i].end_pfn);
+
+ if (common_start >= common_end)
+ continue;
+
+ free_bootmem_late(common_start << PAGE_SHIFT,
+ (common_end - common_start) << PAGE_SHIFT);
+ }
+}
+
#ifdef CONFIG_HAVE_MEMBLOCK
/*
* Basic iterator support. Return the last range of PFNs for a node
On 06/10/2011 03:45 PM, Maarten Lankhorst wrote:
> Op 10-06-11 19:54, Matthew Garrett schreef:
>> On Fri, Jun 10, 2011 at 07:51:46PM +0200, Maarten Lankhorst wrote:
>>> Well,
>>>
>>> Op 10-06-11 18:47, Matthew Garrett schreef:
>>>> So this is obviously even more of a hack, but before you check whether
>>>> the memblock has already been reserved could you __check_region it as
>>>> well? That ought to avoid us touching the kernel. I've got a patch for
>>>> grub that'll avoid the situation where we load the kernel on top of an
>>>> existing resource and I'll port that to grub2, but that's still going to
>>>> be awkward for existing bootloaders.
>>>>
>>> Erm, __check_region calls __requestion_region which does a kzalloc,
>>> if I call __check_region it doesn't boot, probably because of that.
>> Oh, bother.
>>
>>> Do you want me to manually run through iomem_resource? Is it even available up at that point?
>> Should be - we've already called insert_resource to set up the kernel at
>> this point.
>>
>
> Version with yinghai's free_bootmem_late_with_active_regions.
>
> Still has an issue though, I'm getting 2 warnings from swapper:
> [ 2.867034] BUG: Bad page state in process swapper pfn:01900
> [ 2.867303] page:ffffea0000057800 count:0 mapcount:-127 mapping: (null) index:0x0
> [ 2.867683] page flags: 0x100000000000000()
> [ 2.867887] Pid: 1, comm: swapper Not tainted 2.6.39.1-patser+ #15
> [ 2.867888] Call Trace:
> [ 2.867893] [<ffffffff810f349b>] ? dump_page+0x9b/0xd0
> [ 2.867894] [<ffffffff810f3599>] bad_page+0xc9/0x120
> [ 2.867896] [<ffffffff810f36af>] free_pages_prepare+0xbf/0x110
> [ 2.867898] [<ffffffff810f4fa9>] free_hot_cold_page+0x49/0x440
> [ 2.867899] [<ffffffff810f59fd>] __free_pages+0x2d/0x40
> [ 2.867900] [<ffffffff810f5a53>] free_pages+0x43/0x50
> [ 2.867903] [<ffffffff81029542>] free_init_pages+0x132/0x1c0
> [ 2.867904] [<ffffffff81029cd3>] mark_rodata_ro+0x143/0x150
> [ 2.867906] [<ffffffff810001d8>] init_post+0x18/0xd0
> [ 2.867909] [<ffffffff81ab7d45>] kernel_init+0x158/0x163
> [ 2.867911] [<ffffffff815688d4>] kernel_thread_helper+0x4/0x10
> [ 2.867913] [<ffffffff81ab7bed>] ? start_kernel+0x3dc/0x3dc
> [ 2.867914] [<ffffffff815688d0>] ? gs_change+0xb/0xb
> [ 2.867915] Disabling lock debugging due to kernel taint
> [ 2.867922] BUG: Bad page state in process swapper pfn:01910
> [ 2.868187] page:ffffea0000057b80 count:0 mapcount:-127 mapping: (null) index:0x0
> [ 2.868567] page flags: 0x100000000000000()
> [ 2.868769] Pid: 1, comm: swapper Tainted: G B 2.6.39.1-patser+ #15
> [ 2.868770] Call Trace:
> [ 2.868771] [<ffffffff810f349b>] ? dump_page+0x9b/0xd0
> [ 2.868773] [<ffffffff810f3599>] bad_page+0xc9/0x120
> [ 2.868774] [<ffffffff810f36af>] free_pages_prepare+0xbf/0x110
> [ 2.868775] [<ffffffff810f4fa9>] free_hot_cold_page+0x49/0x440
> [ 2.868777] [<ffffffff810f59fd>] __free_pages+0x2d/0x40
> [ 2.868778] [<ffffffff810f5a53>] free_pages+0x43/0x50
> [ 2.868779] [<ffffffff81029542>] free_init_pages+0x132/0x1c0
> [ 2.868781] [<ffffffff81029cd3>] mark_rodata_ro+0x143/0x150
> [ 2.868782] [<ffffffff810001d8>] init_post+0x18/0xd0
> [ 2.868784] [<ffffffff81ab7d45>] kernel_init+0x158/0x163
> [ 2.868785] [<ffffffff815688d4>] kernel_thread_helper+0x4/0x10
> [ 2.868787] [<ffffffff81ab7bed>] ? start_kernel+0x3dc/0x3dc
> [ 2.868788] [<ffffffff815688d0>] ? gs_change+0xb/0xb
>
> Also don't rate for style, that wasn't the scope of this patch. This is just to have something to test with ;)
>
the problem is : overlapping between kernel code with boot services code.
now e820 table that is passed from bootloader do not include boot services code range. and also current boot/head_64.S will not
try to find usable range for decompressed kernel ( too early )...
So solution will be:
1. revert Matthew Garrett's patch, because it breaking unknown good platform.
2. ask vendor of system that Matthew try to fix to go back fix their firmware. otherwise user have stay with CSM with it.
Thanks
Yinghai Lu
On 06/10/2011 03:45 PM, Maarten Lankhorst wrote:
> Op 10-06-11 19:54, Matthew Garrett schreef:
>> On Fri, Jun 10, 2011 at 07:51:46PM +0200, Maarten Lankhorst wrote:
>>> Well,
>>>
>>> Op 10-06-11 18:47, Matthew Garrett schreef:
>>>> So this is obviously even more of a hack, but before you check whether
>>>> the memblock has already been reserved could you __check_region it as
>>>> well? That ought to avoid us touching the kernel. I've got a patch for
>>>> grub that'll avoid the situation where we load the kernel on top of an
>>>> existing resource and I'll port that to grub2, but that's still going to
>>>> be awkward for existing bootloaders.
>>>>
>>> Erm, __check_region calls __requestion_region which does a kzalloc,
>>> if I call __check_region it doesn't boot, probably because of that.
>> Oh, bother.
>>
>>> Do you want me to manually run through iomem_resource? Is it even available up at that point?
>> Should be - we've already called insert_resource to set up the kernel at
>> this point.
>>
>
> Version with yinghai's free_bootmem_late_with_active_regions.
>
> Still has an issue though, I'm getting 2 warnings from swapper:
> [ 2.867034] BUG: Bad page state in process swapper pfn:01900
> [ 2.867303] page:ffffea0000057800 count:0 mapcount:-127 mapping: (null) index:0x0
> [ 2.867683] page flags: 0x100000000000000()
> [ 2.867887] Pid: 1, comm: swapper Not tainted 2.6.39.1-patser+ #15
> [ 2.867888] Call Trace:
> [ 2.867893] [<ffffffff810f349b>] ? dump_page+0x9b/0xd0
> [ 2.867894] [<ffffffff810f3599>] bad_page+0xc9/0x120
> [ 2.867896] [<ffffffff810f36af>] free_pages_prepare+0xbf/0x110
> [ 2.867898] [<ffffffff810f4fa9>] free_hot_cold_page+0x49/0x440
> [ 2.867899] [<ffffffff810f59fd>] __free_pages+0x2d/0x40
> [ 2.867900] [<ffffffff810f5a53>] free_pages+0x43/0x50
> [ 2.867903] [<ffffffff81029542>] free_init_pages+0x132/0x1c0
> [ 2.867904] [<ffffffff81029cd3>] mark_rodata_ro+0x143/0x150
> [ 2.867906] [<ffffffff810001d8>] init_post+0x18/0xd0
> [ 2.867909] [<ffffffff81ab7d45>] kernel_init+0x158/0x163
> [ 2.867911] [<ffffffff815688d4>] kernel_thread_helper+0x4/0x10
> [ 2.867913] [<ffffffff81ab7bed>] ? start_kernel+0x3dc/0x3dc
> [ 2.867914] [<ffffffff815688d0>] ? gs_change+0xb/0xb
> [ 2.867915] Disabling lock debugging due to kernel taint
> [ 2.867922] BUG: Bad page state in process swapper pfn:01910
> [ 2.868187] page:ffffea0000057b80 count:0 mapcount:-127 mapping: (null) index:0x0
> [ 2.868567] page flags: 0x100000000000000()
> [ 2.868769] Pid: 1, comm: swapper Tainted: G B 2.6.39.1-patser+ #15
> [ 2.868770] Call Trace:
> [ 2.868771] [<ffffffff810f349b>] ? dump_page+0x9b/0xd0
> [ 2.868773] [<ffffffff810f3599>] bad_page+0xc9/0x120
> [ 2.868774] [<ffffffff810f36af>] free_pages_prepare+0xbf/0x110
> [ 2.868775] [<ffffffff810f4fa9>] free_hot_cold_page+0x49/0x440
> [ 2.868777] [<ffffffff810f59fd>] __free_pages+0x2d/0x40
> [ 2.868778] [<ffffffff810f5a53>] free_pages+0x43/0x50
> [ 2.868779] [<ffffffff81029542>] free_init_pages+0x132/0x1c0
> [ 2.868781] [<ffffffff81029cd3>] mark_rodata_ro+0x143/0x150
> [ 2.868782] [<ffffffff810001d8>] init_post+0x18/0xd0
> [ 2.868784] [<ffffffff81ab7d45>] kernel_init+0x158/0x163
> [ 2.868785] [<ffffffff815688d4>] kernel_thread_helper+0x4/0x10
> [ 2.868787] [<ffffffff81ab7bed>] ? start_kernel+0x3dc/0x3dc
> [ 2.868788] [<ffffffff815688d0>] ? gs_change+0xb/0xb
>
> Also don't rate for style, that wasn't the scope of this patch. This is just to have something to test with ;)
>
the problem is : overlapping between kernel code with boot services code.
now e820 table that is passed from bootloader do not include boot services code range. and also current boot/head_64.S will not
try to find usable range for decompressed kernel ( too early )...
So solution will be:
1. revert Matthew Garrett's patch, because it breaks known good platforms.
| commit 916f676f8dc016103f983c7ec54c18ecdbb6e349
| Author: Matthew Garrett <[email protected]>
| Date: Wed May 25 09:53:13 2011 -0400
|
| x86, efi: Retain boot service code until after switching to virtual mode
2. ask vendor of system that Matthew try to fix to go back fix their firmware. otherwise user have stay with CSM with it.
Thanks
Yinghai Lu
On Fri, Jun 10, 2011 at 03:58:06PM -0700, Yinghai Lu wrote:
> the problem is : overlapping between kernel code with boot services code.
SHouldn't checking against the iomem resource map avoid that?
> now e820 table that is passed from bootloader do not include boot services code range. and also current boot/head_64.S will not
> try to find usable range for decompressed kernel ( too early )...
>
> So solution will be:
> 1. revert Matthew Garrett's patch, because it breaking unknown good platform.
That's acceptable if we can't find a better solution.
> 2. ask vendor of system that Matthew try to fix to go back fix their firmware. otherwise user have stay with CSM with it.
This isn't an option.
The medium-term fix is to ensure that the bootloaders don't put the
kernel on top of boot services code. The long-term fix is to perform the
SetVirtualAddressMap transition in either the bootloader or the kernel
entry point. But the short-term fix here is to allocate all boot
services regions that don't overlap with the kernel. That'll fix some
number of machines and shouldn't break any existing ones.
--
Matthew Garrett | [email protected]
On Sat, Jun 11, 2011 at 12:03:59AM +0100, Matthew Garrett wrote:
> On Fri, Jun 10, 2011 at 03:58:06PM -0700, Yinghai Lu wrote:
>
> > the problem is : overlapping between kernel code with boot services code.
>
> SHouldn't checking against the iomem resource map avoid that?
>
> > now e820 table that is passed from bootloader do not include boot services code range. and also current boot/head_64.S will not
> > try to find usable range for decompressed kernel ( too early )...
> >
> > So solution will be:
> > 1. revert Matthew Garrett's patch, because it breaking unknown good platform.
>
> That's acceptable if we can't find a better solution.
If no one objects, I'd like to revert the EFI patch that went into
2.6.39.1 that is causing people problems so as to give everyone some
time to get 3.0 working properly on these boxes.
thanks,
greg k-h
Hi Greg,
Op 11-06-11 01:17, Greg KH schreef:
> On Sat, Jun 11, 2011 at 12:03:59AM +0100, Matthew Garrett wrote:
>> On Fri, Jun 10, 2011 at 03:58:06PM -0700, Yinghai Lu wrote:
>>
>>> the problem is : overlapping between kernel code with boot services code.
>> SHouldn't checking against the iomem resource map avoid that?
>>
>>> now e820 table that is passed from bootloader do not include boot services code range. and also current boot/head_64.S will not
>>> try to find usable range for decompressed kernel ( too early )...
>>>
>>> So solution will be:
>>> 1. revert Matthew Garrett's patch, because it breaking unknown good platform.
>> That's acceptable if we can't find a better solution.
> If no one objects, I'd like to revert the EFI patch that went into
> 2.6.39.1 that is causing people problems so as to give everyone some
> time to get 3.0 working properly on these boxes.
Seems we don't have a proper fix yet, so reverting is fine, pulling the consolidate NX patch
would still give the problem of overlapping pages in mainline, there appears to be no solution yet.
Reverting the change would make vanilla stable boot on my system again at least.
~Maarten
On 06/10/2011 04:17 PM, Greg KH wrote:
> On Sat, Jun 11, 2011 at 12:03:59AM +0100, Matthew Garrett wrote:
>> On Fri, Jun 10, 2011 at 03:58:06PM -0700, Yinghai Lu wrote:
>>
>>> the problem is : overlapping between kernel code with boot services code.
>>
>> SHouldn't checking against the iomem resource map avoid that?
>>
>>> now e820 table that is passed from bootloader do not include boot services code range. and also current boot/head_64.S will not
>>> try to find usable range for decompressed kernel ( too early )...
>>>
>>> So solution will be:
>>> 1. revert Matthew Garrett's patch, because it breaking unknown good platform.
>>
>> That's acceptable if we can't find a better solution.
>
> If no one objects, I'd like to revert the EFI patch that went into
> 2.6.39.1 that is causing people problems so as to give everyone some
> time to get 3.0 working properly on these boxes.
>
Yes, makes sense at this point.
-hpa
On 06/10/2011 04:03 PM, Matthew Garrett wrote:
> On Fri, Jun 10, 2011 at 03:58:06PM -0700, Yinghai Lu wrote:
>
>> the problem is : overlapping between kernel code with boot services code.
>
> SHouldn't checking against the iomem resource map avoid that?
>
>> now e820 table that is passed from bootloader do not include boot services code range. and also current boot/head_64.S will not
>> try to find usable range for decompressed kernel ( too early )...
>>
>> So solution will be:
>> 1. revert Matthew Garrett's patch, because it breaking unknown good platform.
>
> That's acceptable if we can't find a better solution.
good.
>
>> 2. ask vendor of system that Matthew try to fix to go back fix their firmware. otherwise user have stay with CSM with it.
>
> This isn't an option.
>
> The medium-term fix is to ensure that the bootloaders don't put the
> kernel on top of boot services code.
that is not enough, will need to make arch/x86/boot/compressed/head_64.S parse e820 table to find right decompress position.
> The long-term fix is to perform the
> SetVirtualAddressMap transition in either the bootloader or the kernel
> entry point.
that is sane and clean workaround for those systems with buggy fw.
> But the short-term fix here is to allocate all boot
> services regions that don't overlap with the kernel. That'll fix some
> number of machines and shouldn't break any existing ones.
that is questionable and dangerous. before SetVirtualAddressMap, some function in boot service could be called,
those data or code for boot services could be overlapped kernel. so kernel code could be damaged by those calling.
also that will make our kernel code more messy.
Yinghai
On 06/10/2011 04:26 PM, Yinghai Lu wrote:
>>
>>> 2. ask vendor of system that Matthew try to fix to go back fix their firmware. otherwise user have stay with CSM with it.
>>
>> This isn't an option.
>>
>> The medium-term fix is to ensure that the bootloaders don't put the
>> kernel on top of boot services code.
>
> that is not enough, will need to make arch/x86/boot/compressed/head_64.S parse e820 table to find right decompress position.
>
No, it should be, because the boot loader can control the decompress
position to avoid the problems.
-hpa
On 06/10/2011 04:32 PM, H. Peter Anvin wrote:
> On 06/10/2011 04:26 PM, Yinghai Lu wrote:
>>>
>>>> 2. ask vendor of system that Matthew try to fix to go back fix their firmware. otherwise user have stay with CSM with it.
>>>
>>> This isn't an option.
>>>
>>> The medium-term fix is to ensure that the bootloaders don't put the
>>> kernel on top of boot services code.
>>
>> that is not enough, will need to make arch/x86/boot/compressed/head_64.S parse e820 table to find right decompress position.
>>
>
> No, it should be, because the boot loader can control the decompress
> position to avoid the problems.
bootloader could find out decompressed kernel size?
Yinghai
On 06/10/2011 04:55 PM, Yinghai Lu wrote:
>>
>> No, it should be, because the boot loader can control the decompress
>> position to avoid the problems.
>
> bootloader could find out decompressed kernel size?
>
Yes, it's the init_size field in the header.
-hpa
On 06/10/2011 05:00 PM, H. Peter Anvin wrote:
> On 06/10/2011 04:55 PM, Yinghai Lu wrote:
>>>
>>> No, it should be, because the boot loader can control the decompress
>>> position to avoid the problems.
>>
>> bootloader could find out decompressed kernel size?
>>
>
> Yes, it's the init_size field in the header.
good, with relocatable_kernel, kernel_alignment, and init_size in header, bootloader could find right position for kernel.
Yinghai
On Fri, Jun 10, 2011 at 04:26:20PM -0700, Yinghai Lu wrote:
> On 06/10/2011 04:03 PM, Matthew Garrett wrote:
> > The medium-term fix is to ensure that the bootloaders don't put the
> > kernel on top of boot services code.
>
> that is not enough, will need to make arch/x86/boot/compressed/head_64.S parse e820 table to find right decompress position.
That's fine, we can ensure we load it where there's enough space.
> > But the short-term fix here is to allocate all boot
> > services regions that don't overlap with the kernel. That'll fix some
> > number of machines and shouldn't break any existing ones.
>
> that is questionable and dangerous. before SetVirtualAddressMap, some function in boot service could be called,
> those data or code for boot services could be overlapped kernel. so kernel code could be damaged by those calling.
Right now it's guaranteed that the system will crash in this situation.
It seems reasonable to give it a fighting chance.
> also that will make our kernel code more messy.
It's code that deals with firmware, so really that's a given...
--
Matthew Garrett | [email protected]
Ok, let's just try this in a somewhat more brute force way. Can you try
this patch on top of current git, and give me the full dmesg and
/proc/iomem ?
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 0d3a4fa..ffbe47c 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -312,11 +312,35 @@ void __init efi_reserve_boot_services(void)
efi_memory_desc_t *md = p;
unsigned long long start = md->phys_addr;
unsigned long long size = md->num_pages << EFI_PAGE_SHIFT;
+ unsigned long long end = start + size;
- if (md->type != EFI_BOOT_SERVICES_CODE &&
- md->type != EFI_BOOT_SERVICES_DATA)
+ if (md->type != EFI_BOOT_SERVICES_CODE)
continue;
+ /*
+ * Trying to map EFI code over the zero page is just asking
+ * for trouble. The good news is that it's almost certainly
+ * only there for graphics card bringup at POST time, so
+ * we should be able to get away with not having it there
+ */
+
+ if (start == 0) {
+ md->num_pages = 0;
+ continue;
+ }
+
+ /*
+ * We probably also want to avoid mapping code over the
+ * kernel...
+ */
+
+ if ((start <= virt_to_phys(_etext)-1 && end >= virt_to_phys(_text)) ||
+ (start <= virt_to_phys(_edata)-1 && end >= virt_to_phys(_etext)) ||
+ (start <= virt_to_phys(&__bss_stop)-1 && end >= virt_to_phys(&__bss_start))) {
+ md->num_pages = 0;
+ continue;
+ }
+
memblock_x86_reserve_range(start, start + size, "EFI Boot");
}
}
@@ -330,8 +354,10 @@ static void __init efi_free_boot_services(void)
unsigned long long start = md->phys_addr;
unsigned long long size = md->num_pages << EFI_PAGE_SHIFT;
- if (md->type != EFI_BOOT_SERVICES_CODE &&
- md->type != EFI_BOOT_SERVICES_DATA)
+ if (md->type != EFI_BOOT_SERVICES_CODE)
+ continue;
+
+ if (size == 0)
continue;
free_bootmem_late(start, size);
@@ -483,9 +509,6 @@ void __init efi_init(void)
x86_platform.set_wallclock = efi_set_rtc_mmss;
#endif
- /* Setup for EFI runtime service */
- reboot_type = BOOT_EFI;
-
#if EFI_DEBUG
print_efi_memmap();
#endif
--
Matthew Garrett | [email protected]
Op 13-06-11 18:47, Matthew Garrett schreef:
> Ok, let's just try this in a somewhat more brute force way. Can you try
> this patch on top of current git, and give me the full dmesg and
> /proc/iomem ?
>
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 0d3a4fa..ffbe47c 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -312,11 +312,35 @@ void __init efi_reserve_boot_services(void)
> efi_memory_desc_t *md = p;
> unsigned long long start = md->phys_addr;
> unsigned long long size = md->num_pages << EFI_PAGE_SHIFT;
> + unsigned long long end = start + size;
>
> - if (md->type != EFI_BOOT_SERVICES_CODE &&
> - md->type != EFI_BOOT_SERVICES_DATA)
> + if (md->type != EFI_BOOT_SERVICES_CODE)
> continue;
>
> + /*
> + * Trying to map EFI code over the zero page is just asking
> + * for trouble. The good news is that it's almost certainly
> + * only there for graphics card bringup at POST time, so
> + * we should be able to get away with not having it there
> + */
> +
> + if (start == 0) {
> + md->num_pages = 0;
> + continue;
> + }
> +
> + /*
> + * We probably also want to avoid mapping code over the
> + * kernel...
> + */
> +
> + if ((start <= virt_to_phys(_etext)-1 && end >= virt_to_phys(_text)) ||
> + (start <= virt_to_phys(_edata)-1 && end >= virt_to_phys(_etext)) ||
_etext -> _sdata perhaps?
> + (start <= virt_to_phys(&__bss_stop)-1 && end >= virt_to_phys(&__bss_start))) {
> + md->num_pages = 0;
> + continue;
> + }
> +
> memblock_x86_reserve_range(start, start + size, "EFI Boot");
> }
> }
Will test though. It might also be appropriate to put a WARN when that condition happens.
~Maarten
On Mon, Jun 13, 2011 at 07:52:42PM +0200, Maarten Lankhorst wrote:
> > + */
> > +
> > + if ((start <= virt_to_phys(_etext)-1 && end >= virt_to_phys(_text)) ||
> > + (start <= virt_to_phys(_edata)-1 && end >= virt_to_phys(_etext)) ||
> _etext -> _sdata perhaps?
_etext is used for the resource allocation earlier, which seems like
it's probably the relevant thing to be copying.
> > memblock_x86_reserve_range(start, start + size, "EFI Boot");
> > }
> > }
> Will test though. It might also be appropriate to put a WARN when that condition happens.
That'd end up triggering even in cases that are absolutely safe (ie, the
firmware doesn't have this bug). The amount of suck here is incredible.
--
Matthew Garrett | [email protected]
Op 13-06-11 20:00, Matthew Garrett schreef:
> On Mon, Jun 13, 2011 at 07:52:42PM +0200, Maarten Lankhorst wrote:
>>> + */
>>> +
>>> + if ((start <= virt_to_phys(_etext)-1 && end >= virt_to_phys(_text)) ||
>>> + (start <= virt_to_phys(_edata)-1 && end >= virt_to_phys(_etext)) ||
>> _etext -> _sdata perhaps?
> _etext is used for the resource allocation earlier, which seems like
> it's probably the relevant thing to be copying.
I meant the second comparison, start <= edata && end >= _etext
>>> memblock_x86_reserve_range(start, start + size, "EFI Boot");
>>> }
>>> }
>> Will test though. It might also be appropriate to put a WARN when that condition happens.
> That'd end up triggering even in cases that are absolutely safe (ie, the
> firmware doesn't have this bug). The amount of suck here is incredible.
Still a crapload of swapper BUGs in free_init_pages, maybe you should just give up on this approach,
and call SetVirtualAddressMap before anything of importance runs. :-/
My kernel never needed the boot code hack btw, so I'm probably a terrible test subject for it.
~Maarten
On Mon, Jun 13, 2011 at 08:14:10PM +0200, Maarten Lankhorst wrote:
> Op 13-06-11 20:00, Matthew Garrett schreef:
> > On Mon, Jun 13, 2011 at 07:52:42PM +0200, Maarten Lankhorst wrote:
> >>> + */
> >>> +
> >>> + if ((start <= virt_to_phys(_etext)-1 && end >= virt_to_phys(_text)) ||
> >>> + (start <= virt_to_phys(_edata)-1 && end >= virt_to_phys(_etext)) ||
> >> _etext -> _sdata perhaps?
> > _etext is used for the resource allocation earlier, which seems like
> > it's probably the relevant thing to be copying.
> I meant the second comparison, start <= edata && end >= _etext
I know:
data_resource.start = virt_to_phys(_etext);
data_resource.end = virt_to_phys(_edata)-1;
(from kernel/setup.c)
> >>> memblock_x86_reserve_range(start, start + size, "EFI Boot");
> >>> }
> >>> }
> >> Will test though. It might also be appropriate to put a WARN when that condition happens.
> > That'd end up triggering even in cases that are absolutely safe (ie, the
> > firmware doesn't have this bug). The amount of suck here is incredible.
> Still a crapload of swapper BUGs in free_init_pages, maybe you should just give up on this approach,
> and call SetVirtualAddressMap before anything of importance runs. :-/
Not straightforward, sadly. Can I have the dmesg and iomem?
--
Matthew Garrett | [email protected]
Op 13-06-11 20:17, Matthew Garrett schreef:
> On Mon, Jun 13, 2011 at 08:14:10PM +0200, Maarten Lankhorst wrote:
>> Op 13-06-11 20:00, Matthew Garrett schreef:
>>> On Mon, Jun 13, 2011 at 07:52:42PM +0200, Maarten Lankhorst wrote:
>>>>> + */
>>>>> +
>>>>> + if ((start <= virt_to_phys(_etext)-1 && end >= virt_to_phys(_text)) ||
>>>>> + (start <= virt_to_phys(_edata)-1 && end >= virt_to_phys(_etext)) ||
>>>> _etext -> _sdata perhaps?
>>> _etext is used for the resource allocation earlier, which seems like
>>> it's probably the relevant thing to be copying.
>> I meant the second comparison, start <= edata && end >= _etext
> I know:
>
> data_resource.start = virt_to_phys(_etext);
> data_resource.end = virt_to_phys(_edata)-1;
>
> (from kernel/setup.c)
Ah, in that case wouldn't 2 comparisons instead of 4 be enough?
>>>>> memblock_x86_reserve_range(start, start + size, "EFI Boot");
>>>>> }
>>>>> }
>>>> Will test though. It might also be appropriate to put a WARN when that condition happens.
>>> That'd end up triggering even in cases that are absolutely safe (ie, the
>>> firmware doesn't have this bug). The amount of suck here is incredible.
>> Still a crapload of swapper BUGs in free_init_pages, maybe you should just give up on this approach,
>> and call SetVirtualAddressMap before anything of importance runs. :-/
> Not straightforward, sadly. Can I have the dmesg and iomem?
>
/proc/iomem:
00000000-0000ffff : reserved
00010000-0009ffff : System RAM
000a0000-000bffff : PCI Bus 0000:00
000c0000-000c7fff : Video ROM
000c8000-000dffff : PCI Bus 0000:00
000f0000-000fffff : System ROM
00100000-bf35bfff : System RAM
01000000-01580278 : Kernel code
01580279-01aa4cff : Kernel data
01b6c000-01c68fff : Kernel bss
bf35c000-bf3acfff : ACPI Non-volatile Storage
bf3ad000-bf60bfff : reserved
bf60c000-bf60cfff : System RAM
bf60d000-bf60dfff : ACPI Tables
bf60e000-bf617fff : ACPI Non-volatile Storage
bf618000-bf63cfff : reserved
bf63d000-bf67ffff : ACPI Non-volatile Storage
bf680000-bf7fffff : System RAM
bf800000-bfffffff : RAM buffer
c0000000-ffffffff : PCI Bus 0000:00
d0000000-dbffffff : PCI Bus 0000:01
d0000000-d7ffffff : 0000:01:00.0
d8000000-dbffffff : 0000:01:00.0
d9000000-d92fffff : efifb
dc100000-dc1fffff : PCI Bus 0000:06
dc100000-dc1fffff : PCI Bus 0000:07
dc100000-dc100fff : 0000:07:00.1
dc101000-dc101fff : 0000:07:00.0
dc101000-dc101fff : bttv0
dc200000-dc2fffff : PCI Bus 0000:03
dc200000-dc203fff : 0000:03:00.0
dc200000-dc203fff : r8169
dc204000-dc204fff : 0000:03:00.0
dc204000-dc204fff : r8169
e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff]
e0000000-efffffff : pnp 00:01
f8000000-fa0fffff : PCI Bus 0000:01
f8000000-f9ffffff : 0000:01:00.0
f8000000-f9ffffff : nvidia
fa000000-fa07ffff : 0000:01:00.0
fa080000-fa083fff : 0000:01:00.1
fa080000-fa083fff : ICH HD audio
fa100000-fa1fffff : PCI Bus 0000:04
fa100000-fa107fff : 0000:04:00.0
fa100000-fa107fff : xhci_hcd
fa200000-fa203fff : 0000:00:1b.0
fa200000-fa203fff : ICH HD audio
fa204000-fa2040ff : 0000:00:1f.3
fa205000-fa2057ff : 0000:00:1f.2
fa205000-fa2057ff : ahci
fa206000-fa2063ff : 0000:00:1d.0
fa206000-fa2063ff : ehci_hcd
fa207000-fa2073ff : 0000:00:1a.0
fa207000-fa2073ff : ehci_hcd
fa208000-fa20800f : 0000:00:16.0
fa208000-fa20800f : mei
fec00000-fec003ff : IOAPIC 0
fed00000-fed003ff : HPET 0
fed08000-fed08fff : pnp 00:08
fed10000-fed19fff : pnp 00:01
fed1c000-fed3ffff : reserved
fed1c000-fed1ffff : pnp 00:08
fed20000-fed3ffff : pnp 00:01
fed90000-fed93fff : pnp 00:01
fee00000-fee0ffff : pnp 00:01
fee00000-fee00fff : Local APIC
ff000000-ffffffff : reserved
ff000000-ffffffff : pnp 00:08
100000000-23f7fffff : System RAM
23f800000-23fffffff : RAM buffer
dmesg:
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.0.0-rc2-patser+ ([email protected]) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) ) #39 SMP PREEMPT Mon Jun 13 19:51:37 CEST 2011
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.0.0-rc2-patser+ root=/dev/sdb2 ro rootflags=ssd,discard root=/dev/sdb2 devtmpfs.mount=1 video=efifb reboot=a,e,p init=/init quiet splash vt.handoff=7
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf35c000 (usable)
[ 0.000000] BIOS-e820: 00000000bf35c000 - 00000000bf3ad000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000bf3ad000 - 00000000bf60c000 (reserved)
[ 0.000000] BIOS-e820: 00000000bf60c000 - 00000000bf60d000 (usable)
[ 0.000000] BIOS-e820: 00000000bf60d000 - 00000000bf60e000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000bf60e000 - 00000000bf618000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000bf618000 - 00000000bf63d000 (reserved)
[ 0.000000] BIOS-e820: 00000000bf63d000 - 00000000bf680000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000bf680000 - 00000000bf800000 (usable)
[ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed40000 (reserved)
[ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
[ 0.000000] BIOS-e820: 0000000100000000 - 000000023f800000 (usable)
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] EFI v2.00 by American Megatrends
[ 0.000000] SMBIOS=0xbf63bc98 ACPI=0xbf3a5000 ACPI 2.0=0xbf3a5000 MPS=0xfcbf0
[ 0.000000] Kernel-defined memdesc doesn't match the one from EFI!
[ 0.000000] EFI: mem00: type=3, attr=0xf, range=[0x0000000000000000-0x0000000000008000) (0MB)
[ 0.000000] EFI: mem01: type=7, attr=0xf, range=[0x0000000000008000-0x0000000000077000) (0MB)
[ 0.000000] EFI: mem02: type=4, attr=0xf, range=[0x0000000000077000-0x0000000000078000) (0MB)
[ 0.000000] EFI: mem03: type=3, attr=0xf, range=[0x0000000000078000-0x00000000000a0000) (0MB)
[ 0.000000] EFI: mem04: type=2, attr=0xf, range=[0x0000000000100000-0x00000000003f9000) (2MB)
[ 0.000000] EFI: mem05: type=7, attr=0xf, range=[0x00000000003f9000-0x0000000001000000) (12MB)
[ 0.000000] EFI: mem06: type=2, attr=0xf, range=[0x0000000001000000-0x0000000001100000) (1MB)
[ 0.000000] EFI: mem07: type=4, attr=0xf, range=[0x0000000001100000-0x0000000001337000) (2MB)
[ 0.000000] EFI: mem08: type=3, attr=0xf, range=[0x0000000001337000-0x0000000001339000) (0MB)
[ 0.000000] EFI: mem09: type=4, attr=0xf, range=[0x0000000001339000-0x0000000001341000) (0MB)
[ 0.000000] EFI: mem10: type=3, attr=0xf, range=[0x0000000001341000-0x0000000001345000) (0MB)
[ 0.000000] EFI: mem11: type=4, attr=0xf, range=[0x0000000001345000-0x0000000001375000) (0MB)
[ 0.000000] EFI: mem12: type=3, attr=0xf, range=[0x0000000001375000-0x0000000001378000) (0MB)
[ 0.000000] EFI: mem13: type=4, attr=0xf, range=[0x0000000001378000-0x000000000137a000) (0MB)
[ 0.000000] EFI: mem14: type=3, attr=0xf, range=[0x000000000137a000-0x0000000001384000) (0MB)
[ 0.000000] EFI: mem15: type=4, attr=0xf, range=[0x0000000001384000-0x0000000001387000) (0MB)
[ 0.000000] EFI: mem16: type=3, attr=0xf, range=[0x0000000001387000-0x0000000001388000) (0MB)
[ 0.000000] EFI: mem17: type=4, attr=0xf, range=[0x0000000001388000-0x000000000138a000) (0MB)
[ 0.000000] EFI: mem18: type=3, attr=0xf, range=[0x000000000138a000-0x000000000138d000) (0MB)
[ 0.000000] EFI: mem19: type=4, attr=0xf, range=[0x000000000138d000-0x000000000138f000) (0MB)
[ 0.000000] EFI: mem20: type=3, attr=0xf, range=[0x000000000138f000-0x0000000001391000) (0MB)
[ 0.000000] EFI: mem21: type=4, attr=0xf, range=[0x0000000001391000-0x0000000001393000) (0MB)
[ 0.000000] EFI: mem22: type=3, attr=0xf, range=[0x0000000001393000-0x0000000001395000) (0MB)
[ 0.000000] EFI: mem23: type=4, attr=0xf, range=[0x0000000001395000-0x0000000001396000) (0MB)
[ 0.000000] EFI: mem24: type=3, attr=0xf, range=[0x0000000001396000-0x0000000001397000) (0MB)
[ 0.000000] EFI: mem25: type=4, attr=0xf, range=[0x0000000001397000-0x00000000013a7000) (0MB)
[ 0.000000] EFI: mem26: type=3, attr=0xf, range=[0x00000000013a7000-0x00000000013a9000) (0MB)
[ 0.000000] EFI: mem27: type=4, attr=0xf, range=[0x00000000013a9000-0x00000000013ad000) (0MB)
[ 0.000000] EFI: mem28: type=3, attr=0xf, range=[0x00000000013ad000-0x00000000013b5000) (0MB)
[ 0.000000] EFI: mem29: type=4, attr=0xf, range=[0x00000000013b5000-0x00000000013c8000) (0MB)
[ 0.000000] EFI: mem30: type=3, attr=0xf, range=[0x00000000013c8000-0x00000000013ca000) (0MB)
[ 0.000000] EFI: mem31: type=4, attr=0xf, range=[0x00000000013ca000-0x00000000013d1000) (0MB)
[ 0.000000] EFI: mem32: type=3, attr=0xf, range=[0x00000000013d1000-0x00000000013de000) (0MB)
[ 0.000000] EFI: mem33: type=4, attr=0xf, range=[0x00000000013de000-0x00000000013e0000) (0MB)
[ 0.000000] EFI: mem34: type=3, attr=0xf, range=[0x00000000013e0000-0x00000000013e8000) (0MB)
[ 0.000000] EFI: mem35: type=4, attr=0xf, range=[0x00000000013e8000-0x00000000013f3000) (0MB)
[ 0.000000] EFI: mem36: type=3, attr=0xf, range=[0x00000000013f3000-0x00000000013f4000) (0MB)
[ 0.000000] EFI: mem37: type=4, attr=0xf, range=[0x00000000013f4000-0x00000000013f6000) (0MB)
[ 0.000000] EFI: mem38: type=3, attr=0xf, range=[0x00000000013f6000-0x00000000013f7000) (0MB)
[ 0.000000] EFI: mem39: type=4, attr=0xf, range=[0x00000000013f7000-0x00000000013fa000) (0MB)
[ 0.000000] EFI: mem40: type=3, attr=0xf, range=[0x00000000013fa000-0x00000000013fc000) (0MB)
[ 0.000000] EFI: mem41: type=4, attr=0xf, range=[0x00000000013fc000-0x000000000179a000) (3MB)
[ 0.000000] EFI: mem42: type=3, attr=0xf, range=[0x000000000179a000-0x000000000179e000) (0MB)
[ 0.000000] EFI: mem43: type=4, attr=0xf, range=[0x000000000179e000-0x000000000179f000) (0MB)
[ 0.000000] EFI: mem44: type=3, attr=0xf, range=[0x000000000179f000-0x00000000017ae000) (0MB)
[ 0.000000] EFI: mem45: type=4, attr=0xf, range=[0x00000000017ae000-0x00000000017b3000) (0MB)
[ 0.000000] EFI: mem46: type=3, attr=0xf, range=[0x00000000017b3000-0x00000000017be000) (0MB)
[ 0.000000] EFI: mem47: type=4, attr=0xf, range=[0x00000000017be000-0x00000000017c6000) (0MB)
[ 0.000000] EFI: mem48: type=3, attr=0xf, range=[0x00000000017c6000-0x00000000017c8000) (0MB)
[ 0.000000] EFI: mem49: type=4, attr=0xf, range=[0x00000000017c8000-0x00000000017ca000) (0MB)
[ 0.000000] EFI: mem50: type=3, attr=0xf, range=[0x00000000017ca000-0x00000000017cd000) (0MB)
[ 0.000000] EFI: mem51: type=4, attr=0xf, range=[0x00000000017cd000-0x00000000017d1000) (0MB)
[ 0.000000] EFI: mem52: type=3, attr=0xf, range=[0x00000000017d1000-0x00000000017d4000) (0MB)
[ 0.000000] EFI: mem53: type=4, attr=0xf, range=[0x00000000017d4000-0x00000000017e6000) (0MB)
[ 0.000000] EFI: mem54: type=3, attr=0xf, range=[0x00000000017e6000-0x00000000017e8000) (0MB)
[ 0.000000] EFI: mem55: type=4, attr=0xf, range=[0x00000000017e8000-0x00000000017e9000) (0MB)
[ 0.000000] EFI: mem56: type=3, attr=0xf, range=[0x00000000017e9000-0x00000000017f1000) (0MB)
[ 0.000000] EFI: mem57: type=4, attr=0xf, range=[0x00000000017f1000-0x00000000017f9000) (0MB)
[ 0.000000] EFI: mem58: type=3, attr=0xf, range=[0x00000000017f9000-0x00000000017fa000) (0MB)
[ 0.000000] EFI: mem59: type=4, attr=0xf, range=[0x00000000017fa000-0x00000000017fb000) (0MB)
[ 0.000000] EFI: mem60: type=3, attr=0xf, range=[0x00000000017fb000-0x00000000017fd000) (0MB)
[ 0.000000] EFI: mem61: type=4, attr=0xf, range=[0x00000000017fd000-0x00000000017fe000) (0MB)
[ 0.000000] EFI: mem62: type=3, attr=0xf, range=[0x00000000017fe000-0x0000000001803000) (0MB)
[ 0.000000] EFI: mem63: type=4, attr=0xf, range=[0x0000000001803000-0x0000000001809000) (0MB)
[ 0.000000] EFI: mem64: type=3, attr=0xf, range=[0x0000000001809000-0x0000000001811000) (0MB)
[ 0.000000] EFI: mem65: type=4, attr=0xf, range=[0x0000000001811000-0x0000000001814000) (0MB)
[ 0.000000] EFI: mem66: type=3, attr=0xf, range=[0x0000000001814000-0x0000000001819000) (0MB)
[ 0.000000] EFI: mem67: type=4, attr=0xf, range=[0x0000000001819000-0x0000000001850000) (0MB)
[ 0.000000] EFI: mem68: type=3, attr=0xf, range=[0x0000000001850000-0x000000000186a000) (0MB)
[ 0.000000] EFI: mem69: type=4, attr=0xf, range=[0x000000000186a000-0x000000000187e000) (0MB)
[ 0.000000] EFI: mem70: type=3, attr=0xf, range=[0x000000000187e000-0x0000000001889000) (0MB)
[ 0.000000] EFI: mem71: type=4, attr=0xf, range=[0x0000000001889000-0x000000000188c000) (0MB)
[ 0.000000] EFI: mem72: type=3, attr=0xf, range=[0x000000000188c000-0x0000000001893000) (0MB)
[ 0.000000] EFI: mem73: type=4, attr=0xf, range=[0x0000000001893000-0x00000000018a1000) (0MB)
[ 0.000000] EFI: mem74: type=3, attr=0xf, range=[0x00000000018a1000-0x00000000018a5000) (0MB)
[ 0.000000] EFI: mem75: type=4, attr=0xf, range=[0x00000000018a5000-0x00000000018ae000) (0MB)
[ 0.000000] EFI: mem76: type=3, attr=0xf, range=[0x00000000018ae000-0x00000000018b6000) (0MB)
[ 0.000000] EFI: mem77: type=4, attr=0xf, range=[0x00000000018b6000-0x00000000018b7000) (0MB)
[ 0.000000] EFI: mem78: type=3, attr=0xf, range=[0x00000000018b7000-0x00000000018c0000) (0MB)
[ 0.000000] EFI: mem79: type=4, attr=0xf, range=[0x00000000018c0000-0x00000000018cc000) (0MB)
[ 0.000000] EFI: mem80: type=3, attr=0xf, range=[0x00000000018cc000-0x0000000001918000) (0MB)
[ 0.000000] EFI: mem81: type=4, attr=0xf, range=[0x0000000001918000-0x0000000001d9f000) (4MB)
[ 0.000000] EFI: mem82: type=3, attr=0xf, range=[0x0000000001d9f000-0x0000000001da3000) (0MB)
[ 0.000000] EFI: mem83: type=4, attr=0xf, range=[0x0000000001da3000-0x0000000001dac000) (0MB)
[ 0.000000] EFI: mem84: type=3, attr=0xf, range=[0x0000000001dac000-0x0000000001daf000) (0MB)
[ 0.000000] EFI: mem85: type=4, attr=0xf, range=[0x0000000001daf000-0x0000000001db1000) (0MB)
[ 0.000000] EFI: mem86: type=3, attr=0xf, range=[0x0000000001db1000-0x0000000001db3000) (0MB)
[ 0.000000] EFI: mem87: type=4, attr=0xf, range=[0x0000000001db3000-0x0000000001db5000) (0MB)
[ 0.000000] EFI: mem88: type=3, attr=0xf, range=[0x0000000001db5000-0x0000000001db7000) (0MB)
[ 0.000000] EFI: mem89: type=4, attr=0xf, range=[0x0000000001db7000-0x0000000001db9000) (0MB)
[ 0.000000] EFI: mem90: type=3, attr=0xf, range=[0x0000000001db9000-0x0000000001dbb000) (0MB)
[ 0.000000] EFI: mem91: type=4, attr=0xf, range=[0x0000000001dbb000-0x0000000001dc5000) (0MB)
[ 0.000000] EFI: mem92: type=3, attr=0xf, range=[0x0000000001dc5000-0x0000000001dc7000) (0MB)
[ 0.000000] EFI: mem93: type=4, attr=0xf, range=[0x0000000001dc7000-0x0000000001dc8000) (0MB)
[ 0.000000] EFI: mem94: type=3, attr=0xf, range=[0x0000000001dc8000-0x0000000001dcd000) (0MB)
[ 0.000000] EFI: mem95: type=4, attr=0xf, range=[0x0000000001dcd000-0x0000000001dd3000) (0MB)
[ 0.000000] EFI: mem96: type=3, attr=0xf, range=[0x0000000001dd3000-0x0000000001dd6000) (0MB)
[ 0.000000] EFI: mem97: type=4, attr=0xf, range=[0x0000000001dd6000-0x0000000001ddc000) (0MB)
[ 0.000000] EFI: mem98: type=3, attr=0xf, range=[0x0000000001ddc000-0x0000000001ddf000) (0MB)
[ 0.000000] EFI: mem99: type=4, attr=0xf, range=[0x0000000001ddf000-0x0000000001de1000) (0MB)
[ 0.000000] EFI: mem100: type=3, attr=0xf, range=[0x0000000001de1000-0x0000000001de3000) (0MB)
[ 0.000000] EFI: mem101: type=4, attr=0xf, range=[0x0000000001de3000-0x0000000001de5000) (0MB)
[ 0.000000] EFI: mem102: type=3, attr=0xf, range=[0x0000000001de5000-0x0000000001de7000) (0MB)
[ 0.000000] EFI: mem103: type=4, attr=0xf, range=[0x0000000001de7000-0x0000000001ded000) (0MB)
[ 0.000000] EFI: mem104: type=3, attr=0xf, range=[0x0000000001ded000-0x0000000001df0000) (0MB)
[ 0.000000] EFI: mem105: type=4, attr=0xf, range=[0x0000000001df0000-0x0000000001df2000) (0MB)
[ 0.000000] EFI: mem106: type=3, attr=0xf, range=[0x0000000001df2000-0x0000000001df4000) (0MB)
[ 0.000000] EFI: mem107: type=4, attr=0xf, range=[0x0000000001df4000-0x0000000001df6000) (0MB)
[ 0.000000] EFI: mem108: type=3, attr=0xf, range=[0x0000000001df6000-0x0000000001df8000) (0MB)
[ 0.000000] EFI: mem109: type=4, attr=0xf, range=[0x0000000001df8000-0x0000000001dfc000) (0MB)
[ 0.000000] EFI: mem110: type=3, attr=0xf, range=[0x0000000001dfc000-0x0000000001dfe000) (0MB)
[ 0.000000] EFI: mem111: type=4, attr=0xf, range=[0x0000000001dfe000-0x0000000001e0e000) (0MB)
[ 0.000000] EFI: mem112: type=3, attr=0xf, range=[0x0000000001e0e000-0x0000000001e10000) (0MB)
[ 0.000000] EFI: mem113: type=4, attr=0xf, range=[0x0000000001e10000-0x0000000001e12000) (0MB)
[ 0.000000] EFI: mem114: type=3, attr=0xf, range=[0x0000000001e12000-0x0000000001e1f000) (0MB)
[ 0.000000] EFI: mem115: type=4, attr=0xf, range=[0x0000000001e1f000-0x0000000001e21000) (0MB)
[ 0.000000] EFI: mem116: type=3, attr=0xf, range=[0x0000000001e21000-0x0000000001e23000) (0MB)
[ 0.000000] EFI: mem117: type=4, attr=0xf, range=[0x0000000001e23000-0x0000000001e25000) (0MB)
[ 0.000000] EFI: mem118: type=3, attr=0xf, range=[0x0000000001e25000-0x0000000001e29000) (0MB)
[ 0.000000] EFI: mem119: type=4, attr=0xf, range=[0x0000000001e29000-0x0000000001e2b000) (0MB)
[ 0.000000] EFI: mem120: type=3, attr=0xf, range=[0x0000000001e2b000-0x0000000001e2d000) (0MB)
[ 0.000000] EFI: mem121: type=4, attr=0xf, range=[0x0000000001e2d000-0x0000000001e35000) (0MB)
[ 0.000000] EFI: mem122: type=3, attr=0xf, range=[0x0000000001e35000-0x0000000001e37000) (0MB)
[ 0.000000] EFI: mem123: type=4, attr=0xf, range=[0x0000000001e37000-0x0000000001e3d000) (0MB)
[ 0.000000] EFI: mem124: type=3, attr=0xf, range=[0x0000000001e3d000-0x0000000001e40000) (0MB)
[ 0.000000] EFI: mem125: type=4, attr=0xf, range=[0x0000000001e40000-0x0000000001e48000) (0MB)
[ 0.000000] EFI: mem126: type=3, attr=0xf, range=[0x0000000001e48000-0x0000000001e4a000) (0MB)
[ 0.000000] EFI: mem127: type=4, attr=0xf, range=[0x0000000001e4a000-0x0000000001e4c000) (0MB)
[ 0.000000] EFI: mem128: type=3, attr=0xf, range=[0x0000000001e4c000-0x0000000001e51000) (0MB)
[ 0.000000] EFI: mem129: type=4, attr=0xf, range=[0x0000000001e51000-0x0000000001e57000) (0MB)
[ 0.000000] EFI: mem130: type=3, attr=0xf, range=[0x0000000001e57000-0x0000000001e5a000) (0MB)
[ 0.000000] EFI: mem131: type=4, attr=0xf, range=[0x0000000001e5a000-0x0000000001e76000) (0MB)
[ 0.000000] EFI: mem132: type=3, attr=0xf, range=[0x0000000001e76000-0x0000000001e84000) (0MB)
[ 0.000000] EFI: mem133: type=4, attr=0xf, range=[0x0000000001e84000-0x00000000021c2000) (3MB)
[ 0.000000] EFI: mem134: type=7, attr=0xf, range=[0x00000000021c2000-0x00000000021c5000) (0MB)
[ 0.000000] EFI: mem135: type=4, attr=0xf, range=[0x00000000021c5000-0x00000000021ed000) (0MB)
[ 0.000000] EFI: mem136: type=3, attr=0xf, range=[0x00000000021ed000-0x00000000021ef000) (0MB)
[ 0.000000] EFI: mem137: type=4, attr=0xf, range=[0x00000000021ef000-0x000000000220e000) (0MB)
[ 0.000000] EFI: mem138: type=3, attr=0xf, range=[0x000000000220e000-0x0000000002217000) (0MB)
[ 0.000000] EFI: mem139: type=4, attr=0xf, range=[0x0000000002217000-0x0000000002219000) (0MB)
[ 0.000000] EFI: mem140: type=7, attr=0xf, range=[0x0000000002219000-0x000000000222d000) (0MB)
[ 0.000000] EFI: mem141: type=4, attr=0xf, range=[0x000000000222d000-0x0000000002780000) (5MB)
[ 0.000000] EFI: mem142: type=7, attr=0xf, range=[0x0000000002780000-0x00000000027ee000) (0MB)
[ 0.000000] EFI: mem143: type=1, attr=0xf, range=[0x00000000027ee000-0x000000000285c000) (0MB)
[ 0.000000] EFI: mem144: type=7, attr=0xf, range=[0x000000000285c000-0x000000008fcbc000) (2260MB)
[ 0.000000] EFI: mem145: type=2, attr=0xf, range=[0x000000008fcbc000-0x00000000bf35c000) (758MB)
[ 0.000000] EFI: mem146: type=10, attr=0xf, range=[0x00000000bf35c000-0x00000000bf3ad000) (0MB)
[ 0.000000] EFI: mem147: type=6, attr=0x800000000000000f, range=[0x00000000bf3ad000-0x00000000bf3b0000) (0MB)
[ 0.000000] EFI: mem148: type=0, attr=0xf, range=[0x00000000bf3b0000-0x00000000bf60a000) (2MB)
[ 0.000000] EFI: mem149: type=5, attr=0x800000000000000f, range=[0x00000000bf60a000-0x00000000bf60b000) (0MB)
[ 0.000000] EFI: mem150: type=6, attr=0x800000000000000f, range=[0x00000000bf60b000-0x00000000bf60c000) (0MB)
[ 0.000000] EFI: mem151: type=7, attr=0xf, range=[0x00000000bf60c000-0x00000000bf60d000) (0MB)
[ 0.000000] EFI: mem152: type=9, attr=0xf, range=[0x00000000bf60d000-0x00000000bf60e000) (0MB)
[ 0.000000] EFI: mem153: type=10, attr=0xf, range=[0x00000000bf60e000-0x00000000bf618000) (0MB)
[ 0.000000] EFI: mem154: type=5, attr=0x800000000000000f, range=[0x00000000bf618000-0x00000000bf61c000) (0MB)
[ 0.000000] EFI: mem155: type=6, attr=0x800000000000000f, range=[0x00000000bf61c000-0x00000000bf62d000) (0MB)
[ 0.000000] EFI: mem156: type=5, attr=0x800000000000000f, range=[0x00000000bf62d000-0x00000000bf63a000) (0MB)
[ 0.000000] EFI: mem157: type=6, attr=0x800000000000000f, range=[0x00000000bf63a000-0x00000000bf63d000) (0MB)
[ 0.000000] EFI: mem158: type=10, attr=0xf, range=[0x00000000bf63d000-0x00000000bf680000) (0MB)
[ 0.000000] EFI: mem159: type=3, attr=0xf, range=[0x00000000bf680000-0x00000000bf7f4000) (1MB)
[ 0.000000] EFI: mem160: type=4, attr=0xf, range=[0x00000000bf7f4000-0x00000000bf7f7000) (0MB)
[ 0.000000] EFI: mem161: type=3, attr=0xf, range=[0x00000000bf7f7000-0x00000000bf800000) (0MB)
[ 0.000000] EFI: mem162: type=7, attr=0xf, range=[0x0000000100000000-0x000000023f800000) (5112MB)
[ 0.000000] EFI: mem163: type=11, attr=0x8000000000000001, range=[0x00000000fed1c000-0x00000000fed20000) (0MB)
[ 0.000000] EFI: mem164: type=11, attr=0x8000000000000001, range=[0x00000000fed20000-0x00000000fed40000) (0MB)
[ 0.000000] EFI: mem165: type=11, attr=0x8000000000000001, range=[0x00000000ff000000-0x0000000100000000) (16MB)
[ 0.000000] DMI 2.6 present.
[ 0.000000] DMI: To Be Filled By O.E.M. To Be Filled By O.E.M./P67 Pro3, BIOS P1.80 02/15/2011
[ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
[ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
[ 0.000000] No AGP bridge found
[ 0.000000] last_pfn = 0x23f800 max_arch_pfn = 0x400000000
[ 0.000000] MTRR default type: uncachable
[ 0.000000] MTRR fixed ranges enabled:
[ 0.000000] 00000-9FFFF write-back
[ 0.000000] A0000-BFFFF uncachable
[ 0.000000] C0000-CFFFF write-protect
[ 0.000000] D0000-DFFFF uncachable
[ 0.000000] E0000-E7FFF write-through
[ 0.000000] E8000-FFFFF write-protect
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 base 000000000 mask E00000000 write-back
[ 0.000000] 1 base 200000000 mask FC0000000 write-back
[ 0.000000] 2 base 0C0000000 mask FC0000000 uncachable
[ 0.000000] 3 base 23F800000 mask FFF800000 uncachable
[ 0.000000] 4 disabled
[ 0.000000] 5 disabled
[ 0.000000] 6 disabled
[ 0.000000] 7 disabled
[ 0.000000] 8 disabled
[ 0.000000] 9 disabled
[ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[ 0.000000] e820 update range: 00000000c0000000 - 0000000100000000 (usable) ==> (reserved)
[ 0.000000] last_pfn = 0xbf800 max_arch_pfn = 0x400000000
[ 0.000000] found SMP MP-table at [ffff8800000fcf50] fcf50
[ 0.000000] initial memory mapped : 0 - 20000000
[ 0.000000] Base memory trampoline at [ffff880000073000] 73000 size 20480
[ 0.000000] init_memory_mapping: 0000000000000000-00000000bf800000
[ 0.000000] 0000000000 - 00bf800000 page 2M
[ 0.000000] kernel direct mapping tables up to bf800000 @ bf358000-bf35c000
[ 0.000000] init_memory_mapping: 0000000100000000-000000023f800000
[ 0.000000] 0100000000 - 023f800000 page 2M
[ 0.000000] kernel direct mapping tables up to 23f800000 @ 23f7f6000-23f800000
[ 0.000000] ACPI: RSDP 00000000bf3a5000 00024 (v02 ALASKA)
[ 0.000000] ACPI: XSDT 00000000bf3a5068 00054 (v01 ALASKA A M I 01072009 AMI 00010013)
[ 0.000000] ACPI: FACP 00000000bf3ac040 000F4 (v04 ALASKA A M I 01072009 AMI 00010013)
[ 0.000000] ACPI: DSDT 00000000bf3a5150 06EED (v02 ALASKA A M I 00000000 INTL 20051117)
[ 0.000000] ACPI: FACS 00000000bf60ff80 00040
[ 0.000000] ACPI: APIC 00000000bf3ac138 00072 (v03 ALASKA A M I 01072009 AMI 00010013)
[ 0.000000] ACPI: SSDT 00000000bf3ac1b0 00102 (v01 AMICPU PROC 00000001 MSFT 03000001)
[ 0.000000] ACPI: MCFG 00000000bf3ac2b8 0003C (v01 ALASKA A M I 01072009 MSFT 00000097)
[ 0.000000] ACPI: AAFT 00000000bf3ac2f8 0006F (v01 ALASKA OEMAAFT 01072009 MSFT 00000097)
[ 0.000000] ACPI: HPET 00000000bf3ac368 00038 (v01 ALASKA A M I 01072009 AMI. 00000004)
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] No NUMA configuration found
[ 0.000000] Faking a node at 0000000000000000-000000023f800000
[ 0.000000] Initmem setup node 0 0000000000000000-000000023f800000
[ 0.000000] NODE_DATA [000000023f7fb000 - 000000023f7fffff]
[ 0.000000] [ffffea0000000000-ffffea0007dfffff] PMD -> [ffff880236e00000-ffff88023ddfffff] on node 0
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0x00000010 -> 0x00001000
[ 0.000000] DMA32 0x00001000 -> 0x00100000
[ 0.000000] Normal 0x00100000 -> 0x0023f800
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[5] active PFN ranges
[ 0.000000] 0: 0x00000010 -> 0x000000a0
[ 0.000000] 0: 0x00000100 -> 0x000bf35c
[ 0.000000] 0: 0x000bf60c -> 0x000bf60d
[ 0.000000] 0: 0x000bf680 -> 0x000bf800
[ 0.000000] 0: 0x00100000 -> 0x0023f800
[ 0.000000] On node 0 totalpages: 2092141
[ 0.000000] DMA zone: 56 pages used for memmap
[ 0.000000] DMA zone: 45 pages reserved
[ 0.000000] DMA zone: 3883 pages, LIFO batch:0
[ 0.000000] DMA32 zone: 14280 pages used for memmap
[ 0.000000] DMA32 zone: 765205 pages, LIFO batch:31
[ 0.000000] Normal zone: 17892 pages used for memmap
[ 0.000000] Normal zone: 1290780 pages, LIFO batch:31
[ 0.000000] ACPI: PM-Timer IO Port: 0x408
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
[ 0.000000] ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
[ 0.000000] IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 0.000000] ACPI: IRQ0 used by override.
[ 0.000000] ACPI: IRQ2 used by override.
[ 0.000000] ACPI: IRQ9 used by override.
[ 0.000000] Using ACPI (MADT) for SMP configuration information
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
[ 0.000000] nr_irqs_gsi: 40
[ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 0000000000100000
[ 0.000000] PM: Registered nosave memory: 00000000bf35c000 - 00000000bf3ad000
[ 0.000000] PM: Registered nosave memory: 00000000bf3ad000 - 00000000bf60c000
[ 0.000000] PM: Registered nosave memory: 00000000bf60d000 - 00000000bf60e000
[ 0.000000] PM: Registered nosave memory: 00000000bf60e000 - 00000000bf618000
[ 0.000000] PM: Registered nosave memory: 00000000bf618000 - 00000000bf63d000
[ 0.000000] PM: Registered nosave memory: 00000000bf63d000 - 00000000bf680000
[ 0.000000] PM: Registered nosave memory: 00000000bf800000 - 00000000fed1c000
[ 0.000000] PM: Registered nosave memory: 00000000fed1c000 - 00000000fed40000
[ 0.000000] PM: Registered nosave memory: 00000000fed40000 - 00000000ff000000
[ 0.000000] PM: Registered nosave memory: 00000000ff000000 - 0000000100000000
[ 0.000000] Allocating PCI resources starting at bf800000 (gap: bf800000:3f51c000)
[ 0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:4 nr_node_ids:1
[ 0.000000] PERCPU: Embedded 25 pages/cpu @ffff88023f400000 s71872 r8192 d22336 u524288
[ 0.000000] pcpu-alloc: s71872 r8192 d22336 u524288 alloc=1*2097152
[ 0.000000] pcpu-alloc: [0] 0 1 2 3
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 2059868
[ 0.000000] Policy zone: Normal
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.0.0-rc2-patser+ root=/dev/sdb2 ro rootflags=ssd,discard root=/dev/sdb2 devtmpfs.mount=1 video=efifb reboot=a,e,p init=/init quiet splash vt.handoff=7
[ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.000000] xsave/xrstor: enabled xstate_bv 0x7, cntxt size 0x340
[ 0.000000] Checking aperture...
[ 0.000000] No AGP bridge found
[ 0.000000] Memory: 8172384k/9428992k available (5632k kernel code, 1060428k absent, 196180k reserved, 5266k data, 768k init)
[ 0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] NR_IRQS:512
[ 0.000000] Extended CMOS year: 2000
[ 0.000000] Console: colour dummy device 80x25
[ 0.000000] console [tty0] enabled
[ 0.000000] allocated 67108864 bytes of page_cgroup
[ 0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups
[ 0.000000] hpet clockevent registered
[ 0.000000] Fast TSC calibration using PIT
[ 0.001000] Detected 3292.386 MHz processor.
[ 0.000001] Calibrating delay loop (skipped), value calculated using timer frequency.. 6584.77 BogoMIPS (lpj=3292386)
[ 0.000004] pid_max: default: 32768 minimum: 301
[ 0.002773] Security Framework initialized
[ 0.002781] SELinux: Initializing.
[ 0.002785] SELinux: Starting in permissive mode
[ 0.003153] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[ 0.005457] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[ 0.006514] Mount-cache hash table entries: 256
[ 0.006612] Initializing cgroup subsys debug
[ 0.006614] Initializing cgroup subsys cpuacct
[ 0.006617] Initializing cgroup subsys memory
[ 0.006622] Initializing cgroup subsys devices
[ 0.006623] Initializing cgroup subsys freezer
[ 0.006624] Initializing cgroup subsys net_cls
[ 0.006625] Initializing cgroup subsys blkio
[ 0.006642] CPU: Physical Processor ID: 0
[ 0.006642] CPU: Processor Core ID: 0
[ 0.006645] mce: CPU supports 9 MCE banks
[ 0.006653] CPU0: Thermal monitoring enabled (TM1)
[ 0.006658] using mwait in idle threads.
[ 0.006705] ACPI: Core revision 20110413
[ 0.012227] ftrace: allocating 20291 entries in 80 pages
[ 0.017271] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[ 0.027272] CPU0: Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz stepping 07
[ 0.128379] Performance Events: PEBS fmt1+, SandyBridge events, Intel PMU driver.
[ 0.128383] ... version: 3
[ 0.128384] ... bit width: 48
[ 0.128384] ... generic registers: 8
[ 0.128385] ... value mask: 0000ffffffffffff
[ 0.128386] ... max period: 000000007fffffff
[ 0.128386] ... fixed-purpose events: 3
[ 0.128387] ... event mask: 00000007000000ff
[ 0.144393] Booting Node 0, Processors #1
[ 0.144397] smpboot cpu 1: start_ip = 73000
[ 0.167375] calibrate_delay_direct() timer_rate_max=3292100 timer_rate_min=3292067 pre_start=33719376247 pre_end=33752297073
[ 0.179370] calibrate_delay_direct() timer_rate_max=3292094 timer_rate_min=3292067 pre_start=33758881203 pre_end=33791802023
[ 0.191368] calibrate_delay_direct() timer_rate_max=3292088 timer_rate_min=3292071 pre_start=33798386165 pre_end=33831306951
[ 0.203366] calibrate_delay_direct() timer_rate_max=3292087 timer_rate_min=3292065 pre_start=33837891141 pre_end=33870811919
[ 0.215364] calibrate_delay_direct() timer_rate_max=3292092 timer_rate_min=3292068 pre_start=33877396089 pre_end=33910316887
[ 0.241388] #2
[ 0.241392] smpboot cpu 2: start_ip = 73000
[ 0.264359] calibrate_delay_direct() timer_rate_max=3292099 timer_rate_min=3292075 pre_start=34038708054 pre_end=34071628928
[ 0.276354] calibrate_delay_direct() timer_rate_max=3292092 timer_rate_min=3292068 pre_start=34078213080 pre_end=34111133886
[ 0.288352] calibrate_delay_direct() timer_rate_max=3292094 timer_rate_min=3292068 pre_start=34117718030 pre_end=34150638824
[ 0.300350] calibrate_delay_direct() timer_rate_max=3292094 timer_rate_min=3292069 pre_start=34157222988 pre_end=34190143806
[ 0.312348] calibrate_delay_direct() timer_rate_max=3292094 timer_rate_min=3292067 pre_start=34196727938 pre_end=34229648732
[ 0.338370] #3 Ok.
[ 0.338374] smpboot cpu 3: start_ip = 73000
[ 0.361344] calibrate_delay_direct() timer_rate_max=3292098 timer_rate_min=3292071 pre_start=34358039851 pre_end=34390960689
[ 0.373339] calibrate_delay_direct() timer_rate_max=3292091 timer_rate_min=3292067 pre_start=34397544819 pre_end=34430465611
[ 0.385337] calibrate_delay_direct() timer_rate_max=3292097 timer_rate_min=3292066 pre_start=34437049761 pre_end=34469970569
[ 0.397335] calibrate_delay_direct() timer_rate_max=3292091 timer_rate_min=3292067 pre_start=34476554739 pre_end=34509475529
[ 0.409333] calibrate_delay_direct() timer_rate_max=3292086 timer_rate_min=3292063 pre_start=34516059741 pre_end=34548980491
[ 0.429467] Brought up 4 CPUs
[ 0.429469] Total of 4 processors activated (26337.32 BogoMIPS).
[ 0.430554] devtmpfs: initialized
[ 0.430631] PM: Registering ACPI NVS region at bf35c000 (331776 bytes)
[ 0.430635] PM: Registering ACPI NVS region at bf60e000 (40960 bytes)
[ 0.430636] PM: Registering ACPI NVS region at bf63d000 (274432 bytes)
[ 0.430698] NET: Registered protocol family 16
[ 0.430773] ACPI: bus type pci registered
[ 0.430796] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[ 0.430797] PCI: not using MMCONFIG
[ 0.430798] PCI: Using configuration type 1 for base access
[ 0.431093] bio: create slab <bio-0> at 0
[ 0.431832] ACPI: EC: Look up EC in DSDT
[ 0.432551] ACPI: Executed 1 blocks of module-level executable AML code
[ 0.433928] ACPI: SSDT 00000000bf60ec18 0038C (v01 AMI IST 00000001 MSFT 03000001)
[ 0.434118] ACPI: Dynamic OEM Table Load:
[ 0.434119] ACPI: SSDT (null) 0038C (v01 AMI IST 00000001 MSFT 03000001)
[ 0.434130] ACPI: SSDT 00000000bf60fe18 00084 (v01 AMI CST 00000001 MSFT 03000001)
[ 0.434297] ACPI: Dynamic OEM Table Load:
[ 0.434298] ACPI: SSDT (null) 00084 (v01 AMI CST 00000001 MSFT 03000001)
[ 0.434511] ACPI: Interpreter enabled
[ 0.434513] ACPI: (supports S0 S1 S3 S4 S5)
[ 0.434522] ACPI: Using IOAPIC for interrupt routing
[ 0.434533] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[ 0.434562] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboard resources
[ 0.459727] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
[ 0.461734] ACPI: No dock devices found.
[ 0.461735] HEST: Table not found.
[ 0.461736] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 0.461819] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[ 0.461910] pci_root PNP0A08:00: host bridge window [io 0x0000-0x0cf7]
[ 0.461911] pci_root PNP0A08:00: host bridge window [io 0x0d00-0xffff]
[ 0.461913] pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x000bffff]
[ 0.461914] pci_root PNP0A08:00: host bridge window [mem 0x000c8000-0x000dffff]
[ 0.461915] pci_root PNP0A08:00: host bridge window [mem 0xc0000000-0xffffffff]
[ 0.461921] pci 0000:00:00.0: [8086:0100] type 0 class 0x000600
[ 0.461943] pci 0000:00:01.0: [8086:0101] type 1 class 0x000604
[ 0.461957] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
[ 0.461959] pci 0000:00:01.0: PME# disabled
[ 0.462011] pci 0000:00:16.0: [8086:1c3a] type 0 class 0x000780
[ 0.462040] pci 0000:00:16.0: reg 10: [mem 0xfa208000-0xfa20800f 64bit]
[ 0.462121] pci 0000:00:16.0: PME# supported from D0 D3hot D3cold
[ 0.462125] pci 0000:00:16.0: PME# disabled
[ 0.462165] pci 0000:00:1a.0: [8086:1c2d] type 0 class 0x000c03
[ 0.462192] pci 0000:00:1a.0: reg 10: [mem 0xfa207000-0xfa2073ff]
[ 0.462289] pci 0000:00:1a.0: PME# supported from D0 D3hot D3cold
[ 0.462293] pci 0000:00:1a.0: PME# disabled
[ 0.462321] pci 0000:00:1b.0: [8086:1c20] type 0 class 0x000403
[ 0.462345] pci 0000:00:1b.0: reg 10: [mem 0xfa200000-0xfa203fff 64bit]
[ 0.462420] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
[ 0.462423] pci 0000:00:1b.0: PME# disabled
[ 0.462447] pci 0000:00:1c.0: [8086:1c10] type 1 class 0x000604
[ 0.462532] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[ 0.462535] pci 0000:00:1c.0: PME# disabled
[ 0.462567] pci 0000:00:1c.4: [8086:1c18] type 1 class 0x000604
[ 0.462651] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
[ 0.462654] pci 0000:00:1c.4: PME# disabled
[ 0.462682] pci 0000:00:1c.5: [8086:1c1a] type 1 class 0x000604
[ 0.462767] pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold
[ 0.462770] pci 0000:00:1c.5: PME# disabled
[ 0.462798] pci 0000:00:1c.6: [8086:1c1c] type 1 class 0x000604
[ 0.462882] pci 0000:00:1c.6: PME# supported from D0 D3hot D3cold
[ 0.462885] pci 0000:00:1c.6: PME# disabled
[ 0.462913] pci 0000:00:1c.7: [8086:244e] type 1 class 0x000604
[ 0.462997] pci 0000:00:1c.7: PME# supported from D0 D3hot D3cold
[ 0.463001] pci 0000:00:1c.7: PME# disabled
[ 0.463035] pci 0000:00:1d.0: [8086:1c26] type 0 class 0x000c03
[ 0.463062] pci 0000:00:1d.0: reg 10: [mem 0xfa206000-0xfa2063ff]
[ 0.463159] pci 0000:00:1d.0: PME# supported from D0 D3hot D3cold
[ 0.463163] pci 0000:00:1d.0: PME# disabled
[ 0.463191] pci 0000:00:1f.0: [8086:1c46] type 0 class 0x000601
[ 0.463339] pci 0000:00:1f.2: [8086:1c02] type 0 class 0x000106
[ 0.463365] pci 0000:00:1f.2: reg 10: [io 0xf070-0xf077]
[ 0.463375] pci 0000:00:1f.2: reg 14: [io 0xf060-0xf063]
[ 0.463385] pci 0000:00:1f.2: reg 18: [io 0xf050-0xf057]
[ 0.463395] pci 0000:00:1f.2: reg 1c: [io 0xf040-0xf043]
[ 0.463405] pci 0000:00:1f.2: reg 20: [io 0xf020-0xf03f]
[ 0.463415] pci 0000:00:1f.2: reg 24: [mem 0xfa205000-0xfa2057ff]
[ 0.463461] pci 0000:00:1f.2: PME# supported from D3hot
[ 0.463465] pci 0000:00:1f.2: PME# disabled
[ 0.463484] pci 0000:00:1f.3: [8086:1c22] type 0 class 0x000c05
[ 0.463504] pci 0000:00:1f.3: reg 10: [mem 0xfa204000-0xfa2040ff 64bit]
[ 0.463532] pci 0000:00:1f.3: reg 20: [io 0xf000-0xf01f]
[ 0.463584] pci 0000:01:00.0: [10de:06c0] type 0 class 0x000300
[ 0.463590] pci 0000:01:00.0: reg 10: [mem 0xf8000000-0xf9ffffff]
[ 0.463598] pci 0000:01:00.0: reg 14: [mem 0xd0000000-0xd7ffffff 64bit pref]
[ 0.463605] pci 0000:01:00.0: reg 1c: [mem 0xd8000000-0xdbffffff 64bit pref]
[ 0.463610] pci 0000:01:00.0: reg 24: [io 0xe000-0xe07f]
[ 0.463615] pci 0000:01:00.0: reg 30: [mem 0xfa000000-0xfa07ffff pref]
[ 0.463645] pci 0000:01:00.1: [10de:0be5] type 0 class 0x000403
[ 0.463652] pci 0000:01:00.1: reg 10: [mem 0xfa080000-0xfa083fff]
[ 0.465343] pci 0000:00:01.0: PCI bridge to [bus 01-01]
[ 0.465347] pci 0000:00:01.0: bridge window [io 0xe000-0xefff]
[ 0.465351] pci 0000:00:01.0: bridge window [mem 0xf8000000-0xfa0fffff]
[ 0.465357] pci 0000:00:01.0: bridge window [mem 0xd0000000-0xdbffffff 64bit pref]
[ 0.465436] pci 0000:00:1c.0: PCI bridge to [bus 02-02]
[ 0.465440] pci 0000:00:1c.0: bridge window [io 0xf000-0x0000] (disabled)
[ 0.465444] pci 0000:00:1c.0: bridge window [mem 0xfff00000-0x000fffff] (disabled)
[ 0.465451] pci 0000:00:1c.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[ 0.465535] pci 0000:03:00.0: [10ec:8168] type 0 class 0x000200
[ 0.465558] pci 0000:03:00.0: reg 10: [io 0xd000-0xd0ff]
[ 0.465599] pci 0000:03:00.0: reg 18: [mem 0xdc204000-0xdc204fff 64bit pref]
[ 0.465625] pci 0000:03:00.0: reg 20: [mem 0xdc200000-0xdc203fff 64bit pref]
[ 0.465698] pci 0000:03:00.0: supports D1 D2
[ 0.465699] pci 0000:03:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 0.465704] pci 0000:03:00.0: PME# disabled
[ 0.467350] pci 0000:00:1c.4: PCI bridge to [bus 03-03]
[ 0.467355] pci 0000:00:1c.4: bridge window [io 0xd000-0xdfff]
[ 0.467362] pci 0000:00:1c.4: bridge window [mem 0xfff00000-0x000fffff] (disabled)
[ 0.467372] pci 0000:00:1c.4: bridge window [mem 0xdc200000-0xdc2fffff 64bit pref]
[ 0.467473] pci 0000:04:00.0: [1b6f:7023] type 0 class 0x000c03
[ 0.467503] pci 0000:04:00.0: reg 10: [mem 0xfa100000-0xfa107fff 64bit]
[ 0.467625] pci 0000:04:00.0: supports D1 D2
[ 0.467626] pci 0000:04:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 0.467631] pci 0000:04:00.0: PME# disabled
[ 0.469349] pci 0000:00:1c.5: PCI bridge to [bus 04-04]
[ 0.469355] pci 0000:00:1c.5: bridge window [io 0xf000-0x0000] (disabled)
[ 0.469361] pci 0000:00:1c.5: bridge window [mem 0xfa100000-0xfa1fffff]
[ 0.469371] pci 0000:00:1c.5: bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[ 0.469449] pci 0000:00:1c.6: PCI bridge to [bus 05-05]
[ 0.469452] pci 0000:00:1c.6: bridge window [io 0xf000-0x0000] (disabled)
[ 0.469456] pci 0000:00:1c.6: bridge window [mem 0xfff00000-0x000fffff] (disabled)
[ 0.469463] pci 0000:00:1c.6: bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[ 0.469538] pci 0000:06:00.0: [1b21:1080] type 1 class 0x000604
[ 0.469663] pci 0000:00:1c.7: PCI bridge to [bus 06-07] (subtractive decode)
[ 0.469667] pci 0000:00:1c.7: bridge window [io 0xf000-0x0000] (disabled)
[ 0.469671] pci 0000:00:1c.7: bridge window [mem 0xfff00000-0x000fffff] (disabled)
[ 0.469677] pci 0000:00:1c.7: bridge window [mem 0xdc100000-0xdc1fffff 64bit pref]
[ 0.469679] pci 0000:00:1c.7: bridge window [io 0x0000-0x0cf7] (subtractive decode)
[ 0.469680] pci 0000:00:1c.7: bridge window [io 0x0d00-0xffff] (subtractive decode)
[ 0.469681] pci 0000:00:1c.7: bridge window [mem 0x000a0000-0x000bffff] (subtractive decode)
[ 0.469682] pci 0000:00:1c.7: bridge window [mem 0x000c8000-0x000dffff] (subtractive decode)
[ 0.469683] pci 0000:00:1c.7: bridge window [mem 0xc0000000-0xffffffff] (subtractive decode)
[ 0.469754] pci 0000:07:00.0: [109e:036e] type 0 class 0x000400
[ 0.469795] pci 0000:07:00.0: reg 10: [mem 0xdc101000-0xdc101fff pref]
[ 0.469992] pci 0000:07:00.1: [109e:0878] type 0 class 0x000480
[ 0.470032] pci 0000:07:00.1: reg 10: [mem 0xdc100000-0xdc100fff pref]
[ 0.470304] pci 0000:06:00.0: PCI bridge to [bus 07-07] (subtractive decode)
[ 0.470315] pci 0000:06:00.0: bridge window [io 0xfff000-0x0000] (disabled)
[ 0.470321] pci 0000:06:00.0: bridge window [mem 0xfff00000-0x000fffff] (disabled)
[ 0.470334] pci 0000:06:00.0: bridge window [mem 0xdc100000-0xdc1fffff 64bit pref]
[ 0.470335] pci 0000:06:00.0: bridge window [??? 0x00000000 flags 0x0] (subtractive decode)
[ 0.470336] pci 0000:06:00.0: bridge window [??? 0x00000000 flags 0x0] (subtractive decode)
[ 0.470337] pci 0000:06:00.0: bridge window [mem 0xdc100000-0xdc1fffff 64bit pref] (subtractive decode)
[ 0.470338] pci 0000:06:00.0: bridge window [??? 0x00000000 flags 0x0] (subtractive decode)
[ 0.470339] pci 0000:06:00.0: bridge window [io 0x0000-0x0cf7] (subtractive decode)
[ 0.470340] pci 0000:06:00.0: bridge window [io 0x0d00-0xffff] (subtractive decode)
[ 0.470341] pci 0000:06:00.0: bridge window [mem 0x000a0000-0x000bffff] (subtractive decode)
[ 0.470343] pci 0000:06:00.0: bridge window [mem 0x000c8000-0x000dffff] (subtractive decode)
[ 0.470344] pci 0000:06:00.0: bridge window [mem 0xc0000000-0xffffffff] (subtractive decode)
[ 0.470389] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[ 0.470431] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT]
[ 0.470444] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX4._PRT]
[ 0.470454] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX5._PRT]
[ 0.470465] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX6._PRT]
[ 0.470476] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX7._PRT]
[ 0.470487] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX7.PE2P._PRT]
[ 0.470507] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
[ 0.470553] pci0000:00: Requesting ACPI _OSC control (0x1d)
[ 0.470607] pci0000:00: ACPI _OSC control (0x1d) granted
[ 0.472320] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15)
[ 0.472347] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *10 11 12 14 15)
[ 0.472368] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 10 11 12 14 15)
[ 0.472389] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 10 11 12 14 15)
[ 0.472410] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0
[ 0.472431] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) *0
[ 0.472452] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 *5 6 7 10 11 12 14 15)
[ 0.472473] ACPI: PCI Interrupt Link [LNKH] (IRQs *3 4 5 6 7 10 11 12 14 15)
[ 0.472518] SCSI subsystem initialized
[ 0.472533] libata version 3.00 loaded.
[ 0.472544] usbcore: registered new interface driver usbfs
[ 0.472549] usbcore: registered new interface driver hub
[ 0.472557] usbcore: registered new device driver usb
[ 0.472576] wmi: Mapper loaded
[ 0.472577] PCI: Using ACPI for IRQ routing
[ 0.482523] PCI: pci_cache_line_size set to 64 bytes
[ 0.482600] reserve RAM buffer: 00000000bf35c000 - 00000000bfffffff
[ 0.482601] reserve RAM buffer: 00000000bf60d000 - 00000000bfffffff
[ 0.482603] reserve RAM buffer: 00000000bf800000 - 00000000bfffffff
[ 0.482604] reserve RAM buffer: 000000023f800000 - 000000023fffffff
[ 0.482654] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0
[ 0.482658] hpet0: 8 comparators, 64-bit 14.318180 MHz counter
[ 0.484673] Switching to clocksource hpet
[ 0.485328] Switched to NOHz mode on CPU #0
[ 0.485379] Switched to NOHz mode on CPU #1
[ 0.485387] Switched to NOHz mode on CPU #2
[ 0.485456] Switched to NOHz mode on CPU #3
[ 0.485795] pnp: PnP ACPI init
[ 0.485800] ACPI: bus type pnp registered
[ 0.485852] pnp 00:00: [bus 00-ff]
[ 0.485854] pnp 00:00: [io 0x0cf8-0x0cff]
[ 0.485854] pnp 00:00: [io 0x0000-0x0cf7 window]
[ 0.485855] pnp 00:00: [io 0x0d00-0xffff window]
[ 0.485856] pnp 00:00: [mem 0x000a0000-0x000bffff window]
[ 0.485857] pnp 00:00: [mem 0x000c8000-0x000dffff window]
[ 0.485858] pnp 00:00: [mem 0xc0000000-0xffffffff window]
[ 0.485859] pnp 00:00: [mem 0x00000000 window]
[ 0.485879] pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 (active)
[ 0.485902] pnp 00:01: [mem 0xfed10000-0xfed19fff]
[ 0.485903] pnp 00:01: [mem 0xe0000000-0xefffffff]
[ 0.485904] pnp 00:01: [mem 0xfed90000-0xfed93fff]
[ 0.485905] pnp 00:01: [mem 0xfed20000-0xfed3ffff]
[ 0.485906] pnp 00:01: [mem 0xfee00000-0xfee0ffff]
[ 0.485924] system 00:01: [mem 0xfed10000-0xfed19fff] has been reserved
[ 0.485925] system 00:01: [mem 0xe0000000-0xefffffff] has been reserved
[ 0.485926] system 00:01: [mem 0xfed90000-0xfed93fff] has been reserved
[ 0.485927] system 00:01: [mem 0xfed20000-0xfed3ffff] has been reserved
[ 0.485929] system 00:01: [mem 0xfee00000-0xfee0ffff] has been reserved
[ 0.485930] system 00:01: Plug and Play ACPI device, IDs PNP0c01 (active)
[ 0.485953] pnp 00:02: [io 0x0000-0xffffffffffffffff disabled]
[ 0.485954] pnp 00:02: [io 0x0290-0x029f]
[ 0.485955] pnp 00:02: [io 0x0000-0xffffffffffffffff disabled]
[ 0.485970] system 00:02: [io 0x0290-0x029f] has been reserved
[ 0.485971] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 0.486080] pnp 00:03: [dma 4]
[ 0.486081] pnp 00:03: [io 0x0000-0x000f]
[ 0.486082] pnp 00:03: [io 0x0081-0x0083]
[ 0.486083] pnp 00:03: [io 0x0087]
[ 0.486084] pnp 00:03: [io 0x0089-0x008b]
[ 0.486085] pnp 00:03: [io 0x008f]
[ 0.486086] pnp 00:03: [io 0x00c0-0x00df]
[ 0.486095] pnp 00:03: Plug and Play ACPI device, IDs PNP0200 (active)
[ 0.486099] pnp 00:04: [io 0x0070-0x0071]
[ 0.486104] pnp 00:04: [irq 8]
[ 0.486113] pnp 00:04: Plug and Play ACPI device, IDs PNP0b00 (active)
[ 0.486116] pnp 00:05: [io 0x0061]
[ 0.486125] pnp 00:05: Plug and Play ACPI device, IDs PNP0800 (active)
[ 0.486132] pnp 00:06: [io 0x0010-0x001f]
[ 0.486133] pnp 00:06: [io 0x0022-0x003f]
[ 0.486133] pnp 00:06: [io 0x0044-0x005f]
[ 0.486134] pnp 00:06: [io 0x0062-0x0063]
[ 0.486135] pnp 00:06: [io 0x0065-0x006f]
[ 0.486136] pnp 00:06: [io 0x0072-0x007f]
[ 0.486136] pnp 00:06: [io 0x0080]
[ 0.486137] pnp 00:06: [io 0x0084-0x0086]
[ 0.486138] pnp 00:06: [io 0x0088]
[ 0.486139] pnp 00:06: [io 0x008c-0x008e]
[ 0.486139] pnp 00:06: [io 0x0090-0x009f]
[ 0.486140] pnp 00:06: [io 0x00a2-0x00bf]
[ 0.486141] pnp 00:06: [io 0x00e0-0x00ef]
[ 0.486142] pnp 00:06: [io 0x04d0-0x04d1]
[ 0.486160] system 00:06: [io 0x04d0-0x04d1] has been reserved
[ 0.486161] system 00:06: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 0.486165] pnp 00:07: [io 0x00f0-0x00ff]
[ 0.486168] pnp 00:07: [irq 13]
[ 0.486177] pnp 00:07: Plug and Play ACPI device, IDs PNP0c04 (active)
[ 0.486306] pnp 00:08: [io 0x0400-0x0453]
[ 0.486306] pnp 00:08: [io 0x0458-0x047f]
[ 0.486307] pnp 00:08: [io 0x1180-0x119f]
[ 0.486308] pnp 00:08: [io 0x0500-0x057f]
[ 0.486309] pnp 00:08: [mem 0xfed1c000-0xfed1ffff]
[ 0.486310] pnp 00:08: [mem 0xfec00000-0xfecfffff]
[ 0.486311] pnp 00:08: [mem 0xfed08000-0xfed08fff]
[ 0.486311] pnp 00:08: [mem 0xff000000-0xffffffff]
[ 0.486329] system 00:08: [io 0x0400-0x0453] has been reserved
[ 0.486330] system 00:08: [io 0x0458-0x047f] has been reserved
[ 0.486331] system 00:08: [io 0x1180-0x119f] has been reserved
[ 0.486332] system 00:08: [io 0x0500-0x057f] has been reserved
[ 0.486334] system 00:08: [mem 0xfed1c000-0xfed1ffff] has been reserved
[ 0.486335] system 00:08: [mem 0xfec00000-0xfecfffff] could not be reserved
[ 0.486336] system 00:08: [mem 0xfed08000-0xfed08fff] has been reserved
[ 0.486337] system 00:08: [mem 0xff000000-0xffffffff] has been reserved
[ 0.486338] system 00:08: Plug and Play ACPI device, IDs PNP0c01 (active)
[ 0.486353] pnp 00:09: [io 0x0454-0x0457]
[ 0.486369] system 00:09: [io 0x0454-0x0457] has been reserved
[ 0.486371] system 00:09: Plug and Play ACPI device, IDs INT3f0d PNP0c02 (active)
[ 0.486422] pnp 00:0a: [mem 0xfed00000-0xfed003ff]
[ 0.486438] pnp 00:0a: Plug and Play ACPI device, IDs PNP0103 (active)
[ 0.486508] pnp: PnP ACPI: found 11 devices
[ 0.486509] ACPI: ACPI bus type pnp unregistered
[ 0.491646] PCI: max bus depth: 2 pci_try_num: 3
[ 0.491710] pci 0000:00:01.0: PCI bridge to [bus 01-01]
[ 0.491712] pci 0000:00:01.0: bridge window [io 0xe000-0xefff]
[ 0.491713] pci 0000:00:01.0: bridge window [mem 0xf8000000-0xfa0fffff]
[ 0.491715] pci 0000:00:01.0: bridge window [mem 0xd0000000-0xdbffffff 64bit pref]
[ 0.491717] pci 0000:00:1c.0: PCI bridge to [bus 02-02]
[ 0.491723] pci 0000:00:1c.0: bridge window [io disabled]
[ 0.491729] pci 0000:00:1c.0: bridge window [mem disabled]
[ 0.491732] pci 0000:00:1c.0: bridge window [mem pref disabled]
[ 0.491739] pci 0000:00:1c.4: PCI bridge to [bus 03-03]
[ 0.491741] pci 0000:00:1c.4: bridge window [io 0xd000-0xdfff]
[ 0.491747] pci 0000:00:1c.4: bridge window [mem disabled]
[ 0.491750] pci 0000:00:1c.4: bridge window [mem 0xdc200000-0xdc2fffff 64bit pref]
[ 0.491757] pci 0000:00:1c.5: PCI bridge to [bus 04-04]
[ 0.491758] pci 0000:00:1c.5: bridge window [io disabled]
[ 0.491763] pci 0000:00:1c.5: bridge window [mem 0xfa100000-0xfa1fffff]
[ 0.491767] pci 0000:00:1c.5: bridge window [mem pref disabled]
[ 0.491773] pci 0000:00:1c.6: PCI bridge to [bus 05-05]
[ 0.491774] pci 0000:00:1c.6: bridge window [io disabled]
[ 0.491779] pci 0000:00:1c.6: bridge window [mem disabled]
[ 0.491783] pci 0000:00:1c.6: bridge window [mem pref disabled]
[ 0.491790] pci 0000:06:00.0: PCI bridge to [bus 07-07]
[ 0.491790] pci 0000:06:00.0: bridge window [io disabled]
[ 0.491798] pci 0000:06:00.0: bridge window [mem disabled]
[ 0.491804] pci 0000:06:00.0: bridge window [mem 0xdc100000-0xdc1fffff 64bit pref]
[ 0.491815] pci 0000:00:1c.7: PCI bridge to [bus 06-07]
[ 0.491815] pci 0000:00:1c.7: bridge window [io disabled]
[ 0.491820] pci 0000:00:1c.7: bridge window [mem disabled]
[ 0.491824] pci 0000:00:1c.7: bridge window [mem 0xdc100000-0xdc1fffff 64bit pref]
[ 0.491835] pci 0000:00:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 0.491837] pci 0000:00:01.0: setting latency timer to 64
[ 0.491842] pci 0000:00:1c.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 0.491846] pci 0000:00:1c.0: setting latency timer to 64
[ 0.491851] pci 0000:00:1c.4: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 0.491855] pci 0000:00:1c.4: setting latency timer to 64
[ 0.491860] pci 0000:00:1c.5: PCI INT B -> GSI 16 (level, low) -> IRQ 16
[ 0.491864] pci 0000:00:1c.5: setting latency timer to 64
[ 0.491870] pci 0000:00:1c.6: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[ 0.491874] pci 0000:00:1c.6: setting latency timer to 64
[ 0.491880] pci 0000:00:1c.7: PCI INT D -> GSI 19 (level, low) -> IRQ 19
[ 0.491884] pci 0000:00:1c.7: setting latency timer to 64
[ 0.491890] pci 0000:06:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[ 0.491895] pci 0000:06:00.0: setting latency timer to 64
[ 0.491899] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7]
[ 0.491900] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff]
[ 0.491901] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
[ 0.491902] pci_bus 0000:00: resource 7 [mem 0x000c8000-0x000dffff]
[ 0.491903] pci_bus 0000:00: resource 8 [mem 0xc0000000-0xffffffff]
[ 0.491904] pci_bus 0000:01: resource 0 [io 0xe000-0xefff]
[ 0.491905] pci_bus 0000:01: resource 1 [mem 0xf8000000-0xfa0fffff]
[ 0.491906] pci_bus 0000:01: resource 2 [mem 0xd0000000-0xdbffffff 64bit pref]
[ 0.491907] pci_bus 0000:03: resource 0 [io 0xd000-0xdfff]
[ 0.491908] pci_bus 0000:03: resource 2 [mem 0xdc200000-0xdc2fffff 64bit pref]
[ 0.491909] pci_bus 0000:04: resource 1 [mem 0xfa100000-0xfa1fffff]
[ 0.491910] pci_bus 0000:06: resource 2 [mem 0xdc100000-0xdc1fffff 64bit pref]
[ 0.491911] pci_bus 0000:06: resource 4 [io 0x0000-0x0cf7]
[ 0.491912] pci_bus 0000:06: resource 5 [io 0x0d00-0xffff]
[ 0.491913] pci_bus 0000:06: resource 6 [mem 0x000a0000-0x000bffff]
[ 0.491914] pci_bus 0000:06: resource 7 [mem 0x000c8000-0x000dffff]
[ 0.491915] pci_bus 0000:06: resource 8 [mem 0xc0000000-0xffffffff]
[ 0.491916] pci_bus 0000:07: resource 2 [mem 0xdc100000-0xdc1fffff 64bit pref]
[ 0.491917] pci_bus 0000:07: resource 6 [mem 0xdc100000-0xdc1fffff 64bit pref]
[ 0.491918] pci_bus 0000:07: resource 8 [io 0x0000-0x0cf7]
[ 0.491919] pci_bus 0000:07: resource 9 [io 0x0d00-0xffff]
[ 0.491920] pci_bus 0000:07: resource 10 [mem 0x000a0000-0x000bffff]
[ 0.491921] pci_bus 0000:07: resource 11 [mem 0x000c8000-0x000dffff]
[ 0.491922] pci_bus 0000:07: resource 12 [mem 0xc0000000-0xffffffff]
[ 0.491938] NET: Registered protocol family 2
[ 0.492056] IP route cache hash table entries: 262144 (order: 9, 2097152 bytes)
[ 0.492599] TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
[ 0.494682] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[ 0.494961] TCP: Hash tables configured (established 524288 bind 65536)
[ 0.494962] TCP reno registered
[ 0.494970] UDP hash table entries: 4096 (order: 5, 131072 bytes)
[ 0.495013] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)
[ 0.495120] NET: Registered protocol family 1
[ 0.740760] pci 0000:01:00.0: Boot video device
[ 0.740832] PCI: CLS 64 bytes, default 64
[ 0.740866] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[ 0.740868] Placing 64MB software IO TLB between ffff8800bb1bf000 - ffff8800bf1bf000
[ 0.740869] software IO TLB at phys 0xbb1bf000 - 0xbf1bf000
[ 0.741288] audit: initializing netlink socket (disabled)
[ 0.741294] type=2000 audit(1307988464.579:1): initialized
[ 0.761922] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[ 0.791007] VFS: Disk quotas dquot_6.5.2
[ 0.791041] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 0.791320] Btrfs loaded
[ 0.791323] msgmni has been set to 15967
[ 0.791359] SELinux: Registering netfilter hooks
[ 0.791599] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[ 0.791614] io scheduler noop registered
[ 0.791631] io scheduler cfq registered (default)
[ 0.791686] pcieport 0000:00:01.0: setting latency timer to 64
[ 0.791700] pcieport 0000:00:01.0: irq 40 for MSI/MSI-X
[ 0.791752] pcieport 0000:00:1c.0: setting latency timer to 64
[ 0.791803] pcieport 0000:00:1c.0: irq 41 for MSI/MSI-X
[ 0.791877] pcieport 0000:00:1c.4: setting latency timer to 64
[ 0.791928] pcieport 0000:00:1c.4: irq 42 for MSI/MSI-X
[ 0.792001] pcieport 0000:00:1c.5: setting latency timer to 64
[ 0.792052] pcieport 0000:00:1c.5: irq 43 for MSI/MSI-X
[ 0.792127] pcieport 0000:00:1c.6: setting latency timer to 64
[ 0.792177] pcieport 0000:00:1c.6: irq 44 for MSI/MSI-X
[ 0.792252] pcieport 0000:00:01.0: Signaling PME through PCIe PME interrupt
[ 0.792253] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
[ 0.792254] pci 0000:01:00.1: Signaling PME through PCIe PME interrupt
[ 0.792255] pcie_pme 0000:00:01.0:pcie01: service driver pcie_pme loaded
[ 0.792271] pcieport 0000:00:1c.0: Signaling PME through PCIe PME interrupt
[ 0.792275] pcie_pme 0000:00:1c.0:pcie01: service driver pcie_pme loaded
[ 0.792290] pcieport 0000:00:1c.4: Signaling PME through PCIe PME interrupt
[ 0.792291] pci 0000:03:00.0: Signaling PME through PCIe PME interrupt
[ 0.792295] pcie_pme 0000:00:1c.4:pcie01: service driver pcie_pme loaded
[ 0.792311] pcieport 0000:00:1c.5: Signaling PME through PCIe PME interrupt
[ 0.792312] pci 0000:04:00.0: Signaling PME through PCIe PME interrupt
[ 0.792316] pcie_pme 0000:00:1c.5:pcie01: service driver pcie_pme loaded
[ 0.792331] pcieport 0000:00:1c.6: Signaling PME through PCIe PME interrupt
[ 0.792335] pcie_pme 0000:00:1c.6:pcie01: service driver pcie_pme loaded
[ 0.792342] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ 0.792353] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[ 0.792384] efifb: probing for efifb
[ 0.792733] efifb: framebuffer at 0xd9000000, mapped to 0xffffc90012880000, using 3072k, total 3072k
[ 0.792734] efifb: mode is 1024x768x32, linelength=4096, pages=1
[ 0.792735] efifb: scrolling: redraw
[ 0.792736] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[ 0.804418] Console: switching to colour frame buffer device 128x48
[ 0.816079] fb0: EFI VGA frame buffer device
[ 0.816082] intel_idle: MWAIT substates: 0x1120
[ 0.816083] intel_idle: v0.4 model 0x2A
[ 0.816083] intel_idle: lapic_timer_reliable_states 0xffffffff
[ 0.816131] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
[ 0.816133] ACPI: Power Button [PWRB]
[ 0.816151] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[ 0.816152] ACPI: Power Button [PWRF]
[ 0.816240] ACPI: acpi_idle yielding to intel_idle
[ 0.817100] ERST: Table is not found!
[ 0.817132] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 0.880933] Linux agpgart interface v0.103
[ 0.881409] brd: module loaded
[ 0.881601] loop: module loaded
[ 0.881640] ahci 0000:00:1f.2: version 3.0
[ 0.881647] ahci 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19
[ 0.881682] ahci 0000:00:1f.2: irq 45 for MSI/MSI-X
[ 0.881702] ahci: SSS flag set, parallel bus scan disabled
[ 0.892756] ahci 0000:00:1f.2: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
[ 0.892760] ahci 0000:00:1f.2: flags: 64bit ncq sntf stag pm led clo pio slum part ems sxs apst
[ 0.892767] ahci 0000:00:1f.2: setting latency timer to 64
[ 0.902965] scsi0 : ahci
[ 0.903004] scsi1 : ahci
[ 0.903031] scsi2 : ahci
[ 0.903057] scsi3 : ahci
[ 0.903083] scsi4 : ahci
[ 0.903108] scsi5 : ahci
[ 0.903167] ata1: SATA max UDMA/133 abar m2048@0xfa205000 port 0xfa205100 irq 45
[ 0.903169] ata2: SATA max UDMA/133 abar m2048@0xfa205000 port 0xfa205180 irq 45
[ 0.903171] ata3: SATA max UDMA/133 abar m2048@0xfa205000 port 0xfa205200 irq 45
[ 0.903173] ata4: SATA max UDMA/133 abar m2048@0xfa205000 port 0xfa205280 irq 45
[ 0.903176] ata5: SATA max UDMA/133 abar m2048@0xfa205000 port 0xfa205300 irq 45
[ 0.903178] ata6: SATA max UDMA/133 abar m2048@0xfa205000 port 0xfa205380 irq 45
[ 0.903204] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 0.903215] ehci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 0.903225] ehci_hcd 0000:00:1a.0: setting latency timer to 64
[ 0.903228] ehci_hcd 0000:00:1a.0: EHCI Host Controller
[ 0.903232] ehci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 1
[ 0.903260] ehci_hcd 0000:00:1a.0: debug port 2
[ 0.907148] ehci_hcd 0000:00:1a.0: cache line size of 64 is not supported
[ 0.907158] ehci_hcd 0000:00:1a.0: irq 16, io mem 0xfa207000
[ 0.916725] ehci_hcd 0000:00:1a.0: USB 2.0 started, EHCI 1.00
[ 0.916836] hub 1-0:1.0: USB hub found
[ 0.916839] hub 1-0:1.0: 2 ports detected
[ 0.916871] ehci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
[ 0.916878] ehci_hcd 0000:00:1d.0: setting latency timer to 64
[ 0.916880] ehci_hcd 0000:00:1d.0: EHCI Host Controller
[ 0.916882] ehci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
[ 0.916902] ehci_hcd 0000:00:1d.0: debug port 2
[ 0.920788] ehci_hcd 0000:00:1d.0: cache line size of 64 is not supported
[ 0.920797] ehci_hcd 0000:00:1d.0: irq 23, io mem 0xfa206000
[ 0.929725] ehci_hcd 0000:00:1d.0: USB 2.0 started, EHCI 1.00
[ 0.929825] hub 2-0:1.0: USB hub found
[ 0.929827] hub 2-0:1.0: 2 ports detected
[ 0.929854] uhci_hcd: USB Universal Host Controller Interface driver
[ 0.929884] i8042: PNP: No PS/2 controller found. Probing ports directly.
[ 0.932701] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 0.932719] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 0.932750] mousedev: PS/2 mouse device common for all mice
[ 0.932793] rtc_cmos 00:04: RTC can wake from S4
[ 0.932864] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
[ 0.932890] rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
[ 0.932930] device-mapper: uevent: version 1.0.3
[ 0.932960] device-mapper: ioctl: 4.20.0-ioctl (2011-02-02) initialised: [email protected]
[ 0.933010] cpuidle: using governor ladder
[ 0.933073] cpuidle: using governor menu
[ 0.933074] EFI Variables Facility v0.08 2004-May-17
[ 0.969678] usbcore: registered new interface driver usbhid
[ 0.969679] usbhid: USB HID core driver
[ 0.969792] TCP cubic registered
[ 0.969843] NET: Registered protocol family 10
[ 0.970086] Mobile IPv6
[ 0.970087] IPv6 over IPv4 tunneling driver
[ 0.970267] NET: Registered protocol family 17
[ 0.970307] PM: Hibernation image not present or could not be loaded.
[ 0.970313] registered taskstats version 1
[ 0.985350] rtc_cmos 00:04: setting system clock to 2011-06-13 18:07:45 UTC (1307988465)
[ 0.985427] ACPI Warning: For \_PR_.P000._PSS: SubPackage[0,1] - suspicious power dissipation values (20110413/nsrepair2-573)
[ 0.985585] ACPI Warning: For \_PR_.P001._PSS: SubPackage[0,1] - suspicious power dissipation values (20110413/nsrepair2-573)
[ 0.985658] ACPI Warning: For \_PR_.P002._PSS: SubPackage[0,1] - suspicious power dissipation values (20110413/nsrepair2-573)
[ 0.985741] ACPI Warning: For \_PR_.P003._PSS: SubPackage[0,1] - suspicious power dissipation values (20110413/nsrepair2-573)
[ 0.985792] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
[ 0.985793] EDD information not available.
[ 1.207752] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 1.218752] usb 1-1: new high speed USB device number 2 using ehci_hcd
[ 1.249416] ata1.00: ATA-7: ST3750640AS, 3.AAE, max UDMA/133
[ 1.249421] ata1.00: 1465149168 sectors, multi 16: LBA48 NCQ (depth 31/32)
[ 1.307717] ata1.00: configured for UDMA/133
[ 1.307967] scsi 0:0:0:0: Direct-Access ATA ST3750640AS 3.AA PQ: 0 ANSI: 5
[ 1.308140] sd 0:0:0:0: [sda] 1465149168 512-byte logical blocks: (750 GB/698 GiB)
[ 1.308340] sd 0:0:0:0: [sda] Write Protect is off
[ 1.308345] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 1.308421] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1.333362] hub 1-1:1.0: USB hub found
[ 1.333450] hub 1-1:1.0: 6 ports detected
[ 1.355718] sda: sda1
[ 1.356105] sd 0:0:0:0: [sda] Attached SCSI disk
[ 1.435730] usb 2-1: new high speed USB device number 2 using ehci_hcd
[ 1.550375] hub 2-1:1.0: USB hub found
[ 1.550445] hub 2-1:1.0: 8 ports detected
[ 1.612740] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 1.613051] ata2.00: ATA-7: INTEL SSDSA2M040G2GC, 2CV102M3, max UDMA/133
[ 1.613056] ata2.00: 78165360 sectors, multi 16: LBA48 NCQ (depth 31/32)
[ 1.613352] ata2.00: configured for UDMA/133
[ 1.613516] scsi 1:0:0:0: Direct-Access ATA INTEL SSDSA2M040 2CV1 PQ: 0 ANSI: 5
[ 1.613630] sd 1:0:0:0: [sdb] 78165360 512-byte logical blocks: (40.0 GB/37.2 GiB)
[ 1.613682] sd 1:0:0:0: [sdb] Write Protect is off
[ 1.613684] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 1.613714] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1.616311] sdb: sdb1 sdb2
[ 1.616773] sd 1:0:0:0: [sdb] Attached SCSI disk
[ 1.624862] usb 1-1.4: new low speed USB device number 3 using ehci_hcd
[ 1.720162] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/input/input2
[ 1.720234] logitech 0003:046D:C517.0001: input: USB HID v1.10 Keyboard [Logitech USB Receiver] on usb-0000:00:1a.0-1.4/input0
[ 1.725356] logitech 0003:046D:C517.0002: fixing up Logitech keyboard report descriptor
[ 1.725839] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.1/input/input3
[ 1.725978] logitech 0003:046D:C517.0002: input,hiddev0: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:1a.0-1.4/input1
[ 1.742723] Refined TSC clocksource calibration: 3292.521 MHz.
[ 1.742729] Switching to clocksource tsc
[ 1.917723] ata3: SATA link down (SStatus 0 SControl 300)
[ 2.222714] ata4: SATA link down (SStatus 0 SControl 300)
[ 2.527708] ata5: SATA link down (SStatus 0 SControl 300)
[ 2.832699] ata6: SATA link down (SStatus 0 SControl 300)
[ 2.856975] device fsid 73d3d24f-521e-4c12-a6b9-45fd63f1c0ba devid 1 transid 43498 /dev/root
[ 2.857294] btrfs: use ssd allocation scheme
[ 2.886944] VFS: Mounted root (btrfs filesystem) readonly on device 0:14.
[ 2.887209] devtmpfs: mounted
[ 2.888216] Freeing unused kernel memory: 768k freed
[ 2.888264] Write protecting the kernel read-only data: 10240k
[ 2.889143] Freeing unused kernel memory: 492k freed
[ 2.891647] Freeing unused kernel memory: 1836k freed
[ 2.891658] BUG: Bad page state in process swapper pfn:01850
[ 2.891780] page:ffffea0000055180 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.891959] page flags: 0x100000000000000()
[ 2.892057] Pid: 1, comm: swapper Not tainted 3.0.0-rc2-patser+ #39
[ 2.892058] Call Trace:
[ 2.892063] [<ffffffff810f689b>] ? dump_page+0x9b/0xd0
[ 2.892065] [<ffffffff810f6999>] bad_page+0xc9/0x120
[ 2.892066] [<ffffffff810f6aab>] free_pages_prepare+0xbb/0x130
[ 2.892068] [<ffffffff810f8379>] free_hot_cold_page+0x49/0x440
[ 2.892070] [<ffffffff810f8ddd>] __free_pages+0x2d/0x40
[ 2.892072] [<ffffffff810f8e33>] free_pages+0x43/0x50
[ 2.892074] [<ffffffff810284f2>] free_init_pages+0x132/0x1c0
[ 2.892076] [<ffffffff81028c83>] mark_rodata_ro+0x143/0x150
[ 2.892078] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.892080] [<ffffffff81ab8d2c>] kernel_init+0x158/0x163
[ 2.892083] [<ffffffff8157d6d4>] kernel_thread_helper+0x4/0x10
[ 2.892084] [<ffffffff81ab8bd4>] ? start_kernel+0x3c3/0x3c3
[ 2.892086] [<ffffffff8157d6d0>] ? gs_change+0xb/0xb
[ 2.892087] Disabling lock debugging due to kernel taint
[ 2.892091] BUG: Bad page state in process swapper pfn:01860
[ 2.892210] page:ffffea0000055500 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.892390] page flags: 0x100000000000000()
[ 2.892488] Pid: 1, comm: swapper Tainted: G B 3.0.0-rc2-patser+ #39
[ 2.892489] Call Trace:
[ 2.892490] [<ffffffff810f689b>] ? dump_page+0x9b/0xd0
[ 2.892491] [<ffffffff810f6999>] bad_page+0xc9/0x120
[ 2.892493] [<ffffffff810f6aab>] free_pages_prepare+0xbb/0x130
[ 2.892495] [<ffffffff810f8379>] free_hot_cold_page+0x49/0x440
[ 2.892496] [<ffffffff810f8ddd>] __free_pages+0x2d/0x40
[ 2.892498] [<ffffffff810f8e33>] free_pages+0x43/0x50
[ 2.892499] [<ffffffff810284f2>] free_init_pages+0x132/0x1c0
[ 2.892500] [<ffffffff81028c83>] mark_rodata_ro+0x143/0x150
[ 2.892502] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.892503] [<ffffffff81ab8d2c>] kernel_init+0x158/0x163
[ 2.892505] [<ffffffff8157d6d4>] kernel_thread_helper+0x4/0x10
[ 2.892506] [<ffffffff81ab8bd4>] ? start_kernel+0x3c3/0x3c3
[ 2.892508] [<ffffffff8157d6d0>] ? gs_change+0xb/0xb
[ 2.892510] BUG: Bad page state in process swapper pfn:01868
[ 2.892629] page:ffffea00000556c0 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.892811] page flags: 0x100000000000000()
[ 2.892906] Pid: 1, comm: swapper Tainted: G B 3.0.0-rc2-patser+ #39
[ 2.892907] Call Trace:
[ 2.892909] [<ffffffff810f689b>] ? dump_page+0x9b/0xd0
[ 2.892910] [<ffffffff810f6999>] bad_page+0xc9/0x120
[ 2.892912] [<ffffffff810f6aab>] free_pages_prepare+0xbb/0x130
[ 2.892913] [<ffffffff810f8379>] free_hot_cold_page+0x49/0x440
[ 2.892915] [<ffffffff810f8ddd>] __free_pages+0x2d/0x40
[ 2.892917] [<ffffffff810f8e33>] free_pages+0x43/0x50
[ 2.892918] [<ffffffff810284f2>] free_init_pages+0x132/0x1c0
[ 2.892919] [<ffffffff81028c83>] mark_rodata_ro+0x143/0x150
[ 2.892921] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.892922] [<ffffffff81ab8d2c>] kernel_init+0x158/0x163
[ 2.892923] [<ffffffff8157d6d4>] kernel_thread_helper+0x4/0x10
[ 2.892925] [<ffffffff81ab8bd4>] ? start_kernel+0x3c3/0x3c3
[ 2.892926] [<ffffffff8157d6d0>] ? gs_change+0xb/0xb
[ 2.892934] BUG: Bad page state in process swapper pfn:0187e
[ 2.893052] page:ffffea0000055b90 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.893232] page flags: 0x100000000000000()
[ 2.893329] Pid: 1, comm: swapper Tainted: G B 3.0.0-rc2-patser+ #39
[ 2.893330] Call Trace:
[ 2.893331] [<ffffffff810f689b>] ? dump_page+0x9b/0xd0
[ 2.893333] [<ffffffff810f6999>] bad_page+0xc9/0x120
[ 2.893334] [<ffffffff810f6aab>] free_pages_prepare+0xbb/0x130
[ 2.893336] [<ffffffff810f8379>] free_hot_cold_page+0x49/0x440
[ 2.893338] [<ffffffff810f8ddd>] __free_pages+0x2d/0x40
[ 2.893339] [<ffffffff810f8e33>] free_pages+0x43/0x50
[ 2.893340] [<ffffffff810284f2>] free_init_pages+0x132/0x1c0
[ 2.893342] [<ffffffff81028c83>] mark_rodata_ro+0x143/0x150
[ 2.893343] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.893345] [<ffffffff81ab8d2c>] kernel_init+0x158/0x163
[ 2.893346] [<ffffffff8157d6d4>] kernel_thread_helper+0x4/0x10
[ 2.893348] [<ffffffff81ab8bd4>] ? start_kernel+0x3c3/0x3c3
[ 2.893349] [<ffffffff8157d6d0>] ? gs_change+0xb/0xb
[ 2.893350] BUG: Bad page state in process swapper pfn:01880
[ 2.893469] page:ffffea0000055c00 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.893649] page flags: 0x100000000000000()
[ 2.893747] Pid: 1, comm: swapper Tainted: G B 3.0.0-rc2-patser+ #39
[ 2.893747] Call Trace:
[ 2.893749] [<ffffffff810f689b>] ? dump_page+0x9b/0xd0
[ 2.893750] [<ffffffff810f6999>] bad_page+0xc9/0x120
[ 2.893752] [<ffffffff810f6aab>] free_pages_prepare+0xbb/0x130
[ 2.893753] [<ffffffff810f8379>] free_hot_cold_page+0x49/0x440
[ 2.893755] [<ffffffff810f8ddd>] __free_pages+0x2d/0x40
[ 2.893757] [<ffffffff810f8e33>] free_pages+0x43/0x50
[ 2.893758] [<ffffffff810284f2>] free_init_pages+0x132/0x1c0
[ 2.893759] [<ffffffff81028c83>] mark_rodata_ro+0x143/0x150
[ 2.893761] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.893762] [<ffffffff81ab8d2c>] kernel_init+0x158/0x163
[ 2.893763] [<ffffffff8157d6d4>] kernel_thread_helper+0x4/0x10
[ 2.893765] [<ffffffff81ab8bd4>] ? start_kernel+0x3c3/0x3c3
[ 2.893766] [<ffffffff8157d6d0>] ? gs_change+0xb/0xb
[ 2.893769] BUG: Bad page state in process swapper pfn:01888
[ 2.893888] page:ffffea0000055dc0 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.894068] page flags: 0x100000000000000()
[ 2.894166] Pid: 1, comm: swapper Tainted: G B 3.0.0-rc2-patser+ #39
[ 2.894166] Call Trace:
[ 2.894168] [<ffffffff810f689b>] ? dump_page+0x9b/0xd0
[ 2.894169] [<ffffffff810f6999>] bad_page+0xc9/0x120
[ 2.894171] [<ffffffff810f6aab>] free_pages_prepare+0xbb/0x130
[ 2.894172] [<ffffffff810f8379>] free_hot_cold_page+0x49/0x440
[ 2.894174] [<ffffffff810f8ddd>] __free_pages+0x2d/0x40
[ 2.894175] [<ffffffff810f8e33>] free_pages+0x43/0x50
[ 2.894177] [<ffffffff810284f2>] free_init_pages+0x132/0x1c0
[ 2.894178] [<ffffffff81028c83>] mark_rodata_ro+0x143/0x150
[ 2.894179] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.894181] [<ffffffff81ab8d2c>] kernel_init+0x158/0x163
[ 2.894182] [<ffffffff8157d6d4>] kernel_thread_helper+0x4/0x10
[ 2.894184] [<ffffffff81ab8bd4>] ? start_kernel+0x3c3/0x3c3
[ 2.894185] [<ffffffff8157d6d0>] ? gs_change+0xb/0xb
[ 2.894187] BUG: Bad page state in process swapper pfn:0188c
[ 2.894306] page:ffffea0000055ea0 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.894486] page flags: 0x100000000000000()
[ 2.894583] Pid: 1, comm: swapper Tainted: G B 3.0.0-rc2-patser+ #39
[ 2.894584] Call Trace:
[ 2.894586] [<ffffffff810f689b>] ? dump_page+0x9b/0xd0
[ 2.894587] [<ffffffff810f6999>] bad_page+0xc9/0x120
[ 2.894588] [<ffffffff810f6aab>] free_pages_prepare+0xbb/0x130
[ 2.894590] [<ffffffff810f8379>] free_hot_cold_page+0x49/0x440
[ 2.894592] [<ffffffff810f8ddd>] __free_pages+0x2d/0x40
[ 2.894593] [<ffffffff810f8e33>] free_pages+0x43/0x50
[ 2.894594] [<ffffffff810284f2>] free_init_pages+0x132/0x1c0
[ 2.894596] [<ffffffff81028c83>] mark_rodata_ro+0x143/0x150
[ 2.894597] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.894599] [<ffffffff81ab8d2c>] kernel_init+0x158/0x163
[ 2.894600] [<ffffffff8157d6d4>] kernel_thread_helper+0x4/0x10
[ 2.894602] [<ffffffff81ab8bd4>] ? start_kernel+0x3c3/0x3c3
[ 2.894603] [<ffffffff8157d6d0>] ? gs_change+0xb/0xb
[ 2.894605] BUG: Bad page state in process swapper pfn:01890
[ 2.894728] page:ffffea0000055f80 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.894903] page flags: 0x100000000000000()
[ 2.895001] Pid: 1, comm: swapper Tainted: G B 3.0.0-rc2-patser+ #39
[ 2.895002] Call Trace:
[ 2.895003] [<ffffffff810f689b>] ? dump_page+0x9b/0xd0
[ 2.895005] [<ffffffff810f6999>] bad_page+0xc9/0x120
[ 2.895006] [<ffffffff810f6aab>] free_pages_prepare+0xbb/0x130
[ 2.895008] [<ffffffff810f8379>] free_hot_cold_page+0x49/0x440
[ 2.895009] [<ffffffff810f8ddd>] __free_pages+0x2d/0x40
[ 2.895011] [<ffffffff810f8e33>] free_pages+0x43/0x50
[ 2.895012] [<ffffffff810284f2>] free_init_pages+0x132/0x1c0
[ 2.895013] [<ffffffff81028c83>] mark_rodata_ro+0x143/0x150
[ 2.895015] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.895016] [<ffffffff81ab8d2c>] kernel_init+0x158/0x163
[ 2.895018] [<ffffffff8157d6d4>] kernel_thread_helper+0x4/0x10
[ 2.895019] [<ffffffff81ab8bd4>] ? start_kernel+0x3c3/0x3c3
[ 2.895020] [<ffffffff8157d6d0>] ? gs_change+0xb/0xb
[ 2.895022] BUG: Bad page state in process swapper pfn:01892
[ 2.895140] page:ffffea0000055ff0 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.895320] page flags: 0x100000000000000()
[ 2.895418] Pid: 1, comm: swapper Tainted: G B 3.0.0-rc2-patser+ #39
[ 2.895419] Call Trace:
[ 2.895420] [<ffffffff810f689b>] ? dump_page+0x9b/0xd0
[ 2.895422] [<ffffffff810f6999>] bad_page+0xc9/0x120
[ 2.895423] [<ffffffff810f6aab>] free_pages_prepare+0xbb/0x130
[ 2.895425] [<ffffffff810f8379>] free_hot_cold_page+0x49/0x440
[ 2.895426] [<ffffffff810f8ddd>] __free_pages+0x2d/0x40
[ 2.895428] [<ffffffff810f8e33>] free_pages+0x43/0x50
[ 2.895429] [<ffffffff810284f2>] free_init_pages+0x132/0x1c0
[ 2.895430] [<ffffffff81028c83>] mark_rodata_ro+0x143/0x150
[ 2.895432] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.895433] [<ffffffff81ab8d2c>] kernel_init+0x158/0x163
[ 2.895435] [<ffffffff8157d6d4>] kernel_thread_helper+0x4/0x10
[ 2.895436] [<ffffffff81ab8bd4>] ? start_kernel+0x3c3/0x3c3
[ 2.895437] [<ffffffff8157d6d0>] ? gs_change+0xb/0xb
[ 2.895444] BUG: Bad page state in process swapper pfn:018a1
[ 2.895562] page:ffffea0000056338 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.895745] page flags: 0x100000000000000()
[ 2.895840] Pid: 1, comm: swapper Tainted: G B 3.0.0-rc2-patser+ #39
[ 2.895841] Call Trace:
[ 2.895842] [<ffffffff810f689b>] ? dump_page+0x9b/0xd0
[ 2.895844] [<ffffffff810f6999>] bad_page+0xc9/0x120
[ 2.895845] [<ffffffff810f6aab>] free_pages_prepare+0xbb/0x130
[ 2.895847] [<ffffffff810f8379>] free_hot_cold_page+0x49/0x440
[ 2.895848] [<ffffffff810f8ddd>] __free_pages+0x2d/0x40
[ 2.895850] [<ffffffff810f8e33>] free_pages+0x43/0x50
[ 2.895851] [<ffffffff810284f2>] free_init_pages+0x132/0x1c0
[ 2.895853] [<ffffffff81028c83>] mark_rodata_ro+0x143/0x150
[ 2.895854] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.895856] [<ffffffff81ab8d2c>] kernel_init+0x158/0x163
[ 2.895857] [<ffffffff8157d6d4>] kernel_thread_helper+0x4/0x10
[ 2.895859] [<ffffffff81ab8bd4>] ? start_kernel+0x3c3/0x3c3
[ 2.895860] [<ffffffff8157d6d0>] ? gs_change+0xb/0xb
[ 2.895861] BUG: Bad page state in process swapper pfn:018a2
[ 2.895979] page:ffffea0000056370 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.896159] page flags: 0x100000000000000()
[ 2.896257] Pid: 1, comm: swapper Tainted: G B 3.0.0-rc2-patser+ #39
[ 2.896258] Call Trace:
[ 2.896259] [<ffffffff810f689b>] ? dump_page+0x9b/0xd0
[ 2.896261] [<ffffffff810f6999>] bad_page+0xc9/0x120
[ 2.896262] [<ffffffff810f6aab>] free_pages_prepare+0xbb/0x130
[ 2.896264] [<ffffffff810f8379>] free_hot_cold_page+0x49/0x440
[ 2.896265] [<ffffffff810f8ddd>] __free_pages+0x2d/0x40
[ 2.896267] [<ffffffff810f8e33>] free_pages+0x43/0x50
[ 2.896268] [<ffffffff810284f2>] free_init_pages+0x132/0x1c0
[ 2.896270] [<ffffffff81028c83>] mark_rodata_ro+0x143/0x150
[ 2.896271] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.896272] [<ffffffff81ab8d2c>] kernel_init+0x158/0x163
[ 2.896274] [<ffffffff8157d6d4>] kernel_thread_helper+0x4/0x10
[ 2.896275] [<ffffffff81ab8bd4>] ? start_kernel+0x3c3/0x3c3
[ 2.896277] [<ffffffff8157d6d0>] ? gs_change+0xb/0xb
[ 2.896278] BUG: Bad page state in process swapper pfn:018a4
[ 2.896397] page:ffffea00000563e0 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.896577] page flags: 0x100000000000000()
[ 2.896675] Pid: 1, comm: swapper Tainted: G B 3.0.0-rc2-patser+ #39
[ 2.896675] Call Trace:
[ 2.896677] [<ffffffff810f689b>] ? dump_page+0x9b/0xd0
[ 2.896678] [<ffffffff810f6999>] bad_page+0xc9/0x120
[ 2.896680] [<ffffffff810f6aab>] free_pages_prepare+0xbb/0x130
[ 2.896681] [<ffffffff810f8379>] free_hot_cold_page+0x49/0x440
[ 2.896683] [<ffffffff810f8ddd>] __free_pages+0x2d/0x40
[ 2.896684] [<ffffffff810f8e33>] free_pages+0x43/0x50
[ 2.896686] [<ffffffff810284f2>] free_init_pages+0x132/0x1c0
[ 2.896687] [<ffffffff81028c83>] mark_rodata_ro+0x143/0x150
[ 2.896688] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.896690] [<ffffffff81ab8d2c>] kernel_init+0x158/0x163
[ 2.896691] [<ffffffff8157d6d4>] kernel_thread_helper+0x4/0x10
[ 2.896693] [<ffffffff81ab8bd4>] ? start_kernel+0x3c3/0x3c3
[ 2.896694] [<ffffffff8157d6d0>] ? gs_change+0xb/0xb
[ 2.896698] BUG: Bad page state in process swapper pfn:018ae
[ 2.896817] page:ffffea0000056610 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.896997] page flags: 0x100000000000000()
[ 2.897095] Pid: 1, comm: swapper Tainted: G B 3.0.0-rc2-patser+ #39
[ 2.897095] Call Trace:
[ 2.897097] [<ffffffff810f689b>] ? dump_page+0x9b/0xd0
[ 2.897098] [<ffffffff810f6999>] bad_page+0xc9/0x120
[ 2.897100] [<ffffffff810f6aab>] free_pages_prepare+0xbb/0x130
[ 2.897101] [<ffffffff810f8379>] free_hot_cold_page+0x49/0x440
[ 2.897103] [<ffffffff810f8ddd>] __free_pages+0x2d/0x40
[ 2.897104] [<ffffffff810f8e33>] free_pages+0x43/0x50
[ 2.897106] [<ffffffff810284f2>] free_init_pages+0x132/0x1c0
[ 2.897107] [<ffffffff81028c83>] mark_rodata_ro+0x143/0x150
[ 2.897109] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.897110] [<ffffffff81ab8d2c>] kernel_init+0x158/0x163
[ 2.897111] [<ffffffff8157d6d4>] kernel_thread_helper+0x4/0x10
[ 2.897113] [<ffffffff81ab8bd4>] ? start_kernel+0x3c3/0x3c3
[ 2.897114] [<ffffffff8157d6d0>] ? gs_change+0xb/0xb
[ 2.897116] BUG: Bad page state in process swapper pfn:018b0
[ 2.897234] page:ffffea0000056680 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.897414] page flags: 0x100000000000000()
[ 2.897512] Pid: 1, comm: swapper Tainted: G B 3.0.0-rc2-patser+ #39
[ 2.897513] Call Trace:
[ 2.897514] [<ffffffff810f689b>] ? dump_page+0x9b/0xd0
[ 2.897516] [<ffffffff810f6999>] bad_page+0xc9/0x120
[ 2.897517] [<ffffffff810f6aab>] free_pages_prepare+0xbb/0x130
[ 2.897519] [<ffffffff810f8379>] free_hot_cold_page+0x49/0x440
[ 2.897520] [<ffffffff810f8ddd>] __free_pages+0x2d/0x40
[ 2.897522] [<ffffffff810f8e33>] free_pages+0x43/0x50
[ 2.897523] [<ffffffff810284f2>] free_init_pages+0x132/0x1c0
[ 2.897524] [<ffffffff81028c83>] mark_rodata_ro+0x143/0x150
[ 2.897526] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.897527] [<ffffffff81ab8d2c>] kernel_init+0x158/0x163
[ 2.897529] [<ffffffff8157d6d4>] kernel_thread_helper+0x4/0x10
[ 2.897530] [<ffffffff81ab8bd4>] ? start_kernel+0x3c3/0x3c3
[ 2.897531] [<ffffffff8157d6d0>] ? gs_change+0xb/0xb
[ 2.897534] BUG: Bad page state in process swapper pfn:018b4
[ 2.897652] page:ffffea0000056760 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.897835] page flags: 0x100000000000000()
[ 2.897930] Pid: 1, comm: swapper Tainted: G B 3.0.0-rc2-patser+ #39
[ 2.897931] Call Trace:
[ 2.897932] [<ffffffff810f689b>] ? dump_page+0x9b/0xd0
[ 2.897934] [<ffffffff810f6999>] bad_page+0xc9/0x120
[ 2.897935] [<ffffffff810f6aab>] free_pages_prepare+0xbb/0x130
[ 2.897937] [<ffffffff810f8379>] free_hot_cold_page+0x49/0x440
[ 2.897938] [<ffffffff810f8ddd>] __free_pages+0x2d/0x40
[ 2.897940] [<ffffffff810f8e33>] free_pages+0x43/0x50
[ 2.897941] [<ffffffff810284f2>] free_init_pages+0x132/0x1c0
[ 2.897942] [<ffffffff81028c83>] mark_rodata_ro+0x143/0x150
[ 2.897944] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.897945] [<ffffffff81ab8d2c>] kernel_init+0x158/0x163
[ 2.897947] [<ffffffff8157d6d4>] kernel_thread_helper+0x4/0x10
[ 2.897948] [<ffffffff81ab8bd4>] ? start_kernel+0x3c3/0x3c3
[ 2.897950] [<ffffffff8157d6d0>] ? gs_change+0xb/0xb
[ 2.897951] BUG: Bad page state in process swapper pfn:018b7
[ 2.898070] page:ffffea0000056808 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.898250] page flags: 0x100000000000000()
[ 2.903882] Pid: 1, comm: swapper Tainted: G B 3.0.0-rc2-patser+ #39
[ 2.903883] Call Trace:
[ 2.903885] [<ffffffff810f689b>] ? dump_page+0x9b/0xd0
[ 2.903886] [<ffffffff810f6999>] bad_page+0xc9/0x120
[ 2.903888] [<ffffffff810f6aab>] free_pages_prepare+0xbb/0x130
[ 2.903889] [<ffffffff810f8379>] free_hot_cold_page+0x49/0x440
[ 2.903891] [<ffffffff810f8ddd>] __free_pages+0x2d/0x40
[ 2.903892] [<ffffffff810f8e33>] free_pages+0x43/0x50
[ 2.903894] [<ffffffff810284f2>] free_init_pages+0x132/0x1c0
[ 2.903895] [<ffffffff81028c83>] mark_rodata_ro+0x143/0x150
[ 2.903896] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.903898] [<ffffffff81ab8d2c>] kernel_init+0x158/0x163
[ 2.903899] [<ffffffff8157d6d4>] kernel_thread_helper+0x4/0x10
[ 2.903901] [<ffffffff81ab8bd4>] ? start_kernel+0x3c3/0x3c3
[ 2.903902] [<ffffffff8157d6d0>] ? gs_change+0xb/0xb
[ 2.903903] BUG: Bad page state in process swapper pfn:018b8
[ 2.909529] page:ffffea0000056840 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.915230] page flags: 0x100000000000000()
[ 2.920868] Pid: 1, comm: swapper Tainted: G B 3.0.0-rc2-patser+ #39
[ 2.920869] Call Trace:
[ 2.920871] [<ffffffff810f689b>] ? dump_page+0x9b/0xd0
[ 2.920872] [<ffffffff810f6999>] bad_page+0xc9/0x120
[ 2.920874] [<ffffffff810f6aab>] free_pages_prepare+0xbb/0x130
[ 2.920875] [<ffffffff810f8379>] free_hot_cold_page+0x49/0x440
[ 2.920877] [<ffffffff810f8ddd>] __free_pages+0x2d/0x40
[ 2.920878] [<ffffffff810f8e33>] free_pages+0x43/0x50
[ 2.920880] [<ffffffff810284f2>] free_init_pages+0x132/0x1c0
[ 2.920881] [<ffffffff81028c83>] mark_rodata_ro+0x143/0x150
[ 2.920882] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.920884] [<ffffffff81ab8d2c>] kernel_init+0x158/0x163
[ 2.920885] [<ffffffff8157d6d4>] kernel_thread_helper+0x4/0x10
[ 2.920887] [<ffffffff81ab8bd4>] ? start_kernel+0x3c3/0x3c3
[ 2.920888] [<ffffffff8157d6d0>] ? gs_change+0xb/0xb
[ 2.920895] BUG: Bad page state in process swapper pfn:018cc
[ 2.926527] page:ffffea0000056ca0 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.932239] page flags: 0x100000000000000()
[ 2.937895] Pid: 1, comm: swapper Tainted: G B 3.0.0-rc2-patser+ #39
[ 2.937896] Call Trace:
[ 2.937897] [<ffffffff810f689b>] ? dump_page+0x9b/0xd0
[ 2.937898] [<ffffffff810f6999>] bad_page+0xc9/0x120
[ 2.937900] [<ffffffff810f6aab>] free_pages_prepare+0xbb/0x130
[ 2.937902] [<ffffffff810f8379>] free_hot_cold_page+0x49/0x440
[ 2.937903] [<ffffffff810f8ddd>] __free_pages+0x2d/0x40
[ 2.937905] [<ffffffff810f8e33>] free_pages+0x43/0x50
[ 2.937906] [<ffffffff810284f2>] free_init_pages+0x132/0x1c0
[ 2.937907] [<ffffffff81028c83>] mark_rodata_ro+0x143/0x150
[ 2.937909] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.937910] [<ffffffff81ab8d2c>] kernel_init+0x158/0x163
[ 2.937912] [<ffffffff8157d6d4>] kernel_thread_helper+0x4/0x10
[ 2.937913] [<ffffffff81ab8bd4>] ? start_kernel+0x3c3/0x3c3
[ 2.937914] [<ffffffff8157d6d0>] ? gs_change+0xb/0xb
[ 2.937916] BUG: Bad page state in process swapper pfn:018d0
[ 2.943561] page:ffffea0000056d80 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.949287] page flags: 0x100000000000000()
[ 2.954949] Pid: 1, comm: swapper Tainted: G B 3.0.0-rc2-patser+ #39
[ 2.954950] Call Trace:
[ 2.954951] [<ffffffff810f689b>] ? dump_page+0x9b/0xd0
[ 2.954953] [<ffffffff810f6999>] bad_page+0xc9/0x120
[ 2.954954] [<ffffffff810f6aab>] free_pages_prepare+0xbb/0x130
[ 2.954956] [<ffffffff810f8379>] free_hot_cold_page+0x49/0x440
[ 2.954958] [<ffffffff810f8ddd>] __free_pages+0x2d/0x40
[ 2.954959] [<ffffffff810f8e33>] free_pages+0x43/0x50
[ 2.954960] [<ffffffff810284f2>] free_init_pages+0x132/0x1c0
[ 2.954962] [<ffffffff81028c83>] mark_rodata_ro+0x143/0x150
[ 2.954963] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.954965] [<ffffffff81ab8d2c>] kernel_init+0x158/0x163
[ 2.954966] [<ffffffff8157d6d4>] kernel_thread_helper+0x4/0x10
[ 2.954968] [<ffffffff81ab8bd4>] ? start_kernel+0x3c3/0x3c3
[ 2.954969] [<ffffffff8157d6d0>] ? gs_change+0xb/0xb
[ 2.954975] BUG: Bad page state in process swapper pfn:018e0
[ 2.960627] page:ffffea0000057100 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.966362] page flags: 0x100000000000000()
[ 2.972031] Pid: 1, comm: swapper Tainted: G B 3.0.0-rc2-patser+ #39
[ 2.972032] Call Trace:
[ 2.972033] [<ffffffff810f689b>] ? dump_page+0x9b/0xd0
[ 2.972035] [<ffffffff810f6999>] bad_page+0xc9/0x120
[ 2.972036] [<ffffffff810f6aab>] free_pages_prepare+0xbb/0x130
[ 2.972038] [<ffffffff810f8379>] free_hot_cold_page+0x49/0x440
[ 2.972039] [<ffffffff810f8ddd>] __free_pages+0x2d/0x40
[ 2.972041] [<ffffffff810f8e33>] free_pages+0x43/0x50
[ 2.972042] [<ffffffff810284f2>] free_init_pages+0x132/0x1c0
[ 2.972044] [<ffffffff81028c83>] mark_rodata_ro+0x143/0x150
[ 2.972046] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.972047] [<ffffffff81ab8d2c>] kernel_init+0x158/0x163
[ 2.972048] [<ffffffff8157d6d4>] kernel_thread_helper+0x4/0x10
[ 2.972050] [<ffffffff81ab8bd4>] ? start_kernel+0x3c3/0x3c3
[ 2.972051] [<ffffffff8157d6d0>] ? gs_change+0xb/0xb
[ 2.972061] BUG: Bad page state in process swapper pfn:01900
[ 2.977722] page:ffffea0000057800 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.983463] page flags: 0x100000000000000()
[ 2.989146] Pid: 1, comm: swapper Tainted: G B 3.0.0-rc2-patser+ #39
[ 2.989146] Call Trace:
[ 2.989148] [<ffffffff810f689b>] ? dump_page+0x9b/0xd0
[ 2.989149] [<ffffffff810f6999>] bad_page+0xc9/0x120
[ 2.989151] [<ffffffff810f6aab>] free_pages_prepare+0xbb/0x130
[ 2.989152] [<ffffffff810f8379>] free_hot_cold_page+0x49/0x440
[ 2.989154] [<ffffffff810f8ddd>] __free_pages+0x2d/0x40
[ 2.989155] [<ffffffff810f8e33>] free_pages+0x43/0x50
[ 2.989157] [<ffffffff810284f2>] free_init_pages+0x132/0x1c0
[ 2.989158] [<ffffffff81028c83>] mark_rodata_ro+0x143/0x150
[ 2.989160] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.989161] [<ffffffff81ab8d2c>] kernel_init+0x158/0x163
[ 2.989162] [<ffffffff8157d6d4>] kernel_thread_helper+0x4/0x10
[ 2.989164] [<ffffffff81ab8bd4>] ? start_kernel+0x3c3/0x3c3
[ 2.989165] [<ffffffff8157d6d0>] ? gs_change+0xb/0xb
[ 2.989170] BUG: Bad page state in process swapper pfn:01910
[ 2.994842] page:ffffea0000057b80 count:0 mapcount:-127 mapping: (null) index:0x0
[ 2.994843] page flags: 0x100000000000000()
[ 2.994844] Pid: 1, comm: swapper Tainted: G B 3.0.0-rc2-patser+ #39
[ 2.994845] Call Trace:
[ 2.994846] [<ffffffff810f689b>] ? dump_page+0x9b/0xd0
[ 2.994847] [<ffffffff810f6999>] bad_page+0xc9/0x120
[ 2.994849] [<ffffffff810f6aab>] free_pages_prepare+0xbb/0x130
[ 2.994850] [<ffffffff810f8379>] free_hot_cold_page+0x49/0x440
[ 2.994852] [<ffffffff810f8ddd>] __free_pages+0x2d/0x40
[ 2.994853] [<ffffffff810f8e33>] free_pages+0x43/0x50
[ 2.994854] [<ffffffff810284f2>] free_init_pages+0x132/0x1c0
[ 2.994855] [<ffffffff81028c83>] mark_rodata_ro+0x143/0x150
[ 2.994856] [<ffffffff810001d8>] init_post+0x18/0xd0
[ 2.994858] [<ffffffff81ab8d2c>] kernel_init+0x158/0x163
[ 2.994859] [<ffffffff8157d6d4>] kernel_thread_helper+0x4/0x10
[ 2.994860] [<ffffffff81ab8bd4>] ? start_kernel+0x3c3/0x3c3
[ 2.994861] [<ffffffff8157d6d0>] ? gs_change+0xb/0xb
Ok, that's odd. These are 0x01800000-0x01900000, which should lie inside
the kernel data range (01580279-01aa4cff : Kernel data). We should be
skipping that region. How are we touching that reange at all? Can you
add a printk to reserve_boot_services to see what it actually ends up
reserving?
--
Matthew Garrett | [email protected]
I'll try what happens with my patch + moving insert_resource for kernel before efi_init.
Op 13-06-11 20:33, Matthew Garrett schreef:
> Ok, that's odd. These are 0x01800000-0x01900000, which should lie inside
> the kernel data range (01580279-01aa4cff : Kernel data). We should be
> skipping that region. How are we touching that reange at all? Can you
> add a printk to reserve_boot_services to see what it actually ends up
> reserving?
~Maarten
Op 13-06-11 20:33, Matthew Garrett schreef:
> Ok, that's odd. These are 0x01800000-0x01900000, which should lie inside
> the kernel data range (01580279-01aa4cff : Kernel data). We should be
> skipping that region. How are we touching that reange at all? Can you
> add a printk to reserve_boot_services to see what it actually ends up
> reserving?
>
Oh, it's the init code... I have a patch that fixes this, and skips the entire kernel region.
Will submit a cleaned up version soon, after testing it some more
~Maarten
Hey,
Op 13-06-11 20:33, Matthew Garrett schreef:
> Ok, that's odd. These are 0x01800000-0x01900000, which should lie inside
> the kernel data range (01580279-01aa4cff : Kernel data). We should be
> skipping that region. How are we touching that reange at all? Can you
> add a printk to reserve_boot_services to see what it actually ends up
> reserving?
Finally success!
Didn't notice it before, but my efi memmap has:
[ 0.000000] EFI: mem00: type=3, attr=0xf, range=[0x0000000000000000-0x0000000000008000) (0MB)
Later on this range gets reserved for bios:
[ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
[ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
So I've added a check for e820.
Also with some digging into the swapper warning, it appears to be because
some memory was allocated in the _init part of the kernel, which you didn't check for.
this probably caused the warnings I had. Now I made sure to cover
the entire kernel from _text to _end, which should cover the entire kernel.
~Maarten
On Tue, Jun 14, 2011 at 04:50:33PM +0200, Maarten Lankhorst wrote:
> Didn't notice it before, but my efi memmap has:
> [ 0.000000] EFI: mem00: type=3, attr=0xf, range=[0x0000000000000000-0x0000000000008000) (0MB)
>
> Later on this range gets reserved for bios:
>
> [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
> [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
>
> So I've added a check for e820.
I've got a patch that ignores any EFI mapping at page 0, since it's
pretty much guaranteed to provide bogosity. Checking e820 might well be
a cleaner approach, though.
> Also with some digging into the swapper warning, it appears to be because
> some memory was allocated in the _init part of the kernel, which you didn't check for.
> this probably caused the warnings I had. Now I made sure to cover
> the entire kernel from _text to _end, which should cover the entire kernel.
Ah, ok, that makes sense. If you post that I'll take a look.
--
Matthew Garrett | [email protected]
On 06/10/2011 05:19 PM, Yinghai Lu wrote:
> On 06/10/2011 05:00 PM, H. Peter Anvin wrote:
>> On 06/10/2011 04:55 PM, Yinghai Lu wrote:
>>>>
>>>> No, it should be, because the boot loader can control the decompress
>>>> position to avoid the problems.
>>>
>>> bootloader could find out decompressed kernel size?
>>>
>>
>> Yes, it's the init_size field in the header.
>
> good, with relocatable_kernel, kernel_alignment, and init_size in header, bootloader could find right position for kernel.
>
Yes, and that's the very reason for it... which unfortunately means
kernel address randomization is hard(er) because it means the kernel
wants to second-guess the boot loader again.
-hpa