[PATCH v1 16/47] fusion: use __arch_phys_wc_add()
From: Luis R. Rodriguez mcg...@suse.com
If and when this gets enabled the driver should address
using ioremap_wc() on the same area, that could require
a bit of work as it would mean a split with two ioremap'd
areas. Annotate this.
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Nagalakshmi Nandigama nagalakshmi.nandig...@avagotech.com
Cc: Praveen Krishnamoorthy praveen.krishnamoor...@avagotech.com
Cc: Sreekanth Reddy sreekanth.re...@avagotech.com
Cc: Abhijit Mahajan abhijit.maha...@avagotech.com
Cc: Juergen Gross jgr...@suse.com
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: mpt-fusionlinux@avagotech.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/message/fusion/mptbase.c | 19 ---
drivers/message/fusion/mptbase.h | 2 +-
2 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 187f836..c7b1a55 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -59,10 +59,6 @@
#include linux/delay.h
#include linux/interrupt.h /* needed for in_interrupt() proto */
#include linux/dma-mapping.h
-#include asm/io.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
#include linux/kthread.h
#include scsi/scsi_host.h
@@ -2820,11 +2816,8 @@ mpt_adapter_dispose(MPT_ADAPTER *ioc)
pci_disable_device(ioc-pcidev);
pci_release_selected_regions(ioc-pcidev, ioc-bars);
-#if defined(CONFIG_MTRR) 0
- if (ioc-mtrr_reg 0) {
- mtrr_del(ioc-mtrr_reg, 0, 0);
- dprintk(ioc, printk(MYIOC_s_INFO_FMT MTRR region
de-registered\n, ioc-name));
- }
+#if 0
+ __arch_phys_wc_del(ioc-wc_cookie);
#endif
/* Zap the adapter lookup ptr! */
@@ -4512,17 +4505,13 @@ PrimeIocFifos(MPT_ADAPTER *ioc)
ioc-req_frames_low_dma = (u32) (alloc_dma 0x);
-#if defined(CONFIG_MTRR) 0
+#if 0
/*
* Enable Write Combining MTRR for IOC's memory region.
* (at least as much as we can; size and base must be
* multiples of 4 kiB
*/
- ioc-mtrr_reg = mtrr_add(ioc-req_frames_dma,
-sz,
-MTRR_TYPE_WRCOMB, 1);
- dprintk(ioc, printk(MYIOC_s_DEBUG_FMT MTRR region registered
(base:size=%08x:%x)\n,
- ioc-name, ioc-req_frames_dma, sz));
+ ioc-wc_cookie = arch_phys_wc_add(ioc-req_frames_dma, sz);
#endif
for (i = 0; i ioc-req_depth; i++) {
diff --git a/drivers/message/fusion/mptbase.h b/drivers/message/fusion/mptbase.h
index 8f14090..f0bff11 100644
--- a/drivers/message/fusion/mptbase.h
+++ b/drivers/message/fusion/mptbase.h
@@ -671,7 +671,7 @@ typedef struct _MPT_ADAPTER
u8 *HostPageBuffer; /* SAS - host page buffer
support */
u32 HostPageBuffer_sz;
dma_addr_t HostPageBuffer_dma;
- int mtrr_reg;
+ int wc_cookie;
struct pci_dev *pcidev;/* struct pci_dev pointer */
int bars; /* bitmask of BAR's that must
be configured */
int msi_enable;
--
2.3.2.209.gd67f9d5.dirty
--
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: iSCSI regression with linux 3.9 and 4.0
On Fri, 2015-03-20 at 13:57 +0100, Christian Hesse wrote: Hello everybody! I reported this issue at LKML [0] but received no answer. Hopefully linux-scsi is a better place... Beginning with linux 3.19 I see an iSCSI regressen. This works perfectly with linux 3.18.x (tested with 3.18.6) and before. Effected kernels I tested are 3.19.0, 3.19.2 and 4.0rc4.r199.gb314aca. The logs tell the story: Feb 19 11:26:49 thebe kernel: scsi host6: iSCSI Initiator over TCP/IP Feb 19 11:26:49 thebe kernel: scsi 6:0:0:0: Direct-Access QNAP iSCSI Storage4.0 PQ: 0 ANSI: 5 Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] 1073741824 512-byte logical blocks: (549 GB/512 GiB) Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Write Protect is off Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Mode Sense: 2f 00 00 00 Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA Feb 19 11:26:49 thebe kernel: sdb: unknown partition table Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Attached SCSI disk Feb 19 11:26:49 thebe iscsid[10804]: Connection1:0 to [target: iqn.2004-04.com.qnap:ts-859:iscsi.xxx.c40a18, portal: xx.xx.xx.xx,3260] through [iface: default] is operational now Feb 19 11:26:57 thebe kernel: sdb: unknown partition table Feb 19 11:28:20 thebe kernel: EXT4-fs (dm-8): mounting with discard option, but the device does not support discard Feb 19 11:28:20 thebe kernel: EXT4-fs (dm-8): mounted filesystem with ordered data mode. Opts: (null) Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] UNKNOWN Result: hostbyte=0x00 driverbyte=0x08 Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] Sense Key : 0x5 [current] Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] ASC=0x24 ASCQ=0x0 Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] CDB: Feb 19 11:28:24 thebe kernel: cdb[0]=0x2a: 2a 00 34 5b 07 ff 00 2f 88 00 Feb 19 11:28:24 thebe kernel: blk_update_request: critical target error, dev sdb, sector 878381055 Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting block 108749056) Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749056 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749057 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749058 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749059 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749060 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749061 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749062 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749063 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749064 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749065 Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting block 108749312) Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting block 108749568) Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting block 108749824) Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting block 108750080) Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting block 108750336) Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] UNKNOWN Result: hostbyte=0x00 driverbyte=0x08 Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] Sense Key : 0x5 [current] Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] ASC=0x24 ASCQ=0x0 Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] CDB: Feb 19 11:29:10 thebe kernel: cdb[0]=0x2a: 2a 00 20 44 89 17 00 20 50 00 Feb 19 11:29:10 thebe kernel: blk_update_request: critical target error, dev sdb, sector 541362455 Feb 19 11:29:10 thebe kernel: Buffer I/O error on dev dm-8, logical block 66621731, lost sync page write Feb 19 11:29:10 thebe kernel: Aborting journal on device dm-8-8. Feb 19 11:29:10 thebe kernel: EXT4-fs error (device dm-8): ext4_journal_check_start:56: Detected aborted journal Feb 19 11:29:10 thebe kernel: EXT4-fs (dm-8): Remounting filesystem read-only Feb 19 11:29:20 thebe kernel: EXT4-fs error (device dm-8): ext4_put_super:780: Couldn't clean up the journal [0]
Re: iSCSI regression with linux 3.9 and 4.0
Ewan Milne emi...@redhat.com on Fri, 2015/03/20 09:51: On Fri, 2015-03-20 at 13:57 +0100, Christian Hesse wrote: Hello everybody! I reported this issue at LKML [0] but received no answer. Hopefully linux-scsi is a better place... Beginning with linux 3.19 I see an iSCSI regressen. This works perfectly with linux 3.18.x (tested with 3.18.6) and before. Effected kernels I tested are 3.19.0, 3.19.2 and 4.0rc4.r199.gb314aca. The logs tell the story: Feb 19 11:26:49 thebe kernel: scsi host6: iSCSI Initiator over TCP/IP Feb 19 11:26:49 thebe kernel: scsi 6:0:0:0: Direct-Access QNAP iSCSI Storage4.0 PQ: 0 ANSI: 5 Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] 1073741824 512-byte logical blocks: (549 GB/512 GiB) Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Write Protect is off Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Mode Sense: 2f 00 00 00 Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA Feb 19 11:26:49 thebe kernel: sdb: unknown partition table Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Attached SCSI disk Feb 19 11:26:49 thebe iscsid[10804]: Connection1:0 to [target: iqn.2004-04.com.qnap:ts-859:iscsi.xxx.c40a18, portal: xx.xx.xx.xx,3260] through [iface: default] is operational now Feb 19 11:26:57 thebe kernel: sdb: unknown partition table Feb 19 11:28:20 thebe kernel: EXT4-fs (dm-8): mounting with discard option, but the device does not support discard Feb 19 11:28:20 thebe kernel: EXT4-fs (dm-8): mounted filesystem with ordered data mode. Opts: (null) Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] UNKNOWN Result: hostbyte=0x00 driverbyte=0x08 Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] Sense Key : 0x5 [current] Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] ASC=0x24 ASCQ=0x0 Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] CDB: Feb 19 11:28:24 thebe kernel: cdb[0]=0x2a: 2a 00 34 5b 07 ff 00 2f 88 00 Feb 19 11:28:24 thebe kernel: blk_update_request: critical target error, dev sdb, sector 878381055 Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting block 108749056) Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749056 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749057 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749058 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749059 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749060 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749061 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749062 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749063 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749064 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749065 Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting block 108749312) Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting block 108749568) Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting block 108749824) Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting block 108750080) Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting block 108750336) Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] UNKNOWN Result: hostbyte=0x00 driverbyte=0x08 Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] Sense Key : 0x5 [current] Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] ASC=0x24 ASCQ=0x0 Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] CDB: Feb 19 11:29:10 thebe kernel: cdb[0]=0x2a: 2a 00 20 44 89 17 00 20 50 00 Feb 19 11:29:10 thebe kernel: blk_update_request: critical target error, dev sdb, sector 541362455 Feb 19 11:29:10 thebe kernel: Buffer I/O error on dev dm-8, logical block 66621731, lost sync page write Feb 19 11:29:10 thebe kernel: Aborting journal on device dm-8-8. Feb 19 11:29:10 thebe kernel: EXT4-fs error (device dm-8): ext4_journal_check_start:56: Detected aborted journal Feb 19 11:29:10 thebe kernel: EXT4-fs (dm-8): Remounting filesystem read-only Feb 19 11:29:20 thebe kernel: EXT4-fs error (device dm-8):
Re: [PATCH] scsi: sd: add a capacity_override attribute
On Tue, 2015-03-17 at 14:08 -0400, Alan Stern wrote:
This patch provides a sysfs interface allowing users to override the
capacity of a SCSI disk. This will help in situations where a buggy
USB-SATA adapter fails to support READ CAPACITY(16) and reports only
the low 32 bits of the capacity in its READ CAPACITY(10) reply. For
an example, see this thread:
http://marc.info/?l=linux-scsim=140908235510961w=2
The interface is awkward because it requires the user to tell the
system to re-read the disk's partition table afterward, but at least
it provides a way to handle deficient hardware.
I think that it is confusing that writing into the capacity_override
sysfs node does not get immediately reflected in the gendisk structure.
Would it hurt to call sd_revalidate_disk() after the value is changed
in capacity_override_store()?
The thing is, if someone overrides the capacity but does not do anything
right away to revalidate the disk, it could change at some arbitrary
time in the future when the revalidation happens for some other reason.
-Ewan
Signed-off-by: Alan Stern st...@rowland.harvard.edu
CC: Dale R. Worley wor...@alum.mit.edu
---
[as1777]
Documentation/ABI/testing/sysfs-class-scsi_disk | 19
drivers/scsi/sd.c | 37
drivers/scsi/sd.h |1
3 files changed, 57 insertions(+)
Index: usb-4.0/Documentation/ABI/testing/sysfs-class-scsi_disk
===
--- /dev/null
+++ usb-4.0/Documentation/ABI/testing/sysfs-class-scsi_disk
@@ -0,0 +1,19 @@
+What:
/sys/class/scsi_disk/HOST:CHANNEL:TARGET:LUN/capacity_override
+Date:March 2015
+KernelVersion: 4.1
+Contact: Alan Stern st...@rowland.harvard.edu
+Description:
+ This file provides a way for users to override the
+ automatically determined disk capacity. For example, some
+ buggy USB-SATA adapters report only the low 32 bits of a
+ drive's block count, resulting in a calculated capacity
+ value that is the actual capacity modulo 2 TB.
+
+ After the correct capacity (in native-size blocks -- often
+ 512 bytes per block but sometimes 4096) is written to this
+ file, the user must tell the system to re-read the disk's
+ partition table by running the command:
+
+ /usr/sbin/blockdev --rereadpt /dev/sdX
+
+ where X is the disk's drive letter.
Index: usb-4.0/drivers/scsi/sd.h
===
--- usb-4.0.orig/drivers/scsi/sd.h
+++ usb-4.0/drivers/scsi/sd.h
@@ -66,6 +66,7 @@ struct scsi_disk {
struct gendisk *disk;
atomic_topeners;
sector_tcapacity; /* size in 512-byte sectors */
+ sector_tcapacity_override; /* in native-size blocks */
u32 max_xfer_blocks;
u32 max_ws_blocks;
u32 max_unmap_blocks;
Index: usb-4.0/drivers/scsi/sd.c
===
--- usb-4.0.orig/drivers/scsi/sd.c
+++ usb-4.0/drivers/scsi/sd.c
@@ -477,6 +477,35 @@ max_write_same_blocks_store(struct devic
}
static DEVICE_ATTR_RW(max_write_same_blocks);
+static ssize_t
+capacity_override_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct scsi_disk *sdkp = to_scsi_disk(dev);
+
+ return sprintf(buf, %llu\n,
+ (unsigned long long) sdkp-capacity_override);
+}
+
+static ssize_t
+capacity_override_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct scsi_disk *sdkp = to_scsi_disk(dev);
+ unsigned long long cap;
+ int err;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EACCES;
+
+ err = kstrtoull(buf, 10, cap);
+ if (err)
+ return err;
+ sdkp-capacity_override = cap;
+ return count;
+}
+static DEVICE_ATTR_RW(capacity_override);
+
static struct attribute *sd_disk_attrs[] = {
dev_attr_cache_type.attr,
dev_attr_FUA.attr,
@@ -489,6 +518,7 @@ static struct attribute *sd_disk_attrs[]
dev_attr_provisioning_mode.attr,
dev_attr_max_write_same_blocks.attr,
dev_attr_max_medium_access_timeouts.attr,
+ dev_attr_capacity_override.attr,
NULL,
};
ATTRIBUTE_GROUPS(sd_disk);
@@ -2152,6 +2182,13 @@ sd_read_capacity(struct scsi_disk *sdkp,
struct scsi_device *sdp = sdkp-device;
sector_t old_capacity = sdkp-capacity;
+ /* Did the user override the reported capacity? */
+ if (!sdkp-first_scan sdkp-capacity_override) {
+ sector_size = sdkp-device-sector_size;
+ sdkp-capacity =
iSCSI regression with linux 3.9 and 4.0
Hello everybody!
I reported this issue at LKML [0] but received no answer. Hopefully
linux-scsi is a better place...
Beginning with linux 3.19 I see an iSCSI regressen. This works perfectly with
linux 3.18.x (tested with 3.18.6) and before. Effected kernels I tested are
3.19.0, 3.19.2 and 4.0rc4.r199.gb314aca.
The logs tell the story:
Feb 19 11:26:49 thebe kernel: scsi host6: iSCSI Initiator over TCP/IP
Feb 19 11:26:49 thebe kernel: scsi 6:0:0:0: Direct-Access QNAP iSCSI
Storage4.0 PQ: 0 ANSI: 5
Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] 1073741824 512-byte logical
blocks: (549 GB/512 GiB)
Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Write Protect is off
Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Mode Sense: 2f 00 00 00
Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Write cache: disabled, read
cache: enabled, doesn't support DPO or FUA
Feb 19 11:26:49 thebe kernel: sdb: unknown partition table
Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Attached SCSI disk
Feb 19 11:26:49 thebe iscsid[10804]: Connection1:0 to [target:
iqn.2004-04.com.qnap:ts-859:iscsi.xxx.c40a18, portal: xx.xx.xx.xx,3260]
through [iface: default] is operational now
Feb 19 11:26:57 thebe kernel: sdb: unknown partition table
Feb 19 11:28:20 thebe kernel: EXT4-fs (dm-8): mounting with discard option,
but the device does not support discard
Feb 19 11:28:20 thebe kernel: EXT4-fs (dm-8): mounted filesystem with ordered
data mode. Opts: (null)
Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] UNKNOWN Result: hostbyte=0x00
driverbyte=0x08
Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] Sense Key : 0x5 [current]
Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] ASC=0x24 ASCQ=0x0
Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] CDB:
Feb 19 11:28:24 thebe kernel: cdb[0]=0x2a: 2a 00 34 5b 07 ff 00 2f 88 00
Feb 19 11:28:24 thebe kernel: blk_update_request: critical target error, dev
sdb, sector 878381055
Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317:
I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting
block 108749056)
Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block
108749056
Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block
108749057
Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block
108749058
Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block
108749059
Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block
108749060
Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block
108749061
Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block
108749062
Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block
108749063
Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block
108749064
Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block
108749065
Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317:
I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting
block 108749312)
Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317:
I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting
block 108749568)
Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317:
I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting
block 108749824)
Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317:
I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting
block 108750080)
Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317:
I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting
block 108750336)
Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] UNKNOWN Result: hostbyte=0x00
driverbyte=0x08
Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] Sense Key : 0x5 [current]
Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] ASC=0x24 ASCQ=0x0
Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] CDB:
Feb 19 11:29:10 thebe kernel: cdb[0]=0x2a: 2a 00 20 44 89 17 00 20 50 00
Feb 19 11:29:10 thebe kernel: blk_update_request: critical target error, dev
sdb, sector 541362455
Feb 19 11:29:10 thebe kernel: Buffer I/O error on dev dm-8, logical block
66621731, lost sync page write
Feb 19 11:29:10 thebe kernel: Aborting journal on device dm-8-8.
Feb 19 11:29:10 thebe kernel: EXT4-fs error (device dm-8):
ext4_journal_check_start:56: Detected aborted journal
Feb 19 11:29:10 thebe kernel: EXT4-fs (dm-8): Remounting filesystem read-only
Feb 19 11:29:20 thebe kernel: EXT4-fs error (device dm-8): ext4_put_super:780:
Couldn't clean up the journal
[0] https://lkml.org/lkml/2015/2/19/91
--
main(a){char*c=/*Schoene Gruesse */B?IJj;MEH
CX:;,b;for(a/*Chris get my mail address:
Re: iSCSI regression with linux 3.9 and 4.0
On Fri, 2015-03-20 at 11:04 -0400, Ewan Milne wrote: Does your target support the Block Limits VPD (page B0)? (i.e. can you run sg_inq /dev/sda -p bl from the sg3_utils package?) I meant /dev/sdb, sorry. -- 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] scsi: sd: add a capacity_override attribute
On Fri, 2015-03-20 at 11:19 -0400, Alan Stern wrote: On Fri, 20 Mar 2015, Ewan Milne wrote: On Tue, 2015-03-17 at 14:08 -0400, Alan Stern wrote: This patch provides a sysfs interface allowing users to override the capacity of a SCSI disk. This will help in situations where a buggy USB-SATA adapter fails to support READ CAPACITY(16) and reports only the low 32 bits of the capacity in its READ CAPACITY(10) reply. For an example, see this thread: http://marc.info/?l=linux-scsim=140908235510961w=2 The interface is awkward because it requires the user to tell the system to re-read the disk's partition table afterward, but at least it provides a way to handle deficient hardware. I think that it is confusing that writing into the capacity_override sysfs node does not get immediately reflected in the gendisk structure. Would it hurt to call sd_revalidate_disk() after the value is changed in capacity_override_store()? It wouldn't hurt, but it wouldn't help much either. sd_revalidate_disk() might cause the new size to show up in the gendisk structure, but it would not cause the partition table to be parsed again. That's the real reason for doing this -- when a drive seems to have fewer blocks than it really does, partitions that extend beyond the end of the drive are rejected. OK, I see. The thing is, if someone overrides the capacity but does not do anything right away to revalidate the disk, it could change at some arbitrary time in the future when the revalidation happens for some other reason. That's why the documentation says that users must force the system to re-read the partition table after writing the sysfs attribute. In my tests, doing that caused a revalidation. Are you saying that could have been a coincidence? It's possible -- I don't understand the design of the block layer. No, I think that re-reading the partition table will revalidate. What I was concerned about is some unsuspecting user writing to the capacity_override sysfs node, observing that it didn't seem to do anything, and being surprised when it changed later. (I've seen some issues with multipath, for example, which will stop using a path if the capacity changes.) I guess it's a principle of least surprise thing. Having said that, if this is what is needed to make the devices work... Reviewed-by: Ewan D. Milne emi...@redhat.com Alan Stern -- 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: iSCSI regression with linux 3.9 and 4.0
On Fri, 2015-03-20 at 15:31 +0100, Christian Hesse wrote: Ewan Milne emi...@redhat.com on Fri, 2015/03/20 09:51: On Fri, 2015-03-20 at 13:57 +0100, Christian Hesse wrote: Hello everybody! I reported this issue at LKML [0] but received no answer. Hopefully linux-scsi is a better place... Beginning with linux 3.19 I see an iSCSI regressen. This works perfectly with linux 3.18.x (tested with 3.18.6) and before. Effected kernels I tested are 3.19.0, 3.19.2 and 4.0rc4.r199.gb314aca. The logs tell the story: Feb 19 11:26:49 thebe kernel: scsi host6: iSCSI Initiator over TCP/IP Feb 19 11:26:49 thebe kernel: scsi 6:0:0:0: Direct-Access QNAP iSCSI Storage4.0 PQ: 0 ANSI: 5 Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] 1073741824 512-byte logical blocks: (549 GB/512 GiB) Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Write Protect is off Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Mode Sense: 2f 00 00 00 Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA Feb 19 11:26:49 thebe kernel: sdb: unknown partition table Feb 19 11:26:49 thebe kernel: sd 6:0:0:0: [sdb] Attached SCSI disk Feb 19 11:26:49 thebe iscsid[10804]: Connection1:0 to [target: iqn.2004-04.com.qnap:ts-859:iscsi.xxx.c40a18, portal: xx.xx.xx.xx,3260] through [iface: default] is operational now Feb 19 11:26:57 thebe kernel: sdb: unknown partition table Feb 19 11:28:20 thebe kernel: EXT4-fs (dm-8): mounting with discard option, but the device does not support discard Feb 19 11:28:20 thebe kernel: EXT4-fs (dm-8): mounted filesystem with ordered data mode. Opts: (null) Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] UNKNOWN Result: hostbyte=0x00 driverbyte=0x08 Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] Sense Key : 0x5 [current] Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] ASC=0x24 ASCQ=0x0 Feb 19 11:28:24 thebe kernel: sd 6:0:0:0: [sdb] CDB: Feb 19 11:28:24 thebe kernel: cdb[0]=0x2a: 2a 00 34 5b 07 ff 00 2f 88 00 Feb 19 11:28:24 thebe kernel: blk_update_request: critical target error, dev sdb, sector 878381055 Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting block 108749056) Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749056 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749057 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749058 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749059 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749060 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749061 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749062 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749063 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749064 Feb 19 11:28:24 thebe kernel: Buffer I/O error on device dm-8, logical block 108749065 Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting block 108749312) Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting block 108749568) Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting block 108749824) Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting block 108750080) Feb 19 11:28:24 thebe kernel: EXT4-fs warning (device dm-8): ext4_end_bio:317: I/O error -121 writing to inode 33196503 (offset 8388608 size 7278592 starting block 108750336) Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] UNKNOWN Result: hostbyte=0x00 driverbyte=0x08 Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] Sense Key : 0x5 [current] Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] ASC=0x24 ASCQ=0x0 Feb 19 11:29:10 thebe kernel: sd 6:0:0:0: [sdb] CDB: Feb 19 11:29:10 thebe kernel: cdb[0]=0x2a: 2a 00 20 44 89 17 00 20 50 00 Feb 19 11:29:10 thebe kernel: blk_update_request: critical target error, dev sdb, sector 541362455 Feb 19 11:29:10 thebe kernel: Buffer I/O error on dev dm-8, logical block 66621731, lost sync page write Feb 19 11:29:10 thebe kernel: Aborting journal on device dm-8-8. Feb 19 11:29:10 thebe kernel: EXT4-fs error (device dm-8): ext4_journal_check_start:56: Detected aborted journal Feb 19 11:29:10 thebe
Re: iSCSI regression with linux 3.9 and 4.0
On Fri, 2015-03-20 at 16:24 +0100, Christian Hesse wrote: Ewan Milne emi...@redhat.com on Fri, 2015/03/20 11:04: On Fri, 2015-03-20 at 15:31 +0100, Christian Hesse wrote: Ewan Milne emi...@redhat.com on Fri, 2015/03/20 09:51: On Fri, 2015-03-20 at 13:57 +0100, Christian Hesse wrote: Hello everybody! I reported this issue at LKML [0] but received no answer. Hopefully linux-scsi is a better place... Beginning with linux 3.19 I see an iSCSI regressen. This works perfectly with linux 3.18.x (tested with 3.18.6) and before. Effected kernels I tested are 3.19.0, 3.19.2 and 4.0rc4.r199.gb314aca. The logs tell the story: [snip log] [0] https://lkml.org/lkml/2015/2/19/91 Sense key 0x5 ASC/ASCQ 0x24 0x00 is ILLEGAL REQUEST, INVALID FIELD IN CDB. The CDB was 2A 00 34 5B 07 FF 00 2F 88 00, which is a WRITE_10 to LBA 878381055 with a length of 12168 blocks (a little less than 6MB). It looks like this is within the reported capacity of the device, and there are no other bits set in the CDB. Looks like you could get this error if RWWP (reject without write protection) is set in the control mode page. I don't see any messages about the protection type, though. What does sysfs report? Is that what you are interested in? # cat protection_mode protection_type none 0 In case it matters: The iSCSI device is LUKS encrypted, that is why device mapper shows up. I removed the discard option from filesystem's default mount option, but that brings no difference except the message is not printed. It is most likely the device that is returning the error, there is a place in the iSCSI Initiator that generates an ILLEGAL REQUEST sense, but it is not the same ASC/ASCQ. There was this change: commit bcdb247c6b6a1f3e72b9b787b73f47dd509d17ec Author: Martin K. Petersen martin.peter...@oracle.com Date: Tue Jun 3 18:45:51 2014 -0400 sd: Limit transfer length Until now the per-command transfer length has exclusively been gated by the max_sectors parameter in the scsi_host template. Given that the size of this parameter has been bumped to an unsigned int we have to be careful not to exceed the target device's capabilities. If the if the device specifies a Maximum Transfer Length in the Block Limits VPD we'll use that value. Otherwise we'll use 0x for devices that have use_16_for_rw set and 0x for the rest. We then combine the chosen disk limit with max_sectors in the host template. The smaller of the two will be used to set the max_hw_sectors queue limit. Signed-off-by: Martin K. Petersen martin.peter...@oracle.com Reviewed-by: Ewan D. Milne emi...@redhat.com Signed-off-by: Christoph Hellwig h...@lst.de What is the value of max_sectors_kb and queue_max_sectors_kb in sysfs for the device? Is it different than what is reported on 3.18? I found 'max_sectors_kb' which is inside in directory called 'queue'. Is that the value you asked for? for 4.0 git: # cat max_sectors_kb 32767 If you change max_sectors_kb to a lower value (e.g. 512) can you get the device to work? There is a max_hw_sectors_kb value but you can't change it. Is it 32768 also for 4.0? Your device reports a maximum transfer length of 2^32-1 blocks but I suspect that it might not be actually able to do that. I don't see what else would be causing the error. Maybe there is a transport limitation that is getting in the way? -Ewan for 3.18.6: # cat max_sectors_kb 512 Does your target support the Block Limits VPD (page B0)? (i.e. can you run sg_inq /dev/sda -p bl from the sg3_utils package?) This does not differ for different kernels. I think this is expected. # sg_inq /dev/sdb -p bl VPD INQUIRY: Block limits page (SBC) Maximum compare and write length: 1 blocks Optimal transfer length granularity: 1 blocks Maximum transfer length: 4294967295 blocks Optimal transfer length: 4294967295 blocks Maximum prefetch, xdread, xdwrite transfer length: 0 blocks Maximum unmap LBA count: 8388607 Maximum unmap block descriptor count: 1 Optimal unmap granularity: 16383 Unmap granularity alignment valid: 0 Unmap granularity alignment: 0 Maximum write same length: 0x blocks Maximum atomic transfer length: 0 Atomic alignment: 0 Atomic transfer length granularity: 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: iSCSI regression with linux 3.9 and 4.0
Ewan Milne emi...@redhat.com on Fri, 2015/03/20 11:04:
On Fri, 2015-03-20 at 15:31 +0100, Christian Hesse wrote:
Ewan Milne emi...@redhat.com on Fri, 2015/03/20 09:51:
On Fri, 2015-03-20 at 13:57 +0100, Christian Hesse wrote:
Hello everybody!
I reported this issue at LKML [0] but received no answer. Hopefully
linux-scsi is a better place...
Beginning with linux 3.19 I see an iSCSI regressen. This works
perfectly with linux 3.18.x (tested with 3.18.6) and before. Effected
kernels I tested are 3.19.0, 3.19.2 and 4.0rc4.r199.gb314aca.
The logs tell the story:
[snip log]
[0] https://lkml.org/lkml/2015/2/19/91
Sense key 0x5 ASC/ASCQ 0x24 0x00 is ILLEGAL REQUEST, INVALID FIELD IN
CDB. The CDB was 2A 00 34 5B 07 FF 00 2F 88 00, which is a WRITE_10
to LBA 878381055 with a length of 12168 blocks (a little less than 6MB).
It looks like this is within the reported capacity of the device, and
there are no other bits set in the CDB.
Looks like you could get this error if RWWP (reject without write
protection) is set in the control mode page. I don't see any messages
about the protection type, though. What does sysfs report?
Is that what you are interested in?
# cat protection_mode protection_type
none
0
In case it matters: The iSCSI device is LUKS encrypted, that is why device
mapper shows up.
I removed the discard option from filesystem's default mount option, but
that brings no difference except the message is not printed.
It is most likely the device that is returning the error, there is a
place in the iSCSI Initiator that generates an ILLEGAL REQUEST sense,
but it is not the same ASC/ASCQ.
There was this change:
commit bcdb247c6b6a1f3e72b9b787b73f47dd509d17ec
Author: Martin K. Petersen martin.peter...@oracle.com
Date: Tue Jun 3 18:45:51 2014 -0400
sd: Limit transfer length
Until now the per-command transfer length has exclusively been gated by
the max_sectors parameter in the scsi_host template. Given that the size
of this parameter has been bumped to an unsigned int we have to be
careful not to exceed the target device's capabilities.
If the if the device specifies a Maximum Transfer Length in the Block
Limits VPD we'll use that value. Otherwise we'll use 0x for
devices that have use_16_for_rw set and 0x for the rest. We then
combine the chosen disk limit with max_sectors in the host template. The
smaller of the two will be used to set the max_hw_sectors queue limit.
Signed-off-by: Martin K. Petersen martin.peter...@oracle.com
Reviewed-by: Ewan D. Milne emi...@redhat.com
Signed-off-by: Christoph Hellwig h...@lst.de
What is the value of max_sectors_kb and queue_max_sectors_kb in sysfs
for the device? Is it different than what is reported on 3.18?
I found 'max_sectors_kb' which is inside in directory called 'queue'. Is that
the value you asked for?
for 4.0 git:
# cat max_sectors_kb
32767
for 3.18.6:
# cat max_sectors_kb
512
Does your target support the Block Limits VPD (page B0)? (i.e. can
you run sg_inq /dev/sda -p bl from the sg3_utils package?)
This does not differ for different kernels. I think this is expected.
# sg_inq /dev/sdb -p bl
VPD INQUIRY: Block limits page (SBC)
Maximum compare and write length: 1 blocks
Optimal transfer length granularity: 1 blocks
Maximum transfer length: 4294967295 blocks
Optimal transfer length: 4294967295 blocks
Maximum prefetch, xdread, xdwrite transfer length: 0 blocks
Maximum unmap LBA count: 8388607
Maximum unmap block descriptor count: 1
Optimal unmap granularity: 16383
Unmap granularity alignment valid: 0
Unmap granularity alignment: 0
Maximum write same length: 0x blocks
Maximum atomic transfer length: 0
Atomic alignment: 0
Atomic transfer length granularity: 0
--
main(a){char*c=/*Schoene Gruesse */B?IJj;MEH
CX:;,b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c ./sig*/b/42*2-3)*42);}
pgpKyWfPxHrKe.pgp
Description: OpenPGP digital signature
Re: [PATCH] scsi: sd: add a capacity_override attribute
On Fri, 20 Mar 2015, Ewan Milne wrote: On Tue, 2015-03-17 at 14:08 -0400, Alan Stern wrote: This patch provides a sysfs interface allowing users to override the capacity of a SCSI disk. This will help in situations where a buggy USB-SATA adapter fails to support READ CAPACITY(16) and reports only the low 32 bits of the capacity in its READ CAPACITY(10) reply. For an example, see this thread: http://marc.info/?l=linux-scsim=140908235510961w=2 The interface is awkward because it requires the user to tell the system to re-read the disk's partition table afterward, but at least it provides a way to handle deficient hardware. I think that it is confusing that writing into the capacity_override sysfs node does not get immediately reflected in the gendisk structure. Would it hurt to call sd_revalidate_disk() after the value is changed in capacity_override_store()? It wouldn't hurt, but it wouldn't help much either. sd_revalidate_disk() might cause the new size to show up in the gendisk structure, but it would not cause the partition table to be parsed again. That's the real reason for doing this -- when a drive seems to have fewer blocks than it really does, partitions that extend beyond the end of the drive are rejected. The thing is, if someone overrides the capacity but does not do anything right away to revalidate the disk, it could change at some arbitrary time in the future when the revalidation happens for some other reason. That's why the documentation says that users must force the system to re-read the partition table after writing the sysfs attribute. In my tests, doing that caused a revalidation. Are you saying that could have been a coincidence? It's possible -- I don't understand the design of the block layer. Alan Stern -- 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
[GIT PULL] target fixes for v4.0-rc5
Hi Linus, Here are current target-pending fixes for v4.0-rc5 code that have made their way into the queue over the last weeks. Please go ahead and pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master The fixes this round include: - Fix long-standing iser-target logout bug related to early conn_logout_comp completion, resulting in iscsi_conn use-after-tree OOpsen. (Sagi + nab) - Fix long-standing tcm_fc bug in ft_invl_hw_context() failure handing for DDP hw offload. (DanC) - Fix incorrect use of unprotected __transport_register_session() in tcm_qla2xxx + other single local se_node_acl fabrics. (Bart) - Fix reference leak in target_submit_cmd() - target_get_sess_cmd() for ack_kref=1 failure path. (Bart) - Fix pSCSI backend -get_device_type() statistics OOPs with un-configured device. (Olaf + nab) - Fix virtual LUN=0 target_configure_device failure OOPs at modprobe time. (Claudio + nab) - Fix FUA write false positive failure regression in v4.0-rc1 code. (Christophe Vu-Brugier + HCH) Thank you, --nab Bart Van Assche (3): tcm_qla2xxx: Fix incorrect use of __transport_register_session loop/usb/vhost-scsi/xen-scsiback: Fix use of __transport_register_session target: Fix reference leak in target_get_sess_cmd() error path Christophe Vu-Brugier (1): target: do not reject FUA CDBs when write cache is enabled but emulate_write_cache is 0 Dan Carpenter (1): tcm_fc: missing curly braces in ft_invl_hw_context() Nicholas Bellinger (5): target: Disallow changing of WRITE cache/FUA attrs after export Revert iscsi-target: Avoid IN_LOGOUT failure case for iser-target iscsi-target: Avoid early conn_logout_comp for iser connections target/pscsi: Fix NULL pointer dereference in get_device_type target: Fix virtual LUN=0 target_configure_device failure OOPs drivers/scsi/qla2xxx/tcm_qla2xxx.c | 2 +- drivers/target/iscsi/iscsi_target.c| 14 + drivers/target/iscsi/iscsi_target_erl0.c | 4 +--- drivers/target/loopback/tcm_loop.c | 7 ++- drivers/target/target_core_device.c| 32 +++--- drivers/target/target_core_pscsi.c | 2 +- drivers/target/target_core_sbc.c | 3 +-- drivers/target/target_core_spc.c | 19 +++--- drivers/target/target_core_transport.c | 4 drivers/target/tcm_fc/tfc_io.c | 3 ++- drivers/usb/gadget/legacy/tcm_usb_gadget.c | 5 ++--- drivers/vhost/scsi.c | 5 ++--- drivers/xen/xen-scsiback.c | 7 ++- include/target/target_core_backend.h | 1 + 14 files changed, 61 insertions(+), 47 deletions(-) -- 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: noise in target_core_register_fabric
On Wed, 2015-03-18 at 08:49 +0100, Olaf Hering wrote:
On Wed, Mar 04, Olaf Hering wrote:
Is there a need to fill dmesg with noise like shown below whenever
targetcli-3.0 runs a command? I think the pr_err calls in those functions
should be converted to pr_debug.
Any update on this?
[ 1240.045518] target_core_register_fabric() trying autoload for fc
[ 1240.045520] target_core_get_fabric() failed for fc
Hi Olaf,
Applying the following patch to target-pending/for-next.
Thank you,
--nab
From 62554910a94a62f7b9b79cee3ca6bac95abe3c29 Mon Sep 17 00:00:00 2001
From: Nicholas Bellinger n...@linux-iscsi.org
Date: Fri, 20 Mar 2015 11:36:50 -0700
Subject: [PATCH] target: Convert fabric module autoload failures to pr_debug
This patch converts the fabric module autoload failures from
pr_err to pr_debug in target_core_register_fabric() code, to
reduce the amount of noise during normal operation.
Reported-by: Olaf Hering o...@aepfle.de
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
---
drivers/target/target_core_configfs.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/target/target_core_configfs.c
b/drivers/target/target_core_configfs.c
index 75d89ad..69baf1c 100644
--- a/drivers/target/target_core_configfs.c
+++ b/drivers/target/target_core_configfs.c
@@ -142,8 +142,8 @@ static struct config_group *target_core_register_fabric(
tf = target_core_get_fabric(name);
if (!tf) {
- pr_err(target_core_register_fabric() trying autoload for %s\n,
- name);
+ pr_debug(target_core_register_fabric() trying autoload for
%s\n,
+name);
/*
* Below are some hardcoded request_module() calls to
automatically
@@ -165,8 +165,8 @@ static struct config_group *target_core_register_fabric(
*/
ret = request_module(iscsi_target_mod);
if (ret 0) {
- pr_err(request_module() failed for
- iscsi_target_mod.ko: %d\n, ret);
+ pr_debug(request_module() failed for
+ iscsi_target_mod.ko: %d\n, ret);
return ERR_PTR(-EINVAL);
}
} else if (!strncmp(name, loopback, 8)) {
@@ -178,8 +178,8 @@ static struct config_group *target_core_register_fabric(
*/
ret = request_module(tcm_loop);
if (ret 0) {
- pr_err(request_module() failed for
- tcm_loop.ko: %d\n, ret);
+ pr_debug(request_module() failed for
+ tcm_loop.ko: %d\n, ret);
return ERR_PTR(-EINVAL);
}
}
@@ -188,8 +188,8 @@ static struct config_group *target_core_register_fabric(
}
if (!tf) {
- pr_err(target_core_get_fabric() failed for %s\n,
- name);
+ pr_debug(target_core_get_fabric() failed for %s\n,
+name);
return ERR_PTR(-EINVAL);
}
pr_debug(Target_Core_ConfigFS: REGISTER - Located fabric:
--
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 15/15] iscsi-target: don't export static symbol
On Wed, 2015-03-11 at 17:56 +0100, Julia Lawall wrote:
From: Julia Lawall julia.law...@lip6.fr
The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@r@
type T;
identifier f;
@@
static T f (...) { ... }
@@
identifier r.f;
declarer name EXPORT_SYMBOL;
@@
-EXPORT_SYMBOL(f);
// /smpl
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
drivers/target/iscsi/iscsi_target.c |1 -
1 file changed, 1 deletion(-)
diff -u -p a/drivers/target/iscsi/iscsi_target.c
b/drivers/target/iscsi/iscsi_target.c
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -2155,7 +2155,6 @@ reject:
cmd-text_in_ptr = NULL;
return iscsit_reject_cmd(cmd, ISCSI_REASON_PROTOCOL_ERROR, buf);
}
-EXPORT_SYMBOL(iscsit_handle_text_cmd);
int iscsit_logout_closesession(struct iscsi_cmd *cmd, struct iscsi_conn
*conn)
{
Applied to target-pending/for-next.
Thanks Julia!
--nab
--
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: iSCSI regression with linux 3.9 and 4.0
On 03/20/2015 07:57 AM, Christian Hesse wrote: Hello everybody! I reported this issue at LKML [0] but received no answer. Hopefully linux-scsi is a better place... Beginning with linux 3.19 I see an iSCSI regressen. This works perfectly with linux 3.18.x (tested with 3.18.6) and before. Effected kernels I tested are 3.19.0, 3.19.2 and 4.0rc4.r199.gb314aca. Could you take a wrireshark/tcpdump trace when running 3.18 and 3.19? We can then see what bits are different and narrow down the patch/change. -- 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: iSCSI regression with linux 3.9 and 4.0
Ewan Milne emi...@redhat.com on Fri, 2015/03/20 11:46:
On Fri, 2015-03-20 at 16:24 +0100, Christian Hesse wrote:
I found 'max_sectors_kb' which is inside in directory called 'queue'. Is
that the value you asked for?
for 4.0 git:
# cat max_sectors_kb
32767
If you change max_sectors_kb to a lower value (e.g. 512) can you get the
device to work?
I will check that on monday. Sitting behind a slow dial up connection right
now...
There is a max_hw_sectors_kb value but you can't change it. Is it
32768 also for 4.0?
# cat max_hw_sectors_kb
32767
It's 3276*7*, not 32768.
Your device reports a maximum transfer length of 2^32-1 blocks but
I suspect that it might not be actually able to do that. I don't see
what else would be causing the error. Maybe there is a transport
limitation that is getting in the way?
What kind of transport limitation can that be? Network MTU and friends should
no be an issue, no?
--
main(a){char*c=/*Schoene Gruesse */B?IJj;MEH
CX:;,b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c ./sig*/b/42*2-3)*42);}
pgp9LNXSP25S2.pgp
Description: OpenPGP digital signature
Re: [PATCH] scsi: sd: add a capacity_override attribute
On Fri, 2015-03-20 at 12:03 -0400, Alan Stern wrote: On Fri, 20 Mar 2015, Ewan Milne wrote: On Fri, 2015-03-20 at 11:19 -0400, Alan Stern wrote: On Fri, 20 Mar 2015, Ewan Milne wrote: On Tue, 2015-03-17 at 14:08 -0400, Alan Stern wrote: This patch provides a sysfs interface allowing users to override the capacity of a SCSI disk. This will help in situations where a buggy USB-SATA adapter fails to support READ CAPACITY(16) and reports only the low 32 bits of the capacity in its READ CAPACITY(10) reply. For an example, see this thread: http://marc.info/?l=linux-scsim=140908235510961w=2 The interface is awkward because it requires the user to tell the system to re-read the disk's partition table afterward, but at least it provides a way to handle deficient hardware. I think that it is confusing that writing into the capacity_override sysfs node does not get immediately reflected in the gendisk structure. Would it hurt to call sd_revalidate_disk() after the value is changed in capacity_override_store()? It wouldn't hurt, but it wouldn't help much either. sd_revalidate_disk() might cause the new size to show up in the gendisk structure, but it would not cause the partition table to be parsed again. That's the real reason for doing this -- when a drive seems to have fewer blocks than it really does, partitions that extend beyond the end of the drive are rejected. OK, I see. The thing is, if someone overrides the capacity but does not do anything right away to revalidate the disk, it could change at some arbitrary time in the future when the revalidation happens for some other reason. That's why the documentation says that users must force the system to re-read the partition table after writing the sysfs attribute. In my tests, doing that caused a revalidation. Are you saying that could have been a coincidence? It's possible -- I don't understand the design of the block layer. No, I think that re-reading the partition table will revalidate. What I was concerned about is some unsuspecting user writing to the capacity_override sysfs node, observing that it didn't seem to do anything, and being surprised when it changed later. (I've seen some issues with multipath, for example, which will stop using a path if the capacity changes.) I guess it's a principle of least surprise thing. Having said that, if this is what is needed to make the devices work... Reviewed-by: Ewan D. Milne emi...@redhat.com Thanks. I don't _mind_ adding an sd_revalidate_disk() call if you think it will improve the patch. What's your suggestion? If that does not cause the partition table to be updated, then it doesn't solve your problem, so I'd leave it the way it is, for now. -Ewan Alan Stern -- 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] scsi: sd: add a capacity_override attribute
On Fri, 20 Mar 2015, Ewan Milne wrote: On Fri, 2015-03-20 at 11:19 -0400, Alan Stern wrote: On Fri, 20 Mar 2015, Ewan Milne wrote: On Tue, 2015-03-17 at 14:08 -0400, Alan Stern wrote: This patch provides a sysfs interface allowing users to override the capacity of a SCSI disk. This will help in situations where a buggy USB-SATA adapter fails to support READ CAPACITY(16) and reports only the low 32 bits of the capacity in its READ CAPACITY(10) reply. For an example, see this thread: http://marc.info/?l=linux-scsim=140908235510961w=2 The interface is awkward because it requires the user to tell the system to re-read the disk's partition table afterward, but at least it provides a way to handle deficient hardware. I think that it is confusing that writing into the capacity_override sysfs node does not get immediately reflected in the gendisk structure. Would it hurt to call sd_revalidate_disk() after the value is changed in capacity_override_store()? It wouldn't hurt, but it wouldn't help much either. sd_revalidate_disk() might cause the new size to show up in the gendisk structure, but it would not cause the partition table to be parsed again. That's the real reason for doing this -- when a drive seems to have fewer blocks than it really does, partitions that extend beyond the end of the drive are rejected. OK, I see. The thing is, if someone overrides the capacity but does not do anything right away to revalidate the disk, it could change at some arbitrary time in the future when the revalidation happens for some other reason. That's why the documentation says that users must force the system to re-read the partition table after writing the sysfs attribute. In my tests, doing that caused a revalidation. Are you saying that could have been a coincidence? It's possible -- I don't understand the design of the block layer. No, I think that re-reading the partition table will revalidate. What I was concerned about is some unsuspecting user writing to the capacity_override sysfs node, observing that it didn't seem to do anything, and being surprised when it changed later. (I've seen some issues with multipath, for example, which will stop using a path if the capacity changes.) I guess it's a principle of least surprise thing. Having said that, if this is what is needed to make the devices work... Reviewed-by: Ewan D. Milne emi...@redhat.com Thanks. I don't _mind_ adding an sd_revalidate_disk() call if you think it will improve the patch. What's your suggestion? Alan Stern -- 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: [Scst-devel] scst qla2xxx.ko VS kernel qla2xxx.ko
On 03/20/2015 01:06 PM, Dr. Greg Wettstein wrote: We have had the opportunity to architect, build, maintain and debug complex converged data and storage networks. The switches on these networks are a million dollars apiece and there are multiple switches in multiple data-centers. The storage, running at about one-half petabyte levels, is all SCST based and we use Qlogic HBA's and CNA's on both the initiators and targets. Given the somewhat colorful history with respect to Qlogic target driver support we had to roll up our sleeves and write an interface driver which allows SCST to run on top of the Qlogic target driver in stock Linux kernels. I just put an integrated patchset which includes SCST 3.0.0, our target interface driver and a few patches to the in-kernel target driver we carry to make all of this work correctly and address various regressions in the stock target driver. You can grab the patchset from the following URL: ftp://ftp.enjellic.com/pub/scst/sqa-1.2_scst-3.0.0_3.10.67.patch.gz All of the storage targets are direct FCOE attachments using Qlogic 8362 CNA's. The above patchset is what we are currently using in production and it has been validated over hundreds and hundreds of terrabytes of I/O, which includes exposure to some rather rigorous fabric and TMF event processing situations. We have also tracked down some rather elusive switch based FCOE transport issues with this codebase. Obviously your mileage may vary. If you drop the above patch onto a 3.10 kernel source tree and build a kernel with the appropriate configuration options it should work with whatever cards are supported by the stock Linux kernel. One of the patches which is included sets the card to QLA2XXX_INI_MODE_EXCLUSIVE which causes the card to come up 'target capable' by default which mirrors the behavior of the SCST supplied Qlogic target driver. In your note you indicate your card is a 'QLogic QLE8362 - 7101674, Sun Storage 16Gb FC PCIe Universal HBA' which I assume is probably an OEM rebranded card. The 8362 is actually a Converged Network Adapter (CNA) rather then an HBA. The 2672 is the 'fibre-channel' HBA version of the card. The stock Qlogic cards are dual-personality cards which allows their operational mode, ie 16 GBPS FC or 10 GBPS ethernet, to be selected through the BIOS setup utilities. Given your e-mail address, I'm sure you've jumped through all these hoops but one obviously wants to have the card setup with the right personality and correct optics for your physical transport layer. You also probably want to make sure you have both your HBA/CNA and motherboard up to the most recent versions of their respective firmware. There are issues particularly with Intel S2600 motherboards and these cards which requires updated firmware on both sides. If the card is detected and found to be target capable by the stock Linux kernel Qlogic driver you will find the available target PWWN's in the following directory: /sys/kernel/scst_tgt/targets/sqatgt If there are none present there is the possibility that the card has been modified in firmware to prohibit target mode or has a modified PCI id which is causing problems for the driver probe logic. If that is the case the card isn't going to be a candidate for use in target mode. We tend to recommend that people buy straight Qlogic branded cards to avoid these sorts of issues. Just as an FYI/CYA there are session management issues/bugs in the Qlogic target driver, regardless of breed; SCST, Qlogic SCST or kernel. These can show up during asynchronous fabric processing events, particularly if you are aggressive in placing the card and fabric under duress. We are in the process of upgrading our patchset to 3.0.1 which will include a number of additional fixes to the in-kernel Qlogic target driver. I will shoot a note off to the list when it is available if you or others find this stuff useful. I hope the above is helpful. Hello Greg, Having to download an SCST target driver that is not in the SCST tree is inconvenient for SCST users. If we would add your version of the SCST QLogic target driver in the SCST tree, would you be willing to maintain that target driver ? We can provide help to make sure that that driver builds against multiple kernel versions. If you want I can send you a copy of the output of the SCST nightly build process. That nightly build process checks whether SCST and its target drivers build correctly against a wide range of kernel versions. Bart. -- 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: [Scst-devel] scst qla2xxx.ko VS kernel qla2xxx.ko
On Mar 13, 4:18am, Suresh Babu Kandukuru wrote: } Subject: Re: [Scst-devel] scst qla2xxx.ko VS kernel qla2xxx.ko Hi, I hope the week is closing out well for everyone. Thanks Bart . We have tested with 2.2.0 and 3.0.1 (scst-svn-6135-branches-3.0.x ) ., loaded all the scst ko files along with qla2xxx_scst.ko qla2x00t.ko . Still this did not any FC ports in /sys/class/fc_hosts/.. . The QLOGIC HBA we are using is QLogic QLE8362 - 7101674, Sun Storage 16Gb FC PCIe Universal HBA, QLogic. . Does the scst qla2xxx_scst.ko driver supports this ?. what we are missing here ?. Any pointers are helpful . Thanks We have had the opportunity to architect, build, maintain and debug complex converged data and storage networks. The switches on these networks are a million dollars apiece and there are multiple switches in multiple data-centers. The storage, running at about one-half petabyte levels, is all SCST based and we use Qlogic HBA's and CNA's on both the initiators and targets. Given the somewhat colorful history with respect to Qlogic target driver support we had to roll up our sleeves and write an interface driver which allows SCST to run on top of the Qlogic target driver in stock Linux kernels. I just put an integrated patchset which includes SCST 3.0.0, our target interface driver and a few patches to the in-kernel target driver we carry to make all of this work correctly and address various regressions in the stock target driver. You can grab the patchset from the following URL: ftp://ftp.enjellic.com/pub/scst/sqa-1.2_scst-3.0.0_3.10.67.patch.gz All of the storage targets are direct FCOE attachments using Qlogic 8362 CNA's. The above patchset is what we are currently using in production and it has been validated over hundreds and hundreds of terrabytes of I/O, which includes exposure to some rather rigorous fabric and TMF event processing situations. We have also tracked down some rather elusive switch based FCOE transport issues with this codebase. Obviously your mileage may vary. If you drop the above patch onto a 3.10 kernel source tree and build a kernel with the appropriate configuration options it should work with whatever cards are supported by the stock Linux kernel. One of the patches which is included sets the card to QLA2XXX_INI_MODE_EXCLUSIVE which causes the card to come up 'target capable' by default which mirrors the behavior of the SCST supplied Qlogic target driver. In your note you indicate your card is a 'QLogic QLE8362 - 7101674, Sun Storage 16Gb FC PCIe Universal HBA' which I assume is probably an OEM rebranded card. The 8362 is actually a Converged Network Adapter (CNA) rather then an HBA. The 2672 is the 'fibre-channel' HBA version of the card. The stock Qlogic cards are dual-personality cards which allows their operational mode, ie 16 GBPS FC or 10 GBPS ethernet, to be selected through the BIOS setup utilities. Given your e-mail address, I'm sure you've jumped through all these hoops but one obviously wants to have the card setup with the right personality and correct optics for your physical transport layer. You also probably want to make sure you have both your HBA/CNA and motherboard up to the most recent versions of their respective firmware. There are issues particularly with Intel S2600 motherboards and these cards which requires updated firmware on both sides. If the card is detected and found to be target capable by the stock Linux kernel Qlogic driver you will find the available target PWWN's in the following directory: /sys/kernel/scst_tgt/targets/sqatgt If there are none present there is the possibility that the card has been modified in firmware to prohibit target mode or has a modified PCI id which is causing problems for the driver probe logic. If that is the case the card isn't going to be a candidate for use in target mode. We tend to recommend that people buy straight Qlogic branded cards to avoid these sorts of issues. Just as an FYI/CYA there are session management issues/bugs in the Qlogic target driver, regardless of breed; SCST, Qlogic SCST or kernel. These can show up during asynchronous fabric processing events, particularly if you are aggressive in placing the card and fabric under duress. We are in the process of upgrading our patchset to 3.0.1 which will include a number of additional fixes to the in-kernel Qlogic target driver. I will shoot a note off to the list when it is available if you or others find this stuff useful. I hope the above is helpful. Good luck with your project. Greg }-- End of excerpt from Suresh Babu Kandukuru As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: g...@enjellic.com -- If you plugged up your nose and mouth right before you
