Using the ACPI S3 sleep state is actually not an uncommon problem with Linux end users, particularly the non-Ubuntu brand. I have to hand it to Ubuntu in that almost every machine I've ever owned has been properly detected and configured automatically. Getting a bug fixed is a bit more difficult, but whatever.
As many of you know, I use Gentoo almost exclusively on my EEE and Gentoo is historically one of the most difficult platforms to tweak. Gentoo has started offering only stage3 tarballs to get users off to a start, but when I began with Gentoo, they offered stage1 and stage2 tarballs, where building the compiler and baselayout from scratch was part of the installation routine.
The next generation of Gentoo-based distros sometimes offer what is called a stage4 tarball. A stage4 tarball is an entire pre-compiled root image and desktop environment, plus all of the tweaks and additional software necessary to exploit all of the capabilities of the hardware.
In my opinion, the stage4 scene is really lacking with Gentoo. Likewise with binary packaging. If there was a stage4 tarball publicly available for the EEE PC, then there would be thousands more users converted over, I'm sure. The same goes for the Maemo devices. The entire ultra-portable market is full of hardware that has unique specifications and tweaks. If Linux distributions don't start packaging the tweaks, then they'll find themselves falling behind the competition.
So far, I've found a few sites that have clearly explained things relating to building software for the EEE PC - one is by Nathan Coulson, and the other two are slightly outdated.
So the EEE PC model 702 (8GB SSD) has an intel 915 mobile graphics controller on the PCI bus. I would assume that this is the root of the issue when it comes to restoring the black screen after suspend / resume.
I've tried vbetool and saving / restoring /proc/bus/pci/00/02.0 to /tmp/video_state, but neither of those approaches has fixed the problem. Some Gentoo users have reported that the hibernate script works by default so that is my next option to try that out.
I thought I'd post the issue here - if you have any suggestions, please feel free to comment.
In the mean time, I wanted to post my eee overlay. Note that many things with linux-2.6.26 already obselete what is in the overlay, such as the atheros driver, atl2, all of the EEE PC platform-specific fixups, etc. Here is a pretty comprehensive 2.6.26 changelog.
If you feel like using my eee overlay, then you can either directly download the tarball or use layman with
The overlay contains:layman -o http://virtb.visibleassets.com:2080/layman.conf -a eee
- sys-kernel
- asus-acpi (asus acpi module for /proc/acpi/asus)
- eee-sources (The same patches for 2.6.23 brought forward to 2.6.24)
- eeepc-linux (the eee module which allows users to overclock their FSB)
- net-wireless
- madwifi-ng (atheros madwifi driver)
- madwifi-ng-tools (tools specifically for the driver)
- app-laptop
- eee-acpi (a collection of scripts for acpi events - currently only eee-suspend and eee-video are disabled)
- x11-apps
- asusosd (ASUS On-Screen-Display for hotkey events)
export ACCEPT_KEYWORDS="**"
export EMERGE_DEFAULT_OPTS="-K"
export PORTAGE_BINHOST="http://virtb.visibleassets.com:2080/geeentoo/packages/All"
export FEATURES="getbinpkg"
emerge -av1 asusosd
Please help fix my Black-Screen-Of-Death !!
3 comments:
Well, I finally figured out what the issue was. It was because I had the / filesystem on ... wait for it ... an SD card. Sigh, that was pretty lame. The problem with that is 1) the SD Card is still USB-connected, and USB takes some connection time when starting from suspended and going to resume. The hardware is often turned off (via some internal chip select) inside the CPU, and to resume one needs to wait about 5 seconds (this can be done in the /etc/acpi script/actions/eee-suspend itself) just as if the kernel were booting (i.e. with rootdelay=5s). I'm going to check to see if this constitutes a bug, but it might be as simple as compiling USB in statically to the kernel.
Similar problem, albeit on ubuntu. Did you find a solution for this issue?
In my case, I had the root filesystem on an SD card and it seems that resuming with the root on an SD card partition is a bad idea. I guess it's like resuming with the root partition on a USB stick - how reliable can it really be? As long as there is a long enough pause before the USB reinitializes, it should _theoretically_ work
Post a Comment