Memory probing fails after 2.6.30 (bisected)
in [Kernel]
|
Prev: [PATCH] BUG: Fix smp_call_function_any to pass the node value to cpumask_of_node.
Next: [PATCH v3 05/12] Export __get_user_pages_fast.
From: Robert Hancock on 5 Jan 2010 20:00 On 01/05/2010 05:02 AM, Anders Eriksson wrote: > > Hi, > > Upgrading my laptop's kernel, I discovered that it reboots immediately after > boot on .31 and later kernels. Grub loads it, but I cannot get one line of > text out of it before it reboots, even using boot_delay. > > Bisecting I came up with the following: > > git bisect start > # good: [07a2039b8eb0af4ff464efd3dfd95de5c02648c6] Linux 2.6.30 > git bisect good 07a2039b8eb0af4ff464efd3dfd95de5c02648c6 > # bad: [74fca6a42863ffacaf7ba6f1936a9f228950f657] Linux 2.6.31 > git bisect bad 74fca6a42863ffacaf7ba6f1936a9f228950f657 > # bad: [925d74ae717c9a12d3618eb4b36b9fb632e2cef3] V4L/DVB (11736): videobuf: modify return value of VIDIOC_REQBUFS ioctl > git bisect bad 925d74ae717c9a12d3618eb4b36b9fb632e2cef3 > # bad: [e349792a385ed47390d156155b1a1e19af1bf163] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6 > git bisect bad e349792a385ed47390d156155b1a1e19af1bf163 > # bad: [c9059598ea8981d02356eead3188bf7fa4d717b8] Merge branch 'for-2.6.31' of git://git.kernel.dk/linux-2.6-block > git bisect bad c9059598ea8981d02356eead3188bf7fa4d717b8 > # bad: [59c288ffb6dfb55bdd6bfe6826ab6203ff791930] Merge branches 'frv' and 'mn10300' > git bisect bad 59c288ffb6dfb55bdd6bfe6826ab6203ff791930 > # bad: [3f6280ddf25fa656d0e17960588e52bee48a7547] Merge branch 'iommu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip > git bisect bad 3f6280ddf25fa656d0e17960588e52bee48a7547 > # good: [c44e3ed539e4fc17d6bcb5eaecb894a94de4cc5f] Merge branch 'x86-cpu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip > git bisect good c44e3ed539e4fc17d6bcb5eaecb894a94de4cc5f > # bad: [be15f9d63b97da0065187696962331de6cd9de9e] Merge branch 'x86-xen-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip > git bisect bad be15f9d63b97da0065187696962331de6cd9de9e > # bad: [9b29e8228a5c2a169436a1a90a60b1f88cb35cd1] Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip > git bisect bad 9b29e8228a5c2a169436a1a90a60b1f88cb35cd1 > # bad: [35d5a9a61490bf39d2e48d7f499c8c801a39ebe9] x86: fix system without memory on node0 ---> Got a BIOS-88 map > git bisect bad 35d5a9a61490bf39d2e48d7f499c8c801a39ebe9 > # bad: [45fbe3ee01b8e463b28c2751b5dcc0cbdc142d90] x86, e820, pci: reserve extra free space near end of RAM ---> Got a BIOS-88 map > git bisect bad 45fbe3ee01b8e463b28c2751b5dcc0cbdc142d90 > # bad: [2b72394e4089643f11669d9610907a1442fe044a] x86: move max_pfn_mapped and max_low_pfn_mapped to setup.c ---> Got a BIOS-88 map > git bisect bad 2b72394e4089643f11669d9610907a1442fe044a > # good: [6424fb38667fffbbb1b90be0ffd9a0c540db6a4b] x86: remove (null) in /sys kernel_page_tables > git bisect good 6424fb38667fffbbb1b90be0ffd9a0c540db6a4b > # bad: [89388913f2c88a2cd15d24abab571b17a2596127] x86: unify noexec handling --> Got a BIOS-88 map > git bisect bad 89388913f2c88a2cd15d24abab571b17a2596127 > # bad: [8ecee4620e76aae418bfa0e8cc830e92cb559bbb] Merge branch 'linus' into x86/mm ---> Got a BIOS-88 map > git bisect bad 8ecee4620e76aae418bfa0e8cc830e92cb559bbb > > Think you missed posting which was the actual bad commit it reported? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Anders Eriksson on 6 Jan 2010 03:40 hancockrwd(a)gmail.com said: > Think you missed posting which was the actual bad commit it reported? The last one in the list: 8ecee4620e76aae418bfa0e8cc830e92cb559bbb That's a merge commit. How do i dig futher into that? My git-fu is lacking... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Anders Eriksson on 6 Jan 2010 03:50 bdonlan(a)gmail.com said: > Looks like the boot succeeded, at least long enough to mount the root fs. > Assuming you're not using bootsplash or something, you should have seen > something. Are you sure this is the log from the failed boot? If it didn't > make it to userspace, it won't leave anything in kern.log. Yes I am. 2.6.31 --> instant reboot. Not one line of printk on the screen. 35d5a9a61490bf39d2e48d7f499c8c801a39ebe9 and 'lower' --> Get a 16 16MB env which didn't boot. I got clued up and booted with init=/bin/bash, so for the fingered commit (i.e. the one switching from all-happy e820 to bios-88), I managed to remount / rw and capture dmesg. Not sure how that interacts with earlyprintk=vga though. Did I get everyting there is to get? -A -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Robert Hancock on 6 Jan 2010 19:00 On Wed, Jan 6, 2010 at 2:32 AM, Anders Eriksson <aeriksson(a)fastmail.fm> wrote: > > hancockrwd(a)gmail.com said: >> Think you missed posting which was the actual bad commit it reported? > > The last one in the list: > 8ecee4620e76aae418bfa0e8cc830e92cb559bbb > > That's a merge commit. How do i dig futher into that? My git-fu is lacking... AFAIK, the bisect shouldn't land on a merge commit unless the changes in the commit itself are what are causing the problem, and the merge commit itself doesn't have any changes. Is it possible something went wrong in the bisect and one of your good/bad results was incorrect? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Bryan Donlan on 6 Jan 2010 23:10
On Wed, Jan 6, 2010 at 6:53 PM, Robert Hancock <hancockrwd(a)gmail.com> wrote: > On Wed, Jan 6, 2010 at 2:32 AM, Anders Eriksson <aeriksson(a)fastmail.fm> wrote: >> >> hancockrwd(a)gmail.com said: >>> Think you missed posting which was the actual bad commit it reported? >> >> The last one in the list: >> 8ecee4620e76aae418bfa0e8cc830e92cb559bbb >> >> That's a merge commit. How do i dig futher into that? My git-fu is lacking... > > AFAIK, the bisect shouldn't land on a merge commit unless the changes > in the commit itself are what are causing the problem, and the merge > commit itself doesn't have any changes. Is it possible something went > wrong in the bisect and one of your good/bad results was incorrect? It's also possible for the bisect to land on a merge if each parent of the merge works, but combining them leads to an interaction causing the bug. I'd suggest specifically retesting each of the parents of the merge, and the merge itself. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |