Information for Lenovo ThinkPad T510

[dgbisse]

I have a new Lenovo ThinkPad T510. ACPI seems to work in basic mode (it enables SMP, and it will power off, but suspend/resume does not work). However, it does require parameters /SMP /APIC /EIS to get it to boot, and even then, it takes about 4 minutes to get past SCREEN01.SYS.

Logs uploaded, as collected by acpi-logs-collector-20090824.zip.

[dgbisse]

You need to increase the file size limit for upload. I split the collected logs into two parts, by removing the lasl section, and uploading it separately.

[dgbisse]

I tried the contents of ACPI319CR4.ZIP.

The good news is that this machine does not hang for 4 minutes at SCREEN01.SYS when using this version.

The bad news is that it now hangs, apparently forever, later in CONFIG.SYS. It appears to be at the point after the last device driver has loaded, and before the first RUN/CALL statement is executed. 2011-02-04_19-11-24.JPG contains a photo of the hang. There are errors displayed.

[pasha]

Please download experimental ACPI build from Mensys site:

• Experimental build for you:

acpi319PollingFullOnly.zip

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

Also I recommended you change uniaud version to last

[dgbisse]

I tried acpi319PollingFullOnly.zip. It does not pause for about 4 minutes at SCREEN01.SYS, but it does fail later, with error messages. 2011-02-23_20-47-57.JPG contains a photo of the screen.

[pasha]

Check pls, \os2\boot\acpi,cfg Polling Full

[dgbisse]

Polling Part was set. I tried Polling Full, and got exactly the same error.

That did, however, suggest another thing to try. I changed the parameters to "/SMP /PIC", and now it boots with no pause, and no error, but now the temperature widget fails to get the temperature. The rest seems to be working. I will leave it that way, to see if it really is working right. Thanks...

[dgbisse]

My mistake. I forgot to change the widgets. Now temperature is correct.

[dgbisse]

I installed eCS 2.1, which installs ACPI 3.18. Of course, that has the defect that causes a 4 minute delay at SCREEN01.SYS, during boot.

I installed the contents of ACPI319POLLINGFULLONLY.ZIP, which works with eCS 2.0. I now get a trap. I very briefly see SCREEN01.SYS (alt-f2), before the trap screen displays. A photo of the trap is in 2011-05-18_21-20-54.jpg.

I then changed the eCS 2.1 kernel (14.105_SMP) to the one from eCS 2.0 (14.104a_SMP), and it now works.

[pasha]

Sorry, 14.105_SMP is't support by acpi.psd now

[jojo]

This is untrue, we ship a patched ACPI.PSD 3.18 in eCS 2.1 that does support kernel 14.105_SMP. -> Updated ACPI 3.18 package to support kernel 14.105 (07/28/2010 19:18:42 sla)

[pasha]

Please download experimental ACPI build from Mensys site:

• Experimental build for you:

acpi319for105-2011-05-30.zip

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

[dgbisse]

Okay, for acpi319for105-2011-05-30.zip:

Using "PSD=ACPI.PSD /SMP /PIC /VBE", and the 105 kernel, it seems to work.

If I try "PSD=ACPI.PSD /SMP /APIC /VBE" it pauses for a few minutes during boot (2011-05-31_13-01-57.JPG - sorry about the quality), then takes a trap in JFS (2011-05-31_13-02-46.JPG).

[pasha]

Please download experimental ACPI build from Mensys site:

• Experimental build for you:

acpi319APICFix-20110605.zip

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

[dgbisse]

acpi319APICFix-20110605.zip

Works with PSD=ACPI.PSD /SMP /PIC /VBE.

With PSD=ACPI.PSD /SMP /APIC /VBE it stops at <see 105.jpg> waits for about 2 minutes, then traps <see 105Trap.jpg>,

[pasha]

Can you attach log from PSD=ACPI.PSD /SMP /PIC /VBE?

[dgbisse]

acpidaemon.log attached.

[dgbisse]

I wish to report that the contents of ACPI3_19_14.exe is working on this machine, but suspend/resume doesn't want to resume properly. It looks like it may be alive, but the screen backlight has not turned on.

ROAMIN3-20120101-acpi-3.19.14.zip will be uploaded shortly.

[dgbisse]

I also need to report that I still can't get the RealTek 10EC:8172 wireless to configure. It uses an unsupported driver, but the problem seems to be that GENMAC never sees that it has an IRQ, even though the PCI program says it is on IRQ17.

[David Azarewicz]

It seems to me that if PCI says it is properly setup, then the PSD has done its job correctly. Perhaps the genmac driver cannot handle the IRQ17, I don't know. It is also possible it is not an interrupt problem, but something else.

There have been many improvements since 3.19.14. I suggest you try the current version 3.20.01 and see if that fixes your problem. If not, a new log would be helpful.

[dgbisse]

I am using 3.20.01, and just tried again. GENMAC is definitely able to use high IRQs, when it works properly. After booting, I look at the results of doing:

COPY WRND32$ CON

and I see the information:

InterruptLevel 0

When it works properly, this shows the IRQ that GENMAC "sees". In this case, it "sees" IRQ 0, and any attempt to actually use the device causes a hard system hang, so I have reason to believe that it really is attempting to use IRQ 0. Everything else says that it has IRQ 17.

This could be a GENMAC problem, but there is no way to get GENMAC fixed. Since ACPI actually assigns the IRQs, I am hoping that ACPI can fix the problem. Otherwise, I will need to wait for the Multimac project to produce results.

Now, I need to figure out how to produce a new log, then upload it.

Thanks...

[David Azarewicz]

It would be good to know how GenMac determines which interrupt to use and why it chooses interrupt 0. I see 2 possibilities:

1. GenMac does not use the normal way to determine which interrupt to use, or
2. There is a different problem that causes GenMac to abort before it determines which interrupt to use and zero is just the initialized value that hasn't been set yet.

#2 is the most likely. Interrupt 0 is a legal interrupt, but it is already claimed exclusively and requesting it will return an error. Doing so will not hang the system, unless the caller doesn't check status and just assumes the request succeeded. More likely there is something else wrong.

Does the GenMac driver work correctly without the PSD loaded?

Does the GenMac driver work correctly with the PSD loaded and using the /VW switch?

[dgbisse]

"It would be good to know how GenMac? determines which interrupt to use and why it chooses interrupt 0."

Genmac does some strange things sometimes. Unfortunately, Willibald Meyer has refused to do anything more with his software, including release it. I would not be surprised if #1 is the proper answer. However, I also have an IBM ThinkPad T43, which has both wired, and wireless, running with Genmac, and using high IRQs, so it isn't that simple.

"Does the GenMac? driver work correctly without the PSD loaded?"

No. No change, other than PCI says it is assigned IRQ11 rather than IRQ17,

"Does the GenMac? driver work correctly with the PSD loaded and using the /VW switch?"

No. No change. Other than PCI says it is assigned IRQ11 rather than IRQ17.

In both cases, the Genmac driver reports that it is assigned IRQ0.

[David Azarewicz]

I'm sorry, but all of the evidence shows that the PSD is working correctly, and that the problem appears to be with GenMac or the hardware.

I took a second look at your log and verified that the PCI device is configured correctly and enabled, and the bridge that connects to it is also configured correctly. I don't see what I could do in the PSD to help since it is hard to fix something that is working correctly.

[dgbisse]

I am pretty sure that GENMAC is where the problem lies. You can close this, if you like, but if you stumble across something that might cause (or fix) the problem, please keep it in mind. I am pretty sure that I had the same problem with an Acer 4720 a couple of years ago (I no longer have that machine), and a couple of others have reported similar problems with GENMAC. Hopefully, Multimac will work properly, when it is developed.

Thanks...

[David Azarewicz]

Ok, I'll keep my eyes open.