Potential Problems - Acer Ferrari 3400LMi Manual

F8­x86_64 on the Acer Ferrari 3400LMi

4.1 Potential problems

There are no problems regarding loading modules or mounting an external IEEE
1394 drive, and if you are patient you managed to browse the content as well.
The problems starts when you try to transfer larger amounts of data. The process
stalls and chokes up the system log with messages like:
kernel: ieee1394: sbp2: aborting sbp2 command
kernel: scsi1 : destination target 0, lun 0
kernel: command: Write (10): 2a 00 02 e1 bc 58 00 00 10 00
kernel: ieee1394: sbp2: aborting sbp2 command
kernel: scsi1 : destination target 0, lun 0
kernel: command: Write (10): 2a 00 02 e1 bc 58 00 00 10 00
kernel: ieee1394: sbp2: aborting sbp2 command
kernel: scsi1 : destination target 0, lun 0
kernel: command: Test Unit Ready: 00 00 00 00 00 00
kernel: ieee1394: sbp2: reset requested
kernel: ieee1394: sbp2: Generating sbp2 fetch agent reset
redneck kernel: ieee1394: sbp2: aborting sbp2 command
kernel: scsi1 : destination target 0, lun 0
kernel: command: Write (10): 2a 00 01 06 d0 df 00 00 03 00
kernel: ieee1394: sbp2: aborting sbp2 command
kernel: scsi1 : destination target 0, lun 0
kernel: command: Write (10): 2a 00 01 06 d0 df 00 00 03 00
kernel: ieee1394: sbp2: aborting sbp2 command
kernel: scsi1 : destination target 0, lun 0
kernel: command: Write (10): 2a 00 02 e1 bd b0 00 00 20 00
Seems to me like a hole bunch of timeouts with corresponding bus resets. These
suspicions got even stronger after timing a read data transfer:
# time cp ­rp /media/ieee1394disk/430MB_folder ~
real 20m29.516s
user 0m0.052s
sys 0m6.476s
Copying 430 MB takes 20 minutes 29 seconds (comparable to USB 1.0
performance). However, the "actual" time is less than 7 seconds. 20 minutes and
22 seconds are spent waiting. Waiting for what? I do not know, but obviously
some bits and pieces fail during the transfer. Furthermore, I do not feel
comfortable with the data integrity when I see these kind of results.
After some digging in the kernel documentation and a quick look in the sbp2.c
source file it turned out that this problem probably is related to a "buggy IEEE
1394 chip" in the external device. The proposed solution is to load the sbp2
module with the argument serialize_io=1. It turned out really well, so here are
some tips regarding the IEEE 1394 configuration.
7