- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo <at> vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Arjan van de Ven wrote: > On Sun, 2006-04-30 at 16:52 +0200, Stefan Richter wrote: >>is there a *direct* future-proof replacement for bus_to_virt()? >> >>It appears there are already architectures which do not define a >>bus_to_virt() funtion or macro. If there isn't a direct replacement, is >>there at least a way to detect at compile time whether bus_to_virt() exists? > > > I'd go one step further: given a world with iommu's, and multiple pci > domains etc, how can you know there even IS such a translation possible > (without first having set it up from the other direction)? Well, we actually do set it up from the other direction. But in a way that does not work with IOMMUs... AFAIU, the patch "dc395x: dynamically map scatter-gather for PIO" [1] by Guennadi Liakhovetski is dealing with the same issue. I am not yet clear whether I could adopt this method for sbp2. [1] http://marc.theaimsgroup.com/?l=linux-scsi&t=114400790300004 -- -- Stefan Richter -=====-=-==- -=-= ----= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo <at> vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html(Continue reading)
Hi, resending the patches ... Changes since last posting: - I reversed the order of patches 2 and 3, as one patch (now 3) refers to a blacklist flag introduced in the other. - Andrew Morton has merged the patches into -mm and fixed up compiler warnings that happened if CONFIG_SCSI_LOGGING was disabled. I merged that into patch 3. - The blist flag 0x800000 has been consumed by BLIST_MAX_512, so go for 0x1000000 instead. Description of the patchset: The trouble is that there are devices that report a LUN with peripheral qualifier 3 on LUN0. We currently don't handle this well yet: - Blacklist flags are not used to do special handling if needed. - If the device does NOT support the REPORT_LUNS scan, we won't see any LUN at all, as we don't even look for LUN 1 then. Yes, such devices do exist, actually, see PATCH2 .. The patches do: - Unconditionally at least look for LUN 1 if LUN 0 was a PQ3 device (but abort scanning there is SPARSELUN is not set and no device can be attached to LUN 1) - Return the blacklist flags for further usage even if LUN 0 was a PQ3 device. - Introduce a blacklist flag BLIST_ATTACH_PQ3 that allows(Continue reading)
From: Kurt Garloff <garloff <at> suse.de> Subject: Tolerate PQ 3 at LUN 0 for scanning Some devices report a peripheral qualifier of 3 for LUN 0; with the original code, we would still try a REPORT_LUNS scan (if SCSI level is >= 3 or if we have the BLIST_REPORTLUNS2 passed in), but NOT any sequential scan. Also, the device at LUN 0 (which is not connected according to the PQ) is not registered with the OS. Unfortunately, SANs exist that are SCSI-2 and do NOT support REPORT_LUNS, but report a unknown device with PQ 3 on LUN 0. We still need to scan them, and most probably we even need BLIST_SPARSELUN (and BLIST_LARGELUN). See the next patch for an example. This is patch 1/3: If we end up in sequential scan, at least try LUN 1 for devices that reported a PQ of 3 for LUN 0. Also return blacklist flags, even for PQ3 devices. Signed-off-by: Kurt Garloff <garloff <at> suse.de> diff -uNrp linux-2.6-hg/drivers/scsi.0/scsi_scan.c linux-2.6-hg/drivers/scsi/scsi_scan.c --- linux-2.6-hg/drivers/scsi.0/scsi_scan.c 2006-04-19 08:55:03.000000000 +0200 +++ linux-2.6-hg/drivers/scsi/scsi_scan.c 2006-04-24 07:37:39.000000000 +0200 <at> <at> -880,6 +880,8 <at> <at> static int scsi_probe_and_add_lun(struct if (scsi_probe_lun(sdev, result, result_len, &bflags)) goto out_free_result; + if (bflagsp) + *bflagsp = bflags;(Continue reading)
From: Kurt Garloff <garloff <at> suse.de> Subject: Introduce BLIST_ATTACH_PQ3 flag Some devices report a peripheral qualifier of 3 for LUN 0; with the original code, we would still try a REPORT_LUNS scan (if SCSI level is >= 3 or if we have the BLIST_REPORTLUNS2 passed in), but NOT any sequential scan. Also, the device at LUN 0 (which is not connected according to the PQ) is not registered with the OS. Unfortunately, SANs exist that are SCSI-2 and do NOT support REPORT_LUNS, but report a unknown device with PQ 3 on LUN 0. We still need to scan them, and most probably we even need BLIST_SPARSELUN (and BLIST_LARGELUN). See the referenced device for an example. This is patch 2/3: Implement the blacklist flag BLIST_ATTACH_PQ3 that makes the scsi scanning code register PQ3 devices and continues scanning; only sg will attach thanks to scsi_bus_match(). Signed-off-by: Kurt Garloff <garloff <at> suse.de> diff -uNrp linux-2.6-hg/include/scsi.1/scsi_devinfo.h linux-2.6-hg/include/scsi/scsi_devinfo.h --- linux-2.6-hg/include/scsi.1/scsi_devinfo.h 2006-04-19 08:55:05.000000000 +0200 +++ linux-2.6-hg/include/scsi/scsi_devinfo.h 2006-04-24 07:40:43.000000000 +0200 <at> <at> -29,4 +29,5 <at> <at> #define BLIST_SELECT_NO_ATN 0x200000 /* select without ATN */ #define BLIST_RETRY_HWERROR 0x400000 /* retry HARDWARE_ERROR */ #define BLIST_MAX_512 0x800000 /* maximum 512 sector cdb length */ +#define BLIST_ATTACH_PQ3 0x1000000 /* Scan: Attach to PQ3 devices */(Continue reading)
From: Kurt Garloff <garloff <at> suse.de>
Subject: Log a message if we stop scanning because dev reports PQ==3
Some devices report a peripheral qualifier of 3 for LUN 0; with the original
code, we would still try a REPORT_LUNS scan (if SCSI level is >= 3 or if we
have the BLIST_REPORTLUNS2 passed in), but NOT any sequential scan.
Also, the device at LUN 0 (which is not connected according to the PQ) is not
registered with the OS.
Unfortunately, SANs exist that are SCSI-2 and do NOT support REPORT_LUNS, but
report a unknown device with PQ 3 on LUN 0. We still need to scan them, and
most probably we even need BLIST_SPARSELUN (and BLIST_LARGELUN). See the bug
reference for an infamous example.
SCSI_CHECK_LOGGING macro and warning fixes from Andrew Morton.
This patch 3/3:
If a PQ3 device is found, log a message that describes the device
(INQUIRY DATA and C:B:T:U tuple) and make a suggestion for blacklisting
it.
Signed-off-by: Kurt Garloff <garloff <at> suse.de>
diff -uNrp linux-2.6-hg/drivers/scsi.2/scsi_logging.h linux-2.6-hg/drivers/scsi/scsi_logging.h
--- linux-2.6-hg/drivers/scsi.2/scsi_logging.h 2005-07-19 03:34:43.000000000 +0200
+++ linux-2.6-hg/drivers/scsi/scsi_logging.h 2006-04-27 23:03:29.000000000 +0200
<at> <at> -45,10 +45,12 <at> <at> extern unsigned int scsi_logging_level;
((scsi_logging_level >> (SHIFT)) & ((1 << (BITS)) - 1))
(Continue reading)
On Mon, 2006-05-01 at 02:44 +0200, Kurt Garloff wrote: > resending the patches ... > Changes since last posting: > - I reversed the order of patches 2 and 3, as one patch (now 3) > refers to a blacklist flag introduced in the other. > - Andrew Morton has merged the patches into -mm and fixed up compiler > warnings that happened if CONFIG_SCSI_LOGGING was disabled. > I merged that into patch 3. > - The blist flag 0x800000 has been consumed by BLIST_MAX_512, so > go for 0x1000000 instead. OK ... I already did that merger; could you take a look and see what's in scsi-misc-2.6 and submit patches against that. Thanks, James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo <at> vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Randy Dunlap <rdunlap <at> xenotime.net>
Modify beginning string to be more readable.
Remove one trailing newline.
Signed-off-by: Randy Dunlap <rdunlap <at> xenotime.net>
---
drivers/scsi/aic7xxx/aic79xx_osm.c | 4 ++--
drivers/scsi/aic7xxx/aic7xxx_osm.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--- linux-2617-rc3.orig/drivers/scsi/aic7xxx/aic79xx_osm.c
+++ linux-2617-rc3/drivers/scsi/aic7xxx/aic79xx_osm.c
<at> <at> -340,7 +340,7 <at> <at> MODULE_LICENSE("Dual BSD/GPL");
MODULE_VERSION(AIC79XX_DRIVER_VERSION);
module_param(aic79xx, charp, 0444);
MODULE_PARM_DESC(aic79xx,
-"period delimited, options string.\n"
+"period-delimited options string:\n"
" verbose Enable verbose/diagnostic logging\n"
" allow_memio Allow device registers to be memory mapped\n"
" debug Bitmask of debug values to enable\n"
<at> <at> -366,7 +366,7 <at> <at> MODULE_PARM_DESC(aic79xx,
" Shorten the selection timeout to 128ms\n"
"\n"
" options aic79xx 'aic79xx=verbose.tag_info:{{}.{}.{..10}}.seltime:1'\n"
-"\n");
+);
static void ahd_linux_handle_scsi_status(struct ahd_softc *,
(Continue reading)> is there a *direct* future-proof replacement for bus_to_virt()? > > It appears there are already architectures which do not define a > bus_to_virt() funtion or macro. If there isn't a direct > replacement, is there at least a way to detect at compile time > whether bus_to_virt() exists? > > I am asking because the sbp2 driver uses bus_to_virt() if > CONFIG_IEEE1394_SBP2_PHYS_DMA=y. I would like to replace this > option by an automatic detection when the respective code in sbp2 > is actually required. > > The current implementation is this: Sbp2 uses bus_to_virt() to map > from 1394 bus addresses (which are currently identical to local > host bus addresses) to virtual addresses. Sounds like you should be using phys_to_virt() anyway? Segher - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo <at> vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2006-05-01 at 10:15 -0700, akpm <at> osdl.org wrote: > diff -puN drivers/scsi/53c700.c~drivers-scsi-use-array_size-macro drivers/scsi/53c700.c > --- devel/drivers/scsi/53c700.c~drivers-scsi-use-array_size-macro 2006-05-01 10:15:39.000000000 -0700 > +++ devel-akpm/drivers/scsi/53c700.c 2006-05-01 10:15:39.000000000 -0700 > <at> <at> -316,7 +316,7 <at> <at> NCR_700_detect(struct scsi_host_template > BUG_ON(!dma_is_consistent(pScript) && L1_CACHE_BYTES < dma_get_cache_alignment()); > hostdata->slots = (struct NCR_700_command_slot *)(memory + SLOTS_OFFSET); > hostdata->dev = dev; > - > + > pSlots = pScript + SLOTS_OFFSET; > > /* Fill in the missing routines from the host template */ noise? > <at> <at> -332,19 +332,18 <at> <at> NCR_700_detect(struct scsi_host_template > tpnt->slave_destroy = NCR_700_slave_destroy; > tpnt->change_queue_depth = NCR_700_change_queue_depth; > tpnt->change_queue_type = NCR_700_change_queue_type; > - > + more noise? > <at> <at> -385,17 +382,17 <at> <at> NCR_700_detect(struct scsi_host_template > host->hostdata[0] = (unsigned long)hostdata; > /* kick the chip */ > NCR_700_writeb(0xff, host, CTEST9_REG); > - if(hostdata->chip710)(Continue reading)
RSS Feed368 | |
|---|---|
366 | |
352 | |
387 | |
287 | |
323 | |
294 | |
333 | |
445 | |
393 | |
266 | |
340 | |
558 | |
356 | |
505 | |
423 | |
441 | |
347 | |
255 | |
300 | |
262 | |
467 | |
643 | |
392 | |
430 | |
255 | |
578 | |
514 | |
513 | |
479 | |
642 | |
502 | |
600 | |
441 | |
581 | |
480 | |
481 | |
363 | |
530 | |
429 | |
340 | |
400 | |
635 | |
387 | |
848 | |
930 | |
620 | |
769 | |
985 | |
1000 | |
744 | |
656 | |
824 | |
896 | |
669 | |
757 | |
586 | |
711 | |
874 | |
614 | |
782 | |
802 | |
1115 | |
1200 | |
1057 | |
712 | |
555 | |
1117 | |
805 | |
562 | |
1027 | |
445 | |
769 | |
485 | |
507 | |
544 | |
598 | |
419 | |
508 | |
612 | |
490 | |
629 | |
471 | |
727 | |
569 | |
519 | |
812 | |
796 | |
711 | |
539 | |
647 | |
743 | |
1018 | |
825 | |
484 | |
552 | |
559 | |
593 | |
614 | |
492 | |
499 | |
297 | |
441 | |
729 | |
734 | |
615 | |
294 | |
642 | |
460 | |
552 | |
472 | |
592 | |
653 | |
325 | |
541 | |
426 | |
395 | |
400 | |
304 | |
361 | |
438 | |
349 | |
362 | |
302 | |
403 | |
250 | |
417 | |
465 | |
290 | |
217 | |
226 | |
257 | |
133 | |
142 |
