linux-kernel - Boot failure since 3.3-rc?

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-next>] [day] [month] [year] [list]

Date:	Sat, 21 Apr 2012 22:45:33 +0200
From:	Sune Mølgaard <sune@...gaard.org>
To:	linux-kernel@...r.kernel.org
Subject: Boot failure since 3.3-rc?

Hiya,

My old AMD Duron system (i386 with 2G RAM) has been unable to boot 
recent kernels, and I have bisected it down to:

commit 321bf4ed5ff5f7c62ef59f33b7eec5b154391f0a
Author: Yinghai Lu <yinghai@...nel.org>
Date:   Mon Jan 30 13:57:12 2012 -0800

     drivers/base/memory.c: fix memory_dev_init() long delay

     One system with 2048g ram, reported soft lockup on recent kernel.

[snip the trace of the bug that this should fix]

     Finally it takes about 55s to create 16400 memory entries.

     Root cause: for x86_64, 2048g (with 2g hole at [2g,4g), and TOP2 
will be 2050g), will have 16400 memory block.

     find_memory_block/subsys_find_device_by_id will be expensive with 
that many entries.

     Actually, we don't need to find that memory block for BOOT path.

     Skip that finding make it get back to normal.

     [   34.466696] cpu_dev_init done
     [   35.290080] memory_dev_init done

     Also solved the delay with topology_init when sections_per_block is 
not 1.

     Signed-off-by: Yinghai Lu <yinghai@...nel.org>
     Cc: Kay Sievers <kay.sievers@...y.org>
     Cc: Nathan Fontenot <nfont@...tin.ibm.com>
     Cc: Robin Holt <holt@....com>
     Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
     Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

:040000 040000 95174f8192a2303d9e59e5f8523a58780b828e3e 
2de57c6dc44872ac11766616f1cf05d6070b60de M	drivers

Will be happy to test patches, but compilation is obviously slow on this 
machine, so some delay might occur.

Best regards,

Sune Mølgaard

-- 
To err is human--and to blame it on a computer is even more so.
- Orben - Current Comedy

--
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/