Serial port debugging... with no serial port?

[rastersoft]

I'm having an odd problem with my laptop: since Linux 6.14 (now with 6.17) it doesn't turn off when it should: it kills all the processes, turns off the screen, but the power led, fan and other leds don't turn off until about 10 to 90 seconds after that (quite random). The journal just shows the normal shutdown process until it says "journal stopped", which matches with the time when the screen goes off, so I have no extra debug info to know what is happening.

In the old days I know that I could use a serial port to send all the kernel debug info, but this is a laptop and it has no serial ports, so the obvious question is: can an USB to serial port work in this case? I'm not very sure, because the USB interface is much more complex than the old 8250/16550 UARTs, so I'm not sure that it would still be working when the problem itself is triggered. So that's my question: can an USB to serial port work until the very last moment, or is it probably being shat down much before? (I also read that, in case of a kernel panic, interrupts aren't available, and I'm pretty sure that USB requires interrupts to work, unlike the old 8250/16550, which could be driven with polling).

 

[dos2unix]

Just curious... do you know what the S in USB stands for?

It's not RS-232, but it;s still serial.

 

[rastersoft]

Being serial or not is not the point. The point is that USB protocol is extremely complex and requires a lot of help from the driver and more, so I'm not sure if it is available just until "the very end", even when the ACPI command to do the shutdown operation is sent, or not. With the original serial port, working with it was so simple that it could be done with a couple of lines and even without interrupts, so in case of an error after the full shutdown process, while the ACPI virtual machine was processing the power off command, it still was possible to send characters through it.

 

[theLegionWithin]

presumably you'd need a USB to TTL serial adapter & then use a serial terminal app to debug via console.

 

[rastersoft]

presumably you'd need a USB to TTL serial adapter & then use a serial terminal app to debug via console.

I've been doing extra investigation, and it seems a little bit more complex: I needed two USB to serial adapters, one for the computer with the problem to send the data, and another for the computer receiving the messages. I had to trick an arduino for that because I had only one USB-to-serial-TTL adapter. Also, an extra driver has to be compiled into the kernel, and also seems that the USB-to-serial driver must also be compiled directly inside the kernel, and not as a module, so I had to compile a new kernel from sources. Finally, the parameters "console=tty0 console=ttyUSB0,19200n8" must be added to the kernel boot (at first I was adding only the second one, and the system didn't boot into the real root, but only entered the ramdisk). That seems to work, and just now I'm going to test shutting down the problematic computer...

 

[rastersoft]

Aaaand... it was too slow, so I'm not sure if the computer just shat down correctly, or the terminal was so slow that it gave enough time, so I cranked it up to 115200 bauds. Let's see what happens...

 

[bob466]

Serial Port...now there's something I've not heard of for a very long time.