You are not logged in.
ah ok :-) and how do i fix it?
Just sit tight and wait until I get my package upgraded.
(╯°□°)╯~ ┻━┻
Offline
*tightsitandwait*
thx :-)
Offline
blixawillbargeld wrote:@toofishes: thanks for the new kernel...everything works so far except volume control using the function key...i tried dkites and igheas acpid packages
There's nothing wrong with the kernel, just item names in alsa devices have changed.
I wonder why nobody noticed this before.
Yeah, I noticed this morning as well when I went to a flash site with loud sound and my mute key no longer worked.
iSpeaker -> Speaker
LineOut -> Line-Out
Offline
acpi-eee v9-4
This should still work perfectly with the older alsa drivers too if somebody really wants to use them. :I
http://kapsi.fi/~ighea/eee/acpi-eee/acp … pkg.tar.gz
And all problems when resuming from suspend seems to be gone now with the latest kernel.
Plain echo mem > /sys/power/state is enough to have successful results.
So the change logs are not just for show.
Last edited by ighea (2008-04-20 21:47:04)
(╯°□°)╯~ ┻━┻
Offline
thx! looks like everything works perfect again!
cheers
s
Offline
So the "limited to UDMA/33 due to 40-wire cable" message in the bootup was annoying me enough that I decided to dive into kernel code and attempt to fix it, since the drive is soldered in. I sent a patch upstream (my first kernel patch, so I probably did it all wrong) and thought you guys might be interested in following. Some speed test results are included in the patch message. http://lkml.org/lkml/2008/4/20/283
Offline
So the "limited to UDMA/33 due to 40-wire cable" message in the bootup was annoying me enough that I decided to dive into kernel code and attempt to fix it, since the drive is soldered in. I sent a patch upstream (my first kernel patch, so I probably did it all wrong) and thought you guys might be interested in following. Some speed test results are included in the patch message. http://lkml.org/lkml/2008/4/20/283
How soon we can expect updated kernel-eee package?
Amazing find, thanks!
(╯°□°)╯~ ┻━┻
Offline
Okay, now with these two scripts, is it possible to make defclock.sh enable cpufreq, and overclock.sh disable it? Think running it constantly at about 600 mhz may shorten the battery life quite a bit. And would it cause any problems - say the processor is running at 300 mhz, then would it suddenly jump to ~600 mhz and then to 900 mhz?
defclock.sh
#!/bin/bash
echo 90 24 1 > /proc/eee/fsb
sleep 1
echo 80 24 1 > /proc/eee/fsb
sleep 1
echo 70 24 0 > /proc/eee/fsb
overclock.sh
#!/bin/bash
echo 80 24 0 > /proc/eee/fsb
echo 85 24 1 > /proc/eee/fsb
echo 90 24 1 > /proc/eee/fsb
echo 95 24 1 > /proc/eee/fsb
echo 97 24 1 > /proc/eee/fsb
echo 100 24 1 > /proc/eee/fsb
echo 30 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
edit: None of the modules for CPU scaling are found, using toofishes kernel. Conky reports full speed, cpufreq reports 230 mhz.
Last edited by KSiimson (2008-04-21 13:04:32)
Offline
i don't think i've seen this answered yet on this thread, so hopefully this question doesn't cause any irritation.
i'm wondering if there are any substantial reasons for updating the eee bios. any comments appreciated.
Offline
You just need eee.ko as far as i know i didn't touch anything with cpufreq
insmod eee.ko
and it should work
not sure about unloading it but a quick search turned up
insmod -k
-k, --autoclean
Set the auto-clean flag on the module. This flag will be used by kerneld(8) to remove modules that have not been used in some period of time --- usually one minute.
Conky is lieing about the cpu speed i don't remember the details but the eee is hardwired to run @ 630 and appear to be at 900, something to do with the FSB but i don't really know too much about it but it.
Okay, now with these two scripts, is it possible to make defclock.sh enable cpufreq, and overclock.sh disable it? Think running it constantly at about 600 mhz may shorten the battery life quite a bit. And would it cause any problems - say the processor is running at 300 mhz, then would it suddenly jump to ~600 mhz and then to 900 mhz?
Offline
BIOS changelog
In fact with the built-in updater it is really easy to keep your bios up-to-date.
I don't really see the difference in term of performences, so if you don't need to update don't bother about it.
I wonder why nobody noticed this before.
I visited your ftp, and downloaded the fix before coming here
Else a question which was lost somewhere back in this topic, does the "print screen" key work ? Is there a way to launch a specific application when pressed ?
Offline
Else a question which was lost somewhere back in this topic, does the "print screen" key work ? Is there a way to launch a specific application when pressed ?
It's just normal print screen key as in any keyboard. See app xev for more info.
(╯°□°)╯~ ┻━┻
Offline
ighea, I have 9-4 installed, and this prints after install:
>>> To use this package, you will have to change your events handler
>>> in /etc/acpi/events/anything to be /etc/acpi/handler_eee.sh.
>>> See /etc/acpi/eee.conf for configurable options.
but I don't seem to have a handler_eee.sh. I dug around in the package but it's not included, where could I find this?
/etc/rc.d/ is where daemons reside. Beware.
Offline
ighea, I have 9-4 installed, and this prints after install:
>>> To use this package, you will have to change your events handler
>>> in /etc/acpi/events/anything to be /etc/acpi/handler_eee.sh.
>>> See /etc/acpi/eee.conf for configurable options.but I don't seem to have a handler_eee.sh. I dug around in the package but it's not included, where could I find this?
It is supposed to mean that in file /etc/acpi/events/anything you change the /etc/acpi/handler.sh to /etc/acpi/handler-eee.sh or anything you like so that /etc/acpi/handler.sh will not be used.
(╯°□°)╯~ ┻━┻
Offline
Hi everybody,
Since I updated to latest acpi-eee & toofishes packages, udev takes 182s to load events. Also, no way to make the eee sleep, closing the lid only changes the vt.
I've tried to boot with standard kernel, udev loads correctly.
Did I miss something? No one else encounter these problems?
Thx for your support
Offline
I just updated to 2.6.25 and have the same problems: 3 minutes to load uevents, after which some udev-related functions fail.
Last edited by testube_babies (2008-04-24 04:41:09)
Offline
There must be some magic with your systems, because atleast I am not able to produce any of those errors. I even moved back to initscripts package from initscripts-splash without any problems.
So have you tried reinstalling udev?
(╯°□°)╯~ ┻━┻
Offline
Hi everybody,
Since I updated to latest acpi-eee & toofishes packages, udev takes 182s to load events. Also, no way to make the eee sleep, closing the lid only changes the vt.
I've tried to boot with standard kernel, udev loads correctly.Did I miss something? No one else encounter these problems?
Thx for your support
Anything funky in dmesg? Or /var/log/messages.log (if you have the stock syslog-ng config)?
Offline
Oups, it seems that it has nothing to do with v86d, sorry.
The real solution is to remove the sdhc card from the slot while booting.
UDEV load events duration:
With sd card: 182200ms
Without: 2450ms
I'm going to run a full sdhc card check.
Note that the sdhc is not mounted (not in fstab).
Previous message:
You're right (I should have the reflex to check logs).
The log files was complaining that v86d was missing.
Install the package, reboot, udev load time is now 2.5s.
Thx toofishes & ighea (should v86d be added in depends?)
Last edited by Defre (2008-04-23 16:52:38)
Offline
Oups, it seems that it has nothing to do with v86d, sorry.
The real solution is to remove the sdhc card from the slot while booting.UDEV load events duration:
With sd card: 182200ms
Without: 2450msI'm going to run a full sdhc card check.
Note that the sdhc is not mounted (not in fstab).Previous message:
You're right (I should have the reflex to check logs).
The log files was complaining that v86d was missing.
Install the package, reboot, udev load time is now 2.5s.Thx toofishes & ighea (should v86d be added in depends?)
I'm going to add a userspace package as a dep to the kernel? Hell no. I don't even use it, I just put it in there so others could.
Now on a more helpful note, I know my bootup is lightening fast with an SD card in all the time, so I'm not sure what issues you are having with your SD card. I have a single ext2 partition on my card. The note about v86d missing is not an issue- its always going to be there, and it can be safely ignored if you don't want to use uvesafb.
Offline
Now on a more helpful note, I know my bootup is lightening fast with an SD card in all the time, so I'm not sure what issues you are having with your SD card. I have a single ext2 partition on my card. The note about v86d missing is not an issue- its always going to be there, and it can be safely ignored if you don't want to use uvesafb.
As an interim solution, you could always blacklist the module for the SD card reader so udev doesn't load it, and manually modprobe it in rc.local. /me shrugs
Offline
Something that may help finding the culprit:
Udev events load in under 3 seconds when I boot with a non-HC card inserted (16MB SD, 1 partition fat16).
Udev chokes on the SDHC card (8GB, 1 partition ext2). The computer doesn't seem to recognize the SDHC card after booting - it won't even show up in /dev. The card checks out fine, and reverting back to 2.6.24eee solves the problem.
Offline
Hi guys,
I've just finished so setting up arch on my new eeepc.
I have only one problem: when arch is shutting down I get:
:: Saving ALSA Levels [BUSY]
/usr/sbin/alsactl: save_state:1251: No soundcards found...
two times.
I'm running latest toofishes' kernel.
Sound works but microphone doesn't.
My MODULES array in rc.conf is empty; may I have to add some modules?
Regards
Offline
Hi guys,
I've just finished so setting up arch on my new eeepc.
I have only one problem: when arch is shutting down I get:
:: Saving ALSA Levels [BUSY]
/usr/sbin/alsactl: save_state:1251: No soundcards found...
two times.
I'm running latest toofishes' kernel.
Sound works but microphone doesn't.
My MODULES array in rc.conf is empty; may I have to add some modules?Regards
You probably used the trick on the wiki to ensure your system shuts down, and the rc.local.shutdown actions run before the alsa shutdown, so your soundcard is already gone as an accessible device by the time this shutdown script runs. But read on and the fix is documented there too.
Offline
You probably used the trick on the wiki to ensure your system shuts down, and the rc.local.shutdown actions run before the alsa shutdown, so your soundcard is already gone as an accessible device by the time this shutdown script runs. But read on and the fix is documented there too.
Yeah, I're right,
that solves the problem.
The last problem is that during boot, a daemons fails to start, but it shows too fast so I can't figured out which one is. There's a log somewhere that I can I read? I guess no. Can I redirect the boot output to a file?
Many Thanks
Offline