Asignación de IRQ
Hola... estoy teniendo unos problemas de conflicto con los IRQ's (creo) entre la controladora de puertos USB y ACPI. Haciendo "lsdev -v" (solo pego las salidas que creo que puede interesar): Device DMA IRQ I/O Ports acpi 9 ACPI 8010-8015 ehci_hcd 10 ohci1394 11 y haciendo "cat interrupts" (en /proc) CPU0 9: 228 XT-PIC acpi 10: 66199 XT-PIC ehci_hcd, yenta, eth0 11: 65986 XT-PIC ohci1394, yenta, NVidia nForce3, nvidia En "/var/log/messages" he observado la siguiente línea que hace referencia a ACPI: linux kernel: ACPI: PCI interrupt 0000:00:06.0[A] -> GSI 11 (level, low) -> IRQ 11 Tiene alguna importancia el hecho de que al hacer "lsdev -v" a "ACPI" no se le asigne un IRQ y que sin embargo a "acpi" si?, hay alguna diferencia en ello? En "/var/log/boot.msn" tb he observado que a "ACPI" se le asigna los irq's 10 y 11, que son las irq's que se le asigna a "*hci_hcd". Por todo ésto es por lo que creo que se trata de un conflicto y porque cuando levanto el sistema con la opción: "acpi=off", desaparece todo éste inconveniente y el sistema funciona perfectamente (en lo referente a los puertos USB). El gran inconveniente es que en éste caso no tengo soporte para "acpi", y en un portatil, pues... como que me deja un poco en "bragas", ya que no me indica el nivel de carga de la batería (por lo demás no me importa). Tambien he probado a levantar el sistema con las opciones: "acpi_irq_pci=irq-number... acpi_irq_pci=irq-9... ACPI_IRQ_PCI=IRQ-9 (por su fuese problema de mayúsculas), acpi_irq_isa=irq-9, con la opción acpi=oldboot", pero con ninguna he conseguido evitar el conflicto entre el soporte ACPI y la controladora USB. Hay alguna forma de que el sistema (o hacerlo manualmente) le asignarle una irq a ACPI" (que no sea mediante "BIOS" la mia no dispone de esa opción). Espero no haberme liado muxo con las explicaciones y de no haberlo hecho con vosotros. -- Salu2 AMD64 || SuSE 9.2 || KDE 3.3.0 || X.org 6.8.1
El 2005-02-22 a las 17:40 +0100, Anul Jade escribió:
estoy teniendo unos problemas de conflicto con los IRQ's (creo) entre la controladora de puertos USB y ACPI.
ACPI entre otras cosas reparte las interrupciones: no sólo es control de energía. Había una información al respecto muy interesante en la pagina web de SuSE, creo que estaba colgando de las novedades de la 9.1
Haciendo "lsdev -v" (solo pego las salidas que creo que puede interesar):
Device DMA IRQ I/O Ports
acpi 9 ACPI 8010-8015
Yo también tengo esos dos: Device DMA IRQ I/O Ports acpi 9 ACPI 4008-400b 4010-4015 Por cierto... veo que tienes mal alineada tu tabla. Dile al kmail que use una fuente de ancho fijo para el correo, o cambia a ese modo cuando edites tablas.
ehci_hcd 10 ohci1394 11
uhci_hcd 19 23 d000-d01f d800-d81f
y haciendo "cat interrupts" (en /proc) CPU0 9: 228 XT-PIC acpi 10: 66199 XT-PIC ehci_hcd, yenta, eth0 11: 65986 XT-PIC ohci1394, yenta, NVidia nForce3, nvidia
Yo tengo: 0: 4976510 IO-APIC-edge timer 1: 6953 IO-APIC-edge i8042 2: 0 XT-PIC cascade 7: 0 IO-APIC-edge parport0 8: 3 IO-APIC-edge rtc 9: 0 IO-APIC-level acpi 12: 100339 IO-APIC-edge i8042 14: 44728 IO-APIC-edge ide0 15: 139 IO-APIC-edge ide1 17: 7354 IO-APIC-level eth0, Intel 82801BA-ICH2 18: 4 IO-APIC-level bttv0 19: 0 IO-APIC-level uhci_hcd 23: 45 IO-APIC-level uhci_hcd NMI: 0 LOC: 4976798 ERR: 0 MIS: 0 Fíjate que en tu caso las interrupciones son manejadas "a lo clásico", tipo XT-PIC en vez de mediante IO-APIC. Eso puede ser el problema. Mira en el log del kernel (o en boot.msg) a ver si se ha desactivado io-apic. Pero no veo colisión de interrupciones, acpi tiene la suya.
En "/var/log/messages" he observado la siguiente línea que hace referencia a ACPI:
linux kernel: ACPI: PCI interrupt 0000:00:06.0[A] -> GSI 11 (level, low) -> IRQ 11
En vez de "/var/log/messages", usa "/var/log/kernel". Tendrás que activarlo en syslog. -- Saludos Carlos Robinson
El 2005-02-22 a las 17:40 +0100, Anul Jade escribió:
estoy teniendo unos problemas de conflicto con los IRQ's (creo) entre la controladora de puertos USB y ACPI
* Prueba a arrancar pasandole la opcion noapic o apic=off APIC = Advanced Programmable Interrupt Controller, sustituto de la antigua PIC, que no es lo mismo que ACPI, acpi y otro pueden tener conflictos pero no son quienes controlan la asignacion de interrupciones.
Hola... El Jueves, 24 de Febrero de 2005 21:31, Carlos E. R. escribió:
El 2005-02-22 a las 17:40 +0100, Anul Jade escribió:
estoy teniendo unos problemas de conflicto con los IRQ's (creo) entre la controladora de puertos USB y ACPI.
ACPI entre otras cosas reparte las interrupciones: no sólo es control de energía. Había una información al respecto muy interesante en la pagina web de SuSE, creo que estaba colgando de las novedades de la 9.1
me he dado una vuelta por la página de SUSE y no he visto nada, si no te importa concretar?... De todas formas y teniendo encuenta lo que dices que hace "acpi" (repartir interrupicones) y como veo que mi problema es un conflicto de asignación de irq, ya que acpi se asigna una irq (la 10 o la 11, depende) que son justo las que usa *hci_hcd, hay alguna forma de indicarle que tiene que asignarse la "9"?.
Haciendo "lsdev -v" (solo pego las salidas que creo que puede interesar):
Device DMA IRQ I/O Ports
acpi 9 ACPI 8010-8015
Yo también tengo esos dos:
Device DMA IRQ I/O Ports acpi 9 ACPI 4008-400b 4010-4015
Por cierto... veo que tienes mal alineada tu tabla. Dile al kmail que use una fuente de ancho fijo para el correo, o cambia a ese modo cuando edites tablas.
tomo nota de la observación (estoy todabía en obras con el SO).
ehci_hcd 10 ohci1394 11
uhci_hcd 19 23 d000-d01f d800-d81f
no... no tengo una salida que haga mención a "uhci_hcd".
y haciendo "cat interrupts" (en /proc) CPU0 9: 228 XT-PIC acpi 10: 66199 XT-PIC ehci_hcd, yenta, eth0 11: 65986 XT-PIC ohci1394, yenta, NVidia nForce3, nvidia
Yo tengo:
0: 4976510 IO-APIC-edge timer 1: 6953 IO-APIC-edge i8042 2: 0 XT-PIC cascade 7: 0 IO-APIC-edge parport0 8: 3 IO-APIC-edge rtc 9: 0 IO-APIC-level acpi 12: 100339 IO-APIC-edge i8042 14: 44728 IO-APIC-edge ide0 15: 139 IO-APIC-edge ide1 17: 7354 IO-APIC-level eth0, Intel 82801BA-ICH2 18: 4 IO-APIC-level bttv0 19: 0 IO-APIC-level uhci_hcd 23: 45 IO-APIC-level uhci_hcd NMI: 0 LOC: 4976798 ERR: 0 MIS: 0
Fíjate que en tu caso las interrupciones son manejadas "a lo clásico", tipo XT-PIC en vez de mediante IO-APIC. Eso puede ser el problema. Mira en el log del kernel (o en boot.msg) a ver si se ha desactivado io-apic.
Pero no veo colisión de interrupciones, acpi tiene la suya.
pues... no, no tengo una salida que indique si se ha desactivado "io-apic". Puede ser que tengas razón en lo que dices, que el problema se encuentre en "tipo" de manejador. En ese caso... que se puede hacer?. Todo ésto es nuevo para mi; agradecería cualquier ayuda.
Saludos Carlos Robinson
Grácias Carlos por responder. P.D. De tomas formas, si no se pudiese solucionar el tema de asignar una irq, cosa que no me puedo creer (en otro SO, puede, pero en linux...), yo lo único que necesito es saber el nivel de carga de la vatería, a si es que, si hay algúna forma (programa) de hacerlo teniendo ACPI desactivado pues... agradecería que me lo comentarais. -- Salu2 SuSE 9.1 || KDE 3.3.2 || X.Org 6.8.1
El 2005-02-27 a las 18:57 +0100, Anul Jade escribió:
ACPI entre otras cosas reparte las interrupciones: no sólo es control de energía. Había una información al respecto muy interesante en la pagina web de SuSE, creo que estaba colgando de las novedades de la 9.1
me he dado una vuelta por la página de SUSE y no he visto nada, si no te importa concretar?...
Busca por "acpi" en la SDB, hay 10 articulos. Yo hablaba de este: http://portal.suse.com/sdb/en/2004/11/acpi_basics.html ( General Information concerning ACPI Support) Estos otros también: http://portal.suse.com/sdb/en/2002/10/81_acpi.html (Kernel Parameters for ACPI/APIC) y estos otros genéricos (son enlaces vistos en las anteriores) http://acpi.sourceforge.net/ http://www.tldp.org/HOWTO/ACPI-HOWTO/
De todas formas y teniendo encuenta lo que dices que hace "acpi" (repartir interrupicones)
Entre otras cosas. Además, el nombre se confunde con APIC: The previous power management standards were APM and PNPBIOS. The new standard is called ACPI (Advanced Configuration and Power Interface specification), and is praised as the successor of APM and PNPBIOS. Additional features of ACPI include the description of the hardware (CPU, bus, ...) as well as some additional minor jobs beyond the power management. Furthermore, the APIC (Advanced Programmable Interrupt Controller) is another technology for the interrupt management. Unfortunately, the similarity of the abbreviations is rather confusing.
y como veo que mi problema es un conflicto de asignación de irq, ya que acpi se asigna una irq (la 10 o la 11, depende) que son justo las que usa *hci_hcd, hay alguna forma de indicarle que tiene que asignarse la "9"?.
Lo dudo, eso lo hace la bios. Sólo configurando la bios podrías. De todos modos, que dos dispositivos usen la misma interrupción no significa necesariamente un conflicto, se pueden compartir... si el driver y el hardware están preparados para ello.
Fíjate que en tu caso las interrupciones son manejadas "a lo clásico", tipo XT-PIC en vez de mediante IO-APIC. Eso puede ser el problema. Mira en el log del kernel (o en boot.msg) a ver si se ha desactivado io-apic.
Pero no veo colisión de interrupciones, acpi tiene la suya.
pues... no, no tengo una salida que indique si se ha desactivado "io-apic".
Puede ser que tengas razón en lo que dices, que el problema se encuentre en "tipo" de manejador. En ese caso... que se puede hacer?.
No lo se, tendría que ver el log de arranque, la parte inicial, pero ni aún así tengo seguridades. Todo eso cambia mucho, y enseguida te quedas desfasado.
De tomas formas, si no se pudiese solucionar el tema de asignar una irq, cosa que no me puedo creer (en otro SO, puede, pero en linux...), yo lo único que necesito es saber el nivel de carga de la vatería, a si es que, si hay algúna forma (programa) de hacerlo teniendo ACPI desactivado pues... agradecería que me lo comentarais.
Leete los enlaces que te he mandado a ver si sacas algo. -- Saludos Carlos Robinson
participants (3)
-
Anul Jade
-
Carlos E. R.
-
jose maria