Opened 13 years ago

Closed 12 years ago

#495 closed defect (unknown)

Information for Lenovo ThinkPad T510

Reported by: dgbisse Owned by: David Azarewicz
Priority: major Milestone: Feedback pending
Component: ACPI PSD Version: 3.19.14
Keywords: Cc:

Description

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.

Attachments (12)

ACPI-LOG-MODEL-OF-YOUR-PC.zip (147.6 KB) - added by dgbisse 13 years ago.
iasl.zip (121.4 KB) - added by dgbisse 13 years ago.
2011-02-04_19-11-24.JPG (93.3 KB) - added by dgbisse 13 years ago.
2011-02-23_20-47-57.JPG (104.1 KB) - added by dgbisse 13 years ago.
2011-05-18_21-20-54.jpg (39.0 KB) - added by dgbisse 13 years ago.
2011-05-31_13-02-46.JPG (246.9 KB) - added by dgbisse 13 years ago.
2011-05-31_13-01-57.JPG (33.0 KB) - added by dgbisse 13 years ago.
105.jpg (9.6 KB) - added by dgbisse 13 years ago.
105Trap.jpg (84.9 KB) - added by dgbisse 13 years ago.
acpidaemon.log (2.1 KB) - added by dgbisse 13 years ago.
ROAMIN3-20120101-acpi-3.19.14.zip (82.1 KB) - added by dgbisse 12 years ago.
ROAMIN3-20120417-acpi-3.20.01.zip (181.1 KB) - added by dgbisse 12 years ago.

Download all attachments as: .zip

Change History (38)

comment:1 Changed 13 years ago by 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.

Changed 13 years ago by dgbisse

Changed 13 years ago by dgbisse

Attachment: iasl.zip added

comment:2 Changed 13 years ago by 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.

Changed 13 years ago by dgbisse

Attachment: 2011-02-04_19-11-24.JPG added

comment:3 Changed 13 years ago by pasha

Owner: changed from eco to pasha

Please download experimental ACPI build from Mensys site:

  • Experimental build for you:

acpi319PollingFullOnly.zip

Also I recommended you change uniaud version to last

comment:4 Changed 13 years ago by 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.

Changed 13 years ago by dgbisse

Attachment: 2011-02-23_20-47-57.JPG added

comment:5 Changed 13 years ago by pasha

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

comment:6 Changed 13 years ago by 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...

comment:7 Changed 13 years ago by dgbisse

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

comment:8 Changed 13 years ago by pasha

Owner: changed from pasha to eco

comment:9 Changed 13 years ago by 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.

Changed 13 years ago by dgbisse

Attachment: 2011-05-18_21-20-54.jpg added

comment:10 Changed 13 years ago by pasha

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

comment:11 Changed 13 years ago by 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)

comment:12 Changed 13 years ago by pasha

Please download experimental ACPI build from Mensys site:

  • Experimental build for you:

acpi319for105-2011-05-30.zip

comment:13 Changed 13 years ago by 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).

Changed 13 years ago by dgbisse

Attachment: 2011-05-31_13-02-46.JPG added

Changed 13 years ago by dgbisse

Attachment: 2011-05-31_13-01-57.JPG added

comment:14 Changed 13 years ago by pasha

Please download experimental ACPI build from Mensys site:

  • Experimental build for you:

acpi319APICFix-20110605.zip

comment:15 Changed 13 years ago by 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>,

Changed 13 years ago by dgbisse

Attachment: 105.jpg added

Changed 13 years ago by dgbisse

Attachment: 105Trap.jpg added

comment:16 Changed 13 years ago by pasha

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

Changed 13 years ago by dgbisse

Attachment: acpidaemon.log added

comment:17 Changed 13 years ago by dgbisse

acpidaemon.log attached.

comment:18 Changed 12 years ago by 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.

Changed 12 years ago by dgbisse

comment:19 Changed 12 years ago by 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.

comment:20 Changed 12 years ago by David Azarewicz

Milestone: Release version 3.19Feedback pending
Owner: changed from eco to David Azarewicz
Status: newassigned
Version: 3.183.19.14

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.

comment:21 Changed 12 years ago by 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...

Changed 12 years ago by dgbisse

comment:22 Changed 12 years ago by 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?

comment:23 Changed 12 years ago by 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.

comment:24 in reply to:  23 Changed 12 years ago by 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.

comment:25 Changed 12 years ago by 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...

comment:26 Changed 12 years ago by David Azarewicz

Resolution: unknown
Status: assignedclosed

Ok, I'll keep my eyes open.

Note: See TracTickets for help on using tickets.