|
|
#1 | |
|
Registered User
Join Date: May 2010
Posts: 4
|
I'm running Gentoo Linux. Laptop is Asus N61Vn with nvidia GT240M.
I got the laptop for over 6 months, everything was working fine up to kernel 2.6.31-gentoo-r10 and nvidia-drivers-190.42-r3 (included). Got the problem when i upgraded my kernel to latest gentoo stable version aka 2.6.32-gentoo-r7. I tried upgrading my nvidia-drivers but it doesn't work either, only thing working is returning to my old 2.6.31 kernel. System hang 5 second after i try launching X, it become unreachable even with a ssh session opened from my desktop to my laptop before crash. Error is "NVIDIA(0): WAIT: (E, 0, 0x857d, 0)" in my Xorg.0.log. PS : i got almost the same config (system and hardware) on my desktop except card is GT240 instead of GT240M, no problem on it. Last edited by BarbuDreadMon; 05-17-10 at 04:42 AM. Reason: change title |
|
|
|
|
|
|
#2 | |
|
Registered User
Join Date: May 2010
Posts: 4
|
I tried with kernel 2.6.33, same problem. Seems like it's related to new features in kernel > 2.6.31.
Problem seems to occur just after he enable acpi hotkeys events and just before he initialize OpenGL acceleration. |
|
|
|
|
|
|
#3 |
|
Registered User
Join Date: Sep 2007
Posts: 3
|
I'm running fedora, but the way I got around this was to add acpi=off as one of the kernel arguments.
After I did that no more problems booting and no more WAIT error. You can add this value to the end of the 'kernel' lines in /etc/grub.conf (remember this is fedora) or you can add them to the kernel lines when your grub.conf starts, if you're using grub. hope this helps. kernel 2.6.32 |
|
|
|
|
|
#4 | |
|
Registered User
Join Date: May 2010
Posts: 4
|
Thanks for the tip but i will stay on my kernel 2.6.31 with acpi until the bug with acpi and mobile nvidia is fixed in 2.6.32+ kernel
|
|
|
|
|
|
|
#5 |
|
Registered User
Join Date: May 2008
Posts: 50
|
Hello,
I'm running fine here with an 8600M GT and Gentoo, currently on kernel 2.6.33. Maybe the driver-version does not fit with the newer kernel? I am using 256.25 now, but 195.36.24 (needs to be keyworded, but is in portage) worked fine for me, too. Maybe just try that one? Good luck! |
|
|
|
|
|
#6 | |
|
Registered User
Join Date: Apr 2006
Posts: 2
|
I also have similar problems in fedora 12 and 13 (kernel > 2.6.30). No problems with fedora 11 an 2.6.30 kernel. The screen starts flickering or the xserver doesn't even start. I've attached the xorg.log files with errors like
[ 273.523] (WW) NVIDIA(0): WAIT (2, 6, 0x8000, 0x00007c48, 0x00007e38) [ 274.852] [mi] EQ overflowing. The server is probably stuck in an infinite loop. [ 274.852] Backtrace: [ 274.874] 0: /usr/bin/Xorg (xorg_backtrace+0x28) [0x49ecb8] [ 274.874] 1: /usr/bin/Xorg (mieqEnqueue+0x1f4) [0x49e664] [ 274.874] 2: /usr/bin/Xorg (xf86PostMotionEventP+0xc4) [0x477e24] [ 274.874] 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7fbec02b9000+0x3dbf) [0x7fbec02bcdbf] [ 274.874] 4: /usr/bin/Xorg (0x400000+0x6aae7) [0x46aae7] [ 274.874] 5: /usr/bin/Xorg (0x400000+0x1180f3) [0x5180f3] [ 274.874] 6: /lib64/libc.so.6 (0x3fba000000+0x32a40) [0x3fba032a40] [ 274.874] 7: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fbec0b21000+0x78140) [0x7fbec0b99140] [ 274.874] 8: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (_nv001056X+0x289) [0x7fbec0b99d79] [ 274.874] 9: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fbec0b21000+0xd5206) [0x7fbec0bf6206] [ 274.874] 10: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fbec0b21000+0x383c7e) [0x7fbec0ea4c7e] [ 274.874] 11: /usr/bin/Xorg (0x400000+0xce777) [0x4ce777] [ 274.874] 12: /usr/bin/Xorg (0x400000+0x2c32c) [0x42c32c] [ 274.874] 13: /usr/bin/Xorg (0x400000+0x219ca) [0x4219ca] [ 274.874] 14: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x3fba01ec5d] [ 274.874] 15: /usr/bin/Xorg (0x400000+0x21579) [0x421579] [ 280.523] (WW) NVIDIA(0): WAIT (1, 6, 0x8000, 0x00007c48, 0x00007e38) |
|
|
|
|
|
|
#7 |
|
NVIDIA Corporation
Join Date: Feb 2010
Location: Santa Clara, CA
Posts: 237
|
BarbuDreadMon, do you still experience this crash if you pass option intel_iommu=off to the kernel at boot?
If intel_iommu=off prevents the crash, then this is a bug which should be fixed in the next release. |
|
|
|
|
|
#8 |
|
Registered User
Join Date: May 2010
Posts: 4
|
No more crash with intel_iommu=off at boot time. I'll wait for next release
. |
|
|
|
|
|
#9 |
|
Registered User
Join Date: Jan 2008
Location: USA
Posts: 11
|
Last several weeks I've noticed my laptop screen sometimes not coming up out of suspend, though I was changing kernel versions a lot so I thought that was causing it. Just had the opportunity to ssh into the laptop during one of those moments, and I see the exact same error in Xorg.0.log.
I'm on 2.6.32 amd64 with driver 270.41.06. I'll give the suggested intel_iommu=off tip a try. If that doesn't work, I'm going to go back to one of the 190 series, that was the last time I was free of this other problem: http://www.nvnews.net/vbulletin/showthread.php?t=158091 Steve |
|
|
|
|
|
#10 |
|
Registered User
Join Date: Jan 2008
Location: USA
Posts: 11
|
Does anybody know whether disabling VT-d is identical to specifying intel_iommu=off?
(BTW, forgot to add on the previous post that I'm on a Thinkpad T410.) |
|
|
|
|
|
#11 |
|
Registered User
Join Date: Jan 2008
Location: USA
Posts: 11
|
Just had it occur again waking from sleep. Thinkpad T410 with NVS 3100M, kernel 2.6.32-21, driver 270.41.06. Didn't boot with intel_iommu=off, but I've had VT-d disabled from the BIOS since my last post. Gonna see if I can possibly revert to 2.6.31, based on BarbuDreadMon's experience.
Edit: Unable to revert since 2.6.31 is incompatible with my wifi card. ![]() |
|
|
|
![]() |
| Thread Tools | |
|
|