Bug 14462 - Ultrabay drive not powered down during suspend - ThinkPad R61
Summary: Ultrabay drive not powered down during suspend - ThinkPad R61
Status: CLOSED UNREPRODUCIBLE
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Sleep-Wake (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: acpi_power-sleep-wake
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-25 02:31 UTC by Daniel Gnoutcheff
Modified: 2009-11-25 05:33 UTC (History)
2 users (show)

See Also:
Kernel Version:
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg (133.59 KB, text/plain)
2009-10-25 02:31 UTC, Daniel Gnoutcheff
Details
dmidecode (13.66 KB, text/plain)
2009-10-25 02:32 UTC, Daniel Gnoutcheff
Details

Description Daniel Gnoutcheff 2009-10-25 02:31:02 UTC
And here is another bug on the Lenovo ThinkPad R61 (7733A82) and its Ultrabay (loaded with a hotpluggable DVD±RW/CD-RW drive).

Back in the day when I was running Windows, I remember that the drive would get powered down during suspend, as indicated by a small light near the bay. However, Linux fails to do this powerdown, which results in a significantly higher-than-desired power drain during suspend.

A workaround is to manually power-down the drive before suspend via /sys/devices/platform/dock.2/undock. This does indeed reduce the power consumed while suspended). But, of course, it's problematic when I have a CD mounted. ;)

Thus is with latest linus (git-describe == v2.6.32-rc5-81-g964fe08).

It's worth noting that there is at least one other ThinkPad that has this problem, namely, the T51:
http://www.thinkwiki.org/wiki/Problem_with_high_power_drain_in_ACPI_sleep#R51:_Ultrabay_and_networking

I'l attach dmesg and dmidecode outputs shortly. I'm ready and willing to help with testing.

Hoping to be of help,
Daniel G.
Comment 1 Daniel Gnoutcheff 2009-10-25 02:31:59 UTC
Created attachment 23517 [details]
dmesg
Comment 2 Daniel Gnoutcheff 2009-10-25 02:32:44 UTC
Created attachment 23518 [details]
dmidecode
Comment 3 Zhang Rui 2009-11-17 03:03:58 UTC
please attach the acpidump output of your laptop.
Comment 4 Zhang Rui 2009-11-17 03:44:52 UTC
I tried to reproduce this bug on a T61 but failed.
And I did find that the led beside the bay is still on if I didn't undock the bay before suspend.

Then I use a power meter to see the power consumption in S3 state.
1. the power consumption is 1.7w ~ 1.8w if I suspend the laptop directly, 
2. the power consumption is 1.7w ~ 1.8w, while it goes to 1.6w eventually, if I undock the ultrabay before suspend.
so it seems that the power consumptions are almost the same in these two cases.

(In reply to comment #0)
> A workaround is to manually power-down the drive before suspend via
> /sys/devices/platform/dock.2/undock. This does indeed reduce the power
> consumed
> while suspended).

I don't know if I reproduced the problem you got on R61, but can you tell me why you think this reduces the power consumption please?
does the battery work much longer than before?
Comment 5 Daniel Gnoutcheff 2009-11-20 16:22:15 UTC
Hmm ... I am now unable to reproduce the high power consumption myself. :P

While I don't have a power meter (wish I did ;), I have been using a hack that guesses the power usage by measuring battery charge before and after suspend. The hack lives at http://www.thinkwiki.org/wiki/ACPI_sleep_power_drain_test_script

Some months ago I had used this script to estimate S3 power usage, and I seem to remember finding that S3 power dropped when I undocked the ultrabay, by 0.5-1.0 W or so. But then I ran out of free time so I couldn't file a bug report right away. Since then, I assumed that if the LED was still on, then the power drain was still there. I now see that this assumption seems to be incorrect. The aforementioned script now suggests a 0.8 W drain during S3, regardless of whether the drive is docked or not.

So it seems that I must have misinterpreted the results the first time around. Either that, or the power drain has been fixed since I last checked, in which case, great work guys. :) Sorry about the noise.

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