Using a serial console

B

balanga

People have mentioned using a serial console to find out what is going on if the screen goes blank. Has anyone used one?

From what I've read you need a comms port and a serial cable, but when did you last see a computer with a comms port?

Will a USB-RS232 adapter suffice? And if so, how should it be configured?
 
with a usb-to-serial adapter, you might lose some of the messages at start, because the usb serial ports needs to be configured, and that can't happen until the kernel is loaded (and a while later). They might be buffered, but you won't know until you try.

Using a usb serial port on a FreeBSD machine (say amd64) to access the built in serial port on another FreeBSD machine (example: Raspberry Pi) works great.

Note: usb serial adapters (and usb serial ports on single board computers like the Raspberry Pi, BeagleBone, etc) comes in various models: 5V, 3.3V. Make sure you don't accidentally connect a 5V device to a device which only can handle 3.3V.

You might need to configure the serial console on the FreeBSD machine, the handbook has an example: https://docs.freebsd.org/en/books/handbook/serialcomms/#serialconsole-setup
 
Can I use a usb-to-serial adapter on a laptop if I want to see the system bootup on another system? I guess I would need another usb-to-serial adapter on the other system... unless I can find something with a RS232 port...
 
Adding to that: an on-board "COM" port was a key requirement when I was looking for a board for building my server a few years ago :) IMHO, a server shouldn't have any gfx chip, and serial console is the "natural" thing to do. A decent server board should also have a BIOS that works with a serial console.

Of course, this doesn't help when trying to get last messages from a crashing kernel… struggling with a similar issue right now, trying to debug why radeonkms.ko only loads fine every ~5th attempt on my "evergreen" hardware (PALM chip)…
 
VladiBG said:
On Intel platform that support AMT you can use Intel® AMT serial-over-LAN using Intel Manageability Commander to access the console.
Click to expand...
Don't know anything about AMT... Is this supported on FreeBSD and how do I tell if a ThinkPad X220 supports it?
 
balanga said:
Is this supported on FreeBSD
Click to expand...

Intel ME is out of band management, it's allow you to manage the computer remotely even if it's turned off or without installed OS.


Depend of the model of the CPU but according the spec it support AMT. You can check your Bios and enable it, after that you need to boot into intel ME set up the strong password.

Detailed specifications - ThinkPad X220 - Lenovo Support US

support.lenovo.com support.lenovo.com

  • Ethernet
    • Non-vPro model: Intel 82579LF Gigabit Network Connection (Lewisville), PHY, PCIe x1
    • vPro model: Intel 82579LM Gigabit Network Connection (Lewisville), PHY, PCIe x1
  • Intel Active Management Technology (iAMT)
Click to expand...
 
Where do I find this? Is it in the BIOS?

I notice that Config -> Intel (R) AMT -> Console Type -> [ PC ANSI, VT100, VT100+, VT-UTF8]

Machine Type Model is 4290NP3
 
VladiBG said:
Only if you have vPro model: Intel 82579LM
Click to expand...
I guess you meant the NIC....

Is this one OK?

Code: 
em0@pci0:0:25:0:<------>class=0x020000 card=0x21ce17aa chip=0x15028086 rev=0x04 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82579LM Gigabit Network Connection (Lewisville)'
    class      = network
    subclass   = ethernet
 
Yes it's ok. You can enable Intel ME enter in the configuration usually with ctrl+P and set up the initial password and IP address then you can try to connect from another machine using intel manageability commander or mesh commander.

Note that the Intel ME password must be 8-32 symbols long with strong complexity ( at least one digit, one symbol except ":" "," ‘”’ , one lower-case letter and one upper case later" otherwise it will not allow you to set the password. The Default password is "admin" when you first initialize it from the bios.
 
I am bumping this topic because despite trying to read the docs found on the Internet, I still don't understand the process of debugging a crash with a serial console. Let's assume i915kms crashes a computer, but because the screen becomes blank and there is no way to access a debugger on that computer, I need a serial console. So, assuming that computer has a DB9 serial port accessible on the outside of its chassis, I can use a serial-to-USB cable to connect one end of the cable to the DB9 port and also connect the other end of the cable to another computer's USB port? So, in this scenario, the computer with the USB port will be able to debug the crash that occurred on the computer with the DB9 port?.. If certain types of crashes can only be debugged with a serial console, why are DB9 ports a rare thing these days? In a situation where DB9 ports are not accessible from the outside and there are no com headers within computers, how can the process of debugging a difficult to diagnose crash proceed?
 
The easy part first: the serial console helps you get a console when the built in one doesn't work (like your i915kms example).
Real serial ports (aka "DB9" as you write) are a rarity (or at least scarce) today, because it has been replaced with usb.
So, you use a usb-to-serial adapter on the crashing computer to get a serial port.
The problem / challenge here is that most likely you will need to configure FreeBSD to give you a serial configure on a usb-to-serial port; it doesn't happen automatically. And that can be hard to do if your computer is crashing and you don't have access to it.

Why are real serial ports a rarity? Because computers are not made for the needs of developers; they are made for the needs of "consumers" (ugh, I dislike that word).

Other ways to debug:
- network access (this one is obvious); if you crashing computer still has network access, you can ssh into it and look at things from there. This very workstation that I'm writing on now has a problem that happens occasionally: the graphics card in it crashes, leaving a black or frozen screen. So I keep a ssh connection open from another workstation so I can shutdown this one when the graphics card crashes (a simple reboot doesn't help, it must be a power off / on sequence).
- forensic / after the fact analysis; if the hard drive / storage device in the machine can be take out and attached to another machine you can use that to look at log files, crash dumps etc.
 
tingo said:
So, you use a usb-to-serial adapter on the crashing computer to get a serial port.
Click to expand...
Wait, in the scenario that I described, a crashing computer has a DB9 (COM) port. There is no need for the crashing computer to have an actual COM port if you want to debug the cause of the crash with a serial console?
 
Oleg_NYC said:
Wait, in the scenario that I described, a crashing computer has a DB9 (COM) port. There is no need for the crashing computer to have an actual COM port if you want to debug the cause of the crash with a serial console?
Click to expand...
I have no experience with (FreeBSD) kernel debugging ... maybe there is an option for "remote debugging" via serial console, but as far as I understood it, this thread wasn't about something like that but "just" about seeing (kernel) messages right before the crash.

There's always the "post mortem analysis" of kernel crashes using the dump files with a debugger, you just have to configure your system to create a crash dump.

Regarding a serial console, it might be possible to get that to work on some USB port (using a converter) as well, never tried. It certainly needs much more kernel code to work fine (the full USB stack and driver for the converter). For a server board, I'd always look for one with a *real* RS-232 port, but that's not for debugging but for having a local console at all, as I want my servers "headless" (so it should also have a "BIOS" that can use that serial console).
 
Can you explain to me what's going on in my situation? I have a serial-to-USB cable, so I connected one end of it to the com port of my computer and connected the other end to the USB port of another computer. On the computer with the USB port, I typed cu -l /dev/ttyU0 . I added
Code: 
console="comconsole"
to /boot/loader.conf of the computer with the DB9 port, rebooted the computer and when the OS started loading, the computer with the USB port started printing out garbage characters using the cu program. What does this all mean? I have no idea. Why were these garbage characters, but not meaningful ones?
 
Did you set the baud rate, etc. as required? Seems like you might be missing a few steps.

Some of these USB to serial things are a bit flakey, but work OK in my experience (not tried with FreeBSD).
 
You must log in or register to reply here.
Back
Top