Instalacja zamkniętego sterownika Nvidia 190.53 na Linux 2.6.33.1
18 marca 2010, norbert_ramzes
Z konieczności chwili, postanowiłem skompilować najnowsze stabilne jądro Linuksa 2.6.33.1. Jednak po długiej konfiguracji i kompilacji pojawił się problem w postaci braku kompatybilności obecnie najnowszego sterownika kart graficznych firmy Nvidia (190.53) z tym kernelem.
Unable to build the NVIDIA kernel module.
Installation has failed. Please see the file
‘/var/log/nvidia-installer.log’ for details. You may find suggestions
on fixing installation problems in the README available on the Linux
driver download page at www.nvidia.com.
Do wyboru miałem otwarty i wolny sterownik albo samemu rozwiązać problem. Wybrałem to drugie rozwiązanie, ze względu na obsługę sprzętowej akceleracji 3D.
Rzut oka na jedne z ostatnich linii w pliku /var/log/nvidia-installer.log:
...
/tmp/selfgz6879/NVIDIA-Linux-x86_64-190.53-pkg2/usr/src/nv/nvacpi.c:511: error: too few arguments to function ‘acpi_walk_namespace’
...Tłumacząc na polski:
/tmp/selfgz6879/NVIDIA-Linux-x86_64-190.53-pkg2/usr/src/nv/nvacpi.c:511: błąd: za mało argumentów dla funkcji ‘acpi_walk_namespace’
Pasowałoby wpierw zajrzeć do tego nvacpi.c, ale niestety instalator jest samorozpakowujący i po instalacji usuwa wszystkie pliki – również po błędzie. Najlepszym wyjściem jest rozpakowanie za pomocą wbudowanego przełącznika:
~/nvidia # sh ./NVIDIA-Linux-x86_64-190.53-pkg2.run -h | grep extract
-x, --extract-only
~/nvidia # sh ./NVIDIA-Linux-x86_64-190.53-pkg2.run -x
Creating directory NVIDIA-Linux-x86_64-190.53-pkg2
Verifying archive integrity... OK
Uncompressing NVIDIA Accelerated Graphics Driver for Linux-x86_64 190.53........................................Wszystkie pliki zostały rozpakowane do nowego katalogu "NVIDIA-Linux-x86_64-190.53-pkg2" w bieżącej ścieżce (~/nvidia).
W pliku z logu, jak na razie, interesują nas tylko linijki w których występuje problem (tam gdzie jest wywoływana funkcja "acpi_walk_namespace"):
~/nvidia/NVIDIA-Linux-x86_64-190.53-pkg2/usr/src/nv/nvacpi.c:
...
510: acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
511: ACPI_UINT32_MAX, nv_acpi_find_methods, NULL, NULL);
...
1151: acpi_walk_namespace(ACPI_TYPE_ANY, handle, 1, nv_acpi_walk_callback, acpi_name, NULL);
...Grepując źródła jądra Linuksa w wersji 2.6.33.1, znajdujemy pierwszy plik w którym jest zdefiniowana ta funkcja.
/usr/src/my_linux/linux-2.6.33.1/include/acpi/acpixf.h:
...
153: acpi_status
154: acpi_walk_namespace(acpi_object_type type,
155: acpi_handle start_object,
156: u32 max_depth,
157: acpi_walk_callback pre_order_visit,
158: acpi_walk_callback post_order_visit,
159: void *context, void **return_value);
....A następnie kernel 2.6.32:
...
153: acpi_status
154: acpi_walk_namespace(acpi_object_type type,
155: acpi_handle start_object,
156: u32 max_depth,
157: acpi_walk_callback user_function,
158: void *context, void **return_value);
....Powyższe fragmenty robią wrażenie, że brakuje jednego argumentu "post_order_visit" oraz wcześniejszy argument "user_function" został zamieniony na "pre_order_visit".
Na oko można dopisać NULL bądź "nv_acpi_find_methods" jako ten brakujący argument "post_order_visit" albo usunąć odwołania do "acpi_walk_namespace", ale jest takie powiedzenie: "na oko to chłop w szpitalu umarł".
Jednak trzeba mieć 100% pewności i szukamy dalej, gdzie jest kod tej funkcji.
/usr/src/my_linux/linux-2.6.33.1/drivers/acpi/acpica/nsxfeval.c:
...
462: acpi_status
463: acpi_walk_namespace(acpi_object_type type,
464: acpi_handle start_object,
465: u32 max_depth,
466: acpi_walk_callback pre_order_visit,
467: acpi_walk_callback post_order_visit,
468: void *context, void **return_value)
469: {
470: acpi_status status;
471:
472: ACPI_FUNCTION_TRACE(acpi_walk_namespace);
473:
474: /* Parameter validation */
475:
476: if ((type > ACPI_TYPE_LOCAL_MAX) ||
477: (!max_depth) || (!pre_order_visit && !post_order_visit)) {
478: return_ACPI_STATUS(AE_BAD_PARAMETER);
479: }
480:
481: /*
...
491: */
492: status = acpi_ut_acquire_read_lock(&acpi_gbl_namespace_rw_lock);
493: if (ACPI_FAILURE(status)) {
494: return status;
495: }
496:
497: /*
...
502: */
503: status = acpi_ut_acquire_mutex(ACPI_MTX_NAMESPACE);
504: if (ACPI_FAILURE(status)) {
505: goto unlock_and_exit;
506: }
507:
508: status = acpi_ns_walk_namespace(type, start_object, max_depth,
509: ACPI_NS_WALK_UNLOCK, pre_order_visit,
510: post_order_visit, context,
511: return_value);
512:
513: (void)acpi_ut_release_mutex(ACPI_MTX_NAMESPACE);
514:
515: unlock_and_exit:
516: (void)acpi_ut_release_read_lock(&acpi_gbl_namespace_rw_lock);
517: return_ACPI_STATUS(status);
518: }
.../usr/src/my_linux/linux-2.6.33.1/drivers/acpi/acpica/nswalk.c:
...
192: acpi_status
193: acpi_ns_walk_namespace(acpi_object_type type,
194: acpi_handle start_node,
195: u32 max_depth,
196: u32 flags,
197: acpi_walk_callback pre_order_visit,
198: acpi_walk_callback post_order_visit,
199: void *context, void **return_value)
200: {
201: acpi_status status;
202: acpi_status mutex_status;
203: struct acpi_namespace_node *child_node;
204: struct acpi_namespace_node *parent_node;
205: acpi_object_type child_type;
206: u32 level;
207: u8 node_previously_visited = FALSE;
208:
209: ACPI_FUNCTION_TRACE(ns_walk_namespace);
210:
211: /* Special case for the namespace Root Node */
212:
213: if (start_node == ACPI_ROOT_OBJECT) {
214: start_node = acpi_gbl_root_node;
215: }
216:
217: /* Null child means "get first node" */
218:
219: parent_node = start_node;
220: child_node = acpi_ns_get_next_node(parent_node, NULL);
221: child_type = ACPI_TYPE_ANY;
222: level = 1;
223:
224: /*
225: * Traverse the tree of nodes until we bubble back up to where we
226: * started. When Level is zero, the loop is done because we have
227: * bubbled up to (and passed) the original parent handle (start_entry)
228: */
229: while (level > 0 && child_node) {
230: status = AE_OK;
231:
232: /* Found next child, get the type if we are not searching for ANY */
233:
234: if (type != ACPI_TYPE_ANY) {
235: child_type = child_node->type;
236: }
237:
238: /*
239: * Ignore all temporary namespace nodes (created during control
240: * method execution) unless told otherwise. These temporary nodes
241: * can cause a race condition because they can be deleted during
242: * the execution of the user function (if the namespace is
243: * unlocked before invocation of the user function.) Only the
244: * debugger namespace dump will examine the temporary nodes.
245: */
246: if ((child_node->flags & ANOBJ_TEMPORARY) &&
247: !(flags & ACPI_NS_WALK_TEMP_NODES)) {
248: status = AE_CTRL_DEPTH;
249: }
250:
251: /* Type must match requested type */
252:
253: else if (child_type == type) {
254: /*
255: * Found a matching node, invoke the user callback function.
256: * Unlock the namespace if flag is set.
257: */
258: if (flags & ACPI_NS_WALK_UNLOCK) {
259: mutex_status =
260: acpi_ut_release_mutex(ACPI_MTX_NAMESPACE);
261: if (ACPI_FAILURE(mutex_status)) {
262: return_ACPI_STATUS(mutex_status);
263: }
264: }
265:
266: /*
267: * Invoke the user function, either pre-order or post-order
268: * or both.
269: */
270: if (!node_previously_visited) {
271: if (pre_order_visit) {
272: status =
273: pre_order_visit(child_node, level,
274: context,
275: return_value);
276: }
277: } else {
278: if (post_order_visit) {
279: status =
280: post_order_visit(child_node, level,
281: context,
282: return_value);
283: }
284: }
285:
286: if (flags & ACPI_NS_WALK_UNLOCK) {
287: mutex_status =
288: acpi_ut_acquire_mutex(ACPI_MTX_NAMESPACE);
289: if (ACPI_FAILURE(mutex_status)) {
290: return_ACPI_STATUS(mutex_status);
291: }
292: }
293:
294: switch (status) {
295: case AE_OK:
296: case AE_CTRL_DEPTH:
297:
298: /* Just keep going */
299: break;
300:
301: case AE_CTRL_TERMINATE:
302:
303: /* Exit now, with OK status */
304:
305: return_ACPI_STATUS(AE_OK);
306:
307: default:
308:
309: /* All others are valid exceptions */
310:
311: return_ACPI_STATUS(status);
312: }
313: }
314:
315: /*
316: * Depth first search: Attempt to go down another level in the
317: * namespace if we are allowed to. Don't go any further if we have
318: * reached the caller specified maximum depth or if the user
319: * function has specified that the maximum depth has been reached.
320: */
321: if (!node_previously_visited &&
322: (level < max_depth) && (status != AE_CTRL_DEPTH)) {
323: if (child_node->child) {
324:
325: /* There is at least one child of this node, visit it */
326:
327: level++;
328: parent_node = child_node;
329: child_node =
330: acpi_ns_get_next_node(parent_node, NULL);
331: continue;
332: }
333: }
334:
335: /* No more children, re-visit this node */
336:
337: if (!node_previously_visited) {
338: node_previously_visited = TRUE;
339: continue;
340: }
341:
342: /* No more children, visit peers */
343:
344: child_node = acpi_ns_get_next_node(parent_node, child_node);
345: if (child_node) {
346: node_previously_visited = FALSE;
347: }
348:
349: /* No peers, re-visit parent */
350:
351: else {
352: /*
353: * No more children of this node (acpi_ns_get_next_node failed), go
354: * back upwards in the namespace tree to the node's parent.
355: */
356: level--;
357: child_node = parent_node;
358: parent_node = acpi_ns_get_parent_node(parent_node);
359:
360: node_previously_visited = TRUE;
361: }
362: }
363:
364: /* Complete walk, not terminated by user function */
365:
366: return_ACPI_STATUS(AE_OK);
367: }
...Teraz sprawdzamy różnicę w stosunku do poprzedniej wersji jądra 2.6.32:
...
189: acpi_status
190: acpi_ns_walk_namespace(acpi_object_type type,
191: acpi_handle start_node,
192: u32 max_depth,
193: u32 flags,
194: acpi_walk_callback user_function,
195: void *context, void **return_value)
196: {
197: acpi_status status;
198: acpi_status mutex_status;
199: struct acpi_namespace_node *child_node;
200: struct acpi_namespace_node *parent_node;
201: acpi_object_type child_type;
202: u32 level;
203:
204: ACPI_FUNCTION_TRACE(ns_walk_namespace);
205:
206: /* Special case for the namespace Root Node */
207:
208: if (start_node == ACPI_ROOT_OBJECT) {
209: start_node = acpi_gbl_root_node;
210: }
211:
212: /* Null child means "get first node" */
213:
214: parent_node = start_node;
215: child_node = NULL;
216: child_type = ACPI_TYPE_ANY;
217: level = 1;
218:
219: /*
220: * Traverse the tree of nodes until we bubble back up to where we
221: * started. When Level is zero, the loop is done because we have
222: * bubbled up to (and passed) the original parent handle (start_entry)
223: */
224: while (level > 0) {
225:
226: /* Get the next node in this scope. Null if not found */
227:
228: status = AE_OK;
229: child_node = acpi_ns_get_next_node(parent_node, child_node);
230: if (child_node) {
231:
232: /* Found next child, get the type if we are not searching for ANY */
233:
234: if (type != ACPI_TYPE_ANY) {
235: child_type = child_node->type;
236: }
237:
238: /*
239: * Ignore all temporary namespace nodes (created during control
240: * method execution) unless told otherwise. These temporary nodes
241: * can cause a race condition because they can be deleted during
242: * the execution of the user function (if the namespace is
243: * unlocked before invocation of the user function.) Only the
244: * debugger namespace dump will examine the temporary nodes.
245: */
246: if ((child_node->flags & ANOBJ_TEMPORARY) &&
247: !(flags & ACPI_NS_WALK_TEMP_NODES)) {
248: status = AE_CTRL_DEPTH;
249: }
250:
251: /* Type must match requested type */
252:
253: else if (child_type == type) {
254: /*
255: * Found a matching node, invoke the user callback function.
256: * Unlock the namespace if flag is set.
257: */
258: if (flags & ACPI_NS_WALK_UNLOCK) {
259: mutex_status =
260: acpi_ut_release_mutex
261: (ACPI_MTX_NAMESPACE);
262: if (ACPI_FAILURE(mutex_status)) {
263: return_ACPI_STATUS
264: (mutex_status);
265: }
266: }
267:
268: status =
269: user_function(child_node, level, context,
270: return_value);
271:
272: if (flags & ACPI_NS_WALK_UNLOCK) {
273: mutex_status =
274: acpi_ut_acquire_mutex
275: (ACPI_MTX_NAMESPACE);
276: if (ACPI_FAILURE(mutex_status)) {
277: return_ACPI_STATUS
278: (mutex_status);
279: }
280: }
281:
282: switch (status) {
283: case AE_OK:
284: case AE_CTRL_DEPTH:
285:
286: /* Just keep going */
287: break;
288:
289: case AE_CTRL_TERMINATE:
290:
291: /* Exit now, with OK status */
292:
293: return_ACPI_STATUS(AE_OK);
294:
295: default:
296:
297: /* All others are valid exceptions */
298:
299: return_ACPI_STATUS(status);
300: }
301: }
302:
303: /*
304: * Depth first search: Attempt to go down another level in the
305: * namespace if we are allowed to. Don't go any further if we have
306: * reached the caller specified maximum depth or if the user
307: * function has specified that the maximum depth has been reached.
308: */
309: if ((level < max_depth) && (status != AE_CTRL_DEPTH)) {
310: if (child_node->child) {
311:
312: /* There is at least one child of this node, visit it */
313:
314: level++;
315: parent_node = child_node;
316: child_node = NULL;
317: }
318: }
319: } else {
320: /*
321: * No more children of this node (acpi_ns_get_next_node failed), go
322: * back upwards in the namespace tree to the node's parent.
323: */
324: level--;
325: child_node = parent_node;
326: parent_node = acpi_ns_get_parent_node(parent_node);
327: }
328: }
329:
330: /* Complete walk, not terminated by user function */
331:
332: return_ACPI_STATUS(AE_OK);
333: }
...Pogrubione zostały najważniejsze dla nas zmiany.
W obydwu wersjach jądra, definicja typu acpi_walk_callback:
...
typedef
acpi_status(*acpi_walk_callback) (acpi_handle obj_handle,
u32 nesting_level,
void *context, void **return_value);
...Łopatologicznie można powiedzieć, że "user_function" został rozbity na "pre_order_visit" i "post_order_visit" – odpowiednio, funkcja z pierwszego wskaźnika ("pre_order_visit") jest wywoływana jako pierwsza, a w każdym następnym przebiegu pętli while wywoływana jest ta z "post_order_visit".
Nie wgłębiając się zbytnio w szczegóły, wniosek nasuwa się sam. W jądrze 2.6.32, "user_function" jest wywoływany "zawsze" a żeby w 2.6.33.1 działanie było podobne, musimy "podać dwukrotnie ten sam wskaźnik – jako pre_order_visit i jako post_order_visit".
Jak już powiedziałem, nie wgłębiając się zbytnio w szczegóły, modyfikujemy plik nvacpi.c w ten sposób:
...
- 510: acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
- 511: ACPI_UINT32_MAX, nv_acpi_find_methods, NULL, NULL);
+ 510: acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
+ 511: ACPI_UINT32_MAX, nv_acpi_find_methods, nv_acpi_find_methods, NULL, NULL);
...
- 1151: acpi_walk_namespace(ACPI_TYPE_ANY, handle, 1, nv_acpi_walk_callback, acpi_name, NULL);
+ 1151: acpi_walk_namespace(ACPI_TYPE_ANY, handle, 1, nv_acpi_walk_callback, nv_acpi_walk_callback, acpi_name, NULL);
...Zabijamy proces gdm (albo innego menadżera logowania) o ile jest uruchomiony i pracujemy na docelowym jądrze 2.6.33.1:
$ ps -C gdm
PID TTY TIME CMD
7865 ? 00:00:00 gdm
7866 ? 00:00:00 gdm
# kill 7865Usuwamy moduł nvidia (jeśli jest załadowany):
# modprobe -r nvidiaalbo:
# rmmod nvidiaKopiujemy nagłówki kernela (jeśli nie zrobiliśmy tego wcześniej):
# cp /usr/src/my_linux/linux-2.6.33.1/include/generated/* /usr/src/my_linux/linux-2.6.33.1/include/linuxAlbo lepiej linkujemy je:
# ln -s /usr/src/my_linux/linux-2.6.33.1/include/generated/* /usr/src/my_linux/linux-2.6.33.1/include/linuxNastępnie ponownie instalujemy sterownik karty graficznej:
~/nvidia # cd NVIDIA-Linux-x86_64-190.53-pkg2
~/nvidia/NVIDIA-Linux-x86_64-190.53-pkg2 # ./nvidia-installer \
--kernel-source-path=/usr/src/my_linux/linux-2.6.33.1 \
-k 2.6.33.1-> Would you like to run the nvidia-xconfig utility to automatically update you
r X configuration file so that the NVIDIA X driver will be used when you res
tart X? Any pre-existing X configuration file will be backed up. (Answer: N
o)
-> Installation of the NVIDIA Accelerated Graphics Driver for Linux-x86_64
(version: 190.53) is now complete. Please update your XF86Config or
xorg.conf file as appropriate; see the file
/usr/share/doc/NVIDIA_GLX-1.0/README.txt for details.
Uruchamiamy ponownie komputer:
# rebootAlbo uruchamiamy gdm/xdm/kdm, jeśli pracujemy na docelowym 2.6.33.1:
# gdmNic nie wybuchło! Grafika działa bez najmniejszych problemów. Jeszcze test glxgears:
I problem z głowy.
Literówki proszę zgłaszać na (JID/mail) norbert at linux dot pl albo (mail) redakcja at jakilinux dot org.
Problemy z instalacją proszę zgłaszać w komentarzach bądź lepiej na forum.
Autor: Norbert Kiszka
Skład: Norbert Kiszka
Aktualizacja:
Równolegle opublikowałem na linux.pl.
Jeden z użytkowników w komentarzu potwierdził, że działa na 2.6.34-rc1:
Od dłuższego czasu jadę na wersji BETA przez tą przypadłość.
Cieszę się że jest działające rozwiązanie.
Mogę potwierdzić że działa na Slackware z kernelem 2.6.34-rc1.
Liczba komentarzy: 23
W komentarzach możesz używać prostych znaczników HTML. Przykłady:
- Link: <a href="jaklinux.org">Linux dla każdego</a>,
- Wytłuszczenie: <strong>tekst pogrubiony</strong>,
- Kursywa: <em>tekst pochylony</em>,
- Przekreślenie: <strike>
tekst przekreślony</strike>, - Kod: <code>
printf("blok kodu");</code>, - Cytat: <blockquote>cytat</blockquote>
I właśnie za to nie lubię Linuksa. Czasem trzeba się nagrzebać w systemie, by coś zaczęło działać. Niesamowita strata czasu…
Za to Windows to niesamowita strata pieniędzy. A w wolnym czasie można sobie podłubać.
Pod Windowsem natomiast, gdy dostaniesz sterowniki niekompatybilne z aktualną wersją systemu, to możesz co najwyżej dać na mszę, by dostawca opublikował uaktualnione.
Spodziewałem się takiego komentarza, zwłaszcza po traszu.
Żebyś Ty wiedział ile czasu kiedyś zmarnowałem żeby zainstalować Via Rhine III na win xp co skończyło się na naprawianiu systemu przez format. Wyjątkowo kupiłem nową w pudełku razem z płytką ze sterownikami (były do win i do lin). Na tej płytce do Linuksa były źródła modułu tylko dla 2.4.x a to dlatego że 2.6 dawno miał już własny – o czym m.in deweloperzy napisali w dość ciekawej dokumentacji na tej płytce. W domu do dziś mi leży jeszcze fajna stara (parę lat albo więcej – ale 100mbps) karta sieciowa D-Linka na usb. Pod win szukałem sterowników dosłownie lata i kompletnie nic nie znalazłem. Na Linuksie obydwie karty działają PNP (zaraz po podłączeniu i bez jakiejkolwiek instalacji czy konfiguracji).
Tutaj są porządne logi (i w ogóle są) oraz kod jest niezwykle czytelny i porządnie obkomentowany (no idealnie nie jest – ale znajdźcie mi jakiś większy kod który ma więcej komentarzy niż samego kodu). Dzięki czemu problem rozwiązałem w ~30 minut (na zegarek nie patrzyłem) pracując na konsoli w niskiej rozdzielczości i bez pośpiechu (a mogłem zrestartować na starym kernelu i pracować w środowisku graficznym). Jedynie ten art powstał ciut dłużej bo to było staranniej napisane niżeli sama naprawa.
A na Windowsie jak coś się sypie albo nie działa to można sobie jedynie zobaczyć niebieski ekranik albo komunikat “wystąpił błąd” a infolinia ms powie Ci tylko że to wina modemu albo płyty głównej byleby się Ciebie pozbyć. To się nazywa wsparcie i pomoc techniczna. Apropo w wyszukiwarce pomocy technicznej win xp wpisz “666″ (numer błędu dial-up) i zobaczysz wiele mówiącą jedną linijkę tekstu:
Jedyne co z tego rozumiem, to to że mogę się potknąć o kabel usb w drodze do łazienki.
Takich rzeczy w win jest całe mnóstwo. Jak nie wierzysz to poszukaj w wbudowanej pomocy albo w necie m.in na forach.
Po raz kolejny przypomnę parę rzeczy. Wszystko mi działa idealnie nawet na starych kernelach (2.6.26 i starsze). Nowy kernel skompilowałem tylko dlatego że według changeloga ma lepsze wsparcie dla bardzo młodego modemu usb który posiadam (w praktyce się okazało że jest dużo lepiej, choć do ideału brakuje – na xp jest dość podobnie).
Równie dobrze można narzekać że nowiutki silnik od Beinga nie pasuje zbytnio do starego malucha. Takim osobom to polecam wizytę u psychoanalityka.
@vries postaraj się napisać coś bardziej przekonywującego, no chyba że chcesz należeć do osób które pasują do powyższego akapitu.
Popieram pana norberta – działających sterowników do mojej karty sieciowej do dzisiaj pod windowsa nie znalazłem. Pod linucha istniały one od 2.6.10 i gdy to zobaczyłem zrobiłem wielkie oczy.
A ta “niesamowita strata czasu” jest dla niektórych względna. Ja nie lubie właśnie jak pod linuchem skończy mi się powód do dłubania.
Ja mam zwyczajnie nadzieje, ze uruchomię mojego Creativa X-Fi 5.1 (usb) pod alsą z obsługa dźwięku 5.1. Co zapewne jest możliwe, skoro pulse audio to potrafi (z którego zacząłem korzystać, gdy dowiedziałem się, że na Ubuntu magicznie dźwięk działa ok). Na razie zmarnowałem jakieś 3-4 godziny na studiowanie dokumentacji alsy i różne próby.
Marnuję również sporo czasu, gdy okazuje się że tablet Wacoma akurat odmówił współpracy z Xorgiem, lub kernelem. Zdarzało się, że faktycznie znajdowałem i aplikowałem niezbędne łatki. Czasem używałem sterowników beta, czasem musiałem cofnąć update i tyle.
Meczę się obecnie z acpi i zmianą jasności na lapku. Tym czasem bez szczególnych efektów. Nowe moduły Intela niestety mnie nie lubią.
Ale i tak najciekawszy jest przypadek mojej myszki a4tech X750, którą nie mogę sortować zawartości okien naciskając na etykiety pod kde (np. w dolphinie). Może powinienem zapoznać się ze sterownikiem? (nie to nie jest wina kde, bo inne myszki działają)
Zapewne mógłbym naprawić wszystkie te problemy, zdaję sobie z tego sprawę. Ale nie jestem na tyle sprawnym programistą, by robić to bez pomocy wujka Google i dokumentacji. A na wszystko potrzebuję dość sporo czasu (zapewne dużo więcej niż zajęłoby to tobie). I musisz zdać sobie sprawę, że naprawiając problemy z moim kompem tracę czas podwójnie. Raz, bo muszę ślęczeć i rozwiązywać problem. Dwa, bo nie robię innych rzeczy.
Nie chcę podłączać silnika beinga do malucha. Nie twierdze, że pod win jest szczególnie lepiej. Nie twierdze, że łatwiej rozwiązywać problemy. Zwyczajnie wkurza mnie, że muszę siedzieć cały dzień i dłubać, bo coś nie działa. Wkurza mnie, że często marnuję sporo czasu, by z różnym skutkiem naprawiać błędy systemu.
@Dragonex: też kiedyś to lubiłem, ale później życie zaczęło mnie coraz bardziej naciskać bym z tym skończył.
@vries w pewnym sensie się z Tobą zgadzam, ale obecnie jest tak o wiele lepiej niż było kiedyś. Teraz przecież nie trzeba już samemu kompilować wszystkiego. Przykładowo we Fedorze instalacja zamkniętego sterownika nvidia to instalacja jednego pakietu i po resecie już działa. Do tego samo wszystko się aktualizuje. Czegoś takiego nie ma nawet w Windows, aby sterowniki systemu same się aktualizowały. Fakt faktem, że nieraz trzeba przywrócić poprzednią wersje kernela, bo nie idzie wszystko po naszej myśli, ale tak jest o wiele lepiej. Jeżeli ktoś normalnie na co dzień używa Linuxa to wcale nie musi instalować najnowszych rozwiązań, które oferują programiści.
> Czegoś takiego nie ma nawet w
> Windows, aby sterowniki systemu same
> się aktualizowały.
Aktualizują się przecież! Nawet w XP! Dział “Sprzęt, opcjonalne” w Microsoft Update
Tylko jak często i jaka jest jakość tego/tych sterowników?
Zdarza mi się czasem zaglądać do źródeł kernela i muszę powiedzieć że jak wypuszczą jakiś moduł sterownika to nie zostawiają go tak sobie tylko czasem zmieniają to i owo żeby było lepiej/bardziej kompatybilnie.
Bo to zależy jaką dystrybucję się instaluje – pod openSUSE wszystko działa “out of the box”.
Jak ktoś wybiera np. Gentoo, to powinien robić to świadomie – jest to system nastawiony na wydajność, ale kosztem ręcznej konfiguracji, przysłowiowego “dziobania”. Coś za coś. Ja na laptopie mam XP oraz openSUSE 11.2 (który startuje szybciej niż winda i jest o wiele bardziej responsywny) i bardzo sobie chwalę. Nie mam sensu tutaj instalować Gentoo, bo sekunda w tą czy w tamtą nie gra roli. Ale na serwerze, gdzie prowadzę złożone obliczenia (modelowanie molekularne) stoi Gentoo. Tam liczy się każda sekunda, bo jak się te sekundy pozbiera razem, to wyjdzie kilka godzin.
I dlatego linux nigdy nie bedzie odpowiednim systemem na desktop.
Porazka.
Takie oprogramowanie nie powinno wogle wychodzic. Nie wnikam czy jest to wina linuxa czy nvidii. Jak nie jedyni to drudzy byliby w stanie takie rzeczy usuwac…
Ale pewnie, lepiej sie przekrzykiwac na usnecie i wydawac jajko raz po raz aby tylko upchac w nim nowe drivery z ktorych cale 5 osob bedzie korzystac, maja w d…e jego stabilnosc i wspolprace…
Wersja stable jadra to MIT w obecnych czasach.
Strach sciagnac jakis update bo zaraz cos moze sie posywac. Dla upgrade calkiem trzeba stawiac klona bo niewiadomo czego sie spodziewac.
Wiesz co to są pakiety w dystrybucjach Linuksa? Jak nie to się lepiej nie wypowiadaj – normalna dystrybucja oznaczona jako stable nigdy nie ma takich problemów – a to dlatego bo pakiety są budowane tak aby nie występowały. Równie dobrze możesz narzekać np. że sterowniki z Win XP nie działają na Win 7 – identyczna analogia (często spotykana w laptopach, tyle że na odwrót).
A to źle że piszą nowe sterowniki? A co jeśli ktoś zachce kupić dany sprzęt i być szóstym? Co do stabilności to niemożna mu nic zarzucić (patrz serwery które działają bez restartu i bez awarii całe lata) a co do kompatybilności – to zależy wyłącznie od konkretnego producenta – w przypadku Nvidii jest prawie idealnie (brakuje tylko otwartości i ew. szybszych wydań).
Tak na przyszłość – jak się na czymś kompletnie nie znasz to się nie wypowiadaj.
W skrócie: news bardzo mi się podoba, takie małe i szybkie howto. Poza tym pokazuje jak można zacząć rozwiązywać problemy, jaką metodologię przyjąć, itp.
Pozdrawiam
Kamil
A nie można po prostu zainstalować sterowniki beta? Ładnie się kompilują z 2.6.33.
Dla każdego coś innego
Cóż jako laik w tej sferze powiem krótko “uszanowanko”.
Hmm, ja tam nie wiem, ale na forum nvidii było/jest znacznie mniej skomplikowane rozwiązanie, czy raczej mniej skomplikowany patch. Sam korzystam ze sterowników z repozytorium i wystarczyło dopisać 2 (dwa) słowa w pliku nvacpi.c
Może i tak jest na tamtym forum – nie patrzyłem tylko sam rozwiązałem problem. W tym arcie są też dwa słowa!!! Jest tylko opisane szczegółowo jak do tego doszedłem (i jak w przyszłości rozwiązywać takie problemy).
Jak już w powyższym akapicie napisałem, rozwiązałem sam problem dopisując również dwa słowa, ale nie chce mi się nawet zaglądać na te fora, więc powiedz mi: czy odkryli że wystarczy TYLKO JEDNO SŁOWO??? Pewnie nie bo nikomu nie chciało się analizować kodu tylko pewnie z głupa (tak jak opisałem na początku art. że nie powinno się robić) dopisali jeden jakiś argument i tyle.
A teraz mały dowód że wystarczy tylko jedno: w moim powyższym art. zmodyfikuj linię 511 dokładnie jak napisałem ale 1151 zostaw w spokoju (czyli dalej tam brakuje jednego argumentu). Kompiluje się? Działa? Czemu? Bo nawet idiota powinien zauważyć linijkę 1086 a mianowicie:
#ifdef DEBUG
Ładny motyw do metacity, kiedyś też go używałem, ostatnio jednak używam Mirę: http://img265.imageshack.us/img265/107/zrzutekranuqa.png W elementach sterujących Mira, a w krawędziach okna Mirav2, jednak trochę mi brakuje tych elementów czerwieni
Jak by ktoś miał problem taki że obraz dzieli się na 6 mniejszych to wystarczy w pliku xorg.conf w sekcji Device dopisać
Option “ModeValidation” “NoTotalsizecheck”
Autor tego artykułu miał niezłego pecha – dzień po jego opublikowaniu wyszły sterowniki 195.36.15, które instalują się bez żadnych problemów. Mimo wszystko gratuluję – wiem jaką satysfakcję daje rozwiązanie takiego problemu.
Wiem o tym, choć 195.36.15 zrobiło mi dwa proste problemy. Raz że nie chciało się normalnie rozpakować (z -x się udało) a dwa to coś krzyczało że mu nie pasuje z bibliotekami – nawet nie przeczytałem dokładnie co tylko zainstalowałem jeszcze raz i poszło wtedy bez problemów.
@vries w pewnym sensie się z Tobą zgadzam, ale obecnie jest tak o wiele lepiej niż było kiedyś. Teraz przecież nie trzeba już samemu kompilować wszystkiego. Przykładowo we Fedorze instalacja zamkniętego sterownika nvidia to instalacja jednego pakietu i po resecie już działa. Do tego samo wszystko się aktualizuje. Czegoś takiego nie ma nawet w Windows, aby sterowniki systemu same się aktualizowały. Fakt faktem, że nieraz trzeba przywrócić poprzednią wersje kernela, bo nie idzie wszystko po naszej myśli, ale tak jest o wiele lepiej. Jeżeli ktoś normalnie na co dzień używa Linuxa to wcale nie musi instalować najnowszych rozwiązań, które oferują programiści.