uart_port structure in serial8250_port[i] doesn't have the port_type values

uart_port structure in serial8250_port[i] doesn't have the port_type values

[V. Ananda Krishnan]

Hi,

  The problem described here is related to the 8250_pci driver in
2.6.12.3/2.6.12.4 kernels. When 8250_pci device driver detects a serial
port pci device and sets up the default setup (8250_pci.c), it tries to
find a match or unused port (serial8250_find_match_or_unused proc in in
8250.c). This leads to the uart_match_port with one of the parameters as
serial8250_ports[i].port. During debugging, I noticed that the none of
elements of the serial8250_ports[i].port.type was having any port value.
So the serial8250_register_port fails and the device driver module fails
to load. In this scenario, the last resort to find any entry which
doesn't have a real port associated with it also fails, because of the
null value in the serial8250_ports[i].port.type.  I would like to know
when the port.type values in uart_8250_port strucutre (in
serial8250_ports[i]) is populated? Is there anything missing in the
serial8250_find_match_or_unused codes?  Any help to degug this problem
is appreciated. Thanks.

V.Ananda Krishnan

Re: uart_port structure in serial8250_port[i] doesn't have the port_type values

[Russell King]

On Mon, Aug 15, 2005 at 09:10:56AM -0500, V. Ananda Krishnan wrote:
>   The problem described here is related to the 8250_pci driver in
> 2.6.12.3/2.6.12.4 kernels. When 8250_pci device driver detects a serial
> port pci device and sets up the default setup (8250_pci.c), it tries to
> find a match or unused port (serial8250_find_match_or_unused proc in in
> 8250.c).
> 
> This leads to the uart_match_port with one of the parameters as
> serial8250_ports[i].port. During debugging, I noticed that the none of
> elements of the serial8250_ports[i].port.type was having any port value.

Every variable has a value.  In this case, they start off as PORT_UNKNOWN
as expected.

> So the serial8250_register_port fails and the device driver module fails
> to load.

I don't follow you here - failure of this function is not dependent on
port.type being PORT_UNKNOWN.

> In this scenario, the last resort to find any entry which
> doesn't have a real port associated with it also fails, because of the
> null value in the serial8250_ports[i].port.type.

Again I don't follow you here.

The only reason serial8250_find_match_or_unused() will return NULL is
if all registered port entries correspond with real hardware ports.
In that case, the solution is to increase the number of 8250 ports
via the kernels configuration.

> I would like to know when the port.type values in uart_8250_port structure
> (in serial8250_ports[i]) is populated? Is there anything missing in the
> serial8250_find_match_or_unused codes?  Any help to degug this problem
> is appreciated. Thanks.

They're set to something other than PORT_UNKNOWN when a port is
discovered via serial8250_register_port() / uart_add_one_port().

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: uart_port structure in serial8250_port[i] doesn't have the port_type values

[V. Ananda Krishnan]

On Mon, 2005-08-15 at 15:52 +0100, Russell King wrote:
> On Mon, Aug 15, 2005 at 09:10:56AM -0500, V. Ananda Krishnan wrote:
> >   The problem described here is related to the 8250_pci driver in
> > 2.6.12.3/2.6.12.4 kernels. When 8250_pci device driver detects a serial
> > port pci device and sets up the default setup (8250_pci.c), it tries to
> > find a match or unused port (serial8250_find_match_or_unused proc in in
> > 8250.c).
> > 
> > This leads to the uart_match_port with one of the parameters as
> > serial8250_ports[i].port. During debugging, I noticed that the none of
> > elements of the serial8250_ports[i].port.type was having any port value.
> 
> Every variable has a value.  In this case, they start off as PORT_UNKNOWN
> as expected.
> 
> > So the serial8250_register_port fails and the device driver module fails
> > to load.
> 
> I don't follow you here - failure of this function is not dependent on
> port.type being PORT_UNKNOWN.

Sorry for not being clear.  When 8250_pci.c invokes the function
serial8250_register_port(&serial_port) at line 1736 (linux-2.6.12.4), I
am seeing the following values: number of ports in the pci device is 1,
and the port structure has io_type:2, iobase:0, membase:80005000 and
mapbase:d6000000. In turn, The serial8250_register_port procedure in
8250.c calls the serial8250_find_match_or_unused(port) routine (line
2439 in 8250.c of linux-2.6.12.4) which returns 0. Hence the
uart_add_one_port(&serial8250_reg, &uart->port) (line 2455 in 8250.c of
linux-2.6.12.4) codes are not touched and serial8250_register_port
returns -28 (-ENOSPC) to the register_port caller.

Please let me know, if this is data is not clear and thanks for your
immediate attention.


> 
> > In this scenario, the last resort to find any entry which
> > doesn't have a real port associated with it also fails, because of the
> > null value in the serial8250_ports[i].port.type.
> 
> Again I don't follow you here.
> 
> The only reason serial8250_find_match_or_unused() will return NULL is
> if all registered port entries correspond with real hardware ports.
> In that case, the solution is to increase the number of 8250 ports
> via the kernels configuration.
> 
> > I would like to know when the port.type values in uart_8250_port structure
> > (in serial8250_ports[i]) is populated? Is there anything missing in the
> > serial8250_find_match_or_unused codes?  Any help to degug this problem
> > is appreciated. Thanks.
> 
> They're set to something other than PORT_UNKNOWN when a port is
> discovered via serial8250_register_port() / uart_add_one_port().
> 

Re: uart_port structure in serial8250_port[i] doesn't have the port_type values

[Russell King]

On Mon, Aug 15, 2005 at 10:56:38AM -0500, V. Ananda Krishnan wrote:
> On Mon, 2005-08-15 at 15:52 +0100, Russell King wrote:
> > On Mon, Aug 15, 2005 at 09:10:56AM -0500, V. Ananda Krishnan wrote:
> > >   The problem described here is related to the 8250_pci driver in
> > > 2.6.12.3/2.6.12.4 kernels. When 8250_pci device driver detects a serial
> > > port pci device and sets up the default setup (8250_pci.c), it tries to
> > > find a match or unused port (serial8250_find_match_or_unused proc in in
> > > 8250.c).
> > > 
> > > This leads to the uart_match_port with one of the parameters as
> > > serial8250_ports[i].port. During debugging, I noticed that the none of
> > > elements of the serial8250_ports[i].port.type was having any port value.
> > 
> > Every variable has a value.  In this case, they start off as PORT_UNKNOWN
> > as expected.
> > 
> > > So the serial8250_register_port fails and the device driver module fails
> > > to load.
> > 
> > I don't follow you here - failure of this function is not dependent on
> > port.type being PORT_UNKNOWN.
> 
> Sorry for not being clear.  When 8250_pci.c invokes the function
> serial8250_register_port(&serial_port) at line 1736 (linux-2.6.12.4), I
> am seeing the following values: number of ports in the pci device is 1,
> and the port structure has io_type:2, iobase:0, membase:80005000 and
> mapbase:d6000000. In turn, The serial8250_register_port procedure in
> 8250.c calls the serial8250_find_match_or_unused(port) routine (line
> 2439 in 8250.c of linux-2.6.12.4) which returns 0. Hence the
> uart_add_one_port(&serial8250_reg, &uart->port) (line 2455 in 8250.c of
> linux-2.6.12.4) codes are not touched and serial8250_register_port
> returns -28 (-ENOSPC) to the register_port caller.

Please consider that the person you're trying to communicate with has
intimate knowledge of the code in question, so adding such things like
line numbers, filenames, and versions to your explaination just adds
extra meaningless noise which just obfuscates the rest of your
explaination.

The problem with your explaination is that it doesn't really give me
any idea what:

* ports are already registered with the driver
* the value of CONFIG_SERIAL_8250_NR_UARTS is

You can provide all of this by providing the complete and entire contents
of /proc/tty/driver/serial

Without this, I can only conclude from your above description that
all available 8250 ports are already associated with some hardware,
and therefore the 8250 driver is working as designed.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: uart_port structure in serial8250_port[i] doesn't have the port_type values

[V. Ananda Krishnan]

On Mon, 2005-08-15 at 17:11 +0100, Russell King wrote:
> On Mon, Aug 15, 2005 at 10:56:38AM -0500, V. Ananda Krishnan wrote:
> > On Mon, 2005-08-15 at 15:52 +0100, Russell King wrote:
> > > On Mon, Aug 15, 2005 at 09:10:56AM -0500, V. Ananda Krishnan wrote:
> > > >   The problem described here is related to the 8250_pci driver in
> > > > 2.6.12.3/2.6.12.4 kernels. When 8250_pci device driver detects a serial
> > > > port pci device and sets up the default setup (8250_pci.c), it tries to
> > > > find a match or unused port (serial8250_find_match_or_unused proc in in
> > > > 8250.c).
> > > > 
> > > > This leads to the uart_match_port with one of the parameters as
> > > > serial8250_ports[i].port. During debugging, I noticed that the none of
> > > > elements of the serial8250_ports[i].port.type was having any port value.
> > > 
> > > Every variable has a value.  In this case, they start off as PORT_UNKNOWN
> > > as expected.
> > > 
> > > > So the serial8250_register_port fails and the device driver module fails
> > > > to load.
> > > 
> > > I don't follow you here - failure of this function is not dependent on
> > > port.type being PORT_UNKNOWN.
> > 
> > Sorry for not being clear.  When 8250_pci.c invokes the function
> > serial8250_register_port(&serial_port) at line 1736 (linux-2.6.12.4), I
> > am seeing the following values: number of ports in the pci device is 1,
> > and the port structure has io_type:2, iobase:0, membase:80005000 and
> > mapbase:d6000000. In turn, The serial8250_register_port procedure in
> > 8250.c calls the serial8250_find_match_or_unused(port) routine (line
> > 2439 in 8250.c of linux-2.6.12.4) which returns 0. Hence the
> > uart_add_one_port(&serial8250_reg, &uart->port) (line 2455 in 8250.c of
> > linux-2.6.12.4) codes are not touched and serial8250_register_port
> > returns -28 (-ENOSPC) to the register_port caller.
> 
> Please consider that the person you're trying to communicate with has
> intimate knowledge of the code in question, so adding such things like
> line numbers, filenames, and versions to your explaination just adds
> extra meaningless noise which just obfuscates the rest of your
> explaination.
> 
> The problem with your explaination is that it doesn't really give me
> any idea what:
> 
> * ports are already registered with the driver
> * the value of CONFIG_SERIAL_8250_NR_UARTS is
> 
> You can provide all of this by providing the complete and entire contents
> of /proc/tty/driver/serial

Thanks for your guidance.  Here is the cat of /proc/tty/driver/serial:
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:11963 rx:0 RTS|DTR
1: uart:16550A port:000002F8 irq:3 tx:11 rx:0
2: uart:16550A port:00000898 irq:14 tx:0 rx:0
3: uart:16550A port:00000890 irq:15 tx:0 rx:0

> 
> Without this, I can only conclude from your above description that
> all available 8250 ports are already associated with some hardware,
> and therefore the 8250 driver is working as designed.
> 

Re: uart_port structure in serial8250_port[i] doesn't have the port_type values

[Russell King]

On Mon, Aug 15, 2005 at 11:33:39AM -0500, V. Ananda Krishnan wrote:
> Thanks for your guidance.  Here is the cat of /proc/tty/driver/serial:
> serinfo:1.0 driver revision:
> 0: uart:16550A port:000003F8 irq:4 tx:11963 rx:0 RTS|DTR
> 1: uart:16550A port:000002F8 irq:3 tx:11 rx:0
> 2: uart:16550A port:00000898 irq:14 tx:0 rx:0
> 3: uart:16550A port:00000890 irq:15 tx:0 rx:0
> 
> On Mon, 2005-08-15 at 17:11 +0100, Russell King wrote:
> > Without this, I can only conclude from your above description that
> > all available 8250 ports are already associated with some hardware,
> > and therefore the 8250 driver is working as designed.

and this is indeed the problem.  The 8250 driver already has 4 hardware
ports already registered.

Obviously, if you have 5 serial ports in the machine and you ask the
driver to only allow 4 ports, it's sensible that you'd get an ENOSPC
error when you try to register the 5th port.

So, if you have 5 ports in the machine, why not try setting
CONFIG_SERIAL_8250_NR_UARTS to at least 5?  Or if you have 6, set it
to at least 6. etc.

Sorry, but I feel like I'm explaining The Damned Obvious(tm) here,
especially as I've hinted towards CONFIG_SERIAL_8250_NR_UARTS twice
in this thread already.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: uart_port structure in serial8250_port[i] doesn't have the port_type values

[V. Ananda Krishnan]

On Mon, 2005-08-15 at 17:41 +0100, Russell King wrote:
> On Mon, Aug 15, 2005 at 11:33:39AM -0500, V. Ananda Krishnan wrote:
> > Thanks for your guidance.  Here is the cat of /proc/tty/driver/serial:
> > serinfo:1.0 driver revision:
> > 0: uart:16550A port:000003F8 irq:4 tx:11963 rx:0 RTS|DTR
> > 1: uart:16550A port:000002F8 irq:3 tx:11 rx:0
> > 2: uart:16550A port:00000898 irq:14 tx:0 rx:0
> > 3: uart:16550A port:00000890 irq:15 tx:0 rx:0
> > 
> > On Mon, 2005-08-15 at 17:11 +0100, Russell King wrote:
> > > Without this, I can only conclude from your above description that
> > > all available 8250 ports are already associated with some hardware,
> > > and therefore the 8250 driver is working as designed.
> 
> and this is indeed the problem.  The 8250 driver already has 4 hardware
> ports already registered.
> 
> Obviously, if you have 5 serial ports in the machine and you ask the
> driver to only allow 4 ports, it's sensible that you'd get an ENOSPC
> error when you try to register the 5th port.
> 
> So, if you have 5 ports in the machine, why not try setting
> CONFIG_SERIAL_8250_NR_UARTS to at least 5?  Or if you have 6, set it
> to at least 6. etc.
> 
> Sorry, but I feel like I'm explaining The Damned Obvious(tm) here,
> especially as I've hinted towards CONFIG_SERIAL_8250_NR_UARTS twice
> in this thread already.
> 
Thanks a bunch.  Will try and let you know.

Re: uart_port structure in serial8250_port[i] doesn't have the port_type values

[V. Ananda Krishnan]

On Mon, 2005-08-15 at 17:41 +0100, Russell King wrote:
> On Mon, Aug 15, 2005 at 11:33:39AM -0500, V. Ananda Krishnan wrote:
> > Thanks for your guidance.  Here is the cat of /proc/tty/driver/serial:
> > serinfo:1.0 driver revision:
> > 0: uart:16550A port:000003F8 irq:4 tx:11963 rx:0 RTS|DTR
> > 1: uart:16550A port:000002F8 irq:3 tx:11 rx:0
> > 2: uart:16550A port:00000898 irq:14 tx:0 rx:0
> > 3: uart:16550A port:00000890 irq:15 tx:0 rx:0
> > 
> > On Mon, 2005-08-15 at 17:11 +0100, Russell King wrote:
> > > Without this, I can only conclude from your above description that
> > > all available 8250 ports are already associated with some hardware,
> > > and therefore the 8250 driver is working as designed.
> 
> and this is indeed the problem.  The 8250 driver already has 4 hardware
> ports already registered.
> 
> Obviously, if you have 5 serial ports in the machine and you ask the
> driver to only allow 4 ports, it's sensible that you'd get an ENOSPC
> error when you try to register the 5th port.
> 
> So, if you have 5 ports in the machine, why not try setting
> CONFIG_SERIAL_8250_NR_UARTS to at least 5?  Or if you have 6, set it
> to at least 6. etc.
> 
> Sorry, but I feel like I'm explaining The Damned Obvious(tm) here,
> especially as I've hinted towards CONFIG_SERIAL_8250_NR_UARTS twice
> in this thread already.

  It works. Thanks a lot.
>