From: "Vegard Nossum" <vegard.nossum@gmail.com>
To: "Pekka Paalanen" <pq@iki.fi>
Cc: "Ingo Molnar" <mingo@elte.hu>,
linux-kernel@vger.kernel.org,
"Steven Rostedt" <srostedt@redhat.com>,
proski@gnu.org, "Pekka Enberg" <penberg@cs.helsinki.fi>
Subject: Re: mmiotrace broken in linux-next (8-bit writes only)
Date: Mon, 30 Jun 2008 23:41:55 +0200 [thread overview]
Message-ID: <19f34abd0806301441w52a9d9e7h42336e05e10f32a9@mail.gmail.com> (raw)
In-Reply-To: <20080630234837.118fff8c@daedalus.pq.iki.fi>
On Mon, Jun 30, 2008 at 10:48 PM, Pekka Paalanen <pq@iki.fi> wrote:
> On Mon, 30 Jun 2008 14:37:36 +0200
> Ingo Molnar <mingo@elte.hu> wrote:
>
>> it would also be nice if you could check whether ftrace as integrated
>> into linux-next has a functional mmiotrace. (and work with me in -tip on
>> fixing it if it doesnt)
>
> I tested it and it is broken in two ways. First is the NULL pointer
> dereference, for which I made a quick patch (in the end of this email)
> and I don't know what is going on in there. The patch allows me to run
> my simple test. However, the test shows, that all 8-bit MMIO writes are
> recorded with datum 0x80, which is incorrect. I've no idea what could
> have changed. All the 16 and 32-bit ops are ok, and so are 8-bit reads,
> which means the writes really do happen with the correct data, but just
> mmiotrace gets it wrong. Mmiotrace source files are unchanged.
>
> Has there been changes in compiler flags or iowrite8() that would cause
> different instructions to be used in implementing the MMIO write?
> I'm completely baffled.
>
> I guess I should try to bisect, but I don't know when I can do that.
> I tested on Athlon64, 64-bit UP kernel.
>
> Vegard, have you experienced any weird issues in instruction decoding?
> But I guess sort of bug would not affect you, since kmemcheck is not
> interested in the data.
No. But kmemcheck is not in -next yet either AFAIK :-)
I'll test the latest tip/master and see if I can try out mmiotrace as
well. But you are right, kmemcheck is not interested in the data.
(BTW, Ingo, Pekka E., I had an additional idea for kmemcheck: We can
record a checksum of bytes that are written and compare them with the
actual value when they are next read. If they differ, we are either
dealing with DMA memory or bad RAM. But this is long into the future..
:-))
Can you please post a few IPs that give you byte-writes with 0x80
value, then post the disassemblies of those IPs? Also, a chunk of the
log would be nice, just so we know what it looks like.
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
next prev parent reply other threads:[~2008-06-30 21:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20080628214626.5f9199d7@daedalus.pq.iki.fi>
[not found] ` <20080630123736.GA4011@elte.hu>
2008-06-30 20:48 ` Pekka Paalanen
2008-06-30 21:41 ` Vegard Nossum [this message]
2008-07-22 19:00 ` [PATCH] x86: fix mmiotrace 8-bit register decoding Pekka Paalanen
2008-07-26 15:55 ` Ingo Molnar
2008-07-01 8:15 ` mmiotrace broken in linux-next (8-bit writes only) Ingo Molnar
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=19f34abd0806301441w52a9d9e7h42336e05e10f32a9@mail.gmail.com \
--to=vegard.nossum@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=penberg@cs.helsinki.fi \
--cc=pq@iki.fi \
--cc=proski@gnu.org \
--cc=srostedt@redhat.com \
/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®