linux-kernel - Re: ohci1396_dma=early nogo on an imac?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4A89722A.1070407@s5r6.in-berlin.de>
Date:	Mon, 17 Aug 2009 17:07:22 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	"Justin P. Mattock" <justinmattock@...il.com>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: ohci1396_dma=early nogo on an imac?

Justin P. Mattock wrote:
> Seems the macbook shows the init ohci1394_dma
> activating, but using this on an imac has no affects.
> is this device supported yet or is this still in the process of being
> developed?(event though the imac is 1394 800 port).
> 
> At the moment my machine boots up 2.6.30.4 but will not bootup
> the latest git. If the early dma option is possible with the imac9,1
> I can send out a post with the error, and see if somebody might know.
> (but if this isn't possible then Ill take the 40$
> for the cable and and spend it on beer)...

init_ohci1394_dma is supposed to work on all OHCI-1394 compliant
controllers.  This includes all FireWire controllers in all iMac models
ever made.  (However, init_ohci1394_dma's initialization is a
trimmed-down version of ohci1394's, and is much much less widely tested
than the ohci1394 driver, hence there may be things which work in the
latter but not quite in the former.  If so, it should be fixed.)

But note that there is an important limitation in init_ohci1394_dma:
After it opened the DMA filters, there must be no subsequent FireWire
bus reset.  When a bus reset happens, the controller immediately filters
everything again ( = disallows remote DMA).  To compensate for that,
init_ohci1394_dma would have to have an IRQ handler which handles bus
reset IRQ events.  (And the CPU must not lock up before you need it to
handle the IRQ.)

Causes for a bus reset are:
  - Something was plugged out or into the bus.
  - One of the nodes on the bus changed its configuration (e.g.
    a disk enclosure finished spinning up its drive mechanism after
    power-on).
  - One of the nodes on the bus (the one which volunteers to be the
    so-called isochronous resource manager or bus manager) resets
    the bus to enable or optimize some bus functions.
To avoid all this, its best if you only have a single other node (as
debugger console) plugged in, have it already powered on and running the
1394 driver stack at the moment when your test PC starts
init_ohci1394_dma, you use the old ieee1394 + ohci1394 + raw1394 drivers
on the debugger console, and set ieee1394's disable_irm=1 parameter
there (disable isochronous resource manager).  The new replacement
drivers firewire-core + firewire-ohci don't have such a parameter, i.e.
always run some bus manager functions which might get in the way of
remote DMA to an init_ohci1394_dma running node.
-- 
Stefan Richter
-=====-==--= =--- =---=
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/