DPT SCSI and HD activity LED

DPT SCSI and HD activity LED

Post by Matt Masu » Wed, 22 Nov 1995 04:00:00



Hiya.  I've just got Debian 0.93R6 installed, running kernel 1.2.13, on
my system.  I've got a DPT 2021/90 SCSI adapter, and I noticed that under
Linux the disk activity LED barely flickers, even when my drives are
getting hammered.  With MS-DOG the thing lights up good and bright during
any kind of access.  Anybody else notice this?  Not like it's a big deal
or anything, but I'm curious.

--
*  Matthew C. Masuda        * "That which does not kill us makes  *

 
 
 

DPT SCSI and HD activity LED

Post by Al Longye » Thu, 23 Nov 1995 04:00:00



>Hiya.  I've just got Debian 0.93R6 installed, running kernel 1.2.13, on
>my system.  I've got a DPT 2021/90 SCSI adapter, and I noticed that under
>Linux the disk activity LED barely flickers, even when my drives are
>getting hammered.  With MS-DOG the thing lights up good and bright during
>any kind of access.  Anybody else notice this?  Not like it's a big deal
>or anything, but I'm curious.

The reason is simple. Under MSDOS, one of the design goals for any
device driver is that it be as small as possible. Being small means
that you can't afford to do fancy things such as SCSI disconnects.

Linux tells the disk to disconnect from the bus when it does not have
data to transfer. This causes your light to go out. When the disk operation
has completed, the device asserts a condition known as "SCSI Re-connect"
and the host and disk begin to transfer the data.

The result is that the SCSI bus is free for use by other devices on the
bus. It permits things such as having a SCSI disk and SCSI tape drive on
the same controller and the same bus operate in a mode such that the SCSI
tape 'streams'. MSDOS could not achieve this because it does not permit the
device to disconnect from the bus.

There are some advantages of a 32 bit operating system. One such is that
you are not bound by trying to make things as small as possible because
you are stuck up against some stupid IBM limitation of 640 KB.

--

The above opinions do not necessarily represent those of the Management
of System Integrators nor any of its subsidiaries.

 
 
 

DPT SCSI and HD activity LED

Post by Michael Neuff » Fri, 24 Nov 1995 04:00:00


: Thanks to those who replied.  DPT tech support says 'the HD light is
: broken' and it will be fixed with a future firmware update.

That's plain rubbish, it definitely isn't broken that way.
While there is no activity on the SCSI bus, the light is off.
Since the DOS drivers do not allow the devices to disconnect
the LED is lit for much longer periods.

Mike

--------====### legal notice ###====-------------------------------------------
Microsoft Network is prohibited from redistributing this work in any form, in
whole or in part.  License to distribute this post is available to Microsoft
for $499.  Posting without permission constitutes an agreement to these terms.

 
 
 

DPT SCSI and HD activity LED

Post by Matt Masu » Fri, 24 Nov 1995 04:00:00


Thanks to those who replied.  DPT tech support says 'the HD light is
broken' and it will be fixed with a future firmware update.

--
*  Matthew C. Masuda        * "That which does not kill us makes  *

 
 
 

DPT SCSI and HD activity LED

Post by Matt Masu » Sat, 02 Dec 1995 04:00:00



: : Thanks to those who replied.  DPT tech support says 'the HD light is
: : broken' and it will be fixed with a future firmware update.

: That's plain rubbish, it definitely isn't broken that way.
: While there is no activity on the SCSI bus, the light is off.
: Since the DOS drivers do not allow the devices to disconnect
: the LED is lit for much longer periods.

The disconnect explanation does make sense to me, and if that's the case,
it makes me wonder how DPT is going to 'fix' it.

 - Matt

--
*  Matthew C. Masuda        * "That which does not kill us makes  *

 
 
 

DPT SCSI and HD activity LED

Post by Michael Neuff » Sun, 03 Dec 1995 04:00:00


: : That's plain rubbish, it definitely isn't broken that way.
: : While there is no activity on the SCSI bus, the light is off.
: : Since the DOS drivers do not allow the devices to disconnect
: : the LED is lit for much longer periods.

: The disconnect explanation does make sense to me, and if that's the case,
: it makes me wonder how DPT is going to 'fix' it.

What should they fix, if nothing's broken  ?

Mike

                                  ___  ()         /|/|
                                  \ /  ||     ^ / /  (
                                 __|__|__|__ _o..O    \   <-- Prehistoric
-------------------------------- \__________(_u___     |>     Gopher Server!
Michael Neuffer                       \``-'---WW     |  |>

                                             |::::::::|.,,|\/_/_/_/-/-' /
                                           __\ _______\     \         :
                                          /   /              )__-----'
----------------------------------------- "---"--------------'    -----------

 
 
 

DPT SCSI and HD activity LED

Post by Matt Masu » Fri, 08 Dec 1995 04:00:00



: : The disconnect explanation does make sense to me, and if that's the case,
: : it makes me wonder how DPT is going to 'fix' it.

: What should they fix, if nothing's broken  ?

Well, that's what I'd like to know.  Someone else forwarded me a message
from DPT tech support saying that they know about the 'problem' and
they're going to fix it in a later firmware release.

 - Matt

--
*  Matthew C. Masuda        * "That which does not kill us makes  *

 
 
 

1. DPT PM2021a SCSI with MAXTOR HD & TOSH CD

I have a DELL 466M (ISA) DX2-66 with 16Mb, one 540Mb IDE drive (c) and
one 540Mb SCSI drive (d). I have a DPT PM2021a controller connected
the the HD (id 1), a Toshiba XM5301b CDROM (id 3) and a HP Scanjet
IIIp (id 2).

I am trying to install Linus with the Slackware SCSI Kernel. When I
insert the Boot disk it decompresses the kernel, detects the SCSI card
and the IDE HD but fails to find any of the SCSI peripherals. I'm
afraid I don't know if there is a way to capture the messages as Linux
loads so I can't quote them verbatim (although others in this
Newsgroup seem to, so there must be a way...) The sytem then starts to
go through repeated loops of:

[ I rebooted several times and copied down what I could; I expect
anyone who can follow this will find a few copying errors for which I
appologise]
:
:
scsi aborting command due to timeout: pid:0,scsi:0, id:0, lun:0 0x0000
00 00 00 00 00
eata_abort called pid:0 target:0 lun:0 reason 3
returning: SCSI_ABORT_BUSY
scsi host 0 abort() timed out - resetting
eata_reset called pid:0 target:0 lun:0 reason 3
eata_reset locked slot XX forced free
eata_reset slot XX in reset, pid 0
eata_reset board reset done, enabling interrupts
eata_reset exit, success

:
:

Where XX is a slot number 0-63, each time round this sequence it is
incremented by one and then returns to the begining. The only way to
stop this is to hard reset.

Anyone any idea what is going on? What can I do to correct the
problem? I am new to Linux/UNIX and C. I can supply further
information about the system etc if it is of use but at the moment I
am not sure what my potential Saviour would need to know!

Many thanks,

David.

2. change hostname

3. Keyboard LED's for ethernet activity?

4. updatemanager - java exception

5. Tekram DC-390U2W activity LED

6. UDMA66 & Linux

7. Activity LED on the front of an E250

8. Swap space not being used..but root filling up

9. Making keyboard LED flash with net activity

10. NCR/Symbios '875 activity LED?

11. E250: envctrltwo0: Failed to blink activity LED

12. Problem with Wangtek SCSI Tape streamer with DPT SCSI controller.

13. 2.4: usb+scsi+X leads to scsi data corruption