Date: Mon, 29 Sep 2014 02:31:25 +0200 From: "=?UTF-8?Q?Jos=C3=A9_P=C3=A9rez_Arauz?=o" <fbl@aoek.com> To: Garrett Cooper <yaneurabeya@gmail.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: What do you use for kernel debugging? Message-ID: <20140929002025.M8991@aoek.com> In-Reply-To: <761DF16E-5383-46BA-B886-CD3358D976AA@gmail.com> References: <20140928071641.M7664@beckpeccoz.com> <761DF16E-5383-46BA-B886-CD3358D976AA@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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)? 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! I hope Dcons + 1394 works where it's applicable. BR, -- José Pérez Arauzo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140929002025.M8991>