Revert "blk-mq: issue directly if hw queue isn't busy in case of 'none'"

PATCH In review Ian W MORRISON 4 participants 12 messages Aug 28, 2018 – Aug 30, 2018 Block layer

lore

Share & tools

lore

Ian W MORRISON

author

2018-08-28 15:47 UTC #0 lore raw

PATCH 1/1 Revert "blk-mq: issue directly if hw queue isn't busy in case of 'none'"

Kernel oops when booting on Bay and Cherry Trail devices such as Intel Compute Stick. Bisected as:

commit 6ce3dd6eec11 ("blk-mq: issue directly if hw queue isn't busy in case of 'none'")

This patch reverts the above commit.

Signed-off-by Ian W MORRISON <[email protected]>

---
 block/blk-mq-sched.c | 13 +------------
 block/blk-mq.c       | 27 +--------------------------
 block/blk-mq.h       |  2 --
 3 files changed, 2 insertions(+), 40 deletions(-)

block/blk-mq-sched.c +1 ~~-12~~

index 29bfe8017a2d..3204c39cb39f 100644
@@ -405,19 +405,8 @@ void blk_mq_sched_insert_requests(struct request_queue *q,
 
 	if (e && e->type->ops.mq.insert_requests)
 		e->type->ops.mq.insert_requests(hctx, list, false);
-	else {
-		/*
-		 * try to issue requests directly if the hw queue isn't
-		 * busy in case of 'none' scheduler, and this way may save
-		 * us one extra enqueue & dequeue to sw queue.
-		 */
-		if (!hctx->dispatch_busy && !e && !run_queue_async) {
-			blk_mq_try_issue_list_directly(hctx, list);
-			if (list_empty(list))
-				return;
-		}
+	else
 		blk_mq_insert_requests(hctx, ctx, list);
-	}
 
 	blk_mq_run_hw_queue(hctx, run_queue_async);
 }

block/blk-mq.c +1 ~~-26~~

index 85a1c1a59c72..09e4611d330d 100644
@@ -1693,16 +1693,13 @@ static blk_status_t __blk_mq_issue_directly(struct blk_mq_hw_ctx *hctx,
 	ret = q->mq_ops->queue_rq(hctx, &bd);
 	switch (ret) {
 	case BLK_STS_OK:
-		blk_mq_update_dispatch_busy(hctx, false);
 		*cookie = new_cookie;
 		break;
 	case BLK_STS_RESOURCE:
 	case BLK_STS_DEV_RESOURCE:
-		blk_mq_update_dispatch_busy(hctx, true);
 		__blk_mq_requeue_request(rq);
 		break;
 	default:
-		blk_mq_update_dispatch_busy(hctx, false);
 		*cookie = BLK_QC_T_NONE;
 		break;
 	}

@@ -1785,27 +1782,6 @@ blk_status_t blk_mq_request_issue_directly(struct request *rq)
 	return ret;
 }
 
-void blk_mq_try_issue_list_directly(struct blk_mq_hw_ctx *hctx,
-		struct list_head *list)
-{
-	while (!list_empty(list)) {
-		blk_status_t ret;
-		struct request *rq = list_first_entry(list, struct request,
-				queuelist);
-
-		list_del_init(&rq->queuelist);
-		ret = blk_mq_request_issue_directly(rq);
-		if (ret != BLK_STS_OK) {
-			if (ret == BLK_STS_RESOURCE ||
-					ret == BLK_STS_DEV_RESOURCE) {
-				list_add(&rq->queuelist, list);
-				break;
-			}
-			blk_mq_end_request(rq, ret);
-		}
-	}
-}
-
 static blk_qc_t blk_mq_make_request(struct request_queue *q, struct bio *bio)
 {
 	const int is_sync = op_is_sync(bio->bi_opf);

@@ -1906,8 +1882,7 @@ static blk_qc_t blk_mq_make_request(struct request_queue *q, struct bio *bio)
 			blk_mq_try_issue_directly(data.hctx, same_queue_rq,
 					&cookie);
 		}
-	} else if ((q->nr_hw_queues > 1 && is_sync) || (!q->elevator &&
-			!data.hctx->dispatch_busy)) {
+	} else if (q->nr_hw_queues > 1 && is_sync) {
 		blk_mq_put_ctx(data.ctx);
 		blk_mq_bio_to_request(rq, bio);
 		blk_mq_try_issue_directly(data.hctx, rq, &cookie);

block/blk-mq.h +0 -2

index 9497b47e2526..bc2b24735ed4 100644
@@ -64,8 +64,6 @@ void blk_mq_insert_requests(struct blk_mq_hw_ctx *hctx, struct blk_mq_ctx *ctx,
 
 /* Used by blk_insert_cloned_request() to issue request directly */
 blk_status_t blk_mq_request_issue_directly(struct request *rq);
-void blk_mq_try_issue_list_directly(struct blk_mq_hw_ctx *hctx,
-				    struct list_head *list);
 
 /*
  * CPU -> queue mappings

Signature · 1 line

2.17.1

Jens Axboe

maintainer

2018-08-28 15:48 UTC #1 lore raw

Quoted 6 lines · Ian W MORRISON

Kernel oops when booting on Bay and Cherry Trail devices such as Intel Compute Stick. Bisected as:
commit 6ce3dd6eec11 ("blk-mq: issue directly if hw queue isn't busy in case of 'none'")
This patch reverts the above commit.

Did I miss the posting of that oops? Just curious where this is going wrong. Not adverse to reverting, but I'd like to try to understand the issue first.

Signature · 1 line

Jens Axboe

Ian W MORRISON

author

2018-08-28 16:07 UTC #2 lore raw

Quoted 7 lines · Jens Axboe

Quoted 5 lines · Ian W MORRISON
Kernel oops when booting on Bay and Cherry Trail devices such as Intel Compute Stick. Bisected as:
commit 6ce3dd6eec11 ("blk-mq: issue directly if hw queue isn't busy in case of 'none'")

Quoted 9 lines

Quoted 1 line
This patch reverts the above commit.
Did I miss the posting of that oops? Just curious where this is going wrong. Not adverse to reverting, but I'd like to try to understand the issue first.
--
Jens Axboe

I've not been able to capture it however manually transcribing what is on the screen:

mmc0: Got data interrupt 0x00000002 even though no data operation

followed by:

mmc0: sdhci: ============= SDHCI REGISTER DUMP ==============

Do you want any specific register value or should I transcribe each (as I am working from an image taken at boot)?

Jens Axboe

maintainer

2018-08-28 16:09 UTC #3 lore raw

Quoted 21 lines · Ian W MORRISON

Quoted 7 lines · Jens Axboe
Quoted 5 lines · Ian W MORRISON
Kernel oops when booting on Bay and Cherry Trail devices such as Intel Compute Stick. Bisected as:
commit 6ce3dd6eec11 ("blk-mq: issue directly if hw queue isn't busy in case of 'none'")
Quoted 9 lines
Quoted 1 line
This patch reverts the above commit.
Did I miss the posting of that oops? Just curious where this is going wrong. Not adverse to reverting, but I'd like to try to understand the issue first.
--
Jens Axboe
I've not been able to capture it however manually transcribing what is on the screen:

Quoted 8 lines

mmc0: Got data interrupt 0x00000002 even though no data operation
followed by:
mmc0: sdhci: ============= SDHCI REGISTER DUMP ==============
Do you want any specific register value or should I transcribe each (as I am working from an image taken at boot)?

Just take a picture of the screen, that should be good enough.

Signature · 1 line

Jens Axboe

Ian W MORRISON

author

2018-08-28 16:10 UTC #4 lore raw

Quoted 29 lines · Jens Axboe

Quoted 27 lines · Ian W MORRISON
Quoted 7 lines · Jens Axboe
Quoted 5 lines · Ian W MORRISON
Kernel oops when booting on Bay and Cherry Trail devices such as Intel Compute Stick. Bisected as:
commit 6ce3dd6eec11 ("blk-mq: issue directly if hw queue isn't busy in case of 'none'")
Quoted 9 lines
Quoted 1 line
This patch reverts the above commit.
Did I miss the posting of that oops? Just curious where this is going wrong. Not adverse to reverting, but I'd like to try to understand the issue first.
--
Jens Axboe
I've not been able to capture it however manually transcribing what is on the screen:
mmc0: Got data interrupt 0x00000002 even though no data operation
followed by:
mmc0: sdhci: ============= SDHCI REGISTER DUMP ==============

Quoted 8 lines

Quoted 2 lines
Do you want any specific register value or should I transcribe each (as I am working from an image taken at boot)?
Just take a picture of the screen, that should be good enough.
--
Jens Axboe

Attached as requested.

Jens Axboe

maintainer

2018-08-28 16:13 UTC #5 lore raw

Quoted 33 lines · Ian W MORRISON

Quoted 32 lines · Jens Axboe
Quoted 29 lines · Ian W MORRISON
Quoted 7 lines · Jens Axboe
Quoted 5 lines · Ian W MORRISON
Kernel oops when booting on Bay and Cherry Trail devices such as Intel Compute Stick. Bisected as:
commit 6ce3dd6eec11 ("blk-mq: issue directly if hw queue isn't busy in case of 'none'")
Quoted 9 lines
Quoted 1 line
This patch reverts the above commit.
Did I miss the posting of that oops? Just curious where this is going wrong. Not adverse to reverting, but I'd like to try to understand the issue first.
--
Jens Axboe
I've not been able to capture it however manually transcribing what is on the screen:
mmc0: Got data interrupt 0x00000002 even though no data operation
followed by:
mmc0: sdhci: ============= SDHCI REGISTER DUMP ==============
Do you want any specific register value or should I transcribe each (as I am working from an image taken at boot)?

Quoted 7 lines

Quoted 5 lines
Just take a picture of the screen, that should be good enough.
--
Jens Axboe
Attached as requested.

Can you see if this patch helps?

https://marc.info/?l=linux-mmc&m=153485326025301&w=2

Signature · 1 line

Jens Axboe

Ian W MORRISON

author

2018-08-28 17:01 UTC #6 lore raw

Quoted 41 lines · Jens Axboe

Quoted 39 lines · Ian W MORRISON
Quoted 37 lines · Jens Axboe
Quoted 21 lines · Ian W MORRISON
Quoted 7 lines · Jens Axboe
Quoted 5 lines · Ian W MORRISON
Kernel oops when booting on Bay and Cherry Trail devices such as Intel Compute Stick. Bisected as:
commit 6ce3dd6eec11 ("blk-mq: issue directly if hw queue isn't busy in case of 'none'")
Quoted 9 lines
Quoted 1 line
This patch reverts the above commit.
Did I miss the posting of that oops? Just curious where this is going wrong. Not adverse to reverting, but I'd like to try to understand the issue first.
--
Jens Axboe
I've not been able to capture it however manually transcribing what is on the screen:
Quoted 8 lines
mmc0: Got data interrupt 0x00000002 even though no data operation
followed by:
mmc0: sdhci: ============= SDHCI REGISTER DUMP ==============
Do you want any specific register value or should I transcribe each (as I am working from an image taken at boot)?
Just take a picture of the screen, that should be good enough.
--
Jens Axboe

Quoted 9 lines

Quoted 1 line
Attached as requested.
Can you see if this patch helps?
https://marc.info/?l=linux-mmc&m=153485326025301&w=2
--
Jens Axboe

I confirm that the above patch works with commit 6ce3dd6eec11 and removes the need for reverting it on eMMC based devices.

Tested on Bay Trail, Cherry Trail (both now working) and Kaby Lake (not affected) devices.

Many thanks,
Ian

Jens Axboe

maintainer

2018-08-28 17:12 UTC #7 lore raw

Quoted 52 lines · Ian W MORRISON

Quoted 41 lines · Jens Axboe
Quoted 39 lines · Ian W MORRISON
Quoted 37 lines · Jens Axboe
Quoted 21 lines · Ian W MORRISON
Quoted 7 lines · Jens Axboe
Quoted 5 lines · Ian W MORRISON
Kernel oops when booting on Bay and Cherry Trail devices such as Intel Compute Stick. Bisected as:
commit 6ce3dd6eec11 ("blk-mq: issue directly if hw queue isn't busy in case of 'none'")
Quoted 9 lines
Quoted 1 line
This patch reverts the above commit.
Did I miss the posting of that oops? Just curious where this is going wrong. Not adverse to reverting, but I'd like to try to understand the issue first.
--
Jens Axboe
I've not been able to capture it however manually transcribing what is on the screen:
Quoted 8 lines
mmc0: Got data interrupt 0x00000002 even though no data operation
followed by:
mmc0: sdhci: ============= SDHCI REGISTER DUMP ==============
Do you want any specific register value or should I transcribe each (as I am working from an image taken at boot)?
Just take a picture of the screen, that should be good enough.
--
Jens Axboe
Quoted 9 lines
Quoted 1 line
Attached as requested.
Can you see if this patch helps?
https://marc.info/?l=linux-mmc&m=153485326025301&w=2
--
Jens Axboe

Quoted 5 lines

I confirm that the above patch works with commit 6ce3dd6eec11 and removes the need for reverting it on eMMC based devices.
Tested on Bay Trail, Cherry Trail (both now working) and Kaby Lake (not affected) devices.

Great, thanks for testing. Adrian, when is this going upstream?

Signature · 1 line

Jens Axboe

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKZW5zIEF4Ym9lIFttYWlsdG86 YXhib2VAa2VybmVsLmRrXQ0KPiBTZW50OiBUdWVzZGF5LCBBdWd1c3QgMjgsIDIwMTggODoxMiBQ TQ0KPiBUbzogSWFuIFcgTU9SUklTT04gPGlhbndtb3JyaXNvbkBnbWFpbC5jb20+DQo+IENjOiBs aW51eC1ibG9ja0B2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7 DQo+IGthc2h5YXAuZGVzYWlAYnJvYWRjb20uY29tOyBsb2Jlcm1hbkByZWRoYXQuY29tOyBvc2Fu ZG92QGZiLmNvbTsNCj4gaGNoQGxzdC5kZTsgYmFydC52YW5hc3NjaGVAd2RjLmNvbTsgaGFyZUBz dXNlLmRlOw0KPiBtaW5nLmxlaUByZWRoYXQuY29tOyBIdW50ZXIsIEFkcmlhbiA8YWRyaWFuLmh1 bnRlckBpbnRlbC5jb20+DQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0hdIFJldmVydCAiYmxrLW1xOiBp c3N1ZSBkaXJlY3RseSBpZiBodyBxdWV1ZSBpc24ndCBidXN5IGluDQo+IGNhc2Ugb2YgJ25vbmUn Ig0KPiANCj4gT24gOC8yOC8xOCAxMTowMSBBTSwgSWFuIFcgTU9SUklTT04gd3JvdGU6DQo+ID4g T24gV2VkLCAyOSBBdWcgMjAxOCBhdCAwMjoxMywgSmVucyBBeGJvZSA8YXhib2VAa2VybmVsLmRr PiB3cm90ZToNCj4gPj4NCj4gPj4gT24gOC8yOC8xOCAxMDoxMCBBTSwgSWFuIFcgTU9SUklTT04g d3JvdGU6DQo+ID4+PiBPbiBXZWQsIDI5IEF1ZyAyMDE4IGF0IDAyOjA5LCBKZW5zIEF4Ym9lIDxh eGJvZUBrZXJuZWwuZGs+IHdyb3RlOg0KPiA+Pj4+DQo+ID4+Pj4gT24gOC8yOC8xOCAxMDowNyBB TSwgSWFuIFcgTU9SUklTT04gd3JvdGU6DQo+ID4+Pj4+IE9uIFdlZCwgMjkgQXVnIDIwMTggYXQg MDE6NDgsIEplbnMgQXhib2UgPGF4Ym9lQGtlcm5lbC5kaz4NCj4gd3JvdGU6DQo+ID4+Pj4+Pg0K PiA+Pj4+Pj4gT24gOC8yOC8xOCA5OjQ3IEFNLCBJYW4gVyBNT1JSSVNPTiB3cm90ZToNCj4gPj4+ Pj4+PiBLZXJuZWwgb29wcyB3aGVuIGJvb3Rpbmcgb24gQmF5IGFuZCBDaGVycnkgVHJhaWwgZGV2 aWNlcyBzdWNoIGFzDQo+ID4+Pj4+Pj4gSW50ZWwgQ29tcHV0ZSBTdGljay4gQmlzZWN0ZWQgYXM6 DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBjb21taXQgNmNlM2RkNmVlYzExICgiYmxrLW1xOiBpc3N1 ZSBkaXJlY3RseSBpZiBodyBxdWV1ZSBpc24ndA0KPiA+Pj4+Pj4+IGJ1c3kgaW4gY2FzZSBvZiAn bm9uZSciKQ0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gVGhpcyBwYXRjaCByZXZlcnRzIHRoZSBhYm92 ZSBjb21taXQuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gRGlkIEkgbWlzcyB0aGUgcG9zdGluZyBvZiB0 aGF0IG9vcHM/IEp1c3QgY3VyaW91cyB3aGVyZSB0aGlzIGlzDQo+ID4+Pj4+PiBnb2luZyB3cm9u Zy4gTm90IGFkdmVyc2UgdG8gcmV2ZXJ0aW5nLCBidXQgSSdkIGxpa2UgdG8gdHJ5IHRvDQo+ID4+ Pj4+PiB1bmRlcnN0YW5kIHRoZSBpc3N1ZSBmaXJzdC4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAtLQ0K PiA+Pj4+Pj4gSmVucyBBeGJvZQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gSSd2ZSBub3Qg YmVlbiBhYmxlIHRvIGNhcHR1cmUgaXQgaG93ZXZlciBtYW51YWxseSB0cmFuc2NyaWJpbmcNCj4g Pj4+Pj4gd2hhdCBpcyBvbiB0aGUgc2NyZWVuOg0KPiA+Pj4+Pg0KPiA+Pj4+PiBtbWMwOiBHb3Qg ZGF0YSBpbnRlcnJ1cHQgMHgwMDAwMDAwMiBldmVuIHRob3VnaCBubyBkYXRhIG9wZXJhdGlvbg0K PiA+Pj4+Pg0KPiA+Pj4+PiBmb2xsb3dlZCBieToNCj4gPj4+Pj4NCj4gPj4+Pj4gbW1jMDogc2Ro Y2k6ID09PT09PT09PT09PT0gU0RIQ0kgUkVHSVNURVIgRFVNUA0KPiA9PT09PT09PT09PT09PQ0K PiA+Pj4+Pg0KPiA+Pj4+PiBEbyB5b3Ugd2FudCBhbnkgc3BlY2lmaWMgcmVnaXN0ZXIgdmFsdWUg b3Igc2hvdWxkIEkgdHJhbnNjcmliZQ0KPiA+Pj4+PiBlYWNoIChhcyBJIGFtIHdvcmtpbmcgZnJv bSBhbiBpbWFnZSB0YWtlbiBhdCBib290KT8NCj4gPj4+Pg0KPiA+Pj4+IEp1c3QgdGFrZSBhIHBp Y3R1cmUgb2YgdGhlIHNjcmVlbiwgdGhhdCBzaG91bGQgYmUgZ29vZCBlbm91Z2guDQo+ID4+Pj4N Cj4gPj4+PiAtLQ0KPiA+Pj4+IEplbnMgQXhib2UNCj4gPj4+Pg0KPiA+Pj4NCj4gPj4+IEF0dGFj aGVkIGFzIHJlcXVlc3RlZC4NCj4gPj4NCj4gPj4gQ2FuIHlvdSBzZWUgaWYgdGhpcyBwYXRjaCBo ZWxwcz8NCj4gPj4NCj4gPj4gaHR0cHM6Ly9tYXJjLmluZm8vP2w9bGludXgtbW1jJm09MTUzNDg1 MzI2MDI1MzAxJnc9Mg0KPiA+Pg0KPiA+PiAtLQ0KPiA+PiBKZW5zIEF4Ym9lDQo+ID4+DQo+ID4N Cj4gPiBJIGNvbmZpcm0gdGhhdCB0aGUgYWJvdmUgcGF0Y2ggd29ya3Mgd2l0aCBjb21taXQgNmNl M2RkNmVlYzExIGFuZA0KPiA+IHJlbW92ZXMgdGhlIG5lZWQgZm9yIHJldmVydGluZyBpdCBvbiBl TU1DIGJhc2VkIGRldmljZXMuDQo+ID4NCj4gPiBUZXN0ZWQgb24gQmF5IFRyYWlsLCBDaGVycnkg VHJhaWwgKGJvdGggbm93IHdvcmtpbmcpIGFuZCBLYWJ5IExha2UNCj4gPiAobm90IGFmZmVjdGVk KSBkZXZpY2VzLg0KPiANCj4gR3JlYXQsIHRoYW5rcyBmb3IgdGVzdGluZy4gQWRyaWFuLCB3aGVu IGlzIHRoaXMgZ29pbmcgdXBzdHJlYW0/DQoNCkl0IGlzIGluIFVsZidzIGZpeGVzIGJyYW5jaCwg c28gbW9zdCBsaWtlbHkgdjQuMTktcmMyIC4gIFRoZW4gdG8gc3RhYmxlIGluIGR1ZSBjb3Vyc2Uu DQoNCglodHRwczovL2dpdC5rZXJuZWwub3JnL3B1Yi9zY20vbGludXgva2VybmVsL2dpdC91bGZo L21tYy5naXQvY29tbWl0Lz9oPWZpeGVzJmlkPTI2Y2FkZGYyNzRjZjFlODlmZDRjZTQ0YWIyYjhk YmM3YTdmOTc2ODENCg0K

Ulf Hansson

2018-08-29 06:15 UTC #9 lore raw

Quoted 70 lines · Adrian

Quoted 70 lines
-----Original Message-----
From: Jens Axboe [mailto:[email protected]]
Sent: Tuesday, August 28, 2018 8:12 PM
To: Ian W MORRISON <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Hunter, Adrian <[email protected]>
Subject: Re: [PATCH] Revert "blk-mq: issue directly if hw queue isn't busy in case of 'none'"
Quoted 7 lines · Ian W MORRISON
Quoted 6 lines · Jens Axboe
Quoted 4 lines · Ian W MORRISON
Quoted 3 lines · Jens Axboe
Quoted 1 line · Ian W MORRISON
On Wed, 29 Aug 2018 at 01:48, Jens Axboe <[email protected]>
Quoted 18 lines · wrote:
Quoted 18 lines
Quoted 18 lines
Quoted 18 lines
Quoted 18 lines
Quoted 17 lines · Ian W MORRISON
Quoted 7 lines
Kernel oops when booting on Bay and Cherry Trail devices such as Intel Compute Stick. Bisected as:
commit 6ce3dd6eec11 ("blk-mq: issue directly if hw queue isn't busy in case of 'none'")
This patch reverts the above commit.
Did I miss the posting of that oops? Just curious where this is going wrong. Not adverse to reverting, but I'd like to try to understand the issue first.
--
Jens Axboe
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
I've not been able to capture it however manually transcribing what is on the screen:
mmc0: Got data interrupt 0x00000002 even though no data operation
followed by:
mmc0: sdhci: ============= SDHCI REGISTER DUMP
==============
Quoted 23 lines
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
Quoted 3 lines
Do you want any specific register value or should I transcribe each (as I am working from an image taken at boot)?
Just take a picture of the screen, that should be good enough.
--
Jens Axboe
Quoted 9 lines
Quoted 1 line
Attached as requested.
Can you see if this patch helps?
https://marc.info/?l=linux-mmc&m=153485326025301&w=2
--
Jens Axboe
I confirm that the above patch works with commit 6ce3dd6eec11 and removes the need for reverting it on eMMC based devices.

Quoted 8 lines

Quoted 4 lines
Quoted 2 lines
Tested on Bay Trail, Cherry Trail (both now working) and Kaby Lake (not affected) devices.
Great, thanks for testing. Adrian, when is this going upstream?
It is in Ulf's fixes branch, so most likely v4.19-rc2 . Then to stable in due course.
        https://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git/commit/?h=fixes&id=26caddf274cf1e89fd4ce44ab2b8dbc7a7f97681

Yep, correct!

As I told someone before, I am deliberately holding on to fixes a little longer that before, to extend the test coverage a bit.

If someone wants to test the latest rc with fixes, one could instead try the pending-fixes branch in Stephen Rothwell's linux-next tree.

Kind regards
Uffe

Jens Axboe

maintainer

2018-08-29 14:01 UTC #10 lore raw

Quoted 80 lines · Ulf Hansson

Quoted 70 lines · Adrian
Quoted 70 lines
-----Original Message-----
From: Jens Axboe [mailto:[email protected]]
Sent: Tuesday, August 28, 2018 8:12 PM
To: Ian W MORRISON <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Hunter, Adrian <[email protected]>
Subject: Re: [PATCH] Revert "blk-mq: issue directly if hw queue isn't busy in case of 'none'"
Quoted 7 lines · Ian W MORRISON
Quoted 6 lines · Jens Axboe
Quoted 4 lines · Ian W MORRISON
Quoted 3 lines · Jens Axboe
Quoted 1 line · Ian W MORRISON
On Wed, 29 Aug 2018 at 01:48, Jens Axboe <[email protected]>
Quoted 18 lines · wrote:
Quoted 18 lines
Quoted 18 lines
Quoted 18 lines
Quoted 18 lines
Quoted 17 lines · Ian W MORRISON
Quoted 7 lines
Kernel oops when booting on Bay and Cherry Trail devices such as Intel Compute Stick. Bisected as:
commit 6ce3dd6eec11 ("blk-mq: issue directly if hw queue isn't busy in case of 'none'")
This patch reverts the above commit.
Did I miss the posting of that oops? Just curious where this is going wrong. Not adverse to reverting, but I'd like to try to understand the issue first.
--
Jens Axboe
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
I've not been able to capture it however manually transcribing what is on the screen:
mmc0: Got data interrupt 0x00000002 even though no data operation
followed by:
mmc0: sdhci: ============= SDHCI REGISTER DUMP
==============
Quoted 23 lines
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
Quoted 3 lines
Do you want any specific register value or should I transcribe each (as I am working from an image taken at boot)?
Just take a picture of the screen, that should be good enough.
--
Jens Axboe
Quoted 9 lines
Quoted 1 line
Attached as requested.
Can you see if this patch helps?
https://marc.info/?l=linux-mmc&m=153485326025301&w=2
--
Jens Axboe
I confirm that the above patch works with commit 6ce3dd6eec11 and removes the need for reverting it on eMMC based devices.
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
Tested on Bay Trail, Cherry Trail (both now working) and Kaby Lake (not affected) devices.
Great, thanks for testing. Adrian, when is this going upstream?
It is in Ulf's fixes branch, so most likely v4.19-rc2 . Then to stable in due course.
        https://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git/commit/?h=fixes&id=26caddf274cf1e89fd4ce44ab2b8dbc7a7f97681

Quoted 7 lines

Yep, correct!
As I told someone before, I am deliberately holding on to fixes a little longer that before, to extend the test coverage a bit.
If someone wants to test the latest rc with fixes, one could instead try the pending-fixes branch in Stephen Rothwell's linux-next tree.

With all due respect, you should expedite this one so we're not wasting peoples time bisecting it again and again. I didn't even know about a pending-fixes branch in the linux-next tree, so I doubt most users will.

Signature · 1 line

Jens Axboe

Ulf Hansson

2018-08-30 12:05 UTC #11 lore raw

Quoted 86 lines · Jens Axboe

Quoted 85 lines · Ulf Hansson
Quoted 70 lines · Adrian
Quoted 70 lines
-----Original Message-----
From: Jens Axboe [mailto:[email protected]]
Sent: Tuesday, August 28, 2018 8:12 PM
To: Ian W MORRISON <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Hunter, Adrian <[email protected]>
Subject: Re: [PATCH] Revert "blk-mq: issue directly if hw queue isn't busy in case of 'none'"
Quoted 7 lines · Ian W MORRISON
Quoted 6 lines · Jens Axboe
Quoted 4 lines · Ian W MORRISON
Quoted 3 lines · Jens Axboe
Quoted 1 line · Ian W MORRISON
On Wed, 29 Aug 2018 at 01:48, Jens Axboe <[email protected]>
Quoted 18 lines · wrote:
Quoted 18 lines
Quoted 18 lines
Quoted 18 lines
Quoted 18 lines
Quoted 17 lines · Ian W MORRISON
Quoted 7 lines
Kernel oops when booting on Bay and Cherry Trail devices such as Intel Compute Stick. Bisected as:
commit 6ce3dd6eec11 ("blk-mq: issue directly if hw queue isn't busy in case of 'none'")
This patch reverts the above commit.
Did I miss the posting of that oops? Just curious where this is going wrong. Not adverse to reverting, but I'd like to try to understand the issue first.
--
Jens Axboe
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
I've not been able to capture it however manually transcribing what is on the screen:
mmc0: Got data interrupt 0x00000002 even though no data operation
followed by:
mmc0: sdhci: ============= SDHCI REGISTER DUMP
==============
Quoted 23 lines
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
Quoted 3 lines
Do you want any specific register value or should I transcribe each (as I am working from an image taken at boot)?
Just take a picture of the screen, that should be good enough.
--
Jens Axboe
Quoted 9 lines
Quoted 1 line
Attached as requested.
Can you see if this patch helps?
https://marc.info/?l=linux-mmc&m=153485326025301&w=2
--
Jens Axboe
I confirm that the above patch works with commit 6ce3dd6eec11 and removes the need for reverting it on eMMC based devices.
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
Tested on Bay Trail, Cherry Trail (both now working) and Kaby Lake (not affected) devices.
Great, thanks for testing. Adrian, when is this going upstream?
It is in Ulf's fixes branch, so most likely v4.19-rc2 . Then to stable in due course.
        https://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git/commit/?h=fixes&id=26caddf274cf1e89fd4ce44ab2b8dbc7a7f97681
Yep, correct!
As I told someone before, I am deliberately holding on to fixes a little longer that before, to extend the test coverage a bit.

Quoted 7 lines

Quoted 2 lines
If someone wants to test the latest rc with fixes, one could instead try the pending-fixes branch in Stephen Rothwell's linux-next tree.
With all due respect, you should expedite this one so we're not wasting peoples time bisecting it again and again. I didn't even know about a pending-fixes branch in the linux-next tree, so I doubt most users will.

I guess it takes some time before people gets aware of the pending-fixes branch. At least I managed to highlight its presence in this thread. :-)

PR about to be created, I keep the folkz in this thread on cc once I post it.

Kind regards
Uffe