home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / bsd / 3027 < prev    next >
Encoding:
Internet Message Format  |  1992-07-28  |  2.4 KB
  1. Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!usc!rpi!uwm.edu!ogicse!pdxgate!eecs!brians
  2. From: brians@eecs.cs.pdx.edu (Brian Smith)
  3. Newsgroups: comp.unix.bsd
  4. Subject: Re: SCSI tape drive not accessible
  5. Message-ID: <5939@pdxgate.UUCP>
  6. Date: 28 Jul 92 14:48:13 GMT
  7. References: <TMH.92Jul23041936@keks.first.gmd.de> <1992Jul23.080507.29145@news.uni-stuttgart.de>
  8. Sender: news@pdxgate.UUCP
  9. Distribution: comp
  10. Organization: Portland State University, Portland, OR
  11. Lines: 32
  12.  
  13. In article <1992Jul23.080507.29145@news.uni-stuttgart.de> zrgl0376@helpdesk.rus.uni-stuttgart.de (Cowboy aka Bjoern Lemke) writes:
  14. >In article <TMH.92Jul23041936@keks.first.gmd.de> tmh@keks.first.gmd.de (Thomas Hoberg) writes:
  15. >>I managed to get the "Tiny BSD" floppy accross the modem and got
  16. >>386BSD installed on my system (486/33, 16MB, ET4000/8514, AHA1542, 1GB
  17. >>Wren VII + 88MB Syquest SCSI drives, Tandberg TDC3800 QIC 525 SCSI
  18. >>Streamer). The SCSI disks are at targets 0+1, the tape drive is at
  19. >>target 4. On boot up, only the first disk is recognized. Trying to
  20. >
  21. >I run into a similar problem. I used a Fujitsu 2624 Harddisk with the same
  22. >Streamer (Tandberg). Setting the tape drive to target 4, resulted in 
  23. >nonrecognizing the streamer. (My harddisk is set to target 0). But after
  24. >setting the tape device to target 1, the scsi controller got it and
  25. >i was able to read and write from the device (/dev/ras1a) including some
  26. >scsi error messages (sense 0 0 0 0 .. and so on). I am not a scsi guru
  27. >and I don't know if this method is proper, but for the moment it works.
  28.  
  29. This is in the faq recently posted.  Apparently, the scsi driver in
  30. 386BSD only probes targets until it finds an empty spot.  So, if you had
  31. target 0, target 1 and target 4, then the driver would find target 0, then
  32. target 1, then look for target 2 (finding it empty/non-responsive), and
  33. conclude that no more devices were on the scsi bus.  The workaround is to
  34. make your scsi devices all contiguous and starting at 0.
  35.  
  36. Brian
  37.  
  38.  
  39. /---------------------------------------|------------------------------------\
  40. | #include <std/disclaim.h>             | Inet: brians@cs.pdx.edu            |
  41. | #include <human/erors.h>              | UUCP: tektronix!pdxgate!brians     |
  42. |---------------------------------------|------------------------------------|
  43. | Behold the warranty.. the bold print giveth and the fine print taketh away.|
  44. \----------------------------------------------------------------------------/
  45.