Debian on the ASUS EeePC 1015B

A picture of the ASUS EeePC 1015B, white.
I recently acquired an ASUS EeePC 1015B, and here is a summary of what I went through for Debian to run smoothly on it.

This is still a "work in progress", so stay tuned.

The ASUS EeePC 1015B

Some technical details on this EeePC worth knowing: All characteristics are on the ASUS website.


Debian is my preferred Linux distribution (even if I have learned to like Ubuntu a lot, recently).

I went for the amd64 flavour of Debian 6, squeeze, and then upgraded to testing.

Recommended Kernel

I recommend that you upgrade to kernel 2.6.39 (from unstable).

You need at least kernel 2.6.38 (and its radeon module) for the text console to have its optimal resolution. I was using uvesafb and v86d as a workaround (with vbemode=276) but that was not optimal.


The brcmsmac module works fine with kernel 2.6.39. You only need to install brcm80211-firmware. See the wiki for details.

My first attempt was to install the broadcom-sta (wl) proprietary driver, but it kept disconnecting from times to times no matter the kernel version.

"Kill" button

I think the "on/off" button effectively kills the radio, even though the LED remains on. This is what dmesg shows at least. It seems I need to restart the i/f manually when I use the button to enable radio again. I need to retry this one.

"Progressive" LED

Articles on the web talk about a "progressive" LED, which dims or lights depending on the signal strength. I have nothing like that working for now.

Power management

I am not completely done with PM, yet. powertop reports that some "tunables" are not optimal by default.


Provided you insert powernow-k8 manually, as of kernel 2.6.39 cpufreq works fine with the C-50. Two frequencies are dynamically used: 800 MHz and 1GHz. You may want to add a line to your /etc/modules.


The acpi -b command seems to work fine and report the current battery charge (through BIOS?) The battery-stats-collector util does not work, though.

EeePC ACPI scripts

There is an eeepc-acpi-scripts package, which seems to be doing good to my EeePC. It "repaired" the HDA audio power management, which was busy 100% of the time before (as reported by powertop). I wonder if this did not have an effect on the HDD led as well :)

Suspend on LID close and hibernate

LID closed is well detected and it is possible to ask acpi-support to suspend in this case. This can be configured in /etc/default/acpi-support.

Hibernate works as well with pm-hibernate.


It is possible to "tweak" the CPU voltages, to spare even more power. This is a "dangerous" process, as undervolting too much will make your APU unstable. I therefore recommend to test stability with a combination of memtester, burnK7, x11perf and a GL application of your choice such as e.g. atlantis (from xscreensaver).

Undervolting the APU can be done under Linux with the undervolt program. See this forum thread for more details.

Settings seem to be applied on a P state transition only. Testing P0 is fairly easy, as the cpufreq governor will do the necessary P0-P1-P0 transition for you if you stop and restart your "load" programs. However, to test P1 you will need to set the governors to userspace and force the P1-P0-P1 transitions with cpufreq-set by doing something like:

for c in 0 1; do
  cpufreq-set -c $c -f 1000000
  cpufreq-set -c $c -f 800000

Here are my findings so far after some quick tests:

P state Default VID Lowest safe VID Errors VID Lockups VID
P0 0x1F 0x35 0x36 0x37
P1 0x2E 0x3B 0x3C 0x3D

Notice how the safe/errors/lockup VIDs are close from each other. I have run overnight with no issue, and I am now running with the lowest VIDs I found, +1 margin.


I did a patch against undervolt, to add frequency support. This allowed me to play a bit and discover that downclocking is indeed possible. From this point, cpufreq-info will not show you the real frequencies any more and you will need to use e.g. xaos -speedtest to be able to measure the effects of your changes.

For some reason, underclocking prevents dynamic frequency scaling to happen correctly in almost all the cases. However, when underclocking P1 by only 0.25x, the DFS still works ok. This allows to lower the VID by one step, too.

Just for fun, I tried with divider set to 10 (which would be 400 MHz):

P state Default VID Lowest safe VID Errors VID Lockups VID
P1 (div 10) 0x2E 0x46 0x47 0x48


Graphics under Xorg are working "out of the box" with testing. The radeon is recognized and mesa is accelerated, using Gallium (this is an "evergreen" chipset after all).

I think I saw some artifacts while trying openarena, though. I need to retry some day.


Speakers work fine with ALSA, provided you select the correct card. This can be done in your .asoundrc:
 pcm.!default {
     type hw
     card 1

 ctl.!default {
     type hw
     card 1
See the ALSA FAQ for details.

Sound switches to the headphones when inserted.

Dedicated packages archive

A dedicated packages repository for EeePC is available:
  deb http://eeepc.debian.net/debian sid main contrib non-free
It seems all packages there are already available in testing, and especially eeepc-acpi-scripts.

Windows refund

There is a law in France, which mentions that in theory hardware and software cannot be sold "bound". In practice, it is not always easy to obtain a refund for the windows license that comes "bundled" with almost every laptop.

I chose the EeePC from ASUS partly because some reported on the internet that it was actually possible to obtain a refund of the Windows license. See this (French) site.

I sent an e-mail to the French support through the ASUS website and rapidly received an e-mail with up-to-date form to complete, which I returned.

This is not finished yet, but all I can say is that ASUS has been very responsive so far.

Remaining issues

Not tested yet

...but I'd like to, some day.

Related links

Copyright © 2011 Vincent Stehlé ( vincent.stehle@free.fr).
GNU Free Documentation License 1.2