In my wifes' machine 2.4.1 (both vanilla and -ac2) enabling ACPI causes
the machine to run so slowly it's unusable. On my machine it's OK.
2.4.0 worked fine, so something has changed between 2.4.0 and 2.4.1 that
broke it. I couldn't find anything in dmesg that looked any different,
though. However since that machine has never successfully booted with
ACPI on the kern.log hasn't been written so it's unlikely I'd find anything.
Tony
I waited out the boot so I could login and experiment, but it was
painfully slow.
Compiling with just APM in and no ACPI, results in a correctly-running
machine with rh7 gcc-2.96-69.
I got lucky this time that with APM worked, else I'd be stuck with slowly
fscking, since this last boot I had to fsck two of my partitions (maximum
mount count exceeded...) I don't even want to know how long it'd take to
fsck my almost 60GB worth of disks on this machine... If that were the
case, I guess I'd be better off fscking with 2.4.0 and then coming back
in... ouch.
-bc
On Sun, 4 Feb 2001, Tony Hoyle wrote:
> Date: Sun, 04 Feb 2001 15:26:04 +0000
> From: Tony Hoyle <[email protected]>
> To: [email protected]
> Subject: ACPI broken in 2.4.1
>
> In my wifes' machine 2.4.1 (both vanilla and -ac2) enabling ACPI causes
> the machine to run so slowly it's unusable. On my machine it's OK.
> 2.4.0 worked fine, so something has changed between 2.4.0 and 2.4.1 that
> broke it. I couldn't find anything in dmesg that looked any different,
> though. However since that machine has never successfully booted with
> ACPI on the kern.log hasn't been written so it's unlikely I'd find anything.
>
> Tony
> I waited out the boot so I could login and experiment, but it was
> painfully slow.
>
> Compiling with just APM in and no ACPI, results in a correctly-running
> machine with rh7 gcc-2.96-69.
Lots of people are seeing this. Stick to APM for now until the acpi folks fix
it.