1 |
----- Original Message ----- |
2 |
From: "Enrico Weigelt" <weigelt@×××××.de> |
3 |
To: <gentoo-amd64@l.g.o> |
4 |
Sent: Tuesday, January 01, 2008 7:18 PM |
5 |
Subject: Re: [gentoo-amd64] Re: NVIDIA 100.14.19 + xorg-server 1.4.0.90 + |
6 |
xorg-x11 7.3 = blackscreen after every restart |
7 |
|
8 |
|
9 |
>* Hemmann, Volker Armin <volker.armin.hemmann@××××××××××××.de> wrote: |
10 |
> |
11 |
>> > For this year I've already wasted too much resources on that. |
12 |
>> > Maybe I'll have a try in a few month. 3D stuff isnt't that |
13 |
>> > important for me - for 2D stuff the free driver works very fine. |
14 |
>> > |
15 |
>> |
16 |
>> yeah, just copying an ebuild and replacing nv with nvidia in xorg.conf |
17 |
>> costs |
18 |
>> so much time and is so hard to do. Whining on the other hand does not |
19 |
>> take |
20 |
>> any time at all. |
21 |
> |
22 |
> It's more than that. Rebuilding the kernel, loosing fb and ovz, etc. |
23 |
> I prefer spending that amount of time on disassambling the binary |
24 |
> module ... ;-o |
25 |
> |
26 |
>> > BTW: the ebuild conflicts between kernel and nvidia-drivers are |
27 |
>> > also annoying. The kernel parts should be handled differently. |
28 |
>> |
29 |
>> what are you talking about? conflicts? kernel parts? which kernel parts |
30 |
>> handled by what and why? |
31 |
> |
32 |
> The problem comes from NV's (broken) package. Their "sanity" |
33 |
> checks seem to go against the *running* kernel, instead the one |
34 |
> to build for. So, in my case, it denies compiling, as the |
35 |
> currently running kernel has rivafb (but the target kernel won't). |
36 |
|
37 |
Package is not broken. It is designed to install and activate kernel modules |
38 |
(while running) and to modify the kernel module boot load list so of course |
39 |
it "goes against" the running kernel. (which must be the same as the kernel |
40 |
pointed at by /usr/src/linux. |
41 |
|
42 |
> |
43 |
|
44 |
You should read |
45 |
http://www.gentoo.org/doc/en/nvidia-guide.xml |
46 |
and |
47 |
http://gentoo-wiki.com/HOWTO_nVidia_Drivers |
48 |
carefully. |
49 |
|
50 |
You need to rebuild your kernel to eliminate the rivafb (rivafb obsolete on |
51 |
all gpu newer than riva128). And eliminate nvidiafb if you did that also. |
52 |
These two modules are documented as preventing proper function of |
53 |
nvidia-drivers. VESA VGA graphics support is the choice you should have for |
54 |
FB support. |
55 |
|
56 |
Quoting: |
57 |
" |
58 |
|
59 |
Kernel Configuration |
60 |
|
61 |
As mentioned above, the nVidia kernel driver installs and runs against your |
62 |
current kernel. It builds as a module, so it makes sense that your kernel |
63 |
must support the loading of kernel modules. If you used genkernel all to |
64 |
configure the kernel for you, then you're all set. If not, double check your |
65 |
kernel configuration so that this support is enabled: |
66 |
|
67 |
Code Listing 3.1: Enabling the Loading of Kernel Modules |
68 |
|
69 |
Loadable module support ---> |
70 |
[*] Enable loadable module support |
71 |
|
72 |
|
73 |
You also need to enable Memory Type Range Register in your kernel: |
74 |
|
75 |
Code Listing 3.2: Enabling MTRR |
76 |
|
77 |
Processor and Features ---> |
78 |
[*] MTRR (Memory Type Range Register) support |
79 |
|
80 |
|
81 |
Also, if you have an AGP graphics card, you can optionally enable agpgart |
82 |
support to your kernel, either compiled in or as a module. If you do not use |
83 |
the in-kernel agpgart, then the drivers will use their own agpgart |
84 |
implementation, called NvAGP. On certain systems, this performs better than |
85 |
the in-kernel agpgart, and on others, it performs worse. You will need to |
86 |
evaluate this on your own system to get the best performance. If you are |
87 |
unsure what to do, use the in-kernel agpgart: |
88 |
|
89 |
Code Listing 3.3: Enabling agpgart |
90 |
|
91 |
Device Drivers ---> |
92 |
Character devices ---> |
93 |
<*> /dev/agpgart (AGP Support) |
94 |
|
95 |
Note: On amd64, the IOMMU controls the agpgart setting. |
96 |
|
97 |
|
98 |
Arch-specific notes |
99 |
|
100 |
Important: For x86 and AMD64 processors, the in-kernel driver |
101 |
conflicts with the binary driver provided by nVidia. If you will be |
102 |
compiling your kernel for these CPUs, you must completely remove support for |
103 |
the in-kernel driver as shown: |
104 |
|
105 |
Code Listing 3.4: Remove the in-kernel driver |
106 |
|
107 |
Device Drivers ---> |
108 |
Graphics Support ---> |
109 |
< > nVidia Framebuffer Support |
110 |
< > nVidia Riva support |
111 |
|
112 |
|
113 |
A good framebuffer alternative is VESA: |
114 |
|
115 |
Code Listing 3.5: Enable VESA support |
116 |
|
117 |
Device Drivers ---> |
118 |
Graphics Support ---> |
119 |
<*> VESA VGA graphics support |
120 |
|
121 |
|
122 |
|
123 |
" |
124 |
|
125 |
> |
126 |
|
127 |
|
128 |
|
129 |
> cu |
130 |
> -- |
131 |
> --------------------------------------------------------------------- |
132 |
> Enrico Weigelt == metux IT service - http://www.metux.de/ |
133 |
> --------------------------------------------------------------------- |
134 |
> Please visit the OpenSource QM Taskforce: |
135 |
> http://wiki.metux.de/public/OpenSource_QM_Taskforce |
136 |
> Patches / Fixes for a lot dozens of packages in dozens of versions: |
137 |
> http://patches.metux.de/ |
138 |
> --------------------------------------------------------------------- |
139 |
> -- |
140 |
> gentoo-amd64@g.o mailing list |
141 |
> |
142 |
|
143 |
-- |
144 |
gentoo-amd64@g.o mailing list |