From: Martin Peschke <mpeschke@linux.vnet.ibm.com>
To: linux-btrace@vger.kernel.org
Subject: Re: bad trace magic
Date: Wed, 19 Nov 2008 17:41:30 +0000 [thread overview]
Message-ID: <1227116490.10046.79.camel@kitka.ibm.com> (raw)
In-Reply-To: <1227094718.10046.29.camel@kitka.ibm.com>
On Wed, 2008-11-19 at 16:07 +0100, Jens Axboe wrote:
> On Wed, Nov 19 2008, Martin Peschke wrote:
> > On Wed, 2008-11-19 at 13:44 +0100, Jens Axboe wrote:
> > > How are you running blktrace?
> >
> > blktrace -a issue -a drv_data -a complete -w 43200 -o
> > - /dev/sda ... /dev/sdz | blkiomon
>
> Ah ok. How hard is this to reproduce?
It's not too hard. I get several bad traces within about half an hour.
> If you could try a non-pipe approach, then it would be nice to see if
> it happens there as well.
I have tried this for about 90 minutes:
blktrace -a complete -a issue -a
drv_data /dev/sda /dev/sdae /dev/sdaj /dev/sdao /dev/sdat /dev/sday
/dev/sdbc /dev/sdbh /dev/sdbm /dev/sdbr /dev/sdbw /dev/sdca
/dev/sdg /dev/sdl /dev/sdq /dev/sdv /dev/sdaa
No bad traces. Need to check whether verify_trace() was called at all...
For this test I had to reduce the number of devices traced due to
the oom-killer picking on blktrace.
Or did you have something else in mind?
> So you don't happen to have a stream of data we can inspect _after_
> the bad magic occured?
I was trying with the command line above.
Would be blktrace in network mode worth another try?
I have just run the my initial test case on a recent linux git tree.
Same issue, bad traces:
--- bad trace magic ---
magic 0x00000000
sequence 0x00000000
time 0x65617407000014d5 <--- first trace magic
sector 0x656174070000a75c <--- another trace magic?!
bytes 0x0000011e
action 0x473dbce5
pid 0x00000000
device 0x0095b5e0
cpu 0x00004000
error 0x0181
pdu_len 0x0008
00000000 00000000 65617407 000014d5 65617407 0000a75c
0000011e 473dbce5 00000000 0095b5e0 00004000 01810008
bad trace in /sys/kernel/debug/block/sdaa/trace0
no previous trace
ts->buf 0x0x81fa0610, ts->len 0x958, ts->max_len 0x80000, offset 0x0, t
0x0x81fa0610
Then I ran blkrawverify /dev/sdaa - no issue found.
next prev parent reply other threads:[~2008-11-19 17:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-19 11:38 bad trace magic Martin Peschke
2008-11-19 11:49 ` Jens Axboe
2008-11-19 12:43 ` Martin Peschke
2008-11-19 12:44 ` Jens Axboe
2008-11-19 15:00 ` Martin Peschke
2008-11-19 15:07 ` Jens Axboe
2008-11-19 17:41 ` Martin Peschke [this message]
2008-11-26 9:33 ` Martin Peschke
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=1227116490.10046.79.camel@kitka.ibm.com \
--to=mpeschke@linux.vnet.ibm.com \
--cc=linux-btrace@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.