Re: Solicitud de ingreso en comunidad
On Tue, May 31, 2005 at 04:00:35PM +0200, Juan Carlos Paz Espiñeira wrote:
Nada me indica q haya conflictos en irq's, ya tengo instalado un suse y un
winxp y ambos tiran bien, mas o menos.
Supongo q los binarios del hurd q me baje no son los mas adecuados, tengo
hiperthreading, mogollon de memoria (2GB), un par de discos duros ide
bastante grandes con un monton de particiones, una tarjeta de red intel,
etc...todo ello aderezado con un monton de errores aleatorios de crc en la
lectura/escritura de cualquier medio de almacenamiento, incluyendo
internet...producto tal vez de algun banco de memoria medio jodido...lo que
muchas veces me provoca q no sepa a q atenerme.
Prodrías probar de reducir los recursos del Ghurd, tal vez reducir la
partición del disco a menos de 1 Gb.
Saludos!
Asi q bueno, intento compilar mi propio mach y mi propio hurd pa ese mach,
para lo cual necesito mis binutils, mi i686-gnu-gcc, etc, con todas las
complicaciones habituales de interpendencias de cabeceras, con glibc, y tal
y cual...vamos, un bonito infierno con la documentación obsoleta q me he
encontrado en la red.
Si esto lo teneis mas trillao, seguro q me paso por el irc.
Muchas gracias
Juan Carlos Paz
On 5/31/05, Guillem Jover [EMAIL PROTECTED] wrote:
Hola,
On Mon, May 30, 2005 at 03:22:15PM +0200, Juan Carlos Paz Espiñeira wrote:
Ya lo he intentado, no me va, se me queda flipao y al poco se me rebota,
asi
q he tomado el camino largo,
estoy bastante atascao, generando el cross-compiler, pero todavia quiero
probar algunas cosas antes de pedir ayuda.
Eso seguramente es un problema de irq compartidas. Cross-compilando no
arreglaras nada. Hay varias soluciones:
1) desactivar en la BIOS las irq compartidas, o quitar (fisicamente)
el hardware que entra en conflicto (esto puede ser dificil en un
portatil ;).
2) Compilar gnumach solo con los drivers que te interesen. Para hacer
esto no necesitas cross-compiler, en linux-x86:
apt-get source gnumach
apt-get build-dep gnumach
cd gnumach-*
sensible-editor debian/rules.options
debuild
Si tienes mas preguntas relacionadas con el Hurd, tenemos una lista
dedicada debian-hurd@lists.debian.org, un canal de irc en español
#hurd-es en freenode, #hug en ingles o #debian-hurd (aunque hay
mas ;).
Por cierto:
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?
;)
saludos,
guillem
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
[EMAIL PROTECTED]
--
# nmag only,,,C79A 1F61 C728 B523 25D9 7ACB D7D0 92E8 978B 82FF
# gnupg 0x978B82FF [pgp.mit.edu] GNU/Linux Registered User 312624
sub boo{$q=pack q;N;,join q++,reverse split q--,shift;$q=~s;\s+$;\n;
;$q} do {printf /%s/,boo($_)} for(9112662581, 676371445, 2158412302)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
prueba
Re: Viejo y grave conflicto entre liblcms liblcms1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Antonio Castro wrote: | Yo creo que es un problema muy grave que se arrastra como digo desde hace | mucho tiempo ya que impide que hay muchas cosas que dependen de esos | dos conjuntos de paquetes incompatibles. Por ejemplo si tienes xine, | totem, kword , kspread, kchar kview, etc. No puedes usar imagemagick | html2ps y muchos otros programas que los usan como comandos externos. | El es que solamente el convert de imagemagick ya es una maravilla. Yo tengo imagemagick, html2ps, totem y xine conviviendo perfectamente en mi sarge, así que no creo que lo que diga sea cierto, y los tengo bastante tiempo y claro actualizándolos cada vez que pueda y nunca tuve problemas. El problema debe ser debido a otra causa, tal vez (digo tal vez) la instalación de algún paquete que no pertenezca a sarge o que provenga de alguna otra distribución, asegúrese de revisar /etc/apt/sources.list y que estos solo tengan mirrors de sarge, sin mezclar diferentes versiones de la distribución. También sería bueno tener en cuenta que si sus sources.list son adecuadas y el update se hace sin problemas de recordar si hizo la migración de woody a sarge de manera correcta usando apt-get dist-upgrade, no está de más ejecutar apt-get -f install y revisar todos y cada unos de los paquetes conflictivos que se listen, en algunos equipos logre solucionar ciertos problemas actualizando de manera puntual paquetes listados como conflictivos y eliminando otros para después volverlos a instalar, pero eso en equipos donde tenia paquetes provenientes de diferentes versiones de debian. Saludos! - -- nmag only gnupg 0xA024A03F [pgp.mit.edu] GNU/Linux Registered User #312624 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAyzZiy3Ce2qAkoD8RAkA3AJ4mk1yxRAudyaR9Jo44P3vJgB2SHQCgi2x2 vbIl+5jz2exARJKzkkr7ekM= =+9Mk -END PGP SIGNATURE-
Re: ip_conntrack, límite de contadores, y kernel 2.4.24
El dom, 21-03-2004 a las 17:40, José Luis Tallón escribió: At 10:38 21/03/2004, you wrote: Content-Type: text/plain; charset= Hola, Necesito saber si alguien ha tenido un problema con el kernel (especÃficamente las series 2.4) y si han tenido alguna solución, les narro el asunto... No me ha pasado. Tengo un servidor que hace de Router con Debian woody stable, gcc 2.95.4, kernel 2.4.24, procesador Intel Petium IV (dual), 512 RAM, NIC D-Link. El kernel 2.4.24 usuado es el obtenido en kernel.org, lo que ya he notado es que cada cierto tiempo (aproximadamente entre 8 a 10 dÃas), el equipo genera un mensaje: No entiendo... 2 procesadores Pentium4 (espero que sean Xeon), con sólo 512MB de memoria, y una NIC de $10 ??? Evidentemente poca memoria, tenía hace poco 1 Gb pero el problema ya existía; venga, no hay problema, se pondrá a sugerencia el Giga ya que el sistema llega a usar el swap con el paso de los días... (Por si acaso esta en SMP y con high memory support 4 Gb, este quedo así porque, repito antes tenía 1 Gb, podría ser ese el problema porque ahora está con solo 512? de todas formas ocurria con el Giga...) Yo usaría una ( ó dos ) Intel e100, al menos. En realidad tiene 4 Dlinks, muy baratas por cierto, ya se ha sugerido la adquisición de unas tarjetas de red de mejor calidad, el problema también se presenta con 3com (3c59x), recomienda alguna además de la Intel e100? Para qué tanta potencia de cálculo?? qué servicios presta esa máquina ? Lo más pesado es el Proxy con aceleración web... y claro el equipo ya estaba, y se tenía que usar como tal, yo he tenido equipos PII de 500 Mhz con iguales resultados, ni más ni menos, pero el tráfico en estos nunca fué tan grande, así que este problema no lo he tenido hasta ahora... En estos momentos estoy poniendo a prueba 3 equipos (que cumplen la misma función y que siempre han estado en producción en diferentes lugares) a los cuales se les ha incrementado el tráfico, veremos como va... Mar 17 10:13:23 blackmarsh kernel: LIST_DELETE: ip_conntrack_core.c:302 `ct-tuplehash[IP_CT_DIR_REPLY]'(ddf5c414) not in ip_conntrack_hash[hr]. Después de ello queda completamente congelado y no hace nada, la única solución es darle reset. Ahora esta situación ha ocurrido en tres oportunidades y siempre ha sido justo cuando los contadores de transmisión de paquetes TX o los contadores de recepción de paquetes RX de la NIC estaban alcanzando el lÃmite (un número bastante grande). Como dato adicional el tráfico manejado por este equipo es bastante grande. Por ahora tengo una solución por ortodoxa, y dado que el equipo es rápido se reinicia una vez por semana, y con eso ese problema parece haber desaparecido, pero no me parece lo más adecuado. Es poco ortodoxo, desde luego, pero de momento... habrá que encontrar una solución al problema, por si acaso. Si tiene alguna otra sugerencia será bien venida. Gracias por su ayuda Saludos Un saludo, José Luis Tallón -- nmag only gnupg 0xA024A03F [pgp.mit.edu] GNU/Linux Registered User #312624
ip_conntrack, límite de contadores, y kernel 2.4.24
Hola, Necesito saber si alguien ha tenido un problema con el kernel (específicamente las series 2.4) y si han tenido alguna solución, les narro el asunto... Tengo un servidor que hace de Router con Debian woody stable, gcc 2.95.4, kernel 2.4.24, procesador Intel Petium IV (dual), 512 RAM, NIC D-Link. El kernel 2.4.24 usuado es el obtenido en kernel.org, lo que ya he notado es que cada cierto tiempo (aproximadamente entre 8 a 10 días), el equipo genera un mensaje: Mar 17 10:13:23 blackmarsh kernel: LIST_DELETE: ip_conntrack_core.c:302 `ct-tuplehash[IP_CT_DIR_REPLY]'(ddf5c414) not in ip_conntrack_hash[hr]. Después de ello queda completamente congelado y no hace nada, la única solución es darle reset. Ahora esta situación ha ocurrido en tres oportunidades y siempre ha sido justo cuando los contadores de transmisión de paquetes TX o los contadores de recepción de paquetes RX de la NIC estaban alcanzando el límite (un número bastante grande). Como dato adicional el tráfico manejado por este equipo es bastante grande. Por ahora tengo una solución por ortodoxa, y dado que el equipo es rápido se reinicia una vez por semana, y con eso ese problema parece haber desaparecido, pero no me parece lo más adecuado. He estado investigando en internet sobre este problema específicamente sobre ip_conntrack_core:302 (302, otros números ya han sido solucionados) y hay poca información (y hacen alusión a un bug en el kernel) y la poca información que hay es sobre consultas como esta de si la nueva versión lo soluciona o si es necesario hacer un downgrade a la 2.4.22, había otra referida al kernel 2.4.23 y que persiste en la 2.4.24 por tanto no ha habido solución... Ahora me queda la duda tengo adicionalmente otro servidor en debian totalmente woody es decir con el kernel 2.4.18-bf24 y que hace un trabajo similar y en este caso el trafico no es elevado, pero este servidor hace como 3 meses genero un problema similar después de haber estado trabajando por un lapso de 8 meses sin parar ahora nunca le di importancia ya que el tiempo de trabajo fue extenso, pero por la cantidad de meses me he puesto a pensar que los contadores también habrían alcanzado el límite y el resultado habría sido el mismo... El problema está en todas las series del kernel 2.4? por si acaso esto ya lo he consultado en las listas vger.kernel.org y en kerneltrap pero aun no hay respuesta... Saludos y Gracias... -- nmag only gnupg 0xA024A03F [pgp.mit.edu] GNU/Linux Registered User #312624 signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: zx630-11
Gracias amigo, tu mensaje me sirvio de forma implicita, ahora ya tengo
funcionando el modem USB zyxel 630
Lo tengo con kernel 2.4.22 (modificado, usa la arquitectura USB del 2.4.18)
Modificacioón del speedtouch para adaptarse a la arquitectura del usb del 2.4.18
y bueno el codigo del zx630-11 con los cambios indicados en su documentacion
Despues de tres dias modificando codigo del kernel y recompilando,
todo va bien, y esos de la timofóonica que me dijeron que necesitaba
adquirir un router...
Saludos!
On Fri, 17 Oct 2003 00:19:54 +0200
Manwe Sulimo [EMAIL PROTECTED] wrote:
puede ser una tonteria, pero al leer mas detenidamente tu mensaje me ha
recordado a un problema que tuve haciendo funcionar el 3com con los drivers
de Comas...
los drivers estaban compilados para 2.4.18 y yo tenia el kernel 2.4.20
en cuanto cambie de kernel se soluciono todo y el modem empezo a funcionar
sin problemas
ojala sea eso...
On Thu, 16 Oct 2003 17:06:02 +
nmag [EMAIL PROTECTED] wrote:
Hola Listeros,
Alguien ha tenido la oportunidad de hacer funcionar esa porquería de
modem USB Prestigy 630 de timofónica para ADSL en debian.
Mi GNU/Linux detecta:
~# cat /proc/bus/usb/devices
P: Vendor=06b9 ProdID=a5a5 Rev= 0.00
S: Manufacturer=AME
S: Prodcut=DynaMiTe USB Modem
He descargado el zx630-11.X.tgz de sourceforge y se procedió a realizar
la compilación todo sin errores, ahora cuando se intenta levantar el
firmware con zxload detecta el dichoso modem pero no puede levantar la línea
ADSL:
~# ./zxload
Zyxel 630-11 microcode upload program. 14/7/2003
Josep Comas [EMAIL PROTECTED]
Sundar [EMAIL PROTECTED]
I found ADSL modem with VendorID = 06b9 ProductID = a5a5
Loading and sending /usr/sbin/fw-usb.bin...
Firmware is sent!
Error: usb_control_msg: error sending control message: Expiró el tiempo de
conexión
Error: usb_control_msg: error sending control message: Expiró el tiempo de
conexión
Error: usb_control_msg: error sending control message: Expiró el tiempo de
conexión
Error: usb_control_msg: error sending control message: Expiró el tiempo de
conexión
Error: usb_control_msg failed after 4 retries
Ahora cuanto hago debug y debugt retorna lo siguiente:
~# ./zxloaddbg
Zyxel 630-11 microcode upload program. 14/7/2003
Josep Comas [EMAIL PROTECTED]
Sundar [EMAIL PROTECTED]
I found ADSL modem with VendorID = 06b9 ProductID = a5a5
bLength: 0x09
bDescriptorType: 0x02
wTotalLength: 0x0093
bNumInterfaces: 0x03
bConfigurationValue: 0x01
iConfiguration: 0x00
bmAttributes: 0x80
MaxPower: 0xfa
Interface = 2
Loading and sending /usr/sbin/fw-usb.bin...
Length of file /usr/sbin/fw-usb.bin = 303584 bytes
PreInit...
Error: usb_bulk_write: error writing to bulk endpoint 5: Expiró el tiempo
de conexión
Error: usb_bulk_write: error writing to bulk endpoint 5: Expiró el tiempo
de conexión
Error: usb_bulk_write: error writing to bulk endpoint 5: Expiró el tiempo
de conexión
Error: usb_bulk_write: error writing to bulk endpoint 5: Expiró el tiempo
de conexión
Error: usb_bulk_write failed after 4 retries
Releasing interface...
Releasing device...
zxloaddbgt retorna lo mismo.
Hay unos cambios que se recomiendan hacer en zxload.c y en zxioctl.c, pero
estos quedan
sin efecto todavía ya que el problema se presenta antes de estas líneas.
Ahora el problema que se me presenta corresponde específicamente a la
función
transfer_ctrl_msg en zxload.c:
/* wait until firmware is ready */
sleep(1);
len = transfer_ctrl_msg(adsl_handle, VENDOR_REQUEST_IN, 0x0a, 0x0c, 0x08,
buf, 0x1);
Los parámetros pasados a través de transfer_ctrl_msg hacen match con los
parámetros
pasados a usb_control_msg en su código:
int tmout = CTRL_TIMEOUT; /* timeout value */
n = 0;
for (j = 0; j CTRL_MSG_RETRIES; j++) {
#ifdef SIMULATE
n = size;
#else
n = usb_control_msg(adsl_handle, requesttype, request, value, index,
buf, size, tmout);
Alguien sabe el motivo de ¿por qué el timeout?, tengo que cambiar los
valores hex del
requesttype o alguno otro?, a ver si alguien ya los conoce los detalles de
hardware del
dichoso modem.
Ahora también probe con el speedtouch que el kernel 2.4.22 ya lo incluye,
modificando
el código fuente del módulo speedtch.c y también de los headers que
acompañan las fuentes del
paquete speedtouch de debian para que acepte el ProductID como 0xa5a5 (que
es el productid de
mi modem)
Y cuando se lanza:
~# modem_run -m -f /ruta/al/fw-usb.bin
Pues el mensaje es similar a los que aparecen con zxload, reconoce el modem
pero no puede
subir el firmware.
Saludos!
nmag only
__
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--
nmag only
gnupg
