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 >>> >>> >>> >>> >>>>ios scenario >>>> >>>>Any suggestions? >>>> >>>>Thanks >>>>Som >>>>--- Somnath kotur <[EMAIL PROTECTED]> wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Hi Juergen, >>>>> You might be spot on with your >>>>> >>>>> >>>>> >>>>> >>>analysis >>> >>> >>> >>> >>>>>which also seems to concur with my observation, >>>>> >>>>> >>>>> >>>>> >>>i >>> >>> >>> >>> >>>>>just >>>>>captured a detailed network trace using a good >>>>>hardware tool of the entire installation >>>>> >>>>> >>>>> >>>>> >>>process, >>> >>> >>> >>> >>>>>found that initially a LOT of I/O's are going >>>>> >>>>> >>>>> >>>>> >>>out >>> >>> >>> >>> >>>>>from >>>>>the initiator ,the iSCSI command sequence number >>>>>going >>>>>upto 21,000 and thereabouts and there is still >>>>> >>>>> >>>>> >>>>> >>>no >>> >>> >>> >>> >>>>>response from the target ,soon after which my >>>>>initiator seems to have sent a Task Management >>>>>Command >>>>>....the target seems to respond much later after >>>>> >>>>> >>>>> >>>>> >>>a >>> >>> >>> >>> >>>>>whole bunch of I/O's (mainly SCSI writes ) are >>>>> >>>>> >>>>> >>>>> >>>>sent >>>> >>>> >>>> >>>> >>>>>out by the initiator. >>>>> >>>>>I was wondering what more do i have to do in my >>>>> >>>>> >>>>> >>>>> >>>>HBA >>>> >>>> >>>> >>>> >>>>>driver to maintain concurrency, all commands >>>>> >>>>> >>>>> >>>>> >>>first >>> >>> >>> >>> >>>>>arrive at tran_tgt_init ,followed by >>>>> >>>>> >>>>> >>>>> >>>tran_init_pkt >>> >>> >>> >>> >>>>>,where i alloc scsi_pkt along with memory for my >>>>> >>>>> >>>>> >>>>> >>>>HBA >>>> >>>> >>>> >>>> >>>>>tran structure ... Do i have to internally queue >>>>> >>>>> >>>>> >>>>> >>>>the >>>> >>>> >>>> >>>> >>>>>scsi pkts arriving in tran_init_pkt? >>>>>Or is there some parameter ,like a 'queue depth' >>>>>that >>>>>i should register with Solaris for the same >>>>> >>>>> >>>>> >>>>> >>>while >>> >>> >>> >>> >>>>>registering my driver? >>>>> >>>>>Thanks >>>>>Som >>>>>--- Juergen Keil <[EMAIL PROTECTED]> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>I think the newfs/mkfs/"mkfs: close failed on >>>>>> >>>>>> >>>>>> >>>>>> >>>>>write >>>>> >>>>> >>>>> >>>>> >>>>>>disk: I/O error " >>>>>>error is more interesting than testing mkfile. >>>>>> >>>>>>newfs / mkfs -F ufs is using async io. Your >>>>>> >>>>>> >>>>>> >>>>>> >>>>iSCSI >>>> >>>> >>>> >>>> >>>>>>driver should be >>>>>>receiving new i/o requests, while the current >>>>>> >>>>>> >>>>>> >>>>>> >>>>i/o >>>> >>>> >>>> >>>> >>>>>>request is still busy. >>>>>> >>>>>>And the script that is constructing the >>>>>> >>>>>> >>>>>> >>>>>> >>>>>boot_archive >>>>> >>>>> >>>>> >>>>> >>>>>>is running >>>>>>two such scripts (shell functions) in >>>>>> >>>>>> >>>>>> >>>>>> >>>parallel, >>> >>> >>> >>> >>>>>one >>>>> >>>>> >>>>> >>>>> >>>>>>for constructing >>>>>>the 32-bit platform/i86pc/boot_archive file, >>>>>> >>>>>> >>>>>> >>>>>> >>>and >>> >>> >>> >>> >>>>>>another one for >>>>>>constructing the 64-bit >>>>>>platform/i86pc/amd64/boot_archive. So, in >>>>>>addition to using newfs on lofi devices, >>>>>> >>>>>> >>>>>> >>>>>> >>>>building >>>> >>>> >>>> >>>> >>>>>>two archives in >>>>>>parallel could also submit more that one >>>>>> >>>>>> >>>>>> >>>>>> >>>>>concurrent >>>>> >>>>> >>>>> >>>>> >>>>>>i/o request to >>>>>>the iSCSI device. >>>>>> >>>>>> >>>>>>Maybe this is causing data corruption in your >>>>>> >>>>>> >>>>>> >>>>>> >>>>>iSCSI >>>>> >>>>> >>>>> >>>>> >>>>>>driver? >>>>>> >>>>>> >>>>>> >>>>>>When you boot from your local IDE disk, mount >>>>>> >>>>>> >>>>>> >>>>>> >>>>the >>>> >>>> >>>> >>>> >>>>>>iSCSI volume >>>>>>containing the installed Solaris root >>>>>> >>>>>> >>>>>> >>>>>> >>>filesystem >>> >>> >>> >>> >>>>>to >>>>> >>>>> >>>>> >>>>> >>>>>>/mnt, and >>>>>>run "/mnt/boot/solaris/bin/create_ramdisk -R >>>>>> >>>>>> >>>>>> >>>>>> >>>>>/mnt". >>>>> >>>>> >>>>> >>>>> >>>>>>Does that >>>>>>produce two files >>>>>> >>>>>> >>>>>> >>>>>> >>>>/mnt/platform/i86pc/boot_archive >>>> >>>> >>>> >>>> >>>>>>and >>>>>>/mnt/platform/i86pc/amd64/boot_archive that >>>>>> >>>>>> >>>>>> >>>>>> >>>can >>> >>> >>> >>> >>>>>both >>>>> >>>>> >>>>> >>>>> >>>>>>be >>>>>>uncompressed with gunzip? >>>>>> >>>>>> >>>>>>Or another test: mount your iSCSI volume to >>>>>> >>>>>> >>>>>> >>>>>> >>>>/mnt, >>>> >>>> >>>> >>>> >>>>>>create two >>>>>>200mbyte files and compress them in parallel: >>>>>> >>>>>> mount ... /mnt >>>>>> dd if=/dev/urandom bs=1024k count=200 >>>>>>of=/mnt/file1 >>>>>> dd if=/dev/urandom bs=1024k count=200 >>>>>>of=/mnt/file2 >>>>>> >>>>>> gzip -v9 /mnt/file1 & gzip -v9 /mnt/file2 >>>>>> >>>>>> gunzip -t /mnt/file1.gz >>>>>> gunzip -t /mnt/file2.gz >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>=== 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 > > _______________________________________________ driver-discuss mailing list driver-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/driver-discuss
