Apenas mi papá compro un nuevo disco duro, el cual me donó 😛 , este nuevo disco duro es 10 Gb. más grande, además de contar con más rpms, anteriormente era un ST330621A con 30 Gb. de 5400 rpms, el nuevo disco duro es un ST340014A con 40 Gb. de 7200 rpms. Al parecer, mi motherboard marca PCChips, modelo M755LMRE con un chipset PC133 GFXcel, no lo acepta muy bien. 😥
Síntomas 😛
Al principio todo iba de maravilla, no se notaba nada raro, pero por ejemplo, como aún uso Windows para juegos u otro programa que aún me falta por encontrar en GNU/Linux Debian, entonces, al estar en Windows y al activar “x” programa, el disco duro se quedaba en el limbo, obligándome a resetear la máquina 😥 , al usar Linux solamente una ocasión me mando el error de “Lost Interrupt”.
Información 🙂
Tomando como base, el mensaje que salio en Linux, el cual era “Lost Interrupt” y utilizándolo para buscar información, googlazo, encontré en algunos foros, en los cuales daban a muchas cosas que podrían ser o posibles causas, como por ejemplo, la alimentación de energía, el cable IDE, el modo DMA, el BIOS, etc., sin saber realmente, cual de los anteriores es la causa.
No encontré alguna página, donde se abordara el tema de “Lost Interrupt” al 100% 😥 , solo se citan las posibles causas, comentadas anteriormente, además, se menciona como el mensaje lo dice “Interrupción Perdida”, quiere decir, a Linux se le olvida que IRQ tiene mi disco en un cierto momento 😛 .
Encontré un parche que se hizo al Kernel, actualmente utilizo el 2.6.9, menciona algo al respecto, esto se puede observar en el archivo de cambios “ChangeLog-2.6.10-rc3“.
PATCH x86_64: Fix lost edge triggered irqs on UP kernel
Patch from Petr VandrovecRecently I’ve observed problems with IDE disks while running UP kernel on x86-64 – it complained a lot about lost irq from hda/hdc. I tracked problem down to the problem that at enable_irq() code calls hw_resend_irq(), but on x86-64 hw_resend_irq() does something useful only when CONFIG_SMP is defined, on UP systems it does nothing.
Due to this IRQ is lost – and when IDE retries command, it can again happen that IRQ is delivered before IDE code does enable_irq(), and again and again, unless due to drive being lazy finally once kernel does enable_irq() before drive prepares its answer, and things move forward … to next lost IRQ.
Esta corrección fue echa y colocada en el Kernel en forma de parche “patch-2.6.10-rc3“, actualmente hay un Kernel más nuevo, el 2.6.10 😀 , con un “ChangeLog-2.6.10” más extenso. 😛
Manos a la Obra 😉
Primero, yo no uso ningún modo DMA (Direct Memory Access), para eso, el disco duro como la motherboard deben soportarlo, además de contar con un cable IDE de 80 hilos.
Después, la actualización del BIOS en teoría no era tan necesaria, Windows por lo que he tenido experiencia 😛 usa rutinas del BIOS, así como también, guarda información en el CMOS, ahora, Linux con lo que me dijeron los gurús, no utiliza las instrucciones del BIOS, esto hace que funcione a la perfección, aunque se tenga un BIOS antiguo o nuevo, eso no importa, yo no lo sabia y la verdad me parece algo muy interesante.
El detalle esta, que aún sigo usando Windows. 😥
Al final de tanto buscar, descargue el BIOS más nuevo para mi motherboard, por lo cual actualice y coloque un nuevo cable IDE de 80 hilos.
Al probar con Windows, ya no tuve ningún problema, funciona muy bien. Para Linux, como tenia el Kernel 2.6.9, lo que hice fue, solo aplicar el parche “patch-2.6.10-rc3“, a los fuentes que ya tenia, y por supuesto recompilar e instalar, después de esto, utilizando Linux tampoco me ha dado problemas. 😀
Nota: Después de que hice todo esto, el Kernel 2.6.10 fue liberado, esta motherboard ya no cuenta con un buen soporte, los controladores no se actualizan tanto como otros, la fecha del driver más nuevo es del 2004, los demás drivers están alrededor de enero del 2003, sin cambios muy significativos, en cuanto actualización del BIOS, el más actual es del 2002, sin más actualizaciones.
