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 >> >> >>>>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
