Showing posts with label debian. Show all posts
Showing posts with label debian. Show all posts

Thursday, September 6, 2012

Make new ThinkPad's charge thresholds work in Debian/Ubuntu

Instead of Intro

ThinkPad`s have been always famous for the amazing hardware compatibility with Linux. But seems this time has gone and owners of new ThinkPad`s like ThinkPad X230, T430 and of some other may have started experiencing some uncomfortable changes. The one of the such changes is inability to use tp_smapi module to set battery thresholds.

Battery charge threshold might be important for you if you want extend the battery's health. They are used to keep batteries partially charged.

I am as an owner of brand new ThinkPad x230 run into the impossibility to load tp_smapi module for my primary Debian (Testing) GNU/Linux as well as to set above mentioned thresholds. Here will be a safe workaround to fix the regression. It must work as well for Ubuntu Linux.

For the previous versions of ThinkPad`s it was simply enough to put desired integers to /sys/devices/platform/smapi/BAT{0,1}/{start,stop}_charge_thresh files to make these thresholds work. Currently there are no such special files anymore; since tp_acpi loading is failed. At least for the newest ThinkPad`s. Fortunately there is an alternative way: to set these values directly through the kernel's ACPI subsystem not ThinkPad brand controller's interface.

There is a module called acpi_call which was originally designed for easy switching video adapters in dual graphics environments. It provides a convenient interface for sending any command to ACPI subsystem; literally "call ACPI for some request". But which command to send to request a change of charge thresholds? Actually it does not matter because you should not do it by yourself. There is a special tool called tpacpi-bat (the part of tpbattstat-applet) which will do it for you.

Solution: all steps together

The only things we need to make ThinkPad`s charge thresholds work in Debian/Ubuntu are:
  1. Install acpi_call module;
  2. Install tpacpi_bat script;
  3. Configure thresholds setting on system boot-up;

acpi_call for Debian/Ubuntu

acpi_call is not included to standard Debian/Ubuntu repositories. The only way is to build it by yourself. Since I am a bit lazy about keeping in mind that with each kernel update I should rebuild acpi_call module I decided to write a simple script which will register and install it as a DKMS module.

The script could be retrieved from my git repository. The only requirement for running it is a root permission. If some packages required to build are missing you will be notified. Run it with 'run' argument and the script will do the following for you:
  • Retrieve acpi_call sources from the main git repository;
  • Register it as a DKMS module;
  • Install acpi_module to your Debian/Ubuntu system.

tpacpi_bat

tpacpi_bat is also not included to standard Debian/Ubuntu repositories. It could be grabbed from the author's git repository. The script depends on Perl only and could be put anywhere on the system, e.g. to /usr/local/bin.

Thresholds on boot-up

To make charge thresholds set on system boot-up:
  • acpi_call entry must be added to /etc/modules
  • The following commands must be added to /etc/rc.local:
/usr/local/tpacpi-bat -v startChargeThreshold 0 N
/usr/local/tpacpi-bat -v stopChargeThreshold 0 K

where N and K are integers in percent of full battery capacity.


Enjoy! Thanks to this ThinkPad's batteries might be a bit healthy :).

Thursday, June 23, 2011

actkbd package for Debian/Ubuntu

Recently I became an owner of Thinkpad X120E laptop produced by Lenovo. The computer was supplied with no pre-installed OS so I deployed (unexpected decision, huh!) Debian GNU/Linux there. This time I decided not to use desktop "ready-to-use-out-of-the-box" environments like Gnome or KDE and give a try to build a DE I want from bricks.

The one of the tasks I have faced with is how to make ThinkPad X120E hotkeys work in Debian GNU/Linux in a uniform way - to have a single keybindings entry point; which should work in VT w/o X.org also. Some of the keys (like VolUp, VolDown, Suspend etc) can be successfully handled through acpid daemon but the rest ones (say enable/disable microphone or switch touchpad/trackpoint) can be with xbindkeys (or similar) application only.

After a short research I found an amazing application called actkbd -- a keyboard shortcut X.org independent daemon. Thanks for being dependent on evdev Linux interface actkbd allows to handle ACPI events as well. But unfortunately there have been no ready-to-use Debian (Ubuntu) package available on the Internet (*).

(*) Of course I could install it using "configure && make && make install" way but I did not want to transform my Debian GNU/Linux installation to Slackware or kind of :).

Hence I made actkbd Debian/Ubuntu package by myself. So you can download here already built actkbd package for Debian Wheezy/i386 or build it by yourself (using dpkg-buildpackage). I am not so experienced in applications debianizing but seems it works well. Please feel free to use it or even to push to Debian/Ubuntu repositories.
Sources of debian/* files are to be shared soon through my git repository.

Sunday, May 1, 2011

Broken Java networking in Debian

Playing around with Java I ran into the problem well known as Bug #560044. Seems that the problem appears for Debian GNU/Linux only. The essence of the issue is: when you run any Java application that requires network access (by HTTP or by other protocol; it does not matter) you will (as well as the running application itself) receive the following error. Or a very similar one:

Exception in thread "main" java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)

This stack trace says nothing specific about occurred error except that a connection with a remote server cannot be established. The problem is at the bottom of explicitly set in Debian bindv6only kernel parameter. When it turned on (set to "1" in terms of sysctl) it means that network-requesting application will receive IPv6 socket by default not IPv4. To be able to use IPv4 socket an application should open it explicitly. Since some applications rely on the host system's settings it leads that they may fail while network access (details).

The solution is pretty easy: to disable explicit IPv6 binding in your Debian GNU/Linux. This can be done by the command execution:

echo 0 | sudo tee -a /proc/sys/net/ipv6/bindv6only 
This snippet will fix the problem for the current session only. To make the changes in Debian permanent the another one should be performed (proposed by Heikki Henriksen):
sudo sed -i 's/net.ipv6.bindv6only\ =\ 1/net.ipv6.bindv6only\ =\ 0/' /etc/sysctl.d/bindv6only.conf && sudo invoke-rc.d procps restart

After this fix (I believe that it is still a w/a) Java applications can have network access and not raise incomprehensible exceptions anymore.

Wednesday, June 2, 2010

APT suggests to remove (autoremove) required packages

After another packages update (or after my attempts to remove Evolution out from the system, I do not know exactly) on my Debian Squeeze, APT began to suggest me to remove 'non-required' packages using 'autoremove' option like this:

The following packages were automatically installed and are no longer required: totem-common libempathy-gtk28 libaprutil1-ldap vinagre odbcinst seahorse-plugins libgeoclue0 xdg-user-dirs gnome-user-share libgalago3 libtelepathy-farsight0 gconf-defaults-service guile-1.8-libs unixodbc
...
Use 'apt-get autoremove' to remove them.

It'd be Ok if packages to remove were really non-required for my system. But they ain't! W/o them my Gnome desktop would be definitely broken. Seems that something went wrong with 'Depends' field of some package.

This had been annoying me until I found a solution:

# apt-get install <list-of-packages-suggested-to-remove>

All above-mentioned packages were installed automatically due 'Depends' field of some (name it 'primary') very important package. Hence APT believes that it's Ok to remove them out when the primary package is purged. By explicitly using 'apt-get install' we tell APT that these packages ain't automatically installed anymore but manually. Pretty easy, yeah?

Alternative ways

  • Use 'aptitude unmarkauto' to mark packages manually installed;
  • Update /etc/apt/apt.conf with debug::pkgAutoRemove=false key to disable APT's autoremoving feature.
Enjoy.

Saturday, May 22, 2010

Twitter and my solution for Debian + Thinkpad issues

Having the latest Debian Squeeze (kernel 2.6.32) I got in some issues (hm... Seems that for some time I'm going to write about Debian and my Thinkpad only :)) with my laptop.

The common issues that I (and Google proves that not only my Thinkpad T410 run into them) had were:
  1. LCD brightness up/down doesn't work with loaded up ``thinkpad_acpi'' module; ``hotkeys'' module param does not help. Even ``acpi_listen'' does not show about corresponding events.
  2. On resume after suspend/hibernate USB goes to sleep or even become disabled;
  3. On resume after suspend/hibernate the system receives a kernel trace error with registers dump.
And I was playing around with them. But nothing really helps: seemed that the issues are more deeper than they look at first glance. These unanswered questions were blocking me from comfortable using of my device which I really like.

Meanwhile there was an announce about Linux 2.6.34 kernel with the fix of famous bug #12309...

So I decided to try it out but unfortunately there were (still are) no Debian packages with the latest kernel sources for Squeeze/Sid. Only vanilla kernel w/o corresponding Debian patches. But Debian Experimental already has it! So what we do:

  1. Download linux-kbuild-2.6.34 from http://ftp.de.debian.org/debian/pool/main/l/linux-kbuild-2.6/ and install it;
  2. Download linux-source-2.6.34 from http://ftp.de.debian.org/debian/pool/main/l/linux-2.6/ and install it;
  3. Go to /usr/src/ and extract .tar.gz with linux sources; then go to the newly created dir with the linux 2.6.34 sources;
  4. Copy current copy config (has a name like ``config-2.6.32-686'') from /boot as .config to the current directory;
  5. Build the kernel with 'make-kpkg' command as described in http://www.debian-administration.org/article/Building_your_own_v2.6.x_Kernel_in_the_Debian_manner.
You will be prompted to answer several questions about using new features (and devices support, of course) added to the new version of kernel. When this kind of survey is finished you can go to take some cups of coffee.


After booting the new Debian kernel I got that those Thinkpad issues became resolved for me.

P.S. BTW, I finally decided to start my personal twitter. Sometimes I have a lot ideas and thoughts I want to share but they ain't so big or not so significant or even I do not have enough time to make standalone posts about them. Hence such 'dumps' are go to my twitter; I hope they are useful and interesting.


Thursday, May 20, 2010

Debian Lenny + Thinkpad T410: network adapter issue

Since I chose Debian to be my primary and favorite Linux distribution on my new Lenovo Thinkpad T410, I agreed to myself to spend my time to solve various specific issues related to it.

So the first issue I met was that the Debian Lenny installation system didn't manage to find my Thinkpad's Intel 1000 ethernet adapter. Google 'said' that appropriate driver for the adapter was 'e1000e'. Manual 'e1000e' module loading (through 'modprobe' on another virtual console) didn't help: seems the driver is slight outdated and doesn't support newer Intel's network adapter.

The solution is simple: to use an alternative disk image made by Kenshi Muto to install Debian Lenny. This ISO can be downloaded from http://kmuto.jp/debian/d-i/.
Thankfully to the latest version of kernel, Debian installation system will detect Thinkpad's network adapter and the user will be able to continue installation from Internet not from CD/DVD only.

Or there is an alternative way: to compile the latest version of Intel's driver and load it from USB-stick during the installation.