Bug 8017

Summary:	ohci1394: Isochronous receive doesn't work when packetsize is bigger than PAGE_SIZE (4KB)
Product:	Drivers	Reporter:	Christian Steineck (memphis)
Component:	IEEE1394	Assignee:	drivers_ieee1394
Status:	REJECTED WILL_NOT_FIX
Severity:	normal	CC:	protasnb, stefanr
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.20	Subsystem:
Regression:	---	Bisected commit-id:
Bug Depends on:
Bug Blocks:	10046

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)

bye

Christian

Comment 1 Natalie Protasevich 2007-07-04 17:17:18 UTC

Stefan, does it sound reasonable?
Thanks.

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

christian

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.
http://sourceforge.net/mailarchive/forum.php?thread_name=47BAB860.1000606%40kbsg.rwth-aachen.de&forum_name=libdc1394-devel

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.