ACPI should notify user if critical troubles

[eco]

If ACPI initialization failed then ACPI.PSD or APM.ADD or.. ACPIHLP.SYS (ACPI helper) should write a message: "ACPI initialization failed". This will economize time for user. He is spending one week to experiments. It's better notify him immediately.

If there are errors on ACPI tables interpretation then it's necessary notify the user.

Is it easy to implement? When Intel ACPI CA code is updated, we can insert this analysis blocks of code again.

[eco]

e-co:

• Again and again.. 10 users.. 20 users.. 1 year.. 2 years.. 3 years.. every month we see that users make the same mistake - they write /ACPI switch instead of /APIC

What to do? Please detect this wrong switch and write message for user on boot: "CRITICAL ERROR: Use /APIC switch instead of /ACPI"

[Steven Levine]

It is good programming practice to help users avoid shooting themselves in the foot. This means all switches should be fully validated and any errors should be reported. IMO, it's a lot more efficient for the user to reboot once after correcting a reported spelling error than to reboot many time troubleshooting something the software chose to ignore.

Ignoring unknown switches or treating /ACPI the same a /APIC is not good practice.

[eco]

e-co:

more comments to "ACPI initialization failed".

1) Current situation: Booting with ACPI.. black box.. success OR hang/trap. OK.. booted to Desktop. Zero information again.

Goal: it's necessary inform the user that his computer is not compatible with Intel ACPI-CA in advance. To economize his time, to economize the time of Support service.

Notes 1: it's impossible insert "sensors" into Intel code, so.. let's analyze the log output.

Notes 2: acpiexec utility allows check the compatibility of PC with Intel ACPI-CA. IMHO, it's necessary check this in real-time, in real conditions.

2) wrong options - Pasha agrees

[eco]

e-co:

"-" it's expensive: it's necessary make a pause => timers?

"+" as i remember, /ACPI is a blocking problem, user fails to boot to desktop.

[eco]

ACPI should make beeps when suspend is finished, beeps when resume starts,

else it's difficult to understand what happens

acpdaemon cfg should contain variable to disable this beeps

[eco]

RUS:

если уснуло на 99%, то три коротких бипа ба-ба-ба-тук-тук или типа того.

если начинаешь просыпаться, то тук-тук-ба-ба-ба

возможность отключить бипы, если юзер уже все настроил.

[eco]

e-co:

One more suggestion:

If many devices occupy IRQ11 then ACPI should write on boot:

"Warning: Too many devices on IRQxx"

Else users never discover that the notebook have troubles.

[pasha]

about what ticket?

[ecsnl]

In my opinion a ticket number is not important. I modified this from a defect to an enhancement. What Eugene is referring to is that there are many cases that user does not even understand its ACPI failing. thats what he is pointing to. And he is asking if we can improve the information gathering so the time of the customer and us is spend better.

[Steven Levine]

Replying to ecsnl:

In my opinion a ticket number is not important.

What do you mean? TRAC requires ticket numbers.

I modified this from a defect to an enhancement.

I moved this to the 2.x milestone. Eugene is correct that the goal should always be to provide messages the user can understand, but a full review of the existing messages can wait.

[pasha]

Please download experimental ACPI build from Mensys site:

• Experimental build for you:

ACPI-APIC-BAT.ZIP

• Read instructions: ​http://ecomstation.ru/projects/acpitools/?action=testcase