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:
> >>
> >>
> >>
> >>>Hi Som,
> >>>
> >>>I have met similar problem before. The root cause
> >>>
> >>>
> >>of my problem is the
> >>
> >>
> >>>root disk not being configured correctly.
> >>>Are you sure your boot disk(iSCSI target) was
> >>>
> >>>
> >>enumerated by your iscsi
> >>
> >>
> >>>initiator driver correctly and attached already?
> >>>You can use -k option to boot your system and
> when
> >>>
> >>>
> >>panic happen, the
> >>
> >>
> >>>system will enter kmdb directly.
> >>>Then you can use ::prtconf to check whether the
> dip
> >>>
> >>>
> >>node of your iSCSI
> >>
> >>
> >>>target under your initiator instance was
> generated
> >>>
> >>>
> >>and attached correctly.
> >>
> >>
> >>>Cheers
> >>>Javen
> >>>
> >>>Somnath kotur wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>Hi Juergen,
> >>>> I have a strange issue with the iscsi
> >>>>boot,whenever i do a 'reboot' after the iSCSI
> LUN
> >>>>
> >>>>
> >>boot
> >>
> >>
> >>>>has come up ,upon reboot ,the kernel panics at
> the
> >>>>
> >>>>
> >>1st
> >>
> >>
> >>>>stage with dump as below: ... it then
> >>>>
> >>>>
> >>automatically
> >>
> >>
> >>>>reboots and on the 2nd time ,the OS comes up
> >>>>
> >>>>
> >>properly
> >>
> >>
> >>>>without the panic ,am wondering if there is some
> >>>>simple explanation to this,like making some
> entry
> >>>>
> >>>>
> >>in a
> >>
> >>
> >>>>system file ?
> >>>>
> >>>>
> >>>>
>
>>>######################################################
> >>>
> >>>
> >>>>panic[cpu0]/thread=fffffffffbc21d00: cannot
> mount
> >>>>
> >>>>
> >>root
> >>
>
=== message truncated ===
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
