-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-01-12 a las 22:17 +0100, Camaleón escribió:
Algo pasa con este puerto a continuación os pongo parte del log que me aparece en messages.
|>> Jan 12 21:34:15 linux kernel: serial8250: too much work for irq3 |>>Jan 12 21:34:15 linux kernel: serial8250: too much work for irq3
Jan 12 21:34:36 linux kernel: ttyS0: LSR safety check engaged! Jan 12 21:34:46 linux kernel: ttyS0: LSR safety check engaged!
¿Qué diantres es ésto? :-? ¿Por qué se toma el puerto ttyS0 y quién se lo agencia? Este mensaje no lo recuerdo de antes... ¿lo tienes sólo desde hoy o ayer también te aparecía?
setserial debe tomar ttyS1 como está definido, luego ¿qué controlador / proceso /servicio ha secuestrado ttyS0? Qué raro...
Es el propio kernel. Por cierto, seterial puede tomar el puerto como está, o puede "definirlo". Ya lo dije: el puerto serie puede generar interrupciones, cuando recibe datos o cuando llaman al timbre (linea ring), por ejemplo. Tendría que volver a estudiarmelo para ser más preciso, hace años, o lustros, que no programo el puerto serie (y nunca en linux). En MsDos esas interrupciones sólo son manejadas cuando se carga un programa que lo haga, pero en linux el kernel está continuamente cargado: luego si el puerto serie decide interrumpir, el kernel lo atenderá. Y si se producen demasiadas interrupciones, se quejará: y da gracias, ya comenté que hace pocos años casi se quedaba frito, que me pasó. Ese (el de LSR) mensaje está en el kernel, lo he encontrado en : /usr/src/linux/drivers/serial 630:au1x00_uart.c 671:sunsu.c 1654:8250.c en los fuentes de kernel-source-2.6.16.27-0.6 (suse 10.1). y es en esos tres ficheros por la misma causa: el kernel detecta un bug en la UART, o su inexistencia. Él tiene un "Serial Port 16450 Compatible", según hwinfo. El driver del kernel (8250.c) comenta: /* * We detected a chip without a FIFO. Only two fall into * this category - the original 8250 and the 16450. The * 16450 has a scratch register (accessible with LCR=0) */ Hay que joderse, no tiene FIFO. Eso significa una interrupción por cada byte enviado o recibido, en vez cada 10, por ejemplo. Ahora observa: (Los //> son mios) static int serial8250_startup(struct uart_port *port) { ... /* * Clear the interrupt registers. */ (void) serial_inp(up, UART_LSR); //> In: Line Status Register (void) serial_inp(up, UART_RX);; //> In: Receive buffer (DLAB=0) (void) serial_inp(up, UART_IIR);; //> In: Interrupt ID Register (void) serial_inp(up, UART_MSR);; //> In: Modem Status Register /* * At this point, there's no way the LSR could still be 0xff; * if it is, then bail out, because there's likely no UART * here. */ if (!(up->port.flags & UPF_BUGGY_UART) && (serial_inp(up, UART_LSR) == 0xff)) { printk("ttyS%d: LSR safety check engaged!\n", up->port.line); return -ENODEV; } Cuando sale ese mensaje, ¡el driver abandona! Está diciendo que cree que no hay UART, que no hay nada que hacer. Lo de "bail out" es un sálvese quien pueda. Respecto al otro mensaje: |>> Jan 12 21:34:15 linux kernel: serial8250: too much work for irq3 También está en el "8250.c". Observa: #define PASS_LIMIT 256 ... /* * This is the serial driver's interrupt routine. * * Arjan thinks the old way was overly complex, so it got simplified. * Alan disagrees, saying that need the complexity to handle the weird * nature of ISA shared interrupts. (This is a special exception.) * * In order to handle ISA shared interrupts properly, we need to check * that all ports have been serviced, and therefore the ISA interrupt * line has been de-asserted. * * This means we need to loop through all ports. checking that they * don't have an interrupt pending. */ static irqreturn_t serial8250_interrupt(int irq, void *dev_id, struct pt_regs *regs) { ... if (l == i->head && pass_counter++ > PASS_LIMIT) { /* If we hit this, we're dead. */ printk(KERN_ERR "serial8250: too much work for " "irq%d\n", irq); break; Así que... bien jodidos. El segundo mensaje quizás se pueda solventar trabajando a velocidades del modem más lentas; pero como sea una oscilación por algún cable o algo... nanay, fritos. El primero.... ¡Buff! :-((( En mi opinión, esto confirma que el culpable es la placa. Es posible que el código del windows sepa solventar ese bug o fallo de ese hardware, y que por eso funcione; pero obviamente el kernel del linux no. Yo no se si hay algún algo en el kernel que se pueda tocar y que ayude... ni idea. ¿colisión entre puertos? :-??? Creo que es reportable en el bugzilla, pero... aparte de hacerlo en inglés, hay que ayudar a los que lo tomen con sus peticiones de más información técnica. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFqB5ItTMYHG2NR9URAguPAJ4nttexZcbzmB8vQmEMzsRUNGmckQCaAhk4 KjcE7ftJzc1EPPKeWkZvYRM= =Snmx -----END PGP SIGNATURE-----