Tu confonds encore. Selon ton dernier post, on parlait de la mise en état hors-interruption, pas de l'opération qui la nécessite. Pour faire simple : L'opération assurant l'atomicité d'une transaction n'a pas besoin d'être elle-même atomique (car elle ne fait pas partie implicite de la transaction). Donc :
1) Tu inhibes les interruptions avec le nombre d'instructions que tu veux (et qui peuvent donc être interrompues).
2) À l'issue du point précédent, les interruptions ont été inhibées. Peu importe à quel moment, l'état est garanti à la frontière entre 1) et 2). Tu fais ton opération atomique (ton lock ou n'importe quoi d'autre) en utilisant à nouveau le nombre d'instructions qui te chante.
3) Tu réactives les interruptions.
Il ne s'agissait pas non plus d' « ajouter » un transistor. Tous les microprocesseurs huit bits, à ma connaissance, sont capables d'inhiber les interruptions eux-mêmes et en une seule opération, ce qui les rend en principe éligibles à la mise en ½uvre de systèmes d'exploitation évolués, selon tes critères. L'exemple donné mettait en lumière le fait que même dans le pire des cas (CPU dépourvu de cette simple fonctionalité), il est parfaitement possible de garantir l'atomicité recherchée.
Je maintiens que c'est du jargon. Le jour ou les articles concernant l'informatique seront écrits en bon français sans aucun jargon, fais moi signe.
Ce n'est pas une raison. Ils le seront quand ceux qui les écrivent feront l'effort.
il faut quand même qu'il y ait un moyen de le faire de façon non-interruptible sinon le serpent se mors la queue et tu limites juste les risques.
Tous les microprocesseurs, même les plus anciens, savent faire cela en une opération et l'inhibition des IRQ est faite en interne, mais cela n'est même pas nécessaire. Si, par exemple, tu mets en place un système d'inhibition en tamponnant la ligne d'IRQ avec un transistor dont la base est attaquée par un port, tu n'as pas besoin d'une opération atomique pour activer la bonne ligne. Une interruption peut avoir lieu pendant que tu récupères l'état du port, se dérouler normalement et te rendre la main pour que tu modifies le bit qui t'intéresse et mette le port à jour. L'atomicité de l'exécution débute au moment où la ligne est mise à l'état adéquat. C'est d'ailleurs le principe de toute transaction.
Supporter est du jargon informatique. C'est marrant, supporter te gêne et pas CPU ...
CPU est un sigle pour « Central Processing Unit ». La seule chose incorrecte à la limite, c'est l'emploi du masculin à la place du féminin, par rapprochement avec « microprocesseur », masculin lui aussi.
« Supporter », ce n'est pas du jargon, c'est une faute de français, et c'est également très laid. C'est une traduction ridicule et mot-à-mot de « to support », qui ne signifie pas la même chose du tout. Et surtout, si cela passe à la limite en français parce qu'on est inondé de termes techniques anglo-saxons, ce n'est absolument pas réversible. Le sens français ne passera absolument pas en anglais en utilisant « to support ».
Ce serait à la limite du jargon si les gens se souvenaient encore d'où cela vient, et surtout que ce n'est pas du tout français. Notre langue est suffisamment riche pour que l'on se permette d'utiliser les termes consacrés, surtout quand ils ont toujours existé. Invoquer le jargon, c'est essayer de justifier une mauvaise habitude plutôt que la pallier.
Même si la quasi-totalité du système est écrite en C, au final c'est bien en assembleur que les instructions sont traduites et il faut donc que le CPU supporte des fonctions essentielles comme, par exemple, un équivalent de l'instruction TAS ( Test And Set ) pour pouvoir implementer des mecanismes de lock
Visiblement cela ne passe pas, donc je développe : Cela ne change absolument rien. D'une part, les locks ne sont en aucun cas gérés par le langage C lui-même, et d'autre part, la seule chose dont le C fasse fortement usage est le système de pile (qui peut même être implémenté à partir de rien à partir du moment où tu peux faire un adressage indexé). Les logiciels écrits en C, notamment Linux, ne sont donc pas du tout censés être articulés autour d'une spécificité d'un microprocesseur donné.
Pour TAS, cette fonction n'existe pas en une seule instruction sur i386. D'une manière générale, si tu as besoin d'effectuer une opération atomique, tu vires les interruptions, tu fais ton travail et tu les réactives. Évidement, avoir une instruction indivisible par essence est cent fois plus efficace, surtout qu'un programme en mode utilisateur qui aurait besoin de faire ce genre de chose devrait demander la permission au noyau, mais c'est nullement une condition vitale pour en écrire un, et heureusement : avec ce genre ce raisonnement, on n'aurait jamais connu Unix en 1970, ni même l'essor du RISC.
integre un MMU et aît pas mal d'autres fonctionalités comme la possibilité d'adresser une taille mémoire suffisante pour au moins pouvoir booter le kernel.
Déjà, j'ai l'impression que pas mal de monde confond les MMUs en général et le mode protégé (comme on l'appelle chez Intel) en particulier.
La principale tâche d'une MMU est la résolution d'adresses virtuelles en adresses physiques. Un tel circuit n'a absolument pas besoin de se trouver embarqué dans le CPU lui-même pour fonctionner. Le système de banques mémoire, par exemple, était extrêmement répandu sur les 8 bits.
Pour la protection des pages, là encore, même s'il est beaucoup plus pratique de l'embarquer, le système peut très bien être externalisé. Un contrôleur de bus peut très bien bloquer la transmission d'un accès et envoyer un signal d'interruption au processeur, qui lui peut même se permettre de l'ignorer superbement sans que l'intégrité du système soit compromise un instant.
Dans tous les cas, non seulement sa gestion ne relève pas de l'assembleur en particulier, mais cela ne relève même pas intrinsèquement du langage C. C'est une fonction qui consiste à aller déposer une table quelque part en mémoire et qui peut être réalisée par n'importe quel moyen.
Pour la taille mémoire, si tu relis mon commentaire, tu t'apercevras que c'est mon argument principal. Pour la manière dont elle est agencée, c'est au compilateur C de s'en accomoder.
Ensuite, ce n'est certainement pas au CPU qu'il manque des fonctionnalités. Étant donné que la quasi-totalité du système est écrite en C, je suis tenté de dire que la seule chose que l'on demande au microprocesseur est de donner la possibilité d'implémenter une pile. Le reste se fait tout seul, et les pilotes pour les différents types de matériels ne réclameront pas des centaines de kilo-octets.
En revanche, c'est l'absence d'une mémoire conséquente qui fera le plus défaut au système. Si en plus, celui-ci ne peut pas se rabattre non plus sur un disque dur, je crains qu'il faille abandonner l'idée d'un système d'exploitation générique sur les vieilles machines.
Voir plutôt ce qui se fait avec OS-9 par exemple, un peu plus haut.
fd = open ("/dev/ttys0",O_RDWR)
if (fd>=0)
{
write (fd,"Bonjour\n",8);
close (fd);
}
return 0;
}
Tout ce que tu écriras et lira vers les fichiers /dev/ttyS0 et /dev/ttyS1 iront et proviendront en fait du port série. C'est cool UNIX, non ?
Bon après, il te faudra ouvrir le tout en bloquant ou non-bloquant, faire les réglages du ports, etc. Il faudra jouer avec termios, fcntl, ioctl, et toutes ces bizzarrerie mais chaque chose en son temps.
Les bibliothèques partagées en C sont les fichiers "*.so" (Shared Object)
Elles vont la plupart du temps dans /usr/lib.
Regarde le contenu du fichier /etc/ld.so.conf . Il contient la liste des répertoires dont le contenu sera maintenu en cache par le loader dynamique. Tous ces répertoires sont réputés contenir des bibliothèques, mais d'une manière générale, sous UNIX, la variable d'ennvironnement LD_LIBRARY_PATH te donne la liste des répertoires qui seront explorées lors du chargement (de la même façon que PATH te donne la liste des réps qui doivent contenir des exécutables).
Pour ajouter une lib et la rendre disponible, il suffit de la déposer dans un de ces répertoires (et accessoirement de relancer ldconfig pour mettre à jour le cache).
Ca c'est pour les bibliothèques dynamiques (les DLL, quoi). Si c'est pour les utiliser pendant une compilation, tu auras également besoin des *.h qui disent à ton programme comment on les utilise. Habituellement c'est /usr/include
En supposant que ta question n'était pas "comment on crée une DLL sous Linux" ni ne concernait les bibliothèques statiques ...
Pour mémoire i2bp fut une société à vapoware qui promettait (au temps de la bulle internet) de transporter de la vidéo (640x480 25fps) dans un débit de 2Ko/s
Si ta question, c'est "je cherche un crack pour pirater le réseau de ma FAC", alors à priori non , il n'y en a pas. C'est même tout l'intérêt du système. Il faudra à la place exploiter les failles de sécurité.
Maintenant, si tu veux faire de la vraie maintenance, la plupart du temps cela relève des droits d'accès plus que de la structure de l'application.
Par exemple, la gestion des partitions d'un disque, donc tu parlais plus haut, se fait en gérant la table des partitions qui se trouve sur le premier secteur (le MBR) du disque lorsque c'est un IDE. Il suffit de donner les droits d'accès avec un "chmod" sur " /dev/hd* " pour que l'utilisateur lambda ait le droit de le faire. Bon, dans ce cas précis, ce n'est pas tout-à-fait vrai car il faut en plus demander au système de relire la table et ça, cela peut demander les privilèges du super-user.
Mais dans tous les cas, l'objectif à atteindre est de se passer au maximum des droits root.
Un truc vraiment bête, ce serait qu'un utilisateur choisisse consciencieusement un mot de passe avec plein de caractères exotiques, et qu'il tombe par accident sur la somme MD5 de "toto" ! :-)
coûtant ainsi des milliers de dollars à l'administrateur système par les surcoûts en bande passante occasionnés.
En même temps, à chaque fois que l'administrateur en question estime ou prévoit d'atteindre un millier de dollars, il pourrait peut-être envisager de remplacer un de ses modem-routeurs :-)
Une chose est sûre, tu vas perdre quelques données mais probablement pas le disque entier.
Ces messages indiquent des secteurs défectueux au bas niveau sur le disque, si bien que même le contrôleur DMA, l'électronique du disque qui se charge d'aller chercher les secteurs tout seul, comme un grand et sans directive de la part du CPU, ne peut plus les lire. Cela est dû au fait que les informations inter-secteurs qui permettent au contrôleur disque de savoir où il se trouve sur une piste sont devenues incorrectes.
Évidement, on comprend que le meilleur cas de figure pour que cela arrive, c'est une coupure de courant au moment où l'électronique du disque est en train de les mettre à jour.
Vu de l'extérieur, l'IDE ou le SCSI faisant abstraction de ces informations et ne présentant que les secteurs eux-mêmes, les formattages traditionnels s'y cassent les dents puisque ceux-ci ne s'occupent que de remplir les secteurs et pas de les construire. La plupart des gens pensent donc que le disque est physiquement endommagé alors qu'un formattage de bas niveau suffit à leur redonner leur jeunesse d'antan.
Malheureusement, depuis que les disquettes sont tombées en désuétude, beaucoup de gens confondent formattages de bas niveau et de haut niveau avec formattage de haut niveau (remplir les secteurs existants avec des zéros) et reconstruction du système de fichiers (qui suffit à présenter un disque comme vide même s'il reste des infos dans les secteurs).
Donc, pour réparer ton disque, il faut trouver l'utilitaire de formattage de bas niveau de ton disque, qui est propre à chaque constructeur (c'est à ça que sert une couche d'abstraction), et si possible isoler et ne formatter que les pistes défectueuses.
Sinon, il faut trouver de la place quelque part, backuper le contenu du disque avec dd en ignorant les erreurs (enfin il faut vérifier que dd remplace les secteurs défectueux par des 00 00), puis procéder là aussi à un formattage de bas-niveau sur la totalité du disque, puis reconstruire.
Bref, c'est pas forcément TRÈS compliqué en soi, mais c'est assez contraignant et il faut avoir un peu de connaissances. Mais au moins, tu devrais pouvoir conserver ton hardware.
[^] # Re: Deadlock
Posté par Obsidian . En réponse au message Linux pour Amstrad CPC-6128+. Évalué à 2.
Non.
Tu confonds encore. Selon ton dernier post, on parlait de la mise en état hors-interruption, pas de l'opération qui la nécessite. Pour faire simple : L'opération assurant l'atomicité d'une transaction n'a pas besoin d'être elle-même atomique (car elle ne fait pas partie implicite de la transaction). Donc :
1) Tu inhibes les interruptions avec le nombre d'instructions que tu veux (et qui peuvent donc être interrompues).
2) À l'issue du point précédent, les interruptions ont été inhibées. Peu importe à quel moment, l'état est garanti à la frontière entre 1) et 2). Tu fais ton opération atomique (ton lock ou n'importe quoi d'autre) en utilisant à nouveau le nombre d'instructions qui te chante.
3) Tu réactives les interruptions.
Il ne s'agissait pas non plus d' « ajouter » un transistor. Tous les microprocesseurs huit bits, à ma connaissance, sont capables d'inhiber les interruptions eux-mêmes et en une seule opération, ce qui les rend en principe éligibles à la mise en ½uvre de systèmes d'exploitation évolués, selon tes critères. L'exemple donné mettait en lumière le fait que même dans le pire des cas (CPU dépourvu de cette simple fonctionalité), il est parfaitement possible de garantir l'atomicité recherchée.
[^] # Re: Et non ...
Posté par Obsidian . En réponse au message Linux pour Amstrad CPC-6128+. Évalué à 2.
Ce n'est pas une raison. Ils le seront quand ceux qui les écrivent feront l'effort.
Tous les microprocesseurs, même les plus anciens, savent faire cela en une opération et l'inhibition des IRQ est faite en interne, mais cela n'est même pas nécessaire. Si, par exemple, tu mets en place un système d'inhibition en tamponnant la ligne d'IRQ avec un transistor dont la base est attaquée par un port, tu n'as pas besoin d'une opération atomique pour activer la bonne ligne. Une interruption peut avoir lieu pendant que tu récupères l'état du port, se dérouler normalement et te rendre la main pour que tu modifies le bit qui t'intéresse et mette le port à jour. L'atomicité de l'exécution débute au moment où la ligne est mise à l'état adéquat. C'est d'ailleurs le principe de toute transaction.
[^] # Re: Et non ...
Posté par Obsidian . En réponse au message Linux pour Amstrad CPC-6128+. Évalué à 2.
CPU est un sigle pour « Central Processing Unit ». La seule chose incorrecte à la limite, c'est l'emploi du masculin à la place du féminin, par rapprochement avec « microprocesseur », masculin lui aussi.
« Supporter », ce n'est pas du jargon, c'est une faute de français, et c'est également très laid. C'est une traduction ridicule et mot-à-mot de « to support », qui ne signifie pas la même chose du tout. Et surtout, si cela passe à la limite en français parce qu'on est inondé de termes techniques anglo-saxons, ce n'est absolument pas réversible. Le sens français ne passera absolument pas en anglais en utilisant « to support ».
Ce serait à la limite du jargon si les gens se souvenaient encore d'où cela vient, et surtout que ce n'est pas du tout français. Notre langue est suffisamment riche pour que l'on se permette d'utiliser les termes consacrés, surtout quand ils ont toujours existé. Invoquer le jargon, c'est essayer de justifier une mauvaise habitude plutôt que la pallier.
Visiblement cela ne passe pas, donc je développe : Cela ne change absolument rien. D'une part, les locks ne sont en aucun cas gérés par le langage C lui-même, et d'autre part, la seule chose dont le C fasse fortement usage est le système de pile (qui peut même être implémenté à partir de rien à partir du moment où tu peux faire un adressage indexé). Les logiciels écrits en C, notamment Linux, ne sont donc pas du tout censés être articulés autour d'une spécificité d'un microprocesseur donné.
Pour TAS, cette fonction n'existe pas en une seule instruction sur i386. D'une manière générale, si tu as besoin d'effectuer une opération atomique, tu vires les interruptions, tu fais ton travail et tu les réactives. Évidement, avoir une instruction indivisible par essence est cent fois plus efficace, surtout qu'un programme en mode utilisateur qui aurait besoin de faire ce genre de chose devrait demander la permission au noyau, mais c'est nullement une condition vitale pour en écrire un, et heureusement : avec ce genre ce raisonnement, on n'aurait jamais connu Unix en 1970, ni même l'essor du RISC.
Déjà, j'ai l'impression que pas mal de monde confond les MMUs en général et le mode protégé (comme on l'appelle chez Intel) en particulier.
http://en.wikipedia.org/wiki/Memory_management_unit
La principale tâche d'une MMU est la résolution d'adresses virtuelles en adresses physiques. Un tel circuit n'a absolument pas besoin de se trouver embarqué dans le CPU lui-même pour fonctionner. Le système de banques mémoire, par exemple, était extrêmement répandu sur les 8 bits.
Pour la protection des pages, là encore, même s'il est beaucoup plus pratique de l'embarquer, le système peut très bien être externalisé. Un contrôleur de bus peut très bien bloquer la transmission d'un accès et envoyer un signal d'interruption au processeur, qui lui peut même se permettre de l'ignorer superbement sans que l'intégrité du système soit compromise un instant.
Dans tous les cas, non seulement sa gestion ne relève pas de l'assembleur en particulier, mais cela ne relève même pas intrinsèquement du langage C. C'est une fonction qui consiste à aller déposer une table quelque part en mémoire et qui peut être réalisée par n'importe quel moyen.
Pour la taille mémoire, si tu relis mon commentaire, tu t'apercevras que c'est mon argument principal. Pour la manière dont elle est agencée, c'est au compilateur C de s'en accomoder.
[^] # Re: Et non ...
Posté par Obsidian . En réponse au message Linux pour Amstrad CPC-6128+. Évalué à 4.
« Supporter », dans ce sens-ci, n'est pas français ! Dites « prendre en charge », « reconnaître » ou « soutenir », selon les cas. http://linuxfr.org/comments/620840.html#620840 .
Ensuite, ce n'est certainement pas au CPU qu'il manque des fonctionnalités. Étant donné que la quasi-totalité du système est écrite en C, je suis tenté de dire que la seule chose que l'on demande au microprocesseur est de donner la possibilité d'implémenter une pile. Le reste se fait tout seul, et les pilotes pour les différents types de matériels ne réclameront pas des centaines de kilo-octets.
En revanche, c'est l'absence d'une mémoire conséquente qui fera le plus défaut au système. Si en plus, celui-ci ne peut pas se rabattre non plus sur un disque dur, je crains qu'il faille abandonner l'idée d'un système d'exploitation générique sur les vieilles machines.
Voir plutôt ce qui se fait avec OS-9 par exemple, un peu plus haut.
[^] # Re: Ca existe? -> OS9
Posté par Obsidian . En réponse au message Linux pour Amstrad CPC-6128+. Évalué à 5.
Les premiers tests ont été très prometteurs.
http://os9.forler.ch/
[^] # Re: libs
Posté par Obsidian . En réponse au message ajouter une library. Évalué à 2.
La seule fois où je l'ai fait, ce fut un mauvais présage, donc je me restreins maintenant aux lignes de codes ... :-) Sinon, c'est par ici :
http://www.google.fr/search?hl=fr&q=Chiromancie&btnG(...)
[^] # Re: héhé
Posté par Obsidian . En réponse au journal Une nouvelle méthode de développement révolutionnaire !. Évalué à 2.
« Oublie les vieux travaux et laisse les nouveaux devenir vieux. »
# Commandement numéro un : " Tout est fichier "
Posté par Obsidian . En réponse au message port serie. Évalué à 2.
int main (void)
{
int fd;
fd = open ("/dev/ttys0",O_RDWR)
if (fd>=0)
{
write (fd,"Bonjour\n",8);
close (fd);
}
return 0;
}
Tout ce que tu écriras et lira vers les fichiers /dev/ttyS0 et /dev/ttyS1 iront et proviendront en fait du port série. C'est cool UNIX, non ?
Bon après, il te faudra ouvrir le tout en bloquant ou non-bloquant, faire les réglages du ports, etc. Il faudra jouer avec termios, fcntl, ioctl, et toutes ces bizzarrerie mais chaque chose en son temps.
En attendant : man stty is good for you.
# libs
Posté par Obsidian . En réponse au message ajouter une library. Évalué à 3.
Elles vont la plupart du temps dans /usr/lib.
Regarde le contenu du fichier /etc/ld.so.conf . Il contient la liste des répertoires dont le contenu sera maintenu en cache par le loader dynamique. Tous ces répertoires sont réputés contenir des bibliothèques, mais d'une manière générale, sous UNIX, la variable d'ennvironnement LD_LIBRARY_PATH te donne la liste des répertoires qui seront explorées lors du chargement (de la même façon que PATH te donne la liste des réps qui doivent contenir des exécutables).
Pour ajouter une lib et la rendre disponible, il suffit de la déposer dans un de ces répertoires (et accessoirement de relancer ldconfig pour mettre à jour le cache).
Ca c'est pour les bibliothèques dynamiques (les DLL, quoi). Si c'est pour les utiliser pendant une compilation, tu auras également besoin des *.h qui disent à ton programme comment on les utilise. Habituellement c'est /usr/include
En supposant que ta question n'était pas "comment on crée une DLL sous Linux" ni ne concernait les bibliothèques statiques ...
# C'était en 2001 !
Posté par Obsidian . En réponse au journal Le retour d'I2BP ?. Évalué à 3.
Putain ! 5 ans !
[^] # Re: 50 Mo
Posté par Obsidian . En réponse au journal Le retour d'I2BP ?. Évalué à 5.
Par contre il faut 27Go d'espace libre pour installer le codec :-)
[^] # Re: Dommage...
Posté par Obsidian . En réponse au journal Le retour d'I2BP ?. Évalué à 10.
[^] # Re: meuh
Posté par Obsidian . En réponse au journal Où créer son blog ?. Évalué à 4.
http://www.bide-et-musique.com/song/4076.html
[^] # Re: Méthode de developpement
Posté par Obsidian . En réponse au message Application root. Évalué à 2.
Maintenant, si tu veux faire de la vraie maintenance, la plupart du temps cela relève des droits d'accès plus que de la structure de l'application.
Par exemple, la gestion des partitions d'un disque, donc tu parlais plus haut, se fait en gérant la table des partitions qui se trouve sur le premier secteur (le MBR) du disque lorsque c'est un IDE. Il suffit de donner les droits d'accès avec un "chmod" sur " /dev/hd* " pour que l'utilisateur lambda ait le droit de le faire. Bon, dans ce cas précis, ce n'est pas tout-à-fait vrai car il faut en plus demander au système de relire la table et ça, cela peut demander les privilèges du super-user.
Mais dans tous les cas, l'objectif à atteindre est de se passer au maximum des droits root.
[^] # Re: Explication simple
Posté par Obsidian . En réponse au journal Quelle place pour les OS libres dans les très grandes entreprises ?. Évalué à 2.
Scénario 3 : "Ok on prend Microsoft Windows"
un jour : itou
Réponse "Fermez toutes les applications et redémarrez votre cluster. Si le problème persiste, contactez votre revendeur informatique."
Cela ne l'a jamais empêché de se vendre, même de force, d'ailleurs ...
[^] # Re: Cosmocats
Posté par Obsidian . En réponse au journal Du copyright en cinema - Les brigades du tigre. Évalué à 10.
[^] # Re: Méthodologie ?
Posté par Obsidian . En réponse au journal Combien de temps faut-il pour cracker un mot de passe ?. Évalué à 2.
# En shell ...
Posté par Obsidian . En réponse au message Traiter un fichier sur deux ?. Évalué à 3.
$ ./commande *[13579].png
Sinon
echo *.png | while read i j ; do ./commande $i ; done
Ca devrait suffire.
[^] # Re: Mauvais routeurs, changer routeurs ?
Posté par Obsidian . En réponse au journal D-Link sabote les protocoles de l'Internet. Évalué à 2.
Le pire, c'est que j'avais déjà eu vent de cette histoire et je n'ai même pas fait le rapprochement. 'faut que je me couche plus tôt, moi ...
[^] # Re: meuh
Posté par Obsidian . En réponse au journal Où créer son blog ?. Évalué à 8.
Ben pas sur skyblog en tout cas ! :-)
[^] # Re: Quelle perte de temps...
Posté par Obsidian . En réponse au journal D-Link sabote les protocoles de l'Internet. Évalué à 10.
Merci pour lui parce qu'en ce moment, il doit plutôt être vidé ...
# Mauvais routeurs, changer routeurs ?
Posté par Obsidian . En réponse au journal D-Link sabote les protocoles de l'Internet. Évalué à -5.
En même temps, à chaque fois que l'administrateur en question estime ou prévoit d'atteindre un millier de dollars, il pourrait peut-être envisager de remplacer un de ses modem-routeurs :-)
# Port 25 ?
Posté par Obsidian . En réponse au journal Port 25 - Le site opensource de MS. Évalué à 10.
[^] # Re: Hotline
Posté par Obsidian . En réponse au journal apu google ?. Évalué à 6.
# Peut-être un espoir
Posté par Obsidian . En réponse au message crash hda. Évalué à 4.
Ces messages indiquent des secteurs défectueux au bas niveau sur le disque, si bien que même le contrôleur DMA, l'électronique du disque qui se charge d'aller chercher les secteurs tout seul, comme un grand et sans directive de la part du CPU, ne peut plus les lire. Cela est dû au fait que les informations inter-secteurs qui permettent au contrôleur disque de savoir où il se trouve sur une piste sont devenues incorrectes.
Évidement, on comprend que le meilleur cas de figure pour que cela arrive, c'est une coupure de courant au moment où l'électronique du disque est en train de les mettre à jour.
Vu de l'extérieur, l'IDE ou le SCSI faisant abstraction de ces informations et ne présentant que les secteurs eux-mêmes, les formattages traditionnels s'y cassent les dents puisque ceux-ci ne s'occupent que de remplir les secteurs et pas de les construire. La plupart des gens pensent donc que le disque est physiquement endommagé alors qu'un formattage de bas niveau suffit à leur redonner leur jeunesse d'antan.
Malheureusement, depuis que les disquettes sont tombées en désuétude, beaucoup de gens confondent formattages de bas niveau et de haut niveau avec formattage de haut niveau (remplir les secteurs existants avec des zéros) et reconstruction du système de fichiers (qui suffit à présenter un disque comme vide même s'il reste des infos dans les secteurs).
Donc, pour réparer ton disque, il faut trouver l'utilitaire de formattage de bas niveau de ton disque, qui est propre à chaque constructeur (c'est à ça que sert une couche d'abstraction), et si possible isoler et ne formatter que les pistes défectueuses.
Sinon, il faut trouver de la place quelque part, backuper le contenu du disque avec dd en ignorant les erreurs (enfin il faut vérifier que dd remplace les secteurs défectueux par des 00 00), puis procéder là aussi à un formattage de bas-niveau sur la totalité du disque, puis reconstruire.
Bref, c'est pas forcément TRÈS compliqué en soi, mais c'est assez contraignant et il faut avoir un peu de connaissances. Mais au moins, tu devrais pouvoir conserver ton hardware.