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
