From: Bernhard Kaindl <firstname.lastname@example.org>
To: Stefan Richter <email@example.com>,
Benjamin Herrenschmidt <firstname.lastname@example.org>
Cc: Andi Kleen <email@example.com>, Bernhard Kaindl <firstname.lastname@example.org>,
Subject: Re: remote debugging via FireWire * __fast__ firedump!
Date: Tue, 4 Dec 2007 04:45:22 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.email@example.com> (raw)
I just wanted to let you know that I'll have picked up the early
firewire patch again and cleaned it up very much so that it should
be ready to submit it and but it on the patch-submission road.
What's left to do is to write some HOWTO like Stefan describes
below, but I'll try to get that done soon.
I've also started working on the userspace tools and got firescope
to work across the 32/64-bit machines (both directions), there is
one hack (which I should do in a clean way insteat) in that patch
of which I do not know if that works in ppc/ppc64 but I could look
at it if needed or send the patch to Benjamin for adding support
for ppc64, to do it properly, we'll probably need an target architecture
option in firescope and as I do not know if it's needed by Benjamin,
I left out ppc64 for now.
I have just had the guts to explore __fast__ memory dumping over
firewire for full-system dumps (reading quadlets is __painfully__
show if you want to read 2GB of memory over the bus, you only get
about some some kilobytes each second) using raw1394_start_read()
to allow also block reads instead of just quatlet reads.
The biggest block size that worked here was 2048 bytes, which was
enough to get nearly 10MB/s of data transfer rate from the remote
memory to disk. Dumping 2GB of remote memory was just a matter of
about 3 few short minutes which quickly ran by.
Afterwards, the victim was dead (I excluded the low MB of memory,
so something else must have caused this), at least the start of
the dump looked well, but I haven't tested the error handling yet,
but I'll send you the tool (I called it firedump) soon.
On Sat, 10 Feb 2007, Stefan Richter wrote:
> Andi Kleen wrote at LKML:
>> Not likely to make .21:
>> - Early firewire support for firescope at early boot
> Was it seen in canonical patch format on a mailinglist before?
> Is it Bernhard Kaindl's ohci1394_early?
> Would be good to put this on the usual patch-submission road in order to
> prep it for 2.6.22. Could be handled via linux1394-2.6.git, although a
> different channel where the actual users of this facility watch would
> IMO be more appropriate.
> I also have suggestions, at least WRT Bernhard's code:
> - The Kconfig option could go into the "Kernel hacking" submenu rather
> than the IEEE 1394 submenu. (The driver source should stay in
> - Leave a note in the Kconfig help how it is typically used, i.e. what
> is required on the remote terminal side, where to find firescope,
> fireproxy etc. and assorted HOWTOs.
> - Indicate in the Kconfig help that only a 4GB address range is made
> visible this way.
> A mostly unrelated note: A simple to set up remote-dmesg utility would
> be nice to have on the terminal side. Maybe a small ieee1394 high-level
> driver which gives hints on the location of the dmesg buffer via
> configuration ROM would be warranted. Or is it feasible to find the
> dmesg buffer by plain memory analysis?
> Stefan Richter
> -=====-=-=== --=- -=-=-
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> mailing list firstname.lastname@example.org
next prev parent reply other threads:[~2007-12-04 4:25 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-10 11:42 What will be in the x86-64/x86 2.6.21 merge Andi Kleen
2007-02-10 13:43 ` [discuss] " Muli Ben-Yehuda
2007-02-10 13:52 ` Andi Kleen
2007-02-10 13:56 ` Muli Ben-Yehuda
2007-02-10 14:03 ` Andi Kleen
2007-02-10 13:51 ` remote debugging via FireWire (was What will be in the x86-64/x86 2.6.21 merge) Stefan Richter
2007-02-10 14:02 ` Andi Kleen
2007-02-10 15:14 ` remote debugging via FireWire Stefan Richter
2007-02-10 15:41 ` Andi Kleen
2007-02-10 19:16 ` Stefan Richter
2007-02-11 21:35 ` Benjamin Herrenschmidt
2007-02-12 6:49 ` Andi Kleen
2007-02-12 7:29 ` Benjamin Herrenschmidt
2007-12-04 3:45 ` Bernhard Kaindl [this message]
2007-12-04 7:39 ` remote debugging via FireWire * __fast__ firedump! Andi Kleen
2007-12-06 16:02 ` Bernhard Kaindl
2007-12-04 22:15 ` Stefan Richter
2007-12-04 22:34 ` Stefan Richter
2007-12-04 22:40 ` Stefan Richter
2007-12-06 18:36 ` [feedback discussion] Early boot debugging via FireWire (ohci1394_dma=early) Bernhard Kaindl
2007-12-06 19:23 ` Stefan Richter
2007-12-06 19:23 ` [PATCH] " Bernhard Kaindl
2007-12-06 20:23 ` Stefan Richter
2007-12-17 13:49 ` Ingo Molnar
2007-12-06 16:32 ` remote debugging via FireWire * __fast__ firedump! Bernhard Kaindl
2007-02-12 14:11 ` What will be in the x86-64/x86 2.6.21 merge James Morris
2007-02-12 14:14 ` Andi Kleen
2007-02-12 14:46 ` James Morris
2007-02-14 6:53 ` Rusty Russell
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.