On Wed, Mar 05, 2008 at 12:23:55AM +0530, aakash berde wrote: > I tried to use the reference of below file but till not succeeded. > Meanwhile I did some research and found that there is no scsi controller is > present on system. > But there sd driver , scsi_vhci driver and ssd driver are available.
But scsi_vhci is only used when multipathing is active, which will never be the case when all devices are hanging off SATA controllers. So forget about scsi_vhci for now. ssd is for FC, so forget that too. All you have is the SATA framework and sd(7D). > With this data I have some queries. > 1. If there is no scsi HBA controller, what will be outout of uscsi command > after communicating with scsi driver. will it be ERROR: Bad Address No. EFAULT means you gave it a bogus pointer. If you try to do a USCSICMD ioctl on a file descriptor that does not represent a uscsi(7I)-capable device, you should expect to see EINVAL, ENOTTY, or perhaps ENXIO. > 2. Besides below directories is there any directory to look for scsi > devices? > # ls /devices/scsi_vhci/ ......No device > #ls /dev/cfg/ ... No device > # ls /dev/rmt/ ... No device > # ls /dev/rdsk/ > c0t7d0p0 c0t7d0p4 c0t7d0s11 c0t7d0s15 c0t7d0s5 c0t7d0s9 c1t0d0p3 > c1t0d0s10 c1t0d0s14 c1t0d0s4 c1t0d0s8 c0t7d0p1 c0t7d0s0 c0t7d0s12 > c0t7d0s2 c0t7d0s6 c1t0d0p0 c1t0d0p4 c1t0d0s11 c1t0d0s15 c1t0d0s5 > c1t0d0s9 c0t7d0p2 c0t7d0s1 c0t7d0s13 c0t7d0s3 c0t7d0s7 c1t0d0p1 > c1t0d0s0 c1t0d0s12 c1t0d0s2 c1t0d0s6 > c0t7d0p3 c0t7d0s10 c0t7d0s14 c0t7d0s4 c0t7d0s8 c1t0d0p2 c1t0d0s1 > c1t0d0s13 c1t0d0s3 c1t0d0s7 > when I give uscsi /dev/rdsk/c0t7d0s0 I get details of SATA hard > disk.Thatmeans any one scsi driver (sd/sgen/scsi_vhci) is working. Is > it right? It means that sd(7D) is attached and the SATA framework is working. That framework provides a limited SATL so that some SCSI commands are translated to ATA commands. You can look at usr/src/uts/common/io/sata/impl/sata.c to see what commands are supported and how the SATL works. Because sd(7D) also supports uscsi(7I), you can ioctl these devices with USCSICMD. However, you will succeed only if the SCSI command and the fields in that command are supported by the SATL. This is also true for SATA devices attached to SAS HBAs, though their SATLs tend to be more complete. The SAT specification (see http://www.t10.org/drafts.htm#SAT) describes this protocol. > 3. What is my thinking is that, if there is no scsi target in the above > directores then uscsi command will fail and give message ERROR: Bad Message. > Is it true? No. If there are no SCSI targets, what are you passing to open(2)? Please do not confuse finding the device node that refers to a target with passing SCSI commands to that target via an open file descriptor and uscsi(7I). They're two separate steps. In the absence of multipathing, libdevinfo(3LIB) should be usable to reliably find SCSI targets. Calling readdir() on some #defined list of paths is insane (though your application would be far from the first to do so). I'm really struggling to understand what you're trying to do. The basic outline should be (1) use libdevinfo or user input to select a SCSI target device node; (2) open(2) that node; (3) construct a SCSI CDB (and parameter block, if appropriate) supported by the SCSI target or SATL interposed on the SATA device; (4) construct the struct uscsicmd for your operation; (5) use ioctl(fd, USCSICMD, ...) to perform the SCSI operation; (6) examine the contents of the uscsicmd structure to perform error checking and observe sense data if applicable; (7) free memory and close(2) the file descriptor. Notice that opening the HBA node (/dev/cfg/cX) never appears anywhere in these steps. -- Keith M Wesolowski "Sir, we're surrounded!" Fishworks "Excellent; we can attack in any direction!" _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
