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

Iosu Landa Marcano eldiabloguardian en gmail.com
Vie Mayo 23 02:30:47 BST 2008


EPALE UN GRAN SALUDO AXZEL  Y SI ES DESEPARANTE SABER QUE INTEL SE LAVA 
LAS MANOS Y A LA COMUNIDAD LIBRE NOS DEJA ENTENDIENDOSE, ASI ES EL 
CAPITALISMO...

Axzel Marin escribió:
> 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
>
> _______________________________________________
> Lista de correo (ubuntu-ve)
> Fraternidad Ubuntu Linux de Venezuela
> (Official VenezuelanTeam)
> _______________________________________________
> ubuntu-ve mailing list
> ubuntu-ve en lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-ve
> www.ubuntu-ve.org | www.ubuntu.org.ve
> _______________________________________________
> Modifica tus opciones de suscripci&#243;n o  desuscribete en: https://lists.ubuntu.com/mailman/listinfo/ubuntu-ve
>
>   

-- 



Más información sobre la lista de distribución ubuntu-ve