23 Jun, 2015

1 commit


29 May, 2014

1 commit

  • Undo a feature introduced in v3.14 by commit fcd46b34425d
    "firewire: Enable remote DMA above 4 GB". That change raised the
    minimum address at which protocol drivers and user programs can register
    for request reception from 0x0001'0000'0000 to 0x8000'0000'0000.
    It turned out that at least one vendor-specific protocol exists which
    uses lower addresses: https://bugzilla.kernel.org/show_bug.cgi?id=76921

    For the time being, revert most of commit fcd46b34425d so that affected
    protocols work like with kernel v3.13 and before. Just keep the valid
    documentation parts from the regressing commit, and the ability to
    identify controllers which could be programmed to accept >32 bit
    physical DMA addresses. The rest of fcd46b34425d should probably be
    brought back as an optional instead of default feature.

    Reported-by: Fabien Spindler
    Cc: # 3.14+
    Signed-off-by: Stefan Richter

    Stefan Richter
     

20 Jan, 2014

1 commit

  • This makes all of a machine's memory accessible to remote debugging via
    FireWire, using the physical response unit (i.e. RDMA) of OHCI-1394 link
    layer controllers.

    This requires actual support by the controller. The only ones currently
    known to support it are Agere/LSI FW643. Most if not all other OHCI-1394
    controllers do not implement the optional Physical Upper Bound register.
    With them, RDMA will continue to be limited to the lowermost 4 GB.

    firewire-ohci's startup message in the kernel log is augmented to tell
    whether the controller does expose more than 4 GB to RDMA.

    While OHCI-1394 allows for a maximum Physical Upper Bound of
    0xffff'0000'0000 (near 256 TB), this implementation sets it to
    0x8000'0000'0000 (128 TB) in order to avoid interference with applications
    that require interrupt-served asynchronous request reception at
    respectively low addresses.

    Note, this change does not switch remote DMA on. It only increases the
    range of remote access to all memory (instead of just 4 GB) whenever
    remote DMA was switched on by other means. The latter is achieved by
    setting firewire-ohci's remote_dma parameter, or if the physical DMA
    filter is opened through firewire-sbp2.

    Derived from patch "firewire: Enable physical DMA above 4GB" by
    Peter Hurley from March 27, 2013.

    Signed-off-by: Stefan Richter

    Stefan Richter
     

13 Jan, 2014

2 commits


03 Oct, 2009

1 commit

  • Update URLs of the userspace tools to use ohci1394_dma=early for
    debugging.

    Seems the address ftp://ftp.suse.de/private/bk/firewire/tools/* is not
    very helpful. After a quick search, seems this was talked about:
    http://www.mail-archive.com/kgdb-bugreport@lists.sourceforge.net/msg02761.html
    (can't find the original thread).

    Signed-off-by: Justin P. Mattock
    Signed-off-by: Stefan Richter

    Justin P. Mattock
     

18 Apr, 2008

1 commit


20 Feb, 2008

1 commit


30 Jan, 2008

1 commit

  • This patch adds a new configuration option, which adds support for a new
    early_param which gets checked in arch/x86/kernel/setup_{32,64}.c:setup_arch()
    to decide wether OHCI-1394 FireWire controllers should be initialized and
    enabled for physical DMA access to allow remote debugging of early problems
    like issues ACPI or other subsystems which are executed very early.

    If the config option is not enabled, no code is changed, and if the boot
    paramenter is not given, no new code is executed, and independent of that,
    all new code is freed after boot, so the config option can be even enabled
    in standard, non-debug kernels.

    With specialized tools, it is then possible to get debugging information
    from machines which have no serial ports (notebooks) such as the printk
    buffer contents, or any data which can be referenced from global pointers,
    if it is stored below the 4GB limit and even memory dumps of of the physical
    RAM region below the 4GB limit can be taken without any cooperation from the
    CPU of the host, so the machine can be crashed early, it does not matter.

    In the extreme, even kernel debuggers can be accessed in this way. I wrote
    a small kgdb module and an accompanying gdb stub for FireWire which allows
    to gdb to talk to kgdb using remote remory reads and writes over FireWire.

    An version of the gdb stub fore FireWire is able to read all global data
    from a system which is running a a normal kernel without any kernel debugger,
    without any interruption or support of the system's CPU. That way, e.g. the
    task struct and so on can be read and even manipulated when the physical DMA
    access is granted.

    A HOWTO is included in this patch, in Documentation/debugging-via-ohci1394.txt
    and I've put a copy online at
    ftp://ftp.suse.de/private/bk/firewire/docs/debugging-via-ohci1394.txt

    It also has links to all the tools which are available to make use of it
    another copy of it is online at:
    ftp://ftp.suse.de/private/bk/firewire/kernel/ohci1394_dma_early-v2.diff

    Signed-Off-By: Bernhard Kaindl
    Tested-By: Thomas Renninger
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Bernhard Kaindl