Sous Linux quand le driver X de la carte se croûte, c'est reboot.
a) Ca dépend quelle partie du driver, si c'est la partie initialisation/selection de mode oui on risque le kernel panic. Par contre si c'est la partie affichage/acceleration et que le pilote n'est pas codé avec les pieds le kernel survivra sans probléme.
b) Neuf fois sur dix, même si c'est la partie "sensible" qui crashe on peut récupérer le système au vol, par exemple si on a une seconde carte graphique ou en se connectant sur un TTY ou via SSH. Le crash d'un module n'entrainne pas forcément la panique du kernel (et heureusement).
c) Quand la partie accéléré se vautre (c'est à dire quand le kernel expose directement des segments mémoires physiques à une appli) là c'est le drame. Mais c'est le drame pareil sous Windows que sous Linux. Et la raison est simple : un programme est en train d'essayer d'écrire dans un segment physique qui n'existe pas ou qui est en erreur. Et ca c'est très mauvais signe.
Sous Windows, ça survit bien si ca s'est vautré dans la partie userspace du module. Tu as un lien en bas de la page wikipedia qui t'explique comment ça marche chez Microsoft.
Et bien si on va sur cette page MSDN on y voit les informations suivantes :
Prior to Windows Vista, graphics memory was reported by the graphics driver as a single number through the Display applet in the control panel. Some legacy APIs exposed two types of memory: local and non-local. However, these numbers were selected by the driver and were mostly inaccurate.
WDDM manages the virtualization of graphics memory in itself and also ensures accurate reporting of various aspects of graphics memory.
En d'autres termes, avant les pilotes de cartes graphiques géraient les informations de mappage mémoires eux-même. Notament la ségrégation entre la mémoire sur la carte et la mémoire réclamée en dehors de la carte, maintenant ils doivent filer toutes les infos à WDDM et c'est lui qui fait la gestion. Mais le pilote lui même est toujours en kernelspace.
Tout ce qui se passe c'est que maintenant ce n'est plus la carte graphique qui expose elle même sa mémoire sur le segment de son choix. Dorénnavant elle indique au kernel quel segment elle a réservé et c'est le kernel qui l'expose soit en direct pour les fonctions accélérés haut niveau, soit via WDDM pour le reste.
Donc on a toujours un pilote en pur kernelspace, mais on a une interface userspace (en l'occurence WDDM) pour accéder de façon rapide à un ensemble réduit de fonctionnalités de la CG.
C'est en ca que c'est très proche d'un framebuffer ou d'une interface VESA+. On a un segment de mémoire qui est mappé en kernelspace par le noyeau. Sauf qu'avant on pouvait aller écrire dedans depuis le userspace comme dans n'importe quel autre segment mémoire exposé - et que maintenant il faut utiliser l'API WDDM. Donc avant on crashait un segment mémoire du kernelspace (et donc panique) et maintenant on plante l'interface WDDM (ce qui est nettement moins grave). A noter que en VESA+ (c'est à dire en VESA virtualisé avec un roud trip par le kernel à chaque appel) on a un comportement similaire, si on fait n'importequoi on se retrouve juste avec un segment de mémoire virtuelle qui n'est plus copiable dans les buffers de la carte graphique - c'est grosso-modo le même genre de séurité que WDDM (sauf qu'on a pas d'API, juste un map mémoire). Malheuresement VESA+ n'est plus supporté par aucune carte en natif… Dommage j'aimais bien le 512x384 en 16bits…
[^] # Re: +1000
Posté par Kaane . En réponse au journal Il y a 15 ans, j'ai fondé LinuxFr. Évalué à 3.
Sous Linux quand le driver X de la carte se croûte, c'est reboot.
a) Ca dépend quelle partie du driver, si c'est la partie initialisation/selection de mode oui on risque le kernel panic. Par contre si c'est la partie affichage/acceleration et que le pilote n'est pas codé avec les pieds le kernel survivra sans probléme.
b) Neuf fois sur dix, même si c'est la partie "sensible" qui crashe on peut récupérer le système au vol, par exemple si on a une seconde carte graphique ou en se connectant sur un TTY ou via SSH. Le crash d'un module n'entrainne pas forcément la panique du kernel (et heureusement).
c) Quand la partie accéléré se vautre (c'est à dire quand le kernel expose directement des segments mémoires physiques à une appli) là c'est le drame. Mais c'est le drame pareil sous Windows que sous Linux. Et la raison est simple : un programme est en train d'essayer d'écrire dans un segment physique qui n'existe pas ou qui est en erreur. Et ca c'est très mauvais signe.
Sous Windows, ça survit bien si ca s'est vautré dans la partie userspace du module. Tu as un lien en bas de la page wikipedia qui t'explique comment ça marche chez Microsoft.
Et bien si on va sur cette page MSDN on y voit les informations suivantes :
En d'autres termes, avant les pilotes de cartes graphiques géraient les informations de mappage mémoires eux-même. Notament la ségrégation entre la mémoire sur la carte et la mémoire réclamée en dehors de la carte, maintenant ils doivent filer toutes les infos à WDDM et c'est lui qui fait la gestion. Mais le pilote lui même est toujours en kernelspace.
Tout ce qui se passe c'est que maintenant ce n'est plus la carte graphique qui expose elle même sa mémoire sur le segment de son choix. Dorénnavant elle indique au kernel quel segment elle a réservé et c'est le kernel qui l'expose soit en direct pour les fonctions accélérés haut niveau, soit via WDDM pour le reste.
Donc on a toujours un pilote en pur kernelspace, mais on a une interface userspace (en l'occurence WDDM) pour accéder de façon rapide à un ensemble réduit de fonctionnalités de la CG.
C'est en ca que c'est très proche d'un framebuffer ou d'une interface VESA+. On a un segment de mémoire qui est mappé en kernelspace par le noyeau. Sauf qu'avant on pouvait aller écrire dedans depuis le userspace comme dans n'importe quel autre segment mémoire exposé - et que maintenant il faut utiliser l'API WDDM. Donc avant on crashait un segment mémoire du kernelspace (et donc panique) et maintenant on plante l'interface WDDM (ce qui est nettement moins grave). A noter que en VESA+ (c'est à dire en VESA virtualisé avec un roud trip par le kernel à chaque appel) on a un comportement similaire, si on fait n'importequoi on se retrouve juste avec un segment de mémoire virtuelle qui n'est plus copiable dans les buffers de la carte graphique - c'est grosso-modo le même genre de séurité que WDDM (sauf qu'on a pas d'API, juste un map mémoire). Malheuresement VESA+ n'est plus supporté par aucune carte en natif… Dommage j'aimais bien le 512x384 en 16bits…