Opened 15 years ago
Closed 12 years ago
#433 closed defect (fixed)
Thinkpad T42 S3 resume fails with UHCI driver hang
Reported by: | Steven Levine | Owned by: | David Azarewicz |
---|---|---|---|
Priority: | major | Milestone: | Feedback pending |
Component: | ACPI PSD | Version: | 3.16 |
Keywords: | Suspend Resume | Cc: | rwklein@… |
Description
Roderick's T42 Running PSD_install options:" /vbe /o1" --:--:--.-- @#netlabs dot org:3.16#@##1## 23 Jul 2009 12:30:42 pasha::::0::@@ ACPI core PSD Driver. (c) netlabs.org 2005-2009 Build date: Jul 23 2009 12:30:46
With ACPI, UHCI registers (i.e. 0x1840) read as all ones during resume processing. The result is that usduchd gets very confused and hangs waiting for IO to complete.
Either the port addresses have changed or the UHCI chipset power is still off.
With APM, resume works as expected and the UHCI register addresses appear unchanged.
Attachments (3)
Change History (17)
by , 15 years ago
Attachment: | t42_pci-d_beforesuspend.txt added |
---|
by , 15 years ago
Attachment: | t42_pci-d_aftersuspend.txt added |
---|
pci.exe output after resume - shows unconfigured uchi and ethernet registers
comment:1 by , 15 years ago
t42_pci-d_aftersuspend.txt shows the effect of the suspend/resume on the UHCI, EHCI and gigabit Ethernet controllers. The memory and/or IO address are unconfigured after the resume.
by , 15 years ago
Attachment: | acpi-log-Model-of-your-PC.ziq added |
---|
comment:2 by , 15 years ago
As requested on the acpi-dev mailing list, uploaded data of the ACPI log tools are in acpi-log-Model-of-your-PC.ziq. (change extension to ZIP).
The output of iasl is included.
comment:3 by , 15 years ago
This email was in relationship to testing ACPI APM with USB drivers. On the 11th of August Pavel wrote:
Hi
As you know, all thinkpad has very bad IRQ rounting at boot. So I recommended use:
LINK LNKA 10 LINK LNKH 6
For Uni CPU notebooks.
Your, Pavel
I tested this with ACPI 3.17 on the T42. With USB drivers installed system hangs at resume. REM USB drivers out it wakes up.
comment:4 by , 13 years ago
Keywords: | Suspend Resume added |
---|
comment:5 by , 12 years ago
I am not sure in how far ACPI.PSD can generically handle this.
For EHCI for example, in chapter 2.1, Table 2-2 the EHCI spec states that PCI config regs 00h-08h (that is: including the command register) are powered by the core power well whereas a few others are powered by the auxiliary power well.
At the beginning of chapter 2. the spec continues to say that PCI config regs powered through the core power well are initialized to default values on a "transition from the PCI Power Management D3hot state to the D0 state" (in short: on resume).
From what I can tell from various chipset specs, the vendor and device id (00h,01h,02h,03h) are always set to constant values when they are reset but for the command register this is not true (as the logs also indicate).
I am beginning to wonder how ACPI.PSD can solve this problem as I don't know if the aforementioned is exactly the same for each and every device. I think it is device specific and therefore needs to be properly handled by the device driver controlling that device.
Even if ACPI.PSD would save the entire PCI config space for each and every device, there are ADDITIONAL memory mapped registers for that device that undergo the same problem: if they are powered through the core power well, their content will be lost. If they are powered through an auxiliary power well, their content will be preserved. Again, see EHCI spec chapter 2.
The only alternative would be to disable power management for devices with device drivers that don't provide the necessary preserving of registers.
comment:6 by , 12 years ago
Lars,
There's nothing for you to do on this until I test with current ACPI and USB drivers. The ticket is rather antique and clearly written against long retired driver versions, so I'm a bit confused as to why you commented on it. The last time this ticket was worked on was 3 years ago if you ignore David's keyword updates which were done 3 months ago.
I will post a comment once I've had time to retest with current drivers.
comment:7 by , 12 years ago
Milestone: | Release version 3.19 |
---|
Please try the current version and let me know how it goes.
comment:8 by , 12 years ago
Milestone: | → Feedback pending |
---|
follow-up: 11 comment:9 by , 12 years ago
Tried this on my single core machine (with SMP 10.104a debug kernel).
I tried with ACPI.PSD 3.21.2
1) I tried two times: without any switches and then with /EIS /VBE switch
2) in both cases, I removed ALL USB HC drivers (USBUHCD.SYS,USBOHCD.SYS,USBEHCD.SYS) from config.sys
In both cases, the system will go into suspend but it will never resume when I attempt to . It will hang with a black text mode screen with the cursor blinking in the upper left corner. From the past I also remember that my NIC ceases to work on a resume (it's a SIS900 with an old MAC driver from Willibald Meyer and most likely has no power management support but works perfectly well otherwise). Therefore an established ICAT session via UDP will also break (I have been testing on my MUT machine).
comment:10 by , 12 years ago
Version: | 3.16 → 3.21.02 |
---|
comment:11 by , 12 years ago
Owner: | changed from | to
---|
Replying to erdmann:
Tried this on my single core machine (with SMP 10.104a debug kernel).
I assume that since you are commenting on this ticket that you are either the reporter and/or you are testing on the a T42, and/or you are working on the problem described in this ticket. :-)
I tried with ACPI.PSD 3.21.2
1) I tried two times: without any switches and then with /EIS /VBE switch
Why the /EIS switch? It is not necessary.
2) in both cases, I removed ALL USB HC drivers (USBUHCD.SYS,USBOHCD.SYS,USBEHCD.SYS) from config.sys
In both cases, the system will go into suspend but it will never resume when I attempt to . It will hang with a black text mode screen with the cursor blinking in the upper left corner. From the past I also remember that my NIC ceases to work on a resume (it's a SIS900 with an old MAC driver from Willibald Meyer and most likely has no power management support but works perfectly well otherwise). Therefore an established ICAT session via UDP will also break (I have been testing on my MUT machine).
Clearly you are not having the same problem on your system as described in this ticket which makes me wonder why you are commenting on this ticket instead of opening a new one for your problem.
It is unlikely that the reporter is still having the reported problem with the current versions of all the drivers, and as he said he hasn't had a chance to try it yet so there is no point in doing anything until he reports back.
Also it was incorrect to change the version since you don't know if the reporter is still having the same problem with the current version.
comment:12 by , 12 years ago
Version: | 3.21.02 → 3.16 |
---|
comment:14 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
pci.exe output before suspend