Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#4762 closed bug (fixed)

Hang at boot with updated ACPI module

Reported by: atomozero Owned by: nobody
Priority: normal Milestone: R1
Component: Drivers/ACPI Version: R1/alpha1
Keywords: Cc: fredrik.holmqvist@…
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by mmlr)

With this kernel config I can't boot:

acpi true
acpi_avoid_full_init true

I have tried with hrev33403 and I think the problem was introduced with the patch in hrev33236.

Attachments (5)

DSC_0672.JPG (185.4 KB ) - added by atomozero 10 years ago.
DSC_0674.JPG (389.5 KB ) - added by atomozero 10 years ago.
DSC_0676.JPG (480.1 KB ) - added by atomozero 10 years ago.
acpi_fix_global_locking.patch (7.1 KB ) - added by tqh 10 years ago.
Fixed global locking code, base on FreeBSD's
syslog (178.4 KB ) - added by tangobravo 10 years ago.
syslog after working boot with patch - thanks tqh!

Download all attachments as: .zip

Change History (26)

by atomozero, 10 years ago

Attachment: DSC_0672.JPG added

by atomozero, 10 years ago

Attachment: DSC_0674.JPG added

by atomozero, 10 years ago

Attachment: DSC_0676.JPG added

comment:1 by axeld, 10 years ago

Component: - GeneralDrivers/ACPI

comment:2 by mmlr, 10 years ago

Description: modified (diff)
Summary: don't boot :(Hang at boot with updated ACPI module

I do also experience the hang at boot on my laptop since the update of the ACPI module. It's a HP/Compaq 2510p. I can get debug output as required.

comment:3 by phoudoin, 10 years ago

What happen when you don't set acpi_avoid_full_init to true, aka when you allow full ACPI init?

Before hrev33236, ACPI was not in a better shape but was, in fact, safer because its initialisation was half done, stopping a lot of non/bad-implemented feature to crash.

comment:4 by jackburton, 10 years ago

I have the same problem on my laptop (Fujitsu-siemens Amilo li2735). With or without the acpi_avoid_full_init.

comment:5 by tqh, 10 years ago

Cc: fredrik.holmqvist@… added

Hanging that late is probably not the ACPI impl itself (it did pass ACPI init and is in ACPI mode). It's most likely one of the ACPI drivers, probably ACPI Embedded Controller. Try removing it when booting with ACPI disabled and see if it boots to desktop.

(ACPI init is done under the third icon)

by tqh, 10 years ago

Fixed global locking code, base on FreeBSD's

comment:6 by tqh, 10 years ago

I think the attached patch should fix this as I had, and was working on tracking the same issue on my laptop. For me it turned out that the global locking code was broken, and all my systems can now fully run under ACPI.

(Some additional code is in the patch, but IMO that should be updated as well.) FreeBSD impl can be viewed here: http://fxr.watson.org/fxr/source/dev/acpica/Osd/OsdSynch.c#L581

comment:7 by tqh, 10 years ago

At least one person has confirmed this patch to fix the hang for them, more feedback welcome. Also I think it should be possible to commit it (pls review first).

comment:8 by phoudoin, 10 years ago

I'll test your patch ASAP and if it does fix it, as I believe it will, I'll do the commit.

comment:9 by tangobravo, 10 years ago

The patch fixes my laptop's AHCI hang. Does a full init now, and PowerStatus works. No CPUFrequency info though. syslog attached if anyone's interested.

by tangobravo, 10 years ago

Attachment: syslog added

syslog after working boot with patch - thanks tqh!

comment:10 by tqh, 10 years ago

That syslog can't be right:

KERN: acpi: ACPI disabled

comment:11 by tqh, 10 years ago

nvm, it contained several boots.

comment:12 by tqh, 10 years ago

The check in AcpiOsWritable should probably be:

	return (info.protection & B_READ_AREA) &&
			(info.protection & B_WRITE_AREA) && 
			(pointer + length) <= (info.address + info.ram_size);

comment:13 by phoudoin, 10 years ago

Patch applied in hrev33781.

comment:14 by jackburton, 10 years ago

with hrev33781 my laptop doesn't hang at boot anymore with ACPI enabled, and it also shuts down correctly. Nice work tqh! Bug closed for me.

comment:15 by phoudoin, 10 years ago

Resolution: fixed
Status: newclosed

Indeed. And +1 for tqh thanking. BTW tqh, do you ask commit access already?

comment:16 by tqh, 10 years ago

No I havn't, but it would simplify things for me.

in reply to:  15 comment:17 by atomozero, 10 years ago

Replying to phoudoin:

Indeed. And +1 for tqh thanking.

thx tqh and thx phoudoin :)

in reply to:  16 comment:18 by phoudoin, 10 years ago

Replying to tqh:

No I havn't, but it would simplify things for me.

I've just call a vote for it on haiku-development.

in reply to:  12 comment:19 by axeld, 10 years ago

Replying to tqh:

The check in AcpiOsWritable should probably be:

	return (info.protection & B_READ_AREA) &&
			(info.protection & B_WRITE_AREA) && 
			(pointer + length) <= (info.address + info.ram_size);

Besides the coding style issues, I'm not sure if that's what you mean. B_READ_AREA means readable from userland. Likewise, B_WRITE_AREA means writable from userland as well.

comment:20 by tqh, 10 years ago

I think that is mostly for userland, it wasn't really supposed to be part of the patch. It was however better than what was in svn so to test if it fixed hang for others I let it be there. Just wanted to mention it's not correct.

comment:21 by tqh, 10 years ago

acpica can be used to build a lot of acpi tools as well. I just implemented most of the functions to make sure those weren't problems.

Note: See TracTickets for help on using tickets.