On Sat, 2023-10-14 at 10:41 +0100, Richard Purdie wrote: > Brief summary: > > We're seeing an issue on x86_64 with 6.5.X where data appears to be > left in the transmission buffer and not sent to the port on the second > serial port (ttyS1) until we trigger it with intervention. > > Paul Gortmaker did some painful bisection over a few days down to: > > serial: core: Start managing serial controllers to enable runtime PM > https://lore.kernel.org/linux-serial/1431f5b4-fb39-483b-9314-ed2b7c118c11@xxxxxxxxx/T/#t Having poked around a bit and knowing nothing about any of this, should this bit of new code added in the above commit to __uart_start() in serial_core.c: /* * Start TX if enabled, and kick runtime PM. If the device is not * enabled, serial_port_runtime_resume() calls start_tx() again * after enabling the device. */ if (pm_runtime_active(&port_dev->dev)) port->ops->start_tx(port); actually be something like: if (pm_runtime_active(&port_dev->dev) || !pm_runtime_enabled(&port_dev->dev)) port->ops->start_tx(port); since there are uarts that don't enable runtime PM? I notice that 16550A I'm using doesn't set UART_CAP_RPM and since we have data left in the xmit buffer (I managed to confirm that), it is as if during init, there is a race between the serial probing and the getty putting data in the buffer? If it weren't statrted, that would explain things... Keep in mind I know nothing about pm_runtime or serial/uarts so this is guesswork on my part. Cheers, Richard
