Acer 3400LMI User Manual
Size:
756.04 Kb
Download

F8­x86_64 on the Acer Ferrari 3400LMi

vmlinuz initrd=initrd.img libata.ignore_hpa=1

3 Hard drive

No hassle what so ever, but my own reflection is that the standard hard drive does not match the “high end gear” profile of this laptop. When the laptop was released 120 MB drives was the latest of the greatest and 100MB drives were off the shelf goods in most stores. However, a smaller drive would have been ok at a higher speed, at least 5400rpm.

3.1 Upgrading the drive

I am addicted to VMware and want extra of everything, size, speed, RAM, etc. Thus, I have replaced the original Hitachi Travelstar 80 GB (4200rpm) drive with a Seagate Momentus 160 GB (5400rpm, ATA/ATAPI­6, ST9160821A). What a difference! The higher speed, as well as the higher storage density, pays off in far better performance. Operating temperature is the same as for the original drive. According to the smartmontools it runs at 40­48 °C during normal load with peaks above 50 °C during heavy load. A highly recommended upgrade!

Depending on the hardware you might notice a strange disk size of your new drive. If you just plan to copy your existing installation to the new drive you need the following two lines in your /etc/modprobe.conf file:

alias scsi_hostadapter libata options libata ignore_hpa=1

If you plan on installing a fresh system on the new drive take a look in the

2 Installation section above. During the installation the proper entries are written to/etc/modprobe.conf.

4 IEEE 1394 Firewire

With FC5 and later there should not be any problems with the IEEE 1394 Firewire support. For me it works just as smooth as the USB support. If you are running kernel version 2.6.14 or later you may skip this section, unless you have specific interest in tweaking you Firewire settings.

A new alternative driver stack for Firewire support (a.k.a Juju) was introduced as experimental in kernel version 2.6.22. In Fedoras kernel configuration 2.6.23.9­85.fc8 the new IEEE1394 driver stack replaces the old drivers. The rest of this section deals with the old driver stack, i.e before Fedora kernel 2.6.23.9­85.fc8. For the most recent information please refer to http://www.linux1394.org.

However, on systems with kernel version 2.6.13 or earlier some might experience problems with the Firewire support due to different default values used in the kernel module. First a short description of the potential problems.

6

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 thesbp2 module with the argumentserialize_io=1. It turned out really well, so here are some tips regarding the IEEE 1394 configuration.

7

F8­x86_64 on the Acer Ferrari 3400LMi

4.2 Configuring Firewire

If you experience the problems mentioned above, and you are running kernel version 2.6.13 or earlier, put the following line in your /etc/modprobe.config:

options sbp2 serialize_io=1 max_speed=2

The serialize_io=1 option tells the scsi drivers to only send one scsi command at a time. Unfortunately, this setting has a small impact on performance, but it is the fix that makes things work.

In kernel version 2.6.14 the default value for serialize_io was changed from0 to1. Thus, if you are running kernel version 2.6.14 or later you should not need do do anything, unless you want to optimize performance (see comments below) or fiddle with the other settings.

The max_speed option might be useful in rare occasions if you want to limit the maximum transfer rate to support “even more buggy” external hardware. Valid values for themax_speed option are:

0 100 mb

1200 mb

2 400 mb (default)

3800 mb

When timing the very same read transfer as above I now get the following result:

# time cp ­rp /media/ieee1394disk/430MB_folder ~

real

0m24.871s

user

0m0.076s

sys

0m6.400s

That is what I call improvement! Going from over 20 minutes down to roughly 25 seconds.

4.3 Comments

After some further exercises with other external hard drives it turned out that the problem described in the previous section indeed seems to be related to the IEEE 1394 chip in the external drives. With some hardware it is quite possible to use the faster serialize_io=0 option. The performance benefit is in the range 20­25%, so consider your options. If you only use IEEE 1394 for your own hardware and it works well with the faster setting, go for it. Otherwise, compatibility with other hardware might be more valuable. Personally, I think it was a wise decision to change the default setting in thesbp2 module. After all those “buggy IEEE 1394 chips” seem to be quite common, and prior to start

8