J'ai un truc étrange sur mon portable (Dell Latitude, Debian/testing) :
j'ai une carte PCMCIA pour avoir des ports USB 2, sur laquelle je branche
un disque dur externe USB. Tout va bien, jusqu'au moment de débrancher le
disque : je démonte toutes les partitions, j'éteins le disque, puis je le
débranche et enfin j'enlève ma carte PCMCIA.
Et là, le clavier est mort. Aucune touche ne répond. La souris marche
encore parfaitement, mais rien à faire pour le clavier. La machine répond
encore en ssh, et à distance, tout va bien.
Dans mon syslog, je trouve ces lignes là qui me semblent correspondre :
========================================================================
Jan 27 09:47:56 cornas kernel: usb.c: USB disconnect on device 07:00.2-2 address 2
Jan 27 09:47:57 cornas usbmgr[506]: "scsi_mod" was unloaded
Jan 27 09:47:57 cornas usbmgr[506]: "sd_mod" was unloaded
Jan 27 09:47:57 cornas usbmgr[506]: "usb-storage" was unloaded
Jan 27 09:50:43 cornas kernel: ehci_hcd 07:00.2: remove state 0
Jan 27 09:50:43 cornas kernel: usb.c: USB disconnect on device 07:00.2-0 address 1
Jan 27 09:50:43 cornas kernel: usb.c: USB bus 2 deregistered
Jan 27 09:50:43 cornas kernel: cs: cb_free(bus 7)
Jan 27 09:50:43 cornas kernel: Unable to handle kernel paging request at virtual address e1cf7020
Jan 27 09:50:43 cornas kernel: printing eip:
Jan 27 09:50:43 cornas kernel: e1cef11d
Jan 27 09:50:43 cornas kernel: *pde = 19248067
Jan 27 09:50:43 cornas kernel: *pte = 00000000
Jan 27 09:50:43 cornas kernel: Oops: 0000
Jan 27 09:50:43 cornas kernel: CPU: 0
Jan 27 09:50:43 cornas kernel: EIP: 0010:[3c59x:__insmod_3c59x_S.data_L2344+20598525/92209159] Tainted: PF
Jan 27 09:50:43 cornas kernel: EFLAGS: 00210286
Jan 27 09:50:43 cornas kernel: eax: 00000000 ebx: d9239a00 ecx: d9239a00 edx: e1cf7020
Jan 27 09:50:43 cornas kernel: esi: d9239a64 edi: 00000000 ebp: c1616000 esp: c1617eac
Jan 27 09:50:43 cornas kernel: ds: 0018 es: 0018 ss: 0018
Jan 27 09:50:43 cornas kernel: Process keventd (pid: 2, stackpage=c1617000)
Jan 27 09:50:43 cornas kernel: Stack: c0271860 c02d4b00 00000013 00200046 c026aa3c c1617ecc 00200046 d
cc4df7c
Jan 27 09:50:43 cornas kernel: c1617ef0 00200286 dcc4c000 00000000 00000001 00200286 c02d1356 0
0200246
Jan 27 09:50:43 cornas kernel: 00000016 dceb1000 c011d961 0000000a 00000400 e0b549e4 00200246 d
9239a00
Jan 27 09:50:43 cornas kernel: Call Trace: [printk+273/336] [rtc:__insmod_rtc_O/lib/modules/2.4.26-
1-686/kernel/drivers/char+-124444/96] [3c59x:__insmod_3c59x_S.data_L2344+20612966/92194718] [rtc:__ins
mod_rtc_O/lib/modules/2.4.26-1-686/kernel/drivers/char+-128039/96] [rtc:__insmod_rtc_O/lib/modules/2.4
.26-1-686/kernel/drivers/char+-124467/96]
Jan 27 09:50:43 cornas kernel: [rtc:__insmod_rtc_O/lib/modules/2.4.26-1-686/kernel/drivers/char+-144
177/96] [rtc:__insmod_rtc_O/lib/modules/2.4.26-1-686/kernel/drivers/char+-142979/96] [rtc:__insmod_rtc
_O/lib/modules/2.4.26-1-686/kernel/drivers/char+-293200/96] [__run_task_queue+90/112] [rtc:__insmod_rt
c_O/lib/modules/2.4.26-1-686/kernel/drivers/char+-100572/96] [context_thread+307/464]
Jan 27 09:50:43 cornas kernel: [context_thread+0/464] [rest_init+0/64] [arch_kernel_thread+46/64] [c
ontext_thread+0/464]
Jan 27 09:50:43 cornas kernel:
Jan 27 09:50:43 cornas kernel: Code: 8b 02 83 c8 02 89 02 31 c0 89 81 00 01 00 00 c7 44 24 0c 90
===========================================================================
Je capte pas trop ce qu'il veut dire. Bon, au début, c'est les messages
normaux quand je débranche mon périphérique USB, mais ensuite, à partir de
"Unable to handle kernel paging...", c'est un problème du kernel, certes,
mais quoi ? Un module qui a planté ? Lequel ? La call-trace semble
indiquer qu'il y a eu un problème en chargeant un module 'char+', mais y'a
pas de modules de ce nom ou similaires chez moi (dans /lib/modules/...,
kernel/driver/char, c'est un répertoire qui ne contient pas de module
habituellement ou actuellement chargé, du moins il me semble).
Dans dmesg, je retrouve les mêmes infos, rien de plus.
Si je ferme ma session graphique, je me retrouve bien au gestionnaire de
login (kdm en l'occurrence), mais le clavier ne marche pas mieux. J'ai
essayé de relancer mon serveur X, mais je n'y arrive pas : si je tue kdm
(par ssh), ça va bien, mais si je le relance, le process est bien là, mais
il ne se passe rien sur ma machine (je reste en console).
Seule solution (jusqu'à présent) pour retrouver le clavier, c'est de
rebooter.
C'est un comportement reproductible, j'avais déjà eu exactement le même
problème la dernière fois que j'avais utilisé mon disque dur externe. Par
contre, je ne sais pas exactement si ça vient de la déconnexion de mon
disque dur ou de l'enlévement de la carte PCMCIA. J'aimerais assez trouver
une solution sans rebooter la machine, parce que j'y fais tourner un tas
de choses que j'aime bien ne pas avoir à relancer. Et comme elle est
accessible par ssh, ça me suffit plus ou moins en attendant...
Si vous avez des pistes...
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
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
Eric Dorino
On Thu, 27 Jan 2005 10:22:23 +0100, Remi Moyen wrote:
Salut,
Bonsoir
J'ai un truc étrange sur mon portable (Dell Latitude, Debian/testing) : j'ai une carte PCMCIA pour avoir des ports USB 2, sur laquelle je branche un disque dur externe USB. Tout va bien, jusqu'au moment de débrancher le disque : je démonte toutes les partitions, j'éteins le disque, puis je le débranche et enfin j'enlève ma carte PCMCIA.
Et là, le clavier est mort. Aucune touche ne répond. La souris marche encore parfaitement, mais rien à faire pour le clavier. La machine répond encore en ssh, et à distance, tout va bien.
Dans mon syslog, je trouve ces lignes là qui me semblent correspondre :
Pour ma part, je vois...
======================================================================= > Jan 27 09:47:56 cornas kernel: usb.c: USB disconnect on device 07:00.2-2 address 2 Jan 27 09:47:57 cornas usbmgr[506]: "scsi_mod" was unloaded Jan 27 09:47:57 cornas usbmgr[506]: "sd_mod" was unloaded Jan 27 09:47:57 cornas usbmgr[506]: "usb-storage" was unloaded
Démontage du disque...
Jan 27 09:50:43 cornas kernel: ehci_hcd 07:00.2: remove state 0 Jan 27 09:50:43 cornas kernel: usb.c: USB disconnect on device 07:00.2-0 address 1 Jan 27 09:50:43 cornas kernel: usb.c: USB bus 2 deregistered
Retrait d'un controleur EHCI...
Jan 27 09:50:43 cornas kernel: cs: cb_free(bus 7)
Retrait de la carte PCMCIA...
Jan 27 09:50:43 cornas kernel: Unable to handle kernel paging request at virtual address e1cf7020 Jan 27 09:50:43 cornas kernel: printing eip: Jan 27 09:50:43 cornas kernel: e1cef11d Jan 27 09:50:43 cornas kernel: *pde = 19248067 Jan 27 09:50:43 cornas kernel: *pte = 00000000 Jan 27 09:50:43 cornas kernel: Oops: 0000 Jan 27 09:50:43 cornas kernel: CPU: 0 Jan 27 09:50:43 cornas kernel: EIP: 0010:[3c59x:__insmod_3c59x_S.data_L2344+20598525/92209159] Tainted: PF Jan 27 09:50:43 cornas kernel: EFLAGS: 00210286 Jan 27 09:50:43 cornas kernel: eax: 00000000 ebx: d9239a00 ecx: d9239a00 edx: e1cf7020 Jan 27 09:50:43 cornas kernel: esi: d9239a64 edi: 00000000 ebp: c1616000 esp: c1617eac Jan 27 09:50:43 cornas kernel: ds: 0018 es: 0018 ss: 0018 Jan 27 09:50:43 cornas kernel: Process keventd (pid: 2, stackpageÁ617000)
Plantage de keventd... Ce thread noyau gère en particulier les insertions/retraits des cartes PCMCIA, mais à aussi à voir avec les chargements/déchargements des modules (je n'ai pas vérifié ce point).
Jan 27 09:50:43 cornas kernel: Stack: c0271860 c02d4b00 00000013 00200046 c026aa3c c1617ecc 00200046 d cc4df7c Jan 27 09:50:43 cornas kernel: c1617ef0 00200286 dcc4c000 00000000 00000001 00200286 c02d1356 0 0200246 Jan 27 09:50:43 cornas kernel: 00000016 dceb1000 c011d961 0000000a 00000400 e0b549e4 00200246 d 9239a00 Jan 27 09:50:43 cornas kernel: Call Trace: [printk+273/336] [rtc:__insmod_rtc_O/lib/modules/2.4.26- 1-686/kernel/drivers/char+-124444/96] [3c59x:__insmod_3c59x_S.data_L2344+20612966/92194718] [rtc:__ins mod_rtc_O/lib/modules/2.4.26-1-686/kernel/drivers/char+-128039/96] [rtc:__insmod_rtc_O/lib/modules/2.4 .26-1-686/kernel/drivers/char+-124467/96] Jan 27 09:50:43 cornas kernel: [rtc:__insmod_rtc_O/lib/modules/2.4.26-1-686/kernel/drivers/char+-144 177/96] [rtc:__insmod_rtc_O/lib/modules/2.4.26-1-686/kernel/drivers/char+-142979/96] [rtc:__insmod_rtc _O/lib/modules/2.4.26-1-686/kernel/drivers/char+-293200/96] [__run_task_queue+90/112] [rtc:__insmod_rt c_O/lib/modules/2.4.26-1-686/kernel/drivers/char+-100572/96] [context_thread+307/464] Jan 27 09:50:43 cornas kernel: [context_thread+0/464] [rest_init+0/64] [arch_kernel_thread+46/64] [c ontext_thread+0/464] Jan 27 09:50:43 cornas kernel: Jan 27 09:50:43 cornas kernel: Code: 8b 02 83 c8 02 89 02 31 c0 89 81 00 01 00 00 c7 44 24 0c 90 ========================================================================== > Je capte pas trop ce qu'il veut dire. Bon, au début, c'est les messages normaux quand je débranche mon périphérique USB, mais ensuite, à partir de "Unable to handle kernel paging...", c'est un problème du kernel, certes, mais quoi ? Un module qui a planté ? Lequel ? La call-trace semble indiquer qu'il y a eu un problème en chargeant un module 'char+', mais y'a pas de modules de ce nom ou similaires chez moi (dans /lib/modules/..., kernel/driver/char, c'est un répertoire qui ne contient pas de module habituellement ou actuellement chargé, du moins il me semble).
C'est un joli plantage.
Dans dmesg, je retrouve les mêmes infos, rien de plus.
Si je ferme ma session graphique, je me retrouve bien au gestionnaire de login (kdm en l'occurrence), mais le clavier ne marche pas mieux. J'ai essayé de relancer mon serveur X, mais je n'y arrive pas : si je tue kdm (par ssh), ça va bien, mais si je le relance, le process est bien là, mais il ne se passe rien sur ma machine (je reste en console).
Seule solution (jusqu'à présent) pour retrouver le clavier, c'est de rebooter.
C'est un comportement reproductible, j'avais déjà eu exactement le même problème la dernière fois que j'avais utilisé mon disque dur externe. Par contre, je ne sais pas exactement si ça vient de la déconnexion de mon disque dur ou de l'enlévement de la carte PCMCIA. J'aimerais assez trouver une solution sans rebooter la machine, parce que j'y fais tourner un tas de choses que j'aime bien ne pas avoir à relancer. Et comme elle est accessible par ssh, ça me suffit plus ou moins en attendant...
Il doit y avoir autre chose que le clavier de bloqué, je pense.
En déconnectant le DD sans toucher à la pccard, y-a-t-il plantage ou non (sur les traces, il y a 3 minutes entre le déchargement des modules et l'abort). Est-ce que le plantage est simplement reproductible, ou bien se produit-il tout le temps. Est-ce pcmcia-cs/cardmgr qui gère les cartes? Quelle est le type de la carte? le module qui la gère?
Si vous avez des pistes...
Je suppose que vu la taille des ports USB, laisser la carte dépasser dans le slot n'est pas une stratégie gagnante :-)
-- Eric
On Thu, 27 Jan 2005 10:22:23 +0100, Remi Moyen wrote:
Salut,
Bonsoir
J'ai un truc étrange sur mon portable (Dell Latitude, Debian/testing) :
j'ai une carte PCMCIA pour avoir des ports USB 2, sur laquelle je branche
un disque dur externe USB. Tout va bien, jusqu'au moment de débrancher le
disque : je démonte toutes les partitions, j'éteins le disque, puis je le
débranche et enfin j'enlève ma carte PCMCIA.
Et là, le clavier est mort. Aucune touche ne répond. La souris marche
encore parfaitement, mais rien à faire pour le clavier. La machine répond
encore en ssh, et à distance, tout va bien.
Dans mon syslog, je trouve ces lignes là qui me semblent correspondre :
Pour ma part, je vois...
======================================================================= > Jan 27 09:47:56 cornas kernel: usb.c: USB disconnect on device 07:00.2-2 address 2
Jan 27 09:47:57 cornas usbmgr[506]: "scsi_mod" was unloaded
Jan 27 09:47:57 cornas usbmgr[506]: "sd_mod" was unloaded
Jan 27 09:47:57 cornas usbmgr[506]: "usb-storage" was unloaded
Démontage du disque...
Jan 27 09:50:43 cornas kernel: ehci_hcd 07:00.2: remove state 0
Jan 27 09:50:43 cornas kernel: usb.c: USB disconnect on device 07:00.2-0 address 1
Jan 27 09:50:43 cornas kernel: usb.c: USB bus 2 deregistered
Retrait d'un controleur EHCI...
Jan 27 09:50:43 cornas kernel: cs: cb_free(bus 7)
Retrait de la carte PCMCIA...
Jan 27 09:50:43 cornas kernel: Unable to handle kernel paging request at virtual address e1cf7020
Jan 27 09:50:43 cornas kernel: printing eip:
Jan 27 09:50:43 cornas kernel: e1cef11d
Jan 27 09:50:43 cornas kernel: *pde = 19248067
Jan 27 09:50:43 cornas kernel: *pte = 00000000
Jan 27 09:50:43 cornas kernel: Oops: 0000
Jan 27 09:50:43 cornas kernel: CPU: 0
Jan 27 09:50:43 cornas kernel: EIP: 0010:[3c59x:__insmod_3c59x_S.data_L2344+20598525/92209159] Tainted: PF
Jan 27 09:50:43 cornas kernel: EFLAGS: 00210286
Jan 27 09:50:43 cornas kernel: eax: 00000000 ebx: d9239a00 ecx: d9239a00 edx: e1cf7020
Jan 27 09:50:43 cornas kernel: esi: d9239a64 edi: 00000000 ebp: c1616000 esp: c1617eac
Jan 27 09:50:43 cornas kernel: ds: 0018 es: 0018 ss: 0018
Jan 27 09:50:43 cornas kernel: Process keventd (pid: 2, stackpageÁ617000)
Plantage de keventd...
Ce thread noyau gère en particulier les insertions/retraits des cartes
PCMCIA, mais à aussi à voir avec les chargements/déchargements des
modules (je n'ai pas vérifié ce point).
Jan 27 09:50:43 cornas kernel: Stack: c0271860 c02d4b00 00000013 00200046 c026aa3c c1617ecc 00200046 d
cc4df7c
Jan 27 09:50:43 cornas kernel: c1617ef0 00200286 dcc4c000 00000000 00000001 00200286 c02d1356 0
0200246
Jan 27 09:50:43 cornas kernel: 00000016 dceb1000 c011d961 0000000a 00000400 e0b549e4 00200246 d
9239a00
Jan 27 09:50:43 cornas kernel: Call Trace: [printk+273/336] [rtc:__insmod_rtc_O/lib/modules/2.4.26-
1-686/kernel/drivers/char+-124444/96] [3c59x:__insmod_3c59x_S.data_L2344+20612966/92194718] [rtc:__ins
mod_rtc_O/lib/modules/2.4.26-1-686/kernel/drivers/char+-128039/96] [rtc:__insmod_rtc_O/lib/modules/2.4
.26-1-686/kernel/drivers/char+-124467/96]
Jan 27 09:50:43 cornas kernel: [rtc:__insmod_rtc_O/lib/modules/2.4.26-1-686/kernel/drivers/char+-144
177/96] [rtc:__insmod_rtc_O/lib/modules/2.4.26-1-686/kernel/drivers/char+-142979/96] [rtc:__insmod_rtc
_O/lib/modules/2.4.26-1-686/kernel/drivers/char+-293200/96] [__run_task_queue+90/112] [rtc:__insmod_rt
c_O/lib/modules/2.4.26-1-686/kernel/drivers/char+-100572/96] [context_thread+307/464]
Jan 27 09:50:43 cornas kernel: [context_thread+0/464] [rest_init+0/64] [arch_kernel_thread+46/64] [c
ontext_thread+0/464]
Jan 27 09:50:43 cornas kernel:
Jan 27 09:50:43 cornas kernel: Code: 8b 02 83 c8 02 89 02 31 c0 89 81 00 01 00 00 c7 44 24 0c 90
========================================================================== >
Je capte pas trop ce qu'il veut dire. Bon, au début, c'est les messages
normaux quand je débranche mon périphérique USB, mais ensuite, à partir de
"Unable to handle kernel paging...", c'est un problème du kernel, certes,
mais quoi ? Un module qui a planté ? Lequel ? La call-trace semble
indiquer qu'il y a eu un problème en chargeant un module 'char+', mais y'a
pas de modules de ce nom ou similaires chez moi (dans /lib/modules/...,
kernel/driver/char, c'est un répertoire qui ne contient pas de module
habituellement ou actuellement chargé, du moins il me semble).
C'est un joli plantage.
Dans dmesg, je retrouve les mêmes infos, rien de plus.
Si je ferme ma session graphique, je me retrouve bien au gestionnaire de
login (kdm en l'occurrence), mais le clavier ne marche pas mieux. J'ai
essayé de relancer mon serveur X, mais je n'y arrive pas : si je tue kdm
(par ssh), ça va bien, mais si je le relance, le process est bien là, mais
il ne se passe rien sur ma machine (je reste en console).
Seule solution (jusqu'à présent) pour retrouver le clavier, c'est de
rebooter.
C'est un comportement reproductible, j'avais déjà eu exactement le même
problème la dernière fois que j'avais utilisé mon disque dur externe. Par
contre, je ne sais pas exactement si ça vient de la déconnexion de mon
disque dur ou de l'enlévement de la carte PCMCIA. J'aimerais assez trouver
une solution sans rebooter la machine, parce que j'y fais tourner un tas
de choses que j'aime bien ne pas avoir à relancer. Et comme elle est
accessible par ssh, ça me suffit plus ou moins en attendant...
Il doit y avoir autre chose que le clavier de bloqué, je pense.
En déconnectant le DD sans toucher à la pccard, y-a-t-il plantage ou
non (sur les traces, il y a 3 minutes entre le déchargement des modules
et l'abort).
Est-ce que le plantage est simplement reproductible, ou bien
se produit-il tout le temps.
Est-ce pcmcia-cs/cardmgr qui gère les cartes?
Quelle est le type de la carte? le module qui la gère?
Si vous avez des pistes...
Je suppose que vu la taille des ports USB, laisser la carte dépasser dans
le slot n'est pas une stratégie gagnante :-)
On Thu, 27 Jan 2005 10:22:23 +0100, Remi Moyen wrote:
Salut,
Bonsoir
J'ai un truc étrange sur mon portable (Dell Latitude, Debian/testing) : j'ai une carte PCMCIA pour avoir des ports USB 2, sur laquelle je branche un disque dur externe USB. Tout va bien, jusqu'au moment de débrancher le disque : je démonte toutes les partitions, j'éteins le disque, puis je le débranche et enfin j'enlève ma carte PCMCIA.
Et là, le clavier est mort. Aucune touche ne répond. La souris marche encore parfaitement, mais rien à faire pour le clavier. La machine répond encore en ssh, et à distance, tout va bien.
Dans mon syslog, je trouve ces lignes là qui me semblent correspondre :
Pour ma part, je vois...
======================================================================= > Jan 27 09:47:56 cornas kernel: usb.c: USB disconnect on device 07:00.2-2 address 2 Jan 27 09:47:57 cornas usbmgr[506]: "scsi_mod" was unloaded Jan 27 09:47:57 cornas usbmgr[506]: "sd_mod" was unloaded Jan 27 09:47:57 cornas usbmgr[506]: "usb-storage" was unloaded
Démontage du disque...
Jan 27 09:50:43 cornas kernel: ehci_hcd 07:00.2: remove state 0 Jan 27 09:50:43 cornas kernel: usb.c: USB disconnect on device 07:00.2-0 address 1 Jan 27 09:50:43 cornas kernel: usb.c: USB bus 2 deregistered
Retrait d'un controleur EHCI...
Jan 27 09:50:43 cornas kernel: cs: cb_free(bus 7)
Retrait de la carte PCMCIA...
Jan 27 09:50:43 cornas kernel: Unable to handle kernel paging request at virtual address e1cf7020 Jan 27 09:50:43 cornas kernel: printing eip: Jan 27 09:50:43 cornas kernel: e1cef11d Jan 27 09:50:43 cornas kernel: *pde = 19248067 Jan 27 09:50:43 cornas kernel: *pte = 00000000 Jan 27 09:50:43 cornas kernel: Oops: 0000 Jan 27 09:50:43 cornas kernel: CPU: 0 Jan 27 09:50:43 cornas kernel: EIP: 0010:[3c59x:__insmod_3c59x_S.data_L2344+20598525/92209159] Tainted: PF Jan 27 09:50:43 cornas kernel: EFLAGS: 00210286 Jan 27 09:50:43 cornas kernel: eax: 00000000 ebx: d9239a00 ecx: d9239a00 edx: e1cf7020 Jan 27 09:50:43 cornas kernel: esi: d9239a64 edi: 00000000 ebp: c1616000 esp: c1617eac Jan 27 09:50:43 cornas kernel: ds: 0018 es: 0018 ss: 0018 Jan 27 09:50:43 cornas kernel: Process keventd (pid: 2, stackpageÁ617000)
Plantage de keventd... Ce thread noyau gère en particulier les insertions/retraits des cartes PCMCIA, mais à aussi à voir avec les chargements/déchargements des modules (je n'ai pas vérifié ce point).
Jan 27 09:50:43 cornas kernel: Stack: c0271860 c02d4b00 00000013 00200046 c026aa3c c1617ecc 00200046 d cc4df7c Jan 27 09:50:43 cornas kernel: c1617ef0 00200286 dcc4c000 00000000 00000001 00200286 c02d1356 0 0200246 Jan 27 09:50:43 cornas kernel: 00000016 dceb1000 c011d961 0000000a 00000400 e0b549e4 00200246 d 9239a00 Jan 27 09:50:43 cornas kernel: Call Trace: [printk+273/336] [rtc:__insmod_rtc_O/lib/modules/2.4.26- 1-686/kernel/drivers/char+-124444/96] [3c59x:__insmod_3c59x_S.data_L2344+20612966/92194718] [rtc:__ins mod_rtc_O/lib/modules/2.4.26-1-686/kernel/drivers/char+-128039/96] [rtc:__insmod_rtc_O/lib/modules/2.4 .26-1-686/kernel/drivers/char+-124467/96] Jan 27 09:50:43 cornas kernel: [rtc:__insmod_rtc_O/lib/modules/2.4.26-1-686/kernel/drivers/char+-144 177/96] [rtc:__insmod_rtc_O/lib/modules/2.4.26-1-686/kernel/drivers/char+-142979/96] [rtc:__insmod_rtc _O/lib/modules/2.4.26-1-686/kernel/drivers/char+-293200/96] [__run_task_queue+90/112] [rtc:__insmod_rt c_O/lib/modules/2.4.26-1-686/kernel/drivers/char+-100572/96] [context_thread+307/464] Jan 27 09:50:43 cornas kernel: [context_thread+0/464] [rest_init+0/64] [arch_kernel_thread+46/64] [c ontext_thread+0/464] Jan 27 09:50:43 cornas kernel: Jan 27 09:50:43 cornas kernel: Code: 8b 02 83 c8 02 89 02 31 c0 89 81 00 01 00 00 c7 44 24 0c 90 ========================================================================== > Je capte pas trop ce qu'il veut dire. Bon, au début, c'est les messages normaux quand je débranche mon périphérique USB, mais ensuite, à partir de "Unable to handle kernel paging...", c'est un problème du kernel, certes, mais quoi ? Un module qui a planté ? Lequel ? La call-trace semble indiquer qu'il y a eu un problème en chargeant un module 'char+', mais y'a pas de modules de ce nom ou similaires chez moi (dans /lib/modules/..., kernel/driver/char, c'est un répertoire qui ne contient pas de module habituellement ou actuellement chargé, du moins il me semble).
C'est un joli plantage.
Dans dmesg, je retrouve les mêmes infos, rien de plus.
Si je ferme ma session graphique, je me retrouve bien au gestionnaire de login (kdm en l'occurrence), mais le clavier ne marche pas mieux. J'ai essayé de relancer mon serveur X, mais je n'y arrive pas : si je tue kdm (par ssh), ça va bien, mais si je le relance, le process est bien là, mais il ne se passe rien sur ma machine (je reste en console).
Seule solution (jusqu'à présent) pour retrouver le clavier, c'est de rebooter.
C'est un comportement reproductible, j'avais déjà eu exactement le même problème la dernière fois que j'avais utilisé mon disque dur externe. Par contre, je ne sais pas exactement si ça vient de la déconnexion de mon disque dur ou de l'enlévement de la carte PCMCIA. J'aimerais assez trouver une solution sans rebooter la machine, parce que j'y fais tourner un tas de choses que j'aime bien ne pas avoir à relancer. Et comme elle est accessible par ssh, ça me suffit plus ou moins en attendant...
Il doit y avoir autre chose que le clavier de bloqué, je pense.
En déconnectant le DD sans toucher à la pccard, y-a-t-il plantage ou non (sur les traces, il y a 3 minutes entre le déchargement des modules et l'abort). Est-ce que le plantage est simplement reproductible, ou bien se produit-il tout le temps. Est-ce pcmcia-cs/cardmgr qui gère les cartes? Quelle est le type de la carte? le module qui la gère?
Si vous avez des pistes...
Je suppose que vu la taille des ports USB, laisser la carte dépasser dans le slot n'est pas une stratégie gagnante :-)
-- Eric
Remi Moyen
On Sat, 29 Jan 2005, Eric Dorino wrote:
Chic, enfin une réponse ! :-)
Dans mon syslog, je trouve ces lignes là qui me semblent correspondre :
Pour ma part, je vois...
Démontage du disque... Retrait d'un controleur EHCI... Retrait de la carte PCMCIA...
Jusque là, tout va bien, en effet.
Plantage de keventd... Ce thread noyau gère en particulier les insertions/retraits des cartes PCMCIA, mais à aussi à voir avec les chargements/déchargements des modules (je n'ai pas vérifié ce point).
Aha...
C'est un joli plantage.
Merci. Tu en veux une photo ? ;-)
Il doit y avoir autre chose que le clavier de bloqué, je pense.
Hum, peut-être, mais je ne vois pas quoi d'autre. La souris marche, de même que le réseau. Ah oui, tous les ports USB sont ensuite bloqués (ceux de la carte PCMCIA si j'essaye de la remettre, évidemment, mais aussi les 2 ports "natifs" de la machine). La souris est en PS/2, au fait (pas en USB !).
En déconnectant le DD sans toucher à la pccard, y-a-t-il plantage ou non (sur les traces, il y a 3 minutes entre le déchargement des modules et l'abort).
Non, je ne crois pas. J'ai pas refait le test exact (parce que je veux pas rebooter cette machine maintenant, j'ai des trucs qui tournent dessus), mais il me semble bien que non : après le démontage et avant l'ejection, j'ai effectivement fait quelques commandes. Maintenant, il est possible qu'il y ait un retard entre l'évenement déclencheur et le crash final, mais je n'y crois pas, parce que le plantage est vraiment à l'instant où j'enlève la carte PCMCIA.
À noter que si j'enlève la carte sans avoir jamais branché le disque dur dessus (je mets la carte, je vérifie qu'elle est reconnue, puis je l'enlève), alors tout allait bien.
Est-ce que le plantage est simplement reproductible, ou bien se produit-il tout le temps.
Ben, j'utilise très rarement ce disque dur (il me sert pour des sauvegardes mensuelles), et je ne branche rien d'autre sur ma carte PCMCIA, donc j'ai pas un pool d'expériences très grand, mais dans ces limites, oui, c'est systèmatique.
Est-ce pcmcia-cs/cardmgr qui gère les cartes?
Ouaip.
Quelle est le type de la carte? le module qui la gère?
Euh... Sunix "3 port USB2.0". Pas d'autre identifiant. Géré par pcmcia_core et yenta_socket.
Je suppose que vu la taille des ports USB, laisser la carte dépasser dans le slot n'est pas une stratégie gagnante :-)
Oui, parce que les slots sont à droite et ma souris aussi. Sinon, c'est sûr que ça serait le plus simple. Enfin, sauf pour transporter le portable. Et un portable non transportable, c'est pas top cool non plus... -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
On Sat, 29 Jan 2005, Eric Dorino wrote:
Chic, enfin une réponse ! :-)
Dans mon syslog, je trouve ces lignes là qui me semblent correspondre :
Pour ma part, je vois...
Démontage du disque...
Retrait d'un controleur EHCI...
Retrait de la carte PCMCIA...
Jusque là, tout va bien, en effet.
Plantage de keventd...
Ce thread noyau gère en particulier les insertions/retraits des cartes
PCMCIA, mais à aussi à voir avec les chargements/déchargements des
modules (je n'ai pas vérifié ce point).
Aha...
C'est un joli plantage.
Merci. Tu en veux une photo ? ;-)
Il doit y avoir autre chose que le clavier de bloqué, je pense.
Hum, peut-être, mais je ne vois pas quoi d'autre. La souris marche, de
même que le réseau. Ah oui, tous les ports USB sont ensuite bloqués (ceux
de la carte PCMCIA si j'essaye de la remettre, évidemment, mais aussi les
2 ports "natifs" de la machine). La souris est en PS/2, au fait (pas en
USB !).
En déconnectant le DD sans toucher à la pccard, y-a-t-il plantage ou
non (sur les traces, il y a 3 minutes entre le déchargement des modules
et l'abort).
Non, je ne crois pas. J'ai pas refait le test exact (parce que je veux pas
rebooter cette machine maintenant, j'ai des trucs qui tournent dessus),
mais il me semble bien que non : après le démontage et avant l'ejection,
j'ai effectivement fait quelques commandes. Maintenant, il est possible
qu'il y ait un retard entre l'évenement déclencheur et le crash final,
mais je n'y crois pas, parce que le plantage est vraiment à l'instant où
j'enlève la carte PCMCIA.
À noter que si j'enlève la carte sans avoir jamais branché le disque dur
dessus (je mets la carte, je vérifie qu'elle est reconnue, puis je
l'enlève), alors tout allait bien.
Est-ce que le plantage est simplement reproductible, ou bien
se produit-il tout le temps.
Ben, j'utilise très rarement ce disque dur (il me sert pour des
sauvegardes mensuelles), et je ne branche rien d'autre sur ma carte
PCMCIA, donc j'ai pas un pool d'expériences très grand, mais dans ces
limites, oui, c'est systèmatique.
Est-ce pcmcia-cs/cardmgr qui gère les cartes?
Ouaip.
Quelle est le type de la carte? le module qui la gère?
Euh... Sunix "3 port USB2.0". Pas d'autre identifiant. Géré par
pcmcia_core et yenta_socket.
Je suppose que vu la taille des ports USB, laisser la carte dépasser dans
le slot n'est pas une stratégie gagnante :-)
Oui, parce que les slots sont à droite et ma souris aussi. Sinon, c'est
sûr que ça serait le plus simple. Enfin, sauf pour transporter le
portable. Et un portable non transportable, c'est pas top cool non plus...
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
Dans mon syslog, je trouve ces lignes là qui me semblent correspondre :
Pour ma part, je vois...
Démontage du disque... Retrait d'un controleur EHCI... Retrait de la carte PCMCIA...
Jusque là, tout va bien, en effet.
Plantage de keventd... Ce thread noyau gère en particulier les insertions/retraits des cartes PCMCIA, mais à aussi à voir avec les chargements/déchargements des modules (je n'ai pas vérifié ce point).
Aha...
C'est un joli plantage.
Merci. Tu en veux une photo ? ;-)
Il doit y avoir autre chose que le clavier de bloqué, je pense.
Hum, peut-être, mais je ne vois pas quoi d'autre. La souris marche, de même que le réseau. Ah oui, tous les ports USB sont ensuite bloqués (ceux de la carte PCMCIA si j'essaye de la remettre, évidemment, mais aussi les 2 ports "natifs" de la machine). La souris est en PS/2, au fait (pas en USB !).
En déconnectant le DD sans toucher à la pccard, y-a-t-il plantage ou non (sur les traces, il y a 3 minutes entre le déchargement des modules et l'abort).
Non, je ne crois pas. J'ai pas refait le test exact (parce que je veux pas rebooter cette machine maintenant, j'ai des trucs qui tournent dessus), mais il me semble bien que non : après le démontage et avant l'ejection, j'ai effectivement fait quelques commandes. Maintenant, il est possible qu'il y ait un retard entre l'évenement déclencheur et le crash final, mais je n'y crois pas, parce que le plantage est vraiment à l'instant où j'enlève la carte PCMCIA.
À noter que si j'enlève la carte sans avoir jamais branché le disque dur dessus (je mets la carte, je vérifie qu'elle est reconnue, puis je l'enlève), alors tout allait bien.
Est-ce que le plantage est simplement reproductible, ou bien se produit-il tout le temps.
Ben, j'utilise très rarement ce disque dur (il me sert pour des sauvegardes mensuelles), et je ne branche rien d'autre sur ma carte PCMCIA, donc j'ai pas un pool d'expériences très grand, mais dans ces limites, oui, c'est systèmatique.
Est-ce pcmcia-cs/cardmgr qui gère les cartes?
Ouaip.
Quelle est le type de la carte? le module qui la gère?
Euh... Sunix "3 port USB2.0". Pas d'autre identifiant. Géré par pcmcia_core et yenta_socket.
Je suppose que vu la taille des ports USB, laisser la carte dépasser dans le slot n'est pas une stratégie gagnante :-)
Oui, parce que les slots sont à droite et ma souris aussi. Sinon, c'est sûr que ça serait le plus simple. Enfin, sauf pour transporter le portable. Et un portable non transportable, c'est pas top cool non plus... -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
Eric Dorino
On Mon, 31 Jan 2005 10:28:11 +0100, Remi Moyen wrote:
On Sat, 29 Jan 2005, Eric Dorino wrote:
Chic, enfin une réponse ! :-) Et une autre :-)
[snip trace]
C'est un joli plantage.
Merci. Tu en veux une photo ? ;-) Oui, oui, avec un apn branché sur la cardbus, si possible ...
Par contre j'ai vu la photo de la bestiole Sunix.
Bon, côté pcmcia/cardbus, il y a pas mal de problème de resources pci ou d'irq à l'insertion/retrait des cartes, dont perte de clavier et keventd pas loin (je ne sais plus où sont les url). L'embarras du choix...
J'allais demander les configs mais côté usb, j'ai vu http://www.linux-usb.org/usb2.html (vers la fin, paragraphe "host controller driver support"), qui explique qu'avant un noyau 2.5.29, la séquence de shutdown usb/pcmcia se plante. Ils conseillent de décharger le module à l'ancienne (rmmod ehci_hcd) avant l'éjection.
Mais c'est un truc à essayer.
[snip]
À noter que si j'enlève la carte sans avoir jamais branché le disque dur dessus (je mets la carte, je vérifie qu'elle est reconnue, puis je l'enlève), alors tout allait bien. Il n'y a pas eu de réservation de ressources dans ce cas(hypothèse).
Je suppose que vu la taille des ports USB, laisser la carte dépasser dans le slot n'est pas une stratégie gagnante :-)
Oui, parce que les slots sont à droite et ma souris aussi. Sinon, c'est sûr que ça serait le plus simple. Enfin, sauf pour transporter le portable. Et un portable non transportable, c'est pas top cool non plus... Non.
<mode fatigue> Le mien, en config voyage, avec la souris externe, le chargeur, les cordons téléphone/réseau, le hub usb/clavier/souris/port com/port parallèle (dont il faudrait que je m'occupe), le grigri lumière usb, le casque et le kensington, c'est juste transportable... </mode>
Tiens-moi au courant, stp.
-- Eric
On Mon, 31 Jan 2005 10:28:11 +0100, Remi Moyen wrote:
On Sat, 29 Jan 2005, Eric Dorino wrote:
Chic, enfin une réponse ! :-)
Et une autre :-)
[snip trace]
C'est un joli plantage.
Merci. Tu en veux une photo ? ;-)
Oui, oui, avec un apn branché sur la cardbus, si possible ...
Par contre j'ai vu la photo de la bestiole Sunix.
Bon, côté pcmcia/cardbus, il y a pas mal de problème de resources pci
ou d'irq à l'insertion/retrait des cartes, dont perte de clavier et
keventd pas loin (je ne sais plus où sont les url).
L'embarras du choix...
J'allais demander les configs mais côté usb, j'ai vu
http://www.linux-usb.org/usb2.html (vers la fin, paragraphe "host
controller driver support"), qui explique qu'avant un noyau 2.5.29, la
séquence de shutdown usb/pcmcia se plante. Ils conseillent de décharger
le module à l'ancienne (rmmod ehci_hcd) avant l'éjection.
Mais c'est un truc à essayer.
[snip]
À noter que si j'enlève la carte sans avoir jamais branché le disque dur
dessus (je mets la carte, je vérifie qu'elle est reconnue, puis je
l'enlève), alors tout allait bien.
Il n'y a pas eu de réservation de ressources dans ce cas(hypothèse).
Je suppose que vu la taille des ports USB, laisser la carte dépasser dans
le slot n'est pas une stratégie gagnante :-)
Oui, parce que les slots sont à droite et ma souris aussi. Sinon, c'est
sûr que ça serait le plus simple. Enfin, sauf pour transporter le
portable. Et un portable non transportable, c'est pas top cool non plus...
Non.
<mode fatigue>
Le mien, en config voyage, avec la souris externe, le chargeur, les
cordons téléphone/réseau, le hub usb/clavier/souris/port com/port
parallèle (dont il faudrait que je m'occupe), le grigri lumière usb, le
casque et le kensington, c'est juste transportable... </mode>
On Mon, 31 Jan 2005 10:28:11 +0100, Remi Moyen wrote:
On Sat, 29 Jan 2005, Eric Dorino wrote:
Chic, enfin une réponse ! :-) Et une autre :-)
[snip trace]
C'est un joli plantage.
Merci. Tu en veux une photo ? ;-) Oui, oui, avec un apn branché sur la cardbus, si possible ...
Par contre j'ai vu la photo de la bestiole Sunix.
Bon, côté pcmcia/cardbus, il y a pas mal de problème de resources pci ou d'irq à l'insertion/retrait des cartes, dont perte de clavier et keventd pas loin (je ne sais plus où sont les url). L'embarras du choix...
J'allais demander les configs mais côté usb, j'ai vu http://www.linux-usb.org/usb2.html (vers la fin, paragraphe "host controller driver support"), qui explique qu'avant un noyau 2.5.29, la séquence de shutdown usb/pcmcia se plante. Ils conseillent de décharger le module à l'ancienne (rmmod ehci_hcd) avant l'éjection.
Mais c'est un truc à essayer.
[snip]
À noter que si j'enlève la carte sans avoir jamais branché le disque dur dessus (je mets la carte, je vérifie qu'elle est reconnue, puis je l'enlève), alors tout allait bien. Il n'y a pas eu de réservation de ressources dans ce cas(hypothèse).
Je suppose que vu la taille des ports USB, laisser la carte dépasser dans le slot n'est pas une stratégie gagnante :-)
Oui, parce que les slots sont à droite et ma souris aussi. Sinon, c'est sûr que ça serait le plus simple. Enfin, sauf pour transporter le portable. Et un portable non transportable, c'est pas top cool non plus... Non.
<mode fatigue> Le mien, en config voyage, avec la souris externe, le chargeur, les cordons téléphone/réseau, le hub usb/clavier/souris/port com/port parallèle (dont il faudrait que je m'occupe), le grigri lumière usb, le casque et le kensington, c'est juste transportable... </mode>
Tiens-moi au courant, stp.
-- Eric
Remi Moyen
On Wed, 2 Feb 2005, Eric Dorino wrote:
Chic, enfin une réponse ! :-) Et une autre :-)
On se croirait sur un forum de discussion.
[snip trace]
C'est un joli plantage.
Merci. Tu en veux une photo ? ;-) Oui, oui, avec un apn branché sur la cardbus, si possible ...
D'accord, envoie-moi ton appareil photo :-)
Bon, côté pcmcia/cardbus, il y a pas mal de problème de resources pci ou d'irq à l'insertion/retrait des cartes, dont perte de clavier et keventd pas loin (je ne sais plus où sont les url). L'embarras du choix...
J'allais demander les configs mais côté usb, j'ai vu http://www.linux-usb.org/usb2.html (vers la fin, paragraphe "host controller driver support"), qui explique qu'avant un noyau 2.5.29, la séquence de shutdown usb/pcmcia se plante. Ils conseillent de décharger le module à l'ancienne (rmmod ehci_hcd) avant l'éjection.
Ah ben... Ça pourrait expliquer, en effet : j'ai bien un noyau < 2.5.29 (je suis encore sur un 2.4.26, pas vraiment récent. À moins que ces modifs n'aient été reportées sur les 2.4 ? Ah non, ils disent "it's also not being updated to match 2.6 any more.")
Mais c'est un truc à essayer.
Oui, ça me semble une bonne piste.
Et dire que j'ai lu cette page déjà des dizaines de fois en essayant de comprendre l'USB 2, sans jamais voir ce passage...
Tiens-moi au courant, stp.
Dès que je me suis décidé à rebooter, ce qui ne saurait tarder (d'autant plus que la date de la prochaine sauvegarde approche !). -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
On Wed, 2 Feb 2005, Eric Dorino wrote:
Chic, enfin une réponse ! :-)
Et une autre :-)
On se croirait sur un forum de discussion.
[snip trace]
C'est un joli plantage.
Merci. Tu en veux une photo ? ;-)
Oui, oui, avec un apn branché sur la cardbus, si possible ...
D'accord, envoie-moi ton appareil photo :-)
Bon, côté pcmcia/cardbus, il y a pas mal de problème de resources pci
ou d'irq à l'insertion/retrait des cartes, dont perte de clavier et
keventd pas loin (je ne sais plus où sont les url).
L'embarras du choix...
J'allais demander les configs mais côté usb, j'ai vu
http://www.linux-usb.org/usb2.html (vers la fin, paragraphe "host
controller driver support"), qui explique qu'avant un noyau 2.5.29, la
séquence de shutdown usb/pcmcia se plante. Ils conseillent de décharger
le module à l'ancienne (rmmod ehci_hcd) avant l'éjection.
Ah ben... Ça pourrait expliquer, en effet : j'ai bien un noyau < 2.5.29
(je suis encore sur un 2.4.26, pas vraiment récent. À moins que ces modifs
n'aient été reportées sur les 2.4 ? Ah non, ils disent "it's also not
being updated to match 2.6 any more.")
Mais c'est un truc à essayer.
Oui, ça me semble une bonne piste.
Et dire que j'ai lu cette page déjà des dizaines de fois en essayant de
comprendre l'USB 2, sans jamais voir ce passage...
Tiens-moi au courant, stp.
Dès que je me suis décidé à rebooter, ce qui ne saurait tarder (d'autant
plus que la date de la prochaine sauvegarde approche !).
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
Merci. Tu en veux une photo ? ;-) Oui, oui, avec un apn branché sur la cardbus, si possible ...
D'accord, envoie-moi ton appareil photo :-)
Bon, côté pcmcia/cardbus, il y a pas mal de problème de resources pci ou d'irq à l'insertion/retrait des cartes, dont perte de clavier et keventd pas loin (je ne sais plus où sont les url). L'embarras du choix...
J'allais demander les configs mais côté usb, j'ai vu http://www.linux-usb.org/usb2.html (vers la fin, paragraphe "host controller driver support"), qui explique qu'avant un noyau 2.5.29, la séquence de shutdown usb/pcmcia se plante. Ils conseillent de décharger le module à l'ancienne (rmmod ehci_hcd) avant l'éjection.
Ah ben... Ça pourrait expliquer, en effet : j'ai bien un noyau < 2.5.29 (je suis encore sur un 2.4.26, pas vraiment récent. À moins que ces modifs n'aient été reportées sur les 2.4 ? Ah non, ils disent "it's also not being updated to match 2.6 any more.")
Mais c'est un truc à essayer.
Oui, ça me semble une bonne piste.
Et dire que j'ai lu cette page déjà des dizaines de fois en essayant de comprendre l'USB 2, sans jamais voir ce passage...
Tiens-moi au courant, stp.
Dès que je me suis décidé à rebooter, ce qui ne saurait tarder (d'autant plus que la date de la prochaine sauvegarde approche !). -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
Remi Moyen
On Wed, 2 Feb 2005, Remi Moyen wrote:
J'allais demander les configs mais côté usb, j'ai vu http://www.linux-usb.org/usb2.html (vers la fin, paragraphe "host controller driver support"), qui explique qu'avant un noyau 2.5.29, la séquence de shutdown usb/pcmcia se plante. Ils conseillent de décharger le module à l'ancienne (rmmod ehci_hcd) avant l'éjection. [...]
Tiens-moi au courant, stp.
Donc, voilà c'est fait, j'ai testé :
Ça marche !
Il suffit bien d'enlever à la main le module ehci-hcd pour que ça ne gèle plus lors de l'ejection de la carte PCMCIA.
J'espère que je ne l'oublierais pas la prochaine fois que j'utiliserais cette carte...
Ceci dit, j'ai toujours rien compris aux modules USB et PCMCIA :
Je boote. Dans mon /etc/modules, je lui dit de charger yenta_socket (qui est nécessaire pour la carte PCMCIA), mais pas pcmcia_core (qui est cependant chargé automatiquement par yenta_socket). La carte n'est pas branchée à ce moment. Pas de problème.
Par contre, ehci-hcd, qui est juste après, ne se charge pas.
Un peu plus tard dans la séquence de boot, je sais pas pourquoi, il me dit qu'il essaye de re-charger pcmcia_core, qui est déjà chargé. Et ce coup-ci, j'ai des messages d'erreur (unresolved symbol etc.).
Enfin, un certain "usb-hid" se lance et détecte les ports USB.
Une fois booté, j'ai usbcore, usb-storage et usb-uhci de chargé.
Si je charge à la main usb-ohci ou ehci-hcd, j'ai des messages d'erreur, le chargement plante. Par contre, si je branche ma carte PCMCIA, alors là je peux charger/décharger ces deux modules tranquillement.
Buh... -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
On Wed, 2 Feb 2005, Remi Moyen wrote:
J'allais demander les configs mais côté usb, j'ai vu
http://www.linux-usb.org/usb2.html (vers la fin, paragraphe "host
controller driver support"), qui explique qu'avant un noyau 2.5.29, la
séquence de shutdown usb/pcmcia se plante. Ils conseillent de décharger
le module à l'ancienne (rmmod ehci_hcd) avant l'éjection.
[...]
Tiens-moi au courant, stp.
Donc, voilà c'est fait, j'ai testé :
Ça marche !
Il suffit bien d'enlever à la main le module ehci-hcd pour que ça ne gèle
plus lors de l'ejection de la carte PCMCIA.
J'espère que je ne l'oublierais pas la prochaine fois que j'utiliserais
cette carte...
Ceci dit, j'ai toujours rien compris aux modules USB et PCMCIA :
Je boote. Dans mon /etc/modules, je lui dit de charger yenta_socket (qui
est nécessaire pour la carte PCMCIA), mais pas pcmcia_core (qui est
cependant chargé automatiquement par yenta_socket). La carte n'est pas
branchée à ce moment. Pas de problème.
Par contre, ehci-hcd, qui est juste après, ne se charge pas.
Un peu plus tard dans la séquence de boot, je sais pas pourquoi, il me dit
qu'il essaye de re-charger pcmcia_core, qui est déjà chargé. Et ce
coup-ci, j'ai des messages d'erreur (unresolved symbol etc.).
Enfin, un certain "usb-hid" se lance et détecte les ports USB.
Une fois booté, j'ai usbcore, usb-storage et usb-uhci de chargé.
Si je charge à la main usb-ohci ou ehci-hcd, j'ai des messages d'erreur,
le chargement plante. Par contre, si je branche ma carte PCMCIA, alors là
je peux charger/décharger ces deux modules tranquillement.
Buh...
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
J'allais demander les configs mais côté usb, j'ai vu http://www.linux-usb.org/usb2.html (vers la fin, paragraphe "host controller driver support"), qui explique qu'avant un noyau 2.5.29, la séquence de shutdown usb/pcmcia se plante. Ils conseillent de décharger le module à l'ancienne (rmmod ehci_hcd) avant l'éjection. [...]
Tiens-moi au courant, stp.
Donc, voilà c'est fait, j'ai testé :
Ça marche !
Il suffit bien d'enlever à la main le module ehci-hcd pour que ça ne gèle plus lors de l'ejection de la carte PCMCIA.
J'espère que je ne l'oublierais pas la prochaine fois que j'utiliserais cette carte...
Ceci dit, j'ai toujours rien compris aux modules USB et PCMCIA :
Je boote. Dans mon /etc/modules, je lui dit de charger yenta_socket (qui est nécessaire pour la carte PCMCIA), mais pas pcmcia_core (qui est cependant chargé automatiquement par yenta_socket). La carte n'est pas branchée à ce moment. Pas de problème.
Par contre, ehci-hcd, qui est juste après, ne se charge pas.
Un peu plus tard dans la séquence de boot, je sais pas pourquoi, il me dit qu'il essaye de re-charger pcmcia_core, qui est déjà chargé. Et ce coup-ci, j'ai des messages d'erreur (unresolved symbol etc.).
Enfin, un certain "usb-hid" se lance et détecte les ports USB.
Une fois booté, j'ai usbcore, usb-storage et usb-uhci de chargé.
Si je charge à la main usb-ohci ou ehci-hcd, j'ai des messages d'erreur, le chargement plante. Par contre, si je branche ma carte PCMCIA, alors là je peux charger/décharger ces deux modules tranquillement.
Buh... -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
Eric Dorino
On Thu, 03 Feb 2005 16:49:01 +0100, Remi Moyen wrote:
On Wed, 2 Feb 2005, Remi Moyen wrote:
J'allais demander les configs mais côté usb, j'ai vu http://www.linux-usb.org/usb2.html (vers la fin, paragraphe "host controller driver support"), qui explique qu'avant un noyau 2.5.29, la séquence de shutdown usb/pcmcia se plante. Ils conseillent de décharger le module à l'ancienne (rmmod ehci_hcd) avant l'éjection. [...]
Tiens-moi au courant, stp.
Donc, voilà c'est fait, j'ai testé :
Ça marche !
Bien! c'est déjà ça.
Il suffit bien d'enlever à la main le module ehci-hcd pour que ça ne gèle plus lors de l'ejection de la carte PCMCIA.
J'espère que je ne l'oublierais pas la prochaine fois que j'utiliserais cette carte...
Ceci dit, j'ai toujours rien compris aux modules USB et PCMCIA :
Dis donc, c'est pourtant simple, non? Tu enlèves la carte, kevent se vautre en arrachant le clavier et l'usb en profite pour se barrer. Heureusement, la chaise reste solide :-)))
Je boote. Dans mon /etc/modules, je lui dit de charger yenta_socket (qui est nécessaire pour la carte PCMCIA), mais pas pcmcia_core (qui est cependant chargé automatiquement par yenta_socket). La carte n'est pas branchée à ce moment. Pas de problème.
Apparition des slots cardbus.
Par contre, ehci-hcd, qui est juste après, ne se charge pas.
Pas de carte insérée, pas d'ehci, logique.
Un peu plus tard dans la séquence de boot, je sais pas pourquoi, il me dit qu'il essaye de re-charger pcmcia_core, qui est déjà chargé. Et ce coup-ci, j'ai des messages d'erreur (unresolved symbol etc.).
Config un peu pessimiste ? Là, je ne suis pas assez calé en debian...
Enfin, un certain "usb-hid" se lance et détecte les ports USB.
Non. Normalement, celui-ci gère les claviers/souris/joysticks USB. Chargé par la config ou hotplug?
Une fois booté, j'ai usbcore, usb-storage et usb-uhci de chargé.
usbcore/uhci: contrôleur usb 1.x (universal: donc Intel, VIA et assimilés) du pc. usb-storage est pour les disques et assimilés (apn, clés). Chargé par config ou hotplug?
Si je charge à la main usb-ohci ou ehci-hcd, j'ai des messages d'erreur, le chargement plante. Par contre, si je branche ma carte PCMCIA, alors là je peux charger/décharger ces deux modules tranquillement.
ohci: contrôleur usb 1.x (open donc ni Intel ni VIA) ehci: contrôleur usb 2.0 C'est la cardbus.
Buh...
Mais non, mais non :-)
-- Eric
On Thu, 03 Feb 2005 16:49:01 +0100, Remi Moyen wrote:
On Wed, 2 Feb 2005, Remi Moyen wrote:
J'allais demander les configs mais côté usb, j'ai vu
http://www.linux-usb.org/usb2.html (vers la fin, paragraphe "host
controller driver support"), qui explique qu'avant un noyau 2.5.29, la
séquence de shutdown usb/pcmcia se plante. Ils conseillent de décharger
le module à l'ancienne (rmmod ehci_hcd) avant l'éjection.
[...]
Tiens-moi au courant, stp.
Donc, voilà c'est fait, j'ai testé :
Ça marche !
Bien! c'est déjà ça.
Il suffit bien d'enlever à la main le module ehci-hcd pour que ça ne gèle
plus lors de l'ejection de la carte PCMCIA.
J'espère que je ne l'oublierais pas la prochaine fois que j'utiliserais
cette carte...
Ceci dit, j'ai toujours rien compris aux modules USB et PCMCIA :
Dis donc, c'est pourtant simple, non?
Tu enlèves la carte, kevent se vautre en arrachant le clavier et l'usb en
profite pour se barrer.
Heureusement, la chaise reste solide :-)))
Je boote. Dans mon /etc/modules, je lui dit de charger yenta_socket (qui
est nécessaire pour la carte PCMCIA), mais pas pcmcia_core (qui est
cependant chargé automatiquement par yenta_socket). La carte n'est pas
branchée à ce moment. Pas de problème.
Apparition des slots cardbus.
Par contre, ehci-hcd, qui est juste après, ne se charge pas.
Pas de carte insérée, pas d'ehci, logique.
Un peu plus tard dans la séquence de boot, je sais pas pourquoi, il me dit
qu'il essaye de re-charger pcmcia_core, qui est déjà chargé. Et ce
coup-ci, j'ai des messages d'erreur (unresolved symbol etc.).
Config un peu pessimiste ?
Là, je ne suis pas assez calé en debian...
Enfin, un certain "usb-hid" se lance et détecte les ports USB.
Non. Normalement, celui-ci gère les claviers/souris/joysticks USB.
Chargé par la config ou hotplug?
Une fois booté, j'ai usbcore, usb-storage et usb-uhci de chargé.
usbcore/uhci: contrôleur usb 1.x (universal: donc Intel, VIA et
assimilés) du pc.
usb-storage est pour les disques et assimilés (apn, clés).
Chargé par config ou hotplug?
Si je charge à la main usb-ohci ou ehci-hcd, j'ai des messages d'erreur,
le chargement plante. Par contre, si je branche ma carte PCMCIA, alors là
je peux charger/décharger ces deux modules tranquillement.
ohci: contrôleur usb 1.x (open donc ni Intel ni VIA)
ehci: contrôleur usb 2.0
C'est la cardbus.
On Thu, 03 Feb 2005 16:49:01 +0100, Remi Moyen wrote:
On Wed, 2 Feb 2005, Remi Moyen wrote:
J'allais demander les configs mais côté usb, j'ai vu http://www.linux-usb.org/usb2.html (vers la fin, paragraphe "host controller driver support"), qui explique qu'avant un noyau 2.5.29, la séquence de shutdown usb/pcmcia se plante. Ils conseillent de décharger le module à l'ancienne (rmmod ehci_hcd) avant l'éjection. [...]
Tiens-moi au courant, stp.
Donc, voilà c'est fait, j'ai testé :
Ça marche !
Bien! c'est déjà ça.
Il suffit bien d'enlever à la main le module ehci-hcd pour que ça ne gèle plus lors de l'ejection de la carte PCMCIA.
J'espère que je ne l'oublierais pas la prochaine fois que j'utiliserais cette carte...
Ceci dit, j'ai toujours rien compris aux modules USB et PCMCIA :
Dis donc, c'est pourtant simple, non? Tu enlèves la carte, kevent se vautre en arrachant le clavier et l'usb en profite pour se barrer. Heureusement, la chaise reste solide :-)))
Je boote. Dans mon /etc/modules, je lui dit de charger yenta_socket (qui est nécessaire pour la carte PCMCIA), mais pas pcmcia_core (qui est cependant chargé automatiquement par yenta_socket). La carte n'est pas branchée à ce moment. Pas de problème.
Apparition des slots cardbus.
Par contre, ehci-hcd, qui est juste après, ne se charge pas.
Pas de carte insérée, pas d'ehci, logique.
Un peu plus tard dans la séquence de boot, je sais pas pourquoi, il me dit qu'il essaye de re-charger pcmcia_core, qui est déjà chargé. Et ce coup-ci, j'ai des messages d'erreur (unresolved symbol etc.).
Config un peu pessimiste ? Là, je ne suis pas assez calé en debian...
Enfin, un certain "usb-hid" se lance et détecte les ports USB.
Non. Normalement, celui-ci gère les claviers/souris/joysticks USB. Chargé par la config ou hotplug?
Une fois booté, j'ai usbcore, usb-storage et usb-uhci de chargé.
usbcore/uhci: contrôleur usb 1.x (universal: donc Intel, VIA et assimilés) du pc. usb-storage est pour les disques et assimilés (apn, clés). Chargé par config ou hotplug?
Si je charge à la main usb-ohci ou ehci-hcd, j'ai des messages d'erreur, le chargement plante. Par contre, si je branche ma carte PCMCIA, alors là je peux charger/décharger ces deux modules tranquillement.
ohci: contrôleur usb 1.x (open donc ni Intel ni VIA) ehci: contrôleur usb 2.0 C'est la cardbus.
Buh...
Mais non, mais non :-)
-- Eric
Remi Moyen
On Fri, 4 Feb 2005, Eric Dorino wrote:
Ça marche !
Bien! c'est déjà ça.
Voui.
Ceci dit, j'ai toujours rien compris aux modules USB et PCMCIA :
Dis donc, c'est pourtant simple, non? Tu enlèves la carte, kevent se vautre en arrachant le clavier et l'usb en profite pour se barrer. Heureusement, la chaise reste solide :-)))
Euh, oui, là, ça va. Sur cette séquence, j'ai compris ce qui foire. C'est sur ce que je décris après que j'ai pas tout suivi. Encore que tes explications m'éclairent pas mal.
Par contre, ehci-hcd, qui est juste après, ne se charge pas.
Pas de carte insérée, pas d'ehci, logique.
Ah, oui, parce que seule la carte fournit l'ehci, donc tant qu'elle n'est pas branchée, le module ne peut pas se charger. Oki...
Buh...
Mais non, mais non :-)
En effet. C'est plus clair. Je commence presque à comprendre.
Merci de tes précisions ! -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
On Fri, 4 Feb 2005, Eric Dorino wrote:
Ça marche !
Bien! c'est déjà ça.
Voui.
Ceci dit, j'ai toujours rien compris aux modules USB et PCMCIA :
Dis donc, c'est pourtant simple, non?
Tu enlèves la carte, kevent se vautre en arrachant le clavier et l'usb en
profite pour se barrer.
Heureusement, la chaise reste solide :-)))
Euh, oui, là, ça va. Sur cette séquence, j'ai compris ce qui foire. C'est
sur ce que je décris après que j'ai pas tout suivi. Encore que tes
explications m'éclairent pas mal.
Par contre, ehci-hcd, qui est juste après, ne se charge pas.
Pas de carte insérée, pas d'ehci, logique.
Ah, oui, parce que seule la carte fournit l'ehci, donc tant qu'elle n'est
pas branchée, le module ne peut pas se charger. Oki...
Buh...
Mais non, mais non :-)
En effet. C'est plus clair. Je commence presque à comprendre.
Merci de tes précisions !
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
Ceci dit, j'ai toujours rien compris aux modules USB et PCMCIA :
Dis donc, c'est pourtant simple, non? Tu enlèves la carte, kevent se vautre en arrachant le clavier et l'usb en profite pour se barrer. Heureusement, la chaise reste solide :-)))
Euh, oui, là, ça va. Sur cette séquence, j'ai compris ce qui foire. C'est sur ce que je décris après que j'ai pas tout suivi. Encore que tes explications m'éclairent pas mal.
Par contre, ehci-hcd, qui est juste après, ne se charge pas.
Pas de carte insérée, pas d'ehci, logique.
Ah, oui, parce que seule la carte fournit l'ehci, donc tant qu'elle n'est pas branchée, le module ne peut pas se charger. Oki...
Buh...
Mais non, mais non :-)
En effet. C'est plus clair. Je commence presque à comprendre.
Merci de tes précisions ! -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
