Re: What do you use for kernel debugging?

> On Sep 28, 2014, at 17:31, "José Pérez Arauzo" <fbl_at_aoek.com> wrote:
> 
> Hi Garrett,
> 
> On Sun, 28 Sep 2014 13:38:24 -0700, Garrett Cooper wrote
>> On Sep 28, 2014, at 0:34, José Pérez Arauzo <fbl_at_aoek.com> wrote:
>> 
>>> Hello,
>>> I am trying to track down a (deadlock?) issue in CURRENT via DDB. The
> kernel does
>>> not complete hw probes on my Acer V5.
>>> 
>>> I get stuck on apic_isr looping which leads nowhere.
>>> 
>>> So I thought maybe things improve if I debug from another machine.
>>> 
>>> 
>>> What do you use for kernel debugging? According to the handbook kgdb over
> serial
>>> is a good option, do you agree? I'm on a netbook with no ethernet and no
> option
>>> for firewire: can I have a USB / nullmodem setup to work?
>>> 
>>> I have no old-style uarts hardware anymore, as the handbook suggests...
>>> 
>>> Any idea is welcome before I buy extra hw. I have a USB to serial showing
> up as
>>> /dev/cuaU0, do I need to grab another one and a nullmodem cable or there
> are better
>>> alternatives? Thank you.
>> 
>> There was some discussion recently about this on an internal list. 
>> Unfortunately no, there isn’t a usable way, but there were some 
>> interesting viable methods that came up (which haven’t been 
>> implemented): ethernet/sound/xHCI.
>> 
>> Your best bet, as others have noted, is to use boot -d, use WITNESS 
>> to spot locking issues, dtrace to isolate which section of code 
>> there are problems, and finally use one of the DEBUG options noted 
>> in /sys/conf/NOTES and /sys/<your-architecture>/conf/NOTES .
>> 
>> Hope that helps!
> 
> Well, it's not so encouraging but I'll work on it.
> 
> Do you mean that we can get rid of chapter 10.5 of the handbook (On-Line
> Kernel Debugging Using Remote GDB)?

No. It still works quite well with serial consoles (both physical and virtual uarts, i.e. IPMI).

> Just to have it clear, when people develop or fix drivers in FreeBSD
> their only option is to use the above mentioned tools, as they have no
> access to a live, on-line kernel debugger?? It's disappointing, to say
> the least!

There are other things that people use, but they're a bit expensive. I'll have to look up  
> I hope Dcons + 1394 works where it's applicable.

Yes, it should work as a debug console if the system has been booted up.

When I was debugging getting ACPI to work on my netbook, here were some other things I did to get the system up and going:
- Built a stripped down kernel that just contains the essential bits (CPU, filesystem, storage).
- built one kernel with debug bits and one with release bits (titled them differently of course).
- built networking and other components as klds and loaded them at boot.
This gave me a quick turnaround time when figuring out what was broken suspend/resume wise. It might help you isolate which drivers or subsystems are causing boot issues as well (at least netbook system boot is relatively quick compared to the other systems I boot off of with gobs of ram and storage drives...).

HTH!
-Garrett