Il arrive qu'au boot, le module scsi prenne bien en compte le graveur mais
rate le scanner astra 610s.
Déjà, c'est un problème.
Auparavant, sur redhat8.0 ou SuSE7.2, je pouvais faire un rmmod puis un
modprobe sur le module, qui alors prenait bien en compte toute la chaine
scsi. J'avais même écrit un script qui faisait ça à la demande via sudo
pour appeler rmmod et modprobe.
Aujourd'hui, faire un rmmod aic7xxx gèle le pc.
C'est le probléme que je rencontre sur la SuSE 10.0, mais aussi auparavant
avec fedora3.
Je pense que le module est utilisé, et donc que son déchargement n'aboutit
jamais.
Peut-être cela est-il dû à un automatisme qui teste à espace régulier la
présence d'un disque dans le graveur : Le fichier /var/log/messages est
pollué par la ligne "localhost kernel: Device not ready. Make sure there
is a disc in the drive." Et le drive en question est bien le graveur
scsi, et non le lecteur dvd ide.
J'étais tout content de trouver dans /etc/auto.misc, la ligne
"cd -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom" que je me suis empressé de
commenter, sans succés.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
sansflotusspam
Bruno wrote:
salut à tous,
Il arrive qu'au boot, le module scsi prenne bien en compte le graveur mais rate le scanner astra 610s. Déjà, c'est un problème.
quelle carte scsi utilise-tu ? si c'est la carte d'origine fournie par Umax, c'est normal, c'est un modèle bridé qui n'est pas utilisable sous Unix (driver très spécial sous Win$, uniquement). en revanche, les Umax fonctionnent très bien avec des AHA ou des Initio (bien meilleures).
si tu as une carte standard, il faut regarder du côté du hotplug et de la base usermap ; les Umax, en particulier les Astra, sont parfaitement reconnus par sane / xsane, qque soit la distrib (j'en utilise depuis la MDK 8.2, c'est dire ...) A+
Auparavant, sur redhat8.0 ou SuSE7.2, je pouvais faire un rmmod puis un modprobe sur le module, qui alors prenait bien en compte toute la chaine scsi. J'avais même écrit un script qui faisait ça à la demande via sudo pour appeler rmmod et modprobe.
Aujourd'hui, faire un rmmod aic7xxx gèle le pc. C'est le probléme que je rencontre sur la SuSE 10.0, mais aussi auparavant avec fedora3.
Je pense que le module est utilisé, et donc que son déchargement n'aboutit jamais. Peut-être cela est-il dû à un automatisme qui teste à espace régulier la présence d'un disque dans le graveur : Le fichier /var/log/messages est pollué par la ligne "localhost kernel: Device not ready. Make sure there is a disc in the drive." Et le drive en question est bien le graveur scsi, et non le lecteur dvd ide.
J'étais tout content de trouver dans /etc/auto.misc, la ligne "cd -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom" que je me suis empressé de commenter, sans succés.
Que cela vous inspire-t-il ?
Merci de m'aider.
Bruno
Bruno wrote:
salut à tous,
Il arrive qu'au boot, le module scsi prenne bien en compte le graveur
mais
rate le scanner astra 610s.
Déjà, c'est un problème.
quelle carte scsi utilise-tu ?
si c'est la carte d'origine fournie par Umax, c'est normal, c'est un modèle
bridé qui n'est pas utilisable sous Unix (driver très spécial sous Win$,
uniquement).
en revanche, les Umax fonctionnent très bien avec des AHA ou des Initio
(bien meilleures).
si tu as une carte standard, il faut regarder du côté du hotplug et de la
base usermap ; les Umax, en particulier les Astra, sont parfaitement
reconnus par sane / xsane, qque soit la distrib (j'en utilise depuis la MDK
8.2, c'est dire ...)
A+
Auparavant, sur redhat8.0 ou SuSE7.2, je pouvais faire un rmmod puis un
modprobe sur le module, qui alors prenait bien en compte toute la chaine
scsi. J'avais même écrit un script qui faisait ça à la demande via sudo
pour appeler rmmod et modprobe.
Aujourd'hui, faire un rmmod aic7xxx gèle le pc.
C'est le probléme que je rencontre sur la SuSE 10.0, mais aussi
auparavant
avec fedora3.
Je pense que le module est utilisé, et donc que son déchargement
n'aboutit
jamais.
Peut-être cela est-il dû à un automatisme qui teste à espace régulier la
présence d'un disque dans le graveur : Le fichier /var/log/messages est
pollué par la ligne "localhost kernel: Device not ready. Make sure there
is a disc in the drive." Et le drive en question est bien le graveur
scsi, et non le lecteur dvd ide.
J'étais tout content de trouver dans /etc/auto.misc, la ligne
"cd -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom" que je me suis empressé
de commenter, sans succés.
Il arrive qu'au boot, le module scsi prenne bien en compte le graveur mais rate le scanner astra 610s. Déjà, c'est un problème.
quelle carte scsi utilise-tu ? si c'est la carte d'origine fournie par Umax, c'est normal, c'est un modèle bridé qui n'est pas utilisable sous Unix (driver très spécial sous Win$, uniquement). en revanche, les Umax fonctionnent très bien avec des AHA ou des Initio (bien meilleures).
si tu as une carte standard, il faut regarder du côté du hotplug et de la base usermap ; les Umax, en particulier les Astra, sont parfaitement reconnus par sane / xsane, qque soit la distrib (j'en utilise depuis la MDK 8.2, c'est dire ...) A+
Auparavant, sur redhat8.0 ou SuSE7.2, je pouvais faire un rmmod puis un modprobe sur le module, qui alors prenait bien en compte toute la chaine scsi. J'avais même écrit un script qui faisait ça à la demande via sudo pour appeler rmmod et modprobe.
Aujourd'hui, faire un rmmod aic7xxx gèle le pc. C'est le probléme que je rencontre sur la SuSE 10.0, mais aussi auparavant avec fedora3.
Je pense que le module est utilisé, et donc que son déchargement n'aboutit jamais. Peut-être cela est-il dû à un automatisme qui teste à espace régulier la présence d'un disque dans le graveur : Le fichier /var/log/messages est pollué par la ligne "localhost kernel: Device not ready. Make sure there is a disc in the drive." Et le drive en question est bien le graveur scsi, et non le lecteur dvd ide.
J'étais tout content de trouver dans /etc/auto.misc, la ligne "cd -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom" que je me suis empressé de commenter, sans succés.
Que cela vous inspire-t-il ?
Merci de m'aider.
Bruno
Bruno
sansflotusspam wrote:
quelle carte scsi utilise-tu ? si c'est la carte d'origine fournie par Umax, c'est normal, c'est un modèle bridé qui n'est pas utilisable sous Unix (driver très spécial sous Win$, uniquement). en revanche, les Umax fonctionnent très bien avec des AHA ou des Initio (bien meilleures).
si tu as une carte standard, il faut regarder du côté du hotplug et de la base usermap ; les Umax, en particulier les Astra, sont parfaitement reconnus par sane / xsane, qque soit la distrib (j'en utilise depuis la MDK 8.2, c'est dire ...) A+
Salut, Ma carte est une AHA2904, et pour être franc, si après avoir mis le scanner sous tension, j'attends une minute avant de lancer le pc, le scanner et détecté. C'est plutôt le problème du rmmod qui m'ennuie...
À+
sansflotusspam wrote:
quelle carte scsi utilise-tu ?
si c'est la carte d'origine fournie par Umax, c'est normal, c'est un
modèle bridé qui n'est pas utilisable sous Unix (driver très spécial sous
Win$, uniquement).
en revanche, les Umax fonctionnent très bien avec des AHA ou des Initio
(bien meilleures).
si tu as une carte standard, il faut regarder du côté du hotplug et de la
base usermap ; les Umax, en particulier les Astra, sont parfaitement
reconnus par sane / xsane, qque soit la distrib (j'en utilise depuis la
MDK 8.2, c'est dire ...)
A+
Salut,
Ma carte est une AHA2904, et pour être franc, si après avoir mis le
scanner sous tension, j'attends une minute avant de lancer le pc, le
scanner et détecté. C'est plutôt le problème du rmmod qui m'ennuie...
quelle carte scsi utilise-tu ? si c'est la carte d'origine fournie par Umax, c'est normal, c'est un modèle bridé qui n'est pas utilisable sous Unix (driver très spécial sous Win$, uniquement). en revanche, les Umax fonctionnent très bien avec des AHA ou des Initio (bien meilleures).
si tu as une carte standard, il faut regarder du côté du hotplug et de la base usermap ; les Umax, en particulier les Astra, sont parfaitement reconnus par sane / xsane, qque soit la distrib (j'en utilise depuis la MDK 8.2, c'est dire ...) A+
Salut, Ma carte est une AHA2904, et pour être franc, si après avoir mis le scanner sous tension, j'attends une minute avant de lancer le pc, le scanner et détecté. C'est plutôt le problème du rmmod qui m'ennuie...
À+
sansflotusspam
Bruno wrote:
sansflotusspam wrote:
quelle carte scsi utilise-tu ? si c'est la carte d'origine fournie par Umax, c'est normal, c'est un modèle bridé qui n'est pas utilisable sous Unix (driver très spécial sous Win$, uniquement). en revanche, les Umax fonctionnent très bien avec des AHA ou des Initio (bien meilleures).
si tu as une carte standard, il faut regarder du côté du hotplug et de la base usermap ; les Umax, en particulier les Astra, sont parfaitement reconnus par sane / xsane, qque soit la distrib (j'en utilise depuis la MDK 8.2, c'est dire ...) A+
Salut, Ma carte est une AHA2904, et pour être franc, si après avoir mis le scanner sous tension, j'attends une minute avant de lancer le pc, le scanner et détecté. C'est plutôt le problème du rmmod qui m'ennuie...
À+
à quel stade du boot le module aic... est-il chargé ? par l'initrd ? ou par /etc/modules ? par un script ? il me semble que si aic.. est dans l'espace kernel, il est normal que rmmod échoue, ce qui ne me semble pas normal, c'est que le scanner doive être allumé avant le PC A+
Bruno wrote:
sansflotusspam wrote:
quelle carte scsi utilise-tu ?
si c'est la carte d'origine fournie par Umax, c'est normal, c'est un
modèle bridé qui n'est pas utilisable sous Unix (driver très spécial sous
Win$, uniquement).
en revanche, les Umax fonctionnent très bien avec des AHA ou des Initio
(bien meilleures).
si tu as une carte standard, il faut regarder du côté du hotplug et de la
base usermap ; les Umax, en particulier les Astra, sont parfaitement
reconnus par sane / xsane, qque soit la distrib (j'en utilise depuis la
MDK 8.2, c'est dire ...)
A+
Salut,
Ma carte est une AHA2904, et pour être franc, si après avoir mis le
scanner sous tension, j'attends une minute avant de lancer le pc, le
scanner et détecté. C'est plutôt le problème du rmmod qui m'ennuie...
À+
à quel stade du boot le module aic... est-il chargé ?
par l'initrd ?
ou par /etc/modules ?
par un script ?
il me semble que si aic.. est dans l'espace kernel, il est normal que rmmod
échoue,
ce qui ne me semble pas normal, c'est que le scanner doive être allumé avant
le PC
A+
quelle carte scsi utilise-tu ? si c'est la carte d'origine fournie par Umax, c'est normal, c'est un modèle bridé qui n'est pas utilisable sous Unix (driver très spécial sous Win$, uniquement). en revanche, les Umax fonctionnent très bien avec des AHA ou des Initio (bien meilleures).
si tu as une carte standard, il faut regarder du côté du hotplug et de la base usermap ; les Umax, en particulier les Astra, sont parfaitement reconnus par sane / xsane, qque soit la distrib (j'en utilise depuis la MDK 8.2, c'est dire ...) A+
Salut, Ma carte est une AHA2904, et pour être franc, si après avoir mis le scanner sous tension, j'attends une minute avant de lancer le pc, le scanner et détecté. C'est plutôt le problème du rmmod qui m'ennuie...
À+
à quel stade du boot le module aic... est-il chargé ? par l'initrd ? ou par /etc/modules ? par un script ? il me semble que si aic.. est dans l'espace kernel, il est normal que rmmod échoue, ce qui ne me semble pas normal, c'est que le scanner doive être allumé avant le PC A+
Bruno
sansflotusspam wrote:
à quel stade du boot le module aic... est-il chargé ? par l'initrd ? ou par /etc/modules ? par un script ? il me semble que si aic.. est dans l'espace kernel, il est normal que rmmod échoue,
Il semble que le module soit chargé via initrd, il est listé dans /etc/sysconfig/kernel à la ligne "INITRD_MODULES=..."
Je ne maîtrise pas du tout le sujet, j'ai oté le nom du module de cette ligne et pourtant, au reboot, rien ne change : aic7xxx est tout de même chargé et ne peut être déchargé ; essayer gèle le système...
sinon, /etc/modules n'existe pas sous SuSE. Rien à propos du module scsi dans /etc/modprobe.d/ Juste la ligne "install scsi_hostadapter /bin/true" dans /etc/modprobe.conf
ce qui ne me semble pas normal, c'est que le scanner doive être allumé avant le PC
Comment le scanner pourrait-il être détecté si éteint ? Je ne comprends pas ton étonnement. La reco de la chaine scsi s'effectue au chargement du module, non ?
À+ et merci Bruno
sansflotusspam wrote:
à quel stade du boot le module aic... est-il chargé ?
par l'initrd ?
ou par /etc/modules ?
par un script ?
il me semble que si aic.. est dans l'espace kernel, il est normal que
rmmod échoue,
Il semble que le module soit chargé via initrd, il est listé
dans /etc/sysconfig/kernel à la ligne "INITRD_MODULES=..."
Je ne maîtrise pas du tout le sujet, j'ai oté le nom du module de cette
ligne et pourtant, au reboot, rien ne change : aic7xxx est tout de même
chargé et ne peut être déchargé ; essayer gèle le système...
sinon, /etc/modules n'existe pas sous SuSE.
Rien à propos du module scsi dans /etc/modprobe.d/
Juste la ligne "install scsi_hostadapter /bin/true"
dans /etc/modprobe.conf
ce qui ne me semble pas normal, c'est que le scanner doive être allumé
avant le PC
Comment le scanner pourrait-il être détecté si éteint ? Je ne comprends
pas ton étonnement. La reco de la chaine scsi s'effectue au chargement du
module, non ?
à quel stade du boot le module aic... est-il chargé ? par l'initrd ? ou par /etc/modules ? par un script ? il me semble que si aic.. est dans l'espace kernel, il est normal que rmmod échoue,
Il semble que le module soit chargé via initrd, il est listé dans /etc/sysconfig/kernel à la ligne "INITRD_MODULES=..."
Je ne maîtrise pas du tout le sujet, j'ai oté le nom du module de cette ligne et pourtant, au reboot, rien ne change : aic7xxx est tout de même chargé et ne peut être déchargé ; essayer gèle le système...
sinon, /etc/modules n'existe pas sous SuSE. Rien à propos du module scsi dans /etc/modprobe.d/ Juste la ligne "install scsi_hostadapter /bin/true" dans /etc/modprobe.conf
ce qui ne me semble pas normal, c'est que le scanner doive être allumé avant le PC
Comment le scanner pourrait-il être détecté si éteint ? Je ne comprends pas ton étonnement. La reco de la chaine scsi s'effectue au chargement du module, non ?
À+ et merci Bruno
Emmanuel Florac
Le Wed, 03 May 2006 19:54:18 +0200, Bruno a écrit :
Il semble que le module soit chargé via initrd, il est listé dans /etc/sysconfig/kernel à la ligne "INITRD_MODULES=..."
C'est sûrement la source du problème.
Je ne maîtrise pas du tout le sujet, j'ai oté le nom du module de cette ligne et pourtant, au reboot, rien ne change : aic7xxx est tout de même chargé et ne peut être déchargé ; essayer gèle le système...
Il faut recréer l'initrd, sans le module. Je ne sais pas comment on fait ça avec SuSE.
-- De longs désirs, une longue admiration sans espérance, voilà le moyen d'adorer les femmes, et de rendre l'amour une passion délicieuse! N. Rétif de la Bretonne.
Le Wed, 03 May 2006 19:54:18 +0200, Bruno a écrit :
Il semble que le module soit chargé via initrd, il est listé
dans /etc/sysconfig/kernel à la ligne "INITRD_MODULES=..."
C'est sûrement la source du problème.
Je ne maîtrise pas du tout le sujet, j'ai oté le nom du module de cette
ligne et pourtant, au reboot, rien ne change : aic7xxx est tout de même
chargé et ne peut être déchargé ; essayer gèle le système...
Il faut recréer l'initrd, sans le module. Je ne sais pas comment on fait
ça avec SuSE.
--
De longs désirs, une longue admiration sans espérance, voilà le moyen
d'adorer les femmes, et de rendre l'amour une passion délicieuse!
N. Rétif de la Bretonne.
Le Wed, 03 May 2006 19:54:18 +0200, Bruno a écrit :
Il semble que le module soit chargé via initrd, il est listé dans /etc/sysconfig/kernel à la ligne "INITRD_MODULES=..."
C'est sûrement la source du problème.
Je ne maîtrise pas du tout le sujet, j'ai oté le nom du module de cette ligne et pourtant, au reboot, rien ne change : aic7xxx est tout de même chargé et ne peut être déchargé ; essayer gèle le système...
Il faut recréer l'initrd, sans le module. Je ne sais pas comment on fait ça avec SuSE.
-- De longs désirs, une longue admiration sans espérance, voilà le moyen d'adorer les femmes, et de rendre l'amour une passion délicieuse! N. Rétif de la Bretonne.
sansflotusspam
Bruno wrote:
sansflotusspam wrote:
à quel stade du boot le module aic... est-il chargé ? par l'initrd ? ou par /etc/modules ? par un script ? il me semble que si aic.. est dans l'espace kernel, il est normal que rmmod échoue,
Il semble que le module soit chargé via initrd, il est listé dans /etc/sysconfig/kernel à la ligne "INITRD_MODULES=..."
Je ne maîtrise pas du tout le sujet, j'ai oté le nom du module de cette ligne et pourtant, au reboot, rien ne change : aic7xxx est tout de même chargé et ne peut être déchargé ; essayer gèle le système...
sinon, /etc/modules n'existe pas sous SuSE. Rien à propos du module scsi dans /etc/modprobe.d/ Juste la ligne "install scsi_hostadapter /bin/true" dans /etc/modprobe.conf
ce qui ne me semble pas normal, c'est que le scanner doive être allumé avant le PC
Comment le scanner pourrait-il être détecté si éteint ? Je ne comprends pas ton étonnement. La reco de la chaine scsi s'effectue au chargement du module, non ?
À+ et merci Bruno
je ne connais pas du tout les particularités de la Süse, mais à part qques différences de "présentation" dans les fichiers de conf, toutes les distribs basées sur un noyau linux fonctionnent pareillement. dans ta config, le module aic7... est bien chargé par l'initrd, donc il réside dans l'espace noyau, ç.a.d. "en dur" ; il est normal qu'une tentative de déchargement du module provoque des soubresauts.
ensuite, il n'est pas du tout impératif que la chaîne scsi soit initiée au boot, les systèmes "linux" sont parfaitement capables de reconnaître l'arrivée de périphs à chaud et de charger le(s) module(s) nécessaire(s), ainsi que les décharger quand ils ne sont plus utiles (périph éteint). normalement, c'est le branchement (l'allumage) du scanner qui déclenche la reconnaissance, le chargement du module et l'attachement à la chaîne scsi.
c'est ainsi que mon vieil Umax 610S a toujours fonctionné, sous MDK 8.2, 9.0, 9.1 et Slackware (on peut ajouter Knoppix, Mepis et qques autres), sans le moindre problème (enfin, côté linux, because côté scanner, il a vieilli le pauvre).
il me semble que le problème vienne d'ailleurs ; que contiennent exactement les fichiers /etc/sane.d/dll.conf (les directives scsi en particulier) et /etc/sane.d/umax.conf ?
A+
Bruno wrote:
sansflotusspam wrote:
à quel stade du boot le module aic... est-il chargé ?
par l'initrd ?
ou par /etc/modules ?
par un script ?
il me semble que si aic.. est dans l'espace kernel, il est normal que
rmmod échoue,
Il semble que le module soit chargé via initrd, il est listé
dans /etc/sysconfig/kernel à la ligne "INITRD_MODULES=..."
Je ne maîtrise pas du tout le sujet, j'ai oté le nom du module de cette
ligne et pourtant, au reboot, rien ne change : aic7xxx est tout de même
chargé et ne peut être déchargé ; essayer gèle le système...
sinon, /etc/modules n'existe pas sous SuSE.
Rien à propos du module scsi dans /etc/modprobe.d/
Juste la ligne "install scsi_hostadapter /bin/true"
dans /etc/modprobe.conf
ce qui ne me semble pas normal, c'est que le scanner doive être allumé
avant le PC
Comment le scanner pourrait-il être détecté si éteint ? Je ne comprends
pas ton étonnement. La reco de la chaine scsi s'effectue au chargement du
module, non ?
À+ et merci
Bruno
je ne connais pas du tout les particularités de la Süse, mais à part qques
différences de "présentation" dans les fichiers de conf, toutes les
distribs basées sur un noyau linux fonctionnent pareillement.
dans ta config, le module aic7... est bien chargé par l'initrd, donc il
réside dans l'espace noyau, ç.a.d. "en dur" ; il est normal qu'une
tentative de déchargement du module provoque des soubresauts.
ensuite, il n'est pas du tout impératif que la chaîne scsi soit initiée au
boot, les systèmes "linux" sont parfaitement capables de reconnaître
l'arrivée de périphs à chaud et de charger le(s) module(s) nécessaire(s),
ainsi que les décharger quand ils ne sont plus utiles (périph éteint).
normalement, c'est le branchement (l'allumage) du scanner qui déclenche la
reconnaissance, le chargement du module et l'attachement à la chaîne scsi.
c'est ainsi que mon vieil Umax 610S a toujours fonctionné, sous MDK 8.2,
9.0, 9.1 et Slackware (on peut ajouter Knoppix, Mepis et qques autres),
sans le moindre problème (enfin, côté linux, because côté scanner, il a
vieilli le pauvre).
il me semble que le problème vienne d'ailleurs ; que contiennent exactement
les fichiers /etc/sane.d/dll.conf (les directives scsi en particulier)
et /etc/sane.d/umax.conf ?
à quel stade du boot le module aic... est-il chargé ? par l'initrd ? ou par /etc/modules ? par un script ? il me semble que si aic.. est dans l'espace kernel, il est normal que rmmod échoue,
Il semble que le module soit chargé via initrd, il est listé dans /etc/sysconfig/kernel à la ligne "INITRD_MODULES=..."
Je ne maîtrise pas du tout le sujet, j'ai oté le nom du module de cette ligne et pourtant, au reboot, rien ne change : aic7xxx est tout de même chargé et ne peut être déchargé ; essayer gèle le système...
sinon, /etc/modules n'existe pas sous SuSE. Rien à propos du module scsi dans /etc/modprobe.d/ Juste la ligne "install scsi_hostadapter /bin/true" dans /etc/modprobe.conf
ce qui ne me semble pas normal, c'est que le scanner doive être allumé avant le PC
Comment le scanner pourrait-il être détecté si éteint ? Je ne comprends pas ton étonnement. La reco de la chaine scsi s'effectue au chargement du module, non ?
À+ et merci Bruno
je ne connais pas du tout les particularités de la Süse, mais à part qques différences de "présentation" dans les fichiers de conf, toutes les distribs basées sur un noyau linux fonctionnent pareillement. dans ta config, le module aic7... est bien chargé par l'initrd, donc il réside dans l'espace noyau, ç.a.d. "en dur" ; il est normal qu'une tentative de déchargement du module provoque des soubresauts.
ensuite, il n'est pas du tout impératif que la chaîne scsi soit initiée au boot, les systèmes "linux" sont parfaitement capables de reconnaître l'arrivée de périphs à chaud et de charger le(s) module(s) nécessaire(s), ainsi que les décharger quand ils ne sont plus utiles (périph éteint). normalement, c'est le branchement (l'allumage) du scanner qui déclenche la reconnaissance, le chargement du module et l'attachement à la chaîne scsi.
c'est ainsi que mon vieil Umax 610S a toujours fonctionné, sous MDK 8.2, 9.0, 9.1 et Slackware (on peut ajouter Knoppix, Mepis et qques autres), sans le moindre problème (enfin, côté linux, because côté scanner, il a vieilli le pauvre).
il me semble que le problème vienne d'ailleurs ; que contiennent exactement les fichiers /etc/sane.d/dll.conf (les directives scsi en particulier) et /etc/sane.d/umax.conf ?
A+
Bruno
sansflotusspam wrote:
je ne connais pas du tout les particularités de la Süse, mais à part qques différences de "présentation" dans les fichiers de conf, toutes les distribs basées sur un noyau linux fonctionnent pareillement. dans ta config, le module aic7... est bien chargé par l'initrd, donc il réside dans l'espace noyau, ç.a.d. "en dur" ; il est normal qu'une tentative de déchargement du module provoque des soubresauts.
aic7xxx est un module, chargé comme tel, il n'est donc pas en dur dans le noyau... Mais chargé dans l'espace noyau, peut-être. Je dois me documenter sur ce concept qui m'est inconnu.
ensuite, il n'est pas du tout impératif que la chaîne scsi soit initiée au boot, les systèmes "linux" sont parfaitement capables de reconnaître l'arrivée de périphs à chaud et de charger le(s) module(s) nécessaire(s), ainsi que les décharger quand ils ne sont plus utiles (périph éteint). normalement, c'est le branchement (l'allumage) du scanner qui déclenche la reconnaissance, le chargement du module et l'attachement à la chaîne scsi.
Mais si le module est chargé au boot, il ne pourrait l'être à nouveau au branchement du scannner ? Qui plus est, mon graveur scsi est branché en permanence, ainsi le module ne saurait être déchargé pour des raisons de non-utilisation. C'est la raison pour laquelle j'utilisais le couple rmmod-modprobe en cas de branchement du scanner en cours de travail ou de perturbations dans la chaine scsi par exemple.
c'est ainsi que mon vieil Umax 610S a toujours fonctionné, sous MDK 8.2, 9.0, 9.1 et Slackware (on peut ajouter Knoppix, Mepis et qques autres), sans le moindre problème (enfin, côté linux, because côté scanner, il a vieilli le pauvre).
Et oui...
il me semble que le problème vienne d'ailleurs ; que contiennent exactement les fichiers /etc/sane.d/dll.conf (les directives scsi en particulier) et /etc/sane.d/umax.conf ?
Rien de bien notable de ce côté, classique voire minimaliste. Mais tu sais, dès lors que le module a reconnu le scanner, (listé dans /proc/scsi/scsi) Xsane fonctionne très bien.
A+
Merci et à +
sansflotusspam wrote:
je ne connais pas du tout les particularités de la Süse, mais à part
qques différences de "présentation" dans les fichiers de conf, toutes les
distribs basées sur un noyau linux fonctionnent pareillement.
dans ta config, le module aic7... est bien chargé par l'initrd, donc il
réside dans l'espace noyau, ç.a.d. "en dur" ; il est normal qu'une
tentative de déchargement du module provoque des soubresauts.
aic7xxx est un module, chargé comme tel, il n'est donc pas en dur dans le
noyau...
Mais chargé dans l'espace noyau, peut-être. Je dois me documenter sur ce
concept qui m'est inconnu.
ensuite, il n'est pas du tout impératif que la chaîne scsi soit initiée
au boot, les systèmes "linux" sont parfaitement capables de reconnaître
l'arrivée de périphs à chaud et de charger le(s) module(s) nécessaire(s),
ainsi que les décharger quand ils ne sont plus utiles (périph éteint).
normalement, c'est le branchement (l'allumage) du scanner qui déclenche
la reconnaissance, le chargement du module et l'attachement à la chaîne
scsi.
Mais si le module est chargé au boot, il ne pourrait l'être à nouveau au
branchement du scannner ? Qui plus est, mon graveur scsi est branché en
permanence, ainsi le module ne saurait être déchargé pour des raisons de
non-utilisation.
C'est la raison pour laquelle j'utilisais le couple rmmod-modprobe en cas
de branchement du scanner en cours de travail ou de perturbations dans la
chaine scsi par exemple.
c'est ainsi que mon vieil Umax 610S a toujours fonctionné, sous MDK 8.2,
9.0, 9.1 et Slackware (on peut ajouter Knoppix, Mepis et qques autres),
sans le moindre problème (enfin, côté linux, because côté scanner, il a
vieilli le pauvre).
Et oui...
il me semble que le problème vienne d'ailleurs ; que contiennent
exactement les fichiers /etc/sane.d/dll.conf (les directives scsi en
particulier) et /etc/sane.d/umax.conf ?
Rien de bien notable de ce côté, classique voire minimaliste. Mais tu
sais, dès lors que le module a reconnu le scanner, (listé
dans /proc/scsi/scsi) Xsane fonctionne très bien.
je ne connais pas du tout les particularités de la Süse, mais à part qques différences de "présentation" dans les fichiers de conf, toutes les distribs basées sur un noyau linux fonctionnent pareillement. dans ta config, le module aic7... est bien chargé par l'initrd, donc il réside dans l'espace noyau, ç.a.d. "en dur" ; il est normal qu'une tentative de déchargement du module provoque des soubresauts.
aic7xxx est un module, chargé comme tel, il n'est donc pas en dur dans le noyau... Mais chargé dans l'espace noyau, peut-être. Je dois me documenter sur ce concept qui m'est inconnu.
ensuite, il n'est pas du tout impératif que la chaîne scsi soit initiée au boot, les systèmes "linux" sont parfaitement capables de reconnaître l'arrivée de périphs à chaud et de charger le(s) module(s) nécessaire(s), ainsi que les décharger quand ils ne sont plus utiles (périph éteint). normalement, c'est le branchement (l'allumage) du scanner qui déclenche la reconnaissance, le chargement du module et l'attachement à la chaîne scsi.
Mais si le module est chargé au boot, il ne pourrait l'être à nouveau au branchement du scannner ? Qui plus est, mon graveur scsi est branché en permanence, ainsi le module ne saurait être déchargé pour des raisons de non-utilisation. C'est la raison pour laquelle j'utilisais le couple rmmod-modprobe en cas de branchement du scanner en cours de travail ou de perturbations dans la chaine scsi par exemple.
c'est ainsi que mon vieil Umax 610S a toujours fonctionné, sous MDK 8.2, 9.0, 9.1 et Slackware (on peut ajouter Knoppix, Mepis et qques autres), sans le moindre problème (enfin, côté linux, because côté scanner, il a vieilli le pauvre).
Et oui...
il me semble que le problème vienne d'ailleurs ; que contiennent exactement les fichiers /etc/sane.d/dll.conf (les directives scsi en particulier) et /etc/sane.d/umax.conf ?
Rien de bien notable de ce côté, classique voire minimaliste. Mais tu sais, dès lors que le module a reconnu le scanner, (listé dans /proc/scsi/scsi) Xsane fonctionne très bien.
A+
Merci et à +
Bruno
Emmanuel Florac wrote:
Le Wed, 03 May 2006 19:54:18 +0200, Bruno a écrit :
Il semble que le module soit chargé via initrd, il est listé dans /etc/sysconfig/kernel à la ligne "INITRD_MODULES=..."
C'est sûrement la source du problème. Il faut recréer l'initrd, sans le module. Je ne sais pas comment on fait ça avec SuSE.
Dès que possible, je me lance à la recherche d'infos concernant le chargement des modules via initrd, même si le problème, par ailleurs pas si dramatique, ne s'en trouve pas résolu, j'aurais au moins appris quelque-chose. Je vous tiens au courant.
Merci et à +
Emmanuel Florac wrote:
Le Wed, 03 May 2006 19:54:18 +0200, Bruno a écrit :
Il semble que le module soit chargé via initrd, il est listé
dans /etc/sysconfig/kernel à la ligne "INITRD_MODULES=..."
C'est sûrement la source du problème.
Il faut recréer l'initrd, sans le module. Je ne sais pas comment on fait
ça avec SuSE.
Dès que possible, je me lance à la recherche d'infos concernant le
chargement des modules via initrd, même si le problème, par ailleurs pas
si dramatique, ne s'en trouve pas résolu, j'aurais au moins appris
quelque-chose. Je vous tiens au courant.
Le Wed, 03 May 2006 19:54:18 +0200, Bruno a écrit :
Il semble que le module soit chargé via initrd, il est listé dans /etc/sysconfig/kernel à la ligne "INITRD_MODULES=..."
C'est sûrement la source du problème. Il faut recréer l'initrd, sans le module. Je ne sais pas comment on fait ça avec SuSE.
Dès que possible, je me lance à la recherche d'infos concernant le chargement des modules via initrd, même si le problème, par ailleurs pas si dramatique, ne s'en trouve pas résolu, j'aurais au moins appris quelque-chose. Je vous tiens au courant.
