All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Bernhard Kaindl <bkaindl@ffii.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Andi Kleen <ak@suse.de>, Bernhard Kaindl <bk@suse.de>,
	linux-kernel@vger.kernel.org
Subject: Re: remote debugging via FireWire * __fast__ firedump!
Date: Tue, 04 Dec 2007 23:15:34 +0100	[thread overview]
Message-ID: <4755D186.20204@s5r6.in-berlin.de> (raw)
In-Reply-To: <alpine.DEB.0.9999.0712040426100.3769@vic.ffii.org>

Bernhard Kaindl wrote:
> 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.

The maximum payload size of block requests depends on three things:
1. speed of the connection between the two nodes (debugged machine and
debugging machine), 2. link layer controllers of the two nodes, 3.
software on the debugging machine.

1.) S100: 512 bytes, S200: 1024 bytes, S400: 2048 bytes, S800 and more:
4096 bytes.

2.) Controllers on CardBus cards are limited to 1024 bytes payload of
asynchronous packets, for reasons I don't know.  The other available
controllers only have the above mentioned speed-dependent limit.

3.) The ohci1394 driver has an implementation limitation which requires
that all packets including headers don't exceed PAGE_SIZE.  This does
not affect the packets which go through the physical response unit
(which they do on the debugged machine) but it affects the debugging
machine.

A quick note to this text from
http://www.suse.de/~bk/firewire/ohci1394_dma_early.diff :
> +	  As all changes to the FireWire bus such as enabling and disabling
> +	  devices cause a bus reset and thereby disable remote DMA for all
> +	  devices, be sure to have FireWire enabled on the debug host (and
> +	  the cable plugged) before booting the debug target for debugging.

Bus resets are also caused by bus managing software, which Linux' old
and new FireWire stacks and the stacks of all other FireWire capable
desktop OSs are to varying degrees.  I wonder if the following could
happen:  The two PCs are directly connected, only the PHY of the
debugging PC is active, then the PHY of the debugged PC is activated,
becomes root node, debugging PC examines the bus, then resets the bus to
force its own PHY to become root node in order to get a working
isochronous resource manager.  This bus reset would switch remote DMA on
the debugged PC off.
-- 
Stefan Richter
-=====-=-=== ==-- --=--
http://arcgraph.de/sr/

  parent reply	other threads:[~2007-12-04 22:15 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   ` remote debugging via FireWire * __fast__ firedump! Bernhard Kaindl
2007-12-04  7:39     ` Andi Kleen
2007-12-06 16:02       ` Bernhard Kaindl
2007-12-04 22:15     ` Stefan Richter [this message]
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

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=4755D186.20204@s5r6.in-berlin.de \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=ak@suse.de \
    --cc=benh@kernel.crashing.org \
    --cc=bk@suse.de \
    --cc=bkaindl@ffii.org \
    --cc=linux-kernel@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.