0

There are some cases when it is needed to see the full log of Linux kernel panic.
But it often can't be done through the regular terminal in display.
I thought that it should be done through the COM-port, but can't figure out:
How can I do that?
What is the reason of working well through COM-port, but not through terminal in my display?

UPD: I use debian-based custom Linux (4.9 kernel) with HDMI-display.
Related: How to get a Linux panic output to a USB serial console when system has also a display adapter

NK-cell
  • 1,145
  • 6
  • 19
  • Can you only see the last parts of it? Have you tried scrolling up? – that other guy Apr 23 '20 at 17:40
  • @thatotherguy Yep, only the last part. For some reason can't scroll. Do you can? – NK-cell Apr 23 '20 at 17:41
  • What system are you doing this on? What is your display vs COM port? You can tell the kernel to boot with the serial port as the console. For example, if you are developing code on a PC for a test/target system, such as Raspberry Pi, you can connect a cable, do `minicom` on the PC and connect to the RPi with [usually] a USB-to-serial dongle cable. `minicom` can save all output it gets. – Craig Estey Apr 23 '20 at 17:42
  • @CraigEstey Updated question. – NK-cell Apr 23 '20 at 17:46
  • If you are developing kernel code, it can be really good to work in a virtual machine. You can easily capture crashes with the virtual serial port. You can even develop a virtual hardware emulator for your device if you are doing a driver. Another good option is to use a second PC as your remote development target. You can use Ethernet to get a remote console. I think "netconsole" is what you want for that. You could also use serial ports or USB serial ports and a null-modem cable to connect the two PCs. It is more convenient when your development machine does not crash if there's a bug. – Zan Lynx Apr 23 '20 at 17:53
  • @ZanLynx completely agree! I use virtual machines. But there are some cases when production device crashes (e.g. on release tests) on conditions that are close to real-life (which can't be done on a virtual machine). But what's a "netconsole"? The network stack is not so simple subsystem or a crashing kernel to manage, isn't it? – NK-cell Apr 23 '20 at 17:59
  • Let me clarify. You really need _two_ systems. A development system [usually a PC running linux] and a serial UART [usually a USB-to-UART dongle cable]. The target system needs a UART serial port. Most low end systems like RPi have one. The target system only needs to set console to its UART [e.g. from your link]. Other systems can "tunnel" the console output through either Ethernet or USB-to-USB. But, this depends upon the H/W ports each system has. So, give the make/model of the two systems (e.g. devel sys is Acer model XXXXX with blah ports and target is RPi model YYYYY with uart/USB ports) – Craig Estey Apr 23 '20 at 18:00
  • What about: https://www.kernel.org/doc/html/v4.14/dev-tools/kgdb.html – Craig Estey Apr 23 '20 at 18:04
  • 1
    @NK-cell For capturing crashes on production devices look into kdump. It uses a small crash kernel, a reserved memory area for the kdump kernel, and the kexec feature so that on a kernel panic it starts a new kernel which can capture and handle the crash and all logs. With enough customization it can package it up and send it to a website, or it can just store it to disk and reboot, and then the original kernel can handle it. Enterprise distros like RedHat and SUSE do this all the time. Fedora supports it too. I don't know about other distros. – Zan Lynx May 03 '20 at 19:02

1 Answers1

1

Simple direct connected console / VTY use the graphics card to convert character bytes (0 - 255) into display character cells. 80x25 is a common format. This is very simple and not hard for a crashing kernel to manage. Just copy some memory around.

The graphical console is more complicated because the kernel now has to locate the font bitmap for a character and copy the bitmap onto the display. It also needs to handle scrolling with more memory copies, or IOCTL calls into the graphics driver, etc.

A console running in a Gnome or KDE GUI session is very complicated. The kernel isn't involved in drawing it at all and doesn't know how.

The more complex the output process is, the less likely that a kernel that is already crashing can manage it successfully.

Serial port output is once again very simple. A buffered UART makes it a bit more complicated, but if a crashing kernel wants to ignore that and simply output bytes at a 9,600 line rate, any serial port will work with that without needing buffers or interrupt management.

Zan Lynx
  • 53,022
  • 10
  • 79
  • 131
  • Thank you! So is there difference for crashing kernel to manage HDMI not graphical console or direct connected console / VTY? Still can't get it.. – NK-cell Apr 23 '20 at 19:53