Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754251AbZGBG7s (ORCPT ); Thu, 2 Jul 2009 02:59:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750949AbZGBG7k (ORCPT ); Thu, 2 Jul 2009 02:59:40 -0400 Received: from mx3.mail.elte.hu ([157.181.1.138]:38315 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750888AbZGBG7k (ORCPT ); Thu, 2 Jul 2009 02:59:40 -0400 Date: Thu, 2 Jul 2009 08:59:22 +0200 From: Ingo Molnar To: Andrew Morton Cc: Yinghai Lu , Thomas Gleixner , "H. Peter Anvin" , Linus Torvalds , "linux-kernel@vger.kernel.org" Subject: [PATCH, v4] x86: Fix printk call in print_local_apic() Message-ID: <20090702065922.GB28135@elte.hu> References: <4A4C3410.8080704@kernel.org> <4A4C43BC.90506@kernel.org> <20090702061254.GA23277@elte.hu> <20090702062847.GB23277@elte.hu> <20090701234848.03dfa601.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090701234848.03dfa601.akpm@linux-foundation.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-ELTE-SpamScore: -1.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.5 -1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4267 Lines: 128 * Andrew Morton wrote: > On Thu, 2 Jul 2009 08:28:47 +0200 Ingo Molnar wrote: > > > + printk(KERN_CONT "%08x", i, apic_read(base + i*0x10)); > > oop - compile it first ;) oops - v4 below ... > There was some talk about teaching the lib/hexdump.c code to be > able to take a caller-provided give-me-another-byte function > pointer. This is the first potential user of such a thing which I > recall seeing, so it's probably good that we didn't do it ;) This at most has 'give me another 4 bytes' - plus there's some indexing weirdness as well. (the bitfield is holey in the MSR range) Dunno. Once the facility is available this code can be updated to use it, although it's certainly obvious enough in its current form already. Ingo -------------------> >From 251e1e44b97852aa5e53e71c4b47e55b2dfd054e Mon Sep 17 00:00:00 2001 From: Ingo Molnar Date: Thu, 2 Jul 2009 08:54:01 +0200 Subject: [PATCH] x86: Fix printk call in print_local_apic() Instead of this: [ 75.690022] <7>printing local APIC contents on CPU#0/0: [ 75.704406] ... APIC ID: 00000000 (0) [ 75.707905] ... APIC VERSION: 00060015 [ 75.722551] ... APIC TASKPRI: 00000000 (00) [ 75.725473] ... APIC PROCPRI: 00000000 [ 75.728592] ... APIC LDR: 00000001 [ 75.742137] ... APIC SPIV: 000001ff [ 75.744101] ... APIC ISR field: [ 75.746648] 0123456789abcdef0123456789abcdef [ 75.746649] <7>00000000000000000000000000000000 Improve the code to be saner and simpler and just print out the bitfield in a single line using hexa values - not as a (rather pointless) binary bitfield. Partially reused Linus's initial fix for this. Reported-and-Tested-by: Yinghai Lu Signed-off-by: Yinghai Lu Cc: Linus Torvalds Cc: Andrew Morton LKML-Reference: <4A4C43BC.90506@kernel.org> Signed-off-by: Ingo Molnar --- arch/x86/kernel/apic/io_apic.c | 31 +++++++++++++------------------ 1 files changed, 13 insertions(+), 18 deletions(-) diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index 4d0216f..8fd1efb 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -1716,25 +1716,19 @@ __apicdebuginit(void) print_IO_APIC(void) return; } -__apicdebuginit(void) print_APIC_bitfield(int base) +__apicdebuginit(void) print_APIC_field(int base) { - unsigned int v; - int i, j; + int i; if (apic_verbosity == APIC_QUIET) return; - printk(KERN_DEBUG "0123456789abcdef0123456789abcdef\n" KERN_DEBUG); - for (i = 0; i < 8; i++) { - v = apic_read(base + i*0x10); - for (j = 0; j < 32; j++) { - if (v & (1< 3) /* Due to the Pentium erratum 3AP. */ -- 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/