Reported by Freddie Witherden on August 2 2010: >>> I have been trying to speed up my forensics library, which currently gets around 13MiB/s when reading blocks of data and an effective rate of 100MiB/s when reading small 10 byte fragments from fixed page offsets. One thought was instead of making requests and waiting for a response I decided to make multiple requests (so always have several requests on the go) and using poll() to read responses back. The problem is that although the ioctl succeeds it is flakey, very flakey. My onboard FireWire controller results in GPFs from the kernel -- and on one occasion a hard out crash. My expresscard adapter, however, 'gives up' after a few 100 requests, with all subsequent requests giving no data read() gives me 24 bytes. The target is fine before and after. Now, the later result could be because of what's going on at the target, however the protection faults do concern me. Has anyone else experienced these kinds of faults and are there any known problems with having multiple requests on the go. <<< Some further information is in the replies to the initial post, http://thread.gmane.org/gmane.linux.kernel.firewire.user/3989 . E.g. http://article.gmane.org/gmane.linux.kernel.firewire.user/3993 and http://article.gmane.org/gmane.linux.kernel.firewire.user/3995 show a general protection fault in firewire-ohci's at_context_transmit() -> context_get_descriptors().
Candidate fixes by Clemens Ladisch: http://thread.gmane.org/gmane.linux.kernel.firewire.devel/14502
The patches from comment 1 work for me.
Fixes merged into mainline, to appear in 2.6.37-rc2, also submitted for inclusion into currently active stable series.