|
|
#85 | |
|
Registered User
Join Date: Jan 2007
Posts: 43
|
Quote:
same symptoms as previous 180.XX drivers, deadlock after suspend, no wake-up, not even sys rq works. do not bother trying this out. in my opinion this should be priority number one to fix suspend befor final release. otherwise this is a half-driver. of course if your still use an ice-age desktop-pc this is not really an issue, but i bought a laptop with nvidia in it and it always works half. i am getting a bit annoyed because the real issues are not being fixed, this is suspend, messed-up qt-graphics, unusable openoffice. i am stucked with 177.XX, where from all those issues, just suspend works and reverting to 173 which once worked so well, does not work as with the newer kernel-release the 173-driver thinks the kernel is a XEN kernel and i have a life to live, good luck every-one. 8400gt m, sony vaio fz31m |
|
|
|
|
|
|
#86 | |
|
Registered User
Join Date: Jan 2008
Posts: 330
|
Thanks for the warning. The amount of regressions they introduce with each new version is really scary. Just imagine you'd submit a patch to lkml that introduces that many regressions.... ouch.
|
|
|
|
|
|
|
#87 |
|
Registered User
Join Date: Dec 2004
Posts: 74
|
In case there was any doubt, the 180.22 driver still has broken suspend (tested w/ 2.6.28 and 27). Good job at failing nvidia, I don't care if you did do vdpau, your priorities are ****ed up. I'm currently LOLing at stable like everyone else. Your development model no longer makes sense, your labels of beta and stable no longer make sense. Your release schedule for your drivers does not make sense (especially lag time between fixes and availability to the public). The only thing you could do to redeem yourself while keeping the proprietary releases is to have nearly daily releases in which your fixes are posted to us immediately and a branch system divided up for experimental features and a branch for stability in which experimental is backported with time after the kinks have been ironed out.
I really like how this thread and a few others were purposely ignored until it was too late to make the fixes for "stable". The same statement pasted into each thread was icing on the cake... wtf are you people smoking? Is it written in stone that you must have such bad communication with the public as well? Never any details whatsoever. And obviously your driver is falling apart anymore. You are aware your work is moving backwards, yes? Don't you all have any pride? To any thinkpad/etc owner currently shafted over the previous months and for the next undetermined number of months , email lenovo/your laptop manufacturer and complain about how nvidia's official stable drivers have dropped support for ubiquitous features such as suspend/hibernate and how things freeze on logout for over a minute for no reason as well as the hardlocks. Say unless nvidia can be encouraged to get support for this pronto you will not be buying from your laptop manufacturer again. This has worked well for phoronix in the past (for other goals...). |
|
|
|
|
|
#88 | |
|
Registered User
Join Date: Jul 2007
Posts: 165
|
Mister, please keep Your voice down...
![]() Lenovo doesn't said they support linux, except SLED10 for which drivers are working (they have special version on their site), suspend + hibernate too, but that OS is OLD as granma (the kernel and the driver) for gods sake... So, there will be no support whatsoever for other combinations and hardware... Why can't people understand, that if it doesn't say support this and that, there is no way of requiring anything, it's a waste of time... nVidia makes chip which is used by Lenovo, You can mail Lenovo and they will answer that they doesn't support anything more than SLED10... The end of the story. Another problem is market share, how many people do use laptop under linux compared to windows? 1/1000? They won't care of some 0.113% at all... However, quite a lot of complaints might pressure Lenovo, maybe something will work out ![]() This is one of the first comments about the suspend issue from nVidia, why the heck do anyone shout afterwards, even one week has not passed. They already said that it might not get into next version and we kinda know that this might be fixed... In next beta hopefully... I choose my "the right way" of course, I'm slowly moving to "red" ones for my desktop, I already have one in my Quad machine and now I'm going to have another (while not throwing out green one), I'll compare and decide what's best and share that info here. Laptop, on the other hand, is not what I can change right away, so I'll compare what I can get out of reds and greens so I can choose right laptop next time... This is my work laptop I don't pay for it, however I decide what I will get ![]()
__________________
** Laptop T500: C2D 2.53Ghz, 4Gb RAM, Radeon Mobility HD3650, ArchLinux x86_64, Gnome, custom 2.6.35.7, Catalyst 10.10... ** Homebrew router/media server: Intel Celeron 1.2GHz 256Mb RAM, Intel Integrated Video, ArchLinux i686, no GUI, 2.6.33.4 ** Homebrew desktop: AMD Phenom X4 9950 Black Edition, 4Gb RAM, integrated Radeon HD3300 + discrete Radeon 4850 512M, Windows 7 Ultimate (for games), ArchLinux i686, Gnome, 2.6.29, catalyst 9.4... (this now just rocks in lunix, really! ) |
|
|
|
|
|
|
#89 |
|
Registered User
Join Date: Dec 2004
Posts: 74
|
Kirugs,
The problem with a beta driver we get the beta treatment which includes new unstable features and a higher chance of leaks and other regressions. Its just poised to go through the same cycle all over again. Its also going to create problems with distributions unless they ship a new stable driver before the next update because most will not build packages for the beta drivers and 177 will desync more as 2.6.29 or 2.6.28 is used in the next set of distro updates. Unless they do something special, they are not releasing another stable driver for what, 6 months? It's likely we're screwed for a long time now, especially kde4 users. Yes, I intend to vote with my wallet too, at least for my desktop (waiting for builds with 3d/xv support on those ati 4000 hd series cards to be released with some cruising of the radeonhd bug tracker to make sure the grass is greener at that time) and I hoped to notify lenovo because many people complaining to the actual people buying nvidia's chip can have impact. Its unfortunate I can't upgrade my laptop however which is also the most troublesome nvidia machine I own. I bought it cause, at that time, nvidia was doing better than the ati cards. Funny how the times are changing the the two are completely reversing their places (wtf?). Regarding the comment from nvidia, nvidia has a ~3 week to 1 month period between beta releases, I have no idea how long it takes for them to release a beta driver after the stable, I recall it taking longer. It's most likely going to be introducing features first, not concerned with bug fixes and even if it does have bug fixes, they will be piggy-backing. I'll be happy to eat my words if some knight-in-shining-armor posts a fix only release within the month clobbering any number of these bugs, especially if it makes the new stable release. |
|
|
|
|
|
#90 | |
|
Registered User
Join Date: Jan 2009
Posts: 9
|
Quote:
First post, 11-23-08. If that's not early enough for them to look into, I don't know what is. Last edited by Chauncellor; 01-10-09 at 07:44 PM. Reason: Wrong Bookmark of all the many I have on this issue |
|
|
|
|
|
|
#91 |
|
Registered User
Join Date: Oct 2008
Posts: 3
|
Aaron, thanks for taking care!
|
|
|
|
|
|
#92 |
|
Registered User
Join Date: Jan 2009
Posts: 1
|
As sad as it is, I'll have to be voting with my wallet (and this message) as well....
It is simply unacceptable that a driver with such a serious issue would be pushed to stable, that nvidia would care so little about linux support that problems like these go unfixed for *months*. I'll buy another nvidia product when they go open source. Until then, they've lost all of my confidence in their ability to perform. If I could shed my laptop of this cruddy thing and use a technically *much less* powerful intel chip, I would. Want to know why? It would work better, in every way: performance, stability, ease-of-use. Apologies for the poisonous tone of this message for those interested in getting this issue solved. Also, I don't blame you nvidia devs for this problem, I know you work on this as much as you can. Thank you for your effort! If nvidia felt it was worth their while to have real support, they'd hire more of you. |
|
|
|
|
|
#93 |
|
Registered User
Join Date: Jan 2007
Posts: 43
|
i would be just very happy with a 177.fix so that refesh-problems disappear..
probably is 180.XX some transition to something newer?/different?/ like ubuntu 8.04, they introduced som much changes, it was the worst ubuntu and 8.10 is just the best ubuntu... so lets hope nvidia-teeam is experimenting towards the light. |
|
|
|
|
|
#94 |
|
Registered User
Join Date: May 2008
Posts: 16
|
Hello.
Same problems on VAIO FZ21Z (8600M GS), Ubuntu 8.10 Kernel 2.6.27.11, driver 180.22 The 177.80 driver works perfect. |
|
|
|
|
|
#95 |
|
Registered User
Join Date: Dec 2008
Posts: 16
|
bump!
|
|
|
|
|
|
#96 |
|
Registered User
Join Date: Jan 2009
Posts: 3
|
Got it to work right here:
System: Gentoo ~amd64 Chip: Quadro FX 570M Driver: 180.22 Kernel: 2.6.28-gentoo-r1 Situation 1: Entering S3 from console, NO X-Server running -> Need to use vbetool to save & restore the vbestate. I.e. when using hibernate-script, I need to set: EnableVbetool yes RestoreVbeStateFrom /var/lib/vbetool/vbestate VbetoolPost yes Situation 2: Entering S3 from a running X-Server -> I CANNOT use vbetool or any other quirks or the display driver will run into an infinite loop when switching back to the X Console (Blank screen, backlight on, IO going crazy). Entering S3 and resuming works perfectly for me when just doing a plain "echo mem > /sys/power/state" |
|
|
|
![]() |
| Thread Tools | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| RHEL 5.6 .nvidia-settings-rc settings un-applied on screen lock | bluziff | NVIDIA Linux | 1 | 06-14-12 05:12 AM |
| Black screen after switching between graphical virtual consoles five times | rrr-wtf | NVIDIA Linux | 1 | 05-21-12 04:40 PM |
| Stubborn screen res problem | Alpsoandso | NVIDIA Linux | 6 | 05-03-12 06:00 PM |
| Toshiba Sat 1950 screen setup | beaulieu | NVIDIA Linux | 7 | 06-13-03 03:17 PM |
| Redhat 8.0 NVIDIA works - INSTRUCTIONS | STEEL1 | NVIDIA Linux | 267 | 04-15-03 06:48 PM |