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

the_enigma · Last edited by the_enigma on Wed Sep 19, 2007 1:05 pm; edited 1 time in total

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

Alphanos · Posted: Thu Aug 09, 2007 3:33 am Post subject:

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
_________________
Alphanos

the_enigma · Posted: Thu Aug 09, 2007 9:23 am Post subject:

the_enigma · Posted: Fri Aug 10, 2007 9:54 am Post subject:

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 · Posted: Sat Aug 11, 2007 1:34 am Post subject:

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.
_________________
Alphanos

the_enigma · Posted: Mon Aug 13, 2007 6:22 am Post subject:

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 · Posted: Mon Aug 13, 2007 11:48 pm Post subject:

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.
_________________
Alphanos

the_enigma · Posted: Thu Aug 16, 2007 1:01 am Post subject:

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 · Posted: Sun Aug 19, 2007 4:26 am Post subject:

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 · Posted: Sun Aug 19, 2007 5:19 am Post subject:

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

devsk · Posted: Sun Aug 19, 2007 5:27 am Post subject:

the_enigma · Posted: Sun Aug 19, 2007 7:54 am Post subject:

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

devsk · Posted: Sun Aug 19, 2007 3:34 pm Post subject:

the_enigma · Posted: Mon Aug 20, 2007 1:00 am Post subject:

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.

devsk · Posted: Mon Aug 20, 2007 1:06 am Post subject:

the_enigma · Posted: Mon Aug 20, 2007 1:18 am Post subject:

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 · Posted: Mon Aug 20, 2007 1:32 am Post subject:

the_enigma · Posted: Mon Aug 20, 2007 2:46 am Post subject:

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 · Posted: Mon Aug 20, 2007 3:16 am Post subject:

do have

the_enigma · Posted: Mon Aug 20, 2007 5:01 am Post subject:

devsk · Posted: Mon Aug 20, 2007 5:12 am Post subject:

I would say remove

the_enigma · Posted: Mon Aug 20, 2007 8:15 am Post subject:

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 · Posted: Wed Aug 22, 2007 5:06 am Post subject:

the_enigma · Posted: Wed Aug 22, 2007 5:24 am Post subject:

devsk · Posted: Wed Aug 22, 2007 7:09 am Post subject: