You are not logged in.
How do i get the silver keys to work? The first one works fine (blacks the screen). So what have you guys put in the eee.conf for these buttons? Wiki says they are already configure but they are not!
And is someone alse having problems with AsusOSD not showing the OSD when pressing a button?
Offline
How do i get the silver keys to work? The first one works fine (blacks the screen). So what have you guys put in the eee.conf for these buttons? Wiki says they are already configure but they are not!
And is someone alse having problems with AsusOSD not showing the OSD when pressing a button?
Other governors to cpufreq are modules not compiled in, so load them (but I dont thing it is necessary because speedstep doesnt save so much power like the fsb does).
The buttons are defined but not configured, you have them free for your commands, (/etc/acpi/eee.conf)
When do you start acpid and when asusosd. I dont have problem with asusosd, but I have to mention that asusosd crash when acpid is restarted. I have problem with silver buttons when I start acpid as bootscript. When I restart that after boot, buttons begin working, this I realy doesnt understand why.
Offline
I'm having trouble getting a LUKS filesystem setup using Robertek's zen kernel.
[root@pico proc]# cryptsetup luksFormat /dev/loop/0 WARNING! ======== This will overwrite data on /dev/loop/0 irrevocably. Are you sure? (Type uppercase yes): YES Enter LUKS passphrase: Verify passphrase: Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop/0 contains at least 133 sectors [root@pico proc]# lsmod | grep dm dm_crypt 10884 0 dm_mod 40368 1 dm_crypt [root@pico proc]# zcat config.gz | grep -i aes # CONFIG_SND_MAESTRO3 is not set CONFIG_CRYPTO_AES=y # CONFIG_CRYPTO_AES_586 is not set
Anyone else? Is the aes-i586 module required for this?
TIA.
Updated
Offline
apeiro wrote:Anyone else? Is the aes-i586 module required for this?
Updated
Thanks, Robertek. Encrypting my home partition with LUKS is on my TODO list.
Offline
I got the Wifi fn+f2 on/off toggle to work with Robertek's stable kernel (2.6.26-zen2eee) and Wicd:
1. Install Robertek's acpi-eee901 package:
$ pacman -S acpi-eee901
2. Add pciehp to MODULES list in /etc/rc.conf, after rt2860sta.
3. Add acpid to the end of the DAEMONS list in /etc/rc.conf.
4. Edit /etc/modprobe.conf: add this line:
options pciehp pciehp_slot_with_bus=1 pciehp_force=1 pciehp_debug=1
5. Edit /etc/acpi/eee.conf, set the following parameters:
NETWORK_UP_COMMAND="/etc/rc.d/wicd start"
NETWORK_DOWN_COMMAND="/etc/rc.d/wicd stop"
6. This is my modified /etc/acpi/wlan.sh:
#! /bin/sh
source /etc/acpi/eee.conf
PWR=$(cat /proc/acpi/asus/wlan)
load_modules() {
modprobe rt2860sta
}
unload_modules() {
rmmod rt2860sta
}
logger "args are ${*} and PWR is $PWR"
case $1 in
poweron)
if [ "$PWR" = "0" ]; then
modprobe pciehp
sleep 1
echo 1 > /proc/acpi/asus/wlan
sleep 1
logger "Loading wlan modules..."
load_modules
sleep 1
logger "Creating wlan interface"
$NETWORK_UP_COMMAND
fi
;;
poweroff)
if [ "$PWR" = "1" ]; then
logger "Running network down command"
$NETWORK_DOWN_COMMAND
sleep 1
logger "Turning interface down and unloading modules"
ifconfig ra0 down
sleep 1
unload_modules
sleep 1
logger "Turning wlan device power off"
echo 0 > /proc/acpi/asus/wlan
modprobe -r pciehp
fi
;;
esac
7. To get asusosd to work in my X session, I created the file /etc/xdg/autostart/asusosd.desktop:
[Desktop Entry]
Encoding=UTF-8
Name=ASUS OSD
Comment=ASUS OSD
Exec=/usr/bin/asusosd
Terminal=false
Type=Application
StartupNotify=false
Hidden=false
I'm using KDEmod (KDE 4.1), but this should work for any desktop environment.
If others try these steps out and it works, I'll update the wiki.
Last edited by chori (2008-09-15 16:36:16)
Offline
Nice.
Does it work with
options pciehp pciehp_slot_with_bus=1 pciehp_force=1
w/o the pciehp_debug??? It is annoying
and does you have some pciehp crashes? I had some when loaded pciehp twice (tryed to load when it is loaded). It did only with debug=1. So it is why I comment all the "modporbe pciehp" in wlan.sh and load that permanent in rc.conf
The stable kernel is still not upgraded with the encryption algorythm, will do that later, maybe tomorow.
Last edited by Robertek (2008-09-15 15:37:35)
Offline
Is anybody else having problems coming out of suspend (ram)? It only happens sometimes. When I open the lid, the LCD backlight comes on, but no activity. I can't switch VTs, the FN+Brightness keys do nothing, and I can't ping the machine.
I'm using Robertek's git kernel.
Offline
Nice.
Does it work with
options pciehp pciehp_slot_with_bus=1 pciehp_force=1
w/o the pciehp_debug??? It is annoying
and does you have some pciehp crashes? I had some when loaded pciehp twice (tryed to load when it is loaded). It did only with debug=1. So it is why I comment all the "modporbe pciehp" in wlan.sh and load that permanent in rc.conf
The stable kernel is still not upgraded with the encryption algorythm, will do that later, maybe tomorow.
I tried it without the debug flag, and it still works perfectly. I suspect the pciehp_debug flag is there simply to enable more verbose logging to the syslog. I haven't experienced any crashes; but then, I haven't tried to load it when it was already loaded.
If you're interested, I can post my syslog output and "ifconfig ra0" output, both before and after the toggle, so you can see exactly what's going on.
Offline
I encountered a bug in /etc/acpi/user-buttons.sh that kept the first hotkey from suspending the X session if you're not running the X session as root (which, of course, no one would do ). The user-button.sh script doesn't grab the current user's Xauthority info, so the "xset dpms force suspend" command fails. Here's the fix I applied, cribbing the logic from /etc/acpi/display.sh:
$ cp /etc/acpi/user-buttons.sh /etc/acpi/user-buttons.sh.MODIFIED
$ vi /etc/acpi/user-buttons.sh.MODIFIED
$ diff /etc/acpi/user-buttons.sh /etc/acpi/user-buttons.sh.MODIFIED
5a6,24
> if [ -S /tmp/.X11-unix/X0 ]; then
> export DISPLAY=:0
> user=$(who | grep "vc/7" | awk '{ if ($(NF) == "(:0)") print $1 }')
> if [ "$user" = "" ];
> then
> logger "Could not verify user for X:"
> logger $(who)
> logger "Falling back to XUSER: $XUSER"
> user="$XUSER"
> else
> logger "Found X session user: $user"
> fi
> XAUTHORITY=/home/$user/.Xauthority
> [ -f $XAUTHORITY ] && export XAUTHORITY
> else
> logger "X not probably running, lets launch the command anyway"
> user="$XUSER"
> fi
>$ cp /etc/acpi/user-buttons.sh.MODIFIED /etc/acpi/user-buttons.sh
Robertek, can you apply this fix to your acpi-eee901 package when you get the chance? Thanks.
Offline
Thanks, updated
I have also make a eee.conf option to change vt/7 to user defined. (not all have X on vt 7, like me)
Offline
awesome...just rebooted and the silver buttons work like a dream.
I'm still having a problem with zen-eee901-git. When I boot, I'm still getting:
modprobe: FATAL: Could not load /lib/modules/2.6.27-rc6-zen1eee/modules.dep: No such file or directory
even after I try to rebuild the .img file manually.
Last edited by JazzplayerL9 (2008-09-15 23:08:51)
Offline
Running depmod -a should get rid of that error.
1000
Offline
I'd like to see support for Bluetooth toggling in the acpi-eee901 package; it may be as simple as applying something similar to this patch to the module source code, thereby creating a /proc/acpi/asus/bt control file that can be used in scripts for toggling.
Robertek, did you make available the kernel source for your current stable 2.6.26-zen2eee kernel and your acpi-eee901 packages? If so, I may roll up my sleeves and try this myself.
Offline
Running depmod -a should get rid of that error.
After doing that, THEN recreate the initrd .img file.
Offline
*Solved*
I'm having trouble getting Arch to boot on my Eee PC 1000. I'm sure it has to do with grub or a bad menu.lst, but I don't know what's wrong. I just have a basic stock kernel install with / on the first 8 MB SSD (sda1) and /home on the second 32 MB drive (sdb1). When I try to boot, I get this:
Booting 'Arch Linux (stock kernel)'
root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
kernel /boot/vmlinuz26
[Linux-bzImage, setup=0x3000, size=0x1809fc]
root=/dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx ro
Error 11: Unrecognized device string
Press any key to continue...
I verified that there are no typos several times by checking
ls -lF /dev/disk/by-uuid
and making sure my UUID in my menu.lst is correct.
I also tried to just use root=/dev/sda1 but that didn't work either. I'm at a loss. Any ideas?
Last edited by nefty (2008-09-16 12:39:29)
Offline
It's a bad menu.lst.
kernel /boot/vmlinuz26 root=/dev/disk/by-uuid.... everything on one line.
1000
Offline
That did it, byte. Thanks. I was debating as to whether or not I should post this in Newbie's Corner or here
Offline
Hi, i had asus EEE 1000H
i tried to overclock and underclock CPU, but when i change /proc/eee/fsb to something like 70 50 0 /proc/cpuinfo show me always the same value. So does anybody know what should i missed?
Because changing fanspeed works ok...
Thanks for reply
Using stock kernel with modules atl1e rt2680sta asus_eee pciehp asus_acpi
Last edited by jerka (2008-09-16 14:52:54)
Offline
yeah so I ran a depmod -a before rebuilding the initrd.img and rebooted...still had the modprobe errors...so I rebuilt the image again and then did a depmod -a...and still had errors. What else can I try?
Also...another question. The silver keys with the new acpi...well they work, but they execute anything you tell them to as root. Not a horrible thing, but also not secure.
Offline
Hi, i had asus EEE 1000H
i tried to overclock and underclock CPU, but when i change /proc/eee/fsb to something like 70 50 0 /proc/cpuinfo show me always the same value. So does anybody know what should i missed?
Because changing fanspeed works ok...
Thanks for replyUsing stock kernel with modules atl1e rt2680sta asus_eee pciehp asus_acpi
/proc/cpuinfo is not reliable. From http://wiki.eeeuser.com/howto:overclockfsb:
You can check that the FSB speed was changed by "cat /proc/eee/fsb". Then try running some of your favorite benchmarks to see if the results are better by 30-50%.
N.B.: It is common practice to check the speed of a CPU by "cat /proc/cpuinfo". In this case, that procedure will not work; /proc/cpuinfo will always report 630 MHz, even though the system may in reality be at 900 MHz. The only way to verify 900 MHz (or any speed different than 630 MHz) is to do some benchmarking.
Offline
yeah so I ran a depmod -a before rebuilding the initrd.img and rebooted...still had the modprobe errors...so I rebuilt the image again and then did a depmod -a...and still had errors. What else can I try?
Also...another question. The silver keys with the new acpi...well they work, but they execute anything you tell them to as root. Not a horrible thing, but also not secure.
First things first: does the file /lib/modules/2.6.27-rc6-zen1eee/modules.dep actually exist on your machine?
If not, run "depmod -a", then see if that file has been created. If it hasn't, investigate that problem.
If it does exist, then remake the initrd image again (don't reboot), as I detailed above. Check to see if the file now exists in the image:
# Replace "myimage.img" with the name of your initrd image file
$ gunzip < /boot/myimage.img | cpio -itv | grep modules.dep
If it exists, investigate the problem of why the bootloader doesn't think it can find it. If it doesn't exist, look into how you're making the initrd image file.
Does your grub menu.lst to point to the new image file?
Offline
yes, /lib/modules/..... exists on my machine. I checked that before I did anything else.
depmod -a has created the file within that folder.
I recreated the image with:
mkinitcpio -c /etc/mkinitcpio-zeneee-git.conf -k /lib/modules/2.6.27-rc6-zen1eee -g /boot/zeneee-git.img
gunzip < zeneee-git.img | cpio -itv | grep modules.dep
850 blocks
So I guess it doesn't exist in the image afterall. Why would that be happening if it exists in the /lib/modules/2.6.27-rc6-zen1eee/ folder?
Offline
I recreated the image with:
mkinitcpio -c /etc/mkinitcpio-zeneee-git.conf -k /lib/modules/2.6.27-rc6-zen1eee -g /boot/zeneee-git.img
[
So I guess it doesn't exist in the image afterall. Why would that be happening if it exists in the /lib/modules/2.6.27-rc6-zen1eee/ folder?
I think I see your problem. The "-k" flag takes just the name of the kernel as a parameter, not the path. Try this:
mkinitcpio -c /etc/mkinitcpio-zeneee-git.conf -k 2.6.27-rc6-zen1eee -g /boot/zeneee-git.img
Offline
@chori,
tried the mkinitcpio command with the changed "-k" flag parameter and it still gives the same error on boot. the earlier "gunzip" command is stating 847 bytes now instead of 850...that's the only change.
EDIT:
I copied over my mkinitcpio.conf to the mkinitcpio-zen-eee.conf and took out all the modules in the line, re-saved it, and regenerated the initrd.img again...this time it worked. Seriously, the .conf files look exactly the same but it generated a good .img this time...no errors. Chalk one up to a strange bug? Thanks for your help, btw.
Last edited by JazzplayerL9 (2008-09-16 18:20:51)
Offline
I copied over my mkinitcpio.conf to the mkinitcpio-zen-eee.conf and took out all the modules in the line, re-saved it, and regenerated the initrd.img again...this time it worked. Seriously, the .conf files look exactly the same but it generated a good .img this time...no errors. Chalk one up to a strange bug? Thanks for your help, btw.
Glad you got it working. Just for fun, run "diff mkinitcpio.conf mkinitcpio-zen-eee.conf", see what you get, if you have the previous copy of your mkinitcpio-zen-eee.conf around.
Last edited by chori (2008-09-16 18:32:01)
Offline