Mdk 10.1 Community freezes on boot

I've got a Compaq Presario 732EA laptop, and I recently installed Mandrake 10.1 Community on it, with no luck in getting it running. I've tried passing nolapic and noapic as kernel parameters (since I've read that the 732 has a particularly debile APIC implementation), but interestingly enough the kernel tells me "Local APIC disabled by BIOS -- reenabling. Found and enabled local APIC" despite my telling it not to enable APIC. Joy..

Basically the crash occurs each time when the text "Calibrating delay loop..." shows up, and no amount of combining noapic, nolapic, acpi=off and so on has helped. Anyone have any suggestions?

And please, don't tell me to recompile the kernel. Out of the 2 computers I have, the laptop is without an OS due to obvious reasons and the other one isn't an Intel machine and I'm not keen on doing a cross compile/cd-burning fiesta

Any help would be greatly appreciated.

Unfortunately you are not the only one reporting this problem.

Others also noted that the 10.1 kernel seems to act as if the parameter is never passed, in other words it disreqards the command line entry.

So if you system is aflicted by APIC or ACPI problems you end up with a freeze.

Out of curiosity, does the system come up in SAFE mode?

No, neither the no-framebuffer or safe modes work.

I have exactly the same situation only on a Compaq Pressario 2100 and with Mandrake 10.1 Official Powerpack. I've also tried the apic, nolapic, etc. When I boot into failsafe or frame buffer, I experience exactly the same symptoms--the boot stalls at the message "Calibrating delay loop."

Additionally, I also received the "APIC disabled by bios...reenabled" sequence.

There is nothing useful on the MandrakeClub website.

However, one poster went back to Mandrake 10.0, downloaded and compiled kernel 2.6.9 and then "upgraded" to Mandrake 10.1. I personally gave up trying to compile and run kernel 2.6.8 on the laptop.

Sorry, I started complaining. I would appreciate any thoughts and ideas.

Dan

That looks like a solution then, to create a set of 2.6.9 rpm's from the src.rpm file.

These would need to be compiled and posted somewhere.

Seems more or less hopeless. Guess I just ought to change distros, or is there any way of doing some kind of magic using only the boot cd I have? (Did a network install off my mac since I ran out of CD-Rs and my precious and only CD-RW disk went to data heaven)

It's not a distro problem.

It's a kernel version problem.

You need to be aware of this and avoid those kernels which may be problematic on your system.

I have a similiarly aflicted laptop too, where-in I cannot use a couple of particular kernels.

Another laptop works perfectly with all the newer ones.

Hmh, that makes sense. Anybody know which kernels are a no-no with my APIC-ally challenged laptop?

As you have seen 2.6.9, 2.6.4 and the 2.4.x tree do not seem to be similiarly aflicted.

However 2.4.x has other problems with newer machines...

my fading brain cells recall that someone on install disabled all power stuff in BIOS like apm and acpi then installed a fresh Mdk then on reboot enabled apci in BIOS.....something to do with the mdk kernel.....ignore if you use a vanilla....and assumes you have no laptop

do a search and see if I speak with fork tongue

Kemosabe, speak with forked tongue...

Wow that dates me...

It's applicable during installation, but doesn't fix the ACPI problems with the 10.1 release.

It's almost as if the kernel is disregarding the APIC and ACPI parameters as many have reported.

Even with noapic they all see "APIC ENABLED" duing boot.

Originally posted by opjose It's almost as if the kernel is disregarding the APIC and ACPI parameters as many have reported. Even with noapic they all see "APIC ENABLED" duing boot. [/B]

I have the same problem on my IBM Thinkpad T41, which I just upgraded from Mandrake 10.0 to 10.1 Official. Fortunately, the machine will still boot with one of the kernels left over from my 10.0 install, so I can easily patch and compile new kernels on it.

The correct command line option is "nolapic", but as others noted above, it doesn't work on the 2.6.8.1-12mdk kernel. I think this is the same bug as in the link below, but the patch given there doesn't compile when applied to the 2.6.8.1-12mdk kernel. A variant using early_param instead of __early_param compiles, but it isn't done compiling everything else and trying to link yet. I'll see if it works when it's done.

http://www.gossamer-threads.com/list...light=1#430572

Doing some more googling, I also notice that in 2.6.9, there's a change that no longer tries to enable the local APIC if the BIOS disabled it, unless "lapic" is given explicitly to force it. This change also ought to fix the problem for me and most others. (However, I wonder if the kernel needs the early_param change as well, in order to get the nolapic/lapic options working for anyone who may still want them.)

The correct command line option is "nolapic".

... both nolapic and noapic are both applicable.

noapic is a superset of the nolapic command, as noacpi is a superset of acpi=ht

In both cases the former disables even more than the latter, so to speak.

[Well, this is a quibble, but I'm not sure that's correct. Tracing through the code, it looks like the code that's causing the problem here is controlled only by nolapic, not noapic. The nolapic option disables local apic use, while noapic disables ioapic use. It's possible for a uniprocessor system to not have an ioapic, but (at least on Pentium and newer) it always has a local apic, because that's onboard the CPU chip.]

More useful information: I was able to get the kernel to work on my laptop by applying a version of the patch for kernel bug 3238 (http://bugzilla.kernel.org/show_bug.cgi?id=3238). The patch is http://bugzilla.kernel.org/attachmen...97&action=view

Actually that's excellent!

I've seen many a kernel post to the effect that the noapic option should indeed shut off the local apic as well.

What you are saying refutes this, not that you are wrong, but rather that's an interesting piece of data, given the prevalence of problems revolving around apic support.

Also you've pretty much confirmed that the kernel is disregarding the nolapic parameter at boot, as all that patch does is to FORCE apic off totally.

Note that the patch does not seem to disable LOCAL apic, but rather it specifies no_apic ...

+ if (enable_local_apic != 1)
+ goto no_apic;


If Local APIC is not enabled on the command line explicitly, disable APIC altogether...

Sheez this fix is so simple! I wish Mandrake would include it in their release.

You may want to post it on their bugtracker as well as this seems to be a rather large problem which needs to be addressed.