kgdboe kgdb kernel debugging at boot

882 Views Asked by At

I'm attempting to get kernel debugging to work during boot. I've followed all the steps to install it (how to use kgdb over ethernet(kgdboe)?) and can connect fine when I insmod after loading, but if I add this

BOOT_IMAGE=/vmlinuz-4.0.0-rc7+ root=UUID=<my_root> ro drm.debug=0x04 kgdbwait kgdboe=@<src_ip>/eth1,@<target_ip>/ vt.handoff=7

to the kernel boot line, I don't see the module loaded, and it doesn't kgdbwait.

When I look at my kern.log, I see the following:

kgdboe: eth0 does not have a in_ifaddr struct associated. Cannot get default IP address.

I have both eth0 and eth1 by the way, but only eth1 is connected.

Any suggestions? Is it just that the pcie network card isn't loaded until after boot and it's causing me issues?

Also, why would I need to specify the source or target ip addresses? Is there any way to have kgdboe accept all ip addresses, even when trying to load it at boot?

Thanks

1

There are 1 best solutions below

0
On

Yes, for early kernel debug kgdboe does not really work. There are several issues, some easy to solve, some not solveable. You can hard link the required modules rather than demand load them to solve the easy issue. But the core problem is that the kgdb early wait will pause all worker threads, and nearly all of the Ethernet PCIe card drivers require worker threads, or else require IRQs. Even on the polled Ethernet driver support (very limited), the IRQ's can be preempted (or illegally hold locks), and prevent the polled Ethernet driver from functioning. As a result early kernel debug does not function with kgdboe reliably, and with some Ethernet drivers, at all. (e.g. kgdbwait on the GRUB2 boot line.) There has been occasional talk about hacking up various Ethernet driver sources to attempt to provide kgdboe support over a special purpose Ethernet driver, but none that I know of that is distributed. You are still best off with using a serial port, and for full functionality, a serial console, which can be multiplexed onto a single serial port if need be with kgdboc (agent-proxy). If true remote access is required, then remote into the debugging system that initiates the serial connection.

You can also use the USB port, but requires a specific USB<->serial USB dongle that is no longer sold. (Ajays Blue dongle). These were discontinued about 6 months ago, and there is no replacement yet. (It was a Windows debugging device adapted to Linux, and Windows has moved on to native USB3.0 debugging features, and Linux has yet to catch up to that.) So, unless you have the needed USB converter, or have another source, or have an alternative adapter, you are out of luck on USB2.0.

Serial is still your best option, sadly, even in 2016. See: http://kdbg.wiki.kernel.org