Linus,
Please pull the latest x86-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus
HEAD: b2d668da9307c4c163dd603d2bb3cadb10f9fd37 x86, relocs: Build clean fix
These are the fixes left over from the very end of the v3.4
stabilization cycle, plus one more fix.
Thanks,
Ingo
------------------>
Alan Cox (1):
x86: Fix boot on Twinhead H12Y
Jarkko Sakkinen (1):
x86, relocs: Build clean fix
Sasha Levin (1):
x86, printk: Add missing KERN_CONT to NMI selftest
arch/x86/Makefile | 1 +
arch/x86/kernel/nmi_selftest.c | 12 ++++++------
arch/x86/pci/fixup.c | 17 +++++++++++++++++
3 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 94e91e4..b1c611e 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -206,6 +206,7 @@ archclean:
$(Q)rm -rf $(objtree)/arch/i386
$(Q)rm -rf $(objtree)/arch/x86_64
$(Q)$(MAKE) $(clean)=$(boot)
+ $(Q)$(MAKE) $(clean)=arch/x86/tools
define archhelp
echo '* bzImage - Compressed kernel image (arch/x86/boot/bzImage)'
diff --git a/arch/x86/kernel/nmi_selftest.c b/arch/x86/kernel/nmi_selftest.c
index 2c39dcd..9f11dd3 100644
--- a/arch/x86/kernel/nmi_selftest.c
+++ b/arch/x86/kernel/nmi_selftest.c
@@ -117,15 +117,15 @@ static void __init dotest(void (*testcase_fn)(void), int expected)
unexpected_testcase_failures++;
if (nmi_fail == FAILURE)
- printk("FAILED |");
+ printk(KERN_CONT "FAILED |");
else if (nmi_fail == TIMEOUT)
- printk("TIMEOUT|");
+ printk(KERN_CONT "TIMEOUT|");
else
- printk("ERROR |");
+ printk(KERN_CONT "ERROR |");
dump_stack();
} else {
testcase_successes++;
- printk(" ok |");
+ printk(KERN_CONT " ok |");
}
testcase_total++;
@@ -150,10 +150,10 @@ void __init nmi_selftest(void)
print_testname("remote IPI");
dotest(remote_ipi, SUCCESS);
- printk("\n");
+ printk(KERN_CONT "\n");
print_testname("local IPI");
dotest(local_ipi, SUCCESS);
- printk("\n");
+ printk(KERN_CONT "\n");
cleanup_nmi_testsuite();
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index d0e6e40..5dd467b 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -519,3 +519,20 @@ static void sb600_disable_hpet_bar(struct pci_dev *dev)
}
}
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_ATI, 0x4385, sb600_disable_hpet_bar);
+
+/*
+ * Twinhead H12Y needs us to block out a region otherwise we map devices
+ * there and any access kills the box.
+ *
+ * See: https://bugzilla.kernel.org/show_bug.cgi?id=10231
+ *
+ * Match off the LPC and svid/sdid (older kernels lose the bridge subvendor)
+ */
+static void __devinit twinhead_reserve_killing_zone(struct pci_dev *dev)
+{
+ if (dev->subsystem_vendor == 0x14FF && dev->subsystem_device == 0xA003) {
+ pr_info("Reserving memory on Twinhead H12Y\n");
+ request_mem_region(0xFFB00000, 0x100000, "twinhead");
+ }
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x27B9, twinhead_reserve_killing_zone);
On Wed, May 23, 2012 at 4:34 AM, Ingo Molnar <[email protected]> wrote:
>
> Sasha Levin (1):
> ? ? ?x86, printk: Add missing KERN_CONT to NMI selftest
Why? This seems to be garbage.
Linus
On 05/23/2012 10:07 AM, Linus Torvalds wrote:
> On Wed, May 23, 2012 at 4:34 AM, Ingo Molnar <[email protected]> wrote:
>>
>> Sasha Levin (1):
>> x86, printk: Add missing KERN_CONT to NMI selftest
>
> Why? This seems to be garbage.
>
This was added to the urgent branch earlier (but it wasn't worth pushing
late in rc) but apparently a more underlying bug was fixed in the meantime.
It didn't seem worth removing since the KERN_CONT should really be there
anyway.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
* H. Peter Anvin <[email protected]> wrote:
> On 05/23/2012 10:07 AM, Linus Torvalds wrote:
> > On Wed, May 23, 2012 at 4:34 AM, Ingo Molnar <[email protected]> wrote:
> >>
> >> Sasha Levin (1):
> >> x86, printk: Add missing KERN_CONT to NMI selftest
> >
> > Why? This seems to be garbage.
> >
>
> This was added to the urgent branch earlier (but it wasn't
> worth pushing late in rc) but apparently a more underlying bug
> was fixed in the meantime.
>
> It didn't seem worth removing since the KERN_CONT should
> really be there anyway.
I'm not sure it should be there: if there's no KERN_ prefix in a
printk, and the previous printk from this context did not end
with \n, then the KERN_CONT should be implicit.
KERN_CONT is really special, for rare cases where you want to
explicitly avoid the <> priority field or to construct it.
Or at least that's how I understand this area, it might have
been updated meanwhile - Linus?
Also, we can rebase the whole branch and get rid of this one and
of the merge commit it has.
Thanks,
Ingo
On Wed, May 23, 2012 at 10:48 AM, Ingo Molnar <[email protected]> wrote:
>
> Also, we can rebase the whole branch and get rid of this one and
> of the merge commit it has.
I took it, but it was really unnecessary.
There were printk() patches in the queue and being discussed that
needed this, but I wouldn't have pulled the end result if they hadn't
been fixed.
Linus
* Linus Torvalds <[email protected]> wrote:
> On Wed, May 23, 2012 at 10:48 AM, Ingo Molnar <[email protected]> wrote:
> >
> > Also, we can rebase the whole branch and get rid of this one
> > and of the merge commit it has.
>
> I took it, but it was really unnecessary.
Agreed.
> There were printk() patches in the queue and being discussed
> that needed this, but I wouldn't have pulled the end result if
> they hadn't been fixed.
Yeah.
Thanks,
Ingo
On 05/23/2012 10:57 AM, Linus Torvalds wrote:
> On Wed, May 23, 2012 at 10:48 AM, Ingo Molnar <[email protected]> wrote:
>>
>> Also, we can rebase the whole branch and get rid of this one and
>> of the merge commit it has.
>
> I took it, but it was really unnecessary.
>
> There were printk() patches in the queue and being discussed that
> needed this, but I wouldn't have pulled the end result if they hadn't
> been fixed.
>
Hi Linus,
Just for clarification - do you want the patch reverted? My reading of
what you wrote (as well as of the patch) is that it was an unnecessary
(redundant) patch, but Ingo is worried that you are saying it is incorrect.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Thu, May 24, 2012 at 8:31 AM, H. Peter Anvin <[email protected]> wrote:
>
> Just for clarification - do you want the patch reverted? ?My reading of
> what you wrote (as well as of the patch) is that it was an unnecessary
> (redundant) patch, but Ingo is worried that you are saying it is incorrect.
It's not technically incorrect, it was just unnecessary.
Linus
On Thu, May 24, 2012 at 11:31 PM, H. Peter Anvin <[email protected]> wrote:
> On 05/23/2012 10:57 AM, Linus Torvalds wrote:
>> On Wed, May 23, 2012 at 10:48 AM, Ingo Molnar <[email protected]> wrote:
>>>
>>> Also, we can rebase the whole branch and get rid of this one and
>>> of the merge commit it has.
>>
>> I took it, but it was really unnecessary.
>>
>> There were printk() patches in the queue and being discussed that
>> needed this, but I wouldn't have pulled the end result if they hadn't
>> been fixed.
>>
>
> Hi Linus,
>
> Just for clarification - do you want the patch reverted? ?My reading of
> what you wrote (as well as of the patch) is that it was an unnecessary
> (redundant) patch, but Ingo is worried that you are saying it is incorrect.
>
> ? ? ? ?-hpa
>
> --
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel. ?I don't speak on their behalf.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
Really redundant.The author is just re-implement the same
things.(Seems he disnt know that this is already implement.)
On Thu, May 24, 2012 at 11:44 PM, Linus Torvalds
<[email protected]> wrote:
> On Thu, May 24, 2012 at 8:31 AM, H. Peter Anvin <[email protected]> wrote:
>>
>> Just for clarification - do you want the patch reverted? ?My reading of
>> what you wrote (as well as of the patch) is that it was an unnecessary
>> (redundant) patch, but Ingo is worried that you are saying it is incorrect.
>
> It's not technically incorrect, it was just unnecessary.
>
> ? ? ? ? ? ? ? ? ? Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
Everyone knows that this patch had been unstable. Also, too much code
are pushed into printk() with the patch
* Chen <[email protected]> wrote:
> Everyone knows that this patch had been unstable. Also, too
> much code are pushed into printk() with the patch
Interesting posts, first the "500K scheduler" nonsense now
printk nonsense?
Ingo
On Thu, 2012-05-24 at 23:48 +0800, Chen wrote:
> The author is just re-implement the same
> things.(Seems he disnt know that this is already implement.)
What existing implementation are you talking about?
Provide links to public, GPLed code.
On Fri, May 25, 2012 at 1:07 AM, Ingo Molnar <[email protected]> wrote:
>
> Interesting posts, first the "500K scheduler" nonsense now
> printk nonsense?
printk nonsense? You actually read my words wrong(LAUGH!)
[I m going to quota my post]
* Chen <[email protected]> wrote:
> Everyone knows that this patch had been unstable. Also, too
> much code are pushed into printk() with the patch
>
I mean that too much code are brought with the patch.
500K scheduler is true. 248K(Core.c[MODULAR]) + 148K(fair.c[CFS]) +
47K(rt.c[RT]) = 443K.(Does not include the other source files of
scheduler.) It is really a *HUGE* CPU scheduler.[But it doesn't bring
much advantages to desktop!!]
* Chen <[email protected]> wrote:
> On Fri, May 25, 2012 at 1:07 AM, Ingo Molnar <[email protected]> wrote:
> >
> > Interesting posts, first the "500K scheduler" nonsense now
> > printk nonsense?
>
> printk nonsense? You actually read my words wrong(LAUGH!)
> [I m going to quota my post]
>
> * Chen <[email protected]> wrote:
> > Everyone knows that this patch had been unstable. Also, too
> > much code are pushed into printk() with the patch
>
> I mean that too much code are brought with the patch.
The 'Everyone knows that this patch had been unstable' bit is
the nonsense.
> 500K scheduler is true. 248K(Core.c[MODULAR]) +
> 148K(fair.c[CFS]) + 47K(rt.c[RT]) = 443K.(Does not include the
> other source files of scheduler.) It is really a *HUGE* CPU
> scheduler.[But it doesn't bring much advantages to desktop!!]
You are quite confused. Here's the reply I gave you in the other
thread:
Only binary code is counted in bytes, source code is counted in
lines.
20 KLOC for a full-featured CPU scheduler that does everything
from simple UP scheduling to thousands of CPUs NUMA scheduling,
cgroups, real-time and more, is entirely reasonable.
As a comparison the VM is 80+ KLOCS, arch/x86/ is 260+ KLOCs,
networking is 720+ KLOCS and the FS subsystem is over 1 million
lines of code.
The scheduler is in fact one of the smaller subsystems.
Thanks,
Ingo