|
|
#25 | |
|
Registered User
Join Date: Oct 2011
Posts: 6
|
I don't understand anything about these things.
But on the last NVIDIA drivers (302.17) on a clevo M570RU, here is what I get : "[ 28.175803] NVRM: Your system is not currently configured to drive a VGA console [ 28.175810] NVRM: on the primary VGA device. The NVIDIA Linux graphics driver [ 28.175815] NVRM: requires the use of a text-mode VGA console. Use of other console [ 28.175819] NVRM: drivers including, but not limited to, vesafb, may result in [ 28.175823] NVRM: corruption and stability problems, and is not supported. [ 49.207828] iwl4965 0000:06:00.0: Aggregation not enabled for tid 0 because load = 2 [ 80.393121] NVRM: GPU at 0000:01:00.0 has fallen off the bus. [ 80.603036] iwl4965 0000:06:00.0: Aggregation not enabled for tid 0 because load = 0 [ 97.820771] iwl4965 0000:06:00.0: Aggregation not enabled for tid 0 because load = 0 [ 108.605614] iwl4965 0000:06:00.0: Aggregation not enabled for tid 0 because load = 3" You'll find the entire nvidia-bug-report.log.gz on attachment. By the way, thanks for still working on that problem. |
|
|
|
|
|
|
#26 | |
|
Registered User
Join Date: Apr 2012
Posts: 22
|
Drivers 304.22 and 304.30 also crash...
|
|
|
|
|
|
|
#27 |
|
Registered User
Join Date: Nov 2008
Posts: 22
|
@sandipt: If that would help in any way, I could offer remote root access to my Clevo M570RU, installed with any distro you like. I just want to see that (sry) damn bug fixed one day.
|
|
|
|
|
|
#28 | |
|
Registered User
Join Date: Apr 2012
Posts: 22
|
I can also give you access to mine (also with any distro). Mine is a Clevo M570RU-U with an 8800M GTX card.
|
|
|
|
|
|
|
#29 |
|
Registered User
Join Date: Apr 2012
Posts: 22
|
I booted in rescue mode and did the following:
Code:
echo 1 > /sys/bus/pci/devices/0000\:01\:00.0/remove echo 1 > /sys/bus/pci/rescan pci 0000:01:00.0: BAR 6: can't allocate mem resource [0xe0000000-0xdfffffff] According to some guys this should be harmless: http://linux.derkeiler.com/Mailing-L.../msg00770.html This is a discussion on this issue involving Linux kernel developers: https://groups.google.com/forum/?fro...el/DQMYaZ95PAk[1-25] It seems it could be a BIOS bug (indeed, the BIOS of this laptop is extremely buggy)... |
|
|
|
|
|
#30 | |
|
Registered User
Join Date: Nov 2008
Posts: 22
|
@momann:
At least using nouveau right now I can do that remove & rescan as often as I like, without any problems (screen gets black and gets back on). Dmesg indicates the driver is reinitalized. No such message "can't allocate mem resource". Did you try that running the nvidia drivers or with nouveau? I just had nouveaufb running (didn't try that with an X server running, because I don't think that would be such a good idea). |
|
|
|
|
|
|
#31 |
|
Registered User
Join Date: Apr 2012
Posts: 22
|
@apriori
I am using driver 270.41.19 and it works fine. I just noticed that memory addressing message, which may or may not give some clues to the developers. |
|
|
|
|
|
#32 |
|
Registered User
Join Date: Nov 2008
Posts: 22
|
@momann:
One straneg thing is, that even the very latest drivers work flawlessly in FreeBSD on tihs machine. So, the question is: Where is the crucial difference leading to that? |
|
|
|
|
|
#33 |
|
Registered User
Join Date: Apr 2012
Posts: 22
|
@apriori Good question. OpenSolaris derivatives also work fine with recent drivers.
I see several possible explanations: 1.- The Linux drivers are different (buggier?) in some way. 2.- I think that the xserver versions in both FreeBSD and OpenSolaris are older than those in any up-to-date Linux distro (including Debian Stable). 3.- The problem is in the Linux kernel. 4.- The problem is in the BIOS. I disassembled the DSDT and there are Linux-specific options (but not specific options for other UNIXes). However, removing those options does not solve the problem... My guess is that it could be a mixture of 4 and 3. The Linux kernel normally contains workarounds to deal with buggy BIOSes (the BIOS developers tend not to care about bugs as far as the system works with Windows and even quite often bugs are introduced on purpose to workaround Windows bugs). When those Linux kernel workarounds are removed from the kernel certain older machines become unstable under Linux. |
|
|
|
|
|
#34 |
|
Registered User
Join Date: Nov 2008
Posts: 22
|
I think, we can rule out 4., the ACPI part of the BIOS. Completely deactivating ACPI does not change anything about the problem. Some official statement about 1) would be nice. Are there major differences in the drivers or do both of them just use the same path? I mean, just interfacing with the kernel, no device specific hacks/quirks? I know at least, that the linux kernel is full of device specific quirks (and they are needed).
2) Is hard to say... since the damn Xorg ABI will prevent proper multi version testing. I think the only chance we have from our side, is to compare the chipset drivers in FreeBSD kernels with the one in the linux kernel. I may be a programer, but that is not exactly my area of expertise. |
|
|
|
|
|
#35 |
|
Registered User
Join Date: Apr 2012
Posts: 22
|
The driver 304.37 also crashes...
Still with 270.41.19, which means Cuda 4.0, which means that with this laptop I will soon be unable to use, test and develop CUDA applications... |
|
|
|
|
|
#36 |
|
Registered User
Join Date: Apr 2012
Posts: 22
|
Isn't anyone investigating this issue? Are we abandoned?
|
|
|
|
![]() |
| Thread Tools | |
|
|