Alors la je plussoie violament la remarque precedante.
Est-ce que je suis sûr que je ne vais pas écraser une donnée qui a été mise précédemment dans le registre ax par le compilateur C ?
C'est quasi certain que tu l'ecrase oui, l'assembleur inline n'est pas encadré par des push/pop. Pour le voir demande a gcc de generer et laisser le code pseudo-assembleur du code en C pour voir ca.
... ça plante sur un segfault, et je ne sais absolument pas pourquoi ! Pire encore, je ne sais pas comment je peux le savoir ! J'ai vérifié que les I/O de la carte étaient activées dans le BIOS, mais malgré tout, dès que j'appelle l'interruption, boum, plantage...
Sous linux l'espace memoire est partagé en deux, user et kernel. Le user-space n'as aucun acces direct au ressource physique du systeme, aucun acces au hard ou a la memoire il doit passer par le kernel pour demander l'acces ou les operation permise(par un driver).
Sur toutes les machines, quand on execute un programme en espace user la tentative d'utilisation des certaines instructions assembleurs provoque un exeception qui se traduit ensuite par un segfault, c'est typiquement ce qu'il se passe quand tu fais asm("int $0x15");
int est une instruction du mode protégé qui ne peut pas etre executé quand le run-level du proc est "user".
Si tu veut plus d'info sur le driver a ecrire post dans le forum kernel
Pour voir les options de compilation du kernel en cours d'utilisation il suffit de faire
gunzip /proc/config.gz |less
il faut regarder sur des nom contenant pcap ou packet ou PF_
je ne peut pas t'en dire plus, désolé
mais un peut éloigné, c'est plutot normal qu'une interface bsd ne soit pas presente sous linux.
Je te suggere par contre de verifier que ton kernel est configurer avec l'option tcp/ip CONFIG_FILTER de mise
et que la lib: libpcap est bien installée sur ton systeme.
La commande mknod ne sert a rien si derriere il n'y as pas de partie du kernel qui feras la gestion du inode créer.
je pense que tu confond contenu et forme. Le tableau suivant
(1) char Array[] ={0x33,0x36,0x37};
et
(2)char Array[]={'3','6','7'};
sont strictement egaux, dans un cas j'ecris le contenu en hexa et dans l'autre en ascii, mais d'un point de vue binaire le resultat de la compilation est strictement identique
A ne pas faire :
char Array[] ={"0x33","0x36","0x37"};
Donc remplis ton tableau dans la forme que tu veut mais a mon avis c'est la forme (1) qui est le plus simple
Bon, sur l'usb il existe plusieurs facon de communiquer, ces packet sont de type
-interrupt (non-géré par libusb)
-bulk
-isochrone
-control
Les packet control sont normaliser pour certain services (pour l'enumeration et deux ou trois operations diverse) c'est bien rare de les utiliser en foncionnelle.
Les packet bulk sont des packet destiné a un endpoint (in ou out), le out est une emission du pc vers le device, le in une lecture du device vers le pc.
donc
int usb_bulk_write(usb_dev_handle *dev, int ep, char *bytes, int size, int timeout);
*dev :le handle du device que tu recupere à l'ouverture
ep : le numeral du endpoint sur lequel ce fait l'operation
*bytes : pointeur sur les données a recevoir ou le tableau de reception
syze : la taille a recevoir ou a emettre
timeout : un temps en milli second sans doute d'attente de la fin d'operation.
Les packet interrupt sont cycliquement emis du device vers le PC (ceci est une approximation du mechanisme !)
Les packet isochrone sont destiné a la transmission rapide de donné sans garanti de reception (typiquement je pense que les images de la CAM utiliseront de l'isochrone)
Les composants electronique ont une gamme de temperature de fonctionnement externe (en general 0-70°C pour la gamme commercial) et un point de disfonctionnement interne du silicium au alentour de 125°C (ca c'est donc a l'interieur du composants lui meme). De plus leur caracteristique de fonctionnement (temps de commutation, consomation electrique) varie en fonction de la temperature dans les fouchette haute et basse de doc constructeur.
La plupart des defaillances sont des comportements en sur-intensité (pour finir finalement en cours-circuit) et donc provoque une elevation de temperature des composants, en les refroidissant on change leur point de fonctionnement puis il rechauffe et ainsi de suite.
je crois que pour choisir une carte wifi il faut :
acheter une carte dont les specs sont clairement marqué sur le site vendeur et demander verification au service technique de la version de la carte
ou
aller dans la boutique avec un portable demander au vendeur d'ouvrir la boite pour voir si la carte fonctionne sous linux
une idée comme ca, le driver realteck date de septembre 2006, ton kernel de mars 2007, je pense que tes soucis de compilation s'explique ainsi.
Si tu peut faire l'essais de prendre une kernel 2.6.17 ou 2.6.18 et de refaire la compilation pour voir si tout ce passe bien ?
Quel commande utilise tu pour compiler ? (./configure ; make )
x86_64 tu compile pour une cible 64 bits ? c'est possible que ce soit cela qui provoque le freeze de ndiswrapper....
serait il possible que l'alimentation de mon laptop soit insuffisante ?
Oui certain laptop prennent des libertés avec la norme USB au niveau de l'alimentation pour économisé 2cts. Une solution pour test rapide est de passer par une hub-usb avec une alimentation externe.
Le disque possède un câble en Y avec 2 prise usb ... et il est noté dans la notice qu'en cas d'alimentation trop faible il faut brancher les 2 prises usb....
La le constructeur du disque prévient que déja il consomme plus que certains device usb, encore une fois la solutions du hub-usb alimentation autonome (on en trouve à 7 euros dans les grandes surface) permet de faire un essais.
En résumé, avec certains kernel l'alimentation usb requis par le device etait mal géré par le passé, on rajoute a ca que les constructeur de laptop font des economie de bout de chandelle et on obtient le genre d'ennuie que tu as.
Cela ne garanti pas que cela peut ce resoudre avec une alim externe.
Sur le desktop de ton ami sous windows, tu pourrais lancer un live-cd pour voir si sur son pc avec un linux tout marche bien non ?
Un cable de 30cm n'intervient pas sur un probleme d'alimentation MAIS si le disk et le PC sont USB 2.0 (480Mbits/s) il faut que ton cable soit bien blindé et certifié compatible 2.0 !
quand je vois des trucs comme ca je me dis que c'est pas la peine de chercher plus loin le module scsi indique qu'il n'arrive pas a communiquer proprement avec ce disk.
Quel est la version du kernel ?
Si le disk dispose d'une alimentation externe est elle bien branchée ?
qui n'engage que moi, c'est que le plus simple est de completer le drivers existant en rajoutant un nouveau inode dans /dev pour la gestion du moteur.
/dev/tracking que tu site, mais ne garder qu'un seul module simplifieras la gestion partager des endpoints et des variables interne a ce module.
Il n'y as aucune difficulté particulière a ce qu'un module dispose de plusieurs interface dans /dev.
>Est-ce possible qu'un disque dur ou qu'une carte PCI/AGP détruise la >carte mère ? (enfin, le FPU)
Normalement ca n'arrive pas sauf si le branchement est fait sans couper l'alimentation du PC, ou que lors de la mise sous tension la carte PCI ne soit qu'a moitier bien enfichée, ou qu'un decharge electrostatique lors de branchement ne se produise (avoir toujours une main sur la caracasse metallique du PC pour brancher une carte est une bonne methode pour les eviter)
>Peut-on changer le FPU ?
Oui en changant le porcesseur qui est monter sur un support donc assez simple a changer
oui depuis les 486DX le FPU est le CPU sont sur le meme die silicium.
Cependant puisque les PC herites des tares des 286 depuis leurs sortie l'environnement logique et logiciel gere les deux elements comme séparé.
Il t'est possible de compiler le kernel pour qu'il emule le FPU par des operations logiciels en laissant ainsi le FPU silicium tranquile.
Normalement si tu fais cela du devrais pouvoir voir si le CPU tiens encore le coup quelques temps
En général sur PC c'est un mode de fonctionnement qui à été abandonné depuis quelques temps. Dans mon cas (soft embarqué avec des petits micro 8 ou 16bits) la régle est
-Le micro passe 80% de sont temps dans 20% du code
c'est généralement vrai, donc l'optimisation ultime est d'identifier les 20% de code et de ré-écrire ces 20% en assembleur permet d'obtenir des resultats bluffants (j'ai deja vu des 400% de gains de temps de traitement).Il est tres simple d'interfacer l'assembleur avec le C (mais il faut s'astreindre à une version particulière de compilateur pour ne pas avoir de surprise).
Le langage C est tres proche du materiel, avec une bonne habitude de ton compilateur tu peut prevoir comment il traduira en assembleur ce que tu est en train d'ecrire et produire un code avec une bonne optimisation de base.
DVB-T est le format TNT en france, bien faire attention si tu achete le stick sur internet qu'il fasse bien du SECAM/PAL BG...pour les dom-tom c'est du PAL K je crois me souvenir
dd fais un acces bas-niveau secteur par secteur au disque dur/disquette.
Si ton flux brut d'entree (if) est une image de disquette alors a la fin tu auras bien une copie secteur par secteur de la disquette sur (of).
Par contre pour copier un fichier il faut utiliser la commande 'cp'
et la commande mount par exemple
mkdir /mnt/floppy
mount /dev/fd0h1440 /mnt/floppy
cp root.gz /mnt/mnt/floppy
cela ne rendra ni la disquette bootable ni rien d'autre mais cela aura bien copié le fichier sur la disquette.
Par contre il se peut que ce que tu doivent réelement devoir faire soit
un dezippage du fichier root.gz et ensuite de le mettre sur une disquette, le mieux c'est d'aller voir sur le site ou tu as trouver ce fichier
la procedure ressemblerait a ca
gunzip root.gz
dd if=root of=/dev/fd0 bs=1440k
je pense a un truc avec tes plantages softs, tu as peut etre un pb avec une barrete memoire.
Tu devrais laisser tourner memtest86 pendant une nuit ou plus pour voir si a chaud il n'y as pas de pb avec une barette.
Je sait que sous mandriva si tu fais urpmi memtest86 il modifie tout ce quil faut pour le faire apparaitre dans le menu du boot du pc...c'est une manip tres simple qui mes souvent en evidences des barettes defectueuses
de rien :-)
Non la pile USB c'est pour stack usb, c'est bien du soft.
>Sinon, j'ai désactivé les modules de l'onduleur mais rien n'y fait, j'ai
>l'impression qu'après un certain temps les ports USB sont comme
>mis en veille...
c'est peut etre l'apm ou dans le bios qu'il faut voir alors...
Tu peut verifier avec un voltemetre au niveau du port usb entre le pin la plus a gauche et celle la plus a droite pour voir si tu trouve un 5 volt ou a peut pres (entre 4 et 5 volt) pour voir si l'alimentation usb est toujours présente.
Tu peut avoir un soucis d'alimentation aussi sur l'usb que tu peut mettre en evidence en faisant passer le cablage usb par un hub disposant d'une alimentation d'appoint sur secteur
PC -> Hub->Onduleur + reste des perifs
Disont que sans savoir ou est le probleme il n'y as pas de preuve que l'unbuntu ne causeras pas de pb.
Si rien ne se passe quand tu branche la clef (pas de message dans dmesg) alors la pile USB du PC est plantée et ne procède plus a l'énumération (qui est une fonction de base).
Cela peut etre le module onduleur.
Pour l'usb 1.1, si tu branche un perif 1.1 sur un port 2.0 il passe alors en 1.1 c'est automatique.
Pour recompiler le kernel c'est assez simple,
tu telecharge les dernieres source de kernel.org
de preference et par habitude tu le decompresse dans
/usr/src/linux-2.6.19
tu te positionne ensuite dans le repertoire
du tape
make xconfig
dans la fenetre graphique, le menu fichier, charger une config
dans le repertoire /boot/
tu as le fichier config du kernel courant, tu le charge tu sauvegarde et du sort
ensuite
make bzImages
make modules
make modules_install
prendre un café
copier arch/i386/compressed/bzImages dans /boot sous un nom sympa et parlant
copier System.map vers /boot sous un nom sympa
il faut maintenant changer l'image ramdisk de la version 2.6.17 (fichier /boot/initramdisk) pour lui adjoindre les modules ext3 et jffs du nouveau kernel puis la sauvegarder sous un autre nom.
Malheureusement je n'ai pas la procedure en memoire ni sous la main car je suis au taf...je te laisse trouver sur le net (ca ressemble tres fortement a ca http://www.automated.it/asterisk/pxeindex.html )
Apres tout ca il faut modifier le gestionnaire de boot grub ou lilo pour qu'il prenne en compte le nouveau kernel sans ecraser l'ancien et voila
[^] # Re: BIOS ?
Posté par TheBreton . En réponse au message Assembleur inline dans gcc. Évalué à 1.
Est-ce que je suis sûr que je ne vais pas écraser une donnée qui a été mise précédemment dans le registre ax par le compilateur C ?
C'est quasi certain que tu l'ecrase oui, l'assembleur inline n'est pas encadré par des push/pop. Pour le voir demande a gcc de generer et laisser le code pseudo-assembleur du code en C pour voir ca.
... ça plante sur un segfault, et je ne sais absolument pas pourquoi ! Pire encore, je ne sais pas comment je peux le savoir ! J'ai vérifié que les I/O de la carte étaient activées dans le BIOS, mais malgré tout, dès que j'appelle l'interruption, boum, plantage...
Sous linux l'espace memoire est partagé en deux, user et kernel. Le user-space n'as aucun acces direct au ressource physique du systeme, aucun acces au hard ou a la memoire il doit passer par le kernel pour demander l'acces ou les operation permise(par un driver).
Sur toutes les machines, quand on execute un programme en espace user la tentative d'utilisation des certaines instructions assembleurs provoque un exeception qui se traduit ensuite par un segfault, c'est typiquement ce qu'il se passe quand tu fais asm("int $0x15");
int est une instruction du mode protégé qui ne peut pas etre executé quand le run-level du proc est "user".
Si tu veut plus d'info sur le driver a ecrire post dans le forum kernel
[^] # Re: BSD et linux sont cousin
Posté par TheBreton . En réponse au message mknod et BPF (Berkeley Packet Filter). Évalué à 1.
gunzip /proc/config.gz |less
il faut regarder sur des nom contenant pcap ou packet ou PF_
je ne peut pas t'en dire plus, désolé
# BSD et linux sont cousin
Posté par TheBreton . En réponse au message mknod et BPF (Berkeley Packet Filter). Évalué à 1.
Je te suggere par contre de verifier que ton kernel est configurer avec l'option tcp/ip CONFIG_FILTER de mise
et que la lib: libpcap est bien installée sur ton systeme.
La commande mknod ne sert a rien si derriere il n'y as pas de partie du kernel qui feras la gestion du inode créer.
[^] # Re: pticours
Posté par TheBreton . En réponse au message Création d'un mini driver avec libusb. Évalué à 2.
(1) char Array[] ={0x33,0x36,0x37};
et
(2)char Array[]={'3','6','7'};
sont strictement egaux, dans un cas j'ecris le contenu en hexa et dans l'autre en ascii, mais d'un point de vue binaire le resultat de la compilation est strictement identique
A ne pas faire :
char Array[] ={"0x33","0x36","0x37"};
Donc remplis ton tableau dans la forme que tu veut mais a mon avis c'est la forme (1) qui est le plus simple
# pticours
Posté par TheBreton . En réponse au message Création d'un mini driver avec libusb. Évalué à 2.
-interrupt (non-géré par libusb)
-bulk
-isochrone
-control
Les packet control sont normaliser pour certain services (pour l'enumeration et deux ou trois operations diverse) c'est bien rare de les utiliser en foncionnelle.
Les packet bulk sont des packet destiné a un endpoint (in ou out), le out est une emission du pc vers le device, le in une lecture du device vers le pc.
donc
int usb_bulk_write(usb_dev_handle *dev, int ep, char *bytes, int size, int timeout);
*dev :le handle du device que tu recupere à l'ouverture
ep : le numeral du endpoint sur lequel ce fait l'operation
*bytes : pointeur sur les données a recevoir ou le tableau de reception
syze : la taille a recevoir ou a emettre
timeout : un temps en milli second sans doute d'attente de la fin d'operation.
Les packet interrupt sont cycliquement emis du device vers le PC (ceci est une approximation du mechanisme !)
Les packet isochrone sont destiné a la transmission rapide de donné sans garanti de reception (typiquement je pense que les images de la CAM utiliseront de l'isochrone)
je te conseille la lecture de:
http://www.usb.org/developers/docs/usb_20_031507.zip
qui est tres complet sur l'usb.
[^] # Re: Donc si j'ai bien compris
Posté par TheBreton . En réponse au journal Linux c'est mieux qu'avant !. Évalué à 1.
La plupart des defaillances sont des comportements en sur-intensité (pour finir finalement en cours-circuit) et donc provoque une elevation de temperature des composants, en les refroidissant on change leur point de fonctionnement puis il rechauffe et ainsi de suite.
[^] # Re: Quelques pistes...
Posté par TheBreton . En réponse au message rtl8185 désespoir. Évalué à 2.
acheter une carte dont les specs sont clairement marqué sur le site vendeur et demander verification au service technique de la version de la carte
ou
aller dans la boutique avec un portable demander au vendeur d'ouvrir la boite pour voir si la carte fonctionne sous linux
des fois cela se passe bien tu peut glaner des infos ici :
http://linuxfr.org/~plagiats/20596.html
http://bcm43xx.berlios.de/?go=devices
http://doc.ubuntu-fr.org/materiel/wifi/liste_carte#tableau
et pour l'usb
http://www.presence-pc.com/tests/cles-usb-wifi-499/
[^] # Re: Quelques pistes...
Posté par TheBreton . En réponse au message rtl8185 désespoir. Évalué à 2.
Si tu peut faire l'essais de prendre une kernel 2.6.17 ou 2.6.18 et de refaire la compilation pour voir si tout ce passe bien ?
Quel commande utilise tu pour compiler ? (./configure ; make )
x86_64 tu compile pour une cible 64 bits ? c'est possible que ce soit cela qui provoque le freeze de ndiswrapper....
[^] # Re: moi
Posté par TheBreton . En réponse au message Disque externe Usb InterDiscount 80Go non reconnu. Évalué à 5.
Oui certain laptop prennent des libertés avec la norme USB au niveau de l'alimentation pour économisé 2cts. Une solution pour test rapide est de passer par une hub-usb avec une alimentation externe.
Le disque possède un câble en Y avec 2 prise usb ... et il est noté dans la notice qu'en cas d'alimentation trop faible il faut brancher les 2 prises usb....
La le constructeur du disque prévient que déja il consomme plus que certains device usb, encore une fois la solutions du hub-usb alimentation autonome (on en trouve à 7 euros dans les grandes surface) permet de faire un essais.
En résumé, avec certains kernel l'alimentation usb requis par le device etait mal géré par le passé, on rajoute a ca que les constructeur de laptop font des economie de bout de chandelle et on obtient le genre d'ennuie que tu as.
Cela ne garanti pas que cela peut ce resoudre avec une alim externe.
Sur le desktop de ton ami sous windows, tu pourrais lancer un live-cd pour voir si sur son pc avec un linux tout marche bien non ?
Un cable de 30cm n'intervient pas sur un probleme d'alimentation MAIS si le disk et le PC sont USB 2.0 (480Mbits/s) il faut que ton cable soit bien blindé et certifié compatible 2.0 !
# moi
Posté par TheBreton . En réponse au message Disque externe Usb InterDiscount 80Go non reconnu. Évalué à 1.
[17179854.268000] end_request: I/O error, dev sda, sector 0
[17179854.268000] Buffer I/O error on device sda, logical block 0
[17179854.280000] sd 0:0:0:0: SCSI error: return code = 0x10070000
[17179854.280000] end_request: I/O error, dev sda, sector 0
[17179854.280000] Buffer I/O error on device sda, logical block 0
quand je vois des trucs comme ca je me dis que c'est pas la peine de chercher plus loin le module scsi indique qu'il n'arrive pas a communiquer proprement avec ce disk.
Quel est la version du kernel ?
Si le disk dispose d'une alimentation externe est elle bien branchée ?
# mon avis
Posté par TheBreton . En réponse au message Ecrire un nouveau driver ou compléter l'existant ?. Évalué à 1.
/dev/tracking que tu site, mais ne garder qu'un seul module simplifieras la gestion partager des endpoints et des variables interne a ce module.
Il n'y as aucune difficulté particulière a ce qu'un module dispose de plusieurs interface dans /dev.
# simple
Posté par TheBreton . En réponse au message demande d'aide. Évalué à 1.
http://gnuwin32.sourceforge.net/packages/gawk.htm
# Pour le reste
Posté par TheBreton . En réponse au message ASUS A8V Deluxe Brûlée ?. Évalué à 1.
Normalement ca n'arrive pas sauf si le branchement est fait sans couper l'alimentation du PC, ou que lors de la mise sous tension la carte PCI ne soit qu'a moitier bien enfichée, ou qu'un decharge electrostatique lors de branchement ne se produise (avoir toujours une main sur la caracasse metallique du PC pour brancher une carte est une bonne methode pour les eviter)
>Peut-on changer le FPU ?
Oui en changant le porcesseur qui est monter sur un support donc assez simple a changer
[^] # Re: informations contradictoires ?
Posté par TheBreton . En réponse au message ASUS A8V Deluxe Brûlée ?. Évalué à 1.
Cependant puisque les PC herites des tares des 286 depuis leurs sortie l'environnement logique et logiciel gere les deux elements comme séparé.
Il t'est possible de compiler le kernel pour qu'il emule le FPU par des operations logiciels en laissant ainsi le FPU silicium tranquile.
Normalement si tu fais cela du devrais pouvoir voir si le CPU tiens encore le coup quelques temps
[^] # Re: Pour la TV sous linux
Posté par TheBreton . En réponse au message Clef USB tunner-TNT-TV. Évalué à 1.
si oui celle la peut faire l'affaire
http://www.ldlc.com/critiques/PB00028284-1/terratec-cinergy-(...)
ou si tu veut une entré analogique (avant TNT) en plus de la TNT parce que la c'est plus galere a trouver un produit compatible linux...
[^] # Re: Question de profane total
Posté par TheBreton . En réponse à la dépêche PyPy, le serpent qui se mord la queue, sort en version 0.99. Évalué à 6.
-Le micro passe 80% de sont temps dans 20% du code
c'est généralement vrai, donc l'optimisation ultime est d'identifier les 20% de code et de ré-écrire ces 20% en assembleur permet d'obtenir des resultats bluffants (j'ai deja vu des 400% de gains de temps de traitement).Il est tres simple d'interfacer l'assembleur avec le C (mais il faut s'astreindre à une version particulière de compilateur pour ne pas avoir de surprise).
Le langage C est tres proche du materiel, avec une bonne habitude de ton compilateur tu peut prevoir comment il traduira en assembleur ce que tu est en train d'ecrire et produire un code avec une bonne optimisation de base.
# Pour la TV sous linux
Posté par TheBreton . En réponse au message Clef USB tunner-TNT-TV. Évalué à 2.
http://linuxtv.org/wiki/index.php/Main_Page
Pour les stick USB (bien lire attentivement si supporté ou non)
http://linuxtv.org/wiki/index.php/DVB_USB
DVB-T est le format TNT en france, bien faire attention si tu achete le stick sur internet qu'il fasse bien du SECAM/PAL BG...pour les dom-tom c'est du PAL K je crois me souvenir
# je ne sait pas pour les interrupts
Posté par TheBreton . En réponse au message Problème de prise en charge carte acquisition - IRQ partagée. Évalué à 1.
D'apres la page
http://mjpeg.sourceforge.net/driver-zoran/cards.php
tous les modules necessaire sont-il bien en chargé ?
videodev, i2c-core, i2c-algo-bit,videocodec, saa7110, adv7175, zr36060, zoran
[^] # Re: ne pas confondre dd et cp
Posté par TheBreton . En réponse au message table de partition effacé. Évalué à 1.
dd if=root of=/dev/fd0h1440
# ne pas confondre dd et cp
Posté par TheBreton . En réponse au message table de partition effacé. Évalué à 2.
Si ton flux brut d'entree (if) est une image de disquette alors a la fin tu auras bien une copie secteur par secteur de la disquette sur (of).
Par contre pour copier un fichier il faut utiliser la commande 'cp'
et la commande mount par exemple
mkdir /mnt/floppy
mount /dev/fd0h1440 /mnt/floppy
cp root.gz /mnt/mnt/floppy
cela ne rendra ni la disquette bootable ni rien d'autre mais cela aura bien copié le fichier sur la disquette.
Par contre il se peut que ce que tu doivent réelement devoir faire soit
un dezippage du fichier root.gz et ensuite de le mettre sur une disquette, le mieux c'est d'aller voir sur le site ou tu as trouver ce fichier
la procedure ressemblerait a ca
gunzip root.gz
dd if=root of=/dev/fd0 bs=1440k
# il y en manque des options
Posté par TheBreton . En réponse au message cc, as et ld. Évalué à 3.
ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.1 -o toto
/usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o
-L/usr/lib/gcc-lib/<A COMPLETER> toto.o -lm -lgcc -lc -lgcc
/usr/lib/crtend.o /usr/lib/crtn.o
voici un lien pour plus d'info
http://www.ensta.fr/~gueydan/Poly/Html/node8.html#SECTION034(...)
[^] # Re: voila
Posté par TheBreton . En réponse au message Problème USB dans Mandriva 2007. Évalué à 1.
Tu devrais laisser tourner memtest86 pendant une nuit ou plus pour voir si a chaud il n'y as pas de pb avec une barette.
Je sait que sous mandriva si tu fais urpmi memtest86 il modifie tout ce quil faut pour le faire apparaitre dans le menu du boot du pc...c'est une manip tres simple qui mes souvent en evidences des barettes defectueuses
[^] # Re: voila
Posté par TheBreton . En réponse au message Problème USB dans Mandriva 2007. Évalué à 1.
Non la pile USB c'est pour stack usb, c'est bien du soft.
>Sinon, j'ai désactivé les modules de l'onduleur mais rien n'y fait, j'ai
>l'impression qu'après un certain temps les ports USB sont comme
>mis en veille...
c'est peut etre l'apm ou dans le bios qu'il faut voir alors...
Tu peut verifier avec un voltemetre au niveau du port usb entre le pin la plus a gauche et celle la plus a droite pour voir si tu trouve un 5 volt ou a peut pres (entre 4 et 5 volt) pour voir si l'alimentation usb est toujours présente.
Tu peut avoir un soucis d'alimentation aussi sur l'usb que tu peut mettre en evidence en faisant passer le cablage usb par un hub disposant d'une alimentation d'appoint sur secteur
PC -> Hub->Onduleur + reste des perifs
Disont que sans savoir ou est le probleme il n'y as pas de preuve que l'unbuntu ne causeras pas de pb.
# oui
Posté par TheBreton . En réponse au message Bonjour à vous tous. Évalué à 2.
et hop en plus un petit lien
http://c.developpez.com/cours/#tutos-bcb
[^] # Re: voila
Posté par TheBreton . En réponse au message Problème USB dans Mandriva 2007. Évalué à 1.
Cela peut etre le module onduleur.
Pour l'usb 1.1, si tu branche un perif 1.1 sur un port 2.0 il passe alors en 1.1 c'est automatique.
Pour recompiler le kernel c'est assez simple,
tu telecharge les dernieres source de kernel.org
de preference et par habitude tu le decompresse dans
/usr/src/linux-2.6.19
tu te positionne ensuite dans le repertoire
du tape
make xconfig
dans la fenetre graphique, le menu fichier, charger une config
dans le repertoire /boot/
tu as le fichier config du kernel courant, tu le charge tu sauvegarde et du sort
ensuite
make bzImages
make modules
make modules_install
prendre un café
copier arch/i386/compressed/bzImages dans /boot sous un nom sympa et parlant
copier System.map vers /boot sous un nom sympa
il faut maintenant changer l'image ramdisk de la version 2.6.17 (fichier /boot/initramdisk) pour lui adjoindre les modules ext3 et jffs du nouveau kernel puis la sauvegarder sous un autre nom.
Malheureusement je n'ai pas la procedure en memoire ni sous la main car je suis au taf...je te laisse trouver sur le net (ca ressemble tres fortement a ca http://www.automated.it/asterisk/pxeindex.html )
Apres tout ca il faut modifier le gestionnaire de boot grub ou lilo pour qu'il prenne en compte le nouveau kernel sans ecraser l'ancien et voila