[l-ubuntu-ve] Problemas varios con servidor Siragon kavak serie 7000 (MOBO SUPERMICRO 7DB3)

Jue Mayo 22 21:53:58 BST 2008

El problema principal reside en el controlador de red Intel 82563EB
(10/100/1000), posee dos puertos de conexión RJ45, ambos utilizando el
mismo chipset, esta maquina ha tenido una historia de instalación de
sistemas operativos propietarios (Llamese Windows 2000 y 2003 server)
y ahora es que puede disfrutar de bits libres con Ubuntu Server LTS
8.04 (En previas instalaciones no fue detectado el RAID SATA con
Debian Etch). Ahora hablando de los errores nos trasladamos hasta su
previa instalación de Windows Server 2000. El sistema estuvo operativo
al rededor de 7 meses sin problemas, pero desde hace 2 meses ha sido
un completo infierno debido a que cada vez que la carga se
incrementaba el controlador colgaba o desconectaba el adaptador y no
permitia ningún tipo de conexiones ni entrantes ni salientes y los
procesos se relentizaban colgando al 100% el sistema, necesitando ser
reiniciado. Pero como windows es windows no mostraba ningún tipo de
reportes de errores (revisamos los logs estos no daban a cierto o que
estaba sucediendo).

Ahora bien, decidimos acabar con ese AD (Active Directory) e instalar
una solución de PDC bajo ubuntu y aquí es cuando nos damos cuenta de
estos errores fundamentales, el primer error fue con el controlador
del RAID el cual daba varios errores a nivel de paridad, decidimos
obviarlos y conectar los discos directamente a los puertos SATA porque
realmente necesitamos resolver y poner a la gente a trabajar.

Concretamente el error se refiere a el colgado de el controlador de
red, más específicamente el modulo e1000. Buscando un poco por google
pudimos encontrar numerosas cadenas de Email y de threads en foros de
personas con diferente controlador que el nuestro (8257X,
especificamente 82573) con problemas similares, muchos de ellos
postean soluciones que para nosotros no funcionaron y paulatinamente
hicieron que nuestro controlador agravara la situación casi colgándose
de inmediatamente de ser montado el modulo y presentar trafico.

Logs:

May 20 04:00:22 olodumare kernel: [320205.057475]   Tx Queue             <0>
May 20 04:00:22 olodumare kernel: [320205.057476]   TDH                  <d4>
May 20 04:00:22 olodumare kernel: [320205.057477]   TDT                  <e7>
May 20 04:00:22 olodumare kernel: [320205.057478]   next_to_use          <e7>
May 20 04:00:22 olodumare kernel: [320205.057479]   next_to_clean        <d3>
May 20 04:00:22 olodumare kernel: [320205.057480] buffer_info[next_to_clean]
May 20 04:00:22 olodumare kernel: [320205.057481]   time_stamp
  <1e8cff2>
May 20 04:00:22 olodumare kernel: [320205.057482]   next_to_watch        <d4>
May 20 04:00:22 olodumare kernel: [320205.057483]   jiffies
  <1e8d11c>
May 20 04:00:22 olodumare kernel: [320205.057484]   next_to_watch.status <0>
May 20 04:00:24 olodumare kernel: [320207.054222]   Tx Queue             <0>
May 20 04:00:24 olodumare kernel: [320207.054223]   TDH                  <d4>
May 20 04:00:24 olodumare kernel: [320207.054224]   TDT                  <e7>
May 20 04:00:24 olodumare kernel: [320207.054225]   next_to_use          <e7>
May 20 04:00:24 olodumare kernel: [320207.054225]   next_to_clean        <d3>
May 20 04:00:24 olodumare kernel: [320207.054226] buffer_info[next_to_clean]
May 20 04:00:24 olodumare kernel: [320207.054227]   time_stamp
  <1e8cff2>
May 20 04:00:24 olodumare kernel: [320207.054228]   next_to_watch        <d4>
May 20 04:00:24 olodumare kernel: [320207.054229]   jiffies
  <1e8d1e4>
May 20 04:00:24 olodumare kernel: [320207.054230]   next_to_watch.status <0>
May 20 04:00:26 olodumare kernel: [320209.051212]   Tx Queue             <0>
May 20 04:00:26 olodumare kernel: [320209.051213]   TDH                  <d4>
May 20 04:00:26 olodumare kernel: [320209.051214]   TDT                  <e7>
May 20 04:00:26 olodumare kernel: [320209.051215]   next_to_use          <e7>
May 20 04:00:26 olodumare kernel: [320209.051215]   next_to_clean        <d3>

Esto es un fragmento de los cientos de errores que podemos encontrar
en /var/log/messages.0, mostrando por consolas seriales lo siguiente:

e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang

Entre las páginas que visitamos, donde podemos encontrar parches,
modificaciones de eeprom y otros hacks y fixes que no funcionaron:

http://support.intel.com/support/network/sb/CS-009209.htm     ------>
Página oficial de intel donde describen las funciones del modulo y la
tarjeta así como los parámetros para controlarla, cabe destacar que
inclusive probamos las versiones del modulo e1000 que incluían el
supuesto FIX al problema así como la versión provista por supermicro e
intel sin todos estos sin mejorar la situación si no al contrario,
lograr que dicha unidad de red se colgase más rápido.

https://bugzilla.redhat.com/show_bug.cgi?id=200656#c11        ----->
En esta página encontramos muchisima información que nos permitio
comprender mejor el problema y chocar con la cruel realidad de que
intel se lavo las manos y no tiene explicación de porque en otras
tarjetas idénticas funciona perfectamente y en otras no, puesto que no
creemos que seamos los únicos con un controlador 82653EB presentando
problemas en el mundo.

Los fix de los eeprom no funcionaron en ninguna de sus versiones, los
que nos dejo impávidos ante la situación abrigándonos a instalar una
tarjeta de red D-Link PCI en un puerto PCI-X a 100mhz.

Por ahora resolvimos el problema pero queremos escuchar sus opiniones
al respecto de esta situación a ver si macomunadamente podemos
encontrar la solución a este tan intrigante acertijo.

Saludos.
--

Axzel G. Marín Graü
Dirección de Sistemas y Procedimientos
Contraloria General del Estado Sucre
Ofic: +58-293-4320708
Movil: 0414-7957491
LinuxCounter N°: 381477