From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 21 19:23:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35F2F709 for ; Mon, 21 Jul 2014 19:23:01 +0000 (UTC) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (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 EC4C72A27 for ; Mon, 21 Jul 2014 19:23:00 +0000 (UTC) Received: by mail-vc0-f169.google.com with SMTP id hu12so13074348vcb.0 for ; Mon, 21 Jul 2014 12:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=MtP6u/ZdLeD8M2lazNyuuSXvzsxUsUmV0eYLt4a6RKs=; b=eoQoEqnslVNz5w47gLxKGFGwvhCWfCAUNjBSndlrb+1ZGfCKotmVidZwDNQbdwoKzs EyWg3nogJvekkjdromQfj2C0RYpyrQeClYK3iyQbmShoIicd2BxEwSGF25+7J44ucghS 3EBw3NV1fN1JtylDl1pA2BWkOsuPdQIaKh8Sz+UrSTbBz/CFEFaZMFI9dtYn6SCPYMyo HOzVtH6KYwdhgvBILet+xEK+X2zAhSjr3dw+MSBEXaBrWoqKGM+OyTZO6gXwBVdyTpL3 cl6Y49tJBqA8OfFSDJ2b6/aET0w9oygecDsE5kW7GHHp7aWPrrG2bl8GRSnVbRB6CoCk kbrQ== MIME-Version: 1.0 X-Received: by 10.52.7.163 with SMTP id k3mr17457612vda.58.1405970579057; Mon, 21 Jul 2014 12:22:59 -0700 (PDT) Received: by 10.220.20.74 with HTTP; Mon, 21 Jul 2014 12:22:59 -0700 (PDT) Date: Mon, 21 Jul 2014 12:22:59 -0700 Message-ID: Subject: Remote kernel debugging question From: Nidal Khalil To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 19:23:01 -0000 Hello All, I am somewhat new to BSD kernel but I am trying to debug a kernel module using remote debugging. I am using 9.2 RELEASE. I setup and compiled the kernel with the following: makeoptions DEBUG=-g options KDB options KDB_TRACE options DDB_CTF options DDB options GDB options ALT_BREAK_TO_DEBUGGER I setup the uart for serial1 flags to 0x90 and I can read and write to the serial from either machine Both machines have the same kernel booted. I can enter ddb but I can not launch gdb The remote GDB backend could not be selected. sysctl -a | grep debug.kdb debug.kdb.available: ddb Is that correct or it should be: debug.kdb.available: ddb gdb How do I enable gdb backend. I appreciate the help. Nidal From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 21 21:56:03 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C52BC72 for ; Mon, 21 Jul 2014 21:56:03 +0000 (UTC) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F096E28D0 for ; Mon, 21 Jul 2014 21:56:02 +0000 (UTC) X-AuditID: 12074423-f79bf6d000007580-d6-53cd8c6a4a71 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 74.EB.30080.A6C8DC35; Mon, 21 Jul 2014 17:55:54 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s6LLts17015626; Mon, 21 Jul 2014 17:55:54 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6LLtqIP023713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 21 Jul 2014 17:55:53 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s6LLtpdi020103; Mon, 21 Jul 2014 17:55:51 -0400 (EDT) Date: Mon, 21 Jul 2014 17:55:51 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: Nidal Khalil Subject: Re: Remote kernel debugging question In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixG6nrpvVczbYYNdUA4vtm/8xWjx6foLR gcljxqf5LB47Z91lD2CK4rJJSc3JLEst0rdL4Mq48/s5S8EpzopP3QUNjLPYuxg5OSQETCR2 LV3ICGGLSVy4t56ti5GLQ0hgNpPE0pbtTBDORkaJU6t3sUM4h5gklq94zwzhNDBKLLs8hQWk n0VAW+L0m2usIDabgJrE473NrBBzFSU2n5oE1MDBISKgIvF2ej5ImFlAXuLC5kNgq4UFdCXW dk0AK+cUCJTonLeZDcTmFXCUePKtA2y8kECARPvy7cwgtqiAjsTq/RBreQUEJU7OfMICMdNS 4tyf62wTGIVmIUnNQpJawMi0ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdMLzezRC81pXQTIziA XZR3MP45qHSIUYCDUYmH10L+bLAQa2JZcWXuIUZJDiYlUd6mTqAQX1J+SmVGYnFGfFFpTmrx IUYJDmYlEd4vzUA53pTEyqrUonyYlDQHi5I471trq2AhgfTEktTs1NSC1CKYrAwHh5IEr1E3 UKNgUWp6akVaZk4JQpqJgxNkOA/QcD+QGt7igsTc4sx0iPwpRkUpcV6/LqCEAEgiozQPrheW YF4xigO9IsybD9LOA0xOcN2vgAYzAQ0uyjwNMrgkESEl1cDYwefG917ptdfN7pKHm96vWqBj ZfGSu6I1/VuBf8Prw8VnuX9mMeX+qluc7tOl0zN9dmGAOLvH+8u/FhuUiwb7RYeaZwedmP24 XkL9joHqrOeaK/54JeaZOnAtPrbW0iz6l9COUyGHIvhulX3JY9lktvZ0cq0fR+7RQEHX6g2P H0saH3j5u1OJpTgj0VCLuag4EQDEmKJPCwMAAA== Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 21:56:03 -0000 On Mon, 21 Jul 2014, Nidal Khalil wrote: > Hello All, > I am somewhat new to BSD kernel but I am trying to debug a kernel module > using remote debugging. > I am using 9.2 RELEASE. > I setup and compiled the kernel with the following: > > makeoptions DEBUG=-g > options KDB > options KDB_TRACE > options DDB_CTF > options DDB > options GDB > options ALT_BREAK_TO_DEBUGGER > > I setup the uart for serial1 flags to 0x90 and I can read and write to the > serial from either machine > Both machines have the same kernel booted. > I can enter ddb but I can not launch gdb > The remote GDB backend could not be selected. > sysctl -a | grep debug.kdb > > debug.kdb.available: ddb > Is that correct or it should be: > debug.kdb.available: ddb gdb > How do I enable gdb backend. I appreciate the help. I do not think I have actually used remote GDB kernel debugging on my own machines, but I wanted to make sure that you had seen the documentation for doing so, available at http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-gdb.html . If it is incorrect, we should update it to be correct. Thanks, Ben Kaduk From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 21 21:58:26 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4270BE52; Mon, 21 Jul 2014 21:58:26 +0000 (UTC) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (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 E40EB28F1; Mon, 21 Jul 2014 21:58:25 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id lf12so13181713vcb.12 for ; Mon, 21 Jul 2014 14:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R3dNuaCtpZ5oKp/hmIPR5Czkq7qMbKa7rHX/gmOl5vY=; b=f8KQ6YYUwRwx/V9wCuEtlGfOQ3lsXNPOx7+SgdoeR0cPKZps4p3o5yMwzZmTDlfuH3 jn1w2mgxIlrfM2pJXmbOY3upBKMD8PZbfT4UQmuhq92Y2hyibUE82PgZf17DSGcv4Vg9 AEXTNYsGZ4wuf/0iGYiEP57KYlHtFm9Tgl0BCXu25oPBrmOuQ8tdxikTcnyguO2qrn0j Bz3UXHW4Mt+i2x4uxJ/H43J6pu8t58V0LR5Z/AVD8ekyEb3zYu8r4i/gZ6ShG5ORP7if v+yEyBjURhYMG9VgjxKt2ls+fydrh0SjEXYEtzfguo6W9+gWuTiOab106aFCa7BRxodW JA9Q== MIME-Version: 1.0 X-Received: by 10.52.239.6 with SMTP id vo6mr13661096vdc.59.1405979904889; Mon, 21 Jul 2014 14:58:24 -0700 (PDT) Received: by 10.220.20.74 with HTTP; Mon, 21 Jul 2014 14:58:24 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Jul 2014 14:58:24 -0700 Message-ID: Subject: Re: Remote kernel debugging question From: Nidal Khalil To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 21:58:26 -0000 Hi Ben, Yes I am familiar with the doc. As On Mon, Jul 21, 2014 at 2:55 PM, Benjamin Kaduk wrote: > On Mon, 21 Jul 2014, Nidal Khalil wrote: > > Hello All, >> I am somewhat new to BSD kernel but I am trying to debug a kernel module >> using remote debugging. >> I am using 9.2 RELEASE. >> I setup and compiled the kernel with the following: >> >> makeoptions DEBUG=-g >> options KDB >> options KDB_TRACE >> options DDB_CTF >> options DDB >> options GDB >> options ALT_BREAK_TO_DEBUGGER >> >> I setup the uart for serial1 flags to 0x90 and I can read and write to the >> serial from either machine >> Both machines have the same kernel booted. >> I can enter ddb but I can not launch gdb >> The remote GDB backend could not be selected. >> sysctl -a | grep debug.kdb >> >> debug.kdb.available: ddb >> Is that correct or it should be: >> debug.kdb.available: ddb gdb >> How do I enable gdb backend. I appreciate the help. >> > > I do not think I have actually used remote GDB kernel debugging on my own > machines, but I wanted to make sure that you had seen the documentation for > doing so, available at http://www.freebsd.org/doc/en/ > books/developers-handbook/kerneldebug-online-gdb.html . If it is > incorrect, we should update it to be correct. > > Thanks, > > Ben Kaduk > From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 21 22:22:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E979F15 for ; Mon, 21 Jul 2014 22:22:35 +0000 (UTC) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (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 F1DA92B62 for ; Mon, 21 Jul 2014 22:22:34 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id hz1so10559399pad.22 for ; Mon, 21 Jul 2014 15:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=zAw/KrLPyWnkc1RCU6wI3xJKgqOmUpZzFJoan35w8yM=; b=G6zwVtzuQb4GLlx12kIpAsEAnLhkQJMz65xs+vJdKwRCSVrZvU7oSOHcn061nfnPwe uXyOmIU1NlxY1PXABtedH+ozbMbHHDYKACyIfl8cW+Kd/JhVZhBfhiAmYJU8eNES1Q0/ EHNNNSGVC/gqkvlM69hnZcZE3CwoWDlMQ8oFX5DCbIpV27vFEiX6dOK1e3haL3Y9WOO3 TAGihN0f1Sv2pJ9aJmw+lwuigVjIJDb0mZbjw/WYJ4+/+r+ct5+fDXDsQnfkCTCnOQqM SqZ+Ccr8z8r/wYDN69VayW+3iu++HERB4lZhKYscEPhqpfftX4E9wt9g9ygqETksneLi jPyQ== X-Received: by 10.70.88.75 with SMTP id be11mr6942318pdb.140.1405981354374; Mon, 21 Jul 2014 15:22:34 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPSA id an15sm62140301pac.6.2014.07.21.15.22.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 15:22:33 -0700 (PDT) Message-ID: <53CD92A8.5000201@gmail.com> Date: Mon, 21 Jul 2014 15:22:32 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nidal Khalil , freebsd-hackers@freebsd.org Subject: Re: Remote kernel debugging question References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 22:22:35 -0000 On 07/21/14 12:22, Nidal Khalil wrote: > Hello All, > I am somewhat new to BSD kernel but I am trying to debug a kernel module > using remote debugging. > I am using 9.2 RELEASE. > I setup and compiled the kernel with the following: > > makeoptions DEBUG=-g > options KDB > options KDB_TRACE > options DDB_CTF > options DDB > options GDB > options ALT_BREAK_TO_DEBUGGER > > I setup the uart for serial1 flags to 0x90 and I can read and write to the > serial from either machine > Both machines have the same kernel booted. > I can enter ddb but I can not launch gdb > The remote GDB backend could not be selected. > sysctl -a | grep debug.kdb > > debug.kdb.available: ddb > Is that correct or it should be: > debug.kdb.available: ddb gdb The latter. > How do I enable gdb backend. I appreciate the help. All this on a recent HEAD. If your problem is 9.2 specific then this may not help, but at least we can compare notes. You did say you set flags to 0x90 for your serial port but it's not clear how. I have this in /boot/loader.conf: hint.uart.0.flags="0x90" When the system boots I see this right around when loader hands off to the kernel. GDB: debug ports: uart GDB: current port: uart KDB: debugger backends: ddb gdb KDB: current backend: ddb Copyright (c) 1992-2014 The FreeBSD Project. ... After the system boots I see both ddb and gdb in the available debug backends and all is well. # sysctl debug.kdb.available debug.kdb.available: ddb gdb # sysctl debug.kdb.current debug.kdb.current: ddb # sysctl debug.kdb.current=gdb debug.kdb.current: ddb -> gdb # sysctl debug.kdb.current debug.kdb.current: gdb Regards, Navdeep From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 21 22:35:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 627D2318 for ; Mon, 21 Jul 2014 22:35:02 +0000 (UTC) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (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 2175E2C4C for ; Mon, 21 Jul 2014 22:35:02 +0000 (UTC) Received: by mail-vc0-f171.google.com with SMTP id hq11so11937569vcb.30 for ; Mon, 21 Jul 2014 15:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hAVCzwPJP3MbqzGFvI6+dKrV54KYz0gWejbl0oFwMBI=; b=IGM8AIXrqnVyJhLLd07zj5jmzKIHH2ZIiELlOBZjTO9CjUHfkXJetzmTjJcSZ0hvjf +7qozNyaPGelyHZlCEy64dBwXNdXd8LD5Zrdc4vr3aroBVYvEzyWayi8cIK6DG+G30HP gEd5MdBs6BdiScp2Jn4HtpLKdH7gFpAvC/I2k7tIJ/Pcmd7niKOiBLO/MQ9TOYpvOs/C 0IT43z+sfWZgEECrhg5luYme3Y5Klm8MI6zXA6ZtsfylEi/pgZDowju5uaIQYcXAVsXU YpyjQ1rdNqptjbwGSFLpj+JeE+yrgFowaoyl8f/yNuWUIsIV6oAkS6Sp/j+lhhDhxX8M zOww== MIME-Version: 1.0 X-Received: by 10.52.157.164 with SMTP id wn4mr5966088vdb.81.1405982101290; Mon, 21 Jul 2014 15:35:01 -0700 (PDT) Received: by 10.220.20.74 with HTTP; Mon, 21 Jul 2014 15:35:01 -0700 (PDT) In-Reply-To: <53CD92A8.5000201@gmail.com> References: <53CD92A8.5000201@gmail.com> Date: Mon, 21 Jul 2014 15:35:01 -0700 Message-ID: Subject: Re: Remote kernel debugging question From: Nidal Khalil To: Navdeep Parhar Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 22:35:02 -0000 The documentation states to put hint.uart.0.flags="0x90" in /boot/device.hits However you hit on a good point. I see some parameters in boot/loader.conf. Can you please email this file I think that I need to do more configuration to this file. I will do it by comparison. Thanks Nidal On Mon, Jul 21, 2014 at 3:22 PM, Navdeep Parhar wrote: > On 07/21/14 12:22, Nidal Khalil wrote: > > Hello All, > > I am somewhat new to BSD kernel but I am trying to debug a kernel module > > using remote debugging. > > I am using 9.2 RELEASE. > > I setup and compiled the kernel with the following: > > > > makeoptions DEBUG=-g > > options KDB > > options KDB_TRACE > > options DDB_CTF > > options DDB > > options GDB > > options ALT_BREAK_TO_DEBUGGER > > > > I setup the uart for serial1 flags to 0x90 and I can read and write to > the > > serial from either machine > > Both machines have the same kernel booted. > > I can enter ddb but I can not launch gdb > > The remote GDB backend could not be selected. > > sysctl -a | grep debug.kdb > > > > debug.kdb.available: ddb > > Is that correct or it should be: > > debug.kdb.available: ddb gdb > > The latter. > > > How do I enable gdb backend. I appreciate the help. > > All this on a recent HEAD. If your problem is 9.2 specific then this > may not help, but at least we can compare notes. You did say you set > flags to 0x90 for your serial port but it's not clear how. I have this > in /boot/loader.conf: > hint.uart.0.flags="0x90" > > When the system boots I see this right around when loader hands off to > the kernel. > > GDB: debug ports: uart > GDB: current port: uart > KDB: debugger backends: ddb gdb > KDB: current backend: ddb > Copyright (c) 1992-2014 The FreeBSD Project. > ... > > After the system boots I see both ddb and gdb in the available debug > backends and all is well. > > # sysctl debug.kdb.available > debug.kdb.available: ddb gdb > # sysctl debug.kdb.current > debug.kdb.current: ddb > # sysctl debug.kdb.current=gdb > debug.kdb.current: ddb -> gdb > # sysctl debug.kdb.current > debug.kdb.current: gdb > > Regards, > Navdeep > From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 21 22:40:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72D4464B for ; Mon, 21 Jul 2014 22:40:11 +0000 (UTC) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (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 45A222C74 for ; Mon, 21 Jul 2014 22:40:11 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id bj1so10677676pad.11 for ; Mon, 21 Jul 2014 15:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=HG0p4RcadAa/fQyLIhTZtzqmG4ESZ35z5WfEj32fGYg=; b=Bpu9H8Gb7viRP2wXWyGaiqrR6L7Mk9sjEayLnXDQ2TZMJ2BaUBAjAwA7YNjJm6mPM5 4yiS5klVf2UqypNsMB2/Au2euaqm1FvOEZlds+CPla/Jx1ssxLOdutAgtTVQV+JteEQT zWv4eMJEO3P4RKI3IgDj+r5LRISaVUf+3cOvn7M5sRfqhHJJEn8jnCi9SWAV101eveob 3DgVo4io+tg6J59REY3emDZIjnslyLyv7tOE9HEUNC/WU14JtdzFMadyKKkcOcntQGbH SAYP2hbyFqbrZOfs1TR7ijBf+GZuZH+VL0CDBZn4z9pIR2H9+PA45qgA7fog5+es1i7i 27eQ== X-Received: by 10.68.252.7 with SMTP id zo7mr17717971pbc.102.1405982410917; Mon, 21 Jul 2014 15:40:10 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPSA id kk3sm6405035pbc.51.2014.07.21.15.40.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 15:40:10 -0700 (PDT) Message-ID: <53CD96C9.2010600@gmail.com> Date: Mon, 21 Jul 2014 15:40:09 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nidal Khalil Subject: Re: Remote kernel debugging question References: <53CD92A8.5000201@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 22:40:11 -0000 On 07/21/14 15:35, Nidal Khalil wrote: > The documentation states to put hint.uart.0.flags="0x90" in > /boot/device.hits Putting it in device.hints should have worked too. In fact, that's where uart(4) has it. You haven't spelled it "hits" on your filesystem like you did here, have you? > However you hit on a good point. I see some parameters in > boot/loader.conf. Can you please email this file > I think that I need to do more configuration to this file. I will do it > by comparison. Thanks That's all there was in the file. Regards, Navdeep > > Nidal > > > On Mon, Jul 21, 2014 at 3:22 PM, Navdeep Parhar > wrote: > > On 07/21/14 12:22, Nidal Khalil wrote: > > Hello All, > > I am somewhat new to BSD kernel but I am trying to debug a kernel > module > > using remote debugging. > > I am using 9.2 RELEASE. > > I setup and compiled the kernel with the following: > > > > makeoptions DEBUG=-g > > options KDB > > options KDB_TRACE > > options DDB_CTF > > options DDB > > options GDB > > options ALT_BREAK_TO_DEBUGGER > > > > I setup the uart for serial1 flags to 0x90 and I can read and > write to the > > serial from either machine > > Both machines have the same kernel booted. > > I can enter ddb but I can not launch gdb > > The remote GDB backend could not be selected. > > sysctl -a | grep debug.kdb > > > > debug.kdb.available: ddb > > Is that correct or it should be: > > debug.kdb.available: ddb gdb > > The latter. > > > How do I enable gdb backend. I appreciate the help. > > All this on a recent HEAD. If your problem is 9.2 specific then this > may not help, but at least we can compare notes. You did say you set > flags to 0x90 for your serial port but it's not clear how. I have this > in /boot/loader.conf: > hint.uart.0.flags="0x90" > > When the system boots I see this right around when loader hands off to > the kernel. > > GDB: debug ports: uart > GDB: current port: uart > KDB: debugger backends: ddb gdb > KDB: current backend: ddb > Copyright (c) 1992-2014 The FreeBSD Project. > ... > > After the system boots I see both ddb and gdb in the available debug > backends and all is well. > > # sysctl debug.kdb.available > debug.kdb.available: ddb gdb > # sysctl debug.kdb.current > debug.kdb.current: ddb > # sysctl debug.kdb.current=gdb > debug.kdb.current: ddb -> gdb > # sysctl debug.kdb.current > debug.kdb.current: gdb > > Regards, > Navdeep > > From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 21 22:44:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E764887A for ; Mon, 21 Jul 2014 22:44:24 +0000 (UTC) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (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 A43F52CFB for ; Mon, 21 Jul 2014 22:44:24 +0000 (UTC) Received: by mail-vc0-f170.google.com with SMTP id lf12so13373847vcb.29 for ; Mon, 21 Jul 2014 15:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FncwdxD+ujtI/UwAEt3B06EPDlMHqllKnEhwN+P92xY=; b=GhC21IhEspR7GiLTMnottM/e15gBMuYsPq189osAPnZ5MFgAtUfJiNOlPma3BxjJFO vNWdqtql0xvcNrvzUDe2x50GOHwe0LMMNq6Ync7N7wJ96Irf8fvZGrFOa4Jcpp0qtrZN rUApAdpKNhqullc5SQ3e8Ms6ZqXpc0n2M/ZzQ7cCD5kDQFvai/oLQbd6/LncNxxygi5W RamkZB/l0MFVm2yTHTXfgfb3UYDdYQIK8h+XFgR3bFirfn+hXDYPLdO4RFVxlE4N/qgE XLOMr9++KGdeI1QVVbKE4UcxbbJficteAzwCDgJ8dBwZcTQcrPSWS1/iXsmddCsvthou rHWw== MIME-Version: 1.0 X-Received: by 10.52.138.7 with SMTP id qm7mr29090329vdb.7.1405982663666; Mon, 21 Jul 2014 15:44:23 -0700 (PDT) Received: by 10.220.20.74 with HTTP; Mon, 21 Jul 2014 15:44:23 -0700 (PDT) In-Reply-To: <53CD96C9.2010600@gmail.com> References: <53CD92A8.5000201@gmail.com> <53CD96C9.2010600@gmail.com> Date: Mon, 21 Jul 2014 15:44:23 -0700 Message-ID: Subject: Re: Remote kernel debugging question From: Nidal Khalil To: Navdeep Parhar Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 22:44:25 -0000 No, I have not . It is hint.uart.0.flags="0x90" Thanks My question is how do I get gdb to show up as part of available debuggers in this node: debug.kdb.available: ddb Thanks Nidal On Mon, Jul 21, 2014 at 3:40 PM, Navdeep Parhar wrote: > On 07/21/14 15:35, Nidal Khalil wrote: > > The documentation states to put hint.uart.0.flags="0x90" in > > /boot/device.hits > > Putting it in device.hints should have worked too. In fact, that's > where uart(4) has it. You haven't spelled it "hits" on your filesystem > like you did here, have you? > > > However you hit on a good point. I see some parameters in > > boot/loader.conf. Can you please email this file > > I think that I need to do more configuration to this file. I will do it > > by comparison. Thanks > > That's all there was in the file. > > Regards, > Navdeep > > > > > Nidal > > > > > > On Mon, Jul 21, 2014 at 3:22 PM, Navdeep Parhar > > wrote: > > > > On 07/21/14 12:22, Nidal Khalil wrote: > > > Hello All, > > > I am somewhat new to BSD kernel but I am trying to debug a kernel > > module > > > using remote debugging. > > > I am using 9.2 RELEASE. > > > I setup and compiled the kernel with the following: > > > > > > makeoptions DEBUG=-g > > > options KDB > > > options KDB_TRACE > > > options DDB_CTF > > > options DDB > > > options GDB > > > options ALT_BREAK_TO_DEBUGGER > > > > > > I setup the uart for serial1 flags to 0x90 and I can read and > > write to the > > > serial from either machine > > > Both machines have the same kernel booted. > > > I can enter ddb but I can not launch gdb > > > The remote GDB backend could not be selected. > > > sysctl -a | grep debug.kdb > > > > > > debug.kdb.available: ddb > > > Is that correct or it should be: > > > debug.kdb.available: ddb gdb > > > > The latter. > > > > > How do I enable gdb backend. I appreciate the help. > > > > All this on a recent HEAD. If your problem is 9.2 specific then this > > may not help, but at least we can compare notes. You did say you set > > flags to 0x90 for your serial port but it's not clear how. I have > this > > in /boot/loader.conf: > > hint.uart.0.flags="0x90" > > > > When the system boots I see this right around when loader hands off > to > > the kernel. > > > > GDB: debug ports: uart > > GDB: current port: uart > > KDB: debugger backends: ddb gdb > > KDB: current backend: ddb > > Copyright (c) 1992-2014 The FreeBSD Project. > > ... > > > > After the system boots I see both ddb and gdb in the available debug > > backends and all is well. > > > > # sysctl debug.kdb.available > > debug.kdb.available: ddb gdb > > # sysctl debug.kdb.current > > debug.kdb.current: ddb > > # sysctl debug.kdb.current=gdb > > debug.kdb.current: ddb -> gdb > > # sysctl debug.kdb.current > > debug.kdb.current: gdb > > > > Regards, > > Navdeep > > > > > > From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 22 17:32:18 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 331FFD43 for ; Tue, 22 Jul 2014 17:32:18 +0000 (UTC) Received: from natasha.panasas.com (natasha.panasas.com [209.166.131.148]) by mx1.freebsd.org (Postfix) with ESMTP id D43752F87 for ; Tue, 22 Jul 2014 17:32:17 +0000 (UTC) Received: from seabiscuit.panasas.com (seabiscuit.panasas.com [172.17.132.204]) by natasha.panasas.com (8.13.1/8.13.1) with ESMTP id s6MHFnRn020919 for ; Tue, 22 Jul 2014 13:15:50 -0400 Received: from SEABISCUIT.int.panasas.com ([172.17.132.204]) by seabiscuit ([172.17.132.204]) with mapi id 14.03.0181.006; Tue, 22 Jul 2014 10:15:49 -0700 From: "Pokala, Ravi" To: "freebsd-hackers@freebsd.org" Subject: Re: Remote kernel debugging question Thread-Topic: Remote kernel debugging question Thread-Index: AQHPpdCVfurLj9uZVUaY1ceLGE0WUA== Date: Tue, 22 Jul 2014 17:15:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [172.17.28.63] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 17:32:18 -0000 > hint.uart.0.flags=3D"0x90" Is this an i386 or amd64 system? If so, shouldn't it be sio(4) rather than uart(4)? I thought uart(4) only became the default serial port driver for i386/amd64 as part of 10. -Ravi From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 22 21:06:40 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9BDED36D for ; Tue, 22 Jul 2014 21:06:40 +0000 (UTC) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::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 4B5AA2643 for ; Tue, 22 Jul 2014 21:06:40 +0000 (UTC) Received: by mail-vc0-f176.google.com with SMTP id id10so483723vcb.21 for ; Tue, 22 Jul 2014 14:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=NHxtZ0AI1VJLWdv/pdhgrRRT3oFE8rnNt6fRRetqdio=; b=KB73aPMx+9bBXqqT9ndJlB46zUvzgwvjMFrDGSujtBDFGXXxySl8rr2nJT5VBeeRsy rwco7fDBUpsHePh/DfyhOcY3G94l3DKnMsaqFebkwz3jGWTPzMMo6uVy1WxUNRdreSQ5 QvAw48UGjBdiorPxpAUSOPiLw8zgobS72QyQq7ffx9E9UQLvGykHMeFP52viKyLtT7J8 /J6h963MbcCxozb7Pd4yJAdF5xu1WYvNGGTTPLO8eBCDHj3gukeQBeAjB4efb/Yvqgg8 zHmay2tkXJ5jYjnhxmsJY+uvYdGiHNM1uq19zSWcNZETquJGSslZVwGLjgaHpKqNBQI3 6F3w== MIME-Version: 1.0 X-Received: by 10.52.138.7 with SMTP id qm7mr37967132vdb.7.1406063199383; Tue, 22 Jul 2014 14:06:39 -0700 (PDT) Received: by 10.220.20.74 with HTTP; Tue, 22 Jul 2014 14:06:39 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Jul 2014 14:06:39 -0700 Message-ID: Subject: Re: freebsd-hackers Digest, Vol 588, Issue 1 From: Nidal Khalil To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 21:06:40 -0000 Still no go On Tue, Jul 22, 2014 at 5:00 AM, wrote: > Send freebsd-hackers mailing list submissions to > freebsd-hackers@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > or, via email, send a message with subject or body 'help' to > freebsd-hackers-request@freebsd.org > > You can reach the person managing the list at > freebsd-hackers-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-hackers digest..." > > > Today's Topics: > > 1. Remote kernel debugging question (Nidal Khalil) > 2. Re: Remote kernel debugging question (Benjamin Kaduk) > 3. Re: Remote kernel debugging question (Nidal Khalil) > 4. Re: Remote kernel debugging question (Navdeep Parhar) > 5. Re: Remote kernel debugging question (Nidal Khalil) > 6. Re: Remote kernel debugging question (Navdeep Parhar) > 7. Re: Remote kernel debugging question (Nidal Khalil) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 21 Jul 2014 12:22:59 -0700 > From: Nidal Khalil > To: freebsd-hackers@freebsd.org > Subject: Remote kernel debugging question > Message-ID: > < > CADoY-6j0d9pBn-TDoMf5gysE8QiGz42DCFGLDWASig-wqLiMbg@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hello All, > I am somewhat new to BSD kernel but I am trying to debug a kernel module > using remote debugging. > I am using 9.2 RELEASE. > I setup and compiled the kernel with the following: > > makeoptions DEBUG=-g > options KDB > options KDB_TRACE > options DDB_CTF > options DDB > options GDB > options ALT_BREAK_TO_DEBUGGER > > I setup the uart for serial1 flags to 0x90 and I can read and write to the > serial from either machine > Both machines have the same kernel booted. > I can enter ddb but I can not launch gdb > The remote GDB backend could not be selected. > sysctl -a | grep debug.kdb > > debug.kdb.available: ddb > Is that correct or it should be: > debug.kdb.available: ddb gdb > How do I enable gdb backend. I appreciate the help. > > Nidal > > > ------------------------------ > > Message: 2 > Date: Mon, 21 Jul 2014 17:55:51 -0400 (EDT) > From: Benjamin Kaduk > To: Nidal Khalil > Cc: freebsd-hackers@freebsd.org > Subject: Re: Remote kernel debugging question > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Mon, 21 Jul 2014, Nidal Khalil wrote: > > > Hello All, > > I am somewhat new to BSD kernel but I am trying to debug a kernel module > > using remote debugging. > > I am using 9.2 RELEASE. > > I setup and compiled the kernel with the following: > > > > makeoptions DEBUG=-g > > options KDB > > options KDB_TRACE > > options DDB_CTF > > options DDB > > options GDB > > options ALT_BREAK_TO_DEBUGGER > > > > I setup the uart for serial1 flags to 0x90 and I can read and write to > the > > serial from either machine > > Both machines have the same kernel booted. > > I can enter ddb but I can not launch gdb > > The remote GDB backend could not be selected. > > sysctl -a | grep debug.kdb > > > > debug.kdb.available: ddb > > Is that correct or it should be: > > debug.kdb.available: ddb gdb > > How do I enable gdb backend. I appreciate the help. > > I do not think I have actually used remote GDB kernel debugging on my own > machines, but I wanted to make sure that you had seen the documentation > for doing so, available at > > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-gdb.html > . If it is incorrect, we should update it to be correct. > > Thanks, > > Ben Kaduk > > > ------------------------------ > > Message: 3 > Date: Mon, 21 Jul 2014 14:58:24 -0700 > From: Nidal Khalil > To: Benjamin Kaduk > Cc: freebsd-hackers@freebsd.org > Subject: Re: Remote kernel debugging question > Message-ID: > < > CADoY-6hcD6ACwFVgX-LJ2cXHL35-bO+F8NYZ69vf3VDpg0DAAA@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi Ben, > Yes I am familiar with the doc. As > > > On Mon, Jul 21, 2014 at 2:55 PM, Benjamin Kaduk wrote: > > > On Mon, 21 Jul 2014, Nidal Khalil wrote: > > > > Hello All, > >> I am somewhat new to BSD kernel but I am trying to debug a kernel module > >> using remote debugging. > >> I am using 9.2 RELEASE. > >> I setup and compiled the kernel with the following: > >> > >> makeoptions DEBUG=-g > >> options KDB > >> options KDB_TRACE > >> options DDB_CTF > >> options DDB > >> options GDB > >> options ALT_BREAK_TO_DEBUGGER > >> > >> I setup the uart for serial1 flags to 0x90 and I can read and write to > the > >> serial from either machine > >> Both machines have the same kernel booted. > >> I can enter ddb but I can not launch gdb > >> The remote GDB backend could not be selected. > >> sysctl -a | grep debug.kdb > >> > >> debug.kdb.available: ddb > >> Is that correct or it should be: > >> debug.kdb.available: ddb gdb > >> How do I enable gdb backend. I appreciate the help. > >> > > > > I do not think I have actually used remote GDB kernel debugging on my own > > machines, but I wanted to make sure that you had seen the documentation > for > > doing so, available at http://www.freebsd.org/doc/en/ > > books/developers-handbook/kerneldebug-online-gdb.html . If it is > > incorrect, we should update it to be correct. > > > > Thanks, > > > > Ben Kaduk > > > > > ------------------------------ > > Message: 4 > Date: Mon, 21 Jul 2014 15:22:32 -0700 > From: Navdeep Parhar > To: Nidal Khalil , freebsd-hackers@freebsd.org > Subject: Re: Remote kernel debugging question > Message-ID: <53CD92A8.5000201@gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 07/21/14 12:22, Nidal Khalil wrote: > > Hello All, > > I am somewhat new to BSD kernel but I am trying to debug a kernel module > > using remote debugging. > > I am using 9.2 RELEASE. > > I setup and compiled the kernel with the following: > > > > makeoptions DEBUG=-g > > options KDB > > options KDB_TRACE > > options DDB_CTF > > options DDB > > options GDB > > options ALT_BREAK_TO_DEBUGGER > > > > I setup the uart for serial1 flags to 0x90 and I can read and write to > the > > serial from either machine > > Both machines have the same kernel booted. > > I can enter ddb but I can not launch gdb > > The remote GDB backend could not be selected. > > sysctl -a | grep debug.kdb > > > > debug.kdb.available: ddb > > Is that correct or it should be: > > debug.kdb.available: ddb gdb > > The latter. > > > How do I enable gdb backend. I appreciate the help. > > All this on a recent HEAD. If your problem is 9.2 specific then this > may not help, but at least we can compare notes. You did say you set > flags to 0x90 for your serial port but it's not clear how. I have this > in /boot/loader.conf: > hint.uart.0.flags="0x90" > > When the system boots I see this right around when loader hands off to > the kernel. > > GDB: debug ports: uart > GDB: current port: uart > KDB: debugger backends: ddb gdb > KDB: current backend: ddb > Copyright (c) 1992-2014 The FreeBSD Project. > ... > > After the system boots I see both ddb and gdb in the available debug > backends and all is well. > > # sysctl debug.kdb.available > debug.kdb.available: ddb gdb > # sysctl debug.kdb.current > debug.kdb.current: ddb > # sysctl debug.kdb.current=gdb > debug.kdb.current: ddb -> gdb > # sysctl debug.kdb.current > debug.kdb.current: gdb > > Regards, > Navdeep > > > ------------------------------ > > Message: 5 > Date: Mon, 21 Jul 2014 15:35:01 -0700 > From: Nidal Khalil > To: Navdeep Parhar > Cc: freebsd-hackers@freebsd.org > Subject: Re: Remote kernel debugging question > Message-ID: > < > CADoY-6hPgy8e7ETt2bFM27P--PJTjSTX0e9+bo3aVE4UyweYEw@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > The documentation states to put hint.uart.0.flags="0x90" in > /boot/device.hits > However you hit on a good point. I see some parameters in boot/loader.conf. > Can you please email this file > I think that I need to do more configuration to this file. I will do it by > comparison. Thanks > > Nidal > > > On Mon, Jul 21, 2014 at 3:22 PM, Navdeep Parhar wrote: > > > On 07/21/14 12:22, Nidal Khalil wrote: > > > Hello All, > > > I am somewhat new to BSD kernel but I am trying to debug a kernel > module > > > using remote debugging. > > > I am using 9.2 RELEASE. > > > I setup and compiled the kernel with the following: > > > > > > makeoptions DEBUG=-g > > > options KDB > > > options KDB_TRACE > > > options DDB_CTF > > > options DDB > > > options GDB > > > options ALT_BREAK_TO_DEBUGGER > > > > > > I setup the uart for serial1 flags to 0x90 and I can read and write to > > the > > > serial from either machine > > > Both machines have the same kernel booted. > > > I can enter ddb but I can not launch gdb > > > The remote GDB backend could not be selected. > > > sysctl -a | grep debug.kdb > > > > > > debug.kdb.available: ddb > > > Is that correct or it should be: > > > debug.kdb.available: ddb gdb > > > > The latter. > > > > > How do I enable gdb backend. I appreciate the help. > > > > All this on a recent HEAD. If your problem is 9.2 specific then this > > may not help, but at least we can compare notes. You did say you set > > flags to 0x90 for your serial port but it's not clear how. I have this > > in /boot/loader.conf: > > hint.uart.0.flags="0x90" > > > > When the system boots I see this right around when loader hands off to > > the kernel. > > > > GDB: debug ports: uart > > GDB: current port: uart > > KDB: debugger backends: ddb gdb > > KDB: current backend: ddb > > Copyright (c) 1992-2014 The FreeBSD Project. > > ... > > > > After the system boots I see both ddb and gdb in the available debug > > backends and all is well. > > > > # sysctl debug.kdb.available > > debug.kdb.available: ddb gdb > > # sysctl debug.kdb.current > > debug.kdb.current: ddb > > # sysctl debug.kdb.current=gdb > > debug.kdb.current: ddb -> gdb > > # sysctl debug.kdb.current > > debug.kdb.current: gdb > > > > Regards, > > Navdeep > > > > > ------------------------------ > > Message: 6 > Date: Mon, 21 Jul 2014 15:40:09 -0700 > From: Navdeep Parhar > To: Nidal Khalil > Cc: freebsd-hackers@freebsd.org > Subject: Re: Remote kernel debugging question > Message-ID: <53CD96C9.2010600@gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 07/21/14 15:35, Nidal Khalil wrote: > > The documentation states to put hint.uart.0.flags="0x90" in > > /boot/device.hits > > Putting it in device.hints should have worked too. In fact, that's > where uart(4) has it. You haven't spelled it "hits" on your filesystem > like you did here, have you? > > > However you hit on a good point. I see some parameters in > > boot/loader.conf. Can you please email this file > > I think that I need to do more configuration to this file. I will do it > > by comparison. Thanks > > That's all there was in the file. > > Regards, > Navdeep > > > > > Nidal > > > > > > On Mon, Jul 21, 2014 at 3:22 PM, Navdeep Parhar > > wrote: > > > > On 07/21/14 12:22, Nidal Khalil wrote: > > > Hello All, > > > I am somewhat new to BSD kernel but I am trying to debug a kernel > > module > > > using remote debugging. > > > I am using 9.2 RELEASE. > > > I setup and compiled the kernel with the following: > > > > > > makeoptions DEBUG=-g > > > options KDB > > > options KDB_TRACE > > > options DDB_CTF > > > options DDB > > > options GDB > > > options ALT_BREAK_TO_DEBUGGER > > > > > > I setup the uart for serial1 flags to 0x90 and I can read and > > write to the > > > serial from either machine > > > Both machines have the same kernel booted. > > > I can enter ddb but I can not launch gdb > > > The remote GDB backend could not be selected. > > > sysctl -a | grep debug.kdb > > > > > > debug.kdb.available: ddb > > > Is that correct or it should be: > > > debug.kdb.available: ddb gdb > > > > The latter. > > > > > How do I enable gdb backend. I appreciate the help. > > > > All this on a recent HEAD. If your problem is 9.2 specific then this > > may not help, but at least we can compare notes. You did say you set > > flags to 0x90 for your serial port but it's not clear how. I have > this > > in /boot/loader.conf: > > hint.uart.0.flags="0x90" > > > > When the system boots I see this right around when loader hands off > to > > the kernel. > > > > GDB: debug ports: uart > > GDB: current port: uart > > KDB: debugger backends: ddb gdb > > KDB: current backend: ddb > > Copyright (c) 1992-2014 The FreeBSD Project. > > ... > > > > After the system boots I see both ddb and gdb in the available debug > > backends and all is well. > > > > # sysctl debug.kdb.available > > debug.kdb.available: ddb gdb > > # sysctl debug.kdb.current > > debug.kdb.current: ddb > > # sysctl debug.kdb.current=gdb > > debug.kdb.current: ddb -> gdb > > # sysctl debug.kdb.current > > debug.kdb.current: gdb > > > > Regards, > > Navdeep > > > > > > > > ------------------------------ > > Message: 7 > Date: Mon, 21 Jul 2014 15:44:23 -0700 > From: Nidal Khalil > To: Navdeep Parhar > Cc: freebsd-hackers@freebsd.org > Subject: Re: Remote kernel debugging question > Message-ID: > < > CADoY-6hJUGOvhQ6qoeP1aYLZ737dgYQGSsik_QF1+qXqcPH1Nw@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > No, I have not . > It is hint.uart.0.flags="0x90" > Thanks > My question is how do I get gdb to show up as part of available debuggers > in this node: > debug.kdb.available: ddb > Thanks > > Nidal > > > On Mon, Jul 21, 2014 at 3:40 PM, Navdeep Parhar wrote: > > > On 07/21/14 15:35, Nidal Khalil wrote: > > > The documentation states to put hint.uart.0.flags="0x90" in > > > /boot/device.hits > > > > Putting it in device.hints should have worked too. In fact, that's > > where uart(4) has it. You haven't spelled it "hits" on your filesystem > > like you did here, have you? > > > > > However you hit on a good point. I see some parameters in > > > boot/loader.conf. Can you please email this file > > > I think that I need to do more configuration to this file. I will do it > > > by comparison. Thanks > > > > That's all there was in the file. > > > > Regards, > > Navdeep > > > > > > > > Nidal > > > > > > > > > On Mon, Jul 21, 2014 at 3:22 PM, Navdeep Parhar > > > wrote: > > > > > > On 07/21/14 12:22, Nidal Khalil wrote: > > > > Hello All, > > > > I am somewhat new to BSD kernel but I am trying to debug a kernel > > > module > > > > using remote debugging. > > > > I am using 9.2 RELEASE. > > > > I setup and compiled the kernel with the following: > > > > > > > > makeoptions DEBUG=-g > > > > options KDB > > > > options KDB_TRACE > > > > options DDB_CTF > > > > options DDB > > > > options GDB > > > > options ALT_BREAK_TO_DEBUGGER > > > > > > > > I setup the uart for serial1 flags to 0x90 and I can read and > > > write to the > > > > serial from either machine > > > > Both machines have the same kernel booted. > > > > I can enter ddb but I can not launch gdb > > > > The remote GDB backend could not be selected. > > > > sysctl -a | grep debug.kdb > > > > > > > > debug.kdb.available: ddb > > > > Is that correct or it should be: > > > > debug.kdb.available: ddb gdb > > > > > > The latter. > > > > > > > How do I enable gdb backend. I appreciate the help. > > > > > > All this on a recent HEAD. If your problem is 9.2 specific then > this > > > may not help, but at least we can compare notes. You did say you > set > > > flags to 0x90 for your serial port but it's not clear how. I have > > this > > > in /boot/loader.conf: > > > hint.uart.0.flags="0x90" > > > > > > When the system boots I see this right around when loader hands off > > to > > > the kernel. > > > > > > GDB: debug ports: uart > > > GDB: current port: uart > > > KDB: debugger backends: ddb gdb > > > KDB: current backend: ddb > > > Copyright (c) 1992-2014 The FreeBSD Project. > > > ... > > > > > > After the system boots I see both ddb and gdb in the available > debug > > > backends and all is well. > > > > > > # sysctl debug.kdb.available > > > debug.kdb.available: ddb gdb > > > # sysctl debug.kdb.current > > > debug.kdb.current: ddb > > > # sysctl debug.kdb.current=gdb > > > debug.kdb.current: ddb -> gdb > > > # sysctl debug.kdb.current > > > debug.kdb.current: gdb > > > > > > Regards, > > > Navdeep > > > > > > > > > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > ------------------------------ > > End of freebsd-hackers Digest, Vol 588, Issue 1 > *********************************************** > From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 22 21:07:11 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4327945D for ; Tue, 22 Jul 2014 21:07:11 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2BC4D2661 for ; Tue, 22 Jul 2014 21:07:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s6ML7AJv019997 for ; Tue, 22 Jul 2014 21:07:10 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s6ML7A8t019996 for hackers@FreeBSD.org; Tue, 22 Jul 2014 21:07:10 GMT (envelope-from bdrewery) Received: (qmail 52133 invoked from network); 22 Jul 2014 16:07:09 -0500 Received: from unknown (HELO blah) (freebsd@shatow.net@67.182.131.225) by sweb.xzibition.com with ESMTPA; 22 Jul 2014 16:07:09 -0500 Message-ID: <53CED27C.4080306@FreeBSD.org> Date: Tue, 22 Jul 2014 14:07:08 -0700 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: hackers@FreeBSD.org Subject: r268621: panic: shadowed tmpfs v_object Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 21:07:11 -0000 On r268621: > panic: shadowed tmpfs v_object 0xfffff807a7f96600 > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe1247d67390 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe1247d67440 > vpanic() at vpanic+0x126/frame 0xfffffe1247d67480 > kassert_panic() at kassert_panic+0x139/frame 0xfffffe1247d674f0 > vm_object_deallocate() at vm_object_deallocate+0x236/frame 0xfffffe1247d67550 > tmpfs_free_node() at tmpfs_free_node+0x138/frame 0xfffffe1247d67580 > tmpfs_reclaim() at tmpfs_reclaim+0x17d/frame 0xfffffe1247d675c0 > VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xf7/frame 0xfffffe1247d675f0 > vgonel() at vgonel+0x1a1/frame 0xfffffe1247d67660 > vrecycle() at vrecycle+0x3e/frame 0xfffffe1247d67690 > tmpfs_inactive() at tmpfs_inactive+0x4c/frame 0xfffffe1247d676b0 > VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xf7/frame 0xfffffe1247d676e0 > vinactive() at vinactive+0xc6/frame 0xfffffe1247d67730 > vputx() at vputx+0x27a/frame 0xfffffe1247d67790 > tmpfs_rename() at tmpfs_rename+0xf5/frame 0xfffffe1247d67860 > VOP_RENAME_APV() at VOP_RENAME_APV+0xfc/frame 0xfffffe1247d67890 > kern_renameat() at kern_renameat+0x3ef/frame 0xfffffe1247d67ae0 > amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247d67bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247d67bf0 > --- syscall (128, FreeBSD ELF64, sys_rename), rip = 0x80088b74a, rsp = 0x7fffffffe238, rbp = 0x7fffffffe710 --- > Uptime: 6d4h0m3s > > Dump failed. Partition too small. Unfortunately I have no dump to debug. -- Regards, Bryan Drewery From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 22 21:30:40 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93BD819C for ; Tue, 22 Jul 2014 21:30:40 +0000 (UTC) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (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 435C32928 for ; Tue, 22 Jul 2014 21:30:40 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id hu12so523333vcb.6 for ; Tue, 22 Jul 2014 14:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=8sbBzSdMn5cpfMM0uvS+nPNOZH6DptWhSuDp+5OWLDc=; b=e0lLy9+aFR3ZKJDmt+A40vSoI5Ci5TlAlfkD+B/IAWi9Nmi0T+KyXmnBvApDXrVNU5 GnwfSNwWJHQXOXu9JM/bQx3mTQUu1uKKST3JiI7kcjH1A5cz5XiawaqEeAYrnLYZqejE edPDytWxtViWkw6CTfoEGoEXLjYkm0nXe+/ceJXgqGO1mnpXfcY3dQgqkQ+/ESycXRMp IgWtUSmTKGYpqgUasnnTZCtenDAVbO5DpvjQAJXB9d+PsftuQrn1cjlivgaYzt9wLdno OaZELM3gsEUS4ATjKXWnmpyNGYhJko06Ro8yzAIQj2KQCbbI93ueToYFSxuWU+AXlVEA k0jQ== MIME-Version: 1.0 X-Received: by 10.52.7.163 with SMTP id k3mr27803978vda.58.1406064639312; Tue, 22 Jul 2014 14:30:39 -0700 (PDT) Received: by 10.220.20.74 with HTTP; Tue, 22 Jul 2014 14:30:39 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Jul 2014 14:30:39 -0700 Message-ID: Subject: Re: freebsd-hackers Digest, Vol 588, Issue 1 From: Nidal Khalil To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 21:30:40 -0000 Hello All, OK, I was able to capture the early boot output by entering ddb GDB: no debug ports present KDB: debugger backend; ddb My pc does not have a serial port. However I am using usb to serial by Prolific Tech. You mean to tell me that the kernel gdb shim is hardwired to /dev/cuau0? Nidal On Tue, Jul 22, 2014 at 2:06 PM, Nidal Khalil wrote: > Still no go > > > On Tue, Jul 22, 2014 at 5:00 AM, > wrote: > >> Send freebsd-hackers mailing list submissions to >> freebsd-hackers@freebsd.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> or, via email, send a message with subject or body 'help' to >> freebsd-hackers-request@freebsd.org >> >> You can reach the person managing the list at >> freebsd-hackers-owner@freebsd.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of freebsd-hackers digest..." >> >> >> Today's Topics: >> >> 1. Remote kernel debugging question (Nidal Khalil) >> 2. Re: Remote kernel debugging question (Benjamin Kaduk) >> 3. Re: Remote kernel debugging question (Nidal Khalil) >> 4. Re: Remote kernel debugging question (Navdeep Parhar) >> 5. Re: Remote kernel debugging question (Nidal Khalil) >> 6. Re: Remote kernel debugging question (Navdeep Parhar) >> 7. Re: Remote kernel debugging question (Nidal Khalil) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Mon, 21 Jul 2014 12:22:59 -0700 >> From: Nidal Khalil >> To: freebsd-hackers@freebsd.org >> Subject: Remote kernel debugging question >> Message-ID: >> < >> CADoY-6j0d9pBn-TDoMf5gysE8QiGz42DCFGLDWASig-wqLiMbg@mail.gmail.com> >> Content-Type: text/plain; charset=UTF-8 >> >> Hello All, >> I am somewhat new to BSD kernel but I am trying to debug a kernel module >> using remote debugging. >> I am using 9.2 RELEASE. >> I setup and compiled the kernel with the following: >> >> makeoptions DEBUG=-g >> options KDB >> options KDB_TRACE >> options DDB_CTF >> options DDB >> options GDB >> options ALT_BREAK_TO_DEBUGGER >> >> I setup the uart for serial1 flags to 0x90 and I can read and write to the >> serial from either machine >> Both machines have the same kernel booted. >> I can enter ddb but I can not launch gdb >> The remote GDB backend could not be selected. >> sysctl -a | grep debug.kdb >> >> debug.kdb.available: ddb >> Is that correct or it should be: >> debug.kdb.available: ddb gdb >> How do I enable gdb backend. I appreciate the help. >> >> Nidal >> >> >> ------------------------------ >> >> Message: 2 >> Date: Mon, 21 Jul 2014 17:55:51 -0400 (EDT) >> From: Benjamin Kaduk >> To: Nidal Khalil >> Cc: freebsd-hackers@freebsd.org >> Subject: Re: Remote kernel debugging question >> Message-ID: >> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >> On Mon, 21 Jul 2014, Nidal Khalil wrote: >> >> > Hello All, >> > I am somewhat new to BSD kernel but I am trying to debug a kernel module >> > using remote debugging. >> > I am using 9.2 RELEASE. >> > I setup and compiled the kernel with the following: >> > >> > makeoptions DEBUG=-g >> > options KDB >> > options KDB_TRACE >> > options DDB_CTF >> > options DDB >> > options GDB >> > options ALT_BREAK_TO_DEBUGGER >> > >> > I setup the uart for serial1 flags to 0x90 and I can read and write to >> the >> > serial from either machine >> > Both machines have the same kernel booted. >> > I can enter ddb but I can not launch gdb >> > The remote GDB backend could not be selected. >> > sysctl -a | grep debug.kdb >> > >> > debug.kdb.available: ddb >> > Is that correct or it should be: >> > debug.kdb.available: ddb gdb >> > How do I enable gdb backend. I appreciate the help. >> >> I do not think I have actually used remote GDB kernel debugging on my own >> machines, but I wanted to make sure that you had seen the documentation >> for doing so, available at >> >> http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-gdb.html >> . If it is incorrect, we should update it to be correct. >> >> Thanks, >> >> Ben Kaduk >> >> >> ------------------------------ >> >> Message: 3 >> Date: Mon, 21 Jul 2014 14:58:24 -0700 >> From: Nidal Khalil >> To: Benjamin Kaduk >> Cc: freebsd-hackers@freebsd.org >> Subject: Re: Remote kernel debugging question >> Message-ID: >> < >> CADoY-6hcD6ACwFVgX-LJ2cXHL35-bO+F8NYZ69vf3VDpg0DAAA@mail.gmail.com> >> Content-Type: text/plain; charset=UTF-8 >> >> Hi Ben, >> Yes I am familiar with the doc. As >> >> >> On Mon, Jul 21, 2014 at 2:55 PM, Benjamin Kaduk wrote: >> >> > On Mon, 21 Jul 2014, Nidal Khalil wrote: >> > >> > Hello All, >> >> I am somewhat new to BSD kernel but I am trying to debug a kernel >> module >> >> using remote debugging. >> >> I am using 9.2 RELEASE. >> >> I setup and compiled the kernel with the following: >> >> >> >> makeoptions DEBUG=-g >> >> options KDB >> >> options KDB_TRACE >> >> options DDB_CTF >> >> options DDB >> >> options GDB >> >> options ALT_BREAK_TO_DEBUGGER >> >> >> >> I setup the uart for serial1 flags to 0x90 and I can read and write to >> the >> >> serial from either machine >> >> Both machines have the same kernel booted. >> >> I can enter ddb but I can not launch gdb >> >> The remote GDB backend could not be selected. >> >> sysctl -a | grep debug.kdb >> >> >> >> debug.kdb.available: ddb >> >> Is that correct or it should be: >> >> debug.kdb.available: ddb gdb >> >> How do I enable gdb backend. I appreciate the help. >> >> >> > >> > I do not think I have actually used remote GDB kernel debugging on my >> own >> > machines, but I wanted to make sure that you had seen the documentation >> for >> > doing so, available at http://www.freebsd.org/doc/en/ >> > books/developers-handbook/kerneldebug-online-gdb.html . If it is >> > incorrect, we should update it to be correct. >> > >> > Thanks, >> > >> > Ben Kaduk >> > >> >> >> ------------------------------ >> >> Message: 4 >> Date: Mon, 21 Jul 2014 15:22:32 -0700 >> From: Navdeep Parhar >> To: Nidal Khalil , freebsd-hackers@freebsd.org >> Subject: Re: Remote kernel debugging question >> Message-ID: <53CD92A8.5000201@gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> On 07/21/14 12:22, Nidal Khalil wrote: >> > Hello All, >> > I am somewhat new to BSD kernel but I am trying to debug a kernel module >> > using remote debugging. >> > I am using 9.2 RELEASE. >> > I setup and compiled the kernel with the following: >> > >> > makeoptions DEBUG=-g >> > options KDB >> > options KDB_TRACE >> > options DDB_CTF >> > options DDB >> > options GDB >> > options ALT_BREAK_TO_DEBUGGER >> > >> > I setup the uart for serial1 flags to 0x90 and I can read and write to >> the >> > serial from either machine >> > Both machines have the same kernel booted. >> > I can enter ddb but I can not launch gdb >> > The remote GDB backend could not be selected. >> > sysctl -a | grep debug.kdb >> > >> > debug.kdb.available: ddb >> > Is that correct or it should be: >> > debug.kdb.available: ddb gdb >> >> The latter. >> >> > How do I enable gdb backend. I appreciate the help. >> >> All this on a recent HEAD. If your problem is 9.2 specific then this >> may not help, but at least we can compare notes. You did say you set >> flags to 0x90 for your serial port but it's not clear how. I have this >> in /boot/loader.conf: >> hint.uart.0.flags="0x90" >> >> When the system boots I see this right around when loader hands off to >> the kernel. >> >> GDB: debug ports: uart >> GDB: current port: uart >> KDB: debugger backends: ddb gdb >> KDB: current backend: ddb >> Copyright (c) 1992-2014 The FreeBSD Project. >> ... >> >> After the system boots I see both ddb and gdb in the available debug >> backends and all is well. >> >> # sysctl debug.kdb.available >> debug.kdb.available: ddb gdb >> # sysctl debug.kdb.current >> debug.kdb.current: ddb >> # sysctl debug.kdb.current=gdb >> debug.kdb.current: ddb -> gdb >> # sysctl debug.kdb.current >> debug.kdb.current: gdb >> >> Regards, >> Navdeep >> >> >> ------------------------------ >> >> Message: 5 >> Date: Mon, 21 Jul 2014 15:35:01 -0700 >> From: Nidal Khalil >> To: Navdeep Parhar >> Cc: freebsd-hackers@freebsd.org >> Subject: Re: Remote kernel debugging question >> Message-ID: >> < >> CADoY-6hPgy8e7ETt2bFM27P--PJTjSTX0e9+bo3aVE4UyweYEw@mail.gmail.com> >> Content-Type: text/plain; charset=UTF-8 >> >> The documentation states to put hint.uart.0.flags="0x90" in >> /boot/device.hits >> However you hit on a good point. I see some parameters in >> boot/loader.conf. >> Can you please email this file >> I think that I need to do more configuration to this file. I will do it by >> comparison. Thanks >> >> Nidal >> >> >> On Mon, Jul 21, 2014 at 3:22 PM, Navdeep Parhar >> wrote: >> >> > On 07/21/14 12:22, Nidal Khalil wrote: >> > > Hello All, >> > > I am somewhat new to BSD kernel but I am trying to debug a kernel >> module >> > > using remote debugging. >> > > I am using 9.2 RELEASE. >> > > I setup and compiled the kernel with the following: >> > > >> > > makeoptions DEBUG=-g >> > > options KDB >> > > options KDB_TRACE >> > > options DDB_CTF >> > > options DDB >> > > options GDB >> > > options ALT_BREAK_TO_DEBUGGER >> > > >> > > I setup the uart for serial1 flags to 0x90 and I can read and write to >> > the >> > > serial from either machine >> > > Both machines have the same kernel booted. >> > > I can enter ddb but I can not launch gdb >> > > The remote GDB backend could not be selected. >> > > sysctl -a | grep debug.kdb >> > > >> > > debug.kdb.available: ddb >> > > Is that correct or it should be: >> > > debug.kdb.available: ddb gdb >> > >> > The latter. >> > >> > > How do I enable gdb backend. I appreciate the help. >> > >> > All this on a recent HEAD. If your problem is 9.2 specific then this >> > may not help, but at least we can compare notes. You did say you set >> > flags to 0x90 for your serial port but it's not clear how. I have this >> > in /boot/loader.conf: >> > hint.uart.0.flags="0x90" >> > >> > When the system boots I see this right around when loader hands off to >> > the kernel. >> > >> > GDB: debug ports: uart >> > GDB: current port: uart >> > KDB: debugger backends: ddb gdb >> > KDB: current backend: ddb >> > Copyright (c) 1992-2014 The FreeBSD Project. >> > ... >> > >> > After the system boots I see both ddb and gdb in the available debug >> > backends and all is well. >> > >> > # sysctl debug.kdb.available >> > debug.kdb.available: ddb gdb >> > # sysctl debug.kdb.current >> > debug.kdb.current: ddb >> > # sysctl debug.kdb.current=gdb >> > debug.kdb.current: ddb -> gdb >> > # sysctl debug.kdb.current >> > debug.kdb.current: gdb >> > >> > Regards, >> > Navdeep >> > >> >> >> ------------------------------ >> >> Message: 6 >> Date: Mon, 21 Jul 2014 15:40:09 -0700 >> From: Navdeep Parhar >> To: Nidal Khalil >> Cc: freebsd-hackers@freebsd.org >> Subject: Re: Remote kernel debugging question >> Message-ID: <53CD96C9.2010600@gmail.com> >> Content-Type: text/plain; charset=UTF-8 >> >> On 07/21/14 15:35, Nidal Khalil wrote: >> > The documentation states to put hint.uart.0.flags="0x90" in >> > /boot/device.hits >> >> Putting it in device.hints should have worked too. In fact, that's >> where uart(4) has it. You haven't spelled it "hits" on your filesystem >> like you did here, have you? >> >> > However you hit on a good point. I see some parameters in >> > boot/loader.conf. Can you please email this file >> > I think that I need to do more configuration to this file. I will do it >> > by comparison. Thanks >> >> That's all there was in the file. >> >> Regards, >> Navdeep >> >> > >> > Nidal >> > >> > >> > On Mon, Jul 21, 2014 at 3:22 PM, Navdeep Parhar > > > wrote: >> > >> > On 07/21/14 12:22, Nidal Khalil wrote: >> > > Hello All, >> > > I am somewhat new to BSD kernel but I am trying to debug a kernel >> > module >> > > using remote debugging. >> > > I am using 9.2 RELEASE. >> > > I setup and compiled the kernel with the following: >> > > >> > > makeoptions DEBUG=-g >> > > options KDB >> > > options KDB_TRACE >> > > options DDB_CTF >> > > options DDB >> > > options GDB >> > > options ALT_BREAK_TO_DEBUGGER >> > > >> > > I setup the uart for serial1 flags to 0x90 and I can read and >> > write to the >> > > serial from either machine >> > > Both machines have the same kernel booted. >> > > I can enter ddb but I can not launch gdb >> > > The remote GDB backend could not be selected. >> > > sysctl -a | grep debug.kdb >> > > >> > > debug.kdb.available: ddb >> > > Is that correct or it should be: >> > > debug.kdb.available: ddb gdb >> > >> > The latter. >> > >> > > How do I enable gdb backend. I appreciate the help. >> > >> > All this on a recent HEAD. If your problem is 9.2 specific then >> this >> > may not help, but at least we can compare notes. You did say you >> set >> > flags to 0x90 for your serial port but it's not clear how. I have >> this >> > in /boot/loader.conf: >> > hint.uart.0.flags="0x90" >> > >> > When the system boots I see this right around when loader hands off >> to >> > the kernel. >> > >> > GDB: debug ports: uart >> > GDB: current port: uart >> > KDB: debugger backends: ddb gdb >> > KDB: current backend: ddb >> > Copyright (c) 1992-2014 The FreeBSD Project. >> > ... >> > >> > After the system boots I see both ddb and gdb in the available debug >> > backends and all is well. >> > >> > # sysctl debug.kdb.available >> > debug.kdb.available: ddb gdb >> > # sysctl debug.kdb.current >> > debug.kdb.current: ddb >> > # sysctl debug.kdb.current=gdb >> > debug.kdb.current: ddb -> gdb >> > # sysctl debug.kdb.current >> > debug.kdb.current: gdb >> > >> > Regards, >> > Navdeep >> > >> > >> >> >> >> ------------------------------ >> >> Message: 7 >> Date: Mon, 21 Jul 2014 15:44:23 -0700 >> From: Nidal Khalil >> To: Navdeep Parhar >> Cc: freebsd-hackers@freebsd.org >> Subject: Re: Remote kernel debugging question >> Message-ID: >> < >> CADoY-6hJUGOvhQ6qoeP1aYLZ737dgYQGSsik_QF1+qXqcPH1Nw@mail.gmail.com> >> Content-Type: text/plain; charset=UTF-8 >> >> No, I have not . >> It is hint.uart.0.flags="0x90" >> Thanks >> My question is how do I get gdb to show up as part of available debuggers >> in this node: >> debug.kdb.available: ddb >> Thanks >> >> Nidal >> >> >> On Mon, Jul 21, 2014 at 3:40 PM, Navdeep Parhar >> wrote: >> >> > On 07/21/14 15:35, Nidal Khalil wrote: >> > > The documentation states to put hint.uart.0.flags="0x90" in >> > > /boot/device.hits >> > >> > Putting it in device.hints should have worked too. In fact, that's >> > where uart(4) has it. You haven't spelled it "hits" on your filesystem >> > like you did here, have you? >> > >> > > However you hit on a good point. I see some parameters in >> > > boot/loader.conf. Can you please email this file >> > > I think that I need to do more configuration to this file. I will do >> it >> > > by comparison. Thanks >> > >> > That's all there was in the file. >> > >> > Regards, >> > Navdeep >> > >> > > >> > > Nidal >> > > >> > > >> > > On Mon, Jul 21, 2014 at 3:22 PM, Navdeep Parhar > > > > wrote: >> > > >> > > On 07/21/14 12:22, Nidal Khalil wrote: >> > > > Hello All, >> > > > I am somewhat new to BSD kernel but I am trying to debug a >> kernel >> > > module >> > > > using remote debugging. >> > > > I am using 9.2 RELEASE. >> > > > I setup and compiled the kernel with the following: >> > > > >> > > > makeoptions DEBUG=-g >> > > > options KDB >> > > > options KDB_TRACE >> > > > options DDB_CTF >> > > > options DDB >> > > > options GDB >> > > > options ALT_BREAK_TO_DEBUGGER >> > > > >> > > > I setup the uart for serial1 flags to 0x90 and I can read and >> > > write to the >> > > > serial from either machine >> > > > Both machines have the same kernel booted. >> > > > I can enter ddb but I can not launch gdb >> > > > The remote GDB backend could not be selected. >> > > > sysctl -a | grep debug.kdb >> > > > >> > > > debug.kdb.available: ddb >> > > > Is that correct or it should be: >> > > > debug.kdb.available: ddb gdb >> > > >> > > The latter. >> > > >> > > > How do I enable gdb backend. I appreciate the help. >> > > >> > > All this on a recent HEAD. If your problem is 9.2 specific then >> this >> > > may not help, but at least we can compare notes. You did say you >> set >> > > flags to 0x90 for your serial port but it's not clear how. I have >> > this >> > > in /boot/loader.conf: >> > > hint.uart.0.flags="0x90" >> > > >> > > When the system boots I see this right around when loader hands >> off >> > to >> > > the kernel. >> > > >> > > GDB: debug ports: uart >> > > GDB: current port: uart >> > > KDB: debugger backends: ddb gdb >> > > KDB: current backend: ddb >> > > Copyright (c) 1992-2014 The FreeBSD Project. >> > > ... >> > > >> > > After the system boots I see both ddb and gdb in the available >> debug >> > > backends and all is well. >> > > >> > > # sysctl debug.kdb.available >> > > debug.kdb.available: ddb gdb >> > > # sysctl debug.kdb.current >> > > debug.kdb.current: ddb >> > > # sysctl debug.kdb.current=gdb >> > > debug.kdb.current: ddb -> gdb >> > > # sysctl debug.kdb.current >> > > debug.kdb.current: gdb >> > > >> > > Regards, >> > > Navdeep >> > > >> > > >> > >> > >> >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org >> " >> >> ------------------------------ >> >> End of freebsd-hackers Digest, Vol 588, Issue 1 >> *********************************************** >> > > From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 22 21:07:46 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3DC30543 for ; Tue, 22 Jul 2014 21:07:46 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0BBE6266F for ; Tue, 22 Jul 2014 21:07:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s6ML7jpN020042 for ; Tue, 22 Jul 2014 21:07:45 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s6ML7jQm020039 for hackers@FreeBSD.org; Tue, 22 Jul 2014 21:07:45 GMT (envelope-from bdrewery) Received: (qmail 57737 invoked from network); 22 Jul 2014 16:07:44 -0500 Received: from unknown (HELO blah) (freebsd@shatow.net@67.182.131.225) by sweb.xzibition.com with ESMTPA; 22 Jul 2014 16:07:44 -0500 Message-ID: <53CED29F.1090809@FreeBSD.org> Date: Tue, 22 Jul 2014 14:07:43 -0700 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: current@FreeBSD.org Subject: Re: r268621: panic: shadowed tmpfs v_object References: <53CED27C.4080306@FreeBSD.org> In-Reply-To: <53CED27C.4080306@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 22 Jul 2014 22:29:00 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 21:07:46 -0000 Meant to send to current@, moving there. On 7/22/14, 2:07 PM, Bryan Drewery wrote: > On r268621: > >> panic: shadowed tmpfs v_object 0xfffff807a7f96600 >> cpuid = 0 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfffffe1247d67390 >> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe1247d67440 >> vpanic() at vpanic+0x126/frame 0xfffffe1247d67480 >> kassert_panic() at kassert_panic+0x139/frame 0xfffffe1247d674f0 >> vm_object_deallocate() at vm_object_deallocate+0x236/frame >> 0xfffffe1247d67550 >> tmpfs_free_node() at tmpfs_free_node+0x138/frame 0xfffffe1247d67580 >> tmpfs_reclaim() at tmpfs_reclaim+0x17d/frame 0xfffffe1247d675c0 >> VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xf7/frame 0xfffffe1247d675f0 >> vgonel() at vgonel+0x1a1/frame 0xfffffe1247d67660 >> vrecycle() at vrecycle+0x3e/frame 0xfffffe1247d67690 >> tmpfs_inactive() at tmpfs_inactive+0x4c/frame 0xfffffe1247d676b0 >> VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xf7/frame 0xfffffe1247d676e0 >> vinactive() at vinactive+0xc6/frame 0xfffffe1247d67730 >> vputx() at vputx+0x27a/frame 0xfffffe1247d67790 >> tmpfs_rename() at tmpfs_rename+0xf5/frame 0xfffffe1247d67860 >> VOP_RENAME_APV() at VOP_RENAME_APV+0xfc/frame 0xfffffe1247d67890 >> kern_renameat() at kern_renameat+0x3ef/frame 0xfffffe1247d67ae0 >> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247d67bf0 >> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247d67bf0 >> --- syscall (128, FreeBSD ELF64, sys_rename), rip = 0x80088b74a, rsp = >> 0x7fffffffe238, rbp = 0x7fffffffe710 --- >> Uptime: 6d4h0m3s >> >> Dump failed. Partition too small. > > Unfortunately I have no dump to debug. > -- Regards, Bryan Drewery From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 23 01:46:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40251149 for ; Wed, 23 Jul 2014 01:46:02 +0000 (UTC) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D04EF2E44 for ; Wed, 23 Jul 2014 01:46:01 +0000 (UTC) X-AuditID: 1209190e-f79946d000007db1-7b-53cf12a489bb Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 6A.0C.32177.4A21FC35; Tue, 22 Jul 2014 21:40:52 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s6N1eq08015206; Tue, 22 Jul 2014 21:40:52 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6N1eobi005432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Jul 2014 21:40:51 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s6N1eoGt018926; Tue, 22 Jul 2014 21:40:50 -0400 (EDT) Date: Tue, 22 Jul 2014 21:40:49 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: Nidal Khalil Subject: Re: freebsd-hackers Digest, Vol 588, Issue 1 In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYrdT110idD7Y4OgrY4vtm/8xWjx6foLR gcljxqf5LB47Z91lD2CK4rJJSc3JLEst0rdL4Mo4NHU+W8F01opLM2cxNTBOYOli5OSQEDCR OLr0BxuELSZx4d56MFtIYDaTxK+f+V2MXED2RkaJN23P2CGcQ0wSiyc9Z4VwGhgltm9+yNzF yMHBIqAtcbolE6SbTUBN4vHeZlaIqYoSm09NAisREVCReDs9HyTMLCAvcWHzIUaQsLCAqcSu U64gYU6BQIl7XVPAbuMVcJT4uOYu1NpzjBK3970ES4gK6Eis3g9TJChxcuYTFoiZlhLn/lxn m8AoNAtJahaS1AJGplWMsim5Vbq5iZk5xanJusXJiXl5qUW6xnq5mSV6qSmlmxhB4cspybeD 8etBpUOMAhyMSjy8BTXngoVYE8uKK3MPMUpyMCmJ8noKnA8W4kvKT6nMSCzOiC8qzUktPsQo wcGsJMIb3QpUzpuSWFmVWpQPk5LmYFES531rbRUsJJCeWJKanZpakFoEk5Xh4FCS4D0rCDRU sCg1PbUiLTOnBCHNxMEJMpwHaPh3kBre4oLE3OLMdIj8KUZdjkX7X3YzCbHk5eelSonzHgW5 TgCkKKM0D24OLO28YhQHekuY9wXIKB5gyoKb9ApoCRPQkqLM0yBLShIRUlINjJYTPn/dd1tO 1Pje1W8LWDPXTpl291XbdIfF6x2mRr5duIF/z7F4td0Lfk455PnqWsPOoGdv+r9ty7x5VZnt DtO1GuHZMmmi74x3WlteOPy0Y6+g88K965mzNdX155fJuf6NW6qdLfk7v8G020Yhy6cxQ7R8 QecVb8a3kismsAn+cNS6JnfkwkElluKMREMt5qLiRACwLOB3FgMAAA== Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 01:46:02 -0000 On Tue, 22 Jul 2014, Nidal Khalil wrote: > Hello All, > OK, I was able to capture the early boot output by entering ddb > GDB: no debug ports present > KDB: debugger backend; ddb > > My pc does not have a serial port. However I am using usb to serial by > Prolific Tech. > You mean to tell me that the kernel gdb shim is hardwired to /dev/cuau0? It is not hardwired to that exact device node, but yes, a USB-to-serial adapter will not work for it. A firewire port is also supposed to be usable for remote kernel debugging, as documented at http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-dcons.html -Ben From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 24 16:46:18 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A3A4FAB for ; Thu, 24 Jul 2014 16:46:18 +0000 (UTC) Received: from mx2.ord1.rackspace.com (mx2.ord1.rackspace.com [173.203.4.136]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "IronPort Appliance Demo Certificate", Issuer "IronPort Appliance Demo Certificate" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AB04423A8 for ; Thu, 24 Jul 2014 16:46:17 +0000 (UTC) X-SBRS: None X-SenderGroup: RELAYLIST-US X-MailFlowPolicy: $RELAYED-US X-IronPort-AV: E=McAfee;i="5600,1067,7471"; a="327755385" X-IronPort-AV: E=Sophos;i="5.01,489,1400043600"; d="scan'208";a="327755385" Received: from ord1exh01.rackspace.corp ([10.12.120.25]) by mx2.ord1.rackspace.com with ESMTP/TLS/AES128-SHA; 24 Jul 2014 11:46:11 -0500 Received: from rstark.munix.us (10.1.69.56) by smtpout.rackspace.com (10.12.120.25) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 24 Jul 2014 11:46:11 -0500 Message-ID: <53D13853.1090802@rackspace.com> Date: Thu, 24 Jul 2014 11:46:11 -0500 From: Ryan Stark User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Subject: Request for assistance with kernel panic in FreeBSD-10.0-p7 References: <53ADC58C.901@rackspace.com> <53ADDD99.5080001@freebsd.org> <53ADE88B.4060308@rackspace.com> In-Reply-To: <53ADE88B.4060308@rackspace.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.69.56] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 16:46:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello Hackers, Seems I was a little enthusiastic in my last report that all issues were resolved, as I have continued to experience sporadic panics when upgrading ports on my FreeBSD workstation. I would appreciate any assistance or pointers in helping me narrow done what is causing these panics and if there is a way to resolve them. /var/log/messages right before reboot: Jul 23 10:20:18 rstark kernel: Fatal trap 12: page fault while in kernel mode Jul 23 10:20:18 rstark kernel: cpuid = 1; apic id = 02 Jul 23 10:20:18 rstark kernel: fault virtual address = 0xfffff9d0f000e020 Jul 23 10:20:18 rstark kernel: fault code = supervisor read data, page not present Jul 23 10:20:18 rstark kernel: instruction pointer = 0x20:0xffffffff80c870d2 Jul 23 10:20:18 rstark kernel: stack pointer = 0x28:0xfffffe0466b497f0 Jul 23 10:20:18 rstark kernel: frame pointer = 0x28:0xfffffe0466b498d0 Jul 23 10:20:18 rstark kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Jul 23 10:20:18 rstark kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Jul 23 10:20:18 rstark kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Jul 23 10:20:18 rstark kernel: current process = 66419 (sed) Jul 23 10:20:18 rstark kernel: trap number = 12 Jul 23 10:20:18 rstark kernel: panic: page fault Jul 23 10:20:18 rstark kernel: cpuid = 1 Jul 23 10:20:18 rstark kernel: KDB: stack backtrace: Jul 23 10:20:18 rstark kernel: #0 0xffffffff808e7e90 at kdb_backtrace+0x60 Jul 23 10:20:18 rstark kernel: #1 0xffffffff808af975 at panic+0x155 Jul 23 10:20:18 rstark kernel: #2 0xffffffff80c8e832 at trap_fatal+0x3a2 Jul 23 10:20:18 rstark kernel: #3 0xffffffff80c8eb09 at trap_pfault+0x2c9 Jul 23 10:20:18 rstark kernel: #4 0xffffffff80c8e296 at trap+0x5e6 Jul 23 10:20:18 rstark kernel: #5 0xffffffff80c75532 at calltrap+0x8 Jul 23 10:20:18 rstark kernel: #6 0xffffffff80b10660 at vmspace_exit+0xa0 Jul 23 10:20:18 rstark kernel: #7 0xffffffff8087c76f at exit1+0x65f Jul 23 10:20:18 rstark kernel: #8 0xffffffff8087c10e at sys_sys_exit+0xe Jul 23 10:20:18 rstark kernel: #9 0xffffffff80c8f127 at amd64_syscall+0x357 Jul 23 10:20:18 rstark kernel: #10 0xffffffff80c7581b at Xfast_syscall+0xfb Jul 23 10:20:18 rstark kernel: Uptime: 1d1h57m1s Jul 23 10:20:18 rstark kernel: Dumping 3817 out of 16282 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% uname -a FreeBSD rstark.munix.us 10.0-RELEASE-p7 FreeBSD 10.0-RELEASE-p7 #1 r268805: Thu Jul 17 15:41:46 CDT 2014 root@rstark.munix.us:/usr/obj/usr/src/sys/GENERIC amd64 Debugging run: [root@rstark /usr/obj/usr/src/sys/GENERIC]# kgdb kernel.debug /var/crash/vmcore.8 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 02 fault virtual address = 0xfffff9d0f000e020 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80c870d2 stack pointer = 0x28:0xfffffe0466b497f0 frame pointer = 0x28:0xfffffe0466b498d0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 66419 (sed) trap number = 12 panic: page fault cpuid = 1 KDB: stack backtrace: #0 0xffffffff808e7e90 at kdb_backtrace+0x60 #1 0xffffffff808af975 at panic+0x155 #2 0xffffffff80c8e832 at trap_fatal+0x3a2 #3 0xffffffff80c8eb09 at trap_pfault+0x2c9 #4 0xffffffff80c8e296 at trap+0x5e6 #5 0xffffffff80c75532 at calltrap+0x8 #6 0xffffffff80b10660 at vmspace_exit+0xa0 #7 0xffffffff8087c76f at exit1+0x65f #8 0xffffffff8087c10e at sys_sys_exit+0xe #9 0xffffffff80c8f127 at amd64_syscall+0x357 #10 0xffffffff80c7581b at Xfast_syscall+0xfb Uptime: 1d1h57m1s Dumping 3817 out of 16282 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. Loaded symbols for /boot/kernel/linprocfs.ko.symbols Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/kernel/linsysfs.ko.symbols...done. Loaded symbols for /boot/kernel/linsysfs.ko.symbols Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/kernel/geom_eli.ko.symbols...done. Loaded symbols for /boot/kernel/geom_eli.ko.symbols Reading symbols from /boot/kernel/crypto.ko.symbols...done. Loaded symbols for /boot/kernel/crypto.ko.symbols Reading symbols from /boot/kernel/aesni.ko.symbols...done. Loaded symbols for /boot/kernel/aesni.ko.symbols Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/sem.ko.symbols...done. Loaded symbols for /boot/kernel/sem.ko.symbols Reading symbols from /boot/kernel/pty.ko.symbols...done. Loaded symbols for /boot/kernel/pty.ko.symbols Reading symbols from /boot/kernel/ums.ko.symbols...done. Loaded symbols for /boot/kernel/ums.ko.symbols Reading symbols from /boot/kernel/uhid.ko.symbols...done. Loaded symbols for /boot/kernel/uhid.ko.symbols Reading symbols from /boot/kernel/pflog.ko.symbols...done. Loaded symbols for /boot/kernel/pflog.ko.symbols Reading symbols from /boot/kernel/pf.ko.symbols...done. Loaded symbols for /boot/kernel/pf.ko.symbols #0 doadump (textdump=) at pcpu.h:219 219 __asm("movq %%gs:%1,%0" : "=r" (td) (kgdb) backtrace #0 doadump (textdump=) at pcpu.h:219 #1 0xffffffff808af5f0 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0xffffffff808af9b4 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0xffffffff80c8e832 in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:882 #4 0xffffffff80c8eb09 in trap_pfault (frame=0xfffffe0466b49740, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:699 #5 0xffffffff80c8e296 in trap (frame=0xfffffe0466b49740) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0xffffffff80c75532 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #7 0xffffffff80c870d2 in pmap_remove_pages (pmap=0xfffff800129a39f8) at /usr/src/sys/amd64/amd64/pmap.c:555 #8 0xffffffff80b10660 in vmspace_exit (td=0xfffff803ef7c7920) at /usr/src/sys/vm/vm_map.c:399 #9 0xffffffff8087c76f in exit1 (td=0xfffff803ef7c7920, rv=) at /usr/src/sys/kern/kern_exit.c:321 #10 0xffffffff8087c10e in sys_sys_exit (td=, uap=) at /usr/src/sys/kern/kern_exit.c:121 #11 0xffffffff80c8f127 in amd64_syscall (td=0xfffff803ef7c7920, traced=0) at subr_syscall.c:134 #12 0xffffffff80c7581b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #13 0x00000008008f431a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) list *0xffffffff80c870d2 0xffffffff80c870d2 is in pmap_remove_pages (/usr/src/sys/amd64/amd64/pmap.c:5187). 5182 inuse &= ~bitmask; 5183 5184 pte = pmap_pdpe(pmap, pv->pv_va); 5185 ptepde = *pte; 5186 pte = pmap_pdpe_to_pde(pte, pv->pv_va); 5187 tpte = *pte; 5188 if ((tpte & (PG_PS | PG_V)) == PG_V) { 5189 superpage = FALSE; 5190 ptepde = tpte; 5191 pte = (pt_entry_t *)PHYS_TO_DMAP(tpte & Not quite sure how to proceed. Thanks in advance for any pointers or assistance! - -- Ryan Stark -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJT0ThSAAoJEOuHL951PlCy63kP/3qvcZUpYnggcqwUpQv7+/QR aUBcudwOf+bGgHSheqNnCUvA3GKZRVnRXx8cJKCpGEy2Y9IPqxRhJBAB3ARAgrTI WBuJAKkGWVgLiBNL8dTFNJ99vc5U8NcELy03TPe3LrXZb31ch1fKXwc+MnL4giwn co4s3q7a+1kUs77WT85szGwqJSWKBUcHpj64bUwzr9PO+au4eJ+K32u9vJ4Mtr84 2Ch1C7WNwRhw8+rGDLPgwJoGXwmQqaVMnSfWWPxSoJ1pI0F1rfuQk550P0/bTcSW XSWCxQWgQ8XQUQ5XUrZcDKAsjCT1/WGHvb5kzmnt12ZZNfEyOGPNEnAammtJFSP9 NfHvFb/H5iSFEQ95p1qQFhg2vmAqKpPVOgnZ7gtOoHHiWkinpO7HwJNBLae8K2Om KQB5X81OF7gvXYJNuWjWiBLDFOAnQuKMQTqq9sdNF8OqZOtEXLRa+Uq7L612X82y ptNvOHQ/144Jr9O8/puutZqKjgiUwEkkcAPFR/9eCA65PVH/n55KwBTaUvs75clP lZCkQqIn7x5vMO8yZTCORKOg1p+I85OeeJZcJiWRhOqvdYcKyfCDOL3fpN+AablW /FBKyITrnF0PhqBM13xjP8UihYwFFuQq+9xG0u+6o00TUaW14Rm2K2wqSZkE30ES dEZn2ioHc1Zz7okuDXSx =1y4Q -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 24 18:33:59 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A84534D6; Thu, 24 Jul 2014 18:33:57 +0000 (UTC) Date: Thu, 24 Jul 2014 14:33:53 -0400 From: Glen Barber To: freebsd-hackers@FreeBSD.org Subject: FreeBSD Quarterly Status Report - Second Quarter 2014 Message-ID: <20140724183353.GL1065@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; x-action=pgp-signed Content-Transfer-Encoding: quoted-printable X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:33:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 FreeBSD Project Quarterly Status Report: April - June 2014 This report covers FreeBSD-related projects between April and June 2014. This is the second of four reports planned for 2014. The second quarter of 2014 was a very busy and productive time for the FreeBSD Project. A new FreeBSD Core Team was elected, the FreeBSD Ports Management Team branched the second quarterly "stable" branch, the FreeBSD Release Engineering Team was in the process of finalizing the FreeBSD 9.3-RELEASE cycle, and many exciting new features have been added to FreeBSD. Thanks to all the reporters for the excellent work! This report contains 24 entries and we hope you enjoy reading it. The deadline for submissions covering the period from July to September 2014 is October 7th, 2014. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Core Team * FreeBSD Port Management Team * FreeBSD Release Engineering Team Projects * Chelsio iSCSI Offload Support * CUSE4BSD * FreeBSD and Summer of Code 2014 * New Automounter * pkg(8) * QEMU bsd-user-Enabled Ports Building * RPC/NFS and CTL/iSCSI Performance Optimizations * ZFSguru Kernel * PostgreSQL Performance Improvements * Running FreeBSD as an Application on Top of the Fiasco.OC Microkernel * SDIO Driver * TMPFS Stability * UEFI Boot * Updated vt(4) System Console Architectures * FreeBSD/arm64 Ports * FreeBSD Python Ports * KDE/FreeBSD * The Graphics Stack on FreeBSD Documentation * Quarterly Status Reports Miscellaneous * FreeBSD Host Support for OpenStack and OpenContrail * The FreeBSD Foundation __________________________________________________________________ FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team constitutes the project's "Board of Directors", responsible for deciding the project's overall goals and direction as well as managing specific areas of the FreeBSD project landscape. Topics for core this quarter have included some far-reaching policy reviews and some significant changes to the project development methodology. In May, a new release policy was published and presented at the BSDCan developer conference by John Baldwin. The idea is that each major release branch (for example, 10.X) is guaranteed to be supported for at least five years, but individual point releases on each branch, like 10.0-RELEASE, will be issued at regular intervals and only the latest point release will be supported. Another significant change did not receive approval. When the change to the Bylaws reforming the core team election process was put to the vote of all FreeBSD developers, it failed to reach a quorum. June saw the culmination of a long running project to replace the project's bug tracking system. As of June 3, the FreeBSD project has switched to Bugzilla as its bug tracking system. All of the history of GNATS PRs has been preserved, so there is no need to re-open old tickets. Work is still going on to replicate some of the integration tweaks that had been applied to GNATS, but all necessary functionality has been implemented and the project is already seeing the benefits of the new capabilities brought by Bugzilla. An election to select core members for the next two year term of office took place during this period. We would like to thank retiring members of core for their years of service. The new core team provides continuity with previous core teams: about half are incumbents from the previous team, and several former core team members have returned after a hiatus. Core now includes two members of the FreeBSD Foundation board and one other Foundation staff member, aiding greater coordination at the top level of the project. At the same time the core-secretary role was passed on to a new volunteer. Other activities included providing consultation on licensing terms for software within the FreeBSD source tree, and oversight of changes to the membership of postmaster and clusteradm. Three new src commit bits were issued during this quarter, and one was taken into safekeeping. __________________________________________________________________ FreeBSD Port Management Team URL: http://www.FreeBSD.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-po= rts/ URL: http://portsmon.freebsd.org/index.html URL: http://www.freebsd.org/portmgr/index.html URL: http://blogs.freebsdish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/portmgr URL: http://plus.google.com/communities/108335846196454338383 Contact: Frederic Culot Contact: FreeBSD Port Management Team The ports tree slowly approaches the 25,000 ports threshold, while the PR count is slightly below 1800. In Q2 we added three new committers, took in one commit bit for safekeeping, and reinstated one commit bit. In May, Thomas Abthorpe was replaced by Frederic Culot as portmgr secretary, and Steve Wills became a member of the portmgr team. Commencing July 1, the third intake of portmgr-lurkers started active duty on portmgr for a four month duration. The next two candidates are William Grzybowski and Nicola Vitale. This quarter also saw the release of the second quarterly branch, namely 2014Q2. This branch was not only built for 10 (as 2014Q1) but for 9 as well (both i386 and amd64). Open tasks: 1. As previously noted, many PRs continue to languish, we would like to see committers dedicate themselves to closing as many as possible. __________________________________________________________________ FreeBSD Release Engineering Team URL: http://www.freebsd.org/releases/9.3R/schedule.html URL: http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, and announcing code freezes and maintaining the respective branches, among other things. In early May, the FreeBSD 9.3-RELEASE cycle entered the code slush phase. The FreeBSD 9.3-RELEASE cycle is nearing the final phases, and 9.3-RC3 builds will be starting soon. 9.3-RC3 is planned to be the final release candidate for this release cycle, and at the time of this writing, 9.3-RELEASE should be available on schedule. Work is ongoing to integrate support for embedded architectures into the release build process. At this time, support exists for a number of ARM kernels, in particular the Raspberry Pi, BeagleBone, and WandBoard. Additionally, work is in progress to produce virtual machine images as part of the release cycle, supporting various cloud services such as Microsoft Azure, Amazon EC2, and Google Compute Engine. This project is sponsored by The FreeBSD Foundation . __________________________________________________________________ Chelsio iSCSI Offload Support Contact: Sreenivasa Honnur Building on the new in-kernel iSCSI target and initiator stack released in FreeBSD 10.0, Chelsio Communications has begun developing an offload interface to take advantage of the hardware offload capabilities of Chelsio T4 and T5 10 and 40 gigabit Ethernet adapters. The code currently implements a working prototype of offload for the initiator side, and target side offload should begin shortly. The code will be released under the BSD license and is expected to be completed later in the year and be committed to FreeBSD-HEAD, and will likely ship in a FreeBSD release in early 2015. Open tasks: 1. Complete testing and debugging of the initiator offload. 2. Start development of target offload. 3. Create hardware-independent offload APIs, based on experiences with target and initiator proof-of-concept implementations. __________________________________________________________________ CUSE4BSD URL: http://svnweb.freebsd.org/changeset/base/266581 Contact: Hans Petter Selasky The so-called CUSE4BSD has been imported into the base system of FreeBSD-11. CUSE is short for character device in userspace. The CUSE library is a wrapper for the devfs(8) kernel functionality which is exposed through /dev/cuse. In order to function, the CUSE kernel code must either be enabled in the kernel configuration file or loaded separately as a module. Follow the commit message link to get more information. __________________________________________________________________ FreeBSD and Summer of Code 2014 URL: http://gsoc.FreeBSD.org URL: https://wiki.freebsd.org/SummerOfCode2014 Contact: Gavin Atkinson Contact: Glen Barber Contact: Wojciech Koszek FreeBSD received 39 project proposals this year, many of which were of a very high standard. After a difficult selection process narrowing these down into the slots we had been allocated, a total of 16 projects were selected to participate in Google Summer of Code 2014 with FreeBSD. The projects selected span a wide range of areas within FreeBSD, covering both the base system and ports infrastructure, userland and kernel. We have students working on firewall optimisation, ports packaging tools, embedded systems, debugging infrastructure, improved Unicode support, enhancements to the loader and to the installer, and several other areas of work. We are just over halfway through the allocated time this year, and are very much looking forward to integrating code produced by these projects into FreeBSD. This is the tenth time FreeBSD has taken part in Google's Summer of Code, and we are grateful to Google to have accepted us as a participating organisation. __________________________________________________________________ New Automounter Contact: Edward Tomasz Napieral/a Deficiencies in the current automounter, amd(8), are a recurring problem reported by many FreeBSD users. A new automounter is being developed to address these concerns. The automounter is a cleanroom implementation of functionality available in most other Unix systems, using proper kernel support implemented via an autofs filesystem. The automounter supports a standard map format, and will integrate with the Lightweight Directory Access Protocol (LDAP) service. The project is at the early testing stage. A patch will be released as part of a broader call for testing after additional review on some critical components (in particular, the autofs filesystem). After fixing reported problems, the code will be committed to FreeBSD 11-CURRENT. It is expected to ship in the FreeBSD 10.2 release. This project is sponsored by The FreeBSD Foundation . Open tasks: 1. Fix bad interaction with fts(3). 2. Debug a problem with Kerberos NFS mounts. __________________________________________________________________ pkg(8) URL: https://github.com/freebsd/pkg URL: https://github.com/freebsd/pkg/issues Contact: Baptiste Daroussin Contact: Bryan Drewery Contact: Matthew Seaman Contact: Vsevolod Stakhov Contact: The pkg mailing list pkg(8) is the new package management tool for FreeBSD. It is now the only supported package management tool for FreeBSD releases from 10.0-RELEASE, including the upcoming 9.3-RELEASE. pkg(8) is available on all currently supported releases. Support for the legacy pkg_tools is due to be discontinued at the beginning of September 2014. The release of pkg(8) 1.3 is imminent. This includes major improvements in the dependency solver. Now we can: * Switch versions of, for example, Perl or PHP and resolve all the conflicts with packages that depend on them automatically. No more need to manually switch package origins. * Deal more gracefully with complex upgrade or install scenarios. * Sandbox operations dealing with freshly downloaded data until it can be verified as trustworthy by checking the package signature. * Deal with provides-and-requires style of dependencies, so for example we can say "this package needs to use a web server" and allow that dependency to be fulfilled by apache or nginx or any other alternative that provides web-server functionality. Beyond the next release, we have work in progress on allowing ranges of versions in dependency rules and handling a selection of "foreign" package repositories, such as CPAN or CTAN or PyPi. There are plans to use pkg(8) to package up the base system. Along with other benefits, this will allow writing a universal installer: download one installer image and from there install any available version of FreeBSD, including snapshots. We are also intending to use pkg(8) within the ports tree at package-build time to handle fulfilling build dependencies. This opens the possibility of installing build-dependencies by downloading binary packages, which means you can install a package with customized options with the minimum amount of time spent compiling anything else. Open tasks: 1. We are sorely lacking a comprehensive testing setup. Integrating automated regression testing into the development cycle is becoming an imperative. 2. We need testers who can run development versions of pkg in as many distinct types of use-cases as possible, and report feedback from their experiences to the freebsd-pkg@freebsd.org mailing list or our issues list on github. __________________________________________________________________ QEMU bsd-user-Enabled Ports Building URL: https://wiki.freebsd.org/QemuUserModeHowTo URL: http://dirty.ysv.freebsd.org/ URL: https://github.com/seanbruno/qemu-bsd-user Contact: Stacey Son Contact: Juergen Lock Contact: Sean Bruno The ports-mgmt/poudriere-devel port is capable of building ports via an emulator. Configuration of the miscellaneous binary image activator is required prior to a poudriere-devel run. ARMV6, MIPS32 and MIPS64 packages can be produced via full emulation. There are several packages that block a full run of builds. They can be viewed on the "Status of ports building" link. To build packages via emulation, on current or latest stable/10: Clone the github repository, and switch to the bsd-user branch. Then run: ./configure --static \ --target-list=3D"arm-bsd-user i386-bsd-user \ mips-bsd-user mips64-bsd-user mips64el-bsd-user \ mipsel-bsd-user ppc-bsd-user ppc64-bsd-user sparc-bsd-user \ sparc64-bsd-user x86_64-bsd-user" gmake; gmake install Then set up the binmiscctl tools to do some evil hackery to redirect execution of armv6 binaries to qemu: binmiscctl add armv6 --interpreter \ "/usr/local/bin/qemu-arm" --magic \ "\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02 \ \x00\x28\x00" --mask "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff \ \xff\xff\xff\xff\xfe\xff\xff\xff" --size 20 --set-enabled Install poudriere-devel from ports. It knows how to set up things. Create a poudriere jail to do all the magic: poudriere jail -c -j 11armv632 -m svn -a armv6 \ -v head Now run poudriere against that jail to build all the ports: poudriere bulk -j 11armv632 -a Nullfs mount the ports tree into the jail: mkdir /usr/local/poudriere/jails/11armv632/usr/ports mount -t nullfs /usr/ports /usr/local/poudriere/jails/11armv632/usr/ports To chroot into the jail: mount -t devfs devfs /usr/local/poudriere/jails/11armv632/dev chroot /usr/local/poudriere/jails/11armv632/ Open tasks: 1. PPC on AMD64 emulation. This is a work in progress as there appear to be some serious issues running the bsd-user binary on big-endian hardware. Justin Hibbits is working on this. 2. SPARC64 on AMD64 emulation is non-functional and instantly segfaults. We are looking for someone to poke at the bits here. 3. External Toolchain, XDEV support. There is partial support for using an AMD64 toolchain that can output binaries for other architecture (e.g., using an AMD64 toolchain to build MIPS64 packages). We are currently tracking a linking issue with ports-mgmt/pkg. Thanks to Warner Losh, Baptiste Daroussin, Dimitry Andric for poking at bits in here to make the XDEV target useful. 4. Signal handling. The MIPS/ARMV6 target stills display a failure that manifests itself when building devel/p5-Sys-SigAction. 5. Massive documentation update needed. These modifications actually allow chrooting into a MIPS or ARMv6 environment and using native toolchains and libraries to prototype software for a target platform. __________________________________________________________________ RPC/NFS and CTL/iSCSI Performance Optimizations Contact: Alexander Motin The FreeBSD RPC stack, used as a base for its NFS server, received multiple optimizations to improve performance and SMP scalability. Algorithmic optimizations reduced processing overhead, while improved locking allowed it to scale up to at least 40 processor cores without significant lock congestion. Combined with some other kernel optimizations, the peak NFS request rate increased by many times, reaching up to 600K requests per second on modern hardware. The CAM Target Layer (CTL), used as the base for the new kernel iSCSI server, also received a series of locking optimizations which allowed its peak request rate to increase from ~200K to ~600K IOPS with the potential of reaching a rate of 1M requests per second. That rate is sufficient to completely saturate 2x10Gbit Ethernet links with 4KB requests. For comparison, the port of net/istgt (user-level iSCSI server) on the same hardware with an equivalent configuration showed only 100K IOPS. There is also ongoing work on improving CTL functionality. It was already made to support three of four VMware VAAI storage acceleration primitives (net/istgt supports 2), while the goal is to reach full VAAI support during next months. With all these improvements, and earlier improvements in CAM, GEOM, ZFS, and a number of other kernel areas coming soon, FreeBSD 10.1 may become the fastest storage release ever. ;) These projects are sponsored by iXsystems, Inc. __________________________________________________________________ ZFSguru URL: http://zfsguru.com URL: http://zfsguru.com/news/stateoftheproject/2014 Contact: Jason Edwards ZFSguru is a multifunctional server appliance with a strong emphasis on storage. ZFSguru began as simple web-interface frontend to ZFS, but has since grown into a FreeBSD derivative with its own infrastructure. The scope of the project has also grown with the inclusion of add-on packages that add functionality beyond the traditional NAS functionality found in similar product like FreeNAS and NAS4Free. ZFSguru aims to be a true multifunctional server appliance that is extremely easy to setup and can unite both novice and more experienced users in a single user interface. The modular nature of the project combats the danger of bloat, whilst still allowing extended functionality to be easily deployed. Where development in the first quarter of this year brought drag-and-drop permissions for Samba and NFS, development in the second quarter focused on strengthening the infrastructure of the project. A new library and toolkit solution dubbed 'Mesa' is in the works, providing a cleaner foundation to the project. A new master server providing secure remote services is being setup, to be located in a high-speed datacenter. But most importantly, a new system build infrastructure has shown great progress and will soon be able to provide automated system builds to our users. This not only improves the frequency of system releases but also frees much developer time to be spent on different areas of the project. Furthermore, a new website and forum is being worked on, replacing the old-fashioned website that offers only limited functionality. The new website will be linked to the server database, providing real-time updates about the project. In addition, a new platform for collaborative development is in the works. A service addon has been created for the GitLab project, which is a drop-in replacement of the popular GitHub website. The choice was made to host our own solution and not rely on GitHub itself. In retrospect this appears to be a good decision. The recent development where GitHub removed projects after DCMA takedowns being sent is incompatible with the philosophy of free-flow-of-information, which the ZFSguru project is a strong proponent of. By hosting our own solution, we have avoided any dependency on third party projects. It is expected that after the infrastructure of the project has been revamped, work on the web-interface itself can continue. New functionality such as GuruDB and Service Bulletins provide a tighter connection between the server infrastructure and the web-interface. The Migration Manager is one of the last remaining features still missing in the web-interface. This functionality provides an easy way to upgrade the current system by performing a new clean installation, but migrate all relevant configuration to the new installation. It also allows to backup all system configuration in a single file to be stored on a different machine should things go awry. A longer version of this status report giving a wider perspective on the project can be found at the stateoftheproject link. __________________________________________________________________ PostgreSQL Performance Improvements URL: https://www.kib.kiev.ua/kib/pgsql_perf_v2.0.pdf Contact: Konstantin Belousov Analysis of the performance of the latest 9.3 version of PostgreSQL on FreeBSD-CURRENT has been performed. The issues which prevented good scalability on a 40-core machine were determined, and changes prototyped which solve the bottlenecks. The URL above provides a paper which contains a detailed explanation of the issues and solutions, together with a graph demonstrating the effects on scalability. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Running FreeBSD as an Application on Top of the Fiasco.OC Microkernel URL: http://en.wikipedia.org/wiki/L4_microkernel_family URL: https://wiki.freebsd.org/201407DevSummit/BSDUserspace Contact: Ilya Bakulin Fiasco.OC belongs to the L4 microkernel family. A microkernel provides a bare minimum of services to the applications running on top of it, unlike traditional kernels that incorporate complex code like IP stacks and device drivers. This allows a dramatic decrease in the amount of code running in the privileged mode of the CPU, achieving higher security while still providing an acceptable level of performance. Running an operating system kernel on top of the microkernel allows leveraging any software that was developed for that operating system. The OS kernel runs in user-mode side-by-side with other microkernel applications such as real-time components. Multiple OSes, each with their userland applications, can even be run in parallel, thus allowing construction of products where processing of corporate data is strictly separated from the processing of private data. The project aims to create a port of FreeBSD to the Fiasco.OC microkernel, a high performance L4 microkernel developed by TU Dresden. Existing ports of OpenBSD and Linux are used as a reference. This will allow the use of unique FreeBSD features like ZFS in L4-based projects. Open tasks: 1. Finish opensourcing the port of L4OpenBSD/amd64 made by genua mbh. This is a work in progress. 2. Publish the sources of the L4FreeBSD port that is largely based on the L4OpenBSD code. 3. Improve the port, the first task being adopting the pmap(9) module to work with L4 microkernel memory allocation services. __________________________________________________________________ SDIO Driver URL: https://wiki.freebsd.org/SDIO URL: https://github.com/kibab/freebsd/tree/mmccam Contact: Ilya Bakulin SDIO is an interface designed as an extension of the existing SD card standard, which allows the connecting of different peripherals to a host with a standard SD controller. Peripherals currently sold on the general market include WLAN/BT modules, cameras, fingerprint readers, and barcode scanners. Additionally, SDIO is used to connect some peripherals in products like Chromebooks and Wandboards. A prototype of the driver for the Marvell SDIO WLAN/BT (Avastar 88W8787) module is also being developed, using the existing Linux driver as the reference. SDIO card detection and initialization already work. Most necessary bus methods are implemented and tested. The WiFi driver is able to load firmware onto the card and initialize it. A rewrite of the MMC stack as a transport layer for the CAM framework is in progress. This will allow utilization of the well-tested CAM locking model and debug features. Open tasks: 1. SDIO stack: finish CAM migration. The initialization of the MMC/SD card is implemented in the XPT layer, but cannot be tested with real hardware because of the lack of any device drivers that implement peripheral drivers and SIMs for CAM MMC. The plan is to use a modified version of the BeagleBone Black SDHCI controller driver for the SIM and a modified version of mmcsd(4) as a peripheral driver. 2. Marvell SDIO WiFi: connect to the FreeBSD network stack, write the code to implement required functions (such as sending/receiving data, network scanning and so on). __________________________________________________________________ TMPFS Stability Contact: Konstantin Belousov Contact: Peter Holm Extensive testing of tmpfs(5) using the stress2 kernel test suite was done. The issues found were debugged and fixed. Most of the problems are related to bugs in the interaction of the vnode and node lifetime, culminating in e.g., unmount races and dotdot lookup bugs. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ UEFI Boot URL: https://wiki.freebsd.org/UEFI URL: http://www.freebsd.org/snapshots/ Contact: Ed Maste Contact: Nathan Whitehorn The Unified Extensible Firmware Interface (UEFI) provides boot- and run-time services for x86 and other computers. For the x86 architecture it replaces the legacy BIOS. This project will adapt the FreeBSD loader and kernel boot process for compatibility with UEFI firmware, found on contemporary servers, desktops, and laptops. Ed and Nathan completed a number of integration tasks over the past three months. Nathan added a first-stage loader, boot1.efi, to support chain-loading the rest of the system from a UFS filesystem. This allows the UEFI boot process to proceed in a similar fashion as with BIOS boot. Nathan also added UEFI support to the FreeBSD installer and release image creation script. The EFI framebuffer requires the vt(4) system console -- a framebuffer driver is not implemented for the legacy syscons(4) console. Ed added automatic vt(4) selection to the UEFI boot path. Snapshots are now built as dual-mode images, and should boot via both BIOS and UEFI. Our plan is to merge the UEFI and vt(4) work to stable/10 to appear in FreeBSD 10.1-RELEASE. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Document manual installation, including dual-boot configurations. 2. Implement boot1.efi for ZFS file systems. 3. Add support for UEFI variables stored in non-volatile memory (NVRAM). 4. Debug boot failures with certain UEFI firmware implementations. 5. Support secure boot. __________________________________________________________________ Updated vt(4) System Console URL: https://wiki.freebsd.org/Newcons Contact: Aleksandr Rybalko Contact: Ed Maste Contact: Ed Schouten Contact: Warren Block The vt(4) (aka Newcons) project provides a replacement for the legacy syscons system console. It brings a number of improvements, including better integration with graphics modes and broader character set support. Since the last report, vt(4) gained the ability to make early driver selection. vt(4) selects the best successfully-probed driver before most other kernel subsystems are initialized. Also, to facilitate migration from syscons(4) to vt(4), multiple virtual terminal subsystems in the kernel are now supported. It is controlled by a small module with just one kernel environment variable. Users can select the virtual terminal system to use by setting kern.vty=3Dsc or kern.vty=3Dvt. The GENERIC kernel configuration for the amd64 and i386 platforms now includes both syscons(4) and vt(4) by default. This configuration is also planned to be in FreeBSD 10.1-RELEASE. The project finally received a man page, so now vt(4) is not only the project name, but also a link to its documentation. Great thanks to Warren Block for that. Major highlights: * Unicode support. * Double-width character support for CJK characters. * xterm(1)-like terminal emulation. * Support for Kernel Mode Setting (KMS) drivers (i915kms, radeonkms). * Support for different fonts per terminal window. * Simplified drivers. Brief status of supported architectures and hardware: * amd64 (VGA/i915kms/radeonkms) -- works. * ARM framebuffer -- works. * i386 (VGA/i915kms/radeonkms) -- works. * IA64 -- untested. * MIPS -- untested. * PPC and PPC64 -- work, but without X.Org yet. * SPARC -- works on certain hardware (e.g., Ultra 5). * vesa(4) -- in progress. * i386/amd64 nVidia driver -- not supported. VGA should be used (VESA planned). * Xbox framebuffer driver -- will be deleted as unused. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Implement the remaining features supported by vidcontrol(1). 2. Write manual pages for vt(4) drivers and kernel interfaces. 3. Support direct handling of keyboard by the kbd device (without kbdmux(4)). 4. CJK fonts. (This is in progress). 5. Address performance issues on some architectures. 6. Switch to vt(4) by default. 7. Convert keyboard maps for use with vt(4). 8. Implement compatibility mode to be able to use single-byte charsets/key-codes in vt(4). __________________________________________________________________ FreeBSD/arm64 URL: http://svnweb.freebsd.org/base/projects/arm64/ Contact: Andrew Turner Arm64 is the name of the in-progress port of FreeBSD to the ARMv8 CPU when it is in AArch64 mode. Until recently, all ARM CPU designs were 32-bit only. With the introduction of the ARMv8 architecture, ARM has added a new 64-bit mode. This new mode has been named AArch64. Booting FreeBSD on the ARM Foundation Model has made a lot of progress since the last status report. An initial pmap implementation has been written. With this, FreeBSD is able to enter the Machine Independent boot code. The required autoconf functions have been added allowing FreeBSD to start scheduling tasks. Finally the cpu_switch and copystr functions were added. With these two, FreeBSD will boot to the mountroot prompt. Work has started on supporting exceptions, including interrupts. This will allow more developers to start working on device drivers. Open tasks: 1. Finish exception and interrupt handling 2. Read the Device Tree or ACPI tables from UEFI 3. Test on real hardware __________________________________________________________________ FreeBSD Python Ports URL: https://wiki.FreeBSD.org/Python URL: irc://freebsd-python@irc.freenode.net Contact: FreeBSD Python Team We are pleased to announce the availability of conflict-free Python package support across different Python versions based on the USES=3Duniquefiles feature recently introduced to the Ports framework. A Python package can be marked as buildable and installable in parallel for different Python versions at the same time on the same host. The package building tools, however, do not support this feature yet and the Python team will work closely with portmgr and the pkg developers to enable support on a global ports and packages scale. In May and June a huge clean-up operation took place to remove the last bits and pieces targeting easy_install. In the beginning of July we committed the final changes to remove easy_install support completely from the ports framework. This greatly simplifies the infrastructure and allows us to modernize and maintain it with less effort. We added Python 3.4, removed Python 3.1 after its end of life, updated the setuptools ports to version 5.1 and PyPy's development version to 2.3.1. The latest Python 2.7.8 and an updated setuptools will hit the tree shortly. Our upstreaming effort continues to produce good outcomes for simplifying maintenance and reducing complexity. Looking forward, one of the top priorities is to comply with the USES framework in the foreseeable future and to roll out a consistent maintainer policy for integrating new Python-related ports into the tree. Open tasks: 1. Migrate bsd.python.mk to the Uses framework. 2. Develop a high-level and lightweight Python Ports Policy. 3. Add support for granular dependencies (for example >=3D1.0,<2.0). 4. See what adding pip (Python Package Index) support will require. 5. Add default QA targets and functions for Python ports (TEST_DEPENDS, regression-test, etc.) 6. More tasks can be found on the team's wiki page (see links). 7. To get involved, come and say "hi" on IRC and let us know what you are interested in! __________________________________________________________________ KDE/FreeBSD URL: http://FreeBSD.kde.org URL: http://FreeBSD.kde.org/area51.php Contact: KDE/FreeBSD Team The KDE/FreeBSD team has continued to improve the experience of KDE software and Qt under FreeBSD. During this quarter, the team has kept most of the KDE and Qt ports up-to-date, working on the following releases: * KDE SC: 4.12.5; Workspace: 4.11.9 As a result -- according to PortScout -- kde@ has 526 ports (up from 526), of which 84.63% are up-to-date (down from 98.86%). iXsystems Inc. continues to provide a machine for the team to build packages and to test updates. iXsystems Inc. has been providing the KDE/FreeBSD team with support for quite a long time and we are very grateful for that. As usual, the team is always looking for more testers and porters so please contact us at kde@FreeBSD.org and visit our home page at http://FreeBSD.kde.org. It would be especially useful to have more helping hands on tasks such as getting rid of the dependency on the defunct HAL project and providing integration with KDE's Bluedevil Bluetooth interface. Open tasks: 1. Updating out-of-date ports, see PortScout for a list 2. Removing the dependency on HAL __________________________________________________________________ The Graphics Stack on FreeBSD URL: https://wiki.freebsd.org/Graphics URL: http://lists.freebsd.org/pipermail/freebsd-announce/2014-July/00157= 0.ht ml URL: http://trillian.chruetertee.ch/ports/browser/trunk Contact: FreeBSD Graphics team We were generally short on time this quarter. We made less progress than expected on all fronts. The alternate pkg(8) repository, built with WITH_NEW_XORG, is now available. This alleviates the need for users to rebuild their ports with WITH_NEW_XORG. See the announcement, linked above for further information. Thanks to a contribution from Jan Kokem=C3=BCller, Radeon 32bit ioctls a= re now working on 64bit hosts. This was tested successfully with Wine and StarCraft II on FreeBSD 9.x and 11. This required modifications to emulators/i386-wine-devel so that it works with WITH_NEW_XORG, and the creation of a new port, libtxc_dxtn, to support the texture compression used by StarCraft II. We have not yet had the time to polish everything, so this still requires manual steps. The DRM generic code update is ready, but it breaks the current i915 driver. Therefore, the i915 driver must be updated before anything is committed. Compared to the previous status report, OpenCL test programs are running fine now, thanks to upgrades and fixes to libc++ and Clang. The relevant ports are still not ready to hit the ports tree, unfortunately. Open tasks: 1. See the "Graphics" wiki page for up-to-date information. __________________________________________________________________ Quarterly Status Reports Contact: Quarterly Status Report Team These quarterly status reports help the FreeBSD community stay up-to-date with the happenings in and around the project. Updates from FreeBSD teams, new features being developed in- or out-of-tree, products derived from FreeBSD, and FreeBSD events are all welcome additions to the status reports. The Monthly team has been busy since the last report, with longtime organizer G=C3=A1bor P=C3=A1li having stepped down from the team -- than= k you G=C3=A1bor for all your hard work! This has left something of a void in = the preparation of this report, for which the call for items was issued quite late. To help fill the void, Warren Block and Benjamin Kaduk have been added to the monthly@ team, joining Glen Barber, Gavin Atkinson, Ed Maste, and the rest of the team in preparing this report. Special thanks to Glen for doing most of the work while simultaneously getting 9.3-RELEASE out the door! The next cycle is sooner than you think! The deadline for submitting entries for the Q3 report is October 7th, 2014. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Submit reports for Q42014 to monthly@FreeBSD.org! __________________________________________________________________ FreeBSD Host Support for OpenStack and OpenContrail URL: http://www.openstack.org URL: http://www.opencontrail.org URL: https://github.com/Semihalf/openstack-devstack URL: https://github.com/Semihalf/openstack-nova URL: https://github.com/Semihalf/contrail-vrouter URL: https://blueprints.launchpad.net/nova/+spec/freebsd-compute-node Contact: Grzegorz Bernacki Contact: Michal Dubiel Contact: Dominik Ermel Contact: Rafal Jaworowski OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources in a datacenter. OpenContrail is a network virtualization (SDN) solution comprising network controller, virtual router, and analytics engine, which can be integrated with cloud orchestration systems like OpenStack or CloudStack. The goal of this work is to enable FreeBSD as a fully supported compute host for OpenStack using OpenContrail virtualized networking. The main areas of development are: * Libvirt hypervisor driver for bhyve. * Support for bhyve (via libvirt compute driver) and the overall FreeBSD platform in nova-compute. * OpenContrail vRouter (forwarding plane kernel module) port to FreeBSD. * OpenContrail Agent (network controller node) port to FreeBSD. * Integration and performance optimizations. Since the last report the following items have been completed, which allow for a working demo of an OpenStack compute node on a FreeBSD host using OpenContrail for network virtualization: * Port of the OpenContrail vRouter kernel module for FreeBSD (MPLS over GRE mode only) * Port of the OpenContrail Agent for FreeBSD * FreeBSD version of a Devstack installation/configuration script with support for the OpenContrail solution (Compute node components only) A demo was presented at the DevSummit during BSDCan2014 in Ottawa. Also, a meetup regarding the subject was organized in Krakow, Poland. Work on this project is sponsored by Juniper Networks. __________________________________________________________________ The FreeBSD Foundation URL: http://www.FreeBSDFoundation.org/ URL: http://freebsdjournal.com/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Most of the funding is used to support FreeBSD development projects, conferences and developer summits, purchase equipment to grow and improve the FreeBSD infrastructure, and provide legal support for the Project. We published our third issue of the FreeBSD Journal. We have over 2700 subscriptions so far. We continued working on the digital edition, which will allow subscribers to read the magazine in different web browsers, including those than run on FreeBSD. This will be available for the July/August issue of the Journal. We hired Anne Dickison, on a freelance basis, as our new marketing director, to help us promote the Foundation and Project. The annual board meeting was held in Ottawa, Canada, in May. Directors and officers were elected, and we did some long-term planning. We worked on our vision, core values, project road mapping, and our near-term goals. We also met with the core team to discuss roles and responsibilities, project roadmapping, and what we can do to help the Project more. We were a Gold+ sponsor for BSDCan, May 16-17 and provided 7 travel grants for developers to attend the conference. We also were the sponsor for both the developer and vendor summits. Justin Gibbs gave a FreeBSD presentation at a FreeBSD user's internal technology summit. Company visits like this help users understand the Project structure better and gives us a chance to communicate what FreeBSD people are working on as well as learn what different companies are doing with FreeBSD, as well as what they'd like to see supported. We can then help facilitate collaboration between the companies and FreeBSD developers. We were represented at Great Wide Open, April 2-3 (greatwideopen.org), Texas LinuxFest, June 13-14 (texaslinuxfest.org), and SouthEast LinuxFest, June 20-22 (southeastlinuxfest.org). Hardware was purchased to support an upgrade at Sentex. A new high-capacity 1Gbps switch was deployed to allow for more systems to be added to the test lab. The main file server and development box was upgraded to allow more users in the lab simultaneously. We purchased hardware, including package builders, and a larger server to allow NYI to be a full replica of all Project systems, comparable to what is in place at Yahoo Inc. and ISC. We worked with our lawyer to create an NDA between the Foundation and individuals for third party NDAs. This allows developers who need access to proprietary documents, to go through the Foundation, via an NDA for access. FreeBSD Foundation Systems Administrator and Release Engineer, Glen Barber, continued work on producing regularly-updated FreeBSD/arm snapshots for embedded devices, such as the Raspberry Pi, ZedBoard, and BeagleBone. In addition to producing weekly development snapshots from the head/ and stable/ branches, with feedback and help from Ed Maste, Glen finished work to produce release images that will, by default, provide debugging files for userland and kernel available on the FreeBSD Project FTP mirrors. Note that the debugging files will not be included on the bootonly.iso, disc1.iso, or dvd1.iso images due to the size of the resulting images. Foundation staff member Konstantin Belousov completed an investigation into poor performance of PostgreSQL on FreeBSD. This uncovered scalability problems in the FreeBSD kernel, and changes to address these issues are in progress. Some previously completed Foundation-sponsored projects received enhancements or additional work. The ARM superpages project was completed last year, but is now enabled by default in FreeBSD-CURRENT. Many stability fixes and enhancements have been committed to the in-kernel iSCSI stack. The iSCSI project was released in FreeBSD 10.0. Many stability fixes and enhancements have been committed and will be included in FreeBSD 10.1. Work continues on the Foundation-sponsored autofs automount daemon, UEFI boot support, the updated vt(4) system video console, virtual machine images, and the Intel graphics driver update. Foundation-sponsored work resulted in 226 commits to FreeBSD over the April to June period. __________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJT0VGRAAoJELls3eqvi17QF0UP/iPhYcVNJ2WUJS3rZ9MPCPHj EfN3DLsOMCO54YWEIUnQqZTR0ist9HjUaSbyLfTIM9j4xmwvz2Z6JWiMvg8Ui8QC 6EuLjLOKvlwaj4F9/OMu5mrOpYeXtwZOS5KgeYN+yq9sBXV3mzMe8yhzIT6zTGNM akRhbVqJiQRKnwF4T15PML/AJ9ihrfYqz3j3veocelWDyuEG2LOpJQj1zfUXX2f8 YdCDSi/6bNmNoh95Nf7+F7Uj+R7EvYHZ5SdvO9eUk/ET/J4x/JAXcxwms/ars2wX LsJjVZS9vLVCvb82HADb6tWAUCi02hHy0vUxxKj2E9u113Nq2Ecws2kSdnaIEfJp jFUE3y5/VWnCKOGXgF3T4iB20M+i/nqOQStnY33fq5Dr36LlHvVpLNCF9XjRs+IN p6O8aDOnl8etil+Z2w6IWeth/D6la8a2+4xEP3/l/d9VHParchoKUcA44RFM/k8D MNz/+fQurkaLZXEQUlr9oB/QRuZ6t54pT/rD1Nu40/kvnoS+Ss8JdN1VzcdBe5b1 hehkxxZ1/GmxSp2YcdeQVfK86YE+323izsa4fBjvx/6z+Zo3C2dIV2mgBuoz1mQd U5G/a1DOcVHGqBO7xUVlgwEr1c2pTARmRBEU5rkehibqkznG5QFfj83k3j3Mvx0N P9kkcHSgEgy40srydzLq =3D3eLh -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 25 19:43:41 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 569CD4EF; Fri, 25 Jul 2014 19:43:41 +0000 (UTC) Received: from smtp-out-01.shaw.ca (smtp-out-01.shaw.ca [64.59.136.137]) by mx1.freebsd.org (Postfix) with ESMTP id ED8A2263E; Fri, 25 Jul 2014 19:43:40 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=BkBxTXsSVzyY7C2joSQK+JNK4mJr1It1Skr7Xe8+Jh8= c=1 sm=1 a=7V3fggXvsmQA:10 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=8nJEP1OIZ-IA:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=6I5d2MoRAAAA:8 a=BWvPGDcYAAAA:8 a=1KmhjRZRDwvG-PhjtxoA:9 a=wPNLvfGTeEIA:10 a=RgXXd5XzHKoA:10 a=SV7veod9ZcQA:10 a=V7tsTZBp22UA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-01.shaw.ca with ESMTP; 25 Jul 2014 13:42:32 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 110F1A46C; Fri, 25 Jul 2014 12:42:32 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.9/8.14.9) with ESMTP id s6PJCVZN003786; Fri, 25 Jul 2014 12:12:31 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.14.9/8.14.8/Submit) with ESMTP id s6PHK8YX095747; Fri, 25 Jul 2014 10:20:08 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201407251720.s6PHK8YX095747@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: trasz@FreeBSD.org Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2014 In-Reply-To: Message from Glen Barber of "Thu, 24 Jul 2014 14:33:53 -0400." <20140724183353.GL1065@hub.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Jul 2014 10:19:55 -0700 Cc: Glen Barber , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 19:43:41 -0000 In message <20140724183353.GL1065=40hub.FreeBSD.org>, Glen Barber writes:= > New Automounter >=20 > Contact: Edward Tomasz Napieral/a >=20 > Deficiencies in the current automounter, amd(8), are a recurring > problem reported by many FreeBSD users. A new automounter is being > developed to address these concerns. >=20 > The automounter is a cleanroom implementation of functionality > available in most other Unix systems, using proper kernel support > implemented via an autofs filesystem. The automounter supports a > standard map format, and will integrate with the Lightweight Directo= ry > Access Protocol (LDAP) service. Will it also integrate with NIS (as SunOS and Solaris do)? FreeBSD's amd = currently integrates with NIS as well. --=20 Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 25 21:12:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 236DF7AF; Fri, 25 Jul 2014 21:12:58 +0000 (UTC) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (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 3D2432E4A; Fri, 25 Jul 2014 21:12:57 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id q58so4743405wes.18 for ; Fri, 25 Jul 2014 14:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=5CixpQx38wT7/cblhEdhEC7smrirlwRu2Ll1zdl9o+w=; b=DV0Jki0iD3c0brggRxNDicviEHnc0t1iYZJ/SAyY1ocoJHWv/iFz2F8A9wWAmkVsUp j3LYaUtrLbgTHyyXKcib3PJUpQDG9+4lBJ6GqHNfEOJMnxqTIjHZyYr0SgeqUgyJXrw7 pQCNABtN5jvBAmSUR2mw7VGa1RvMYq6cWm33WtoU9iebJrKezgM82QEsJsk6CfpWX3wl iNOkJU2SLl9loTDTzGpgo4f+H7pZjdfTUk1x3kxGdkkZR+mez0uRRHZfby6+7PfGW8aC 59F4CbE6IQvRks6c/1KbTIetNwTi6ovUeoHhqJxsaa/7zRdd3DHiCPRHg2Qk9Ttxcnr9 6PLQ== X-Received: by 10.180.221.172 with SMTP id qf12mr8791812wic.54.1406322775536; Fri, 25 Jul 2014 14:12:55 -0700 (PDT) Received: from brick.home (cmu49.neoplus.adsl.tpnet.pl. [83.31.148.49]) by mx.google.com with ESMTPSA id u10sm10363103wix.14.2014.07.25.14.12.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Jul 2014 14:12:54 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Fri, 25 Jul 2014 23:12:49 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Cy Schubert Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2014 Message-ID: <20140725211249.GA3933@brick.home> Mail-Followup-To: Cy Schubert , Glen Barber , freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org References: <20140724183353.GL1065@hub.FreeBSD.org> <201407251720.s6PHK8YX095747@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201407251720.s6PHK8YX095747@slippy.cwsent.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Glen Barber , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 21:12:58 -0000 On 0725T1019, Cy Schubert wrote: > In message <20140724183353.GL1065@hub.FreeBSD.org>, Glen Barber writes: > > New Automounter > > > > Contact: Edward Tomasz Napieral/a > > > > Deficiencies in the current automounter, amd(8), are a recurring > > problem reported by many FreeBSD users. A new automounter is being > > developed to address these concerns. > > > > The automounter is a cleanroom implementation of functionality > > available in most other Unix systems, using proper kernel support > > implemented via an autofs filesystem. The automounter supports a > > standard map format, and will integrate with the Lightweight Directory > > Access Protocol (LDAP) service. > > Will it also integrate with NIS (as SunOS and Solaris do)? FreeBSD's amd > currently integrates with NIS as well. It's just a matter of testing, apart from a trivial shell script. Would you be able to help me with this? From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 26 02:46:43 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14CE5616; Sat, 26 Jul 2014 02:46:43 +0000 (UTC) Received: from smtp-out-02.shaw.ca (smtp-out-02.shaw.ca [64.59.136.138]) by mx1.freebsd.org (Postfix) with ESMTP id BA50328C9; Sat, 26 Jul 2014 02:46:41 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=UbGOdjJMTOnDdlSKs4VLEv47Nwxh2hlhayjdFxkzNJk= c=1 sm=1 a=7V3fggXvsmQA:10 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=6I5d2MoRAAAA:8 a=BWvPGDcYAAAA:8 a=jn4Z1P99xdyqle8XhOAA:9 a=CjuIK1q_8ugA:10 a=RgXXd5XzHKoA:10 a=SV7veod9ZcQA:10 a=V7tsTZBp22UA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-02.shaw.ca with ESMTP; 25 Jul 2014 20:46:34 -0600 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id A52EBA56F; Fri, 25 Jul 2014 19:46:34 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.9/8.14.9) with ESMTP id s6Q2kXdV013283; Fri, 25 Jul 2014 19:46:33 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.14.9/8.14.8/Submit) with ESMTP id s6Q2kX7n013280; Fri, 25 Jul 2014 19:46:33 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201407260246.s6Q2kX7n013280@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Cy Schubert , Glen Barber , freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2014 In-Reply-To: Message from Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= of "Fri, 25 Jul 2014 23:12:49 +0200." <20140725211249.GA3933@brick.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Jul 2014 19:46:33 -0700 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 02:46:43 -0000 In message <20140725211249.GA3933@brick.home>, Edward Tomasz =?utf-8?Q?Napiera= C5=82a?= writes: > On 0725T1019, Cy Schubert wrote: > > In message <20140724183353.GL1065@hub.FreeBSD.org>, Glen Barber writes: > > > New Automounter > > > > > > Contact: Edward Tomasz Napieral/a > > > > > > Deficiencies in the current automounter, amd(8), are a recurring > > > problem reported by many FreeBSD users. A new automounter is being > > > developed to address these concerns. > > > > > > The automounter is a cleanroom implementation of functionality > > > available in most other Unix systems, using proper kernel support > > > implemented via an autofs filesystem. The automounter supports a > > > standard map format, and will integrate with the Lightweight Directory > > > Access Protocol (LDAP) service. > > > > Will it also integrate with NIS (as SunOS and Solaris do)? FreeBSD's amd > > currently integrates with NIS as well. > > It's just a matter of testing, apart from a trivial shell script. > Would you be able to help me with this? > Sure! Just point me in the direction of the patches. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 26 06:35:12 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D86455A1; Sat, 26 Jul 2014 06:35:12 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8B5902B8F; Sat, 26 Jul 2014 06:35:12 +0000 (UTC) Received: from latte.bs.cs.huji.ac.il ([132.65.179.20] helo=mbpro2.bs.cs.huji.ac.il) by kabab.cs.huji.ac.il with esmtp id 1XAvZO-000GTG-Oc; Sat, 26 Jul 2014 09:35:02 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2014 From: Daniel Braniss In-Reply-To: <201407260246.s6Q2kX7n013280@slippy.cwsent.com> Date: Sat, 26 Jul 2014 09:40:04 +0300 Content-Transfer-Encoding: 7bit Message-Id: <53C46240-10B2-453C-A077-8C151A4B391C@cs.huji.ac.il> References: <201407260246.s6Q2kX7n013280@slippy.cwsent.com> To: Cy Schubert X-Mailer: Apple Mail (2.1878.6) Cc: Glen Barber , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 06:35:12 -0000 On Jul 26, 2014, at 5:46 AM, Cy Schubert wrote: > In message <20140725211249.GA3933@brick.home>, Edward Tomasz > =?utf-8?Q?Napiera= > C5=82a?= writes: >> On 0725T1019, Cy Schubert wrote: >>> In message <20140724183353.GL1065@hub.FreeBSD.org>, Glen Barber writes: >>>> New Automounter >>>> >>>> Contact: Edward Tomasz Napieral/a >>>> >>>> Deficiencies in the current automounter, amd(8), are a recurring >>>> problem reported by many FreeBSD users. A new automounter is being >>>> developed to address these concerns. >>>> >>>> The automounter is a cleanroom implementation of functionality >>>> available in most other Unix systems, using proper kernel support >>>> implemented via an autofs filesystem. The automounter supports a >>>> standard map format, and will integrate with the Lightweight Directory >>>> Access Protocol (LDAP) service. >>> >>> Will it also integrate with NIS (as SunOS and Solaris do)? FreeBSD's amd >>> currently integrates with NIS as well. >> and hesiod? i can help with the testing danny >> It's just a matter of testing, apart from a trivial shell script. >> Would you be able to help me with this? >> > > > Sure! Just point me in the direction of the patches. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 26 13:22:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55E13E38; Sat, 26 Jul 2014 13:22:34 +0000 (UTC) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (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 6CAA62BCC; Sat, 26 Jul 2014 13:22:33 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id x48so5409334wes.17 for ; Sat, 26 Jul 2014 06:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=ppqEkfihE/lsMCuo50Sgpd699uh+4aTfKFl3ghjoKt4=; b=j4ofrRrx64wzHS8Z537Am5wndOylhAYctYQSuV/fVSdDqGt6E4ousT11cxBew0OE7B 4owAUxv9glPztU3Ee3pUmml2vtcJh6NMhK3OGNigm14iq3MSA5U7Jv3bHX7q/arR6tBk XVaZ11to0R+xLt+VCDdfHqvErtW3hDsof3jEPxdg55Tl92ih2GIbLizh/g2uNBErkSb0 V8iCIpikD32VTP4kmxaFZI3D3hlLMSjpq2EbQ6Qn7cFv3SeKgRs9s4aT0uLH3JR+/4gh nIIlWp/MmB3DFdEeaoYGcb+ivYe24Sag83VVu/JpboGZjk5fuYDmtqQ3ymy/MZMvtbzA hq3g== X-Received: by 10.194.2.132 with SMTP id 4mr30720137wju.49.1406380950875; Sat, 26 Jul 2014 06:22:30 -0700 (PDT) Received: from brick.home (cmu49.neoplus.adsl.tpnet.pl. [83.31.148.49]) by mx.google.com with ESMTPSA id wd7sm33644582wjc.36.2014.07.26.06.22.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Jul 2014 06:22:30 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sat, 26 Jul 2014 15:22:27 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Cy Schubert Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2014 Message-ID: <20140726132227.GA6812@brick.home> Mail-Followup-To: Cy Schubert , Glen Barber , freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org References: <20140725211249.GA3933@brick.home> <201407260246.s6Q2kX7n013280@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201407260246.s6Q2kX7n013280@slippy.cwsent.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Glen Barber , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 13:22:34 -0000 On 0725T1946, Cy Schubert wrote: > In message <20140725211249.GA3933@brick.home>, Edward Tomasz > =?utf-8?Q?Napiera= > C5=82a?= writes: > > On 0725T1019, Cy Schubert wrote: > > > In message <20140724183353.GL1065@hub.FreeBSD.org>, Glen Barber writes: > > > > New Automounter > > > > > > > > Contact: Edward Tomasz Napieral/a > > > > > > > > Deficiencies in the current automounter, amd(8), are a recurring > > > > problem reported by many FreeBSD users. A new automounter is being > > > > developed to address these concerns. > > > > > > > > The automounter is a cleanroom implementation of functionality > > > > available in most other Unix systems, using proper kernel support > > > > implemented via an autofs filesystem. The automounter supports a > > > > standard map format, and will integrate with the Lightweight Directory > > > > Access Protocol (LDAP) service. > > > > > > Will it also integrate with NIS (as SunOS and Solaris do)? FreeBSD's amd > > > currently integrates with NIS as well. > > > > It's just a matter of testing, apart from a trivial shell script. > > Would you be able to help me with this? > > > > > Sure! Just point me in the direction of the patches. So, the autofs branch is here: https://github.com/trasz/autofs. Directory services integration is done by external executable, which is usually a shell script. There is an LDAP example, at etc/autofs/include_ldap. Script to integrate with other services (which would be include_nis or include_hesiod) needs to do the same - retrieve the map named at the command line and output it to stdout, in a proper format. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 26 20:11:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1276419D; Sat, 26 Jul 2014 20:11:30 +0000 (UTC) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (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 B622C2DD8; Sat, 26 Jul 2014 20:11:29 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id cm18so6023135qab.32 for ; Sat, 26 Jul 2014 13:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4JE49dy2OEUKrMkKs1CyqStI/ULieHMO0dG7a+Egul0=; b=d2R5wbhrGsVW2PdYV0LoQPqqKcYbai4SMPl3uDBmVK/5LQYs1mFPTirRWJvGqWO05f BxWK9zKtvtM4SaWqr8O0b2ulL6j2rXW5Cx449YkwRyT+8w/p2Z+uHAdFarubV8piXRuo w1hBy4z0C5FjGldGHdA1UDNdQu5ycw2soPcfy0Vp0q5ljqkermQ2SHEVwdNjYtlME9B1 HcOvqWbdj6ECsWaWaF/swZJ/TjtIpFf70gXIO06OXmLsYY5L0q8U27P5i7ahZlUci4PF QncpScUUHst/YNO2xyQeBjk6VkcbK2sV0LLqva0YGRzyKW4Z5qYhVC4kaTewqjYPxWzc vD7g== MIME-Version: 1.0 X-Received: by 10.140.41.133 with SMTP id z5mr40879365qgz.99.1406405488898; Sat, 26 Jul 2014 13:11:28 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Sat, 26 Jul 2014 13:11:28 -0700 (PDT) In-Reply-To: <00E55D89-BDD1-41AD-BBF6-6752B90E8324@ccsys.com> References: <00E55D89-BDD1-41AD-BBF6-6752B90E8324@ccsys.com> Date: Sat, 26 Jul 2014 13:11:28 -0700 X-Google-Sender-Auth: lyvebhsM_dz_fMAga7-AnHYAsx4 Message-ID: Subject: Re: Working on NUMA support From: Adrian Chadd To: Jeff Roberson Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Andrew Bates X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 20:11:30 -0000 Hi all! Has there been any further progress on this? I've been working on making the receive side scaling support usable by mere mortals and I've reached a point where I'm going to need this awareness in the 10ge/40ge drivers for the hardware I have access to. I'm right now more interested in the kernel driver/allocator side of things, so: * when bringing up a NIC, figure out what are the "most local" CPUs to run on; * for each NIC queue, figure out what the "most local" bus resources are for NIC resources like descriptors and packet memory (eg mbufs); * for each NIC queue, figure out what the "most local" resources are for local driver structures that the NIC doesn't touch (eg per-queue state); * for each RSS bucket, figure out what the "most local" resources are for things like packet memory (mbufs), tcp/udp/inp control structures, etc. I had a chat with jhb yesterday and he reminded me that y'all at isilon have been looking into this. He described a few interesting cases from the kernel side to me. * On architectures with external IO controllers, the path cost from an IO device to multiple CPUs may be (almost) equivalent, so there's not a huge penalty to allocate things on the wrong CPU. I think it'll be nice to get CPU local affinity where possible so we can parallelise DRAM access fully, but we can play with this and see. * On architectures with CPU-integrated IO controllers, there's a large penalty for doing inter-CPU IO, * .. but there's not such a huge penalty for doing inter-CPU memory access. Given that, we may find that we should always put the IO resources local to the CPU it's attached to, even if we decide to run some / all of the IO for the device on another CPU. Ie, any RAM that the IO device is doing data or descriptor DMA into should be local to that device. John said that in his experience it seemed the penalty for a non-local CPU touching memory was much less than device DMA crossing QPI. So the tricky bit is figuring that out and expressing it all in a way that allows us to do memory allocation and CPU binding in a more aware way. The other half of this tricky thing is to allow it to be easily overridden by a curious developer or system administrator that wants to experiment with different policies. Now, I'm very specifically only addressing the low level kernel IO / memory allocation requirements here. There's other things to worry about up in userland; I think you're trying to address that in your KPI descriptions. Thoughts? -a