> 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:
>>> 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
>>> 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
> 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,
- 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
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"