Re: What do you use for kernel debugging?
Hi Daniel, On Thu, 2 Oct 2014 20:50:30 -0400, O'Connor, Daniel wrote [...] I wrote a quick program to dump xHCI extended capabilities https://gist.github.com/DanielO/c42819ae69a1f680039a Cool! Run pciconf -lb and look for the base value for xhciX then run the command with that like so.. HCCPARAMS1 = 0x014040c3 xECP (0xf0948500) = ID 1 (Legacy support) Specific 0x0100 xECP (0xf0948504) = ID 0 (Reserved (0)) Specific 0xe000 xECP (0xf0948524) = ID 85 (Reserved (85)) Specific 0x2042 That's with AMD: xhci0: XHCI (generic) USB 3.0 controller mem 0xf0948000-0xf0949fff irq 18 at device 16.0 on pci0 usbus0: waiting for BIOS to give up control xhci0: 32 byte context size. usbus0 on xhci0 xhci0@pci0:0:16:0: class=0x0c0330 card=0x080d1025 chip=0x78141022 rev=0x01 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' class = serial bus subclass = USB BR, -- José Pérez Arauzo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What do you use for kernel debugging?
On 1 Oct 2014, at 15:54, O'Connor, Daniel Daniel.O'con...@emc.com wrote: On 1 Oct 2014, at 14:33, Adrian Chadd adr...@freebsd.org wrote: There's also something for XHCI. So I see.. Section 7.6 in here has details.. http://www.intel.com.au/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf Interestingly unlike the EHCI version it does not require hardware between the debugger and debugee, only a special cable. (see http://msdn.microsoft.com/en-us/library/windows/hardware/hh439372(v=vs.85).aspx) I wrote a quick program to dump xHCI extended capabilities https://gist.github.com/DanielO/c42819ae69a1f680039a Run pciconf -lb and look for the base value for xhciX then run the command with that like so.. xhci0@pci0:3:0:0: class=0x0c0330 card=0x077815ad chip=0x077815ad rev=0x00 hdr=0x00 bar [10] = type Memory, range 64, base 0xfd4c, size 131072, enabled root@foo:~ # ./xhcicap 0xfd4c HCCPARAMS1 = 0x0388f283 xECP (0xfd4c0e20) = ID 2 (Supported protocol) Specific 0x0300 xECP (0xfd4c0e23) = ID 3 (Extended PM) Specific 0x4253 (this is a VMWare Fusion guest with USB3 enabled) I ran it on Gigabyte Z77-D3H board (only real hardware I had handy with USB3) which has 2 USB3 controllers - one on the Intel chipset, the other an Etron EJ168. It shows.. Intel.. HCCPARAMS1 = 0x20007181 xECP (0xf7f08000) = ID 2 (Supported protocol) Specific 0x200 xECP (0xf7f08008) = ID 1 (Legacy support) Specific 0x3001 Etron.. HCCPARAMS1 = 0x040050af xECP (0xf7c01000) = ID 1 (Legacy support) Specific 0x Neither support debugging (and according to the spec the later is broken as it is supposed to have at least one ‘supported protocol’ entry). Regards, Daniel O’Connor Senior Software Engineer Isilon Platforms Team ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What do you use for kernel debugging?
On 10/01/14 07:03, Adrian Chadd wrote: There's also something for XHCI. Please please write it for freebsd. :) Hi, The FreeBSD bootloader can run a regular USB stack which connects to the XHCI/EHCI and any supported serial adapter for example. What is currently missing is some PCI pieces to attach the drivers. You don't need the USB debug port to get keyboard/console input. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What do you use for kernel debugging?
On 1 Oct 2014, at 14:33, Adrian Chadd adr...@freebsd.org wrote: There's also something for XHCI. So I see.. Section 7.6 in here has details.. http://www.intel.com.au/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf Interestingly unlike the EHCI version it does not require hardware between the debugger and debugee, only a special cable. (see http://msdn.microsoft.com/en-us/library/windows/hardware/hh439372(v=vs.85).aspx) A quick search shows the cable is pretty cheap ($15 for a short one) Please please write it for freebsd. :) Not sure I have the cycles :( -a On 30 September 2014 21:45, O'Connor, Daniel Daniel.O'con...@emc.com wrote: On 1 Oct 2014, at 0:14, Julian Elischer jul...@freebsd.org wrote: Unfortunately you can't use a USB serial as it requires the USB stack be working before it can be used.. similar with ethernet connected debugging which requires that the driver for the ethernet hardware support it. (which why we don't have it in the tree though it has been done several times in the past). There IS a USB debug standard, Linux has some code to support it. I am not sure what percentage of hardware has it hooked up though (the host controller has a designated debug port but it could physically be anything). http://www.coreboot.org/EHCI_Debug_Port The hardware is bit more expensive than a null modem or firewire cable though :( Regards, Daniel O’Connor Senior Software Engineer Isilon Platforms Team ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Regards, Daniel O’Connor Senior Software Engineer Isilon Platforms Team ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What do you use for kernel debugging?
On 1 October 2014 03:12, Hans Petter Selasky h...@selasky.org wrote: On 10/01/14 07:03, Adrian Chadd wrote: There's also something for XHCI. Please please write it for freebsd. :) Hi, The FreeBSD bootloader can run a regular USB stack which connects to the XHCI/EHCI and any supported serial adapter for example. What is currently missing is some PCI pieces to attach the drivers. You don't need the USB debug port to get keyboard/console input. We actually _want_ the debug port support. The EHCI/XHCI debugging stuff is separate from the whole normal USB stack and is really designed for lower level debugging - ie, when everything is actually busted. Think of it as being the polled conduit for doing remote kgdb and (hopefully, with the XHCI stuff) remote memory inspection when things go off the deep end. -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What do you use for kernel debugging?
On 9/29/14, 9:35 AM, Garrett Cooper wrote: On Sep 28, 2014, at 17:51, José Pérez Arauzo f...@aoek.com wrote: Hi Benjamin, On Sun, 28 Sep 2014 15:54:36 -0400 (EDT), Benjamin Kaduk wrote On Sun, 28 Sep 2014, José Pérez Arauzo 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? with hardware related debugging it's always hard.. in the past I used serial and firewire but they are getting hard to find. if it wasn't hardware related then using bhyve with it's gdb debugger hook works fine. Unfortunately you can't use a USB serial as it requires the USB stack be working before it can be used.. similar with ethernet connected debugging which requires that the driver for the ethernet hardware support it. (which why we don't have it in the tree though it has been done several times in the past). You cannot. Oh, what a shame. Why not? Is it because you need hardware probe to be over to use it? Today I bought a shining USB to USB thingy made by Hama, and guess what? It's not supported on FBDS, altought uplcom(4) reports support for Hama USB to RS232 brother. The bootloader doesn't support USB debugging and I'm pretty sure the devices don't support local/remote debugging :(.. I'll do some poking around. I'll talk to some SMEs and see if I can write up a TODO list for a wiki page. Cheers! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What do you use for kernel debugging?
On 9/29/14, 8:31 AM, José Pérez Arauzo 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 works when you have the hardware. but modern laptops have so little hardware.. we really will have to define an API/ABI to add to teh current ethernet driver API so that we can do network based debugging. it's getting harder and harder to find alternatives. (though debugging a VM works well). 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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What do you use for kernel debugging?
On 1 Oct 2014, at 0:14, Julian Elischer jul...@freebsd.org wrote: Unfortunately you can't use a USB serial as it requires the USB stack be working before it can be used.. similar with ethernet connected debugging which requires that the driver for the ethernet hardware support it. (which why we don't have it in the tree though it has been done several times in the past). There IS a USB debug standard, Linux has some code to support it. I am not sure what percentage of hardware has it hooked up though (the host controller has a designated debug port but it could physically be anything). http://www.coreboot.org/EHCI_Debug_Port The hardware is bit more expensive than a null modem or firewire cable though :( Regards, Daniel O’Connor Senior Software Engineer Isilon Platforms Team ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What do you use for kernel debugging?
There's also something for XHCI. Please please write it for freebsd. :) -a On 30 September 2014 21:45, O'Connor, Daniel Daniel.O'con...@emc.com wrote: On 1 Oct 2014, at 0:14, Julian Elischer jul...@freebsd.org wrote: Unfortunately you can't use a USB serial as it requires the USB stack be working before it can be used.. similar with ethernet connected debugging which requires that the driver for the ethernet hardware support it. (which why we don't have it in the tree though it has been done several times in the past). There IS a USB debug standard, Linux has some code to support it. I am not sure what percentage of hardware has it hooked up though (the host controller has a designated debug port but it could physically be anything). http://www.coreboot.org/EHCI_Debug_Port The hardware is bit more expensive than a null modem or firewire cable though :( Regards, Daniel O’Connor Senior Software Engineer Isilon Platforms Team ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What do you use for kernel debugging?
Hi Garrett, On Sun, 28 Sep 2014 18:43:45 -0700, Garrett Cooper wrote [...] 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 Yes, that's gold. It might not apply to the specific case where device probe does not complete, but I'll give it a try. Give me a day or two. Thank you! BR, -- José Pérez Arauzo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What do you use for kernel debugging?
On Sun, 28 Sep 2014, José Pérez Arauzo 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? You cannot. 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. I'm not sure that there are alternatives at all, unfortunately. You may be reduced to debugging-via-printf. -Ben Kaduk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What do you use for kernel debugging?
- Original Message - From: Benjamin Kaduk ka...@mit.edu To: José Pérez Arauzo f...@aoek.com Cc: FreeBSD Current freebsd-current@freebsd.org Sent: Sunday, September 28, 2014 8:54 PM Subject: Re: What do you use for kernel debugging? On Sun, 28 Sep 2014, José Pérez Arauzo 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? You cannot. 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. I'm not sure that there are alternatives at all, unfortunately. You may be reduced to debugging-via-printf. dtrace can also be quite invaluable. Regards Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What do you use for kernel debugging?
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! -Garrett signature.asc Description: Message signed with OpenPGP using GPGMail
Re: What do you use for kernel debugging?
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)? 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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What do you use for kernel debugging?
On Mon, 29 Sep 2014 02:31:25 +0200 José Pérez Arauzo f...@aoek.com wrote: I hope Dcons + 1394 works where it's applicable. BR, -- José Pérez Arauzo As a constant user of DCons+firewire, I can say it certainly works, and quite well at that. At least on PowerPC where firewire is everywhere. I only wish it were possible to use dcons+firewire even earlier in the boot (before the firewire device is probed), maybe initialize something in the loader. - Justin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What do you use for kernel debugging?
Hi Benjamin, On Sun, 28 Sep 2014 15:54:36 -0400 (EDT), Benjamin Kaduk wrote On Sun, 28 Sep 2014, José Pérez Arauzo 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? You cannot. Oh, what a shame. Why not? Is it because you need hardware probe to be over to use it? Today I bought a shining USB to USB thingy made by Hama, and guess what? It's not supported on FBDS, altought uplcom(4) reports support for Hama USB to RS232 brother. 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. I'm not sure that there are alternatives at all, unfortunately. You may be reduced to debugging-via-printf. Wow, bad news! :-| BR, -- José Pérez Arauzo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What do you use for kernel debugging?
On Sep 28, 2014, at 17:35, Justin Hibbits chmeeed...@gmail.com wrote: On Mon, 29 Sep 2014 02:31:25 +0200 José Pérez Arauzo f...@aoek.com wrote: I hope Dcons + 1394 works where it's applicable. BR, -- José Pérez Arauzo As a constant user of DCons+firewire, I can say it certainly works, and quite well at that. At least on PowerPC where firewire is everywhere. I only wish it were possible to use dcons+firewire even earlier in the boot (before the firewire device is probed), maybe initialize something in the loader. It would be nice if both the FireWire and USB subsystems started up sooner. There are other issues (with USB for instance), where ukbd not being initialized before the mount root prompt can leave the system undebuggable. In the short term: can the SYSINIT priority be changed in the drivers to support this? It would be nice if there was a pluggable infrastructure for bootloader enabling of devices as debugger consoles that would make this possible. Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What do you use for kernel debugging?
On Sep 28, 2014, at 17:51, José Pérez Arauzo f...@aoek.com wrote: Hi Benjamin, On Sun, 28 Sep 2014 15:54:36 -0400 (EDT), Benjamin Kaduk wrote On Sun, 28 Sep 2014, José Pérez Arauzo 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? You cannot. Oh, what a shame. Why not? Is it because you need hardware probe to be over to use it? Today I bought a shining USB to USB thingy made by Hama, and guess what? It's not supported on FBDS, altought uplcom(4) reports support for Hama USB to RS232 brother. The bootloader doesn't support USB debugging and I'm pretty sure the devices don't support local/remote debugging :(.. I'll do some poking around. I'll talk to some SMEs and see if I can write up a TODO list for a wiki page. Cheers! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What do you use for kernel debugging?
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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
