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
> >>path
> >>
> >>fffffffffbc44ab0 genunix:rootconf+0xea()
> >>fffffffffbc44ae0 genunix:vfs_mountroot+0x51()
> >>fffffffffbc44b20 genunix:main+0x86()
> >>0xfe800342(fe800000)
> >>kobj_init + 0x1c3(100ff88,..)
> >>
> >>
> >>
> >>skipping system dump - no dump device configured
> >>rebooting...
> >>
>
>>###################################################
> >>
> >>
> >>Thanks
> >>Som
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>--- Somnath kotur <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>
> >>
> >>
> >>>Hi Juergen/Javen,
> >>> Finally the issue got fixed last
> >>>night,iscsi boot is working !!!
> >>> The problem was that when the SCSA stack was
> >>>doing
> >>>a partial DMA and breaking a request into
> multiple
> >>>windows, my driver's pvt structure which has a
> field
> >>>called cdb_length was relying on the 'cmdlen'
> >>>parameter passed in tran_init_pkt() ,this
> parameter
> >>>happens to be set to '0' for all windows after
> the
> >>>first one. I am not sure if they expect us to
> pick
> >>>up
> >>>the cmdlen from the first window and use the same
> >>>for
> >>>the rest(which is how i worked around this) or is
> it
> >>>a
> >>>genuine bug ?
> >>>
> >>>I know that the opensolaris src code is different
> >>>from
> >>>the OS in the CD release, as the scsi_pkt
> structure
> >>>has changed and the cdb length is embedded in
> >>>it,hope
> >>>this behaviour is addressed in that?
> >>>
> >>>FINALLY having got it to work , i STILL see
> couple
> >>>of
> >>>issues though that havent gone
> >>>
> >>>the newfs/mkfs still gives the same error as
> before
> >>>.
> >>>and my install_log still gives errors as it was
> >>>giving
> >>>before on post installation...any ideas pls?
> >>>
> >>>I also see a strange behaviour in that when i
> >>>reboot,and just when grub is loading the
> kernel,the
> >>>system does a warm boot by itself and then the
> 2nd
> >>>time around the acutal OS is booted into ..????
> So
> >>>the
> >>>actual delta time b/n OS reboot and up time is
> >>>turning
> >>>out to be around 4-5 mins !!
> >>>
> >>>Thanks
> >>>Som
> >>>
> >>>
> >>>
> >>>
> >>>--- Somnath kotur <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>Hi Juergen,
> >>>> The 2nd expt went fine, the network
> >>>>
> >>>>
> >>>>
> >>>>
> >>>trace
> >>>
> >>>
> >>>
> >>>
> >>>>showed that the i/o's were not really in
> parallel
> >>>>(rather async)
> >>>>
> >>>>The first expt of creating the ramdisk
> definitely
> >>>>recreated the issue,(tho there was no amd64
> >>>>directory
> >>>>under i86pc)
> >>>>
> >>>>Saw some nearly 3200 commands being sent before
> >>>>initiator sent the task mgmt command to the
> target
> >>>>
> >>>>
> >>>>So definitely there is some problem with this
> >>>>
> >>>>
> >>>>
> >>>>
> >>>async
> >>>
> >>>
> >>>
>
=== message truncated ===
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
