Arch on Asus EEE 901

inf · 2009-02-19 14:28:53

Robertek has been "M.I.A" for a long time and his pages are also down so don't think you can get the headers etc from anywhere.

Also I would suggest using your own kernel (there are couple in AUR (blinds f.ex)) and configs are also available.

orange · 2009-02-19 14:48:01

Robertek has been "M.I.A" for a long time and his pages are also down so don't think you can get the headers etc from anywhere.

That's what I was worried about. I opted for Robertek's solution so far as Blind's AUR isn't that perfectly documented unfortunately. So, Robertek's kernel is more or less unmaintained? Do you have any experiences with Blind's kernel? Does it offer exactely the same functionality? I'm especially curious about eee-control, acpi-eeepc-generic and/or buttons-eee901. As far as I understood Robertek's acpi-eee supported everything out of the box. Hm, I guess I need to learn a bit more about the AUR. I'm not a new Linux user but honestly an Arch "greenhorn"

Any recommendation for the acpi-eee questions?
Does Blind's kernel offer headers? I mean does makepkg result in kernel, kernel-source and kernel-header packages when building from source?

I hope these questions are not too stupid for you hardcore archers.

Thanks in advance

big_gie · 2009-02-19 15:02:20

Blind's kernel is a vanilla 2.6.29-rc? while Robertek applied the zen patch set. Also if it's unmaintained, its probably not at .29 at all... Blind's also including some staging drivers I think.
Blind's kernel is mainly everything built-in instead of modules, and the rest not compiled at all.
I wanted to create a wiki page with kernel options for the eee series, but did not have time yet.

Blind · 2009-02-19 15:03:46

It works perfectly with eee-control, I hear - everything should work out of the box.
Also check out acpi-eeepc-generic with acpid-ted1 for that kernel. That is the future.
In case you want to get your hand a bit dirty, then you can try buttons-eee901 (and help me with that package).
If you run into problems, people are always here to help

I took out the headers part because they would conflict with the stock ones. I could create a package for that, though, if you really needed it.

Last but not least, AUR is (one of) the biggest pros of Arch, it's easy to use, so getting acquainted with it is really worth it!

@lejonet: Did you change anything in /etc/PolicyKit/PolicyKit.conf? If not, then you will probably have to...also check .pacnew files etc.

lejonet · 2009-02-19 15:18:58

@Blind
No I haven't changed any hal policies except adding one for the touchpad and keymapping. Ill look into that, is kindof annoying that it broke just because I did a system upgrade But then, what would a toy be without tinkering?
I'll get back to you when i've gotten the time to try this.

big_gie · 2009-02-19 15:30:42

orange wrote:

I'm especially curious about eee-control, acpi-eeepc-generic and/or buttons-eee901. As far as I understood Robertek's acpi-eee supported everything out of the box.

I forgot to add... acpi-eee-generic needs acpid. So it should not depend on the kernel you have. BUT, acpid does depend on the kernel you have. For the moment, acpid depends on a deprecated kernel feature (mainly /proc/acpi/events). Blind's kernel does not include this (its a depracated feature, it should not be used anymore...) so Arch's stock acpid will not work with Blind's kernel.
The future, as Blind states, is the netlink interface. It is already in most kernels. So you need an acpid package supporting netlink. The authors have provided an updated version which supports netlink.
More info for this on AUR: http://aur.archlinux.org/packages.php?ID=23827

With that, acpid works, so acpi-eee-generic will work

orange · 2009-02-19 18:40:53

Thanks a lot for all the explanations - very friendly community

I read the dedicated thread about acpi-eee-generic by big_gie and it outlines that it works with the stock arch kernel as well. Thus I'm wondering why I should use Blind's kernel in the AUR at all?

I mean, if I haven't missed anything really important, acpi-eee-generic works with stock acpid and kernel. For Blind's kernel I'd need to replace(?) acpid with acpid-ted1 to make it work. Still in the loop?

So what is the ultimate advantage not to use the stock kernel if all toggle, special keys and so on work with the stock kernel and acpi-eee-generic and stock acpid anyway?

@Blind: I'm pretty sure you'll be able to explain the advantages Thus headers for your kernel would be indeed highly appreciated. Not only for me though, I guess some other community members would be interested to replace the ralink adapter as well. Assumed they prefer aircrack-ng over wireless n. Or is it a wrong assumption that one urgently needs the headers to build madwifi-ng? I'm used to that procedure from other distros at least.

Blind · 2009-02-19 19:08:34

Hehehe

Alright, here is my explanation. With my kernel in AUR
1. you do not have to worry about the rt2860 wifi driver anymore (but you want to replace it anyways), and
2. only the drivers and modules for the Eee PC 901/1000 are compiled, saving you space in both RAM and SSD, as well as boot time

You got that right, that you would need to replace acpid with big_gie's acpid-ted1 using my kernel in AUR. At some point in the near future, as explained, this will be the standard anyways - you would just be on the the more bloody side of the bleeding edge for some time.

However, to sum it up, looking at your case, I think you could indeed live with the stock kernel and acpi-eeepc-generic - it would definitely make life a bit easier for you with the madwifi thingy (I don't know anything about it, it seems likely though that you need the kernel-headers).

But you wouldn't have all the fun, right?

orange · 2009-02-19 19:38:20

Great, I think losing a bit ssd/ram space and boot time is worth it. I mean arch is anyway the fastest distro I've ever seen. The rt2860 support is indeed great, but (as you said) not a requirement for me. I just need to wait for the arrival of my recently ordered ar5007eg atheros wireless card now.

For your better understanding, what I need to do (kernel headers) is the following:
http://www.aircrack-ng.org/doku.php?id=madwifi-ng

But you wouldn't have all the fun, right?

That's true, but maybe I'll have even more fun with the atheros card

Last edited by orange (2009-02-19 19:39:05)

inf · 2009-02-19 21:24:55

How can i get to menuconfig / xconfig while building the kernel from aur. I tried to edit the pkgbuild but it doesn't effect on anything

lejonet · 2009-02-19 22:26:08

@Orange

I have a AR5008 atheros based card in my eeepc 901, but then I am using my own compiled kernel. Remember that if you want to replace the ath5k or ath9k driver your kernel must be built with the mac80211 and cfg80211 as modules, or you wont be able to compile the madwifi drivers for it.
I haven't gotten acpi to really work with my custom kernel, but I am going to give the netlink interface acpid package a try, I have indeed taken away /proc/acpi/event feature in my kernel.

@Blind
I dont understand what it is that I am supposed to change. The error dbus is giving seems like it doesn't like text in its configuration file, but that is kinda contradicting?
I checked /etc/PolicyKit/PolicyKit.conf and it was basically blank, which I guess is default. There were no policies defined in it.

Last edited by lejonet (2009-02-19 23:07:00)

Blind · 2009-02-20 14:20:55

@inf: there is a line in the PKGBUILD

  ####################
  # stop here
  # this is useful to configure the kernel
  #msg "Stopping build"
  #return 1
  ####################

(return 1) should do the trick. I usually stop the build after the configure step (you can see it start the compile process) with ctrl-c, and then cd into the src/linux-2.6.XX dir, to run make menuconfig by hand.

@lejonet: Mmh, I just read your post up there again. It seems like you there is a broken config file (for dbus). This would likely be one that you created (sorry), and thus located in /etc/dbus-1/ ?
Since when did you say it was broken? After my kernel upgrade, or after the dbus or hal upgrade?

After the HAL upgrade, to mount things, I had to change /etc/PolicyKit/PolicyKit.conf according to the HAL wiki page, but that only affected automounting of USB sticks and the like.
There are (maybe too) many things that can go wrong...nevertheless, I assume a borked dbus (or HAL) config...maybe reinstalling of dbus helps?

I don't know if this helps

Etuxia · 2009-02-20 18:17:01

I got a new battery for my EeePC from Asus, they took my computer installed windows and run tests and gave it back to we with windows.

Now Im dreaming for a monster batery: http://www.dealextreme.com/details.dx/sku.17081

lejonet · 2009-02-21 01:00:52

@blind
It has nothing to do with ur kernel, I run with my own custom kernel, but it broke AFTER the system update which updated hal and dbus. And yeah it seems like there is something wrong with the dbus config, but I haven't changed a single thing in there before the update...

Blind · 2009-02-21 07:55:56

Check out the recent messages in AUR regarding the 2GB - you will have to slightly modify the config.

big_gie's package uses libnotify for OSD, afaik. If you want FSB changing, you may want to install eee-control. All of that should work out of the box with that kernel.
The kernel in AUR is substentially different from zeneee. It is a complete vanilla kernel, but with all drivers for the EeePC 901/1000. No non-kernel drivers needed, but also no non-vanilla patches - that would be much too complicated for my simple mind...

Last edited by Blind (2009-02-21 07:56:47)

D-Locked · 2009-02-21 10:37:38

Blind wrote:

big_gie's package uses libnotify for OSD, afaik. If you want FSB changing, you may want to install eee-control. All of that should work out of the box with that kernel.

The "Performance" option in eee-control's tray menu is greyed out for me. Do you know what might be the cause for this?
I have your kernel and acpid-ted1 installed.

Last edited by D-Locked (2009-02-21 10:41:53)

lejonet · 2009-02-21 15:36:41

After sitting searching around on my eeepc and the net I haven't found any thread anywhere that have the same problem as me, I find alot of people that have had problems with automounting etc after hal 0.5.11-7 upgrade and then I noticed something with my eeepc, slim is also broken...
I am getting the "INIT: id "x" respawning too fast" whenever I restart into graphical mode (init 5 for me).
I use inittab for going directly to graphical environment, could it be related?

I am considering just reinstalling everything with the 2009.02 usb image, Ive made quite a mess in the system before anyways, might be a idea to do a clean restart?

Edit:

After using dbus-daemon command in the CLI I've established that there is some configurational problem with my /etc/dbus-1/system.conf, the weird thing tho is that I haven't changed a single thing before the upgrade and now after the upgrade the only thing i've done is to make sure all the comment are as one long line instead, cuz I thought it might be a syntax problem...
This is really getting me annoyed over hal >.< I cannot use my eeepc at all atm...

Last edited by lejonet (2009-02-21 15:48:29)

big_gie · 2009-02-26 18:27:46

The /proc/eee is provided by an unsupported kernel module (i think it's asus' acpi-eee or something like that...). That feature is not present in the in-kernel module eeepc-laptop which should replace the old driver.

chori · 2009-02-26 18:51:48

Etuxia wrote:

I got a new battery for my EeePC from Asus, they took my computer installed windows and run tests and gave it back to we with windows.
Now Im dreaming for a monster batery: http://www.dealextreme.com/details.dx/sku.17081

Ok, I've been quiet recently (no issues with my eee901, but still running the old zeneee kernel).

I bought one of those 12000 batteries for my 901 shortly before Christmas... I was stuck on a plane in late December for 10 hours , and the battery drained down to 23% as I watched movie after movie. Needless to say, I'm very pleased.

chori · 2009-02-26 18:59:18

Two considerations have kept me from moving off the zeneee kernel:

1) the /proc/eee FSB kernel module is much faster at changing state than the cpufreq utils, noticeably so. Not a big deal, but still.

2) last I checked, no other ArchLinux kernel had the bluetooth toggle patch compiled in. Is this still the case?

(Three considerations, really: I'm lazy, and don't feel like rebuilding a system that is now humming along smoothly to my specifications.)

Reasons I'm thinking of changing:

1) Robertek's kernel may not be maintained going forward

2) All the functionality I want, plus much more, is now (probably) distributed in the vanilla kernel.

If anyone's interested, I still have the source for the zeneee kernel (.27 release); I can make it available if anyone is willing to host it, and I could create a kernel-headers package for it.

Edit: okay, I was confused. I tested the eee.ko module against cpufreq to change FSB, it was cpufreq that was so slow. I need to reread my own posts in this thread.

Last edited by chori (2009-02-26 23:01:45)

Blind · 2009-02-26 21:25:59

Hi,

well, everybody can chose their own poison

With the kernel in AUR, which is a vanilla kernel that only has a patch for the staging drivers (that are also developed in-kernel but not deemed to be 'good enough' for the linux kernel standards, but slowly getting there), all the drives for an Eee PC 901/1000 are there. I am not using the eee-control program because of all its gnome dependencies (I am using LXDE), thus I cannot say anything about the FSB changing.
Let me restate that again: that kernel does not use ANY patches beyond the patches for the staging drivers, that are maintained by kernel dev gregkh on kernel.org.

Obviously, not too far in the future, all this functionality will become available in Arch's stock kernel. Until then, I believe I will actively maintain that kernel.

I am not sure about this, but if you really want the FSB changing, you can try and build the eee-module yourself for whichever kernel you would like. Looking at the source of the in kernel module for the eee, it is like big_gie says: I dont think there is support for that.

But it doesn't say anything in the requirements of eee-control about it. No clue, guys!

Cheers,
Blind

chori · 2009-02-26 23:10:12

Looks like eee-control requires either eeepc_acpi or eeepc_laptop kernel modules, which supplant the original eee kernel module (which is the one distributed in the zeneee901 kernel). eeepc_laptop is included in linux kernel versions 2.6.27+ (but may need to be enabled). I haven't tested either of these modules out.

Some web browsing also suggests that not all of the bugs are worked out of the eeepc_laptop module yet, though it's close to stable.

chori · 2009-02-26 23:14:25

Blind wrote:

Hi,
well, everybody can chose their own poison
With the kernel in AUR, which is a vanilla kernel that only has a patch for the staging drivers (that are also developed in-kernel but not deemed to be 'good enough' for the linux kernel standards, but slowly getting there), all the drives for an Eee PC 901/1000 are there. I am not using the eee-control program because of all its gnome dependencies (I am using LXDE), thus I cannot say anything about the FSB changing.
Let me restate that again: that kernel does not use ANY patches beyond the patches for the staging drivers, that are maintained by kernel dev gregkh on kernel.org.
Obviously, not too far in the future, all this functionality will become available in Arch's stock kernel. Until then, I believe I will actively maintain that kernel.
I am not sure about this, but if you really want the FSB changing, you can try and build the eee-module yourself for whichever kernel you would like. Looking at the source of the in kernel module for the eee, it is like big_gie says: I dont think there is support for that.
But it doesn't say anything in the requirements of eee-control about it. No clue, guys!
Cheers,
Blind

Thanks for clarifying the state of the current vanilla kernel, @Blind, vis-a-vis your patched kernel. I'll wait for the vanilla kernel to catch up, since I have a working system right now.

lejonet · 2009-02-26 23:16:24

kernevil wrote:

Hi Blind,
this is my first post in the arch forums After trying lots of distributions in the last year i think that Arch fits all my needs and i'm very happy with it.
I have installed your kernel in a eee 901 and after enabling the event acpi interface it works great with acpi-eeepc-generic, but i haven't found how to control the fsb. With robertek kernel using /proc/eee/fsb and all devices disabled powertop report 5.9W, but with your kernel it goes up to 8W. Is there any patch for eeepc-laptop to control this?
Also is there WPA2 enterprise support (for eduroam) in the rt2860 module? And is there any way of control the power of the wifi card? I think that it takes too much power (up to 2W)...
Thanks

Eduroam works perfectly fine if you use the drivers supplied with either blinds kernel or the old zeneee kernel. I have eduroam at the university that I am studying at and it works like a charm. I believe its called WPA2-TLS in wicd if you use that.

big_gie · 2009-02-26 23:24:48

I checked the eee-control source and it controls directly the FSB without eee* kernel module. From the source (ichsmbus.py):
# This module implements user-space access to the i801 compatible SMBus
# controllers found on all recent Intel chipsets.
# Only what is needed for eee-control so far, e.g. block transfers, are
# supported.

Arch Linux

#1001 2009-02-19 14:28:53

Re: Arch on Asus EEE 901

#1002 2009-02-19 14:48:01

Re: Arch on Asus EEE 901

#1003 2009-02-19 15:02:20

Re: Arch on Asus EEE 901

#1004 2009-02-19 15:03:46

Re: Arch on Asus EEE 901

#1005 2009-02-19 15:18:58

Re: Arch on Asus EEE 901

#1006 2009-02-19 15:30:42

Re: Arch on Asus EEE 901

#1007 2009-02-19 18:40:53

Re: Arch on Asus EEE 901

#1008 2009-02-19 19:08:34

Re: Arch on Asus EEE 901

#1009 2009-02-19 19:38:20

Re: Arch on Asus EEE 901

#1010 2009-02-19 21:24:55

Re: Arch on Asus EEE 901

#1011 2009-02-19 22:26:08

Re: Arch on Asus EEE 901

#1012 2009-02-20 14:20:55

Re: Arch on Asus EEE 901

#1013 2009-02-20 18:17:01

Re: Arch on Asus EEE 901

#1014 2009-02-21 01:00:52

Re: Arch on Asus EEE 901

#1015 2009-02-21 07:55:56

Re: Arch on Asus EEE 901

#1016 2009-02-21 10:37:38

Re: Arch on Asus EEE 901

#1017 2009-02-21 15:36:41

Re: Arch on Asus EEE 901

#1018 2009-02-26 18:27:46

Re: Arch on Asus EEE 901

#1019 2009-02-26 18:51:48

Re: Arch on Asus EEE 901

#1020 2009-02-26 18:59:18

Re: Arch on Asus EEE 901

#1021 2009-02-26 21:25:59

Re: Arch on Asus EEE 901

#1022 2009-02-26 23:10:12

Re: Arch on Asus EEE 901

#1023 2009-02-26 23:14:25

Re: Arch on Asus EEE 901

#1024 2009-02-26 23:16:24

Re: Arch on Asus EEE 901

#1025 2009-02-26 23:24:48

Re: Arch on Asus EEE 901

Board footer