Marc SCHAEFER a écrit :
C'est peut-être lié à une gestion d'interruption incorrecte.
Ce qui corrige le problème, en général, est de désactiver le contrôleur
d'interruption avancé (APIC)
noapic
Faire
cat /proc/interrupts
pour déterminer si c'est vraiment l'APIC qui est le problème.
Merci pour tes suggestions. Je ne trouve pas l'APIC dans /proc/interrupts...
[EMAIL PROTECTED]:~$ cat /proc/interrupts
CPU0
0: 423523 XT-PIC timer
1: 581 XT-PIC i8042
2: 0 XT-PIC cascade
5: 9175 XT-PIC Ensoniq AudioPCI
7: 1 XT-PIC parport0
8: 1 XT-PIC rtc
9: 1 XT-PIC acpi
10: 0 XT-PIC uhci_hcd:usb1
11: 259 XT-PIC em8300, eth0
12: 8990 XT-PIC i8042
14: 18682 XT-PIC ide0
15: 6772 XT-PIC ide1
NMI: 0
LOC: 0
ERR: 0
MIS: 0
Tu peux mettre sur une liste noire pour l'auto-détection 8139cp en
l'ajoutant ainsi:
# echo 8139cp >> /etc/hotplug/blacklist
Je l'ai fait, mais il revient quand même au démarrage (scrogneugneu!).
Ce qui est étonnant, c'est qu'en sautant l'étape qui coince avec Ctrl-C,
il finit quand même par se bloquer plus tard, à une étape un peu
aléatoire. Comme si le blocage se faisait après x secondes de démarrage
et non en raison d'un module ou démon particulier.
Essayer avec un kernel 2.4 aussi, ou un 2.6.15.
Bon, je vais encore essayer ça. Sinon, je vire kubuntu et je retourne à
Sarge.
Merci!
Greg
_______________________________________________
gull mailing list
[email protected]
http://lists.alphanet.ch/mailman/listinfo/gull
