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
>
>
>
>
> Som wrote:
>
> > Javen,
> > So i tried the steps ive written below, the
> > archive size was 97M ,so i typed
> > mkfile 97 m file1 ,the command worked just fine, i
> > captured the network trace throughtout this
> > operation,all i saw was lots of writes (64K each)
> ,and
> > each of them seemed to be completing sucesfully
> > (atleast from protocol point of view ,both iSCSI
> and
> > SCSI reporting good status)
> >
> > Any ideas,pls advise?
> >
> > Thanks
> > Som
> >
> >
> >
> > --- Somnath kotur <[EMAIL PROTECTED]> wrote:
> >
> > > Javen,
> > > So you actually think that the size of the
> > > archive is definitely incorrect?
> > >
> > > Here is what i am proposing to do ,let me know
> if
> > > i
> > > have understood you right ..
> > >
> > > - I will boot Solaris off my local IDE disk
> > > - Mount my iSCSI target disk on a volume say
> /mnt
> > > - Use my local disk's boot archive to
> uncompress
> > > and
> > > use as a lofi device?
> > > - Get the size of the lofi device and change
> > > directory to /mnt
> > > - mkfile $size (obtained in above step) <file1>
> > >
> > > My DMA logic is based on the one SCSI HBA driver
> > > that
> > > came with the opensolaris source ,which is the
> isp
> > > driver (esp the multiple cookies /DMA windows
> > > handling
> > > part) ... that is my reference ,should be OK ?
> > >
> > > BTW, i believe diskiomizer and vdbench are SUN
> > > internal tools (atleast what i saw on first
> glance)
> > > ,is there any way to obtain them on opensolaris
> ?
> > >
> > > Thanks
> > > Som
> > >
> > >
> > >
> > >
> > > --- Javen Wu <[EMAIL PROTECTED]> wrote:
> > >
> > > > Hi Som,
> > > >
> > > > The experiment I suggested is to prove that
> the
> > > > boot-archive has
> > > > already corrupt before you reboot the machine
> and
> > > > problem exists
> > > > in your write handler.
> > > >
> > > > IIRC, boot-archive use mkfile(1M) to create a
> file
> > > > and use the file
> > > > as a lofi device. Since the size of
> boot-archive
> > > is
> > > > not correct, I suspect
> > > > the command mkfile failed during create
> archive.
> > > >
> > > > You can uncompress a correct archive from CD
> and
> > > > check the size of the
> > > > lofi device before
> > > > compress. Then I think you can try mkfile(1M)
> > > > command like "mkfile $size
> > > > file1" on
> > > > your iscsi target device with your initiator
> > > driver
> > > > so that you can
> > > > simplify the
> > > > scenario and debug/trace the problem during
> write
> > > > operation.
> > > >
> > > > Is it possible you handle (DMA) incorrectly
> when
> > > the
> > > > buffer size is big
> > > > enough? IE. (multiple cookies or have to bind
> > > > partially and split window
> > > > to transfer).
> > > >
> > > > Generally, we don't use analyze function of
> format
> > > > to verify our driver.
> > > > We use diskomizer or vdbench which are really
> good
> > > > test utilities to test
> > > > a HBA driver.
> > > >
> > > > Cheers
> > > > Javen
> > > >
> > > >
> > > > Somnath kotur wrote:
> > > >
> > > > >Javen/Juergen,
> > > > > Thank you for the tip,yes i have tried
> the
> > > > same
> > > > >below ... mounted it on /a ,and checked the
> > > archive
> > > > by
> > > > >typing the command below:
> > > > >
> > > > ># gunzip < boot_archive >
> /tmp/bootarchive.img
> > > > >
> > > > >resulted in another error saying
> > > > >'gunzip:stdin: invalid compressed data -
> format
> > > > >violated'
> > > > >
> > > > >So it did not really help ,tho the size of
> the
>
=== 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
