# Suspend to RAM, NVidia, vesafb-tng and slowdowns [solved]

## the_enigma

Ok, I have a Dell Vostro 1400, with an Nvidia 8400GS video card.  I've got the nvidia-drivers package installed, and 3D acceleration works.  I've also got a vesafb running.  Well, vesafb-tng to be precise.

I can suspend to RAM and wake up at the moment.  However, when my laptop wakes up after suspending, vesafb starts taking up all of the available processor time.  A normally unloaded laptop gets load averages of over 2.

I don't know whether it's related, but the framebuffer I run, makes a pretty progress bar during the suspend process.  However, while waking up there is no progress bar.  Also, dmesg reports 

```
vesafb: BUG, returned from vm86 with 0 (EIP: 0xc7e9b)

vesafb: mode switch failed (eax: 0x0)
```

I've tried googling the error messages, best I can find is to try plain vesafb, no TNG.  

I'll just have to reboot now to get some processor time free to recompile with plain vesafb, but has anyone seen anything like this?

For the record, my card in my laptop is PCI-E, so NvAGP is never used, neither is /dev/agpgart

Edit:  Ok, I'm now running vesafb, rather than vesafb-tng.  I no longer have vesafb using my processor like crazy after waking up from a suspend.  However, X still does.  I can solve this by restarting X, but it's not quite a solution.  However, there are no more error messages in dmesg.Last edited by the_enigma on Wed Sep 19, 2007 1:05 pm; edited 1 time in total

----------

## Alphanos

Hi the_enigma,

I don't have a solution but I am having the same problem.  I am glad to see someone else is having the same issue since it seems to indicate that my hardware isn't broken at least.  Let me document some things I have noticed that will hopefully be to our mutual benefit.

My vesafb process rises to 100% CPU utilization at seemingly random times, and I cannot seem to fix it without rebooting - I've tried killing the process but it immediately restarts and continues to use 100% of the CPU.  The problem is not consistent either - sometimes I can leave my machine and nothing happens, other times after I resume using the machine I notice that the system seems sluggish and top reveals the vesafb problem.

I have a desktop PC which is not using any suspend.  I do commonly switch to a bootsplash/framebuffer console while leaving my machine for a while, but I am not using any progress bars, etc.  My dmesg error is very similar.  It reads:

vesafb: BUG, returned from vm86 with 0 (EIP: 0x9a6fa)

vesafb: mode switch failed (eax: 0xffff)

My machine is a 2.8GHz P4 with hyperthreading.  I have a nVidia 5900FX Ultra AGP video card which I have been using with vesafb-tng for some time without problems.  I am using nvidia-drivers 100.14.11 and kernel sources 2.6.21-gentoo-r4.

The relevant entry in my grub.conf reads:

title=Gentoo Linux 2.6.21-gentoo-r4 1280x1024x16 Framebuffer Bootsplash Verbose

root (hd0,0)

kernel /boot/bzImage root=/dev/sda3 video=vesafb:1280x1024-16@80,ywrap,mtrr splash=verbose,theme:earth

initrd=/boot/splash/earth-1280x1024

Here are some potentially relevant excerpts from earlier in my dmesg output (during boot):

Console: colour VGA+ 80x25

checking if image is initramfs... it is

Freeing initrd memory: 1800k freed

agpgart: Detected an Intel 865 Chipset.

agpgart: AGP aperture is 64M @ 0xf8000000

vesafb: unrecognized option mtrr

vesafb: NVIDIA Corporation, GW-P/N@CVG732000IQ0J0:0, GW-CLK@R^C<C2>^Af^C<CC>^A<E8>^C<F4>^A (OEM: NVIDIA)

vesafb: VBE version: 3.0

vesafb: protected mode interface info at c000:e800

vesafb: pmi: set display start = c00ce836, set palette = c00ce8a0

vesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da

vesafb: VBIOS/hardware doesn't support DDC transfers

vesafb: no monitor limits have been set

vesafb: scrolling: ywrap using protected mode interface, yres_virtual=4096

Console: switching to colour frame buffer device 160x64

fbsplash: console 0 using theme 'earth'

fbsplash: switched splash state to 'on' on console 0

vesafb: framebuffer at 0xe0000000, mapped to 0xf8d00000, using 10240k, total 262144k

fb0: VESA VGA frame buffer device

Apparently the mtrr parameter is outdated and I should remove it, but I find it hard to believe that is causing the problem.

Logs indicate that I updated to my current kernel sources on July 15th, and I updated to the my current version of nvidia-drivers on July 19th.  I could try to downgrade one or both of these, but since unlike you I don't seem to have a reliable way of reproducing the problem, I don't know how I could test if the change fixes the problem.  So far I have only noticed the problem happening three or four times, and I did not keep track of when it first occurred.  Fortunately the hyperthreading on my processor seems to allow the system to continue to run while the problem is occurring, like now, but the system does seem much more sluggish.

Hopefully this information will be of some help.  I will see if I can find any other references to people having this problem, and I will also check back here to see if you have found anything.  Can you also please post your version of nvidia-drivers and kernel sources?

Edit:

Not sure if it's important, but the non-comment lines from my /etc/modules.d/nvidia :

alias char-major-195 nvidia

alias /dev/nvidiactl char-major-195

options nvidia NVreg_EnableAGPSBA=1 NVreg_EnableAGPFW=1

options nvidia NVreg_DeviceFileMode=432 NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=27 NVreg_ModifyDeviceFiles=1

----------

## the_enigma

 *Alphanos2 wrote:*   

> -snip-
> 
> Apparently the mtrr parameter is outdated and I should remove it, but I find it hard to believe that is causing the problem.
> 
> -snip-

 

The mtrr option now requires an option.  As in, you need to use mtrr:X, where X is 0,1,2,3 or 4.  

See /usr/src/linux/Documentation/fb/vesafb.txt

For what it's worth, my kernel line is 

```
kernel (hd0,0)/boot/kernel-genkernel-x86-2.6.20-suspend2-r6 root=/dev/ram0 ramdisk=8192 real_root=/dev/sda3  doscsi init=/linuxrc video=vesafb:mtrr:3,vga=865 splash=silent,fadein,theme:true-nature CONSOLE=/dev/tty1 quiet resume=swap:/dev/sda2 
```

----------

## the_enigma

I just got my crazy-high CPU usage again.  I thought I'd try to attach strace to see if I could spot anything.  My kernel hung as soon as I did, no messages printed to /var/log/messages.

----------

## Alphanos

Thanks for the tip on mtrr, I'll make sure to update that the next time that I upgrade my kernel.

Unfortunately (or maybe fortunately?) I haven't yet encountered the problem again myself.  It seems to be pretty infrequent for me, and I don't know how to replicate it.  I'll be keeping this thread open in a Firefox tab for quite a while so that I'll remember to check for it every day.

----------

## the_enigma

Ok, just did some more testing.  I completely disabled any framebuffers, and that did nothing.   I also tried disabling "SwitchToTextMode" and "UseDummyXServer", but that didn't seem to have any effect on anything.

Not sure what else there is to test.

Edit:  Tried to attach strace again, hard locked again :/

----------

## Alphanos

I'm still having trouble replicating the problem on demand.  It hasn't happened again for me yet.

How about this.  If you use a live disk such as the Gentoo install CD that includes framebuffer, can you reproduce the same problem?  I know that's a pretty broad comparison, but maybe it would give someplace to start.

----------

## the_enigma

Well, I tried an Ubuntu LiveCD.  It "suspended" I think.  The battery light started doing its "slow flash" thing.  However, when it started up, the video never came back.  Going to download a Gentoo LiveCD as well, see if that's better.

Edit:  Tried a Gentoo LiveCD (2007.0).  Same results as Ubuntu.  Possibly because I didn't have the official NVidia drivers installed, only ran X with vesa.  Unfortunately, my wireless card (ipw3945) isn't supported directly off the LiveCD, so I couldn't try installing them.

----------

## devsk

you guys should try gentoo-sources-2.6.21-r1 or less. gentoo-sources-2.6.21-r2 and greater can't resume from suspend. I filed a bug but was asked to figure which patches going from r1 to r2 created this problem and I never got the time to do that. If you are inclined to solve this problem, please follow the steps in the bug below and help identify the patch that created this problem. My video card is also nvidia and currently has 40 days uptime using suspend to ram (suspending at least twice a day) using 2.6.21-r1.

https://bugs.gentoo.org/show_bug.cgi?id=184852

----------

## the_enigma

Cool.  I didn't realise that gentoo-sources supported suspend.  I'll be trying that next.

----------

## devsk

 *the_enigma wrote:*   

> Cool.  I didn't realise that gentoo-sources supported suspend.  I'll be trying that next.

 suspend-to-ram or ACPI S3 sleep is supported by the mainline kernel. Most of the time if you do "modprobe -r <your_network_driver>" before suspending, you should not have problems resuming. You can use hibernate-ram script from sys-power/hibernate-script and do some basic setup in /etc/hibernate/*.conf and you are good to go!! The script does all the dirty work like unloading incompatible modules etc.

----------

## the_enigma

Ok, just compiled gentoo-sources 2.6.20-gentoo-r8.  I can suspend, but still have major slowdowns on starting back up.  And dmesg still prints

```
vesafb: BUG, returned from vm86 with 0 (EIP: 0xc7e9b)

vesafb: mode switch failed (eax: 0x0)
```

----------

## devsk

 *the_enigma wrote:*   

> Ok, just compiled gentoo-sources 2.6.20-gentoo-r8.  I can suspend, but still have major slowdowns on starting back up.  And dmesg still prints
> 
> ```
> vesafb: BUG, returned from vm86 with 0 (EIP: 0xc7e9b)
> 
> ...

 can you try regular vesafb instead of TNG version? only other difference I can see is that I am using AMD64 (64-bit system).

----------

## the_enigma

Ok, I tried regular vesafb.  It has no real "errors" as such in dmesg or Xorg.0.log or anything, but it displays similar issues.

I can suspend fine, still, but on resuming, X starts hogging one core again.  If I try to attach strace, the X session freezes up.  I can still cleanly power down by tapping my power button though, so it must just be X.  Now I don't know whether to investigate vesafb, Xorg, or maybe even the nvidia-drivers?

edit:  Ok, the ACPI-still-works thing gave me an idea.  If I run strace from another system here, I get output.  X still freezes, but when strace stops, X starts "working" again.  Albeit still slowly.

Anyway, what I've noticed is that there seem to be a crazy number of "gettimeofday" calls when I get my "lag" spikes.  I'm talking upwards of 9000 calls in one second.  9391 calls, in just one test.  So I now may be getting somewhere.  Anyway, works beckons, but I will investigate further tonight.Last edited by the_enigma on Mon Aug 20, 2007 1:16 am; edited 1 time in total

----------

## devsk

 *the_enigma wrote:*   

> Ok, I tried regular vesafb.  It has no real "errors" as such in dmesg or Xorg.0.log or anything, but it displays similar issues.
> 
> I can suspend fine, still, but on resuming, X starts hogging one core again.  If I try to attach strace, the X session freezes up.  I can still cleanly power down by tapping my power button though, so it must just be X.  Now I don't know whether to investigate vesafb, Xorg, or maybe even the nvidia-drivers?

 what versions of xorg-server and nvidia-drivers? did you try tricks like vbetool and SwitchToTextMode one by one. I at least have SwitchToTextMode to 'yes' and EnableVbetool 'no'.

----------

## the_enigma

xorg-server is 1.3.0.0 (yes, marked unstable, but I get the same results with 1.2.0-r3)

nvidia-drivers is 100.14.11, and I don't know if I've tried any others.  Will check this out.

I've got SwitchToTextMode enabled, and I've played with VBETool, but not with plain vesafb so I will also try those again too.

----------

## devsk

 *the_enigma wrote:*   

> xorg-server is 1.3.0.0 (yes, marked unstable, but I get the same results with 1.2.0-r3)
> 
> nvidia-drivers is 100.14.11.

 I am running the same. What other hardware do you have?

you can always try to ssh into the machine from another machine or switch to a console and do the strace from there.

----------

## the_enigma

It's a core2duo laptop, centrino, with the ICH9 (I think, maybe ICH8 ) 965 chipset.  Intel ipw3945 wireless (module unloaded before suspend), SATA hard drive, BCM5906 network card, inbuilt USB webcam (module unloaded before suspend), inbuild SD/MMC card reader, intel-HDA audio with a STAC9228.

I think that's all

As to running strace over the network, I did that in an edit a few posts up.  As I surmised, X doesn't crash, but just seems to "stop", which is in itself odd behaviour, but anyway I also noticed huge masses of gettimeofday syscalls during the "lag spikes", which were creatable by swapping workspaces.  By "huge masses" I mean in excess of 9000 calls in a second, I presume that is large since the best I can create on this laptop without suspending is just 2000 calls per second, and that involves some quick flipping between workspaces.

----------

## devsk

do have 

```
Section "Extensions"

        Option          "Composite"  "True"

        Option          "RENDER" "True"

EndSection
```

 and

```
 Option  "RenderAccel"           "True"
```

in Section "Device" for the video device? Also, make sure that you DON'T have 

```
Option "UseEvents"             "True"
```

After that, one last thing to try would be to use 'nv' driver from xorg package x11-drivers/xf86-video-nv instead of nvidia and see if that gets you any better behavior during resume.

----------

## the_enigma

 *devsk wrote:*   

> do have 
> 
> ```
> Section "Extensions"
> 
> ...

 

I do have Composite and RENDER, and RenderAccel.  I don't have UseEvents anywhere in xorg.conf

Anyway, I'll try 'nv' when I get home.  Somehow I doubt work likes me playing with this when I'm meant to be building an embedded OS  :Smile: 

Edit:  I have 

```
Option "VBERestore"
```

.  Wonder if that makes a difference.  I'll try with "nv" first though, see how that goes.

----------

## devsk

I would say remove 

```
Option "VBERestore"
```

 first. With Nvidia, I had to disable VBE related stuff to get it working. Give it a shot!

----------

## the_enigma

Ok, the nv driver doesn't support my 8400GS apparently.  Suspend to RAM with the vesa driver was .. a failure.  It shutdown ok, and started up again, but the video never came back.

Anyway, back to the nvidia driver.  I disabled VBERestore, but I still have the same results.

----------

## devsk

 *the_enigma wrote:*   

> Ok, the nv driver doesn't support my 8400GS apparently.  Suspend to RAM with the vesa driver was .. a failure.  It shutdown ok, and started up again, but the video never came back.
> 
> Anyway, back to the nvidia driver.  I disabled VBERestore, but I still have the same results.

 then the only thing is amd64 vs. x86. Do you wanna try a recent amd64 livecd?

----------

## the_enigma

 *devsk wrote:*   

>  *the_enigma wrote:*   Ok, the nv driver doesn't support my 8400GS apparently.  Suspend to RAM with the vesa driver was .. a failure.  It shutdown ok, and started up again, but the video never came back.
> 
> Anyway, back to the nvidia driver.  I disabled VBERestore, but I still have the same results. then the only thing is amd64 vs. x86. Do you wanna try a recent amd64 livecd?

 

I have an Intel Core2Duo, I didn't think the amd64 livecd would work for me?  I also wonder whether the multi-core thing might be playing havoc with things.  I'm going to try running in single-core mode, see if that helps at all.

----------

## devsk

 *the_enigma wrote:*   

>  *devsk wrote:*    *the_enigma wrote:*   Ok, the nv driver doesn't support my 8400GS apparently.  Suspend to RAM with the vesa driver was .. a failure.  It shutdown ok, and started up again, but the video never came back.
> 
> Anyway, back to the nvidia driver.  I disabled VBERestore, but I still have the same results. then the only thing is amd64 vs. x86. Do you wanna try a recent amd64 livecd? 
> 
> I have an Intel Core2Duo, I didn't think the amd64 livecd would work for me?  I also wonder whether the multi-core thing might be playing havoc with things.  I'm going to try running in single-core mode, see if that helps at all.

 core2duo is 64-bit capable. amd64 profile will run fine because its generic x86_64 and nothing amd specific. If you do install amd64 finally on disk, make sure to choose CFLAGS correctly, and of course amd specific flags like k8 won't work.

I ran my amd64 livecd (I build it myself to have custom setup/programs/users etc. and I used generic settings, nothing AMD specific) and subsequent install on core2duo just fine. Although the lappy had Intel card, suspend to ram and resume worked fine there as well.

Moreover, my desktop (the lappy as well because it was core2duo and I had SMP enabled) where I do suspend to ram on daily basis is a dual core amd 3800 X2. There is nothing wrong with SMP support for suspend to ram, it works.

amd64 livecd may help because I have found that x86_64 is more stable than x86, kernel-wise. I never tested suspend to ram on x86 myself.

----------

## the_enigma

Well I tried the official Gentoo LiveCD (2007.0).  It booted, but the opensource nv drivers didn't support my GS8400, or at least error'ed out.  And X refused to start with vesa drivers.

Also tried the Ubuntu LiveCD.  It didn't even boot beyond grub.

Looks like I'll have to find a LiveCD with the closed-source nvidia drivers on them, and try that.

----------

## the_enigma

Update:  Nvidia issue  :Very Happy: 

100.14.19 drivers fixed my problem.  Now I just need to get the sleep+battery info buttons working.

----------

## nihil39

I have a vostro 1400 with 8400GS and I'm experiencing a problem with X.org.  I use amd64 2.6.22-r8 gentoo kernel and xorg-server 1.3.0. If I enable vesafb support in the kernel I'm not able to resume (blank screen) from X nor able to switch to another shell (ctrl-alt-f?). 

Can someone help me to solve this issue?  Thank you in advance.

----------

## the_enigma

 *nihil39 wrote:*   

> I have a vostro 1400 with 8400GS and I'm experiencing a problem with X.org.  I use amd64 2.6.22-r8 gentoo kernel and xorg-server 1.3.0. If I enable vesafb support in the kernel I'm not able to resume (blank screen) from X nor able to switch to another shell (ctrl-alt-f?). 
> 
> Can someone help me to solve this issue?  Thank you in advance.

 

Since you're using amd64, I presume you're also using vesafb and not vesafb-tng.  What version of the nvidia-drivers are you running?  I had to run 100.14.19 to fix my first issues with resuming.

----------

## nihil39

 *the_enigma wrote:*   

>  *nihil39 wrote:*   I have a vostro 1400 with 8400GS and I'm experiencing a problem with X.org.  I use amd64 2.6.22-r8 gentoo kernel and xorg-server 1.3.0. If I enable vesafb support in the kernel I'm not able to resume (blank screen) from X nor able to switch to another shell (ctrl-alt-f?). 
> 
> Can someone help me to solve this issue?  Thank you in advance. 
> 
> Since you're using amd64, I presume you're also using vesafb and not vesafb-tng.  What version of the nvidia-drivers are you running?  I had to run 100.14.19 to fix my first issues with resuming.

 

Thanks, I solved that issue by downloading the latest drivers. Now I have problems with sound but I'll post that in another (already existing) thread  :Smile: 

----------

## the_enigma

Check http://www.strudel-hound.com/wiki/index.php?title=Linux_on_the_Dell_Vostro_1400 if you want, it sums up all of my workings with the Vostro 1400 so far.

----------

