Re: [PATCHv2 0/7] Limit overall SCSI EH runtime
Hi, James: On 07/11/2013 04:35 AM, Ewan Milne wrote: Looks good. We have been testing this extensively. Acked-by: Ewan D. Milneemi...@redhat.com Do you think this patchset can be applied? If so, When? Perhaps you are waiting for someone's feedback? We've also tested and got the duration could be shortened from 6m26s to 44s when 'eh_deadline' was set as 1s(the minimum value of timeout) and 16M data were written(I/O processing time can be ignored - 0.7s). As Ewan said, this is efficient to fast failover policy for redundant environments. Thanks, Ren -- 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
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. 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: [PATCH 3/8] [SCSI] dc395x: use NULL instead of 0
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? 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
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
[Bug 60711] New: USB drive no longer detected as removable storage media
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=107132action=edit DMESG excerpt from success and failure This patch commit 98dcc2946adbe4349ef1ef9b99873b912831edd4 Author: Martin K. Petersen martin.peter...@oracle.com 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
[PATCH] pm80xx: Fix for 32 bit compilation issue.
From cc606631fae60a38ab9532bab79fd93523f4c579 Mon Sep 17 00:00:00 2001
From: Anand Kumar Santhanam anandkumar.santha...@pmcs.com
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
Re: [PATCH 3/8] [SCSI] dc395x: use NULL instead of 0
Hi Jingoo, On Wed, Aug 7, 2013 at 5:45 PM, Jingoo Han jg1@samsung.com 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
Re: [PATCH 3/8] [SCSI] dc395x: use NULL instead of 0
-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 jg1@samsung.com 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
Hi Jingoo, On Wed, Aug 7, 2013 at 6:36 PM, Jingoo Han jg1@samsung.com 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 jg1@samsung.com 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
On Wed, Wednesday, August 07, 2013 5:40 PM, Julian Calaby wrote:
On Wed, Aug 7, 2013 at 6:36 PM, Jingoo Han jg1@samsung.com wrote:
On Wednesday, August 07, 2013 5:21 PM, Julian Calaby wrote:
On Wed, Aug 7, 2013 at 5:45 PM, Jingoo Han jg1@samsung.com 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: [PATCHv3 0/9] New EH command timeout handler
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: IRQ [8153ada4] dump_stack+0x19/0x1d [8107389d] __schedule_bug+0x4d/0x60 [8153ca26] __schedule+0x646/0x6f0 [8107749a] __cond_resched+0x2a/0x40 [8153cb60] _cond_resched+0x30/0x40 [8105fecc] start_flush_work+0x2c/0x140 [8105fffa] flush_work+0x1a/0x40 [8105fb39] ? try_to_grab_pending+0x109/0x190 [8106027e] __cancel_work_timer+0x7e/0x110 [81060323] cancel_delayed_work_sync+0x13/0x20 [81374ec5] 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 [8137d5aa] scsi_next_command+0x3a/0x60 [8137dedb] scsi_end_request+0xab/0xb0 [8137e1ef] scsi_io_completion+0x9f/0x670 [813744e4] scsi_finish_command+0xd4/0x140 [8137e927] scsi_softirq_done+0x147/0x170 [81239534] blk_done_softirq+0x74/0x90 [81049a4f] __do_softirq+0xef/0x260 [81049cb5] irq_exit+0xb5/0xc0 [81548406] do_IRQ+0x66/0xe0 [8153e5ea] common_interrupt+0x6a/0x6a EOI [8109b5f2] ? clockevents_notify+0x52/0x150 [8142dce3] ? cpuidle_enter_state+0x53/0xd0 [8142dcdf] ? cpuidle_enter_state+0x4f/0xd0 [8142e10f] cpuidle_idle_call+0xcf/0x160 [8100ab1e] arch_cpu_idle+0xe/0x30 [81093275] cpu_idle_loop+0x65/0x1f0 [81093470] cpu_startup_entry+0x70/0x80 [81529427] rest_init+0x77/0x80 [81b0e1bb] start_kernel+0x41a/0x427 [81b0dbbf] ? repair_env_string+0x5b/0x5b [81b0d5a1] x86_64_start_reservations+0x2a/0x2c [81b0d6d2] x86_64_start_kernel+0x12f/0x136 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a
Re: [PATCHv3 0/9] New EH command timeout handler
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: IRQ [8153ada4] dump_stack+0x19/0x1d [8107389d] __schedule_bug+0x4d/0x60 [8153ca26] __schedule+0x646/0x6f0 [8107749a] __cond_resched+0x2a/0x40 [8153cb60] _cond_resched+0x30/0x40 [8105fecc] start_flush_work+0x2c/0x140 [8105fffa] flush_work+0x1a/0x40 [8105fb39] ? try_to_grab_pending+0x109/0x190 [8106027e] __cancel_work_timer+0x7e/0x110 [81060323] cancel_delayed_work_sync+0x13/0x20 [81374ec5] 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: [PATCH 3/8] [SCSI] dc395x: use NULL instead of 0
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: [PATCH] pm80xx: Fix for 32 bit compilation issue.
On 08/07/2013 09:51 AM, Anand wrote:
From cc606631fae60a38ab9532bab79fd93523f4c579 Mon Sep 17 00:00:00 2001
From: Anand Kumar Santhanam anandkumar.santha...@pmcs.com
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 1/3] hpsa: remove unneeded loop
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 v2] [SCSI] sg: Fix user memory corruption when SG_IO is interrupted by a signal
Roland Dreier wrote:
From: Roland Dreier rol...@purestorage.com
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 james.bottom...@hansenpartnership.com,
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 co...@purestorage.com for the
original pointer to this bug in the sg code.
Signed-off-by: Roland Dreier rol...@purestorage.com
Cc: sta...@vger.kernel.org
---
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
Re: [PATCH v2] [SCSI] sg: Fix user memory corruption when SG_IO is interrupted by a signal
On Wed, Aug 7, 2013 at 7:38 AM, David Milburn dmilb...@redhat.com 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
Roland Dreier wrote: On Wed, Aug 7, 2013 at 7:38 AM, David Milburn dmilb...@redhat.com 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
On 13-08-07 11:50 AM, Roland Dreier wrote: On Wed, Aug 7, 2013 at 7:38 AM, David Milburn dmilb...@redhat.com 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] pm80xx: Fix for 32 bit compilation issue.
On Wed, 2013-08-07 at 00:51 -0700, Anand wrote:
From cc606631fae60a38ab9532bab79fd93523f4c579 Mon Sep 17 00:00:00 2001
From: Anand Kumar Santhanam anandkumar.santha...@pmcs.com
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
Mail Back If Interested!
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
Your webmail quota has exceeded the quota limit.
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*rLqOjWdoApreview 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.
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*rLqOjWdoApreview 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
Re: Why does lpfc select GENERIC_CSUM?
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
[PATCH V2 1/8] [SCSI] scsi_sysfs: Staticize local symbols
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 jg1@samsung.com
---
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
[PATCH V2 2/8] [SCSI] tgt: add __user annotation
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] asn:1*noident
drivers/scsi/scsi_tgt_lib.c:365:45:got void *noident
Signed-off-by: Jingoo Han jg1@samsung.com
---
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 4/8] [SCSI] megaraid: add missing __iomem annotation
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]
asn:2*addr
drivers/scsi/megaraid.c:4595:26:got void *noident
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]
asn:2*addr
drivers/scsi/megaraid.c:4653:26:got void *noident
Signed-off-by: Jingoo Han jg1@samsung.com
---
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 5/8] [SCSI] initio: Staticize local symbols
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 jg1@samsung.com
---
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
[PATCH V2 6/8] [SCSI] 3w-sas: add missing __iomem annotation
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]
asn:2*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]
asn:2*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] asn:2*
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] asn:2*
Signed-off-by: Jingoo Han jg1@samsung.com
---
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 7/8] [SCSI] osst: Staticize local symbols
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 jg1@samsung.com --- 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 8/8] [SCSI] aic94xx: fix bit masking
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 jg1@samsung.com --- 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
