Re: problem w/ kgdb serial port on 2.6.0 & 2.6.1

[George Anzinger]

Uh, which kgdb?  The one from Andrew's mm tree or the one from souceforge?

George


tripperda@xxxxxxxxxx wrote:
> when trying to use the newest kgdb patches against both 2.6.0 and 2.6.1, I ran into a boot-time kernel oops in the serial port code. this would happen shortly after connecting to a remote gdb, on a Dell M60 laptop.
>
> I don't have the actual oops message anymore, but I have a patch that fixed things for me. not sure if the patch is correct, so here's the info:
>
> the oops happened in serial_core.c:uart_match_port(struct uart_port *port1, struct uart_port *port2). the problem was that port1 was NULL, causing an oops on this code (I've added printks in my file, so the line numbers would be off):
>
> static int uart_match_port(struct uart_port *port1, struct uart_port *port2)
> {  
>         if (port1->iotype != port2->iotype)
>                 return 0;
>
> this was called from uart_find_match_or_unused(struct uart_driver *drv, struct uart_port *port), here:
>
>         for (i = 0; i < drv->nr; i++)
>                 if (uart_match_port(drv->state[i].port, port))
>                         return &drv->state[i];
>
>
> I added printks to get a better idea of what's going on and see this:
>
> Jan 14 23:58:09 localhost kernel: uart_register_driver (will alloc state)
> Jan 14 23:58:09 localhost kernel: uart_add_one_port: line 1
> Jan 14 23:58:09 localhost kernel: uart_add_one_port: line 3
> Jan 14 23:58:09 localhost kernel: uart_add_one_port: line 4
> Jan 14 23:58:09 localhost kernel: uart_add_one_port: line 5
> Jan 14 23:58:09 localhost kernel: uart_add_one_port: line 6
> Jan 14 23:58:09 localhost kernel: uart_add_one_port: line 7
>
> are the ports added supposed to be sequential? it looks like drv->state[i].port is filled in as needed, but uart_find_match_or_unused() seems to expect all drv->state[i] for i = 0 && i < drv->nr.
>
> I "fixed" this in my kernel by adding checks for drv->state[i].port being non-null before trying to use it, and everything works great (patch attached). but I'm not sure if that's the correct solution, or if the ports should be added sequentially instead of as they are. I'm more than happy to run more tests and get more information.
>
> Thanks,
> Terence
>
>
>
>
>
> ------------------------------------------------------------------------
>
> --- serial_core.c	2004-01-16 14:20:15.000000000 -0600
> +++ serial_core.c.new	2004-01-16 14:19:43.000000000 -0600
> @@ -2304,7 +2304,7 @@
>  	 * then we can't register the port.
>  	 */
>  	for (i = 0; i < drv->nr; i++)
> -		if (uart_match_port(drv->state[i].port, port))
> +		if (drv->state[i].port && uart_match_port(drv->state[i].port, port))
>  			return &drv->state[i];
>  
>  	/*
> @@ -2313,7 +2313,8 @@
>  	 * used (indicated by zero iobase).
>  	 */
>  	for (i = 0; i < drv->nr; i++)
> -		if (drv->state[i].port->type == PORT_UNKNOWN &&
> +		if (drv->state[i].port &&
> +		    drv->state[i].port->type == PORT_UNKNOWN &&
>  		    drv->state[i].port->iobase == 0 &&
>  		    drv->state[i].count == 0)
>  			return &drv->state[i];
> @@ -2323,7 +2324,8 @@
>  	 * entry which doesn't have a real port associated with it.
>  	 */
>  	for (i = 0; i < drv->nr; i++)
> -		if (drv->state[i].port->type == PORT_UNKNOWN &&
> +		if (drv->state[i].port &&
> +		    drv->state[i].port->type == PORT_UNKNOWN &&
>  		    drv->state[i].count == 0)
>  			return &drv->state[i];
>  

--
George Anzinger   george@xxxxxxxxxx
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/