On Sun, 28 Sep 2014 13:38:24 -0700, Garrett Cooper wrote
> On Sep 28, 2014, at 0:34, José Pérez Arauzo <f...@aoek.com> wrote:
> > Hello,
> > I am trying to track down a (deadlock?) issue in CURRENT via DDB. The
> > 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
> > is a good option, do you agree? I'm on a netbook with no ethernet and no
> > 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
> > /dev/cuaU0, do I need to grab another one and a nullmodem cable or there
> > 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
I hope Dcons + 1394 works where it's applicable.
José Pérez Arauzo
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"