x86/urgent fixes for v3.5
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(-)
arch/x86/Makefile +1 -0
@@ -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)'
arch/x86/kernel/nmi_selftest.c +6 -6
@@ -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 ();
arch/x86/pci/fixup.c +17 -0
@@ -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);
Quoted 3 lines · Ingo Molnar
Sasha Levin (1):
x86, printk: Add missingKERN_CONTto NMI selftest
Why? This seems to be garbage.
Linus
H. Peter Anvin
reviewerQuoted 7 lines · Linus Torvalds
Quoted 3 lines · Ingo Molnar
Sasha Levin (1):
x86, printk: Add missingKERN_CONTto NMI selftestWhy? 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
Signature · 2 lines
H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
Quoted 9 lines · H. Peter Anvin
Quoted 7 lines · Linus Torvalds
Quoted 3 lines · Ingo Molnar
Sasha Levin (1):
x86, printk: Add missingKERN_CONTto NMI selftestWhy? This seems to be garbage.
Quoted 6 lines
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_CONTshould 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
Quoted 3 lines · Ingo Molnar
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
Quoted 6 lines · Linus Torvalds
Quoted 3 lines · Ingo Molnar
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.
Quoted 3 lines
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
H. Peter Anvin
reviewerQuoted 11 lines · Linus Torvalds
Quoted 3 lines · Ingo Molnar
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
Signature · 2 lines
H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
Quoted 4 lines · H. Peter Anvin
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
Quoted 6 lines · Linus Torvalds
Quoted 4 lines · H. Peter Anvin
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.
Quoted 8 lines
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
Quoted 2 lines · Chen
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
Quoted 3 lines · Ingo Molnar
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]
Quoted 3 lines · Chen
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!!]
Quoted 5 lines · Chen
Quoted 3 lines · Ingo Molnar
Interesting posts, first the "500K scheduler" nonsense now printk nonsense?
Quoted 8 lines
printk nonsense? You actually read my words wrong(LAUGH!) [I m going to quota my post]
Quoted 2 lines · Chen
Everyone knows that this patch had been unstable. Also, too much code are pushed into
printk()with the patchI mean that too much code are brought with the patch.
The 'Everyone knows that this patch had been unstable' bit is the nonsense.
Quoted 4 lines
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
Quoted 25 lines · H. Peter Anvin
Quoted 11 lines · Linus Torvalds
Quoted 3 lines · Ingo Molnar
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.
Quoted 5 lines
--
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.)
Quoted 2 lines · Chen
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.