From stefanr is at s5r6.in-berlin.de Mon Nov 10 18:58:25 2003 Date: Mon, 10 Nov 2003 23:45:00 +0100 (CET) From: Stefan Richter <stefanr is at s5r6.in-berlin.de> To: feenberg is at nber.org Cc: linux1394-user is at lists.sourceforge.net Subject: Re: Large drive support On 10 Nov, Daniel Feenberg wrote: > I have posted more detail at > http://www.nber.org/sys-admin/granite-digital-linux.html . Below I quote from this web page. > Standard Linux distributions seem to include firewire support > as part of the SCSI subsystem, at least we found it in RH 9 and > Suse 8.2 even though no Firewire drives were present during the > OS installation. We believe any distribution based on the 2.4 > kernel is likely to include some support for IEEE1394 (Firewire) > drives. Some distributions began to enable FireWire in their precompiled kernels starting with kernel 2.4.18. Most distribitions started it with kernel 2.4.19. FireWire support does actually have little to do with SCSI support. One of the high-level (protocol) drivers of the Linux 1394 driver collection --- the sbp2 driver --- is at the same time a SCSI low-level driver. That is, SBP-2 compatible devices like FireWire disk drives, scanners, and so on, appear to the Linux user space as SCSI devices residing on a "host adapter" called sbp2. The IEEE 1394 bus itself is driven by the ieee1394 driver and one of the associated low-level drivers, ohci1394 or pcilynx. The sbp2 driver encapsules SCSI in SBP-2 and runs it over IEEE 1394. > Depending on how throughly the kernel has been patched, it is > likely that the drives will not be spontaneously "registered" > (made available at the hardware level). This was generally the > case with our Red Hat 9 installation, although very rarely the > drives would "take" - just often enough to be frustrating. When speaking about "registering" or "discover" SBP-2 devices we have to observe several layers. 1st, the IEEE 1394 mid- and low-level drivers have to be inserted into the running kernel, of course. 2nd, the device has to respond to a so-called ConfigROM query by the ieee1394 driver and has to answer with correct information about its type and features. (Many devices answer correctly only after a certain short period after they were powered up.) 3rd, the sbp2 driver has to be inserted when (or before) a SBP-2 device is added. 4th, the device must respond to and allow the login request of the sbp2 driver. 5th, the device has to be registered with the Linux SCSI subsystem. The 3rd step is automated on most 2.4.19+ based distributions using the "hotplug" facility. This facility is a combination of kernel capabilities and event-triggered user space helper programs. However this automation does not work as well (or actually not at all) during the boot procedure. The 5th step depends on the sbp2 driver revision. The sbp2 driver of older kernels up to some 2.4.21-pre version used to automatically register all devices it found immediately after the driver was loaded. (More correctly, it inserted itself into the SCSI subsystem in a way that all already discovered SBP-2 devices were "caught" by the regular initial SCSI bus scan.) Since kernel 2.4.21, this one condition of automated discovery by the SCSI subsystem is no longer possible. It is now required to trigger a SCSI re-scan regardless if a SBP-2 device was added before or after the sbp2 driver was loaded. A re-scan is also needed every time a SBP-2 device was removed, regardless of the sbp2 driver version. The SCSI subsystem of the original 2.4 kernel does not provide a possibility for the sbp2 driver to trigger a re-scan. It only provides a crude /proc interface for this task which is not guarded against certain race condition and therefore unsafe, actually. A patch for the 2.4 SCSI subsystem exists which introduces a hook for sbp2 and potentially for similar drivers to trigger the re-scan. This method is much more comfortable and even safer than the SCSI /proc interface. The patch was written by E. Andersen and can be found via www.linux1394.org. Kernel 2.6 is not restricted in this way. It does not need a trigger of the re-scan, neither via /proc nor via a patch. > [...] After umounting a drive, and removing it from the bay > issue the following command: rescan-scsi-bus.sh -r > > If you don't logically remove the drive this way, and the OS > doesn't handle this (RH9 appears not to), then the system will > hang the next time you insert a different drive. The system is already in danger when you issue any SCSI request to the removed device, which would not possible if you had run the "rescan-scsi-bus.sh -r" (or had a kernel with the patch mentioned above). > As far as I can tell, however, you can reinsert the same drive > with no adverse consequences. Yes, you can do without the two re-scans if you just unplug and re-plug the same device *and* you avoid any accesses to the SCSI device node in the meantime. If your drive is new, the following are easy commands to make it one big ext3 partition (assuming the hardware address is /dev/sda) sfdisk /dev/sda mkfs.ext3 /dev/sda1 mount /dev/sda1 /mnt > If you have any other SCSI devices, or devices using SCSI emulation > the drive won't be /dev/sda, so you need to be a bit careful before > doing this. The correct device node can be taken from /var/log/messages or one of the files in /proc/scsi/ (under kernel 2.4, don't ask me where it is located under kernel 2.6). > [...] Red Hat uses ohci 1.1 and SBP2 rev 709. Are you sure this is ohci1394 Rev 1.1? This would be very old, and the combination with the relatively much newer sbp2 Rev 709 looks creepy to me. > The updated Suse installation uses version SBP2 version 799). This is intermediate between the partially problematic sbp2 revision in kernel 2.4.20 and the rather good one in kernel 2.4.21 (sbp2 Rev 906). -- Stefan Richter -=====-=--== =-== -=-=- http://arcgraph.de/sr/