| 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
| ||
|
Message-Id: <1245709281.20062.7.camel@pasglop> Date: Tue, 23 Jun 2009 08:21:21 +1000 From: Benjamin Herrenschmidt <benh@...nel.crashing.org> To: Brian King <brking@...ux.vnet.ibm.com> Cc: James Bottomley <James.Bottomley@...senPartnership.com>, linuxppc-dev@...abs.org, Pekka Enberg <penberg@...helsinki.fi>, Linux Kernel list <linux-kernel@...r.kernel.org> Subject: Re: Boot failure on the powerstation with 2.6.30 latest On Mon, 2009-06-22 at 11:11 -0500, Brian King wrote: > James, > > I was running into a similar hang on one of my Power boxes as well. > Reverting c868d550115b9ccc0027c67265b9520790f05601 allowed by system > to boot. It looks like that patch injected a bug where we can end up > waiting on an uninitialized mutex: > > [c0000000009f3c30] c00000000052c7dc .mutex_lock+0x34/0x50 > [c0000000009f3cb0] c00000000008b190 .get_online_cpus+0x3c/0x74 > [c0000000009f3d40] c000000000146cd0 .kmem_cache_create+0xcc/0x548 > [c0000000009f3e50] c000000000032ae0 .pgtable_cache_init+0x28/0x6c > [c0000000009f3ee0] c000000000780960 .start_kernel+0x1ec/0x520 > [c0000000009f3f90] c0000000000083d8 .start_here_common+0x1c/0x44 > > The mutex gets initialized in cpu_hotplug_init, which doesn't get called until > after pgtable_cache_init. Ah good, I didn't have a chance to track that one down yet. So the problem here is that we must do pgtable_cache_init there because vmalloc is initialized right after, which relies on allocating page tables and that will need kmem caches on some archs. So I suspect we need to sort out this mutex, either initializing it from elsewhere, moving cpu_hotplug_init() earlier, or avoiding it when the kernel state isn't SYSTEM_RUNNING, I haven't looked in details yet. Cheers, Ben. > -Brian > > James Bottomley wrote: > > 2.6.30-rc8 worked fine ... unless this is a known problem, I suppose I > > can begin bisecting. > > > > The boot log of the hang is: > > > > Please wait, loading kernel... > > Elf64 kernel loaded... > > Loading ramdisk... > > ramdisk loaded at 02500000, size: 8280 Kbytes > > OF stdout device is: /ht/isa@...erial@2f8 > > Preparing to boot Linux version 2.6.30 (jejb@...ymoor) (gcc version 4.3.3 (Debian 4.3.3-10) ) #1 SMP Mon Jun 22 09:59:35 CDT 2009 > > command line: root=/dev/sda3 ro console=ttyS0,19200n1 > > memory layout at init: > > alloc_bottom : 0000000002d16000 > > alloc_top : 0000000030000000 > > alloc_top_hi : 0000000080000000 > > rmo_top : 0000000030000000 > > ram_top : 0000000080000000 > > instantiating rtas at 0x000000002fff5000... done > > boot cpu hw idx 0000000000000000 > > starting cpu hw idx 0000000000000001... done > > starting cpu hw idx 0000000000000002... done > > starting cpu hw idx 0000000000000003... done > > copying OF device tree... > > Building dt strings... > > Building dt structure... > > Device tree strings 0x0000000003117000 -> 0x0000000003117640 > > Device tree struct 0x0000000003118000 -> 0x000000000311b000 > > Calling quiesce... > > returning from prom_init > > > > So it looks like some type of early boot failure or handoff in head_64 > > > > James > > > > > > _______________________________________________ > > Linuxppc-dev mailing list > > Linuxppc-dev@...ts.ozlabs.org > > https://lists.ozlabs.org/listinfo/linuxppc-dev > > -- 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/
Powered by blists - more mailing lists