Bug 8017 - ohci1394: Isochronous receive doesn't work when packetsize is bigger than PAGE_SIZE (4KB)
Summary: ohci1394: Isochronous receive doesn't work when packetsize is bigger than PAG...
Alias: None
Product: Drivers
Classification: Unclassified
Component: IEEE1394 (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: drivers_ieee1394
Depends on:
Blocks: 10046
  Show dependency tree
Reported: 2007-02-15 08:21 UTC by Christian Steineck
Modified: 2008-12-13 03:19 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.20
Regression: ---
Bisected commit-id:


Description Christian Steineck 2007-02-15 08:21:53 UTC
Iso receiving doesn't work if packetsize is bigger then PAGE_SIZE (4KB in most
cases). This makes this driver incompatible to ieee1394b (firewire 800) because
it supports a maximum packet size of 8192Bytes. This is a problem which exists
in ohci1394 and probably other layers depending on it (proved with raw1394 which
doesn't do ieee1394b because of this bug).

Hope this could be fixed soon :o)


Comment 1 Natalie Protasevich 2007-07-04 17:17:18 UTC
Stefan, does it sound reasonable?
Comment 2 Stefan Richter 2007-07-05 02:02:21 UTC
Re Description:  The problem currently mostly affects applications on top of raw1394, perhaps also ones on top of video1394.  We have workarounds in sbp2 and eth1394 to avoid this ohci1394 implementation issue there.

Re Comment #1:  I am not aware of anybody looking into it.  We have three classes of contributors to the IEEE 1394 driver subsystem:  1. Kristian Høgsberg who is only working on the new firewire stack;  2. me who is chronically short of time and not intimately familiar with ohci1394's receive/transmit DMA programming;  3. occasional submitters who sporadically (very infrequently) come up with fixes on their own.

Kristian's new driver stack, initially conceived as alternative to the mainline ieee1394 stack, then submitted and now merged as mid or long term replacement of the old stack, does not have this PAGE_SIZE limitation.  If we get the new stack feature-complete reasonably soon and manage the transition of userspace libraries in a satisfying manner, this bug will be candidate for WILL_NOT_FIX.  (Unless we receive a fix from someone among those occasional submitters.)
Comment 3 Natalie Protasevich 2007-11-02 13:41:41 UTC
Does it make sence to ask Christian test what Kristian got so far (hopefully he's still around, I mean the reporter)? Is there a good pointer where Kristian's newest work is?
Comment 4 Stefan Richter 2007-11-02 14:50:49 UTC
By 'where', do you mean where to download (that's simple, Kristian's driver code is in mainline), or at level of usability?  The latter is somewhat explained at http://wiki.linux1394.org/JujuMigration and http://wiki.linux1394.org/ToDo .

Isochronous support in these drivers is not yet complete, but should work with 1394b/ FireWire-800 controllers.  Userspace integration of the new drivers is lagging though.  In particular, we need to merge Fedora patches into the upstream repo of the userspace libraw1394 and complete them feature-wise.  I may have time do set this into motion in late November, December.
Comment 5 Christian Steineck 2007-11-02 15:53:14 UTC
Yes i'm still around. I am watching the ieee 1394 mailing list and do follow the juju development process. Right now the isochronous parts of libraw are not complete but i'm willing to test it out when it becomes ready.

so far

Comment 6 Stefan Richter 2008-02-19 12:22:10 UTC
Update/ side note on support of bigger packets by the new alternative firewire drivers:  Someone reported in the meantime that the new stack is also buggy in this regard, at least when using isochronous reception via libdc1394 v2.
Comment 7 Stefan Richter 2008-12-13 03:19:21 UTC
It looks less and less realistic that this is going to be fixed.  Nevertheless, if anybody is interested to work on it, he can pull this out of bug 10046 again.

Note You need to log in before you can comment on or make changes to this bug.