[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ccp4bb]: linux and firewire
BS"D
Due to the large number of requests, I will be sending the basic steps I
used to the BB as a general posting.
File is attached. Please tell me if something is not clear. But
again this is not intended as a step by step guide for novices to linux.
I hope this helps....
Harry
BS"D
Basic steps to using external firewire disks on Intel based laptop running
linux.
We used a Compaq Aramada E500 with RedHat 7.1.
1) If the laptop in question does not have a firewire port, you need to
purchase PCMCIA (CardBus) FireWire card. We got one from
www.firewiredirect.com
for $69 plus shipping (nearly as much as the card, for overseas orders!)
This card uses the OHCI chipset, and this is compatible with the kernel.
2) You also need to patch your kernel source and recompile the modules,
if it is 2.4.4 or lower, to get more updated source the ohci1394 and ieee1394
modules, and to get source for the sbp2 module. See
linux1394.sourceforge.net
Alternatively (what I did) is to go to RedHat
ftp.redhat.com/redhat/linux/rawhide/i386/RedHat/RPMS/
and get the compiled 2.4.6 kernel as rpm's
kernel-2.4.6-3.1.i686.rpm
mkinitrd-3.1.5-1.i386.rpm
kernel-pcmcia-cs-3.1.27-5.i386.rpm
e2fsprogs-1.22-3.i386.rpm
e2fsprogs-devel-1.22-3.i386.rpm
filesystem-2.1.3-1.i386.rpm
Note that I listed the i686 kernel, assuming you have PIII notebook.
You don't need the kernal source, which is more complicated, since it
requires all new compilers, etc., etc...
3) With all the new/patched kernel in place, you can just plug in the card
into the cardbus slot; the kernel will recognize it, and load the ieee1394 and
ohci1394 modules. You need to load the low level scsi module and the sbp2
(First, though plug the drive (powered up) into the firewire socket; then you
can load sbp2.)
insmod scsi_mod
insmod sbp2
The drive will be assigned a scsi id, and will likely be /dev/sda. Use fdisk
to format it, or Partition magic on Windows machine.
Then make a directory as a mount point, mount it and test it:
mkdir /data
mount /dev/sda1 /data
You can use linuxconf to mount the disk as well.
The disks are hot swappable, but sbp2 will not see the new disk except when
first loaded, so there is a script for this from
http://www.garloff.de/kurt/linux/rescan-scsi-bus.sh
I presume it is best to use umount before unplugging the disk.
**NOTE**
The disk my be plugged/unplugged without affecting the system, but unplugging
the cardbus *card* causes my system to hang.
The file /usr/src/linux-2.4.6-3.1/drivers/ieee1394/sbp2.c contains a lot of
information about this topic. Here is the header of that file:
*
* Brief Description:
*
* This driver implements the Serial Bus Protocol 2 (SBP-2) over IEEE-1394
* under Linux. The SBP-2 driver is implemented as an IEEE-1394 high-level
* driver. It also registers as a SCSI lower-level driver in order to accept
* SCSI commands for transport using SBP-2.
*
* Driver Loading:
*
* Currently, the SBP-2 driver is supported only as a module. Because the
* Linux SCSI stack is not Plug-N-Play aware, module load order is
* important. Assuming the SCSI core drivers are either built into the
* kernel or already loaded as modules, you should load the IEEE-1394 modules
* in the following order:
*
* ieee1394 (e.g. insmod ieee1394)
* ohci1394 (e.g. insmod ohci1394)
* sbp2 (e.g. insmod sbp2)
*
* The SBP-2 driver will attempt to discover any attached SBP-2 devices when first
* loaded, or after any IEEE-1394 bus reset (e.g. a hot-plug). It will then print
* out a debug message indicating if it was able to discover a SBP-2 device.
*
* Currently, the SBP-2 driver will catch any attached SBP-2 devices during the
* initial scsi bus scan (when the driver is first loaded). To add or remove
* SBP-2 devices after this initial scan (i.e. if you plug-in or un-plug a
* device after the SBP-2 driver is loaded), you must either use the scsi procfs
* add-single-device, remove-single-device, or a shell script such as
* rescan-scsi-bus.sh.
*
* The easiest way to add/detect new SBP-2 devices is to run the shell script
* rescan-scsi-bus.sh (or re-load the SBP-2 driver). This script may be
* found at:
* http://www.garloff.de/kurt/linux/rescan-scsi-bus.sh
*
* As an alternative, you may manually add/remove SBP-2 devices via the procfs with
* add-single-device <h> <b> <t> <l> or remove-single-device <h> <b> <t> <l>, where:
* <h> = host (starting at zero for first SCSI adapter)
* <b> = bus (normally zero)
* <t> = target (starting at zero for first SBP-2 device)
* <l> = lun (normally zero)
*
* e.g. To manually add/detect a new SBP-2 device
* echo "scsi add-single-device 0 0 0 0" > /proc/scsi/scsi
*
* e.g. To manually remove a SBP-2 device after it's been unplugged
* echo "scsi remove-single-device 0 0 0 0" > /proc/scsi/scsi
*
* e.g. To check to see which SBP-2/SCSI devices are currently registered
* cat /proc/scsi/scsi
*
* After scanning for new SCSI devices (above), you may access any attached
* SBP-2 storage devices as if they were SCSI devices (e.g. mount /dev/sda1,
* fdisk, mkfs, etc.).
*
*
* Module Load Options:
*
* The SBP-2 driver now has a number of module load parameters available for use
* in debugging/testing. Following are the valid parameters
*
* no_bus_scan - Skip the initial scsi bus scan during module load
* (1 = skip bus scan, 0 = perform bus scan, default = 0)
*
* mode_sense_hack - Emulate mode sense for devices like 1394 memory stick readers
* (1 = emulate/fake mode sense, 0 = do not emulate/fake mode sense, default = 0)
*
* max_speed - Force max speed allowed
* (0 = 100mb, 1 = 200mb, 2 = 400mb, default = auto configure)
*
* serialize_io - Force scsi stack to send down one command at a time, for debugging
* (1 = serialize all I/O, 0 = do not serialize I/O, default = 1)
*
* no_large_packets - Force scsi stack to limit max packet size sent down, for debugging
* (1 = limit max transfer size, 0 = do not limit max packet size, default = 0)
*
* (e.g. insmod sbp2 no_bus_scan=1)
*
*
* Current Support:
*
* The SBP-2 driver is still in an early state, but supports a variety of devices.
* I have read/written many gigabytes of data from/to SBP-2 drives, and have seen
* performance of more than 16 MBytes/s on individual drives (limit of the media
* transfer rate).
*
* Following are the devices that have been tested successfully:
*
* - Western Digital IEEE-1394 hard drives
* - Maxtor IEEE-1394 hard drives
* - VST (SmartDisk) IEEE-1394 hard drives and Zip drives (several flavors)
* - LaCie IEEE-1394 hard drives (several flavors)
* - QPS IEEE-1394 CD-RW/DVD drives and hard drives
* - BusLink IEEE-1394 hard drives
* - Iomega IEEE-1394 Zip/Jazz drives
* - ClubMac IEEE-1394 hard drives
* - FirePower IEEE-1394 hard drives
* - EzQuest IEEE-1394 hard drives and CD-RW drives
* - Castlewood/ADS IEEE-1394 ORB drives
* - Evergreen IEEE-1394 hard drives and CD-RW drives
* - Addonics IEEE-1394 CD-RW drives
* - Bellstor IEEE-1394 hard drives and CD-RW drives
* - APDrives IEEE-1394 hard drives
* - Fujitsu IEEE-1394 MO drives
* - Sony IEEE-1394 CD-RW drives
* - Epson IEEE-1394 scanner
* - ADS IEEE-1394 memory stick and compact flash readers
* (e.g. "insmod sbp2 mode_sense_hack=1" for mem stick and flash readers))
* - SBP-2 bridge-based devices (LSI, Oxford Semiconductor, Indigita bridges)
* - Various other standard IEEE-1394 hard drives and enclosures
*
*
* Performance Issues:
*
* - Make sure you are "not" running fat/fat32 on your attached SBP-2 drives. You'll
* get much better performance formatting the drive ext2 (but you will lose the
* ability to easily move the drive between Windows/Linux).
*
* - In ohci1394.h, remove the IEEE1394_USE_BOTTOM_HALVES #define, and rebuild.
* This will give you around 30% to 40% performance increase.
*
*
* Current Issues:
*
* - Currently, all I/O from the scsi stack is serialized by default, as there
* are some stress issues under investigation with deserialized I/O. To enable
* deserialized I/O for testing, do "insmod sbp2 serialize_io=0"
*
* - Hot-Plugging: Need to add procfs support and integration with linux
* hot-plug support (http://linux-hotplug.sourceforge.net) for auto-mounting
* of drives.
*
* - Error Handling: SCSI aborts and bus reset requests are handled somewhat
* but the code needs additional debugging.
*
* - IEEE-1394 Bus Management: There is currently little bus management
* in the core IEEE-1394 stack. Because of this, the SBP-2 driver handles
* detection of SBP-2 devices itself. This should be moved to the core
* stack.
*
* - The SBP-2 driver is currently only supported as a module. It would not take
* much work to allow it to be compiled into the kernel, but you'd have to
* add some init code to the kernel to support this... and modules are much
* more flexible anyway. ;-)
*
* - Workaround for PPC pismo firewire chipset (enable SBP2_PPC_PISMO_WORKAROUND
* define below).
*