linux-kernel - Re: [BISECTED] Today's Linus.git hangs during boot: can't find the floppy controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 9 Aug 2010 08:37:42 +0200
From:	Markus Trippelsdorf <markus@...ppelsdorf.de>
To:	walt <w41ter@...il.com>
Cc:	linux-kernel@...r.kernel.org, tj@...nel.org
Subject: Re: [BISECTED] Today's Linus.git hangs during boot: can't find the
 floppy controller

On Sun, Aug 08, 2010 at 01:17:53PM -0700, walt wrote:
> This commit produces the error:
> 
> commit 6ee0578b4daaea01c96b172c6aacca43fd9807a6
> Author: Suresh Siddha <suresh.b.siddha@...el.com>
> 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 <suresh.b.siddha@...el.com>
>     Signed-off-by: Tejun Heo <tj@...nel.org>
>     Cc: Oleg Nesterov <oleg@...hat.com>
>     Cc: Andrew Morton <akpm@...ux-foundation.org>
> 
> 
> 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.)

(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
...


-- 
»A man who doesn't know he is in prison can never escape.«
William S. Burroughs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/