Date: Sun, 28 Sep 2014 18:43:45 -0700 From: Garrett Cooper <yaneurabeya@gmail.com> To: =?utf-8?Q?Jos=C3=A9_P=C3=A9rez_Arauzo?= <fbl@aoek.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: What do you use for kernel debugging? Message-ID: <82981B04-42EF-4F06-A01D-5465D91C2B86@gmail.com> In-Reply-To: <20140929002025.M8991@aoek.com> References: <20140928071641.M7664@beckpeccoz.com> <761DF16E-5383-46BA-B886-CD3358D976AA@gmail.com> <20140929002025.M8991@aoek.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sep 28, 2014, at 17:31, "Jos=C3=A9 P=C3=A9rez Arauzo" <fbl@aoek.com> wr= ote: >=20 > Hi Garrett, >=20 > On Sun, 28 Sep 2014 13:38:24 -0700, Garrett Cooper wrote >> On Sep 28, 2014, at 0:34, Jos=C3=A9 P=C3=A9rez Arauzo <fbl@aoek.com> wrot= e: >>=20 >>> 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. >>>=20 >>> I get stuck on apic_isr looping which leads nowhere. >>>=20 >>> So I thought maybe things improve if I debug from another machine. >>>=20 >>>=20 >>> What do you use for kernel debugging? According to the handbook kgdb ove= r > 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? >>>=20 >>> I have no old-style uarts hardware anymore, as the handbook suggests... >>>=20 >>> Any idea is welcome before I buy extra hw. I have a USB to serial showin= g > up as >>> /dev/cuaU0, do I need to grab another one and a nullmodem cable or there= > are better >>> alternatives? Thank you. >>=20 >> There was some discussion recently about this on an internal list.=20 >> Unfortunately no, there isn=E2=80=99t a usable way, but there were some=20= >> interesting viable methods that came up (which haven=E2=80=99t been=20 >> implemented): ethernet/sound/xHCI. >>=20 >> Your best bet, as others have noted, is to use boot -d, use WITNESS=20 >> to spot locking issues, dtrace to isolate which section of code=20 >> there are problems, and finally use one of the DEBUG options noted=20 >> in /sys/conf/NOTES and /sys/<your-architecture>/conf/NOTES . >>=20 >> Hope that helps! >=20 > Well, it's not so encouraging but I'll work on it. >=20 > 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 virtua= l 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 ha= ve to look up =20 > 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 othe= r things I did to get the system up and going: - Built a stripped down kernel that just contains the essential bits (CPU, f= ilesystem, storage). - built one kernel with debug bits and one with release bits (titled them di= fferently 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 suspe= nd/resume wise. It might help you isolate which drivers or subsystems are ca= using boot issues as well (at least netbook system boot is relatively quick c= ompared to the other systems I boot off of with gobs of ram and storage driv= es...). HTH! -Garrett=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?82981B04-42EF-4F06-A01D-5465D91C2B86>