Re: [PATCH] ibmvscsi driver - fourth version

[James Bottomley <James.Bottomley@steeleye.com>]

On Thu, 2004-03-11 at 16:25, Dave Boutcher wrote:
> On 11 Mar 2004 12:43:57 -0500, James Bottomley 
> <James.Bottomley@steeleye.com> wrote:
> > dma_map_single() has no error return currently, what is this trying to
> > do?
> Well, actually in in arch/ppc64/pci_iommu.c it can return 0xFFFFFFFF 
> (actually, it returns NO_TCE, which is ((dma_addr_t)-1)).

Well, OK, put a fixme in there, since eventually there will be a
standard for dma_map_single errors, and it may not be -1.

> 
> > +
> > +	/* Block requests until we get the SRP login back */
> > +	scsi_block_requests(host);
> > +
> > +	if (!scsi_add_host(hostdata->host, hostdata->dev)) {
> > +
> > +		scsi_scan_host(host);
> > +		return hostdata;
> > +	}
> >
> > Er, have you actually tried this ... the block requests will block all
> > requests including the attempt to scan. I assume the unblock is coming
> > from the schedule_work, but you're still hanging the rest of the system
> > waiting for this on a bootup.
> 
> Yes, this works fine, but I don't like it.  The scenario is that until we 
> get the SRP_LOGIN response back from the adapter, we don't know what the 
> queue_limit is (can_queue).  If the mid-layer starts scanning and sending 
> SCSI cmnds, we have to hold them up until we get that response back.  I've 
> tried a number of approaches....originally I kicked off scsi_scan from the 
> bottom half that gets the SRP_LOGIN_RSP.  However:
> - The bottom half is executing in a work queue.  Calling scsi_scan() 
> causes more requests to be sent and responses returned, which would like 
> to execute in the bottom_half workqueue, except that the workqueue is busy 
> because it is executing scsi_scan().
> - I created a second workqueue just to handle scsi_scan(), but that was 
> getting byzantine and Christoph threw up on it.
> 
> The only other approach I have considered is not doing the 
> scsi_block_requests(), but waiting on a completion before issuing 
> scsi_scan() and posting the completion when the SRP_LOGIN_RSP is received.

I don't quite follow this.  SCSI uses a softirq in 2.6, so there are no
bottom half scheduling issues for us at all.

Hanging the boot sequence like this waiting for a login isn't
acceptable.

As I see it, the preferred option would be simply to trigger a scan of
the device from user land using the scsi_host class, so dispense with
the scsi_scan_host() altogether.

James