Andrew Worsley | 1 Jun 01:04 2011

Re: [PATCH] init, calibrate: Drop annoying warning

I can see your point - it's useful when debugging the bogomips issue -
but if it's working it's not relevant.
Would be nice to have an extra level of verbose debug or a debug
branch of the file or perhaps just a relevant comment
that would easily allow it to be found and reverted to re-enable debug
if people want to debug this stuff again.

That said I would suggest just changing the comment (I don't know how
to just submit a comment change?) to something like:

"Drop calibrate_delay_direct() KERN_DEBUG printk related to bogomips
calculation as it appears when booting
every core on setups with 'ignore_loglevel' for people who want to
test latest kernels and scan dmesg for possible issues.
and this information isn't very useful to the widest audience of
kernel boot message gazers."

which would allow an easy revert locally when ever it was deemed useful.

On 1 June 2011 04:29, Borislav Petkov <bp <at>> wrote:
> From: Borislav Petkov <borislav.petkov <at>>
> Even though the error message is KERN_DEBUG, it appears when booting
> every core on setups with 'ignore_loglevel' for people who want to test
> latest kernels and scan dmesg for possible issues. Also, it doesn't show
> very useful information to the widest audience of kernel boot message
> gazers so drop it.
> Introduced by d2b463135f84d15808163cd15638b108e323d3e7.
(Continue reading)

Joel Becker | 1 Jun 01:07 2011

Re: [PATCH] ocfs2: use proper little-endian bitops

On Tue, May 31, 2011 at 03:57:13PM -0700, Mark Fasheh wrote:
> On Mon, May 30, 2011 at 09:58:05PM +0900, Akinobu Mita wrote:
> > Using __test_and_{set,clear}_bit_le() with ignoring its return value
> > can be replaced with __{set,clear}_bit_le().
> > 
> > Signed-off-by: Akinobu Mita <akinobu.mita <at>>
> > Cc: Joel Becker <jlbec <at>>
> > Cc: Mark Fasheh <mfasheh <at>>
> > Cc: ocfs2-devel <at>
> Looks reasonable to me...
> Signed-off-by: Mark Fasheh <mfasheh <at>>
> Joel?

	No argument here.  Akinobu, do you want me to send it with ocfs2
fixes, or are you going to push it along?

Acked-by: Joel Becker <jlbec <at>>




"Lately I've been talking in my sleep.
 Can't imagine what I'd have to say.
 Except my world will be right
 When love comes back my way."

(Continue reading)

Stephen Boyd | 1 Jun 01:10 2011

[PATCH] msm: timer: Fix SMP build error

Fix build breakage on SMP=y builds due to 0f7b332 (ARM:
consolidate SMP cross call implementation, 2011-04-03)

arch/arm/mach-msm/timer.c: In function 'local_timer_setup':
arch/arm/mach-msm/timer.c:295: error: implicit declaration of
function 'gic_enable_ppi'

Signed-off-by: Stephen Boyd <sboyd <at>>
 arch/arm/mach-msm/timer.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c
index 38b95e9..9bfdd5a 100644
--- a/arch/arm/mach-msm/timer.c
+++ b/arch/arm/mach-msm/timer.c
 <at>  <at>  -23,6 +23,8  <at>  <at> 
 #include <linux/io.h>

 #include <asm/mach/time.h>
+#include <asm/hardware/gic.h>
 #include <mach/msm_iomap.h>
 #include <mach/cpu.h>


Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

(Continue reading)

Christian Kujau | 1 Jun 01:50 2011

3.0-rc1: powerpc hangs at Kernel virtual memory layout


trying to boot 3.0-rc1 on powerpc32 only progresses until:

  > Kernel virtual memory layout:
  >   * 0xfffcf000..0xfffff000  : fixmap

And then the system hangs, does not respond to keyboard (sysrq does not 
seem to work on this PowerBook G4). But after a while the system reboots 
itself, so I guess the machine panicked but did not print anything on the 

Full messages (picture), config & (working) dmesg:

I'm currently trying to bisect this, so far I have:

git bisect start
# good: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
git bisect good 61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf
# bad: [55922c9d1b84b89cb946c777fddccb3247e7df2c] Linux 3.0-rc1
git bisect bad 55922c9d1b84b89cb946c777fddccb3247e7df2c
# bad: [c44dead70a841d90ddc01968012f323c33217c9e] Merge branch 'usb-next' 
of git://
git bisect bad c44dead70a841d90ddc01968012f323c33217c9e
# bad: [d93515611bbc70c2fe4db232e5feb448ed8e4cc9] macvlan: fix panic if 
lowerdev in a bond
git bisect bad d93515611bbc70c2fe4db232e5feb448ed8e4cc9
(Continue reading)

Akinobu Mita | 1 Jun 01:52 2011

Re: [PATCH] ocfs2: use proper little-endian bitops

>        No argument here.  Akinobu, do you want me to send it with ocfs2
> fixes, or are you going to push it along?
> Acked-by: Joel Becker <jlbec <at>>

Thanks. Please add it to ocfs2 tree.
Tejun Heo | 1 Jun 01:56 2011

[PATCH] block: blkdev_get() should acess ->bd_disk only after success

d4dc210f69 (block: don't block events on excl write for non-optical
devices) added dereferencing of bdev->bd_disk to test
GENHD_FL_BLOCK_EVENTS_ON_EXCL_WRITE; however, bdev->bd_disk can be
%NULL if open failed which can lead to an oops.

Test the flag after testing open was successful, not before.

Signed-off-by: Tejun Heo <tj <at>>
Reported-by: David Miller <davem <at>>
Tested-by: David Miller <davem <at>>
Cc: stable <at>
 fs/block_dev.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/block_dev.c b/fs/block_dev.c
index 1f2b199..1a2421f 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
 <at>  <at>  -1272,8 +1272,8  <at>  <at>  int blkdev_get(struct block_device *bdev, fmode_t mode, void *holder)
 		 * individual writeable reference is too fragile given the
 		 * way  <at> mode is used in blkdev_get/put().
-		if ((disk->flags & GENHD_FL_BLOCK_EVENTS_ON_EXCL_WRITE) &&
-		    !res && (mode & FMODE_WRITE) && !bdev->bd_write_holder) {
+		if (!res && (mode & FMODE_WRITE) && !bdev->bd_write_holder &&
+		    (disk->flags & GENHD_FL_BLOCK_EVENTS_ON_EXCL_WRITE)) {
 			bdev->bd_write_holder = true;
(Continue reading)

Maarten Lankhorst | 1 Jun 01:57 2011

Re: [PATCH] [RFC] usb: Do not attempt to reset the device while it is disabled

Op 01-06-11 00:35, Sarah Sharp schreef:
> On Tue, May 31, 2011 at 09:07:32PM +0200, Maarten Lankhorst wrote:
>> Op 31-05-11 20:18, Sarah Sharp schreef:
>>> On Tue, May 31, 2011 at 07:41:14PM +0200, Maarten Lankhorst wrote:
>> My xhci controller is this one:
>> 04:00.0 USB Controller: Device 1b6f:7023 (rev 01) (prog-if 30 [XHCI])
>> Subsystem: ASRock Incorporation Device 7023
> Ok, the PCI SIGG says that vendor ID is assigned to Etron.  Congrats,
> that's the first xHCI host controller I've seen from that company. :)
> Ok, so the xHCI driver does successfully get a slot from the host
> controller.
>> [  545.664041] xhci_hcd 0000:04:00.0: Allocating ring at ffff8801c7d7ccc0
>> [  545.664044] xhci_hcd 0000:04:00.0: Allocating priv segment structure at ffff8801e2e26c40
>> [  545.664047] xhci_hcd 0000:04:00.0: // Allocating segment at ffff8800bac3f800 (virtual)
0xbac3f800 (DMA)
>> [  545.664053] xhci_hcd 0000:04:00.0: Linking segment 0xbac3f800 to segment 0xbac3f800 (DMA)
>> [  545.664056] xhci_hcd 0000:04:00.0: Wrote link toggle flag to segment ffff8801e2e26c40 (virtual),
0xbac3f800 (DMA)
>> [  545.664059] xhci_hcd 0000:04:00.0: Set slot id 1 dcbaa entry ffff8800bac3e008 to 0xbac21000
>> [  545.664070] xhci_hcd 0000:04:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc90001ce0420, 32'h2f1, 4'hf);
> But I don't see an Address Device command complete here.  The command
> submission probably caused that memory write, but there really should be
> more debugging here.  I'll have to look through the hub initialization
> and see if there is any error path that would make it skip setting the
> device address.
> Have you tried on Linux 3.0-rc1?
Same problem with 3.0rc1 it seems. Just look at hub_port_init, that appears to be where it's going wrong:
(Continue reading)

Frederic Weisbecker | 1 Jun 02:00 2011

Re: [PATCH v2] trace: Add x86 irq vector entry/exit tracepoints

On Tue, May 31, 2011 at 02:28:18PM -0700, Vaibhav Nagarnaik wrote:
> From: Jiaying Zhang <jiayingz <at>>
> The current interrupt trace of irq_handler_entry and irq_handler_exit
> give traces of when an interrupt is handled. They provide good data
> about when the system is running in kernel space and how it affects the
> currently running applications.
> Apart from this, they are IRQ vectors which trigger the system into
> kernel space. Tracing such events gives us the trace of where the system
> is spending its time. We want to know which cores are handling
> interrupts and how they are affecting other processes in the system.
> Also, the trace provides information about when the cores are idle and
> which interrupts are changing that state.
> The following patch adds the event definition and trace instrumentation
> for interrupt vectors. For x86, a lookup table is provided to print out
> readable IRQ vector names. The template can be used to provide interrupt
> vector lookup tables on other architectures.
> With this patch, following interrupt vectors are logged by ftrace
> (when enabled):
> Interrupt as in /proc/interrupts        Name as it appears in ftrace log
> NMI: Non-maskable interrupts           : NMI_VECTOR
> LOC: Local timer interrupts            : LOCAL_TIMER_VECTOR
> SPU: Spurious interrupts               : SPURIOUS_APIC_VECTOR
> PMI: Performance monitoring interrupts : <not added>
> IWI: IRQ work interrupts               : IRQ_WORK_VECTOR
> RES: Rescheduling interrupts           : RESCHEDULE_VECTOR
(Continue reading)

Stephen Rothwell | 1 Jun 02:11 2011

Re: [Kgdb-bugreport] [PATCH] kgdbts: only use new asm-generic/ptrace.h api when needed

On Mon, 30 May 2011 12:28:17 -0400 Mike Frysinger <vapier <at>> wrote:
> i prefer to have as much outside of ifdefs as possible.  gcc optimizes
> the result away, so it isnt a code size problem.

Can we just get a patch sent to Linus, please?   His tree has now been
broken for powerpc and sparc32 for 5 days :-(

It would have been nice if the original patch had been in linux-next at
some point (especially given that I have a "kgdb" tree in linux-next).

/me just slightly annoyed.

Linus, the fix patch is below (I have applied it to linux-next today):

From:	Mike Frysinger <vapier <at>>
To:	kgdb-bugreport <at>,
	Jason Wessel <jason.wessel <at>>,
	Andrew Morton <akpm <at>>
Cc:	linux-kernel <at>, linux-next <at>
Subject: [PATCH] kgdbts: only use new asm-generic/ptrace.h api when needed
Date:	Sat, 28 May 2011 10:04:25 -0400

The new instruction_pointer_set helper is defined for people who have
converted to asm-generic/ptrace.h, so don't use it generally unless
the arch needs it (in which case it has been converted).  This should
fix building of kgdb tests for arches not yet converted.

Signed-off-by: Mike Frysinger <vapier <at>>
(Continue reading)

Brad Campbell | 1 Jun 02:18 2011

Re: KVM induced panic on 2.6.38[2367] & 2.6.39

On 01/06/11 06:31, Hugh Dickins wrote:
> Brad, my suspicion is that in each case the top 16 bits of RDX have been
> mysteriously corrupted from ffff to 0000, causing the general protection
> faults.  I don't understand what that has to do with KSM.

No, nor do I. The panic I reproduced with KSM off was in a completely 
unrelated code path. To be honest I would not be surprised if it turns 
out I have dodgy RAM, although it has passed multiple memtests and I've 
tried clocking it down. Just a gut feeling.

> But it's only a suspicion, because I can't make sense of the "Code:"
> lines in your traces, they have more than the expected 64 bytes, and
> only one of them has a ">" (with no"<") to mark faulting instruction.

Yeah, with hindsight I must have removed them when I re-formatted the 
code from the oops. Each byte was one line in the syslog so there was a 
lot of deleting to get it to a postable format.

> I did try compiling the 2.6.39 kernel from your config, but of course
> we have different compilers, so although I got close, it wasn't exact.
> Would you mind mailing me privately (it's about 73MB) the "objdump -trd"
> output for your original vmlinux (with KSM on)?  (Those -trd options are
> the ones I'm used to typing, I bet not they're not all relevant.)
> Of course, it's only a tiny fraction of that output that I need,
> might be better to cut it down to remove_rmap_item_from_tree and
> dup_fd and ksm_scan_thread, if you have the time to do so.

(Continue reading)