Re: [PATCH] ibmvscsi driver - fourth version

James Bottomley
2004-03-11T22:08:25Z

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