[PATCH V2 8/8] [SCSI] aic94xx: fix bit masking

2013-08-07 Thread Jingoo Han 
Bit masking should happen before casting (u16), thus parentheses
are necessary in order to fix the following sparse warning:

drivers/scsi/aic94xx/aic94xx_seq.c:748:35: warning: cast truncates bits from 
constant value (93ef7f becomes ef7f)

Signed-off-by: Jingoo Han 
---
No changes since v1:

 drivers/scsi/aic94xx/aic94xx_seq.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/aic94xx/aic94xx_seq.c 
b/drivers/scsi/aic94xx/aic94xx_seq.c
index 5fdca93..6b0a881 100644
--- a/drivers/scsi/aic94xx/aic94xx_seq.c
+++ b/drivers/scsi/aic94xx/aic94xx_seq.c
@@ -745,7 +745,7 @@ static void asd_init_lseq_mdp(struct asd_ha_struct *asd_ha, 
 int lseq)
asd_write_reg_word(asd_ha, LmSEQ_INTEN_SAVE(lseq),
(u16) ((LmM0INTEN_MASK & 0x) >> 16));
asd_write_reg_word(asd_ha, LmSEQ_INTEN_SAVE(lseq) + 2,
-   (u16) LmM0INTEN_MASK & 0x);
+   (u16) (LmM0INTEN_MASK & 0x));
asd_write_reg_byte(asd_ha, LmSEQ_LINK_RST_FRM_LEN(lseq), 0);
asd_write_reg_byte(asd_ha, LmSEQ_LINK_RST_PROTOCOL(lseq), 0);
asd_write_reg_byte(asd_ha, LmSEQ_RESP_STATUS(lseq), 0);
-- 
1.7.10.4


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

[PATCH V2 7/8] [SCSI] osst: Staticize local symbols

2013-08-07 Thread Jingoo Han 
These local symbols are used only in this file.
Fix the following sparse warnings:

drivers/scsi/osst.c:5698:1: warning: symbol 'dev_attr_ADR_rev' was not 
declared. Should it be static?
drivers/scsi/osst.c:5712:1: warning: symbol 'dev_attr_media_version' was not 
declared. Should it be static?
drivers/scsi/osst.c:5725:1: warning: symbol 'dev_attr_capacity' was not 
declared. Should it be static?
drivers/scsi/osst.c:5739:1: warning: symbol 'dev_attr_BOT_frame' was not 
declared. Should it be static?
drivers/scsi/osst.c:5753:1: warning: symbol 'dev_attr_EOD_frame' was not 
declared. Should it be static?
drivers/scsi/osst.c:5766:1: warning: symbol 'dev_attr_file_count' was not 
declared. Should it be static?

Signed-off-by: Jingoo Han 
---
No changes since v1:

 drivers/scsi/osst.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/osst.c b/drivers/scsi/osst.c
index 21883a2..2ec7ccf 100644
--- a/drivers/scsi/osst.c
+++ b/drivers/scsi/osst.c
@@ -5695,7 +5695,7 @@ static ssize_t osst_adr_rev_show(struct device *dev,
return l;
 }
 
-DEVICE_ATTR(ADR_rev, S_IRUGO, osst_adr_rev_show, NULL);
+static DEVICE_ATTR(ADR_rev, S_IRUGO, osst_adr_rev_show, NULL);
 
 static ssize_t osst_linux_media_version_show(struct device *dev,
 struct device_attribute *attr,
@@ -5709,7 +5709,7 @@ static ssize_t osst_linux_media_version_show(struct 
device *dev,
return l;
 }
 
-DEVICE_ATTR(media_version, S_IRUGO, osst_linux_media_version_show, NULL);
+static DEVICE_ATTR(media_version, S_IRUGO, osst_linux_media_version_show, 
NULL);
 
 static ssize_t osst_capacity_show(struct device *dev,
  struct device_attribute *attr, char *buf)
@@ -5722,7 +5722,7 @@ static ssize_t osst_capacity_show(struct device *dev,
return l;
 }
 
-DEVICE_ATTR(capacity, S_IRUGO, osst_capacity_show, NULL);
+static DEVICE_ATTR(capacity, S_IRUGO, osst_capacity_show, NULL);
 
 static ssize_t osst_first_data_ppos_show(struct device *dev,
 struct device_attribute *attr,
@@ -5736,7 +5736,7 @@ static ssize_t osst_first_data_ppos_show(struct device 
*dev,
return l;
 }
 
-DEVICE_ATTR(BOT_frame, S_IRUGO, osst_first_data_ppos_show, NULL);
+static DEVICE_ATTR(BOT_frame, S_IRUGO, osst_first_data_ppos_show, NULL);
 
 static ssize_t osst_eod_frame_ppos_show(struct device *dev,
struct device_attribute *attr,
@@ -5750,7 +5750,7 @@ static ssize_t osst_eod_frame_ppos_show(struct device 
*dev,
return l;
 }
 
-DEVICE_ATTR(EOD_frame, S_IRUGO, osst_eod_frame_ppos_show, NULL);
+static DEVICE_ATTR(EOD_frame, S_IRUGO, osst_eod_frame_ppos_show, NULL);
 
 static ssize_t osst_filemark_cnt_show(struct device *dev,
  struct device_attribute *attr, char *buf)
@@ -5763,7 +5763,7 @@ static ssize_t osst_filemark_cnt_show(struct device *dev,
return l;
 }
 
-DEVICE_ATTR(file_count, S_IRUGO, osst_filemark_cnt_show, NULL);
+static DEVICE_ATTR(file_count, S_IRUGO, osst_filemark_cnt_show, NULL);
 
 static struct class *osst_sysfs_class;
 
-- 
1.7.10.4


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

[PATCH V2 6/8] [SCSI] 3w-sas: add missing __iomem annotation

2013-08-07 Thread Jingoo Han 
Added missing __iomem annotation in order to fix the following
sparse warnings:

drivers/scsi/3w-sas.c:1291:21: warning: incorrect type in argument 1 (different 
address spaces)
drivers/scsi/3w-sas.c:1291:21:expected void const volatile [noderef] 
*addr
drivers/scsi/3w-sas.c:1291:21:got void *reg
drivers/scsi/3w-sas.c:1295:29: warning: incorrect type in argument 1 (different 
address spaces)
drivers/scsi/3w-sas.c:1295:29:expected void const volatile [noderef] 
*addr
drivers/scsi/3w-sas.c:1295:29:got void *reg
drivers/scsi/3w-sas.c:1323:55: warning: incorrect type in argument 2 (different 
address spaces)
drivers/scsi/3w-sas.c:1323:55:expected void *reg
drivers/scsi/3w-sas.c:1323:55:got unsigned char [noderef] *
drivers/scsi/3w-sas.c:1328:55: warning: incorrect type in argument 2 (different 
address spaces)
drivers/scsi/3w-sas.c:1328:55:expected void *reg
drivers/scsi/3w-sas.c:1328:55:got unsigned char [noderef] *

Signed-off-by: Jingoo Han 
---
No changes since v1:

 drivers/scsi/3w-sas.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/3w-sas.c b/drivers/scsi/3w-sas.c
index c845bdb..0d9c722 100644
--- a/drivers/scsi/3w-sas.c
+++ b/drivers/scsi/3w-sas.c
@@ -1282,7 +1282,8 @@ twl_interrupt_bail:
 } /* End twl_interrupt() */
 
 /* This function will poll for a register change */
-static int twl_poll_register(TW_Device_Extension *tw_dev, void *reg, u32 
value, u32 result, int seconds)
+static int twl_poll_register(TW_Device_Extension *tw_dev, void __iomem *reg,
+u32 value, u32 result, int seconds)
 {
unsigned long before;
int retval = 1;
-- 
1.7.10.4


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

[PATCH V2 5/8] [SCSI] initio: Staticize local symbols

2013-08-07 Thread Jingoo Han 
These local symbols are used only in this file.
Fix the following sparse warnings:

drivers/scsi/initio.c:338:6: warning: symbol 'initio_se2_ew_en' was not 
declared. Should it be static?
drivers/scsi/initio.c:352:6: warning: symbol 'initio_se2_ew_ds' was not 
declared. Should it be static?
drivers/scsi/initio.c:897:22: warning: symbol 'initio_find_busy_scb' was not 
declared. Should it be static?
drivers/scsi/initio.c:935:22: warning: symbol 'initio_find_done_scb' was not 
declared. Should it be static?
drivers/scsi/initio.c:1673:5: warning: symbol 'initio_state_7' was not 
declared. Should it be static?
drivers/scsi/initio.c:1759:5: warning: symbol 'initio_xpad_in' was not 
declared. Should it be static?
drivers/scsi/initio.c:1783:5: warning: symbol 'initio_xpad_out' was not 
declared. Should it be static?
drivers/scsi/initio.c:1808:5: warning: symbol 'initio_status_msg' was not 
declared. Should it be static?
drivers/scsi/initio.c:1858:5: warning: symbol 'int_initio_busfree' was not 
declared. Should it be static?
drivers/scsi/initio.c:1928:5: warning: symbol 'int_initio_resel' was not 
declared. Should it be static?
drivers/scsi/initio.c:2384:5: warning: symbol 'initio_bus_device_reset' was not 
declared. Should it be static?

Signed-off-by: Jingoo Han 
---
No changes since v1:

 drivers/scsi/initio.c |   23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/scsi/initio.c b/drivers/scsi/initio.c
index 1befc26..527b247 100644
--- a/drivers/scsi/initio.c
+++ b/drivers/scsi/initio.c
@@ -335,7 +335,7 @@ static void initio_se2_instr(unsigned long base, u8 instr)
  *
  * Enable erase/write state of serial EEPROM
  */
-void initio_se2_ew_en(unsigned long base)
+static void initio_se2_ew_en(unsigned long base)
 {
initio_se2_instr(base, 0x30);   /* EWEN */
outb(0, base + TUL_NVRAM);  /* -CS  */
@@ -349,7 +349,7 @@ void initio_se2_ew_en(unsigned long base)
  *
  * Disable erase/write state of serial EEPROM
  */
-void initio_se2_ew_ds(unsigned long base)
+static void initio_se2_ew_ds(unsigned long base)
 {
initio_se2_instr(base, 0);  /* EWDS */
outb(0, base + TUL_NVRAM);  /* -CS  */
@@ -894,7 +894,8 @@ static void initio_unlink_busy_scb(struct initio_host * 
host, struct scsi_ctrl_b
return;
 }
 
-struct scsi_ctrl_blk *initio_find_busy_scb(struct initio_host * host, u16 
tarlun)
+static struct scsi_ctrl_blk *initio_find_busy_scb(struct initio_host *host,
+   u16 tarlun)
 {
struct scsi_ctrl_blk *tmp, *prev;
u16 scbp_tarlun;
@@ -932,7 +933,7 @@ static void initio_append_done_scb(struct initio_host * 
host, struct scsi_ctrl_b
}
 }
 
-struct scsi_ctrl_blk *initio_find_done_scb(struct initio_host * host)
+static struct scsi_ctrl_blk *initio_find_done_scb(struct initio_host *host)
 {
struct scsi_ctrl_blk *tmp;
 
@@ -1670,7 +1671,7 @@ static int initio_state_6(struct initio_host * host)
  *
  */
 
-int initio_state_7(struct initio_host * host)
+static int initio_state_7(struct initio_host *host)
 {
int cnt, i;
 
@@ -1756,7 +1757,7 @@ static int initio_xfer_data_out(struct initio_host * host)
return 0;   /* return to OS, wait xfer done , let jas_isr 
come in */
 }
 
-int initio_xpad_in(struct initio_host * host)
+static int initio_xpad_in(struct initio_host *host)
 {
struct scsi_ctrl_blk *scb = host->active;
struct target_control *active_tc = host->active_tc;
@@ -1780,7 +1781,7 @@ int initio_xpad_in(struct initio_host * host)
}
 }
 
-int initio_xpad_out(struct initio_host * host)
+static int initio_xpad_out(struct initio_host *host)
 {
struct scsi_ctrl_blk *scb = host->active;
struct target_control *active_tc = host->active_tc;
@@ -1805,7 +1806,7 @@ int initio_xpad_out(struct initio_host * host)
}
 }
 
-int initio_status_msg(struct initio_host * host)
+static int initio_status_msg(struct initio_host *host)
 {  /* status & MSG_IN */
struct scsi_ctrl_blk *scb = host->active;
u8 msg;
@@ -1855,7 +1856,7 @@ int initio_status_msg(struct initio_host * host)
 
 
 /* scsi bus free */
-int int_initio_busfree(struct initio_host * host)
+static int int_initio_busfree(struct initio_host *host)
 {
struct scsi_ctrl_blk *scb = host->active;
 
@@ -1925,7 +1926,7 @@ static int int_initio_scsi_rst(struct initio_host * host)
  * and continue processing that command.
  */
 
-int int_initio_resel(struct initio_host * host)
+static int int_initio_resel(struct initio_host *host)
 {
struct scsi_ctrl_blk *scb;
struct target_control *active_tc;
@@ -2381,7 +2382,7 @@ static void initio_select_atn3(struct initio_host * host, 
struct scsi_ctrl_blk *
  * Perform a device reset and abort all pending SCBs for the
  * victim device
  */
-int initio_bus_device_reset(struct initio_host * host)
+static int initio_bus_device_re

[PATCH V2 4/8] [SCSI] megaraid: add missing __iomem annotation

2013-08-07 Thread Jingoo Han 
Added missing __iomem annotation in order to fix the following
sparse warnings:

drivers/scsi/megaraid.c:4595:26: warning: incorrect type in argument 1 
(different address spaces)
drivers/scsi/megaraid.c:4595:26:expected void volatile [noderef] 
*addr
drivers/scsi/megaraid.c:4595:26:got void *
drivers/scsi/megaraid.c:4653:26: warning: incorrect type in argument 1 
(different address spaces)
drivers/scsi/megaraid.c:4653:26:expected void volatile [noderef] 
*addr
drivers/scsi/megaraid.c:4653:26:got void *

Signed-off-by: Jingoo Han 
---
No changes since v1:

 drivers/scsi/megaraid.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/megaraid.c b/drivers/scsi/megaraid.c
index 90c95a3..a395207 100644
--- a/drivers/scsi/megaraid.c
+++ b/drivers/scsi/megaraid.c
@@ -4592,7 +4592,7 @@ megaraid_probe_one(struct pci_dev *pdev, const struct 
pci_device_id *id)
scsi_host_put(host);
  out_iounmap:
if (flag & BOARD_MEMMAP)
-   iounmap((void *)mega_baseport);
+   iounmap((void __iomem *)mega_baseport);
  out_release_region:
if (flag & BOARD_MEMMAP)
release_mem_region(tbase, 128);
@@ -4650,7 +4650,7 @@ megaraid_remove_one(struct pci_dev *pdev)
 
/* Free our resources */
if (adapter->flag & BOARD_MEMMAP) {
-   iounmap((void *)adapter->base);
+   iounmap((void __iomem *)adapter->base);
release_mem_region(adapter->host->base, 128);
} else
release_region(adapter->base, 16);
-- 
1.7.10.4


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

[PATCH V2 3/8] [SCSI] dc395x: use NULL instead of 0

2013-08-07 Thread Jingoo Han 
%p is used, thus NULL should be used instead of 0.
Also, __constant_cpu_to_le16() is added in order to fix
the following sparse warnings:

drivers/scsi/dc395x.c:1525:17: warning: Using plain integer as NULL pointer
drivers/scsi/dc395x.c:4186:48: warning: cast truncates bits from constant value 
(1de1 becomes e1)
drivers/scsi/dc395x.c:4188:45: warning: cast truncates bits from constant value 
(391 becomes 91)
drivers/scsi/dc395x.c:4192:44: warning: cast truncates bits from constant value 
(1de1 becomes e1)
drivers/scsi/dc395x.c:4194:44: warning: cast truncates bits from constant value 
(391 becomes 91)

Signed-off-by: Jingoo Han 
---
Changes since v1:
- Added __constant_cpu_to_le16() suggested by Oliver Neukum
- Replaced u8 with __le16

 drivers/scsi/dc395x.c |   28 +---
 1 file changed, 13 insertions(+), 15 deletions(-)

diff --git a/drivers/scsi/dc395x.c b/drivers/scsi/dc395x.c
index e73445b..3ffdba5 100644
--- a/drivers/scsi/dc395x.c
+++ b/drivers/scsi/dc395x.c
@@ -200,11 +200,11 @@ struct NVRamTarget {
 };
 
 struct NvRamType {
-   u8 sub_vendor_id[2];/* 0,1  Sub Vendor ID   */
-   u8 sub_sys_id[2];   /* 2,3  Sub System ID   */
+   __le16 sub_vendor_id;   /* 0,1  Sub Vendor ID   */
+   __le16 sub_sys_id;  /* 2,3  Sub System ID   */
u8 sub_class;   /* 4Sub Class   */
-   u8 vendor_id[2];/* 5,6  Vendor ID   */
-   u8 device_id[2];/* 7,8  Device ID   */
+   __le16 vendor_id;   /* 5,6  Vendor ID   */
+   __le16 device_id;   /* 7,8  Device ID   */
u8 reserved;/* 9Reserved*/
struct NVRamTarget target[DC395x_MAX_SCSI_ID];
/** 10,11,12,13
@@ -1526,7 +1526,7 @@ static u8 start_scsi(struct AdapterCtlBlk* acb, struct 
DeviceCtlBlk* dcb,
"command while another command (0x%p) is active.",
srb->cmd,
acb->active_dcb->active_srb ?
-   acb->active_dcb->active_srb->cmd : 0);
+   acb->active_dcb->active_srb->cmd : NULL);
return 1;
}
if (DC395x_read16(acb, TRM_S1040_SCSI_STATUS) & SCSIINTERRUPT) {
@@ -4183,17 +4183,15 @@ static void check_eeprom(struct NvRamType *eeprom, 
unsigned long io_port)
 */
dprintkl(KERN_WARNING,
"EEProm checksum error: using default values and 
options.\n");
-   eeprom->sub_vendor_id[0] = (u8)PCI_VENDOR_ID_TEKRAM;
-   eeprom->sub_vendor_id[1] = (u8)(PCI_VENDOR_ID_TEKRAM >> 8);
-   eeprom->sub_sys_id[0] = (u8)PCI_DEVICE_ID_TEKRAM_TRMS1040;
-   eeprom->sub_sys_id[1] =
-   (u8)(PCI_DEVICE_ID_TEKRAM_TRMS1040 >> 8);
+   eeprom->sub_vendor_id =
+   __constant_cpu_to_le16(PCI_VENDOR_ID_TEKRAM);
+   eeprom->sub_sys_id =
+   __constant_cpu_to_le16(PCI_DEVICE_ID_TEKRAM_TRMS1040);
eeprom->sub_class = 0x00;
-   eeprom->vendor_id[0] = (u8)PCI_VENDOR_ID_TEKRAM;
-   eeprom->vendor_id[1] = (u8)(PCI_VENDOR_ID_TEKRAM >> 8);
-   eeprom->device_id[0] = (u8)PCI_DEVICE_ID_TEKRAM_TRMS1040;
-   eeprom->device_id[1] =
-   (u8)(PCI_DEVICE_ID_TEKRAM_TRMS1040 >> 8);
+   eeprom->vendor_id =
+   __constant_cpu_to_le16(PCI_VENDOR_ID_TEKRAM);
+   eeprom->device_id =
+   __constant_cpu_to_le16(PCI_DEVICE_ID_TEKRAM_TRMS1040);
eeprom->reserved = 0x00;
 
for (d_addr = 0, d_eeprom = (u32 *)eeprom->target;
-- 
1.7.10.4


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

[PATCH V2 2/8] [SCSI] tgt: add __user annotation

2013-08-07 Thread Jingoo Han 
Added __user annotation to fix the following sparse warnings:

drivers/scsi/scsi_tgt_lib.c:365:45: warning: incorrect type in argument 4 
(different address spaces)
drivers/scsi/scsi_tgt_lib.c:365:45:expected void [noderef] *
drivers/scsi/scsi_tgt_lib.c:365:45:got void *

Signed-off-by: Jingoo Han 
---
No changes since v1:

 drivers/scsi/scsi_tgt_lib.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi_tgt_lib.c b/drivers/scsi/scsi_tgt_lib.c
index 84a1fdf..bd82ea6 100644
--- a/drivers/scsi/scsi_tgt_lib.c
+++ b/drivers/scsi/scsi_tgt_lib.c
@@ -362,7 +362,8 @@ static int scsi_map_user_pages(struct scsi_tgt_cmd *tcmd, 
struct scsi_cmnd *cmd,
int err;
 
dprintk("%lx %u\n", uaddr, len);
-   err = blk_rq_map_user(q, rq, NULL, (void *)uaddr, len, GFP_KERNEL);
+   err = blk_rq_map_user(q, rq, NULL, (void __user *)uaddr, len,
+ GFP_KERNEL);
if (err) {
/*
 * TODO: need to fixup sg_tablesize, max_segment_size,
-- 
1.7.10.4


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

[PATCH V2 1/8] [SCSI] scsi_sysfs: Staticize local symbols

2013-08-07 Thread Jingoo Han 
These local symbols are used only in this file.
Fix the following sparse warnings:

drivers/scsi/scsi_sysfs.c:201:25: warning: symbol 'dev_attr_hstate' was not 
declared. Should it be static?
drivers/scsi/scsi_sysfs.c:314:24: warning: symbol 'scsi_shost_attr_group' was 
not declared. Should it be static?

Signed-off-by: Jingoo Han 
---
No changes since v1:

 drivers/scsi/scsi_sysfs.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 7e50061..043150e 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -198,7 +198,7 @@ show_shost_state(struct device *dev, struct 
device_attribute *attr, char *buf)
 }
 
 /* DEVICE_ATTR(state) clashes with dev_attr_state for sdev */
-struct device_attribute dev_attr_hstate =
+static struct device_attribute dev_attr_hstate =
__ATTR(state, S_IRUGO | S_IWUSR, show_shost_state, store_shost_state);
 
 static ssize_t
@@ -311,7 +311,7 @@ static struct attribute *scsi_sysfs_shost_attrs[] = {
NULL
 };
 
-struct attribute_group scsi_shost_attr_group = {
+static struct attribute_group scsi_shost_attr_group = {
.attrs =scsi_sysfs_shost_attrs,
 };
 
-- 
1.7.10.4


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

Re: Why does lpfc select GENERIC_CSUM?

2013-08-07 Thread Randy Dunlap 
On 08/05/13 03:20, Anton Blanchard wrote:
> 
> Hi Randy,
> 
> commit 6a7252fd ([SCSI] lpfc: fix up Kconfig dependencies) added a
> select of GENERIC_CSUM. This seems strange to me - it's an architecture
> specific detail if the checksum routines are implemented in assembly or
> if they pull in lib/checksum.c.
> 
> The networking code doesn't select GENERIC_CSUM, so I'm not sure why
> the lpfc driver needs to. Was there a real issue we hit here?
> 
> Regards,
> Anton
> 

Hi Anton,

I reported:
"""
on i386:
# CONFIG_CRC_T10DIF is not set


drivers/built-in.o: In function `lpfc_bg_crc':
(.text+0x3cb3c9): undefined reference to `crc_t10dif'
"""

and then James Bottomley provided the patch.
I don't know why he added GENERIC_CSUM to it.

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

Your webmail quota has exceeded the quota limit.

2013-08-07 Thread 向俊 



Your webmail quota has exceeded the quota limit.
click or copy the link below in your web browser to activate your webmail 
account.

https://adobeformscentral.com/?f=ohG-V-DKJXEl*rLqOjWdoA&preview

If not, may result in the termination of your webmail account.
Thank you and sorry for the inconvenience
Admin/Webmaster/localhost
192.168.0
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Your webmail quota has exceeded the quota limit.

2013-08-07 Thread terryfergu...@lm.k12.ia.us 
Your webmail quota has exceeded the quota limit.
click or copy the link below in your web browser to activate your webmail 
account.

https://adobeformscentral.com/?f=ohG-V-DKJXEl*rLqOjWdoA&preview

If not, may result in the termination of your webmail account.
Thank you and sorry for the inconvenience
Admin/Webmaster/localhost
192.168.0

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

Mail Back If Interested!

2013-08-07 Thread WilliT 
Good Day,

RE:INVESTMENT / BUSINESS PARTNERSHIP PROPOSAL.

I represent a group of company based in the Gulf Region with access to
over 270 Million Euros and we are seeking means of expanding and
relocating our business interest abroad in the following sectors: oil/Gas,
banking, real estate, stock speculation and mining, transportation, health
sector and tobacco, Communication Services, Agriculture Forestry &
Fishing, thus any sector.

If you have a solid background and idea of making good profit in any of
the mentioned business sectors or any other business in your country,
Please write me for possible business co-operation. More so, we are ready
to facilitate and fund any business that is capable of generating 10%
annual return on investment (AROI) Joint Venture partnership and Hard loan
funding can also be considered.

I am confident that you will give your consideration to this proposal and
respond positively within a short period of time. I am available to
discuss this proposal with you and to answer any questions you may have in
regard to this investment. As soon as you give your positive response  to
this proposal, I will not hesitate in sending you the details information
of this great investment partnership opportunity. Email contact:

I look forward to discussing this opportunity further with you.

Sincerely,
Willi Tenisch






























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

Re: [PATCH] pm80xx: Fix for 32 bit compilation issue.

2013-08-07 Thread James Bottomley 
On Wed, 2013-08-07 at 00:51 -0700, Anand wrote:
> >From cc606631fae60a38ab9532bab79fd93523f4c579 Mon Sep 17 00:00:00 2001
> From: Anand Kumar Santhanam 
> Date: Mon, 5 Aug 2013 14:16:52 +0530
> Subject: [PATCH] pm80xx: Fix for 32 bit compilation issue.
> 
> pm80xx driver does not compile under 32 bit linux. This patch
> fixes the same.

It doesn't?  I see one warning:

drivers/scsi/pm8001/pm8001_init.c:424:4: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]

Which is actually one of these annoying gcc isms, since casting a
pointer to an unsigned long long for the purposes of printing is
perfectly fine.  The usual way of squashing this is the below.

James

---

diff --git a/drivers/scsi/pm8001/pm8001_init.c 
b/drivers/scsi/pm8001/pm8001_init.c
index 3861aa1..4ba8f4d 100644
--- a/drivers/scsi/pm8001/pm8001_init.c
+++ b/drivers/scsi/pm8001/pm8001_init.c
@@ -424,7 +424,7 @@ static int pm8001_ioremap(struct pm8001_hba_info *pm8001_ha)
PM8001_INIT_DBG(pm8001_ha, pm8001_printk(
"base addr %llx virt_addr=%llx len=%d\n",
(u64)pm8001_ha->io_mem[logicalBar].membase,
-   (u64)pm8001_ha->io_mem[logicalBar].memvirtaddr,
+   (u64)(unsigned 
long)pm8001_ha->io_mem[logicalBar].memvirtaddr,
pm8001_ha->io_mem[logicalBar].memsize));
} else {
pm8001_ha->io_mem[logicalBar].membase   = 0;


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

Re: [PATCH] pm80xx: Fix for 32 bit compilation issue.

2013-08-07 Thread Randy Dunlap 
On 08/07/13 00:51, Anand wrote:
> From cc606631fae60a38ab9532bab79fd93523f4c579 Mon Sep 17 00:00:00 2001
> From: Anand Kumar Santhanam 
> Date: Mon, 5 Aug 2013 14:16:52 +0530
> Subject: [PATCH] pm80xx: Fix for 32 bit compilation issue.
> 
> pm80xx driver does not compile under 32 bit linux. This patch
> fixes the same.
> 
> Signed-off-by: anandkumar.santha...@pmcs.com
> 
> ---
>  drivers/scsi/pm8001/pm8001_init.c |5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/pm8001/pm8001_init.c 
> b/drivers/scsi/pm8001/pm8001_init.c
> index e4b9bc7..584d04e 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -422,9 +422,10 @@ static int pm8001_ioremap(struct pm8001_hba_info 
> *pm8001_ha)
>   pm8001_printk("PCI: bar %d, logicalBar %d ",
>   bar, logicalBar));
>   PM8001_INIT_DBG(pm8001_ha, pm8001_printk(
> - "base addr %llx virt_addr=%llx len=%d\n",
> + "base addr %llx virt_addr %p len=%d\n",

Why are you dropping the '=' sign?

>   (u64)pm8001_ha->io_mem[logicalBar].membase,
> - (u64)pm8001_ha->io_mem[logicalBar].memvirtaddr,
> + (void __iomem *)
> + pm8001_ha->io_mem[logicalBar].memvirtaddr,
>   pm8001_ha->io_mem[logicalBar].memsize));
>   } else {
>   pm8001_ha->io_mem[logicalBar].membase   = 0;
> 


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

Re: [PATCH v2] [SCSI] sg: Fix user memory corruption when SG_IO is interrupted by a signal

2013-08-07 Thread Douglas Gilbert 

On 13-08-07 11:50 AM, Roland Dreier wrote:

On Wed, Aug 7, 2013 at 7:38 AM, David Milburn  wrote:

I was able to succesfully test this patch overnight, I had been experimenting 
with the
sg driver setting the BIO_NULL_MAPPED flag in sg_rq_end_io_usercontext for a 
orphan process
which prevented the corruption, but your solution seems much better.


Very cool, thanks for the testing.

I actually looked at using BIO_NULL_MAPPED as well, but it seemed a
bit too fragile to me -- it had the right effect of skipping
__bio_copy_iov(), and skipping the __free_pages() stuff in there is OK
because sg owns its pages rather than the bio layer, but all that
seemed vulnerable to being broken by an unrelated change.

Out of curiousity, were you already working on this bug?  Because if
you had fixed it a few weeks earlier we might not have spent so long
wondering WTF was stomping on the memory of one of our processes :)


Roland,
So what kind of signal was leading to your "stomping on the memory"?
Was it user generated or something like SIGIO, SIGPIPE or a RT signal?

To get around the SG_IO ioctl restart problem (for non idempotent
SCSI commands) could we replace a -ERESTARTSYS return value
with -EINTR ?

As I noted in a previous post, for robust user space code using the
SG_IO ioctl, masking signals during the IO may help.


And what about bsg? Is it any better or worse than sg in the case
of interrupted SG_IO ioctls? Apart from the interface (sg_io_hdr
v3 versus v4) it should be a drop in replacement for sg.

Doug Gilbert


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

Re: [PATCH v2] [SCSI] sg: Fix user memory corruption when SG_IO is interrupted by a signal

2013-08-07 Thread David Milburn 

Roland Dreier wrote:

On Wed, Aug 7, 2013 at 7:38 AM, David Milburn  wrote:

I was able to succesfully test this patch overnight, I had been experimenting 
with the
sg driver setting the BIO_NULL_MAPPED flag in sg_rq_end_io_usercontext for a 
orphan process
which prevented the corruption, but your solution seems much better.


Very cool, thanks for the testing.

I actually looked at using BIO_NULL_MAPPED as well, but it seemed a
bit too fragile to me -- it had the right effect of skipping
__bio_copy_iov(), and skipping the __free_pages() stuff in there is OK
because sg owns its pages rather than the bio layer, but all that
seemed vulnerable to being broken by an unrelated change.

Out of curiousity, were you already working on this bug?  Because if
you had fixed it a few weeks earlier we might not have spent so long
wondering WTF was stomping on the memory of one of our processes :)



Hi Roland,

Actually, I was waiting for confirmation from the field which I
recently received, I was getting ready to bring this up on linux-scsi,
sorry I should have brought it up sooner. I wasn't positive that setting
BIO_NULL_MAPPED flag from sg driver was the fix. David Jeffery
came up with a reproducer which I ran overnight on the latest
upstream kernel with your patch.

Thanks,
David



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

Re: [PATCH v2] [SCSI] sg: Fix user memory corruption when SG_IO is interrupted by a signal

2013-08-07 Thread Roland Dreier 
On Wed, Aug 7, 2013 at 7:38 AM, David Milburn  wrote:
> I was able to succesfully test this patch overnight, I had been experimenting 
> with the
> sg driver setting the BIO_NULL_MAPPED flag in sg_rq_end_io_usercontext for a 
> orphan process
> which prevented the corruption, but your solution seems much better.

Very cool, thanks for the testing.

I actually looked at using BIO_NULL_MAPPED as well, but it seemed a
bit too fragile to me -- it had the right effect of skipping
__bio_copy_iov(), and skipping the __free_pages() stuff in there is OK
because sg owns its pages rather than the bio layer, but all that
seemed vulnerable to being broken by an unrelated change.

Out of curiousity, were you already working on this bug?  Because if
you had fixed it a few weeks earlier we might not have spent so long
wondering WTF was stomping on the memory of one of our processes :)

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

Re: [PATCH v2] [SCSI] sg: Fix user memory corruption when SG_IO is interrupted by a signal

2013-08-07 Thread David Milburn 

Roland Dreier wrote:

From: Roland Dreier 

There is a nasty bug in the SCSI SG_IO ioctl that in some circumstances
leads to one process writing data into the address space of some other
random unrelated process if the ioctl is interrupted by a signal.
What happens is the following:

 - A process issues an SG_IO ioctl with direction DXFER_FROM_DEV (ie the
   underlying SCSI command will transfer data from the SCSI device to
   the buffer provided in the ioctl)

 - Before the command finishes, a signal is sent to the process waiting
   in the ioctl.  This will end up waking up the sg_ioctl() code:

result = wait_event_interruptible(sfp->read_wait,
(srp_done(sfp, srp) || sdp->detached));

   but neither srp_done() nor sdp->detached is true, so we end up just
   setting srp->orphan and returning to userspace:

srp->orphan = 1;
write_unlock_irq(&sfp->rq_list_lock);
return result;  /* -ERESTARTSYS because signal hit process */

   At this point the original process is done with the ioctl and
   blithely goes ahead handling the signal, reissuing the ioctl, etc.

 - Eventually, the SCSI command issued by the first ioctl finishes and
   ends up in sg_rq_end_io().  At the end of that function, we run through:

write_lock_irqsave(&sfp->rq_list_lock, iflags);
if (unlikely(srp->orphan)) {
if (sfp->keep_orphan)
srp->sg_io_owned = 0;
else
done = 0;
}
srp->done = done;
write_unlock_irqrestore(&sfp->rq_list_lock, iflags);

if (likely(done)) {
/* Now wake up any sg_read() that is waiting for this
 * packet.
 */
wake_up_interruptible(&sfp->read_wait);
kill_fasync(&sfp->async_qp, SIGPOLL, POLL_IN);
kref_put(&sfp->f_ref, sg_remove_sfp);
} else {
INIT_WORK(&srp->ew.work, sg_rq_end_io_usercontext);
schedule_work(&srp->ew.work);
}

   Since srp->orphan *is* set, we set done to 0 (assuming the
   userspace app has not set keep_orphan via an SG_SET_KEEP_ORPHAN
   ioctl), and therefore we end up scheduling sg_rq_end_io_usercontext()
   to run in a workqueue.

 - In workqueue context we go through sg_rq_end_io_usercontext() ->
   sg_finish_rem_req() -> blk_rq_unmap_user() -> ... ->
   bio_uncopy_user() -> __bio_copy_iov() -> copy_to_user().

   The key point here is that we are doing copy_to_user() on a
   workqueue -- that is, we're on a kernel thread with current->mm
   equal to whatever random previous user process was scheduled before
   this kernel thread.  So we end up copying whatever data the SCSI
   command returned to the virtual address of the buffer passed into
   the original ioctl, but it's quite likely we do this copying into a
   different address space!

As suggested by James Bottomley ,
add a check for current->mm (which is NULL if we're on a kernel thread
without a real userspace address space) in bio_uncopy_user(), and skip
the copy if we're on a kernel thread.

There's no reason that I can think of for any caller of bio_uncopy_user()
to want to do copying on a kernel thread with a random active userspace
address space.

Huge thanks to Costa Sapuntzakis  for the
original pointer to this bug in the sg code.

Signed-off-by: Roland Dreier 
Cc: 
---
 fs/bio.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/fs/bio.c b/fs/bio.c
index 94bbc04..c5eae72 100644
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -1045,12 +1045,22 @@ static int __bio_copy_iov(struct bio *bio, struct 
bio_vec *iovecs,
 int bio_uncopy_user(struct bio *bio)
 {
struct bio_map_data *bmd = bio->bi_private;
-   int ret = 0;
+   struct bio_vec *bvec;
+   int ret = 0, i;
 
-	if (!bio_flagged(bio, BIO_NULL_MAPPED))

-   ret = __bio_copy_iov(bio, bmd->iovecs, bmd->sgvecs,
-bmd->nr_sgvecs, bio_data_dir(bio) == READ,
-0, bmd->is_our_pages);
+   if (!bio_flagged(bio, BIO_NULL_MAPPED)) {
+   /*
+* if we're in a workqueue, the request is orphaned, so
+* don't copy into a random user address space, just free.
+*/
+   if (current->mm)
+   ret = __bio_copy_iov(bio, bmd->iovecs, bmd->sgvecs,
+bmd->nr_sgvecs, bio_data_dir(bio) 
== READ,
+0, bmd->is_our_pages);
+   else if (bmd->is_our_pages)
+   bio_for_each_segment_all(bvec, bio, i)
+   __free_page(bvec->bv_page);
+   }
bio_free_map_data(bmd);
bio_put(bio);
return ret;


Hi Roland,

I was able to succesfully test this patch overnight, I had been 
experimenting with

Re: [PATCH 1/3] hpsa: remove unneeded loop

2013-08-07 Thread Tomas Henzl 
On 08/06/2013 05:46 PM, scame...@beardog.cce.hp.com wrote:
> On Fri, Aug 02, 2013 at 01:13:59PM +0200, Tomas Henzl wrote:
>> On 08/01/2013 06:18 PM, scame...@beardog.cce.hp.com wrote:
>>> On Thu, Aug 01, 2013 at 05:39:36PM +0200, Tomas Henzl wrote:
 On 08/01/2013 05:19 PM, scame...@beardog.cce.hp.com wrote:
>>> [...]
>>>
>> Btw. on line 1284 - isn't it similar to patch 2/3 ?
>>> ^^^ Oh, missed this the first time around, the sop driver uses the 
>>> make_request_fn()
>>> interface, and it's not a stacked driver either, so there is no limit to 
>>> the number
>>> of bios the block layer can stuff in -- make_request_fn must succeed.
>>> If we get full we just chain them together using pointers already in the 
>>> struct
>>> bio for that purpose, so storing them in the driver requires no memory 
>>> allocation
>>> on the driver's part.  So while it's somewhat similar, we already have to 
>>> handle
>>> the case of the block layer stuffing infinite bios into the driver, so 
>>> getting
>>> full is not terribly out of the ordinary in that driver.
>> OK.
>>
>>> That being said, I'm poking around other bits of code lying around here
>>> looking for similar problems, so thanks again for that one.
>>>
> find_first_zero_bit is not atomic, but the test_and_set_bit, which is what
> counts, is atomic.   That find_first_zero_bit is not atomic confused me 
> about
> this code for a long time, and is why the spin lock was there in the first
> place.  But if there's a race on the find_first_zero_bit and it returns 
> the
> same bit to multiple concurrent threads, only one thread will win the
> test_and_set_bit, and the other threads will go back around the loop to 
> try
> again, and get a different bit.
 Yes.
 But, let's expect just one zero bit at the end of the list. The 
 find_first_zero_bit(ffzb)
 starts now,  thread+1 zeroes a new bit at the beginning, ffzb continues,
 thread+2 takes the zero bit at the end. The result it that ffzb hasn't 
 found a zero bit
 even though that at every moment that bit was there.Ffter that the 
 function returns -EBUSY.
 rc = (u16) find_first_zero_bit(qinfo->request_bits, qinfo->qdepth);
 if (rc >= qinfo->qdepth-1)
return (u16) -EBUSY;
 Still, I think that this is almost impossible, and if it should happen
 a requeue is not so bad.
>>> Oh, wow.  Didn't think of that.  Hmm, technically no guarantee that
>>> any given thread would ever get a bit, if all the other threads keep
>>> snatching them away just ahead of an unlucky thread.
>>>
>>> Could we, instead of giving up, go back around and try again on the theory
>>> that some bits should be free in there someplace and the thread shouldn't
>>> be infinitely unlucky?
>> In theory that gives you also no guarantee, it's likely that for a guarantee 
>> some
>> kind of locking is needed, the spinlock, which already is there, gives you 
>> that. 
>> Otoh, a very high likelihood is probably enough and give better overall 
>> throughput,
>> maybe some statistics/testing is needed? I don't know how much faster is it
>> without the spinlock.
> On thinking about this a bit more, it would be a shame if we closed the
> hole allowing the "cmd_alloc returned NULL" message (the scsi_done() 
> cmd_free()
> race) and then immediately opened up another different hole that permitted the
> same problem to occur. 
>
> So to be safe, I think we should go with your patch as is -- leave
> the spin lock, but get rid of the unnecessary loop.

Thank you.

I was going to write something similar - that we could use my patch as a
temporary solution until a better lockless  is found.

tomash



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

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

Re: [PATCH] pm80xx: Fix for 32 bit compilation issue.

2013-08-07 Thread Tomas Henzl 
On 08/07/2013 09:51 AM, Anand wrote:
> From cc606631fae60a38ab9532bab79fd93523f4c579 Mon Sep 17 00:00:00 2001
> From: Anand Kumar Santhanam 
> Date: Mon, 5 Aug 2013 14:16:52 +0530
> Subject: [PATCH] pm80xx: Fix for 32 bit compilation issue.
>
> pm80xx driver does not compile under 32 bit linux. This patch
> fixes the same.
>
> Signed-off-by: anandkumar.santha...@pmcs.com
>
> ---
>  drivers/scsi/pm8001/pm8001_init.c |5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_init.c 
> b/drivers/scsi/pm8001/pm8001_init.c
> index e4b9bc7..584d04e 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -422,9 +422,10 @@ static int pm8001_ioremap(struct pm8001_hba_info 
> *pm8001_ha)
>   pm8001_printk("PCI: bar %d, logicalBar %d ",
>   bar, logicalBar));
>   PM8001_INIT_DBG(pm8001_ha, pm8001_printk(
> - "base addr %llx virt_addr=%llx len=%d\n",
> + "base addr %llx virt_addr %p len=%d\n",
>   (u64)pm8001_ha->io_mem[logicalBar].membase,
> - (u64)pm8001_ha->io_mem[logicalBar].memvirtaddr,
> + (void __iomem *)

Hi Anand,
the memvirtaddr is of type 'void __iomem*' - is the explicit cast needed?
Tomas 

> + pm8001_ha->io_mem[logicalBar].memvirtaddr,
>   pm8001_ha->io_mem[logicalBar].memsize));
>   } else {
>   pm8001_ha->io_mem[logicalBar].membase   = 0;

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

Re: [PATCH 3/8] [SCSI] dc395x: use NULL instead of 0

2013-08-07 Thread Oliver Neukum 
On Wed, 2013-08-07 at 15:58 +0900, Jingoo Han wrote:
> On Wednesday, August 07, 2013 3:50 PM, Oliver Neukum wrote:
> > On Wed, 2013-08-07 at 12:55 +0900, Jingoo Han wrote:
> > 
> > > @@ -4183,15 +4183,17 @@ static void check_eeprom(struct NvRamType 
> > > *eeprom, unsigned long io_port)
> > >*/
> > >   dprintkl(KERN_WARNING,
> > >   "EEProm checksum error: using default values and 
> > > options.\n");
> > > - eeprom->sub_vendor_id[0] = (u8)PCI_VENDOR_ID_TEKRAM;
> > > + eeprom->sub_vendor_id[0] = (u8)(PCI_VENDOR_ID_TEKRAM & 0xff);
> > 
> > Hi,
> > 
> > if you are fixing these issues please use the proper macros for
> > conversion of endianness.
> 
> Sorry, I cannot understand exactly what you mean. :(
> Would you please let me know which macros can be used?

In this case constant_cpu_to_le16() would be the macro you want.
Have a look at include/uapi/linux/byteorder/

Regards
Oliver



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

Re: [PATCHv3 0/9] New EH command timeout handler

2013-08-07 Thread Hannes Reinecke 
On 08/07/2013 12:08 PM, Ren Mingxin wrote:
> Hi, Hannes:
> 
> On 07/15/2013 02:05 PM, Ren Mingxin wrote:
>> On 07/12/2013 06:27 PM, Hannes Reinecke wrote:
>>> On 07/12/2013 12:00 PM, Ren Mingxin wrote:
 On 07/12/2013 02:09 PM, Hannes Reinecke wrote:
> On 07/12/2013 06:14 AM, Ren Mingxin wrote:
>> On 07/01/2013 10:24 PM, Hannes Reinecke wrote:
>>> With the original SCSI EH I got:
>>> # time dd if=/dev/zero of=/dev/dm-2 bs=4k count=4k oflag=direct
>>> 4096+0 records in
>>> 4096+0 records out
>>> 16777216 bytes (17 MB) copied, 142.652 s, 118 kB/s
>>>
>>> real2m22.657s
>>> user0m0.013s
>>> sys0m0.145s
>>>
>>> With this patchset I got:
>>> # time dd if=/dev/zero of=/dev/dm-2 bs=4k count=4k oflag=direct
>>> 4096+0 records in
>>> 4096+0 records out
>>> 16777216 bytes (17 MB) copied, 52.1579 s, 322 kB/s
>>>
>>> real0m52.163s
>>> user0m0.012s
>>> sys0m0.145s
>>>
>>> Test was to disable RSCN on the target port, disable the
>>> target port, and then start the 'dd' command as indicated.
>>
>> Do you mean disabling RSCN/port is enough? I'm afraid I couldn't
>> reproduce the problem by your steps. Both with and without your
>> patchset are the same 'dd' result: 27s. Please let me know
>> where I
>> neglected or mistook:
>>
>> 1) I made a dm-multipath target 'dm-0' whose grouping policy was
>>  failover;
>> 2) Disable RSCN/port via brocade fc switch:
>>  SW300:root>   portcfg rscnsupr 15 --enable; portDisable 15
>> 3) Start the 'dd' command:
>>  # time dd if=/dev/zero of=/dev/dm-0 bs=4k count=4k
>> oflag=direct
>>  dd: writing `/dev/sde': Input/output error
>>  1+0 records in
>>  0+0 records out
>>  0 bytes (0 B) copied, 27.8588 s, 0.0 kB/s
>>
>>  real0m27.860s
>>  user0m0.001s
>>  sys 0m0.000s
>
> You are aware that you have to disable RSCNs on the _target_ port,
> right?
> Disabling RSCNs on the _initiator_ ports is a well-tested case,
> and
> the one which actually makes sense (and is even implemented in
> QLogic switches).
> Disabling RSCNs for the _target_ port, OTOH, has a very
> questionable
> nature (hence QLogic switches don't even allow you to do this).

 You're right. By disabling RSCNs on target port, I've reproduced
 this
 problem. Thank you so much. But I've encountered the bug I said
 before. I'll test again with your new patchset once you send.

>>>
>>> Could you check with the attached patch? That should convert it to
>>> delayed_work and avoid this issue.
>>
>> Unfortunately, the login prompt couldn't be entered in and BUGs were
>> printed ceaselessly while os booting with this patch. The BUGs are
>> like below:
>>
>> BUG: scheduling while atomic: swapper/0/0/0x1100
>> Modules linked in: mptsas(F+) mptscsih(F) mptbase(F)
>> scsi_transport_sas(F)
>> CPU: 0 PID: 0 Comm: swapper/0 Tainted: GF3.10.0hannes+
>> #10
>> Hardware name: FUJITSU-SV PRIMEQUEST 1800E/SB-8GDIMM-CN, BIOS
>> PRIMEQUEST 1000 Series BIOS Version 1.39 11/16/2012
>>   88047ee03b68 8153ada4 88047ee03b78
>>  8107389d 88047ee03c08 8153ca26 81a01fd8
>>  00012d00 81a00010 00012d00 00012d00
>> Call Trace:
>>   [] dump_stack+0x19/0x1d
>>  [] __schedule_bug+0x4d/0x60
>>  [] __schedule+0x646/0x6f0
>>  [] __cond_resched+0x2a/0x40
>>  [] _cond_resched+0x30/0x40
>>  [] start_flush_work+0x2c/0x140
>>  [] flush_work+0x1a/0x40
>>  [] ? try_to_grab_pending+0x109/0x190
>>  [] __cancel_work_timer+0x7e/0x110
>>  [] cancel_delayed_work_sync+0x13/0x20
>>  [] scsi_put_command+0x65/0xa0
> 
> This bug is caused by the sync function 'cancel_delayed_work_sync'
> which is invoked in the interrupt context. By replacing it by non-
> sync function 'cancel_delayed_work' in 'scsi_put_command' can avoid.
> 
> Do you think there is such need to sync in the function 'scsi_put_
> command'? Since SCSI command block will be freed here, it is NOT
> necessary to wait for the abort work to finish on it, yes?
> 
You are right, cancel_delayed_work() should be sufficient here.

I'll give it a spin and repost the patchset.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke   zSeries & Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 0/9] New EH command timeout handler

2013-08-07 Thread Ren Mingxin 

Hi, Hannes:

On 07/15/2013 02:05 PM, Ren Mingxin wrote:

On 07/12/2013 06:27 PM, Hannes Reinecke wrote:

On 07/12/2013 12:00 PM, Ren Mingxin wrote:

On 07/12/2013 02:09 PM, Hannes Reinecke wrote:

On 07/12/2013 06:14 AM, Ren Mingxin wrote:

On 07/01/2013 10:24 PM, Hannes Reinecke wrote:

With the original SCSI EH I got:
# time dd if=/dev/zero of=/dev/dm-2 bs=4k count=4k oflag=direct
4096+0 records in
4096+0 records out
16777216 bytes (17 MB) copied, 142.652 s, 118 kB/s

real2m22.657s
user0m0.013s
sys0m0.145s

With this patchset I got:
# time dd if=/dev/zero of=/dev/dm-2 bs=4k count=4k oflag=direct
4096+0 records in
4096+0 records out
16777216 bytes (17 MB) copied, 52.1579 s, 322 kB/s

real0m52.163s
user0m0.012s
sys0m0.145s

Test was to disable RSCN on the target port, disable the
target port, and then start the 'dd' command as indicated.


Do you mean disabling RSCN/port is enough? I'm afraid I couldn't
reproduce the problem by your steps. Both with and without your
patchset are the same 'dd' result: 27s. Please let me know where I
neglected or mistook:

1) I made a dm-multipath target 'dm-0' whose grouping policy was
 failover;
2) Disable RSCN/port via brocade fc switch:
 SW300:root>   portcfg rscnsupr 15 --enable; portDisable 15
3) Start the 'dd' command:
 # time dd if=/dev/zero of=/dev/dm-0 bs=4k count=4k oflag=direct
 dd: writing `/dev/sde': Input/output error
 1+0 records in
 0+0 records out
 0 bytes (0 B) copied, 27.8588 s, 0.0 kB/s

 real0m27.860s
 user0m0.001s
 sys 0m0.000s


You are aware that you have to disable RSCNs on the _target_ port,
right?
Disabling RSCNs on the _initiator_ ports is a well-tested case, and
the one which actually makes sense (and is even implemented in
QLogic switches).
Disabling RSCNs for the _target_ port, OTOH, has a very questionable
nature (hence QLogic switches don't even allow you to do this).


You're right. By disabling RSCNs on target port, I've reproduced this
problem. Thank you so much. But I've encountered the bug I said
before. I'll test again with your new patchset once you send.



Could you check with the attached patch? That should convert it to
delayed_work and avoid this issue.


Unfortunately, the login prompt couldn't be entered in and BUGs were
printed ceaselessly while os booting with this patch. The BUGs are
like below:

BUG: scheduling while atomic: swapper/0/0/0x1100
Modules linked in: mptsas(F+) mptscsih(F) mptbase(F) 
scsi_transport_sas(F)

CPU: 0 PID: 0 Comm: swapper/0 Tainted: GF3.10.0hannes+ #10
Hardware name: FUJITSU-SV PRIMEQUEST 1800E/SB-8GDIMM-CN, BIOS 
PRIMEQUEST 1000 Series BIOS Version 1.39 11/16/2012

  88047ee03b68 8153ada4 88047ee03b78
 8107389d 88047ee03c08 8153ca26 81a01fd8
 00012d00 81a00010 00012d00 00012d00
Call Trace:
  [] dump_stack+0x19/0x1d
 [] __schedule_bug+0x4d/0x60
 [] __schedule+0x646/0x6f0
 [] __cond_resched+0x2a/0x40
 [] _cond_resched+0x30/0x40
 [] start_flush_work+0x2c/0x140
 [] flush_work+0x1a/0x40
 [] ? try_to_grab_pending+0x109/0x190
 [] __cancel_work_timer+0x7e/0x110
 [] cancel_delayed_work_sync+0x13/0x20
 [] scsi_put_command+0x65/0xa0


This bug is caused by the sync function 'cancel_delayed_work_sync'
which is invoked in the interrupt context. By replacing it by non-
sync function 'cancel_delayed_work' in 'scsi_put_command' can avoid.

Do you think there is such need to sync in the function 'scsi_put_
command'? Since SCSI command block will be freed here, it is NOT
necessary to wait for the abort work to finish on it, yes?

Thanks,
Ren


 [] scsi_next_command+0x3a/0x60
 [] scsi_end_request+0xab/0xb0
 [] scsi_io_completion+0x9f/0x670
 [] scsi_finish_command+0xd4/0x140
 [] scsi_softirq_done+0x147/0x170
 [] blk_done_softirq+0x74/0x90
 [] __do_softirq+0xef/0x260
 [] irq_exit+0xb5/0xc0
 [] do_IRQ+0x66/0xe0
 [] common_interrupt+0x6a/0x6a
  [] ? clockevents_notify+0x52/0x150
 [] ? cpuidle_enter_state+0x53/0xd0
 [] ? cpuidle_enter_state+0x4f/0xd0
 [] cpuidle_idle_call+0xcf/0x160
 [] arch_cpu_idle+0xe/0x30
 [] cpu_idle_loop+0x65/0x1f0
 [] cpu_startup_entry+0x70/0x80
 [] rest_init+0x77/0x80
 [] start_kernel+0x41a/0x427
 [] ? repair_env_string+0x5b/0x5b
 [] x86_64_start_reservations+0x2a/0x2c
 [] x86_64_start_kernel+0x12f/0x136


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

Re: [PATCH 3/8] [SCSI] dc395x: use NULL instead of 0

2013-08-07 Thread Jingoo Han 
On Wed, Wednesday, August 07, 2013 5:40 PM, Julian Calaby > wrote:
> On Wed, Aug 7, 2013 at 6:36 PM, Jingoo Han  wrote:
> > On Wednesday, August 07, 2013 5:21 PM, Julian Calaby wrote:
> >> On Wed, Aug 7, 2013 at 5:45 PM, Jingoo Han  wrote:
> >> > On Wednesday, August 07, 2013 3:50 PM, Oliver Neukum wrote:
> >> >> On Wed, 2013-08-07 at 12:55 +0900, Jingoo Han wrote:
> >> >>
> >> >> > @@ -4183,15 +4183,17 @@ static void check_eeprom(struct NvRamType 
> >> >> > *eeprom, unsigned long
> io_port)
> >> >> >  */
> >> >> > dprintkl(KERN_WARNING,
> >> >> > "EEProm checksum error: using default values and 
> >> >> > options.\n");
> >> >> > -   eeprom->sub_vendor_id[0] = (u8)PCI_VENDOR_ID_TEKRAM;
> >> >> > +   eeprom->sub_vendor_id[0] = (u8)(PCI_VENDOR_ID_TEKRAM & 
> >> >> > 0xff);
> >> >>
> >> >> Hi,
> >> >>
> >> >> if you are fixing these issues please use the proper macros for
> >> >> conversion of endianness.
> >> >
> >> > Then, do you mean the following? :)
> >> >
> >> > -   prom->sub_vendor_id[0] = (u8)PCI_VENDOR_ID_TEKRAM;
> >> > +   eprom->sub_vendor_id[0] = (u8)(PCI_VENDOR_ID_TEKRAM & 
> >> > le16_to_cpu(0xff));
> >>
> >> No.
> >>
> >> The issue is that the driver is doing things like this:
> >>
> >> eeprom->member[0] = (u8)(CONSTANT & 0xff);
> >> eeprom->member[1] = (u8)(CONSTANT >> 8);
> >>
> >> Which is exactly the same as code along the lines of:
> >>
> >> eeprom->member = cpu_to_le16(CONSTANT);
> >
> > However, when I compile the following, it makes build error.
> >
> > -   eeprom->sub_vendor_id[0] = (u8)(PCI_VENDOR_ID_TEKRAM & 
> > 0xff);
> > -   eeprom->sub_vendor_id[1] = (u8)(PCI_VENDOR_ID_TEKRAM >> 8);
> > +   eeprom->sub_vendor_id = cpu_to_le16(PCI_VENDOR_ID_TEKRAM);
> 
> Of course it does.
> 
> I said code along the lines of. You'll need to do more than just what
> I suggested, including changing the definition of the eeprom struct
> and fixing any other places where it's used / set.

I fixed it as below. In this case, it does not make any warnings.
Oliver Neukum, do you mean the following?

struct NvRamType {
-   u8 sub_vendor_id[2];/* 0,1  Sub Vendor ID   */
+   u16 sub_vendor_id;  /* 0,1  Sub Vendor ID   */

-   eeprom->sub_vendor_id[0] = (u8)(PCI_VENDOR_ID_TEKRAM & 0xff);
-   eeprom->sub_vendor_id[1] = (u8)(PCI_VENDOR_ID_TEKRAM >> 8);
+   eeprom->sub_vendor_id = cpu_to_le16(PCI_VENDOR_ID_TEKRAM);

Best regards,
Jingoo Han


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

Re: [PATCH 3/8] [SCSI] dc395x: use NULL instead of 0

2013-08-07 Thread Julian Calaby 
Hi Jingoo,

On Wed, Aug 7, 2013 at 6:36 PM, Jingoo Han  wrote:
>
>
>> -Original Message-
>> From: Julian Calaby [mailto:julian.cal...@gmail.com]
>> Sent: Wednesday, August 07, 2013 5:21 PM
>> To: Jingoo Han
>> Cc: Oliver Neukum; James Bottomley; Ali Akcaagac; Jamie Lenehan; 
>> dc3...@twibble.org; James Bottomley;
>> linux-scsi
>> Subject: Re: [PATCH 3/8] [SCSI] dc395x: use NULL instead of 0
>>
>> Hi Jingoo,
>>
>> On Wed, Aug 7, 2013 at 5:45 PM, Jingoo Han  wrote:
>> > On Wednesday, August 07, 2013 3:50 PM, Oliver Neukum wrote:
>> >> On Wed, 2013-08-07 at 12:55 +0900, Jingoo Han wrote:
>> >>
>> >> > @@ -4183,15 +4183,17 @@ static void check_eeprom(struct NvRamType 
>> >> > *eeprom, unsigned long io_port)
>> >> >  */
>> >> > dprintkl(KERN_WARNING,
>> >> > "EEProm checksum error: using default values and 
>> >> > options.\n");
>> >> > -   eeprom->sub_vendor_id[0] = (u8)PCI_VENDOR_ID_TEKRAM;
>> >> > +   eeprom->sub_vendor_id[0] = (u8)(PCI_VENDOR_ID_TEKRAM & 
>> >> > 0xff);
>> >>
>> >> Hi,
>> >>
>> >> if you are fixing these issues please use the proper macros for
>> >> conversion of endianness.
>> >
>> > Then, do you mean the following? :)
>> >
>> > -   prom->sub_vendor_id[0] = (u8)PCI_VENDOR_ID_TEKRAM;
>> > +   eprom->sub_vendor_id[0] = (u8)(PCI_VENDOR_ID_TEKRAM & 
>> > le16_to_cpu(0xff));
>>
>> No.
>>
>> The issue is that the driver is doing things like this:
>>
>> eeprom->member[0] = (u8)(CONSTANT & 0xff);
>> eeprom->member[1] = (u8)(CONSTANT >> 8);
>>
>> Which is exactly the same as code along the lines of:
>>
>> eeprom->member = cpu_to_le16(CONSTANT);
>
> However, when I compile the following, it makes build error.
>
> -   eeprom->sub_vendor_id[0] = (u8)(PCI_VENDOR_ID_TEKRAM & 0xff);
> -   eeprom->sub_vendor_id[1] = (u8)(PCI_VENDOR_ID_TEKRAM >> 8);
> +   eeprom->sub_vendor_id = cpu_to_le16(PCI_VENDOR_ID_TEKRAM);

Of course it does.

I said code along the lines of. You'll need to do more than just what
I suggested, including changing the definition of the eeprom struct
and fixing any other places where it's used / set.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/8] [SCSI] dc395x: use NULL instead of 0

2013-08-07 Thread Jingoo Han 


> -Original Message-
> From: Julian Calaby [mailto:julian.cal...@gmail.com]
> Sent: Wednesday, August 07, 2013 5:21 PM
> To: Jingoo Han
> Cc: Oliver Neukum; James Bottomley; Ali Akcaagac; Jamie Lenehan; 
> dc3...@twibble.org; James Bottomley;
> linux-scsi
> Subject: Re: [PATCH 3/8] [SCSI] dc395x: use NULL instead of 0
> 
> Hi Jingoo,
> 
> On Wed, Aug 7, 2013 at 5:45 PM, Jingoo Han  wrote:
> > On Wednesday, August 07, 2013 3:50 PM, Oliver Neukum wrote:
> >> On Wed, 2013-08-07 at 12:55 +0900, Jingoo Han wrote:
> >>
> >> > @@ -4183,15 +4183,17 @@ static void check_eeprom(struct NvRamType 
> >> > *eeprom, unsigned long io_port)
> >> >  */
> >> > dprintkl(KERN_WARNING,
> >> > "EEProm checksum error: using default values and 
> >> > options.\n");
> >> > -   eeprom->sub_vendor_id[0] = (u8)PCI_VENDOR_ID_TEKRAM;
> >> > +   eeprom->sub_vendor_id[0] = (u8)(PCI_VENDOR_ID_TEKRAM & 0xff);
> >>
> >> Hi,
> >>
> >> if you are fixing these issues please use the proper macros for
> >> conversion of endianness.
> >
> > Then, do you mean the following? :)
> >
> > -   prom->sub_vendor_id[0] = (u8)PCI_VENDOR_ID_TEKRAM;
> > +   eprom->sub_vendor_id[0] = (u8)(PCI_VENDOR_ID_TEKRAM & 
> > le16_to_cpu(0xff));
> 
> No.
> 
> The issue is that the driver is doing things like this:
> 
> eeprom->member[0] = (u8)(CONSTANT & 0xff);
> eeprom->member[1] = (u8)(CONSTANT >> 8);
> 
> Which is exactly the same as code along the lines of:
> 
> eeprom->member = cpu_to_le16(CONSTANT);

However, when I compile the following, it makes build error.

-   eeprom->sub_vendor_id[0] = (u8)(PCI_VENDOR_ID_TEKRAM & 0xff);
-   eeprom->sub_vendor_id[1] = (u8)(PCI_VENDOR_ID_TEKRAM >> 8);
+   eeprom->sub_vendor_id = cpu_to_le16(PCI_VENDOR_ID_TEKRAM);

Best regards,
Jingoo Han

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

Re: [PATCH 3/8] [SCSI] dc395x: use NULL instead of 0

2013-08-07 Thread Julian Calaby 
Hi Jingoo,

On Wed, Aug 7, 2013 at 5:45 PM, Jingoo Han  wrote:
> On Wednesday, August 07, 2013 3:50 PM, Oliver Neukum wrote:
>> On Wed, 2013-08-07 at 12:55 +0900, Jingoo Han wrote:
>>
>> > @@ -4183,15 +4183,17 @@ static void check_eeprom(struct NvRamType *eeprom, 
>> > unsigned long io_port)
>> >  */
>> > dprintkl(KERN_WARNING,
>> > "EEProm checksum error: using default values and 
>> > options.\n");
>> > -   eeprom->sub_vendor_id[0] = (u8)PCI_VENDOR_ID_TEKRAM;
>> > +   eeprom->sub_vendor_id[0] = (u8)(PCI_VENDOR_ID_TEKRAM & 0xff);
>>
>> Hi,
>>
>> if you are fixing these issues please use the proper macros for
>> conversion of endianness.
>
> Then, do you mean the following? :)
>
> -   prom->sub_vendor_id[0] = (u8)PCI_VENDOR_ID_TEKRAM;
> +   eprom->sub_vendor_id[0] = (u8)(PCI_VENDOR_ID_TEKRAM & 
> le16_to_cpu(0xff));

No.

The issue is that the driver is doing things like this:

eeprom->member[0] = (u8)(CONSTANT & 0xff);
eeprom->member[1] = (u8)(CONSTANT >> 8);

Which is exactly the same as code along the lines of:

eeprom->member = cpu_to_le16(CONSTANT);

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] pm80xx: Fix for 32 bit compilation issue.

2013-08-07 Thread Anand 
>From cc606631fae60a38ab9532bab79fd93523f4c579 Mon Sep 17 00:00:00 2001
From: Anand Kumar Santhanam 
Date: Mon, 5 Aug 2013 14:16:52 +0530
Subject: [PATCH] pm80xx: Fix for 32 bit compilation issue.

pm80xx driver does not compile under 32 bit linux. This patch
fixes the same.

Signed-off-by: anandkumar.santha...@pmcs.com

---
 drivers/scsi/pm8001/pm8001_init.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/pm8001/pm8001_init.c 
b/drivers/scsi/pm8001/pm8001_init.c
index e4b9bc7..584d04e 100644
--- a/drivers/scsi/pm8001/pm8001_init.c
+++ b/drivers/scsi/pm8001/pm8001_init.c
@@ -422,9 +422,10 @@ static int pm8001_ioremap(struct pm8001_hba_info 
*pm8001_ha)
pm8001_printk("PCI: bar %d, logicalBar %d ",
bar, logicalBar));
PM8001_INIT_DBG(pm8001_ha, pm8001_printk(
-   "base addr %llx virt_addr=%llx len=%d\n",
+   "base addr %llx virt_addr %p len=%d\n",
(u64)pm8001_ha->io_mem[logicalBar].membase,
-   (u64)pm8001_ha->io_mem[logicalBar].memvirtaddr,
+   (void __iomem *)
+   pm8001_ha->io_mem[logicalBar].memvirtaddr,
pm8001_ha->io_mem[logicalBar].memsize));
} else {
pm8001_ha->io_mem[logicalBar].membase   = 0;
-- 
1.7.1

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

[Bug 60711] New: USB drive no longer detected as removable storage media

2013-08-07 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=60711

Bug ID: 60711
   Summary: USB drive no longer detected as removable storage
media
   Product: IO/Storage
   Version: 2.5
Kernel Version: 3.10.3
  Hardware: i386
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: low
  Priority: P1
 Component: SCSI
  Assignee: linux-scsi@vger.kernel.org
  Reporter: trall...@onlinehome.de
Regression: No

Created attachment 107132
  --> https://bugzilla.kernel.org/attachment.cgi?id=107132&action=edit
DMESG excerpt from success and failure

This patch

commit 98dcc2946adbe4349ef1ef9b99873b912831edd4
Author: Martin K. Petersen 
Date:   Thu Jun 6 22:15:55 2013 -0400
SCSI: sd: Update WRITE SAME heuristics
commit 66c28f97120e8a621afd5aa7a31c4b85c547d33d upstream.

introduced with kernel patch-3.10.3 effectively breaks detection of some USB
drives as removable storage media. The concerned drives are recognized by the
SCSI layer, but are no longer available as removable storage (see attachment).

Commenting out the following if-clause from sd.c (function sd_read_write_same)
if (!scsi_get_vpd_page(sdev, 0x89, buffer, SD_BUF_SIZE))
sdev->no_write_same = 1;
makes anything working as expected.

-- 
You are receiving this mail because:
You are the assignee for the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/8] [SCSI] dc395x: use NULL instead of 0

2013-08-07 Thread Jingoo Han 
On Wednesday, August 07, 2013 3:50 PM, Oliver Neukum wrote:
> On Wed, 2013-08-07 at 12:55 +0900, Jingoo Han wrote:
> 
> > @@ -4183,15 +4183,17 @@ static void check_eeprom(struct NvRamType *eeprom, 
> > unsigned long io_port)
> >  */
> > dprintkl(KERN_WARNING,
> > "EEProm checksum error: using default values and 
> > options.\n");
> > -   eeprom->sub_vendor_id[0] = (u8)PCI_VENDOR_ID_TEKRAM;
> > +   eeprom->sub_vendor_id[0] = (u8)(PCI_VENDOR_ID_TEKRAM & 0xff);
> 
> Hi,
> 
> if you are fixing these issues please use the proper macros for
> conversion of endianness.

Then, do you mean the following? :)

-   prom->sub_vendor_id[0] = (u8)PCI_VENDOR_ID_TEKRAM;
+   eprom->sub_vendor_id[0] = (u8)(PCI_VENDOR_ID_TEKRAM & 
le16_to_cpu(0xff));


Best regards,
Jingoo Han


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