TheBreton a écrit 927 commentaires

Si on décide de croire atop la presque seule différence dans le log est la ligne
133 cron
c'est une piste a voir non ?
Sinon si on dit que les acces disques sont long et que le nombre de fichier ne change pratiquement pas on peut envisagé une defaillance disque dur peut etre aussi non ? sur-chauffe et temps de seek de la tete qui augemente ?
Sinon je pense que pour creuser plus il faudra patcher le kernel pour avoir plus d'info avec atop mais peut etre aussi voir du coté des drivers ide ou sata si des infos de debug ne sont pas disponible.
(modinfo nom-du-driver) puis rmmod insmod....

souvent les pb sont du aux effort mécanique sur les cables sortant du port usb qui force sur les soudures du connecteur sur la carte mère.
Plus rarement c'est la qualité du connecteur :usure physique des broches à force de connexion/ deconnexion .

Il n'y as que 4 broches sur l'usb mais il les faut toutes pour que ca marche...et avec l'usb 3.0 ce sera pire on rajoute 4 fils de liaisons superspeed et 1 masse de plus.

et surtout avec les pc portables, les ports USB sont limite pour la consommation des périphériques (je rigole encore avec les cartes mère d'une série de D**l disposant d'un fusible 500mA sur Vbus mais de piste cuivre qui claquait à 100mA, on en a fumé deux ou trois avant de comprendre d'ou venait le defaut et que c'etait pas notre périphérique).

Peut tu faire l'essais avec un hub usb disposant d'une alimentation secteur?

Un faux contact sur ton micro tu le validerais en passant la clef tnt sur un autre port.
Il n'existe pas d'equivalent à 'ping' pour l'usb car les composants host détecte le branchement/debranchement des péripheriques par le niveau electrique sur la ligne D- ou par l'échec d'une transaction J/K et dans le log kernel tu devrais voir le dechargement du module de gestion de ton tunner.

Pour regarder si un mode debug est dipo dans le driver fais un modinfo dessus.

dmesg n'indique rien de special ? (pas de too many file?)

que donne "lsof -n | awk '{print $1}' | sort | uniq -c | sort -rn | head" quand ca tourne a fond
(lsof permet de savoir les fichiers ouvert sur le systeme et la petite ligne la indique le nombre par process je l'ai trouvé la http://dev.petitchevalroux.net/linux/afficher-les-processus-(...) )



que donne la commande top quand ca part en vrille ? (memoire swap utilisé par exemple..)

Le PC1024 c'est de l'isa, donc les vieilles recettes doivent encore fonctionnées.
Je dis tout de mémoire, il faudra ce replongé dans le code des drivers isa pour verifier tout ce que je dis ci dessous.

Normalement soit la plage mémoire est courte et donc situé normalement par des accès IO. (et il faut utiliser inb,outb ou w) voir http://www.faqs.org/docs/Linux-mini/IO-Port-Programming.html

Soit la quantité est grande et il fallait la positionner l'adresse de la ram entre 14M et 16M.

Ensuite il fallait dire au kernel lors du boot time qu'une plage d'adresse physique etait reserve en lui passant l'option memmap en lui decrivant la zone d'exclusion.
Ensuite dans le module driver de la carte il fallait faire un ioremap

http://www.xml.com/ldd/chapter/book/ch08.html

pas trop mal foutue
http://www.linuxpedia.fr/doku.php/expert/grub2

a première lecture rapide tu dois utiliser
grub-mkconfig
et GRUB_PRELOAD_MODULES="raid mdraid" ou tu dois rajouter linux

Ben oui et si tu veux changer de fournisseur d'accès, ça te met une barrière supplémentaire.
Non, chez free on conserve son adresse mail meme si on n'est plus abonné.

Le coupable le plus courant dans ce cas la c'est un driver.
Pas de trace suspecte avec dmseg ?
Alors la seule solution c'est de changer petit a petit les drivers les uns les autres pour voir de qui ca pouvait venir.
Je commencerais par changer le driver nvidia par l'equivalent libre, puis il faudra déactiver les autres, soit au démarrage, soit par un rmmod.

Deja dans le code je vois des while() qui peuvent ne jamais finir.
En embarqué ou en kernel on doit toujours mettre une limite temporel ou un compteur de boucle au cas ou...
pour le debug pas trop le choix, utilise kdb (qui est dans le kernel mais faut le recompiler) et/ou kgdb qui necessite kdb et 2 machine pour le debug.

Je peut dire une connerie ?
Récemment je me suis pris la tête sur des problème de connexion ssh sur une mandriva fraichement installé.
En fait j'avais tout simple oublié que la configuration par défaut du firewall rejetait toute connexion ssh entrante et qu'il fallait les autorisés...

c'est dans /var/log que tu trouve les logs systeme et que tu peut trouver les indications sur ce qui se passe quand quelqu'un tente une connexion.

vive la console, mort au cliquodrome ! Mort au generateur de code à base de click de souris qui auront la peaux de nos poignet !

C'est de l'humour je suis désolé pour la dégradation de ton état de santé. Mais je pense que l'opération est difficilement évitable à terme.
Ici la médecine du travail (rien que le terme me fais rire quand on vois l'interet des visites) nous conseille d'avoir un ballon de sable dé-stressant pour faire travailler le poignet de temps en temps et de mettre des reposes poignets ré-hausseur en gel pour utiliser la souris et le clavier (c'est pas curatif mais préventif).
Perso les clavier ergo je trouve que c'est pas terrible.

arf le dédit formation...juridiquement valable uniquement si faisant parti d'un avenant indépendemment du contrat de travail ce qui est rarement le cas.
Et puis gardé chez un client quelqu'un qui veut partir et ternir l'image de la boite aupres du client... il n'y as que les buzard de commerciaux pour croire que ca peut marcher.

Ca me rapelle une astuce qui était utilisé sur les CPC464 (oui c'est vieux) pour éviter le relecture d'un fichier basic on modifiait avec un editeur hexa la couleur du texte en planquant des codes ascii (escape sequence) dans un commentaire.
En l'occurence essaye avec un hexedit de voir ce que cela donne ou kwrite, enfin un autre outils que more

Bonjour, Xilinx propose le ise webpack qui est 100% proprio mais compatible linux y compris les outils de programmations jtag.

Niveau langage le Verilog est d'usage plutot americain, le VHDL plutot europeens.
Dans les 2 cas ce ne sont pas des langage pour concevoir des logiques (ou je sait c'est bizarre) mais des langage de simulation analogique.

Par utilisation d'une petite partie des instructions on peut concevoir des logiques sur fpga. Mais plein d'instructions VHDL ne seront pas comprise pour concevoir un fpga (surtout les directives de timing).

Un site bien pour commencer avec des cours (rechercher vhdl)
http://pagesperso-orange.fr/xcotton/electron/coursetdocs.htm

Un site ou piocher des idées et des exemples
http://www.opencores.org/

Un livre dont l'auteur est sympa et que je croise de temps en temps
(bien que le contenu soit assez bateau les connaissance de bases des methodes est importante)
http://www.eyrolles.com/Informatique/Livre/vhdl-methodologie(...)

A savoir, je ne pense pas qu'il existe de solution non-proprio pour fitter du vhdl dans un composant. Le bitstream des fpga etant 100% proprio.

Linux etant un OS j'en deduis que tu demande un choix de distribution plutot non ?Cela depend de tes performance attendue (temps de boot, interface graphique ou pas....).
Si ton PC est blackbox, sans ecran ni clavier/souris alors je te conseille de partir plutot vers LFS (Linux From Scratch) pour maitriser ton temps de boot et les services lancer (les distrib on tendance a faire vraiment trop de chose pour etre le plus compatible possible).
Si tu veut plein de chose en plus des taches decrites plus haut alors je te conseille ubuntu ou mandriva pour commencer a te familiariser avec linux.

Le Débit Lyonnais fais un systeme de numéro carte bleu unique et temporaire, tu créer une carte du montant voulu sur leur site ensuite il te donne un numéro de carte utilisable du montant voulu avec date de validité et code sécurité.
Je trouve le système tres bien (et gratuit c.a.d. pas de payement en plus que ce qu'il te prenne d'habitude) et au pire tu ne risque que le montant de la carte que tu as provisionné.
De mémoire ca s'apelle e-carte bleu

Je ne comprend pas le pourquoi du passage en negatif du post a moins que cette phrase si ils font ce choix, c'est qu'ils ont leurs raisons ne soit au coeur de la réaction épidermique.
et a mon avis ils connaissent le probleme legerement mieux que a peu pres tout le monde sur ce site. sur ce point tu as raison.

Le problème est que le choix, le technique ne l'as pas, ce n'est pas la direction technique qui choisit son OS mais des politiquards, des accords commerciaux douteux, des vieux indéboulonnable au coeur de la DCN (devenu DCNS) qui refuse le moindre changement remettant en cause leurs (maigre?) connaissances technique et toute une mafia qui gravite autour du microcosme économique militaro-industrielle. L'important pour ces gens la est de décroché des bugets (quelque fois absurde) pour pérénisé une situation acquise au fils du temps.

C'est étonnant le nombre de gradé de l'armé qui finisse a des postes important dans des sociétés de droit privé qui son fournisseur de l'armée non ?

Tu peut lire la license ici, une fois signé par un gouvernement ce dernier obtient l'acces au source de windows, office et autre chose marrante.
http://www.microsoft.com/resources/sharedsource/gsp.mspx

Je confirme MS interdit explicitement de corriger un bug si on en voit un mais nous invite à leur signaler et attendre qu'un correctif soit disponible.
C'était comme ça à l'époque de la sortie de XPe en shared source en tout cas je ne me suis plus intéresser au problème depuis.

Si, rassure toi, dans les systemes embarqués (voiture, aéro...) on travaille toujours sans OS win32, même sur des micros 32 bits (mais souvent avec un OS quand même (sur les 32bits) sauf si on peut s'en passer, mais on à les sources par contre).
Sur les micros 16bits et 8bits c'est extrêmement rare quand on mets un OS .
Des sales bêtes (papillons) on bien essayées de rentrer dans les voitures sur les interfaces clients (cf citroen xsara ce http://www.maximegaillard.com/421-windows-sur-les-citron.htm(...) )
mais cela c'était il y a quelques années....et ça n'as pas marché :-)

bon je pense que la lecture du rubiny te sera d'une grande aide
http://lwn.net/Kernel/LDD3/
tu trouveras toutes les reponses a tes question (y compris sur le passage d'argument au module au moment du chargement qui serait bien plus souple que le define a la compilation).
Pour le fops et le role de /proc dans le systeme les explications si dessous sont suffisantes.
Bonne lecture

j'ai pas du tout compris ce que tu compte faire.
Mais sous unix tout est fichier donc a priori c'est dans l'esprit effectivement.
Maintenant ce que je ne comprend pas c' est pourquoi tu n'utiliserais pas la fops de ton module dans /dev ? Car /proc est plutot dans l'information module->user que dans l'interaction module<->user

sans vouloir te décourager mais je pense que le morceau que tu essaie d'avaler est sans doute un peut trop gros pour toi.

Mais sinon tu peut utiliser ca
http://www.national.com/pf/LM/LMX9830.html
en profile "transparent uart" c'est assez simple
MAIS c'est du BGA et il faut concevoir le front-end RF as utiliser avec le chip.
Pour commencer
http://fr.wikipedia.org/wiki/Bluetooth
et pour des tas de doc accessible
https://www.bluetooth.org/apps/content/
Coté linux prend un dongle usb standard il marcheras assez bien
Bonne chance

zut c'est lspci bien sur et pas lspic

Moi je commencerais par essayer un livecd (ou dvd) recent de style ubuntu (mais bon le choix reste ouvert)
Je regarderais si la carte reseau fonctionne et est reconnue

Si oui : je regarderais quel module est utilisé par cette carte :
a) j'essayerais sous debian de voir quel est la version dispo
b) j'installerais la distro qui marche car je fais au plus simple

Si non : je me dirais qu'il n'y as pas encore de drivers disponible et que les recherches reste ouverte a coup de lspic et de google