Bonjour à tous. J’ai installé Debian sur un vieux PC portable que j’ai retrouvé. Quand je dis vieux, il est de 2003. Le processeur est un intel céléron, 256M de RAM. J’y est installer le 7.5 wheezy, i386. L’installation c’est bien passé, aucun soucis, sauf que (sinon je ne serais pas là) lorsque je boot le PC, j’ai l’ecran où je dois choisir le démarrage normal ou maintenance, je choisi normal, le boot démarre et aprés quelques secondes, ecran noir. Quand je dis écran noir, c’est comme si, il n’y avait pas d’alim ou que le PC est branché sur un autre écran. L’autre problème, c’est que ce n’est pas a chaque démarrage. Lors d’un démarrage normal, le boot démarre et au bout de quelques secondes, je peux voir qu’il y a un changement dans la config de l’ecran (police différente) et la je peux aller sur Debian. J’ai essayé de voir les log, le probleme c’est qu’au bout d’un moment, Debian est figé, je peux encore bouger la souris, mais ça ne répond plus et le ventillo du processeur s’emballe.
J’ai essayer de chercher quelque infos (peut etre pas au bon endroit) et je peux voir que d’autres personnes ont aussi des problème d’ecran noir noir, excepté que la configuration est differente.
SVP, quelqu’un pourrait-il m’aider car je n’ai jamais eu ces problème avec mes install de Debian.
D’avance merci beaucoup.
[quote=“Van Dilly”]
J’ai essayer de chercher quelque infos (peut etre pas au bonne endroit) et je peux voir que d’autres personnes ont aussi des problème d’ecran noir noir, excepté que la configuration est differente.[/quote]
Au boN endroit, pas la bonNE configuration.
Commence par préciser le matériel en présence, tout particulièrement la carte graphique pour que les gentils membres de debian-fr qui posséderaient ce type de matériel fassent part de leurs expériences, de leurs succès ou de leurs échecs cuisants.
$ lspci
Salut,
De toute manière, avec autant de ram, AMHA tu ne peux espérer travailler qu’en mode console et pas avec un environnement graphique 
@ etxeberrizahar: Merci pour la correction…
lspci -> VGA Compatible Controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03).
Proces: Intel Celeron 2.40GHz
Graph: Intel 854x86/MMX/SSE2
@ ggoodluck47: c’est ce que je peux voir… La prochaine fois je ne tiendrai pas compte du “Matériel minimum” de la doc Debian (128M mini (debian.org/releases/wheezy/ … 04.html.fr)), et puis certain, par la suite, si ce PC est OK, j’utiliserai uniquement la commande. Je suis curieux et j’aimerai savoir pourquoi ces problèmes que je n’ai jamais eu et donc, que je ne connais pas
Salut,
[quote=“ggoodluck47”]Salut,
De toute manière, avec autant de ram, AMHA tu ne peux espérer travailler qu’en mode console et pas avec un environnement graphique 
[/quote]
Ce ne sont là, que des idées préconçues, engrangées au grès du temps, à tord. 
[quote]Quasiment tous les processeurs de la famille x86 (IA-32), toute la série Pentium d’Intel encore en usage sur les PC sont reconnus ; cela veut dire également les processeurs 32 bits AMD et VIA (anciennement Cyrix) et les processeurs tels que Athlon XP et Intel P4 Xeon.
[/quote]
2.5. Mémoire et espace disque nécessaires
[quote]Vous devez posséder au moins 80MB de mémoire vive et 580MB d’espace disque. Ce sont vraiment des valeurs minimales. Pour une estimation plus réaliste, voyez Section 3.4, « Matériel minimum ».
L’installation sur des systèmes avec moins de mémoire [4] ou avec moins d’espace disque disponible est encore possible mais cela demande des utilisateurs expérimentés.
[4] L’installateur graphique demande plus de mémoire que l’installateur texte. Il ne doit pas être utilisé avec des systèmes avec une quantité de mémoire inférieure à 80MB. Si un choix est proposé, il vaut mieux sélectionner l’installateur texte.[/quote]
[quote]Selon vos besoins, vous pouvez continuer avec du matériel inférieur au matériel recommandé dans le tableau ci-dessous. Cependant, la plupart des utilisateurs seront frustrés s’ils ignorent ces suggestions.
Un Pentium 4, 1 GHz, est la configuration minimale recommandée pour une machine de bureau.
Tableau 3.2. Configuration matérielle minimale recommandée
Type d’installation RAM (minimum) RAM (recommandée) Disque dur
Sans desktop 64 megaoctets 256 megaoctets 1 gigaoctet
Avec desktop 128 megaoctets 512 megaoctets 5 gigaoctets
[/quote]
[quote]La quantité de mémoire nécessaire est inférieure à celle donnée dans le tableau. Selon l’architecture, il est possible d’installer Debian avec 20 Mo (sur s390) ou 60 Mo (sur amd64). Il en va de même pour l’espace disque, surtout si vous choisissez une à une les applications à installer. Voyez Section D.2, « Espace disque nécessaire pour les tâches » pour vous faire une idée de l’espace disque nécessaire.
Il est possible de faire fonctionner un environnement de bureau sur de vieilles machines ou des machines bas de gamme mais il est alors recommandé d’installer un gestionnaire graphique moins gourmand en ressources que les environnements de bureau de GNOME et KDE. Par exemple, xfce4, icewm et wmaker, mais il en existe d’autres.
[/quote]
À titre perso, sur une machine “bénéficiant” de 256 Mio de RAM, je fais tourner une BLFS-7.4 avec les environnements graphiques suivants Xfce4 et/où KDE-4 sans le moindre souci.
Bien évidemment il n’est pas question de faire une comparaison niveau performance, hein … 
[i]À titre perso, sur une machine “bénéficiant” de 256 Mio de RAM, je fais tourner une BLFS-7.4 avec les environnements graphiques suivants Xfce4 et/où KDE-4 sans le moindre souci.
Bien évidemment il n’est pas question de faire une comparaison niveau performance, hein … [/i][/quote]
Ceci dit, avec ma config, sans charger la mule, ça va, c’est si je commence à faire 36 choses à la fois, comme voir les log avec quelque chose qui tourne derrière, ça bloque. Ca bloque aussi quand l’écran se met en veille. Pour vérifier je peux changer la RAM. Sinon, comme je l’ai dit, si c’est ok, j’utiliserai trés rarement le mode graphique. C’est juste un PC qui etait là, à dormir dans un carton, autant voir si il peut etre utile avant de le jeter bêtement. Ce serait un plus pour moi, afin de pouvoir prendre la main sur d’autre machines, qui eux, sont à leur place et qui n’ont pas besoin d’etre décabler pour une petite broutille qui peut etre faite à distance, sans avoir a utiliser Putty sous windows ou le PC de ma femme. Je cherche pas non plus a en faire un serveur, loin de là. Et puis, le problème principal, c’est lors du boot où l’ecran s’éteint complétement.
i845 ?
Expérience personnelle passée (ai abandonné cette machine depuis longtemps) : oublie X sur ces engins.
X instable, comme ils diraient en rosbif «broken beyond repair», tellement cassé qu’on ne pouvait raisonnablement songer à le réparer.Tu n’auras pas de X stable avec une debian contemporaine.
«Ça eût marché, ça ne marche plus»
À partir de squeeze, crashs sur crashs.
Pour disposer de X sans crashs inopinés, je n’installerais rien de plus récent que debian lenny (voire etch) sur des engins pareils.
Si tu installes un environnement graphique malgré tout, ne pas installer gnome ou kde même d’époque sur ce genre de coucou.
(La bonne nouvelle dans le tableau,X ne crashait pas tout le système.Le système restait exploitable par ssh malgré son X aux fraises.)
Merci etxeberrizahar. C’est quelque chose que je ne savais pas du tout et je suis bien content de le savoir. J’ai jamais eu de problème comme celui-ci et jamais avec l’interface graphique, donc, j’ai jamais apporté de l’importance à ça pour les autres installations. Maintenant, certain, j’y regarderai à 2 fois.
Pour le fun, je vais essayer avec lenny, mais vraiment pour le fun. Sinon recyclage ou dans mon musée: le garage 
Merci beaucoup etxeberrizahar et toute les personnes présente sur ce sujet, de votre aide et de votre temps.
Tiens un article de Phoronix à propos de cette circuiterie (article de 2012).
Intel Finally Delivers Stable i830GM/i845G Driver qu’ils affirment. (À vérifier, ne jamais croire aveuglément Foireux-Nix ).
Soulignés, témoignages de la sinistre réputation de cette circuiterie sous nulix.
phoronix.com/scan.php?page=n … px=MTI1MzI
[quote]
While the Intel 830GM and 845G chipsets were first introduced more than one decade ago, their graphics driver support has been botched for much of the time. As of today though, Intel Linux driver developers think they have taken care of the longstanding stability issues with this now ancient hardware.
Since the introduction of the Graphics Execution Manager (GEM) in 2008 for managing the memory used by the Intel Linux graphics driver, the old i830/845 support has been a mess. Various attempts were tried by Intel Open-Source Technology Center developers like doing a GEM-free UMS driver and various other shots to hopefully stabilize the support and make hardware acceleration work well. These attempts though haven’t been a great success.
Back in August they worked their xf86-video-intel X.Org driver finally to a point where they could re-enable hardware acceleration by default. However, with this enabled acceleration support, Intel developers still knew the hardware would hang at some point. “Enable acceleration by default on 830gm/845g. The GMCH on this pair of chipsets is notoriously incoherent, so the GPU is almost certainly going to hang at some point, though unlikely to hang the system and should automatically disable acceleration (and thence behave identically as if the acceleration was disabled from the start). Option NoAccel can be used to disable all 2D acceleration and Option DRI can be used to disable all 3D acceleration.”
To some surprise when waking up this morning, it turns out that they think they have finally countered the i830GM/845G stability issues once and for all.
Chris Wilson began the announcement for today’s xf86-video-intel 2.20.16 release by rejoicing over this old Brookdale chipset support finally being stabilized. By making a small change, they discovered they can actually provide stable support for this hardware that is painstakingly slow by today’s standards.
Rejoice! We have found a trick to make 830gm/845g stable at long last. Ever since the switch to GEM and dynamic video memory, those early second generation chipsets have been [u]plagued by instability[/u]. The lack of flushing cachelines from the CPU to GMCH was eventually solved by using an undocmented bit, but 830/845 were [u]still hanging under memory pressure[/u]. These deaths were all due to garbage finding its way into the command streamer, and they go away if we take a leaf out of the original driver and never reuse those pages for anything else. So for the first time ever, I have been able to complete running the test suite on an 845g, even whilst thrashing the page and buffer caches!
Other changes to the weekend release of xf86-video-intel 2.20.16 include running the SF stage as a single-thread for “Gen4” hardware to workaround some bugs, scanout fixes for Gen6/Gen7, tune batch flushing, and a handful of other fixes.
As usual, Intel’s Chris Wilson continues to be the dominant developer working on this 2D X.Org driver with him taking responsibility for 53 of the changes in this latest point release while Jesse Barnes was the only other contributor with just one change.[/quote]