Re: kernel BUG at drivers/scsi/scsi_lib.c:1101! observed during md5sum for one file on (RAID4-RAID0) device
On Thu, 2015-07-30 at 05:03 -0400, Yi Zhang wrote: Hi SCSI/RAID maintainer During raid test with 4.2.0-rc3, I observed below kernel BUG, pls check below info for the test log/environment/test steps. Log: [ 306.741662] md: bindsdb1 [ 306.750865] md: bindsdc1 [ 306.753993] md: bindsdd1 [ 306.764475] md: bindsde1 [ 306.786156] md: bindsdf1 [ 306.789362] md: bindsdh1 [ 306.792555] md: bindsdg1 [ 306.868166] raid6: sse2x1 gen() 10589 MB/s [ 306.889143] raid6: sse2x1 xor() 8218 MB/s [ 306.910121] raid6: sse2x2 gen() 13453 MB/s [ 306.931102] raid6: sse2x2 xor() 8990 MB/s [ 306.952079] raid6: sse2x4 gen() 15539 MB/s [ 306.973063] raid6: sse2x4 xor() 10771 MB/s [ 306.994039] raid6: avx2x1 gen() 20582 MB/s [ 307.015017] raid6: avx2x2 gen() 24019 MB/s [ 307.035998] raid6: avx2x4 gen() 27824 MB/s [ 307.040755] raid6: using algorithm avx2x4 gen() 27824 MB/s [ 307.046869] raid6: using avx2x2 recovery algorithm [ 307.058793] async_tx: api initialized (async) [ 307.075428] xor: automatically using best checksumming function: [ 307.091942]avx : 32008.000 MB/sec [ 307.147662] md: raid6 personality registered for level 6 [ 307.153584] md: raid5 personality registered for level 5 [ 307.159505] md: raid4 personality registered for level 4 [ 307.165698] md/raid:md0: device sdf1 operational as raid disk 4 [ 307.172300] md/raid:md0: device sde1 operational as raid disk 3 [ 307.178899] md/raid:md0: device sdd1 operational as raid disk 2 [ 307.185497] md/raid:md0: device sdc1 operational as raid disk 1 [ 307.192093] md/raid:md0: device sdb1 operational as raid disk 0 [ 307.199052] md/raid:md0: allocated 6482kB [ 307.203573] md/raid:md0: raid level 4 active with 5 out of 6 devices, algorithm 0 [ 307.211958] md0: detected capacity change from 0 to 53645148160 [ 307.218658] md: recovery of RAID array md0 [ 307.223226] md: minimum _guaranteed_ speed: 1000 KB/sec/disk. [ 307.229729] md: using maximum available idle IO bandwidth (but not more than 20 KB/sec) for recovery. [ 307.240427] md: using 128k window, over a total of 10477568k. [ 374.670951] md: md0: recovery done. [ 375.722806] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) [ 447.553364] md: unbindsdh1 [ 447.559905] md: export_rdev(sdh1) [ 447.572684] md: cannot remove active disk sdg1 from md0 ... [ 447.578909] md/raid:md0: Disk failure on sdg1, disabling device. [ 447.578909] md/raid:md0: Operation continuing on 5 devices. [ 447.594850] md: unbindsdg1 [ 447.601834] md: export_rdev(sdg1) [ 447.615446] md: raid0 personality registered for level 0 [ 447.629275] md/raid0:md0: md_size is 104775680 sectors. [ 447.635094] md: RAID0 configuration for md0 - 1 zone [ 447.640627] md: zone0=[sdb1/sdc1/sdd1/sde1/sdf1] [ 447.645833] zone-offset= 0KB, device-offset= 0KB, size= 52387840KB [ 447.654949] [ 447.739443] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) [ 447.749258] bio too big device sde1 (768 512) This is the actual error. It looks like an md problem (md list copied). [ 447.754824] bio too big device sdf1 (1024 512) [ 447.759989] bio too big device sdb1 (768 512) [ 447.771102] bio too big device sdc1 (1024 512) [ 447.776276] bio too big device sdd1 (1024 512) [ 447.781459] bio too big device sde1 (1024 512) [ 447.786635] bio too big device sdf1 (768 512) [ 447.811156] bio too big device sdb1 (1024 512) [ 447.816329] bio too big device sdc1 (1024 512) [ 447.821513] bio too big device sdd1 (1024 512) [ 447.826681] bio too big device sde1 (768 512) [ 447.886106] bio too big device sdf1 (1024 512) [ 447.891269] bio too big device sdb1 (1024 512) [ 447.896452] bio too big device sdc1 (1024 512) [ 447.901628] bio too big device sdd1 (768 512) [ 447.930647] bio too big device sde1 (1024 512) [ 447.935820] bio too big device sdf1 (1024 512) [ 447.941003] bio too big device sdb1 (1024 512) [ 447.946179] bio too big device sdc1 (768 512) [ 447.976196] bio too big device sdd1 (1024 512) [ 447.981367] bio too big device sde1 (1024 512) [ 447.986549] bio too big device sdf1 (1024 512) [ 447.991728] bio too big device sdb1 (768 512) [ 448.033614] bio too big device sdc1 (1024 512) [ 448.038786] bio too big device sdd1 (1024 512) [ 448.043968] bio too big device sde1 (1024 512) [ 448.049145] bio too big device sdf1 (768 512) [ 448.083273] bio too big device sdb1 (1024 512) [ 448.088444] bio too big device sdc1 (1024 512) [ 448.093626] bio too big device sdd1 (1024 512) [ 448.098804] bio too big device sde1 (768 512) [ 448.128357] bio too big device sdf1 (1024 512) [ 448.133536] bio too big device sdb1 (1024 512) [ 448.138720] bio too big device sdc1 (1024 512) [ 448.143897] bio too big device sdd1 (768 512) [ 448.173456] bio too big device sde1 (1024 512) [
Re: [PATCH] target: Wait RCU grace-period before backend/fabric unload
On Thu, Jul 30, 2015 at 06:15:23AM +, Nicholas A. Bellinger wrote:
From: Nicholas Bellinger n...@linux-iscsi.org
This patch addresses a v4.2-rc1 regression where backend driver
struct module unload immediately after -free_device() has done
an internal call_rcu(), results in IRQ rcu_process_callbacks()
use-after-free paging OOPsen.
It adds a explicit synchronize_rcu() in target_backend_unregister()
to wait a full RCU grace period before releasing target_backend_ops
memory, and allowing TBO-module exit to proceed.
Good catch, but...
You need rcu_barrier() rather than synchronize_rcu() in this case.
All that synchronize_rcu() does is wait for pre-existing RCU readers,
when what is needed is to wait for all pre-existing RCU callbacks
to be invoked.
So please replace the two synchronize_rcu() calls with rcu_barrier().
Thanx, Paul
Also, go ahead and do the same for target_unregister_template()
to ensure se_deve_entry-rcu_head - kfree_rcu() grace period has
passed, before allowing target_core_fabric_ops-owner module exit
to proceed.
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Christoph Hellwig h...@lst.de
Cc: Hannes Reinecke h...@suse.de
Cc: Sagi Grimberg sa...@mellanox.com
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
---
drivers/target/target_core_configfs.c | 10 +-
drivers/target/target_core_hba.c | 10 +-
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/target/target_core_configfs.c
b/drivers/target/target_core_configfs.c
index c2e9fea..b4c3ae0 100644
--- a/drivers/target/target_core_configfs.c
+++ b/drivers/target/target_core_configfs.c
@@ -457,8 +457,16 @@ void target_unregister_template(const struct
target_core_fabric_ops *fo)
if (!strcmp(t-tf_ops-name, fo-name)) {
BUG_ON(atomic_read(t-tf_access_cnt));
list_del(t-tf_list);
+ mutex_unlock(g_tf_lock);
+ /*
+ * Allow any outstanding fabric se_deve_entry-rcu_head
+ * grace periods to expire post kfree_rcu(), before
allowing
+ * fabric driver unload of
target_core_fabric_ops-module
+ * to proceed.
+ */
+ synchronize_rcu();
kfree(t);
- break;
+ return;
}
}
mutex_unlock(g_tf_lock);
diff --git a/drivers/target/target_core_hba.c
b/drivers/target/target_core_hba.c
index 62ea4e8..0fb830b 100644
--- a/drivers/target/target_core_hba.c
+++ b/drivers/target/target_core_hba.c
@@ -84,8 +84,16 @@ void target_backend_unregister(const struct
target_backend_ops *ops)
list_for_each_entry(tb, backend_list, list) {
if (tb-ops == ops) {
list_del(tb-list);
+ mutex_unlock(backend_mutex);
+ /*
+ * Allow any outstanding backend driver -rcu_head grace
+ * period to expire post -free_device() - call_rcu(),
+ * before allowing backend driver module unload of
+ * target_backend_ops-owner to proceed.
+ */
+ synchronize_rcu();
kfree(tb);
- break;
+ return;
}
}
mutex_unlock(backend_mutex);
--
1.9.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 v2 3/3] cxlflash: Virtual LUN support
Wendy:
Thanks for taking the time to review this patch. Comments inline below.
- Manoj Kumar
On 7/29/2015 5:13 PM, wenxi...@linux.vnet.ibm.com wrote:
+/* Update the free_curr_idx */
+if (bit_pos == 63)
+lun_info-free_curr_idx = bit_word + 1;
Predefined Macros for 63 and 64?
Good point. We will add definitions to indicate that the bit_word is 8
bytes.
+/**
+ * ba_clone() - frees a block from the block allocator
+ * @ba_lun:Block allocator from which to allocate a block.
+ * @to_free:Block to free.
+ *
+ * Return: 0 on success, -1 on failure
+ */
More accurate description about ba_clone() function.
Good catch. Will correct in the next version of this patch (v3).
+rc = ba_init(blka-ba_lun);
init_ba() and ba_init(). Probably one of them needs more accurate name.
Agreed. We will disambiguate in v3.
free cmd_buf and sense_buf?
Same issue that Brian had pointed out. We had already corrected earlier.
You will see it in our next submission.
+mutex_unlock(blka-mutex);
+
Should hold the lock for lightwight sync?
+/*
+ * The following sequence is prescribed in the SISlite spec
+ * for syncing up with the AFU when adding LXT entries.
+ */
+dma_wmb(); /* Make LXT updates are visible */
+
+rhte-lxt_start = lxt;
+dma_wmb(); /* Make RHT entry's LXT table update visible */
+
+rhte-lxt_cnt = my_new_size;
+dma_wmb(); /* Make RHT entry's LXT table size update visible */
+
+cxlflash_afu_sync(afu, ctxid, rhndl, AFU_LW_SYNC);
+
cxlflash_afu_sync() does ensure that only one of these SYNC commands is
outstanding at one time. No additional serialization is required.
Should hold the lock for lightwight sync?
+cxlflash_afu_sync(afu, ctxid, rhndl, AFU_HW_SYNC);
Same issue as the one discussed above. No additional serialization
should be necessary.
+/* Setup the LUN table on the first call */
+rc = init_lun_table(cfg, lli);
+if (rc) {
+pr_err(%s: call to init_lun_table failed rc=%d!\n,
+ __func__, rc);
+goto out;
+}
+
+rc = init_ba(lli);
+if (rc) {
+pr_err(%s: call to init_ba failed rc=%d!\n,
+ __func__, rc);
+rc = -ENOMEM;
Do you need to remove the entry you create in init_lun_table() if
init_ba() fails?
The LUN table is global to the adapter. If there are two threads
creating two virtual LUNs concurrently, the first one inserts the LUN
into the table. Cannot have that table entry be deleted, even if
init_ba() fails, as the other thread could be using it.
--
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] hptiop: Support HighPoint RR36xx HBAs and Support SAS tape and SAS media changer
On Wed, 2015-06-24 at 11:41 +0800, linux wrote:
Support HighPoint RR36xx HBAs which are based on Marvell Frey.
Support SAS tape and SAS media changer.
Signed-off-by: HighPoint Linux Team li...@highpoint-tech.com
drivers/scsi/hptiop.c | 104
+++
drivers/scsi/hptiop.h |6 +--
2 files changed, 69 insertions(+), 41 deletions(-)
diff -urN linux.git/drivers/scsi/hptiop.c linux/drivers/scsi/hptiop.c
--- linux.git/drivers/scsi/hptiop.c 2015-06-08 01:48:38.09375 -0400
+++ linux/drivers/scsi/hptiop.c 2015-06-08 02:45:33.234375000 -0400
@@ -1,6 +1,6 @@
/*
* HighPoint RR3xxx/4xxx controller driver for Linux
- * Copyright (C) 2006-2012 HighPoint Technologies, Inc. All Rights
Reserved.
This patch won't apply. Your email tool has broken the lines which
damage the patch.
Can you resend either preferentially from an email tool which doesn't do
linebreaks or as an attachment?
Thanks,
James
+ * Copyright (C) 2006-2015 HighPoint Technologies, Inc. All Rights
Reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -42,7 +42,7 @@
static char driver_name[] = hptiop;
static const char driver_name_long[] = RocketRAID 3xxx/4xxx Controller
driver;
-static const char driver_ver[] = v1.8;
+static const char driver_ver[] = v1.10.0;
static int iop_send_sync_msg(struct hptiop_hba *hba, u32 msg, u32
millisec);
static void hptiop_finish_scsi_req(struct hptiop_hba *hba, u32 tag,
@@ -764,9 +764,7 @@
scsi_set_resid(scp,
scsi_bufflen(scp) -
le32_to_cpu(req-dataxfer_length));
scp-result = SAM_STAT_CHECK_CONDITION;
- memcpy(scp-sense_buffer, req-sg_list,
- min_t(size_t, SCSI_SENSE_BUFFERSIZE,
- le32_to_cpu(req-dataxfer_length)));
+ memcpy(scp-sense_buffer, req-sg_list,
SCSI_SENSE_BUFFERSIZE);
goto skip_resid;
break;
@@ -1036,9 +1034,10 @@
_req-index, _req-req_virt);
scp-result = 0;
-
- if (scp-device-channel || scp-device-lun ||
- scp-device-id hba-max_devices) {
+
+ if (scp-device-channel ||
+ (scp-device-id hba-max_devices) ||
+ ((scp-device-id == (hba-max_devices-1))
scp-device-lun)) {
scp-result = DID_BAD_TARGET 16;
free_req(hba, _req);
goto cmd_done;
@@ -1168,6 +1167,14 @@
NULL
};
+static int hptiop_slave_config(struct scsi_device *sdev)
+{
+ if (sdev-type == TYPE_TAPE)
+ blk_queue_max_hw_sectors(sdev-request_queue, 8192);
+
+ return 0;
+}
+
static struct scsi_host_template driver_template = {
.module = THIS_MODULE,
.name = driver_name,
@@ -1179,6 +1186,7 @@
.use_clustering = ENABLE_CLUSTERING,
.proc_name = driver_name,
.shost_attrs= hptiop_attrs,
+ .slave_configure= hptiop_slave_config,
.this_id= -1,
.change_queue_depth = hptiop_adjust_disk_queue_depth,
};
@@ -1323,7 +1331,8 @@
}
hba = (struct hptiop_hba *)host-hostdata;
-
+ memset(hba, 0, sizeof(struct hptiop_hba));
+
hba-ops = iop_ops;
hba-pcidev = pcidev;
hba-host = host;
@@ -1336,7 +1345,7 @@
init_waitqueue_head(hba-reset_wq);
init_waitqueue_head(hba-ioctl_wq);
- host-max_lun = 1;
+ host-max_lun = 128;
host-max_channel = 0;
host-io_port = 0;
host-n_io_port = 0;
@@ -1428,34 +1437,33 @@
dprintk(req_size=%d, max_requests=%d\n, req_size,
hba-max_requests);
hba-req_size = req_size;
- start_virt = dma_alloc_coherent(pcidev-dev,
- hba-req_size*hba-max_requests + 0x20,
- start_phy, GFP_KERNEL);
-
- if (!start_virt) {
- printk(KERN_ERR scsi%d: fail to alloc request mem\n,
- hba-host-host_no);
- goto free_request_irq;
- }
-
- hba-dma_coherent = start_virt;
- hba-dma_coherent_handle = start_phy;
-
- if ((start_phy 0x1f) != 0) {
- offset = ((start_phy + 0x1f) ~0x1f) - start_phy;
- start_phy += offset;
- start_virt += offset;
- }
-
hba-req_list = NULL;
+
for (i = 0; i hba-max_requests; i++) {
+ start_virt = dma_alloc_coherent(pcidev-dev,
+ hba-req_size + 0x20,
+ start_phy, GFP_KERNEL);
+
+ if (!start_virt) {
+ printk(KERN_ERR scsi%d: fail to alloc
Re: [dm-devel] kernel BUG at drivers/scsi/scsi_lib.c:1101! observed during md5sum for one file on (RAID4-RAID0) device
On Thu, 30 Jul 2015 06:28:06 -0700 James Bottomley james.bottom...@hansenpartnership.com wrote: On Thu, 2015-07-30 at 05:03 -0400, Yi Zhang wrote: Hi SCSI/RAID maintainer During raid test with 4.2.0-rc3, I observed below kernel BUG, pls check below info for the test log/environment/test steps. Log: [ 306.741662] md: bindsdb1 [ 306.750865] md: bindsdc1 [ 306.753993] md: bindsdd1 [ 306.764475] md: bindsde1 [ 306.786156] md: bindsdf1 [ 306.789362] md: bindsdh1 [ 306.792555] md: bindsdg1 [ 306.868166] raid6: sse2x1 gen() 10589 MB/s [ 306.889143] raid6: sse2x1 xor() 8218 MB/s [ 306.910121] raid6: sse2x2 gen() 13453 MB/s [ 306.931102] raid6: sse2x2 xor() 8990 MB/s [ 306.952079] raid6: sse2x4 gen() 15539 MB/s [ 306.973063] raid6: sse2x4 xor() 10771 MB/s [ 306.994039] raid6: avx2x1 gen() 20582 MB/s [ 307.015017] raid6: avx2x2 gen() 24019 MB/s [ 307.035998] raid6: avx2x4 gen() 27824 MB/s [ 307.040755] raid6: using algorithm avx2x4 gen() 27824 MB/s [ 307.046869] raid6: using avx2x2 recovery algorithm [ 307.058793] async_tx: api initialized (async) [ 307.075428] xor: automatically using best checksumming function: [ 307.091942]avx : 32008.000 MB/sec [ 307.147662] md: raid6 personality registered for level 6 [ 307.153584] md: raid5 personality registered for level 5 [ 307.159505] md: raid4 personality registered for level 4 [ 307.165698] md/raid:md0: device sdf1 operational as raid disk 4 [ 307.172300] md/raid:md0: device sde1 operational as raid disk 3 [ 307.178899] md/raid:md0: device sdd1 operational as raid disk 2 [ 307.185497] md/raid:md0: device sdc1 operational as raid disk 1 [ 307.192093] md/raid:md0: device sdb1 operational as raid disk 0 [ 307.199052] md/raid:md0: allocated 6482kB [ 307.203573] md/raid:md0: raid level 4 active with 5 out of 6 devices, algorithm 0 [ 307.211958] md0: detected capacity change from 0 to 53645148160 [ 307.218658] md: recovery of RAID array md0 [ 307.223226] md: minimum _guaranteed_ speed: 1000 KB/sec/disk. [ 307.229729] md: using maximum available idle IO bandwidth (but not more than 20 KB/sec) for recovery. [ 307.240427] md: using 128k window, over a total of 10477568k. [ 374.670951] md: md0: recovery done. [ 375.722806] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) [ 447.553364] md: unbindsdh1 [ 447.559905] md: export_rdev(sdh1) [ 447.572684] md: cannot remove active disk sdg1 from md0 ... [ 447.578909] md/raid:md0: Disk failure on sdg1, disabling device. [ 447.578909] md/raid:md0: Operation continuing on 5 devices. [ 447.594850] md: unbindsdg1 [ 447.601834] md: export_rdev(sdg1) [ 447.615446] md: raid0 personality registered for level 0 [ 447.629275] md/raid0:md0: md_size is 104775680 sectors. [ 447.635094] md: RAID0 configuration for md0 - 1 zone [ 447.640627] md: zone0=[sdb1/sdc1/sdd1/sde1/sdf1] [ 447.645833] zone-offset= 0KB, device-offset= 0KB, size= 52387840KB [ 447.654949] [ 447.739443] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) [ 447.749258] bio too big device sde1 (768 512) This is the actual error. It looks like an md problem (md list copied). Thanks. It certainly does look like an md problem ah, found it. level_store in drivers/md/md.c calls blk_set_stacking_limits after calling -takeover and before calling -run. -run should impose the limits from the underlying device, but for RAID0, -takeover is doing that. I can fix that... hopefully it will become irrelevant soon when the immutable-bio patches go in. This patch isn't quite right, but it should be pretty close. Can you test and confirm? Thanks, NeilBrown diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c index efb654eb5399..17804f374709 100644 --- a/drivers/md/raid0.c +++ b/drivers/md/raid0.c @@ -83,7 +83,6 @@ static int create_strip_zones(struct mddev *mddev, struct r0conf **private_conf) char b[BDEVNAME_SIZE]; char b2[BDEVNAME_SIZE]; struct r0conf *conf = kzalloc(sizeof(*conf), GFP_KERNEL); - bool discard_supported = false; if (!conf) return -ENOMEM; @@ -188,19 +187,12 @@ static int create_strip_zones(struct mddev *mddev, struct r0conf **private_conf) } dev[j] = rdev1; - if (mddev-queue) - disk_stack_limits(mddev-gendisk, rdev1-bdev, - rdev1-data_offset 9); - if (rdev1-bdev-bd_disk-queue-merge_bvec_fn) conf-has_merge_bvec = 1; if (!smallest || (rdev1-sectors smallest-sectors)) smallest = rdev1; cnt++; - - if (blk_queue_discard(bdev_get_queue(rdev1-bdev))) - discard_supported = true; } if (cnt !=
Re: [PATCH] target: Wait RCU grace-period before backend/fabric unload
On Thu, 2015-07-30 at 06:07 -0700, Paul E. McKenney wrote:
On Thu, Jul 30, 2015 at 06:15:23AM +, Nicholas A. Bellinger wrote:
From: Nicholas Bellinger n...@linux-iscsi.org
This patch addresses a v4.2-rc1 regression where backend driver
struct module unload immediately after -free_device() has done
an internal call_rcu(), results in IRQ rcu_process_callbacks()
use-after-free paging OOPsen.
It adds a explicit synchronize_rcu() in target_backend_unregister()
to wait a full RCU grace period before releasing target_backend_ops
memory, and allowing TBO-module exit to proceed.
Good catch, but...
You need rcu_barrier() rather than synchronize_rcu() in this case.
All that synchronize_rcu() does is wait for pre-existing RCU readers,
when what is needed is to wait for all pre-existing RCU callbacks
to be invoked.
Ah, was getting confused by rcu_barrier_tasks() being specific to
CONFIG_TASKS_RCU in update.c code, and missing rcu_barrier() in
tree_plugin.h.
Should have taken a look at Documentation/RCU/rcubarrier.txt..
So please replace the two synchronize_rcu() calls with rcu_barrier().
nod, below is the updated version.
Thanks for the review!
--nab
From 9721910116f9883c7afded613ec88dc2de12339a Mon Sep 17 00:00:00 2001
From: Nicholas Bellinger n...@linux-iscsi.org
Date: Wed, 29 Jul 2015 22:27:13 -0700
Subject: [PATCH] target: Perform RCU callback barrier before backend/fabric
unload
This patch addresses a v4.2-rc1 regression where backend driver
module unload happening immediately after TBO-free_device()
does internal call_rcu(), will currently result in IRQ context
rcu_process_callbacks() use-after-free paging OOPsen.
It adds the missing rcu_barrier() in target_backend_unregister()
to perform an explicit RCU barrier waiting for all RCU callbacks
to complete before releasing target_backend_ops memory, and
allowing TBO-module exit to proceed.
Also, do the same for fabric drivers in target_unregister_template()
to ensure se_deve_entry-rcu_head - kfree_rcu() callbacks have
completed, before allowing target_core_fabric_ops-owner module
exit to proceed.
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Christoph Hellwig h...@lst.de
Cc: Hannes Reinecke h...@suse.de
Cc: Sagi Grimberg sa...@mellanox.com
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
---
drivers/target/target_core_configfs.c | 9 -
drivers/target/target_core_hba.c | 10 +-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/target/target_core_configfs.c
b/drivers/target/target_core_configfs.c
index c2e9fea..860e840 100644
--- a/drivers/target/target_core_configfs.c
+++ b/drivers/target/target_core_configfs.c
@@ -457,8 +457,15 @@ void target_unregister_template(const struct
target_core_fabric_ops *fo)
if (!strcmp(t-tf_ops-name, fo-name)) {
BUG_ON(atomic_read(t-tf_access_cnt));
list_del(t-tf_list);
+ mutex_unlock(g_tf_lock);
+ /*
+* Wait for any outstanding fabric
se_deve_entry-rcu_head
+* callbacks to complete post kfree_rcu(), before
allowing
+* fabric driver unload of TFO-module to proceed.
+*/
+ rcu_barrier();
kfree(t);
- break;
+ return;
}
}
mutex_unlock(g_tf_lock);
diff --git a/drivers/target/target_core_hba.c b/drivers/target/target_core_hba.c
index 62ea4e8..be9cefc 100644
--- a/drivers/target/target_core_hba.c
+++ b/drivers/target/target_core_hba.c
@@ -84,8 +84,16 @@ void target_backend_unregister(const struct
target_backend_ops *ops)
list_for_each_entry(tb, backend_list, list) {
if (tb-ops == ops) {
list_del(tb-list);
+ mutex_unlock(backend_mutex);
+ /*
+* Wait for any outstanding backend driver -rcu_head
+* callbacks to complete post TBO-free_device() -
+* call_rcu(), before allowing backend driver module
+* unload of target_backend_ops-owner to proceed.
+*/
+ rcu_barrier();
kfree(tb);
- break;
+ return;
}
}
mutex_unlock(backend_mutex);
--
1.9.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 v2 1/3] cxlflash: Base error recovery support
Wendy: Thanks for your review. Comment inline below. - Manoj Kumar On 7/29/2015 5:12 PM, wenxi...@linux.vnet.ibm.com wrote: + +cfg-eeh_active = EEH_STATE_NONE; +wake_up_all(cfg-eeh_waitq); +} + Do you need host-lock in these EEH callback functions? These are synchronous callbacks and only one of them can be active on a card at a time. So, I do not believe these need the host-lock. -- 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 0/1] be2iscsi : Add warning message for unsupported devices
Add a warning message to indicate obsolete/unsupported BE2 Adapter Family devices Ketan Mukadam (1): be2iscsi : Add warning message for unsupported adapter drivers/scsi/be2iscsi/be_main.c | 2 ++ drivers/scsi/be2iscsi/be_mgmt.c | 3 ++- 2 files changed, 4 insertions(+), 1 deletion(-) -- 1.8.3.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 2/8] pm80xx: Corrected device state changes in I_T_Nexus_Reset
On Wed, Jul 29, 2015 at 9:40 PM, Tomas Henzl the...@redhat.com wrote:
On 29.7.2015 08:27, viswa...@pmcs.com wrote:
From: Viswas G viswa...@pmcs.com
In Nexus reset the device state set to DS_IN_RECOVERY before doing
phy reset and internal cleanup. Once internal cleanup finishes,
the device state will set to DS_OPERATIONAL.
Signed-off-by: Viswas G viswa...@pmcs.com
Signed-off-by: Suresh Thiagarajan suresh.thiagara...@pmcs.com
---
drivers/scsi/pm8001/pm8001_sas.c | 14 +++---
drivers/scsi/pm8001/pm8001_sas.h |8
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/pm8001/pm8001_sas.c
b/drivers/scsi/pm8001/pm8001_sas.c
index b93f289..4e6955f 100644
--- a/drivers/scsi/pm8001/pm8001_sas.c
+++ b/drivers/scsi/pm8001/pm8001_sas.c
@@ -980,13 +980,21 @@ int pm8001_I_T_nexus_reset(struct domain_device *dev)
rc = 0;
goto out;
}
+ pm8001_dev-setds_completion = completion_setstate;
+ PM8001_CHIP_DISP-set_dev_state_req(pm8001_ha,
+ pm8001_dev, DS_IN_RECOVERY);
+ wait_for_completion(completion_setstate);
rc = sas_phy_reset(phy, 1);
msleep(2000);
+ if (rc) {
+ PM8001_EH_DBG(pm8001_ha,
+ pm8001_printk(phy reset failed for device %x\n
+ with rc %d\n, pm8001_dev-device_id, rc));
+ }
rc = pm8001_exec_internal_task_abort(pm8001_ha, pm8001_dev ,
dev, 1, 0);
- pm8001_dev-setds_completion = completion_setstate;
- rc = PM8001_CHIP_DISP-set_dev_state_req(pm8001_ha,
- pm8001_dev, 0x01);
+ PM8001_CHIP_DISP-set_dev_state_req(pm8001_ha,
+ pm8001_dev, DS_OPERATIONAL);
Hi Viswas,
the set_dev_state_req can't fail any more ? Also the
pm8001_exec_internal_task_abort may fail - shouldn't
be error handling also added ?
Cheers,
Tomas
Hi Tomas,
The set_dev_state can fail if the ccb/Inbound queue slot is not available. It
can happen
If there are more than 256 requests are penning with controller.
Internal task abort failure also can be handled. Will resent the patch with
these changes.
Regards,
Viswas G
wait_for_completion(completion_setstate);
} else {
rc = sas_phy_reset(phy, 1);
diff --git a/drivers/scsi/pm8001/pm8001_sas.h
b/drivers/scsi/pm8001/pm8001_sas.h
index 8dd8b78..c9736cc 100644
--- a/drivers/scsi/pm8001/pm8001_sas.h
+++ b/drivers/scsi/pm8001/pm8001_sas.h
@@ -569,6 +569,14 @@ struct pm8001_fw_image_header {
#define NCQ_READ_LOG_FLAG 0x8000
#define NCQ_ABORT_ALL_FLAG 0x4000
#define NCQ_2ND_RLE_FLAG0x2000
+
+/* Device states */
+#define DS_OPERATIONAL 0x01
+#define DS_PORT_IN_RESET 0x02
+#define DS_IN_RECOVERY 0x03
+#define DS_IN_ERROR 0x04
+#define DS_NON_OPERATIONAL 0x07
+
/**
* brief param structure for firmware flash update.
*/
--
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
-Original Message-
From: Tomas Henzl [mailto:the...@redhat.com]
Sent: Wednesday, July 29, 2015 9:40 PM
To: Viswas G; linux-scsi@vger.kernel.org
Cc: xjtu...@gmail.com; jbottom...@parallels.com; Suresh Thiagarajan
Subject: Re: [PATCH 2/8] pm80xx: Corrected device state changes in
I_T_Nexus_Reset
On 29.7.2015 08:27, viswa...@pmcs.com wrote:
From: Viswas G viswa...@pmcs.com
In Nexus reset the device state set to DS_IN_RECOVERY before doing phy
reset and internal cleanup. Once internal cleanup finishes, the device
state will set to DS_OPERATIONAL.
Signed-off-by: Viswas G viswa...@pmcs.com
Signed-off-by: Suresh Thiagarajan suresh.thiagara...@pmcs.com
---
drivers/scsi/pm8001/pm8001_sas.c | 14 +++---
drivers/scsi/pm8001/pm8001_sas.h |8
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/pm8001/pm8001_sas.c
b/drivers/scsi/pm8001/pm8001_sas.c
index b93f289..4e6955f 100644
--- a/drivers/scsi/pm8001/pm8001_sas.c
+++ b/drivers/scsi/pm8001/pm8001_sas.c
@@ -980,13 +980,21 @@ int pm8001_I_T_nexus_reset(struct domain_device *dev)
rc = 0;
goto out;
}
+ pm8001_dev-setds_completion = completion_setstate;
+ PM8001_CHIP_DISP-set_dev_state_req(pm8001_ha,
+ pm8001_dev, DS_IN_RECOVERY);
+ wait_for_completion(completion_setstate);
rc = sas_phy_reset(phy, 1);
msleep(2000);
+ if (rc)
Re: [PATCH] scsi: pmcraid: trivial typo in printk
On 07/29/2015 08:39 PM, Joe Perches wrote: Trivial typo fixes: o \b should be \n o coalesce format to avoid excess spaces Signed-off-by: Joe Perches j...@perches.com --- Reviewed-by: Hannes Reinecke h...@suse.com Cheers, Hannes -- Dr. Hannes ReineckezSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (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] [SCSI] atp870u: 64 bit bug in probe()
On 07/29/2015 11:36 PM, Dan Carpenter wrote: On 64 bit CPUs there is a memory corruption bug on probe(). It should be a u32 pointer instead of an unsigned long pointer or we write past the end of the setupdata[] array. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com --- Someone reported in 2003 that probe has a NULL deref so maybe it's related to this memory corruption? https://bugzilla.kernel.org/show_bug.cgi?id=1118 If only we had applied this patch when I originally sent it two years ago, then it would only be 10 years too late instead of 12! :P Reviewed-by: Hannes Reinecke h...@suse.com Cheers, Hannes -- Dr. Hannes ReineckezSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (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] scsi: a100u2w: trivial typo in printk
On 07/29/2015 08:19 PM, Colin King wrote: From: Colin Ian King colin.k...@canonical.com Trivial typo fix, \b should be \n Signed-off-by: Colin Ian King colin.k...@canonical.com --- Reviewed-by: Hannes Reinecke h...@suse.com Cheers, Hannes -- Dr. Hannes ReineckezSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (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
[PATCH] target: Wait RCU grace-period before backend/fabric unload
From: Nicholas Bellinger n...@linux-iscsi.org
This patch addresses a v4.2-rc1 regression where backend driver
struct module unload immediately after -free_device() has done
an internal call_rcu(), results in IRQ rcu_process_callbacks()
use-after-free paging OOPsen.
It adds a explicit synchronize_rcu() in target_backend_unregister()
to wait a full RCU grace period before releasing target_backend_ops
memory, and allowing TBO-module exit to proceed.
Also, go ahead and do the same for target_unregister_template()
to ensure se_deve_entry-rcu_head - kfree_rcu() grace period has
passed, before allowing target_core_fabric_ops-owner module exit
to proceed.
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Christoph Hellwig h...@lst.de
Cc: Hannes Reinecke h...@suse.de
Cc: Sagi Grimberg sa...@mellanox.com
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
---
drivers/target/target_core_configfs.c | 10 +-
drivers/target/target_core_hba.c | 10 +-
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/target/target_core_configfs.c
b/drivers/target/target_core_configfs.c
index c2e9fea..b4c3ae0 100644
--- a/drivers/target/target_core_configfs.c
+++ b/drivers/target/target_core_configfs.c
@@ -457,8 +457,16 @@ void target_unregister_template(const struct
target_core_fabric_ops *fo)
if (!strcmp(t-tf_ops-name, fo-name)) {
BUG_ON(atomic_read(t-tf_access_cnt));
list_del(t-tf_list);
+ mutex_unlock(g_tf_lock);
+ /*
+* Allow any outstanding fabric se_deve_entry-rcu_head
+* grace periods to expire post kfree_rcu(), before
allowing
+* fabric driver unload of
target_core_fabric_ops-module
+* to proceed.
+*/
+ synchronize_rcu();
kfree(t);
- break;
+ return;
}
}
mutex_unlock(g_tf_lock);
diff --git a/drivers/target/target_core_hba.c b/drivers/target/target_core_hba.c
index 62ea4e8..0fb830b 100644
--- a/drivers/target/target_core_hba.c
+++ b/drivers/target/target_core_hba.c
@@ -84,8 +84,16 @@ void target_backend_unregister(const struct
target_backend_ops *ops)
list_for_each_entry(tb, backend_list, list) {
if (tb-ops == ops) {
list_del(tb-list);
+ mutex_unlock(backend_mutex);
+ /*
+* Allow any outstanding backend driver -rcu_head grace
+* period to expire post -free_device() - call_rcu(),
+* before allowing backend driver module unload of
+* target_backend_ops-owner to proceed.
+*/
+ synchronize_rcu();
kfree(tb);
- break;
+ return;
}
}
mutex_unlock(backend_mutex);
--
1.9.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: [scsi 3/7 RESEND] scsi_debug: vfree is null safe so drop the check
Tomas == Tomas Winkler tomas.wink...@intel.com writes: Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- 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: [scsi 2/7 RESEND] scsi_debug: use SCSI_W_LUN_REPORT_LUNS instead of SAM2_WLUN_REPORT_LUNS;
Tomas == Tomas Winkler tomas.wink...@intel.com writes: Tomas use SCSI_W_LUN_REPORT_LUNS from scsi.h instead of localy defined Tomas SAM2_WLUN_REPORT_LUNS Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- 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: [scsi 1/7 RESEND] scsi_debug: define pr_fmt() for consistent logging
Tomas == Tomas Winkler tomas.wink...@intel.com writes: Tomas Use pr_fmt with both module name and __func__ Also drop few bare Tomas printk leftovers Tomas The log format should stay pretty much intact Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- 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: [scsi 5/7 RESEND] scsi_debug: schedule_resp fix input variable check
Tomas == Tomas Winkler tomas.wink...@intel.com writes: Tomas The function should never be called with cmnd NULL so put a fat Tomas WARN there. Fix also smatch wraning: schedule_resp() warn: Tomas variable dereferenced before check 'cmnd' Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- 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: [scsi 7/7] scsi_debug: resp_request: remove unused variable
Tomas == Tomas Winkler tomas.wink...@intel.com writes: Tomas Fixes the following warning In function ‘resp_requests’: Tomas drivers/scsi//scsi_debug.c:1432:15: warning: variable Tomas ‘want_dsense’ set but not used [-Wunused-but-set-variable] bool Tomas dsense, want_dsense; Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- 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: [scsi 4/7 RESEND] scsi_debug: make dump_sector static
Tomas == Tomas Winkler tomas.wink...@intel.com writes: Tomas fixes warning: warning: no previous prototype for ‘dump_sector’ Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- 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: [scsi 6/7 RESEND] scsi_debug: fix REPORT LUNS Well Known LU
Tomas == Tomas Winkler tomas.wink...@intel.com writes: Tomas The use case to report 'REPORT LUNS WLUN' described in scsi_debug Tomas documentation didn't work because: scsi_scan_host_selected() Tomas checks for: lun shost-max_lun Tomas To fix this we set: max_lun = SCSI_W_LUN_REPORT_LUNS + 1; Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- 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 5/8] pm80xx: Remove unnecessary phy disconnect while link error
On 29.7.2015 08:27, viswa...@pmcs.com wrote: From: Viswas G viswa...@pmcs.com If the link error happens, we don't need to disconnect the phy, which will remove the drive. Instead acknowledging the controller and logging the error will be enough. Signed-off-by: Viswas G viswa...@pmcs.com Signed-off-by: Suresh Thiagarajan suresh.thiagara...@pmcs.com Reviewed-by: Tomas Henzl the...@redhat.com Tomas -- 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 6/8] pm80xx: Add PORT RECOVERY TIMEOUT support
On 29.7.2015 08:27, viswa...@pmcs.com wrote: From: Viswas G viswa...@pmcs.com PORT RECOVERY TIMEOUT is the maximum time between the controller's detection of the PHY down until the receipt of the ID_Frame (from the same remote SAS port). If the time expires before the ID_FRAME is received, the port is considered INVALID and can be removed. The IOP_EVENT_PORT_RECOVERY_TIMER_TMO event is reported following the IOP_EVENT_ PHY_DOWN event when the PHY/port does not recover after Port Recovery Time. Signed-off-by: Viswas G viswa...@pmcs.com Signed-off-by: Suresh Thiagarajan suresh.thiagara...@pmcs.com Reviewed-by: Tomas Henzl the...@redhat.com Tomas -- 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 7/8] pm80xx: Handling Invalid SSP Response frame
On 29.7.2015 08:27, viswa...@pmcs.com wrote: From: Viswas G viswa...@pmcs.com The request has to be retried incase if the length of the SSP Response IU is invalid. Signed-off-by: Viswas G viswa...@pmcs.com Signed-off-by: Suresh Thiagarajan suresh.thiagara...@pmcs.com Reviewed-by: Tomas Henzl the...@redhat.com Tomas -- 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 7/8] pm80xx: Handling Invalid SSP Response frame
On 29.7.2015 08:27, viswa...@pmcs.com wrote: From: Viswas G viswa...@pmcs.com The request has to be retried incase if the length of the SSP Response IU is invalid. Signed-off-by: Viswas G viswa...@pmcs.com Signed-off-by: Suresh Thiagarajan suresh.thiagara...@pmcs.com Reviewed-by: Tomas Henzl the...@redhat.com Tomas -- 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 8/8] pm80xx: Bump pm80xx driver version to 0.1.38
On 29.7.2015 08:27, viswa...@pmcs.com wrote: From: Viswas G viswa...@pmcs.com Bump pm80xx driver version to 0.1.38. Signed-off-by: Viswas G viswa...@pmcs.com Signed-off-by: Suresh Thiagarajan suresh.thiagara...@pmcs.com Reviewed-by: Tomas Henzl the...@redhat.com Tomas -- 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
kernel BUG at drivers/scsi/scsi_lib.c:1101! observed during md5sum for one file on (RAID4-RAID0) device
Hi SCSI/RAID maintainer During raid test with 4.2.0-rc3, I observed below kernel BUG, pls check below info for the test log/environment/test steps. Log: [ 306.741662] md: bindsdb1 [ 306.750865] md: bindsdc1 [ 306.753993] md: bindsdd1 [ 306.764475] md: bindsde1 [ 306.786156] md: bindsdf1 [ 306.789362] md: bindsdh1 [ 306.792555] md: bindsdg1 [ 306.868166] raid6: sse2x1 gen() 10589 MB/s [ 306.889143] raid6: sse2x1 xor() 8218 MB/s [ 306.910121] raid6: sse2x2 gen() 13453 MB/s [ 306.931102] raid6: sse2x2 xor() 8990 MB/s [ 306.952079] raid6: sse2x4 gen() 15539 MB/s [ 306.973063] raid6: sse2x4 xor() 10771 MB/s [ 306.994039] raid6: avx2x1 gen() 20582 MB/s [ 307.015017] raid6: avx2x2 gen() 24019 MB/s [ 307.035998] raid6: avx2x4 gen() 27824 MB/s [ 307.040755] raid6: using algorithm avx2x4 gen() 27824 MB/s [ 307.046869] raid6: using avx2x2 recovery algorithm [ 307.058793] async_tx: api initialized (async) [ 307.075428] xor: automatically using best checksumming function: [ 307.091942]avx : 32008.000 MB/sec [ 307.147662] md: raid6 personality registered for level 6 [ 307.153584] md: raid5 personality registered for level 5 [ 307.159505] md: raid4 personality registered for level 4 [ 307.165698] md/raid:md0: device sdf1 operational as raid disk 4 [ 307.172300] md/raid:md0: device sde1 operational as raid disk 3 [ 307.178899] md/raid:md0: device sdd1 operational as raid disk 2 [ 307.185497] md/raid:md0: device sdc1 operational as raid disk 1 [ 307.192093] md/raid:md0: device sdb1 operational as raid disk 0 [ 307.199052] md/raid:md0: allocated 6482kB [ 307.203573] md/raid:md0: raid level 4 active with 5 out of 6 devices, algorithm 0 [ 307.211958] md0: detected capacity change from 0 to 53645148160 [ 307.218658] md: recovery of RAID array md0 [ 307.223226] md: minimum _guaranteed_ speed: 1000 KB/sec/disk. [ 307.229729] md: using maximum available idle IO bandwidth (but not more than 20 KB/sec) for recovery. [ 307.240427] md: using 128k window, over a total of 10477568k. [ 374.670951] md: md0: recovery done. [ 375.722806] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) [ 447.553364] md: unbindsdh1 [ 447.559905] md: export_rdev(sdh1) [ 447.572684] md: cannot remove active disk sdg1 from md0 ... [ 447.578909] md/raid:md0: Disk failure on sdg1, disabling device. [ 447.578909] md/raid:md0: Operation continuing on 5 devices. [ 447.594850] md: unbindsdg1 [ 447.601834] md: export_rdev(sdg1) [ 447.615446] md: raid0 personality registered for level 0 [ 447.629275] md/raid0:md0: md_size is 104775680 sectors. [ 447.635094] md: RAID0 configuration for md0 - 1 zone [ 447.640627] md: zone0=[sdb1/sdc1/sdd1/sde1/sdf1] [ 447.645833] zone-offset= 0KB, device-offset= 0KB, size= 52387840KB [ 447.654949] [ 447.739443] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) [ 447.749258] bio too big device sde1 (768 512) [ 447.754824] bio too big device sdf1 (1024 512) [ 447.759989] bio too big device sdb1 (768 512) [ 447.771102] bio too big device sdc1 (1024 512) [ 447.776276] bio too big device sdd1 (1024 512) [ 447.781459] bio too big device sde1 (1024 512) [ 447.786635] bio too big device sdf1 (768 512) [ 447.811156] bio too big device sdb1 (1024 512) [ 447.816329] bio too big device sdc1 (1024 512) [ 447.821513] bio too big device sdd1 (1024 512) [ 447.826681] bio too big device sde1 (768 512) [ 447.886106] bio too big device sdf1 (1024 512) [ 447.891269] bio too big device sdb1 (1024 512) [ 447.896452] bio too big device sdc1 (1024 512) [ 447.901628] bio too big device sdd1 (768 512) [ 447.930647] bio too big device sde1 (1024 512) [ 447.935820] bio too big device sdf1 (1024 512) [ 447.941003] bio too big device sdb1 (1024 512) [ 447.946179] bio too big device sdc1 (768 512) [ 447.976196] bio too big device sdd1 (1024 512) [ 447.981367] bio too big device sde1 (1024 512) [ 447.986549] bio too big device sdf1 (1024 512) [ 447.991728] bio too big device sdb1 (768 512) [ 448.033614] bio too big device sdc1 (1024 512) [ 448.038786] bio too big device sdd1 (1024 512) [ 448.043968] bio too big device sde1 (1024 512) [ 448.049145] bio too big device sdf1 (768 512) [ 448.083273] bio too big device sdb1 (1024 512) [ 448.088444] bio too big device sdc1 (1024 512) [ 448.093626] bio too big device sdd1 (1024 512) [ 448.098804] bio too big device sde1 (768 512) [ 448.128357] bio too big device sdf1 (1024 512) [ 448.133536] bio too big device sdb1 (1024 512) [ 448.138720] bio too big device sdc1 (1024 512) [ 448.143897] bio too big device sdd1 (768 512) [ 448.173456] bio too big device sde1 (1024 512) [ 448.178627] bio too big device sdf1 (1024 512) [ 448.183811] bio too big device sdb1 (1024 512) [ 448.188985] bio too big device sdc1 (768 512) [ 448.231050] bio too big device sdd1 (1024 512) [ 448.236221] bio too big
