Bug 4364 - S1 suspend/resume resets thermal limits -- TP 600X
S1 suspend/resume resets thermal limits -- TP 600X
Status: CLOSED CODE_FIX
Product: ACPI
Classification: Unclassified
Component: Power-Thermal
i386 Linux
: P2 normal
Assigned To: Konstantin Karasyov
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-17 23:05 UTC by Sanjoy Mahajan
Modified: 2007-02-15 22:18 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.11.4
Tree: Mainline
Regression: ---


Attachments
output of acpidmp (206.32 KB, text/plain)
2005-03-17 23:06 UTC, Sanjoy Mahajan
Details
output of lspci -vv (7.56 KB, text/plain)
2005-03-17 23:07 UTC, Sanjoy Mahajan
Details
output of dmesg (before entering S1) (13.73 KB, text/plain)
2005-03-17 23:09 UTC, Sanjoy Mahajan
Details
2.6.11.4 kernel config (34.83 KB, text/plain)
2005-03-17 23:10 UTC, Sanjoy Mahajan
Details
Thermal suspen/resume (1.34 KB, patch)
2006-05-08 08:32 UTC, Konstantin Karasyov
Details | Diff

Description Sanjoy Mahajan 2005-03-17 23:05:01 UTC
Distribution: Debian testing

Hardware Environment: Thinkpad 600X 650MHz Pentium III

Software Environment: 2.6.11.4 + ACPI subsystem 20050309 + ibm_acpi 0.10f +
XFree 4.3.0.1

Problem Description: After entering S1 state, the screen goes blank but then
starts growing fine, rainbow-colored patterns near the middle of the screen and
a few horizontal lines.  The cruft grows until I hit the Fn key to wake it up. 
It eventually comes back and the screen is just as it was before the sleep.  But
various drivers are unhappy.  The uhci_hcd driver continuously reports error
messages such as 

hub 1-0:1.0: debounce: port 1: total 1500ms stable 0ms status 0x31f
hub 1-0:1.0: connect-debounce failed, port 1 disabled
uhci_hcd 0000:00:07.2: port 2 portsc ffff,00
hub 1-0:1.0: over-current change on port 2
hub 1-0:1.0: port 2, status 031f, change 000b, 1.5 Mb/s
uhci_hcd 0000:00:07.2: port 2 portsc ffff,00
uhci_hcd 0000:00:07.2: port 2 portsc ffff,00
uhci_hcd 0000:00:07.2: port 2 portsc ffff,00

The messages continue until I modprobe -r the driver and then reload it.  But
that produces the following warning:

USB Universal Host Controller Interface driver v2.2
PCI: Enabling device 0000:00:07.2 (0000 -> 0001)
PCI: Found IRQ 11 for device 0000:00:07.2
uhci_hcd 0000:00:07.2: Intel Corp. 82371AB/EB/MB PIIX4 USB
uhci_hcd 0000:00:07.2: irq 11, io base 0x4000
uhci_hcd 0000:00:07.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:07.2: detected 8 ports
uhci_hcd 0000:00:07.2: port count misdetected? forcing to 2 ports
uhci_hcd 0000:00:07.2: USBCMD_HCRESET timed out!
uhci_hcd 0000:00:07.2: init error -110
uhci_hcd 0000:00:07.2: remove, state 0
uhci_hcd 0000:00:07.2: roothub graceful disconnect
usb_disconnect nodev
Uninitialised timer!
This is just a warning.  Your computer is OK
function=0x00000000, data=0x0
 [<c011f351>] check_timer_failed+0x61/0x70
 [<c011f599>] del_timer+0x19/0x60
 [<e498c9c3>] uhci_stop+0x23/0x90 [uhci_hcd]
 [<c0255417>] usb_hcd_pci_remove+0xb7/0x1c0
 [<c02550c6>] usb_hcd_pci_probe+0x316/0x5b0
 [<c01d3282>] pci_device_probe_static+0x52/0x70
 [<c01d32dc>] __pci_device_probe+0x3c/0x50
 [<c01d331c>] pci_device_probe+0x2c/0x50
 [<c022713f>] driver_probe_device+0x2f/0x80
 [<c022728c>] driver_attach+0x5c/0xa0
 [<c02277dd>] bus_add_driver+0x9d/0xd0
 [<c0227dff>] driver_register+0x2f/0x40
 [<c01d35a4>] pci_register_driver+0x64/0x90
 [<e49b109b>] uhci_hcd_init+0x9b/0xf1 [uhci_hcd]
 [<c012e252>] sys_init_module+0x132/0x1c0
 [<c0102f33>] syscall_call+0x7/0xb
uhci_hcd 0000:00:07.2: USB bus 1 deregistered
uhci_hcd: probe of 0000:00:07.2 failed with error -110

Not surprisingly the USB-connected cell phone (cdc_acm driver) wouldn't behave
after those errors (couldn't talk to the /dev/ttyACM0 device).  Also the modem
in the xircom ethernet/modem combination card wouldn't work either.  Both worked
fine before the sleep attempt (and are working fine now after rebooting).

Also, the thermal-zone settings reset themselves to the default.  I had done

  echo 120:0:40:55:0 > /proc/acpi/thermal_zone/THM2/trip_points

to get the damn loud fan to be less aggressive (which worked fine -- an ACPI
success for which I am very happy).  By the way, I also had to do 

  echo 10 > THM2/polling_frequency

to get the change to take effect.  But now the polling_frequency is back to
'polling disabled' and the trip_points back to

critical (S5):           120 C
active[0]:               34 C: devices=0xc1574108 

I am using a custom DSDT: The vanilla TP 600X DSDT (from BIOS 1.11) but with a
few meager attempts to fix the DSDT recompilation errors and the S3 "missing
sleep state object" error (Bug #3534) -- no good or bad effect from the fixes,
at least that I could find.  I'll attach the output of acpidmp as well as
several other hopefully useful files.

Steps to reproduce: Boot w/ "apm=off pci=noacpi acpi_sleep=s3_bios" then into X,
then "echo 1 > /proc/acpi/sleep", wait a few seconds, then wake up by tapping
the Fn key.
Comment 1 Sanjoy Mahajan 2005-03-17 23:06:50 UTC
Created attachment 4747 [details]
output of acpidmp
Comment 2 Sanjoy Mahajan 2005-03-17 23:07:46 UTC
Created attachment 4748 [details]
output of lspci -vv
Comment 3 Sanjoy Mahajan 2005-03-17 23:09:06 UTC
Created attachment 4749 [details]
output of dmesg (before entering S1)
Comment 4 Sanjoy Mahajan 2005-03-17 23:10:49 UTC
Created attachment 4750 [details]
2.6.11.4 kernel config
Comment 5 Sanjoy Mahajan 2005-03-17 23:21:33 UTC
I forgot to add that I'll happily test patches or config permutations.
Comment 6 Len Brown 2005-08-17 12:18:03 UTC
each bugzilla should ideally focus on a single issue.
I dont' think we can help the screen issue.
I'm going to focus this issue on the thermal
tip-points loss of state and assign this to konstantin.
It is likely that supsend/resume needs to be added
to the thermal.c driver.
Comment 7 Sanjoy Mahajan 2005-08-17 12:26:00 UTC
> It is likely that supsend/resume needs to be added to the thermal.c driver.

And maybe also to fan.c.  A related problem (fan always on after
swsusp) is at Bug #5000, with this additional comment:

> Well, that fan.c lacks suspend/resume support. Hint hint :-).
> Put fan at full speed in _suspend() hook, and make hardware put the
> fan back to sane state during _resume() hook.

I don't (yet?) know how to do that, but someone else might know
already before I figure it out!

Comment 8 Konstantin Karasyov 2006-05-08 08:32:16 UTC
Created attachment 8052 [details]
Thermal suspen/resume

Here is suspend/resume implementation for ACPI thermal.
In order to make it work, a patch available from here:
http://bugzilla.kernel.org/attachment.cgi?id=8048&action=view
should be implemented first.
Comment 9 Konstantin Karasyov 2006-05-08 08:43:43 UTC
Sanjoy,

You should note that IIRC, the DSDT on your system implements 'Notify 
(\_TZ.THRM, 0x81)' or similar action in _WAK method, i.e. the trip points are 
being re-read on system resume. So, this could be the reason of thermal limits 
reset.

You could save trip poins on suspend and set them on resume, though I think 
it's not quite correct to override BIOS implementation in OS, so I didn't 
implemented it in the above patch.
Comment 10 Len Brown 2006-05-15 00:26:55 UTC
applied patch in comment #8 to acpi-test tree. 
Comment 11 Len Brown 2007-02-15 22:18:15 UTC
patch in comment #8 shipped in linux-2.6.18
closed.

Note You need to log in before you can comment on or make changes to this bug.