curieusement, j'ai le msg qd je quitte linux :
umount /proc not mounted ...
Qu'est ce qu'il y a dans /proc après le démarrage? S'il n'y a rien, de
toute façon le système ne peut pas fonctionner correctement. Peut-être
une option mal définie lors de la compil noyau?
curieusement, j'ai le msg qd je quitte linux :
umount /proc not mounted ...
Qu'est ce qu'il y a dans /proc après le démarrage? S'il n'y a rien, de
toute façon le système ne peut pas fonctionner correctement. Peut-être
une option mal définie lors de la compil noyau?
curieusement, j'ai le msg qd je quitte linux :
umount /proc not mounted ...
Qu'est ce qu'il y a dans /proc après le démarrage? S'il n'y a rien, de
toute façon le système ne peut pas fonctionner correctement. Peut-être
une option mal définie lors de la compil noyau?
curieusement, j'ai le msg qd je quitte linux :
umount /proc not mounted ...
Qu'est ce qu'il y a dans /proc après le démarrage? S'il n'y a rien, de
toute façon le système ne peut pas fonctionner correctement. Peut-être
une option mal définie lors de la compil noyau?
voici /etc/mtab :
curieusement, j'ai le msg qd je quitte linux :
umount /proc not mounted ...
Qu'est ce qu'il y a dans /proc après le démarrage? S'il n'y a rien, de
toute façon le système ne peut pas fonctionner correctement. Peut-être
une option mal définie lors de la compil noyau?
voici /etc/mtab :
curieusement, j'ai le msg qd je quitte linux :
umount /proc not mounted ...
Qu'est ce qu'il y a dans /proc après le démarrage? S'il n'y a rien, de
toute façon le système ne peut pas fonctionner correctement. Peut-être
une option mal définie lors de la compil noyau?
voici /etc/mtab :
waaaoouuu !! Il faut rester humble devant la technique, mais il faut
aussi persévérer. il y a forcément une solution !!
bon, bonne nouvelle, je boote sur le 2.6.20. mkinitrd a généré l'image.
mais, mais..., je n'ai pas encore le réseau ni ma résolution VGA.
waaaoouuu !! Il faut rester humble devant la technique, mais il faut
aussi persévérer. il y a forcément une solution !!
bon, bonne nouvelle, je boote sur le 2.6.20. mkinitrd a généré l'image.
mais, mais..., je n'ai pas encore le réseau ni ma résolution VGA.
waaaoouuu !! Il faut rester humble devant la technique, mais il faut
aussi persévérer. il y a forcément une solution !!
bon, bonne nouvelle, je boote sur le 2.6.20. mkinitrd a généré l'image.
mais, mais..., je n'ai pas encore le réseau ni ma résolution VGA.
Ce que je trouve le plus étonnant, c'est que ton lspci n'a pas du tout
changé : visiblement tu ne reconnais pas plus de matos qu'avant. Alors
qu'en principe il devrait tout reconnaître maintenant !
Ce que je trouve le plus étonnant, c'est que ton lspci n'a pas du tout
changé : visiblement tu ne reconnais pas plus de matos qu'avant. Alors
qu'en principe il devrait tout reconnaître maintenant !
Ce que je trouve le plus étonnant, c'est que ton lspci n'a pas du tout
changé : visiblement tu ne reconnais pas plus de matos qu'avant. Alors
qu'en principe il devrait tout reconnaître maintenant !
Blaise Potard wrote in message
<45e1da2c$0$13855$:Ce que je trouve le plus étonnant, c'est que ton lspci n'a pas du tout
changé : visiblement tu ne reconnais pas plus de matos qu'avant. Alors
qu'en principe il devrait tout reconnaître maintenant !
Ce que reconnaît le noyau et ce qu'affiche lspci n'a strictement aucun
rapport.
Blaise Potard wrote in message
<45e1da2c$0$13855$426a74cc@news.free.fr>:
Ce que je trouve le plus étonnant, c'est que ton lspci n'a pas du tout
changé : visiblement tu ne reconnais pas plus de matos qu'avant. Alors
qu'en principe il devrait tout reconnaître maintenant !
Ce que reconnaît le noyau et ce qu'affiche lspci n'a strictement aucun
rapport.
Blaise Potard wrote in message
<45e1da2c$0$13855$:Ce que je trouve le plus étonnant, c'est que ton lspci n'a pas du tout
changé : visiblement tu ne reconnais pas plus de matos qu'avant. Alors
qu'en principe il devrait tout reconnaître maintenant !
Ce que reconnaît le noyau et ce qu'affiche lspci n'a strictement aucun
rapport.
ce serait bien d'expliciter. rien que pour la culture générale.
ce serait bien d'expliciter. rien que pour la culture générale.
ce serait bien d'expliciter. rien que pour la culture générale.
claude wrote in message <45e1dd51$0$19803$:ce serait bien d'expliciter. rien que pour la culture générale.
Les bus modernes, dont le bus PCI (mais aussi USB, par exemple) comportent
dans leur protocole un moyen standard pour chaque périphérique présent de
décliner son identité, au moyen en général de quelques nombres. Très
souvent, ces nombres comportent au moins une classe, standardisée
globalement, qui explicite de quel type de périphérique il s'agit, un
identifiant vendeur, attribué à chaque constructeur, et un identifiant de
produit, attribué par le constructeur.
lspci lit tous ces identifiants sur le bus, en utilisant l'interface
/proc/bus/pci fournie par le noyau, et les affiche. Pour que ce soit plus
lisible, il utilise une table de correspondance entre les identifiants et
des noms lisibles. Cette table est un simple fichier texte, souvent dans
/usr/share/misc/pci.ids, et peut être mise à jour, la dernière version se
trouvant sur <URL: http://pciids.sourceforge.net/v2.2/pci.ids >. Quand lspci
dit « unknown », ça veut juste dire que le périphérique n'est pas listé dans
sa table. On peut demander à lspci de ne pas utiliser la table, et
d'afficher les valeurs numériques, avec l'option -n.
De son côté, le noyau a, pour chaque driver capable de gérer des
périphériques PCI, une table permettant de déterminer quels périphériques il
peut gérer, et quels périphériques il ne peut pas gérer. On peut avoir une
certaine vue de ces tables en regardant
/lib/modules/`uname -r`/modules.pcimap (qui ne liste pas ce qui est géré par
des drivers directement dans le noyau). Au moment d'initialiser un driver,
le noyau énumère les périphériques PCI, et regarde les quels sont acceptés
par la table.
Le mécanisme qui permet au noyau d'énumérer les périphériques pour un driver
est le même que celui qui lui permet de les énumérer pour /proc/bus/pci/,
qui sert à lspci. Dans ces conditions, il est clair que si un périphérique
n'apparaît pas du tout dans lspci, le noyau ne peut pas le gérer : c'est
tout simplement qu'il n'existe pas (éventuellement virtuellement, par
exemple désactivé par le BIOS). Mais au delà, rien : un périphérique peut
être reconnu par le noyau et affiché « unknown » par lspci, ou
réciproquement être listé avec un nom très détaillé par lspci et ne pas être
reconnu par le noyau.
Une manière de savoir si un périphérique est reconnu par le noyau est
d'aller voir dans /sys/bus/pci/devices : chaque périphérique y est
représenté par un lien symbolique vers un répertoire. Si dans ce répertoire
se trouve un lien symbolique « driver », le périphérique est reconnu.
Voici un petit script (zsh) pour voir ça :
for i in /sys/bus/pci/devices/*
if [[ -e $i/driver ]]; then
d=`readlink $i/driver`
print ${i:t} reconnu par ${d:t}
else
print ${i:t} inconnu
fi
claude wrote in message <45e1dd51$0$19803$426a74cc@news.free.fr>:
ce serait bien d'expliciter. rien que pour la culture générale.
Les bus modernes, dont le bus PCI (mais aussi USB, par exemple) comportent
dans leur protocole un moyen standard pour chaque périphérique présent de
décliner son identité, au moyen en général de quelques nombres. Très
souvent, ces nombres comportent au moins une classe, standardisée
globalement, qui explicite de quel type de périphérique il s'agit, un
identifiant vendeur, attribué à chaque constructeur, et un identifiant de
produit, attribué par le constructeur.
lspci lit tous ces identifiants sur le bus, en utilisant l'interface
/proc/bus/pci fournie par le noyau, et les affiche. Pour que ce soit plus
lisible, il utilise une table de correspondance entre les identifiants et
des noms lisibles. Cette table est un simple fichier texte, souvent dans
/usr/share/misc/pci.ids, et peut être mise à jour, la dernière version se
trouvant sur <URL: http://pciids.sourceforge.net/v2.2/pci.ids >. Quand lspci
dit « unknown », ça veut juste dire que le périphérique n'est pas listé dans
sa table. On peut demander à lspci de ne pas utiliser la table, et
d'afficher les valeurs numériques, avec l'option -n.
De son côté, le noyau a, pour chaque driver capable de gérer des
périphériques PCI, une table permettant de déterminer quels périphériques il
peut gérer, et quels périphériques il ne peut pas gérer. On peut avoir une
certaine vue de ces tables en regardant
/lib/modules/`uname -r`/modules.pcimap (qui ne liste pas ce qui est géré par
des drivers directement dans le noyau). Au moment d'initialiser un driver,
le noyau énumère les périphériques PCI, et regarde les quels sont acceptés
par la table.
Le mécanisme qui permet au noyau d'énumérer les périphériques pour un driver
est le même que celui qui lui permet de les énumérer pour /proc/bus/pci/,
qui sert à lspci. Dans ces conditions, il est clair que si un périphérique
n'apparaît pas du tout dans lspci, le noyau ne peut pas le gérer : c'est
tout simplement qu'il n'existe pas (éventuellement virtuellement, par
exemple désactivé par le BIOS). Mais au delà, rien : un périphérique peut
être reconnu par le noyau et affiché « unknown » par lspci, ou
réciproquement être listé avec un nom très détaillé par lspci et ne pas être
reconnu par le noyau.
Une manière de savoir si un périphérique est reconnu par le noyau est
d'aller voir dans /sys/bus/pci/devices : chaque périphérique y est
représenté par un lien symbolique vers un répertoire. Si dans ce répertoire
se trouve un lien symbolique « driver », le périphérique est reconnu.
Voici un petit script (zsh) pour voir ça :
for i in /sys/bus/pci/devices/*
if [[ -e $i/driver ]]; then
d=`readlink $i/driver`
print ${i:t} reconnu par ${d:t}
else
print ${i:t} inconnu
fi
claude wrote in message <45e1dd51$0$19803$:ce serait bien d'expliciter. rien que pour la culture générale.
Les bus modernes, dont le bus PCI (mais aussi USB, par exemple) comportent
dans leur protocole un moyen standard pour chaque périphérique présent de
décliner son identité, au moyen en général de quelques nombres. Très
souvent, ces nombres comportent au moins une classe, standardisée
globalement, qui explicite de quel type de périphérique il s'agit, un
identifiant vendeur, attribué à chaque constructeur, et un identifiant de
produit, attribué par le constructeur.
lspci lit tous ces identifiants sur le bus, en utilisant l'interface
/proc/bus/pci fournie par le noyau, et les affiche. Pour que ce soit plus
lisible, il utilise une table de correspondance entre les identifiants et
des noms lisibles. Cette table est un simple fichier texte, souvent dans
/usr/share/misc/pci.ids, et peut être mise à jour, la dernière version se
trouvant sur <URL: http://pciids.sourceforge.net/v2.2/pci.ids >. Quand lspci
dit « unknown », ça veut juste dire que le périphérique n'est pas listé dans
sa table. On peut demander à lspci de ne pas utiliser la table, et
d'afficher les valeurs numériques, avec l'option -n.
De son côté, le noyau a, pour chaque driver capable de gérer des
périphériques PCI, une table permettant de déterminer quels périphériques il
peut gérer, et quels périphériques il ne peut pas gérer. On peut avoir une
certaine vue de ces tables en regardant
/lib/modules/`uname -r`/modules.pcimap (qui ne liste pas ce qui est géré par
des drivers directement dans le noyau). Au moment d'initialiser un driver,
le noyau énumère les périphériques PCI, et regarde les quels sont acceptés
par la table.
Le mécanisme qui permet au noyau d'énumérer les périphériques pour un driver
est le même que celui qui lui permet de les énumérer pour /proc/bus/pci/,
qui sert à lspci. Dans ces conditions, il est clair que si un périphérique
n'apparaît pas du tout dans lspci, le noyau ne peut pas le gérer : c'est
tout simplement qu'il n'existe pas (éventuellement virtuellement, par
exemple désactivé par le BIOS). Mais au delà, rien : un périphérique peut
être reconnu par le noyau et affiché « unknown » par lspci, ou
réciproquement être listé avec un nom très détaillé par lspci et ne pas être
reconnu par le noyau.
Une manière de savoir si un périphérique est reconnu par le noyau est
d'aller voir dans /sys/bus/pci/devices : chaque périphérique y est
représenté par un lien symbolique vers un répertoire. Si dans ce répertoire
se trouve un lien symbolique « driver », le périphérique est reconnu.
Voici un petit script (zsh) pour voir ça :
for i in /sys/bus/pci/devices/*
if [[ -e $i/driver ]]; then
d=`readlink $i/driver`
print ${i:t} reconnu par ${d:t}
else
print ${i:t} inconnu
fi
très instructif ! merci
pour nvidia, pas de lien symbolique module --> xxxx, comme pour d'autres
peripf que j'ai regardés.
donc, il y a un pb. comment créer cette relation ? à la main ? en
recompilant le noyau ?
très instructif ! merci
pour nvidia, pas de lien symbolique module --> xxxx, comme pour d'autres
peripf que j'ai regardés.
donc, il y a un pb. comment créer cette relation ? à la main ? en
recompilant le noyau ?
très instructif ! merci
pour nvidia, pas de lien symbolique module --> xxxx, comme pour d'autres
peripf que j'ai regardés.
donc, il y a un pb. comment créer cette relation ? à la main ? en
recompilant le noyau ?
Si tu parles d'une carte graphique, c'est normal : ce n'est pas le noyau qui
la gère, à moins d'utiliser le framebuffer, c'est le serveur X11, et il ne
laisse pas de trace dans /sys/.
pour le moment, je veux installer mon chipset réseau NFORCE-MCP61 de
Il y a trois raisons qui peuvent faire que cette relation n'existent pas :
- Le module capable de gérer le périphérique en question existe dans
/lib/modules/`uname -r`/ mais il n'est pas chargé.
- Le driver capable de gérer le périphérique existe dans le noyau, mais il
n'a pas été compilé pour la version en utilisation actuellement.
- Le driver n'existe tout simplement pas.
Le premier cas ne devrait pas arriver avec une distribution actuelle
configurée par défaut, parce que les modules sont chargés automatiquement en
fonction des périphériques qu'ils sont censés reconnaître, mais une
bizarrerie peut se produire. Il faudrait essayer de voir dans modules.pcimap
s'il y a un module plausible correspondant aux identifiants PCI du
périphérique concerné.
je ne crois pas, mais je vais regarder cela à nouveau.
Pour le second cas, il faudrait fouiller dans les sources du noyau, à la
recherche des identifiants qui vont bien. Par exemple, pour mon contrôleur
SATA, ça ressemble à ça :
Si tu parles d'une carte graphique, c'est normal : ce n'est pas le noyau qui
la gère, à moins d'utiliser le framebuffer, c'est le serveur X11, et il ne
laisse pas de trace dans /sys/.
pour le moment, je veux installer mon chipset réseau NFORCE-MCP61 de
Il y a trois raisons qui peuvent faire que cette relation n'existent pas :
- Le module capable de gérer le périphérique en question existe dans
/lib/modules/`uname -r`/ mais il n'est pas chargé.
- Le driver capable de gérer le périphérique existe dans le noyau, mais il
n'a pas été compilé pour la version en utilisation actuellement.
- Le driver n'existe tout simplement pas.
Le premier cas ne devrait pas arriver avec une distribution actuelle
configurée par défaut, parce que les modules sont chargés automatiquement en
fonction des périphériques qu'ils sont censés reconnaître, mais une
bizarrerie peut se produire. Il faudrait essayer de voir dans modules.pcimap
s'il y a un module plausible correspondant aux identifiants PCI du
périphérique concerné.
je ne crois pas, mais je vais regarder cela à nouveau.
Pour le second cas, il faudrait fouiller dans les sources du noyau, à la
recherche des identifiants qui vont bien. Par exemple, pour mon contrôleur
SATA, ça ressemble à ça :
Si tu parles d'une carte graphique, c'est normal : ce n'est pas le noyau qui
la gère, à moins d'utiliser le framebuffer, c'est le serveur X11, et il ne
laisse pas de trace dans /sys/.
pour le moment, je veux installer mon chipset réseau NFORCE-MCP61 de
Il y a trois raisons qui peuvent faire que cette relation n'existent pas :
- Le module capable de gérer le périphérique en question existe dans
/lib/modules/`uname -r`/ mais il n'est pas chargé.
- Le driver capable de gérer le périphérique existe dans le noyau, mais il
n'a pas été compilé pour la version en utilisation actuellement.
- Le driver n'existe tout simplement pas.
Le premier cas ne devrait pas arriver avec une distribution actuelle
configurée par défaut, parce que les modules sont chargés automatiquement en
fonction des périphériques qu'ils sont censés reconnaître, mais une
bizarrerie peut se produire. Il faudrait essayer de voir dans modules.pcimap
s'il y a un module plausible correspondant aux identifiants PCI du
périphérique concerné.
je ne crois pas, mais je vais regarder cela à nouveau.
Pour le second cas, il faudrait fouiller dans les sources du noyau, à la
recherche des identifiants qui vont bien. Par exemple, pour mon contrôleur
SATA, ça ressemble à ça :
pour le moment, je veux installer mon chipset réseau NFORCE-MCP61 de
nvidia. ça fait 15 jours que je suis là dessus.
impossible d'avancer.
pour le moment, je veux installer mon chipset réseau NFORCE-MCP61 de
nvidia. ça fait 15 jours que je suis là dessus.
impossible d'avancer.
pour le moment, je veux installer mon chipset réseau NFORCE-MCP61 de
nvidia. ça fait 15 jours que je suis là dessus.
impossible d'avancer.
