F8x86_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
