kernel BUG at block/bio.c:1785 while trying to issue a discard to LVM on RAID1 md

2016-10-03 Thread Sitsofe Wheeler 
Hi,

While trying to do a discard (via blkdiscard --length 1048576
/dev/) to an LVM device atop a two disk md RAID1 the
following oops was generated:

[  103.306243] md: resync of RAID array md127
[  103.306246] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
[  103.306248] md: using maximum available idle IO bandwidth (but not
more than 20 KB/sec) for resync.
[  103.306251] md: using 128k window, over a total of 244194432k.
[  103.308158] [ cut here ]
[  103.308205] kernel BUG at block/bio.c:1785!
[  103.308243] invalid opcode:  [#1] SMP
[  103.308279] Modules linked in: vmw_vsock_vmci_transport vsock
sb_edac raid1 edac_core intel_powerclamp coretemp crct10dif_pclmul
crc32_pclmul ghash_clmulni_intel vmw_balloon ppdev intel_rapl_perf
joydev vmxnet3 parport_pc vmw_vmci parport shpchp acpi_cpufreq fjes
tpm_tis tpm i2c_piix4 dm_multipath vmwgfx drm_kms_helper ttm drm
crc32c_intel serio_raw vmw_pvscsi ata_generic pata_acpi
[  103.308641] CPU: 0 PID: 391 Comm: md127_raid1 Not tainted
4.7.5-200.fc24.x86_64 #1
[  103.308699] Hardware name: VMware, Inc. VMware Virtual
Platform/440BX Desktop Reference Platform, BIOS 6.00 09/30/2014
[  103.308784] task: 88003beb ti: 8816c000 task.ti:
8816c000
[  103.308841] RIP: 0010:[]  []
bio_split+0x82/0x90
[  103.308921] RSP: 0018:8816fb38  EFLAGS: 00010246
[  103.308972] RAX: 00057fff RBX:  RCX: 88003f017a80
[  103.309038] RDX: 0240 RSI:  RDI: 88003bc01500
[  103.309110] RBP: 8816fb50 R08: 0080 R09: 88003bc01500
[  103.310652] R10: 8816fbb0 R11:  R12: 
[  103.312043] R13:  R14: 0002 R15: 88003f168900
[  103.313419] FS:  () GS:88003ec0()
knlGS:
[  103.314815] CS:  0010 DS:  ES:  CR0: 80050033
[  103.315731] CR2: 7fdd4daeb400 CR3: 3b2c5000 CR4: 001406f0
[  103.316328] Stack:
[  103.316879]   01fe 
8816fbf0
[  103.317473]  a23b1afd 0246 02011200
88003f017a80
[  103.318050]  00058000 00803e8013c0 8816fc00
88003bc01500
[  103.318626] Call Trace:
[  103.319196]  [] blk_queue_split+0x2cd/0x620
[  103.319780]  [] blk_queue_bio+0x53/0x3d0
[  103.320378]  [] generic_make_request+0xf2/0x1d0
[  103.320960]  [] submit_bio+0x76/0x160
[  103.321535]  [] submit_bio_wait+0x63/0x90
[  103.322112]  [] raid1d+0x3ea/0xfb0 [raid1]
[  103.322688]  [] ? schedule_timeout+0x1ac/0x270
[  103.323268]  [] md_thread+0x139/0x150
[  103.323848]  [] ? prepare_to_wait_event+0xf0/0xf0
[  103.324417]  [] ? find_pers+0x70/0x70
[  103.324988]  [] kthread+0xd8/0xf0
[  103.325562]  [] ret_from_fork+0x1f/0x40
[  103.326108]  [] ? kthread_worker_fn+0x180/0x180
[  103.326654] Code: 44 89 e2 4c 89 ef e8 1e 47 03 00 41 8b 75 28 48
89 df e8 92 d6 ff ff 5b 4c 89 e8 41 5c 41 5d 5d c3 e8 63 fc ff ff 49
89 c5 eb b6 <0f> 0b 0f 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00
48 8b
[  103.328410] RIP  [] bio_split+0x82/0x90
[  103.328943]  RSP 
[  103.329474] ---[ end trace f093e2f8fabdb9b3 ]---

The kernel is 4.7.5-200.fc24.x86_64 from Fedora 24. While md is stuck
in the PENDING state the oops seems to be reproducible. If md is in
the middle of resyncing the system locks up entirely without printing
anything instead...

The "disks" are raw disk mappings of SSDs on ESXi being passed to a
VM. Here's the some initial /sys/block/ output before the any discards
are issued:
 # grep . /sys/block/sdc/queue/*
/sys/block/sdc/queue/add_random:0
/sys/block/sdc/queue/discard_granularity:512
/sys/block/sdc/queue/discard_max_bytes:4294966784
/sys/block/sdc/queue/discard_max_hw_bytes:4294966784
/sys/block/sdc/queue/discard_zeroes_data:0
/sys/block/sdc/queue/hw_sector_size:512
/sys/block/sdc/queue/io_poll:0
grep: /sys/block/sdc/queue/iosched: Is a directory
/sys/block/sdc/queue/iostats:1
/sys/block/sdc/queue/logical_block_size:512
/sys/block/sdc/queue/max_hw_sectors_kb:32767
/sys/block/sdc/queue/max_integrity_segments:0
/sys/block/sdc/queue/max_sectors_kb:1280
/sys/block/sdc/queue/max_segments:128
/sys/block/sdc/queue/max_segment_size:65536
/sys/block/sdc/queue/minimum_io_size:512
/sys/block/sdc/queue/nomerges:0
/sys/block/sdc/queue/nr_requests:128
/sys/block/sdc/queue/optimal_io_size:0
/sys/block/sdc/queue/physical_block_size:512
/sys/block/sdc/queue/read_ahead_kb:128
/sys/block/sdc/queue/rotational:0
/sys/block/sdc/queue/rq_affinity:1
/sys/block/sdc/queue/scheduler:[noop] deadline cfq
/sys/block/sdc/queue/write_cache:write through
/sys/block/sdc/queue/write_same_max_bytes:0

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

BFQ/Kyber as default I/O scheduler?

2018-04-03 Thread Sitsofe Wheeler 
Hi,

Is there any particular reason the new(ish) BFQ and Kyber I/O
schedulers have not been added to the "Default I/O scheduler" choices
in block/Kconfig.iosched ? Is it because they are multiqueue only?

-- 
Sitsofe | http://sucs.org/~sits/

Re: [BISECTED][REGRESSION] Hang while booting EeePC 900

2018-04-05 Thread Sitsofe Wheeler 
On 2 April 2018 at 21:29, Tejun Heo  wrote:
> Hello, Sitsofe.
>
> Can you see whether the following patch makes any difference?
>
> Thanks.
>
> diff --git a/block/blk-timeout.c b/block/blk-timeout.c
> index a05e367..f0e6e41 100644
> --- a/block/blk-timeout.c
> +++ b/block/blk-timeout.c
> @@ -165,7 +165,7 @@ void blk_abort_request(struct request *req)
>  * No need for fancy synchronizations.
>  */
> blk_rq_set_deadline(req, jiffies);
> -   mod_timer(>q->timeout, 0);
> +   kblockd_schedule_work(>q->timeout_work);
> } else {
> if (blk_mark_rq_complete(req))
> return;

Just out of interest, does the fact that an abort occurs mean that the
hardware is somehow broken or badly behaved?

-- 
Sitsofe | http://sucs.org/~sits/

Re: [BISECTED][REGRESSION] Hang while booting EeePC 900

2018-04-02 Thread Sitsofe Wheeler 
Hi Tejun,

On 2 April 2018 at 21:29, Tejun Heo  wrote:
>
> Can you see whether the following patch makes any difference?
>
> Thanks.
>
> diff --git a/block/blk-timeout.c b/block/blk-timeout.c
> index a05e367..f0e6e41 100644
> --- a/block/blk-timeout.c
> +++ b/block/blk-timeout.c
> @@ -165,7 +165,7 @@ void blk_abort_request(struct request *req)
>  * No need for fancy synchronizations.
>  */
> blk_rq_set_deadline(req, jiffies);
> -   mod_timer(>q->timeout, 0);
> +   kblockd_schedule_work(>q->timeout_work);
> } else {
> if (blk_mark_rq_complete(req))
> return;

That patch seems to fix the issue.

-- 
Sitsofe | http://sucs.org/~sits/

Re: BFQ/Kyber as default I/O scheduler?

2018-04-03 Thread Sitsofe Wheeler 
On 3 April 2018 at 15:21, Jens Axboe <ax...@kernel.dk> wrote:
> On 4/3/18 6:08 AM, Sitsofe Wheeler wrote:
>>
>> Is there any particular reason the new(ish) BFQ and Kyber I/O
>> schedulers have not been added to the "Default I/O scheduler" choices
>> in block/Kconfig.iosched ? Is it because they are multiqueue only?
>
> Yes, the default scheduler selection only applies to !mq schedulers.
> If you search the git log for "Architected-by" you can see why,
> there's some mailing archive goodness on the topic from the same
> time, too.

For those playing along at home the commit Jens is referring to is
"block: get rid of blk-mq default scheduler choice Kconfig entries"
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b86dd815ff74ab9eda474d1c28428ac0db2c3032
) and the mailing archive thread was
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1338302.html
).

Sigh, OK got it - udev rules for selecting multiqueue I/O schedulers
(at least until the day single queue block layer is ripped out).

(Finishing that thread made me feel like I'd been slapped in the face
by a wet trout and I had nothing to do with it! :-)

-- 
Sitsofe | http://sucs.org/~sits/