https://www.thinkwiki.org/w/api.php?action=feedcontributions&user=LJSBrokken&feedformat=atomThinkWiki - User contributions [en]2024-03-29T12:47:18ZUser contributionsMediaWiki 1.31.12https://www.thinkwiki.org/w/index.php?title=Problem_with_high_power_drain_in_ACPI_sleep&diff=34125Problem with high power drain in ACPI sleep2007-10-26T09:36:59Z<p>LJSBrokken: /* Affected Models */</p>
<hr />
<div>{| width="100%"<br />
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__<br />
|style="vertical-align:top" |<br />
==Problem description==<br />
Several people realized that their ThinkPads eat up too much power while suspended to ram via ACPI. Compared to APM suspend to ram the power drain is experienced to be about 10 times as high, 2-5 Watts. This empties the battery within one or two days.<br />
|}<br />
<br />
==Affected Models==<br />
{| border="1" cellspacing="0" cellpadding="2" style="float:right;margin-left:20px;"<br />
|-<br />
! style="vertical-align:top;background-color:#ffcfbc;" | affected models<br />
! style="vertical-align:top;background-color:#cfefcf;" | unaffected models <br />
|-<br />
| style="vertical-align:top;background-color:#fff0e0;" |<br />
* {{R32}}<br />
** 2658-BQG<br />
* {{R40}}<br />
** 2722-3GG<br />
** 2722-5MG<br />
** 2722-B3G<br />
** 2722-CDG<br />
** 2897-GWU<br />
** 2722-6YU<br />
** 2722-CDG<br />
* {{R50}}<br />
** 1829-7RG<br />
** 1829-6DM<br />
** 1836-3SU<br />
* {{R51}}<br />
** 1829-9MG<br />
** 1829-EHG<br />
** 1829-L7G<br />
** 1829-R6G<br />
** 1830-DG4<br />
** 1830-BMG<br />
** 1836-Q6U<br />
* {{T23}}<br />
**2647-???<br />
* {{T30}}<br />
** 2366-81A<br />
** 2366-97U<br />
** 2366-FBU<br />
** 2366-96G<br />
*{{T40}}<br />
**2373-19G<br />
**2373-22G<br />
**2373-42G<br />
**2373-75G <br />
**2373-82U<br />
**2373-92U<br />
**2373-A1U<br />
**2373-MU3<br />
*{{T40p}}<br />
**2373-G1U <br />
**2373-G3U<br />
**2373-G3G<br />
**2373-G1G<br />
**2373-G5G<br />
* {{T41}}<br />
**2379-DJU<br />
**2373-3KG<br />
**2373-9HU<br />
**2373-4FG<br />
**2373-4PG<br />
**2373-1FG<br />
**2373-2FG<br />
**2373-2GG<br />
**2373-6U4<br />
**2373-7JU<br />
**2373-CY0<br />
**2373-TG5<br />
**2373-3HM<br />
**2373-4GU<br />
**2373-8RG<br />
* {{T41p}}<br />
**2373-9FU<br />
* {{T42}}<br />
**2373-C19<br />
**2373-CTO<br />
**2378-DTU<br />
**2378-DUU<br />
**2378-XXE<br />
**2378-R4U<br />
**2373-FWG<br />
**2374-ZEP<br />
**2373-F2G<br />
**2373-JTU<br />
**2373-VUW<br />
**[[2373-6ZG]]<br />
* {{X21}}<br />
**2662-BSG<br />
* {{X22}}<br />
**2662-9DU<br />
* {{X24}}<br />
**2662-MQU<br />
* {{X31}}<br />
**2672-C2G<br />
* {{X32}}<br />
**2884-A3U<br />
*{{X41T}}<br />
** 1869-5CU<br />
| style="vertical-align:top;background-color:#e9f9e9;" |<br />
*[[:Category:A22m | A22m]]<br />
**2628<br />
*[[:Category:A31 | A31]]<br />
**2652-D5G<br />
*[[:Category:R50p | R50p]]<br />
*[[:Category:R52 | R52]]<br />
**1858-6MM<br />
*[[:Category:T41 | T41]]<br />
**2373-GEU<br />
*[[:Category:T41p | T41p]]<br />
**2373-GKG<br />
**2373-GGG<br />
**[[2373-GHG]]<br />
*[[:Category:T42 | T42]]<br />
**[[2373-M1G]]<br />
**[[2373-WBZ]]<br />
**[[2373-F7G]]<br />
**[[2378-DXU]]<br />
**[[2378-FVU]]<br />
**[[2378-RTU]]<br />
**[[2378-RRU]]<br />
*[[:Category:T42p | T42p]]<br />
**[[2373-HTG]]<br />
**[[2373-W6M]]<br />
**[[2373-GTG]]<br />
**[[2373-GXG]]<br />
**2373-KXM<br />
*[[:Category:T43 | T43]]<br />
**[[2668-W12]]<br />
*[[:Category:T43p | T43p]]<br />
**[[2668-G2G]]<br />
*[[:Category:X40 | X40]]<br />
**2371<br />
|}<br />
*Different symptoms have been reported for different models. In some models the origin of the power drain is obvious ([[Problem with LCD backlight remaining on during ACPI sleep|backlight on during suspend]]), in other models there is no obvious reason.<br />
<br />
*On some models/configurations the higher power drain couldn't even be realized or was at least significantly lower.<br />
<br />
*The T4x ThinkPad series and other Radeon based models suspend to ram just fine, and there are no components that are obviously left powered up. The [[UltraBay]] and network light is on, but that is the same under windows (but under APM sleep to RAM those lights are OFF). For these models the higher power drain is caused by a driver problem and can be fixed in software. Starting with linux 2.6.18 this fix is in the official kernel.<br />
<br />
The table on the right gives an overview of the models suffering from the mysterious power drain. To find out about your model, you may use the following [[ACPI sleep power drain test script | script]]. It creates a file {{path|/var/log/battery.log}} which will tell you if you are affected or not.<br />
<br />
==Affected Operating Systems==<br />
*Linux, all flavours.<br />
*Windows, for some models as well (only when using non-IBM drivers).<br />
*FreeBSD (on the A22M)<br />
<br />
==Radeon GPU not powered off==<br />
A frequent cause of the mysterious power drain is the Radeon GPU, which requires extra steps to suspend properly. We identified affected thinkpads, and [[radeonfb]] activates the workaround on those models automatically (starting with linux kernel 2.6.18).<br />
<br />
===Status===<br />
*The official bugzilla entry for the radeon suspend issue is in the [http://bugme.osdl.org/show_bug.cgi?id=3022 OSDL Bugzilla]. There you can find the above-mentioned patch for older kernel versions. The patch removes the CONFIG_PPC_PMAC condition for enabling D2 sleep in {{path|drivers/video/aty/radeon_pm.c}}. If you suspect that this patch makes things worse, you can disable it by the kernel parameter {{bootparm|video|radeonfb:ignore_devlist|1}}. Similarly, if the patch is not automatically activated on your notebook you can force it by {{bootparm|video|radeonfb:force_sleep|1}}. In case that improves your sleep, please leave a note in the bugzilla including the output of {{cmdroot|lspci -d "1002:*" -vn}}. See also [http://thread.gmane.org/gmane.linux.hardware.thinkpad/25355 the linux-thinkpad ML post requesting this information] for more information. <br />
<br />
*Most certainly, the DSDT is not at fault. (Interesting to note: The DSDT from BIOS 3.13 (Nov 04) for the T42p compiles without bugs.)<br />
<br />
===Solutions===<br />
You must use a recent (or patched) version of the [[radeonfb]] driver, even if you are only interested in using the X window system. The radeon frame buffer suspends the radeon chip correctly during ACPI sleep. Starting with linux 2.6.18, this patch is in the official (kernel.org) kernels.<br />
<br />
If the patch is known to work on your notebook, it is automatically enabled. If you think that your computer would profit from the patch as well, you can force it by including the module parameter {{bootparm|video|radeonfb:force_sleep|1}}. If it does not work this can result in system hangs.<br />
<br />
====Problem with radeonfb and X====<br />
In some cases [[radeonfb]] cannot coexist with the [[radeon]] X.org driver (causing corrupted rendering and hangs). Using the <tt>Option "UseFBDev" "True"</tt> of [[radeon]] may help, but this is incompatible with [[radeon]]'s mergedfb mode. A "GPU device layer" architecture which may, one day, resolve this was proposed by Dave Airlie [http://airlied.livejournal.com/#item30632 here] and [http://lkml.org/lkml/2006/7/22/45 here]. <br />
{{HELP|Practical solutions for this problem are needed}}<br />
<br />
Configurations which exhibit this problem: {{T43}} [[ATI Mobility Radeon X300]] with {{Fedora}} 5 using the [[radeon]] driver, with and without DRI.<br />
<br />
Configurations which don't exhibit this problem: {{T41}} [[ATI Mobility Radeon 9000]] running {{Fedora}} 5 and 6 using [[radeon]] driver, with and without DRI.<br />
<br />
====Fedora Core====<br />
* Fedora Core 6: Ships with kernel >= 2.6.18, only needs initrd (see below).<br />
* Fedora Core 5: The latest kernel from updates (2.6.18-1.2200.fc5) seems to actually fix this issue, you only have to make custom initrd because the default one does not contain radeonfb.<br />
* Fedora Core 4: Fedora ships a patched radeon frame buffer (radeonfb.ko), but you must enable it yourself. {{Fedora}} compiles it as a module rather than including it in the kernel, therefore you cannot activate it at boot time without a custom initrd. You must arrange for the module to be loaded before X starts (for example, using an init script).<br />
* Fedora Core 3: this is also true for updated kernels (at least for kernel-2.6.12-1.1376_FC3) but '''not''' for the initially shipped version.<br />
<br />
====openSuSE====<br />
* openSuSE 10.2: Ships with kernel >= 2.6.18. Needs initrd and boot menu changes. See [[http://en.opensuse.org/SDB:ThinkPadPowerDrain openSuSE SDB article on ThinkPad power drain problem]]<br />
<br />
====testing radeonfb without changing initrd====<br />
If you want to try the radeon frame buffer, you can enable it as follows:<br />
*First, switch to a console ({{key|Ctrl}}{{key|Alt}}{{key|F1}}) and log in as root.<br />
*Stop X: {{cmdroot|init 3}}<br />
*Now you can load the module: {{cmdroot|1=modprobe radeonfb force_sleep=1}}<br />
*Finally, resume X: {{cmdroot|init 5}}<br />
<br />
====Gentoo====<br />
After installing the patch on {{Gentoo}} (it works fine with gentoo-sources: {{cmdroot|cd /usr/src/linux/drivers/video/aty}}, and execute {{cmdroot|patch -p4 < <patchname>}}, then recompile the kernel), one needs to add {{bootparm|video|radeonfb:force_sleep}} to the kernel parameters.<br />
<br />
====including radeonfb into your initrd====<br />
As an alternative you can build your customized initrd. This is as simple as running<br />
:{{cmdroot|1=mkinitrd --with=radeonfb /boot/<name-of-your-new-initrd> `uname -r`}}<br />
and replacing the initrd in {{path|/boot/grub/grub.conf}} with your new one. You also need to add the kernel command line argument {{bootparm|video|2=radeonfb:force_sleep}}.<br />
<br />
With FC6 and KDE I had to:<br />
*Login as root<br />
*Enter the command as {{cmdroot|1=mkinitrd --with=radeonfb /boot/<name-of-your-new-initrd> <kernel version>}}<br />
:e.g. {{cmdroot|1=mkinitrd --with=radeonfb /boot/initrd-2.6.18-1.2798.fc6-my.img 2.6.18-1.2798.fc6}}<br />
:And the kernel command line argument was added to /etc/sysconfig/grub.<br />
<br />
==Backlight staying on==<br />
It is possible that [[radeontool]] will help some people if the backlight stays on.<br />
(simply run "radeontool light off" before suspend and "radeontool light on" after resume).<br />
A radeontool patch for freebsd is here: http://www.init-main.com/radeontool.patch (by Takanori Watanabe).<br />
<br />
===Notes for gnome-power-manager===<br />
If you suspend from Gnome and need to run radeontool to turn the backlight off you need to find the suspend script for HAL. In Ubuntu, the scripts are located in /usr/share/hal/scripts/. Add the following the script "hal-system-power-suspend":<br />
chvt 1<br />
radeontool light off<br />
And in the resume script ("restore-after-standby"):<br />
radeontool light on<br />
chvt 7<br />
<br />
This worked for me. YMMV. [[User:Etnoy|Etnoy]] 16:27, 9 November 2006 (CET)<br />
<br />
===For models without Radeon graphics===<br />
The Problem seems to be solved when you use the [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to turn the LCD off before suspending ...<br />
:{{cmdroot|vbetool dpms off}}<br />
and turning it on afterwards again...<br />
:{{cmdroot|vbetool dpms on}}<br />
You have to change to a normal console before turning the LCD off.<br />
Additionally you have to deactivate the Wake-On-Lan feature like mentioned above ...<br />
:{{cmdroot|ethtool -s eth0 wol d}}<br />
With these commands used together the "testing script" reports no high power drain while suspending.<br />
<br />
==Other problems causing the power drain==<br />
On my [[:Category:R51|R51]] using Gentoo Linux, the high power drain was not caused by the graphics adaptor but by several components not powered down properly before putting the Thinkpad into S3.<br />
<br />
If the above did not help you, this might do:<br />
<br />
Walk through<br />
/sys/devices/*/*/power/state<br />
and try to disable each of it, every time checking the power drain. (See linux/Documentation/power/devices.txt for values to write into the state-files. 3 should be the value you want to try)<br />
Do the same for other components (Like the Ultrabay, etc.). Please add your experiences here.<br />
<br />
===R51: Ultrabay and networking===<br />
On my system, ultrabay and networking light were still on while in S3. So were the devices theirselves.<br />
echo -n eject > /proc/acpi/ibm/bay # Disable ultrabay<br />
ethtool -s eth0 wol d # Disable Wake-On-Lan (And so the eth-adaptor)<br />
echo mem > /sys/power/state # Sleep<br />
<br />
For me, this lowered the power drain from >700mW to 338 mW.<br />
<br />
===USB===<br />
My initial testing of a [[:Category:T43|T43]] (2669-model) revealed no power drain issues. However, after several rounds of BIOS and kernel upgrades I have discovered that the power drain has risen to >700mWh. Having tested things a bit, I have discoved that removing ehci_hcd module solved the high power drain. This is a [[:Category:T43|T43]] laptop, with kernel 2.6.17-r5 and BIOS 1.28/EC 1.06. For me, issuing {{cmdroot|modprobe -r ehci_hcd}} before going to sleep and reloading the module ({{cmdroot|modprobe ehci_hcd}}) after waking up dropped the power drain down to 277mWh in suspend2ram, which seems fair. The unloading/reloading can be put into the suitable ACPI script called to suspend the laptop.<br />
<br />
===Wake-on-LAN===<br />
Some additional power savings can be achieved by turning off the wake-on-lan ({{cmdroot|ethtool -s eth0 wol d}}). The power drain of the wol feature is far smaller than the radeon bug, but can be noticeable.</div>LJSBrokkenhttps://www.thinkwiki.org/w/index.php?title=Talk:Problem_with_unauthorized_MiniPCI_network_card&diff=23297Talk:Problem with unauthorized MiniPCI network card2006-07-20T11:17:46Z<p>LJSBrokken: </p>
<hr />
<div>== Affected Models ==<br />
I am unsure about which models this applies to. I have seen reports of this problem affecting a T41p, T43, X40, R31, X31, and T30; but I do not know how far back this problem goes or if there are exceptions. If anyone has better information, please clarify/specify the "Affected Models" section. --[[User:Kevinoid|Kevinoid]] 05:44, 14 Dec 2005 (CET)<br />
<br />
== Solution on T43? ==<br />
There were several edits to the previous page to the effect that "this didn't work for my T43". Although I do not weight this as highly credible (please just ask for help on the ML rather than adding random comments to pages), I did feel that it deserved a mention that the solution may not work on the T43. If anyone can confirm or deny this statement, please do so (and possibly ask on the ML for solutions if it does not work for you). --[[User:Kevinoid|Kevinoid]] 05:44, 14 Dec 2005 (CET)<br />
<br />
== Confirmation - patch not working on T43 ==<br />
I can confirm, that a "nvram/cmos" patch is not working on my T43, exact type 1871-A62. I tried several cards (some working without patch in another thinkpads (t40, t42, x40), but no success.--[[User:Jap|Jap]] 09:50, 13 June 2006 (CEST)<br />
<br />
== Hotplugging PCI device ==<br />
I'd like to send out a '''BIG FAT WARNING''' that 'hotplugging' the mini-PCI card can easily lead to frying the system board, mini-PCI bus, or both. Yes, it happened to me... :-( Interrupting the boot process at the lilo boot menu, and then inserting the ipw2915abg card worked as a charm to circumvent the BIOS white list. However, somewhere it must have gone wrong because now the laptop hangs immediately when the IBM/Intel boot logos appear. --[[User:LJSBrokken|LJSBrokken]] 13:01, 20 July 2006 (GMT+1)</div>LJSBrokkenhttps://www.thinkwiki.org/w/index.php?title=Talk:SMAPI_support_for_Linux&diff=13950Talk:SMAPI support for Linux2005-12-21T16:03:57Z<p>LJSBrokken: /* Feedback */</p>
<hr />
<div>== Feedback ==<br />
<br />
Great, great work! Really! This completely rocks. I just stopped my battery from charging at 77% and restarted charging a bit later, no problems whatsoever. BTW, this is on kernel 2.6.14.3.<br />
<br />
--[[User:Spiney|spiney]] 21:25, 5 Dec 2005 (CET)<br />
----<br />
None of the fuctions is working on my T40, kernel 2.6.14-mm2.<br />
<br />
--[[User:Lammic|lammic]], 2005.12.05<br />
<br />
Works for me on a T41 running 2.6.12-10-686 (Ubuntu 5.10).<br />
<br />
--[[User:berndtnm|berndtnm]], 2005.12.06<br />
<br />
Including stop_charge_thresh? That one seems to be missing on the T42p.<br />
<br />
--[[User:Thinker|Thinker]] 00:46, 7 Dec 2005 (CET)<br />
----<br />
<br />
tp_smapi works just fine on an R52 with Ubuntu Breezy stock kernel.<br />
<br />
--[[User:Micampe|Micampe]] 12:52, 7 Dec 2005 (CET)<br />
<br />
----<br />
<br />
''To set the thresholds for starting and stopping battery charging (in percent of current capacity):''<br />
<br />
'''current''' really? That'd be weird, I'd expect it to be percent of '''total''' capacity.<br />
<br />
--[[User:Micampe|Micampe]] 14:39, 7 Dec 2005 (CET)<br />
<br />
"Current full charge capacity", as opposed to "current remaining capacity" or "designed full charge capacity"...<br />
<br />
--[[User:Thinker|Thinker]] 15:05, 7 Dec 2005 (CET)<br />
----<br />
<br />
Battery features don't work with my T41p. I can't check this with windows. Can anybody try these features?<br />
<br />
-- Nils, 7 Dec 2005<br />
----<br />
<br />
Nils, does cdrom_speed work for you on the T41p? Could you provide the details requested in the README (dmesg etc.)?<br />
<br />
--[[User:Thinker|Thinker]] 21:57, 7 Dec 2005 (CET)<br />
----<br />
<br />
CDRom Speed seems to work. (I see no warnings, but I have to do a speed test.) Now, I've send all outputs to the email-address in the readme.<br />
<br />
-- Nils, 8 Dec 2005<br />
----<br />
<br />
All the features except the stop_charge_thresh seem to work here on a t42p. <br />
One note, the start_charge_thresh seems to really be stop_charge_thresh. Ie, If I set that to lower than my current battery %, it will never charge, <br />
and if I set it to 100 the battery charges all the way. <br />
<br />
--[[User:Nirik|Nirik]] 16 Dec 2005<br />
----<br />
<br />
Nirik, "all the features" as of which version? For example, do the force_discharge{1,2} in tp_smapi 0.12 also work for you? See the table in the article page. About start_charge, that's odd. Can you send me a log of what you did, what was the result a what was the dmesg output for each operation?<br />
<br />
--[[User:Thinker|Thinker]] 14:16, 16 Dec 2005 (CET)<br />
----<br />
<br />
System T40p:<br />
<br />
<pre><br />
fairlight:/sys/devices/platform/smapi/BAT0# echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge1<br />
fairlight:/sys/devices/platform/smapi/BAT0# echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge2<br />
fairlight:/sys/devices/platform/smapi/BAT0# dmesg <br />
tp_smapi: req_in: BX=2118 CX=100 DI=0 SI=0<br />
tp_smapi: req_out: AX=8680 BX=2118 CX=100 DX=b2 DI=0 SI=0 ret=-38<br />
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)<br />
tp_smapi: cannot get force_discharge1 of battery 0: Function is not supported by SMAPI BIOS<br />
tp_smapi: req_in: BX=2104 CX=100 DI=0 SI=0<br />
tp_smapi: req_out: AX=80 BX=2103 CX=100 DX=78 DI=0 SI=0 ret=0<br />
tp_smapi: cannot get force_discharge2 of battery 0: bx=2103<br />
</pre><br />
<br />
So it seems force_discharge1 is not supported at all. But force_discharge2? By the way, i think wiki is a _very_ good idea for collecting information, but not for discussion. I would prefer a maillinglist. We can use sourceforge.<br />
<br />
--[[User|StefanSchmidt]]<br />
<br />
force_discharge2 is indicating a real error condition (bx=2103 which has bit 0x02 on), but I have no idea what the error is or how to fix it. Sorry. If you can trigger this function under Windows and have SoftICE or equivalent, maybe it can be worked out.<br />
<br />
About the Wiki discussion, I'm not sure a mailing list is justified yet, but you can use the linux-thinkpad list or the e-mail address in the README. <br />
<br />
--[[User:Thinker|Thinker]] 21:42, 16 Dec 2005 (CET)<br />
<br />
OK, then i use linux-thinkpad to get more people involved. I'am away the next weeks, but i hope to find some time to hacking on tp_smapi.<br />
<br />
--[[User:StefanSchmidt]]<br />
----<br />
<br />
Someone reported cd_speed works on T42 but on mine, it doesn't: this is 2378DXU<br />
<br />
--[[User:eBug]] 22:55, 17 Dec 2005 (CET)<br />
----<br />
<br />
eBug, how does it fail? If the file doesn't exist, it means you didn't enable PROVIDE_CD_SPEED (see the README). If it does exist, can you provide the dmesg output when you read an write to the file?<br />
<br />
--[[User:Thinker|Thinker]] 11:53, 18 Dec 2005 (CET)<br />
----<br />
<br />
To confirm:<br />
tp_smapi 0.13 works with hdaps module loaded on T41 (2373-8RG). However, force_discharge*, inhibit_charge_minutes, start_charge_thresh, stop_charge_thresh don't seem to be implemented on this model.<br />
<br />
--[[User:LJSBRokken|LJSBrokken]] 21 Dec 2005<br />
----<br />
<br />
==Changing the CD speed when the CD is being accessed will hang your computer==<br />
<br />
I don't have this problem on my T40p. CDROM is mounted and file on CD is opened. Change speed do '''not''' hang my system.<br />
<br />
-- Stefan Schmidt<br />
----<br />
<br />
An open file looks fine if you're not reading/writing at that point. But my T43 does hangs on this:<br />
# dd if=/dev/scd0 of=/dev/null &<br />
# echo 1 > /sys/devices/platform/smapi/cdrom_speed<br />
<br />
--[[User:Thinker|Thinker]] 16:41, 7 Dec 2005 (CET)<br />
----<br />
<br />
OK, sorry. I was to fast. My system hangs on this commands, too. :(<br />
<br />
-- Stefan Schmidt<br />
<br />
Works well. Great.<br />
<br />
T42 2373-8zh. Working :cdrom_speed and start_charge_thresh. Untest : inhibit_charge_minutes.<br />
<br />
-- Haifeng Chen<br />
<br />
cdrom_speed works on my T40.<br />
<br />
-- [[User:Lammic|lammic]], 2005.12.09<br />
<br />
== "thinkpad" module kernel compatibility ==<br />
<br />
Ajunge, how do you compile the "thinkpad" module compile on kernel >=2.6.9? The latest thinkpad version (5.8) still uses "get_cpu_ptr" and "set_cpu_ptr", which were removed in 2.6.9.<br />
<br />
--[[User:Thinker|Thinker]] 13:53, 10 Dec 2005 (CET)<br />
----<br />
<br />
The Debian thinkpad-source package in unstable (version 5.8-4) works just fine; I'm compiling it with 2.6.14 without any problems. And get_cpu_ptr is present; it's defined in include/linux/percpu.h.<br />
<br />
--[[User:TedTso|TedTso]] 18:56, 17 Dec 2005 (EDT)<br />
----<br />
<br />
Stock thinkpad_5.8.tar.gz doesn't #include percpu.h anyway, and doesn't compile on vanilla 2.6.14.3 or 2.6.15-rc5. Maybe Debian patched it? In that case the article page should ref the patch.<br />
<br />
--[[User:Thinker|Thinker]] 11:50, 18 Dec 2005 (CET)<br />
----<br />
<br />
Oops, my mistake. I forgot that I had patched my copy of thinkpadpm.c. I replaced the use of get_cpu_ptr and set_cpu_ptr with get_cpu_val() and set_cpu_val(). I just double checked, and it tpctl is working for me on 2.6.15-rc5.<br />
<br />
--[[User:TedTso|TedTso]] 14:45, 19 Dec 2005 (EDT)<br />
----<br />
<br />
Care to send a patch? It would be useful on the article page, and maybe we can get it into upstream.<br />
<br />
--[[User:Thinker|Thinker]] 23:11, 19 Dec 2005 (CET)<br />
----<br />
<br />
== Kernel Patch? ==<br />
<br />
Hello Thinker,<br />
<br />
would it be possible to provide the SMAPI support as kernel patch as well? Something along the lines of: (0.12 against 2.6.15-rc5)<br />
<br />
''(deleted, see below for how to create a patch file)''<br />
<br />
Deleted the tp_smapi.c file at the end, out of obvious reasons, and I'm not sure about the placement in the ACPI section, OTOH there it would be found easily next to ibm_acpi.<br />
<br />
Providing a patch would help when recompiling the kernel often, I hate recompiling external modules every time (even got me a kernel-upgrade script to do most of it automatically). But of course it's up to you. :)<br />
<br />
--[[User:Spiney|spiney]] 09:52, 16 Dec 2005 (CET)<br />
----<br />
<br />
I'll be glad to add this, but I don't want to go through additional manual steps in the release process (there are already quite a few). Can you add a "make patch" functionality to the Makefile, or something of the sort, to automatically generate a full patch (including tp_smapi.c) against current kernel sources?<br />
<br />
Also, this shouldn't be under drivers/acpi, since it doesn't use ACPI at all (that's why I didn't make it a patch to ibm_acpi). I think the right place is drivers/firmware, like the dell_rbu driver for Dell laptops.<br />
<br />
BTW, the convention for kernel patches is to start them once level higher:<br />
diff -Nurp kernel-2.6.14-vanilla kernel-2.6.14-patched<br />
<br />
--[[User:Thinker|Thinker]] 17:12, 16 Dec 2005 (CET)<br />
----<br />
<br />
Of course it's from the wrong level, as usual I was just lazy/inattentive. And at one point I'll remember who likes what patch format, promise. ;)<br />
<br />
A patch target as in "create a new file holding a correct diff to current kernel source" would be rather difficult, since line numbers might change etc., but applying the patch should be straighforward with a bit of sed. Of course I could just do that, create a patch with the diff command and then apply the new patch file in reverse. ;)<br />
<br />
--[[User:Spiney|spiney]] 18:36, 16 Dec 2005 (CET)<br />
----<br />
<br />
If it does that on a local copy (no changes the original kernel tree) and cleans up after itself, that's fine with me. :-)<br />
<br />
--[[User:Thinker|Thinker]] 18:50, 16 Dec 2005 (CET)<br />
----<br />
<br />
Ok, here's a shell script that creates the patch, feel free to use it under the terms of the GPL. For example call it from your Makefile with the patch target: (I didn't want to put all the script into the Makefile, since the rules about escaping in Makefiles, well, escape me ;)<br />
<br />
<pre><br />
#!/bin/bash<br />
<br />
KDIR=/lib/modules/$(uname -r)/build<br />
FDIR=drivers/firmware<br />
OPWD=$(pwd)<br />
<br />
TMPDIR=$(mktemp -d)<br />
cd $TMPDIR<br />
<br />
mkdir -p a/$FDIR<br />
cp $KDIR/$FDIR/{Kconfig,Makefile} a/$FDIR<br />
cp -r a b<br />
sed -i -e '/endmenu/i\<br />
config IBM_SMAPI\<br />
tristate "IBM ThinkPad SMAPI Support"\<br />
depends on X86\<br />
---help---\<br />
This adds SMAPI support on IBM ThinkPads, mostly used for battery\<br />
charge control. For more information about this driver see\<br />
<http://www.thinkwiki.org/wiki/SMAPI_support_for_Linux> .\<br />
\<br />
If you have an IBM ThinkPad laptop, say Y or M here.\<br />
' b/$FDIR/Kconfig<br />
sed -i -e '$a\<br />
obj-$(CONFIG_IBM_SMAPI) += tp_smapi.o' b/$FDIR/Makefile<br />
cp $OPWD/tp_smapi.c b/$FDIR<br />
diff -Nurp a b > $OPWD/tp_smapi-$(uname -r).patch<br />
rm -r a b<br />
cd $OPWD<br />
</pre><br />
<br />
BTW, [http://qbnz.com/highlighter/ GeSHi]-based syntax-highlighting would be great...<br />
<br />
--[[User:Spiney|spiney]] 19:28, 16 Dec 2005 (CET)<br />
----<br />
<br />
Ah, neat sed foo. How about [http://tpctl.sourceforge.net/tmp/Makefile this] escapade, then? <br />
<br />
What's the sed spell needed to replace the Makefile's<br />
VER := 0.13<br />
with auto-parsing of<br />
#define TP_VERSION "0.13"<br />
from tp_smapi.c?<br />
<br />
--[[User:Thinker|Thinker]] 20:37, 16 Dec 2005 (CET)<br />
----<br />
<br />
Hmm, something like<br />
VERFROMC=$(sed -ne 's/^#define TP_VERSION "\(.*\)"/\1/gp' tp_smapi.c)<br />
sed -i -e "s/^VER := .*$/VER := $VERFROMC/" Makefile<br />
should do (untested, from the top of my head, maybe the temporary variable isn't even necessary?). And neat Makefile wizardry, at one point I'll learn the syntax.<br />
<br />
--[[User:Spiney|spiney]] 20:44, 16 Dec 2005 (CET)<br />
----<br />
<br />
Makefile escaping is horrible, keep avoiding it... Anyway, the updated [http://tpctl.sourceforge.net/tmp/Makefile make patch] seems to do the right thing.<br />
<br />
--[[User:Thinker|Thinker]] 21:36, 16 Dec 2005 (CET)<br />
----</div>LJSBrokkenhttps://www.thinkwiki.org/w/index.php?title=Talk:SMAPI_support_for_Linux&diff=13556Talk:SMAPI support for Linux2005-12-21T16:00:47Z<p>LJSBrokken: /* Feedback */</p>
<hr />
<div>== Feedback ==<br />
<br />
Great, great work! Really! This completely rocks. I just stopped my battery from charging at 77% and restarted charging a bit later, no problems whatsoever. BTW, this is on kernel 2.6.14.3.<br />
<br />
--[[User:Spiney|spiney]] 21:25, 5 Dec 2005 (CET)<br />
----<br />
None of the fuctions is working on my T40, kernel 2.6.14-mm2.<br />
<br />
--[[User:Lammic|lammic]], 2005.12.05<br />
<br />
Works for me on a T41 running 2.6.12-10-686 (Ubuntu 5.10).<br />
<br />
--[[User:berndtnm|berndtnm]], 2005.12.06<br />
<br />
Including stop_charge_thresh? That one seems to be missing on the T42p.<br />
<br />
--[[User:Thinker|Thinker]] 00:46, 7 Dec 2005 (CET)<br />
----<br />
<br />
tp_smapi works just fine on an R52 with Ubuntu Breezy stock kernel.<br />
<br />
--[[User:Micampe|Micampe]] 12:52, 7 Dec 2005 (CET)<br />
<br />
----<br />
<br />
''To set the thresholds for starting and stopping battery charging (in percent of current capacity):''<br />
<br />
'''current''' really? That'd be weird, I'd expect it to be percent of '''total''' capacity.<br />
<br />
--[[User:Micampe|Micampe]] 14:39, 7 Dec 2005 (CET)<br />
<br />
"Current full charge capacity", as opposed to "current remaining capacity" or "designed full charge capacity"...<br />
<br />
--[[User:Thinker|Thinker]] 15:05, 7 Dec 2005 (CET)<br />
----<br />
<br />
Battery features don't work with my T41p. I can't check this with windows. Can anybody try these features?<br />
<br />
-- Nils, 7 Dec 2005<br />
----<br />
<br />
Nils, does cdrom_speed work for you on the T41p? Could you provide the details requested in the README (dmesg etc.)?<br />
<br />
--[[User:Thinker|Thinker]] 21:57, 7 Dec 2005 (CET)<br />
----<br />
<br />
CDRom Speed seems to work. (I see no warnings, but I have to do a speed test.) Now, I've send all outputs to the email-address in the readme.<br />
<br />
-- Nils, 8 Dec 2005<br />
----<br />
<br />
All the features except the stop_charge_thresh seem to work here on a t42p. <br />
One note, the start_charge_thresh seems to really be stop_charge_thresh. Ie, If I set that to lower than my current battery %, it will never charge, <br />
and if I set it to 100 the battery charges all the way. <br />
<br />
--[[User:Nirik|Nirik]] 16 Dec 2005<br />
----<br />
<br />
Nirik, "all the features" as of which version? For example, do the force_discharge{1,2} in tp_smapi 0.12 also work for you? See the table in the article page. About start_charge, that's odd. Can you send me a log of what you did, what was the result a what was the dmesg output for each operation?<br />
<br />
--[[User:Thinker|Thinker]] 14:16, 16 Dec 2005 (CET)<br />
----<br />
<br />
System T40p:<br />
<br />
<pre><br />
fairlight:/sys/devices/platform/smapi/BAT0# echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge1<br />
fairlight:/sys/devices/platform/smapi/BAT0# echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge2<br />
fairlight:/sys/devices/platform/smapi/BAT0# dmesg <br />
tp_smapi: req_in: BX=2118 CX=100 DI=0 SI=0<br />
tp_smapi: req_out: AX=8680 BX=2118 CX=100 DX=b2 DI=0 SI=0 ret=-38<br />
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)<br />
tp_smapi: cannot get force_discharge1 of battery 0: Function is not supported by SMAPI BIOS<br />
tp_smapi: req_in: BX=2104 CX=100 DI=0 SI=0<br />
tp_smapi: req_out: AX=80 BX=2103 CX=100 DX=78 DI=0 SI=0 ret=0<br />
tp_smapi: cannot get force_discharge2 of battery 0: bx=2103<br />
</pre><br />
<br />
So it seems force_discharge1 is not supported at all. But force_discharge2? By the way, i think wiki is a _very_ good idea for collecting information, but not for discussion. I would prefer a maillinglist. We can use sourceforge.<br />
<br />
--[[User|StefanSchmidt]]<br />
<br />
force_discharge2 is indicating a real error condition (bx=2103 which has bit 0x02 on), but I have no idea what the error is or how to fix it. Sorry. If you can trigger this function under Windows and have SoftICE or equivalent, maybe it can be worked out.<br />
<br />
About the Wiki discussion, I'm not sure a mailing list is justified yet, but you can use the linux-thinkpad list or the e-mail address in the README. <br />
<br />
--[[User:Thinker|Thinker]] 21:42, 16 Dec 2005 (CET)<br />
<br />
OK, then i use linux-thinkpad to get more people involved. I'am away the next weeks, but i hope to find some time to hacking on tp_smapi.<br />
<br />
--[[User:StefanSchmidt]]<br />
----<br />
<br />
Someone reported cd_speed works on T42 but on mine, it doesn't: this is 2378DXU<br />
<br />
--[[User:eBug]] 22:55, 17 Dec 2005 (CET)<br />
----<br />
<br />
eBug, how does it fail? If the file doesn't exist, it means you didn't enable PROVIDE_CD_SPEED (see the README). If it does exist, can you provide the dmesg output when you read an write to the file?<br />
<br />
--[[User:Thinker|Thinker]] 11:53, 18 Dec 2005 (CET)<br />
----<br />
<br />
To confirm:<br />
tp_smapi 0.13 works with hdaps module loaded on T41 (2373-8RG). However, force_discharge*, inhibit_charge_minutes, start_charge_thresh, stop_charge_thresh don't seem to be implemented on this model.<br />
<br />
==Changing the CD speed when the CD is being accessed will hang your computer==<br />
<br />
I don't have this problem on my T40p. CDROM is mounted and file on CD is opened. Change speed do '''not''' hang my system.<br />
<br />
-- Stefan Schmidt<br />
----<br />
<br />
An open file looks fine if you're not reading/writing at that point. But my T43 does hangs on this:<br />
# dd if=/dev/scd0 of=/dev/null &<br />
# echo 1 > /sys/devices/platform/smapi/cdrom_speed<br />
<br />
--[[User:Thinker|Thinker]] 16:41, 7 Dec 2005 (CET)<br />
----<br />
<br />
OK, sorry. I was to fast. My system hangs on this commands, too. :(<br />
<br />
-- Stefan Schmidt<br />
<br />
Works well. Great.<br />
<br />
T42 2373-8zh. Working :cdrom_speed and start_charge_thresh. Untest : inhibit_charge_minutes.<br />
<br />
-- Haifeng Chen<br />
<br />
cdrom_speed works on my T40.<br />
<br />
-- [[User:Lammic|lammic]], 2005.12.09<br />
<br />
== "thinkpad" module kernel compatibility ==<br />
<br />
Ajunge, how do you compile the "thinkpad" module compile on kernel >=2.6.9? The latest thinkpad version (5.8) still uses "get_cpu_ptr" and "set_cpu_ptr", which were removed in 2.6.9.<br />
<br />
--[[User:Thinker|Thinker]] 13:53, 10 Dec 2005 (CET)<br />
----<br />
<br />
The Debian thinkpad-source package in unstable (version 5.8-4) works just fine; I'm compiling it with 2.6.14 without any problems. And get_cpu_ptr is present; it's defined in include/linux/percpu.h.<br />
<br />
--[[User:TedTso|TedTso]] 18:56, 17 Dec 2005 (EDT)<br />
----<br />
<br />
Stock thinkpad_5.8.tar.gz doesn't #include percpu.h anyway, and doesn't compile on vanilla 2.6.14.3 or 2.6.15-rc5. Maybe Debian patched it? In that case the article page should ref the patch.<br />
<br />
--[[User:Thinker|Thinker]] 11:50, 18 Dec 2005 (CET)<br />
----<br />
<br />
Oops, my mistake. I forgot that I had patched my copy of thinkpadpm.c. I replaced the use of get_cpu_ptr and set_cpu_ptr with get_cpu_val() and set_cpu_val(). I just double checked, and it tpctl is working for me on 2.6.15-rc5.<br />
<br />
--[[User:TedTso|TedTso]] 14:45, 19 Dec 2005 (EDT)<br />
----<br />
<br />
Care to send a patch? It would be useful on the article page, and maybe we can get it into upstream.<br />
<br />
--[[User:Thinker|Thinker]] 23:11, 19 Dec 2005 (CET)<br />
----<br />
<br />
== Kernel Patch? ==<br />
<br />
Hello Thinker,<br />
<br />
would it be possible to provide the SMAPI support as kernel patch as well? Something along the lines of: (0.12 against 2.6.15-rc5)<br />
<br />
''(deleted, see below for how to create a patch file)''<br />
<br />
Deleted the tp_smapi.c file at the end, out of obvious reasons, and I'm not sure about the placement in the ACPI section, OTOH there it would be found easily next to ibm_acpi.<br />
<br />
Providing a patch would help when recompiling the kernel often, I hate recompiling external modules every time (even got me a kernel-upgrade script to do most of it automatically). But of course it's up to you. :)<br />
<br />
--[[User:Spiney|spiney]] 09:52, 16 Dec 2005 (CET)<br />
----<br />
<br />
I'll be glad to add this, but I don't want to go through additional manual steps in the release process (there are already quite a few). Can you add a "make patch" functionality to the Makefile, or something of the sort, to automatically generate a full patch (including tp_smapi.c) against current kernel sources?<br />
<br />
Also, this shouldn't be under drivers/acpi, since it doesn't use ACPI at all (that's why I didn't make it a patch to ibm_acpi). I think the right place is drivers/firmware, like the dell_rbu driver for Dell laptops.<br />
<br />
BTW, the convention for kernel patches is to start them once level higher:<br />
diff -Nurp kernel-2.6.14-vanilla kernel-2.6.14-patched<br />
<br />
--[[User:Thinker|Thinker]] 17:12, 16 Dec 2005 (CET)<br />
----<br />
<br />
Of course it's from the wrong level, as usual I was just lazy/inattentive. And at one point I'll remember who likes what patch format, promise. ;)<br />
<br />
A patch target as in "create a new file holding a correct diff to current kernel source" would be rather difficult, since line numbers might change etc., but applying the patch should be straighforward with a bit of sed. Of course I could just do that, create a patch with the diff command and then apply the new patch file in reverse. ;)<br />
<br />
--[[User:Spiney|spiney]] 18:36, 16 Dec 2005 (CET)<br />
----<br />
<br />
If it does that on a local copy (no changes the original kernel tree) and cleans up after itself, that's fine with me. :-)<br />
<br />
--[[User:Thinker|Thinker]] 18:50, 16 Dec 2005 (CET)<br />
----<br />
<br />
Ok, here's a shell script that creates the patch, feel free to use it under the terms of the GPL. For example call it from your Makefile with the patch target: (I didn't want to put all the script into the Makefile, since the rules about escaping in Makefiles, well, escape me ;)<br />
<br />
<pre><br />
#!/bin/bash<br />
<br />
KDIR=/lib/modules/$(uname -r)/build<br />
FDIR=drivers/firmware<br />
OPWD=$(pwd)<br />
<br />
TMPDIR=$(mktemp -d)<br />
cd $TMPDIR<br />
<br />
mkdir -p a/$FDIR<br />
cp $KDIR/$FDIR/{Kconfig,Makefile} a/$FDIR<br />
cp -r a b<br />
sed -i -e '/endmenu/i\<br />
config IBM_SMAPI\<br />
tristate "IBM ThinkPad SMAPI Support"\<br />
depends on X86\<br />
---help---\<br />
This adds SMAPI support on IBM ThinkPads, mostly used for battery\<br />
charge control. For more information about this driver see\<br />
<http://www.thinkwiki.org/wiki/SMAPI_support_for_Linux> .\<br />
\<br />
If you have an IBM ThinkPad laptop, say Y or M here.\<br />
' b/$FDIR/Kconfig<br />
sed -i -e '$a\<br />
obj-$(CONFIG_IBM_SMAPI) += tp_smapi.o' b/$FDIR/Makefile<br />
cp $OPWD/tp_smapi.c b/$FDIR<br />
diff -Nurp a b > $OPWD/tp_smapi-$(uname -r).patch<br />
rm -r a b<br />
cd $OPWD<br />
</pre><br />
<br />
BTW, [http://qbnz.com/highlighter/ GeSHi]-based syntax-highlighting would be great...<br />
<br />
--[[User:Spiney|spiney]] 19:28, 16 Dec 2005 (CET)<br />
----<br />
<br />
Ah, neat sed foo. How about [http://tpctl.sourceforge.net/tmp/Makefile this] escapade, then? <br />
<br />
What's the sed spell needed to replace the Makefile's<br />
VER := 0.13<br />
with auto-parsing of<br />
#define TP_VERSION "0.13"<br />
from tp_smapi.c?<br />
<br />
--[[User:Thinker|Thinker]] 20:37, 16 Dec 2005 (CET)<br />
----<br />
<br />
Hmm, something like<br />
VERFROMC=$(sed -ne 's/^#define TP_VERSION "\(.*\)"/\1/gp' tp_smapi.c)<br />
sed -i -e "s/^VER := .*$/VER := $VERFROMC/" Makefile<br />
should do (untested, from the top of my head, maybe the temporary variable isn't even necessary?). And neat Makefile wizardry, at one point I'll learn the syntax.<br />
<br />
--[[User:Spiney|spiney]] 20:44, 16 Dec 2005 (CET)<br />
----<br />
<br />
Makefile escaping is horrible, keep avoiding it... Anyway, the updated [http://tpctl.sourceforge.net/tmp/Makefile make patch] seems to do the right thing.<br />
<br />
--[[User:Thinker|Thinker]] 21:36, 16 Dec 2005 (CET)<br />
----</div>LJSBrokken