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:34:58 +0100	[thread overview]
Message-ID: <4755D612.1090103@s5r6.in-berlin.de> (raw)
In-Reply-To: <4755D186.20204@s5r6.in-berlin.de>

Stefan Richter wrote:
> 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.

PS:
If there are only 1394a nodes, you can read the connection speed from
the speed map registers on the debugging machine.  It becomes difficult
for 1394b nodes and some mixtures of 1394a and b nodes.  But consumer
1394b hardware is always S800 capable.  Consumer 1394a hardware is
always S400 capable.  Except consumer camcorders which are AFAIK
typically limited to S100, but they have only one port and will
therefore never sit between debugging and debugged PC.  So it's not as
difficult in 99.9% of the cases:  You can expect S400, some people might
get S800.  But you can't use the bigger S800 block size if the debugging
machine runs ohci1394.

> 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.

This is relevant if the debugging or the debugged PC have a CardBus
card.  Actually this is the limit of all 1394a CardBus card I have seen;
I don't know about 1394b CardBus cards, or Express cards.  (I suppose
Express cards have no limits of this kind, as they are just PCIe cards
in a different formfactor.)

This payload limitation of the link can be read from the bus info blocks
of the debugged and the debugging machine.  Though I am not entirely
sure right now if the ohci1394_earlyinit driven machine will have its
bus info block properly set up.
-- 
Stefan Richter
-=====-=-=== ==-- --=--
http://arcgraph.de/sr/

  reply	other threads:[~2007-12-04 22:35 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
2007-12-04 22:34       ` Stefan Richter [this message]
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=4755D612.1090103@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.