You are not logged in.
Thanks. I've looked through that thinkwiki but didn't find anything that seemed to fix this.
Could you please just clarify something for me: I'm using the beyond kernel, so I need to apply a patch to use radeonfb, right? A kernel patch. Now, this is completely ignorant for someone who's been using linux as much as me, but how are they applied? Is it applied to source, then compiled in? I'm right in thinking that you can't just do a 'hot' patch on a kernel, yes?
Sorry if that's a bit confused. But I'm not really sure how all these patches apply specifically to the arch kernels, and the ramifications for subsequent, say, pacman updates of the kernel.
I'll go and read about it myself for now anyway.
Cheers again.
T
Offline
Since you are not familiar with kernel patching, I would suggest to check better if that patch is a plausible solution for your issue.
Radeonfb is a fb driver which is in any linux kernel, but the default configs for arch kernels do not use it (they need to be of general utility, so they use the vesafb in different flavours). Thus, in order to use radeonfb you do not need to patch the kernel source, but to configure and compile it.
The patch I was referring to is a patch which modifies the source of the kernel radeonfb driver, in order to solve a suspend issue affecting many thinkpad laptops. Thus, if we have valid reasons to think that this is your issue, you will need to:
1) patch the kernel source;
2) configure it;
3) compile it.
This can be also done through abs, inserting the patch in a PKGBUILD and then following the wiki how-tos on configuring and compiling a kernel through abs.
However, since it could be a bit hard to do these things for the first time, I would suggest to check if we can actually hope to solve your issue with this strategy.
Therefore, look at this thinkwiki page and verify if your thinkpad model is listed here:
http://www.thinkwiki.org/wiki/Problem_w … ACPI_sleep
Please note that, while the article talks about a powerdrain issue, many thinkpads do not resume at all without this patch.
If your model is listed, we can go further.
If it is not listed, then tell me your thinkpad model and your video card model. I will do other checks in the stuff I collected when I was maintaining the patch.
Anyway, the kernel bugzilla page I was referring to is the following:http://bugme.osdl.org/show_bug.cgi?id=3022
Make a search also in the comments to see if your thinkpad model is mentioned somewhere.
Mortuus in anima, curam gero cutis
Offline
I've been subscribing to the the cpufreq mailing list and apparingly there was a regression on suspend to ram in the 2.6.17 series.
Offline
Hello again.
Thanks for taking the time to help me resolve the issue. I checked the thinkwiki page, and yes my Thinkpad is affected (it's a T40).
I'm comfortable recompiling the kernel, my only problem is I've never actually had to apply a patch. A quick run through of the main steps would be very helpful.
I'm still confused as to why the suspend only seems to fail after a few hours of being suspended. For now I'll try to find some configs for the hibernate scripts.
One other thing: the suspend to ram uses the echo power state method to go into suspension. The suspend to disk uses the suspend2 software (although I did briefly try the other option, it only works with CK kernel, which completely fails to resume). Which shuld I be using, any ideas? I'm not sure how Arch-specific the scripts are. I'll peruse the thinkwiki a little more.
Thanks again,
T
Offline
You can use both, they have different aims: suspension to ram is much faster, but you can go out of power; suspension to disk slower (sometimes slower than rebooting), but saves what you were doing and you do not risk to go out of power.
You can use hibernate-scripts for both: you define the common parameters in common.conf and the specific ones in ram.conf and suspend2.conf, respectively. In hibernate.conf you list in order your preferred methods, then if you call simply hibernate the first method listed there will be tried.
If you want to use a different method call directly the corresponding confgi file, say 'hibernate -F /etc/hibernate/suspend2.conf'.
The script is not arch-specific, but does not need to be, nothing in suspension is arch-specific.
Anyway, it is a nice script, where each relevant detail can be refined, so I would not look for other things (such as powersave or others).
About the patch, if you are able to configure and compile a kernel, patching is very simple.
Download the patch from the link in kernel bugzilla I posted above: the right one is the last attachment, put there by Volker Braun.
With the traditional method (i.e., if you download directly the kernel source from kernel.org):
cd /usr/src/linux-<foo>
patch -Np1 < <thefoopatchpath>
You can use the same method also to apply other patches (e.g., the beyond patchset).
Then you can go on in configuring the kernel. You have to select Device Drivers, Graphics Support, Ati Radeon Display Support (put a Y, that thing can not be a module).
You may also deselect VESA VGA graphics support.
Then compile, install and be sure to modify properly, if needed, your bootloader config.
With the ABS method, it is also easier. In the wiki you can find general infos on kernel compilation through abs.
Let us suppose that you want to use the patch together with a beyond kernel (this should be safe, since there should be no inteersection):
cd /var/abs/local
cp -R /var/abs/extra/kernels/kernel26beyond .
cd kernel26beyond
cp <thefoopatchpath> .
Now, you have to edit the PKGBUILD in order to include the patch and to configure your kernel. So:
1) list the patch in source () ;
2) remove the md5sums stuff;
2) there is a line with 'patch' where the beyond patchset is applied; you need to put anothere line immediately before:
patch -Np1 -i ../<foopatch> || return 1
3) look for the line 'yes "" | make config'. Comment it and write in the line after 'make menuconfig'.
Fine: now you can launch makepkg; you will be directly prompted to configure the kernel with make menuconfig (as above).
Finally, you will install the kernel package you created with pacman -U.
Let me know if this helps. Please refer to howtos in the wiki for kernel compilation through abs (it is likely that I missed some detail in this quick guide).
Mortuus in anima, curam gero cutis
Offline
If you are not going to personalize fully your kernel (a good idea!), you will also need to generate a mkinitcpio image before rebooting.
This is done automatically if you use abs and pacman, but you need to do it on your own if you happen to prefer the traditional method.
Mortuus in anima, curam gero cutis
Offline
Things are getting worse for me
I have upgraded to the latest beyond kernel, released today. Now, when I try to run the hibernate script, the kernel panics in __pgae_cache_release (I am compiling a kernel with USB serial console support so that I can get the full trace).
I tried following the advice on the Suspend2 website. They recommend testing hibernation with as few modules as possible. Unfortunately, with the single-user boot parameter, Arch still loads all the modules it does for multi-user sessions. Booting with init=/bin/sh causes a kernel panic when the boot process tries to access the root file-system (which I believe it should not).
I would really appreciate any help, since I rely heavily on the laptop's ability to suspend (it has a very short battery life, around 2hr).
Elad
Offline
The init=/bin/sh kernel panic is really strange, but I can not reproduce this behaviour (but I do not use any initrd & co)
Anyway, to minimize the number of modules, I would suggest to disable in /etc/rc.conf any autoloading of modules. Or to unload by hand all the suspicious modules before hibernation.
Mortuus in anima, curam gero cutis
Offline
I got Suspend-to-RAM working again (with Suspend 1). The module responsible for my problem (laptop freezes upon resume) was sdhci, which is a new driver introduced in 2.6.17.
Still no luck with Suspend 2 (same kernel panic, even with the latest kernel upgrade). However, I am reasonably happy with Suspend 1, so for me this is no longer an urgent issue.
Offline
I got Suspend-to-RAM working again (with Suspend 1). The module responsible for my problem (laptop freezes upon resume) was sdhci, which is a new driver introduced in 2.6.17.
Still no luck with Suspend 2 (same kernel panic, even with the latest kernel upgrade). However, I am reasonably happy with Suspend 1, so for me this is no longer an urgent issue.
can you outline what you did to get suspend 1 working (wiki would be great)... i've decided that i'm not a true linux user until i wrestle with suspend
Offline
Basically, suspend-to-ram is as simple as
echo -n "mem" > /sys/power/state
However, you would usually like to perform some actions before and after suspension. I therefore have the following sleep.sh script:
# if launched through a lid event and lid is open, do nothing
echo "$1" | grep "button/lid" && grep -q open /proc/acpi/button/lid/LID/state &&
exit 0
# lock sessions
/opt/kde/bin/dcop --all-users --all-sessions kdesktop KScreensaverIface lock
# turn the network off
/etc/rc.d/network stop
# store mixer settings
/etc/rc.d/alsa stop
# unload offensive modules
for m in sdhci ndiswrapper
do
/sbin/modprobe -r $m
done
# sync filesystem and clock
sync
/sbin/hwclock --systohc
# go to sleep
sleep 5 && echo -n "mem" > /sys/power/state
# readjust the clock (it might be off a bit after suspend)
/sbin/hwclock --adjust
/sbin/hwclock --hctosys
# restore offensive modules
for m in sdhci ndiswrapper
do
/sbin/modprobe $m
done
# restore mixer settings
/etc/rc.d/alsa start
# restart network
/etc/rc.d/network start
You can invoke the script directly, or put it under /etc/acpi/actions and add a script to /etc/acpi/events containing the following lines:
# suspend on lid closing
event=button/lid
action=/etc/acpi/actions/sleep.sh %e
Note that I am still tweaking the sleep.sh script (restoring alsa settings doesn't work porperly), but I hope it can give you a reasonable start.
Elad
Offline
ok, i guess this confirms that my suspend problems aren't related to suspend2... with both, i get a HUGE error (when resuming), pretty much saying:
Recursive faults. Errors fixed, reboot required.
With this text (plus a bunch of stuff that is incomprehensible), and the sleep light still on, it freezes, and i have to manually reboot.
I think my ram might be bad...
thinkpad T40 2373-7CU, heavily upgraded
<edit>
"Fixing recursive fault but reboot is needed"
Offline
I believe you are getting the same kernel crash I'm having with the beyond kernel. Have you tried the regular kernel?
Offline
nope... i will
Offline
it works with the regular kernel... awesome!!
i was having a bit of trouble getting a new IP from my router, but i think that's a router problem (eventually it got the ip).
Now, off to compile my own kernel, with just ck
Offline
Yesterday, I found my laptop don't wake up after suspended to ram, but it could. I use a vanila kernel and don't know when it began. I see in errors.log:
Sep 20 03:49:15 zaratustra pnp: Failed to activate device 00:03.
Sep 20 03:49:15 zaratustra pnp: Failed to activate device 00:04.
I can't understand, which devices don't wake up. There is a tool lspnp, but arch doesn't include it:( Try to do this package myself.
Offline
I really think that you can use lspci to identify 00:03 and 00:04
Mortuus in anima, curam gero cutis
Offline
I really think that you can use lspci to identify 00:03 and 00:04
It may do with /sys. It were keyboard and mouse, but they work. Really, My video card isn't waking up. I have built a new 2.6.18 kernel, but it doesn't work too
Offline
Did you try the usual workarounds included in the hibernate scripts (usable also for suspension to ram): switch to text mode and the dummy x server?
Do you own a radeon mobility card? If so, there is a workaround that enables D2 state for some chipset and can be tried with a specific boot parameter on many radeon chipsets. If this is the case, I can give you further details on this workaround.
Mortuus in anima, curam gero cutis
Offline
I booted without X (init 3), nothing was changed. I don't have ati card, my card is intel 855GM. I want to try old kernels: 2.6.16, 2.6.17 to detect when problem was up.
Offline
Try to use vbetool, in the three different ways suggested in the hibernate script (or i810switch, it should support your specific chipset, verify this in their website; i810switch is in the AUR).
Play with the IncompatibleDevices setting in the script.
Try to unload any possible module (or boot with init=/bin/sh, if you do not use initrd-initcpio). So you can verify if a module is guilty, as in many cases.
It is highly unlikely that your problem depend on the suspend-to-ram core in the kernel. In 99% of cases the device drivers are guilty (their development sometimes degrades the suspension ability of the devices).
Mortuus in anima, curam gero cutis
Offline
vbetool solves problem. vbetool post returns screen in normal mode. It's same kind of hack Most likely, the best way is a bios upgrade, but I think, there isn't a new bios for my laptop
Offline
So patching the kernel is the ONLY solution in this problem? Didn't the patch apply to the main branch of the kernel?
Lenovo Sunrise 125C Laptop
Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04)
Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 04)
Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)
Offline