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
