Back to main DC390 page
Linux DC390 driver:
This page should describe common problems with the DC390 driver and
give hints how to solve them.
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
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.
- 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.
- 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
You may instead use the
- 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
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
- 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.
- 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
- 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.
- 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++ )
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
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
* echo "RESET" >/proc/scsi/tmscsim/? may be necessary to
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.
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
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