Asus z71v usually fails to recover from suspend-to-ram (since Edgy)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned | ||
linux-source-2.6.20 (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
I first started using Ubuntu with Dapper, which suspended and resumed fine. In Dapper, powering on the laptop from suspend mode caused all fans to spin up to full speed for about 10 seconds, then they would quit and the screen would come on.
I am currently (9 Apr. 2007) running an up-to-date beta of feisty. While the system suspends just fine, the laptop fails almost every time to come out of suspend. The fans still come on to full power, but the system just stays in that state until a hard shutdown is performed.
I have had this problem since Edgy. In Edgy, occasionally the system would proceed beyond the fan stage after a very long delay. When that happened, sometimes the X session would appear, and sometimes not. Manually switching to VT7 often brought the laptop into a state where it could at least be shut down properly, but it was definately not properly resumed, as most drivers were not loaded, and many services not running. This has not yet occurred with Feisty, but I have not tested it as extensively yet.
Sometimes, the system does resume. Strangely, it seems to depend on how long it had been suspended for. If the system is put to sleep, then immediately (ie: within a minute or two) resumed, it usually works. Currently, with feisty, it works almost every time. Sometimes in Feisty, on a successful resume, I get a message that VBETool has crashed. I went to submit the bug, but there are already many duplicates. See:
https:/
When testing Edgy, I tried to debug this problem by going into the /etc/acpi/resume.d/ directory and going through each script, adding debug lines after every significant step that would add to a log file, so that I could see where the process hung up. However, either all of the scripts ran and the system started, or nothing ran at all. Thus, this problem must be in the kernel or some other very early process, since the scripts were never called on failed resumes. Since VBEtool crashes, I suspect it may have something to do with the NVidia card in my laptop.
I have included the lspci and dmesg output, taken immediately upon reboot after a failed resume.
I hope someone has some suggestions, since suspend is critical to my using feisty.
Thank you,
Pascal
Changed in linux-source-2.6.20 (Ubuntu): | |
assignee: | Registry Administrators (registry) → nobody |
Thank you for your bug report.
There are signs of the nvidia binary module in the dmesg output (thanks for attaching it) It's probably worth setting POST_VIDEO=false in /etc/default/ acpi-support and seeing if things are any better. If not you could try using NvAGP as described on https:/ /help.ubuntu. com/community/ NvidiaLaptopBin aryDriverSuspen d ...