🚀 go-pugleaf

Kernel:		1.2.13 and 1.3.42
Controller:	ANY(?)
Device:		HP DAT drive (probably all models)


I recently experienced a bug which caused the SCSI portion of the Linux
kernel to fail to recognize the presence of my HP 34580A DAT tape drive
at boot-time.  This occured while using kernel version 1.2.13, but this
is a problem in the recent 1.3.42 kernel also.  (See below.)

I managed to figure out that the non-recognition problem with the HP
34580A drive was _only_ occuring in cases where I booted Linux at times
when I *did* have a tape physically loaded into the drive.  I was able
to get Linux to recognize the HP DAT drive (at boot time) *only* when
there was *no* tape actually in the drive.

(Note that this is exactly backwards to what it says in the SCSI HowTo!
It suggests that if you have a problem with a SCSI tape drive not being
recognized at boot-time, that you should put a tape *into* the drive!)

Anyway, I tracked this problem down to what appears to be a small bug
in the drivers/scsi/scsi.c file.  Given below is my suggested patch to
eliminate the problem:

*** scsi.c-	Thu Aug  3 14:55:34 1995
--- scsi.c	Sun Nov 19 13:01:20 1995
***************
*** 473,478 ****
  		 (status_byte(SCpnt->result) & CHECK_CONDITION)) &&
  		((SCpnt->sense_buffer[0] & 0x70) >> 4) == 7) {
- 	      if (SCpnt->sense_buffer[2] &0xe0)
- 		continue; /* No devices here... */
  	      if(((SCpnt->sense_buffer[2] & 0xf) != NOT_READY) &&
  		 ((SCpnt->sense_buffer[2] & 0xf) != UNIT_ATTENTION))
--- 473,476 ----

This patch simply removes two lines.

It seems that the problem was caused by two things... First, the HP 34580A
can sometimes (often?) signal ``EOM'' right after boot up.  This means
that it will yield sense bytes in which the third sense byte has its 0x40
bit set.  Second, unless I am mistaken, the two lines indicated in the
patch above are simply incorrect.  These two lines cause any SCSI device
which has any of the three highest-order bits set in sense_buffer[2] to
be essentially ignored at boot time.  But those are merely status bits
relating to the state of the media (i.e. at EOM or not) and to the status
and/or outcome of prior SCSI commands.

I can see no obvious reason why such a check should be either necessary
or even helpful... and indeed, in the case of the HP 34580A, this check
is highly counterproductive; making it impossible to use the drive (in
many cases) when it just happened to contain a tape at boot time.

Note that this same code is also present in drivers/scsi/scsi.c in the
recent 1.3.42 kernel sources, so this is an ongoing issue.

I look forward to the comments of the authors/maintainers of scsi.c.

-- 

-- Ron Guilmette, Roseville, CA -------- Infinite Monkeys & Co. ------------
---- E-mail: rfg@monkeys.com ----------- Purveyors of Compiler Test Suites -
----------------------------------------------------------------------------