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-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
