Bug 18292

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().