aab@cichlid.com (Andy Burgess) (11/18/90)
I have been trying to get a Sparc 1 running SunOS 4.1 to recognize an Adaptec ACB-5500 (SCSI to ST-506 disk controller). Thanks to some helpful email I have had some success. The ACB-5500 identifies itself as a ACB-4000 which SunOS apparently supports. (There are entries in /etc/format.dat for an ACB-4000) So far so good. I have addressed the ACB-5500 as target 2 and was able to format and make filesystems on a Seagate 4051 (40Mb) and on a Seagate 4096 (80Mb). However I still have two problems: PROBLEM 1: I cannot get SunOS to recognize both of the seagate drives at the same time. I mean that I can access either disk when it is at lun 0 but cannot get format or mount to recognize the other disk at lun 1. I have modified the kernel config file to say: disk sd2 at scsibus0 target 2 lun 0 # third hard SCSI disk disk sd7 at scsibus0 target 2 lun 1 # aab, second drive on ACB-5500 (The sd2 line was already there, I added sd7) which gives boot messages: sd2 at esp0 target 2 lun 0 sd2: <Seagate 4096 cyl 1020 alt 4 hd 9 sec 17> sd7 at esp0 target 2 lun 1 sd7: <Seagate 4051 cyl 970 alt 2 hd 5 sec 17> But format refuses to accept sd7: # format -d sd7 Searching for disks...done Unable to find specified disk 'sd7'. I have tried mknod'ing [r]sd7[a-h] in /dev with every logical permutation of the major and minor device numbers of sd2 in an attempt to specify lun 1 to no avail. No doubt I missed the correct ones or there is another problem as well. I have searched the online manual pages and scanned through the *.h and *.c files in /sys/scsi without success. Please excuse me if this is in the hardcopy manuals but my manuals are 1-1/2 hours away. Does anyone know how to make SunOS use an lun other than 0 as a disk? PROBLEM 2: When I copy files to the ST-506 drive in an attempt to test it I occasionally get the following console message: Nov 16 14:09:49 guppy vmunix: sd2: undecoded sense information Nov 16 14:09:49 guppy vmunix: 0x91 0x1 0x21 0xd0 Assuming a fatal error The values of the four hex bytes will change, some examples: 0x91 0x1 0x21 0xd0 0x91 0x0 0x4f 0xde 0x91 0x0 0x4f 0x89 0x20 0x0 0x0 0x0 0x24 0x0 0x0 0x0 This causes the copy to complain about an I/O error and fail. This happens only with the 4051 which was always a bit 'flaky' anyway. Although I added the manufacturers defect list to the drive with format there may be others defects that have cropped up over the years that I did not specify. The drive did pass verification after formatting. The ACB-5500 manual talks about an unusual defect mapping scheme where bad sectors are mapped out to spare sectors on the same track but I don't know if the format command enabled this scheme or not. Perhaps the controller is telling the OS about this defect mapping and because it is non-standard (I presume) the OS is getting confused??? Does anyone know what is going on and what to do about it? Thank you Andy PS If you post a response would you please email me as well? I always read these groups but the newsfeed will fail occasionally. I'll post a summary of course. -- Andy Burgess Independent Consultant aab@cichlid.com uunet!silma!cichlid!aab