Bug 10140 - Kernel blocked after "ACPI: bus type pci registered"
Summary: Kernel blocked after "ACPI: bus type pci registered"
Alias: None
Product: Platform Specific/Hardware
Classification: Unclassified
Component: x86-64 (show other bugs)
Hardware: All Linux
: P1 high
Assignee: Thomas Gleixner
Depends on:
Blocks: 9832
  Show dependency tree
Reported: 2008-03-01 08:13 UTC by François Valenduc
Modified: 2008-03-05 15:38 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.25-rc3-git3
Regression: Yes
Bisected commit-id:

Output of dmesg (with kernel 2.6.25-rc3) (30.25 KB, text/plain)
2008-03-01 08:19 UTC, François Valenduc
Patch for testing (780 bytes, patch)
2008-03-02 11:02 UTC, Thomas Gleixner
Details | Diff
Patch fixing the problem for me. (552 bytes, patch)
2008-03-02 13:30 UTC, Rafael J. Wysocki
Details | Diff

Description François Valenduc 2008-03-01 08:13:46 UTC
Latest working kernel version: 2.6.25-rc3
Earliest failing kernel version:2.6.25-rc3-git3
Distribution: Gentoo
Hardware Environment: Packard Bell EasyNote, Intel Core 2 Duo
Software Environment: Gentoo
Problem Description: 

Steps to reproduce: Simply try to boot the computer !

With the current version of 2.6.25-git, the kernel stop after "ACPI: bus type pci registered". After having tried git-bisect once again, it seems that the following commit is problematic:

8be8f54bae3453588011cad06363813a5293af53 is first bad commit
commit 8be8f54bae3453588011cad06363813a5293af53
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sat Feb 23 20:43:21 2008 +0100

    x86: CPA: avoid split of alias mappings

If I revert it, things work a little better but the kernel once again stop when it try to scan the partition table.
Comment 1 François Valenduc 2008-03-01 08:19:00 UTC
Created attachment 15104 [details]
Output of dmesg (with kernel 2.6.25-rc3)
Comment 2 Thomas Gleixner 2008-03-02 11:02:18 UTC
Created attachment 15109 [details]
Patch for testing

Can you please apply the attached patch on top of git latest ?
Comment 3 Rafael J. Wysocki 2008-03-02 11:29:09 UTC
With the patch from Comment #2 applied I get:

  CC      arch/x86/kernel/traps_64.o
/home/rafael/src/linux-2.6/arch/x86/mm/pageattr.c: In function ‘cpa_process_alias’:
/home/rafael/src/linux-2.6/arch/x86/mm/pageattr.c:626: error: ‘struct cpa_data’ has no member named ‘tlb_flush’
/home/rafael/src/linux-2.6/arch/x86/mm/pageattr.c:627: error: ‘struct cpa_data’ has no member named ‘tlb_flush’
/home/rafael/src/linux-2.6/arch/x86/mm/pageattr.c:655: error: ‘struct cpa_data’ has no member named ‘tlb_flush’
/home/rafael/src/linux-2.6/arch/x86/mm/pageattr.c:656: error: ‘struct cpa_data’ has no member named ‘tlb_flush’
make[2]: *** [arch/x86/mm/pageattr.o] Error 1
Comment 4 Rafael J. Wysocki 2008-03-02 11:30:44 UTC
The commit mentioned above also breaks my HP nx6325.  The box crashes early in the boot process, 100% of the time.
Comment 5 Rafael J. Wysocki 2008-03-02 11:32:25 UTC
This entry is being used for tracking a regression from 2.6.24.  Please don't
close it until the problem is fixed in the mainline.

Handled-By : Thomas Gleixner <tglx@linutronix.de>
Comment 6 Rafael J. Wysocki 2008-03-02 11:38:34 UTC
References : http://lkml.org/lkml/2008/2/28/153
Comment 7 Rafael J. Wysocki 2008-03-02 13:30:11 UTC
Created attachment 15110 [details]
Patch fixing the problem for me.

The attached patch fixes the issue for me.  Can you test it, please?
Comment 8 Thomas Gleixner 2008-03-02 16:28:50 UTC
Doh, ignore the patch. We revert the commit for now and try to figure out why your boot gets stuck later.
Comment 9 François Valenduc 2008-03-03 00:57:36 UTC
The patched proposed by Rafaël indeed avoid blocking the kernel. In fact, the kernel is blocked right when the framebuffer (uvesafb in my case) would be initialized.
I will retry with the commit reverted and see what happens. I don't understand why it can't boot in that case, since during the different stages of the bisection, the kernel always booted when git-bisect stopped at a point where this commit was not applied. Maybe I made a mistake with the initramfs image needed to boot from a LVM2 root partition. 
Comment 10 François Valenduc 2008-03-03 10:00:48 UTC
Reverting the commit or applying the patch proposed by Rafael solves the problem. With the commit applied and uvesafb disabled, the problem also occurs. So, the initialization of the framebuffer is not the cause of the problem.

Note You need to log in before you can comment on or make changes to this bug.