Re: [BUG/PATCH] : bug in tty_default_put_char()

[Jean Tourrilhes]

On Mon, Aug 26, 2002 at 09:22:23PM +0100, Russell King wrote:
> On Mon, Aug 26, 2002 at 01:17:32PM -0700, Jean Tourrilhes wrote:
> > 	It's possible that it's a bit more complex than that, but the
> > TTY stuff is a bit magic to me.
> 
> The patch appears to be in 2.5.31.
> 
> Ok, do you want me to cook up a patch to make ircomm bug() when put_char
> gets called when write_room would have returned 0 ?
> 
> Is it possible for the user who experienced the problem to try out such
> a patch?

	Hi,

	After sending you bogus path and bogus bug reports, I though
it would be time to send you a *real* patch.
	Patch below allow to set "uart=none", which is necessary for
FIR hardware. Patch for 2.5.31.

----------------------------------------------
diff -u -p linux/drivers/serial/core.r1.c linux/drivers/serial/core.c
--- linux/drivers/serial/core.r1.c      Wed Aug 28 11:54:20 2002
+++ linux/drivers/serial/core.c Wed Aug 28 11:58:21 2002
@@ -730,12 +730,17 @@ uart_set_info(struct uart_info *info, st
                 */
                if (port->type != PORT_UNKNOWN)
                        retval = port->ops->request_port(port);
+               else
+                       /* If we set the uart to unknown, we should *always*
+                        * succeed at the test below. - Jean II */
+                       retval = 0;
 
                /*
                 * If we fail to request resources for the
                 * new port, try to restore the old settings.
                 */
                if (retval && old_type != PORT_UNKNOWN) {
+                       DPRINTK("uart_set_info(%d): could not set new serial configuration, reverting to old one\n", MINOR(tty->device) - tty->driver.minor_start);
                        port->iobase = old_iobase;
                        port->type = old_type;
                        port->hub6 = old_hub6;
----------------------------------------------

	Regarding the initial bug I reported.
	The write is comming from the PPP line discipline. If PPP
can't transmit the data, it just drops it and assume higher layers
will retry. This is true for TCP, but not for "chat".
	I implemented the workaround, and the user report that it has
fixed his problem.
	I've also found a bunch of other bugs related to that in the
process, but I'll spare you the details.

	Have fun...

	Jean