Arch on Asus EEE 901

bleichmittel · 2009-03-09 09:54:08

Blind wrote:

@bleichmittel: mmmh...dunno, maybe we should compile it in the kernel? Motion to do so?

Compiled eeepc_laptop into the kernel. Now booting takes longer before loading modules (even before udev is starting). So I guess the Kernel takes longer to load now!?

Blind · 2009-03-09 15:10:40

Yeah, I have the same experience. I guess it is either slow boot or slow module loading via udev.
The next thing to try might be compiling pciehp aas module, and then append the line to /etc/modules.conf as big_gie suggested. I seem to remember I did that before, and it didnt help...oh well.

tyranny12 · 2009-03-12 03:30:23

I've been having issues getting WPA2 to work over my the RT2860 on my Eee 901. I'm running Blind's custom kernel (2.6.29rc7) at the moment, but I had this issue using stock as well, even when I was running with the patched version that explicitly builds in WPA_SUPPLICANT (re: the rt2860 AUR.)

The wireless connects fine to non-authenticated networks. I don't have other encrypted wireless networks to test. My tests have been with networkmanager (not on Blind's kernel,) wicd, and with direct wpa_supplicant authentication. wpa_supplicant attempts to authenticate (pre-association) to my AP, and then times out.

Anyone have any experience with this? I'm wondering if it's not related the string of dbus/consolekit configurations that seem built in to the latest packages.

---------------

Incidentally, that reminds me - I don't have the solution on hand, but I read all over the place about Bluetooth pairing issues with the latest bluez, and with arch, and with eees. I solved mine - once I have my eee with me tomorrow I'll dig through my browser history and post the resolution. In short, it was ConsoleKit missing a file for slim.

JazzplayerL9 · 2009-03-12 07:03:14

@tyranny12,

Yeah I have the same problem using anything other than the zen-eee901 kernel. Luckily my university has two wireless networks...one for "secure" access and the other for open web-only access. I can access the "secure" stuff from web-only through SSH...so it doesn't bother me too much. I'd like to see what is causing it though...alas, no time to try.

tyranny12 · 2009-03-13 15:15:35

Ok, now I'm annoyed. I'm on my Eee now, and the Bluetooth fix that I applied obviously wasn't it, as I typoed the solution. Oh well, I will list the sum total of how I got bluetooth-applet working. I also don't have the right link for the earlier stuff,

Bluez wasn't working. As we know, passkey-agent is deprecated. I grabbed the 'simple test' scripts available from the bluez maintainers (referenced in the bluetooth discussions in BBS.) I used that to set up a pair with my mouse, but it still would time out. At this point I had long given up on the GUI tools working.

I installed bluetooth 4.32.1 from the archlinux bugs section. No change.

Googling, I found dbus-send commands used in this scenario. They also failed, so I won't replicate them here. I did however grant my user bluetooth permissions in dbus. I don't know if this is necessary anymore.

<!-- This configuration file specifies the required security policies
     for Bluetooth core daemon to work. -->

<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>

  <!-- ../system.conf have denied everything, so we just punch some holes -->

  <policy user="root">
    <allow own="org.bluez"/>
    <allow send_destination="org.bluez"/>
    <allow send_interface="org.bluez.Agent"/>
  </policy>

  <policy user="YOURUSERNAMEHERE">
    <allow own="org.bluez"/>
    <allow send_destination="org.bluez"/>
    <allow send_interface="org.bluez.Agent"/>
  </policy>

  <policy at_console="true">
    <allow send_destination="org.bluez"/>
  </policy>

  <policy context="default">
    <deny send_destination="org.bluez"/>
  </policy>

</busconfig>

Finally, I set HIDD_ENABLE to true in /etc/conf.d/bluetooth, and added the line below to the 'slim' file in /etc/pam.d I had to create the 'slim' file.

session optional pam_ck_connector.so

And now bluetooth works like magic, even from the bluetooth-applet (which wouldn't start before I created the 'slim' file.

Last edited by tyranny12 (2009-03-13 15:16:16)

Blind · 2009-03-13 18:13:37

Hi,

in the begining, I had trouble with wpa_supplicant as well. I stopped using networmanager or any of that like.
Here are the settings with which I got it to work consistently with a simple wpa_supplicant.conf file.

ctrl_interface=/var/run/wpa_supplicant
# change ap_scan to 2 if running into problems
ap_scan=1
fast_reauth=1
eapol_version=1

network={
  key_mgmt=NONE
}

network={
  ssid="WLAN"
  scan_ssid=1
  proto=WPA
  key_mgmt=WPA-PSK
  pairwise=TKIP
  group=TKIP
  #psk="STRINGPASSWORD"
  psk=HEXPASSWORD
}

Maybe that helps.
About bluetooth: did you start the bluetooth daemon? Bluetooth works just fine here.

tyranny12 · 2009-03-14 14:25:50

@Blind

Thanks - I'll give that wpa_supplicant.conf a try. And yes, the bluetooth daemon was running - I'd read your AUR thread already and seen that a few people had missed that. I've had a lot of problems with dbus and other permission based issues on this config, which I suspect are coming from the 'newer' config files I've had from the fresh install.

The bluez issues I mentioned are actually widespread across the net so I wanted to post what worked for me here. For the record, even when I couldn't pair, I could scan for devices and see them, and try to connect, so the daemon was functional in the background.

Blind · 2009-03-14 16:33:12

@tyranny12:

Let me know if wpa_supplicant worked for you - also, there is also a dbus rule in /etc/dbus-1/ that looks suspicious...

About the bluetooth: sorry, I guess I didn't totally read your post

I think ever since we moved to this HAL/PolicyKit thing, people have been trouble with it. Now the situation has changed again with the permissive/non-permissive dbus?
To be honest I am starting to lose track of all that stuff - it is just getting too damn confusing. Maybe one of the devs could come up with a nice wiki page explaining the details of DBUS, HAL and how it works with PolicyKit, when/where ConsoleKit comes in (what it does?), and what is to be expected in the future with DeviceKit. I think a really well documented wiki would clear up a LOT of the confusion that goes around (and be unique to the web, for that matter). Also, it would be nice to know the locations of what to change where if something doesnt work. I know of at least 3 places where you can change stuff and try to make things work
/etc/PolicyKit/
/etc/dbus-1/system.d/
/etc/hal/...
When I try to fix something, I NEVER know if I am touching things in the right place...

Blind · 2009-03-14 21:41:51

@tyranny12:
I guess I was wrong all the way. While WPA_SUPPLICANT is enabled in the kernel driver, there is more to the whole story. Here is an explanation and some hope for the rc8 staging patches:

Staging: rt2860: Ported v1.7.1.1 changes into v1.8.0.0, becoming v1.8.1.1

When RaLink released rt2860 v1.7.0.0, it lacked proper support for both WEP
and WPA/WPA2 encryption. Either was possible, but the module had to be
compiled to support only one or the other, never both.

Since the EeePC was the most common device with this hardware (and these
users were complaining to RaLink that WPA/WPA2 encryption didn't work)
RaLink released a fix as an "eeepc-specific" version of this driver, v1.7.1.1

Unfortunately, when v1.8.0.0 was released, this WPA/WPA2 fix was never
included.

What complicates things further is that RaLink has no interest in
continuing work on this Linux driver for their hardware.

This commit ports the changes introduced in v1.7.1.1 into the v1.8.0.0
release, upgrading the kernel's module to v1.8.1.1

Signed-off-by: Adam McDaniel <adam@array.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

So, while Ralink is obviously a Linux unfriendly company, the patched staging driver will hopfully do it all. I am talking about the gregkh patches, as those have not been included in the mainline rc8. So I will wait for gregkh to update his patches to rc8 and the release the PKG in AUR.

tyranny12 · 2009-03-14 22:13:29

@Blind
Fun. That explains all the difficultly.

However, I took some settings from your wpa_supplicant.conf and my existing attempts, and I got something that works!

Now I'm trying to convince WICD to use settings like this. Failing that I'll glance at NM.

ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
fast_reauth=1
eapol_version=1

#network={
#    key_mgmt=NONE
#}

network={
    ssid="NAME"
    scan_ssid=1
#    proto=RSN
    proto=WPA RSN
    key_mgmt=WPA-PSK
#    pairwise=CCMP TKIP
#    group=CCMP TKIP 
    pairwise=TKIP
    group=TKIP
    psk="PSKWASHERE"
#    psk=CALCULATEDPSKWASHERE
}

tyranny12 · 2009-03-14 23:00:21

After finding out that NetworkManager is even less easy to customize than WICD, I'm sticking with my WICD for when I'm out and my direct wpa_supplicancy for home. I'll wait till rc8 before I try to make WICD/NM work automagically - no point in fixing it now when the new patch may break my efforts.

Blind · 2009-03-15 03:15:11

I sure do hope that it's going to work - I assume gregkh will update his patches to rc8 on Monday or Tuesday next week.
I am certainly very curious myself - I have worked with wicd a while ago, but it seemed resource hoggy. I heard they changed that with some newer release.
Right now I am using my own scripts to connect - works ok, too (e.g. the first rule that you commented out connects automatically to the strongest, open AP).

tyranny12 · 2009-03-16 16:21:59

Yea, I commented it out because there are a plethora of APs in London that are 'open' but are for subscribers/pay only. I'd never get to the proper SSIDs if I left that rule in. I can't even connect to my home network if I leave it there, so I just use wpa_supplicant for my home network and WICD for the open networks.

Blind · 2009-03-17 13:40:00

Ah, well, that makes sense
Ok, I updated the package just now - good luck with your experiments!

tyranny12 · 2009-03-17 22:07:47

Time to play - I'll update once I've tested. (;

tyranny12 · 2009-03-18 00:01:51

When I came home the kernel was built - installed it, restarted and boom - WICD likes my wireless network with no problems. (;

---

Regarding the PPP modems they keep talking about in your AUR thread, I'm going to probably upgrade my mobile contract to get one for some new developments. If I do I'll try to help you with the modules marco_eeepc is talking about.

Blind · 2009-03-18 02:03:51

Yay on the wifi

Well, I hope we have it figured out now. I'll update the config soon. Took some of my nerves, but...

zaibach · 2009-03-29 20:02:41

Anyone managed to get the touchpad working properly under Blind's kernel?
I'm unable to make it work as smooth as it works under the zenee kernel with the same config.

Blind · 2009-03-30 18:01:18

I can post my config tonight, which works reasonably well.
A lot has changed since zeneee, so I am not surprised that your config does not work the same way.

Anyways, I also want to mention that there seems to be a kernel patch for the synaptics/elantech driver out there. I am not certain, whether I want to include that at this point, but there seems to be a motion to include that patch in the mainstream kernel anyways. We shall see.

zaibach · 2009-03-30 19:32:04

No worries, the fact is that i already have to digest the hal/fdi thingie from newer Xorgs. Ty Blind.

chori · 2009-04-02 13:44:12

This is probably not the appropriate thread for this post, but I thought it was an interesting article on the next generation of netbooks:

http://www.nytimes.com/2009/04/02/techn … books.html

Sigh. Already my eee901 feels antiquated, and I've only had it for six months.

Lazer · 2009-04-02 14:20:48

Actually it's not antiquated at all, I have yet to find a better netbook than this. Soon a lot of netbooks with the GS45 graphic chip will arrive, which drains less power and provides better performance but... good luck in getting linux to work with one of those! The only annoying thing is the EXTREMELY slow 16GB SDD, I am seriously thinking of replacing it...
BTW, more on topic, I have still no luck with testing xorg and UXA, even with the Blind's .29 kernel. X keeps crashing after a few seconds. If I recompile the kernel with KMS support it will crash less (sometimes it will, especially with 3D apps or composite enabled) but the screen seem to display 16 bit colors (even though the log clearly says 24) and I am unable to switch VTs. Not to mention that the framebuffer is not actually working (I don't see any resolution change in the terminal). It is such a mess! Anyone managed to get it working?

zodmaner · 2009-04-02 15:42:38

For anyone interested, I've made (yet another) customized kernel for Eee PC model 901.

There are two packages to choose from: kernel-eee901 and kernel-eee901-kms.

* The kernel-eee901 package contains all the necessary drivers/modules for ASUS Eee PC model 901.
* The kernel-eee901-kms is, as the name implies, contains KMS module. The KMS module is built into the kernel itself, so you don't have to worry about loading it. Aside from KMS module, this package is no different from kernel-eee901.

I try to keep my kernel lean and mean, so that means:

* Only include essential modules to get all the hardwares working.
* Almost all of the modules gets built into the kernel itself, so it should be fast and small.
* No need for initramfs image to boot, since all the essential modules are built into the kernel.

Basically, if you have ever used toofishes' kernel for Eee PC model 701, which I used as a template and inspiration, then you know what to expect.

You can download pre-complied packages from my GitHub's page here:
* kernel-eee901: kernel-eee901-2.6.29-1-i686.pkg.tar.gz
* kernel-eee901-kms: kernel-eee901-kms-2.6.29-1-i686.pkg.tar.gz

Install them just as you would install normal Arch Linux's package (# pacman -U kernel-eee901-2.6.29-1-i686.pkg.tar.gz, for example).

PKGBUILD for both packages can be download or clone from my public repository here.

A word of warning about KMS though, if you're using KMS enabled kernel, make sure to use UXA or else the system will hard lock when it tries to start X (trust me, I've learn this the hard way ).

For more information, such as detail installation instructions, etc., please checkout the project wiki page here.

Hope these packages will be of use to you guys.

Also, credit where credit is due: I couldn't have create these two packages without the following people:

* toofishes, original creator of the PKGBUILD that I use. IMHO, his kernel-eee package for ASUS Eee PC model 701 is really the shining example of Arch's KISS philosophy. I create these packages using his kernel-eee package as a template in hoping that I could capture the same simplicity and elegance.
* Robertek, for pioneering the effort to get Arch running on the 901. His kernel are what I use when I first got the 901 and making these packages would have been a lot harder without having his kernel's PKGBUILD and kernel config file to use as a base.
* Blind, for making me aware of gregkh staging patch. It really does make dealing with wireless a lot more easier.
* nowahn, for the jumpy cursor patch. Makes the 901 touchpad feels a lot less sucky.
* And all of the fine folks at Arch Linux community.

Thank you all guys, you guys rock!

Last edited by zodmaner (2009-04-02 15:52:59)

Blind · 2009-04-02 16:46:10

Hi,

while I certainly think that it is great you are working on this, I would have liked to see a different name for your package. Now, confusion is programmed.

Regards,
Blind

zodmaner · 2009-04-02 17:45:54

Blind wrote:

Hi,
while I certainly think that it is great you are working on this, I would have liked to see a different name for your package. Now, confusion is programmed.
Regards,
Blind

Well, I think leaving out the "26" from kernel part of the name would avoid confusion with your package, Blind. I guess it wasn't that much of a help, eh?

Well, I'm open for any suggestion on the new name (seeing how badly I've done the job). Maybe kernel-eee901-zod?

Arch Linux

#1051 2009-03-09 09:54:08

Re: Arch on Asus EEE 901

#1052 2009-03-09 15:10:40

Re: Arch on Asus EEE 901

#1053 2009-03-12 03:30:23

Re: Arch on Asus EEE 901

#1054 2009-03-12 07:03:14

Re: Arch on Asus EEE 901

#1055 2009-03-13 15:15:35

Re: Arch on Asus EEE 901

#1056 2009-03-13 18:13:37

Re: Arch on Asus EEE 901

#1057 2009-03-14 14:25:50

Re: Arch on Asus EEE 901

#1058 2009-03-14 16:33:12

Re: Arch on Asus EEE 901

#1059 2009-03-14 21:41:51

Re: Arch on Asus EEE 901

#1060 2009-03-14 22:13:29

Re: Arch on Asus EEE 901

#1061 2009-03-14 23:00:21

Re: Arch on Asus EEE 901

#1062 2009-03-15 03:15:11

Re: Arch on Asus EEE 901

#1063 2009-03-16 16:21:59

Re: Arch on Asus EEE 901

#1064 2009-03-17 13:40:00

Re: Arch on Asus EEE 901

#1065 2009-03-17 22:07:47

Re: Arch on Asus EEE 901

#1066 2009-03-18 00:01:51

Re: Arch on Asus EEE 901

#1067 2009-03-18 02:03:51

Re: Arch on Asus EEE 901

#1068 2009-03-29 20:02:41

Re: Arch on Asus EEE 901

#1069 2009-03-30 18:01:18

Re: Arch on Asus EEE 901

#1070 2009-03-30 19:32:04

Re: Arch on Asus EEE 901

#1071 2009-04-02 13:44:12

Re: Arch on Asus EEE 901

#1072 2009-04-02 14:20:48

Re: Arch on Asus EEE 901

#1073 2009-04-02 15:42:38

Re: Arch on Asus EEE 901

#1074 2009-04-02 16:46:10

Re: Arch on Asus EEE 901

#1075 2009-04-02 17:45:54

Re: Arch on Asus EEE 901

Board footer