Geert,
> From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
> To: Stephen N Chivers <schivers@xxxxxxxxxx>
> Cc: Chris Proctor <cproctor@xxxxxxxxxx>, linux-serial@xxxxxxxxxxxxxxx
> Date: 05/02/2014 12:05 AM
> Subject: Re: Linux-3.15-rcX - PowerPC Serial Console woes.
> Sent by: geert.uytterhoeven@xxxxxxxxx
>
> Hi Stephen
>
> CC linux-serial
>
> On Thu, May 1, 2014 at 11:54 AM, Stephen N Chivers
> <schivers@xxxxxxxxxx> wrote:
> > Geert,
> >
> > I have a brace of PowerPC computers, most of which are
> > VME Single boards (MVME5100 and MVME4100),
> > but I also have some MPC8349MITX and a SAM440EP.
> >
> > They are all operated diskless from a file server.
> >
> > None of them have a graphical consoles and so as usual
> > I am quite reliant on the serial console.
> >
> > I am having problems with the unexpected disabling of the
> > serial console during the boot process.
> >
> > In all Linux-3.15 release candidates the serial console
> > is disabled during the boot process when the OF Platform
> > devices are registering.
> >
> > I will use the SAM440EP as an example, it is setup using
> > a defaultish configuration with, 8250 uarts configured,
> > serial console support, early printk, the "standardish"
> > UDBG console and the OF platform devices.
> >
> > The disabling of the serial console leads to the loss of
> > boot messages, this is ok for my present configuration as
> > (fortunately) the root file system is mounted and so the
> > boot messages are in /var/log/messages.
> >
> > The tty (ttyS0) device is around as after the machine has gone to
> > run state 3, the console login prompt is present without
> > problems.
> >
> > What is going on is:
> >
> > UDBG does its stuff ok. It is the console:
> >
> > bootconsole [udbg0] enabled
> >
> > The 8250 driver wakes up:
> >
> > Serial: 8250/16550 driver, 10 ports, IRQ sharing disabled
> > serial8250.0: ttyS0 at MMIO 0xef600300 (irq = 16, base_baud = 509259)
is a
> > 16550A
> > console [ttyS0] enabled
> > console [ttyS0] enabled
> > bootconsole [udbg0] disabled
> > bootconsole [udbg0] disabled
>
> Here the legacy 8250 driver takes over, as expected.
>
> > serial8250.0: ttyS1 at MMIO 0xef600400 (irq = 17, base_baud = 509259)
is a
> > 16550A
> > serial8250.0: ttyS2 at MMIO 0xef600500 (irq = 18, base_baud = 509259)
is a
> > 16550A
> > serial8250.0: ttyS3 at MMIO 0xef600600 (irq = 19, base_baud = 509259)
is a
> > 16550A
> > 0000:00:0c.0: ttyS4 at I/O 0x2000 (irq = 25, base_baud = 921600) is a
> > 16550A
> > 0000:00:0c.0: ttyS5 at I/O 0x2008 (irq = 25, base_baud = 921600) is a
> > 16550A
> >
> > The OF PLATFORM devices kick and disable the serial console:
> >
> > console [ttyS0] disabled
>
> Here the OF 8250 driver takes over.
>
> > now, the OF serial devices are:
> >
> > ef600300.serial: ttyS0 at MMIO 0xef600300 (irq = 16, base_baud =
509259)
> > is a 16550
> > ef600400.serial: ttyS1 at MMIO 0xef600400 (irq = 17, base_baud =
509259)
> > is a 16550
> > ef600500.serial: ttyS2 at MMIO 0xef600500 (irq = 18, base_baud =
509259)
> > is a 16550
> > ef600600.serial: ttyS3 at MMIO 0xef600600 (irq = 19, base_baud =
509259)
> > is a 16550
> >
> > when the devices are registered as part of the platform device probe,
> > serial8250_register_8250_port in 8250_core.c finds that these devices
> > match the earlier ones and so the lines that read:
> >
> > if (uart->port.dev)
> > uart_remove_one_port(&serial8250_reg, &uart->port);
> >
> > are executed. Now uart_remove_one_port calls unregister_console,
> > and that is where the console get disabled.
> >
> > In Linux-3.14 uart_remove_one_port does not call unregister_console
> > and so for that release the serial console remains active.
>
> That's correct.
>
> It was added in commit 5f5c9ae56c38942623f69c3e6dc6ec78e4da2076
> Author: Geert Uytterhoeven <geert+renesas@xxxxxxxxxxxxxx>
> Date: Fri Feb 28 14:21:32 2014 +0100
>
> serial_core: Unregister console in uart_remove_one_port()
>
> which fixed a crash on driver rmmod.
>
> > Taking CONFIG_OF_PLATFORM out of the configuration fixes this
> > problem. But, shouldn't serial8250_register_8250_port leave things
> > as they are if the ports match? I tried a few things along those lines
> > but the results are truly bad (the machine goes done to a "monitor"
> > that isn't U-Boot).
>
> I also don't like how the OF serial driver tries to unregister and
> register the same port.
>
> Currently this indeed removes the serial console, just like when doing
> a driver unbind or rmmod, followed by a bind or insmod.
>
> But this case is different, as no driver is actually unloaded.
> Can you check why the register_console() in uart_configure_port() is not
> called? If it's just due to a simple flag having the wrong state, perhaps
> it can be fixed easily.
See below.
>
> Is it due to port->type being reset to PORT_UNKNOWN in
> uart_remove_one_port()? It seems port->type should already have the
> right value when calling uart_add_one_port().
Yes, it is due to the port type being set to PORT_UNKNOWN in
uart_remove_one_port.
I have found that of_serial does not set the port type
in of_platform_serial_probe before it calls
serial8250_register_8250_port:
#ifdef CONFIG_SERIAL_8250
case PORT_8250 ... PORT_MAX_8250:
{
struct uart_8250_port port8250;
memset(&port8250, 0, sizeof(port8250));
port8250.port = port;
Adding:
port.port_type = port_type
immediately before the assignment:
port8250.port = port;
is a partial fix. That helps to get into the stretch of code
in uart_configure_port that would register the console. But
the console is not registered as it is already enabled:
if (port->cons && !(port->cons->flags & CON_ENABLED))
register_console(port->cons);
That is because when the console is disabled by the call to
unregister_console, the CON_ENABLED flag is not reset.
Adding:
console->flags &= ~CON_ENABLED;
to unregister_console immediately before the console is
unlocked fixes that.
I have tested these two changes and they work for my
configurations. But, the disable/enabling of the console
is a bit ugly:
console [ttyS0] disabled
console [ttyS0] enabled
If something truly unfortunate occurs while the console
is disabled it may never be observed......
The alternative is to add a call to console_stop
immediately prior to deregistering the console
in uart_remove_one_port. That would reset the
CON_ENABLED bit.
No other clients of unregister_console call console_stop
immediately prior to calling unregister_console.
Opinions?
The following (tentative) patch against 3.15-rc3 fixes the two problems.
drivers/tty/serial/of_serial.c | 1 +
kernel/printk/printk.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c
index 9924660..27981e2 100644
--- a/drivers/tty/serial/of_serial.c
+++ b/drivers/tty/serial/of_serial.c
@@ -173,6 +173,7 @@ static int of_platform_serial_probe(struct platform_device *ofdev)
{
struct uart_8250_port port8250;
memset(&port8250, 0, sizeof(port8250));
+ port.type = port_type;
port8250.port = port;
if (port.fifosize)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index a45b509..81c7161 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2413,6 +2413,7 @@ int unregister_console(struct console *console)
if (console_drivers != NULL && console->flags & CON_CONSDEV)
console_drivers->flags |= CON_CONSDEV;
+ console->flags &= ~CON_ENABLED;
console_unlock();
console_sysfs_notify();
return res;
>
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
