Hi Javen,
Sorry for the previous mail ,some keystroke
combination accidentally sent it out while i was in
between typing
I think the root cause for this problem
might be something else which is that even i do a
succesful login to a target and my ndi_devi_online for
the corresponding LUN behind the tgt succeeds ,the
prtconf output looks as below:
'pci<my vendorid>,<subsysid>,instance# 0
disk <some instance number>
sd, instance #1 (driver not attached)
st, instance #0 (driver not attached)
ses, instance #0 (driver not attached)
'
With this,when i run the 'format' utility i am able to
see the LUN ,similiarly when i do a logout ,the first
line in the prtconf output disappears
'pci<my vendorid>,<subsysid>,instance# 0
sd, instance #1 (no driver attached)
st, instance #1 (no driver attached)
ses, instance #0 (driver not attached)
'
So im not sure if this is right and how to get rid of
or merge the node that my driver creates through
ndi_devi_alloc (for the LUN) and the above 'sd' node
that i guess is being created via sd.conf entries
I remember you mentioning about ndi_merge_node but i
could not find much about the semantics of the API and
usage? None of the other SCSI HBA drivers including
solaris's own iscsi initiator seem to invoking that
call
Any ideas
Thanks
Som
--- Javen Wu <[EMAIL PROTECTED]> wrote:
> Hi Som,
>
> I can understand the word "attached" in your email
> in two ways.
> 1. "attached" means the *driver* attachs with the
> device.
> 2. "attached" means the device hook up with the
> iscsi initiator port.
>
> If you mean #1, I think the answer is "No" or
> "impossible" in my mind.
> If you mean #2, I think the answer is "Yes" and
> "possible" but need
> extra work.
>
> I assume you mean #2, let me explain how to reach
> your aim to unload your
> iscsi driver with the target hooked up with your
> initiator port.
>
> From driver side,
> ================
> you need implement tran_bus_unconfig() routine in
> your HBA driver.
> For BUS_UNCONFIG_ALL, you need call
> ndi_devi_offline() manually in
> your tran_bus_unconfig() for all attached target
> devices with
> NDI_DEVI_REMOVE argument.
>
> From user land,
> ==============
> you need a utility to trigger the
> tran_bus_unconfig(), there are
> two options,
> 1. implement cfgadm(1M) plugin for your HBA driver
> so that you
> can borrow "cfgadm -c unconfigure controller" to
> trigger bus
> unconfigure all.
> 2. implement another utility by yourself and call
> scsi standard
> ioctl() with cmd "DEVCTL_BUS_UNCONFIGURE". (please
> refer to
> scsi_hba_ioctl()).
>
> Maybe other guys have better idea, above is just
> what I thought.;)
>
> Hope it helps.
>
> Cheers
> Javen
>
>
> Somnath kotur wrote:
>
> >Hi Javen,
> > Thanks for the info. Well my iSCSI driver
> >requires that i be able to rem_drv my driver with
> >tgts/luns attached ,i.e im wondering if the
> framework
> >internally provides options for the HBA driver to
> >detach its luns, i think i did see a print
> indicating
> >that tran_lun_reset_notify was called when i did
> >attempt to do it..so thats what im intersted to
> know
> >..is there a sequence to the rem_drv if/when
> >LUNs/Targets are attached to the SCSI HBA driver so
> >that i get a chance to remove all the child
> instances
> >of the driver from the device tree?
> >
> >Thanks
> >Som
> >
> >--- Javen Wu <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Hi Som,
> >>
> >>There are two possible scenarios which you can
> >>unload your SCSI HBA
> >>driver without reboot.
> >>1. No any child of the HBA driver instance in the
> >>device tree.
> >>2. If you boot system is not from a SCSI disk and
> >>you can try to unload
> >>sd(7D) driver by "rem_drv sd" without any risk,
> you
> >>can unload your SCSI
> >>HBA driver by rem_drv(1M).
> >>
> >>Thanks
> >>Javen
> >>
> >>
> >>Garrett D'Amore wrote:
> >>
> >>
> >>>Somnath kotur wrote:
> >>>
> >>>
> >>>>Javen ,
> >>>> Is it actually possible to rem_drv my
> >>>>
> >>SCSI
> >>
> >>>>HBA driver ? I read this note below in one of
> the
> >>>>driver docs ,not sure if it is dated
> >>>>
> >>>>
> >>>>
>
>******************************************************
> >
> >>>>Removing the Driver
> >>>>
> >>>>To remove a driver from the system, use
> >>>>
> >>rem_drv(1M),
> >>
> >>>>then delete the driver module and configuration
> >>>>
> >>file
> >>
> >>>>from the module path. The driver cannot be used
> >>>>
> >>again
> >>
> >>>>until it is reinstalled with add_drv(1M).
> >>>>
> >>Removing a
> >>
> >>>>SCSI HBA driver will require a reboot to take
> >>>>
> >>effect.
> >>
> >>>>
>
>******************************************************
> >
> >>>>If its actually possible now, what are the
> entry
> >>>>points that it would hit and i would need to
> take
> >>>>
> >>care
> >>
> >>>>of in my SCSI HBA driver particularly if i have
> >>>>LUNs/targets attached?
> >>>>
> >>>>
> >>>
> >>>rem_drv works, but for SCSI drivers its actions
> >>>
> >>are not likely to take
> >>
> >>>effect until the next boot.
> >>>
> >>>The problem is that if you have any target nodes
> >>>
> >>still attached, then
> >>
> >>>the framework will refuse to detach your node.
> If
> >>>
> >>your bus is
> >>
> >>>hotpluggable, you could try hot-unplugging each
> of
> >>>
> >>the targets (making
> >>
> >>>sure that they are not in use first!), then the
> >>>
> >>framework will see
> >>
> >>>that you have no dependencies in the device tree
> >>>
> >>(providing your
> >>
> >>>driver actually does ndi_devi_offline for devices
> >>>
> >>that were hot removed).
> >>
> >>>In that case, your driver will see its detach(9e)
> >>>
> >>entry point called
> >>
> >>>with cmd == DDI_DETACH. I do not believe that
> >>>
> >>you'll see any other
> >>
> >>>entry points called during the rem_drv.
> >>>
> >>> -- Garrett
> >>>
> >>>
> >>>>Thanks Som
> >>>>
>
=== message truncated ===
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
