scsi_scan.c

scsi_scan.c

[Luben Tuikov]

What is the status of scsi_scan.c in 2.4.latest
and in 2.5.latest (28)?

I thought that Patric Mansfield's version would be
used? It looks to me (2.5.28) that some mixture
of old and new (P.M.) code is used. (Judging by
the the use of the old ``if (SDpnt != oldSDpnt) ...''
along with the new scsi_scan_target() by P.M.)

Currently select_queue_depths() gets quite confused
setting the queue depths unless extended effort
is used on SDpnt to see that it is the ``next''
device to be later scanned... (going through the devices)

???
-- 
Luben

Re: scsi_scan.c

[Patrick Mansfield]

On Thu, Jul 25, 2002 at 04:42:02PM -0400, Luben Tuikov wrote:
> What is the status of scsi_scan.c in 2.4.latest
> and in 2.5.latest (28)?
> 
> I thought that Patric Mansfield's version would be
> used? It looks to me (2.5.28) that some mixture
> of old and new (P.M.) code is used. (Judging by
> the the use of the old ``if (SDpnt != oldSDpnt) ...''
> along with the new scsi_scan_target() by P.M.)

The REPORT LUNS support and scsi_scan_target are there, I didn't push my
scsi_scan.c cleanup, I'm re-rolling right now to 2.5.28 - generally, merging
with the driverfs stuff Mike Sullivan added (plus his patches that apply
to scsi_scan.c).

> Currently select_queue_depths() gets quite confused
> setting the queue depths unless extended effort
> is used on SDpnt to see that it is the ``next''
> device to be later scanned... (going through the devices)
> 
> ???

Do you mean for the "hardcoded" scanning via /proc/scsi/scsi? Doug Ledford
has a nice patch for this via the slave_attach/slave_detach calls - 
slave_attach can set the queue depth.

I still think all queue depth setting/handling could be done in the
mid-layer, or at a minimum have some common queue depth setting/handling
code.

In any case, select_queue_depths is broken for hardcoded scanning, since
queue depths can't be adjusted.

-- Patrick Mansfield

> -- 
> Luben
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

scsi_scan.c

[Andre Straker-Payne]

With regards to Linux 2.6, file "drivers/scsi/scsi_scan.c", lines 691 and 928.

691         result = kmalloc(256, GFP_ATOMIC |
692                         (host->unchecked_isa_dma) ? __GFP_DMA : 0);

928         lun_data = kmalloc(length, GFP_ATOMIC |
929                            (sdev->host->unchecked_isa_dma ? __GFP_DMA :
0));

In line 691, the evaluation done to fill the priority field for the kmalloc is
ambiguous. If your system does not support the GFP_DMA type, this call will
fail, since it always evaluates true. I imagine that 928 is shows what this 691
should look like.

Andre Straker-Payne

"There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know. "