Bonjour a tous,
Ma config :
CM ABIT NF7-S 2.0 avec controlleur S-ATA Silicon Image 3112A
Disque IDE IBM 40 Go
Disque S-ATA Hitachi 160 Go
Linux noyau 2.6.10
Le boot se fait sur le disque IBM
Maintenant le probleme :
Si je compile le driver SCSI pour le controleur SI 3112A sous forme de
module (sata_sil.o), tout fonctionne correctement. Le controleur est
detecté, le disque Hitachi egalement. Le disque est reconnu comme disque
SCSI, et je peux monter les partitions et y acceder sans probleme, en
tant que disque SCSI (/dev/sdaX).
Par contre, si je compile le support SI 3112A dans le noyau, et non en
module, le systeme se bloque lors du boot a la detection du disque
Hitachi par le controleur S-ATA. J'ai eu beau chercher sur des tas de
forums, meme lire le code du noyau, je n'ai aucune idée du pourquoi de
se bloquage.
Si quelqu'un a une idée ou une piste, je suis preneur...
Bonjour a tous,
Ma config :
CM ABIT NF7-S 2.0 avec controlleur S-ATA Silicon Image 3112A
Disque IDE IBM 40 Go
Disque S-ATA Hitachi 160 Go
Linux noyau 2.6.10
Le boot se fait sur le disque IBM
Maintenant le probleme :
Si je compile le driver SCSI pour le controleur SI 3112A sous forme de
module (sata_sil.o), tout fonctionne correctement. Le controleur est
detecté, le disque Hitachi egalement. Le disque est reconnu comme disque
SCSI, et je peux monter les partitions et y acceder sans probleme, en
tant que disque SCSI (/dev/sdaX).
Par contre, si je compile le support SI 3112A dans le noyau, et non en
module, le systeme se bloque lors du boot a la detection du disque
Hitachi par le controleur S-ATA. J'ai eu beau chercher sur des tas de
forums, meme lire le code du noyau, je n'ai aucune idée du pourquoi de
se bloquage.
Si quelqu'un a une idée ou une piste, je suis preneur...
Bonjour a tous,
Ma config :
CM ABIT NF7-S 2.0 avec controlleur S-ATA Silicon Image 3112A
Disque IDE IBM 40 Go
Disque S-ATA Hitachi 160 Go
Linux noyau 2.6.10
Le boot se fait sur le disque IBM
Maintenant le probleme :
Si je compile le driver SCSI pour le controleur SI 3112A sous forme de
module (sata_sil.o), tout fonctionne correctement. Le controleur est
detecté, le disque Hitachi egalement. Le disque est reconnu comme disque
SCSI, et je peux monter les partitions et y acceder sans probleme, en
tant que disque SCSI (/dev/sdaX).
Par contre, si je compile le support SI 3112A dans le noyau, et non en
module, le systeme se bloque lors du boot a la detection du disque
Hitachi par le controleur S-ATA. J'ai eu beau chercher sur des tas de
forums, meme lire le code du noyau, je n'ai aucune idée du pourquoi de
se bloquage.
Si quelqu'un a une idée ou une piste, je suis preneur...
L'initialisation se fait sans doute trop tôt.
Il faudrait que tu regardes les messages du noyau au boot voire que tu
rajoute des messages pour savoir exactement à quel endroit
l'initialisation s'arrête.
Au cas ou, affiche l'IRQ PCI du controleur au moment ou il se bloque. J'ai
eu un problème similaire avec l'Imac G5 du au fait que l'IRQ PCI était
mal détectée au boot, ce qui fait que le noyau attendait indéfiniment
que le disque lui réponde. Mais comme l'init des IRQ PCI est très
différente sur un PC, je ne suis pas sur que ça puisse avoir un rapport...
L'initialisation se fait sans doute trop tôt.
Il faudrait que tu regardes les messages du noyau au boot voire que tu
rajoute des messages pour savoir exactement à quel endroit
l'initialisation s'arrête.
Au cas ou, affiche l'IRQ PCI du controleur au moment ou il se bloque. J'ai
eu un problème similaire avec l'Imac G5 du au fait que l'IRQ PCI était
mal détectée au boot, ce qui fait que le noyau attendait indéfiniment
que le disque lui réponde. Mais comme l'init des IRQ PCI est très
différente sur un PC, je ne suis pas sur que ça puisse avoir un rapport...
L'initialisation se fait sans doute trop tôt.
Il faudrait que tu regardes les messages du noyau au boot voire que tu
rajoute des messages pour savoir exactement à quel endroit
l'initialisation s'arrête.
Au cas ou, affiche l'IRQ PCI du controleur au moment ou il se bloque. J'ai
eu un problème similaire avec l'Imac G5 du au fait que l'IRQ PCI était
mal détectée au boot, ce qui fait que le noyau attendait indéfiniment
que le disque lui réponde. Mais comme l'init des IRQ PCI est très
différente sur un PC, je ne suis pas sur que ça puisse avoir un rapport...
L'initialisation se fait sans doute trop tôt.
Il faudrait que tu regardes les messages du noyau au boot voire que tu
rajoute des messages pour savoir exactement à quel endroit
l'initialisation s'arrête.
Effectivement, je pense que cela vient d'un probleme de sequence d'init
du disque. J'ai ajoute pas mal de traces dans libata-core.c pour
comprendre le cheminement de l'init. En fait, tout se bloque dans la
fonction ata_dev_set_xfermode, qui semble fixer le mode de transfert,
comme son nom l'indique. Une fois le mode fixe, on appelle
wait_for_completion, qui semble attendre le feu vert pour continuer
l'init. C'est la que la bat blesse : en module, tout roule, en dur dans
le noyau, tout reste bloque sur cette "completion". Peut-etre que le
fait de charger ce module en dernier joue-t-il ?Au cas ou, affiche l'IRQ PCI du controleur au moment ou il se bloque. J'ai
eu un problème similaire avec l'Imac G5 du au fait que l'IRQ PCI était
mal détectée au boot, ce qui fait que le noyau attendait indéfiniment
que le disque lui réponde. Mais comme l'init des IRQ PCI est très
différente sur un PC, je ne suis pas sur que ça puisse avoir un rapport...
Apparement, pas de probleme d'affectation d'IRQ, qu'on soit en module ou
non (dixit les traces).
L'initialisation se fait sans doute trop tôt.
Il faudrait que tu regardes les messages du noyau au boot voire que tu
rajoute des messages pour savoir exactement à quel endroit
l'initialisation s'arrête.
Effectivement, je pense que cela vient d'un probleme de sequence d'init
du disque. J'ai ajoute pas mal de traces dans libata-core.c pour
comprendre le cheminement de l'init. En fait, tout se bloque dans la
fonction ata_dev_set_xfermode, qui semble fixer le mode de transfert,
comme son nom l'indique. Une fois le mode fixe, on appelle
wait_for_completion, qui semble attendre le feu vert pour continuer
l'init. C'est la que la bat blesse : en module, tout roule, en dur dans
le noyau, tout reste bloque sur cette "completion". Peut-etre que le
fait de charger ce module en dernier joue-t-il ?
Au cas ou, affiche l'IRQ PCI du controleur au moment ou il se bloque. J'ai
eu un problème similaire avec l'Imac G5 du au fait que l'IRQ PCI était
mal détectée au boot, ce qui fait que le noyau attendait indéfiniment
que le disque lui réponde. Mais comme l'init des IRQ PCI est très
différente sur un PC, je ne suis pas sur que ça puisse avoir un rapport...
Apparement, pas de probleme d'affectation d'IRQ, qu'on soit en module ou
non (dixit les traces).
L'initialisation se fait sans doute trop tôt.
Il faudrait que tu regardes les messages du noyau au boot voire que tu
rajoute des messages pour savoir exactement à quel endroit
l'initialisation s'arrête.
Effectivement, je pense que cela vient d'un probleme de sequence d'init
du disque. J'ai ajoute pas mal de traces dans libata-core.c pour
comprendre le cheminement de l'init. En fait, tout se bloque dans la
fonction ata_dev_set_xfermode, qui semble fixer le mode de transfert,
comme son nom l'indique. Une fois le mode fixe, on appelle
wait_for_completion, qui semble attendre le feu vert pour continuer
l'init. C'est la que la bat blesse : en module, tout roule, en dur dans
le noyau, tout reste bloque sur cette "completion". Peut-etre que le
fait de charger ce module en dernier joue-t-il ?Au cas ou, affiche l'IRQ PCI du controleur au moment ou il se bloque. J'ai
eu un problème similaire avec l'Imac G5 du au fait que l'IRQ PCI était
mal détectée au boot, ce qui fait que le noyau attendait indéfiniment
que le disque lui réponde. Mais comme l'init des IRQ PCI est très
différente sur un PC, je ne suis pas sur que ça puisse avoir un rapport...
Apparement, pas de probleme d'affectation d'IRQ, qu'on soit en module ou
non (dixit les traces).
Bah, si, là j'en suis sur, c'est un problème d'IRQ, mais les causes
peuvent être multiples.
Met des traces dans libata-core.c:ata_host_intr et ata_interrupt. C'est
la que doit se déclencher le déblocage de la complétion.
Attention tout de même: pas trop de traces, c'est un handler
d'interruptions hardware !
Si possible, regroupe les traces en dehors des
spin_lock_irqsave(); ... spin_unlock_irqrestore();
mais tu peux collecter de l'info entre et l'afficher à la fin...
Bah, si, là j'en suis sur, c'est un problème d'IRQ, mais les causes
peuvent être multiples.
Met des traces dans libata-core.c:ata_host_intr et ata_interrupt. C'est
la que doit se déclencher le déblocage de la complétion.
Attention tout de même: pas trop de traces, c'est un handler
d'interruptions hardware !
Si possible, regroupe les traces en dehors des
spin_lock_irqsave(); ... spin_unlock_irqrestore();
mais tu peux collecter de l'info entre et l'afficher à la fin...
Bah, si, là j'en suis sur, c'est un problème d'IRQ, mais les causes
peuvent être multiples.
Met des traces dans libata-core.c:ata_host_intr et ata_interrupt. C'est
la que doit se déclencher le déblocage de la complétion.
Attention tout de même: pas trop de traces, c'est un handler
d'interruptions hardware !
Si possible, regroupe les traces en dehors des
spin_lock_irqsave(); ... spin_unlock_irqrestore();
mais tu peux collecter de l'info entre et l'afficher à la fin...
Bah, si, là j'en suis sur, c'est un problème d'IRQ, mais les causes
peuvent être multiples.
Met des traces dans libata-core.c:ata_host_intr et ata_interrupt. C'est
la que doit se déclencher le déblocage de la complétion.
Attention tout de même: pas trop de traces, c'est un handler
d'interruptions hardware !
Si possible, regroupe les traces en dehors des
spin_lock_irqsave(); ... spin_unlock_irqrestore();
mais tu peux collecter de l'info entre et l'afficher à la fin...
Mauvaise pioche ! Les traces que j'ai ajoutées a l'entrée et a la sortie
de ces 2 fonctions ainsi que dans les boucles ne se sont meme pas
afichées ! Ou alors, c'est que l'interruption hard n'est jamais arrivée !
Cependant, j'avoue que je n'ai pas bien saisi le fonctionnement de la
fonction wait_for_completion : on repete un appel a schedule() jusqu'a
ce que ... quoi ?
Bah, si, là j'en suis sur, c'est un problème d'IRQ, mais les causes
peuvent être multiples.
Met des traces dans libata-core.c:ata_host_intr et ata_interrupt. C'est
la que doit se déclencher le déblocage de la complétion.
Attention tout de même: pas trop de traces, c'est un handler
d'interruptions hardware !
Si possible, regroupe les traces en dehors des
spin_lock_irqsave(); ... spin_unlock_irqrestore();
mais tu peux collecter de l'info entre et l'afficher à la fin...
Mauvaise pioche ! Les traces que j'ai ajoutées a l'entrée et a la sortie
de ces 2 fonctions ainsi que dans les boucles ne se sont meme pas
afichées ! Ou alors, c'est que l'interruption hard n'est jamais arrivée !
Cependant, j'avoue que je n'ai pas bien saisi le fonctionnement de la
fonction wait_for_completion : on repete un appel a schedule() jusqu'a
ce que ... quoi ?
Bah, si, là j'en suis sur, c'est un problème d'IRQ, mais les causes
peuvent être multiples.
Met des traces dans libata-core.c:ata_host_intr et ata_interrupt. C'est
la que doit se déclencher le déblocage de la complétion.
Attention tout de même: pas trop de traces, c'est un handler
d'interruptions hardware !
Si possible, regroupe les traces en dehors des
spin_lock_irqsave(); ... spin_unlock_irqrestore();
mais tu peux collecter de l'info entre et l'afficher à la fin...
Mauvaise pioche ! Les traces que j'ai ajoutées a l'entrée et a la sortie
de ces 2 fonctions ainsi que dans les boucles ne se sont meme pas
afichées ! Ou alors, c'est que l'interruption hard n'est jamais arrivée !
Cependant, j'avoue que je n'ai pas bien saisi le fonctionnement de la
fonction wait_for_completion : on repete un appel a schedule() jusqu'a
ce que ... quoi ?
wait_for_completion attends qu'un autre thread vienne le débloquer.
Dans ton cas, c'est le handler d'interruption qui doit débloquer le
thread en attente. Mais si tu n'as aucune trace, ça veut dire que
soit l'interruption hardware n'est pas déclenchée, soit elle n'est pas
celle que le driver attends.
Dans le premier cas, c'est peut-être que le système de gestion du PCI
n'a pas encore signalée au controleur quelle IRQ il doit utiliser.
Regarde si par hasard il n'y a pas des fonctions du style pci_fixup pour
ton chipset qui ne seraient pas encore appelées dans ton cas. Une autre
possibilité (mais j'y crois moins, je ne vois pas comment ça marcherait
en module) est que l'interruption est désactivée à ce moment là.
Pour savoir si tu es dans le second cas, ajoute des traces pour voir
quelle interruption hardware le driver attend et avec quelle configuration
(edge/level, ...). Compare ensuite ce que te donne les deux cas. Si ça
diffère, le problème vient de là.
wait_for_completion attends qu'un autre thread vienne le débloquer.
Dans ton cas, c'est le handler d'interruption qui doit débloquer le
thread en attente. Mais si tu n'as aucune trace, ça veut dire que
soit l'interruption hardware n'est pas déclenchée, soit elle n'est pas
celle que le driver attends.
Dans le premier cas, c'est peut-être que le système de gestion du PCI
n'a pas encore signalée au controleur quelle IRQ il doit utiliser.
Regarde si par hasard il n'y a pas des fonctions du style pci_fixup pour
ton chipset qui ne seraient pas encore appelées dans ton cas. Une autre
possibilité (mais j'y crois moins, je ne vois pas comment ça marcherait
en module) est que l'interruption est désactivée à ce moment là.
Pour savoir si tu es dans le second cas, ajoute des traces pour voir
quelle interruption hardware le driver attend et avec quelle configuration
(edge/level, ...). Compare ensuite ce que te donne les deux cas. Si ça
diffère, le problème vient de là.
wait_for_completion attends qu'un autre thread vienne le débloquer.
Dans ton cas, c'est le handler d'interruption qui doit débloquer le
thread en attente. Mais si tu n'as aucune trace, ça veut dire que
soit l'interruption hardware n'est pas déclenchée, soit elle n'est pas
celle que le driver attends.
Dans le premier cas, c'est peut-être que le système de gestion du PCI
n'a pas encore signalée au controleur quelle IRQ il doit utiliser.
Regarde si par hasard il n'y a pas des fonctions du style pci_fixup pour
ton chipset qui ne seraient pas encore appelées dans ton cas. Une autre
possibilité (mais j'y crois moins, je ne vois pas comment ça marcherait
en module) est que l'interruption est désactivée à ce moment là.
Pour savoir si tu es dans le second cas, ajoute des traces pour voir
quelle interruption hardware le driver attend et avec quelle configuration
(edge/level, ...). Compare ensuite ce que te donne les deux cas. Si ça
diffère, le problème vient de là.
