Steve Chang wrote: > Another question related, > On item (3) - If everything is done through DMA allocation, > then do I need to process if buf flag is > B_PHYS or B_PAGEIO and how if necessary? >
ddi_dma_buf_bind_handle() should take care of all this for you, so you shouldn't have to worry about either of those flags. That is assuming that you don't need to access the buffer contents yourself from kernel software. I've not looked carefully at your results below, but maybe Javen will have some advice. It looks like the problem is that you are trying to access a target id 1 or 2, and getting a failure. What exactly are you returning back on tran_start()? -- Garrett > > During trace, tran_tgt_probe() return Ivalue is 0 > On SCSI Inquiry(0x12) command. Then it keeps one > more times and that's it and no more commands down > to the driver. The flow is following > > tran_tgt_probe()->scsi_hba_probe->tran_getcap->tran_init_pkt-> > tran_start-> .. cmd=12 tid=0/lun=0 -> return ok -> > pkt_complete() > tran_tgt_prob return 0 > > tran_tgt_probe()->scsi_hba_probe->tran_getcap->tran_init_pkt-> > tran_start->.. cmd=12 tid=0/lun=0 -> return ok -> > pkt_complete() > tran_tgt_prob return 0 > > tran_tgt_probe()->scsi_hba_probe->tran_getcap-> > tran_init_pkt-> > tran_start-> .. cmd=12 tid=1/lun=0 -> return fail -> > pkt_complete() > tran_tgt_prob return 4 > > tran_tgt_probe()->scsi_hba_probe->tran_getcap-> > tran_init_pkt-> > tran_start-> .. cmd=12 tid=2/lun=0 -> return fail -> > pkt_complete() > tran_tgt_prob return 4 > ..... > > What could be wrong and any advice? > > Thanks > Steve > > > -----Original Message----- > From: Javen Wu [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 12, 2008 7:34 PM > To: Javen Wu > Cc: Steve Chang; driver-discuss@opensolaris.org > Subject: Re: [driver-discuss] SCSI driver questions > > Correct one typo.... > > > >> Please see answer in line. >> >> >> >> >>> This SCSI HBA driver is for IOP based HBA. The driver will just pass >>> SCSI command to >>> >>> IOP and then get status back from interrupt when it is done. During >>> debugging I found >>> >>> Several issues >>> >>> (1) Will DDI_ATTACH get timeout? I found DDI_ATTACH keep coming when >>> my current DDI_ATTACH >>> >>> is still running initialization. How to prevent that? And if I have >>> multiple HBAs at the >>> >>> same time, what will be the behavior? >>> >>> >>> >>> >> If you have multiple HBA instance, the DDI_ATTACH will be called several >> times for each instance >> >> > If you have multiple HBA instances, the DDI_ATTACH will be called once > for each instances > during your add_drv. ;) > > >> . >> I am not sure if you have global resource shared by multiple instance, >> if you want to protect access >> global resource shared by multiple instance in your driver, you should >> use mutex or condition variable >> to protect and synchronize. As for why you saw multiple DDI_ATTACH >> arrive is because during solaris driver >> configuration devices use multiple threads asynchronized by calling >> > mt_xxxx. > >> >> >> >>> (2) During ddi_tran_tgt_init(), I saw a sequence of calling >>> target_id=0 .. 15 then again >>> >>> Target_id=0 ..15, then target_id=0..7 then target_id=0..7. Is it correct? >>> >>> >>> >>> >> That's correct. I guess you used "scsi" as your driver class. So the >> children enumeration would >> be relies on .conf file of target drivers. So what you saw is because >> solaris enumerate/configure >> children of your HBA according sd.conf, st.conf, sgen.conf, ses.conf. >> >> >> >> >>> (3) Since our IOP will handle all commands physically, the HBA just >>> programs DMA handle for >>> >>> every command. In ddi_tran_init_pkt(), HBA does >>> ddi_dma_alloc_handle(),and >>> >>> ddi_dma_buf_bind_handle() to get DMA physical address, dma size. Hence >>> in ddi_tran_start(), >>> >>> will fill in this dma_cookie pointer content to mailbox. Do I process >>> it correctly? >>> >>> >>> >>> >> You process correctly. >> >> >> >> >>> Later the command is done and return "good" status on SCSI Identify >>> command. But I keep >>> >>> seeing kernel send SCSI identify for this target again. This confuses >>> me and it seems the >>> >>> kernel is not receiving the data. >>> >>> >>> >>> >> Sorry, I have never heard SCSI Identify command, which command you are >> referring? >> INQUIRY(0x12), right? You can trace your tran_tgt_probe() routine and >> watch the return value. >> See if the value return successfully or not. Otherwise, some problem >> exist in your code. >> Anyway, let's see the your tran_tgt_probe return value for the specific >> target firstly. >> >> Javen >> _______________________________________________ >> 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 > _______________________________________________ driver-discuss mailing list driver-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/driver-discuss
