Re: [PATCH] dtc: Coding police and printk levels
Alan Cox lxorguk.ukuu.org.uk> writes:
>
> On Fri, 22 Jun 2007 11:00:06 -0700
> "Darrick J. Wong" us.ibm.com> wrote:
>
> > On Fri, Jun 22, 2007 at 02:26:29PM +0100, Alan Cox wrote:
> > > -244,7 +242,7
> > > if (check_signature(base +
> > > signatures[sig].offset,
signatures[sig].string,
> strlen(signatures[sig].string))) {
> > > addr =
> > > bases[current_base].address;
> > > #if (DTCDEBUG & DTCDEBUG_INIT)
> > > - printk("scsi-dtc : detected
> > > board.\n");
> > > + printk(KERB_DEBUG "scsi-dtc :
> > > detected board.\n");
> >
> > I think you meant KERN_DEBUG ?
>
> Thanks - thats a path thats not compiled and I missed that. Will fix it.
> -
I guess we should always test-compile all edited build paths to ensure
we have not broken someone else's build. That's going into my checklist !
Thanks,
MikeW
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
scsi, was Re: -mm merge plans for 2.6.23
> restore-acpi-change-for-scsi.patch > git-scsi-misc-vs-greg-sysfs-stuff.patch > aacraid-rename-check_reset.patch > scsi-dont-build-scsi_dma_mapunmap-for-has_dma.patch > drivers-scsi-small-cleanups.patch > sym53c8xx_2-claims-cpqarray-device.patch > drivers-scsi-wd33c93c-cleanups.patch > make-seagate_st0x_detect-static.patch > pci-error-recovery-symbios-scsi-base-support.patch > pci-error-recovery-symbios-scsi-first-failure.patch > drivers-scsi-pcmcia-nsp_csc-remove-kernel-24-code.patch > drivers-message-i2o-devicec-remove-redundant-gfp_atomic-from-kmalloc.patch > drivers-scsi-aic7xxx_oldc-remove-redundant-gfp_atomic-from-kmalloc.patch > use-menuconfig-objects-ii-scsi.patch > remove-dead-references-to-module_parm-macro.patch > ppa-coding-police-and-printk-levels.patch > remove-the-dead-cyberstormiii_scsi-option.patch > config_scsi_fd_8xx-no-longer-exists.patch > use-mutex-instead-of-semaphore-in-megaraid-mailbox-driver.patch > > Sent to James. Care to drop the patches James NACKed every single time? - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] Expose Power Management Policy option to users
Hi! > This patch will modify the scsi subsystem to allow > users to set a power management policy for the link. > > The scsi subsystem will create a new sysfs file for each > host in /sys/class/scsi_host called "link_power_management_policy". > This file can have 3 possible values: > > Value Meaning > --- > min_power User wishes the link to conserve power as much as > possible, even at the cost of some performance > > max_performance User wants priority to be on performance, not power > savings > > medium_power User wants power savings, with less performance cost > than min_power (but less power savings as well). Has that anything to do with HIPM vs. DIPM? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] Expose Power Management Policy option to users
On Mon, 9 Jul 2007 19:36:04 + Pavel Machek <[EMAIL PROTECTED]> wrote: > Hi! > > > This patch will modify the scsi subsystem to allow > > users to set a power management policy for the link. > > > > The scsi subsystem will create a new sysfs file for each > > host in /sys/class/scsi_host called "link_power_management_policy". > > This file can have 3 possible values: > > > > Value Meaning > > --- > > min_power User wishes the link to conserve power as much as > > possible, even at the cost of some performance > > > > max_performance User wants priority to be on performance, not power > > savings > > > > medium_powerUser wants power savings, with less performance cost > > than min_power (but less power savings as well). > > Has that anything to do with HIPM vs. DIPM? > > Pavel Hi Pavel, I'm not sure I'm understanding your question, but if you mean the different levels of power savings you would get, no. With ALPM you have the option of instructing the link to either go into slumber or partial mode when it determines the link is quiet. Slumber uses less power, but has more latency to come out of. So, for a SATA device, setting the link_power_managment file to "medium_power" will set up the link to only go into Partial mode, which has less power savings (about half by my informal measurement), but less latency, and therefore less of a performance hit. Hopefully this answers your question. Kristen - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi, was Re: -mm merge plans for 2.6.23
On Wed, 11 Jul 2007 13:37:18 +0200 Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > restore-acpi-change-for-scsi.patch > > git-scsi-misc-vs-greg-sysfs-stuff.patch > > aacraid-rename-check_reset.patch > > scsi-dont-build-scsi_dma_mapunmap-for-has_dma.patch > > drivers-scsi-small-cleanups.patch > > sym53c8xx_2-claims-cpqarray-device.patch > > drivers-scsi-wd33c93c-cleanups.patch > > make-seagate_st0x_detect-static.patch > > pci-error-recovery-symbios-scsi-base-support.patch > > pci-error-recovery-symbios-scsi-first-failure.patch > > drivers-scsi-pcmcia-nsp_csc-remove-kernel-24-code.patch > > drivers-message-i2o-devicec-remove-redundant-gfp_atomic-from-kmalloc.patch > > drivers-scsi-aic7xxx_oldc-remove-redundant-gfp_atomic-from-kmalloc.patch > > use-menuconfig-objects-ii-scsi.patch > > remove-dead-references-to-module_parm-macro.patch > > ppa-coding-police-and-printk-levels.patch > > remove-the-dead-cyberstormiii_scsi-option.patch > > config_scsi_fd_8xx-no-longer-exists.patch > > use-mutex-instead-of-semaphore-in-megaraid-mailbox-driver.patch > > > > Sent to James. > > Care to drop the patches James NACKed every single time? I'm not aware of any which fit that description. There may be a couple in there which fix real bugs in an unapproved way. But I keep such patches as a matter of policy, so people keep on getting pestered about their bugs. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Cleanup sni_53c710
- base address is now a physical address; no need to convert it
- remove not needed error printk in module init function
Signed-off-by: Thomas Bogendoerfer <[EMAIL PROTECTED]>
---
diff --git a/drivers/scsi/sni_53c710.c b/drivers/scsi/sni_53c710.c
index a7dfb65..0a6b45b 100644
--- a/drivers/scsi/sni_53c710.c
+++ b/drivers/scsi/sni_53c710.c
@@ -84,7 +84,7 @@ static int __init snirm710_probe(struct platform_device *dev)
hostdata->dev = &dev->dev;
dma_set_mask(&dev->dev, DMA_32BIT_MASK);
- hostdata->base = ioremap_nocache(CPHYSADDR(base), 0x100);
+ hostdata->base = ioremap_nocache(base, 0x100);
hostdata->differential = 0;
hostdata->clock = SNIRM710_CLOCK;
@@ -141,13 +141,7 @@ static struct platform_driver snirm710_driver = {
static int __init snirm710_init(void)
{
- int err;
-
- if ((err = platform_driver_register(&snirm710_driver))) {
- printk(KERN_ERR "Driver registration failed\n");
- return err;
- }
- return 0;
+ return platform_driver_register(&snirm710_driver);
}
static void __exit snirm710_exit(void)
--
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.[ RFC1925, 2.3 ]
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Remove printk, which triggers because of low scsi clock on SNI RMs
remove printk, which triggers because of low scsi clock on SNI RMs
Signed-off-by: Thomas Bogendoerfer <[EMAIL PROTECTED]>
---
diff --git a/drivers/scsi/53c700.c b/drivers/scsi/53c700.c
index cb02656..b5ee4b3 100644
--- a/drivers/scsi/53c700.c
+++ b/drivers/scsi/53c700.c
@@ -267,8 +267,6 @@ NCR_700_offset_period_to_sxfer(struct
NCR_700_Host_Parameters *hostdata,
offset = max_offset;
}
if(XFERP < min_xferp) {
- printk(KERN_WARNING "53c700: XFERP %d is less than minium,
setting to %d\n",
- XFERP, min_xferp);
XFERP = min_xferp;
}
return (offset & 0x0f) | (XFERP & 0x07)<<4;
--
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.[ RFC1925, 2.3 ]
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Clean up scsi_add_lun a bit
This patch tidies up scsi_add_lun a bit. I rewrote the kerneldoc to match
the actual parameters, moved the check for RBC and MMC REPORT_LUN devices
away from the switch(), changed the setup of sdev->type to account for
BLIST_ISROM, moved the check for BLIST_NO_ULD_ATTACH further down in
the function, removed a bogus comment and fixed some whitespace issues.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 662577f..fe7e90b 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -703,16 +703,14 @@ static int scsi_probe_lun(struct scsi_device *sdev,
unsigned char *inq_result,
/**
* scsi_add_lun - allocate and fully initialze a scsi_device
- * @sdevscan: holds information to be stored in the new scsi_device
- * @sdevnew: store the address of the newly allocated scsi_device
+ * @sdev: holds information to be stored in the new scsi_device
* @inq_result:holds the result of a previous INQUIRY to the LUN
* @bflags:black/white list flag
+ * @async: 1 if this device is being scanned asynchronously
*
* Description:
- * Allocate and initialize a scsi_device matching sdevscan. Optionally
- * set fields based on values in [EMAIL PROTECTED] If @sdevnew is not
- * NULL, store the address of the new scsi_device in [EMAIL PROTECTED]
(needed
- * when scanning a particular LUN).
+ * Initialize the scsi_device @sdev. Optionally set fields based
+ * on values in [EMAIL PROTECTED]
*
* Return:
* SCSI_SCAN_NO_RESPONSE: could not allocate or setup a scsi_device
@@ -752,25 +750,15 @@ static int scsi_add_lun(struct scsi_device *sdev,
unsigned char *inq_result,
sdev->rev = (char *) (sdev->inquiry + 32);
if (*bflags & BLIST_ISROM) {
- /*
-* It would be better to modify sdev->type, and set
-* sdev->removable; this can now be done since
-* print_inquiry has gone away.
-*/
- inq_result[0] = TYPE_ROM;
- inq_result[1] |= 0x80; /* removable */
- } else if (*bflags & BLIST_NO_ULD_ATTACH)
- sdev->no_uld_attach = 1;
+ sdev->type = TYPE_ROM;
+ sdev->removable = 1;
+ } else {
+ sdev->type = (inq_result[0] & 0x1f);
+ sdev->removable = (inq_result[1] & 0x80) >> 7;
+ }
- switch (sdev->type = (inq_result[0] & 0x1f)) {
+ switch (sdev->type) {
case TYPE_RBC:
- /* RBC devices can return SCSI-3 compliance and yet
-* still not support REPORT LUNS, so make them act as
-* BLIST_NOREPORTLUN unless BLIST_REPORTLUN2 is
-* specifically set */
- if ((*bflags & BLIST_REPORTLUN2) == 0)
- *bflags |= BLIST_NOREPORTLUN;
- /* fall through */
case TYPE_TAPE:
case TYPE_DISK:
case TYPE_PRINTER:
@@ -784,13 +772,6 @@ static int scsi_add_lun(struct scsi_device *sdev, unsigned
char *inq_result,
sdev->writeable = 1;
break;
case TYPE_ROM:
- /* MMC devices can return SCSI-3 compliance and yet
-* still not support REPORT LUNS, so make them act as
-* BLIST_NOREPORTLUN unless BLIST_REPORTLUN2 is
-* specifically set */
- if ((*bflags & BLIST_REPORTLUN2) == 0)
- *bflags |= BLIST_NOREPORTLUN;
- /* fall through */
case TYPE_WORM:
sdev->writeable = 0;
break;
@@ -798,6 +779,15 @@ static int scsi_add_lun(struct scsi_device *sdev, unsigned
char *inq_result,
printk(KERN_INFO "scsi: unknown device type %d\n", sdev->type);
}
+ if (sdev->type == TYPE_RBC || sdev->type == TYPE_ROM) {
+ /* RBC and MMC devices can return SCSI-3 compliance and yet
+* still not support REPORT LUNS, so make them act as
+* BLIST_NOREPORTLUN unless BLIST_REPORTLUN2 is
+* specifically set */
+ if ((*bflags & BLIST_REPORTLUN2) == 0)
+ *bflags |= BLIST_NOREPORTLUN;
+ }
+
/*
* For a peripheral qualifier (PQ) value of 1 (001b), the SCSI
* spec says: The device server is capable of supporting the
@@ -815,12 +805,11 @@ static int scsi_add_lun(struct scsi_device *sdev,
unsigned char *inq_result,
*/
sdev->inq_periph_qual = (inq_result[0] >> 5) & 7;
- sdev->removable = (0x80 & inq_result[1]) >> 7;
sdev->lockable = sdev->removable;
sdev->soft_reset = (inq_result[7] & 1) && ((inq_result[3] & 7) == 2);
- if (sdev->scsi_level >= SCSI_3 || (sdev->inquiry_len > 56 &&
- inq_result[56] & 0x04))
+ if (sdev->scsi_level >= SCSI_3 ||
+ (sdev->inquiry_len > 56 && inq_resul
[PATCH][BUG] Incorrect SCSI transfer length computation from odd sized scsi_execute_async() transfers.
Any function which use scsi_execute_async() and transfers "odd" sized data that doesn't align correctly with the segment sizes may have its transfer length padded out to the closest segment size. For writes, this results in unnecessary data being transfered to the SCSI target. For reads, it affects the residual data length being returned to the application since the residual length will be based on the padded transfer size rather than the actual request size. The easiest way to see this is by trying to read using the SG_IO ioctl a large (>32k) buffer size from a tape device that only has a few bytes of data stored for the current block. The resulting resid will generally be incorrect. I've fixed this simply by changing scsi_req_map_sg() so that it places the requested transfer length in rq->data_len rather than the sum of all the sg segments. This patch applies against scsi_lib.c in 2.6.22. Signed-off-by: Jeremy Linton <[EMAIL PROTECTED]> --- linux-2.6.22/drivers/scsi/scsi_lib.c.orig 2007-07-11 19:07:06.0 -0500 +++ linux-2.6.22/drivers/scsi/scsi_lib.c2007-07-11 18:43:36.0 -0500 @@ -350,7 +350,7 @@ static int scsi_req_map_sg(struct reques } rq->buffer = rq->data = NULL; - rq->data_len = data_len; + rq->data_len = bufflen; return 0; free_bios: - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BUG] Incorrect SCSI transfer length computation from odd sized scsi_execute_async() transfers.
Jeremy Linton wrote: Any function which use scsi_execute_async() and transfers "odd" sized data that doesn't align correctly with the segment sizes may have its transfer length padded out to the closest segment size. For writes, this results in unnecessary data being transfered to the SCSI target. For reads, it affects the residual data length being returned to the application since the residual length will be based on the padded transfer size rather than the actual request size. The easiest way to see this is by trying to read using the SG_IO ioctl a large (>32k) buffer size from a tape device that only has a few bytes of data stored for the current block. The resulting resid will generally be incorrect. I've fixed this simply by changing scsi_req_map_sg() so that it places the requested transfer length in rq->data_len rather than the sum of all the sg segments. This patch applies against scsi_lib.c in 2.6.22. Signed-off-by: Jeremy Linton <[EMAIL PROTECTED]> --- linux-2.6.22/drivers/scsi/scsi_lib.c.orig 2007-07-11 19:07:06.0 -0500 +++ linux-2.6.22/drivers/scsi/scsi_lib.c2007-07-11 18:43:36.0 -0500 @@ -350,7 +350,7 @@ static int scsi_req_map_sg(struct reques } rq->buffer = rq->data = NULL; - rq->data_len = data_len; + rq->data_len = bufflen; return 0; I think you needed some other bits in there. See this patch http://marc.info/?l=linux-scsi&m=117392208211297&w=2 I tried just setting the bufflen first, and that still had problems. Could you try the patch here http://marc.info/?l=linux-scsi&m=117392208211297&w=2 - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][BUG] Incorrect SCSI transfer length computation from odd sized scsi_execute_async() transfers.
Mike Christie wrote: I think you needed some other bits in there. See this patch I tried just setting the bufflen first, and that still had problems. Could you try the patch here http://marc.info/?l=linux-scsi&m=117392208211297&w=2 I just read the thread.. I didn't see any strange retries with my test case. I will try duplicating the problem tomorrow. Then I will apply your patch and rerun my test. I'm curious if this has been known since 2.6.19 why the patch hasn't propagated to the main kernel tree? - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
