Re: [PATCH] ibmvscsi driver - fourth version

Dave Boutcher
2004-03-11T21:26:27Z

James,

Thanks for the comments, I'll send a revised patch. On a couple of the
issues...

On 11 Mar 2004 12:43:57 -0500, James Bottomley
<James.Bottomley@steeleye.com> wrote:
> +static int map_single_data(struct scsi_cmnd *cmd,
> + struct SRP_CMD *srp_cmd, struct device *dev)
> +{
> [...]
> + data->virtual_address =
> + (u64) (unsigned long)dma_map_single(dev, cmd->request_buffer,
> + cmd->request_bufflen,
> + DMA_BIDIRECTIONAL);
> + if (data->virtual_address == 0xFFFFFFFF) {
> + printk(KERN_ERR
> + "ibmvscsi: Unable to map request_buffer for command!\n");
>
> 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)).

> +
> + /* 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.

Dave B