SCSI targets

Hi, I'm getting the following warning messsage from a Solaris 2.6 system. The equipment has 2 internal disks at target 0,2 and 5 external disks on 1,3,4,5 and 6.
WARNING: /sbus@1f,0/SUNW,fas@e,8800000 (fas0):
data transfer overrun: current fas state:
fas: Latched stat=0x90<IPND,XZERO> intr=0x10<BUS>
fas: last msgout: <unknown msg>, last msgin:IDENTIFY
fas: DMA csr=0xb2bf8810<TWOCYC,BRST1,BST0,DSB
LEDRN,WIDE,INTEN>
fas: addr=0 dmacnt=0 test=0 last=f0520000 last_cnt=800
fas: fas state:
fas: count(32)=0 cmd=1 stat=13 stat2=80 intr=0
fas: step=cc fifoflag=80 conf=17 test=13 conf2=90 conf3=c3
fas: Cmd dump for Target 0 Lun 0:
fas: cdb=[ 0xa 0x0 0x0 0x10 0x4 0x0 ]
fas: State=DATA Last State=DATA_DONE
fas: pkt_state=0xf<XFER,CMD,SEL,ARB> pkt_flags=0x4000 pkt_statistics=0x3
WARNING: /sbus@1f,0/SUNW,fas@e,8800000 (fas0):
Target 0 reducing sync. transfer rate
WARNING: /sbus@1f,0/SUNW,fas@e,8800000/sd@0,0 (sd0):
SCSI transport failed: reason 'data_ovr': retrying command
Eventhough the system works fine (apparently) I'm a little worried about this message... any idea?
thanks!!

Thanks
Is it supported to create a symbolic link in the /dev/rdsk t opoint to the devices under /devices? Anyways, the entries under /dev/rdsk are all symbolic links, so can I just create an entry with the same name on the two nodes to poing to the device?

Similar Messages

Scsi-target auto-poll

SANOS configuration guide mentions the command "show scsi-target auto-poll". It doesn't explain in detail what auto-poll is and how to activate it. It vaguely mentions that it has to do with "CSM or an IPS module is in the chassis". Can someone please clarify? Does this mean that the switch will attempt scsi-target on all IPS ports if it's inserted into the chassis? Because I thought the scsi target discovery can only be done on demand.
thanks

Whenever an IPS or CSM blade is in an MDS, the MDS will login to storage just the same as a real initiator would. We send Inquiry, Report Luns, and read capacity to learn about the storage out on the SAN. This process is done when the storage device comes online or when manually initiated. However, with auto-poll, we will go thru the discovery process every X number of seconds that can be configured.
This is not on the IPS ports but rather on any FC attached device that registers itself as a target. We use the pwwn seen as the result of show scsi-target internal driver. If the storage has any kind of LUN security, this pwwn will need to be permited or our discovery process will fail due to it being denied.

SCSI target driver won't attach

I am writing a SCSI target driver for a data acquisition system with Solaris 8 X86. When I try the add_drv command: add_drv ds21 I get the following errors:
devfsadm: driver failed to attach: ds21
Warning: Driver (ds21) successfully added to system but failed to attach
I probably need to include an alias with the add_drv command, but, I have used the prtconf -vp command to list the devices names however, none of the devices tied to the SCSI bus show up on the list. Any suggestions?

I think that you are missing entries in your driver.conf file for the devices that your driver is controlling. See the bst sample driver.
If you have just one scsi bus, it should take the form
name="ds21" class="scsi" target=t lun=0;
where t is the SCSI Target ID
If you have more than one scsi bus, it should take the form
name="sd21" parent="/sbus@1,f8000000/esp@0,8000" target=t lun=0;

WHY IS S.M.A.R.T STATUS SUPPORTED ON ATA BUS BUT NOT ON SCSI?

I have 4 internal HD's on a G4 733 S-Drive (Digital Audio) running X.4.4
and my question is:
Why is S.M.A.R.T STATUS supported on the ATA bus but not on the SCSI bus?
Is there something wrong with my computer if only 2 of the 4 internal HD's read "Verified" and the other two state "SMART STATUS NOT SUPPORTED"?
The only reason I noticed this is because I decided to clone my main HD running X.4.2 (supported) to a larger 7200 rpm HD connected to the SCSI. My Main HD is in position one on the ATA Bus. All four internal hard drives are currently running well although the SCSI bus was a bit slower upon startup only. So I updated the cloned HD to X.4.4 and then loaded iLife '06 to the cloned drive just to make sure all runs as expected. Which it did.
I ran apple's DU on all four internal HD's and all of them showed the green writing with No red lettering. But can someone please help me interpret the following from apple's DU on each HD which reads follows:
Disk Description : IBM-IC35L060AVER07-0 Total Capacity : 57.3 GB (61,492,838,400 Bytes)
Connection Bus : ATA Write Status : Read/Write
Connection Type : Internal S.M.A.R.T. Status : Verified
Connection ID : Device 0
Disk Description : WDC WD1200JB-00HUA0 Total Capacity : 111.8 GB (120,034,123,776 Bytes)
Connection Bus : ATA Write Status : Read/Write
Connection Type : Internal S.M.A.R.T. Status : Verified
Connection ID : Device 1
Disk Description : ATA WDC WD1200JB-00G Media Total Capacity : 111.8 GB (120,034,123,776 Bytes)
Connection Bus : SCSI Write Status : Read/Write
Connection Type : External S.M.A.R.T. Status : Not Supported
Connection ID : SCSI Target ID 0, Logical Unit 0
Disk Description : ATA Maxtor 6Y120P0 Media Total Capacity : 114.5 GB (122,942,324,736 Bytes)
Connection Bus : SCSI Write Status : Read/Write
Connection Type : External S.M.A.R.T. Status : Not Supported
Connection ID : SCSI Target ID 2, Logical Unit 0
Thanks in Advance.
SDMacuser

Hi, SD!
I haven't found anything specific on this, but I have always been under the impression that S.M.A.R.T. simply doesn't work with SCSI or externals. In my own experience, if I switch a drive from FW to my IDE bus, it reports. If I switch from the IDE bus to FW, the drive's S.M.A.R.T isn't supported.
Other than being unable to actually run and verify S.M.A.R.T. on your SCSI or external drives, I really don't think that you need be concerned with the "not supported" message, which simply is telling you that the particular drive or bus can't run S.M.A.R.T. (man! I hate typing all those "periods"...).
It also isn't supported on some old hard drives, even if they're connected to the IDE bus (like those 6-10 giggers I scrounge from ancient PCs that my friends and relatives junk when they finally switch and get new Macs...)
Regards,
Gary
1GH DP G4 Quicksilver 2002, 400MH B&W rev.2 G3, Mac SE30 Mac OS X (10.4.2) 5G iPod, Epson 2200 & R300 & LW Select 360 Printers, Epson 3200 Scanner
1GH DP G4 Quicksilver 2002, 400MH B&W rev.2 G3, Mac SE30 Mac OS X (10.4.2) 5G iPod, Epson 2200 & R300 & LW Select 360 Printers, Epson 3200 Scanner

Send a SCSI command to the device in attach ( )

I want to send an Inquiry Page and Read Buffer SCSI command to the device in attach( ). Can I do that? How to do that?
Thanks.

I assume you are talking about a SCSI Target driver, not an HBA driver.
Using scsi_probe() would be the normal way to send an inquiry. Once you have initialized everything in the attach routine, I don't think there is any reason you can't start a normal transfer. Have you looked at the sample drivers?
http://developers.sun.com/prodtech/solaris/driverdev/reference/codesamples/
Richard

Scsi device discovery in Cisco MDS switches

I was using this device discovery to find out how many luns can be seen on that server.
I tried to use discover scsi-target command and it does not give much useful information. and I do not want to add the OS WWNS on my LUN security in addition to HBA WWNS for the host group on the array end.
The problem that I am having is that I can see 7 LUNs out of 9 when I connect to Cisco MDS where as in brocade I can see all the LUNs.
I checked the LUN security and zoning and everything seems to be correct.
If Cisco SAN OS has commands where by I can see what LUNs can be seen on the switch, that would be really helpful. But It looks like LUN/LDEV info cannot be seen through discover command.
Please let me know how to troubleshoot this problem
Thanks

In the array, I tried to add switch wwn to the LUN Security and zoned the same switch wwn on the MDS. Is there anything I am missing. Thanks in advance
But still I could not see any LUNs. When I do discover command, NLUNS shows 0.
and the command sh scsi-target lun os win shows nothing.
discover scsi-target vsan 21 fcid 0xea000b os win
VSAN: 21 FCID: 0xea000b
PRLI RSP: 0x01 SPARM: 0x0012
SCSI TYPE: 31 NLUNS: 0
Vendor: HITACHI Model: DISK-SUBSYSTEM Rev: 5007
Other: 7f:00:03:12:cf:00:00:02

Trying to go into Target mode shuts down dual 800mhz G4

I have a Dual 800 G4 and am trying to set it up so I can use the Migration Assistant on my new MacPro. When I try and restart holding down 'T' the computer just abruptly shuts down. I'm wondering if this has something to do with the fact that I have a PCI scsi card installed in the G4, the details of the drives in the G4 are here:
SCSI Parallel Domain 65536:
Initiator Identifier: 7
ATA WDC WD800BB-40BS:
Capacity: 74.53 GB
Manufacturer: ATA
Model: WDC WD800BB-40BS
Revision: A0
Removable Media: Yes
BSD Name: disk1
OS9 Drivers: Yes
SCSI Target Identifier: 0
SCSI Logical Unit Identifier: 0
S.M.A.R.T. status: Not Supported
Volumes:
Mac Diddly:
Capacity: 74.53 GB
Available: 61.17 GB
Writable: Yes
File System: HFS+
BSD Name: disk1s6
Mount Point: /Volumes/Mac Diddly
ATA WDC WD800JB-00CR:
Capacity: 74.53 GB
Manufacturer: ATA
Model: WDC WD800JB-00CR
Revision: A1
Removable Media: Yes
BSD Name: disk0
OS9 Drivers: No
SCSI Target Identifier: 1
SCSI Logical Unit Identifier: 0
S.M.A.R.T. status: Not Supported
Volumes:
Macintosh HD:
Capacity: 74.53 GB
Available: 6.67 GB
Writable: Yes
File System: Journaled HFS+
BSD Name: disk0s2
Mount Point: /
Anyone have any ideas why my G4 won't enter Target mode? And if not, is there another way I can migrate all my user info to the new MacPro.
Thanks in advance...
Dual 800 G4 Mac OS X (10.4.9) PCI SCSI card, firewire drives, additional firewire 800 PCI card, additional PCI USB card

See this article for information.
(20727)

Can't use scsi scanner?

I have a Sharp JX-320 scanner. I've been using it on an older Mac, but I want to get rid of some clutter and use it on my Mac G4 OS X Tiger.
It shows up through System Profiler (see profile below). But when I try to scan, either through Photoshop's scanning plugin or through VueScan, the scanning utilities are unable to find the scanner. This happens whether I work in OS X (using Photoshop 7 or VueScan), or in Classic (Photoshop 6)
The scanner is plugged in to the scsi card, is the only thing on the chain, and is terminated. I can't really figure out what the scsi device number is, or how to change it, if that might be the problem.
What's going on? Is there any way to get the scanner to show up?
SCSI Parallel Domain 65536:
Initiator Identifier: 7
SHARP JX320 SCSI:
Manufacturer: SHARP
Model: JX320 SCSI
Revision: 071I
SCSI Target Identifier: 4
SCSI Logical Unit Identifier: 0

Well, I only tried downloading the VueScan utility since the Photoshop plugins aren't working. I couldn't find my scanner in their unsupported list, but I didn't really expect it to work. (I was testing for an OS X native scanning utility, but it's not worth paying the $50 to license the utility when I can get a USB scanner for about the same cost.)
Unfortunately, this computer won't boot in OS 9: I can only run OS 9.2.2 in Classic.
In PS 7 my plug-in doesn't work. It doesn't even show up. Which is about what I'd expect. But I can't find an OS X plug-in for PS 7.
In Classic, I've tried it both in PS 4 and PS 6. The utility opens as it always has on my OS 8.6 and OS 9.2.2 Macs. But when I try to scan, I get an error (GPIB Device "DEV7"not found).
Any idea why the scanner would show up in System Profiler, but not be found by the scanning utility?
Any idea if there's something that can be done to "fix" that?
Any idea where I could get an OS X plug-in for Photoshop 7 that might work with this scanner?
Thanks for any advice or help.

Relation between ssd and SCSI

When I use Fibre Channel disk via sd driver, I know what cntndnsn
means. But changed to ssd, the special files are
c1t200600004C7F3E2Dd19, where following 't' is not a normal target
number, but WWN of disk array. I guess ssd belongs to some kind of SCSI
disk driver. But how to get the SCSI target number of ssd disk through
programming?
Message was edited by:
Pukras

Thanks a lot., Darren.
I can understand 'Other drivers may fake a low 't' number'.
But problem is how to get the faked number. Like the following name='target'...
# prtconf -v
ssd, instance #45
System software properties:
name='sd_retry_on_reservation_conflict' type=int items=1
value=00000000
Driver properties:
name='pm-hardware-state' type=string items=1 dev=none
value='needs-suspend-resume'
name='ddi-failfast-supported' type=boolean dev=none
name='ddi-kernel-ioctl' type=boolean dev=none
Hardware properties:
name='devid' type=string items=1
value='id1,ssd@x00004c7f3e2d0270'
name='inquiry-revision-id' type=string items=1
value='2800'
name='inquiry-product-id' type=string items=1
value='iStorage 2000'
name='inquiry-vendor-id' type=string items=1
value='NEC'
name='inquiry-device-type' type=int items=1
value=00000000
name='sam-lun' type=int64 items=1
value=0016000000000000
name='lun' type=int items=1
value=00000016
name='target' type=int items=1
value=00b600dc
name='port-wwn' type=byte items=8
value=20.06.00.00.4c.7f.3e.2d
name='node-wwn' type=byte items=8
value=20.00.00.00.4c.7f.3e.2d
name='compatible' type=string items=5
value='scsiclass,00.vNEC.piStorage_2000.r2800' + 'scsiclass,00.vNEC.piStorage_2000' + 'scsa,00.bfcp' + 'scsiclass,00' + 'scsiclass'
Pukras

Scsi offline or reservation conflict errors afer swapping HBAs

We swapped out all of our EMC branded Emulex LP10000 HBAs and replaced them with the Sun branded Emulex LP11000 (SG-XPCI1FC-EM4-Z). We now receive a steady stream of SCSI errors in /var/ad/messages similar to the following:
Nov 8 13:37:29 fhtulsaps201 scsi: [ID 107833 kern.warning] WARNING: /ssm@0,0/pci@19,600000/SUNW,emlxs@1/fp@0,0/ssd@w50060482d52dd0b7,16 (ssd27):
Nov 8 13:37:29 fhtulsaps201 offline or reservation conflict
These devices are target devices from a remote server and are kept in sync using EMCs RecoverPoint appliances. They are normally in a read write disabled state. I do not have access to SRDF but expect I would get the same errors since SRDF also puts the target devices in the same read write disabled state.
As you can see the messages file fills up rather quickly and is basically unusable.
root@fhtulsaps201# wc -l /var/adm/messages
208634 /var/adm/messages
root@fhtulsaps201# ls -l /var/adm/messages*
-rw-r--r-- 1 root root 28340369 Nov 8 13:52 /var/adm/messages
-rw-r--r-- 1 root root 94960043 Nov 7 03:07 /var/adm/messages.0
-rw-r--r-- 1 root root 94643625 Oct 31 03:08 /var/adm/messages.1
-rw-r--r-- 1 root root 113367276 Oct 24 03:07 /var/adm/messages.2
-rw-r--r-- 1 root root 118930213 Oct 17 03:08 /var/adm/messages.3
root@fhtulsaps201#
As a part of the HBA upgrade we applied several kernel patches so at this point I'm not sure if the new HBAs are to blame or one of the patches.
The old HBAs never produced these errors.
I would like to know it there's a way to reduce the logging output from the scsi driver.
Thanks for any help.

We see the same error, though not nearly in such abundance, on our Clariion systems when they are using "explicit trespass" mode. In this mode the "passive" path is completely inaccessible until a special control message is sent to it. Veritas sends that special control message when the primary path has failed (EMC's PowerPath does the same thing).
I know EMC recommends this because you should never end up with I/O going to the wrong service processor accidentally (a trespass) because it simply won't service such I/O's unless explicitly told to do so (gee, I wonder where the name explicit trespass came from? :)
I'd guess your RecoverPoint devices behave similarly.
The relevant code appears to this this bit from http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/scsi/targets/sd.c#9589:
   9570           /*
   9571            * If the target is not yet ready here (defined by a TUR
   9572            * failure), invalidate the geometry and print an 'offline'
   9573            * message. This is a legacy message, as the state of the
   9574            * target is not actually changed to SD_STATE_OFFLINE.
   9575            *
   9576            * If the TUR fails for EACCES (Reservation Conflict),
   9577            * SD_RESERVED_BY_OTHERS will be returned to indicate
   9578            * reservation conflict. If the TUR fails for other
   9579            * reasons, SD_NOT_READY_VALID will be returned.
   9580            */I'm not a SCSI expert by any stretch of the imagination, but it seems to me that either Solaris is misinterpreting the "EACCES" error code or EMC is mis-using it. Could be that there's no good code in the SCSI protocol to say "Yea, I'm here, but I won't talk to you right now" except this one.
This exists in the "sd_ready_and_valid" function which appears to be called any time I/O is attempted to the device if the geometry of the device is not yet known (which it never will be for these standby devices).
So, in summary, if your system can "see" a SCSI LUN which responds to a Test Unit Ready (TUR) with "EACCES" then you're going to be seeing these messages. I think your only hope it to check your systems carefully and find out what process is trying to do I/O to them and fix that process.
Best of luck!

ISCSI-TARGET RPM

I need iscsi-target rpm for OEL 5.4 and OEL 5.2 32bit and 64bit for both version, can anyone tell me where to download it from ?

I suggest the following:
$ su - root
# cd /etc/yum.repos.d
# wget http://public-yum.oracle.com/public-yum-el5.repo
# yum install scsi-target-utils
# yum install iscsi-initiator-utils
For setup information, the following should do:
http://www.linuxjournal.com/content/creating-software-backed-iscsi-targets-red-hat-enterprise-linux-6

SCSI auto sense failure when SCSI tape drives are present

I've got a driver based on Sun's old SCSI Solaris 8 bst.c sample that worked fine up until the latest Solaris 10. Now I get a "Check condition with Auto Sensing" failure on all SCSI targets using this driver whenever a SCSI tape drive is present.
Is there a document that describes SCSI driver changes with the latest Solaris 10?

When a failure occurs pkt_r is 0 (command complete), pkt_state has flags 0x17 (which mean xfer didn't happen and STATE_ARQ_DONE didn't happen), but the sts_chk bit is true indicating a check condition.
rqsense option is set, so the driver doesn't attempt to manually retrieve sense data. Should it?
Anyone at Sun want to advise on an OS behavior change that might be linked to this?

7.1pre install on scsi/sata : impossible?

Before I add a bug report, I wanted to ask if someone could second that
- for scsi cdroms no nodes are created - like /dev/scd0 - so one can not load modules from the setup cdrom
- for sata cdroms no nodes are created - as the kernel is still unpatched to support sata-atapi
- you can't switch keyboard layout so native languaged people are somehow stuck trying to type "ls /dev/ | grep cd" or "ls /dev/scd*"
- autoprobe of network modules fails (maybe in follow of issue 1 and 2) at least for forcedeth and sklin98
- some fs are not supported without modprobing, like jfs, xfs

apeiro wrote:
Moo-Crumpus wrote:- for scsi cdroms no nodes are created - like /dev/scd0 - so one can not load modules from the setup cdrom
- for sata cdroms no nodes are created - as the kernel is still unpatched to support sata-atapi
Yea, this needs fixing. Maybe you can help me out? I'm a scsi idiot and only have archaic ide drives. What nodes/majors/minors do sata/scsi users need? The install environment uses a static /dev for 0.7.1, so I need to create these nodes manually.
Device Names
A device name can be thought of as a gateway to a kernel driver that controls a device rather than the device itself. Hence there can be multiple device names some of which may offer slightly different characteristics, all mapping to the same actual device.
The device names of the various SCSI devices are found within the /dev directory. Traditionally in Linux, SCSI devices have been identified by their major and minor device number rather than their SCSI bus addresses (e.g. SCSI target id and LUN). The device pseudo file system (devfs) moves away from the major and minor device number scheme and for the SCSI subsystem uses device names based on the SCSI bus addresses [discussed later in Section 3.3 and see reference: W5]. Alternatively, there is a utility called scsidev which addresses this issue within the scope of the Linux SCSI subsystem and thus does not have the same system wide impact as devfs. Scsidev is discussed later in Section 3.4 and ref: W6.
Eight block major numbers are reserved for SCSI disks: 8, 65, 66, 67, 68, 69, 70 and 71. Each major can accommodate 256 minor numbers which, in the case of SCSI disks, are subdivided as follows:
[b,8,0] /dev/sda
[b,8,1] /dev/sda1
[b,8,15] /dev/sda15
[b,8,16] /dev/sdb
[b,8,17] /dev/sdb1
[b,8,255] /dev/sdp15
The disk device names without a trailing digit refer to the whole disk (e.g. /dev/sda) while those with a trailing digit refer to one of the 15 allowable partitions [2] within that disk.
The remaining 7 SCSI disk block major numbers follow a similar pattern:
[b,65,0] /dev/sdq
[b,65,1] /dev/sdq1
[b,65,159] /dev/sdz15
[b,65,160] /dev/sdaa
[b,65,161] /dev/sdaa1
[b,65,255] /dev/sdaf15
[b,66,0] /dev/sdag
[b,66,1] /dev/sdag1
[b,66,255] /dev/sdav15
[b,71,255] /dev/sddx15
So there are 128 possible disks (i.e. /dev/sda to /dev/sddx) each having up to 15 partitions. By way of contrast, the IDE subsystem allows 20 disks (10 controllers each with 1 master and 1 slave) which can have up to 63 partitions each.
SCSI CD-ROM devices are allocated the block major number of 11. Traditionally sr has been the device name but scd probably is more recognizable and is favoured by several recent distributions. 256 SCSI CD-ROM devices are allowed:
[b,11,0] /dev/scd0 [or /dev/sr0]
[b,11,255] /dev/scd255 [or /dev/sr255]
SCSI tape devices are allocated the char major number of 9. Up to 32 tape devices are supported each of which can be accessed in one of four modes (0, 1, 2 and 3), with or without rewind. The devices are allocated as follows:
[c,9,0] /dev/st0 [tape 0, mode 0, rewind]
[c,9,1] /dev/st1 [tape 1, mode 0, rewind]
[c,9,31] /dev/st31 [tape 31, mode 0, rewind]
[c,9,32] /dev/st0l [tape 0, mode 1, rewind]
[c,9,63] /dev/st31l [tape 31, mode 1, rewind]
[c,9,64] /dev/st0m [tape 0, mode 2, rewind]
[c,9,96] /dev/st0a [tape 0, mode 3, rewind]
[c,9,127] /dev/st31a [tape 31, mode 3, rewind]
[c,9,128] /dev/nst0 [tape 0, mode 0, no rewind]
[c,9,160] /dev/nst0l [tape 0, mode 1, no rewind]
[c,9,192] /dev/nst0m [tape 0, mode 2, no rewind]
[c,9,224] /dev/nst0a [tape 0, mode 3, no rewind]
[c,9,255] /dev/nst31a [tape 31, mode 3, no rewind]
The SCSI generic (sg) devices are allocated the char major number of 21. There are 256 possible SCSI generic (sg) devices:
[c,21,0] /dev/sg0
[c,21,1] /dev/sg1
[c,21,255] /dev/sg255
Note that the SCSI generic device name's use of a trailing letter (e.g. /dev/sgc) is deprecated.
Each SCSI disk (but not each partition), each SCSI CD-ROM and each SCSI tape is mapped to an sg device. SCSI devices that don't fit into these three categories (e.g. scanners) also appear as sg devices.
Pseudo devices [see Section 10.1] can cause devices that are usually not considered as SCSI to appear as SCSI device names. For example an ATAPI CD-ROM may be picked up by the ide-scsi pseudo driver and mapped to /dev/scd0 .
The linux/Documentation/devices.txt file supplied within the kernel source is the definitive reference for Linux device names and their corresponding major and minor number allocations.
http://www.faqs.org/docs/Linux-HOWTO/SC … tml#dnames

Scsi probe 4times..why?

Hi,
My .conf looks like this.....
name = "mydriver" class="scsi"
target=0 lun=0
target=15 lun=0
/*added my stuff here*/
blocks_per_bit=16
bm_shift=10
....etc
why add_drv or drv_config is calling my probe routine 4times for 15 targets? totally, it is calling my probe routine 60 times.
can any one help me in this ?
thanks
kiran

I don't have any fibrechannel devices on my laptop. But have you tried fibreconfig(8)?
fibreconfig -- Tool for configuring settings for Fibre Channel controllers and targets.
-r Dynamically updates system settings. Note: Cannot be used in
conjunction with -c option.
Maybe this willl do what you want?
Andy

Cisco UCS M81KR as an FC Target?

Does anyone know if the UCS M81KR and be configured so that a virtual FC interface can run in Target Mode.
I am looking at the possability of creating a Storage Virtualisation Software Appliance from Blade Servers but I need FC Targets for the servers to offer storage out to other Blades...
Thanks

Padma,
We produce Storage Software that runs on WINTEL based Servers. In a nutshell our software
allows us to virtualize storage from a pool of backend disks. We have written Target mode Drivers for both QLogic and Emulex Fiber Channels HBAs.This allows the Server running our Storage Software to appear as a SCSI Target to SCSI Initiators.
More information at www.datacore.com.
Regards,
Hugh

SCSI targets

Similar Messages

Maybe you are looking for