From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 01:43:51 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41A86DBC for ; Mon, 29 Sep 2014 01:43:51 +0000 (UTC) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 15C9B35E for ; Mon, 29 Sep 2014 01:43:51 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id fp1so3265187pdb.21 for ; Sun, 28 Sep 2014 18:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=vsfQlpOhda319LQo3sgn8fWtYyBwjIi2Abh1RzUOVAY=; b=a7T+OQ7x0985zSYM+TNUeYOR0CaPd80WlBWHbjmwnMCsFidvKWz5BRZuszf7DF9NdA 9mwqaD37G9Z8A2WtgGtKccjQgt8w6rauZYiP0CV45Io+x74CWdi/1BKF9dAfTDGAol1b CEXouedsh9na5qOF94IaPs754BEBr8nTnp8rj3YBj3H3WV63kzrSLtC6Ot+NUwDgVdEm EMUttahe8HmDF+8lsNin0waeo9aRM7x4afTs1nFGH5sZx6Fxi4h4e4Cf2vzWFTqwgBKP ybvfHbMkolWFvYkYYrl4dQQ/koS2kc8GgFoAYNc/qb6P2dZNPt5ZRA7csMgm1bBk3fjZ gZmQ== X-Received: by 10.70.30.97 with SMTP id r1mr67595019pdh.109.1411955030663; Sun, 28 Sep 2014 18:43:50 -0700 (PDT) Received: from [10.69.49.218] (mobile-166-137-213-165.mycingular.net. [166.137.213.165]) by mx.google.com with ESMTPSA id ps1sm10813229pac.41.2014.09.28.18.43.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Sep 2014 18:43:49 -0700 (PDT) References: <20140928071641.M7664@beckpeccoz.com> <761DF16E-5383-46BA-B886-CD3358D976AA@gmail.com> <20140929002025.M8991@aoek.com> Mime-Version: 1.0 (1.0) In-Reply-To: <20140929002025.M8991@aoek.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <82981B04-42EF-4F06-A01D-5465D91C2B86@gmail.com> X-Mailer: iPhone Mail (11D257) From: Garrett Cooper Subject: Re: What do you use for kernel debugging? Date: Sun, 28 Sep 2014 18:43:45 -0700 To: =?utf-8?Q?Jos=C3=A9_P=C3=A9rez_Arauzo?= Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 01:43:51 -0000 > On Sep 28, 2014, at 17:31, "Jos=C3=A9 P=C3=A9rez Arauzo" wr= ote: >=20 > Hi Garrett, >=20 > On Sun, 28 Sep 2014 13:38:24 -0700, Garrett Cooper wrote >> On Sep 28, 2014, at 0:34, Jos=C3=A9 P=C3=A9rez Arauzo wrot= e: >>=20 >>> 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. >>>=20 >>> I get stuck on apic_isr looping which leads nowhere. >>>=20 >>> So I thought maybe things improve if I debug from another machine. >>>=20 >>>=20 >>> What do you use for kernel debugging? According to the handbook kgdb ove= r > 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? >>>=20 >>> I have no old-style uarts hardware anymore, as the handbook suggests... >>>=20 >>> Any idea is welcome before I buy extra hw. I have a USB to serial showin= g > up as >>> /dev/cuaU0, do I need to grab another one and a nullmodem cable or there= > are better >>> alternatives? Thank you. >>=20 >> There was some discussion recently about this on an internal list.=20 >> Unfortunately no, there isn=E2=80=99t a usable way, but there were some=20= >> interesting viable methods that came up (which haven=E2=80=99t been=20 >> implemented): ethernet/sound/xHCI. >>=20 >> Your best bet, as others have noted, is to use boot -d, use WITNESS=20 >> to spot locking issues, dtrace to isolate which section of code=20 >> there are problems, and finally use one of the DEBUG options noted=20 >> in /sys/conf/NOTES and /sys//conf/NOTES . >>=20 >> Hope that helps! >=20 > Well, it's not so encouraging but I'll work on it. >=20 > 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 virtua= l 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 ha= ve to look up =20 > 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 othe= r things I did to get the system up and going: - Built a stripped down kernel that just contains the essential bits (CPU, f= ilesystem, storage). - built one kernel with debug bits and one with release bits (titled them di= fferently 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 suspe= nd/resume wise. It might help you isolate which drivers or subsystems are ca= using boot issues as well (at least netbook system boot is relatively quick c= ompared to the other systems I boot off of with gobs of ram and storage driv= es...). HTH! -Garrett=