* gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? @ 2010-11-06 11:15 Jim 2010-11-07 21:31 ` Andi Kleen 0 siblings, 1 reply; 129+ messages in thread From: Jim @ 2010-11-06 11:15 UTC (permalink / raw) To: Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-06 11:15 gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? Jim @ 2010-11-07 21:31 ` Andi Kleen 2010-11-07 22:41 ` Andreas Schwab 0 siblings, 1 reply; 129+ messages in thread From: Andi Kleen @ 2010-11-07 21:31 UTC (permalink / raw) To: Jim; +Cc: Linux Kernel Mailing List, gcc 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. ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-07 21:31 ` Andi Kleen @ 2010-11-07 22:41 ` Andreas Schwab 2010-11-07 23:03 ` Andi Kleen 2010-11-15 18:42 ` Jeff Law 0 siblings, 2 replies; 129+ messages in thread From: Andreas Schwab @ 2010-11-07 22:41 UTC (permalink / raw) To: Andi Kleen; +Cc: Jim, Linux Kernel Mailing List, gcc 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." ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-07 22:41 ` Andreas Schwab @ 2010-11-07 23:03 ` Andi Kleen 2010-11-08 10:49 ` Richard Guenther 2010-11-15 18:42 ` Jeff Law 1 sibling, 1 reply; 129+ messages in thread From: Andi Kleen @ 2010-11-07 23:03 UTC (permalink / raw) To: Andreas Schwab; +Cc: Jim, Linux Kernel Mailing List, gcc 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. ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-07 23:03 ` Andi Kleen @ 2010-11-08 10:49 ` Richard Guenther 2010-11-08 11:20 ` Andi Kleen 2010-11-15 18:45 ` Jeff Law 0 siblings, 2 replies; 129+ messages in thread From: Richard Guenther @ 2010-11-08 10:49 UTC (permalink / raw) To: Andi Kleen; +Cc: Andreas Schwab, Jim, Linux Kernel Mailing List, gcc 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. > ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-08 10:49 ` Richard Guenther @ 2010-11-08 11:20 ` Andi Kleen 2010-11-08 11:20 ` Richard Guenther ` (2 more replies) 2010-11-15 18:45 ` Jeff Law 1 sibling, 3 replies; 129+ messages in thread From: Andi Kleen @ 2010-11-08 11:20 UTC (permalink / raw) To: Richard Guenther; +Cc: Andreas Schwab, Jim, Linux Kernel Mailing List, gcc 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. ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-08 11:20 ` Andi Kleen @ 2010-11-08 11:20 ` Richard Guenther 2010-11-08 11:47 ` Paul Koning 2010-11-08 12:20 ` Michael Matz 2010-11-08 18:39 ` Dave Korn 2 siblings, 1 reply; 129+ messages in thread From: Richard Guenther @ 2010-11-08 11:20 UTC (permalink / raw) To: Andi Kleen; +Cc: Andreas Schwab, Jim, Linux Kernel Mailing List, gcc 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. > ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-08 11:20 ` Richard Guenther @ 2010-11-08 11:47 ` Paul Koning 2010-11-08 11:53 ` Jakub Jelinek 0 siblings, 1 reply; 129+ messages in thread From: Paul Koning @ 2010-11-08 11:47 UTC (permalink / raw) To: Richard Guenther Cc: Andi Kleen, Andreas Schwab, Jim, Linux Kernel Mailing List, gcc 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-08 11:47 ` Paul Koning @ 2010-11-08 11:53 ` Jakub Jelinek 0 siblings, 0 replies; 129+ messages in thread From: Jakub Jelinek @ 2010-11-08 11:53 UTC (permalink / raw) To: Paul Koning Cc: Richard Guenther, Andi Kleen, Andreas Schwab, Jim, Linux Kernel Mailing List, gcc 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-08 11:20 ` Andi Kleen 2010-11-08 11:20 ` Richard Guenther @ 2010-11-08 12:20 ` Michael Matz 2010-11-08 18:39 ` Dave Korn 2 siblings, 0 replies; 129+ messages in thread From: Michael Matz @ 2010-11-08 12:20 UTC (permalink / raw) To: Andi Kleen Cc: Richard Guenther, Andreas Schwab, Jim, Linux Kernel Mailing List, gcc 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. ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-08 11:20 ` Andi Kleen 2010-11-08 11:20 ` Richard Guenther 2010-11-08 12:20 ` Michael Matz @ 2010-11-08 18:39 ` Dave Korn 2010-11-09 13:00 ` Michael Matz 2 siblings, 1 reply; 129+ messages in thread From: Dave Korn @ 2010-11-08 18:39 UTC (permalink / raw) To: Andi Kleen Cc: Richard Guenther, Andreas Schwab, Jim, Linux Kernel Mailing List, gcc 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-08 18:39 ` Dave Korn @ 2010-11-09 13:00 ` Michael Matz 2010-11-09 13:48 ` Andi Kleen 0 siblings, 1 reply; 129+ messages in thread From: Michael Matz @ 2010-11-09 13:00 UTC (permalink / raw) To: Dave Korn Cc: Andi Kleen, Richard Guenther, Andreas Schwab, Jim, Linux Kernel Mailing List, gcc 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. ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-09 13:00 ` Michael Matz @ 2010-11-09 13:48 ` Andi Kleen 2010-11-09 13:57 ` Andreas Schwab 0 siblings, 1 reply; 129+ messages in thread From: Andi Kleen @ 2010-11-09 13:48 UTC (permalink / raw) To: Michael Matz Cc: Dave Korn, Andi Kleen, Richard Guenther, Andreas Schwab, Jim, Linux Kernel Mailing List, gcc > 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 ^ permalink raw reply related [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-09 13:48 ` Andi Kleen @ 2010-11-09 13:57 ` Andreas Schwab 2010-11-09 16:43 ` Jim 0 siblings, 1 reply; 129+ messages in thread From: Andreas Schwab @ 2010-11-09 13:57 UTC (permalink / raw) To: Andi Kleen Cc: Michael Matz, Dave Korn, Richard Guenther, Jim, Linux Kernel Mailing List, gcc 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." ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-09 13:57 ` Andreas Schwab @ 2010-11-09 16:43 ` Jim 2010-11-13 11:13 ` [PATCH] i8k: Tell gcc that *regs gets clobbered Jim Bos 2010-11-15 0:52 ` gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? James Cloos 0 siblings, 2 replies; 129+ messages in thread From: Jim @ 2010-11-09 16:43 UTC (permalink / raw) To: Andreas Schwab Cc: Andi Kleen, Michael Matz, Dave Korn, Richard Guenther, Linux Kernel Mailing List, gcc [-- 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* [PATCH] i8k: Tell gcc that *regs gets clobbered 2010-11-09 16:43 ` Jim @ 2010-11-13 11:13 ` Jim Bos 2010-11-15 0:52 ` gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? James Cloos 1 sibling, 0 replies; 129+ messages in thread From: Jim Bos @ 2010-11-13 11:13 UTC (permalink / raw) To: Linus Torvalds Cc: Andreas Schwab, Andi Kleen, Michael Matz, Dave Korn, Richard Guenther, Linux Kernel Mailing List, gcc [-- 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-09 16:43 ` Jim 2010-11-13 11:13 ` [PATCH] i8k: Tell gcc that *regs gets clobbered Jim Bos @ 2010-11-15 0:52 ` James Cloos 2010-11-15 3:21 ` Linus Torvalds 1 sibling, 1 reply; 129+ messages in thread From: James Cloos @ 2010-11-15 0:52 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Andreas Schwab, Andi Kleen, Michael Matz, Dave Korn, Richard Guenther, Jim, gcc, Jim Bos, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 0:52 ` gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? James Cloos @ 2010-11-15 3:21 ` Linus Torvalds 2010-11-15 8:56 ` Jakub Jelinek 0 siblings, 1 reply; 129+ messages in thread From: Linus Torvalds @ 2010-11-15 3:21 UTC (permalink / raw) To: James Cloos Cc: Linux Kernel Mailing List, Andreas Schwab, Andi Kleen, Michael Matz, Dave Korn, Richard Guenther, gcc, Jim Bos 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 3:21 ` Linus Torvalds @ 2010-11-15 8:56 ` Jakub Jelinek 2010-11-15 9:12 ` Andi Kleen ` (3 more replies) 0 siblings, 4 replies; 129+ messages in thread From: Jakub Jelinek @ 2010-11-15 8:56 UTC (permalink / raw) To: Linus Torvalds Cc: James Cloos, Linux Kernel Mailing List, Andreas Schwab, Andi Kleen, Michael Matz, Dave Korn, Richard Guenther, gcc, Jim Bos 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 8:56 ` Jakub Jelinek @ 2010-11-15 9:12 ` Andi Kleen 2010-11-15 9:20 ` Jakub Jelinek ` (2 subsequent siblings) 3 siblings, 0 replies; 129+ messages in thread From: Andi Kleen @ 2010-11-15 9:12 UTC (permalink / raw) To: Jakub Jelinek Cc: Linus Torvalds, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Andi Kleen, Michael Matz, Dave Korn, Richard Guenther, gcc, Jim Bos > 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. ^ permalink raw reply related [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 8:56 ` Jakub Jelinek 2010-11-15 9:12 ` Andi Kleen @ 2010-11-15 9:20 ` Jakub Jelinek 2010-11-15 10:03 ` Jakub Jelinek 2010-11-15 10:24 ` Richard Guenther 3 siblings, 0 replies; 129+ messages in thread From: Jakub Jelinek @ 2010-11-15 9:20 UTC (permalink / raw) To: Linus Torvalds Cc: James Cloos, Linux Kernel Mailing List, Andreas Schwab, Andi Kleen, Michael Matz, Dave Korn, Richard Guenther, gcc, Jim Bos 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 8:56 ` Jakub Jelinek 2010-11-15 9:12 ` Andi Kleen 2010-11-15 9:20 ` Jakub Jelinek @ 2010-11-15 10:03 ` Jakub Jelinek 2010-11-15 10:54 ` Andi Kleen 2010-11-15 10:24 ` Richard Guenther 3 siblings, 1 reply; 129+ messages in thread From: Jakub Jelinek @ 2010-11-15 10:03 UTC (permalink / raw) To: Linus Torvalds Cc: James Cloos, Linux Kernel Mailing List, Andreas Schwab, Andi Kleen, Michael Matz, Dave Korn, Richard Guenther, gcc, Jim Bos 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 10:03 ` Jakub Jelinek @ 2010-11-15 10:54 ` Andi Kleen 2010-11-15 11:16 ` Jakub Jelinek 0 siblings, 1 reply; 129+ messages in thread From: Andi Kleen @ 2010-11-15 10:54 UTC (permalink / raw) To: Jakub Jelinek Cc: Linus Torvalds, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Andi Kleen, Michael Matz, Dave Korn, Richard Guenther, gcc, Jim Bos > 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. ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 10:54 ` Andi Kleen @ 2010-11-15 11:16 ` Jakub Jelinek 2010-11-15 11:37 ` Andi Kleen 2010-11-15 16:04 ` Linus Torvalds 0 siblings, 2 replies; 129+ messages in thread From: Jakub Jelinek @ 2010-11-15 11:16 UTC (permalink / raw) To: Andi Kleen Cc: Linus Torvalds, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Michael Matz, Dave Korn, Richard Guenther, gcc, Jim Bos 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 11:16 ` Jakub Jelinek @ 2010-11-15 11:37 ` Andi Kleen 2010-11-15 17:36 ` Jim Bos 2010-11-15 16:04 ` Linus Torvalds 1 sibling, 1 reply; 129+ messages in thread From: Andi Kleen @ 2010-11-15 11:37 UTC (permalink / raw) To: Jakub Jelinek Cc: Andi Kleen, Linus Torvalds, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Michael Matz, Dave Korn, Richard Guenther, gcc, Jim Bos > 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. ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 11:37 ` Andi Kleen @ 2010-11-15 17:36 ` Jim Bos 2010-11-15 17:44 ` Jakub Jelinek 0 siblings, 1 reply; 129+ messages in thread From: Jim Bos @ 2010-11-15 17:36 UTC (permalink / raw) To: Andi Kleen Cc: Jakub Jelinek, Linus Torvalds, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Michael Matz, Dave Korn, Richard Guenther, gcc [-- 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 --] ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 17:36 ` Jim Bos @ 2010-11-15 17:44 ` Jakub Jelinek 2010-11-15 18:17 ` Jim Bos 0 siblings, 1 reply; 129+ messages in thread From: Jakub Jelinek @ 2010-11-15 17:44 UTC (permalink / raw) To: Jim Bos Cc: Andi Kleen, Linus Torvalds, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Michael Matz, Dave Korn, Richard Guenther, gcc 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 17:44 ` Jakub Jelinek @ 2010-11-15 18:17 ` Jim Bos 2010-11-15 18:26 ` Jakub Jelinek 0 siblings, 1 reply; 129+ messages in thread From: Jim Bos @ 2010-11-15 18:17 UTC (permalink / raw) To: Jakub Jelinek Cc: Andi Kleen, Linus Torvalds, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Michael Matz, Dave Korn, Richard Guenther, gcc 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 18:17 ` Jim Bos @ 2010-11-15 18:26 ` Jakub Jelinek 2010-11-15 19:10 ` Jim Bos 0 siblings, 1 reply; 129+ messages in thread From: Jakub Jelinek @ 2010-11-15 18:26 UTC (permalink / raw) To: Jim Bos Cc: Andi Kleen, Linus Torvalds, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Michael Matz, Dave Korn, Richard Guenther, gcc 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 18:26 ` Jakub Jelinek @ 2010-11-15 19:10 ` Jim Bos 0 siblings, 0 replies; 129+ messages in thread From: Jim Bos @ 2010-11-15 19:10 UTC (permalink / raw) To: Jakub Jelinek Cc: Andi Kleen, Linus Torvalds, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Michael Matz, Dave Korn, Richard Guenther, gcc 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 11:16 ` Jakub Jelinek 2010-11-15 11:37 ` Andi Kleen @ 2010-11-15 16:04 ` Linus Torvalds 2010-11-15 17:40 ` Jim Bos 1 sibling, 1 reply; 129+ messages in thread From: Linus Torvalds @ 2010-11-15 16:04 UTC (permalink / raw) To: Jakub Jelinek Cc: Andi Kleen, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Michael Matz, Dave Korn, Richard Guenther, gcc, Jim Bos [-- 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 ^ permalink raw reply related [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 16:04 ` Linus Torvalds @ 2010-11-15 17:40 ` Jim Bos 2010-11-15 18:08 ` Linus Torvalds 0 siblings, 1 reply; 129+ messages in thread From: Jim Bos @ 2010-11-15 17:40 UTC (permalink / raw) To: Linus Torvalds Cc: Jakub Jelinek, Andi Kleen, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Michael Matz, Dave Korn, Richard Guenther, gcc 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. ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 17:40 ` Jim Bos @ 2010-11-15 18:08 ` Linus Torvalds 2010-11-15 18:30 ` Jim Bos 0 siblings, 1 reply; 129+ messages in thread From: Linus Torvalds @ 2010-11-15 18:08 UTC (permalink / raw) To: Jim Bos Cc: Jakub Jelinek, Andi Kleen, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Michael Matz, Dave Korn, Richard Guenther, gcc 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 18:08 ` Linus Torvalds @ 2010-11-15 18:30 ` Jim Bos 2010-11-15 18:37 ` Jim Bos ` (2 more replies) 0 siblings, 3 replies; 129+ messages in thread From: Jim Bos @ 2010-11-15 18:30 UTC (permalink / raw) To: Linus Torvalds Cc: Jakub Jelinek, Andi Kleen, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Michael Matz, Dave Korn, Richard Guenther, gcc [-- 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 18:30 ` Jim Bos @ 2010-11-15 18:37 ` Jim Bos 2010-11-15 18:56 ` Linus Torvalds 2010-11-15 18:58 ` Jakub Jelinek 2 siblings, 0 replies; 129+ messages in thread From: Jim Bos @ 2010-11-15 18:37 UTC (permalink / raw) To: Linus Torvalds Cc: Jakub Jelinek, Andi Kleen, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Michael Matz, Dave Korn, Richard Guenther, gcc 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 18:30 ` Jim Bos 2010-11-15 18:37 ` Jim Bos @ 2010-11-15 18:56 ` Linus Torvalds 2010-11-15 18:58 ` Jakub Jelinek 2 siblings, 0 replies; 129+ messages in thread From: Linus Torvalds @ 2010-11-15 18:56 UTC (permalink / raw) To: Jim Bos Cc: Jakub Jelinek, Andi Kleen, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Michael Matz, Dave Korn, Richard Guenther, gcc 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 18:30 ` Jim Bos 2010-11-15 18:37 ` Jim Bos 2010-11-15 18:56 ` Linus Torvalds @ 2010-11-15 18:58 ` Jakub Jelinek 2010-11-15 19:12 ` Jakub Jelinek 2 siblings, 1 reply; 129+ messages in thread From: Jakub Jelinek @ 2010-11-15 18:58 UTC (permalink / raw) To: Jim Bos Cc: Linus Torvalds, Jakub Jelinek, Andi Kleen, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Michael Matz, Dave Korn, Richard Guenther, gcc 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 (®s); if (!x) x = regs.eax; in the callers is optimized into regs = {} regs.eax = 166; x = i8k_smm (®s); if (!x) x = 166; Now, not sure why this happens, as there is case GIMPLE_ASM: for (i = 0; i < gimple_asm_nclobbers (stmt); i++) { tree op = gimple_asm_clobber_op (stmt, i); if (simple_cst_equal(TREE_VALUE (op), memory_identifier_string) == 1) { if (dump_file) fprintf (dump_file, " memory asm clobber is not const/pure"); /* Abandon all hope, ye who enter here. */ local->pure_const_state = IPA_NEITHER; } } Debugging... Jakub ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 18:58 ` Jakub Jelinek @ 2010-11-15 19:12 ` Jakub Jelinek 2010-11-15 19:21 ` Linus Torvalds 2010-11-15 19:53 ` Richard Henderson 0 siblings, 2 replies; 129+ messages in thread From: Jakub Jelinek @ 2010-11-15 19:12 UTC (permalink / raw) To: Linus Torvalds Cc: Jim Bos, Andi Kleen, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Michael Matz, Dave Korn, Richard Guenther, gcc [-- 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"); ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 19:12 ` Jakub Jelinek @ 2010-11-15 19:21 ` Linus Torvalds 2010-11-15 19:51 ` Jakub Jelinek 2010-11-15 19:53 ` Richard Henderson 1 sibling, 1 reply; 129+ messages in thread From: Linus Torvalds @ 2010-11-15 19:21 UTC (permalink / raw) To: Jakub Jelinek Cc: Jim Bos, Andi Kleen, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Michael Matz, Dave Korn, Richard Guenther, gcc 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 19:21 ` Linus Torvalds @ 2010-11-15 19:51 ` Jakub Jelinek 2010-11-15 20:22 ` Jim Bos 2010-11-15 22:43 ` gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? Andi Kleen 0 siblings, 2 replies; 129+ messages in thread From: Jakub Jelinek @ 2010-11-15 19:51 UTC (permalink / raw) To: Linus Torvalds Cc: Jim Bos, Andi Kleen, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Michael Matz, Dave Korn, Richard Guenther, gcc 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 19:51 ` Jakub Jelinek @ 2010-11-15 20:22 ` Jim Bos 2011-06-03 13:05 ` 2.6.39.1 immediately reboots/resets on EFI system Jim Bos 2010-11-15 22:43 ` gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? Andi Kleen 1 sibling, 1 reply; 129+ messages in thread From: Jim Bos @ 2010-11-15 20:22 UTC (permalink / raw) To: Linus Torvalds Cc: Jakub Jelinek, Andi Kleen, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Michael Matz, Dave Korn, Richard Guenther, gcc [-- 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* 2.6.39.1 immediately reboots/resets on EFI system 2010-11-15 20:22 ` Jim Bos @ 2011-06-03 13:05 ` Jim Bos 2011-06-03 13:33 ` Matthew Garrett 0 siblings, 1 reply; 129+ messages in thread From: Jim Bos @ 2011-06-03 13:05 UTC (permalink / raw) To: Linux Kernel Mailing List, Matthew Garrett; +Cc: Greg KH, H. Peter Anvin [-- 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 --] ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-03 13:05 ` 2.6.39.1 immediately reboots/resets on EFI system Jim Bos @ 2011-06-03 13:33 ` Matthew Garrett 2011-06-03 14:26 ` Jim Bos 0 siblings, 1 reply; 129+ messages in thread From: Matthew Garrett @ 2011-06-03 13:33 UTC (permalink / raw) To: Jim Bos; +Cc: Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-03 13:33 ` Matthew Garrett @ 2011-06-03 14:26 ` Jim Bos 2011-06-03 14:46 ` Matthew Garrett 2011-06-06 15:27 ` Maarten Lankhorst 0 siblings, 2 replies; 129+ messages in thread From: Jim Bos @ 2011-06-03 14:26 UTC (permalink / raw) To: Matthew Garrett; +Cc: Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-03 14:26 ` Jim Bos @ 2011-06-03 14:46 ` Matthew Garrett 2011-06-05 10:40 ` Jim Bos 2011-06-06 15:01 ` Maarten Lankhorst 2011-06-06 15:27 ` Maarten Lankhorst 1 sibling, 2 replies; 129+ messages in thread From: Matthew Garrett @ 2011-06-03 14:46 UTC (permalink / raw) To: Jim Bos; +Cc: Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-03 14:46 ` Matthew Garrett @ 2011-06-05 10:40 ` Jim Bos 2011-06-05 12:57 ` Maarten Lankhorst 2011-06-06 15:01 ` Maarten Lankhorst 1 sibling, 1 reply; 129+ messages in thread From: Jim Bos @ 2011-06-05 10:40 UTC (permalink / raw) To: Matthew Garrett; +Cc: Linux Kernel Mailing List, Greg KH, H. Peter Anvin [-- 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 --] ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-05 10:40 ` Jim Bos @ 2011-06-05 12:57 ` Maarten Lankhorst 0 siblings, 0 replies; 129+ messages in thread From: Maarten Lankhorst @ 2011-06-05 12:57 UTC (permalink / raw) To: Jim Bos Cc: Matthew Garrett, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-03 14:46 ` Matthew Garrett 2011-06-05 10:40 ` Jim Bos @ 2011-06-06 15:01 ` Maarten Lankhorst 2011-06-06 15:40 ` Jim Bos 2011-06-06 15:44 ` Matthew Garrett 1 sibling, 2 replies; 129+ messages in thread From: Maarten Lankhorst @ 2011-06-06 15:01 UTC (permalink / raw) To: Matthew Garrett Cc: Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply related [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-06 15:01 ` Maarten Lankhorst @ 2011-06-06 15:40 ` Jim Bos 2011-06-06 15:44 ` Matthew Garrett 1 sibling, 0 replies; 129+ messages in thread From: Jim Bos @ 2011-06-06 15:40 UTC (permalink / raw) To: Maarten Lankhorst Cc: Matthew Garrett, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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. ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-06 15:01 ` Maarten Lankhorst 2011-06-06 15:40 ` Jim Bos @ 2011-06-06 15:44 ` Matthew Garrett 1 sibling, 0 replies; 129+ messages in thread From: Matthew Garrett @ 2011-06-06 15:44 UTC (permalink / raw) To: Maarten Lankhorst Cc: Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-03 14:26 ` Jim Bos 2011-06-03 14:46 ` Matthew Garrett @ 2011-06-06 15:27 ` Maarten Lankhorst 2011-06-06 16:11 ` Jim Bos 1 sibling, 1 reply; 129+ messages in thread From: Maarten Lankhorst @ 2011-06-06 15:27 UTC (permalink / raw) To: Jim Bos Cc: Matthew Garrett, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-06 15:27 ` Maarten Lankhorst @ 2011-06-06 16:11 ` Jim Bos 2011-06-06 16:43 ` Maarten Lankhorst 0 siblings, 1 reply; 129+ messages in thread From: Jim Bos @ 2011-06-06 16:11 UTC (permalink / raw) To: Maarten Lankhorst Cc: Matthew Garrett, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-06 16:11 ` Jim Bos @ 2011-06-06 16:43 ` Maarten Lankhorst 2011-06-07 0:19 ` Yinghai Lu 0 siblings, 1 reply; 129+ messages in thread From: Maarten Lankhorst @ 2011-06-06 16:43 UTC (permalink / raw) To: Jim Bos Cc: Matthew Garrett, Linux Kernel Mailing List, Greg KH, H. Peter Anvin, Yinghai Lu 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-06 16:43 ` Maarten Lankhorst @ 2011-06-07 0:19 ` Yinghai Lu 2011-06-07 1:41 ` Matthew Garrett 0 siblings, 1 reply; 129+ messages in thread From: Yinghai Lu @ 2011-06-07 0:19 UTC (permalink / raw) To: Maarten Lankhorst Cc: Jim Bos, Matthew Garrett, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-07 0:19 ` Yinghai Lu @ 2011-06-07 1:41 ` Matthew Garrett 2011-06-07 2:05 ` Yinghai Lu 0 siblings, 1 reply; 129+ messages in thread From: Matthew Garrett @ 2011-06-07 1:41 UTC (permalink / raw) To: Yinghai Lu Cc: Maarten Lankhorst, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-07 1:41 ` Matthew Garrett @ 2011-06-07 2:05 ` Yinghai Lu 2011-06-07 8:25 ` Maarten Lankhorst 2011-06-07 9:08 ` Maarten Lankhorst 0 siblings, 2 replies; 129+ messages in thread From: Yinghai Lu @ 2011-06-07 2:05 UTC (permalink / raw) To: Matthew Garrett Cc: Maarten Lankhorst, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply related [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-07 2:05 ` Yinghai Lu @ 2011-06-07 8:25 ` Maarten Lankhorst 2011-06-07 15:14 ` Yinghai Lu 2011-06-07 9:08 ` Maarten Lankhorst 1 sibling, 1 reply; 129+ messages in thread From: Maarten Lankhorst @ 2011-06-07 8:25 UTC (permalink / raw) To: Yinghai Lu Cc: Matthew Garrett, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-07 8:25 ` Maarten Lankhorst @ 2011-06-07 15:14 ` Yinghai Lu 0 siblings, 0 replies; 129+ messages in thread From: Yinghai Lu @ 2011-06-07 15:14 UTC (permalink / raw) To: Maarten Lankhorst Cc: Matthew Garrett, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-07 2:05 ` Yinghai Lu 2011-06-07 8:25 ` Maarten Lankhorst @ 2011-06-07 9:08 ` Maarten Lankhorst 2011-06-07 12:22 ` Maarten Lankhorst 2011-06-10 16:47 ` Matthew Garrett 1 sibling, 2 replies; 129+ messages in thread From: Maarten Lankhorst @ 2011-06-07 9:08 UTC (permalink / raw) To: Yinghai Lu Cc: Matthew Garrett, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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); } } ^ permalink raw reply related [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-07 9:08 ` Maarten Lankhorst @ 2011-06-07 12:22 ` Maarten Lankhorst 2011-06-07 22:25 ` Yinghai Lu 2011-06-10 16:47 ` Matthew Garrett 1 sibling, 1 reply; 129+ messages in thread From: Maarten Lankhorst @ 2011-06-07 12:22 UTC (permalink / raw) To: Yinghai Lu Cc: Matthew Garrett, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-07 12:22 ` Maarten Lankhorst @ 2011-06-07 22:25 ` Yinghai Lu 2011-06-08 16:44 ` Jim Bos 0 siblings, 1 reply; 129+ messages in thread From: Yinghai Lu @ 2011-06-07 22:25 UTC (permalink / raw) To: Maarten Lankhorst Cc: Matthew Garrett, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-07 22:25 ` Yinghai Lu @ 2011-06-08 16:44 ` Jim Bos 2011-06-08 19:17 ` Yinghai Lu 0 siblings, 1 reply; 129+ messages in thread From: Jim Bos @ 2011-06-08 16:44 UTC (permalink / raw) To: Yinghai Lu Cc: Maarten Lankhorst, Matthew Garrett, Linux Kernel Mailing List, Greg KH, H. Peter Anvin [-- 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 --] ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 16:44 ` Jim Bos @ 2011-06-08 19:17 ` Yinghai Lu 2011-06-08 19:23 ` Matthew Garrett 0 siblings, 1 reply; 129+ messages in thread From: Yinghai Lu @ 2011-06-08 19:17 UTC (permalink / raw) To: Jim Bos, Matthew Garrett, H. Peter Anvin, Ingo Molnar, Thomas Gleixner Cc: Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Linus Torvalds, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 19:17 ` Yinghai Lu @ 2011-06-08 19:23 ` Matthew Garrett 2011-06-08 19:27 ` Yinghai Lu 0 siblings, 1 reply; 129+ messages in thread From: Matthew Garrett @ 2011-06-08 19:23 UTC (permalink / raw) To: Yinghai Lu Cc: Jim Bos, H. Peter Anvin, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Linus Torvalds, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 19:23 ` Matthew Garrett @ 2011-06-08 19:27 ` Yinghai Lu 2011-06-08 19:29 ` Matthew Garrett 0 siblings, 1 reply; 129+ messages in thread From: Yinghai Lu @ 2011-06-08 19:27 UTC (permalink / raw) To: Matthew Garrett Cc: Jim Bos, H. Peter Anvin, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Linus Torvalds, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 19:27 ` Yinghai Lu @ 2011-06-08 19:29 ` Matthew Garrett 2011-06-08 19:35 ` Yinghai Lu 0 siblings, 1 reply; 129+ messages in thread From: Matthew Garrett @ 2011-06-08 19:29 UTC (permalink / raw) To: Yinghai Lu Cc: Jim Bos, H. Peter Anvin, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Linus Torvalds, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 19:29 ` Matthew Garrett @ 2011-06-08 19:35 ` Yinghai Lu 2011-06-08 19:38 ` Matthew Garrett 0 siblings, 1 reply; 129+ messages in thread From: Yinghai Lu @ 2011-06-08 19:35 UTC (permalink / raw) To: Matthew Garrett Cc: Jim Bos, H. Peter Anvin, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Linus Torvalds, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 19:35 ` Yinghai Lu @ 2011-06-08 19:38 ` Matthew Garrett 2011-06-08 19:46 ` Yinghai Lu 2011-06-08 19:48 ` Yinghai Lu 0 siblings, 2 replies; 129+ messages in thread From: Matthew Garrett @ 2011-06-08 19:38 UTC (permalink / raw) To: Yinghai Lu Cc: Jim Bos, H. Peter Anvin, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Linus Torvalds, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 19:38 ` Matthew Garrett @ 2011-06-08 19:46 ` Yinghai Lu 2011-06-08 19:52 ` Matthew Garrett 2011-06-08 19:48 ` Yinghai Lu 1 sibling, 1 reply; 129+ messages in thread From: Yinghai Lu @ 2011-06-08 19:46 UTC (permalink / raw) To: Matthew Garrett Cc: Jim Bos, H. Peter Anvin, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Linus Torvalds, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 19:46 ` Yinghai Lu @ 2011-06-08 19:52 ` Matthew Garrett 0 siblings, 0 replies; 129+ messages in thread From: Matthew Garrett @ 2011-06-08 19:52 UTC (permalink / raw) To: Yinghai Lu Cc: Jim Bos, H. Peter Anvin, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Linus Torvalds, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 19:38 ` Matthew Garrett 2011-06-08 19:46 ` Yinghai Lu @ 2011-06-08 19:48 ` Yinghai Lu 2011-06-08 19:52 ` Matthew Garrett 1 sibling, 1 reply; 129+ messages in thread From: Yinghai Lu @ 2011-06-08 19:48 UTC (permalink / raw) To: Matthew Garrett Cc: Jim Bos, H. Peter Anvin, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Linus Torvalds, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 19:48 ` Yinghai Lu @ 2011-06-08 19:52 ` Matthew Garrett 2011-06-08 20:03 ` Yinghai Lu 0 siblings, 1 reply; 129+ messages in thread From: Matthew Garrett @ 2011-06-08 19:52 UTC (permalink / raw) To: Yinghai Lu Cc: Jim Bos, H. Peter Anvin, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Linus Torvalds, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 19:52 ` Matthew Garrett @ 2011-06-08 20:03 ` Yinghai Lu 2011-06-08 20:09 ` Matthew Garrett 0 siblings, 1 reply; 129+ messages in thread From: Yinghai Lu @ 2011-06-08 20:03 UTC (permalink / raw) To: Matthew Garrett Cc: Jim Bos, H. Peter Anvin, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Linus Torvalds, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 20:03 ` Yinghai Lu @ 2011-06-08 20:09 ` Matthew Garrett 2011-06-08 20:23 ` Yinghai Lu 0 siblings, 1 reply; 129+ messages in thread From: Matthew Garrett @ 2011-06-08 20:09 UTC (permalink / raw) To: Yinghai Lu Cc: Jim Bos, H. Peter Anvin, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Linus Torvalds, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 20:09 ` Matthew Garrett @ 2011-06-08 20:23 ` Yinghai Lu 2011-06-08 20:30 ` Matthew Garrett 0 siblings, 1 reply; 129+ messages in thread From: Yinghai Lu @ 2011-06-08 20:23 UTC (permalink / raw) To: Matthew Garrett Cc: Jim Bos, H. Peter Anvin, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Linus Torvalds, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 20:23 ` Yinghai Lu @ 2011-06-08 20:30 ` Matthew Garrett 2011-06-08 20:36 ` Yinghai Lu 0 siblings, 1 reply; 129+ messages in thread From: Matthew Garrett @ 2011-06-08 20:30 UTC (permalink / raw) To: Yinghai Lu Cc: Jim Bos, H. Peter Anvin, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Linus Torvalds, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 20:30 ` Matthew Garrett @ 2011-06-08 20:36 ` Yinghai Lu 2011-06-08 20:42 ` Matthew Garrett 0 siblings, 1 reply; 129+ messages in thread From: Yinghai Lu @ 2011-06-08 20:36 UTC (permalink / raw) To: Matthew Garrett Cc: Jim Bos, H. Peter Anvin, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Linus Torvalds, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 20:36 ` Yinghai Lu @ 2011-06-08 20:42 ` Matthew Garrett 2011-06-08 20:46 ` Yinghai Lu 2011-06-08 21:06 ` Linus Torvalds 0 siblings, 2 replies; 129+ messages in thread From: Matthew Garrett @ 2011-06-08 20:42 UTC (permalink / raw) To: Yinghai Lu Cc: Jim Bos, H. Peter Anvin, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Linus Torvalds, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 20:42 ` Matthew Garrett @ 2011-06-08 20:46 ` Yinghai Lu 2011-06-08 21:06 ` Matthew Garrett 2011-06-08 21:06 ` Linus Torvalds 1 sibling, 1 reply; 129+ messages in thread From: Yinghai Lu @ 2011-06-08 20:46 UTC (permalink / raw) To: Matthew Garrett Cc: Jim Bos, H. Peter Anvin, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Linus Torvalds, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 20:46 ` Yinghai Lu @ 2011-06-08 21:06 ` Matthew Garrett 0 siblings, 0 replies; 129+ messages in thread From: Matthew Garrett @ 2011-06-08 21:06 UTC (permalink / raw) To: Yinghai Lu Cc: Jim Bos, H. Peter Anvin, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Linus Torvalds, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 20:42 ` Matthew Garrett 2011-06-08 20:46 ` Yinghai Lu @ 2011-06-08 21:06 ` Linus Torvalds 2011-06-08 21:28 ` Matthew Garrett 1 sibling, 1 reply; 129+ messages in thread From: Linus Torvalds @ 2011-06-08 21:06 UTC (permalink / raw) To: Matthew Garrett Cc: Yinghai Lu, Jim Bos, H. Peter Anvin, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 21:06 ` Linus Torvalds @ 2011-06-08 21:28 ` Matthew Garrett 2011-06-08 21:31 ` H. Peter Anvin ` (2 more replies) 0 siblings, 3 replies; 129+ messages in thread From: Matthew Garrett @ 2011-06-08 21:28 UTC (permalink / raw) To: Linus Torvalds Cc: Yinghai Lu, Jim Bos, H. Peter Anvin, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 21:28 ` Matthew Garrett @ 2011-06-08 21:31 ` H. Peter Anvin 2011-06-08 21:36 ` Matthew Garrett 2011-06-08 21:31 ` Linus Torvalds 2011-06-08 21:38 ` Yinghai Lu 2 siblings, 1 reply; 129+ messages in thread From: H. Peter Anvin @ 2011-06-08 21:31 UTC (permalink / raw) To: Matthew Garrett Cc: Linus Torvalds, Yinghai Lu, Jim Bos, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 21:31 ` H. Peter Anvin @ 2011-06-08 21:36 ` Matthew Garrett 0 siblings, 0 replies; 129+ messages in thread From: Matthew Garrett @ 2011-06-08 21:36 UTC (permalink / raw) To: H. Peter Anvin Cc: Linus Torvalds, Yinghai Lu, Jim Bos, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 21:28 ` Matthew Garrett 2011-06-08 21:31 ` H. Peter Anvin @ 2011-06-08 21:31 ` Linus Torvalds 2011-06-08 21:42 ` Matthew Garrett 2011-06-08 21:51 ` H. Peter Anvin 2011-06-08 21:38 ` Yinghai Lu 2 siblings, 2 replies; 129+ messages in thread From: Linus Torvalds @ 2011-06-08 21:31 UTC (permalink / raw) To: Matthew Garrett Cc: Yinghai Lu, Jim Bos, H. Peter Anvin, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 21:31 ` Linus Torvalds @ 2011-06-08 21:42 ` Matthew Garrett 2011-06-08 21:51 ` H. Peter Anvin 1 sibling, 0 replies; 129+ messages in thread From: Matthew Garrett @ 2011-06-08 21:42 UTC (permalink / raw) To: Linus Torvalds Cc: Yinghai Lu, Jim Bos, H. Peter Anvin, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 21:31 ` Linus Torvalds 2011-06-08 21:42 ` Matthew Garrett @ 2011-06-08 21:51 ` H. Peter Anvin 2011-06-08 22:57 ` Linus Torvalds 1 sibling, 1 reply; 129+ messages in thread From: H. Peter Anvin @ 2011-06-08 21:51 UTC (permalink / raw) To: Linus Torvalds Cc: Matthew Garrett, Yinghai Lu, Jim Bos, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 21:51 ` H. Peter Anvin @ 2011-06-08 22:57 ` Linus Torvalds 2011-06-08 23:54 ` Maarten Lankhorst 0 siblings, 1 reply; 129+ messages in thread From: Linus Torvalds @ 2011-06-08 22:57 UTC (permalink / raw) To: H. Peter Anvin Cc: Matthew Garrett, Yinghai Lu, Jim Bos, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 22:57 ` Linus Torvalds @ 2011-06-08 23:54 ` Maarten Lankhorst 0 siblings, 0 replies; 129+ messages in thread From: Maarten Lankhorst @ 2011-06-08 23:54 UTC (permalink / raw) To: Linus Torvalds Cc: H. Peter Anvin, Matthew Garrett, Yinghai Lu, Jim Bos, Ingo Molnar, Thomas Gleixner, Linux Kernel Mailing List, Greg KH, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-08 21:28 ` Matthew Garrett 2011-06-08 21:31 ` H. Peter Anvin 2011-06-08 21:31 ` Linus Torvalds @ 2011-06-08 21:38 ` Yinghai Lu 2 siblings, 0 replies; 129+ messages in thread From: Yinghai Lu @ 2011-06-08 21:38 UTC (permalink / raw) To: Matthew Garrett Cc: Linus Torvalds, Jim Bos, H. Peter Anvin, Ingo Molnar, Thomas Gleixner, Maarten Lankhorst, Linux Kernel Mailing List, Greg KH, Andrew Morton 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-07 9:08 ` Maarten Lankhorst 2011-06-07 12:22 ` Maarten Lankhorst @ 2011-06-10 16:47 ` Matthew Garrett 2011-06-10 17:51 ` Maarten Lankhorst 1 sibling, 1 reply; 129+ messages in thread From: Matthew Garrett @ 2011-06-10 16:47 UTC (permalink / raw) To: Maarten Lankhorst Cc: Yinghai Lu, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-10 16:47 ` Matthew Garrett @ 2011-06-10 17:51 ` Maarten Lankhorst 2011-06-10 17:54 ` Matthew Garrett 0 siblings, 1 reply; 129+ messages in thread From: Maarten Lankhorst @ 2011-06-10 17:51 UTC (permalink / raw) To: Matthew Garrett Cc: Yinghai Lu, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-10 17:51 ` Maarten Lankhorst @ 2011-06-10 17:54 ` Matthew Garrett 2011-06-10 22:45 ` Maarten Lankhorst 0 siblings, 1 reply; 129+ messages in thread From: Matthew Garrett @ 2011-06-10 17:54 UTC (permalink / raw) To: Maarten Lankhorst Cc: Yinghai Lu, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-10 17:54 ` Matthew Garrett @ 2011-06-10 22:45 ` Maarten Lankhorst 2011-06-10 22:58 ` Yinghai Lu ` (2 more replies) 0 siblings, 3 replies; 129+ messages in thread From: Maarten Lankhorst @ 2011-06-10 22:45 UTC (permalink / raw) To: Matthew Garrett Cc: Yinghai Lu, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply related [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-10 22:45 ` Maarten Lankhorst @ 2011-06-10 22:58 ` Yinghai Lu 2011-06-10 23:03 ` Matthew Garrett 2011-06-10 23:00 ` Yinghai Lu 2011-06-13 16:47 ` Matthew Garrett 2 siblings, 1 reply; 129+ messages in thread From: Yinghai Lu @ 2011-06-10 22:58 UTC (permalink / raw) To: Maarten Lankhorst Cc: Matthew Garrett, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-10 22:58 ` Yinghai Lu @ 2011-06-10 23:03 ` Matthew Garrett 2011-06-10 23:17 ` Greg KH 2011-06-10 23:26 ` Yinghai Lu 0 siblings, 2 replies; 129+ messages in thread From: Matthew Garrett @ 2011-06-10 23:03 UTC (permalink / raw) To: Yinghai Lu Cc: Maarten Lankhorst, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-10 23:03 ` Matthew Garrett @ 2011-06-10 23:17 ` Greg KH 2011-06-10 23:22 ` Maarten Lankhorst 2011-06-10 23:25 ` H. Peter Anvin 2011-06-10 23:26 ` Yinghai Lu 1 sibling, 2 replies; 129+ messages in thread From: Greg KH @ 2011-06-10 23:17 UTC (permalink / raw) To: Matthew Garrett Cc: Yinghai Lu, Maarten Lankhorst, Jim Bos, Linux Kernel Mailing List, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-10 23:17 ` Greg KH @ 2011-06-10 23:22 ` Maarten Lankhorst 2011-06-10 23:25 ` H. Peter Anvin 1 sibling, 0 replies; 129+ messages in thread From: Maarten Lankhorst @ 2011-06-10 23:22 UTC (permalink / raw) To: Greg KH Cc: Matthew Garrett, Yinghai Lu, Jim Bos, Linux Kernel Mailing List, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-10 23:17 ` Greg KH 2011-06-10 23:22 ` Maarten Lankhorst @ 2011-06-10 23:25 ` H. Peter Anvin 1 sibling, 0 replies; 129+ messages in thread From: H. Peter Anvin @ 2011-06-10 23:25 UTC (permalink / raw) To: Greg KH Cc: Matthew Garrett, Yinghai Lu, Maarten Lankhorst, Jim Bos, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-10 23:03 ` Matthew Garrett 2011-06-10 23:17 ` Greg KH @ 2011-06-10 23:26 ` Yinghai Lu 2011-06-10 23:32 ` H. Peter Anvin 2011-06-11 15:29 ` Matthew Garrett 1 sibling, 2 replies; 129+ messages in thread From: Yinghai Lu @ 2011-06-10 23:26 UTC (permalink / raw) To: Matthew Garrett Cc: Maarten Lankhorst, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-10 23:26 ` Yinghai Lu @ 2011-06-10 23:32 ` H. Peter Anvin 2011-06-10 23:55 ` Yinghai Lu 2011-06-11 15:29 ` Matthew Garrett 1 sibling, 1 reply; 129+ messages in thread From: H. Peter Anvin @ 2011-06-10 23:32 UTC (permalink / raw) To: Yinghai Lu Cc: Matthew Garrett, Maarten Lankhorst, Jim Bos, Linux Kernel Mailing List, Greg KH 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-10 23:32 ` H. Peter Anvin @ 2011-06-10 23:55 ` Yinghai Lu 2011-06-11 0:00 ` H. Peter Anvin 0 siblings, 1 reply; 129+ messages in thread From: Yinghai Lu @ 2011-06-10 23:55 UTC (permalink / raw) To: H. Peter Anvin Cc: Matthew Garrett, Maarten Lankhorst, Jim Bos, Linux Kernel Mailing List, Greg KH 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-10 23:55 ` Yinghai Lu @ 2011-06-11 0:00 ` H. Peter Anvin 2011-06-11 0:19 ` Yinghai Lu 0 siblings, 1 reply; 129+ messages in thread From: H. Peter Anvin @ 2011-06-11 0:00 UTC (permalink / raw) To: Yinghai Lu Cc: Matthew Garrett, Maarten Lankhorst, Jim Bos, Linux Kernel Mailing List, Greg KH 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-11 0:00 ` H. Peter Anvin @ 2011-06-11 0:19 ` Yinghai Lu 2011-06-14 18:06 ` H. Peter Anvin 0 siblings, 1 reply; 129+ messages in thread From: Yinghai Lu @ 2011-06-11 0:19 UTC (permalink / raw) To: H. Peter Anvin Cc: Matthew Garrett, Maarten Lankhorst, Jim Bos, Linux Kernel Mailing List, Greg KH 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-11 0:19 ` Yinghai Lu @ 2011-06-14 18:06 ` H. Peter Anvin 0 siblings, 0 replies; 129+ messages in thread From: H. Peter Anvin @ 2011-06-14 18:06 UTC (permalink / raw) To: Yinghai Lu Cc: Matthew Garrett, Maarten Lankhorst, Jim Bos, Linux Kernel Mailing List, Greg KH 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-10 23:26 ` Yinghai Lu 2011-06-10 23:32 ` H. Peter Anvin @ 2011-06-11 15:29 ` Matthew Garrett 1 sibling, 0 replies; 129+ messages in thread From: Matthew Garrett @ 2011-06-11 15:29 UTC (permalink / raw) To: Yinghai Lu Cc: Maarten Lankhorst, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-10 22:45 ` Maarten Lankhorst 2011-06-10 22:58 ` Yinghai Lu @ 2011-06-10 23:00 ` Yinghai Lu 2011-06-13 16:47 ` Matthew Garrett 2 siblings, 0 replies; 129+ messages in thread From: Yinghai Lu @ 2011-06-10 23:00 UTC (permalink / raw) To: Maarten Lankhorst, H. Peter Anvin, Linus Torvalds, Andrew Morton, Ingo Molnar, Thomas Gleixner Cc: Matthew Garrett, Jim Bos, Linux Kernel Mailing List, Greg KH 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-10 22:45 ` Maarten Lankhorst 2011-06-10 22:58 ` Yinghai Lu 2011-06-10 23:00 ` Yinghai Lu @ 2011-06-13 16:47 ` Matthew Garrett 2011-06-13 17:52 ` Maarten Lankhorst 2 siblings, 1 reply; 129+ messages in thread From: Matthew Garrett @ 2011-06-13 16:47 UTC (permalink / raw) To: Maarten Lankhorst Cc: Yinghai Lu, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply related [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-13 16:47 ` Matthew Garrett @ 2011-06-13 17:52 ` Maarten Lankhorst 2011-06-13 18:00 ` Matthew Garrett 0 siblings, 1 reply; 129+ messages in thread From: Maarten Lankhorst @ 2011-06-13 17:52 UTC (permalink / raw) To: Matthew Garrett Cc: Yinghai Lu, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-13 17:52 ` Maarten Lankhorst @ 2011-06-13 18:00 ` Matthew Garrett 2011-06-13 18:14 ` Maarten Lankhorst 0 siblings, 1 reply; 129+ messages in thread From: Matthew Garrett @ 2011-06-13 18:00 UTC (permalink / raw) To: Maarten Lankhorst Cc: Yinghai Lu, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-13 18:00 ` Matthew Garrett @ 2011-06-13 18:14 ` Maarten Lankhorst 2011-06-13 18:17 ` Matthew Garrett 0 siblings, 1 reply; 129+ messages in thread From: Maarten Lankhorst @ 2011-06-13 18:14 UTC (permalink / raw) To: Matthew Garrett Cc: Yinghai Lu, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-13 18:14 ` Maarten Lankhorst @ 2011-06-13 18:17 ` Matthew Garrett 2011-06-13 18:23 ` Maarten Lankhorst 0 siblings, 1 reply; 129+ messages in thread From: Matthew Garrett @ 2011-06-13 18:17 UTC (permalink / raw) To: Maarten Lankhorst Cc: Yinghai Lu, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-13 18:17 ` Matthew Garrett @ 2011-06-13 18:23 ` Maarten Lankhorst 2011-06-13 18:33 ` Matthew Garrett 0 siblings, 1 reply; 129+ messages in thread From: Maarten Lankhorst @ 2011-06-13 18:23 UTC (permalink / raw) To: Matthew Garrett Cc: Yinghai Lu, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-13 18:23 ` Maarten Lankhorst @ 2011-06-13 18:33 ` Matthew Garrett 2011-06-13 18:45 ` Maarten Lankhorst ` (2 more replies) 0 siblings, 3 replies; 129+ messages in thread From: Matthew Garrett @ 2011-06-13 18:33 UTC (permalink / raw) To: Maarten Lankhorst Cc: Yinghai Lu, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-13 18:33 ` Matthew Garrett @ 2011-06-13 18:45 ` Maarten Lankhorst 2011-06-14 14:34 ` Maarten Lankhorst 2011-06-14 14:50 ` Maarten Lankhorst 2 siblings, 0 replies; 129+ messages in thread From: Maarten Lankhorst @ 2011-06-13 18:45 UTC (permalink / raw) To: Matthew Garrett Cc: Yinghai Lu, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-13 18:33 ` Matthew Garrett 2011-06-13 18:45 ` Maarten Lankhorst @ 2011-06-14 14:34 ` Maarten Lankhorst 2011-06-14 14:50 ` Maarten Lankhorst 2 siblings, 0 replies; 129+ messages in thread From: Maarten Lankhorst @ 2011-06-14 14:34 UTC (permalink / raw) To: Matthew Garrett Cc: Yinghai Lu, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-13 18:33 ` Matthew Garrett 2011-06-13 18:45 ` Maarten Lankhorst 2011-06-14 14:34 ` Maarten Lankhorst @ 2011-06-14 14:50 ` Maarten Lankhorst 2011-06-14 14:55 ` Matthew Garrett 2 siblings, 1 reply; 129+ messages in thread From: Maarten Lankhorst @ 2011-06-14 14:50 UTC (permalink / raw) To: Matthew Garrett Cc: Yinghai Lu, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: 2.6.39.1 immediately reboots/resets on EFI system 2011-06-14 14:50 ` Maarten Lankhorst @ 2011-06-14 14:55 ` Matthew Garrett 0 siblings, 0 replies; 129+ messages in thread From: Matthew Garrett @ 2011-06-14 14:55 UTC (permalink / raw) To: Maarten Lankhorst Cc: Yinghai Lu, Jim Bos, Linux Kernel Mailing List, Greg KH, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 19:51 ` Jakub Jelinek 2010-11-15 20:22 ` Jim Bos @ 2010-11-15 22:43 ` Andi Kleen 2010-11-15 22:46 ` Jakub Jelinek 1 sibling, 1 reply; 129+ messages in thread From: Andi Kleen @ 2010-11-15 22:43 UTC (permalink / raw) To: Jakub Jelinek Cc: Linus Torvalds, Jim Bos, Andi Kleen, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Michael Matz, Dave Korn, Richard Guenther, gcc > 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 22:43 ` gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? Andi Kleen @ 2010-11-15 22:46 ` Jakub Jelinek 0 siblings, 0 replies; 129+ messages in thread From: Jakub Jelinek @ 2010-11-15 22:46 UTC (permalink / raw) To: Andi Kleen Cc: Linus Torvalds, Jim Bos, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Michael Matz, Dave Korn, Richard Guenther, gcc 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 19:12 ` Jakub Jelinek 2010-11-15 19:21 ` Linus Torvalds @ 2010-11-15 19:53 ` Richard Henderson 1 sibling, 0 replies; 129+ messages in thread From: Richard Henderson @ 2010-11-15 19:53 UTC (permalink / raw) To: Jakub Jelinek Cc: Linus Torvalds, Jim Bos, Andi Kleen, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Michael Matz, Dave Korn, Richard Guenther, gcc 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~ ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 8:56 ` Jakub Jelinek ` (2 preceding siblings ...) 2010-11-15 10:03 ` Jakub Jelinek @ 2010-11-15 10:24 ` Richard Guenther 3 siblings, 0 replies; 129+ messages in thread From: Richard Guenther @ 2010-11-15 10:24 UTC (permalink / raw) To: Jakub Jelinek Cc: Linus Torvalds, James Cloos, Linux Kernel Mailing List, Andreas Schwab, Andi Kleen, Michael Matz, Dave Korn, gcc, Jim Bos 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. ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-08 10:49 ` Richard Guenther 2010-11-08 11:20 ` Andi Kleen @ 2010-11-15 18:45 ` Jeff Law 2010-11-15 19:04 ` Linus Torvalds 2010-11-15 22:07 ` Richard Guenther 1 sibling, 2 replies; 129+ messages in thread From: Jeff Law @ 2010-11-15 18:45 UTC (permalink / raw) To: Richard Guenther Cc: Andi Kleen, Andreas Schwab, Jim, Linux Kernel Mailing List, gcc 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 18:45 ` Jeff Law @ 2010-11-15 19:04 ` Linus Torvalds 2010-11-15 22:07 ` Richard Guenther 1 sibling, 0 replies; 129+ messages in thread From: Linus Torvalds @ 2010-11-15 19:04 UTC (permalink / raw) To: Jeff Law Cc: Richard Guenther, Andi Kleen, Andreas Schwab, Jim, Linux Kernel Mailing List, gcc 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(®s) ? : regs.eax; } and since gcc has (incorrectly) decided that "i8k_smm()" is a const function, it thinks that "regs.eax" hasn't changed, so it doesn't bother to reload it: it "knows" that it is still I8K_SMM_BIOS_VERSION that it initialized it with. So it will basically have rewritten that final return statement as return i8k_smm(®s) ? : I8K_SMM_BIOS_VERSION; which obviously doesn't really work. This also explains why adding "volatile" worked. The "asm volatile" triggered "this is not a const function". Similarly, the "+m" works, because it also makes clear that the asm is writing to memory, and isn't a const function. Now, the "memory" clobber should clearly also have done that, but I'd be willing to bet that some version of gcc (possibly extra slackware patches) had forgotten the trivial logic to say "a memory clobber also makes the user function non-const". Linus ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 18:45 ` Jeff Law 2010-11-15 19:04 ` Linus Torvalds @ 2010-11-15 22:07 ` Richard Guenther 2010-11-15 22:58 ` Jeff Law 1 sibling, 1 reply; 129+ messages in thread From: Richard Guenther @ 2010-11-15 22:07 UTC (permalink / raw) To: Jeff Law; +Cc: Andi Kleen, Andreas Schwab, Jim, Linux Kernel Mailing List, gcc 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 > ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 22:07 ` Richard Guenther @ 2010-11-15 22:58 ` Jeff Law 2010-11-15 23:07 ` Richard Guenther 0 siblings, 1 reply; 129+ messages in thread From: Jeff Law @ 2010-11-15 22:58 UTC (permalink / raw) To: Richard Guenther Cc: Andi Kleen, Andreas Schwab, Jim, Linux Kernel Mailing List, gcc 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 22:58 ` Jeff Law @ 2010-11-15 23:07 ` Richard Guenther 2010-11-16 4:10 ` Jeff Law 0 siblings, 1 reply; 129+ messages in thread From: Richard Guenther @ 2010-11-15 23:07 UTC (permalink / raw) To: Jeff Law; +Cc: Andi Kleen, Andreas Schwab, Jim, Linux Kernel Mailing List, gcc 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 > ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-15 23:07 ` Richard Guenther @ 2010-11-16 4:10 ` Jeff Law 0 siblings, 0 replies; 129+ messages in thread From: Jeff Law @ 2010-11-16 4:10 UTC (permalink / raw) To: Richard Guenther Cc: Andi Kleen, Andreas Schwab, Jim, Linux Kernel Mailing List, gcc 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
* Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? 2010-11-07 22:41 ` Andreas Schwab 2010-11-07 23:03 ` Andi Kleen @ 2010-11-15 18:42 ` Jeff Law 1 sibling, 0 replies; 129+ messages in thread From: Jeff Law @ 2010-11-15 18:42 UTC (permalink / raw) To: Andreas Schwab; +Cc: Andi Kleen, Jim, Linux Kernel Mailing List, gcc 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 ^ permalink raw reply [flat|nested] 129+ messages in thread
end of thread, other threads:[~2011-06-14 18:07 UTC | newest] Thread overview: 129+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-11-06 11:15 gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? Jim 2010-11-07 21:31 ` Andi Kleen 2010-11-07 22:41 ` Andreas Schwab 2010-11-07 23:03 ` Andi Kleen 2010-11-08 10:49 ` Richard Guenther 2010-11-08 11:20 ` Andi Kleen 2010-11-08 11:20 ` Richard Guenther 2010-11-08 11:47 ` Paul Koning 2010-11-08 11:53 ` Jakub Jelinek 2010-11-08 12:20 ` Michael Matz 2010-11-08 18:39 ` Dave Korn 2010-11-09 13:00 ` Michael Matz 2010-11-09 13:48 ` Andi Kleen 2010-11-09 13:57 ` Andreas Schwab 2010-11-09 16:43 ` Jim 2010-11-13 11:13 ` [PATCH] i8k: Tell gcc that *regs gets clobbered Jim Bos 2010-11-15 0:52 ` gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? James Cloos 2010-11-15 3:21 ` Linus Torvalds 2010-11-15 8:56 ` Jakub Jelinek 2010-11-15 9:12 ` Andi Kleen 2010-11-15 9:20 ` Jakub Jelinek 2010-11-15 10:03 ` Jakub Jelinek 2010-11-15 10:54 ` Andi Kleen 2010-11-15 11:16 ` Jakub Jelinek 2010-11-15 11:37 ` Andi Kleen 2010-11-15 17:36 ` Jim Bos 2010-11-15 17:44 ` Jakub Jelinek 2010-11-15 18:17 ` Jim Bos 2010-11-15 18:26 ` Jakub Jelinek 2010-11-15 19:10 ` Jim Bos 2010-11-15 16:04 ` Linus Torvalds 2010-11-15 17:40 ` Jim Bos 2010-11-15 18:08 ` Linus Torvalds 2010-11-15 18:30 ` Jim Bos 2010-11-15 18:37 ` Jim Bos 2010-11-15 18:56 ` Linus Torvalds 2010-11-15 18:58 ` Jakub Jelinek 2010-11-15 19:12 ` Jakub Jelinek 2010-11-15 19:21 ` Linus Torvalds 2010-11-15 19:51 ` Jakub Jelinek 2010-11-15 20:22 ` Jim Bos 2011-06-03 13:05 ` 2.6.39.1 immediately reboots/resets on EFI system Jim Bos 2011-06-03 13:33 ` Matthew Garrett 2011-06-03 14:26 ` Jim Bos 2011-06-03 14:46 ` Matthew Garrett 2011-06-05 10:40 ` Jim Bos 2011-06-05 12:57 ` Maarten Lankhorst 2011-06-06 15:01 ` Maarten Lankhorst 2011-06-06 15:40 ` Jim Bos 2011-06-06 15:44 ` Matthew Garrett 2011-06-06 15:27 ` Maarten Lankhorst 2011-06-06 16:11 ` Jim Bos 2011-06-06 16:43 ` Maarten Lankhorst 2011-06-07 0:19 ` Yinghai Lu 2011-06-07 1:41 ` Matthew Garrett 2011-06-07 2:05 ` Yinghai Lu 2011-06-07 8:25 ` Maarten Lankhorst 2011-06-07 15:14 ` Yinghai Lu 2011-06-07 9:08 ` Maarten Lankhorst 2011-06-07 12:22 ` Maarten Lankhorst 2011-06-07 22:25 ` Yinghai Lu 2011-06-08 16:44 ` Jim Bos 2011-06-08 19:17 ` Yinghai Lu 2011-06-08 19:23 ` Matthew Garrett 2011-06-08 19:27 ` Yinghai Lu 2011-06-08 19:29 ` Matthew Garrett 2011-06-08 19:35 ` Yinghai Lu 2011-06-08 19:38 ` Matthew Garrett 2011-06-08 19:46 ` Yinghai Lu 2011-06-08 19:52 ` Matthew Garrett 2011-06-08 19:48 ` Yinghai Lu 2011-06-08 19:52 ` Matthew Garrett 2011-06-08 20:03 ` Yinghai Lu 2011-06-08 20:09 ` Matthew Garrett 2011-06-08 20:23 ` Yinghai Lu 2011-06-08 20:30 ` Matthew Garrett 2011-06-08 20:36 ` Yinghai Lu 2011-06-08 20:42 ` Matthew Garrett 2011-06-08 20:46 ` Yinghai Lu 2011-06-08 21:06 ` Matthew Garrett 2011-06-08 21:06 ` Linus Torvalds 2011-06-08 21:28 ` Matthew Garrett 2011-06-08 21:31 ` H. Peter Anvin 2011-06-08 21:36 ` Matthew Garrett 2011-06-08 21:31 ` Linus Torvalds 2011-06-08 21:42 ` Matthew Garrett 2011-06-08 21:51 ` H. Peter Anvin 2011-06-08 22:57 ` Linus Torvalds 2011-06-08 23:54 ` Maarten Lankhorst 2011-06-08 21:38 ` Yinghai Lu 2011-06-10 16:47 ` Matthew Garrett 2011-06-10 17:51 ` Maarten Lankhorst 2011-06-10 17:54 ` Matthew Garrett 2011-06-10 22:45 ` Maarten Lankhorst 2011-06-10 22:58 ` Yinghai Lu 2011-06-10 23:03 ` Matthew Garrett 2011-06-10 23:17 ` Greg KH 2011-06-10 23:22 ` Maarten Lankhorst 2011-06-10 23:25 ` H. Peter Anvin 2011-06-10 23:26 ` Yinghai Lu 2011-06-10 23:32 ` H. Peter Anvin 2011-06-10 23:55 ` Yinghai Lu 2011-06-11 0:00 ` H. Peter Anvin 2011-06-11 0:19 ` Yinghai Lu 2011-06-14 18:06 ` H. Peter Anvin 2011-06-11 15:29 ` Matthew Garrett 2011-06-10 23:00 ` Yinghai Lu 2011-06-13 16:47 ` Matthew Garrett 2011-06-13 17:52 ` Maarten Lankhorst 2011-06-13 18:00 ` Matthew Garrett 2011-06-13 18:14 ` Maarten Lankhorst 2011-06-13 18:17 ` Matthew Garrett 2011-06-13 18:23 ` Maarten Lankhorst 2011-06-13 18:33 ` Matthew Garrett 2011-06-13 18:45 ` Maarten Lankhorst 2011-06-14 14:34 ` Maarten Lankhorst 2011-06-14 14:50 ` Maarten Lankhorst 2011-06-14 14:55 ` Matthew Garrett 2010-11-15 22:43 ` gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ? Andi Kleen 2010-11-15 22:46 ` Jakub Jelinek 2010-11-15 19:53 ` Richard Henderson 2010-11-15 10:24 ` Richard Guenther 2010-11-15 18:45 ` Jeff Law 2010-11-15 19:04 ` Linus Torvalds 2010-11-15 22:07 ` Richard Guenther 2010-11-15 22:58 ` Jeff Law 2010-11-15 23:07 ` Richard Guenther 2010-11-16 4:10 ` Jeff Law 2010-11-15 18:42 ` Jeff Law
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).