Skip to contentSkip to conversation

Today's Linus.git hangs during boot: can't find the floppy controller

BISECTED In review walt 7 participants 16 messages Aug 8, 2010 – Jun 19, 2018

Subsystems (3)
DRM drivers DRM misc Workqueue
lore
Share & tools
lore

walt

author
#0 lore raw

This commit produces the error:

commit 6ee0578b4daaea01c96b172c6aacca43fd9807a6

Author: Suresh Siddha <[email protected]>
Date:   Fri Jul 30 14:57:37 2010 -0700

workqueue: mark init_workqueues() as early_initcall()

Mark init_workqueues() as early_initcall() and thus it will be initialized before smp bringup. init_workqueues() registers for the hotcpu notifier and thus it should cope with the processors that are brought online after the workqueues are initialized.

x86 smp bringup code uses workqueues and uses a workaround for the cold boot process (as the workqueues are initialized post smp_init()). Marking init_workqueues() as early_initcall() will pave the way for cleaning up this code.

Signed-off-by Suresh Siddha <[email protected]>
Signed-off-by Tejun Heo <[email protected]>
Cc Oleg Nesterov <[email protected]>
Cc Andrew Morton <[email protected]>

Just after the error message about the floppy controller not found, the machine hangs for two minutes and then this message:

task swapper:1 blocked for greater than 120 seconds, followed by a stack trace, and again every two minutes AFAICT.

I'm not including all the gory messages and stack traces because I'm hoping you'll know what the problem is without them. (Fingers crossed.)

BTW, I see this problem only on my dual-core machine, not the older single single processor machine, as I would expect from reading the commit message. (Both machine have properly functioning floppy drives.)

I'll be happy to supply more details if needed.

Thanks

#1 lore raw
Quoted 30 lines · walt

This commit produces the error:

commit 6ee0578b4daaea01c96b172c6aacca43fd9807a6

Author: Suresh Siddha <[email protected]>
Date:   Fri Jul 30 14:57:37 2010 -0700

workqueue: mark init_workqueues() as early_initcall()

Mark init_workqueues() as early_initcall() and thus it will be initialized before smp bringup. init_workqueues() registers for the hotcpu notifier and thus it should cope with the processors that are brought online after the workqueues are initialized.

x86 smp bringup code uses workqueues and uses a workaround for the cold boot process (as the workqueues are initialized post smp_init()). Marking init_workqueues() as early_initcall() will pave the way for cleaning up this code.

Signed-off-by Suresh Siddha <[email protected]>
Signed-off-by Tejun Heo <[email protected]>
Cc Oleg Nesterov <[email protected]>
Cc Andrew Morton <[email protected]>

Just after the error message about the floppy controller not found, the machine hangs for two minutes and then this message:

task swapper:1 blocked for greater than 120 seconds, followed by a stack trace, and again every two minutes AFAICT.

Quoted 6 lines

I'm not including all the gory messages and stack traces because I'm hoping you'll know what the problem is without them. (Fingers crossed.)

BTW, I see this problem only on my dual-core machine, not the older single single processor machine, as I would expect from reading the commit message. (Both machine have properly functioning floppy drives.)

(Added Tejun to CC)

I see a similar problem here. The kernel will boot, but the system will not initialize (no X11).
After reverting the commit, the system starts normally and the only workqueue problem left is drm related:

% dmesg | grep ERROR
[drm:drm_kms_helper_poll_enable] *ERROR* delayed enqueue failed 1 [drm:output_poll_execute] *ERROR* delayed enqueue failed 1 [drm:output_poll_execute] *ERROR* delayed enqueue failed 1 [drm:output_poll_execute] *ERROR* delayed enqueue failed 1 [drm:output_poll_execute] *ERROR* delayed enqueue failed 1 [drm:output_poll_execute] *ERROR* delayed enqueue failed 1 [drm:output_poll_execute] *ERROR* delayed enqueue failed 1 [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
...

Signature · 2 lines
»A man who doesn't know he is in prison can never escape.«
William S. Burroughs
#2 lore raw
Quoted 38 lines · Markus Trippelsdorf
Quoted 30 lines · walt

This commit produces the error:

commit 6ee0578b4daaea01c96b172c6aacca43fd9807a6

Author: Suresh Siddha <[email protected]>
Date:   Fri Jul 30 14:57:37 2010 -0700

workqueue: mark init_workqueues() as early_initcall()

Mark init_workqueues() as early_initcall() and thus it will be initialized before smp bringup. init_workqueues() registers for the hotcpu notifier and thus it should cope with the processors that are brought online after the workqueues are initialized.

x86 smp bringup code uses workqueues and uses a workaround for the cold boot process (as the workqueues are initialized post smp_init()). Marking init_workqueues() as early_initcall() will pave the way for cleaning up this code.

Signed-off-by Suresh Siddha <[email protected]>
Signed-off-by Tejun Heo <[email protected]>
Cc Oleg Nesterov <[email protected]>
Cc Andrew Morton <[email protected]>

Just after the error message about the floppy controller not found, the machine hangs for two minutes and then this message:

task swapper:1 blocked for greater than 120 seconds, followed by a stack trace, and again every two minutes AFAICT.

Quoted 6 lines

I'm not including all the gory messages and stack traces because I'm hoping you'll know what the problem is without them. (Fingers crossed.)

BTW, I see this problem only on my dual-core machine, not the older single single processor machine, as I would expect from reading the commit message. (Both machine have properly functioning floppy drives.)

Quoted 6 lines

(Added Tejun to CC)

I see a similar problem here. The kernel will boot, but the system will not initialize (no X11).
After reverting the commit, the system starts normally and the only workqueue problem left is drm related:

I would guess that both of you have CONFIG_HOTPLUG_CPU disabled and enabling that config option will make the problem disappear.

Quoted 1 line

From the problem description and the patch it looks like it got screwed up

the same way I did two years ago.
See commits a802dd0eb5fc97a50cf1abb1f788a8f6cc5db635 and 4403b406d4369a275d483ece6ddee0088cc0d592.

#3 lore raw
Quoted 46 lines · Heiko Carstens
Quoted 38 lines · Markus Trippelsdorf
Quoted 30 lines · walt

This commit produces the error:

commit 6ee0578b4daaea01c96b172c6aacca43fd9807a6

Author: Suresh Siddha <[email protected]>
Date:   Fri Jul 30 14:57:37 2010 -0700

workqueue: mark init_workqueues() as early_initcall()

Mark init_workqueues() as early_initcall() and thus it will be initialized before smp bringup. init_workqueues() registers for the hotcpu notifier and thus it should cope with the processors that are brought online after the workqueues are initialized.

x86 smp bringup code uses workqueues and uses a workaround for the cold boot process (as the workqueues are initialized post smp_init()). Marking init_workqueues() as early_initcall() will pave the way for cleaning up this code.

Signed-off-by Suresh Siddha <[email protected]>
Signed-off-by Tejun Heo <[email protected]>
Cc Oleg Nesterov <[email protected]>
Cc Andrew Morton <[email protected]>

Just after the error message about the floppy controller not found, the machine hangs for two minutes and then this message:

task swapper:1 blocked for greater than 120 seconds, followed by a stack trace, and again every two minutes AFAICT.

Quoted 6 lines

I'm not including all the gory messages and stack traces because I'm hoping you'll know what the problem is without them. (Fingers crossed.)

BTW, I see this problem only on my dual-core machine, not the older single single processor machine, as I would expect from reading the commit message. (Both machine have properly functioning floppy drives.)

Quoted 6 lines

(Added Tejun to CC)

I see a similar problem here. The kernel will boot, but the system will not initialize (no X11).
After reverting the commit, the system starts normally and the only workqueue problem left is drm related:

Quoted 6 lines

I would guess that both of you have CONFIG_HOTPLUG_CPU disabled and enabling that config option will make the problem disappear.
From the problem description and the patch it looks like it got screwed up the same way I did two years ago.
See commits a802dd0eb5fc97a50cf1abb1f788a8f6cc5db635 and 4403b406d4369a275d483ece6ddee0088cc0d592.

Add Suresh to cc list.

maintainer
#4 lore raw

Hello,

Quoted 11 lines · Heiko Carstens
Quoted 11 lines
Quoted 4 lines

I see a similar problem here. The kernel will boot, but the system will not initialize (no X11).
After reverting the commit, the system starts normally and the only workqueue problem left is drm related:

I would guess that both of you have CONFIG_HOTPLUG_CPU disabled and enabling that config option will make the problem disappear.
From the problem description and the patch it looks like it got screwed up the same way I did two years ago.
See commits a802dd0eb5fc97a50cf1abb1f788a8f6cc5db635 and 4403b406d4369a275d483ece6ddee0088cc0d592.

Heh, that's almost hilarious. I'll see if this can be fixed differently this time.

Thanks.

Signature · 1 line
tejun
#5 lore raw

PATCH 1/1 workqueue: workqueue_cpu_callback() should be cpu_notifier not hotcpu_notifier

Commit 6ee0578b (workqueue: mark init_workqueues as early_initcall) made workqueue SMP initialization depend on workqueue_cpu_callback(), which however was registered as hotcpu_notifier() and didn't get called if CONFIG_HOTPLUG_CPU is not set. This made gcwqs on non-boot CPUs not create their initial workers leading to boot failures. Fix it by making it a cpu_notifier.

Signed-off-by Tejun Heo <[email protected]>
Reported-and-bisected-by walt <[email protected]>

---
So, something like this. Can you please verify the fix?

Thanks.

 kernel/workqueue.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/workqueue.c +1 -1
index da6c482..2994a0e 100644
@@ -3527,7 +3527,7 @@ static int __init init_workqueues(void)
 	unsigned int cpu;
 	int i;
 
-	hotcpu_notifier(workqueue_cpu_callback, CPU_PRI_WORKQUEUE);
+	cpu_notifier(workqueue_cpu_callback, CPU_PRI_WORKQUEUE);
 
 	/* initialize gcwqs */
 	for_each_gcwq_cpu(cpu) {
#6 lore raw

Re: [PATCH wq#for-linus] workqueue: workqueue_cpu_callback() should be cpu_notifier not hotcpu_notifier

Quoted 8 lines · Tejun Heo

Commit 6ee0578b (workqueue: mark init_workqueues as early_initcall) made workqueue SMP initialization depend on workqueue_cpu_callback(), which however was registered as hotcpu_notifier() and didn't get called if CONFIG_HOTPLUG_CPU is not set. This made gcwqs on non-boot CPUs not create their initial workers leading to boot failures. Fix it by making it a cpu_notifier.

So, something like this. Can you please verify the fix?

This fixes the boot problem here. Thanks.
(The drm delayed enqueue problem, which I mentioned earlier still persists.)

Signature · 2 lines
»A man who doesn't know he is in prison can never escape.«
William S. Burroughs
#7 lore raw

Re: [PATCH wq#for-linus] workqueue: workqueue_cpu_callback() should be cpu_notifier not hotcpu_notifier

Hello,

Quoted 1 line · Markus Trippelsdorf

This fixes the boot problem here. Thanks.

Great. May I add your Tested-by?

Quoted 2 lines

(The drm delayed enqueue problem, which I mentioned earlier still persists.)

Yeah, I'm looking into it now but it looks like the error message is simply spurious. queue_delayed_work() returns 1 if the work was actually queued and 0 if it was already pending and thus the function call was no-op. output_poll_execute() is incorrectly interpreting 1 return as error. I'll look through the history and try to find out whether/how wq changes affected the behavior, but the fix is most likely simply killing the message.

Thanks.

Signature · 1 line
tejun
Tested-by
#8 lore raw

Re: [PATCH wq#for-linus] workqueue: workqueue_cpu_callback() should be cpu_notifier not hotcpu_notifier

Quoted 6 lines · Tejun Heo

Hello,

Quoted 1 line · Markus Trippelsdorf

This fixes the boot problem here. Thanks.

Great. May I add your Tested-by?

Sure.

Tested-by Markus Trippelsdorf <[email protected]>
Quoted 10 lines
Quoted 2 lines

(The drm delayed enqueue problem, which I mentioned earlier still persists.)

Yeah, I'm looking into it now but it looks like the error message is simply spurious. queue_delayed_work() returns 1 if the work was actually queued and 0 if it was already pending and thus the function call was no-op. output_poll_execute() is incorrectly interpreting 1 return as error. I'll look through the history and try to find out whether/how wq changes affected the behavior, but the fix is most likely simply killing the message.

Yes, this looks like a cosmetic issue and I observe no other graphics problems at all.

Signature · 2 lines
»A man who doesn't know he is in prison can never escape.«
William S. Burroughs
#9 lore raw

PATCH 1/1 drm: fix a fallout from slow-work -> wq conversion

In reply to Tejun Heo

Commit 991ea75c (drm: use workqueue instead of slow-work), which made drm to use wq instead of slow-work, didn't account for the return value difference between delayed_slow_work_enqueue() and queue_delayed_work(). The former returns 0 on success and -errno on failures while the latter never fails and only uses the return value to indicate whether the work was already pending or not.

This misconversion triggered spurious error messages. Remove the now unnecessary return value check and error message.

Signed-off-by Tejun Heo <[email protected]>
Reported-by Markus Trippelsdorf <[email protected]>
Cc David Airlie <[email protected]>
Cc [email protected]

---
Markus, it's almost trivial but it would be great if you can test this one too.

David, may I route this wq#for-linus?

Thanks.

 drivers/gpu/drm/drm_crtc_helper.c |    8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)
drivers/gpu/drm/drm_crtc_helper.c +2 -6
index 4598130..211ed7e 100644
@@ -839,7 +839,6 @@ static void output_poll_execute(struct work_struct *work)
 	struct drm_connector *connector;
 	enum drm_connector_status old_status, status;
 	bool repoll = false, changed = false;
-	int ret;
 
 	mutex_lock(&dev->mode_config.mutex);
 	list_for_each_entry(connector, &dev->mode_config.connector_list, head) {

@@ -874,11 +873,8 @@ static void output_poll_execute(struct work_struct *work)
 			dev->mode_config.funcs->output_poll_changed(dev);
 	}
 
-	if (repoll) {
-		ret = queue_delayed_work(system_nrt_wq, delayed_work, DRM_OUTPUT_POLL_PERIOD);
-		if (ret)
-			DRM_ERROR("delayed enqueue failed %d\n", ret);
-	}
+	if (repoll)
+		queue_delayed_work(system_nrt_wq, delayed_work, DRM_OUTPUT_POLL_PERIOD);
 }
 
 void drm_kms_helper_poll_disable(struct drm_device *dev)
#10 lore raw

Re: [PATCH wq#for-linus] drm: fix a fallout from slow-work -> wq conversion

Quoted 10 lines · Tejun Heo

Commit 991ea75c (drm: use workqueue instead of slow-work), which made drm to use wq instead of slow-work, didn't account for the return value difference between delayed_slow_work_enqueue() and queue_delayed_work(). The former returns 0 on success and -errno on failures while the latter never fails and only uses the return value to indicate whether the work was already pending or not.

This misconversion triggered spurious error messages. Remove the now unnecessary return value check and error message.

Quoted 7 lines
Signed-off-by Tejun Heo <[email protected]>
Reported-by Markus Trippelsdorf <[email protected]>
Cc David Airlie <[email protected]>
Cc [email protected]

---
Markus, it's almost trivial but it would be great if you can test this one too.

Looks good, but drm_kms_helper_poll_disable needs the same treatment.

drivers/gpu/drm/drm_crtc_helper.c +4 -12
index 4598130..b9e4dbf 100644
@@ -839,7 +839,6 @@ static void output_poll_execute(struct work_struct *work)
 	struct drm_connector *connector;
 	enum drm_connector_status old_status, status;
 	bool repoll = false, changed = false;
-	int ret;
 
 	mutex_lock(&dev->mode_config.mutex);
 	list_for_each_entry(connector, &dev->mode_config.connector_list, head) {

@@ -874,11 +873,8 @@ static void output_poll_execute(struct work_struct *work)
 			dev->mode_config.funcs->output_poll_changed(dev);
 	}
 
-	if (repoll) {
-		ret = queue_delayed_work(system_nrt_wq, delayed_work, DRM_OUTPUT_POLL_PERIOD);
-		if (ret)
-			DRM_ERROR("delayed enqueue failed %d\n", ret);
-	}
+	if (repoll)
+		queue_delayed_work(system_nrt_wq, delayed_work, DRM_OUTPUT_POLL_PERIOD);
 }
 
 void drm_kms_helper_poll_disable(struct drm_device *dev)

@@ -893,18 +889,14 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
 {
 	bool poll = false;
 	struct drm_connector *connector;
-	int ret;
 
 	list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
 		if (connector->polled)
 			poll = true;
 	}
 
-	if (poll) {
-		ret = queue_delayed_work(system_nrt_wq, &dev->mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
-		if (ret)
-			DRM_ERROR("delayed enqueue failed %d\n", ret);
-	}
+	if (poll)
+		queue_delayed_work(system_nrt_wq, &dev->mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
 }
 EXPORT_SYMBOL(drm_kms_helper_poll_enable);
Signature · 2 lines
»A man who doesn't know he is in prison can never escape.«
William S. Burroughs
#11 lore raw

PATCH 1/1 drm: fix fallouts from slow-work -> wq conversion

Quoted 1 line

From 9a919c46dfa48a9c1f465174609b90253eb8ffc1 Mon Sep 17 00:00:00 2001

From: Tejun Heo <[email protected]>
Date: Mon, 9 Aug 2010 12:01:27 +0200

Commit 991ea75c (drm: use workqueue instead of slow-work), which made drm to use wq instead of slow-work, didn't account for the return value difference between delayed_slow_work_enqueue() and queue_delayed_work(). The former returns 0 on success and -errno on failures while the latter never fails and only uses the return value to indicate whether the work was already pending or not.

This misconversion triggered spurious error messages. Remove the now unnecessary return value check and error message.

Markus: caught another incorrect conversion in drm_kms_helper_poll_enable()

Signed-off-by Tejun Heo <[email protected]>
Reported-by Markus Trippelsdorf <[email protected]>
Tested-by Markus Trippelsdorf <[email protected]>
Cc David Airlie <[email protected]>
Cc [email protected]

---
Oops, you're right. So, this should do it.

Thank you.

 drivers/gpu/drm/drm_crtc_helper.c |   16 ++++------------
 1 files changed, 4 insertions(+), 12 deletions(-)
drivers/gpu/drm/drm_crtc_helper.c +4 -12
index 4598130..b9e4dbf 100644
@@ -839,7 +839,6 @@ static void output_poll_execute(struct work_struct *work)
 	struct drm_connector *connector;
 	enum drm_connector_status old_status, status;
 	bool repoll = false, changed = false;
-	int ret;
 
 	mutex_lock(&dev->mode_config.mutex);
 	list_for_each_entry(connector, &dev->mode_config.connector_list, head) {

@@ -874,11 +873,8 @@ static void output_poll_execute(struct work_struct *work)
 			dev->mode_config.funcs->output_poll_changed(dev);
 	}
 
-	if (repoll) {
-		ret = queue_delayed_work(system_nrt_wq, delayed_work, DRM_OUTPUT_POLL_PERIOD);
-		if (ret)
-			DRM_ERROR("delayed enqueue failed %d\n", ret);
-	}
+	if (repoll)
+		queue_delayed_work(system_nrt_wq, delayed_work, DRM_OUTPUT_POLL_PERIOD);
 }
 
 void drm_kms_helper_poll_disable(struct drm_device *dev)

@@ -893,18 +889,14 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
 {
 	bool poll = false;
 	struct drm_connector *connector;
-	int ret;
 
 	list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
 		if (connector->polled)
 			poll = true;
 	}
 
-	if (poll) {
-		ret = queue_delayed_work(system_nrt_wq, &dev->mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
-		if (ret)
-			DRM_ERROR("delayed enqueue failed %d\n", ret);
-	}
+	if (poll)
+		queue_delayed_work(system_nrt_wq, &dev->mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
 }
 EXPORT_SYMBOL(drm_kms_helper_poll_enable);
Signature · 1 line
1.7.1
author
#12 lore raw

Re: [PATCH] drm: fix fallouts from slow-work -> wq conversion

Quoted 51 lines · Tejun Heo

From 9a919c46dfa48a9c1f465174609b90253eb8ffc1 Mon Sep 17 00:00:00 2001
From: Tejun Heo<[email protected]>
Date: Mon, 9 Aug 2010 12:01:27 +0200

Commit 991ea75c (drm: use workqueue instead of slow-work), which made drm to use wq instead of slow-work, didn't account for the return value difference between delayed_slow_work_enqueue() and queue_delayed_work(). The former returns 0 on success and -errno on failures while the latter never fails and only uses the return value to indicate whether the work was already pending or not.

This misconversion triggered spurious error messages. Remove the now unnecessary return value check and error message.

drivers/gpu/drm/drm_crtc_helper.c +2 -7
index 4598130..b9e4dbf 100644
@@ -839,7 +839,6 @@ static void output_poll_execute(struct work_struct *work)
  	struct drm_connector *connector;
  	enum drm_connector_status old_status, status;
  	bool repoll = false, changed = false;
-	int ret;
 
  	mutex_lock(&dev->mode_config.mutex);
  	list_for_each_entry(connector,&dev->mode_config.connector_list, head) {

@@ -874,11 +873,8 @@ static void output_poll_execute(struct work_struct *work)
  			dev->mode_config.funcs->output_poll_changed(dev);
  	}
 
-	if (repoll) {
-		ret = queue_delayed_work(system_nrt_wq, delayed_work, DRM_OUTPUT_POLL_PERIOD);
-		if (ret)
-			DRM_ERROR("delayed enqueue failed %d\n", ret);
-	}
+	if (repoll)
+		queue_delayed_work(system_nrt_wq, delayed_work, DRM_OUTPUT_POLL_PERIOD);
  }
 
  void drm_kms_helper_poll_disable(struct drm_device *dev)

@@ -893,18 +889,14 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
  {
  	bool poll = false;
  	struct drm_connector *connector;
-	int ret;
 
  	list_for_each_entry(connector,&dev->mode_config.connector_list, head) {
  		if (connector->polled)
  			poll = true;
  	}

drivers/gpu/drm/drm_crtc_helper.c void drm_kms_helper_poll_enable(struct drm_device *dev) · line 901

Quoted 10 lines
drivers/gpu/drm/drm_crtc_helper.c +2 -5
 
-	if (poll) {
-		ret = queue_delayed_work(system_nrt_wq,&dev->mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
-		if (ret)
-			DRM_ERROR("delayed enqueue failed %d\n", ret);
-	}
+	if (poll)
+		queue_delayed_work(system_nrt_wq,&dev->mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
  }
  EXPORT_SYMBOL(drm_kms_helper_poll_enable);

I was getting the same spurious error messages, and this patches fixes it, thanks.

maintainer Acked-by David Airlie on v1 1/1
#13 lore raw

Re: [PATCH] drm: fix fallouts from slow-work -> wq conversion

In reply to Tejun Heo
Quoted 11 lines · Tejun Heo
Quoted 1 line

From 9a919c46dfa48a9c1f465174609b90253eb8ffc1 Mon Sep 17 00:00:00 2001

From: Tejun Heo <[email protected]>
Date: Mon, 9 Aug 2010 12:01:27 +0200

Commit 991ea75c (drm: use workqueue instead of slow-work), which made drm to use wq instead of slow-work, didn't account for the return value difference between delayed_slow_work_enqueue() and queue_delayed_work(). The former returns 0 on success and -errno on failures while the latter never fails and only uses the return value to indicate whether the work was already pending or not.

Quoted 4 lines

This misconversion triggered spurious error messages. Remove the now unnecessary return value check and error message.

Markus: caught another incorrect conversion in drm_kms_helper_poll_enable()

Acked-by David Airlie <[email protected]>

For queuing via your tree.

Thanks,
Dave.

Quoted 70 lines
Signed-off-by Tejun Heo <[email protected]>
Reported-by Markus Trippelsdorf <[email protected]>
Tested-by Markus Trippelsdorf <[email protected]>
Cc David Airlie <[email protected]>
Cc [email protected]

---
Oops, you're right. So, this should do it.

Thank you.

 drivers/gpu/drm/drm_crtc_helper.c |   16 ++++------------
 1 files changed, 4 insertions(+), 12 deletions(-)
drivers/gpu/drm/drm_crtc_helper.c +4 -13
index 4598130..b9e4dbf 100644
@@ -839,7 +839,6 @@ static void output_poll_execute(struct work_struct *work)
        struct drm_connector *connector;
        enum drm_connector_status old_status, status;
        bool repoll = false, changed = false;
-       int ret;
 
        mutex_lock(&dev->mode_config.mutex);
        list_for_each_entry(connector, &dev->mode_config.connector_list, head) {

@@ -874,11 +873,8 @@ static void output_poll_execute(struct work_struct *work)
                        dev->mode_config.funcs->output_poll_changed(dev);
        }
 
-       if (repoll) {
-               ret = queue_delayed_work(system_nrt_wq, delayed_work, DRM_OUTPUT_POLL_PERIOD);
-               if (ret)
-                       DRM_ERROR("delayed enqueue failed %d\n", ret);
-       }
+       if (repoll)
+               queue_delayed_work(system_nrt_wq, delayed_work, DRM_OUTPUT_POLL_PERIOD);
 }
 
 void drm_kms_helper_poll_disable(struct drm_device *dev)

@@ -893,18 +889,14 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
 {
        bool poll = false;
        struct drm_connector *connector;
-       int ret;
 
        list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
                if (connector->polled)
                        poll = true;
        }
 
-       if (poll) {
-               ret = queue_delayed_work(system_nrt_wq, &dev->mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
-               if (ret)
-                       DRM_ERROR("delayed enqueue failed %d\n", ret);
-       }
+       if (poll)
+               queue_delayed_work(system_nrt_wq, &dev->mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
 }
 EXPORT_SYMBOL(drm_kms_helper_poll_enable);
 
--

1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 4 lines

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

author
#14 lore raw

Re: [PATCH wq#for-linus] workqueue: workqueue_cpu_callback() should be cpu_notifier not hotcpu_notifier

In reply to Tejun Heo
Quoted 15 lines · Tejun Heo

Commit 6ee0578b (workqueue: mark init_workqueues as early_initcall) made workqueue SMP initialization depend on workqueue_cpu_callback(), which however was registered as hotcpu_notifier() and didn't get called if CONFIG_HOTPLUG_CPU is not set. This made gcwqs on non-boot CPUs not create their initial workers leading to boot failures. Fix it by making it a cpu_notifier.
---
So, something like this. Can you please verify the fix?

kernel/workqueue.c +0 -0
index da6c482..2994a0e 100644

kernel/workqueue.c static int __init init_workqueues(void) · line 3530

Quoted 5 lines
kernel/workqueue.c +1 -1
@@ -3527,7 +3527,7 @@ static int __init init_workqueues(void)
  	unsigned int cpu;
  	int i;
 
-	hotcpu_notifier(workqueue_cpu_callback, CPU_PRI_WORKQUEUE);
+	cpu_notifier(workqueue_cpu_callback, CPU_PRI_WORKQUEUE);

This fixes the hang during boot for me too, thanks.

Acked-by on v1 1/1
#15 lore raw

Re: [PATCH wq#for-linus] workqueue: workqueue_cpu_callback() should be cpu_notifier not hotcpu_notifier

In reply to Tejun Heo
Quoted 22 lines · Tejun Heo

Commit 6ee0578b (workqueue: mark init_workqueues as early_initcall) made workqueue SMP initialization depend on workqueue_cpu_callback(), which however was registered as hotcpu_notifier() and didn't get called if CONFIG_HOTPLUG_CPU is not set. This made gcwqs on non-boot CPUs not create their initial workers leading to boot failures. Fix it by making it a cpu_notifier.

Signed-off-by Tejun Heo <[email protected]>
Reported-and-bisected-by walt <[email protected]>

---
So, something like this. Can you please verify the fix?

Thanks.

 kernel/workqueue.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/workqueue.c +0 -0
index da6c482..2994a0e 100644

kernel/workqueue.c static int __init init_workqueues(void) · line 3533

Quoted 8 lines
kernel/workqueue.c +1 -1
@@ -3527,7 +3527,7 @@ static int __init init_workqueues(void)
 	unsigned int cpu;
 	int i;
 
-	hotcpu_notifier(workqueue_cpu_callback, CPU_PRI_WORKQUEUE);
+	cpu_notifier(workqueue_cpu_callback, CPU_PRI_WORKQUEUE);
 
 	/* initialize gcwqs */
 	for_each_gcwq_cpu(cpu) {
Acked-by Suresh Siddha <[email protected]>