Hi Som,
Actually, your tran_bus_config() should allocate/online immediate
children as persistent node before you call
ndi_busos_bus_config(). In one world, you have to use
ndi_devi_alloc/ndi_devi_online to online all immediate children as well.
I believe your HBA is able to discover the specific target existence or
all attached targets by some vendor specific method.
Once HBA detect targets, you use ndi_devi_alloc() and ndi_devi_online()
to configure your devices.
Please refer to my below pseudo code:
myxx_tran_bus_config(dev_info_t *parent, uint_t flags,
ddi_bus_config_op_t op, void *arg, dev_info_t **childp)
{
int ret = DDI_FAILURE;
/*
* get the softstate of your initiator
*/
myxx_softstate = (myxx_softs *)ddi_get_soft_state(mpt_state,
ddi_get_instance(parent));
if (myxx_softstate == NULL) {
return (NDI_FAILURE);
}
ndi_devi_enter(parent, &circ1);
switch (op) {
case BUS_CONFIG_ONE:
/* parse target name out of name given */
if ((ptr = strchr((char *)arg, '@')) == NULL) {
ret = NDI_FAILURE;
break;
}
/*
* per the string to parse target and lun
*/
myxx_parse_target_lun(prt, &target, lun&)
ret = myxx_config_one(myxx_softstate, target,lun);
break;
case BUS_CONFIG_DRIVER:
case BUS_CONFIG_ALL:
myxx_config_all(myxx_softstate);
ret = DDI_SUCCESS;
break;
default:
break;
}
/*
* Only when above configure success, then invoke ndi_busop
*/
if (ret == NDI_SUCCESS) {
ret = ndi_busop_bus_config(parent, flags,
op, arg, childp, 0);
ndi_devi_exit(parent, circ1);
}
int myxx_config_one(myxx_softs *myxx, int target, int lun, dev_info_t
**childp) {
/*
* Check if the target+lun has already been in your internel list
* if exist, just set childp pointer and return success, if failed
go to next step
* to configure
*/
.....code for search internal list...
if (find the node from internal list) {
set childp
return (NDI_SUCCESS);
}
/*
* your discovery process to make sure the target is there
*/
....target discovery existence...
or just scsi_hba_probe() to probe the target,lun
if the target,lun exist we need configure the device
ndi_devi_alloc()
scsi_hba_nodename_compatible_get()
if (ndi_prop_update_int(DDI_DEV_T_NONE,
*lun_dip, TARGET_PROP, (int)target) !=
DDI_PROP_SUCCESS) {
ndi_rtn = NDI_FAILURE;
goto error_handle;
}
if (ndi_prop_update_int(DDI_DEV_T_NONE,
*lun_dip, LUN_PROP, lun) !=
DDI_PROP_SUCCESS) {
mpt_log(mpt, CE_WARN, "mpt driver unable to create "
"property for target %d lun %d (LUN_PROP)",
target, lun);
ndi_rtn = NDI_FAILURE;
goto error_handle;
}
ret = ndi_devi_online();
if (ret ==NDI_SUCCESS)
set the dip to childp;
return (ret);
}
void myxx_config_all() {
discovery all attached iSCSI targets
for (each target) {
issue REPORT_LUN to get LUNs
for (each lun) {
myxx_config_one();
}
}
Above is just a rough pseduo codes for configuration routine, hope it
can help you.
BTW, I am not sure if you handle device offline, I mean when a iscsi
target get gone, you can call ndi_devi_offline to offline the target
devices.
Javen
Somnath kotur wrote:
>Hi Javen,
> Yes that is right, atleast that is the only
>thing i could understand after looking at the src
>code,(esp the solaris iscsi initiator src) .So below
>is what i am doing in my tran_bus_config.
>
>myxx_tran_bus_config(dev_info_t *parent, uint_t flags,
> ddi_bus_config_op_t op, void *arg, dev_info_t
>**childp)
>{
> return ndi_busop_bus_config(parent, flags,
> op, arg, childp, 0);
>}
>
>I figured that the implementation of BUS_CONFIG_ONE
>and BUS_CONFIG_ALL was more relevant to it ,because of
>the way it names its target(iqn way), i just use a
>targetID
>
>
>On hotplug i do an ndi_devi_alloc ,update the
>target/lun props and online it
>
>
>In my tran_tgt_init() i do as below :
>
> if (ndi_dev_is_persistent_node(tgt_dip) == 0) {
>
> (void) ndi_merge_node(tgt_dip,
>scsi_name_child);
> ddi_set_name_addr(tgt_dip, NULL);
> return (DDI_FAILURE);
> }
>// Then my driver scans through its internal list of
>available targets looking for the same targetnumber
>input via the sd(struct scsi_device *) parameter and
>if found returns DDI_SUCCESS.
>
>
>So, pls let me know what i am doing wrong and if so
>,how to correct it.
>
>Thanks
>Som
>
>
>
>--- Javen Wu <[EMAIL PROTECTED]> wrote:
>
>
>
>>Hi Som,
>>
>> From you last email, I found another potential
>>problem which maybe
>>irrelevant to your panic.
>>My understanding about your last email is that you
>>use
>>ndi_busop_bus_configure() to enumerate the immediate
>>children, but for
>>the target added into the system after the system
>>boot, you use
>>ndi_devi_online(). In another words, You relies on
>>.conf files of target
>>drivers(sd.conf, st.conf...) to enumerate iSCSI
>>targets during boot, but
>>use ndi_devi_online handle hotplug. Is my
>>understanding correct? If my
>>understanding is correct, that could cause the
>>attributes of dip
>>nodes(dev_info_t) of your iSCSI targets in the
>>device tree are different.
>>You know, solaris has .conf node and persistent node
>>which are
>>different. Persistent node was allocated by
>>ndi_devi_alloc() and onlined
>>by ndi_devi_online(). But .conf nodes are different.
>>I guess according your implementation, the immediate
>>children are .conf
>>nodes, however, the iSCSI targets reported
>>asynchronizly are persistent
>>node which would cause endless problem.
>>Is it possible you show us how you implement
>>tran_bus_config()
>>BUS_CONFIG_ONE & BUS_CONFIG_ALL?
>>How you name your iSCSI target? iqn name or small
>>digital targetID?
>>How you load your driver? What's your driver class?
>>
>>--javen
>>
>>
>>Somnath kotur wrote:
>>
>>
>>
>>>Hi Javen,
>>> Well, this is consistently reproducible
>>>exactly 50% of the time, i.e * every other reboot
>>>
>>>
>>*
>>
>>
>>>... so im thinking that there must be some simple
>>>explanation to this ..like some setting ,prtconf
>>>output was OK ..im still looking on seeing the
>>>
>>>
>>output
>>
>>
>>>of tran_tgt_init and probe ..
>>>
>>>BTW i am indeed using ndi_devi_online when i want
>>>
>>>
>>to
>>
>>
>>>async report my targets online after an iscsi login
>>>
>>>
>>to
>>
>>
>>>a target
>>>
>>>Thanks
>>>Som
>>>
>>>--- Javen Wu <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>
>>>
>>>>Hi Som,
>>>>
>>>>I met the same panic stack during configuration
>>>>failure in my driver.
>>>>But I am not sure if your problem is exactly same
>>>>
>>>>
>>as
>>
>>
>>>>mine.
>>>>I am curious why it happens occasionally in your
>>>>case. But I think
>>>>that's a start point
>>>>to position/debug the problem. Is it possible the
>>>>configure routine
>>>>failed by some reason occasionally?
>>>>
>>>>I thought your implement dynamic enumeration by
>>>>calling ndi_devi_online
>>>>previously, but it seems your driver is not.
>>>>
>>>>Anyway, I guess before panic in mount root, your
>>>>tran_bus_configure
>>>>failed and return DDI_FAILURE.
>>>>You can verify my guess by watching the return
>>>>
>>>>
>>value
>>
>>
>>>>of your
>>>>tran_bus_configure by kmdb.
>>>>
>>>>If my above guess is correct. So after you invoke
>>>>ndi_busop_bus_configure(), please trace the return
>>>>value
>>>>of your tran_tgt_init() and tran_tgt_probe()
>>>>
>>>>
>>routine
>>
>>
>>>>and watch the
>>>>return value. Most likely your
>>>>tran_tgt_probe() failed occasionally due to some
>>>>werid situation in my
>>>>mind. If you didn't implement
>>>>tran_tgt_probe() routine by yourself, the SCSA
>>>>
>>>>
>>will
>>
>>
>>>>set scsi_hba_probe()
>>>>as default. So you can trace the return
>>>>value of scsi_hba_probe().
>>>>
>>>>If scsi_hba_probe failed as well. That means at
>>>>least *this time*, your
>>>>IO met some problem to send inquiry...So you can
>>>>
>>>>
>>do
>>
>>
>>>>deeper investigation.
>>>>
>>>>Cheers
>>>>Javen
>>>>
>>>>Somnath kotur wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>Javen,
>>>>> Thank you once again, but one thing i do
>>>>>
>>>>>
>>>>>
>>>>not
>>>>
>>>>
>>>>
>>>>>understand is if that is the case,then why does
>>>>>
>>>>>
>>it
>>
>>
>>>>>boot fine after the reboot ,i mean everytime
>>>>>
>>>>>
>>there
>>
>>
>>>>is
>>>>
>>>>
>>>>
>>>>>a panic ..the subsequent reboot that is initiated
>>>>>
>>>>>
>>>>>
>>>>by
>>>>
>>>>
>>>>
>>>>>it always leads to a succesful boot ..(reboot
>>>>>
>>>>>
>>from
>>
>>
>>>>>this stage again leads to a panic ..alternating)
>>>>>
>>>>>my tran_bus_config() implementation just calls
>>>>>ndi_busop_bus_config(parent, flags,op, arg,
>>>>>
>>>>>
>>childp,
>>
>>
>>>>0)
>>>>
>>>>
>>>>
>>>>>=> passing down the rest of the args as it is
>>>>>
>>>>>
>>>>>
>>>>..with
>>>>
>>>>
>>>>
>>>>>timeout of 0, you think that should be changed?
>>>>>
>>>>>Thanks
>>>>>som
>>>>>
>>>>>
>>>>>
>>>>>--- Javen Wu <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>During the boot phase, system would configure
>>>>>>
>>>>>>
>>root
>>
>>
>>>>>>device by
>>>>>>BUS_CONFIG_ONE with the argument root device
>>>>>>
>>>>>>
>>path.
>>
>>
>>>>>>I don't know how you implement your
>>>>>>tran_bus_config() routine, but you
>>>>>>can trace or debug your implementation of
>>>>>>tran_bus_config with
>>>>>>BUS_CONFIG_ONE by kmdb. I think the panic could
>>>>>>
>>>>>>
>>be
>>
>>
>>>>>>caused by
>>>>>>tran_bus_config failure during configuring root
>>>>>>device. Another way to
>>>>>>prove the point is I guess you invoked
>>>>>>ndi_devi_online() in your
>>>>>>tran_bus_config(), you can watch the return
>>>>>>
>>>>>>
>>value
>>
>>
>>>>of
>>>>
>>>>
>>>>
>>>>>>ndi_devi_online()
>>>>>>during boot by kmdb. I suppose you used x86
>>>>>>
>>>>>>
>>>>>>
>>>>system,
>>>>
>>>>
>>>>
>>>>>>%eax or %rax is the
>>>>>>return value after you jump out the function by
>>>>>>
>>>>>>
>>>>>>
>>>>":u"
>>>>
>>>>
>>>>
>>>>>>command in kmdb.
>>>>>>
>>>>>>Javen
>>>>>>
>>>>>>
>>>>>>Javen Wu wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>=== 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
