> On Sep 28, 2014, at 17:31, "José Pérez Arauzo" <f...@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 <f...@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 _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"