Most recent kernel where this bug did not occur: none Distribution: Debian Sarge Hardware Environment: Alienware Aurora notebook m7700 RAID-0 VIA with two drives Software Environment: Bare minimum Sarge distribution Problem Description: I have recently bought an Alienware Aurora m7700 notebook, which comes with an AMD Athlon 64 X2 4400+ dual core processor (wow, that's a mouth full). Since it came set up with a RAID-0 VIA adapter I need dmraid in order to recognize my drives, which means that I cannot boot directly into Linux. Thus, I am forced to use Loadlin and a vmlinuz/initrd combination which initializes dmraid and boots up the rest of the system. I am only mentioning all this in case the fact that I am booting from Loadlin has anything to do with my problem. My problem is that, with an SMP kernel, I am unable to get both processors recognized. I currently suspect that the reason for this is that the system freezes very early on in the boot cycle if ACPI is turned on. When I specify "acpi=off" the system boots successfully but it fails to detect the motherboard as multi-processor and only initializes the first processor. When I boot from a Knoppix 4.0.2 cd, ACPI is turned on successfully and IO-APIC/Local APIC is turned on so that both of my processors get recognized. In fact, if I try to boot Knoppix with "acpi=off" it freezes immediately on startup. This puzzles me somewhat since I have tried using the very same kernel from the Knoppix cd to boot from my harddisk and got the same problem there. The reason I am asking for help on this list is that I am now labouring under the assumption that the problem with recognizing my processors is due to the fact that ACPI cannot be turned on (at least, not when booting from my hard drive), which I think must be because my BIOS has a faulty ACPI namespace. I read up on http://acpi.sourceforge.net/dsdt and obtained the DSDT for my system, which turns out to have quite a lot of compilation errors. Some of these I could correct but almost two dozen remain, and I was wondering if someone on this list could nudge me along in the right direction[1]. If there is any other information I could give that might help with this, please let me know. I am really eager to get this 100% working under Linux... Thanks in advance, - robin [1] Of course, if trying to make the DSDT compile correctly is just a red herring, I would still appreciate any suggestions as to what the real root cause is :-)
Created attachment 7592 [details] The changes I was able to make to the DSDT so far
Created attachment 7593 [details] The DSDT file I am trying to get compiled
Created attachment 7594 [details] My Linux .config file
Created attachment 7595 [details] The output of /proc/cpuinfo when booted using Knoppix
Created attachment 7596 [details] The output of 'dmesg' when run under Knoppix
Created attachment 7597 [details] The output of 'dmesg' when I have to boot with acpi=off
Created attachment 7598 [details] The output of 'dmidecode'
Created attachment 7599 [details] The output of 'dmidecode' under Knoppix
Created attachment 7600 [details] The output of 'lspci -v -v'
Created attachment 7601 [details] The iasl compiler errors when trying to compile AuroraAMD64.dsl
>My problem is that, with an SMP kernel, I am unable to get both >processors recognized. Could you please try latest baseline kernel, and latest BIOS? >I read up on http://acpi.sourceforge.net/dsdt and obtained the DSDT for my >system, which turns out to have quite a lot of compilation errors This is NOT a right approach for fix your problem. Although, it can help debugging the issue. Please attach acpidump output.
Created attachment 7620 [details] The output of acpidump Created when booted from the Knoppix cd, since that is the only way to get ACPI working right now.
I've attached the acpidump output. With latest baseline kernel do you mean the Linus tree, the -mm tree or perhaps another tree? Thanks, - robin
Re: which tree linus tree
I tried out the 2.6.16 kernel and got the same problem with that one. The bootup sequence basically locks up after the following message: ACPI namespace successfully loaded at root b042d698 Unfortunately I cannot see what happens earlier in the boot sequence since all but the last 40 lines or so are scrolled off the screen and I can't write to disk yet at that point since my harddisk controller cannot be recognized until after I run the dmraid tool...
Can you enable acpi debug option in your config, so we could get more infos. Better if you could write down several lines of output just before boot hang. >ACPI namespace successfully loaded at root b042d698 This looks strange. is the PAGE_OFFSET 0xc0000000? Another suspection is the acpi earily initialization (init before other CPUs boot breaks this system)
This is what I could write down from the frozen boot screen. I ran it once with just ACPI_DEBUG on and a second time with ACPI_DEBUG and also boot paramers "acpi_dbg_layer=255" and "acpi_dbg_level=255". This is what I could write down before it went off the screen: [...] Enabling unmasked SIMD FPU exception support: done [...] tbxface-0109 [02] load_tables : ACPI Tables successfully acquired [...] Parsing all Control Methods:.............................................. .......................................................................... [...] Table [DSDT](id 0006) - 542 Objects with 61 Devices 164 Methods 17 Regions [...] Parsing all Control Methods: Table [SSDT](id 0004) - 6 Objects with 0 Devices 0 Methods 0 Regions [...] nsload-0146 [05] ns_load_table: *** Completed Table Method Parsing and Object Initialization *** nsload-0208 [04] ns_load_table_by_type : Namespace load: 0 SSDT or PSDTs ACPI namespace successfully loaded at c044433c How can I find out what the PAGE_OFFSET is? If ACPI tries to initialize too early before all CPUs are online, do you have a suggestion on how I could force it to delay a while? Thanks for your help, - Robin
please boot the latest kernel with acpi enabled, but with maxcpus=1 and attach the output from dmesg -s64000
This is a bit of a setback, but booting with "maxcpus=1" or even "maxcpus=0 nosmp" and ACPI turned on, still causes Linux to freeze up right after it reports that the ACPI namespace has been loaded successfully.
Would the fact that I am forced to boot into Linux using LoadLin have anything to do with this? Could it be that DOS leaves the ACPI information in an inconsistent state, or something to that effect? Obviously I don't know enough about ACPI to figure that out, so my apologies if the question is a naive one... - Robin
I have turned off the RAID on my laptop, restoring my drives to a normal disk setup. This allows me to boot into Linux straightaway, using Grub and doing away with the DOS/Loadlin solution altogether. Using the very same kernel as before, I can now successfully boot up with ACPI turned on and have both processors recognized. This issue could probably be closed now, unless someone wants to investigate it further.
hmmm, something funky about that raid setup. glad the normal config is working