mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Vegard Nossum" <vegard.nossum@gmail.com>
To: "Jeremy Fitzhardinge" <jeremy@goop.org>
Cc: "Ingo Molnar" <mingo@elte.hu>,
	"Pekka Enberg" <penberg@cs.helsinki.fi>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kmemcheck: SMP support
Date: Fri, 23 May 2008 17:51:44 +0200	[thread overview]
Message-ID: <19f34abd0805230851w59a5972dk593900cf3ea8c14a@mail.gmail.com> (raw)
In-Reply-To: <4836E55C.5000304@goop.org>

On Fri, May 23, 2008 at 5:40 PM, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> Vegard Nossum wrote:
>>
>> This works on real hw, but not on qemu. It seems to get stuck waiting for
>> one
>> of the atomic values to change. Don't know why yet, it might just be yet
>> another bug in qemu... (we've hit at least two of them so far. And they
>> were
>> real bugs too.)
>>
>
> I've noticed that qemu mis-reports the eip of cmpxchg if it faults (it
> reports the eip of the start of the basic block, I think).  Does that match
> what you're seeing?

You mean the EIP that gets pushed on the stack for the page fault?
(That would be bad news for kmemcheck. I suppose the rest of the
kernel never page faults on cmpxchg addresses?)

Or do you mean the EIP that shows up in gdb?

But no, it seems to be unrelated. What I hit so far were (in 0.9.0):

1. qemu doesn't set the single-stepping flag of DR6 on single-step
debug exceptions.
2. qemu triggers int 0 (divide error) instead of int 2 on NMI IPIs.

But both of these were fixed in the latest 0.9.1.

I don't yet know if what I'm hitting now is really an error with qemu.
But I usually trust the real hardware more :-)


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036

  reply	other threads:[~2008-05-23 15:51 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-23 14:17 Vegard Nossum
2008-05-23 15:06 ` Ingo Molnar
2008-05-23 15:30   ` Vegard Nossum
2008-05-23 16:13     ` Jeremy Fitzhardinge
2008-05-26  9:11     ` Ingo Molnar
2008-05-26  9:29     ` Avi Kivity
2008-05-23 15:40 ` Jeremy Fitzhardinge
2008-05-23 15:51   ` Vegard Nossum [this message]
2008-05-23 17:12     ` Jan Kiszka
2008-05-23 17:32       ` Vegard Nossum
2008-05-23 17:54         ` Jan Kiszka
2008-05-23 20:54         ` Jeremy Fitzhardinge
2008-05-23 16:09 ` Johannes Weiner
2008-05-23 17:10   ` Vegard Nossum
     [not found] ` <19f34abd0805230719j1ce0e2eje6da7c1f963fdf75@mail.gmail.com>
2008-05-25 14:30   ` Fwd: " Pekka Paalanen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19f34abd0805230851w59a5972dk593900cf3ea8c14a@mail.gmail.com \
    --to=vegard.nossum@gmail.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=penberg@cs.helsinki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®