Re: post 3.14 serial regression

[Geert Uytterhoeven]

Hi Greg,

On Wed, Apr 9, 2014 at 2:36 AM, Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Apr 08, 2014 at 02:38:31PM -0700, Dave Hansen wrote:
>> On 04/08/2014 02:03 PM, Dave Hansen wrote:
>> > On 04/08/2014 04:27 AM, One Thousand Gnomes wrote:
>> >>> At the end, you can see that init is somehow dying.  If I revert this
>> >>> patch, init is happy again and doesn't die, and the serial console works
>> >>> like before.
>> >>
>> >> Can you check if init is getting a SIGHUP - possibly its opening the
>> >> device and when it goes away gets a hangup which it isn't catching ?
>> >
>> > I do see plenty of SIGCHLDs and a heap of SIGTERMs to 'systemd-udevd',
>> > but no SIGHUP.  I do see a "Warning: unable to open an initial console."
>> > now, though.  (details far below)
>> >
>> > I instrumented uart_remove_one_port().  It *looks* like while searching
>> > for a uart_port for 0x1008 (my actual port),
>> > serial8250_find_match_or_unused() finds 0x3e8 since 0x3e8 is
>> > PORT_UNKNOWN.  The new code unregisters the 0x1008 console since it
>> > _thinks_ it is about to re-register it.
>>
>> <sigh>
>>
>> Looks like this just changed the detection order so my device went from
>> ttyS2 to ttyS4:
>>
>> # cat /proc/tty/driver/serial
>> serinfo:1.0 driver revision:
>> 0: uart:16550A port:000003F8 irq:4 tx:0 rx:0 CTS|DSR|CD
>> 1: uart:16550A port:000002F8 irq:3 tx:0 rx:0
>> 2: uart:unknown port:000003E8 irq:4
>> 3: uart:unknown port:000002E8 irq:3
>> 4: uart:ST16650V2 port:00001008 irq:18 tx:0 rx:0
>> 5: uart:ST16650V2 port:00001000 irq:19 tx:0 rx:0
>
> That's not good.
>
> Geert, any idea how to fix this?  Or should I just revert your change to
> get back to the "working" behavior?

Sorry, no idea. Reverting the change will bring back the crash on
unbind for me.

When I read Dave's first email, my first though was "why is
uart_remove_one_port() called on an active port?". But this doesn't
seem to be the case?

Dave: If I understand it correctly, you use console=ttyS2, while the kernel
suddenly changed the order of the serial devices, so your port is no
longer ttyS2, but ttyS4. Hence the serial port is not found, and
uart_remove_one_port() is called on it, taking away your /dev/console for
userspace?

Why does the serial port driver call uart_add_one_port() for ports that
don't exist?
Or if it does exist ("inaccessible and buried inside the system somewhere"),
how is it removed again?

>From the backtrace, it's the call below to uart_remove_one_port()
that removes the port?

/**
 *      serial8250_register_8250_port - register a serial port
 *      @up: serial port template
 *
 *      Configure the serial port specified by the request. If the
 *      port exists and is in use, it is hung up and unregistered
 *      first.
 *
 *      The port is then probed and if necessary the IRQ is autodetected
 *      If this fails an error is returned.
 *
 *      On success the port is ready to use and the line number is returned.
 */
int serial8250_register_8250_port(struct uart_8250_port *up)
{
        ...

        if (uart && uart->port.type != PORT_8250_CIR) {
                if (uart->port.dev)
                        uart_remove_one_port(&serial8250_reg, &uart->port);

where was it added before?

I'm a bit confused...

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-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/