Re: Zip
On Thu, 22 Feb 2001, blaise vogel wrote: IDE 2 en esclave avec un CDrom en maitre. Correctement reconnu par le bios et au boot de linux. En fait avec 1 périph. sur la nappe, ça marche! Et je n'ai pas de message d'erreur après le cp. Impossible de kill -9 la commande cp et si je veux redémarrer, impossible il n'arrive pas à démonter le swap. Si ton kill -9 n'est pas pris en compte, cela signifie que le process n'est pas dans une phase qui lui permet d'examiner la liste des signaux recus. Il existe quelques phases d'un process pendant lesquelles les signaux ne sont pas traites. Ce sont, normalement, des phases tres courtes avec une priorite tres elevee. Ces phases sont des phases 'kernel mode'. C'est a dire que le process est en train d'executer un "system call", donc du code 'kernel' au nom du process. A un certain moment, le code kernel doit effectuer une tache tres importante et ne desire pas etre interrompu et s'attribue une priorite elevee. Ces phases sont souvent des acces I/O de bas niveau du kernel. Ce genre de probleme arrive parfois avec des peripheriques lents, suite a des bugs du driver ou des problemes hard non traites par les drivers. Le process reste alors dans cet etat de haute priorite, dans l'attente d'un reponse du peripherique et incapable de traiter quelque signal que se soit. Souvent, le seul moyen de debloquer la situation consiste a eteindre le peripherique en cause, engendrant ainsi un 'event' qui poura etre pris en compte par le driver. Dans d'autre cas, le driver a un timeout de 15 minutes ... :-) Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question.
Re: Zip
On Mon, 26 Feb 2001, Daniel Cordey wrote: elevee. Ces phases sont des phases 'kernel mode'. C'est a dire que le process est en train d'executer un "system call", donc du code 'kernel' au nom du Un processus peut tre dans un system call mais interruptible (peut traiter un signal, le system call s'interrompt alors). Il peut aussi tre dans un system call, mais non interruptible. Ces deux tats de processus se nomment respectivement: interruptible sleep S ininterruptible sleep D alors dans cet etat de haute priorite, dans l'attente d'un reponse du Ce n'est pas vraiment un tat de haute priorit, peripherique et incapable de traiter quelque signal que se soit. Souvent, le par contre c'est un tat d'attente sans interruption possible par un signal. L'avantage de l'tat D c'est que l'on a pas besoin d'crire du code de reprise en cas d'interruption, c'est pour cela que c'est le plus populaire. Par contre bien sr, pour tout priphrique qui peut tre lent et o l'interruption par un signal a un sens, l'autre est mieux. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question.
Re: Zip
On Mon, 26 Feb 2001, Marc SCHAEFER wrote: Un processus peut être dans un system call mais interruptible (peut traiter un signal, le system call s'interrompt alors). Il peut aussi être dans un system call, mais non interruptible. Evidement, tous les system call n'ont pas besoin d'etre non-interruptible; comme par exemple gettimeofday(). Seul les "parties" de code du kernel modifiant des structures communes a d'autres parties, ou des "portions" de drivers "bas niveau" sont sujettes a ces "protection" particulieres. Il est incorrecte de developper du code "kernel", ou "drivers", uniquement en mode non-interruptible, mais il y a des situation ou on ne peut pas eviter de le faire. Ce n'est pas vraiment un état de haute priorité, Il y a des situations ou l'on ne veut pas etre interrompu meme par certains "interupt hardware". Par exemple, ecrire : if(Flag) Flag = RELEASE_FLAG; n'est pas une operation atomique et risque d'etre interrompue entre le teste et l'assignation. Je ne me suis pas plonger dans le code source des drivers SCSI, mais... je vais suivre tes recommandations :-) L'avantage de l'état D c'est que l'on a pas besoin d'écrire du code de reprise en cas d'interruption, c'est pour cela que c'est le plus populaire. Par contre bien sûr, pour tout périphérique qui peut être lent et où l'interruption par un signal a un sens, l'autre est mieux. Exacte... mais helas, des cas imprevus arrivent toujours a se glisser dans les premieres versions des drivers :-) Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question.
Re: Zip
On Mon, 26 Feb 2001, Daniel Cordey wrote: Il y a des situations ou l'on ne veut pas etre interrompu meme par certains "interupt hardware". Par exemple, ecrire : if(Flag) Flag = RELEASE_FLAG; Ce genre de situations ncessitent plus qu'un processus en tat D: il faut bloquer les interruptions du matriel (si le matriel change ce bit), ou avoir une mthode de verrouillage. En fait, tant que tu ne fais pas de sleep direct ou indirect (accder de la mmoire user-space peut provoquer un dswappage, donc sleep implicite), le kernel te garantit qu'aucun autre processus ne peut accder tes donnes. Ds que tu dors (en D ou S), cette garantie disparat (en bref, le kernel implmente en interne un multitche coopratif). Par contre les interruptions sont toujours actives. PS: les versions rcentes du kernel ont introduit des modifications ce qui prcde, en particulier en SMP, ce qu'il fait qu'il faut en gnral faire plus attention. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question.
Re: Zip
On Thu, 22 Feb 2001, blaise vogel wrote: Et je n'ai pas de message d'erreur aprs le cp. Impossible de kill -9 la erreurs dans dmesg ? -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question.
Re: Zip
erreurs dans dmesg ? En fait, après quelques heures la commande aboutit! (Pour env. 10Mb) J'ai envoyé tail -f /var/log/messages, puis le cp, env. 5-10 secondes normales puis un message (j'ai pas la machine avec moi :-(( ) du genre reinit /dev/hdd4, 50 secondes sans rien avec le zip mort, puis même message et le zip qui tourne 1 seconde. Une idée? -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question.
Re: Zip
Ton Zip il est sur un bus SCSI ? IDE ? Port série ? Trou de souris ? IDE 2 en esclave avec un CDrom en maitre. Correctement reconnu par le bios et au boot de linux. En fait avec 1 périph. sur la nappe, ça marche! Et je n'ai pas de message d'erreur après le cp. Impossible de kill -9 la commande cp et si je veux redémarrer, impossible il n'arrive pas à démonter le swap. Après essai et recherche, je pense qu'il y a un problème avec le chipset Apollo KT-133 ou un bug avec ma Suse 6.3. C'est la 2eme fois que j'ai un problème avec linux sur l'IDE2 avec 2 périph., j'avais résolu en débranchant 1 périph. :-((, pas très propre comme solution Blaise -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question.
