left arrow Back to main DC390 page

Linux DC390 driver:
Known problems

This page should describe common problems with the DC390 driver and give hints how to solve them.

General hints

Make sure your SCSI setup is sane. This means proper cabling: No T-like cabling, no longer than max. (3m for FastSCSI10, 1.5m for UltraSCSI20) length, proper termination. Active termination is required for UltraSCSI20 and highly recommended for FastSCSI10. Your connectors should be tightly fixed in their place. Also make sure, your devices have unique SCSI IDs and don't conflict with the initiator ID of the SCSI controller (usually 7).

It is a good idea to read README.tmscsim, included in the driver distribution. Look for it at /usr/src/linux/drivers/scsi/README.tmscsim.

Devices not recognized: Delay after reset

The SCSI2 spec. ist not very explicit about the time devices may need to be ready to reply to SCSI selections after a Bus Reset occured. The spec. suggests a normal Selection Timeout, which is 0.25s. A lot of devices don't comply to this. Some scanners and some CDRs (eg. Yamaha CRW4416 -- it seems to be fixed with the 1.0g firmware revision) are known not to answer to a "TEST UNIT READY" command for a much longer time (3s or similar).
Now the default delay after a bus reset for the tmscsim driver as of rev. 2.0d is 0.6s, which leads to some devices not being recognized.

If you suspect that this might be your problem, first try to find out whether it's true. You have to know the SCSI ID of the missing device and root privileges for this.

  1. Type cat /proc/scsi/scsi and you will get a list of recognized SCSI devices. Probably one of your devices is missing. You may also want to check the driver's internal device settings list by typeing cat /proc/scsi/tmscsim/H. The H should be replaced by the number Linux assigns to your tmscsim driven DC390/AM53C974 adapter. Most times it's just 0.
  2. Manually ask for the device being recognized again. You hvae to be root for this. Issue the command echo "scsi add-single-device C B T U" >/proc/scsi/scsi where C = Controller number (often 0), B = Bus channel (usually 0), T = Target SCSI ID of the device being searched for and U = Unit SCSI LUN of the device (usually 0).
    You may instead use the rescan-scsi-bus.sh script.
  3. Check whether this resulted in your device being recognized by repeating step 1. If your device is recognized now, it's very likely, that the problem really is the long recovery time of your device after a bus reset.

Let's assume, you identified the problem and the device can be manually recognized. Now, there are four possible solutions to your problem:

  1. Use the rescan-scsi-bus.sh script or manually use the scsi add-single-device command to detect your device, whenever needed. You max want to put something like (sleep 10; echo "scsi add-single-device C B T U" >/proc/scsi/scsi)& to your system startup scripts.
  2. Prevent the tmscsim driver from resetting the SCSI bus on startup. Look at README.tmscsim (it is included in the driver distribution and can be found inside the kernel source tree in linux/drivers/scsi/README.tmscsim.) [tmscsim=7,0,31,43]
  3. Upgrade your driver to 2.0d2 or later. Look at the main DC390 page and download the sources. Read README.tmscsim to learn how to change the delay after a bus reset. [tmscsim=7,0,31,63,4,5]
  4. Patch your driver (version 2.0d) manually: linux/drivers/scsi/tmscsim.c does have code like this on line 1835 (or similar): 
            for( i=0; i<600; i++ )
                udelay(1000);
    which causes 600ms delay. Replace the 600 by 3000 or whatever value necessary for your device. Note: There are two places in tmscsim.c containing code like the above.
Note: With solutions 3 or 4, you have to recompile (and reinstall) your kernel (or the kernel module), if you want your change to be effective.

Scanner problems

There some reports with scanners causing problems when scanning with SANE, but I didn't manage to solve these yet. More reports are welcome.

Basically, the scanner scans the image, but upon completion, there is a hang.

Here are some hints:
* Disable Sync nego for the scanner
* echo "INQUIRY i" >/proc/scsi/tmscsim/?(i = scanner idx) may help
* echo "RESET" >/proc/scsi/tmscsim/? may be necessary to recover.

Andreas Rick tracked this bug down to a Selection Timeout which resulted in the command being requeued again. As no further commands were sent to the scanner, this command was sitting in its queue forever.
In 2.0d18 the Selection Timeout is returned to the mid-layer and this seems to solve the problem.

JVC XR-W2010

A problem was reported, that this device is only recognized after a Wind*ws Boot and a Linux boot without SCSI bus reset [tmscsim=7,0,31,43]. Looks like a buggy SCAM implementation in the JVC firmware to me.

Dynamic driver changes to Multi-LUN devices

Right now (as of driver 2.0d10), each LUN has an own DCB with it's own settings for sync speed etc. This does not reflect the SCSI spec telling, that these settings are per target (SCSI ID). If you change these settings by echoing to /proc/scsi/tmscsim/?, you might get problems.
This will get fixed for 2.0f.

TEAC CD-ROM CD-532S Rev: 1.0A not recognized

I have currently a report about this device not being recognized with 2.0x drivers (and even not with 1.02r2), but with 1.11. Something to be debugged! If anybody has a similar device, please contact me.
(w) by KG, last change 17.01.'00