gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jim]

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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Andi Kleen]

Jim <jim876@xs4all.nl> 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

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Andreas Schwab]

Andi Kleen <andi@firstfloor.org> writes:

> Jim <jim876@xs4all.nl> 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, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Andi Kleen]

Andreas Schwab <schwab@linux-m68k.org> 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
-- 
ak@linux.intel.com -- Speaking for myself only.

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Richard Guenther]

On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen <andi@firstfloor.org> wrote:
> Andreas Schwab <schwab@linux-m68k.org> 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
> --
> ak@linux.intel.com -- Speaking for myself only.
>

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Andi Kleen]

Richard Guenther <richard.guenther@gmail.com> writes:

> On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen <andi@firstfloor.org> wrote:
>> Andreas Schwab <schwab@linux-m68k.org> 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

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Richard Guenther]

On Mon, Nov 8, 2010 at 12:20 PM, Andi Kleen <andi@firstfloor.org> wrote:
> Richard Guenther <richard.guenther@gmail.com> writes:
>
>> On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen <andi@firstfloor.org> wrote:
>>> Andreas Schwab <schwab@linux-m68k.org> 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
>
> --
> ak@linux.intel.com -- Speaking for myself only.
>

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Paul Koning]

On Nov 8, 2010, at 6:20 AM, Richard Guenther wrote:

> On Mon, Nov 8, 2010 at 12:20 PM, Andi Kleen <andi@firstfloor.org> wrote:
>> Richard Guenther <richard.guenther@gmail.com> writes:
>> 
>>> On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen <andi@firstfloor.org> wrote:
>>>> Andreas Schwab <schwab@linux-m68k.org> 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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jakub Jelinek]

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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Michael Matz]

Hi,

On Mon, 8 Nov 2010, Andi Kleen wrote:

> Richard Guenther <richard.guenther@gmail.com> writes:
> 
> > On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen <andi@firstfloor.org> wrote:
> >> Andreas Schwab <schwab@linux-m68k.org> 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.

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Dave Korn]

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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Michael Matz]

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.

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Andi Kleen]

> 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 <ak@linux.intel.com>

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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Andreas Schwab]

Andi Kleen <andi@firstfloor.org> 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, schwab@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jim]

[-- Attachment #1: Type: text/plain, Size: 470 bytes --]

On 11/09/2010 02:57 PM, Andreas Schwab wrote:
> Andi Kleen <andi@firstfloor.org> 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



[-- Attachment #2: PATCH.i8k.c --]
[-- Type: text/plain, Size: 565 bytes --]

--- i8k.c.ORIG	2010-08-02 17:20:46.000000000 +0200
+++ i8k.c	2010-11-09 17:31:29.000000000 +0100
@@ -141,7 +141,7 @@
 		"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
@@ -166,7 +166,7 @@
 	    "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

[PATCH] i8k: Tell gcc that *regs gets clobbered

[Jim Bos]

[-- Attachment #1: Type: text/plain, Size: 464 bytes --]



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 <andi@firstfloor.org> and Andreas Schwab
<schwab@linux-m68k.org> for providing the fix.

Signed-off-by: Jim Bos <jim876@xs4all.nl>


[-- Attachment #2: PATCH.i8k.c --]
[-- Type: text/plain, Size: 624 bytes --]

--- linux-2.6.36/drivers/char/i8k.c.ORIG	2010-08-02 17:20:46.000000000 +0200
+++ linux-2.6.36/drivers/char/i8k.c	2010-11-13 11:35:11.000000000 +0100
@@ -141,7 +141,7 @@
 		"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
@@ -166,7 +166,8 @@
 	    "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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[James Cloos]

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 <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Linus Torvalds]

On Sun, Nov 14, 2010 at 4:52 PM, James Cloos <cloos@jhcloos.com> 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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jakub Jelinek]

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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Andi Kleen]

> 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 <ak@linux.intel.com>

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;


-- 
ak@linux.intel.com -- Speaking for myself only.

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jakub Jelinek]

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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jakub Jelinek]

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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Andi Kleen]

> 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
-- 
ak@linux.intel.com -- Speaking for myself only.

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jakub Jelinek]

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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Andi Kleen]

> 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

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jim Bos]

[-- Attachment #1: Type: text/plain, Size: 677 bytes --]

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


[-- Attachment #2: outp.txt --]
[-- Type: text/plain, Size: 3690 bytes --]

rm -f include/config/kernel.release
echo "2.6.36$(/bin/sh /usr/src/linux-2.6.36/scripts/setlocalversion /usr/src/linux-2.6.36)" > include/config/kernel.release
set -e; : '  CHK     include/linux/version.h'; mkdir -p include/linux/; 	(echo \#define LINUX_VERSION_CODE 132644; echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';) < /usr/src/linux-2.6.36/Makefile > include/linux/version.h.tmp; if [ -r include/linux/version.h ] && cmp -s include/linux/version.h include/linux/version.h.tmp; then rm -f include/linux/version.h.tmp; else : '  UPD     include/linux/version.h'; mv -f include/linux/version.h.tmp include/linux/version.h; fi
set -e; : '  CHK     include/generated/utsrelease.h'; mkdir -p include/generated/; 	if [ `echo -n "2.6.36" | wc -c ` -gt 64 ]; then echo '"2.6.36" exceeds 64 characters' >&2; exit 1; fi; (echo \#define UTS_RELEASE \"2.6.36\";) < include/config/kernel.release > include/generated/utsrelease.h.tmp; if [ -r include/generated/utsrelease.h ] && cmp -s include/generated/utsrelease.h include/generated/utsrelease.h.tmp; then rm -f include/generated/utsrelease.h.tmp; else : '  UPD     include/generated/utsrelease.h'; mv -f include/generated/utsrelease.h.tmp include/generated/utsrelease.h; fi
mkdir -p .tmp_versions 
make -f scripts/Makefile.build obj=scripts/basic
rm -f .tmp_quiet_recordmcount
make -f scripts/Makefile.build obj=.
mkdir -p kernel/
mkdir -p arch/x86/kernel/
make -f scripts/Makefile.build obj=. missing-syscalls
  /bin/sh scripts/checksyscalls.sh gcc -Wp,-MD,./.missing-syscalls.d  -nostdinc -isystem /usr/lib/gcc/i486-slackware-linux/4.5.1/include -I/usr/src/linux-2.6.36/arch/x86/include -Iinclude  -include include/generated/autoconf.h -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 -Os -m32 -msoft-float -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium3 -mtune=generic -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=1024 -fno-stack-protector -fomit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack    -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(missing_syscalls)"  -D"KBUILD_MODNAME=KBUILD_STR(missing_syscalls)" 
make -f scripts/Makefile.build obj=scripts
make -f scripts/Makefile.build obj=scripts/mod
make -f scripts/Makefile.build obj=drivers/char drivers/char/i8k.o
  gcc -Wp,-MD,drivers/char/.i8k.o.d  -nostdinc -isystem /usr/lib/gcc/i486-slackware-linux/4.5.1/include -I/usr/src/linux-2.6.36/arch/x86/include -Iinclude  -include include/generated/autoconf.h -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 -Os -m32 -msoft-float -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium3 -mtune=generic -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=1024 -fno-stack-protector -fomit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack  -DMODULE  -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(i8k)"  -D"KBUILD_MODNAME=KBUILD_STR(i8k)"  -c -o drivers/char/i8k.o drivers/char/i8k.c

[-- Attachment #3: i8k.i.gz --]
[-- Type: application/gzip, Size: 79922 bytes --]

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jakub Jelinek]

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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jim Bos]

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 majordomo@vger.kernel.org
> 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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jakub Jelinek]

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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jim Bos]

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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Linus Torvalds]

[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]

On Mon, Nov 15, 2010 at 3:16 AM, Jakub Jelinek <jakub@redhat.com> 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

[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 1019 bytes --]

 drivers/char/i8k.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
index f0863be..101011e 100644
--- a/drivers/char/i8k.c
+++ b/drivers/char/i8k.c
@@ -114,7 +114,7 @@ static inline const char *i8k_get_dmi_data(int field)
 /*
  * Call the System Management Mode BIOS. Code provided by Jonathan Buzzard.
  */
-static int i8k_smm(struct smm_regs *regs)
+static noinline int i8k_smm(struct smm_regs *regs)
 {
 	int rc;
 	int eax = regs->eax;
@@ -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), "+m" (*regs)
+		:"=a"(rc)
 		:    "a"(regs)
 		:    "%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");
 #else
@@ -168,7 +168,7 @@ static int i8k_smm(struct smm_regs *regs)
 	    "lahf\n\t"
 	    "shrl $8,%%eax\n\t"
 	    "andl $1,%%eax\n"
-	    :"=a"(rc), "+m" (*regs)
+	    :"=a"(rc)
 	    :    "a"(regs)
 	    :    "%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");
 #endif

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jim Bos]

On 11/15/2010 05:04 PM, Linus Torvalds wrote:
> On Mon, Nov 15, 2010 at 3:16 AM, Jakub Jelinek <jakub@redhat.com> 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.

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Linus Torvalds]

On Mon, Nov 15, 2010 at 9:40 AM, Jim Bos <jim876@xs4all.nl> 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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jim Bos]

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

On 11/15/2010 07:08 PM, Linus Torvalds wrote:
> On Mon, Nov 15, 2010 at 9:40 AM, Jim Bos <jim876@xs4all.nl> 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



[-- Attachment #2: i8k.s-2.6.36 --]
[-- Type: text/plain, Size: 22373 bytes --]

	.file	"i8k.c"
# GNU C (GCC) version 4.5.1 (i486-slackware-linux)
#	compiled by GNU C version 4.5.1, GMP version 5.0.1, MPFR version 2.4.2-p3, MPC version 0.8.2
# GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=96817
# options passed:  -nostdinc -I/usr/src/linux-2.6.36/arch/x86/include
# -Iinclude -D__KERNEL__ -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1
# -DCONFIG_AS_CFI_SECTIONS=1 -DMODULE -DKBUILD_STR(s)=#s
# -DKBUILD_BASENAME=KBUILD_STR(i8k) -DKBUILD_MODNAME=KBUILD_STR(i8k)
# -isystem /usr/lib/gcc/i486-slackware-linux/4.5.1/include -include
# include/generated/autoconf.h -MD drivers/char/.i8k.s.d drivers/char/i8k.c
# -m32 -msoft-float -mregparm=3 -mpreferred-stack-boundary=2 -march=i686
# -mtune=pentium3 -mtune=generic -mno-sse -mno-mmx -mno-sse2 -mno-3dnow
# -auxbase-strip drivers/char/i8k.s -Os -Wall -Wundef -Wstrict-prototypes
# -Wno-trigraphs -Werror-implicit-function-declaration -Wno-format-security
# -Wno-sign-compare -Wframe-larger-than=1024 -Wdeclaration-after-statement
# -Wno-pointer-sign -fno-strict-aliasing -fno-common
# -fno-delete-null-pointer-checks -freg-struct-return -ffreestanding
# -fno-asynchronous-unwind-tables -fno-stack-protector -fomit-frame-pointer
# -fno-strict-overflow -fconserve-stack -fverbose-asm
# options enabled:  -falign-loops -fargument-alias -fauto-inc-dec
# -fbranch-count-reg -fcaller-saves -fcprop-registers -fcrossjumping
# -fcse-follow-jumps -fdefer-pop -fdwarf2-cfi-asm -fearly-inlining
# -feliminate-unused-debug-types -fexpensive-optimizations
# -fforward-propagate -ffunction-cse -fgcse -fgcse-lm
# -fguess-branch-probability -fident -fif-conversion -fif-conversion2
# -findirect-inlining -finline -finline-functions
# -finline-functions-called-once -finline-small-functions -fipa-cp
# -fipa-pure-const -fipa-reference -fipa-sra -fira-share-save-slots
# -fira-share-spill-slots -fivopts -fkeep-static-consts
# -fleading-underscore -fmath-errno -fmerge-constants -fmerge-debug-strings
# -fmove-loop-invariants -fomit-frame-pointer -foptimize-register-move
# -foptimize-sibling-calls -fpeephole -fpeephole2 -freg-struct-return
# -fregmove -freorder-blocks -freorder-functions -frerun-cse-after-loop
# -fsched-critical-path-heuristic -fsched-dep-count-heuristic
# -fsched-group-heuristic -fsched-interblock -fsched-last-insn-heuristic
# -fsched-rank-heuristic -fsched-spec -fsched-spec-insn-heuristic
# -fsched-stalled-insns-dep -fschedule-insns2 -fshow-column -fsigned-zeros
# -fsplit-ivs-in-unroller -fsplit-wide-types -fthread-jumps
# -ftoplevel-reorder -ftrapping-math -ftree-builtin-call-dce -ftree-ccp
# -ftree-ch -ftree-copy-prop -ftree-copyrename -ftree-cselim -ftree-dce
# -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre
# -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize
# -ftree-parallelize-loops= -ftree-phiprop -ftree-pre -ftree-pta
# -ftree-reassoc -ftree-scev-cprop -ftree-sink -ftree-slp-vectorize
# -ftree-sra -ftree-switch-conversion -ftree-ter -ftree-vect-loop-version
# -ftree-vrp -funit-at-a-time -fvect-cost-model -fverbose-asm
# -fzero-initialized-in-bss -m32 -m96bit-long-double -malign-stringops
# -mfused-madd -mglibc -mieee-fp -mno-fancy-math-387 -mno-red-zone
# -mno-sse4 -mpush-args -msahf -mtls-direct-seg-refs

# Compiler executable checksum: 7ba2dc3c015559b9d16b297ee7f8d354

	.text
	.type	i8k_smm, @function
i8k_smm:
	pushl	%ebp	#
	movl	%eax, %ebp	# regs, regs
	pushl	%edi	#
	pushl	%esi	#
	pushl	%ebx	#
	subl	$8, %esp	#,
	movl	(%eax), %eax	# regs_2(D)->eax,
	movl	%eax, 4(%esp)	#, %sfp
	movl	%ebp, %eax	# regs,
#APP
# 148 "drivers/char/i8k.c" 1
	pushl %eax
	movl 0(%eax),%edx
	push %edx
	movl 4(%eax),%ebx
	movl 8(%eax),%ecx
	movl 12(%eax),%edx
	movl 16(%eax),%esi
	movl 20(%eax),%edi
	popl %eax
	out %al,$0xb2
	out %al,$0x84
	xchgl %eax,(%esp)
	movl %ebx,4(%eax)
	movl %ecx,8(%eax)
	movl %edx,12(%eax)
	movl %esi,16(%eax)
	movl %edi,20(%eax)
	popl %edx
	movl %edx,0(%eax)
	lahf
	shrl $8,%eax
	andl $1,%eax

# 0 "" 2
#NO_APP
	testl	%eax, %eax	#
	movl	$-22, %edx	#, D.15130
	movl	%eax, (%esp)	#, %sfp
	jne	.L2	#,
	movl	0(%ebp), %ecx	# regs_2(D)->eax, D.15123
	cmpw	$-1, %cx	#, D.15123
	je	.L2	#,
	cmpl	4(%esp), %ecx	# %sfp, D.15123
	cmovne	%eax, %edx	#,, D.15130
.L2:
	addl	$8, %esp	#,
	movl	%edx, %eax	# D.15130,
	popl	%ebx	#
	popl	%esi	#
	popl	%edi	#
	popl	%ebp	#
	ret
	.size	i8k_smm, .-i8k_smm
	.type	i8k_get_bios_version, @function
i8k_get_bios_version:
	pushl	%edi	#
	xorl	%eax, %eax	# tmp61
	subl	$24, %esp	#,
	movl	$6, %ecx	#, tmp62
	movl	%esp, %edi	#, tmp60
	rep stosl
	movl	%esp, %eax	#, tmp63
	movl	$166, (%esp)	#, regs.eax
	call	i8k_smm	#
	movl	$166, %edx	#, tmp65
	testl	%eax, %eax	# D.15225
	cmove	%edx, %eax	# D.15225,, tmp65, D.15225
	addl	$24, %esp	#,
	popl	%edi	#
	ret
	.size	i8k_get_bios_version, .-i8k_get_bios_version
	.type	i8k_get_fn_status, @function
i8k_get_fn_status:
	pushl	%edi	#
	movl	$6, %ecx	#, tmp63
	pushl	%ebx	#
	xorl	%ebx, %ebx	# tmp62
	subl	$24, %esp	#,
	movl	%ebx, %eax	# tmp62,
	movl	%esp, %edi	#, tmp61
	rep stosl
	movl	%esp, %eax	#, tmp64
	movl	$37, (%esp)	#, regs.eax
	call	i8k_smm	#
	testl	%eax, %eax	# rc
	cmovg	%ebx, %eax	# rc,, tmp62, tmp65
	addl	$24, %esp	#,
	popl	%ebx	#
	popl	%edi	#
	ret
	.size	i8k_get_fn_status, .-i8k_get_fn_status
	.type	i8k_get_power_status, @function
i8k_get_power_status:
	pushl	%edi	#
	movl	$6, %ecx	#, tmp63
	pushl	%ebx	#
	xorl	%ebx, %ebx	# tmp62
	subl	$24, %esp	#,
	movl	%ebx, %eax	# tmp62,
	movl	%esp, %edi	#, tmp61
	rep stosl
	movl	%esp, %eax	#, tmp64
	movl	$105, (%esp)	#, regs.eax
	call	i8k_smm	#
	testl	%eax, %eax	# rc
	cmovg	%ebx, %eax	# rc,, tmp62, tmp65
	addl	$24, %esp	#,
	popl	%ebx	#
	popl	%edi	#
	ret
	.size	i8k_get_power_status, .-i8k_get_power_status
	.type	i8k_get_fan_status, @function
i8k_get_fan_status:
	pushl	%edi	#
	movl	%eax, %edx	# fan, fan
	subl	$24, %esp	#,
	xorl	%eax, %eax	# tmp64
	movl	%esp, %edi	#, tmp63
	movl	$6, %ecx	#, tmp65
	rep stosl
	andl	$255, %edx	#, tmp66
	movl	%esp, %eax	#, tmp67
	movl	%edx, 4(%esp)	# tmp66, regs.ebx
	movl	$163, (%esp)	#, regs.eax
	call	i8k_smm	#
	movl	$163, %edx	#, tmp69
	testl	%eax, %eax	# D.15134
	cmove	%edx, %eax	# D.15134,, tmp69, D.15134
	addl	$24, %esp	#,
	popl	%edi	#
	ret
	.size	i8k_get_fan_status, .-i8k_get_fan_status
	.type	i8k_get_fan_speed, @function
i8k_get_fan_speed:
	pushl	%edi	#
	movl	%eax, %edx	# fan, fan
	subl	$24, %esp	#,
	xorl	%eax, %eax	# tmp67
	movl	%esp, %edi	#, tmp66
	movl	$6, %ecx	#, tmp68
	rep stosl
	andl	$255, %edx	#, tmp69
	movl	%esp, %eax	#, tmp70
	movl	$675, (%esp)	#, regs.eax
	movl	%edx, 4(%esp)	# tmp69, regs.ebx
	call	i8k_smm	#
	testl	%eax, %eax	# D.15145
	jne	.L13	#,
	imull	$675, fan_mult, %eax	#, fan_mult, D.15145
.L13:
	addl	$24, %esp	#,
	popl	%edi	#
	ret
	.size	i8k_get_fan_speed, .-i8k_get_fan_speed
	.type	i8k_get_dell_signature, @function
i8k_get_dell_signature:
	pushl	%edi	#
	movl	%eax, %edx	# req_fn, req_fn
	subl	$24, %esp	#,
	xorl	%eax, %eax	# tmp63
	movl	%esp, %edi	#, tmp62
	movl	$6, %ecx	#, tmp64
	rep stosl
	movl	%esp, %eax	#, tmp65
	movl	%edx, (%esp)	# req_fn, regs.eax
	call	i8k_smm	#
	movl	$-1, %edx	#, tmp67
	testl	%eax, %eax	# rc
	cmovns	%edx, %eax	# rc,, tmp67, rc
	addl	$24, %esp	#,
	popl	%edi	#
	ret
	.size	i8k_get_dell_signature, .-i8k_get_dell_signature
	.type	i8k_open_fs, @function
i8k_open_fs:
	movl	%edx, %eax	# file, file
	xorl	%ecx, %ecx	#
	movl	$i8k_proc_show, %edx	#,
	jmp	single_open	#
	.size	i8k_open_fs, .-i8k_open_fs
	.section	.rodata.str1.1,"aMS",@progbits,1
.LC0:
	.string	"?"
	.text
	.type	i8k_get_dmi_data, @function
i8k_get_dmi_data:
	call	dmi_get_system_info	#
	testl	%eax, %eax	# dmi_data
	je	.L20	#,
	cmpb	$0, (%eax)	#,* dmi_data
	movl	$.LC0, %edx	#, tmp63
	cmove	%edx, %eax	# dmi_data,, tmp63, dmi_data
	ret
.L20:
	movl	$.LC0, %eax	#, dmi_data
	ret
	.size	i8k_get_dmi_data, .-i8k_get_dmi_data
	.type	i8k_get_temp.clone.1, @function
i8k_get_temp.clone.1:
	pushl	%edi	#
	xorl	%eax, %eax	# tmp61
	subl	$24, %esp	#,
	movl	$6, %ecx	#, tmp62
	movl	%esp, %edi	#, tmp60
	rep stosl
	movl	%esp, %eax	#, tmp63
	movl	$4259, (%esp)	#, regs.eax
	call	i8k_smm	#
	testl	%eax, %eax	# rc
	js	.L22	#,
	movl	prev.12857, %eax	# prev, rc
	movl	$127, prev.12857	#, prev
.L22:
	addl	$24, %esp	#,
	popl	%edi	#
	ret
	.size	i8k_get_temp.clone.1, .-i8k_get_temp.clone.1
	.section	.rodata.str1.1
.LC1:
	.string	"1.0"
.LC2:
	.string	"%s %s %s %d %d %d %d %d %d %d\n"
	.text
	.type	i8k_proc_show, @function
i8k_proc_show:
	pushl	%ebp	#
	pushl	%edi	#
	pushl	%esi	#
	pushl	%ebx	#
	orl	$-1, %ebx	#, ac_power
	subl	$16, %esp	#,
	movl	%eax, 12(%esp)	# seq, %sfp
	call	i8k_get_temp.clone.1	#
	movl	%eax, (%esp)	#, %sfp
	movl	$1, %eax	#,
	call	i8k_get_fan_status	#
	movl	%eax, 4(%esp)	#, %sfp
	xorl	%eax, %eax	#
	call	i8k_get_fan_status	#
	movl	%eax, %esi	#, right_fan
	movl	$1, %eax	#,
	call	i8k_get_fan_speed	#
	movl	%eax, %edi	#, left_speed
	xorl	%eax, %eax	#
	call	i8k_get_fan_speed	#
	movl	%eax, %ebp	#, right_speed
	call	i8k_get_fn_status	#
	cmpl	$0, power_status	#, power_status
	movl	%eax, 8(%esp)	#, %sfp
	je	.L24	#,
	call	i8k_get_power_status	#
	movl	%eax, %ebx	#, ac_power
.L24:
	movl	$7, %eax	#,
	call	i8k_get_dmi_data	#
	pushl	8(%esp)	# %sfp
	pushl	%ebx	# ac_power
	pushl	%ebp	# right_speed
	pushl	%edi	# left_speed
	pushl	%esi	# right_fan
	pushl	24(%esp)	# %sfp
	pushl	24(%esp)	# %sfp
	pushl	%eax	# D.15110
	pushl	$bios_version	#
	pushl	$.LC1	#
	pushl	$.LC2	#
	pushl	56(%esp)	# %sfp
	call	seq_printf	#
	addl	$64, %esp	#,
	popl	%ebx	#
	popl	%esi	#
	popl	%edi	#
	popl	%ebp	#
	ret
	.size	i8k_proc_show, .-i8k_proc_show
	.type	copy_from_user.clone.2, @function
copy_from_user.clone.2:
	movl	$4, %ecx	#,
	jmp	_copy_from_user	#
	.size	copy_from_user.clone.2, .-copy_from_user.clone.2
	.type	i8k_ioctl, @function
i8k_ioctl:
	pushl	%ebp	#
	movl	%edx, %ebp	# cmd, cmd
	pushl	%edi	#
	pushl	%esi	#
	movl	$-22, %esi	#, ret
	pushl	%ebx	#
	movl	%ecx, %ebx	# arg, arg
	subl	$48, %esp	#,
	testl	%ecx, %ecx	# arg
	movl	$0, 44(%esp)	#, val
	je	.L28	#,
	cmpl	$-2147194493, %edx	#, cmd
	je	.L32	#,
	ja	.L37	#,
	cmpl	$-2147194495, %edx	#, cmd
	je	.L30	#,
	ja	.L31	#,
	cmpl	$-2147194496, %edx	#, cmd
	jne	.L46	#,
	jmp	.L58	#
.L37:
	cmpl	$-1073452667, %edx	#, cmd
	je	.L34	#,
	ja	.L38	#,
	cmpl	$-2147194492, %edx	#, cmd
	jne	.L46	#,
	jmp	.L59	#
.L38:
	cmpl	$-1073452666, %edx	#, cmd
	je	.L35	#,
	cmpl	$-1073452665, %edx	#, cmd
	jne	.L46	#,
	jmp	.L60	#
.L58:
	call	i8k_get_bios_version	#
	jmp	.L41	#
.L30:
	leal	24(%esp), %esi	#, tmp93
	xorl	%eax, %eax	# tmp95
	movl	%esi, %edi	# tmp93, tmp94
	movl	$4, %ecx	#, tmp96
	rep stosl
	movb	$7, %al	#,
	call	i8k_get_dmi_data	#
	movl	$16, %ecx	#,
	movl	%eax, %edx	# D.15468,
	movl	%esi, %eax	# tmp93,
	call	strlcpy	#
	jmp	.L39	#
.L32:
	call	i8k_get_fn_status	#
	jmp	.L41	#
.L31:
	call	i8k_get_power_status	#
	jmp	.L41	#
.L59:
	call	i8k_get_temp.clone.1	#
	jmp	.L41	#
.L34:
	leal	44(%esp), %eax	#, tmp98
	movl	%ecx, %edx	# arg,
	call	copy_from_user.clone.2	#
	movl	$-14, %esi	#, ret
	testl	%eax, %eax	# D.15473
	jne	.L28	#,
	movl	44(%esp), %eax	# val,
	call	i8k_get_fan_speed	#
	jmp	.L41	#
.L35:
	leal	44(%esp), %eax	#, tmp100
	movl	%ecx, %edx	# arg,
	call	copy_from_user.clone.2	#
	movl	$-14, %esi	#, ret
	testl	%eax, %eax	# D.15476
	jne	.L28	#,
	movl	44(%esp), %eax	# val,
	jmp	.L57	#
.L60:
	cmpl	$0, restricted	#, restricted
	je	.L40	#,
	movl	$21, %eax	#,
	orl	$-1, %esi	#, ret
	call	capable	#
	testl	%eax, %eax	# D.15479
	je	.L28	#,
.L40:
	leal	44(%esp), %eax	#, tmp102
	movl	%ebx, %edx	# arg,
	call	copy_from_user.clone.2	#
	movl	$-14, %esi	#, ret
	testl	%eax, %eax	# D.15480
	jne	.L28	#,
	leal	4(%ebx), %edx	#, tmp103
	leal	40(%esp), %eax	#, tmp104
	call	copy_from_user.clone.2	#
	testl	%eax, %eax	# D.15482
	jne	.L28	#,
	movl	%esp, %edi	#, tmp105
	movl	$6, %ecx	#, tmp107
	movl	40(%esp), %edx	# speed, speed.19
	rep stosl
	movl	44(%esp), %esi	# val, val.15
	movl	$419, (%esp)	#, regs.eax
	cmpl	$2, %edx	#, speed.19
	movb	$2, %cl	#,
	cmovle	%edx, %ecx	# speed.19,, speed
	movl	%esi, %edx	# val.15, tmp112
	testl	%ecx, %ecx	# speed
	cmovns	%ecx, %eax	# speed,, tmp113
	andl	$255, %edx	#, tmp112
	sall	$8, %eax	#, tmp113
	orl	%edx, %eax	# tmp112, tmp113
	movl	%eax, 4(%esp)	# tmp113, regs.ebx
	movl	%esp, %eax	#, tmp114
	call	i8k_smm	#
	testl	%eax, %eax	# D.15487
	jne	.L41	#,
	movl	%esi, %eax	# val.15,
.L57:
	call	i8k_get_fan_status	#
.L41:
	movl	%eax, 44(%esp)	# D.15487, val
.L39:
	movl	44(%esp), %esi	# val, ret
	testl	%esi, %esi	# ret
	js	.L28	#,
	cmpl	$-2147194496, %ebp	#, cmd
	je	.L55	#,
	cmpl	$-2147194495, %ebp	#, cmd
	jne	.L55	#,
	leal	24(%esp), %edx	#, tmp116
	movl	$16, %ecx	#,
.L56:
	movl	%ebx, %eax	# arg,
	call	copy_to_user	#
	cmpl	$1, %eax	#, D.15485
	sbbl	%esi, %esi	# ret
	notl	%esi	# ret
	andl	$-14, %esi	#, ret
	jmp	.L28	#
.L55:
	leal	44(%esp), %edx	#, tmp117
	movl	$4, %ecx	#,
	jmp	.L56	#
.L46:
	movl	$-22, %esi	#, ret
.L28:
	addl	$48, %esp	#,
	movl	%esi, %eax	# ret,
	popl	%ebx	#
	popl	%esi	#
	popl	%edi	#
	popl	%ebp	#
	ret
	.size	i8k_ioctl, .-i8k_ioctl
	.section	.rodata.str1.1
.LC3:
	.string	"<6>i8k: not running on a supported Dell system.\n"
.LC4:
	.string	"<6>i8k: vendor=%s, model=%s, version=%s\n"
.LC5:
	.string	"<3>i8k: unable to get SMM Dell signature\n"
.LC6:
	.string	"<4>i8k: unable to get SMM BIOS version\n"
.LC7:
	.string	"<4>i8k: BIOS version mismatch: %s != %s\n"
.LC8:
	.string	"1.14 21/02/2005"
.LC9:
	.string	"<6>Dell laptop SMM driver v%s Massimo Dal Zotto (dz@debian.org)\n"
.LC10:
	.string	"i8k"
	.section	.init.text,"ax",@progbits
	.type	i8k_init, @function
i8k_init:
	pushl	%esi	#
	movl	$i8k_dmi_table, %eax	#,
	pushl	%ebx	#
	subl	$4, %esp	#,
	call	dmi_check_system	#
	testl	%eax, %eax	# D.15529
	jne	.L62	#,
	cmpl	$0, ignore_dmi	#, ignore_dmi
	jne	.L63	#,
	cmpl	$0, force	#, force
	movl	$-19, %eax	#, D.15099
	je	.L64	#,
.L63:
	pushl	$.LC3	#
	call	printk	#
	movl	$2, %eax	#,
	call	i8k_get_dmi_data	#
	movl	%eax, %esi	#, D.15525
	movl	$5, %eax	#,
	call	i8k_get_dmi_data	#
	movl	%eax, %ebx	#, D.15524
	movl	$4, %eax	#,
	call	i8k_get_dmi_data	#
	pushl	%esi	# D.15525
	pushl	%ebx	# D.15524
	pushl	%eax	# D.15523
	pushl	$.LC4	#
	call	printk	#
	addl	$20, %esp	#,
.L62:
	movl	$2, %eax	#,
	call	i8k_get_dmi_data	#
	movl	$4, %ecx	#,
	movl	%eax, %edx	# D.15522,
	movl	$bios_version, %eax	#,
	call	strlcpy	#
	movl	$65187, %eax	#,
	call	i8k_get_dell_signature	#
	testl	%eax, %eax	# D.15521
	je	.L65	#,
	movl	$65443, %eax	#,
	call	i8k_get_dell_signature	#
	testl	%eax, %eax	# D.15520
	je	.L65	#,
	pushl	$.LC5	#
	call	printk	#
	movl	$-19, %eax	#, D.15099
	cmpl	$0, force	#, force
	popl	%edx	#
	je	.L64	#,
.L65:
	call	i8k_get_bios_version	#
	testl	%eax, %eax	# version
	jg	.L66	#,
	pushl	$.LC6	#
	call	printk	#
	popl	%eax	#
	jmp	.L67	#
.L66:
	movl	%eax, %edx	# version, tmp79
	sarl	$16, %edx	#, tmp79
	movb	%dl, (%esp)	# tmp79, buff
	movl	%eax, %edx	# version, tmp80
	sarl	$8, %edx	#, tmp80
	movb	%al, 2(%esp)	# version, buff
	movl	$2, %eax	#,
	movb	%dl, 1(%esp)	# tmp80, buff
	movb	$0, 3(%esp)	#, buff
	call	dmi_get_system_info	#
	testl	%eax, %eax	# D.15514
	jne	.L68	#,
	movl	%esp, %edx	#, tmp81
	movl	$4, %ecx	#,
	movl	$bios_version, %eax	#,
	call	strlcpy	#
.L68:
	movl	$4, %ecx	#,
	movl	$bios_version, %edx	#,
	movl	%esp, %eax	#,
	movl	%esp, %ebx	#, tmp82
	call	strncmp	#
	testl	%eax, %eax	# D.15513
	je	.L67	#,
	pushl	$bios_version	#
	pushl	%ebx	# tmp82
	pushl	$.LC7	#
	call	printk	#
	addl	$12, %esp	#,
	jmp	.L67	#
.L74:
	pushl	$.LC8	#
	pushl	$.LC9	#
	call	printk	#
	xorl	%eax, %eax	# D.15099
	popl	%ebx	#
	popl	%esi	#
.L64:
	addl	$4, %esp	#,
	popl	%ebx	#
	popl	%esi	#
	ret
.L67:
	pushl	$0	#
	xorl	%ecx, %ecx	#
	xorl	%edx, %edx	#
	movl	$.LC10, %eax	#,
	pushl	$i8k_fops	#
	call	proc_create_data	#
	movl	%eax, %edx	#, proc_i8k
	testl	%edx, %edx	# proc_i8k
	popl	%eax	#
	movl	$-2, %eax	#, D.15099
	popl	%ecx	#
	je	.L64	#,
	jmp	.L74	#
	.size	i8k_init, .-i8k_init
	.section	.exit.text,"ax",@progbits
	.type	i8k_exit, @function
i8k_exit:
	xorl	%edx, %edx	#
	movl	$.LC10, %eax	#,
	jmp	remove_proc_entry	#
	.size	i8k_exit, .-i8k_exit
	.section	.modinfo,"a",@progbits
	.align 4
	.type	__mod_fan_mult83, @object
	.size	__mod_fan_mult83, 48
__mod_fan_mult83:
	.string	"parm=fan_mult:Factor to multiply fan speed with"
	.align 4
	.type	__mod_fan_multtype82, @object
	.size	__mod_fan_multtype82, 22
__mod_fan_multtype82:
	.string	"parmtype=fan_mult:int"
	.section	__param,"a",@progbits
	.align 4
	.type	__param_fan_mult, @object
	.size	__param_fan_mult, 16
__param_fan_mult:
# name:
	.long	__param_str_fan_mult
# ops:
	.long	param_ops_int
# perm:
	.value	0
# flags:
	.value	0
# <anonymous>:
# arg:
	.long	fan_mult
	.section	.modinfo
	.align 4
	.type	__mod_power_status79, @object
	.size	__mod_power_status79, 51
__mod_power_status79:
	.string	"parm=power_status:Report power status in /proc/i8k"
	.align 4
	.type	__mod_power_statustype78, @object
	.size	__mod_power_statustype78, 27
__mod_power_statustype78:
	.string	"parmtype=power_status:bool"
	.section	__param
	.align 4
	.type	__param_power_status, @object
	.size	__param_power_status, 16
__param_power_status:
# name:
	.long	__param_str_power_status
# ops:
	.long	param_ops_bool
# perm:
	.value	384
# flags:
	.value	0
# <anonymous>:
# arg:
	.long	power_status
	.section	.modinfo
	.align 4
	.type	__mod_restricted75, @object
	.size	__mod_restricted75, 62
__mod_restricted75:
	.string	"parm=restricted:Allow fan control if SYS_ADMIN capability set"
	.align 4
	.type	__mod_restrictedtype74, @object
	.size	__mod_restrictedtype74, 25
__mod_restrictedtype74:
	.string	"parmtype=restricted:bool"
	.section	__param
	.align 4
	.type	__param_restricted, @object
	.size	__param_restricted, 16
__param_restricted:
# name:
	.long	__param_str_restricted
# ops:
	.long	param_ops_bool
# perm:
	.value	0
# flags:
	.value	0
# <anonymous>:
# arg:
	.long	restricted
	.section	.modinfo
	.align 4
	.type	__mod_ignore_dmi71, @object
	.size	__mod_ignore_dmi71, 74
__mod_ignore_dmi71:
	.string	"parm=ignore_dmi:Continue probing hardware even if DMI data does not match"
	.align 4
	.type	__mod_ignore_dmitype70, @object
	.size	__mod_ignore_dmitype70, 25
__mod_ignore_dmitype70:
	.string	"parmtype=ignore_dmi:bool"
	.section	__param
	.align 4
	.type	__param_ignore_dmi, @object
	.size	__param_ignore_dmi, 16
__param_ignore_dmi:
# name:
	.long	__param_str_ignore_dmi
# ops:
	.long	param_ops_bool
# perm:
	.value	0
# flags:
	.value	0
# <anonymous>:
# arg:
	.long	ignore_dmi
	.section	.modinfo
	.align 4
	.type	__mod_force67, @object
	.size	__mod_force67, 63
__mod_force67:
	.string	"parm=force:Force loading without checking for supported models"
	.align 4
	.type	__mod_forcetype66, @object
	.size	__mod_forcetype66, 20
__mod_forcetype66:
	.string	"parmtype=force:bool"
	.section	__param
	.align 4
	.type	__param_force, @object
	.size	__param_force, 16
__param_force:
# name:
	.long	__param_str_force
# ops:
	.long	param_ops_bool
# perm:
	.value	0
# flags:
	.value	0
# <anonymous>:
# arg:
	.long	force
	.section	.modinfo
	.align 4
	.type	__mod_license63, @object
	.size	__mod_license63, 12
__mod_license63:
	.string	"license=GPL"
	.align 4
	.type	__mod_description62, @object
	.size	__mod_description62, 58
__mod_description62:
	.string	"description=Driver for accessing SMM BIOS on Dell laptops"
	.align 4
	.type	__mod_author61, @object
	.size	__mod_author61, 41
__mod_author61:
	.string	"author=Massimo Dal Zotto (dz@debian.org)"
	.data
	.align 4
	.type	fan_mult, @object
	.size	fan_mult, 4
fan_mult:
	.long	30
	.local	power_status
	.comm	power_status,4,4
	.local	restricted
	.comm	restricted,4,4
	.local	ignore_dmi
	.comm	ignore_dmi,4,4
	.local	force
	.comm	force,4,4
	.section	.rodata
	.align 4
	.type	i8k_fops, @object
	.size	i8k_fops, 100
i8k_fops:
# owner:
	.long	__this_module
# llseek:
	.long	seq_lseek
# read:
	.long	seq_read
# unlocked_ioctl:
	.zero	20
	.long	i8k_ioctl
# open:
	.zero	8
	.long	i8k_open_fs
# release:
	.zero	4
	.long	single_release
	.zero	44
	.local	bios_version
	.comm	bios_version,4,4
	.local	prev.12857
	.comm	prev.12857,4,4
	.section	.rodata.str1.1
.LC11:
	.string	"Dell Inspiron"
.LC12:
	.string	"Dell Latitude"
.LC13:
	.string	"Dell Inspiron 2"
.LC14:
	.string	"Dell Latitude 2"
.LC15:
	.string	"Dell Inspiron 3"
.LC16:
	.string	"Dell Precision"
.LC17:
	.string	"Dell Vostro"
	.section	.init.data,"aw",@progbits
	.align 4
	.type	i8k_dmi_table, @object
	.size	i8k_dmi_table, 2988
i8k_dmi_table:
# ident:
	.zero	4
	.long	.LC11
# matches:
# slot:
	.byte	4
# substr:
	.string	"Dell Computer"
	.zero	65
# slot:
	.byte	5
# substr:
	.string	"Inspiron"
	.zero	70
	.zero	160
	.zero	4
# ident:
	.zero	4
	.long	.LC12
# matches:
# slot:
	.byte	4
# substr:
	.string	"Dell Computer"
	.zero	65
# slot:
	.byte	5
# substr:
	.string	"Latitude"
	.zero	70
	.zero	160
	.zero	4
# ident:
	.zero	4
	.long	.LC13
# matches:
# slot:
	.byte	4
# substr:
	.string	"Dell Inc."
	.zero	69
# slot:
	.byte	5
# substr:
	.string	"Inspiron"
	.zero	70
	.zero	160
	.zero	4
# ident:
	.zero	4
	.long	.LC14
# matches:
# slot:
	.byte	4
# substr:
	.string	"Dell Inc."
	.zero	69
# slot:
	.byte	5
# substr:
	.string	"Latitude"
	.zero	70
	.zero	160
	.zero	4
# ident:
	.zero	4
	.long	.LC15
# matches:
# slot:
	.byte	4
# substr:
	.string	"Dell Inc."
	.zero	69
# slot:
	.byte	5
# substr:
	.string	"MM061"
	.zero	73
	.zero	160
	.zero	4
# ident:
	.zero	4
	.long	.LC15
# matches:
# slot:
	.byte	4
# substr:
	.string	"Dell Inc."
	.zero	69
# slot:
	.byte	5
# substr:
	.string	"MP061"
	.zero	73
	.zero	160
	.zero	4
# ident:
	.zero	4
	.long	.LC16
# matches:
# slot:
	.byte	4
# substr:
	.string	"Dell Inc."
	.zero	69
# slot:
	.byte	5
# substr:
	.string	"Precision"
	.zero	69
	.zero	160
	.zero	4
# ident:
	.zero	4
	.long	.LC17
# matches:
# slot:
	.byte	4
# substr:
	.string	"Dell Inc."
	.zero	69
# slot:
	.byte	5
# substr:
	.string	"Vostro"
	.zero	72
	.zero	160
	.zero	4
	.zero	332
	.section	.rodata
	.align 4
	.type	__param_str_fan_mult, @object
	.size	__param_str_fan_mult, 9
__param_str_fan_mult:
	.string	"fan_mult"
	.align 4
	.type	__param_str_power_status, @object
	.size	__param_str_power_status, 13
__param_str_power_status:
	.string	"power_status"
	.align 4
	.type	__param_str_restricted, @object
	.size	__param_str_restricted, 11
__param_str_restricted:
	.string	"restricted"
	.align 4
	.type	__param_str_ignore_dmi, @object
	.size	__param_str_ignore_dmi, 11
__param_str_ignore_dmi:
	.string	"ignore_dmi"
	.align 4
	.type	__param_str_force, @object
	.size	__param_str_force, 6
__param_str_force:
	.string	"force"
.globl init_module
	.set	init_module,i8k_init
.globl cleanup_module
	.set	cleanup_module,i8k_exit
	.ident	"GCC: (GNU) 4.5.1"
	.section	.note.GNU-stack,"",@progbits

[-- Attachment #3: i8k.s-2.6.36+patch --]
[-- Type: text/plain, Size: 22948 bytes --]

	.file	"i8k.c"
# GNU C (GCC) version 4.5.1 (i486-slackware-linux)
#	compiled by GNU C version 4.5.1, GMP version 5.0.1, MPFR version 2.4.2-p3, MPC version 0.8.2
# GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=96817
# options passed:  -nostdinc -I/usr/src/linux-2.6.36/arch/x86/include
# -Iinclude -D__KERNEL__ -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1
# -DCONFIG_AS_CFI_SECTIONS=1 -DMODULE -DKBUILD_STR(s)=#s
# -DKBUILD_BASENAME=KBUILD_STR(i8k) -DKBUILD_MODNAME=KBUILD_STR(i8k)
# -isystem /usr/lib/gcc/i486-slackware-linux/4.5.1/include -include
# include/generated/autoconf.h -MD drivers/char/.i8k.s.d drivers/char/i8k.c
# -m32 -msoft-float -mregparm=3 -mpreferred-stack-boundary=2 -march=i686
# -mtune=pentium3 -mtune=generic -mno-sse -mno-mmx -mno-sse2 -mno-3dnow
# -auxbase-strip drivers/char/i8k.s -Os -Wall -Wundef -Wstrict-prototypes
# -Wno-trigraphs -Werror-implicit-function-declaration -Wno-format-security
# -Wno-sign-compare -Wframe-larger-than=1024 -Wdeclaration-after-statement
# -Wno-pointer-sign -fno-strict-aliasing -fno-common
# -fno-delete-null-pointer-checks -freg-struct-return -ffreestanding
# -fno-asynchronous-unwind-tables -fno-stack-protector -fomit-frame-pointer
# -fno-strict-overflow -fconserve-stack -fverbose-asm
# options enabled:  -falign-loops -fargument-alias -fauto-inc-dec
# -fbranch-count-reg -fcaller-saves -fcprop-registers -fcrossjumping
# -fcse-follow-jumps -fdefer-pop -fdwarf2-cfi-asm -fearly-inlining
# -feliminate-unused-debug-types -fexpensive-optimizations
# -fforward-propagate -ffunction-cse -fgcse -fgcse-lm
# -fguess-branch-probability -fident -fif-conversion -fif-conversion2
# -findirect-inlining -finline -finline-functions
# -finline-functions-called-once -finline-small-functions -fipa-cp
# -fipa-pure-const -fipa-reference -fipa-sra -fira-share-save-slots
# -fira-share-spill-slots -fivopts -fkeep-static-consts
# -fleading-underscore -fmath-errno -fmerge-constants -fmerge-debug-strings
# -fmove-loop-invariants -fomit-frame-pointer -foptimize-register-move
# -foptimize-sibling-calls -fpeephole -fpeephole2 -freg-struct-return
# -fregmove -freorder-blocks -freorder-functions -frerun-cse-after-loop
# -fsched-critical-path-heuristic -fsched-dep-count-heuristic
# -fsched-group-heuristic -fsched-interblock -fsched-last-insn-heuristic
# -fsched-rank-heuristic -fsched-spec -fsched-spec-insn-heuristic
# -fsched-stalled-insns-dep -fschedule-insns2 -fshow-column -fsigned-zeros
# -fsplit-ivs-in-unroller -fsplit-wide-types -fthread-jumps
# -ftoplevel-reorder -ftrapping-math -ftree-builtin-call-dce -ftree-ccp
# -ftree-ch -ftree-copy-prop -ftree-copyrename -ftree-cselim -ftree-dce
# -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre
# -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize
# -ftree-parallelize-loops= -ftree-phiprop -ftree-pre -ftree-pta
# -ftree-reassoc -ftree-scev-cprop -ftree-sink -ftree-slp-vectorize
# -ftree-sra -ftree-switch-conversion -ftree-ter -ftree-vect-loop-version
# -ftree-vrp -funit-at-a-time -fvect-cost-model -fverbose-asm
# -fzero-initialized-in-bss -m32 -m96bit-long-double -malign-stringops
# -mfused-madd -mglibc -mieee-fp -mno-fancy-math-387 -mno-red-zone
# -mno-sse4 -mpush-args -msahf -mtls-direct-seg-refs

# Compiler executable checksum: 7ba2dc3c015559b9d16b297ee7f8d354

	.text
	.type	i8k_smm, @function
i8k_smm:
	pushl	%ebp	#
	movl	%eax, %ebp	# regs, regs
	pushl	%edi	#
	pushl	%esi	#
	pushl	%ebx	#
	subl	$8, %esp	#,
	movl	(%eax), %eax	# regs_2(D)->eax,
	movl	%eax, 4(%esp)	#, %sfp
	movl	%ebp, %eax	# regs,
#APP
# 148 "drivers/char/i8k.c" 1
	pushl %eax
	movl 0(%eax),%edx
	push %edx
	movl 4(%eax),%ebx
	movl 8(%eax),%ecx
	movl 12(%eax),%edx
	movl 16(%eax),%esi
	movl 20(%eax),%edi
	popl %eax
	out %al,$0xb2
	out %al,$0x84
	xchgl %eax,(%esp)
	movl %ebx,4(%eax)
	movl %ecx,8(%eax)
	movl %edx,12(%eax)
	movl %esi,16(%eax)
	movl %edi,20(%eax)
	popl %edx
	movl %edx,0(%eax)
	lahf
	shrl $8,%eax
	andl $1,%eax

# 0 "" 2
#NO_APP
	testl	%eax, %eax	#
	movl	$-22, %edx	#, D.15130
	movl	%eax, (%esp)	#, %sfp
	jne	.L2	#,
	movl	0(%ebp), %ecx	# regs_2(D)->eax, D.15123
	cmpw	$-1, %cx	#, D.15123
	je	.L2	#,
	cmpl	4(%esp), %ecx	# %sfp, D.15123
	cmovne	%eax, %edx	#,, D.15130
.L2:
	addl	$8, %esp	#,
	movl	%edx, %eax	# D.15130,
	popl	%ebx	#
	popl	%esi	#
	popl	%edi	#
	popl	%ebp	#
	ret
	.size	i8k_smm, .-i8k_smm
	.type	i8k_get_bios_version, @function
i8k_get_bios_version:
	pushl	%edi	#
	xorl	%eax, %eax	# tmp62
	subl	$24, %esp	#,
	movl	$6, %ecx	#, tmp63
	movl	%esp, %edi	#, tmp61
	rep stosl
	movl	%esp, %eax	#, tmp64
	movl	$166, (%esp)	#, regs.eax
	call	i8k_smm	#
	testl	%eax, %eax	# D.15225
	cmove	(%esp), %eax	# regs.eax,, D.15225
	addl	$24, %esp	#,
	popl	%edi	#
	ret
	.size	i8k_get_bios_version, .-i8k_get_bios_version
	.type	i8k_get_fn_status, @function
i8k_get_fn_status:
	pushl	%edi	#
	xorl	%eax, %eax	# tmp65
	subl	$24, %esp	#,
	movl	$6, %ecx	#, tmp66
	movl	%esp, %edi	#, tmp64
	rep stosl
	movl	%esp, %eax	#, tmp67
	movl	$37, (%esp)	#, regs.eax
	call	i8k_smm	#
	testl	%eax, %eax	# rc
	js	.L9	#,
	movl	(%esp), %eax	# regs.eax, csui.31
	shrl	$8, %eax	#, csui.31
	andl	$7, %eax	#, csui.31
	leal	-1(%eax), %edx	#, csui.31
	xorl	%eax, %eax	# rc
	cmpl	$3, %edx	#, csui.31
	ja	.L9	#,
	movl	CSWTCH.30(,%edx,4), %eax	# CSWTCH.30, rc
.L9:
	addl	$24, %esp	#,
	popl	%edi	#
	ret
	.size	i8k_get_fn_status, .-i8k_get_fn_status
	.type	i8k_get_power_status, @function
i8k_get_power_status:
	pushl	%edi	#
	xorl	%eax, %eax	# tmp63
	subl	$24, %esp	#,
	movl	$6, %ecx	#, tmp64
	movl	%esp, %edi	#, tmp62
	rep stosl
	movl	%esp, %eax	#, tmp65
	movl	$105, (%esp)	#, regs.eax
	call	i8k_smm	#
	testl	%eax, %eax	# rc
	js	.L12	#,
	xorl	%eax, %eax	# rc
	cmpb	$5, (%esp)	#, regs.eax
	sete	%al	#, rc
.L12:
	addl	$24, %esp	#,
	popl	%edi	#
	ret
	.size	i8k_get_power_status, .-i8k_get_power_status
	.type	i8k_get_fan_status, @function
i8k_get_fan_status:
	pushl	%edi	#
	movl	%eax, %edx	# fan, fan
	subl	$24, %esp	#,
	xorl	%eax, %eax	# tmp66
	movl	%esp, %edi	#, tmp65
	movl	$6, %ecx	#, tmp67
	rep stosl
	andl	$255, %edx	#, tmp68
	movl	%esp, %eax	#, tmp69
	movl	$163, (%esp)	#, regs.eax
	movl	%edx, 4(%esp)	# tmp68, regs.ebx
	call	i8k_smm	#
	testl	%eax, %eax	# D.15134
	jne	.L14	#,
	movl	(%esp), %eax	# regs.eax, regs.eax
	andl	$255, %eax	#, D.15134
.L14:
	addl	$24, %esp	#,
	popl	%edi	#
	ret
	.size	i8k_get_fan_status, .-i8k_get_fan_status
	.type	i8k_get_fan_speed, @function
i8k_get_fan_speed:
	pushl	%edi	#
	movl	%eax, %edx	# fan, fan
	subl	$24, %esp	#,
	xorl	%eax, %eax	# tmp69
	movl	%esp, %edi	#, tmp68
	movl	$6, %ecx	#, tmp70
	rep stosl
	andl	$255, %edx	#, tmp71
	movl	%esp, %eax	#, tmp72
	movl	$675, (%esp)	#, regs.eax
	movl	%edx, 4(%esp)	# tmp71, regs.ebx
	call	i8k_smm	#
	testl	%eax, %eax	# D.15145
	jne	.L16	#,
	movl	(%esp), %eax	# regs.eax, regs.eax
	andl	$65535, %eax	#, D.15145
	imull	fan_mult, %eax	# fan_mult, D.15145
.L16:
	addl	$24, %esp	#,
	popl	%edi	#
	ret
	.size	i8k_get_fan_speed, .-i8k_get_fan_speed
	.type	i8k_get_dell_signature, @function
i8k_get_dell_signature:
	pushl	%edi	#
	movl	%eax, %edx	# req_fn, req_fn
	subl	$24, %esp	#,
	xorl	%eax, %eax	# tmp65
	movl	%esp, %edi	#, tmp64
	movl	$6, %ecx	#, tmp66
	rep stosl
	movl	%esp, %eax	#, tmp67
	movl	%edx, (%esp)	# req_fn, regs.eax
	call	i8k_smm	#
	testl	%eax, %eax	# rc
	js	.L18	#,
	orl	$-1, %eax	#, rc
	cmpl	$1145651527, (%esp)	#, regs.eax
	jne	.L18	#,
	xorl	%eax, %eax	# rc
	cmpl	$1145392204, 12(%esp)	#, regs.edx
	sete	%al	#, rc
	decl	%eax	# rc
.L18:
	addl	$24, %esp	#,
	popl	%edi	#
	ret
	.size	i8k_get_dell_signature, .-i8k_get_dell_signature
	.type	i8k_open_fs, @function
i8k_open_fs:
	movl	%edx, %eax	# file, file
	xorl	%ecx, %ecx	#
	movl	$i8k_proc_show, %edx	#,
	jmp	single_open	#
	.size	i8k_open_fs, .-i8k_open_fs
	.section	.rodata.str1.1,"aMS",@progbits,1
.LC0:
	.string	"?"
	.text
	.type	i8k_get_dmi_data, @function
i8k_get_dmi_data:
	call	dmi_get_system_info	#
	testl	%eax, %eax	# dmi_data
	je	.L24	#,
	cmpb	$0, (%eax)	#,* dmi_data
	movl	$.LC0, %edx	#, tmp63
	cmove	%edx, %eax	# dmi_data,, tmp63, dmi_data
	ret
.L24:
	movl	$.LC0, %eax	#, dmi_data
	ret
	.size	i8k_get_dmi_data, .-i8k_get_dmi_data
	.type	i8k_get_temp.clone.1, @function
i8k_get_temp.clone.1:
	pushl	%edi	#
	xorl	%eax, %eax	# tmp63
	subl	$24, %esp	#,
	movl	$6, %ecx	#, tmp64
	movl	%esp, %edi	#, tmp62
	rep stosl
	movl	%esp, %eax	#, tmp65
	movl	$4259, (%esp)	#, regs.eax
	call	i8k_smm	#
	testl	%eax, %eax	# rc
	js	.L26	#,
	movl	(%esp), %eax	# regs.eax, regs.eax
	andl	$255, %eax	#, rc
	cmpl	$127, %eax	#, rc
	jle	.L27	#,
	movl	prev.12857, %eax	# prev, rc
	movl	$127, prev.12857	#, prev
	jmp	.L26	#
.L27:
	movl	%eax, prev.12857	# rc, prev
.L26:
	addl	$24, %esp	#,
	popl	%edi	#
	ret
	.size	i8k_get_temp.clone.1, .-i8k_get_temp.clone.1
	.section	.rodata.str1.1
.LC1:
	.string	"1.0"
.LC2:
	.string	"%s %s %s %d %d %d %d %d %d %d\n"
	.text
	.type	i8k_proc_show, @function
i8k_proc_show:
	pushl	%ebp	#
	pushl	%edi	#
	pushl	%esi	#
	pushl	%ebx	#
	orl	$-1, %ebx	#, ac_power
	subl	$16, %esp	#,
	movl	%eax, 12(%esp)	# seq, %sfp
	call	i8k_get_temp.clone.1	#
	movl	%eax, (%esp)	#, %sfp
	movl	$1, %eax	#,
	call	i8k_get_fan_status	#
	movl	%eax, 4(%esp)	#, %sfp
	xorl	%eax, %eax	#
	call	i8k_get_fan_status	#
	movl	%eax, %esi	#, right_fan
	movl	$1, %eax	#,
	call	i8k_get_fan_speed	#
	movl	%eax, %edi	#, left_speed
	xorl	%eax, %eax	#
	call	i8k_get_fan_speed	#
	movl	%eax, %ebp	#, right_speed
	call	i8k_get_fn_status	#
	cmpl	$0, power_status	#, power_status
	movl	%eax, 8(%esp)	#, %sfp
	je	.L29	#,
	call	i8k_get_power_status	#
	movl	%eax, %ebx	#, ac_power
.L29:
	movl	$7, %eax	#,
	call	i8k_get_dmi_data	#
	pushl	8(%esp)	# %sfp
	pushl	%ebx	# ac_power
	pushl	%ebp	# right_speed
	pushl	%edi	# left_speed
	pushl	%esi	# right_fan
	pushl	24(%esp)	# %sfp
	pushl	24(%esp)	# %sfp
	pushl	%eax	# D.15110
	pushl	$bios_version	#
	pushl	$.LC1	#
	pushl	$.LC2	#
	pushl	56(%esp)	# %sfp
	call	seq_printf	#
	addl	$64, %esp	#,
	popl	%ebx	#
	popl	%esi	#
	popl	%edi	#
	popl	%ebp	#
	ret
	.size	i8k_proc_show, .-i8k_proc_show
	.type	copy_from_user.clone.2, @function
copy_from_user.clone.2:
	movl	$4, %ecx	#,
	jmp	_copy_from_user	#
	.size	copy_from_user.clone.2, .-copy_from_user.clone.2
	.type	i8k_ioctl, @function
i8k_ioctl:
	pushl	%ebp	#
	movl	%edx, %ebp	# cmd, cmd
	pushl	%edi	#
	pushl	%esi	#
	movl	$-22, %esi	#, ret
	pushl	%ebx	#
	movl	%ecx, %ebx	# arg, arg
	subl	$48, %esp	#,
	testl	%ecx, %ecx	# arg
	movl	$0, 44(%esp)	#, val
	je	.L33	#,
	cmpl	$-2147194493, %edx	#, cmd
	je	.L37	#,
	ja	.L42	#,
	cmpl	$-2147194495, %edx	#, cmd
	je	.L35	#,
	ja	.L36	#,
	cmpl	$-2147194496, %edx	#, cmd
	jne	.L51	#,
	jmp	.L63	#
.L42:
	cmpl	$-1073452667, %edx	#, cmd
	je	.L39	#,
	ja	.L43	#,
	cmpl	$-2147194492, %edx	#, cmd
	jne	.L51	#,
	jmp	.L64	#
.L43:
	cmpl	$-1073452666, %edx	#, cmd
	je	.L40	#,
	cmpl	$-1073452665, %edx	#, cmd
	jne	.L51	#,
	jmp	.L65	#
.L63:
	call	i8k_get_bios_version	#
	jmp	.L46	#
.L35:
	leal	24(%esp), %esi	#, tmp93
	xorl	%eax, %eax	# tmp95
	movl	%esi, %edi	# tmp93, tmp94
	movl	$4, %ecx	#, tmp96
	rep stosl
	movb	$7, %al	#,
	call	i8k_get_dmi_data	#
	movl	$16, %ecx	#,
	movl	%eax, %edx	# D.15467,
	movl	%esi, %eax	# tmp93,
	call	strlcpy	#
	jmp	.L44	#
.L37:
	call	i8k_get_fn_status	#
	jmp	.L46	#
.L36:
	call	i8k_get_power_status	#
	jmp	.L46	#
.L64:
	call	i8k_get_temp.clone.1	#
	jmp	.L46	#
.L39:
	leal	44(%esp), %eax	#, tmp98
	movl	%ecx, %edx	# arg,
	call	copy_from_user.clone.2	#
	movl	$-14, %esi	#, ret
	testl	%eax, %eax	# D.15472
	jne	.L33	#,
	movl	44(%esp), %eax	# val,
	call	i8k_get_fan_speed	#
	jmp	.L46	#
.L40:
	leal	44(%esp), %eax	#, tmp100
	movl	%ecx, %edx	# arg,
	call	copy_from_user.clone.2	#
	movl	$-14, %esi	#, ret
	testl	%eax, %eax	# D.15475
	jne	.L33	#,
	movl	44(%esp), %eax	# val,
	jmp	.L62	#
.L65:
	cmpl	$0, restricted	#, restricted
	je	.L45	#,
	movl	$21, %eax	#,
	orl	$-1, %esi	#, ret
	call	capable	#
	testl	%eax, %eax	# D.15478
	je	.L33	#,
.L45:
	leal	44(%esp), %eax	#, tmp102
	movl	%ebx, %edx	# arg,
	call	copy_from_user.clone.2	#
	movl	$-14, %esi	#, ret
	testl	%eax, %eax	# D.15479
	jne	.L33	#,
	leal	4(%ebx), %edx	#, tmp103
	leal	40(%esp), %eax	#, tmp104
	call	copy_from_user.clone.2	#
	testl	%eax, %eax	# D.15481
	jne	.L33	#,
	movl	%esp, %edi	#, tmp105
	movl	$6, %ecx	#, tmp107
	movl	40(%esp), %edx	# speed, speed.19
	rep stosl
	movl	44(%esp), %esi	# val, val.15
	movl	$419, (%esp)	#, regs.eax
	cmpl	$2, %edx	#, speed.19
	movb	$2, %cl	#,
	cmovle	%edx, %ecx	# speed.19,, speed
	movl	%esi, %edx	# val.15, tmp112
	testl	%ecx, %ecx	# speed
	cmovns	%ecx, %eax	# speed,, tmp113
	andl	$255, %edx	#, tmp112
	sall	$8, %eax	#, tmp113
	orl	%edx, %eax	# tmp112, tmp113
	movl	%eax, 4(%esp)	# tmp113, regs.ebx
	movl	%esp, %eax	#, tmp114
	call	i8k_smm	#
	testl	%eax, %eax	# D.15486
	jne	.L46	#,
	movl	%esi, %eax	# val.15,
.L62:
	call	i8k_get_fan_status	#
.L46:
	movl	%eax, 44(%esp)	# D.15486, val
.L44:
	movl	44(%esp), %esi	# val, ret
	testl	%esi, %esi	# ret
	js	.L33	#,
	cmpl	$-2147194496, %ebp	#, cmd
	je	.L60	#,
	cmpl	$-2147194495, %ebp	#, cmd
	jne	.L60	#,
	leal	24(%esp), %edx	#, tmp116
	movl	$16, %ecx	#,
.L61:
	movl	%ebx, %eax	# arg,
	call	copy_to_user	#
	cmpl	$1, %eax	#, D.15484
	sbbl	%esi, %esi	# ret
	notl	%esi	# ret
	andl	$-14, %esi	#, ret
	jmp	.L33	#
.L60:
	leal	44(%esp), %edx	#, tmp117
	movl	$4, %ecx	#,
	jmp	.L61	#
.L51:
	movl	$-22, %esi	#, ret
.L33:
	addl	$48, %esp	#,
	movl	%esi, %eax	# ret,
	popl	%ebx	#
	popl	%esi	#
	popl	%edi	#
	popl	%ebp	#
	ret
	.size	i8k_ioctl, .-i8k_ioctl
	.section	.rodata.str1.1
.LC3:
	.string	"<6>i8k: not running on a supported Dell system.\n"
.LC4:
	.string	"<6>i8k: vendor=%s, model=%s, version=%s\n"
.LC5:
	.string	"<3>i8k: unable to get SMM Dell signature\n"
.LC6:
	.string	"<4>i8k: unable to get SMM BIOS version\n"
.LC7:
	.string	"<4>i8k: BIOS version mismatch: %s != %s\n"
.LC8:
	.string	"1.14 21/02/2005"
.LC9:
	.string	"<6>Dell laptop SMM driver v%s Massimo Dal Zotto (dz@debian.org)\n"
.LC10:
	.string	"i8k"
	.section	.init.text,"ax",@progbits
	.type	i8k_init, @function
i8k_init:
	pushl	%esi	#
	movl	$i8k_dmi_table, %eax	#,
	pushl	%ebx	#
	subl	$4, %esp	#,
	call	dmi_check_system	#
	testl	%eax, %eax	# D.15529
	jne	.L67	#,
	cmpl	$0, ignore_dmi	#, ignore_dmi
	jne	.L68	#,
	cmpl	$0, force	#, force
	movl	$-19, %eax	#, D.15099
	je	.L69	#,
.L68:
	pushl	$.LC3	#
	call	printk	#
	movl	$2, %eax	#,
	call	i8k_get_dmi_data	#
	movl	%eax, %esi	#, D.15525
	movl	$5, %eax	#,
	call	i8k_get_dmi_data	#
	movl	%eax, %ebx	#, D.15524
	movl	$4, %eax	#,
	call	i8k_get_dmi_data	#
	pushl	%esi	# D.15525
	pushl	%ebx	# D.15524
	pushl	%eax	# D.15523
	pushl	$.LC4	#
	call	printk	#
	addl	$20, %esp	#,
.L67:
	movl	$2, %eax	#,
	call	i8k_get_dmi_data	#
	movl	$4, %ecx	#,
	movl	%eax, %edx	# D.15522,
	movl	$bios_version, %eax	#,
	call	strlcpy	#
	movl	$65187, %eax	#,
	call	i8k_get_dell_signature	#
	testl	%eax, %eax	# D.15521
	je	.L70	#,
	movl	$65443, %eax	#,
	call	i8k_get_dell_signature	#
	testl	%eax, %eax	# D.15520
	je	.L70	#,
	pushl	$.LC5	#
	call	printk	#
	movl	$-19, %eax	#, D.15099
	cmpl	$0, force	#, force
	popl	%edx	#
	je	.L69	#,
.L70:
	call	i8k_get_bios_version	#
	testl	%eax, %eax	# version
	jg	.L71	#,
	pushl	$.LC6	#
	call	printk	#
	popl	%eax	#
	jmp	.L72	#
.L71:
	movl	%eax, %edx	# version, tmp79
	sarl	$16, %edx	#, tmp79
	movb	%dl, (%esp)	# tmp79, buff
	movl	%eax, %edx	# version, tmp80
	sarl	$8, %edx	#, tmp80
	movb	%al, 2(%esp)	# version, buff
	movl	$2, %eax	#,
	movb	%dl, 1(%esp)	# tmp80, buff
	movb	$0, 3(%esp)	#, buff
	call	dmi_get_system_info	#
	testl	%eax, %eax	# D.15514
	jne	.L73	#,
	movl	%esp, %edx	#, tmp81
	movl	$4, %ecx	#,
	movl	$bios_version, %eax	#,
	call	strlcpy	#
.L73:
	movl	$4, %ecx	#,
	movl	$bios_version, %edx	#,
	movl	%esp, %eax	#,
	movl	%esp, %ebx	#, tmp82
	call	strncmp	#
	testl	%eax, %eax	# D.15513
	je	.L72	#,
	pushl	$bios_version	#
	pushl	%ebx	# tmp82
	pushl	$.LC7	#
	call	printk	#
	addl	$12, %esp	#,
	jmp	.L72	#
.L79:
	pushl	$.LC8	#
	pushl	$.LC9	#
	call	printk	#
	xorl	%eax, %eax	# D.15099
	popl	%ebx	#
	popl	%esi	#
.L69:
	addl	$4, %esp	#,
	popl	%ebx	#
	popl	%esi	#
	ret
.L72:
	pushl	$0	#
	xorl	%ecx, %ecx	#
	xorl	%edx, %edx	#
	movl	$.LC10, %eax	#,
	pushl	$i8k_fops	#
	call	proc_create_data	#
	movl	%eax, %edx	#, proc_i8k
	testl	%edx, %edx	# proc_i8k
	popl	%eax	#
	movl	$-2, %eax	#, D.15099
	popl	%ecx	#
	je	.L69	#,
	jmp	.L79	#
	.size	i8k_init, .-i8k_init
	.section	.exit.text,"ax",@progbits
	.type	i8k_exit, @function
i8k_exit:
	xorl	%edx, %edx	#
	movl	$.LC10, %eax	#,
	jmp	remove_proc_entry	#
	.size	i8k_exit, .-i8k_exit
	.section	.modinfo,"a",@progbits
	.align 4
	.type	__mod_fan_mult83, @object
	.size	__mod_fan_mult83, 48
__mod_fan_mult83:
	.string	"parm=fan_mult:Factor to multiply fan speed with"
	.align 4
	.type	__mod_fan_multtype82, @object
	.size	__mod_fan_multtype82, 22
__mod_fan_multtype82:
	.string	"parmtype=fan_mult:int"
	.section	__param,"a",@progbits
	.align 4
	.type	__param_fan_mult, @object
	.size	__param_fan_mult, 16
__param_fan_mult:
# name:
	.long	__param_str_fan_mult
# ops:
	.long	param_ops_int
# perm:
	.value	0
# flags:
	.value	0
# <anonymous>:
# arg:
	.long	fan_mult
	.section	.modinfo
	.align 4
	.type	__mod_power_status79, @object
	.size	__mod_power_status79, 51
__mod_power_status79:
	.string	"parm=power_status:Report power status in /proc/i8k"
	.align 4
	.type	__mod_power_statustype78, @object
	.size	__mod_power_statustype78, 27
__mod_power_statustype78:
	.string	"parmtype=power_status:bool"
	.section	__param
	.align 4
	.type	__param_power_status, @object
	.size	__param_power_status, 16
__param_power_status:
# name:
	.long	__param_str_power_status
# ops:
	.long	param_ops_bool
# perm:
	.value	384
# flags:
	.value	0
# <anonymous>:
# arg:
	.long	power_status
	.section	.modinfo
	.align 4
	.type	__mod_restricted75, @object
	.size	__mod_restricted75, 62
__mod_restricted75:
	.string	"parm=restricted:Allow fan control if SYS_ADMIN capability set"
	.align 4
	.type	__mod_restrictedtype74, @object
	.size	__mod_restrictedtype74, 25
__mod_restrictedtype74:
	.string	"parmtype=restricted:bool"
	.section	__param
	.align 4
	.type	__param_restricted, @object
	.size	__param_restricted, 16
__param_restricted:
# name:
	.long	__param_str_restricted
# ops:
	.long	param_ops_bool
# perm:
	.value	0
# flags:
	.value	0
# <anonymous>:
# arg:
	.long	restricted
	.section	.modinfo
	.align 4
	.type	__mod_ignore_dmi71, @object
	.size	__mod_ignore_dmi71, 74
__mod_ignore_dmi71:
	.string	"parm=ignore_dmi:Continue probing hardware even if DMI data does not match"
	.align 4
	.type	__mod_ignore_dmitype70, @object
	.size	__mod_ignore_dmitype70, 25
__mod_ignore_dmitype70:
	.string	"parmtype=ignore_dmi:bool"
	.section	__param
	.align 4
	.type	__param_ignore_dmi, @object
	.size	__param_ignore_dmi, 16
__param_ignore_dmi:
# name:
	.long	__param_str_ignore_dmi
# ops:
	.long	param_ops_bool
# perm:
	.value	0
# flags:
	.value	0
# <anonymous>:
# arg:
	.long	ignore_dmi
	.section	.modinfo
	.align 4
	.type	__mod_force67, @object
	.size	__mod_force67, 63
__mod_force67:
	.string	"parm=force:Force loading without checking for supported models"
	.align 4
	.type	__mod_forcetype66, @object
	.size	__mod_forcetype66, 20
__mod_forcetype66:
	.string	"parmtype=force:bool"
	.section	__param
	.align 4
	.type	__param_force, @object
	.size	__param_force, 16
__param_force:
# name:
	.long	__param_str_force
# ops:
	.long	param_ops_bool
# perm:
	.value	0
# flags:
	.value	0
# <anonymous>:
# arg:
	.long	force
	.section	.modinfo
	.align 4
	.type	__mod_license63, @object
	.size	__mod_license63, 12
__mod_license63:
	.string	"license=GPL"
	.align 4
	.type	__mod_description62, @object
	.size	__mod_description62, 58
__mod_description62:
	.string	"description=Driver for accessing SMM BIOS on Dell laptops"
	.align 4
	.type	__mod_author61, @object
	.size	__mod_author61, 41
__mod_author61:
	.string	"author=Massimo Dal Zotto (dz@debian.org)"
	.data
	.align 4
	.type	fan_mult, @object
	.size	fan_mult, 4
fan_mult:
	.long	30
	.local	power_status
	.comm	power_status,4,4
	.local	restricted
	.comm	restricted,4,4
	.local	ignore_dmi
	.comm	ignore_dmi,4,4
	.local	force
	.comm	force,4,4
	.section	.rodata
	.align 4
	.type	i8k_fops, @object
	.size	i8k_fops, 100
i8k_fops:
# owner:
	.long	__this_module
# llseek:
	.long	seq_lseek
# read:
	.long	seq_read
# unlocked_ioctl:
	.zero	20
	.long	i8k_ioctl
# open:
	.zero	8
	.long	i8k_open_fs
# release:
	.zero	4
	.long	single_release
	.zero	44
	.local	bios_version
	.comm	bios_version,4,4
	.local	prev.12857
	.comm	prev.12857,4,4
	.section	.rodata.str1.1
.LC11:
	.string	"Dell Inspiron"
.LC12:
	.string	"Dell Latitude"
.LC13:
	.string	"Dell Inspiron 2"
.LC14:
	.string	"Dell Latitude 2"
.LC15:
	.string	"Dell Inspiron 3"
.LC16:
	.string	"Dell Precision"
.LC17:
	.string	"Dell Vostro"
	.section	.init.data,"aw",@progbits
	.align 4
	.type	i8k_dmi_table, @object
	.size	i8k_dmi_table, 2988
i8k_dmi_table:
# ident:
	.zero	4
	.long	.LC11
# matches:
# slot:
	.byte	4
# substr:
	.string	"Dell Computer"
	.zero	65
# slot:
	.byte	5
# substr:
	.string	"Inspiron"
	.zero	70
	.zero	160
	.zero	4
# ident:
	.zero	4
	.long	.LC12
# matches:
# slot:
	.byte	4
# substr:
	.string	"Dell Computer"
	.zero	65
# slot:
	.byte	5
# substr:
	.string	"Latitude"
	.zero	70
	.zero	160
	.zero	4
# ident:
	.zero	4
	.long	.LC13
# matches:
# slot:
	.byte	4
# substr:
	.string	"Dell Inc."
	.zero	69
# slot:
	.byte	5
# substr:
	.string	"Inspiron"
	.zero	70
	.zero	160
	.zero	4
# ident:
	.zero	4
	.long	.LC14
# matches:
# slot:
	.byte	4
# substr:
	.string	"Dell Inc."
	.zero	69
# slot:
	.byte	5
# substr:
	.string	"Latitude"
	.zero	70
	.zero	160
	.zero	4
# ident:
	.zero	4
	.long	.LC15
# matches:
# slot:
	.byte	4
# substr:
	.string	"Dell Inc."
	.zero	69
# slot:
	.byte	5
# substr:
	.string	"MM061"
	.zero	73
	.zero	160
	.zero	4
# ident:
	.zero	4
	.long	.LC15
# matches:
# slot:
	.byte	4
# substr:
	.string	"Dell Inc."
	.zero	69
# slot:
	.byte	5
# substr:
	.string	"MP061"
	.zero	73
	.zero	160
	.zero	4
# ident:
	.zero	4
	.long	.LC16
# matches:
# slot:
	.byte	4
# substr:
	.string	"Dell Inc."
	.zero	69
# slot:
	.byte	5
# substr:
	.string	"Precision"
	.zero	69
	.zero	160
	.zero	4
# ident:
	.zero	4
	.long	.LC17
# matches:
# slot:
	.byte	4
# substr:
	.string	"Dell Inc."
	.zero	69
# slot:
	.byte	5
# substr:
	.string	"Vostro"
	.zero	72
	.zero	160
	.zero	4
	.zero	332
	.section	.rodata
	.align 4
	.type	CSWTCH.30, @object
	.size	CSWTCH.30, 16
CSWTCH.30:
	.long	1
	.long	2
	.long	0
	.long	4
	.align 4
	.type	__param_str_fan_mult, @object
	.size	__param_str_fan_mult, 9
__param_str_fan_mult:
	.string	"fan_mult"
	.align 4
	.type	__param_str_power_status, @object
	.size	__param_str_power_status, 13
__param_str_power_status:
	.string	"power_status"
	.align 4
	.type	__param_str_restricted, @object
	.size	__param_str_restricted, 11
__param_str_restricted:
	.string	"restricted"
	.align 4
	.type	__param_str_ignore_dmi, @object
	.size	__param_str_ignore_dmi, 11
__param_str_ignore_dmi:
	.string	"ignore_dmi"
	.align 4
	.type	__param_str_force, @object
	.size	__param_str_force, 6
__param_str_force:
	.string	"force"
.globl init_module
	.set	init_module,i8k_init
.globl cleanup_module
	.set	cleanup_module,i8k_exit
	.ident	"GCC: (GNU) 4.5.1"
	.section	.note.GNU-stack,"",@progbits

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jim Bos]

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 <jim876@xs4all.nl> 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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Linus Torvalds]

On Mon, Nov 15, 2010 at 10:30 AM, Jim Bos <jim876@xs4all.nl> 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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jakub Jelinek]

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 <jim876@xs4all.nl> 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 (&regs);
if (!x) x = regs.eax;
in the callers is optimized into
regs = {}
regs.eax = 166;
x = i8k_smm (&regs);
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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jakub Jelinek]

[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]

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

[-- Attachment #2: 1 --]
[-- Type: text/plain, Size: 706 bytes --]

--- gcc/ipa-pure-const.c.jj	2010-08-11 16:06:19.000000000 +0200
+++ gcc/ipa-pure-const.c	2010-11-15 20:06:36.121310614 +0100
@@ -460,7 +460,10 @@ check_stmt (gimple_stmt_iterator *gsip, 
       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 (TREE_CODE (TREE_VALUE (op)) == STRING_CST
+	      && TREE_STRING_LENGTH (TREE_VALUE (op)) == sizeof ("memory")
+	      && memcmp (TREE_STRING_POINTER (TREE_VALUE (op)), "memory",
+			 sizeof ("memory")) == 0)
 	    {
               if (dump_file)
                 fprintf (dump_file, "    memory asm clobber is not const/pure");

[-- Attachment #3: 2 --]
[-- Type: text/plain, Size: 561 bytes --]

--- gcc/ipa-pure-const.c.jj	2010-08-11 16:06:19.000000000 +0200
+++ gcc/ipa-pure-const.c	2010-11-15 20:07:51.463716989 +0100
@@ -460,7 +460,7 @@ check_stmt (gimple_stmt_iterator *gsip, 
       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 (strcmp (TREE_STRING_POINTER (TREE_VALUE (link)), "memory") == 0)
 	    {
               if (dump_file)
                 fprintf (dump_file, "    memory asm clobber is not const/pure");

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Linus Torvalds]

On Mon, Nov 15, 2010 at 11:12 AM, Jakub Jelinek <jakub@redhat.com> 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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jakub Jelinek]

On Mon, Nov 15, 2010 at 11:21:30AM -0800, Linus Torvalds wrote:
> On Mon, Nov 15, 2010 at 11:12 AM, Jakub Jelinek <jakub@redhat.com> 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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jim Bos]

[-- Attachment #1: Type: text/plain, Size: 2021 bytes --]

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 <jakub@redhat.com> 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 <jim876@xs4all.nl>


[-- Attachment #2: PATCH2.i8k.c --]
[-- Type: text/plain, Size: 916 bytes --]

--- linux/drivers/char/i8k.c.ORIG	2010-11-15 21:04:19.000000000 +0100
+++ linux/drivers/char/i8k.c	2010-11-15 21:02:32.000000000 +0100
@@ -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"
@@ -141,11 +141,11 @@
 		"lahf\n\t"
 		"shrl $8,%%eax\n\t"
 		"andl $1,%%eax\n"
-		:"=a"(rc), "+m" (*regs)
+		:"=a"(rc)
 		:    "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"
@@ -167,7 +167,7 @@
 	    "lahf\n\t"
 	    "shrl $8,%%eax\n\t"
 	    "andl $1,%%eax\n"
-	    :"=a"(rc), "+m" (*regs)
+	    :"=a"(rc)
 	    :    "a"(regs)
 	    :    "%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");
 #endif

2.6.39.1 immediately reboots/resets on EFI system

[Jim Bos]

[-- Attachment #1: Type: text/plain, Size: 879 bytes --]


*,

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

[-- Attachment #2: config-2.6.39.1.gz --]
[-- Type: application/gzip, Size: 20748 bytes --]

[-- Attachment #3: dmesg-2.6.39.1-withoutEFIpart.gz --]
[-- Type: application/gzip, Size: 10623 bytes --]

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Jim Bos]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Jim Bos]

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

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

[-- Attachment #2: dmesg-3.0.0-rc1-EFI-bad_pages.gz --]
[-- Type: application/gzip, Size: 12132 bytes --]

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Maarten Lankhorst]

Hi,

2011/6/5 Jim Bos <jim876@xs4all.nl>:
> 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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Maarten Lankhorst]

Hi Matthew,

2011/6/3 Matthew Garrett <mjg59@srcf.ucam.org>:
> 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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Jim Bos]

On 06/06/2011 05:01 PM, Maarten Lankhorst wrote:
> Hi Matthew,
> 
> 2011/6/3 Matthew Garrett <mjg59@srcf.ucam.org>:
>> 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 <jim876@xs4all.nl>

Jim.

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Maarten Lankhorst]

Hi Jim,

2011/6/3 Jim Bos <jim876@xs4all.nl>:
> 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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Jim Bos]

On 06/06/2011 05:27 PM, Maarten Lankhorst wrote:
> Hi Jim,
> 
> 2011/6/3 Jim Bos <jim876@xs4all.nl>:
>> 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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Maarten Lankhorst]

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 <jim876@xs4all.nl>:
>>> 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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Yinghai Lu]

On Mon, Jun 6, 2011 at 9:43 AM, Maarten Lankhorst
<m.b.lankhorst@gmail.com> 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 <jim876@xs4all.nl>:
>>>> 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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Yinghai Lu]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Maarten Lankhorst]

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+ (mlankhorst@patser.local) (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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Yinghai Lu]

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+ (mlankhorst@patser.local) (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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Maarten Lankhorst]

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);
 	}
 }

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Maarten Lankhorst]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Yinghai Lu]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Jim Bos]

[-- Attachment #1: Type: text/plain, Size: 3070 bytes --]

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




[-- Attachment #2: bug.txt --]
[-- Type: text/plain, Size: 1075 bytes --]

[    2.630101] BUG: Bad page state in process swapper  pfn:01800
[    2.631771] page:ffffea0000054000 count:0 mapcount:-127 mapping:          (null) index:0x0
[    2.633472] page flags: 0x4000000000000000()
[    2.635172] Pid: 1, comm: swapper Not tainted 3.0.0-rc1 #3
[    2.636856] Call Trace:
[    2.638515]  [<ffffffff8107e50d>] ? bad_page+0xd0/0xe2
[    2.640176]  [<ffffffff8107ea4c>] ? free_pages_prepare+0x67/0xa3
[    2.641846]  [<ffffffff8107db1e>] ? get_pageblock_flags_group+0x3f/0x76
[    2.643511]  [<ffffffff8107ebbf>] ? free_hot_cold_page+0x25/0x193
[    2.645177]  [<ffffffff81021ac9>] ? change_page_attr_set+0x23/0x28
[    2.646858]  [<ffffffff8101ee85>] ? free_init_pages+0xfb/0x110
[    2.648550]  [<ffffffff810001d8>] ? init_post+0xe/0xb6
[    2.650237]  [<ffffffff817b9bfc>] ? kernel_init+0x122/0x126
[    2.651926]  [<ffffffff81444564>] ? kernel_thread_helper+0x4/0x10
[    2.653602]  [<ffffffff817b9ada>] ? start_kernel+0x34f/0x34f
[    2.655268]  [<ffffffff81444560>] ? gs_change+0x13/0x13
[    2.656920] Disabling lock debugging due to kernel taint

[-- Attachment #3: dmesg-3.0.0-rc1.gz --]
[-- Type: application/gzip, Size: 14862 bytes --]

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Yinghai Lu]

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 <mjg@redhat.com>
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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

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 <mjg@redhat.com>
> 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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Yinghai Lu]

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 <mjg@redhat.com>
>> 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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

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 <mjg@redhat.com>
> >> 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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Yinghai Lu]

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 <mjg@redhat.com>
>>>> 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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Yinghai Lu]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Yinghai Lu]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Yinghai Lu]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Yinghai Lu]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Yinghai Lu]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Yinghai Lu]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Linus Torvalds]

On Wed, Jun 8, 2011 at 1:42 PM, Matthew Garrett <mjg59@srcf.ucam.org> 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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

On Wed, Jun 08, 2011 at 02:06:21PM -0700, Linus Torvalds wrote:
> On Wed, Jun 8, 2011 at 1:42 PM, Matthew Garrett <mjg59@srcf.ucam.org> 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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[H. Peter Anvin]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Linus Torvalds]

On Wed, Jun 8, 2011 at 2:28 PM, Matthew Garrett <mjg59@srcf.ucam.org> 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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

On Wed, Jun 08, 2011 at 02:31:55PM -0700, Linus Torvalds wrote:
> On Wed, Jun 8, 2011 at 2:28 PM, Matthew Garrett <mjg59@srcf.ucam.org> 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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[H. Peter Anvin]

On 06/08/2011 02:31 PM, Linus Torvalds wrote:
> On Wed, Jun 8, 2011 at 2:28 PM, Matthew Garrett <mjg59@srcf.ucam.org> 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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Linus Torvalds]

On Wed, Jun 8, 2011 at 2:51 PM, H. Peter Anvin <hpa@linux.intel.com> 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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Maarten Lankhorst]

Hey,

Op 09-06-11 00:57, Linus Torvalds schreef:
> On Wed, Jun 8, 2011 at 2:51 PM, H. Peter Anvin <hpa@linux.intel.com> 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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Yinghai Lu]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Maarten Lankhorst]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Maarten Lankhorst]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[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 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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Greg KH]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Maarten Lankhorst]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[H. Peter Anvin]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Yinghai Lu]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[H. Peter Anvin]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Yinghai Lu]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[H. Peter Anvin]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Yinghai Lu]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[H. Peter Anvin]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[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 <mjg@redhat.com>
| 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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Maarten Lankhorst]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Maarten Lankhorst]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Maarten Lankhorst]

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+ (mlankhorst@patser.local) (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: dm-devel@redhat.com
[    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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

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 | mjg59@srcf.ucam.org

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Maarten Lankhorst]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Maarten Lankhorst]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Maarten Lankhorst]

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

Re: 2.6.39.1 immediately reboots/resets on EFI system

[Matthew Garrett]

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 | mjg59@srcf.ucam.org

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Andi Kleen]

> 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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jakub Jelinek]

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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Richard Henderson]

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~

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Richard Guenther]

On Mon, Nov 15, 2010 at 9:56 AM, Jakub Jelinek <jakub@redhat.com> 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.

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jeff Law]

On 11/08/10 03:49, Richard Guenther wrote:
> On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen<andi@firstfloor.org>  wrote:
>> Andreas Schwab<schwab@linux-m68k.org>  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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Linus Torvalds]

On Mon, Nov 15, 2010 at 10:45 AM, Jeff Law <law@redhat.com> 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(&regs) ? : 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(&regs) ? : 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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Richard Guenther]

On Mon, Nov 15, 2010 at 7:45 PM, Jeff Law <law@redhat.com> wrote:
> On 11/08/10 03:49, Richard Guenther wrote:
>>
>> On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen<andi@firstfloor.org>  wrote:
>>>
>>> Andreas Schwab<schwab@linux-m68k.org>  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
>

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jeff Law]

On 11/15/10 15:07, Richard Guenther wrote:
> On Mon, Nov 15, 2010 at 7:45 PM, Jeff Law<law@redhat.com>  wrote:
>> On 11/08/10 03:49, Richard Guenther wrote:
>>> On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen<andi@firstfloor.org>    wrote:
>>>> Andreas Schwab<schwab@linux-m68k.org>    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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Richard Guenther]

On Mon, Nov 15, 2010 at 11:58 PM, Jeff Law <law@redhat.com> wrote:
> On 11/15/10 15:07, Richard Guenther wrote:
>>
>> On Mon, Nov 15, 2010 at 7:45 PM, Jeff Law<law@redhat.com>  wrote:
>>>
>>> On 11/08/10 03:49, Richard Guenther wrote:
>>>>
>>>> On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen<andi@firstfloor.org>
>>>>  wrote:
>>>>>
>>>>> Andreas Schwab<schwab@linux-m68k.org>    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
>

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jeff Law]

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

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

[Jeff Law]

On 11/07/10 15:41, Andreas Schwab wrote:
> Andi Kleen<andi@firstfloor.org>  writes:
>
>> Jim<jim876@xs4all.nl>  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