From owner-freebsd-current@FreeBSD.ORG Sun Jan 19 01:42:54 2014 Return-Path: Delivered-To: freebsd-current@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 31857B31; Sun, 19 Jan 2014 01:42:54 +0000 (UTC) Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [IPv6:2607:f8b0:400c:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A64E61261; Sun, 19 Jan 2014 01:42:53 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id w20so2220696vbb.13 for ; Sat, 18 Jan 2014 17:42:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=txlSrkG18VxqdC9HA3N0fS0tt4Kt1swx2izVkHA4+Wc=; b=JwHVFel//a5lD0ZPaJMEE/FicflgJalgnNEsHH/TILs3XwMPJESsfvd3cTKH+Sh7D2 1tL4a2qAXOQdGQXJsZOM3zyoIPW/ZQ3HJ31PfIMTKjytRiCTsE2cFGdHBgi4rXlcojNN NwMYmqq8GILmJr56PV+21zBnWIMjXVY6gE9ft3Cy0gKGCwxPQe/m+oMqDmLYPbx4kVPR J5BIBYhZkZOGaMWW0MUNdwAlFa3itJwoIBbEPmAZJ6jgQLiHI3khI+eqQ/JjyHGK244t EJCj3KSv1oJ/HMAicRKVKIfuNcRxNQ8SVWB+1wSt7ySjz31RmFad+HtMU1qxjEjCaqn3 diJw== X-Received: by 10.52.244.49 with SMTP id xd17mr2400085vdc.26.1390095772638; Sat, 18 Jan 2014 17:42:52 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.171.1 with HTTP; Sat, 18 Jan 2014 17:42:32 -0800 (PST) In-Reply-To: <20140115113430.GK26504@FreeBSD.org> References: <20140115113430.GK26504@FreeBSD.org> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Sun, 19 Jan 2014 02:42:32 +0100 X-Google-Sender-Auth: sbrCmL7p60RZD0oI-qigzWcg6FA Message-ID: Subject: Re: Regression on 10-RC5 with a multicast routing daemon To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" , Andre Oppermann X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 01:42:54 -0000 On Wed, Jan 15, 2014 at 12:34 PM, Gleb Smirnoff wrote: > Olivier, > > > TL;DR version: you need not subtract iphdrlen in 10.0. Code in > igmp.c:accept_igmp() > should be smth like: > > iphdrlen = ip->ip_hl << 2; > #ifdef RAW_INPUT_IS_RAW /* Linux */ > ipdatalen = ntohs(ip->ip_len) - iphdrlen; > #else > #if __FreeBSD_version >= 1000000 > ipdatalen = ip->ip_len - iphdrlen; > #else > ipdatalen = ip->ip_len; > #endif > #endif > > With this patch I've no more the message "warning - Received packet from x.x.x.x shorter (28 bytes) than hdr+data length (20+28)":Thanks! But there is still a regression regarding the PIM socket behavior not related to the packet format. The pim.c include 2 functions (pim_read and pim_accept) that are called when the socket received a packet: There functions are never triggered when PIM packets are received on 10.0. In the same time igmp_read() and igmp_accept() are correctly triggered on 9.2 and 10.0. tcpdump in non-promiscious mode correctly see input of PIM packet: This should confirm that once this daemon is started, it correctly open a PIM socket and the multicast filter is updated. From owner-freebsd-current@FreeBSD.ORG Sun Jan 19 03:11:09 2014 Return-Path: Delivered-To: current@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 81ACF77D; Sun, 19 Jan 2014 03:11:09 +0000 (UTC) Received: from smtpauth4.wiscmail.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5182A181E; Sun, 19 Jan 2014 03:11:08 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth4.wiscmail.wisc.edu by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MZM00300OD1LZ00@smtpauth4.wiscmail.wisc.edu>; Sat, 18 Jan 2014 21:11:07 -0600 (CST) X-Spam-PmxInfo: Server=avs-4, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.19.30017, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (adsl-76-208-68-77.dsl.mdsnwi.sbcglobal.net [76.208.68.77]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MZM003BZOUHNB10@smtpauth4.wiscmail.wisc.edu>; Sat, 18 Jan 2014 21:11:07 -0600 (CST) Message-id: <52DB4249.6010801@freebsd.org> Date: Sat, 18 Jan 2014 21:11:05 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: Aleksandr Rybalko , current@freebsd.org Subject: Re: [CFT] updated ofwfb driver vt(9) References: <20140117174207.88bedb221f2ac942c607dbf1@freebsd.org> In-reply-to: <20140117174207.88bedb221f2ac942c607dbf1@freebsd.org> X-Enigmail-Version: 1.6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 03:11:09 -0000 On 01/17/14 09:42, Aleksandr Rybalko wrote: > Hello hackers! > > I did updated version of vt's ofwfb driver, but have no HW to test. > It will be very nice if someone try it on ppc/sparc device. > > Instructions on how to enable vt(9) (newcons) can be found here: > https://wiki.freebsd.org/Newcons > > Patch to HEAD in attachment. (hope it will not be stripped) > > xf86-video-scfb expected to work too :) > > Many-many thanks! > > WBW I tried it on the following systems: QEMU (640x480 32-bit framebuffer): works fine. This is the good news. Powerbook G4 (1280x854 8-bit): first screen and a half of kernel output displays OK, although the cursor is bright cyan instead of light gray. The system then freezes completely. G5 iMac (1680x1050 8-bit): Screen turns black. Letters visible periodically underneath the cyan cursor. System eventually freezes completely. All three systems work fine with the old ofwfb (though the very slow scrolling makes booting take twice as long as with syscons) and I'm a bit at a loss to debug this correctly. Any ideas? -Nathan From owner-freebsd-current@FreeBSD.ORG Mon Jan 20 00:14:05 2014 Return-Path: Delivered-To: freebsd-current@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 6FE0068A; Mon, 20 Jan 2014 00:14:05 +0000 (UTC) Received: from pozo.com (pozo.com [50.197.129.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4D2F219FD; Mon, 20 Jan 2014 00:14:04 +0000 (UTC) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.7/8.14.7) with ESMTP id s0K06OfO098802 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NOT); Sun, 19 Jan 2014 16:06:25 -0800 (PST) (envelope-from null@pozo.com) Message-Id: <201401200006.s0K06OfO098802@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 19 Jan 2014 16:06:19 -0800 To: freebsd-current@freebsd.org From: Manfred Antar Subject: vm_reserv.c panic on sparc64 current Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,BAYES_00, MISSING_MID autolearn=no version=3.3.2, No X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: s0K06OfO098802 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Cc: alc@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 00:14:05 -0000 vm_reserv.c starting with revision 259999 causes panic on sparc64 (netra T1 200) version 259998 works backtrace: Starting apache22. panic: Bad link elm 0xfffff8007d4728f8 prev->next != elm cpuid = 0 KDB: enter: panic [ thread pid 1965 tid 100058 ] Stopped at kdb_enter+0x80: ta %xcc, 1 db> bt Tracing pid 1965 tid 100058 td 0xfffff80001880db0 vpanic() at vpanic+0x1f8 panic() at panic+0x20 vm_page_dequeue() at vm_page_dequeue+0xf8 vm_fault_hold() at vm_fault_hold+0x54c vm_fault() at vm_fault+0x88 trap_pfault() at trap_pfault+0x1ac trap() at trap+0xdc -- data access protection tar=0x4100679c sfar=0x41006010 sfsr=0x800005 %o7=0x4062ea3c -- userland() at 0x4062eab8 user trace: trap %o7=0x4062ea3c pc 0x4062eab8, sp 0x7fdffffd811 pc 0x4062ecd0, sp 0x7fdffffd8d1 pc 0x406397f0, sp 0x7fdffffd991 pc 0x1121f8, sp 0x7fdffffda71 pc 0x11bc4c, sp 0x7fdffffdb31 pc 0x10fce8, sp 0x7fdffffdbf1 pc 0x107e14, sp 0x7fdffffdcb1 pc 0x106310, sp 0x7fdffffdd71 pc 0x107160, sp 0x7fdffffde81 pc 0x106360, sp 0x7fdffffe041 pc 0x106284, sp 0x7fdffffe151 pc 0x111c6c, sp 0x7fdffffe261 pc 0x112118, sp 0x7fdffffe341 pc 0x102bc4, sp 0x7fdffffe441 pc 0x402258f4, sp 0x7fdffffe501 done ======================== || null@pozo.com || || || ======================== From owner-freebsd-current@FreeBSD.ORG Mon Jan 20 07:19:40 2014 Return-Path: Delivered-To: current@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 75B39228; Mon, 20 Jan 2014 07:19:40 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4B2BC18A4; Mon, 20 Jan 2014 07:19:39 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id s0K7JWbx095062; Mon, 20 Jan 2014 02:19:32 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s0K7JWRL095052; Mon, 20 Jan 2014 07:19:32 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 20 Jan 2014 07:19:32 GMT Message-Id: <201401200719.s0K7JWRL095052@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 07:19:40 -0000 TB --- 2014-01-20 04:00:20 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-01-20 04:00:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-01-20 04:00:20 - starting HEAD tinderbox run for arm/arm TB --- 2014-01-20 04:00:20 - cleaning the object tree TB --- 2014-01-20 04:00:20 - /usr/local/bin/svn stat /src TB --- 2014-01-20 04:00:25 - At svn revision 260900 TB --- 2014-01-20 04:00:26 - building world TB --- 2014-01-20 04:00:26 - CROSS_BUILD_TESTING=YES TB --- 2014-01-20 04:00:26 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-20 04:00:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-20 04:00:26 - SRCCONF=/dev/null TB --- 2014-01-20 04:00:26 - TARGET=arm TB --- 2014-01-20 04:00:26 - TARGET_ARCH=arm TB --- 2014-01-20 04:00:26 - TZ=UTC TB --- 2014-01-20 04:00:26 - __MAKE_CONF=/dev/null TB --- 2014-01-20 04:00:26 - cd /src TB --- 2014-01-20 04:00:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Jan 20 04:00:35 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jan 20 07:02:47 UTC 2014 TB --- 2014-01-20 07:02:47 - generating LINT kernel config TB --- 2014-01-20 07:02:47 - cd /src/sys/arm/conf TB --- 2014-01-20 07:02:47 - /usr/bin/make -B LINT TB --- 2014-01-20 07:02:47 - cd /src/sys/arm/conf TB --- 2014-01-20 07:02:47 - /usr/sbin/config -m LINT TB --- 2014-01-20 07:02:47 - building LINT kernel TB --- 2014-01-20 07:02:47 - CROSS_BUILD_TESTING=YES TB --- 2014-01-20 07:02:47 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-20 07:02:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-20 07:02:47 - SRCCONF=/dev/null TB --- 2014-01-20 07:02:47 - TARGET=arm TB --- 2014-01-20 07:02:47 - TARGET_ARCH=arm TB --- 2014-01-20 07:02:47 - TZ=UTC TB --- 2014-01-20 07:02:47 - __MAKE_CONF=/dev/null TB --- 2014-01-20 07:02:47 - cd /src TB --- 2014-01-20 07:02:47 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 20 07:02:48 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] uart_cpu_pxa.o: warning: multiple common of `uart_bus_space_mem' uart_cpu_fdt.o: warning: previous common is here uart_cpu_pxa.o: warning: multiple common of `uart_bus_space_io' uart_cpu_fdt.o: warning: previous common is here board_hl201.o: In function `board_init': /src/sys/arm/at91/board_hl201.c:(.text+0x174): undefined reference to `at91_enable_nand' board_sam9260ek.o: In function `board_init': /src/sys/arm/at91/board_sam9260ek.c:(.text+0x2a8): undefined reference to `at91_enable_nand' *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-01-20 07:19:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-20 07:19:32 - ERROR: failed to build LINT kernel TB --- 2014-01-20 07:19:32 - 9323.44 user 1842.94 system 11951.73 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 20 08:18:10 2014 Return-Path: Delivered-To: freebsd-current@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 93F293C1; Mon, 20 Jan 2014 08:18:10 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5998E1E58; Mon, 20 Jan 2014 08:18:09 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id s0K8I8GY008534; Mon, 20 Jan 2014 02:18:08 -0600 Received: from mh3.mail.rice.edu (mh3.mail.rice.edu [128.42.199.10]) by pp2.rice.edu with ESMTP id 1hfdjgggq3-1; Mon, 20 Jan 2014 02:18:08 -0600 X-Virus-Scanned: by amavis-2.7.0 at mh3.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh3.mail.rice.edu (Postfix) with ESMTPSA id A7E5F4013D; Mon, 20 Jan 2014 02:18:07 -0600 (CST) Message-ID: <52DCDBBA.7010009@rice.edu> Date: Mon, 20 Jan 2014 02:18:02 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Manfred Antar , freebsd-current@freebsd.org Subject: Re: vm_reserv.c panic on sparc64 current References: <201401200006.s0K06OfO098802@pozo.com> In-Reply-To: <201401200006.s0K06OfO098802@pozo.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.248919945447816 urlsuspect_oldscore=0.248919945447816 suspectscore=3 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.248919945447816 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401200002 Cc: alc@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 08:18:10 -0000 On 01/19/2014 18:06, Manfred Antar wrote: > vm_reserv.c starting with revision 259999 causes panic on sparc64 (netra T1 200) > version 259998 works > > backtrace: > Starting apache22. > panic: Bad link elm 0xfffff8007d4728f8 prev->next != elm > cpuid = 0 > KDB: enter: panic > [ thread pid 1965 tid 100058 ] > Stopped at kdb_enter+0x80: ta %xcc, 1 > db> bt > Tracing pid 1965 tid 100058 td 0xfffff80001880db0 > vpanic() at vpanic+0x1f8 > panic() at panic+0x20 > vm_page_dequeue() at vm_page_dequeue+0xf8 Can you provide the full contents of the struct vm_page that is being passed to vm_page_dequeue? > vm_fault_hold() at vm_fault_hold+0x54c > vm_fault() at vm_fault+0x88 > trap_pfault() at trap_pfault+0x1ac > trap() at trap+0xdc > -- data access protection tar=0x4100679c sfar=0x41006010 sfsr=0x800005 %o7=0x4062ea3c -- > userland() at 0x4062eab8 > user trace: trap %o7=0x4062ea3c > pc 0x4062eab8, sp 0x7fdffffd811 > pc 0x4062ecd0, sp 0x7fdffffd8d1 > pc 0x406397f0, sp 0x7fdffffd991 > pc 0x1121f8, sp 0x7fdffffda71 > pc 0x11bc4c, sp 0x7fdffffdb31 > pc 0x10fce8, sp 0x7fdffffdbf1 > pc 0x107e14, sp 0x7fdffffdcb1 > pc 0x106310, sp 0x7fdffffdd71 > pc 0x107160, sp 0x7fdffffde81 > pc 0x106360, sp 0x7fdffffe041 > pc 0x106284, sp 0x7fdffffe151 > pc 0x111c6c, sp 0x7fdffffe261 > pc 0x112118, sp 0x7fdffffe341 > pc 0x102bc4, sp 0x7fdffffe441 > pc 0x402258f4, sp 0x7fdffffe501 > done > > > ======================== > || null@pozo.com || > || || > ======================== > > From owner-freebsd-current@FreeBSD.ORG Mon Jan 20 12:08:36 2014 Return-Path: Delivered-To: freebsd-current@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 DE527424; Mon, 20 Jan 2014 12:08:36 +0000 (UTC) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9DD3018DD; Mon, 20 Jan 2014 12:08:36 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.95,690,1384329600"; d="asc'?scan'208";a="137976331" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx12-out.netapp.com with ESMTP; 20 Jan 2014 04:08:35 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Mon, 20 Jan 2014 04:08:35 -0800 From: "Eggert, Lars" To: John Nielsen Subject: Re: using ConnectX card as Ethernet (mlxen) Thread-Topic: using ConnectX card as Ethernet (mlxen) Thread-Index: AQHOfL84Utvue43Zsk+plvzCsSUACpldPAwAgTIBQAA= Date: Mon, 20 Jan 2014 12:08:34 +0000 Message-ID: <8D21D2EF-8A74-40A3-A49F-73FDE7C3CFD2@netapp.com> References: <3A359B33-380C-4230-A62C-623765E9376A@jnielsen.net> <201307091158.19381.jhb@freebsd.org> <2BA72819-3004-4FB6-BB4F-5964B41F6B2F@jnielsen.net> In-Reply-To: <2BA72819-3004-4FB6-BB4F-5964B41F6B2F@jnielsen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_58BC5D16-AD2E-42D7-8A70-C442B3ECA48E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 12:08:36 -0000 --Apple-Mail=_58BC5D16-AD2E-42D7-8A70-C442B3ECA48E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2013-7-9, at 22:08, John Nielsen wrote: On Jul 9, 2013, at 9:58 AM, John Baldwin wrote: >> So this was just fixed (finally) in HEAD in r253048. You can how use = the >> sysctls to change this. >=20 > I saw the commit. Thanks! I'll give it a try at some point (whenever = my schedule and hardware availability align). is this supposed to work at the moment? When I try, the machine seems to = crash: root@one:~ # sysctl sys.device.mlx4_core0.mlx4_port1=3Deth sys.device.mlx4_core0.mlx4_port1: auto (ib) Write failed: Broken pipe Shared connection to xxx closed. Unfortunately I don't have serial console access at the moment, so I = can't access any messages that may have gotten dumped. The cards in question are: mlx4_core0@pci0:17:0:0: class=3D0x028000 card=3D0x005015b3 = chip=3D0x100315b3 rev=3D0x00 hdr=3D0x00 vendor =3D 'Mellanox Technologies' device =3D 'MT27500 Family [ConnectX-3]' class =3D network Lars --Apple-Mail=_58BC5D16-AD2E-42D7-8A70-C442B3ECA48E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUt0RwtZcnpRveo1xAQLXNAP+M1r55Gqdce3kNB95Uj0BFULm97wcCI1Z Zr9FMCw/f5hwQWkTye77zKhemENce5V4mxY6deaUVWFLLW1gyEUTUZpJdn9P9gQH 3mJmilyaXoc5ie68ZCBHh+bH/hpTTJbXF64Cwwj6S0sy4uCLpFXY69hCEwSGGEr5 fzgTNBQlV7A= =DWDG -----END PGP SIGNATURE----- --Apple-Mail=_58BC5D16-AD2E-42D7-8A70-C442B3ECA48E-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 20 13:57:21 2014 Return-Path: Delivered-To: freebsd-current@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 698A1F9D for ; Mon, 20 Jan 2014 13:57:21 +0000 (UTC) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2B6ED1237 for ; Mon, 20 Jan 2014 13:57:20 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.95,690,1384329600"; d="asc'?scan'208";a="137987944" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx12-out.netapp.com with ESMTP; 20 Jan 2014 05:57:19 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Mon, 20 Jan 2014 05:57:19 -0800 From: "Eggert, Lars" To: John Nielsen Subject: Re: using ConnectX card as Ethernet (mlxen) Thread-Topic: using ConnectX card as Ethernet (mlxen) Thread-Index: AQHOfL84Utvue43Zsk+plvzCsSUACpldPAwAgTIBQACAAB5egA== Date: Mon, 20 Jan 2014 13:57:18 +0000 Message-ID: <1B2953DE-CA37-44BC-9EFE-542D13A4F576@netapp.com> References: <3A359B33-380C-4230-A62C-623765E9376A@jnielsen.net> <201307091158.19381.jhb@freebsd.org> <2BA72819-3004-4FB6-BB4F-5964B41F6B2F@jnielsen.net> <8D21D2EF-8A74-40A3-A49F-73FDE7C3CFD2@netapp.com> In-Reply-To: <8D21D2EF-8A74-40A3-A49F-73FDE7C3CFD2@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_E2AA19BE-F470-4F0F-9D09-21269771BAF8"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 13:57:21 -0000 --Apple-Mail=_E2AA19BE-F470-4F0F-9D09-21269771BAF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, if I leave the mlx4ib device out of the kernel (i.e., only compile in = mlxen), doing the sysctl switch to Ethernet mode works fine. Lars On 2014-1-20, at 13:08, Eggert, Lars wrote: > Hi, >=20 > On 2013-7-9, at 22:08, John Nielsen wrote: > On Jul 9, 2013, at 9:58 AM, John Baldwin wrote: >>> So this was just fixed (finally) in HEAD in r253048. You can how = use the >>> sysctls to change this. >>=20 >> I saw the commit. Thanks! I'll give it a try at some point (whenever = my schedule and hardware availability align). >=20 > is this supposed to work at the moment? When I try, the machine seems = to crash: >=20 > root@one:~ # sysctl sys.device.mlx4_core0.mlx4_port1=3Deth > sys.device.mlx4_core0.mlx4_port1: auto (ib) > Write failed: Broken pipe > Shared connection to xxx closed. >=20 > Unfortunately I don't have serial console access at the moment, so I = can't access any messages that may have gotten dumped. >=20 > The cards in question are: >=20 > mlx4_core0@pci0:17:0:0: class=3D0x028000 card=3D0x005015b3 = chip=3D0x100315b3 rev=3D0x00 hdr=3D0x00 > vendor =3D 'Mellanox Technologies' > device =3D 'MT27500 Family [ConnectX-3]' > class =3D network >=20 > Lars --Apple-Mail=_E2AA19BE-F470-4F0F-9D09-21269771BAF8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUt0rO9ZcnpRveo1xAQLxMgQAhRpmnEoTZ7tHJYrTwls7STnrJqlG8Yx+ Lg7EPFOhivbooRmHm53Yd/LFnPzTgJ6jxcKD0Mvn4/Ex98ZOh0MJs/mmRlO1M/0H yUYA4AEwyC7y1lRaEjaShx/ZS0b+5u8IyH7GozMzM2F5ZVW07BjKwPh8b05gxQED QWGTBeVFy7w= =FmAZ -----END PGP SIGNATURE----- --Apple-Mail=_E2AA19BE-F470-4F0F-9D09-21269771BAF8-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 20 15:36:17 2014 Return-Path: Delivered-To: current@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 6FDC234C for ; Mon, 20 Jan 2014 15:36:17 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1A95E1B28 for ; Mon, 20 Jan 2014 15:36:16 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.7/8.14.7) with ESMTP id s0KFaFVW011385 for ; Mon, 20 Jan 2014 07:36:15 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.7/8.14.7/Submit) id s0KFaFTf011384 for current@freebsd.org; Mon, 20 Jan 2014 07:36:15 -0800 (PST) (envelope-from david) Date: Mon, 20 Jan 2014 07:36:15 -0800 From: David Wolfskill To: current@freebsd.org Subject: panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx... Message-ID: <20140120153615.GS1789@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IUSVF+LtaR4kWxuH" Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 15:36:17 -0000 --IUSVF+LtaR4kWxuH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I saw this on my "build machine" after updating the "head" slice from: FreeBSD 11.0-CURRENT #1387 r260875M/260877:1100005: Sun Jan 19 11:57:25 PS= T 2014 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC= i386 to FreeBSD 11.0-CURRENT #1388 r260904M/260904:1100005: Mon Jan 20 06:25:53 PS= T 2014 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC= i386 A bit of context: On this machine and my laptop, it is my practice to perf= orm the following on a daily basis: * Ensure the machine is booted from slice 1 (stable/9). * Update the ports tree. * Update the source tree. * Start fetching any ports that are to be updated. * Update stable/9. * Reboot (staying on slice 1 -- stable/9). * Update the installed ports that warrant it ("portmaster -da --index"). * Update the sources on slice 3 (stable/10). * Remove old libraries for stable/9 ("make delete-old-libs"). * Reboot to slice 3 (stable/10). * Update stable/10. * Reboot (staying on slice 3 -- stable/10). * Update the sources on slice 4 (head). * Remove old libraries for stable/10 ("make delete-old-libs"). * Reboot to slice 4 (head) * Update head. * Reboot (staying on slice 4 -- head). * Remove old libraries for head ("make delete-old-libs"). [If a given slice didn't have source updates, I don't try to rebuild FreeBSD on it, though.] For my laptop, I then reboot to slice 1 (usually; sometimes slice 3, especially if there were no source updates for stable/9). For the build machine, I set the default boot slice back to 1, then issue "shutdown -p now" to shut it off until just before midnight. Today, there were a couple of perturbations from the above: * The only update for stable/10 I had was: U /S3/usr/src/release/doc/en_US.ISO8859-1/errata/article.xml so I decided that didn't warrant rebuilding FreeBSD stable/10. * The panic in the Subject line -- only on the build machine. Here's what I see (cut/paste) on serial console: =2E.. Jan 20 07:02:12 freebeast shutdown: power-down by david:=20 Stopping cron. Waiting for PIDS: 1090. Stopping sshd. Waiting for PIDS: 1080. Stopping rsyncd. Waiting for PIDS: 1057. Stopping powerd. Waiting for PIDS: 1042. sysctl: dev.cpu.0.freq=3D3600: Device not configured Stopping ntpd. Waiting for PIDS: 1039. Stopping lpd. Waiting for PIDS: 1018. Stopping lockd. Waiting for PIDS: 1001. Stopping statd. Waiting for PIDS: 998. Stopping nfsd. Waiting for PIDS: 994 995. Stopping mountd. Waiting for PIDS: 992. Stopping casperd. Waiting for PIDS: 951. Stopping amd. Waiting for PIDS: 943. Stopping ypbind. Stopping rpcbind. Waiting for PIDS: 916, 916. Stopping devd. Writing entropy file:. Terminated =2E Jan 20 07:02:16 freebeast syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...2 4 4 4 3 3 3 2 1 1 0 0 0 0 done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done All buffers synced. lock order reversal: 1st 0xc7336c68 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1237 2nd 0xc76846dc devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1412 KDB: stack backtrace: db_trace_self_wrapper(c112d57c,a3231,e1fb9888,c0b1bfe7,1,...) at db_trace_s= elf_wrapper+0x2d/frame 0xe1fb9828 kdb_backtrace(c1131131,c76846dc,c1124024,c6dad2d0,c1162dc1,...) at kdb_back= trace+0x30/frame 0xe1fb9890 witness_checkorder(c76846dc,9,c1162dc1,584,0,...) at witness_checkorder+0xc= 8a/frame 0xe1fb98e0 __lockmgr_args(c76846dc,80400,c76846fc,0,0,0,c1162dc1,584) at __lockmgr_arg= s+0x844/frame 0xe1fb99b4 vop_stdlock(e1fb9a28,c6dad3a0,c6dad408,c169bc38,e1fb9a4c,...) at vop_stdloc= k+0x4d/frame 0xe1fb99e4 VOP_LOCK1_APV(c13828dc,e1fb9a28,0,0,c13cded0,...) at VOP_LOCK1_APV+0x104/fr= ame 0xe1fb9a10 _vn_lock(c76846a8,80400,c1162dc1,584,c1393aac,...) at _vn_lock+0xa1/frame 0= xe1fb9a50 ffs_flushfiles(c753f000,a,c6f0a310,e1fb9b38,c0d416e3,...) at ffs_flushfiles= +0x14c/frame 0xe1fb9a9c softdep_flushfiles(c753f000,2,c6f0a310,0,0,...) at softdep_flushfiles+0x6e/= frame 0xe1fb9af0 ffs_unmount(c753f000,80000,e1fb9b70,518,c6f0a310,...) at ffs_unmount+0x194/= frame 0xe1fb9b38 dounmount(c753f000,80000,c6f0a310,0,e1db3eb0,...) at dounmount+0x4dc/frame = 0xe1fb9b98 vfs_unmountall(e1db4058,0,c112895a,144,c6d8b1a0,...) at vfs_unmountall+0x4e= /frame 0xe1fb9bb8 kern_reboot(4008,0,c112895a,c3,0,...) at kern_reboot+0x5af/frame 0xe1fb9c20 sys_reboot(c6f0a310,e1fb9cc8,14,c112b5b7,7a2,...) at sys_reboot+0x6f/frame = 0xe1fb9c40 syscall(e1fb9d08) at syscall+0x2de/frame 0xe1fb9cfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe1fb9cfc --- syscall (55, FreeBSD ELF32, sys_reboot), eip =3D 0x805a9df, esp =3D 0xb= fbfd88c, ebp =3D 0xbfbfd960 --- Uptime: 4m28s panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx @ /usr/src= /sys/dev/uart/uart_cpu.h:94 cpuid =3D 0 KDB: stack backtrace: db_trace_self_wrapper(c112d57c,2f727375,2f637273,2f737973,2f766564,...) at = db_trace_self_wrapper+0x2d/frame 0xe1fb9a60 kdb_backtrace(c12ec1f3,0,c11269a2,e1fb9b38,e1fb9b08,...) at kdb_backtrace+0= x30/frame 0xe1fb9ac8 vpanic(c140d0c8,100,c11269a2,e1fb9b38,e1fb9b38,...) at vpanic+0x11f/frame 0= xe1fb9b08 kassert_panic(c11269a2,c10f66d8,c10f6758,5e,8,...) at kassert_panic+0xea/fr= ame 0xe1fb9b2c __mtx_lock_spin_flags(c7291830,0,c10f6758,5e,c137d684,...) at __mtx_lock_sp= in_flags+0x190/frame 0xe1fb9b5c ns8250_bus_grab(c7291800,c7062b28,c137d684,5e,c140b9a4,...) at ns8250_bus_g= rab+0x40/frame 0xe1fb9b78 uart_grab(c13fd070) at uart_grab+0x83/frame 0xe1fb9b9c uart_cngrab(c137d69c,88888889,e1fb9c20,c0ac7d43,c1128e43,...) at uart_cngra= b+0x12/frame 0xe1fb9ba8 cngrab(c1128e43,1c,c112895a,144,c6d8b1a0,...) at cngrab+0x33/frame 0xe1fb9b= b8 kern_reboot(4008,0,c112895a,c3,0,...) at kern_reboot+0x6d3/frame 0xe1fb9c20 sys_reboot(c6f0a310,e1fb9cc8,14,c112b5b7,7a2,...) at sys_reboot+0x6f/frame = 0xe1fb9c40 syscall(e1fb9d08) at syscall+0x2de/frame 0xe1fb9cfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe1fb9cfc --- syscall (55, FreeBSD ELF32, sys_reboot), eip =3D 0x805a9df, esp =3D 0xb= fbfd88c, ebp =3D 0xbfbfd960 --- KDB: enter: panic [ thread pid 1 tid 100002 ] Stopped at kdb_enter+0x3d: movl $0,kdb_why db> show locks exclusive sleep mutex Giant (Giant) r =3D 0 (0xc1724910) locked @ /usr/src/= sys/vm/swap_pager.c:2365 db>=20 When I issued "reset", the machine came back up normally (in slice 1 -- stable/9). I then rebooted to slice 4 (head), and issued the same commands I usually do to set the default boot slice back to 1, then "shutdown -p now" -- and re-created the panic. I can leave the machine up for a while if anyone has suggestions for me to poke around. I have a local private mirror of the FreeBSD SVN repos and a spare bootable slice; I'm williing to try patches. The machine isn't especially fast, but it's generally OK. If it would be worthwhile, I could reboot my laptop to slice 4 (head) & attempt the same reset-to-slice-1-default & power-off. This definitely did not happen @r260875, and it appears to be quite repeatable @r260904. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --IUSVF+LtaR4kWxuH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQJ8BAEBCgBmBQJS3UJuXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk72dwP/0HRx4Y55a5Cvdr9vaEQhYMx PpgS/hs2KyNtE9rCECgLY6AkmAfvZMLF7tIkYsrODp4Bzisg1jvzrw+4T5ubxbjL KToq7gRQ7yxXTR4gOYPHiHKfPE6lSb3C6R9auV9s6RphdrTvxeSR/xPS1DlTjvhM dszaDjrHnN4HxTvYmM9LsN4p9M/x3XdNCVEZYwrLaLvliavzdt71KkmOu68qrPlX eN0BLR3XGhReV3EXOaR+h9RydRG26AxTJANrtzscfCa1U/lLDL5EFQ3JMOymIKql dckZ3IJHQCkRgm2JTK/FK4XrLthklAB+YXSWyLcL+A02gjDnQmpc54iNNlZ7Yc1F yXkfG1qcdKc0rkoi4K8vYm7kksvWwO1qsQWpdFran5KTvTDJRxUxwsxNVRn7s8Gw /DSfMT5YZtZo4pybJBQmoSiyaFxTOKTWIsnd1qlP4mKeA/8GPE0mqK48gPR3ZqZP 6FoN55NNzhB45Fqz/NeqxMtkFXn+V9NomIH8gsxOgQ+8VIz21ncBubpMLtK+5cB5 LQoF/EPn2C2DdPUNaansltNthQVJKzcwBCW/0FmmHtMXDFfwL0k7tTqsUSfgOry4 uErHw17tzNXcfccpf0OsPW2yOwu/GOxh/IsPRzA4rZKm6wiTrVmXTUY4PW/fSaH3 XKl86iyU48BmMtGRla+h =uO0i -----END PGP SIGNATURE----- --IUSVF+LtaR4kWxuH-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 20 16:38:40 2014 Return-Path: Delivered-To: current@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 23C73118 for ; Mon, 20 Jan 2014 16:38:40 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9FF79114B for ; Mon, 20 Jan 2014 16:38:39 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id s0KGbphW036946; Mon, 20 Jan 2014 18:37:51 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s0KGbphW036946 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id s0KGbpVP036945; Mon, 20 Jan 2014 18:37:51 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 20 Jan 2014 18:37:50 +0200 From: Konstantin Belousov To: David Wolfskill Subject: Re: panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx... Message-ID: <20140120163750.GC24664@kib.kiev.ua> References: <20140120153615.GS1789@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ctP54qlpMx3WjD+/" Content-Disposition: inline In-Reply-To: <20140120153615.GS1789@albert.catwhisker.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 16:38:40 -0000 --ctP54qlpMx3WjD+/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 20, 2014 at 07:36:15AM -0800, David Wolfskill wrote: > Jan 20 07:02:16 freebeast syslogd: exiting on signal 15 > Waiting (max 60 seconds) for system process `vnlru' to stop...done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining...2 4 4 4 3 3 3 2 1 1 0 0 0 0 done > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > All buffers synced. > lock order reversal: > 1st 0xc7336c68 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1237 > 2nd 0xc76846dc devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1412 > KDB: stack backtrace: > db_trace_self_wrapper(c112d57c,a3231,e1fb9888,c0b1bfe7,1,...) at db_trace= _self_wrapper+0x2d/frame 0xe1fb9828 > kdb_backtrace(c1131131,c76846dc,c1124024,c6dad2d0,c1162dc1,...) at kdb_ba= cktrace+0x30/frame 0xe1fb9890 > witness_checkorder(c76846dc,9,c1162dc1,584,0,...) at witness_checkorder+0= xc8a/frame 0xe1fb98e0 > __lockmgr_args(c76846dc,80400,c76846fc,0,0,0,c1162dc1,584) at __lockmgr_a= rgs+0x844/frame 0xe1fb99b4 > vop_stdlock(e1fb9a28,c6dad3a0,c6dad408,c169bc38,e1fb9a4c,...) at vop_stdl= ock+0x4d/frame 0xe1fb99e4 > VOP_LOCK1_APV(c13828dc,e1fb9a28,0,0,c13cded0,...) at VOP_LOCK1_APV+0x104/= frame 0xe1fb9a10 > _vn_lock(c76846a8,80400,c1162dc1,584,c1393aac,...) at _vn_lock+0xa1/frame= 0xe1fb9a50 > ffs_flushfiles(c753f000,a,c6f0a310,e1fb9b38,c0d416e3,...) at ffs_flushfil= es+0x14c/frame 0xe1fb9a9c > softdep_flushfiles(c753f000,2,c6f0a310,0,0,...) at softdep_flushfiles+0x6= e/frame 0xe1fb9af0 > ffs_unmount(c753f000,80000,e1fb9b70,518,c6f0a310,...) at ffs_unmount+0x19= 4/frame 0xe1fb9b38 > dounmount(c753f000,80000,c6f0a310,0,e1db3eb0,...) at dounmount+0x4dc/fram= e 0xe1fb9b98 > vfs_unmountall(e1db4058,0,c112895a,144,c6d8b1a0,...) at vfs_unmountall+0x= 4e/frame 0xe1fb9bb8 > kern_reboot(4008,0,c112895a,c3,0,...) at kern_reboot+0x5af/frame 0xe1fb9c= 20 > sys_reboot(c6f0a310,e1fb9cc8,14,c112b5b7,7a2,...) at sys_reboot+0x6f/fram= e 0xe1fb9c40 > syscall(e1fb9d08) at syscall+0x2de/frame 0xe1fb9cfc > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe1fb9cfc > --- syscall (55, FreeBSD ELF32, sys_reboot), eip =3D 0x805a9df, esp =3D 0= xbfbfd88c, ebp =3D 0xbfbfd960 --- > Uptime: 4m28s > panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx @ /usr/s= rc/sys/dev/uart/uart_cpu.h:94 >=20 > cpuid =3D 0 > KDB: stack backtrace: > db_trace_self_wrapper(c112d57c,2f727375,2f637273,2f737973,2f766564,...) a= t db_trace_self_wrapper+0x2d/frame 0xe1fb9a60 > kdb_backtrace(c12ec1f3,0,c11269a2,e1fb9b38,e1fb9b08,...) at kdb_backtrace= +0x30/frame 0xe1fb9ac8 > vpanic(c140d0c8,100,c11269a2,e1fb9b38,e1fb9b38,...) at vpanic+0x11f/frame= 0xe1fb9b08 > kassert_panic(c11269a2,c10f66d8,c10f6758,5e,8,...) at kassert_panic+0xea/= frame 0xe1fb9b2c > __mtx_lock_spin_flags(c7291830,0,c10f6758,5e,c137d684,...) at __mtx_lock_= spin_flags+0x190/frame 0xe1fb9b5c > ns8250_bus_grab(c7291800,c7062b28,c137d684,5e,c140b9a4,...) at ns8250_bus= _grab+0x40/frame 0xe1fb9b78 > uart_grab(c13fd070) at uart_grab+0x83/frame 0xe1fb9b9c > uart_cngrab(c137d69c,88888889,e1fb9c20,c0ac7d43,c1128e43,...) at uart_cng= rab+0x12/frame 0xe1fb9ba8 > cngrab(c1128e43,1c,c112895a,144,c6d8b1a0,...) at cngrab+0x33/frame 0xe1fb= 9bb8 > kern_reboot(4008,0,c112895a,c3,0,...) at kern_reboot+0x6d3/frame 0xe1fb9c= 20 > sys_reboot(c6f0a310,e1fb9cc8,14,c112b5b7,7a2,...) at sys_reboot+0x6f/fram= e 0xe1fb9c40 > syscall(e1fb9d08) at syscall+0x2de/frame 0xe1fb9cfc > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe1fb9cfc > --- syscall (55, FreeBSD ELF32, sys_reboot), eip =3D 0x805a9df, esp =3D 0= xbfbfd88c, ebp =3D 0xbfbfd960 --- > KDB: enter: panic > [ thread pid 1 tid 100002 ] > Stopped at kdb_enter+0x3d: movl $0,kdb_why > db> show locks > exclusive sleep mutex Giant (Giant) r =3D 0 (0xc1724910) locked @ /usr/sr= c/sys/vm/swap_pager.c:2365 > db>=20 >=20 >=20 > When I issued "reset", the machine came back up normally (in slice > 1 -- stable/9). I then rebooted to slice 4 (head), and issued the > same commands I usually do to set the default boot slice back to 1, then > "shutdown -p now" -- and re-created the panic. >=20 > I can leave the machine up for a while if anyone has suggestions for me > to poke around. I have a local private mirror of the FreeBSD SVN repos > and a spare bootable slice; I'm williing to try patches. The machine > isn't especially fast, but it's generally OK. >=20 > If it would be worthwhile, I could reboot my laptop to slice 4 (head) & > attempt the same reset-to-slice-1-default & power-off. >=20 > This definitely did not happen @r260875, and it appears to be quite > repeatable @r260904. You do not have option WITNESS_SKIPSPIN in your kernel config, do you ? --ctP54qlpMx3WjD+/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJS3VDeAAoJEJDCuSvBvK1B+3cQAJtqawq+shtNgD59zEtEemAK A4YaW0br824OCkJTdPodUHXiWUYuLJBPI/7dy9Mj4WWl9nlE4oyduwUoCOqm/NV/ SbT96DrCMju2wYkyTfxmhWi4Bsr71lMJvrPKv3TI6OS4gat6fYTx6D0hTIv7TovI s1y8y/4fAK0qu9S+kCC14P+M5WQ0BC0aBupL68zW/YVWNjGD22U3Md0dqeg5jAZE K+a+qgekgZhOMEA93Ee5nh/U/UxNKsZYD94yozgRf2izJgvBBmKmV0cdHoSbzXPF 6mM6CUdgaLwcKFepqNaP0rDBarzjC/SZZ18eXfZe93pL4FRdYmCkRoroK8M6Kdpb oSHQSjJVC4gRpuAQN8IkBE3wBb7bzsqKEf5+76EBhbbvhuFlx6Uj/WSfO4+rH67k dI53ab6P5Q/igNpBn2KncL+W3fMWjsILunYHTH2jZTEIRCDtMqNv4KYZSjVRy8jY CC/qxdz94DTeBv0GUc6EmXXX97TxFYwoDSVvMrxPE7hHfvEpTNa51txI+1EwrLP9 8d3WiGoQHnpabHRVfWz3XC9x3qBDcvRNdvkgMmov+ix7N+SuXbRiCN2PV2MCqKyN oZHS/wedwmpQglkibW8zyZppd+8u+aQX7coILMGd5BOqV4Nu7P8RzOCj2DjVWb1+ 23a4Pa0aH87tXP5WbYRt =jIba -----END PGP SIGNATURE----- --ctP54qlpMx3WjD+/-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 20 16:46:37 2014 Return-Path: Delivered-To: current@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 5F575695 for ; Mon, 20 Jan 2014 16:46:37 +0000 (UTC) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1A12A127E for ; Mon, 20 Jan 2014 16:46:37 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id if11so2879306vcb.22 for ; Mon, 20 Jan 2014 08:46:36 -0800 (PST) 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=jJ1ciaXFvoq9DGPLnerZhgfI5tyKMscmYt/p5sHy3pQ=; b=Chm1MD0ZG5JVp2G72gIB0VrakB7BqUQuENaF2tIEmpABgH1Usv+Tl/rOcxtx5gbKsA 8nMdMMWe9y+8llWAJ37jcRTAWkBdZe7SCczdHlzLD9N7Kf/CTmXHitPoL+IFNP1gaHQJ j2uNgU046A9bpVox0euqzNtLMod4GDmMxu9035XN+QE9RI//Y41H8HiSD0rbPKd7CYW7 CrNgta9GZRaKk2SN1WxcQRtMD7wpRNKoIBdzK4/umL3buQs3qZBgm8IN4O1Y0xzSr1AI JPMI8F0v1Idn5Sh8dZZGtq94DDaDNcYIl0Df2KYJtbjbxuy1kgeQXYY6EdP+O6j1BlpB isjQ== MIME-Version: 1.0 X-Received: by 10.58.201.169 with SMTP id kb9mr200493vec.42.1390236396103; Mon, 20 Jan 2014 08:46:36 -0800 (PST) Received: by 10.220.168.135 with HTTP; Mon, 20 Jan 2014 08:46:36 -0800 (PST) In-Reply-To: <20140120163750.GC24664@kib.kiev.ua> References: <20140120153615.GS1789@albert.catwhisker.org> <20140120163750.GC24664@kib.kiev.ua> Date: Mon, 20 Jan 2014 11:46:36 -0500 Message-ID: Subject: Re: panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx... From: Thomas Hoffmann To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Konstantin Belousov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 16:46:37 -0000 On Mon, Jan 20, 2014 at 11:37 AM, Konstantin Belousov wrote: > On Mon, Jan 20, 2014 at 07:36:15AM -0800, David Wolfskill wrote: > > Jan 20 07:02:16 freebeast syslogd: exiting on signal 15 > > Waiting (max 60 seconds) for system process `vnlru' to stop...done > > Waiting (max 60 seconds) for system process `syncer' to stop... > > Syncing disks, vnodes remaining...2 4 4 4 3 3 3 2 1 1 0 0 0 0 done > > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > > All buffers synced. > > lock order reversal: > > 1st 0xc7336c68 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1237 > > 2nd 0xc76846dc devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1412 > > KDB: stack backtrace: > > db_trace_self_wrapper(c112d57c,a3231,e1fb9888,c0b1bfe7,1,...) at > db_trace_self_wrapper+0x2d/frame 0xe1fb9828 > > kdb_backtrace(c1131131,c76846dc,c1124024,c6dad2d0,c1162dc1,...) at > kdb_backtrace+0x30/frame 0xe1fb9890 > > witness_checkorder(c76846dc,9,c1162dc1,584,0,...) at > witness_checkorder+0xc8a/frame 0xe1fb98e0 > > __lockmgr_args(c76846dc,80400,c76846fc,0,0,0,c1162dc1,584) at > __lockmgr_args+0x844/frame 0xe1fb99b4 > > vop_stdlock(e1fb9a28,c6dad3a0,c6dad408,c169bc38,e1fb9a4c,...) at > vop_stdlock+0x4d/frame 0xe1fb99e4 > > VOP_LOCK1_APV(c13828dc,e1fb9a28,0,0,c13cded0,...) at > VOP_LOCK1_APV+0x104/frame 0xe1fb9a10 > > _vn_lock(c76846a8,80400,c1162dc1,584,c1393aac,...) at > _vn_lock+0xa1/frame 0xe1fb9a50 > > ffs_flushfiles(c753f000,a,c6f0a310,e1fb9b38,c0d416e3,...) at > ffs_flushfiles+0x14c/frame 0xe1fb9a9c > > softdep_flushfiles(c753f000,2,c6f0a310,0,0,...) at > softdep_flushfiles+0x6e/frame 0xe1fb9af0 > > ffs_unmount(c753f000,80000,e1fb9b70,518,c6f0a310,...) at > ffs_unmount+0x194/frame 0xe1fb9b38 > > dounmount(c753f000,80000,c6f0a310,0,e1db3eb0,...) at > dounmount+0x4dc/frame 0xe1fb9b98 > > vfs_unmountall(e1db4058,0,c112895a,144,c6d8b1a0,...) at > vfs_unmountall+0x4e/frame 0xe1fb9bb8 > > kern_reboot(4008,0,c112895a,c3,0,...) at kern_reboot+0x5af/frame > 0xe1fb9c20 > > sys_reboot(c6f0a310,e1fb9cc8,14,c112b5b7,7a2,...) at > sys_reboot+0x6f/frame 0xe1fb9c40 > > syscall(e1fb9d08) at syscall+0x2de/frame 0xe1fb9cfc > > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe1fb9cfc > > --- syscall (55, FreeBSD ELF32, sys_reboot), eip = 0x805a9df, esp = > 0xbfbfd88c, ebp = 0xbfbfd960 --- > > Uptime: 4m28s > > panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx @ > /usr/src/sys/dev/uart/uart_cpu.h:94 > > > > cpuid = 0 > > KDB: stack backtrace: > > db_trace_self_wrapper(c112d57c,2f727375,2f637273,2f737973,2f766564,...) > at db_trace_self_wrapper+0x2d/frame 0xe1fb9a60 > > kdb_backtrace(c12ec1f3,0,c11269a2,e1fb9b38,e1fb9b08,...) at > kdb_backtrace+0x30/frame 0xe1fb9ac8 > > vpanic(c140d0c8,100,c11269a2,e1fb9b38,e1fb9b38,...) at > vpanic+0x11f/frame 0xe1fb9b08 > > kassert_panic(c11269a2,c10f66d8,c10f6758,5e,8,...) at > kassert_panic+0xea/frame 0xe1fb9b2c > > __mtx_lock_spin_flags(c7291830,0,c10f6758,5e,c137d684,...) at > __mtx_lock_spin_flags+0x190/frame 0xe1fb9b5c > > ns8250_bus_grab(c7291800,c7062b28,c137d684,5e,c140b9a4,...) at > ns8250_bus_grab+0x40/frame 0xe1fb9b78 > > uart_grab(c13fd070) at uart_grab+0x83/frame 0xe1fb9b9c > > uart_cngrab(c137d69c,88888889,e1fb9c20,c0ac7d43,c1128e43,...) at > uart_cngrab+0x12/frame 0xe1fb9ba8 > > cngrab(c1128e43,1c,c112895a,144,c6d8b1a0,...) at cngrab+0x33/frame > 0xe1fb9bb8 > > kern_reboot(4008,0,c112895a,c3,0,...) at kern_reboot+0x6d3/frame > 0xe1fb9c20 > > sys_reboot(c6f0a310,e1fb9cc8,14,c112b5b7,7a2,...) at > sys_reboot+0x6f/frame 0xe1fb9c40 > > syscall(e1fb9d08) at syscall+0x2de/frame 0xe1fb9cfc > > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe1fb9cfc > > --- syscall (55, FreeBSD ELF32, sys_reboot), eip = 0x805a9df, esp = > 0xbfbfd88c, ebp = 0xbfbfd960 --- > > KDB: enter: panic > > [ thread pid 1 tid 100002 ] > > Stopped at kdb_enter+0x3d: movl $0,kdb_why > > db> show locks > > exclusive sleep mutex Giant (Giant) r = 0 (0xc1724910) locked @ > /usr/src/sys/vm/swap_pager.c:2365 > > db> > > > > > > When I issued "reset", the machine came back up normally (in slice > > 1 -- stable/9). I then rebooted to slice 4 (head), and issued the > > same commands I usually do to set the default boot slice back to 1, then > > "shutdown -p now" -- and re-created the panic. > > > > I can leave the machine up for a while if anyone has suggestions for me > > to poke around. I have a local private mirror of the FreeBSD SVN repos > > and a spare bootable slice; I'm williing to try patches. The machine > > isn't especially fast, but it's generally OK. > > > > If it would be worthwhile, I could reboot my laptop to slice 4 (head) & > > attempt the same reset-to-slice-1-default & power-off. > > > > This definitely did not happen @r260875, and it appears to be quite > > repeatable @r260904 > > You do not have option WITNESS_SKIPSPIN in your kernel config, do you ? > My recent source upgrade from 10.0-RELEASE r260689 to 11.0-CURRENT r260850 left me with a GENERIC kernel with the following defined: options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed why? -Tom From owner-freebsd-current@FreeBSD.ORG Mon Jan 20 17:14:21 2014 Return-Path: Delivered-To: current@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 27978BF5; Mon, 20 Jan 2014 17:14:21 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB40A1569; Mon, 20 Jan 2014 17:14:20 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1W5IQP-000IT0-8a; Mon, 20 Jan 2014 17:14:13 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s0KHE9vq044395; Mon, 20 Jan 2014 10:14:09 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19ymoCRdQqidBB2ZRpQmWvP Subject: Re: panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx... From: Ian Lepore To: David Wolfskill In-Reply-To: <20140120153615.GS1789@albert.catwhisker.org> References: <20140120153615.GS1789@albert.catwhisker.org> Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Jan 2014 10:14:08 -0700 Message-ID: <1390238048.1230.75.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Warner Losh , current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 17:14:21 -0000 On Mon, 2014-01-20 at 07:36 -0800, David Wolfskill wrote: > I saw this on my "build machine" after updating the "head" slice from: > > FreeBSD 11.0-CURRENT #1387 r260875M/260877:1100005: Sun Jan 19 11:57:25 PST 2014 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386 > > to > > FreeBSD 11.0-CURRENT #1388 r260904M/260904:1100005: Mon Jan 20 06:25:53 PST 2014 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386 > > > A bit of context: On this machine and my laptop, it is my practice to perform the following on a daily basis: > * Ensure the machine is booted from slice 1 (stable/9). > * Update the ports tree. > * Update the source tree. > * Start fetching any ports that are to be updated. > * Update stable/9. > * Reboot (staying on slice 1 -- stable/9). > * Update the installed ports that warrant it ("portmaster -da --index"). > * Update the sources on slice 3 (stable/10). > * Remove old libraries for stable/9 ("make delete-old-libs"). > * Reboot to slice 3 (stable/10). > * Update stable/10. > * Reboot (staying on slice 3 -- stable/10). > * Update the sources on slice 4 (head). > * Remove old libraries for stable/10 ("make delete-old-libs"). > * Reboot to slice 4 (head) > * Update head. > * Reboot (staying on slice 4 -- head). > * Remove old libraries for head ("make delete-old-libs"). > > [If a given slice didn't have source updates, I don't try to rebuild > FreeBSD on it, though.] > > For my laptop, I then reboot to slice 1 (usually; sometimes slice > 3, especially if there were no source updates for stable/9). For > the build machine, I set the default boot slice back to 1, then issue > "shutdown -p now" to shut it off until just before midnight. > > Today, there were a couple of perturbations from the above: > * The only update for stable/10 I had was: > U /S3/usr/src/release/doc/en_US.ISO8859-1/errata/article.xml > > so I decided that didn't warrant rebuilding FreeBSD stable/10. > > * The panic in the Subject line -- only on the build machine. > > Here's what I see (cut/paste) on serial console: > > ... > Jan 20 07:02:12 freebeast shutdown: power-down by david: > Stopping cron. > Waiting for PIDS: 1090. > Stopping sshd. > Waiting for PIDS: 1080. > Stopping rsyncd. > Waiting for PIDS: 1057. > Stopping powerd. > Waiting for PIDS: 1042. > sysctl: dev.cpu.0.freq=3600: Device not configured > Stopping ntpd. > Waiting for PIDS: 1039. > Stopping lpd. > Waiting for PIDS: 1018. > Stopping lockd. > Waiting for PIDS: 1001. > Stopping statd. > Waiting for PIDS: 998. > Stopping nfsd. > Waiting for PIDS: 994 995. > Stopping mountd. > Waiting for PIDS: 992. > Stopping casperd. > Waiting for PIDS: 951. > Stopping amd. > Waiting for PIDS: 943. > Stopping ypbind. > Stopping rpcbind. > Waiting for PIDS: 916, 916. > Stopping devd. > Writing entropy file:. > Terminated > . > Jan 20 07:02:16 freebeast syslogd: exiting on signal 15 > Waiting (max 60 seconds) for system process `vnlru' to stop...done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining...2 4 4 4 3 3 3 2 1 1 0 0 0 0 done > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > All buffers synced. > lock order reversal: > 1st 0xc7336c68 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1237 > 2nd 0xc76846dc devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1412 > KDB: stack backtrace: > db_trace_self_wrapper(c112d57c,a3231,e1fb9888,c0b1bfe7,1,...) at db_trace_self_wrapper+0x2d/frame 0xe1fb9828 > kdb_backtrace(c1131131,c76846dc,c1124024,c6dad2d0,c1162dc1,...) at kdb_backtrace+0x30/frame 0xe1fb9890 > witness_checkorder(c76846dc,9,c1162dc1,584,0,...) at witness_checkorder+0xc8a/frame 0xe1fb98e0 > __lockmgr_args(c76846dc,80400,c76846fc,0,0,0,c1162dc1,584) at __lockmgr_args+0x844/frame 0xe1fb99b4 > vop_stdlock(e1fb9a28,c6dad3a0,c6dad408,c169bc38,e1fb9a4c,...) at vop_stdlock+0x4d/frame 0xe1fb99e4 > VOP_LOCK1_APV(c13828dc,e1fb9a28,0,0,c13cded0,...) at VOP_LOCK1_APV+0x104/frame 0xe1fb9a10 > _vn_lock(c76846a8,80400,c1162dc1,584,c1393aac,...) at _vn_lock+0xa1/frame 0xe1fb9a50 > ffs_flushfiles(c753f000,a,c6f0a310,e1fb9b38,c0d416e3,...) at ffs_flushfiles+0x14c/frame 0xe1fb9a9c > softdep_flushfiles(c753f000,2,c6f0a310,0,0,...) at softdep_flushfiles+0x6e/frame 0xe1fb9af0 > ffs_unmount(c753f000,80000,e1fb9b70,518,c6f0a310,...) at ffs_unmount+0x194/frame 0xe1fb9b38 > dounmount(c753f000,80000,c6f0a310,0,e1db3eb0,...) at dounmount+0x4dc/frame 0xe1fb9b98 > vfs_unmountall(e1db4058,0,c112895a,144,c6d8b1a0,...) at vfs_unmountall+0x4e/frame 0xe1fb9bb8 > kern_reboot(4008,0,c112895a,c3,0,...) at kern_reboot+0x5af/frame 0xe1fb9c20 > sys_reboot(c6f0a310,e1fb9cc8,14,c112b5b7,7a2,...) at sys_reboot+0x6f/frame 0xe1fb9c40 > syscall(e1fb9d08) at syscall+0x2de/frame 0xe1fb9cfc > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe1fb9cfc > --- syscall (55, FreeBSD ELF32, sys_reboot), eip = 0x805a9df, esp = 0xbfbfd88c, ebp = 0xbfbfd960 --- > Uptime: 4m28s > panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx @ /usr/src/sys/dev/uart/uart_cpu.h:94 > > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper(c112d57c,2f727375,2f637273,2f737973,2f766564,...) at db_trace_self_wrapper+0x2d/frame 0xe1fb9a60 > kdb_backtrace(c12ec1f3,0,c11269a2,e1fb9b38,e1fb9b08,...) at kdb_backtrace+0x30/frame 0xe1fb9ac8 > vpanic(c140d0c8,100,c11269a2,e1fb9b38,e1fb9b38,...) at vpanic+0x11f/frame 0xe1fb9b08 > kassert_panic(c11269a2,c10f66d8,c10f6758,5e,8,...) at kassert_panic+0xea/frame 0xe1fb9b2c > __mtx_lock_spin_flags(c7291830,0,c10f6758,5e,c137d684,...) at __mtx_lock_spin_flags+0x190/frame 0xe1fb9b5c > ns8250_bus_grab(c7291800,c7062b28,c137d684,5e,c140b9a4,...) at ns8250_bus_grab+0x40/frame 0xe1fb9b78 > uart_grab(c13fd070) at uart_grab+0x83/frame 0xe1fb9b9c > uart_cngrab(c137d69c,88888889,e1fb9c20,c0ac7d43,c1128e43,...) at uart_cngrab+0x12/frame 0xe1fb9ba8 > cngrab(c1128e43,1c,c112895a,144,c6d8b1a0,...) at cngrab+0x33/frame 0xe1fb9bb8 > kern_reboot(4008,0,c112895a,c3,0,...) at kern_reboot+0x6d3/frame 0xe1fb9c20 > sys_reboot(c6f0a310,e1fb9cc8,14,c112b5b7,7a2,...) at sys_reboot+0x6f/frame 0xe1fb9c40 > syscall(e1fb9d08) at syscall+0x2de/frame 0xe1fb9cfc > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe1fb9cfc > --- syscall (55, FreeBSD ELF32, sys_reboot), eip = 0x805a9df, esp = 0xbfbfd88c, ebp = 0xbfbfd960 --- > KDB: enter: panic > [ thread pid 1 tid 100002 ] > Stopped at kdb_enter+0x3d: movl $0,kdb_why > db> show locks > exclusive sleep mutex Giant (Giant) r = 0 (0xc1724910) locked @ /usr/src/sys/vm/swap_pager.c:2365 > db> > > > When I issued "reset", the machine came back up normally (in slice > 1 -- stable/9). I then rebooted to slice 4 (head), and issued the > same commands I usually do to set the default boot slice back to 1, then > "shutdown -p now" -- and re-created the panic. > > I can leave the machine up for a while if anyone has suggestions for me > to poke around. I have a local private mirror of the FreeBSD SVN repos > and a spare bootable slice; I'm williing to try patches. The machine > isn't especially fast, but it's generally OK. > > If it would be worthwhile, I could reboot my laptop to slice 4 (head) & > attempt the same reset-to-slice-1-default & power-off. > > This definitely did not happen @r260875, and it appears to be quite > repeatable @r260904. > > Peace, > david Since you mention serial console, I think r260890 might be a candidate. -- Ian From owner-freebsd-current@FreeBSD.ORG Mon Jan 20 17:24:05 2014 Return-Path: Delivered-To: current@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 B777CED7 for ; Mon, 20 Jan 2014 17:24:05 +0000 (UTC) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7EA53165B for ; Mon, 20 Jan 2014 17:24:05 +0000 (UTC) Received: by mail-ig0-f179.google.com with SMTP id c10so8486776igq.0 for ; Mon, 20 Jan 2014 09:24:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=jVGkI0EIEiy6XfAUZyKVVqEOLQBBFFs7S/VqZOhaMGQ=; b=YYEtEXqDMNFzcOXZ3bwxia8sNiCrMuA0Lcu7NcVHhsu6wpZ7JibD8vz02dzBBcnhUZ 0ZgKZSm0OYYE38I0gTurSx/fT8PcWfFAvn2yDQDGAhxbYbYgIACMHrc1VrOCinews6iK fdQpkXFqf56sTlpS++qjMLuk0Y/VlxuzTat4RhV44kH6muzA1zxrA3dg0BeP0BytVI66 8MulTz7T4vS3MzafEvRjvPU1+xJH3jKkCe31m2nQvX07jYTiD2baaG7SUyEaplsiiPOp /MkVgWUZIUvYv4qz9XiOn4kD0SLpNPdrKg8TVnX0l3qUcFy9i96wl/0PaSDRvduGzlIp P8VQ== X-Gm-Message-State: ALoCoQkYlSr7aDXnNEXB8SkVZgr1s8ND4FAX/LrRgYc08/PjLoTqzcGghRqJMhaHnzb4uG+2cI9D X-Received: by 10.50.232.9 with SMTP id tk9mr13585521igc.27.1390238644616; Mon, 20 Jan 2014 09:24:04 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id u1sm3848886ige.1.2014.01.20.09.24.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Jan 2014 09:24:04 -0800 (PST) Sender: Warner Losh Subject: Re: panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx... Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1390238048.1230.75.camel@revolution.hippie.lan> Date: Mon, 20 Jan 2014 10:24:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140120153615.GS1789@albert.catwhisker.org> <1390238048.1230.75.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) Cc: Warner Losh , current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 17:24:05 -0000 On Jan 20, 2014, at 10:14 AM, Ian Lepore wrote: > On Mon, 2014-01-20 at 07:36 -0800, David Wolfskill wrote: >> I saw this on my "build machine" after updating the "head" slice = from: >>=20 >> FreeBSD 11.0-CURRENT #1387 r260875M/260877:1100005: Sun Jan 19 = 11:57:25 PST 2014 = root@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386 >>=20 >> to >>=20 >> FreeBSD 11.0-CURRENT #1388 r260904M/260904:1100005: Mon Jan 20 = 06:25:53 PST 2014 = root@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386 >>=20 >>=20 >> A bit of context: On this machine and my laptop, it is my practice = to perform the following on a daily basis: >> * Ensure the machine is booted from slice 1 (stable/9). >> * Update the ports tree. >> * Update the source tree. >> * Start fetching any ports that are to be updated. >> * Update stable/9. >> * Reboot (staying on slice 1 -- stable/9). >> * Update the installed ports that warrant it ("portmaster -da = --index"). >> * Update the sources on slice 3 (stable/10). >> * Remove old libraries for stable/9 ("make delete-old-libs"). >> * Reboot to slice 3 (stable/10). >> * Update stable/10. >> * Reboot (staying on slice 3 -- stable/10). >> * Update the sources on slice 4 (head). >> * Remove old libraries for stable/10 ("make delete-old-libs"). >> * Reboot to slice 4 (head) >> * Update head. >> * Reboot (staying on slice 4 -- head). >> * Remove old libraries for head ("make delete-old-libs"). >>=20 >> [If a given slice didn't have source updates, I don't try to rebuild >> FreeBSD on it, though.] >>=20 >> For my laptop, I then reboot to slice 1 (usually; sometimes slice >> 3, especially if there were no source updates for stable/9). For >> the build machine, I set the default boot slice back to 1, then issue >> "shutdown -p now" to shut it off until just before midnight. >>=20 >> Today, there were a couple of perturbations from the above: >> * The only update for stable/10 I had was: >> U /S3/usr/src/release/doc/en_US.ISO8859-1/errata/article.xml >>=20 >> so I decided that didn't warrant rebuilding FreeBSD stable/10. >>=20 >> * The panic in the Subject line -- only on the build machine. >>=20 >> Here's what I see (cut/paste) on serial console: >>=20 >> ... >> Jan 20 07:02:12 freebeast shutdown: power-down by david:=20 >> Stopping cron. >> Waiting for PIDS: 1090. >> Stopping sshd. >> Waiting for PIDS: 1080. >> Stopping rsyncd. >> Waiting for PIDS: 1057. >> Stopping powerd. >> Waiting for PIDS: 1042. >> sysctl: dev.cpu.0.freq=3D3600: Device not configured >> Stopping ntpd. >> Waiting for PIDS: 1039. >> Stopping lpd. >> Waiting for PIDS: 1018. >> Stopping lockd. >> Waiting for PIDS: 1001. >> Stopping statd. >> Waiting for PIDS: 998. >> Stopping nfsd. >> Waiting for PIDS: 994 995. >> Stopping mountd. >> Waiting for PIDS: 992. >> Stopping casperd. >> Waiting for PIDS: 951. >> Stopping amd. >> Waiting for PIDS: 943. >> Stopping ypbind. >> Stopping rpcbind. >> Waiting for PIDS: 916, 916. >> Stopping devd. >> Writing entropy file:. >> Terminated >> . >> Jan 20 07:02:16 freebeast syslogd: exiting on signal 15 >> Waiting (max 60 seconds) for system process `vnlru' to stop...done >> Waiting (max 60 seconds) for system process `syncer' to stop... >> Syncing disks, vnodes remaining...2 4 4 4 3 3 3 2 1 1 0 0 0 0 done >> Waiting (max 60 seconds) for system process `bufdaemon' to = stop...done >> All buffers synced. >> lock order reversal: >> 1st 0xc7336c68 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1237 >> 2nd 0xc76846dc devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1412 >> KDB: stack backtrace: >> db_trace_self_wrapper(c112d57c,a3231,e1fb9888,c0b1bfe7,1,...) at = db_trace_self_wrapper+0x2d/frame 0xe1fb9828 >> kdb_backtrace(c1131131,c76846dc,c1124024,c6dad2d0,c1162dc1,...) at = kdb_backtrace+0x30/frame 0xe1fb9890 >> witness_checkorder(c76846dc,9,c1162dc1,584,0,...) at = witness_checkorder+0xc8a/frame 0xe1fb98e0 >> __lockmgr_args(c76846dc,80400,c76846fc,0,0,0,c1162dc1,584) at = __lockmgr_args+0x844/frame 0xe1fb99b4 >> vop_stdlock(e1fb9a28,c6dad3a0,c6dad408,c169bc38,e1fb9a4c,...) at = vop_stdlock+0x4d/frame 0xe1fb99e4 >> VOP_LOCK1_APV(c13828dc,e1fb9a28,0,0,c13cded0,...) at = VOP_LOCK1_APV+0x104/frame 0xe1fb9a10 >> _vn_lock(c76846a8,80400,c1162dc1,584,c1393aac,...) at = _vn_lock+0xa1/frame 0xe1fb9a50 >> ffs_flushfiles(c753f000,a,c6f0a310,e1fb9b38,c0d416e3,...) at = ffs_flushfiles+0x14c/frame 0xe1fb9a9c >> softdep_flushfiles(c753f000,2,c6f0a310,0,0,...) at = softdep_flushfiles+0x6e/frame 0xe1fb9af0 >> ffs_unmount(c753f000,80000,e1fb9b70,518,c6f0a310,...) at = ffs_unmount+0x194/frame 0xe1fb9b38 >> dounmount(c753f000,80000,c6f0a310,0,e1db3eb0,...) at = dounmount+0x4dc/frame 0xe1fb9b98 >> vfs_unmountall(e1db4058,0,c112895a,144,c6d8b1a0,...) at = vfs_unmountall+0x4e/frame 0xe1fb9bb8 >> kern_reboot(4008,0,c112895a,c3,0,...) at kern_reboot+0x5af/frame = 0xe1fb9c20 >> sys_reboot(c6f0a310,e1fb9cc8,14,c112b5b7,7a2,...) at = sys_reboot+0x6f/frame 0xe1fb9c40 >> syscall(e1fb9d08) at syscall+0x2de/frame 0xe1fb9cfc >> Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe1fb9cfc >> --- syscall (55, FreeBSD ELF32, sys_reboot), eip =3D 0x805a9df, esp =3D= 0xbfbfd88c, ebp =3D 0xbfbfd960 --- >> Uptime: 4m28s >> panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx @ = /usr/src/sys/dev/uart/uart_cpu.h:94 >>=20 >> cpuid =3D 0 >> KDB: stack backtrace: >> = db_trace_self_wrapper(c112d57c,2f727375,2f637273,2f737973,2f766564,...) = at db_trace_self_wrapper+0x2d/frame 0xe1fb9a60 >> kdb_backtrace(c12ec1f3,0,c11269a2,e1fb9b38,e1fb9b08,...) at = kdb_backtrace+0x30/frame 0xe1fb9ac8 >> vpanic(c140d0c8,100,c11269a2,e1fb9b38,e1fb9b38,...) at = vpanic+0x11f/frame 0xe1fb9b08 >> kassert_panic(c11269a2,c10f66d8,c10f6758,5e,8,...) at = kassert_panic+0xea/frame 0xe1fb9b2c >> __mtx_lock_spin_flags(c7291830,0,c10f6758,5e,c137d684,...) at = __mtx_lock_spin_flags+0x190/frame 0xe1fb9b5c >> ns8250_bus_grab(c7291800,c7062b28,c137d684,5e,c140b9a4,...) at = ns8250_bus_grab+0x40/frame 0xe1fb9b78 >> uart_grab(c13fd070) at uart_grab+0x83/frame 0xe1fb9b9c >> uart_cngrab(c137d69c,88888889,e1fb9c20,c0ac7d43,c1128e43,...) at = uart_cngrab+0x12/frame 0xe1fb9ba8 >> cngrab(c1128e43,1c,c112895a,144,c6d8b1a0,...) at cngrab+0x33/frame = 0xe1fb9bb8 >> kern_reboot(4008,0,c112895a,c3,0,...) at kern_reboot+0x6d3/frame = 0xe1fb9c20 >> sys_reboot(c6f0a310,e1fb9cc8,14,c112b5b7,7a2,...) at = sys_reboot+0x6f/frame 0xe1fb9c40 >> syscall(e1fb9d08) at syscall+0x2de/frame 0xe1fb9cfc >> Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe1fb9cfc >> --- syscall (55, FreeBSD ELF32, sys_reboot), eip =3D 0x805a9df, esp =3D= 0xbfbfd88c, ebp =3D 0xbfbfd960 --- >> KDB: enter: panic >> [ thread pid 1 tid 100002 ] >> Stopped at kdb_enter+0x3d: movl $0,kdb_why >> db> show locks >> exclusive sleep mutex Giant (Giant) r =3D 0 (0xc1724910) locked @ = /usr/src/sys/vm/swap_pager.c:2365 >> db>=20 >>=20 >>=20 >> When I issued "reset", the machine came back up normally (in slice >> 1 -- stable/9). I then rebooted to slice 4 (head), and issued the >> same commands I usually do to set the default boot slice back to 1, = then >> "shutdown -p now" -- and re-created the panic. >>=20 >> I can leave the machine up for a while if anyone has suggestions for = me >> to poke around. I have a local private mirror of the FreeBSD SVN = repos >> and a spare bootable slice; I'm williing to try patches. The machine >> isn't especially fast, but it's generally OK. >>=20 >> If it would be worthwhile, I could reboot my laptop to slice 4 (head) = & >> attempt the same reset-to-slice-1-default & power-off. >>=20 >> This definitely did not happen @r260875, and it appears to be quite >> repeatable @r260904. >>=20 >> Peace, >> david >=20 > Since you mention serial console, I think r260890 might be a = candidate. I'm pretty sure that it is. I'll take a look at it. Warner= From owner-freebsd-current@FreeBSD.ORG Mon Jan 20 17:47:21 2014 Return-Path: Delivered-To: current@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 DB227290 for ; Mon, 20 Jan 2014 17:47:21 +0000 (UTC) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A4486186B for ; Mon, 20 Jan 2014 17:47:21 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id e14so8651167iej.3 for ; Mon, 20 Jan 2014 09:47:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=QUCxvN9R5rwdj5Fz1YM9UshyuWx40YXpsKLWUF0nb6Y=; b=CB5QxR1kM39SVUjszkSuIABkycUNHya2NnH21sZ1cCdywAMxsdqh9v48yLtfx3m/aa 7F9qQ3MI4ID3Wtb6vXJ6TOvvSr6leIgQhSXwnIYvTH9av90khNRxpObIQEa3VIsP+wxq RoO6BAGYFL0XJITeJUGvl/dja4atzfcbPjccEZUsNFTneFNywoTaZjs9GIKL1yi+z8ou metKWQ8WvnVpfaBqmP/Bq4VgHXydw9Lv2ZzbB/pJTJD6jRUxbX/K722wQvsfhYYgYCVO TEmJ4thuBxsevUdehYEIxFXvGrMX1iRMtju1DGO3C4fkiaMm9U+QWqytWXuJNzX4Nldj 6JQw== X-Gm-Message-State: ALoCoQnTMRMKxn2oXP15UlGktBsczkaDlcRfciFItpPf9IzUyQcHYgn3RG3ihUDgp9aRMCe5cB45 X-Received: by 10.42.232.206 with SMTP id jv14mr2518690icb.52.1390240035517; Mon, 20 Jan 2014 09:47:15 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id fk5sm3978845igb.9.2014.01.20.09.47.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Jan 2014 09:47:15 -0800 (PST) Sender: Warner Losh Subject: Re: panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx... Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1390238048.1230.75.camel@revolution.hippie.lan> Date: Mon, 20 Jan 2014 10:47:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <76191F53-3C1F-4175-AE9C-1D9FD1B1F0CA@bsdimp.com> References: <20140120153615.GS1789@albert.catwhisker.org> <1390238048.1230.75.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) Cc: Warner Losh , current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 17:47:21 -0000 > On Mon, 2014-01-20 at 07:36 -0800, David Wolfskill wrote: >> panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx @ = /usr/src/sys/dev/uart/uart_cpu.h:94 >=20 > Since you mention serial console, I think r260890 might be a = candidate. I have a fix for this. I committed the wrong version of uart_core.c. = r260911 should fix this. So this is broken from r260890-r260910. Warner= From owner-freebsd-current@FreeBSD.ORG Mon Jan 20 18:33:42 2014 Return-Path: Delivered-To: current@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 EEA899A2; Mon, 20 Jan 2014 18:33:42 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 980401D61; Mon, 20 Jan 2014 18:33:42 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.7/8.14.7) with ESMTP id s0KIXfls013512; Mon, 20 Jan 2014 10:33:41 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.7/8.14.7/Submit) id s0KIXfMN013511; Mon, 20 Jan 2014 10:33:41 -0800 (PST) (envelope-from david) Date: Mon, 20 Jan 2014 10:33:41 -0800 From: David Wolfskill To: current@freebsd.org Subject: Re: panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx... Message-ID: <20140120183341.GU1789@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="QHhm1I6mwQR20oIa" Content-Disposition: inline In-Reply-To: <76191F53-3C1F-4175-AE9C-1D9FD1B1F0CA@bsdimp.com> <1390238048.1230.75.camel@revolution.hippie.lan> <20140120163750.GC24664@kib.kiev.ua> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Warner Losh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 18:33:43 -0000 --QHhm1I6mwQR20oIa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 20, 2014 at 06:37:50PM +0200, Konstantin Belousov wrote: > ... > You do not have option WITNESS_SKIPSPIN in your kernel config, do you ? It was a GENERIC kernel for i386; it has WITNESS_SKIPSPIN. On Mon, Jan 20, 2014 at 10:14:08AM -0700, Ian Lepore wrote: > ... > Since you mention serial console, I think r260890 might be a candidate. Good call. :-} On Mon, Jan 20, 2014 at 10:24:01AM -0700, Warner Losh wrote: > ...=20 > I'm pretty sure that it is. I'll take a look at it. On Mon, Jan 20, 2014 at 10:47:12AM -0700, Warner Losh wrote: > ... > I have a fix for this. I committed the wrong version of uart_core.c. r260= 911 should fix this. So this is broken from r260890-r260910. > .... So I see. I'll hand-apply that, rebuild the kernel, and give it a shot, Thanks, all! :-) Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --QHhm1I6mwQR20oIa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQJ8BAEBCgBmBQJS3WwEXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7la0QAJwxjbzuItH9CocdYlOQ8nYF MlSmbnDSzdwj6qtYkKXkg85oN6BRAOjSd2WffG36O0THASYZCXkX5sFqWglkzC0a PL9JpIgAXJlH9inpf6fxxgcc5mc3BwcCtDytXSJ8rFBivwSR7mR+HaUA+PxIPc41 /dztWZkON5Vzw+RH0TwjFATOa3bvRU2/z2YvFLM/tfIO+J6+/Q3Q845vMQz4O9OD Kfhdzvd5feLjI5YXEaqVtdaJckpTrYYHrIFEX7p6D8iKCJDGOuRoHxK8wup8jBKS CAC9eaHCQRRkVY2O5//gNO+pH+oFsWh2MKLP37F3rENlQ692u8ztrs71vm+62iWZ TxOp6EniUsPgESqmYq0G6sA7PhLaVum4i1qPZxKAu3oOy65vnGftmbRiWWtOP59l 4cpjxDVf0OvpgEXwPcVV7IM4eJ3biBcF5XRYtwTkBIsN6lDsH06r937xHtuXv6M3 63Za0TF9NU2JIl2QZ87T++WNMIt2YHjliM60WNvHwkMcvYL/K/L8TFXjSs18lKvN dbDwdwQjmoBXV5AzpP8DVmTaVfBS+HKrZ2MAD+bKAKWNP/bUppW+Omp4ep/VIpP1 s5my2n/iNQ03PcxoEXVGAXcn6abb4c7uSPMbGjQR0CY0nkTeKv5hQasKiBU62gxJ O5DGdoChIpt92OePBkux =SNaE -----END PGP SIGNATURE----- --QHhm1I6mwQR20oIa-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 20 18:55:28 2014 Return-Path: Delivered-To: current@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 F13D9C1C; Mon, 20 Jan 2014 18:55:27 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AE3EC1F5E; Mon, 20 Jan 2014 18:55:27 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.7/8.14.7) with ESMTP id s0KItQZd013848; Mon, 20 Jan 2014 10:55:26 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.7/8.14.7/Submit) id s0KItQ28013847; Mon, 20 Jan 2014 10:55:26 -0800 (PST) (envelope-from david) Date: Mon, 20 Jan 2014 10:55:26 -0800 From: David Wolfskill To: current@freebsd.org Subject: Re: panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx... Message-ID: <20140120185526.GW1789@albert.catwhisker.org> References: <76191F53-3C1F-4175-AE9C-1D9FD1B1F0CA@bsdimp.com> <1390238048.1230.75.camel@revolution.hippie.lan> <20140120163750.GC24664@kib.kiev.ua> <20140120183341.GU1789@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4WCFFtl4AQpQKunj" Content-Disposition: inline In-Reply-To: <20140120183341.GU1789@albert.catwhisker.org> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Warner Losh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 18:55:28 -0000 --4WCFFtl4AQpQKunj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 20, 2014 at 10:33:41AM -0800, David Wolfskill wrote: > ... > On Mon, Jan 20, 2014 at 10:47:12AM -0700, Warner Losh wrote: > > ... > > I have a fix for this. I committed the wrong version of uart_core.c. r2= 60911 should fix this. So this is broken from r260890-r260910. > > .... >=20 > So I see. I'll hand-apply that, rebuild the kernel, and give it a shot, >=20 > Thanks, all! :-) > .... We have a winner! Ref.: =2E.. Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe1fb9cfc --- syscall (55, FreeBSD ELF32, sys_reboot), eip =3D 0x805a9df, esp =3D 0xb= fbfd88c, ebp =3D 0xbfbfd960 --- Uptime: 5m15s usbus0: Controller shutdown uhub0: at usbus0, port 1, addr 1 (disconnected) usbus0: Controller shutdown complete usbus1: Controller shutdown uhub1: at usbus1, port 1, addr 1 (disconnected) usbus1: Controller shutdown complete usbus2: Controller shutdown uhub2: at usbus2, port 1, addr 1 (disconnected) usbus2: Controller shutdown complete usbus3: Controller shutdown uhub3: at usbus3, port 1, addr 1 (disconnected) usbus3: Controller shutdown complete usbus4: Controller shutdown uhub4: at usbus4, port 1, addr 1 (disconnected) usbus4: Controller shutdown complete aac0: shutting down controller...done acpi0: Powering system off Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --4WCFFtl4AQpQKunj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQJ8BAEBCgBmBQJS3XEdXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7HDUQAJ+l8YhbnpMciEACq+6x2Q4Z v87oMDcrKTLHcOIbXZRspcxDn7ygqBCQP9Avo2WLezOlYblyTGgzxncBRf7ZHxsA lDlqMjsP6UVERjjYOovAALkUwXaD0aFM+NHXHC9T8ZY+vyG+aEGecvEP4SiV7VOE ILqD7OeWZ6JBAxd4V52MZZav9datE7wI1QNSSxT27FWRtyYgfzEH2lc1jOrZvAR+ egbvzMq6c+qAJhfaJo3PEQdTi1taL0P/PhbEMrw07k0r1I3noOFbN6wZchM7bhfG 4S4KEWkjrMTxHIxH6IwuViQEIbKGPo72TH9UNyiMOrLimWJZjvHI+WGFTKr5qWD3 vguTATEcrnDx4QSTFX+5hg1n4npjRBPU4lRb71/eCl4RNm9T1+CA00wzBJS6XmTn zIQFkduvLlNzlRLXFkhrBKDWdweypzwoyKgWzgYoXWniDPs/hDr86lmsLRrWqf5y D6uTynJXRwv7NK1R5RjloniZRYssELR99xlTXxbjsV4hnYgrmIOtMgkLlAIswW7c 3EmLrth3RmZXV0xisY6dtOKCdm8WDjJSns457LqpaIvd8ytVBJz++PwEg8sD8T7v 4LjIQ/mtA3tX2zLtGFl/ns49mYEEEo/CozyxZnk18MBa3MTY9exLavgNIzswUu/f l5oT9Ugym86Qjg/UpJEe =nRs6 -----END PGP SIGNATURE----- --4WCFFtl4AQpQKunj-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 20 19:10:18 2014 Return-Path: Delivered-To: current@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 364F0363; Mon, 20 Jan 2014 19:10:18 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0BB0610F6; Mon, 20 Jan 2014 19:10:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id s0KJAGvJ043733; Mon, 20 Jan 2014 14:10:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s0KJAGjO043722; Mon, 20 Jan 2014 19:10:16 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 20 Jan 2014 19:10:16 GMT Message-Id: <201401201910.s0KJAGjO043722@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 19:10:18 -0000 TB --- 2014-01-20 15:50:22 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-01-20 15:50:22 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-01-20 15:50:22 - starting HEAD tinderbox run for arm/arm TB --- 2014-01-20 15:50:22 - cleaning the object tree TB --- 2014-01-20 15:51:45 - /usr/local/bin/svn stat /src TB --- 2014-01-20 15:51:48 - At svn revision 260909 TB --- 2014-01-20 15:51:49 - building world TB --- 2014-01-20 15:51:49 - CROSS_BUILD_TESTING=YES TB --- 2014-01-20 15:51:49 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-20 15:51:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-20 15:51:49 - SRCCONF=/dev/null TB --- 2014-01-20 15:51:49 - TARGET=arm TB --- 2014-01-20 15:51:49 - TARGET_ARCH=arm TB --- 2014-01-20 15:51:49 - TZ=UTC TB --- 2014-01-20 15:51:49 - __MAKE_CONF=/dev/null TB --- 2014-01-20 15:51:49 - cd /src TB --- 2014-01-20 15:51:49 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Jan 20 15:51:56 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jan 20 18:53:38 UTC 2014 TB --- 2014-01-20 18:53:38 - generating LINT kernel config TB --- 2014-01-20 18:53:38 - cd /src/sys/arm/conf TB --- 2014-01-20 18:53:38 - /usr/bin/make -B LINT TB --- 2014-01-20 18:53:38 - cd /src/sys/arm/conf TB --- 2014-01-20 18:53:38 - /usr/sbin/config -m LINT TB --- 2014-01-20 18:53:39 - building LINT kernel TB --- 2014-01-20 18:53:39 - CROSS_BUILD_TESTING=YES TB --- 2014-01-20 18:53:39 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-20 18:53:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-20 18:53:39 - SRCCONF=/dev/null TB --- 2014-01-20 18:53:39 - TARGET=arm TB --- 2014-01-20 18:53:39 - TARGET_ARCH=arm TB --- 2014-01-20 18:53:39 - TZ=UTC TB --- 2014-01-20 18:53:39 - __MAKE_CONF=/dev/null TB --- 2014-01-20 18:53:39 - cd /src TB --- 2014-01-20 18:53:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 20 18:53:39 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] uart_cpu_pxa.o: warning: multiple common of `uart_bus_space_mem' uart_cpu_fdt.o: warning: previous common is here uart_cpu_pxa.o: warning: multiple common of `uart_bus_space_io' uart_cpu_fdt.o: warning: previous common is here board_hl201.o: In function `board_init': /src/sys/arm/at91/board_hl201.c:(.text+0x174): undefined reference to `at91_enable_nand' board_sam9260ek.o: In function `board_init': /src/sys/arm/at91/board_sam9260ek.c:(.text+0x2a8): undefined reference to `at91_enable_nand' *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-01-20 19:10:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-20 19:10:16 - ERROR: failed to build LINT kernel TB --- 2014-01-20 19:10:16 - 9319.49 user 1835.60 system 11993.62 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 20 19:32:05 2014 Return-Path: Delivered-To: freebsd-current@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 2EDE7BD3 for ; Mon, 20 Jan 2014 19:32:05 +0000 (UTC) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E14CC12A0 for ; Mon, 20 Jan 2014 19:32:04 +0000 (UTC) Received: by mail-vc0-f179.google.com with SMTP id ia6so2972774vcb.24 for ; Mon, 20 Jan 2014 11:32:04 -0800 (PST) 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=764ECnVr6KF/xCmqC5f3vL83xblzQDPEa0bp60ODj7Y=; b=LFeUfTzDt0v6JqwLaJBOV8hQarAhlCCQsRChj+Pq+eJFKX7XCGAI1igz73qsIzLPtr ejiRxrOPNp4TSigj6CreinA8645WWIm4GNH5drOorkly25YkBfsKXEJrhTnKINtTeRz8 BGbbKGkuN8XnXreXR2WGHaCFx1CMpvxmgGV38ESN+4oZXm0NfNUyUNI6XXa78sLp7wx+ ppBYxpAp3ehk5JpnjX79JNQ646yAo2NGs7xX5f+isO9bFV+W+gxS4keTB/XOGmw3pU3A gkEm9QmE1hSk1K/YWCls2qnu31xcXZWbOz1X5jEjb0lt2ehq1US2zrtuUJkTbKUAJMOA 0qfw== MIME-Version: 1.0 X-Received: by 10.58.187.98 with SMTP id fr2mr58623vec.38.1390246324030; Mon, 20 Jan 2014 11:32:04 -0800 (PST) Received: by 10.220.168.135 with HTTP; Mon, 20 Jan 2014 11:32:03 -0800 (PST) Date: Mon, 20 Jan 2014 14:32:03 -0500 Message-ID: Subject: Problem updating bootcode on ZFS on root system with MBR From: Thomas Hoffmann To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 19:32:05 -0000 I am running 11.0-CURRENT (r260850) with zfs on root with MBR. After upgrading my 10.0-RELEASE (r260669) system to 11.0-CURRENT (r260850) my zpools reported that they needed to be upgraded. So, I upgraded my zpools and I am attempting to update the bootcode (as required). I managed to get the boot1 stage code updated, but cannot get the boot2 stage code updated. Here is what I have done: # sysctl kern.geom.debugflags=0x10 kern.geom.debugflags: 0 -> 16 # dd if=/boot/zfsboot of=/tmp/zfsboot1 count=1 1+0 records in 1+0 records out 512 bytes transferred in 0.014996 secs (34142 bytes/sec) # gpart bootcode -b /tmp/zfsboot1 /dev/ada0s1 bootcode written to ada0s1 # dd if=/boot/zfsboot of=/dev/ada0s1a skip=1 seek=1024 dd: /dev/ada0s1a: Operation not permitted The final dd statement fails with "operation not permitted". In all my research, understood the initial sysctl command I ran would prevent this particular error from happening. What do I need to do to get the boot2 code written to /dev/ada0s1a? Thanks. -Tom From owner-freebsd-current@FreeBSD.ORG Mon Jan 20 21:24:36 2014 Return-Path: Delivered-To: freebsd-current@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 6D2D7EC7 for ; Mon, 20 Jan 2014 21:24:36 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 425AE1D2F for ; Mon, 20 Jan 2014 21:24:36 +0000 (UTC) Received: from pippin.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 484E8B97B; Mon, 20 Jan 2014 16:24:35 -0500 (EST) From: John Baldwin To: "Eggert, Lars" Subject: Re: using ConnectX card as Ethernet (mlxen) Date: Mon, 20 Jan 2014 15:59:43 -0500 Message-ID: <1536242.pn1tTPOXXc@pippin.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/11.0-CURRENT; KDE/4.10.5; amd64; ; ) In-Reply-To: <8D21D2EF-8A74-40A3-A49F-73FDE7C3CFD2@netapp.com> References: <3A359B33-380C-4230-A62C-623765E9376A@jnielsen.net> <2BA72819-3004-4FB6-BB4F-5964B41F6B2F@jnielsen.net> <8D21D2EF-8A74-40A3-A49F-73FDE7C3CFD2@netapp.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 20 Jan 2014 16:24:35 -0500 (EST) Cc: "freebsd-current@freebsd.org" , John Nielsen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 21:24:36 -0000 On Monday 20 January 2014 12:08:34 Eggert, Lars wrote: > Hi, > > On 2013-7-9, at 22:08, John Nielsen wrote: > > On Jul 9, 2013, at 9:58 AM, John Baldwin wrote: > >> So this was just fixed (finally) in HEAD in r253048. You can how use the > >> sysctls to change this. > > > > I saw the commit. Thanks! I'll give it a try at some point (whenever my > > schedule and hardware availability align). > is this supposed to work at the moment? When I try, the machine seems to > crash: > > root@one:~ # sysctl sys.device.mlx4_core0.mlx4_port1=eth > sys.device.mlx4_core0.mlx4_port1: auto (ib) > Write failed: Broken pipe > Shared connection to xxx closed. > > Unfortunately I don't have serial console access at the moment, so I can't > access any messages that may have gotten dumped. > > The cards in question are: > > mlx4_core0@pci0:17:0:0: class=0x028000 card=0x005015b3 chip=0x100315b3 > rev=0x00 hdr=0x00 vendor = 'Mellanox Technologies' > device = 'MT27500 Family [ConnectX-3]' > class = network I believe this should work, yes. Getting a crashdump or the panic messages would be really helpful in figuring out why it isn't. Thanks. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 03:23:35 2014 Return-Path: Delivered-To: freebsd-current@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 819A7719 for ; Tue, 21 Jan 2014 03:23:35 +0000 (UTC) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 41FB419C9 for ; Tue, 21 Jan 2014 03:23:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=2lZUEe4ejLct5g08auejqiRTMgZkC1TY+rRZ8YA/tSw=; b=JyuwVFb8XCil3gXJQEF2++hz1gwpPF0ro32r8hEo0kelmH+D2TYfUVtGl9k6wkqsdSJHLu8xBG+InkSUYvuC5blQ1/hkk3Rokw+mMVrFGb/gfhF9ZQ51TpEYZTuiPQtm9U5/+bqyVoDatCLht6YBv3HOriNL7QvZCH5LduqpuRk=; Received: from 107-128-180-255.lightspeed.austtx.sbcglobal.net ([107.128.180.255]:45242 helo=borg.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1W5Rw0-0001AX-9G for freebsd-current@freebsd.org; Mon, 20 Jan 2014 21:23:34 -0600 Date: Mon, 20 Jan 2014 21:23:16 -0600 From: Larry Rosenman To: freebsd-current@freebsd.org Subject: Panic/Solaris Assert/ZAP.c:534 Message-ID: <20140121032316.GA1773@borg.lerctr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Score: 3.1 (+++) X-LERCTR-Spam-Score: 3.1 (+++) X-Spam-Report: SpamScore (3.1/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, FH_RANDOM_SURE=0.5, KAM_STOCKTIP=5.5, TVD_RCVD_IP=0.001 X-LERCTR-Spam-Report: SpamScore (3.1/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, FH_RANDOM_SURE=0.5, KAM_STOCKTIP=5.5, TVD_RCVD_IP=0.001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 03:23:35 -0000 Ideas? I'm getting this on a regular basis, and scrub/etc doesn't seem to get around it, but booting off: FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #113 r260864: Fri Jan 17 19:10:06 CST 2014 root@:/usr/obj/usr/src/sys/BORG-DTRACE amd64 Seems to avoid it. HELP. borg.lerctr.org dumped core - see /var/crash/vmcore.1 Mon Jan 20 21:18:41 CST 2014 FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r260896: Mon Jan 20 12:31:46 CST 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 panic: solaris assert: l->l_phys->l_hdr.lh_block_type == ((1ULL << 63) + 0) (0x0 == 0x8000000000000000), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c, line: 534 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: Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #1 r260896: Mon Jan 20 12:31:46 CST 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 info: [drm] Initialized drm 1.1.0 20060810 CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (2327.55-MHz K8-class CPU) Origin="GenuineIntel" Id=0x10676 Family=0x6 Model=0x17 Stepping=6 Features=0xbfebfbff Features2=0xce3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 68719476736 (65536 MB) avail memory = 65641644032 (62600 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard random: initialized kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) unknown: I/O range not supported cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 350 Event timer "HPET1" frequency 14318180 Hz quality 340 Event timer "HPET2" frequency 14318180 Hz quality 340 atrtc0: port 0x70-0x71 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 pcib5: at device 0.2 on pci3 pci5: on pcib5 pcib6: irq 18 at device 2.0 on pci2 pci6: on pcib6 em0: port 0x2000-0x201f mem 0xd9220000-0xd923ffff,0xd9200000-0xd921ffff irq 18 at device 0.0 on pci6 em0: Using an MSI interrupt em0: Ethernet address: 00:30:48:f2:29:9c em1: port 0x2020-0x203f mem 0xd9260000-0xd927ffff,0xd9240000-0xd925ffff irq 19 at device 0.1 on pci6 em1: Using an MSI interrupt em1: Ethernet address: 00:30:48:f2:29:9d pcib7: at device 0.3 on pci1 pci7: on pcib7 pcib8: at device 4.0 on pci0 pci8: on pcib8 vgapci0: port 0x3000-0x307f mem 0xd8000000-0xd8ffffff,0xc0000000-0xc7ffffff,0xc8000000-0xc9ffffff irq 16 at device 0.0 on pci8 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io hdac0: mem 0xd9000000-0xd9003fff irq 17 at device 0.1 on pci8 pcib9: at device 6.0 on pci0 pci9: on pcib9 pci0: at device 8.0 (no driver attached) pcib10: irq 17 at device 28.0 on pci0 pci10: on pcib10 pcib11: irq 16 at device 0.0 on pci10 pci11: on pcib11 pcm0: port 0x4080-0x409f,0x4000-0x407f irq 16 at device 0.0 on pci11 pcm0: system configuration SubVendorID: 0x1412, SubDeviceID: 0x2403 XIN2 Clock Source: 24.576MHz(96kHz*256) MPU-401 UART(s) #: not implemented ADC #: 1 and SPDIF receiver connected DAC #: 4 Multi-track converter type: AC'97(SDATA_OUT:packed) S/PDIF(IN/OUT): 1/1 ID# 0x00 GPIO(mask/dir/state): 0xff/0xff/0xff uhci0: port 0x1800-0x181f irq 17 at device 29.0 on pci0 usbus0 on uhci0 uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 usbus1 on uhci1 uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 usbus2 on uhci2 ehci0: mem 0xd9600400-0xd96007ff irq 17 at device 29.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib12: at device 30.0 on pci0 pci12: on pcib12 vgapci1: port 0x5000-0x50ff mem 0xd0000000-0xd7ffffff,0xd9300000-0xd930ffff irq 18 at device 1.0 on pci12 drmn1: on vgapci1 info: [drm] RADEON_IS_PCI info: [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080). info: [drm] register mmio base: 0xD9300000 info: [drm] register mmio size: 65536 info: [drm] radeon_atrm_get_bios: ===> Try ATRM... info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:8:0:0, vendor=10de, device=104a info: [drm] radeon_atrm_get_bios: Get ACPI device handle info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0xd0000000 info: [drm] igp_read_bios_from_vram: Map address: 0xfffff800d0000000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x0000 info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] radeon_read_bios: Map address: 0xfffff800000c0000 (131072 bytes) drmn1: info: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used) drmn1: info: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] radeon: irq initialized. info: [drm] Detected VRAM RAM=128M, BAR=128M info: [drm] RAM width 64bits SDR [TTM] Zone kernel: Available graphics memory: 33006090 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator info: [drm] radeon: 16M of VRAM memory ready info: [drm] radeon: 512M of GTT memory ready. info: [drm] GART: num cpu pages 131072, num gpu pages 131072 info: [drm] PCI GART of 512M enabled (table at 0x0000000011200000). drmn1: info: WB disabled drmn1: info: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0x0xfffff8001083c000 info: [drm] Loading R100 Microcode info: [drm] radeon: ring at 0x00000000B0001000 info: [drm] ring test succeeded in 1 usecs info: [drm] ib test succeeded in 0 usecs info: [drm] radeon_device_init: Taking over the fictitious range 0xd0000000-0xd4000000 iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iicbus1: on iicbb1 addr 0xff iic1: on iicbus1 iicbus2: on iicbb2 addr 0xff iic2: on iicbus2 iicbus3: on iicbb3 addr 0xff iic3: on iicbus3 info: [drm] Radeon Display Connectors info: [drm] Connector 0: info: [drm] VGA-1 info: [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60 info: [drm] Encoders: info: [drm] CRT1: INTERNAL_DAC1 info: [drm] Connector 1: info: [drm] DVI-I-1 info: [drm] HPD2 info: [drm] DDC: 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c info: [drm] Encoders: info: [drm] CRT2: INTERNAL_DAC2 info: [drm] DFP2: INTERNAL_DVO1 composite sync not supported composite sync not supported info: [drm] fb mappable at 0xD0040000 info: [drm] vram apper at 0xD0000000 info: [drm] size 2076672 info: [drm] fb depth is 8 info: [drm] pitch is 1920 fbd1 on drmn1 vt_allocate: Replace existing VT driver. info: [drm] Initialized radeon 2.29.0 20080528 vgapci1: Boot video device isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: at channel 0 on atapci0 ahci0: port 0x18a0-0x18a7,0x1874-0x1877,0x1878-0x187f,0x1870-0x1873,0x1880-0x189f mem 0xd9600800-0xd9600bff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ichsmb0: port 0x1100-0x111f irq 19 at device 31.3 on pci0 smbus0: on ichsmb0 acpi_button0: on acpi0 ipmi0: port 0xca2-0xca3 on acpi0 ipmi0: KCS mode found at io 0xca2 on acpi atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ichwd0 on isa0 orm0: at iomem 0xc0000-0xcafff on isa0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 coretemp4: on cpu4 est4: on cpu4 p4tcc4: on cpu4 coretemp5: on cpu5 est5: on cpu5 p4tcc5: on cpu5 coretemp6: on cpu6 est6: on cpu6 p4tcc6: on cpu6 coretemp7: on cpu7 est7: on cpu7 p4tcc7: on cpu7 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x387 offMax=0x491 hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm1: at nid 4 on hdaa0 pcm2: at nid 5 on hdaa0 random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen3.1: at usbus3 uhub0: on usbus3 ugen2.1: at usbus2 uhub1: on usbus2 ugen1.1: at usbus1 uhub2: on usbus1 ugen0.1: at usbus0 uhub3: on usbus0 ipmi0: IPMI device rev. 1, firmware rev. 1.64, version 2.0 ata0: DMA limited to UDMA33, controller found non-ATA66 cable ipmi0: Number of channels 8 ipmi0: Attached watchdog uhub2: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: Serial Number 5YDA1ZL4 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus2 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: Serial Number 5YD6FPLG ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada1: quirks=0x1<4K> ada1: Previously was known as ad6 ada2 at ahcich2 bus 0 scbus3 target 0 lun 0 ada2: ATA-8 SATA 3.x device ada2: Serial Number 5YDA3PC5 ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada2: quirks=0x1<4K> ada2: Previously was known as ad8 ada3 at ahcich3 bus 0 scbus4 target 0 lun 0 ada3: ATA-8 SATA 3.x device ada3: Serial Number 5YD9Y0P4 ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3: quirks=0x1<4K> ada3: Previously was known as ad10 ada4 at ahcich4 bus 0 scbus5 target 0 lun 0 ada4: ATA-8 SATA 3.x device ada4: Serial Number 5YDA1R5W ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada4: quirks=0x1<4K> ada4: Previously was known as ad12 ada5 at ahcich5 bus 0 scbus6 target 0 lun 0 ada5: ATA-8 SATA 3.x device ada5: Serial Number 5YD5RBS8 ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada5: quirks=0x1<4K> ada5: Previously was known as ad14 cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present Netvsc initializing... done! SMP: AP CPU #6 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #3 Launched! Root mount waiting for: usbus3 uhub0: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 Root mount waiting for: usbus3 ugen3.2: at usbus3 ukbd0: on usbus3 kbd2 at ukbd0 Trying to mount root from zfs:zroot/ROOT/default []... ugen0.2: at usbus0 ugen1.2: at usbus1 <118>Setting hostuuid: 53d19f64-d663-a017-8922-0030488e9ff3. <118>Setting hostid: 0xf53a926e. <118>Entropy harvesting: interrupts ethernet point_to_point swi. <118>Starting file system checks: <118>Mounting local file systems:. panic: solaris assert: l->l_phys->l_hdr.lh_block_type == ((1ULL << 63) + 0) (0x0 == 0x8000000000000000), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c, line: 534 cpuid = 7 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe100c499090 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe100c499140 vpanic() at vpanic+0x126/frame 0xfffffe100c499180 panic() at panic+0x43/frame 0xfffffe100c4991e0 assfail3() at assfail3+0x2f/frame 0xfffffe100c499200 zap_get_leaf_byblk() at zap_get_leaf_byblk+0x4e1/frame 0xfffffe100c499250 zap_deref_leaf() at zap_deref_leaf+0xd1/frame 0xfffffe100c4992a0 fzap_cursor_retrieve() at fzap_cursor_retrieve+0xce/frame 0xfffffe100c499310 zap_cursor_retrieve() at zap_cursor_retrieve+0x20a/frame 0xfffffe100c499390 ddt_zap_walk() at ddt_zap_walk+0x5e/frame 0xfffffe100c499650 ddt_walk() at ddt_walk+0x78/frame 0xfffffe100c499680 dsl_scan_sync() at dsl_scan_sync+0x6ec/frame 0xfffffe100c4999e0 spa_sync() at spa_sync+0x5c4/frame 0xfffffe100c499ad0 txg_sync_thread() at txg_sync_thread+0x256/frame 0xfffffe100c499bb0 fork_exit() at fork_exit+0x84/frame 0xfffffe100c499bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe100c499bf0 --- trap 0, rip = 0, rsp = 0xfffffe100c499cb0, rbp = 0 --- KDB: enter: panic Uptime: 14s Dumping 2263 out of 64465 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel.old/linux.ko.symbols...done. Loaded symbols for /boot/kernel.old/linux.ko.symbols Reading symbols from /boot/kernel.old/if_lagg.ko.symbols...done. Loaded symbols for /boot/kernel.old/if_lagg.ko.symbols Reading symbols from /boot/kernel.old/snd_envy24ht.ko.symbols...done. Loaded symbols for /boot/kernel.old/snd_envy24ht.ko.symbols Reading symbols from /boot/kernel.old/snd_spicds.ko.symbols...done. Loaded symbols for /boot/kernel.old/snd_spicds.ko.symbols Reading symbols from /boot/kernel.old/coretemp.ko.symbols...done. Loaded symbols for /boot/kernel.old/coretemp.ko.symbols Reading symbols from /boot/kernel.old/ichsmb.ko.symbols...done. Loaded symbols for /boot/kernel.old/ichsmb.ko.symbols Reading symbols from /boot/kernel.old/smbus.ko.symbols...done. Loaded symbols for /boot/kernel.old/smbus.ko.symbols Reading symbols from /boot/kernel.old/ichwd.ko.symbols...done. Loaded symbols for /boot/kernel.old/ichwd.ko.symbols Reading symbols from /boot/kernel.old/cpuctl.ko.symbols...done. Loaded symbols for /boot/kernel.old/cpuctl.ko.symbols Reading symbols from /boot/kernel.old/crypto.ko.symbols...done. Loaded symbols for /boot/kernel.old/crypto.ko.symbols Reading symbols from /boot/kernel.old/cryptodev.ko.symbols...done. Loaded symbols for /boot/kernel.old/cryptodev.ko.symbols Reading symbols from /boot/kernel.old/dtraceall.ko.symbols...done. Loaded symbols for /boot/kernel.old/dtraceall.ko.symbols Reading symbols from /boot/kernel.old/profile.ko.symbols...done. Loaded symbols for /boot/kernel.old/profile.ko.symbols Reading symbols from /boot/kernel.old/cyclic.ko.symbols...done. Loaded symbols for /boot/kernel.old/cyclic.ko.symbols Reading symbols from /boot/kernel.old/dtrace.ko.symbols...done. Loaded symbols for /boot/kernel.old/dtrace.ko.symbols Reading symbols from /boot/kernel.old/systrace_freebsd32.ko.symbols...done. Loaded symbols for /boot/kernel.old/systrace_freebsd32.ko.symbols Reading symbols from /boot/kernel.old/systrace.ko.symbols...done. Loaded symbols for /boot/kernel.old/systrace.ko.symbols Reading symbols from /boot/kernel.old/sdt.ko.symbols...done. Loaded symbols for /boot/kernel.old/sdt.ko.symbols Reading symbols from /boot/kernel.old/lockstat.ko.symbols...done. Loaded symbols for /boot/kernel.old/lockstat.ko.symbols Reading symbols from /boot/kernel.old/fasttrap.ko.symbols...done. Loaded symbols for /boot/kernel.old/fasttrap.ko.symbols Reading symbols from /boot/kernel.old/fbt.ko.symbols...done. Loaded symbols for /boot/kernel.old/fbt.ko.symbols Reading symbols from /boot/kernel.old/dtnfscl.ko.symbols...done. Loaded symbols for /boot/kernel.old/dtnfscl.ko.symbols Reading symbols from /boot/kernel.old/dtmalloc.ko.symbols...done. Loaded symbols for /boot/kernel.old/dtmalloc.ko.symbols Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel.old/ipmi.ko.symbols...done. Loaded symbols for /boot/kernel.old/ipmi.ko.symbols Reading symbols from /boot/kernel.old/ipmi_linux.ko.symbols...done. Loaded symbols for /boot/kernel.old/ipmi_linux.ko.symbols Reading symbols from /boot/kernel.old/radeonkms.ko.symbols...done. Loaded symbols for /boot/kernel.old/radeonkms.ko.symbols Reading symbols from /boot/kernel.old/iicbb.ko.symbols...done. Loaded symbols for /boot/kernel.old/iicbb.ko.symbols Reading symbols from /boot/kernel.old/iicbus.ko.symbols...done. Loaded symbols for /boot/kernel.old/iicbus.ko.symbols Reading symbols from /boot/kernel.old/iic.ko.symbols...done. Loaded symbols for /boot/kernel.old/iic.ko.symbols Reading symbols from /boot/kernel.old/drm2.ko.symbols...done. Loaded symbols for /boot/kernel.old/drm2.ko.symbols Reading symbols from /boot/kernel.old/radeonkmsfw_R100_cp.ko.symbols...done. Loaded symbols for /boot/kernel.old/radeonkmsfw_R100_cp.ko.symbols Reading symbols from /boot/kernel.old/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel.old/fdescfs.ko.symbols Reading symbols from /boot/kernel.old/linprocfs.ko.symbols...done. Loaded symbols for /boot/kernel.old/linprocfs.ko.symbols #0 doadump (textdump=1) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0xffffffff809b98d7 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:452 #2 0xffffffff809b9de5 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff809b9e33 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:688 #4 0xffffffff80327a2f in assfail3 (a=, lv=, op=, rv=, f=, l=) at /usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:91 #5 0xffffffff803bad81 in zap_get_leaf_byblk (zap=, blkid=, tx=0x0, lt=, lp=0xfffffe100c4994e8) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:534 #6 0xffffffff803b8461 in zap_deref_leaf (zap=0xfffff80020a4ec00, h=9377620324092215296, tx=0x0, lt=RW_READER, lp=0xfffffe100c4994e8) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:585 #7 0xffffffff803ba24e in fzap_cursor_retrieve (zap=0xfffff80020a4ec00, zc=0xfffffe100c4994d8, za=0xfffffe100c4993c0) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:1181 #8 0xffffffff803c076a in zap_cursor_retrieve (zc=0xfffffe100c4994d8, za=0xfffffe100c4993c0) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:1290 #9 0xffffffff80352fde in ddt_zap_walk (os=0xfffff8002031bc00, object=156, dde=0xfffffe100c499828, walk=0xfffff800201ce3d0) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ddt_zap.c:117 #10 0xffffffff80352c88 in ddt_walk (spa=0xfffffe000d377000, ddb=0xfffff800201ce3b8, dde=0xfffffe100c499828) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ddt.c:219 #11 0xffffffff803800dc in dsl_scan_sync (dp=0xfffff8002031f800, tx=0xfffff80022180000) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c:1204 #12 0xffffffff803999b4 in spa_sync (spa=0xfffffe000d377000, txg=14079627) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:6549 #13 0xffffffff803a4e96 in txg_sync_thread (arg=0xfffff8002031f800) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c:518 #14 0xffffffff80988f94 in fork_exit ( callout=0xffffffff803a4c40 , arg=0xfffff8002031f800, frame=0xfffffe100c499c00) at /usr/src/sys/kern/kern_fork.c:977 #15 0xffffffff80d9576e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:605 #16 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) ------------------------------------------------------------------------ ps -axlww UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -8 0 0 0 - DLs - 0:00.10 [kernel] 0 1 0 0 21 0 9432 0 wait DLs - 0:00.00 [init] 0 2 0 0 -16 0 0 0 ftcl DL - 0:00.00 [ftcleanup] 0 3 0 0 -16 0 0 0 crypto_w DL - 0:00.00 [crypto] 0 4 0 0 -16 0 0 0 crypto_r DL - 0:00.00 [crypto returns] 0 5 0 0 -16 0 0 0 ccb_scan DL - 0:00.00 [cam] 0 6 0 0 -16 0 0 0 - DL - 0:00.00 [fdc0] 0 7 0 0 -8 0 0 0 - RL - 0:00.00 [zfskern] 0 8 0 0 -16 0 0 0 waiting_ DL - 0:00.00 [sctp_iterator] 0 9 0 0 -16 0 0 0 ipmireq DL - 0:00.00 [ipmi0: kcs] 0 10 0 0 -16 0 0 0 audit_wo DL - 0:00.00 [audit] 0 11 0 0 155 0 0 0 - RL - 0:00.00 [idle] 0 12 0 0 -84 0 0 0 - WL - 0:00.00 [intr] 0 13 0 0 -8 0 0 0 - DL - 0:00.00 [geom] 0 14 0 0 -16 0 0 0 - DL - 0:00.00 [rand_harvestq] 0 15 0 0 -68 0 0 0 - DL - 0:00.00 [usb] 0 16 0 0 -20 0 0 0 VBoxIS DL - 0:00.00 [TIMER] 0 17 0 0 -16 0 0 0 psleep DL - 0:00.00 [pagedaemon] 0 18 0 0 -16 0 0 0 psleep DL - 0:00.00 [vmdaemon] 0 19 0 0 155 0 0 0 pgzero DL - 0:00.00 [pagezero] 0 20 0 0 -16 0 0 0 psleep DL - 0:00.00 [bufdaemon] 0 21 0 0 16 0 0 0 syncer DL - 0:00.00 [syncer] 0 22 0 0 -16 0 0 0 vlruwt DL - 0:00.00 [vnlru] 0 23 0 0 -16 0 0 0 sdflush DL - 0:00.00 [softdepflush] 0 24 1 0 52 0 16992 0 wait Ds+ - 0:00.02 [sh] 0 72 24 0 52 0 16992 0 wait D+ - 0:00.00 [sh] 0 75 72 0 39 0 40064 0 zio->io_ D+ - 0:00.00 [zfs] ------------------------------------------------------------------------ vmstat -s 42891 cpu context switches 5520 device interrupts 462 software interrupts 5061 traps 5879 system calls 23 kernel threads created 37 fork() calls 15 vfork() calls 0 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 0 swap pager pageouts 0 swap pager pages paged out 135 vnode pager pageins 923 vnode pager pages paged in 0 vnode pager pageouts 0 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 0 pages reactivated 1770 copy-on-write faults 15 copy-on-write optimized faults 2266 zero fill pages zeroed 0 zero fill pages prezeroed 0 intransit blocking page faults 4682 total VM faults taken 112 page faults requiring I/O 0 pages affected by kernel thread creation 1350 pages affected by fork() 525 pages affected by vfork() 0 pages affected by rfork() 0 pages cached 55124 pages freed 0 pages freed by daemon 0 pages freed by exiting processes 473 pages active 869 pages inactive 0 pages in VM cache 140410 pages wired down 15933660 pages free 4096 bytes per page 1934 total name lookups cache hits (80% pos + 4% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) cdev 8 2K - 8 256 ppbusdev 2 1K - 2 256 filedesc 27 54K - 76 2048 kdtrace 330 78K - 522 64,256 kenv 87 12K - 115 16,32,64,128 proc-args 3 1K - 31 32,64,128 hhook 2 1K - 2 256 ithread 125 22K - 125 32,128,256 KTRACE 100 13K - 100 128 entropy 1026 65K - 1026 32,64 acpiintr 1 1K - 1 64 linker 403 101K - 533 16,32,64,128,256,512,1024,2048,4096 lockf 2 1K - 2 64,128 loginclass 2 1K - 2 64 cache 1 1K - 1 32 devbuf 17314 34391K - 18687 16,32,64,128,256,512,1024,2048,4096 temp 57 18K - 548 16,32,64,128,256,512,1024,2048 ip6ndp 3 1K - 3 64 ata_pci 1 1K - 1 64 acpica 1824 187K - 63680 16,32,64,128,256,512,1024,2048 kbdmux 7 18K - 7 16,512,1024,2048 module 521 66K - 521 128 mtx_pool 2 16K - 2 LED 4 1K - 4 16,128 CAM XPT 58 4K - 309 16,32,64,128,512,1024,2048 osd 6 1K - 12 16,32,64,128 pmchooks 1 1K - 1 128 CAM DEV 15 30K - 24 2048 acpitask 1 8K - 1 hdaa 4 5K - 4 512,1024,2048 pgrp 2 1K - 2 128 session 2 1K - 2 128 proc 2 256K - 2 subproc 100 145K - 149 512,4096 cred 54 9K - 254 64,256 plimit 2 1K - 2 256 uidinfo 2 33K - 2 128 hdac 1 1K - 1 512 hdacc 1 1K - 1 32 vtbuf 24 5712K - 24 4096 acpisem 22 3K - 22 128 vt 11 3K - 11 256 sysctl 0 0K - 50 16,32,64 sysctloid 7607 378K - 7779 16,32,64,128 sysctltmp 0 0K - 6 32,64 tidhash 1 256K - 1 callout 9 3208K - 9 umtx 684 86K - 684 128 p1003.1b 1 1K - 1 16 SWAP 12 19681K - 12 64 bus 2257 362K - 8440 16,32,64,128,256,512,1024 bus-sc 157 310K - 5479 16,32,64,128,256,512,1024,2048,4096 devstat 32 65K - 32 32,4096 eventhandler 104 9K - 104 64,128 DEVFS3 230 58K - 270 256 kobj 349 1396K - 1111 4096 DEVFS1 202 101K - 238 512 Per-cpu 1 1K - 1 32 DEVFS 41 1K - 42 16,128 rman 360 41K - 754 16,32,128 sbuf 0 0K - 2295 16,32,64,128,256 sglist 3 1K - 3 32 taskqueue 127 19K - 171 16,32,64,128,256 terminal 11 3K - 11 256 Unitno 28 2K - 120 32,64 vmem 2 136K - 2 ioctlops 0 0K - 158 16,32,64 iov 1 1K - 34 64,256,512 msg 4 30K - 4 2048,4096 sem 4 106K - 4 2048,4096 shm 1 20K - 1 tty 14 14K - 14 1024 shmfd 1 8K - 1 pcb 12 8341K - 12 16,128,1024,2048 vfscache 1 16384K - 1 vfs_hash 1 8192K - 1 vnodes 1 1K - 1 256 mount 251 9K - 550 16,32,64,128,256 vnodemarker 0 0K - 5 512 BPF 3 1K - 3 128 ifnet 4 7K - 4 128,2048 ifaddr 34 10K - 34 32,64,256,512,2048,4096 clone 8 1K - 8 128 arpcom 2 1K - 2 16 lltable 6 3K - 6 512 routetbl 5 2K - 5 256,512 igmp 3 1K - 3 256 sctp_vrf 1 1K - 1 64 hostcache 1 28K - 1 syncache 1 64K - 1 mld 3 1K - 3 128 rpc 2 1K - 2 512 audit_evclass 187 6K - 228 32 ufs_quota 1 8192K - 1 vm_pgdata 7 8193K - 7 128 pfs_nodes 73 19K - 73 256 pfs_vncache 2 1K - 2 64 scsi_cd 0 0K - 11 16 GEOM 404 67K - 3278 16,32,64,128,256,512,1024,2048 memdesc 1 4K - 1 4096 feeder 20 2K - 24 32,128 acpidev 36 3K - 36 64 atkbddev 2 1K - 2 64 CAM CCB 0 0K - 5331 2048 mixer 3 12K - 3 4096 raid_data 0 0K - 480 32,128,256 CAM path 22 1K - 115 32 solaris 289279 163254K - 391115 16,32,64,128,256,512,1024,2048,4096 UART 6 5K - 6 16,1024 kstat_data 6 1K - 6 64 CAM periph 16 4K - 40 16,32,64,128,256 md_nvidia_data 0 0K - 78 512 pci_link 16 2K - 16 32,64,128 md_sii_data 0 0K - 78 512 acpi_perf 8 1K - 8 64 CAM queue 23 8K - 57 16,32,512 apmdev 1 1K - 1 128 madt_table 0 0K - 1 4096 CAM dev queue 8 1K - 8 64 CAM SIM 8 2K - 8 256 ddb_capture 1 48K - 1 io_apic 2 4K - 2 2048 MCA 8 1K - 8 128 msi 4 1K - 4 128 nexusdev 4 1K - 4 16 isadev 5 1K - 5 128 USB 46 59K - 52 16,32,64,128,256,512,1024,2048,4096 USBdev 35 4K - 35 32,64,128,256 linux 17 2K - 17 64 spicds 7 1K - 7 128 envy24ht 15 195K - 15 64,2048 cpuctl 1 1K - 1 64 crypto 1 1K - 1 512 cyclic 32 3K - 32 16,64,128 SDT 32 2K - 32 16,64 fbt 60661 7839K - 60661 128 iprtheap 17 54K - 17 32,64,128,256 nvidia 194 864K - 195 16,32,64,128,256,512,1024,2048,4096 ipmi 0 0K - 11 128 gem_name 59 10K - 62 32,4096 drm_global 2 1K - 2 128,256 drm_vblank 7 1K - 7 16,64 drm_dma 2 1K - 2 32 drm_sarea 1 1K - 1 16 drm_driver 32 2203K - 36 16,32,64,128,256,512,1024,4096 drm_ctxbitmap 1 4K - 1 4096 drm_sman 13 2K - 13 128 drm_hashtab 1 4096K - 1 drm_kms 90 18K - 107 16,32,64,128,256,2048 ttm_pd 6 9K - 6 16,2048 ttm_rman 2 1K - 2 256 ttm_zone 2 1K - 2 64 ttm_poolmgr 1 1K - 1 512 fdesc_mount 1 1K - 1 16 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 384, 0, 267, 3, 267, 0, 0 UMA Zones: 1664, 0, 267, 1, 267, 0, 0 UMA Slabs: 112, 0, 4719, 6, 7221, 0, 0 UMA RCntSlabs: 120, 0, 0, 0, 0, 0, 0 UMA Hash: 256, 0, 77, 13, 77, 0, 0 4 Bucket: 32, 0, 262, 854, 1813, 0, 0 6 Bucket: 48, 0, 276, 1052, 1590, 0, 0 8 Bucket: 64, 0, 62, 992, 883, 0, 0 12 Bucket: 96, 0, 36, 989, 167, 0, 0 16 Bucket: 128, 0, 131, 1016, 1263, 17, 0 32 Bucket: 256, 0, 130, 380, 285, 49, 0 64 Bucket: 512, 0, 119, 238, 465, 49, 0 128 Bucket: 1024, 0, 406, 46, 3736, 2, 0 vmem btag: 56, 0, 11416, 441, 11514, 167, 0 VM OBJECT: 256, 0, 590, 400, 1335, 0, 0 RADIX NODE: 144, 0, 6442, 416, 10926, 0, 0 MAP: 240, 0, 3, 61, 3, 0, 0 KMAP ENTRY: 128, 0, 8, 271, 8, 0, 0 MAP ENTRY: 128, 0, 103, 920, 1717, 0, 0 VMSPACE: 448, 0, 4, 204, 54, 0, 0 fakepg: 104, 0, 0, 0, 0, 0, 0 mt_zone: 4112, 0, 405, 0, 405, 0, 0 16: 16, 0, 6, 243, 6, 0, 0 16: 16, 0, 2762, 973, 3015, 0, 0 16: 16, 0, 147166, 740, 158653, 0, 0 16: 16, 0, 55, 941, 28215, 0, 0 16: 16, 0, 62, 685, 63, 0, 0 16: 16, 0, 732, 1011, 5473, 0, 0 16: 16, 0, 30, 219, 30, 0, 0 16: 16, 0, 1, 746, 18, 0, 0 32: 32, 0, 30, 1086, 117, 0, 0 32: 32, 0, 3091, 877, 3295, 0, 0 32: 32, 0, 65004, 716, 73960, 0, 0 32: 32, 0, 66, 554, 4216, 0, 0 32: 32, 0, 18, 1098, 98, 0, 0 32: 32, 0, 839, 897, 2874, 0, 0 32: 32, 0, 94, 650, 186, 0, 0 32: 32, 0, 8, 736, 164, 0, 0 64: 64, 0, 5, 181, 6, 0, 0 64: 64, 0, 517, 909, 589, 0, 0 64: 64, 0, 7078, 982, 33984, 0, 0 64: 64, 0, 767, 783, 1637, 0, 0 64: 64, 0, 80, 106, 80, 0, 0 64: 64, 0, 9187, 857, 9746, 0, 0 64: 64, 0, 131, 551, 131, 0, 0 64: 64, 0, 1038, 760, 1071, 0, 0 128: 128, 0, 34, 741, 95, 0, 0 128: 128, 0, 1899, 612, 1908, 0, 0 128: 128, 0, 121830, 806, 128094, 0, 0 128: 128, 0, 1077, 318, 27007, 0, 0 128: 128, 0, 112, 663, 192, 0, 0 128: 128, 0, 1895, 740, 4111, 0, 0 128: 128, 0, 29, 126, 30, 0, 0 128: 128, 0, 524, 499, 526, 0, 0 256: 256, 0, 2, 73, 2, 0, 0 256: 256, 0, 308, 307, 451, 0, 0 256: 256, 0, 372, 543, 2665, 0, 0 256: 256, 0, 64, 131, 740, 0, 0 256: 256, 0, 28, 347, 348, 0, 0 256: 256, 0, 909, 441, 1963, 0, 0 256: 256, 0, 31, 44, 31, 0, 0 256: 256, 0, 4, 191, 25, 0, 0 512: 512, 0, 2, 33, 9, 0, 0 512: 512, 0, 69, 197, 225, 0, 0 512: 512, 0, 130, 276, 32908, 0, 0 512: 512, 0, 16, 47, 35, 0, 0 512: 512, 0, 3, 32, 3, 0, 0 512: 512, 0, 327, 170, 2804, 0, 0 512: 512, 0, 47, 16, 47, 0, 0 512: 512, 0, 1, 62, 2, 0, 0 1024: 1024, 0, 0, 104, 99, 0, 0 1024: 1024, 0, 9, 19, 9, 0, 0 1024: 1024, 0, 8372, 68, 23684, 0, 0 1024: 1024, 0, 5, 23, 2074, 0, 0 1024: 1024, 0, 16, 12, 16, 0, 0 1024: 1024, 0, 230, 98, 1280, 0, 0 1024: 1024, 0, 2, 14, 2, 0, 0 1024: 1024, 0, 0, 0, 0, 0, 0 2048: 2048, 0, 2, 4, 9, 0, 0 2048: 2048, 0, 6, 4, 6, 0, 0 2048: 2048, 0, 11, 19, 39, 0, 0 2048: 2048, 0, 7, 53, 5343, 0, 0 2048: 2048, 0, 21, 9, 30, 0, 0 2048: 2048, 0, 48, 42, 466, 0, 0 2048: 2048, 0, 5, 1, 5, 0, 0 2048: 2048, 0, 0, 0, 0, 0, 0 4096: 4096, 0, 0, 0, 0, 0, 0 4096: 4096, 0, 5, 0, 5, 0, 0 4096: 4096, 0, 167, 4, 295, 0, 0 4096: 4096, 0, 10, 0, 12, 0, 0 4096: 4096, 0, 16, 0, 17, 0, 0 4096: 4096, 0, 25, 0, 415, 0, 0 4096: 4096, 0, 15, 0, 15, 0, 0 4096: 4096, 0, 349, 10, 1111, 0, 0 uint64 pcpu: 8, 0, 1398, 138, 1398, 0, 0 SLEEPQUEUE: 88, 0, 343, 680, 343, 0, 0 Files: 80, 0, 8, 874, 395, 0, 0 rl_entry: 40, 0, 6, 687, 6, 0, 0 TURNSTILE: 136, 0, 343, 277, 343, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1208, 0, 26, 46, 75, 0, 0 THREAD: 1168, 0, 302, 40, 445, 0, 0 cpuset: 72, 0, 287, 593, 430, 0, 0 cyclic_id_cache: 64, 0, 0, 0, 0, 0, 0 audit_record: 1248, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 25720710, 0, 10, 0, 0, 0 mbuf: 256, 25720710, 1, 134, 1, 0, 0 mbuf_cluster: 2048, 4018860, 0, 0, 0, 0, 0 mbuf_jumbo_page: 4096, 2009429, 0, 0, 0, 0, 0 mbuf_jumbo_9k: 9216, 1786158, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 1339616, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 sendfile_sync: 128, 0, 0, 0, 0, 0, 0 dtrace_state_cache: 4096, 0, 0, 0, 0, 0, 0 g_bio: 248, 0, 0, 672, 15403, 0, 0 DMAR_MAP_ENTRY: 120, 0, 0, 0, 0, 0, 0 ttyinq: 160, 0, 15, 57, 15, 0, 0 ttyoutq: 256, 0, 8, 67, 8, 0, 0 ata_request: 336, 0, 0, 88, 39, 0, 0 vtnet_tx_hdr: 24, 0, 0, 0, 0, 0, 0 cryptop: 88, 0, 0, 0, 0, 0, 0 cryptodesc: 72, 0, 0, 0, 0, 0, 0 nv_stack_t: 12288, 0, 2, 1, 6, 0, 0 FPU_save_area: 512, 0, 0, 0, 0, 0, 0 taskq_zone: 48, 0, 0, 415, 20, 0, 0 taskq_zone: 48, 0, 0, 0, 0, 0, 0 VNODE: 472, 0, 332, 164, 333, 0, 0 VNODEPOLL: 112, 0, 0, 0, 0, 0, 0 BUF TRIE: 144, 0, 0, 105948, 0, 0, 0 NAMEI: 1024, 0, 0, 104, 908, 0, 0 S VFS Cache: 108, 0, 248, 767, 294, 0, 0 STS VFS Cache: 148, 0, 0, 0, 0, 0, 0 L VFS Cache: 328, 0, 0, 0, 0, 0, 0 LTS VFS Cache: 368, 0, 0, 0, 0, 0, 0 NCLNODE: 528, 0, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 0, 0, 0, 0, 0 reference_cache: 40, 0, 0, 0, 0, 0, 0 reference_history_cache: 8, 0, 0, 0, 0, 0, 0 range_seg_cache: 64, 0, 9978, 934, 10433, 0, 0 zio_cache: 920, 0, 6, 814, 12019, 0, 0 zio_link_cache: 48, 0, 3, 1408, 7868, 0, 0 zio_buf_512: 512, 0, 590, 166, 1077, 0, 0 zio_data_buf_512: 512, 0, 54, 65, 56, 0, 0 zio_buf_1024: 1024, 0, 22, 58, 61, 0, 0 zio_data_buf_1024: 1024, 0, 40, 40, 40, 0, 0 zio_buf_1536: 1536, 0, 22, 24, 24, 0, 0 zio_data_buf_1536: 1536, 0, 23, 13, 23, 0, 0 zio_buf_2048: 2048, 0, 35, 25, 64, 0, 0 zio_data_buf_2048: 2048, 0, 14, 12, 15, 0, 0 zio_buf_2560: 2560, 0, 0, 15, 27, 0, 0 zio_data_buf_2560: 2560, 0, 17, 4, 17, 0, 0 zio_buf_3072: 3072, 0, 2, 4, 2, 0, 0 zio_data_buf_3072: 3072, 0, 8, 4, 8, 0, 0 zio_buf_3584: 3584, 0, 1, 0, 1, 0, 0 zio_data_buf_3584: 3584, 0, 2, 0, 2, 0, 0 zio_buf_4096: 4096, 0, 49, 706, 3790, 0, 0 zio_data_buf_4096: 4096, 0, 0, 24, 25, 0, 0 zio_buf_5120: 5120, 0, 1, 0, 1, 0, 0 zio_data_buf_5120: 5120, 0, 4, 0, 4, 0, 0 zio_buf_6144: 6144, 0, 1, 0, 1, 0, 0 zio_data_buf_6144: 6144, 0, 3, 0, 3, 0, 0 zio_buf_7168: 7168, 0, 0, 0, 0, 0, 0 zio_data_buf_7168: 7168, 0, 1, 0, 1, 0, 0 zio_buf_8192: 8192, 0, 1, 13, 187, 0, 0 zio_data_buf_8192: 8192, 0, 2, 1, 4, 0, 0 zio_buf_10240: 10240, 0, 1, 0, 1, 0, 0 zio_data_buf_10240: 10240, 0, 1, 0, 1, 0, 0 zio_buf_12288: 12288, 0, 1, 8, 45, 0, 0 zio_data_buf_12288: 12288, 0, 4, 0, 4, 0, 0 zio_buf_14336: 14336, 0, 0, 0, 0, 0, 0 zio_data_buf_14336: 14336, 0, 1, 0, 1, 0, 0 zio_buf_16384: 16384, 0, 398, 23, 543, 0, 0 zio_data_buf_16384: 16384, 0, 2, 0, 2, 0, 0 zio_buf_20480: 20480, 0, 0, 5, 19, 0, 0 zio_data_buf_20480: 20480, 0, 3, 0, 3, 0, 0 zio_buf_24576: 24576, 0, 0, 9, 16, 0, 0 zio_data_buf_24576: 24576, 0, 5, 0, 5, 0, 0 zio_buf_28672: 28672, 0, 0, 14, 83, 0, 0 zio_data_buf_28672: 28672, 0, 4, 0, 4, 0, 0 zio_buf_32768: 32768, 0, 0, 2, 3, 0, 0 zio_data_buf_32768: 32768, 0, 2, 0, 2, 0, 0 zio_buf_36864: 36864, 0, 1, 5, 8, 0, 0 zio_data_buf_36864: 36864, 0, 1, 2, 3, 0, 0 zio_buf_40960: 40960, 0, 0, 3, 3, 0, 0 zio_data_buf_40960: 40960, 0, 2, 0, 2, 0, 0 zio_buf_45056: 45056, 0, 0, 1, 1, 0, 0 zio_data_buf_45056: 45056, 0, 1, 0, 1, 0, 0 zio_buf_49152: 49152, 0, 0, 0, 0, 0, 0 zio_data_buf_49152: 49152, 0, 0, 0, 0, 0, 0 zio_buf_53248: 53248, 0, 0, 1, 1, 0, 0 zio_data_buf_53248: 53248, 0, 1, 0, 1, 0, 0 zio_buf_57344: 57344, 0, 0, 0, 0, 0, 0 zio_data_buf_57344: 57344, 0, 0, 0, 0, 0, 0 zio_buf_61440: 61440, 0, 0, 0, 0, 0, 0 zio_data_buf_61440: 61440, 0, 0, 0, 0, 0, 0 zio_buf_65536: 65536, 0, 0, 0, 0, 0, 0 zio_data_buf_65536: 65536, 0, 0, 0, 0, 0, 0 zio_buf_69632: 69632, 0, 0, 2, 2, 0, 0 zio_data_buf_69632: 69632, 0, 2, 0, 2, 0, 0 zio_buf_73728: 73728, 0, 0, 1, 1, 0, 0 zio_data_buf_73728: 73728, 0, 1, 0, 1, 0, 0 zio_buf_77824: 77824, 0, 0, 0, 0, 0, 0 zio_data_buf_77824: 77824, 0, 0, 0, 0, 0, 0 zio_buf_81920: 81920, 0, 0, 0, 0, 0, 0 zio_data_buf_81920: 81920, 0, 1, 0, 1, 0, 0 zio_buf_86016: 86016, 0, 0, 0, 0, 0, 0 zio_data_buf_86016: 86016, 0, 0, 0, 0, 0, 0 zio_buf_90112: 90112, 0, 0, 2, 2, 0, 0 zio_data_buf_90112: 90112, 0, 0, 1, 1, 0, 0 zio_buf_94208: 94208, 0, 0, 0, 0, 0, 0 zio_data_buf_94208: 94208, 0, 0, 0, 0, 0, 0 zio_buf_98304: 98304, 0, 1, 1, 2, 0, 0 zio_data_buf_98304: 98304, 0, 1, 0, 1, 0, 0 zio_buf_102400: 102400, 0, 0, 0, 0, 0, 0 zio_data_buf_102400: 102400, 0, 0, 0, 0, 0, 0 zio_buf_106496: 106496, 0, 0, 0, 0, 0, 0 zio_data_buf_106496: 106496, 0, 0, 0, 0, 0, 0 zio_buf_110592: 110592, 0, 0, 1, 1, 0, 0 zio_data_buf_110592: 110592, 0, 1, 0, 1, 0, 0 zio_buf_114688: 114688, 0, 0, 3, 14, 0, 0 zio_data_buf_114688: 114688, 0, 0, 0, 0, 0, 0 zio_buf_118784: 118784, 0, 0, 0, 0, 0, 0 zio_data_buf_118784: 118784, 0, 0, 0, 0, 0, 0 zio_buf_122880: 122880, 0, 0, 0, 0, 0, 0 zio_data_buf_122880: 122880, 0, 0, 0, 0, 0, 0 zio_buf_126976: 126976, 0, 0, 0, 0, 0, 0 zio_data_buf_126976: 126976, 0, 0, 0, 0, 0, 0 zio_buf_131072: 131072, 0, 1, 11, 61, 0, 0 zio_data_buf_131072: 131072, 0, 39, 5, 48, 0, 0 lz4_ctx: 16384, 0, 0, 0, 0, 0, 0 sa_cache: 80, 0, 272, 757, 272, 0, 0 dnode_t: 1096, 0, 746, 37, 1863, 0, 0 dmu_buf_impl_t: 336, 0, 1270, 127, 1729, 0, 0 arc_buf_hdr_t: 328, 0, 881, 163, 1332, 0, 0 arc_buf_t: 72, 0, 880, 770, 1359, 0, 0 zil_lwb_cache: 192, 0, 0, 0, 0, 0, 0 zfs_znode_cache: 368, 0, 272, 138, 272, 0, 0 pipe: 744, 0, 0, 40, 13, 0, 0 Mountpoints: 816, 0, 24, 41, 24, 0, 0 procdesc: 128, 0, 0, 0, 0, 0, 0 ksiginfo: 112, 0, 26, 1024, 26, 0, 0 itimer: 352, 0, 0, 0, 0, 0, 0 KNOTE: 128, 0, 0, 0, 0, 0, 0 socket: 696, 2062880, 0, 0, 0, 0, 0 ipq: 56, 125599, 0, 0, 0, 0, 0 udp_inpcb: 392, 2062880, 0, 0, 0, 0, 0 udpcb: 16, 2062965, 0, 0, 0, 0, 0 tcp_inpcb: 392, 2062880, 0, 0, 0, 0, 0 tcpcb: 1024, 2062880, 0, 0, 0, 0, 0 tcptw: 88, 27810, 0, 0, 0, 0, 0 syncache: 160, 15360, 0, 0, 0, 0, 0 hostcache: 136, 15370, 0, 0, 0, 0, 0 tcpreass: 40, 251262, 0, 0, 0, 0, 0 sackhole: 32, 0, 0, 0, 0, 0, 0 sctp_ep: 1408, 2062880, 0, 0, 0, 0, 0 sctp_asoc: 2352, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80012, 0, 0, 0, 0, 0 sctp_raddr: 728, 80000, 0, 0, 0, 0, 0 sctp_chunk: 136, 400026, 0, 0, 0, 0, 0 sctp_readq: 104, 400026, 0, 0, 0, 0, 0 sctp_stream_msg_out: 104, 400026, 0, 0, 0, 0, 0 sctp_asconf: 40, 400059, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400060, 0, 0, 0, 0, 0 ripcb: 392, 2062880, 0, 0, 0, 0, 0 unpcb: 240, 2062880, 0, 0, 0, 0, 0 rtentry: 200, 0, 0, 0, 0, 0, 0 selfd: 56, 0, 0, 0, 0, 0, 0 SWAPMETA: 288, 8037731, 0, 0, 0, 0, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq6: fdc0 22 0 irq14: ata0 55 0 irq17: uhci0 ehci0 55 0 irq18: uhci2+ 304 0 irq19: uhci1 ahci0+ 5075 13 cpu0:timer 2410 6 irq259: hdac0 9 0 cpu6:timer 442 1 cpu1:timer 404 1 cpu2:timer 482 1 cpu7:timer 548 1 cpu5:timer 477 1 cpu4:timer 484 1 cpu3:timer 765 2 Total 11532 31 ------------------------------------------------------------------------ pstat -T 8/2062880 files 0M/147455M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/#C:0xc0 50331392 0 50331392 0% /dev/ad14p2 50331392 0 50331392 0% /dev/usb/3.2.1 50331392 0 50331392 0% /dev/#C:0xd0 50331392 0 50331392 0% /dev/#C:0xd8 50331392 0 50331392 0% /dev/#C:0xe0 50331392 0 50331392 0% Total 301988352 0 301988352 0% ------------------------------------------------------------------------ iostat tty ada0 ada1 ada2 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 15 15.18 60 0.89 15.40 65 0.98 14.86 63 0.91 0 0 2 1 97 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) shminfo: shmmax: 536870912 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 131072 (max amount of shared memory in pages) seminfo: semmni: 50 (# of semaphore identifiers) semmns: 340 (# of semaphores in system) semmnu: 150 (# of undo structures in system) semmsl: 340 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 50 (max # of undo entries per process) semusz: 632 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat Client Info: Rpc Counts: Getattr Setattr Lookup Readlink Read Write Create Remove 2 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 1 1 0 0 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 0 0 4 Cache Info: Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Misses 0 0 0 0 0 0 0 0 BioRLHits Misses BioD Hits Misses DirE Hits Misses Accs Hits Misses 0 0 0 0 0 0 0 0 Server Info: Getattr Setattr Lookup Readlink Read Write Create Remove 0 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Server Ret-Failed 0 Server Faults 0 Server Cache Stats: Inprog Idem Non-idem Misses 0 0 0 0 Server Write Gathering: WriteOps WriteRPC Opsaved 0 0 0 ------------------------------------------------------------------------ netstat -s tcp: 0 packets sent 0 data packets (0 bytes) 0 data packets (0 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 0 ack-only packets (0 delayed) 0 URG only packets 0 window probe packets 0 window update packets 0 control packets 0 packets received 0 acks (for 0 bytes) 0 duplicate acks 0 acks for unsent data 0 packets (0 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 0 connection requests 0 connection accepts 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 0 connections established (including accepts) 0 connections closed (including 0 drops) 0 connections updated cached RTT on close 0 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 0 segments updated rtt (of 0 attempts) 0 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 0 correct ACK header predictions 0 correct data packet header predictions 0 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 0 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 0 cookies sent 0 cookies received 0 hostcache entries added 0 bucket overflow 0 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 0 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 0 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 0 dropped due to no socket 0 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 0 delivered 0 datagrams output 0 times multicast source filter matched ip: 0 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 0 packets for this host 0 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 0 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 0 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 0 calls to icmp_error 0 errors not generated in response to an icmp message 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored 0 message responses generated 0 invalid return addresses 0 no return routes igmp: 0 messages received 0 messages received with too few bytes 0 messages received with wrong TTL 0 messages received with bad checksum 0 V1/V2 membership queries received 0 V3 membership queries received 0 membership queries received with invalid field(s) 0 general queries received 0 group queries received 0 group-source queries received 0 group-source queries dropped 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 V3 reports received without Router Alert 0 membership reports sent arp: 0 ARP requests sent 0 ARP replies sent 0 ARP requests received 0 ARP replies received 0 ARP packets received 0 total packets dropped due to no ARP entry 0 ARP entrys timed out 0 Duplicate IPs seen ip6: 0 total packets received 0 with size smaller than minimum 0 with data size < data length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 fragments that exceeded limit 0 packets reassembled ok 0 packets for this host 0 packets forwarded 0 packets not forwardable 0 redirects sent 0 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 packets that violated scope rules 0 multicast packets which we don't join Mbuf statistics: 0 one mbuf 0 one ext mbuf 0 two or more ext mbuf 0 packets whose headers are not contiguous 0 tunneling packets that can't find gif 0 packets discarded because of too many headers 0 failures of source address selection Source addresses selection rule applied: icmp6: 0 calls to icmp6_error 0 errors not generated in response to an icmp6 message 0 errors not generated because of rate limitation 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Histogram of error messages to be generated: 0 no route 0 administratively prohibited 0 beyond scope 0 address unreachable 0 port unreachable 0 packet too big 0 time exceed transit 0 time exceed reassembly 0 erroneous header field 0 unrecognized next header 0 unrecognized option 0 redirect 0 unknown 0 message responses generated 0 messages with too many ND options 0 messages with bad ND options 0 bad neighbor solicitation messages 0 bad neighbor advertisement messages 0 bad router solicitation messages 0 bad router advertisement messages 0 bad redirect messages 0 path MTU changes rip6: 0 messages received 0 checksum calculations on inbound 0 messages with bad checksum 0 messages dropped due to no socket 0 multicast messages dropped due to no socket 0 messages dropped due to full socket buffers 0 delivered 0 datagrams output ------------------------------------------------------------------------ netstat -m netstat: invalid address (0x0) 1/144/145 mbufs in use (current/cache/total) 18446744073709551606/10/0/4018860 mbuf clusters in use (current/cache/total/max) 0/10 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/2009429 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/1786158 9k jumbo clusters in use (current/cache/total/max) 0/0/0/1339616 16k jumbo clusters in use (current/cache/total/max) 18014398509481964K/56K/36K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) ------------------------------------------------------------------------ netstat -anr Routing tables Internet: Destination Gateway Flags Netif Expire Internet6: Destination Gateway Flags Netif Expire ------------------------------------------------------------------------ netstat -anA ------------------------------------------------------------------------ netstat -aL ------------------------------------------------------------------------ fstat fstat: can't read file 1 at 0x200007fffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 7 at 0x200007fffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x200007fffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 7 at 0x200007fffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x200007fffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 7 at 0x200007fffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root zfs 75 root - - error - root zfs 75 wd - - error - root zfs 75 text - - error - root zfs 75 ctty /dev 13 crw------- console rw root zfs 75 0 /dev 13 crw------- console rw root zfs 75 6 /dev 13 crw------- console rw root sh 72 root - - error - root sh 72 wd - - error - root sh 72 text - - error - root sh 72 ctty /dev 13 crw------- console rw root sh 72 0 /dev 13 crw------- console rw root sh 72 6 /dev 13 crw------- console rw root sh 24 root - - error - root sh 24 wd - - error - root sh 24 text - - error - root sh 24 ctty /dev 13 crw------- console rw root sh 24 0 /dev 13 crw------- console rw root sh 24 6 /dev 13 crw------- console rw root init 1 root - - error - root init 1 wd - - error - root init 1 text - - error - root kernel 0 root - - error - root kernel 0 wd - - error - ------------------------------------------------------------------------ dmesg Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #1 r260896: Mon Jan 20 12:31:46 CST 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 info: [drm] Initialized drm 1.1.0 20060810 CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (2327.55-MHz K8-class CPU) Origin="GenuineIntel" Id=0x10676 Family=0x6 Model=0x17 Stepping=6 Features=0xbfebfbff Features2=0xce3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 68719476736 (65536 MB) avail memory = 65641644032 (62600 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard random: initialized kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) unknown: I/O range not supported cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 350 Event timer "HPET1" frequency 14318180 Hz quality 340 Event timer "HPET2" frequency 14318180 Hz quality 340 atrtc0: port 0x70-0x71 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 pcib5: at device 0.2 on pci3 pci5: on pcib5 pcib6: irq 18 at device 2.0 on pci2 pci6: on pcib6 em0: port 0x2000-0x201f mem 0xd9220000-0xd923ffff,0xd9200000-0xd921ffff irq 18 at device 0.0 on pci6 em0: Using an MSI interrupt em0: Ethernet address: 00:30:48:f2:29:9c em1: port 0x2020-0x203f mem 0xd9260000-0xd927ffff,0xd9240000-0xd925ffff irq 19 at device 0.1 on pci6 em1: Using an MSI interrupt em1: Ethernet address: 00:30:48:f2:29:9d pcib7: at device 0.3 on pci1 pci7: on pcib7 pcib8: at device 4.0 on pci0 pci8: on pcib8 vgapci0: port 0x3000-0x307f mem 0xd8000000-0xd8ffffff,0xc0000000-0xc7ffffff,0xc8000000-0xc9ffffff irq 16 at device 0.0 on pci8 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io hdac0: mem 0xd9000000-0xd9003fff irq 17 at device 0.1 on pci8 pcib9: at device 6.0 on pci0 pci9: on pcib9 pci0: at device 8.0 (no driver attached) pcib10: irq 17 at device 28.0 on pci0 pci10: on pcib10 pcib11: irq 16 at device 0.0 on pci10 pci11: on pcib11 pcm0: port 0x4080-0x409f,0x4000-0x407f irq 16 at device 0.0 on pci11 pcm0: system configuration SubVendorID: 0x1412, SubDeviceID: 0x2403 XIN2 Clock Source: 24.576MHz(96kHz*256) MPU-401 UART(s) #: not implemented ADC #: 1 and SPDIF receiver connected DAC #: 4 Multi-track converter type: AC'97(SDATA_OUT:packed) S/PDIF(IN/OUT): 1/1 ID# 0x00 GPIO(mask/dir/state): 0xff/0xff/0xff uhci0: port 0x1800-0x181f irq 17 at device 29.0 on pci0 usbus0 on uhci0 uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 usbus1 on uhci1 uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 usbus2 on uhci2 ehci0: mem 0xd9600400-0xd96007ff irq 17 at device 29.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib12: at device 30.0 on pci0 pci12: on pcib12 vgapci1: port 0x5000-0x50ff mem 0xd0000000-0xd7ffffff,0xd9300000-0xd930ffff irq 18 at device 1.0 on pci12 drmn1: on vgapci1 info: [drm] RADEON_IS_PCI info: [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080). info: [drm] register mmio base: 0xD9300000 info: [drm] register mmio size: 65536 info: [drm] radeon_atrm_get_bios: ===> Try ATRM... info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:8:0:0, vendor=10de, device=104a info: [drm] radeon_atrm_get_bios: Get ACPI device handle info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0xd0000000 info: [drm] igp_read_bios_from_vram: Map address: 0xfffff800d0000000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x0000 info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] radeon_read_bios: Map address: 0xfffff800000c0000 (131072 bytes) drmn1: info: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used) drmn1: info: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] radeon: irq initialized. info: [drm] Detected VRAM RAM=128M, BAR=128M info: [drm] RAM width 64bits SDR [TTM] Zone kernel: Available graphics memory: 33006090 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator info: [drm] radeon: 16M of VRAM memory ready info: [drm] radeon: 512M of GTT memory ready. info: [drm] GART: num cpu pages 131072, num gpu pages 131072 info: [drm] PCI GART of 512M enabled (table at 0x0000000011200000). drmn1: info: WB disabled drmn1: info: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0x0xfffff8001083c000 info: [drm] Loading R100 Microcode info: [drm] radeon: ring at 0x00000000B0001000 info: [drm] ring test succeeded in 1 usecs info: [drm] ib test succeeded in 0 usecs info: [drm] radeon_device_init: Taking over the fictitious range 0xd0000000-0xd4000000 iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iicbus1: on iicbb1 addr 0xff iic1: on iicbus1 iicbus2: on iicbb2 addr 0xff iic2: on iicbus2 iicbus3: on iicbb3 addr 0xff iic3: on iicbus3 info: [drm] Radeon Display Connectors info: [drm] Connector 0: info: [drm] VGA-1 info: [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60 info: [drm] Encoders: info: [drm] CRT1: INTERNAL_DAC1 info: [drm] Connector 1: info: [drm] DVI-I-1 info: [drm] HPD2 info: [drm] DDC: 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c info: [drm] Encoders: info: [drm] CRT2: INTERNAL_DAC2 info: [drm] DFP2: INTERNAL_DVO1 composite sync not supported composite sync not supported info: [drm] fb mappable at 0xD0040000 info: [drm] vram apper at 0xD0000000 info: [drm] size 2076672 info: [drm] fb depth is 8 info: [drm] pitch is 1920 fbd1 on drmn1 vt_allocate: Replace existing VT driver. info: [drm] Initialized radeon 2.29.0 20080528 vgapci1: Boot video device isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: at channel 0 on atapci0 ahci0: port 0x18a0-0x18a7,0x1874-0x1877,0x1878-0x187f,0x1870-0x1873,0x1880-0x189f mem 0xd9600800-0xd9600bff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ichsmb0: port 0x1100-0x111f irq 19 at device 31.3 on pci0 smbus0: on ichsmb0 acpi_button0: on acpi0 ipmi0: port 0xca2-0xca3 on acpi0 ipmi0: KCS mode found at io 0xca2 on acpi atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ichwd0 on isa0 orm0: at iomem 0xc0000-0xcafff on isa0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 coretemp4: on cpu4 est4: on cpu4 p4tcc4: on cpu4 coretemp5: on cpu5 est5: on cpu5 p4tcc5: on cpu5 coretemp6: on cpu6 est6: on cpu6 p4tcc6: on cpu6 coretemp7: on cpu7 est7: on cpu7 p4tcc7: on cpu7 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x387 offMax=0x491 hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm1: at nid 4 on hdaa0 pcm2: at nid 5 on hdaa0 random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen3.1: at usbus3 uhub0: on usbus3 ugen2.1: at usbus2 uhub1: on usbus2 ugen1.1: at usbus1 uhub2: on usbus1 ugen0.1: at usbus0 uhub3: on usbus0 ipmi0: IPMI device rev. 1, firmware rev. 1.64, version 2.0 ata0: DMA limited to UDMA33, controller found non-ATA66 cable ipmi0: Number of channels 8 ipmi0: Attached watchdog uhub2: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: Serial Number 5YDA1ZL4 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus2 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: Serial Number 5YD6FPLG ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada1: quirks=0x1<4K> ada1: Previously was known as ad6 ada2 at ahcich2 bus 0 scbus3 target 0 lun 0 ada2: ATA-8 SATA 3.x device ada2: Serial Number 5YDA3PC5 ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada2: quirks=0x1<4K> ada2: Previously was known as ad8 ada3 at ahcich3 bus 0 scbus4 target 0 lun 0 ada3: ATA-8 SATA 3.x device ada3: Serial Number 5YD9Y0P4 ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3: quirks=0x1<4K> ada3: Previously was known as ad10 ada4 at ahcich4 bus 0 scbus5 target 0 lun 0 ada4: ATA-8 SATA 3.x device ada4: Serial Number 5YDA1R5W ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada4: quirks=0x1<4K> ada4: Previously was known as ad12 ada5 at ahcich5 bus 0 scbus6 target 0 lun 0 ada5: ATA-8 SATA 3.x device ada5: Serial Number 5YD5RBS8 ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada5: quirks=0x1<4K> ada5: Previously was known as ad14 cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present Netvsc initializing... done! SMP: AP CPU #6 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #3 Launched! Root mount waiting for: usbus3 uhub0: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 Root mount waiting for: usbus3 ugen3.2: at usbus3 ukbd0: on usbus3 kbd2 at ukbd0 Trying to mount root from zfs:zroot/ROOT/default []... ugen0.2: at usbus0 ugen1.2: at usbus1 Setting hostuuid: 53d19f64-d663-a017-8922-0030488e9ff3. Setting hostid: 0xf53a926e. Entropy harvesting: interrupts ethernet point_to_point swi. Starting file system checks: Mounting local file systems:. panic: solaris assert: l->l_phys->l_hdr.lh_block_type == ((1ULL << 63) + 0) (0x0 == 0x8000000000000000), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c, line: 534 cpuid = 7 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe100c499090 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe100c499140 vpanic() at vpanic+0x126/frame 0xfffffe100c499180 panic() at panic+0x43/frame 0xfffffe100c4991e0 assfail3() at assfail3+0x2f/frame 0xfffffe100c499200 zap_get_leaf_byblk() at zap_get_leaf_byblk+0x4e1/frame 0xfffffe100c499250 zap_deref_leaf() at zap_deref_leaf+0xd1/frame 0xfffffe100c4992a0 fzap_cursor_retrieve() at fzap_cursor_retrieve+0xce/frame 0xfffffe100c499310 zap_cursor_retrieve() at zap_cursor_retrieve+0x20a/frame 0xfffffe100c499390 ddt_zap_walk() at ddt_zap_walk+0x5e/frame 0xfffffe100c499650 ddt_walk() at ddt_walk+0x78/frame 0xfffffe100c499680 dsl_scan_sync() at dsl_scan_sync+0x6ec/frame 0xfffffe100c4999e0 spa_sync() at spa_sync+0x5c4/frame 0xfffffe100c499ad0 txg_sync_thread() at txg_sync_thread+0x256/frame 0xfffffe100c499bb0 fork_exit() at fork_exit+0x84/frame 0xfffffe100c499bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe100c499bf0 --- trap 0, rip = 0, rsp = 0xfffffe100c499cb0, rbp = 0 --- KDB: enter: panic Uptime: 14s Dumping 2263 out of 64465 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% ------------------------------------------------------------------------ kernel config options CONFIG_AUTOGENERATED ident VT-LER machine amd64 cpu HAMMER makeoptions WITH_CTF=1 makeoptions DEBUG=-g options ZFS options XENHVM options USB_DEBUG options ATH_ENABLE_11N options AH_AR5416_INTERRUPT_MITIGATION options AH_SUPPORT_AR5416 options IEEE80211_SUPPORT_MESH options IEEE80211_AMPDU_AGE options IEEE80211_DEBUG options SC_PIXEL_MODE options VESA options AHD_REG_PRETTY_PRINT options AHC_REG_PRETTY_PRINT options ATA_STATIC_ID options ACPI_DMAR options SMP options MALLOC_DEBUG_MAXZONES=8 options INVARIANT_SUPPORT options INVARIANTS options DEADLKRES options GDB options DDB options KDB_TRACE options KDB options INCLUDE_CONFIG_FILE options DDB_CTF options KDTRACE_HOOKS options KDTRACE_FRAME options MAC options CAPABILITIES options CAPABILITY_MODE options AUDIT options HWPMC_HOOKS options KBD_INSTALL_CDEV options PRINTF_BUFR_SIZE=128 options _KPOSIX_PRIORITY_SCHEDULING options SYSVSEM options SYSVMSG options SYSVSHM options STACK options KTRACE options SCSI_DELAY=5000 options COMPAT_FREEBSD7 options COMPAT_FREEBSD6 options COMPAT_FREEBSD5 options COMPAT_FREEBSD4 options COMPAT_FREEBSD32 options GEOM_LABEL options GEOM_RAID options GEOM_PART_GPT options PSEUDOFS options PROCFS options CD9660 options MSDOSFS options NFS_ROOT options NFSLOCKD options NFSD options NFSCL options MD_ROOT options QUOTA options UFS_GJOURNAL options UFS_DIRHASH options UFS_ACL options SOFTUPDATES options FFS options SCTP options TCP_OFFLOAD options INET6 options INET options PREEMPTION options SCHED_ULE options NEW_PCIB options GEOM_PART_MBR options GEOM_PART_EBR_COMPAT options GEOM_PART_EBR options GEOM_PART_BSD device isa device mem device io device uart_ns8250 device cpufreq device acpi device pci device fdc device ahci device ata device mvs device siis device ahc device ahd device esp device hptiop device isp device mpt device mps device sym device trm device adv device adw device aic device bt device isci device scbus device ch device da device sa device cd device pass device ses device amr device arcmsr device ciss device dpt device hptmv device hptnr device hptrr device hpt27xx device iir device ips device mly device twa device tws device aac device aacp device aacraid device ida device mfi device mlx device twe device atkbdc device atkbd device psm device kbdmux device splash device agp device cbb device pccard device cardbus device uart device ppc device ppbus device lpt device ppi device puc device bxe device de device em device igb device ixgbe device le device ti device txp device vx device miibus device ae device age device alc device ale device bce device bfe device bge device cas device dc device et device fxp device gem device hme device jme device lge device msk device nfe device nge device pcn device re device rl device sf device sge device sis device sk device ste device stge device tl device tx device vge device vr device wb device xl device cs device ed device ex device ep device fe device sn device xe device wlan device wlan_wep device wlan_ccmp device wlan_tkip device wlan_amrr device an device ath device ath_pci device ath_hal device ath_rate_sample device ipw device iwi device iwn device malo device mwl device ral device wi device wpi device loop device random device padlock_rng device rdrand_rng device ether device vlan device tun device md device gif device faith device firmware device bpf device uhci device ohci device ehci device xhci device usb device ukbd device umass device sound device snd_cmi device snd_csa device snd_emu10kx device snd_es137x device snd_hda device snd_ich device snd_via8233 device mmc device mmcsd device sdhci device virtio device virtio_pci device vtnet device virtio_blk device virtio_scsi device virtio_balloon device hyperv device xenpci device vmx device vt device vt_vga ------------------------------------------------------------------------ ddb capture buffer -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 09:04:54 2014 Return-Path: Delivered-To: freebsd-current@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 EEF5B65D; Tue, 21 Jan 2014 09:04:54 +0000 (UTC) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C467F1584; Tue, 21 Jan 2014 09:04:54 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.95,695,1384329600"; d="asc'?scan'208";a="138128821" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx12-out.netapp.com with ESMTP; 21 Jan 2014 01:04:47 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 01:04:48 -0800 From: "Eggert, Lars" To: John Baldwin Subject: Re: using ConnectX card as Ethernet (mlxen) Thread-Topic: using ConnectX card as Ethernet (mlxen) Thread-Index: AQHOfL84Utvue43Zsk+plvzCsSUACpldPAwAgTIBQACAAJRngIAAypCA Date: Tue, 21 Jan 2014 09:04:46 +0000 Message-ID: <0C5748ED-5142-46A4-93FA-A6BA2FF77E52@netapp.com> References: <3A359B33-380C-4230-A62C-623765E9376A@jnielsen.net> <2BA72819-3004-4FB6-BB4F-5964B41F6B2F@jnielsen.net> <8D21D2EF-8A74-40A3-A49F-73FDE7C3CFD2@netapp.com> <1536242.pn1tTPOXXc@pippin.baldwin.cx> In-Reply-To: <1536242.pn1tTPOXXc@pippin.baldwin.cx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_D79EDB87-80B0-4DC1-87CA-1B75D20FF0BB"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "freebsd-current@freebsd.org" , John Nielsen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 09:04:55 -0000 --Apple-Mail=_D79EDB87-80B0-4DC1-87CA-1B75D20FF0BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2014-1-20, at 21:59, John Baldwin wrote: > I believe this should work, yes. Getting a crashdump or the panic = messages=20 > would be really helpful in figuring out why it isn't. Thanks. I rebuilt the kernel, and see no crashes anymore. So that's good. But there are a bunch of other issues that maybe someone has some ideas = about: (1) Late attach The ConnectX-3 attaches very late during the boot process, after the = system is already in single-user mode. See the attached dmesg; pci17 and = pci18 (there are two identical cards in this system) first show as "no = driver attached" during the PCI bus enumeration. Only after the system = is single-user mode does the mlx4_core attach to the cards. That means that e.g. trying to set sysctls for these cards in = /etc/sysctl.conf, or configuring their IP addresses via rc.conf is not = possible. At the moment, I work around this by sleeping in rc.local and = then doing assignments there, but that's a hack. Any clues why these cards attach so late? (2) Device numbers change After booting, these cards show up in InfiniBand mode: ib0: flags=3D8002 metric 0 mtu 65520 options=3D80018 lladdr 80.0.0.48.fe.80.0.0.0.0.0.0.f4.52.14.3.0.10.d1.21 nd6 options=3D21 ib1: flags=3D8002 metric 0 mtu 65520 options=3D80018 lladdr 80.0.0.49.fe.80.0.0.0.0.0.0.f4.52.14.3.0.10.d1.22 nd6 options=3D21 ib2: flags=3D8002 metric 0 mtu 65520 options=3D80018 lladdr 80.0.0.48.fe.80.0.0.0.0.0.0.f4.52.14.3.0.10.d0.d1 nd6 options=3D21 ib3: flags=3D8002 metric 0 mtu 65520 options=3D80018 lladdr 80.0.0.49.fe.80.0.0.0.0.0.0.f4.52.14.3.0.10.d0.d2 nd6 options=3D21 Then I force one into Ethernet mode: # sysctl sys.device.mlx4_core0.mlx4_port1=3Deth sys.device.mlx4_core0.mlx4_port1: auto (ib) -> eth and the device numbers on the ib devices change: ib1 is now ib4, and I = have a new mlxen0 device. ib2: flags=3D8002 metric 0 mtu 65520 options=3D80018 lladdr 80.0.0.48.fe.80.0.0.0.0.0.0.f4.52.14.3.0.10.d0.d1 nd6 options=3D21 ib3: flags=3D8002 metric 0 mtu 65520 options=3D80018 lladdr 80.0.0.49.fe.80.0.0.0.0.0.0.f4.52.14.3.0.10.d0.d2 nd6 options=3D21 mlxen0: flags=3D8843 metric 0 = mtu 1500 = options=3Dd05bb ether f4:52:14:10:d1:21 inet6 fe80::f652:14ff:fe10:d121%mlxen0 prefixlen 64 scopeid 0xe=20= nd6 options=3D21 media: Ethernet autoselect status: no carrier ib4: flags=3D8002 metric 0 mtu 65520 options=3D80018 lladdr 80.0.0.4a.fe.80.0.0.0.0.0.0.f4.52.14.3.0.10.d1.22 nd6 options=3D21 When I change another port into Ethernet mode # sysctl sys.device.mlx4_core0.mlx4_port2=3Deth sys.device.mlx4_core0.mlx4_port2: auto (ib) -> eth device numbers change again. Now mxlen0 disappears and becomes mxlen1, = and I have a new mxlen2 device: ib2: flags=3D8002 metric 0 mtu 65520 options=3D80018 lladdr 80.0.0.48.fe.80.0.0.0.0.0.0.f4.52.14.3.0.10.d0.d1 nd6 options=3D21 ib3: flags=3D8002 metric 0 mtu 65520 options=3D80018 lladdr 80.0.0.49.fe.80.0.0.0.0.0.0.f4.52.14.3.0.10.d0.d2 nd6 options=3D21 mlxen1: flags=3D8843 metric 0 = mtu 1500 = options=3Dd05bb ether f4:52:14:10:d1:21 inet6 fe80::f652:14ff:fe10:d121%mlxen1 prefixlen 64 scopeid 0xe=20= nd6 options=3D21 media: Ethernet autoselect status: no carrier mlxen2: flags=3D8843 metric 0 = mtu 1500 = options=3Dd05bb ether f4:52:14:10:d1:22 inet6 fe80::f652:14ff:fe10:d122%mlxen2 prefixlen 64 scopeid 0xf=20= nd6 options=3D21 media: Ethernet autoselect status: no carrier Changing the other two ports (on the second card) to Ethernet mode=20 # sysctl sys.device.mlx4_core1.mlx4_port1=3Deth sys.device.mlx4_core1.mlx4_port1: auto (ib) -> eth # sysctl sys.device.mlx4_core1.mlx4_port2=3Deth sys.device.mlx4_core1.mlx4_port2: auto (ib) -> eth leaves me with mlxen1, mlxen2, mlxen4 and mlxen 5: mlxen1: flags=3D8843 metric 0 = mtu 1500 = options=3Dd05bb ether f4:52:14:10:d1:21 inet6 fe80::f652:14ff:fe10:d121%mlxen1 prefixlen 64 scopeid 0xe=20= nd6 options=3D21 media: Ethernet autoselect status: no carrier mlxen2: flags=3D8843 metric 0 = mtu 1500 = options=3Dd05bb ether f4:52:14:10:d1:22 inet6 fe80::f652:14ff:fe10:d122%mlxen2 prefixlen 64 scopeid 0xf=20= inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255=20 nd6 options=3D21 media: Ethernet autoselect (40Gbase-CR4 = ) status: active mlxen4: flags=3D8843 metric 0 = mtu 1500 = options=3Dd05bb ether f4:52:14:10:d0:d1 inet6 fe80::f652:14ff:fe10:d0d1%mlxen4 prefixlen 64 scopeid 0x10=20= nd6 options=3D21 media: Ethernet autoselect status: no carrier mlxen5: flags=3D8843 metric 0 = mtu 1500 = options=3Dd05bb ether f4:52:14:10:d0:d2 inet6 fe80::f652:14ff:fe10:d0d2%mlxen5 prefixlen 64 scopeid 0x11=20= inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255=20 nd6 options=3D21 media: Ethernet autoselect (10Gbase-CX4 = ) status: active Needless to say, having devices change numbers is problematic. (3) 40G TCP performance I barely get over 10G with netperf over the 40G interfaces: root@one:~ # netperf -H two-mlxen2 -- -s512k -S512K MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to = two-mlxen2.muclab () port 0 AF_INET : histogram : interval : dirty data = : demo Recv Send Send =20 Socket Socket Message Elapsed =20 Size Size Size Time Throughput =20 bytes bytes bytes secs. 10^6bits/sec =20 524288 512000 512000 10.07 10268.01 =20 Any clues as to what could be limiting performance here? Thanks, Lars --Apple-Mail=_D79EDB87-80B0-4DC1-87CA-1B75D20FF0BB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUt44K9ZcnpRveo1xAQLNZAP/Zb4RgcWGfayz8qAx7Zqd/iC306na4yCq KTb4VKA7vduD9iKEzkD3+XOY2jbHHgpWzGljStPu0X1OYErkn+2IMoICBXMMn/1I uRPrgOFJqAzcCZmBNQ6G8FFCxX2ahb/CuNDTfhGWpfV7vP4IouGPAN81GaSq794/ gsodbbfJcG8= =ALPM -----END PGP SIGNATURE----- --Apple-Mail=_D79EDB87-80B0-4DC1-87CA-1B75D20FF0BB-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 09:05:51 2014 Return-Path: Delivered-To: freebsd-current@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 E82F7845; Tue, 21 Jan 2014 09:05:50 +0000 (UTC) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9931D15AF; Tue, 21 Jan 2014 09:05:50 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.95,695,1384329600"; d="asc'?txt'?scan'208";a="138128965" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx12-out.netapp.com with ESMTP; 21 Jan 2014 01:05:49 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 01:05:49 -0800 From: "Eggert, Lars" To: John Baldwin Subject: Re: using ConnectX card as Ethernet (mlxen) Thread-Topic: using ConnectX card as Ethernet (mlxen) Thread-Index: AQHOfL84Utvue43Zsk+plvzCsSUACpldPAwAgTIBQACAAJRngIAAypCAgAAATIA= Date: Tue, 21 Jan 2014 09:05:48 +0000 Message-ID: <02DE6AEB-1EB5-423A-BEAA-BEB3E4D593F9@netapp.com> References: <3A359B33-380C-4230-A62C-623765E9376A@jnielsen.net> <2BA72819-3004-4FB6-BB4F-5964B41F6B2F@jnielsen.net> <8D21D2EF-8A74-40A3-A49F-73FDE7C3CFD2@netapp.com> <1536242.pn1tTPOXXc@pippin.baldwin.cx> <0C5748ED-5142-46A4-93FA-A6BA2FF77E52@netapp.com> In-Reply-To: <0C5748ED-5142-46A4-93FA-A6BA2FF77E52@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_E22B2B23-381C-46F4-AA4F-1776E04F29AE"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "freebsd-current@freebsd.org" , John Nielsen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 09:05:51 -0000 --Apple-Mail=_E22B2B23-381C-46F4-AA4F-1776E04F29AE Content-Type: multipart/mixed; boundary="Apple-Mail=_963D1D27-DD10-4006-B772-9A93CDC88A7B" --Apple-Mail=_963D1D27-DD10-4006-B772-9A93CDC88A7B Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 2014-1-21, at 10:04, Lars Eggert wrote: > See the attached dmesg which I of course forget to attach (sigh). See below. Lars --Apple-Mail=_963D1D27-DD10-4006-B772-9A93CDC88A7B Content-Disposition: attachment; filename=dmesg.txt Content-Type: text/plain; x-mac-type=54455854; x-mac-creator=21526368; x-unix-mode=0644; name="dmesg.txt" Content-Transfer-Encoding: quoted-printable GDB: no debug ports present970 KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #8 ab08c30(fas3270)-dirty: Tue Jan 21 09:07:36 CET 2014 = elars@stanley.muccbc.hq.netapp.com:/usr/home/elars/obj/usr/home/elars/src/= sys/FAS3270 amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: Intel(R) Xeon(R) CPU E5240 @ 3.00GHz (3000.17-MHz K8-class CPU) Origin=3D"GenuineIntel" Id=3D0x1067a Family=3D0x6 Model=3D0x17 = Stepping=3D10 = Features=3D0xbfebfbff = Features2=3D0xc0ce3bd AMD Features=3D0x20100800 AMD Features2=3D0x1 TSC: P-state invariant, performance statistics real memory =3D 18253611008 (17408 MB) avail memory =3D 16599695360 (15830 MB) MPTable: Event timer "LAPIC" quality 400 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 2 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 random device not loaded; using insecure entropy ioapic0: Assuming intbase of 0 ioapic0 irqs 0-23 on motherboard netmap: loaded module random: initialized smbios0: at iomem 0xf6c00-0xf6c1e on motherboard smbios0: Version: 2.5 cryptosoft0: on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 cxgbc0: mem 0xdd001000-0xdd001fff,0xdc800000-0xdcffffff,0xdd000000-0xdd000fff irq 16 at device 0.0 on pci1 cxgbc0: AD8158 0xf=3D0x3 0x1=3D0xf cxgbc0: using MSI-X interrupts (9 vectors) cxgb0: on cxgbc0 cxgb0: Ethernet address: 00:a0:98:30:c2:2a cxgb1: on cxgbc0 cxgb1: Ethernet address: 00:a0:98:30:c2:2b cxgbc0: Firmware Version 7.11.0 pcib2: at device 3.0 on pci0 pci2: on pcib2 pcib3: at device 4.0 on pci0 pci3: on pcib3 pcib4: mem 0xdd300000-0xdd31ffff irq 16 at device 0.0 on pci3 pci4: on pcib4 pcib3: unable to route slot 0 INTB pcib5: irq 16 at device 4.0 on pci4 pci5: on pcib5 pcib6: irq 10 at device 5.0 on pci4 pci6: on pcib6 ix0: mem 0xdd400000-0xdd47ffff,0xdd500000-0xdd503fff irq 17 at device 0.0 on pci6 ix0: Using MSIX interrupts with 5 vectors ix0: Ethernet address: 90:e2:ba:37:d5:b4 ix0: PCI Express Bus: Speed 5.0GT/s Width x8 001.000008 [2141] netmap_attach success for ix0 ix1: mem 0xdd480000-0xdd4fffff,0xdd504000-0xdd507fff irq 18 at device 0.1 on pci6 ix1: Using MSIX interrupts with 5 vectors ix1: Ethernet address: 90:e2:ba:37:d5:b5 ix1: PCI Express Bus: Speed 5.0GT/s Width x8 001.000009 [2141] netmap_attach success for ix1 pcib7: irq 16 at device 8.0 on pci4 pci7: on pcib7 pcib8: at device 0.0 on pci7 pci8: on pcib8 pcib9: at device 0.0 on pci8 pci9: on pcib9 em0: mem 0xdd620000-0xdd63ffff,0xdd600000-0xdd61ffff irq 16 at device 0.0 on pci9 em0: Using an MSI interrupt em0: Ethernet address: 00:1b:21:a8:a5:34 001.000010 [2141] netmap_attach success for em0 em1: mem 0xdd660000-0xdd67ffff,0xdd640000-0xdd65ffff irq 17 at device 0.1 on pci9 em1: Using an MSI interrupt em1: Ethernet address: 00:1b:21:a8:a5:35 001.000011 [2141] netmap_attach success for em1 pcib10: at device 1.0 on pci8 pci10: on pcib10 em2: mem 0xdd720000-0xdd73ffff,0xdd700000-0xdd71ffff irq 17 at device 0.0 on pci10 em2: Using an MSI interrupt em2: Ethernet address: 00:1b:21:a8:a5:36 001.000012 [2141] netmap_attach success for em2 em3: mem 0xdd760000-0xdd77ffff,0xdd740000-0xdd75ffff irq 18 at device 0.1 on pci10 em3: Using an MSI interrupt em3: Ethernet address: 00:1b:21:a8:a5:37 001.000013 [2141] netmap_attach success for em3 pcib11: at device 5.0 on pci0 pci11: on pcib11 pcib12: at device 6.0 on pci0 pci12: on pcib12 pcib0: unable to route slot 6 INTA pcib13: mem 0xddd00000-0xddd1ffff irq 5 at device 0.0 on pci12 pci13: on pcib13 pcib13: unable to route slot 4 INTA pcib13: unable to route slot 5 INTA pcib13: unable to route slot 6 INTA pcib14: irq 16 at device 0.0 on pci13 pci14: on pcib14 pcib15: mem 0xdda00000-0xdda1ffff irq 16 at device 0.0 on pci14 pci15: on pcib15 pcib14: unable to route slot 0 INTB pcib14: unable to route slot 0 INTB pcib14: unable to route slot 0 INTB pcib16: irq 10 at device 1.0 on pci15 pci16: on pcib16 pcib17: irq 16 at device 4.0 on pci15 pci17: on pcib17 pci17: at device 0.0 (no driver attached) pcib18: irq 10 at device 5.0 on pci15 pci18: on pcib18 pci18: at device 0.0 (no driver attached) pcib19: irq 16 at device 8.0 on pci15 pci19: on pcib19 pcib20: irq 10 at device 9.0 on pci15 pci20: on pcib20 pcib21: irq 5 at device 4.0 on pci13 pci21: on pcib21 pcib22: irq 10 at device 5.0 on pci13 pci22: on pcib22 pci22: at device 0.0 (no driver attached) pci22: at device 0.1 (no driver attached) pcib23: irq 11 at device 6.0 on pci13 pci23: on pcib23 pci23: at device 0.0 (no driver attached) pcib24: at device 7.0 on pci0 pci24: on pcib24 pci0: at device 8.0 (no driver attached) uhci0: port 0x1820-0x183f irq 16 at device 26.0 on pci0 usbus0 on uhci0 ehci0: mem 0xde101000-0xde1013ff irq 18 at device 26.7 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 pcib25: irq 16 at device 28.0 on pci0 pci25: on pcib25 em4: port 0x3000-0x301f mem 0xdde20000-0xdde3ffff,0xdde00000-0xdde1ffff irq 16 at device 0.0 on pci25 em4: Using an MSI interrupt em4: Ethernet address: 00:a0:98:30:c2:28 001.000015 [2141] netmap_attach success for em4 em5: port 0x3020-0x303f mem 0xdde60000-0xdde7ffff,0xdde40000-0xdde5ffff irq 17 at device 0.1 on pci25 em5: Using an MSI interrupt em5: Ethernet address: 00:a0:98:30:c2:29 001.000016 [2141] netmap_attach success for em5 pcib26: irq 16 at device 28.4 on pci0 pci26: on pcib26 bge0: mem 0xddf00000-0xddf0ffff irq 16 at device 0.0 on pci26 bge0: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:a0:98:30:c2:2c pcib27: irq 17 at device 28.5 on pci0 pci27: on pcib27 bge1: mem 0xde000000-0xde00ffff irq 17 at device 0.0 on pci27 bge1: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge1: Ethernet address: 00:a0:98:30:c2:2d uhci1: port 0x1840-0x185f irq 16 at device 29.0 on pci0 usbus2 on uhci1 ehci1: mem 0xde101400-0xde1017ff irq 16 at device 29.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci1 pcib28: at device 30.0 on pci0 pci28: on pcib28 isab0: at device 31.0 on pci0 isa0: on isab0 ichsmb0: port 0x1860-0x187f mem 0xde101800-0xde1018ff irq 17 at device 31.3 on pci0 smbus0: on ichsmb0 smb0: on smbus0 pci0: at device 31.6 (no driver attached) cpu0 on motherboard coretemp0: on cpu0 est0: failed to enable SpeedStep p4tcc0: on cpu0 cpu1 on motherboard coretemp1: on cpu1 est1: failed to enable SpeedStep p4tcc1: on cpu1 cpu2 on motherboard coretemp2: on cpu2 est2: failed to enable SpeedStep p4tcc2: on cpu2 cpu3 on motherboard coretemp3: on cpu3 est3: failed to enable SpeedStep p4tcc3: on cpu3 ichwd0 on isa0 ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 ipmi0: on isa0 ipmi0: KCS mode found at io 0xca2 alignment 0x1 on isa ichwd0 at port 0x1030-0x1037,0x1060-0x107f on isa0 ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 orm0: at iomem 0xc0800-0xc17ff,0xc1800-0xc27ff,0xdc000-0xdffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 atkbd0: [GIANT-LOCKED] uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 atrtc0: at port 0x70 irq 8 on isa0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: at port 0x40 on isa0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounters tick every 1.000 msec iw_cxgb: Chelsio T3 RDMA Driver loaded random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ipmi0: IPMI device rev. 1, firmware rev. 1.00, version 2.0 ipmi0: Number of channels 0 ipmi0: Attached watchdog bootpc_init: wired to interface 'em4' Sending DHCP Discover packet from interface em4 (00:a0:98:30:c2:28) uhub0: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered ugen3.2: at usbus3 umass0: on usbus3 da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: Serial Number 0FF0022700196137 da0: 40.000MB/s transfers da0: 1936MB (3964928 512 byte sectors: 255H 63S/T 246C) da0: quirks=3D0x2 ugen1.2: at usbus1 umass1: on usbus1 em4: link state changed to UP Received DHCP Offer packet on em4 from 192.168.0.1 (accepted) (no root path) (boot_file) Received DHCP Offer packet on em4 from 192.168.0.1 (ignored) (no root path) (boot_file) da1 at umass-sim1 bus 1 scbus1 target 0 lun 0 da1: Removable Direct Access SCSI-6 device da1: Serial Number AA011208121048257561 da1: 40.000MB/s transfers da1: 30533MB (62533296 512 byte sectors: 255H 63S/T 3892C) da1: quirks=3D0x2 Sending DHCP Request packet from interface em4 (00:a0:98:30:c2:28) Received DHCP Ack packet on em4 from 192.168.0.1 (accepted) (no root path) (boot_file) em4 at 192.168.1.1 server 192.168.0.1 boot file /pxe/pxelinux.0 subnet mask 255.255.0.0 router 192.168.0.1 rootfs 192.168.0.1:/usr/home/elars/dst hostname one Adjusted interface em4 SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! Timecounter "TSC-low" frequency 1500085939 Hz quality 1000 hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 IAP/2/40/0x3ff IAF/3/40/0x67 Trying to mount root from nfs: []... NFS ROOT: 192.168.0.1:/usr/home/elars/dst Running ipoib_demux (0xffffffff805f5ff0) mlx4_core0: mem 0xdd800000-0xdd8fffff,0xde800000-0xdeffffff irq 16 at device 0.0 on pci17 <6>mlx4_core: Mellanox ConnectX core driver v1.1 (Dec, 2011) <6>mlx4_core: Initializing mlx4_core em0: link state changed to UP em1: link state changed to UP em2: link state changed to UP em3: link state changed to UP Interface em4 IP-Address 192.168.1.1 Broadcast 192.168.255.255 Entropy harvesting: interrupts ethernet point_to_point swi. eval: cannot create /etc/hostid: Read-only file system /etc/rc: WARNING: could not store hostuuid in /etc/hostid. Writing entropy file:. Additional TCP/IP options: IPv6 Privacy Addresses. cxgb0: link state changed to DOWN mlx4_core0: 64B EQEs/CQEs supported by the device but not enabled <6>mlx4_en: Mellanox ConnectX HCA Ethernet driver v1.5.2 (July 2010) mlx4_core1: mem 0xdd900000-0xdd9fffff,0xdf000000-0xdf7fffff irq 17 at device 0.0 on pci18 <6>mlx4_core: Initializing mlx4_core cxgb1: link state changed to DOWN em0: link state changed to DOWN ix0: link state changed to UP em1: link state changed to DOWN em2: link state changed to DOWN em3: link state changed to DOWN Starting dhclient. DHCPDISCOVER on em4 to 255.255.255.255 port 67 interval 7 DHCPOFFER from 192.168.0.1 unknown dhcp option value 0xd0 unknown dhcp option value 0xd1 unknown dhcp option value 0xd2 unknown dhcp option value 0xd3 ix1: link state changed to UP em1: link state changed to UP DHCPREQUEST on em4 to 255.255.255.255 port 67 DHCPACK from 192.168.0.1 unknown dhcp option value 0xd0 unknown dhcp option value 0xd1 unknown dhcp option value 0xd2 unknown dhcp option value 0xd3 bound to 192.168.1.1 -- renewal in 21600 seconds. bge0: link state changed to DOWN em0: link state changed to UP bge1: link state changed to DOWN em2: link state changed to UP em3: link state changed to UP bge0: link state changed to UP bge1: link state changed to UP Starting Network: lo0 cxgb0 cxgb1 ix0 ix1 em0 em1 em2 em3 em4 em5 bge0 bge1. Starting pflogd: add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Mounting NFS file systems:. Mounting late file systems:. Starting rpcbind. Starting local daemons:. Performing sanity check on sshd configuration. Tue Jan 21 09:20:07 CET 2014 FreeBSD/amd64 (one) (ttyu0) login: mlx4_core1: 64B EQEs/CQEs supported by the device but not enabled <6>mlx4_ib: Mellanox ConnectX InfiniBand driver v1.0 (April 4, 2008) <7>ib0: max_srq_sge=3D31 <7>ib0: max_cm_mtu =3D 0x10000, num_frags=3D16 ib0: Attached to mlx4_0 port 1 <7>ib1: max_srq_sge=3D31 <7>ib1: max_cm_mtu =3D 0x10000, num_frags=3D16 ib1: Attached to mlx4_0 port 2 <6>mlx4_ib: Mellanox ConnectX InfiniBand driver v1.0 (April 4, 2008) <7>ib2: max_srq_sge=3D31 <7>ib2: max_cm_mtu =3D 0x10000, num_frags=3D16 ib2: Attached to mlx4_1 port 1 <7>ib3: max_srq_sge=3D31 <7>ib3: max_cm_mtu =3D 0x10000, num_frags=3D16 ib3: Attached to mlx4_1 port 2 FreeBSD/amd64 (one) (ttyu0) login: --Apple-Mail=_963D1D27-DD10-4006-B772-9A93CDC88A7B Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_963D1D27-DD10-4006-B772-9A93CDC88A7B-- --Apple-Mail=_E22B2B23-381C-46F4-AA4F-1776E04F29AE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUt44bNZcnpRveo1xAQKVwAP/fFrO47F78xe4+dagd7GLwjZK4fJGdAD7 kkEN7MCKdm7DIxhrVHFqOfKELr/p+C6KJXZKNbv8df+QE7mwtxGZvj6VMjk/S2rP 4JmM7pA5t4IlBXzyJTBIBeDb0yNbjI3CepolkUQepbVOmPRQKlc9BYDMmd1GWZQU bxFEk+ik5x4= =spCJ -----END PGP SIGNATURE----- --Apple-Mail=_E22B2B23-381C-46F4-AA4F-1776E04F29AE-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 09:31:45 2014 Return-Path: Delivered-To: freebsd-current@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 943DA324; Tue, 21 Jan 2014 09:31:45 +0000 (UTC) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 52A941816; Tue, 21 Jan 2014 09:31:45 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.95,695,1384329600"; d="asc'?scan'208";a="97191685" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx11-out.netapp.com with ESMTP; 21 Jan 2014 01:31:44 -0800 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 01:31:44 -0800 From: "Eggert, Lars" To: John Baldwin Subject: Re: using ConnectX card as Ethernet (mlxen) Thread-Topic: using ConnectX card as Ethernet (mlxen) Thread-Index: AQHOfL84Utvue43Zsk+plvzCsSUACpldPAwAgTIBQACAAJRngIAAypCAgAAATICAAAc/gA== Date: Tue, 21 Jan 2014 09:31:43 +0000 Message-ID: References: <3A359B33-380C-4230-A62C-623765E9376A@jnielsen.net> <2BA72819-3004-4FB6-BB4F-5964B41F6B2F@jnielsen.net> <8D21D2EF-8A74-40A3-A49F-73FDE7C3CFD2@netapp.com> <1536242.pn1tTPOXXc@pippin.baldwin.cx> <0C5748ED-5142-46A4-93FA-A6BA2FF77E52@netapp.com> <02DE6AEB-1EB5-423A-BEAA-BEB3E4D593F9@netapp.com> In-Reply-To: <02DE6AEB-1EB5-423A-BEAA-BEB3E4D593F9@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_65D9E374-BF91-4B2D-A874-1EAFE1550969"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "freebsd-current@freebsd.org" , John Nielsen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 09:31:45 -0000 --Apple-Mail=_65D9E374-BF91-4B2D-A874-1EAFE1550969 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Last follow-up: I just saw that there are some additional messages = (errors?) on the serial console when changing the device from IB to = Ethernet, maybe they mean something to someone: root@one:~ # sysctl sys.device.mlx4_core0.mlx4_port1=3Deth sys.device.mlx4_core0.mlx4_port1: auto (ib)<7>ib0: stopping interface <7>ib0: downing ib_dev <7>ib0: stopping multicast thread <7>ib0: flushing multicast list <7>"qpn 0x48: invalid attribute mask specified " "for transition 0 to 6.=20= qp_type 4," " attr_mask 0x1\n"<4>ib0: Failed to modify QP to ERROR state <7>ib0: All sends and receives done. <7>ib0: cleaning up ib_dev <7>ib0: stopping multicast thread <7>ib0: flushing multicast list <7>ib0: Cleanup ipoib connected mode. <7>ib1: stopping interface <7>ib1: downing ib_dev <7>ib1: stopping multicast thread <7>ib1: flushing multicast list <7>"qpn 0x49: invalid attribute mask specified " "for transition 0 to 6.=20= qp_type 4," " attr_mask 0x1\n"<4>ib1: Failed to modify QP to ERROR state <7>ib1: All sends and receives done. <7>ib1: cleaning up ib_dev <7>ib1: stopping multicast thread <7>ib1: flushing multicast list <7>ib1: Cleanup ipoib connected mode. <6>mlx4_en mlx4_core0: Using 5 tx rings for port:1 <6>mlx4_en mlx4_core0: Defaulting to 4 rx rings for port:1 <6>mlx4_en mlx4_core0: Activating port:1 mlxen0: Ethernet address: f4:52:14:10:d1:21 <4>mlx4_en: mlx4_core0: Port 1: Using 5 TX rings <4>mlx4_en: mlx4_core0: Port 1: Using 4 RX rings <6>mlx4_ib: Mellanox ConnectX InfiniBand driver v1.Jan 21 09:21:31 0=20 (April 4, 2008) one kernel: mlx4_en: mlx4_core0: Port 1: Using 5 TX rings Jan <7>ib4: max_srq_sge=3D31 21 09:21:31 one <7>ib4: max_cm_mtu =3D 0x10000, num_frags=3D16 kernel: mlx4_en:ib4: mlx4_core0: PorAttached to mlx4_0 port 2 t 1: Using 4 RX rings -> eth Lars --Apple-Mail=_65D9E374-BF91-4B2D-A874-1EAFE1550969 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUt4+f9ZcnpRveo1xAQJ3GgP+PbSbu12f8fJem3cbcmIWFGcBVbyqkbhb w+zwogywkhlsFpQwHNzIe2zuNDjmiXXpUmFDxK6Jr7YxR1PWdgWOt56l8pEz/3eD BEJQXO5aVbl9BOP/QxSJHRIkAQTkrVDEzT97pZ/R8zFiUyvdoGLacK2ihWpVjE5T WFrbKpgmfbo= =+9BH -----END PGP SIGNATURE----- --Apple-Mail=_65D9E374-BF91-4B2D-A874-1EAFE1550969-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 09:36:36 2014 Return-Path: Delivered-To: freebsd-current@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 4353E4E1 for ; Tue, 21 Jan 2014 09:36:36 +0000 (UTC) Received: from forward10l.mail.yandex.net (forward10l.mail.yandex.net [84.201.143.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EBA7E1866 for ; Tue, 21 Jan 2014 09:36:35 +0000 (UTC) Received: from smtp18.mail.yandex.net (smtp18.mail.yandex.net [95.108.252.18]) by forward10l.mail.yandex.net (Yandex) with ESMTP id 2EECDBA1020; Tue, 21 Jan 2014 13:36:28 +0400 (MSK) Received: from smtp18.mail.yandex.net (localhost [127.0.0.1]) by smtp18.mail.yandex.net (Yandex) with ESMTP id D3FDC18A062A; Tue, 21 Jan 2014 13:36:27 +0400 (MSK) Received: from 84.201.164.23-vpn.dhcp.yndx.net (84.201.164.23-vpn.dhcp.yndx.net [84.201.164.23]) by smtp18.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 9DdY01E5gE-aRfCh15s; Tue, 21 Jan 2014 13:36:27 +0400 (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (Client certificate not present) X-Yandex-Uniq: 44118f56-7ba3-499e-a70e-de528c98fa1c DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1390296987; bh=tqZnaXV5tHfPpHSc7SYTaPzYBhlXHV87Hlp+3VMkyZY=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=T4xcTvUa5h4KD+fED6p+Uk1LeDidF2iq68rnSkgoWdt2ZjqffgteL5FnFBZ48DPjb 12FTCjZJlCOKmfzHNuWMSPB2qWbRY3RnARyATsGr2HjmTqa3nCGa6ytR393tVpa0Yv jNxDWGMBtKPCQcgOvxiuSmsKAKm21yt4ajz6jjaU= Authentication-Results: smtp18.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <52DE3F6B.6050209@yandex.ru> Date: Tue, 21 Jan 2014 13:35:39 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Thomas Hoffmann , freebsd-current Subject: Re: Problem updating bootcode on ZFS on root system with MBR References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 09:36:36 -0000 On 20.01.2014 23:32, Thomas Hoffmann wrote: > I am running 11.0-CURRENT (r260850) with zfs on root with MBR. > > After upgrading my 10.0-RELEASE (r260669) system to 11.0-CURRENT (r260850) > my zpools reported that they needed to be upgraded. So, I upgraded my > zpools and I am attempting to update the bootcode (as required). I managed > to get the boot1 stage code updated, but cannot get the boot2 stage code > updated. Here is what I have done: > > # sysctl kern.geom.debugflags=0x10 > kern.geom.debugflags: 0 -> 16 > > # dd if=/boot/zfsboot of=/tmp/zfsboot1 count=1 > 1+0 records in > 1+0 records out > 512 bytes transferred in 0.014996 secs (34142 bytes/sec) > > # gpart bootcode -b /tmp/zfsboot1 /dev/ada0s1 > bootcode written to ada0s1 > > # dd if=/boot/zfsboot of=/dev/ada0s1a skip=1 seek=1024 > dd: /dev/ada0s1a: Operation not permitted > > The final dd statement fails with "operation not permitted". In all my > research, understood the initial sysctl command I ran would prevent this > particular error from happening. > > What do I need to do to get the boot2 code written to /dev/ada0s1a? This will work only if ada0s1a isn't in use. The debugflags trick works only for whole disk, i.e. for geoms with rank=1. Another way is calculate needed offset and write bootcode directly to ada0. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 10:47:08 2014 Return-Path: Delivered-To: freebsd-current@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 746747C0 for ; Tue, 21 Jan 2014 10:47:08 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BDEA01EB7 for ; Tue, 21 Jan 2014 10:47:07 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA28375; Tue, 21 Jan 2014 12:46:58 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1W5YrC-000HcB-3z; Tue, 21 Jan 2014 12:46:58 +0200 Message-ID: <52DE4FD0.5030409@FreeBSD.org> Date: Tue, 21 Jan 2014 12:45:36 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" , Thomas Hoffmann , freebsd-current Subject: Re: Problem updating bootcode on ZFS on root system with MBR References: <52DE3F6B.6050209@yandex.ru> In-Reply-To: <52DE3F6B.6050209@yandex.ru> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 10:47:08 -0000 on 21/01/2014 11:35 Andrey V. Elsukov said the following: > On 20.01.2014 23:32, Thomas Hoffmann wrote: >> I am running 11.0-CURRENT (r260850) with zfs on root with MBR. >> >> After upgrading my 10.0-RELEASE (r260669) system to 11.0-CURRENT (r260850) >> my zpools reported that they needed to be upgraded. So, I upgraded my >> zpools and I am attempting to update the bootcode (as required). I managed >> to get the boot1 stage code updated, but cannot get the boot2 stage code >> updated. Here is what I have done: >> >> # sysctl kern.geom.debugflags=0x10 >> kern.geom.debugflags: 0 -> 16 >> >> # dd if=/boot/zfsboot of=/tmp/zfsboot1 count=1 >> 1+0 records in >> 1+0 records out >> 512 bytes transferred in 0.014996 secs (34142 bytes/sec) >> >> # gpart bootcode -b /tmp/zfsboot1 /dev/ada0s1 >> bootcode written to ada0s1 >> >> # dd if=/boot/zfsboot of=/dev/ada0s1a skip=1 seek=1024 >> dd: /dev/ada0s1a: Operation not permitted >> >> The final dd statement fails with "operation not permitted". In all my >> research, understood the initial sysctl command I ran would prevent this >> particular error from happening. >> >> What do I need to do to get the boot2 code written to /dev/ada0s1a? > > This will work only if ada0s1a isn't in use. The debugflags trick works > only for whole disk, i.e. for geoms with rank=1. Another way is > calculate needed offset and write bootcode directly to ada0. And ultimately we should extend our ZFS interface with an ioctl to write a blob to a boot code area of a specified ZFS leaf vdev. This would the right way to install zfsboot. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 11:19:19 2014 Return-Path: Delivered-To: freebsd-current@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 79AE6196; Tue, 21 Jan 2014 11:19:19 +0000 (UTC) Received: from forward10l.mail.yandex.net (forward10l.mail.yandex.net [IPv6:2a02:6b8:0:1819::a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2ECA01178; Tue, 21 Jan 2014 11:19:18 +0000 (UTC) Received: from smtp17.mail.yandex.net (smtp17.mail.yandex.net [95.108.252.17]) by forward10l.mail.yandex.net (Yandex) with ESMTP id A58E0BA0ECA; Tue, 21 Jan 2014 15:19:14 +0400 (MSK) Received: from smtp17.mail.yandex.net (localhost [127.0.0.1]) by smtp17.mail.yandex.net (Yandex) with ESMTP id 3FDD1190071C; Tue, 21 Jan 2014 15:19:14 +0400 (MSK) Received: from 84.201.164.23-vpn.dhcp.yndx.net (84.201.164.23-vpn.dhcp.yndx.net [84.201.164.23]) by smtp17.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id NlWEjdaRN2-JDNaYj6x; Tue, 21 Jan 2014 15:19:13 +0400 (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (Client certificate not present) X-Yandex-Uniq: 54b15342-1337-4987-aabd-629469966c1f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1390303153; bh=NtnPmyYWtUNIg7PjtxVtV73kNxb1+F1kniDIx243uGA=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=GmFn91W17+mj8XbrPVv8URQvXZdo7VdvuJEdHbdIHDpxwrQVwzOdb07h7aLl+T35E DN72zgabziMtwYI+RKdEwiX82/JvmzgN0SDq8WF5MSgybmB7z/Ao8RimpadXTrL+Pi 1luF+jG5y+4xj3L3D/g5eQ2dk5Xo3KBpOzV4rp/g= Authentication-Results: smtp17.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <52DE5781.7090600@yandex.ru> Date: Tue, 21 Jan 2014 15:18:25 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Andriy Gapon , Thomas Hoffmann , freebsd-current Subject: Re: Problem updating bootcode on ZFS on root system with MBR References: <52DE3F6B.6050209@yandex.ru> <52DE4FD0.5030409@FreeBSD.org> In-Reply-To: <52DE4FD0.5030409@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 11:19:19 -0000 On 21.01.2014 14:45, Andriy Gapon wrote: >>> What do I need to do to get the boot2 code written to /dev/ada0s1a? >> >> This will work only if ada0s1a isn't in use. The debugflags trick works >> only for whole disk, i.e. for geoms with rank=1. Another way is >> calculate needed offset and write bootcode directly to ada0. > > > And ultimately we should extend our ZFS interface with an ioctl to write a blob > to a boot code area of a specified ZFS leaf vdev. This would the right way to > install zfsboot. Hi Andriy, do you have some patches to test? :-) -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 13:34:03 2014 Return-Path: Delivered-To: freebsd-current@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 83E57F11; Tue, 21 Jan 2014 13:34:03 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0316B1DC0; Tue, 21 Jan 2014 13:34:02 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id s0LDXxVL068199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Jan 2014 17:33:59 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id s0LDXxVP068198; Tue, 21 Jan 2014 17:33:59 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 21 Jan 2014 17:33:59 +0400 From: Gleb Smirnoff To: Olivier =?iso-8859-1?Q?Cochard-Labb=E9?= Subject: Re: Regression on 10-RC5 with a multicast routing daemon Message-ID: <20140121133359.GB66160@glebius.int.ru> References: <20140115113430.GK26504@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="yEPQxsgoJgBvi8ip" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" , Andre Oppermann X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 13:34:03 -0000 --yEPQxsgoJgBvi8ip Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Sun, Jan 19, 2014 at 02:42:32AM +0100, Olivier Cochard-Labbé wrote: O> > Olivier, O> > O> > O> > TL;DR version: you need not subtract iphdrlen in 10.0. Code in O> > igmp.c:accept_igmp() O> > should be smth like: O> > O> > iphdrlen = ip->ip_hl << 2; O> > #ifdef RAW_INPUT_IS_RAW /* Linux */ O> > ipdatalen = ntohs(ip->ip_len) - iphdrlen; O> > #else O> > #if __FreeBSD_version >= 1000000 O> > ipdatalen = ip->ip_len - iphdrlen; O> > #else O> > ipdatalen = ip->ip_len; O> > #endif O> > #endif O> > O> > O> With this patch I've no more the message "warning - Received packet from O> x.x.x.x shorter (28 bytes) than hdr+data length (20+28)":Thanks! O> But there is still a regression regarding the PIM socket behavior not O> related to the packet format. O> The pim.c include 2 functions (pim_read and pim_accept) that are called O> when the socket received a packet: There functions are never triggered when O> PIM packets are received on 10.0. O> In the same time igmp_read() and igmp_accept() are correctly triggered on O> 9.2 and 10.0. O> tcpdump in non-promiscious mode correctly see input of PIM packet: This O> should confirm that once this daemon is started, it correctly open a PIM O> socket and the multicast filter is updated. Can you please try this patch to kernel? If it doesn't work, can you please gather ktr(4) information with KTR_IPMF compiled into kernel. -- Totus tuus, Glebius. --yEPQxsgoJgBvi8ip Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ip_mroute.c.diff" Index: sys/netinet/ip_mroute.c =================================================================== --- sys/netinet/ip_mroute.c (revision 260904) +++ sys/netinet/ip_mroute.c (working copy) @@ -2557,14 +2557,13 @@ pim_encapcheck(const struct mbuf *m, int off, int * is passed to if_simloop(). */ void -pim_input(struct mbuf *m, int off) +pim_input(struct mbuf *m, int iphlen) { struct ip *ip = mtod(m, struct ip *); struct pim *pim; int minlen; - int datalen = ntohs(ip->ip_len); + int datalen = ntohs(ip->ip_len) - iphlen; int ip_tos; - int iphlen = off; /* Keep statistics */ PIMSTAT_INC(pims_rcv_total_msgs); @@ -2594,8 +2593,7 @@ void * Get the IP and PIM headers in contiguous memory, and * possibly the PIM REGISTER header. */ - if ((m->m_flags & M_EXT || m->m_len < minlen) && - (m = m_pullup(m, minlen)) == 0) { + if (m->m_len < minlen && (m = m_pullup(m, minlen)) == 0) { CTR1(KTR_IPMF, "%s: m_pullup() failed", __func__); return; } --yEPQxsgoJgBvi8ip-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 13:49:13 2014 Return-Path: Delivered-To: freebsd-current@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 9DA6B42E for ; Tue, 21 Jan 2014 13:49:13 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5614B1F00 for ; Tue, 21 Jan 2014 13:49:13 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1W5bhW-00033K-LA for freebsd-current@freebsd.org; Tue, 21 Jan 2014 14:49:10 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 21 Jan 2014 14:49:10 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 21 Jan 2014 14:49:10 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Subject: freebsd-update Date: Tue, 21 Jan 2014 14:49:00 +0100 Lines: 48 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xHdLP4BcmJukl7bttIqAP9ENRicwN13BO" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 X-Enigmail-Version: 1.6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 13:49:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xHdLP4BcmJukl7bttIqAP9ENRicwN13BO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Is there any way I can avoid manually resolving hundreds of merge conflicts of the following type while using freebsd-update ? 1 <<<<<<< current version 2 # $FreeBSD: release/9.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 3 =3D=3D=3D=3D=3D=3D=3D 4 # $FreeBSD: release/10.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 5 >>>>>>> 10.0-RELEASE ? I can't be the only one seeing those...? --xHdLP4BcmJukl7bttIqAP9ENRicwN13BO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlLeesxfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDYxNDE4MkQ3ODMwNDAwMDJFRUIzNDhFNUZE MDhENTA2M0RGRjFEMkMACgkQ/QjVBj3/HSzc9ACfY/qZcziUz0RKgTMXvMfdg2a0 Fv0AnifKf//KNOw+WN/TZyAo0sjWfVQm =vnFW -----END PGP SIGNATURE----- --xHdLP4BcmJukl7bttIqAP9ENRicwN13BO-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 15:13:41 2014 Return-Path: Delivered-To: freebsd-current@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 C90358D8; Tue, 21 Jan 2014 15:13:41 +0000 (UTC) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 879BC175F; Tue, 21 Jan 2014 15:13:41 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id wn1so3248059obc.20 for ; Tue, 21 Jan 2014 07:13:40 -0800 (PST) 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=zd4aZKNQBUqM+oUX2y/02jZyLiPvvb/TfCCAjbQZIdg=; b=lfMlP10dHzA3bEaETF26LEX6zaH6M2ET+lxAmAl4LDGEAp6ECIECFlCSiPnouAIGdF LD4k6IIgsPczLhNw9Ob+nYOF2xpACTak4UVUcsbDy9Hui1Lt26dD9359RKkmiYGdODXM 0Du43fdbelR4x49Ibqh466WY8RT2bsgR5ltd4nx0H8MRYw99yJTISGK9xrvUdefyL0I+ Qd2ZU6ld0yfbnkF1piUPnrEHNd0RtXAUfqSE8hmLSxLv2Q3nNkJqv7rG82KQLIdWn437 uMXcitSx26Zdbu8LDxl/VKd9Qy/DsAMPpwLCLwckiXDFigX1KpD5EzeEDmizWn0C7FyM z97g== MIME-Version: 1.0 X-Received: by 10.182.223.114 with SMTP id qt18mr1881230obc.61.1390317220695; Tue, 21 Jan 2014 07:13:40 -0800 (PST) Received: by 10.76.168.137 with HTTP; Tue, 21 Jan 2014 07:13:40 -0800 (PST) In-Reply-To: References: Date: Tue, 21 Jan 2014 09:13:40 -0600 Message-ID: Subject: Re: freebsd-update From: Antonio Olivares To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 15:13:41 -0000 On Tue, Jan 21, 2014 at 7:49 AM, Ivan Voras wrote: > Hi, > > Is there any way I can avoid manually resolving hundreds of merge > conflicts of the following type while using freebsd-update ? > > 1 <<<<<<< current version > > > 2 # $FreeBSD: release/9.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z > peter $ > > 3 ======= > > > 4 # $FreeBSD: release/10.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z > peter $ > > 5 >>>>>>> 10.0-RELEASE > > > > ? > > I can't be the only one seeing those...? > Yes, One has to manually go one by one to fix these :( I tried at one point a sed command like sed -i "" '>>>>' to fix these, but it did not work correctly. I see errrors when booting when I don't correct these :( Hopefully someone suggests something better, but yes I do see these as well :( Best Regards, Antonio From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 15:46:47 2014 Return-Path: Delivered-To: freebsd-current@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 CC47D556; Tue, 21 Jan 2014 15:46:47 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 988D61A4C; Tue, 21 Jan 2014 15:46:47 +0000 (UTC) Received: from [192.168.5.208] (216-75-226-134.static.wiline.com [216.75.226.134]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id s0LFkihX040669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Jan 2014 15:46:45 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: freebsd-update From: David Chisnall In-Reply-To: Date: Tue, 21 Jan 2014 07:46:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5F09668C-0DEA-4074-A06C-BC4D29F92368@FreeBSD.org> References: To: Antonio Olivares X-Mailer: Apple Mail (2.1822) Cc: FreeBSD Current , Ivan Voras X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 15:46:47 -0000 On 21 Jan 2014, at 07:13, Antonio Olivares = wrote: > On Tue, Jan 21, 2014 at 7:49 AM, Ivan Voras = wrote: >> Hi, >>=20 >> Is there any way I can avoid manually resolving hundreds of merge >> conflicts of the following type while using freebsd-update ? >>=20 >> 1 <<<<<<< current version >>=20 >>=20 >> 2 # $FreeBSD: release/9.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z >> peter $ >>=20 >> 3 =3D=3D=3D=3D=3D=3D=3D >>=20 >>=20 >> 4 # $FreeBSD: release/10.0.0/etc/csh.cshrc 50472 1999-08-27 = 23:37:10Z >> peter $ >>=20 >> 5 >>>>>>> 10.0-RELEASE >>=20 >>=20 >>=20 >> ? >>=20 >> I can't be the only one seeing those...? >>=20 >=20 > Yes, One has to manually go one by one to fix these :( > I tried at one point a sed command like sed -i "" '>>>>' to fix > these, but it did not work correctly. I see errrors when booting when > I don't correct these :( I thought this was fixed already (I didn't see these in the 9.2->10-RC3 = upgrade). Doesn't freebsd-update pass -F (If the files differ only by = VCS Id ($FreeBSD) install the new file) to mergemaster? David From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 15:49:04 2014 Return-Path: Delivered-To: freebsd-current@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 1F58F8C6 for ; Tue, 21 Jan 2014 15:49:04 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 61B051A93 for ; Tue, 21 Jan 2014 15:49:03 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA04315; Tue, 21 Jan 2014 17:48:59 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1W5dZT-000HzN-6g; Tue, 21 Jan 2014 17:48:59 +0200 Message-ID: <52DE9699.5040801@FreeBSD.org> Date: Tue, 21 Jan 2014 17:47:37 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" , Thomas Hoffmann , freebsd-current Subject: Re: Problem updating bootcode on ZFS on root system with MBR References: <52DE3F6B.6050209@yandex.ru> <52DE4FD0.5030409@FreeBSD.org> <52DE5781.7090600@yandex.ru> In-Reply-To: <52DE5781.7090600@yandex.ru> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 15:49:04 -0000 on 21/01/2014 13:18 Andrey V. Elsukov said the following: > On 21.01.2014 14:45, Andriy Gapon wrote: >>>> What do I need to do to get the boot2 code written to /dev/ada0s1a? >>> >>> This will work only if ada0s1a isn't in use. The debugflags trick works >>> only for whole disk, i.e. for geoms with rank=1. Another way is >>> calculate needed offset and write bootcode directly to ada0. >> >> >> And ultimately we should extend our ZFS interface with an ioctl to write a blob >> to a boot code area of a specified ZFS leaf vdev. This would the right way to >> install zfsboot. > > Hi Andriy, > > do you have some patches to test? :-) > I don't, but the following patch can serve as a very good example. It adds an ioctl that serves a slightly different but quite similar purpose: commit 54802d6659ec134fd221c3daaa8fdf9cee985d39 Author: Andriy Gapon Date: Fri Sep 14 23:15:43 2012 +0300 [wip] zfs: add a new ioctl that allows to place text data into pad2 area The data is placed into Pad2 area of the first vdev label of a given vdev in a given pool. diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h index fb30ea9..4a46cc2 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h @@ -162,6 +162,8 @@ typedef enum { extern int vdev_label_init(vdev_t *vd, uint64_t txg, vdev_labeltype_t reason); +extern int vdev_label_write_pad2(vdev_t *vd, const char *buf, size_t size); + #ifdef __cplusplus } #endif diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c index c7dd3ad..55c87d8 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c @@ -855,6 +855,44 @@ retry: return (error); } +int +vdev_label_write_pad2(vdev_t *vd, const char *buf, size_t size) +{ + spa_t *spa = vd->vdev_spa; + zio_t *zio; + char *pad2; + int flags = ZIO_FLAG_CONFIG_WRITER | ZIO_FLAG_CANFAIL; + int error; + + if (size > VDEV_PAD_SIZE) + return (EINVAL); + + if (!vd->vdev_ops->vdev_op_leaf) + return (ENODEV); + if (vdev_is_dead(vd)) + return (ENXIO); + + ASSERT(spa_config_held(spa, SCL_ALL, RW_WRITER) == SCL_ALL); + + pad2 = zio_buf_alloc(VDEV_PAD_SIZE); + bzero(pad2, VDEV_PAD_SIZE); + memcpy(pad2, buf, size); + +retry: + zio = zio_root(spa, NULL, NULL, flags); + vdev_label_write(zio, vd, 0, pad2, + offsetof(vdev_label_t, vl_pad2), + VDEV_PAD_SIZE, NULL, NULL, flags); + error = zio_wait(zio); + if (error != 0 && !(flags & ZIO_FLAG_TRYHARD)) { + flags |= ZIO_FLAG_TRYHARD; + goto retry; + } + + zio_buf_free(pad2, VDEV_PAD_SIZE); + return (error); +} + /* * ========================================================================== * uberblock load/sync diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c index e208ed8..ff90839 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c @@ -3404,6 +3404,53 @@ zfs_ioc_log_history(const char *unused, nvlist_t *innvl, nvlist_t *outnvl) return (error); } +#ifdef __FreeBSD__ +static int +zfs_ioc_nextboot(const char *unused, nvlist_t *innvl, nvlist_t *outnvl) +{ + char name[MAXNAMELEN]; + spa_t *spa; + vdev_t *vd; + char *command; + uint64_t pool_guid; + uint64_t vdev_guid; + int error; + + if (nvlist_lookup_uint64(innvl, + ZPOOL_CONFIG_POOL_GUID, &pool_guid) != 0) + return (EINVAL); + if (nvlist_lookup_uint64(innvl, + ZPOOL_CONFIG_GUID, &vdev_guid) != 0) + return (EINVAL); + if (nvlist_lookup_string(innvl, + "command", &command) != 0) + return (EINVAL); + + mutex_enter(&spa_namespace_lock); + spa = spa_by_guid(pool_guid, vdev_guid); + if (spa != NULL) + strcpy(name, spa_name(spa)); + mutex_exit(&spa_namespace_lock); + if (spa == NULL) + return (ENOENT); + + if ((error = spa_open(name, &spa, FTAG)) != 0) + return (error); + spa_vdev_state_enter(spa, SCL_ALL); + vd = spa_lookup_by_guid(spa, vdev_guid, B_TRUE); + if (vd == NULL) { + (void) spa_vdev_state_exit(spa, NULL, ENXIO); + spa_close(spa, FTAG); + return (ENODEV); + } + error = vdev_label_write_pad2(vd, command, strlen(command)); + (void) spa_vdev_state_exit(spa, NULL, 0); + txg_wait_synced(spa->spa_dsl_pool, 0); + spa_close(spa, FTAG); + return (error); +} +#endif + /* * The dp_config_rwlock must not be held when calling this, because the * unmount may need to write out data. @@ -5605,6 +5652,9 @@ zfs_ioctl_init(void) zfs_secpolicy_config, POOL_CHECK_NONE); zfs_ioctl_register_dataset_nolog(ZFS_IOC_UNJAIL, zfs_ioc_unjail, zfs_secpolicy_config, POOL_CHECK_NONE); + zfs_ioctl_register("fbsd_nextboot", ZFS_IOC_NEXTBOOT, + zfs_ioc_nextboot, zfs_secpolicy_config, NO_NAME, + POOL_CHECK_NONE, B_FALSE, B_FALSE); #endif } diff --git a/sys/cddl/contrib/opensolaris/uts/common/sys/fs/zfs.h b/sys/cddl/contrib/opensolaris/uts/common/sys/fs/zfs.h index 454c28a..917223dc 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/sys/fs/zfs.h +++ b/sys/cddl/contrib/opensolaris/uts/common/sys/fs/zfs.h @@ -839,6 +839,7 @@ typedef enum zfs_ioc { ZFS_IOC_SEND_NEW, ZFS_IOC_SEND_SPACE, ZFS_IOC_CLONE, + ZFS_IOC_NEXTBOOT, ZFS_IOC_LAST } zfs_ioc_t; -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 17:26:35 2014 Return-Path: Delivered-To: freebsd-current@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 AFAAD75A; Tue, 21 Jan 2014 17:26:35 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3FC6A13DA; Tue, 21 Jan 2014 17:26:35 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3D74BB9AB; Tue, 21 Jan 2014 12:26:34 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: [CFT] xboxfb with vt(9) (a.k.a. newcons) Date: Tue, 21 Jan 2014 11:43:55 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20140115144524.ede04bd0cb57ebc1dfad131a@freebsd.org> <4981005459307976130@gmail297201516> <20140116014736.29f9fe41.ray@freebsd.org> In-Reply-To: <20140116014736.29f9fe41.ray@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201401211143.55623.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 21 Jan 2014 12:26:34 -0500 (EST) Cc: Aleksandr Rybalko , Ed Schouten X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 17:26:35 -0000 On Wednesday, January 15, 2014 6:47:36 pm Aleksandr Rybalko wrote: > On Wed, 15 Jan 2014 23:35:39 +0000 > Ed Schouten wrote: > > > Hello there, > > > > On Wed Jan 15 2014 at 1:43:56 PM, Aleksandr Rybalko > > wrote: > > > > > I've just committed update to xboxfb driver for vt(9). But I have > > > no HW to test on. So if anybody have HW and time/wish to test it, > > > please help me. > > > > > > As I also mentioned to you privately, I think it might actually be > > wiser to just drop Xbox support entirely. The Xbox support was a > > funny thing back then, but I suspect it has actually outlived its > > usefulness. > > > > The original Xbox only has a 733 MHz Celeron CPU, 64 MB of RAM and a > > 10 GB harddisk. I don't think there are that many people left who > > want to run FreeBSD 11 on it. > > > > Thoughts? > > > > Ed > > Hi folks! > > Ed, Raspberry-Pi has more RAM, almost same CPU clock and no HDD at all > and people use it :) > > Since it already in HEAD I would prefer to left it here for some time. > So other will be able to use it as example. But even for that better to > know if it works, to not waste time of users or hackers who will try to > use it. :) If you don't find anyone who is able to test this, then you probably should remove it. If someone steps up to test it, then it can stay, but it is hard to keep code around that no one tests. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 17:26:40 2014 Return-Path: Delivered-To: freebsd-current@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 3E7D8935; Tue, 21 Jan 2014 17:26:39 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B18B813DE; Tue, 21 Jan 2014 17:26:39 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 97835B94C; Tue, 21 Jan 2014 12:26:38 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Regression on 10-RC5 with a multicast routing daemon Date: Tue, 21 Jan 2014 11:48:53 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20140115113430.GK26504@FreeBSD.org> In-Reply-To: <20140115113430.GK26504@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201401211148.53400.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 21 Jan 2014 12:26:38 -0500 (EST) Cc: Olivier =?iso-8859-1?q?Cochard-Labb=E9?= , "freebsd-net@freebsd.org" , Gleb Smirnoff , andre@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 17:26:40 -0000 On Wednesday, January 15, 2014 6:34:30 am Gleb Smirnoff wrote: > Damn, what a mess. I'd like to go towards absolutely unmodified packets > for the 11-release cycle. I agree. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 17:26:44 2014 Return-Path: Delivered-To: freebsd-current@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 06DB8A78; Tue, 21 Jan 2014 17:26:44 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D045613DF; Tue, 21 Jan 2014 17:26:43 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B1B36B945; Tue, 21 Jan 2014 12:26:42 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: freebsd-update Date: Tue, 21 Jan 2014 11:49:45 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <5F09668C-0DEA-4074-A06C-BC4D29F92368@FreeBSD.org> In-Reply-To: <5F09668C-0DEA-4074-A06C-BC4D29F92368@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201401211149.45793.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 21 Jan 2014 12:26:42 -0500 (EST) Cc: David Chisnall , Ivan Voras , Antonio Olivares X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 17:26:44 -0000 On Tuesday, January 21, 2014 10:46:37 am David Chisnall wrote: > > On 21 Jan 2014, at 07:13, Antonio Olivares wrote: > > > On Tue, Jan 21, 2014 at 7:49 AM, Ivan Voras wrote: > >> Hi, > >> > >> Is there any way I can avoid manually resolving hundreds of merge > >> conflicts of the following type while using freebsd-update ? > >> > >> 1 <<<<<<< current version > >> > >> > >> 2 # $FreeBSD: release/9.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z > >> peter $ > >> > >> 3 ======= > >> > >> > >> 4 # $FreeBSD: release/10.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z > >> peter $ > >> > >> 5 >>>>>>> 10.0-RELEASE > >> > >> > >> > >> ? > >> > >> I can't be the only one seeing those...? > >> > > > > Yes, One has to manually go one by one to fix these :( > > I tried at one point a sed command like sed -i "" '>>>>' to fix > > these, but it did not work correctly. I see errrors when booting when > > I don't correct these :( > > I thought this was fixed already (I didn't see these in the 9.2->10-RC3 upgrade). Doesn't freebsd-update pass -F (If the files differ only by VCS Id ($FreeBSD) install the new file) to mergemaster? AFAIK it doesn't use mergemaster? I thought it used its own tool? I really want to figure out a way to let it use etcupdate instead since it handles this case even for locally modified files cleanly. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 19:03:18 2014 Return-Path: Delivered-To: freebsd-current@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 C8BE3463; Tue, 21 Jan 2014 19:03:18 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9C6FB1E12; Tue, 21 Jan 2014 19:03:18 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9586DB977; Tue, 21 Jan 2014 14:03:17 -0500 (EST) From: John Baldwin To: Roger Pau Monne Subject: Re: [PATCH RFC 02/13] ioapic: introduce hooks for some ioapic ops Date: Tue, 21 Jan 2014 13:27:17 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <1387884062-41154-1-git-send-email-roger.pau@citrix.com> <1387884062-41154-3-git-send-email-roger.pau@citrix.com> In-Reply-To: <1387884062-41154-3-git-send-email-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201401211327.17258.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 21 Jan 2014 14:03:17 -0500 (EST) Cc: julien.grall@citrix.com, freebsd-xen@freebsd.org, freebsd-current@freebsd.org, kib@freebsd.org, xen-devel@lists.xenproject.org, gibbs@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 19:03:18 -0000 On Tuesday, December 24, 2013 6:20:51 am Roger Pau Monne wrote: > Create some hooks for IO APIC operations that will diverge from bare > metal when implemented for Xen Dom0. > > This patch should not introduce any changes in functionality, it's a > preparatory patch for the implementation of the Xen IO APIC hooks. I think this is fine. I should really create a sys/x86/include/apicvar.h as there is a lot shared between those two headers. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 19:03:17 2014 Return-Path: Delivered-To: freebsd-current@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 AACFC460; Tue, 21 Jan 2014 19:03:17 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F2F81E10; Tue, 21 Jan 2014 19:03:17 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 71FC2B94C; Tue, 21 Jan 2014 14:03:16 -0500 (EST) From: John Baldwin To: Roger Pau Monne Subject: Re: [PATCH RFC 01/13] xen: use the hardware e820 map on Dom0 Date: Tue, 21 Jan 2014 13:25:29 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <1387884062-41154-1-git-send-email-roger.pau@citrix.com> <1387884062-41154-2-git-send-email-roger.pau@citrix.com> In-Reply-To: <1387884062-41154-2-git-send-email-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201401211325.29460.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 21 Jan 2014 14:03:16 -0500 (EST) Cc: julien.grall@citrix.com, freebsd-xen@freebsd.org, freebsd-current@freebsd.org, kib@freebsd.org, xen-devel@lists.xenproject.org, gibbs@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 19:03:17 -0000 On Tuesday, December 24, 2013 6:20:50 am Roger Pau Monne wrote: > We need to do some tweaking of the hardware e820 map, since the memory > layout provided by Xen and the e820 map doesn't match. > > This consists in clamping the e820 map so that regions above max_pfn > are marked as unusuable. > --- > sys/x86/xen/pv.c | 35 +++++++++++++++++++++++++++++++++-- > 1 files changed, 33 insertions(+), 2 deletions(-) > > diff --git a/sys/x86/xen/pv.c b/sys/x86/xen/pv.c > index 4f7415e..ab4afba 100644 > --- a/sys/x86/xen/pv.c > +++ b/sys/x86/xen/pv.c > @@ -297,17 +297,48 @@ static void > xen_pv_parse_memmap(caddr_t kmdp, vm_paddr_t *physmap, int *physmap_idx) > { > struct xen_memory_map memmap; > + unsigned long max_pfn = HYPERVISOR_start_info->nr_pages; > + u_int64_t mem_end = ptoa(max_pfn); > u_int32_t size; > - int rc; > + int rc, mem_op, i; One minor nit is that it is preferred to not initalize variables in declarations style-wise. Aside from that, this looks fine to me. > /* Fetch the E820 map from Xen */ > memmap.nr_entries = MAX_E820_ENTRIES; > set_xen_guest_handle(memmap.buffer, xen_smap); > - rc = HYPERVISOR_memory_op(XENMEM_memory_map, &memmap); > + mem_op = xen_initial_domain() ? > + XENMEM_machine_memory_map : > + XENMEM_memory_map; > + rc = HYPERVISOR_memory_op(mem_op, &memmap); > if (rc) > panic("unable to fetch Xen E820 memory map"); > size = memmap.nr_entries * sizeof(xen_smap[0]); > > + /* > + * This should be improved, Xen provides us with a single > + * chunk of physical memory that goes from 0 to max_pfn, > + * and what we do here is clamp the HW memory map to make > + * sure regions above max_pfn are marked as reserved. > + * > + * TRTTD would be to move the memory not used because of > + * the holes in the HW memory map to the now clamped regions > + * using XENMEM_{decrease/increase}_reservation. > + */ > + for (i = 0; i < memmap.nr_entries; i++) { > + u_int64_t end = xen_smap[i].base + xen_smap[i].length; > + if (xen_smap[i].type == SMAP_TYPE_MEMORY) { > + if (xen_smap[i].base > mem_end) { > + /* Mark as reserved */ > + xen_smap[i].type = SMAP_TYPE_RESERVED; > + continue; > + } > + if (end > mem_end) { > + /* Truncate region */ > + xen_smap[i].length -= end - mem_end; > + } > + } > + } > + > + > bios_add_smap_entries(xen_smap, size, physmap, physmap_idx); > } > > -- > 1.7.7.5 (Apple Git-26) > > -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 19:03:21 2014 Return-Path: Delivered-To: freebsd-current@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 CBA09562; Tue, 21 Jan 2014 19:03:21 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A0E531E15; Tue, 21 Jan 2014 19:03:21 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5EBAEB946; Tue, 21 Jan 2014 14:03:20 -0500 (EST) From: John Baldwin To: Roger Pau Monne Subject: Re: [PATCH RFC 05/13] xen: implement Xen IO APIC ops Date: Tue, 21 Jan 2014 13:55:13 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <1387884062-41154-1-git-send-email-roger.pau@citrix.com> <1387884062-41154-6-git-send-email-roger.pau@citrix.com> In-Reply-To: <1387884062-41154-6-git-send-email-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201401211355.13800.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 21 Jan 2014 14:03:20 -0500 (EST) Cc: julien.grall@citrix.com, freebsd-xen@freebsd.org, freebsd-current@freebsd.org, kib@freebsd.org, xen-devel@lists.xenproject.org, gibbs@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 19:03:22 -0000 On Tuesday, December 24, 2013 6:20:54 am Roger Pau Monne wrote: > Implement a different set of hooks for IO APIC to use when running > under Xen Dom0. > --- > sys/x86/xen/pv.c | 44 ++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 44 insertions(+), 0 deletions(-) > > diff --git a/sys/x86/xen/pv.c b/sys/x86/xen/pv.c > index ab4afba..e5ad200 100644 > --- a/sys/x86/xen/pv.c > +++ b/sys/x86/xen/pv.c > @@ -49,6 +49,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > > +#include > #include > #include > #include > @@ -58,6 +59,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > > #include > > @@ -73,6 +75,11 @@ static caddr_t xen_pv_parse_preload_data(u_int64_t); > static void xen_pv_parse_memmap(caddr_t, vm_paddr_t *, int *); > > static void xen_pv_set_init_ops(void); > + > +static u_int xen_pv_ioapic_read(volatile ioapic_t *, int); > +static void xen_pv_ioapic_write(volatile ioapic_t *, int, u_int); > +static void xen_pv_ioapic_register_intr(struct ioapic_intsrc *); > + > /*---------------------------- Extern Declarations ---------------------------*/ > /* Variables used by amd64 mp_machdep to start APs */ > extern struct mtx ap_boot_mtx; > @@ -92,6 +99,13 @@ struct init_ops xen_init_ops = { > .parse_memmap = xen_pv_parse_memmap, > }; > > +/* Xen ioapic_ops implementation */ > +struct ioapic_ops xen_ioapic_ops = { > + .read = xen_pv_ioapic_read, > + .write = xen_pv_ioapic_write, > + .register_intr = xen_pv_ioapic_register_intr, > +}; > + > static struct > { > const char *ev; > @@ -342,6 +356,34 @@ xen_pv_parse_memmap(caddr_t kmdp, vm_paddr_t *physmap, int *physmap_idx) > bios_add_smap_entries(xen_smap, size, physmap, physmap_idx); > } > > +static u_int > +xen_pv_ioapic_read(volatile ioapic_t *apic, int reg) > +{ > + struct physdev_apic apic_op; > + int rc; > + > + mtx_assert(&icu_lock, MA_OWNED); > + > + apic_op.apic_physbase = pmap_kextract((vm_offset_t) apic); Seems a shame to have to do this. I wouldn't mind if you changed the read/write callbacks to take 'struct ioapic *' instead and then use the 'io_paddr' member. I do think that would be cleaner. > + apic_op.reg = reg; > + rc = HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op); > + if (rc) > + panic("apic_read operation failed"); > + > + return (apic_op.value); > +} > + > +static void > +xen_pv_ioapic_write(volatile ioapic_t *apic, int reg, u_int val) > +{ > +} I guess not allowing writes is on purpose? > + > +static void > +xen_pv_ioapic_register_intr(struct ioapic_intsrc *pin) > +{ > + xen_register_pirq(pin->io_irq, pin->io_activehi, pin->io_edgetrigger); > +} > + > static void > xen_pv_set_init_ops(void) > { > @@ -349,4 +391,6 @@ xen_pv_set_init_ops(void) > init_ops = xen_init_ops; > /* Disable lapic */ > lapic_disabled = true; > + /* IOAPIC ops for Xen PV */ > + ioapic_ops = xen_ioapic_ops; > } > -- > 1.7.7.5 (Apple Git-26) > > -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 19:03:20 2014 Return-Path: Delivered-To: freebsd-current@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 761D1486; Tue, 21 Jan 2014 19:03:20 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4A7FF1E13; Tue, 21 Jan 2014 19:03:20 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B3974B945; Tue, 21 Jan 2014 14:03:18 -0500 (EST) From: John Baldwin To: Roger Pau Monne Subject: Re: [PATCH RFC 04/13] xen: implement basic PIRQ support for Dom0 Date: Tue, 21 Jan 2014 13:52:44 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <1387884062-41154-1-git-send-email-roger.pau@citrix.com> <1387884062-41154-5-git-send-email-roger.pau@citrix.com> In-Reply-To: <1387884062-41154-5-git-send-email-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201401211352.44784.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 21 Jan 2014 14:03:19 -0500 (EST) Cc: julien.grall@citrix.com, freebsd-xen@freebsd.org, freebsd-current@freebsd.org, kib@freebsd.org, xen-devel@lists.xenproject.org, gibbs@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 19:03:20 -0000 On Tuesday, December 24, 2013 6:20:53 am Roger Pau Monne wrote: > This allows Dom0 to manage physical hardware, redirecting the > physical interrupts to event channels. > --- > sys/x86/xen/xen_intr.c | 190 +++++++++++++++++++++++++++++++++++++++++++++-- > sys/xen/xen_intr.h | 11 +++ > 2 files changed, 192 insertions(+), 9 deletions(-) > > diff --git a/sys/x86/xen/xen_intr.c b/sys/x86/xen/xen_intr.c > index bc0781e..340e5ed 100644 > --- a/sys/x86/xen/xen_intr.c > +++ b/sys/x86/xen/xen_intr.c > @@ -104,6 +104,8 @@ DPCPU_DECLARE(struct vcpu_info *, vcpu_info); > > #define is_valid_evtchn(x) ((x) != 0) > > +#define EEXIST 17 /* Xen "already exists" error */ Is there a xen_errno.h header? Might be nice to have one and give these constants unique names (e.g. XEN_EEXIST or some such) to avoid confusion/conflicts with . Other than that I think this looks fine. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 19:03:22 2014 Return-Path: Delivered-To: freebsd-current@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 DD6A96AA; Tue, 21 Jan 2014 19:03:22 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B450E1E16; Tue, 21 Jan 2014 19:03:22 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B55EEB99A; Tue, 21 Jan 2014 14:03:21 -0500 (EST) From: John Baldwin To: Roger Pau Monne Subject: Re: [PATCH RFC 06/13] xen: Dom0 console fixes Date: Tue, 21 Jan 2014 14:02:58 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <1387884062-41154-1-git-send-email-roger.pau@citrix.com> <1387884062-41154-7-git-send-email-roger.pau@citrix.com> In-Reply-To: <1387884062-41154-7-git-send-email-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201401211402.58721.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 21 Jan 2014 14:03:21 -0500 (EST) Cc: julien.grall@citrix.com, freebsd-xen@freebsd.org, freebsd-current@freebsd.org, kib@freebsd.org, xen-devel@lists.xenproject.org, gibbs@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 19:03:22 -0000 On Tuesday, December 24, 2013 6:20:55 am Roger Pau Monne wrote: > Minor fixes and workarounds to make the Xen Dom0 console work. Looks ok to me. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 19:37:03 2014 Return-Path: Delivered-To: freebsd-current@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 DEC0B871; Tue, 21 Jan 2014 19:37:02 +0000 (UTC) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 90FFC111C; Tue, 21 Jan 2014 19:37:02 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id i7so7502215oag.1 for ; Tue, 21 Jan 2014 11:37:01 -0800 (PST) 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=1H6iy0e9onYmiSLMPRZbWr/TSwNiuZ221pXbcWdjUTA=; b=cdYWdSAqpyyrwbuBsAno8sMy6OYxkwgTNx7DzlIKwUHkV0eRBhhTeBhCxYoH5lYfzy 2vktXQdjz/KvXV9n7T7X4zckuhfmiF9tg8PH7Pow4E+xkT3JXVHdb+FASXp32WKqWlQo oxCSCAMUOY8LiukAaUuL447L04fdCQBCNld273LClKa+GnltCqDZ98hcb2EM2JVIHSxQ T7yhzHeq/FIDAYcBlhN/Z3cfwpxfYxqrcgj0NlJK8JAQEypJAPBgGZgAUv6pz2yF31bb xMZ5hyZQRU8yjDGQ1eJDkfpUPY7uB+u6uF0VZByKho6+UVeQMXC82D6ZZgtPBpFoiPQM oHYw== MIME-Version: 1.0 X-Received: by 10.182.135.165 with SMTP id pt5mr2921109obb.66.1390333021709; Tue, 21 Jan 2014 11:37:01 -0800 (PST) Received: by 10.76.3.11 with HTTP; Tue, 21 Jan 2014 11:37:01 -0800 (PST) In-Reply-To: References: <5256B761.4050301@gmail.com> <1381421583.19140.32451849.084D8E32@webmail.messagingengine.com> <5256E2D5.4060101@allanjude.com> <1387388390.28188.61199633.413D38F8@webmail.messagingengine.com> Date: Tue, 21 Jan 2014 14:37:01 -0500 Message-ID: Subject: Re: FreeBSD 10 and zfsd From: Outback Dingo To: asomers@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 19:37:03 -0000 On Thu, Dec 19, 2013 at 6:32 PM, wrote: > On Wed, Dec 18, 2013 at 2:40 PM, Outback Dingo > wrote: > > > > > > > > On Wed, Dec 18, 2013 at 4:40 PM, Alan Somers > wrote: > >> > >> On Wed, Dec 18, 2013 at 11:47 AM, Outback Dingo > > >> wrote: > >> > > >> > > >> > On Wed, Dec 18, 2013 at 12:39 PM, Mark Felder > wrote: > >> >> > >> >> On Thu, Oct 10, 2013, at 11:26, Alan Somers wrote: > >> >> > > >> >> > Due to popular demand, I have located a round toit. I'm currently > >> >> > working on rebasing the zfsd project branch to head, after which > I'll > >> >> > push SpectraLogic's recent changes. > >> >> > > >> >> > >> >> Just thought I'd ping the list about the situation here... would love > >> >> to > >> >> see this in HEAD soon :) > >> > > >> > > >> > > >> > Id love to see an updated patch from the zfsd tree against head itself > >> > so we > >> > could continue using and testing it > >> > >> Coming up ... > >> > > > > Sweeeeeeeeeet..........!!! > > Sorry, but I'm running into nontrivial merge conflicts. It's going to > take a few more days. > > -Alan > > Has any progress been made on an updated patch set ?? > > > > > >> > >> > > >> >> > >> >> _______________________________________________ > >> >> freebsd-current@freebsd.org mailing list > >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> >> To unsubscribe, send any mail to > >> >> "freebsd-current-unsubscribe@freebsd.org" > >> > > >> > > > > > > From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 19:40:21 2014 Return-Path: Delivered-To: freebsd-current@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 A03B5A8C; Tue, 21 Jan 2014 19:40:21 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0E73E1152; Tue, 21 Jan 2014 19:40:20 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id d13so4849086wiw.6 for ; Tue, 21 Jan 2014 11:40:19 -0800 (PST) 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=jfpvT6DcjRUvsoKE5o+/si57W1Q6tF/RLf4ZE2eReJo=; b=pG/BR7/ilvhXSe3iJtG5HowXX9YPzm/BDyXsd1k6kw81aqEXF89vXrR5fvdgJMR3ep C+PXv0chTgFfrZBxZAtIGB7pNR6lN6WmvQ40FuYAnoUeejvyVds4sldTVm7ZTkxFtLnn aw5iCtTKPC8ByzZYZf7RZnQOMAQO+fZ0QGfnUn+tm9yQ4BwITPIQH2TWL5n0ypijjUv6 myp82lAok0MtWZ23JruISP8lFlWbR3Bbu1jeEXNCln9cD9w1Ws6CBG2wf9eWziuv4mnc AFAxU0wJuo8wE1TlILuUcRiE8mwco9VeEGQ9IRwQ2L0OeJ1X4LHCpe+ejEVLf+ScR5U8 jxeQ== MIME-Version: 1.0 X-Received: by 10.180.221.38 with SMTP id qb6mr15963937wic.26.1390333219411; Tue, 21 Jan 2014 11:40:19 -0800 (PST) Sender: asomers@gmail.com Received: by 10.194.22.35 with HTTP; Tue, 21 Jan 2014 11:40:19 -0800 (PST) In-Reply-To: References: <5256B761.4050301@gmail.com> <1381421583.19140.32451849.084D8E32@webmail.messagingengine.com> <5256E2D5.4060101@allanjude.com> <1387388390.28188.61199633.413D38F8@webmail.messagingengine.com> Date: Tue, 21 Jan 2014 12:40:19 -0700 X-Google-Sender-Auth: pCKTvYui2rE0uCp9TCcKn0BzXtw Message-ID: Subject: Re: FreeBSD 10 and zfsd From: Alan Somers To: Outback Dingo Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 19:40:21 -0000 On Tue, Jan 21, 2014 at 12:37 PM, Outback Dingo wrote: > > > > On Thu, Dec 19, 2013 at 6:32 PM, wrote: >> >> On Wed, Dec 18, 2013 at 2:40 PM, Outback Dingo >> wrote: >> > >> > >> > >> > On Wed, Dec 18, 2013 at 4:40 PM, Alan Somers >> > wrote: >> >> >> >> On Wed, Dec 18, 2013 at 11:47 AM, Outback Dingo >> >> >> >> wrote: >> >> > >> >> > >> >> > On Wed, Dec 18, 2013 at 12:39 PM, Mark Felder >> >> > wrote: >> >> >> >> >> >> On Thu, Oct 10, 2013, at 11:26, Alan Somers wrote: >> >> >> > >> >> >> > Due to popular demand, I have located a round toit. I'm currently >> >> >> > working on rebasing the zfsd project branch to head, after which >> >> >> > I'll >> >> >> > push SpectraLogic's recent changes. >> >> >> > >> >> >> >> >> >> Just thought I'd ping the list about the situation here... would >> >> >> love >> >> >> to >> >> >> see this in HEAD soon :) >> >> > >> >> > >> >> > >> >> > Id love to see an updated patch from the zfsd tree against head >> >> > itself >> >> > so we >> >> > could continue using and testing it >> >> >> >> Coming up ... >> >> >> > >> > Sweeeeeeeeeet..........!!! >> >> Sorry, but I'm running into nontrivial merge conflicts. It's going to >> take a few more days. >> >> -Alan >> > > > Has any progress been made on an updated patch set ?? Yes, but not any visible progress. I had to make some changes to devd and libdevctl, and I'm currently blocked by this bug. I have a tentative solution for it, and I hope to start a discussion on freebsd-net about it today or tomorrow. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/185813 -Alan > > >> >> > >> > >> >> >> >> > >> >> >> >> >> >> _______________________________________________ >> >> >> freebsd-current@freebsd.org mailing list >> >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> >> To unsubscribe, send any mail to >> >> >> "freebsd-current-unsubscribe@freebsd.org" >> >> > >> >> > >> > >> > > > From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 20:42:52 2014 Return-Path: Delivered-To: freebsd-current@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 D2BBF956; Tue, 21 Jan 2014 20:42:52 +0000 (UTC) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9408F170E; Tue, 21 Jan 2014 20:42:52 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id q10so6632300pdj.38 for ; Tue, 21 Jan 2014 12:42:52 -0800 (PST) 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=McGzKm7kasb8146n8jt6imrU6KaLeay6izOXS1s/3os=; b=wVnWg1o0qq4TTQ1keOpW65Oq8tZ+PuhKNwdDMcU3JO3iouTHRyWK+6nF4T7nyoexhu w0ZuxklndNa5IiZkBdxhUX65dwx/uIu3uqmToSL8tQkOKjf6lGOsWOX3YGAAJR+GEfYE /RXLCS+U2m2rAuYADMnbA0ZaUPeRboCLDY9AG4R0mF6PRac1RgfaVewWiBssT/Kjh608 Hyi4Ag+1OaJL5Blt0douOlizq8PCTTTtDmXFB1lrPz2VgUs2jQ72hx8MlG42X3AqfVPC 7YM6F0pZ08dN6B6jCr7PBmsqJfFL7nZRLosw3oPtshW/hGLeokQbRJSqZT4A8qmW1Q98 064g== MIME-Version: 1.0 X-Received: by 10.69.31.97 with SMTP id kl1mr27331206pbd.62.1390336972247; Tue, 21 Jan 2014 12:42:52 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.67.30.1 with HTTP; Tue, 21 Jan 2014 12:42:52 -0800 (PST) In-Reply-To: <201401211149.45793.jhb@freebsd.org> References: <5F09668C-0DEA-4074-A06C-BC4D29F92368@FreeBSD.org> <201401211149.45793.jhb@freebsd.org> Date: Tue, 21 Jan 2014 12:42:52 -0800 X-Google-Sender-Auth: XLFo3wo7nrJ9w3aQxpr9ysmPoL0 Message-ID: Subject: Re: freebsd-update From: Kevin Oberman To: John Baldwin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Current , David Chisnall , Ivan Voras , Antonio Olivares X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 20:42:53 -0000 On Tue, Jan 21, 2014 at 8:49 AM, John Baldwin wrote: > On Tuesday, January 21, 2014 10:46:37 am David Chisnall wrote: > > > > On 21 Jan 2014, at 07:13, Antonio Olivares > wrote: > > > > > On Tue, Jan 21, 2014 at 7:49 AM, Ivan Voras > wrote: > > >> Hi, > > >> > > >> Is there any way I can avoid manually resolving hundreds of merge > > >> conflicts of the following type while using freebsd-update ? > > >> > > >> 1 <<<<<<< current version > > >> > > >> > > >> 2 # $FreeBSD: release/9.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z > > >> peter $ > > >> > > >> 3 ======= > > >> > > >> > > >> 4 # $FreeBSD: release/10.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z > > >> peter $ > > >> > > >> 5 >>>>>>> 10.0-RELEASE > > >> > > >> > > >> > > >> ? > > >> > > >> I can't be the only one seeing those...? > > >> > > > > > > Yes, One has to manually go one by one to fix these :( > > > I tried at one point a sed command like sed -i "" '>>>>' to fix > > > these, but it did not work correctly. I see errrors when booting when > > > I don't correct these :( > > > > I thought this was fixed already (I didn't see these in the 9.2->10-RC3 > upgrade). Doesn't freebsd-update pass -F (If the files differ only by VCS > Id > ($FreeBSD) install the new file) to mergemaster? > > AFAIK it doesn't use mergemaster? I thought it used its own tool? I > really > want to figure out a way to let it use etcupdate instead since it handles > this case even for locally modified files cleanly. > Having just gone through this on a 10.0-rc5 to 10.0-RELEASE run, I can assure you that it is not completely fixed. One huge part is fixed... every file's ID line is no longer is changed on every release. OTOH, for files that are modified, thy still show up. It hit many of the sendmail .cf files. Annoying as I don't even use sendmail. Not sure if there was a good reason Colin re-invented the wheel on this. It does not use mergemaster or even a reasonable differences editor such as the one mergemaster uses. Just going to the mergemaster code for handling diffs would be a HUGE win. I am getting really tired of "/<<<<3ddddn". -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Tue Jan 21 21:11:24 2014 Return-Path: Delivered-To: freebsd-current@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 F1AB14BF; Tue, 21 Jan 2014 21:11:23 +0000 (UTC) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9863C1931; Tue, 21 Jan 2014 21:11:23 +0000 (UTC) Received: by mail-vc0-f173.google.com with SMTP id ld13so3798045vcb.4 for ; Tue, 21 Jan 2014 13:11:22 -0800 (PST) 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=Z09szqQWJEUUUQajQBmGdw4cQDl9yOoRbMmNRnCYlw0=; b=EoqPWy09HOAwaeFXvKg4gqIcIMyTQTf18Lz9P3C/XeopdslVz2Diy8xicX5Rzl5aFA C6WNbTYnd7yh638SKhkrXn4PrWcNGOcy/PJ2reGqaDkEsm3jyMdzfPWihSU9kjjRayNU rKYD93Xi+g0kx6E1zWPfqzrMIfnOe4tg4w10MCPwgKefpj/CfVDkt6aEtwSNrmddzkV7 wecCNrFPNZk5afeGHprkHhrzl4k9v4ERVr/m5sBb1QZJPfxaW4rUaEUL7e1MJ0H11Gnu gmcvEln+b4TzljsPV0hgp9kKaxfRJ4UbuUzemlOVmhtwIP+ov/7dLu9/QsGKbGu9JyHG 5fHQ== MIME-Version: 1.0 X-Received: by 10.58.255.233 with SMTP id at9mr7004460ved.20.1390338682595; Tue, 21 Jan 2014 13:11:22 -0800 (PST) Received: by 10.220.168.135 with HTTP; Tue, 21 Jan 2014 13:11:22 -0800 (PST) In-Reply-To: <52DE9699.5040801@FreeBSD.org> References: <52DE3F6B.6050209@yandex.ru> <52DE4FD0.5030409@FreeBSD.org> <52DE5781.7090600@yandex.ru> <52DE9699.5040801@FreeBSD.org> Date: Tue, 21 Jan 2014 16:11:22 -0500 Message-ID: Subject: Re: Problem updating bootcode on ZFS on root system with MBR From: Thomas Hoffmann To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "Andrey V. Elsukov" , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 21:11:24 -0000 On Tue, Jan 21, 2014 at 10:47 AM, Andriy Gapon wrote: > on 21/01/2014 13:18 Andrey V. Elsukov said the following: > > On 21.01.2014 14:45, Andriy Gapon wrote: > >>>> What do I need to do to get the boot2 code written to /dev/ada0s1a? > >>> > >>> This will work only if ada0s1a isn't in use. The debugflags trick works > >>> only for whole disk, i.e. for geoms with rank=1. Another way is > >>> calculate needed offset and write bootcode directly to ada0. > >> > >> > >> And ultimately we should extend our ZFS interface with an ioctl to > write a blob > >> to a boot code area of a specified ZFS leaf vdev. This would the right > way to > >> install zfsboot. > > > > Hi Andriy, > > > > do you have some patches to test? :-) > > > > I don't, but the following patch can serve as a very good example. > It adds an ioctl that serves a slightly different but quite similar > purpose: > > commit 54802d6659ec134fd221c3daaa8fdf9cee985d39 > Author: Andriy Gapon > Date: Fri Sep 14 23:15:43 2012 +0300 > > [wip] zfs: add a new ioctl that allows to place text data into pad2 > area > > The data is placed into Pad2 area of the first vdev label of a given > vdev in a given pool. > > diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h > b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h > index fb30ea9..4a46cc2 100644 > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h > @@ -162,6 +162,8 @@ typedef enum { > > extern int vdev_label_init(vdev_t *vd, uint64_t txg, vdev_labeltype_t > reason); > > +extern int vdev_label_write_pad2(vdev_t *vd, const char *buf, size_t > size); > + > #ifdef __cplusplus > } > #endif > diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c > b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c > index c7dd3ad..55c87d8 100644 > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c > @@ -855,6 +855,44 @@ retry: > return (error); > } > > +int > +vdev_label_write_pad2(vdev_t *vd, const char *buf, size_t size) > +{ > + spa_t *spa = vd->vdev_spa; > + zio_t *zio; > + char *pad2; > + int flags = ZIO_FLAG_CONFIG_WRITER | ZIO_FLAG_CANFAIL; > + int error; > + > + if (size > VDEV_PAD_SIZE) > + return (EINVAL); > + > + if (!vd->vdev_ops->vdev_op_leaf) > + return (ENODEV); > + if (vdev_is_dead(vd)) > + return (ENXIO); > + > + ASSERT(spa_config_held(spa, SCL_ALL, RW_WRITER) == SCL_ALL); > + > + pad2 = zio_buf_alloc(VDEV_PAD_SIZE); > + bzero(pad2, VDEV_PAD_SIZE); > + memcpy(pad2, buf, size); > + > +retry: > + zio = zio_root(spa, NULL, NULL, flags); > + vdev_label_write(zio, vd, 0, pad2, > + offsetof(vdev_label_t, vl_pad2), > + VDEV_PAD_SIZE, NULL, NULL, flags); > + error = zio_wait(zio); > + if (error != 0 && !(flags & ZIO_FLAG_TRYHARD)) { > + flags |= ZIO_FLAG_TRYHARD; > + goto retry; > + } > + > + zio_buf_free(pad2, VDEV_PAD_SIZE); > + return (error); > +} > + > /* > * > ========================================================================== > * uberblock load/sync > diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c > b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c > index e208ed8..ff90839 100644 > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c > @@ -3404,6 +3404,53 @@ zfs_ioc_log_history(const char *unused, nvlist_t > *innvl, > nvlist_t *outnvl) > return (error); > } > > +#ifdef __FreeBSD__ > +static int > +zfs_ioc_nextboot(const char *unused, nvlist_t *innvl, nvlist_t *outnvl) > +{ > + char name[MAXNAMELEN]; > + spa_t *spa; > + vdev_t *vd; > + char *command; > + uint64_t pool_guid; > + uint64_t vdev_guid; > + int error; > + > + if (nvlist_lookup_uint64(innvl, > + ZPOOL_CONFIG_POOL_GUID, &pool_guid) != 0) > + return (EINVAL); > + if (nvlist_lookup_uint64(innvl, > + ZPOOL_CONFIG_GUID, &vdev_guid) != 0) > + return (EINVAL); > + if (nvlist_lookup_string(innvl, > + "command", &command) != 0) > + return (EINVAL); > + > + mutex_enter(&spa_namespace_lock); > + spa = spa_by_guid(pool_guid, vdev_guid); > + if (spa != NULL) > + strcpy(name, spa_name(spa)); > + mutex_exit(&spa_namespace_lock); > + if (spa == NULL) > + return (ENOENT); > + > + if ((error = spa_open(name, &spa, FTAG)) != 0) > + return (error); > + spa_vdev_state_enter(spa, SCL_ALL); > + vd = spa_lookup_by_guid(spa, vdev_guid, B_TRUE); > + if (vd == NULL) { > + (void) spa_vdev_state_exit(spa, NULL, ENXIO); > + spa_close(spa, FTAG); > + return (ENODEV); > + } > + error = vdev_label_write_pad2(vd, command, strlen(command)); > + (void) spa_vdev_state_exit(spa, NULL, 0); > + txg_wait_synced(spa->spa_dsl_pool, 0); > + spa_close(spa, FTAG); > + return (error); > +} > +#endif > + > /* > * The dp_config_rwlock must not be held when calling this, because the > * unmount may need to write out data. > @@ -5605,6 +5652,9 @@ zfs_ioctl_init(void) > zfs_secpolicy_config, POOL_CHECK_NONE); > zfs_ioctl_register_dataset_nolog(ZFS_IOC_UNJAIL, zfs_ioc_unjail, > zfs_secpolicy_config, POOL_CHECK_NONE); > + zfs_ioctl_register("fbsd_nextboot", ZFS_IOC_NEXTBOOT, > + zfs_ioc_nextboot, zfs_secpolicy_config, NO_NAME, > + POOL_CHECK_NONE, B_FALSE, B_FALSE); > #endif > } > > diff --git a/sys/cddl/contrib/opensolaris/uts/common/sys/fs/zfs.h > b/sys/cddl/contrib/opensolaris/uts/common/sys/fs/zfs.h > index 454c28a..917223dc 100644 > --- a/sys/cddl/contrib/opensolaris/uts/common/sys/fs/zfs.h > +++ b/sys/cddl/contrib/opensolaris/uts/common/sys/fs/zfs.h > @@ -839,6 +839,7 @@ typedef enum zfs_ioc { > ZFS_IOC_SEND_NEW, > ZFS_IOC_SEND_SPACE, > ZFS_IOC_CLONE, > + ZFS_IOC_NEXTBOOT, > ZFS_IOC_LAST > } zfs_ioc_t; > > > -- > Andriy Gapon > Thanks for the responses. My apologies for going silent, but I had to step away from the problem for a bit. I was able to resolve my problem by doing the following: After upgrading my zpools and after my aborted attempt to update the bootcode as reported above, I copied /boot/zfsboot (or more precisely /bootpool/boot/zfsboot) to a USB thumb drive. I attempted to reboot my system, which failed due to unsupported zfs features. This was expected, but I thought, hey, I might get lucky. I then booted into a Live CD, mounted my USB thumb drive on /tmp/usb and executed: sysctl kern.geom.debugflags=0x10 dd if=/tmp/usb/zfsboot of=/dev/ada0s1 count=1 dd if=/tmp/usb/zfsboot of=/dev/ada0s1d skip=1 seek=1024 Then I rebooted and all is well. All zpools support all features. While this procedure was not tedious, it would still be nice if, as Andriy stated, FreeBSD contained a native way do this zfs bootcode update for MBR schemes that is as simple as for the GPT schemes. Its been a gazillion years since I've done any C programming, but I'll take a look at the patches. Thanks, Andriy and Andrey. - Tom From owner-freebsd-current@FreeBSD.ORG Wed Jan 22 02:25:30 2014 Return-Path: Delivered-To: current@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 709A18AD for ; Wed, 22 Jan 2014 02:25:30 +0000 (UTC) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D86E711C0 for ; Wed, 22 Jan 2014 02:25:29 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id n15so6639610lbi.11 for ; Tue, 21 Jan 2014 18:25:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=hEiJo1Uw6tut8Xcx9mA8dd3O12DeXRWTc1AwJnszpBo=; b=XkSRDCnbvWONfjko/os401rvk6zpeqynJMWZFvL/mZTC9PDpKdLXNmxDSnzenPWVv5 kIAw8nMZI/ufY4JSrl+XXiKsLFZchsPXaYu+vQ+1OEW4e7X1AQLFN/Nx9yIBNpmfdNbb n4UGsiaddT9ru0lH95SXOi4M0DV7HG07ufv+GXCga7Yz2LWIq0M4xPOkFOayuAfBoZcf +Hui+f49GbAv1FbVRrh3Da8ZMpOvqx3/nlKd8IgiA5HZ/CWlO66STNh+k/Gjz7fFVXpJ TYccpjSiOVInoyx8KmlDCb9rtxDGoe19Q4RLVkpSF3V/QchdN6jqtAi5lYhx6pPDUkoC 6FoA== MIME-Version: 1.0 X-Received: by 10.112.132.102 with SMTP id ot6mr866867lbb.27.1390357527798; Tue, 21 Jan 2014 18:25:27 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.115.4.162 with HTTP; Tue, 21 Jan 2014 18:25:27 -0800 (PST) Date: Tue, 21 Jan 2014 18:25:27 -0800 X-Google-Sender-Auth: 7UNAsOiO2obiisLJRRgfyKi48WQ Message-ID: Subject: possible selrecord optimization ? From: Luigi Rizzo To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 02:25:30 -0000 Looking at how selrecord() / selwakeup() and their Linux counterparts poll_wait() and wake_up() are used, i noticed the following: - linux tends to call wake_up() unconditionally at the beginning of the poll handler - FreeBSD tends to call selrecord() only when it detects a blocking situation, and this also requires something (a lock or a retry; the lock in selinfo is not good for this) to avoid the race between the blocking_test..selrecord pair and the selwakeup(). FreeBSD could call selrecord unconditionally (and save the extra lock/retry), but selrecord is expensive as it queues the thread on the struct selinfo, and this takes a lock. I wonder if we could use the same optimization as Linux: as soon as pollscan/selscan detects a non-blocking fd, make selrecord a no-op (which is probably as simple as setting SELTD_RESCAN; and since it only goes up we do not need to lock to check it). This way, we would pay at most for one extra selrecord per poll/select. Even more interesting, it could simplify the logic and locking in poll handlers. As an example, in sys/uipc_socket.c :: sopoll_generic() we could completely decouple the locks on so_snd and so_rcv. comments ? Note that it is only an optimization, so we could write poll handlers in the selrecord-then-test style even without it. cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Jan 22 08:31:35 2014 Return-Path: Delivered-To: freebsd-current@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 F2918E43; Wed, 22 Jan 2014 08:31:34 +0000 (UTC) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 72C841E61; Wed, 22 Jan 2014 08:31:34 +0000 (UTC) Received: by mail-ve0-f171.google.com with SMTP id pa12so40993veb.16 for ; Wed, 22 Jan 2014 00:31:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=hF981SH8BOmn81Wa6JBUy//NpZ/kX1amiX/HoLf1WdY=; b=ZFIZYKdq8FpFP95W1kAbZOGs+LWRnrT4ZDk1pNUM2QSOSBtbcfO3uwXM1VUvhZaGss 3Mt7ICdMkqfm0VP22oZSq3cGST11jV6g7VFFi8n380c0dk416adHjOz6+HD9PteCy+Pc rs1N9DKvn2Ysy42vy95gyKsXqL87fpD7daY+AptAMmAvXKn5eoUT5gVyxdEUV64qlPmm D+dkAZmj6INRKE4b6QCGtPquyd3ffuZ4VSuhext88Ff1z32Sn6Mjr7fYdF1la5u6X9Yi 8zXLNDqdq2hEWHi5/hFsKuu8+GO2MvR88Kfajg+cjKXfBxYPvlc3RoXUFtjmuopOFLkj UEEA== X-Received: by 10.58.90.202 with SMTP id by10mr109539veb.6.1390379493530; Wed, 22 Jan 2014 00:31:33 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.171.1 with HTTP; Wed, 22 Jan 2014 00:31:13 -0800 (PST) In-Reply-To: <20140121133359.GB66160@glebius.int.ru> References: <20140115113430.GK26504@FreeBSD.org> <20140121133359.GB66160@glebius.int.ru> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Wed, 22 Jan 2014 09:31:13 +0100 X-Google-Sender-Auth: rR4OZUMGUahuzXByUyzVbNZoN-E Message-ID: Subject: Re: Regression on 10-RC5 with a multicast routing daemon To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" , Andre Oppermann X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 08:31:35 -0000 On Tue, Jan 21, 2014 at 2:33 PM, Gleb Smirnoff wrote: > On Sun, Jan 19, 2014 at 02:42:32AM +0100, Olivier Cochard-Labb=E9 wrote: > O> But there is still a regression regarding the PIM socket behavior not > O> related to the packet format. > > Can you please try this patch to kernel? > > Lot's better with your patch: This fix the problem with PIM messages. Thanks ! From owner-freebsd-current@FreeBSD.ORG Wed Jan 22 10:31:57 2014 Return-Path: Delivered-To: freebsd-current@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 D5ACDDB3 for ; Wed, 22 Jan 2014 10:31:57 +0000 (UTC) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 928F218A0 for ; Wed, 22 Jan 2014 10:31:57 +0000 (UTC) Received: by mail-vb0-f50.google.com with SMTP id w8so104967vbj.9 for ; Wed, 22 Jan 2014 02:31:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=RAENw4xb/edGCwDInbMeB1wCoWIjVZl3ZZrEpeArxto=; b=mJ+oew0BR8XOH5rx46ceZbjtux9erEwQzmoJCpPQALWmnUwj+h8qu7y92wQyCws53x /NY7CzmBipF4SdK79C5LMgUoQbHJciwr9FwNRht1BOpEnESmzVak/+lNnuoxKJ/U4F+6 ceaZ+LcSeluIv8hoH+sl3rF6YNRQf6baj+1e35VbdzvuiH7cYO/hgjK3lhLZmbydGUBQ l8/+aioJFyAeub/xqjdIw+FYWtTkiJSHFHujZljEmf8sKHisCZyjIWXwcaVWc4Llzkzb RmkhFyVep3gMwCU5KW6GEOZgvyJhoeq55m14yMAbQ8DS7bNBz/I6z6BTF/0Ozltslw2G 4htw== X-Received: by 10.220.193.70 with SMTP id dt6mr334149vcb.17.1390386716346; Wed, 22 Jan 2014 02:31:56 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.171.1 with HTTP; Wed, 22 Jan 2014 02:31:36 -0800 (PST) From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Wed, 22 Jan 2014 11:31:36 +0100 X-Google-Sender-Auth: PTE7g6MnNqJyWET-OM1ghxcl7CU Message-ID: Subject: Bad support of Kingston DataTraveler/DT USB key since 9.2 (not fixed in 10.0) To: "freebsd-current@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 10:31:57 -0000 Hi all, There is a regression since 9.2 (still not fixed on 10.0) regarding a list of Kingston DataTraveler/DT USB keys - usb/180837, regarding "Kingston DT 101 G2": This PR include a patch for 9.2 and a link to netbsd code that include other Kingston USB keys; - usb/184014, regarding "Kingston DT 100 G2" (include tips for debugging) - usb/185747, regarding "Kingston DT 101 G2" (duplicate PR with usb/180837), that include a patch for 10.0; - misc/185837, regarding "Kingston DataTraveler 2.0". Can someone check with the netbsd code for the full list of known buggy Kingston USB key and commit these quirks patches ? Thanks, From owner-freebsd-current@FreeBSD.ORG Wed Jan 22 10:37:40 2014 Return-Path: Delivered-To: current@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 38413377 for ; Wed, 22 Jan 2014 10:37:40 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id EDFD71911 for ; Wed, 22 Jan 2014 10:37:39 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:c031:70cd:3c9f:30e4]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id B2E2C4AC2D for ; Wed, 22 Jan 2014 14:37:36 +0400 (MSK) Date: Wed, 22 Jan 2014 14:37:32 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1172931021.20140122143732@serebryakov.spb.ru> To: FreeBSD Current Subject: FreeBSD -CURREEN/x64 as guest in VirtualBox 4.3 -- freezes HOST system under load (VirtualBox 4.2 is Ok) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 10:37:40 -0000 Hello, FreeBSD. After upgrading VirtualBox (Windows host) to 4.3.x, FreeBSD guest starts to spent a lot of time in swi4:clock: PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root -60 - 0K 176K WAIT 0 29:13 18.99% intr{swi4: clock} Also, host becomes almost unusable, as half of keyboard presses are missed and other are multiplied and mouse is chaotic. It looks to be connected to complex/mixed workload (like "make -j4 buildworld buildkernel") as pure-CPU load (like xz-ipping /dev/zero to /dev/null) and pure-I/O load (like dd'ing from /dev/zero to virtual disk) doesn't cause this behavior. FreeBSD (exactly same VM configuration) doesn't have this problem on VirtualBox 4.2.x. VM is 2 CPU (out of 4 physical), 4Gb of RAM (out of 8 physical) ICH9, I/O APIC, virtual SATA controller (AHCI mode) with 3 virtual disks, that's all. Timers in system: kern.eventtimer.et.LAPIC.flags: 15 kern.eventtimer.et.LAPIC.frequency: 500014822 kern.eventtimer.et.LAPIC.quality: 400 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.choice: LAPIC(400) i8254(100) RTC(0) kern.eventtimer.singlemul: 4 kern.eventtimer.idletick: 0 kern.eventtimer.timer: LAPIC kern.eventtimer.periodic: 0 I think, it is new VBox version problem, but I want to be sure before reporting it to Oracle's bugtracking, as FreeBSD is not usual guest system and I don't want bug to be ignored :) -- // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Wed Jan 22 10:38:08 2014 Return-Path: Delivered-To: freebsd-current@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 E863E563 for ; Wed, 22 Jan 2014 10:38:08 +0000 (UTC) Received: from mta04.bitpro.no (mta04.bitpro.no [92.42.64.203]) by mx1.freebsd.org (Postfix) with ESMTP id 97C811922 for ; Wed, 22 Jan 2014 10:38:08 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta04.bitpro.no (Postfix) with ESMTPS id 2FD3A10058D; Wed, 22 Jan 2014 11:38:07 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id C3C6E1604EA; Wed, 22 Jan 2014 11:38:56 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UPqLZC-Ln03; Wed, 22 Jan 2014 11:38:56 +0100 (CET) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id 11A3C1604E9; Wed, 22 Jan 2014 11:38:55 +0100 (CET) Message-ID: <52DF9FCE.6010603@bitfrost.no> Date: Wed, 22 Jan 2014 11:39:10 +0100 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Olivier_Cochard-Labb=E9?= , "freebsd-current@freebsd.org" Subject: Re: Bad support of Kingston DataTraveler/DT USB key since 9.2 (not fixed in 10.0) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 10:38:09 -0000 On 01/22/14 11:31, Olivier Cochard-Labbé wrote: > Hi all, > There is a regression since 9.2 (still not fixed on 10.0) regarding a list > of Kingston DataTraveler/DT USB keys > - usb/180837, regarding "Kingston DT 101 G2": This PR include a patch for > 9.2 and a link to netbsd code that include other Kingston USB keys; > - usb/184014, regarding "Kingston DT 100 G2" (include tips for debugging) > - usb/185747, regarding "Kingston DT 101 G2" (duplicate PR with > usb/180837), that include a patch for 10.0; > - misc/185837, regarding "Kingston DataTraveler 2.0". > > Can someone check with the netbsd code for the full list of known buggy > Kingston USB key and commit these quirks patches ? > Hi, Can you make a list of VID+PID and the minimum of quirks needed. Many Kingston devices I've got work just fine. Maybe they are not original? --HPS From owner-freebsd-current@FreeBSD.ORG Wed Jan 22 14:25:38 2014 Return-Path: Delivered-To: freebsd-current@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 9961B587; Wed, 22 Jan 2014 14:25:38 +0000 (UTC) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5A6CD1DBE; Wed, 22 Jan 2014 14:25:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=MVRcS7qDXnmS2x9xxquFtNnKftV0GuvYd7ajw6g4uBE=; b=GyH4sur1ybdR7EzDAcOvPzXfaD2Z4TpPnQQisXrB4jLVsYAxApmr7632OLCqd8RuQsGImoYbJ4s2cMb6gkA8YbJXeZnHyGUd5VTlmwFyNwi1VqfzVchlSSE9lxi2z21RlL6Yclq/yKUtF+pSpewH04GvWYoZbaYDVgtfq5AyFE4=; Received: from localhost.lerctr.org ([127.0.0.1]:40046 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpa (Exim 4.82 (FreeBSD)) (envelope-from ) id 1W5ykE-000EjT-HD; Wed, 22 Jan 2014 08:25:36 -0600 Received: from proxy.lucent.com ([135.245.48.14]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Wed, 22 Jan 2014 08:25:30 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 22 Jan 2014 08:25:30 -0600 From: Larry Rosenman To: Freebsd fs , Freebsd current Subject: Fwd: Panic/Solaris Assert/ZAP.c:534 Message-ID: X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/0.9.5 X-Spam-Score: 2.0 (++) X-LERCTR-Spam-Score: 2.0 (++) X-Spam-Report: SpamScore (2.0/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, FH_RANDOM_SURE=0.001, KAM_STOCKTIP=5.5, RP_MATCHES_RCVD=-0.59 X-LERCTR-Spam-Report: SpamScore (2.0/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, FH_RANDOM_SURE=0.001, KAM_STOCKTIP=5.5, RP_MATCHES_RCVD=-0.59 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 14:25:38 -0000 Repost, including the FS guys. Ideas? -------- Original Message -------- Subject: Panic/Solaris Assert/ZAP.c:534 Date: 2014-01-20 21:23 From: Larry Rosenman To: freebsd-current@freebsd.org Ideas? I'm getting this on a regular basis, and scrub/etc doesn't seem to get around it, but booting off: FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #113 r260864: Fri Jan 17 19:10:06 CST 2014 root@:/usr/obj/usr/src/sys/BORG-DTRACE amd64 Seems to avoid it. HELP. borg.lerctr.org dumped core - see /var/crash/vmcore.1 Mon Jan 20 21:18:41 CST 2014 FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r260896: Mon Jan 20 12:31:46 CST 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 panic: solaris assert: l->l_phys->l_hdr.lh_block_type == ((1ULL << 63) + 0) (0x0 == 0x8000000000000000), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c, line: 534 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: Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #1 r260896: Mon Jan 20 12:31:46 CST 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 info: [drm] Initialized drm 1.1.0 20060810 CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (2327.55-MHz K8-class CPU) Origin="GenuineIntel" Id=0x10676 Family=0x6 Model=0x17 Stepping=6 Features=0xbfebfbff Features2=0xce3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 68719476736 (65536 MB) avail memory = 65641644032 (62600 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard random: initialized kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) unknown: I/O range not supported cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 350 Event timer "HPET1" frequency 14318180 Hz quality 340 Event timer "HPET2" frequency 14318180 Hz quality 340 atrtc0: port 0x70-0x71 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 pcib5: at device 0.2 on pci3 pci5: on pcib5 pcib6: irq 18 at device 2.0 on pci2 pci6: on pcib6 em0: port 0x2000-0x201f mem 0xd9220000-0xd923ffff,0xd9200000-0xd921ffff irq 18 at device 0.0 on pci6 em0: Using an MSI interrupt em0: Ethernet address: 00:30:48:f2:29:9c em1: port 0x2020-0x203f mem 0xd9260000-0xd927ffff,0xd9240000-0xd925ffff irq 19 at device 0.1 on pci6 em1: Using an MSI interrupt em1: Ethernet address: 00:30:48:f2:29:9d pcib7: at device 0.3 on pci1 pci7: on pcib7 pcib8: at device 4.0 on pci0 pci8: on pcib8 vgapci0: port 0x3000-0x307f mem 0xd8000000-0xd8ffffff,0xc0000000-0xc7ffffff,0xc8000000-0xc9ffffff irq 16 at device 0.0 on pci8 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io hdac0: mem 0xd9000000-0xd9003fff irq 17 at device 0.1 on pci8 pcib9: at device 6.0 on pci0 pci9: on pcib9 pci0: at device 8.0 (no driver attached) pcib10: irq 17 at device 28.0 on pci0 pci10: on pcib10 pcib11: irq 16 at device 0.0 on pci10 pci11: on pcib11 pcm0: port 0x4080-0x409f,0x4000-0x407f irq 16 at device 0.0 on pci11 pcm0: system configuration SubVendorID: 0x1412, SubDeviceID: 0x2403 XIN2 Clock Source: 24.576MHz(96kHz*256) MPU-401 UART(s) #: not implemented ADC #: 1 and SPDIF receiver connected DAC #: 4 Multi-track converter type: AC'97(SDATA_OUT:packed) S/PDIF(IN/OUT): 1/1 ID# 0x00 GPIO(mask/dir/state): 0xff/0xff/0xff uhci0: port 0x1800-0x181f irq 17 at device 29.0 on pci0 usbus0 on uhci0 uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 usbus1 on uhci1 uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 usbus2 on uhci2 ehci0: mem 0xd9600400-0xd96007ff irq 17 at device 29.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib12: at device 30.0 on pci0 pci12: on pcib12 vgapci1: port 0x5000-0x50ff mem 0xd0000000-0xd7ffffff,0xd9300000-0xd930ffff irq 18 at device 1.0 on pci12 drmn1: on vgapci1 info: [drm] RADEON_IS_PCI info: [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080). info: [drm] register mmio base: 0xD9300000 info: [drm] register mmio size: 65536 info: [drm] radeon_atrm_get_bios: ===> Try ATRM... info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:8:0:0, vendor=10de, device=104a info: [drm] radeon_atrm_get_bios: Get ACPI device handle info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0xd0000000 info: [drm] igp_read_bios_from_vram: Map address: 0xfffff800d0000000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x0000 info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] radeon_read_bios: Map address: 0xfffff800000c0000 (131072 bytes) drmn1: info: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used) drmn1: info: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] radeon: irq initialized. info: [drm] Detected VRAM RAM=128M, BAR=128M info: [drm] RAM width 64bits SDR [TTM] Zone kernel: Available graphics memory: 33006090 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator info: [drm] radeon: 16M of VRAM memory ready info: [drm] radeon: 512M of GTT memory ready. info: [drm] GART: num cpu pages 131072, num gpu pages 131072 info: [drm] PCI GART of 512M enabled (table at 0x0000000011200000). drmn1: info: WB disabled drmn1: info: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0x0xfffff8001083c000 info: [drm] Loading R100 Microcode info: [drm] radeon: ring at 0x00000000B0001000 info: [drm] ring test succeeded in 1 usecs info: [drm] ib test succeeded in 0 usecs info: [drm] radeon_device_init: Taking over the fictitious range 0xd0000000-0xd4000000 iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iicbus1: on iicbb1 addr 0xff iic1: on iicbus1 iicbus2: on iicbb2 addr 0xff iic2: on iicbus2 iicbus3: on iicbb3 addr 0xff iic3: on iicbus3 info: [drm] Radeon Display Connectors info: [drm] Connector 0: info: [drm] VGA-1 info: [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60 info: [drm] Encoders: info: [drm] CRT1: INTERNAL_DAC1 info: [drm] Connector 1: info: [drm] DVI-I-1 info: [drm] HPD2 info: [drm] DDC: 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c info: [drm] Encoders: info: [drm] CRT2: INTERNAL_DAC2 info: [drm] DFP2: INTERNAL_DVO1 composite sync not supported composite sync not supported info: [drm] fb mappable at 0xD0040000 info: [drm] vram apper at 0xD0000000 info: [drm] size 2076672 info: [drm] fb depth is 8 info: [drm] pitch is 1920 fbd1 on drmn1 vt_allocate: Replace existing VT driver. info: [drm] Initialized radeon 2.29.0 20080528 vgapci1: Boot video device isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: at channel 0 on atapci0 ahci0: port 0x18a0-0x18a7,0x1874-0x1877,0x1878-0x187f,0x1870-0x1873,0x1880-0x189f mem 0xd9600800-0xd9600bff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ichsmb0: port 0x1100-0x111f irq 19 at device 31.3 on pci0 smbus0: on ichsmb0 acpi_button0: on acpi0 ipmi0: port 0xca2-0xca3 on acpi0 ipmi0: KCS mode found at io 0xca2 on acpi atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ichwd0 on isa0 orm0: at iomem 0xc0000-0xcafff on isa0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 coretemp4: on cpu4 est4: on cpu4 p4tcc4: on cpu4 coretemp5: on cpu5 est5: on cpu5 p4tcc5: on cpu5 coretemp6: on cpu6 est6: on cpu6 p4tcc6: on cpu6 coretemp7: on cpu7 est7: on cpu7 p4tcc7: on cpu7 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x387 offMax=0x491 hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm1: at nid 4 on hdaa0 pcm2: at nid 5 on hdaa0 random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen3.1: at usbus3 uhub0: on usbus3 ugen2.1: at usbus2 uhub1: on usbus2 ugen1.1: at usbus1 uhub2: on usbus1 ugen0.1: at usbus0 uhub3: on usbus0 ipmi0: IPMI device rev. 1, firmware rev. 1.64, version 2.0 ata0: DMA limited to UDMA33, controller found non-ATA66 cable ipmi0: Number of channels 8 ipmi0: Attached watchdog uhub2: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: Serial Number 5YDA1ZL4 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus2 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: Serial Number 5YD6FPLG ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada1: quirks=0x1<4K> ada1: Previously was known as ad6 ada2 at ahcich2 bus 0 scbus3 target 0 lun 0 ada2: ATA-8 SATA 3.x device ada2: Serial Number 5YDA3PC5 ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada2: quirks=0x1<4K> ada2: Previously was known as ad8 ada3 at ahcich3 bus 0 scbus4 target 0 lun 0 ada3: ATA-8 SATA 3.x device ada3: Serial Number 5YD9Y0P4 ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3: quirks=0x1<4K> ada3: Previously was known as ad10 ada4 at ahcich4 bus 0 scbus5 target 0 lun 0 ada4: ATA-8 SATA 3.x device ada4: Serial Number 5YDA1R5W ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada4: quirks=0x1<4K> ada4: Previously was known as ad12 ada5 at ahcich5 bus 0 scbus6 target 0 lun 0 ada5: ATA-8 SATA 3.x device ada5: Serial Number 5YD5RBS8 ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada5: quirks=0x1<4K> ada5: Previously was known as ad14 cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present Netvsc initializing... done! SMP: AP CPU #6 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #3 Launched! Root mount waiting for: usbus3 uhub0: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 Root mount waiting for: usbus3 ugen3.2: at usbus3 ukbd0: on usbus3 kbd2 at ukbd0 Trying to mount root from zfs:zroot/ROOT/default []... ugen0.2: at usbus0 ugen1.2: at usbus1 <118>Setting hostuuid: 53d19f64-d663-a017-8922-0030488e9ff3. <118>Setting hostid: 0xf53a926e. <118>Entropy harvesting: interrupts ethernet point_to_point swi. <118>Starting file system checks: <118>Mounting local file systems:. panic: solaris assert: l->l_phys->l_hdr.lh_block_type == ((1ULL << 63) + 0) (0x0 == 0x8000000000000000), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c, line: 534 cpuid = 7 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe100c499090 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe100c499140 vpanic() at vpanic+0x126/frame 0xfffffe100c499180 panic() at panic+0x43/frame 0xfffffe100c4991e0 assfail3() at assfail3+0x2f/frame 0xfffffe100c499200 zap_get_leaf_byblk() at zap_get_leaf_byblk+0x4e1/frame 0xfffffe100c499250 zap_deref_leaf() at zap_deref_leaf+0xd1/frame 0xfffffe100c4992a0 fzap_cursor_retrieve() at fzap_cursor_retrieve+0xce/frame 0xfffffe100c499310 zap_cursor_retrieve() at zap_cursor_retrieve+0x20a/frame 0xfffffe100c499390 ddt_zap_walk() at ddt_zap_walk+0x5e/frame 0xfffffe100c499650 ddt_walk() at ddt_walk+0x78/frame 0xfffffe100c499680 dsl_scan_sync() at dsl_scan_sync+0x6ec/frame 0xfffffe100c4999e0 spa_sync() at spa_sync+0x5c4/frame 0xfffffe100c499ad0 txg_sync_thread() at txg_sync_thread+0x256/frame 0xfffffe100c499bb0 fork_exit() at fork_exit+0x84/frame 0xfffffe100c499bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe100c499bf0 --- trap 0, rip = 0, rsp = 0xfffffe100c499cb0, rbp = 0 --- KDB: enter: panic Uptime: 14s Dumping 2263 out of 64465 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel.old/linux.ko.symbols...done. Loaded symbols for /boot/kernel.old/linux.ko.symbols Reading symbols from /boot/kernel.old/if_lagg.ko.symbols...done. Loaded symbols for /boot/kernel.old/if_lagg.ko.symbols Reading symbols from /boot/kernel.old/snd_envy24ht.ko.symbols...done. Loaded symbols for /boot/kernel.old/snd_envy24ht.ko.symbols Reading symbols from /boot/kernel.old/snd_spicds.ko.symbols...done. Loaded symbols for /boot/kernel.old/snd_spicds.ko.symbols Reading symbols from /boot/kernel.old/coretemp.ko.symbols...done. Loaded symbols for /boot/kernel.old/coretemp.ko.symbols Reading symbols from /boot/kernel.old/ichsmb.ko.symbols...done. Loaded symbols for /boot/kernel.old/ichsmb.ko.symbols Reading symbols from /boot/kernel.old/smbus.ko.symbols...done. Loaded symbols for /boot/kernel.old/smbus.ko.symbols Reading symbols from /boot/kernel.old/ichwd.ko.symbols...done. Loaded symbols for /boot/kernel.old/ichwd.ko.symbols Reading symbols from /boot/kernel.old/cpuctl.ko.symbols...done. Loaded symbols for /boot/kernel.old/cpuctl.ko.symbols Reading symbols from /boot/kernel.old/crypto.ko.symbols...done. Loaded symbols for /boot/kernel.old/crypto.ko.symbols Reading symbols from /boot/kernel.old/cryptodev.ko.symbols...done. Loaded symbols for /boot/kernel.old/cryptodev.ko.symbols Reading symbols from /boot/kernel.old/dtraceall.ko.symbols...done. Loaded symbols for /boot/kernel.old/dtraceall.ko.symbols Reading symbols from /boot/kernel.old/profile.ko.symbols...done. Loaded symbols for /boot/kernel.old/profile.ko.symbols Reading symbols from /boot/kernel.old/cyclic.ko.symbols...done. Loaded symbols for /boot/kernel.old/cyclic.ko.symbols Reading symbols from /boot/kernel.old/dtrace.ko.symbols...done. Loaded symbols for /boot/kernel.old/dtrace.ko.symbols Reading symbols from /boot/kernel.old/systrace_freebsd32.ko.symbols...done. Loaded symbols for /boot/kernel.old/systrace_freebsd32.ko.symbols Reading symbols from /boot/kernel.old/systrace.ko.symbols...done. Loaded symbols for /boot/kernel.old/systrace.ko.symbols Reading symbols from /boot/kernel.old/sdt.ko.symbols...done. Loaded symbols for /boot/kernel.old/sdt.ko.symbols Reading symbols from /boot/kernel.old/lockstat.ko.symbols...done. Loaded symbols for /boot/kernel.old/lockstat.ko.symbols Reading symbols from /boot/kernel.old/fasttrap.ko.symbols...done. Loaded symbols for /boot/kernel.old/fasttrap.ko.symbols Reading symbols from /boot/kernel.old/fbt.ko.symbols...done. Loaded symbols for /boot/kernel.old/fbt.ko.symbols Reading symbols from /boot/kernel.old/dtnfscl.ko.symbols...done. Loaded symbols for /boot/kernel.old/dtnfscl.ko.symbols Reading symbols from /boot/kernel.old/dtmalloc.ko.symbols...done. Loaded symbols for /boot/kernel.old/dtmalloc.ko.symbols Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel.old/ipmi.ko.symbols...done. Loaded symbols for /boot/kernel.old/ipmi.ko.symbols Reading symbols from /boot/kernel.old/ipmi_linux.ko.symbols...done. Loaded symbols for /boot/kernel.old/ipmi_linux.ko.symbols Reading symbols from /boot/kernel.old/radeonkms.ko.symbols...done. Loaded symbols for /boot/kernel.old/radeonkms.ko.symbols Reading symbols from /boot/kernel.old/iicbb.ko.symbols...done. Loaded symbols for /boot/kernel.old/iicbb.ko.symbols Reading symbols from /boot/kernel.old/iicbus.ko.symbols...done. Loaded symbols for /boot/kernel.old/iicbus.ko.symbols Reading symbols from /boot/kernel.old/iic.ko.symbols...done. Loaded symbols for /boot/kernel.old/iic.ko.symbols Reading symbols from /boot/kernel.old/drm2.ko.symbols...done. Loaded symbols for /boot/kernel.old/drm2.ko.symbols Reading symbols from /boot/kernel.old/radeonkmsfw_R100_cp.ko.symbols...done. Loaded symbols for /boot/kernel.old/radeonkmsfw_R100_cp.ko.symbols Reading symbols from /boot/kernel.old/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel.old/fdescfs.ko.symbols Reading symbols from /boot/kernel.old/linprocfs.ko.symbols...done. Loaded symbols for /boot/kernel.old/linprocfs.ko.symbols #0 doadump (textdump=1) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0xffffffff809b98d7 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:452 #2 0xffffffff809b9de5 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff809b9e33 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:688 #4 0xffffffff80327a2f in assfail3 (a=, lv=, op=, rv=, f=, l=) at /usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:91 #5 0xffffffff803bad81 in zap_get_leaf_byblk (zap=, blkid=, tx=0x0, lt=, lp=0xfffffe100c4994e8) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:534 #6 0xffffffff803b8461 in zap_deref_leaf (zap=0xfffff80020a4ec00, h=9377620324092215296, tx=0x0, lt=RW_READER, lp=0xfffffe100c4994e8) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:585 #7 0xffffffff803ba24e in fzap_cursor_retrieve (zap=0xfffff80020a4ec00, zc=0xfffffe100c4994d8, za=0xfffffe100c4993c0) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:1181 #8 0xffffffff803c076a in zap_cursor_retrieve (zc=0xfffffe100c4994d8, za=0xfffffe100c4993c0) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:1290 #9 0xffffffff80352fde in ddt_zap_walk (os=0xfffff8002031bc00, object=156, dde=0xfffffe100c499828, walk=0xfffff800201ce3d0) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ddt_zap.c:117 #10 0xffffffff80352c88 in ddt_walk (spa=0xfffffe000d377000, ddb=0xfffff800201ce3b8, dde=0xfffffe100c499828) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ddt.c:219 #11 0xffffffff803800dc in dsl_scan_sync (dp=0xfffff8002031f800, tx=0xfffff80022180000) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c:1204 #12 0xffffffff803999b4 in spa_sync (spa=0xfffffe000d377000, txg=14079627) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:6549 #13 0xffffffff803a4e96 in txg_sync_thread (arg=0xfffff8002031f800) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c:518 #14 0xffffffff80988f94 in fork_exit ( callout=0xffffffff803a4c40 , arg=0xfffff8002031f800, frame=0xfffffe100c499c00) at /usr/src/sys/kern/kern_fork.c:977 #15 0xffffffff80d9576e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:605 #16 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) ------------------------------------------------------------------------ ps -axlww UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -8 0 0 0 - DLs - 0:00.10 [kernel] 0 1 0 0 21 0 9432 0 wait DLs - 0:00.00 [init] 0 2 0 0 -16 0 0 0 ftcl DL - 0:00.00 [ftcleanup] 0 3 0 0 -16 0 0 0 crypto_w DL - 0:00.00 [crypto] 0 4 0 0 -16 0 0 0 crypto_r DL - 0:00.00 [crypto returns] 0 5 0 0 -16 0 0 0 ccb_scan DL - 0:00.00 [cam] 0 6 0 0 -16 0 0 0 - DL - 0:00.00 [fdc0] 0 7 0 0 -8 0 0 0 - RL - 0:00.00 [zfskern] 0 8 0 0 -16 0 0 0 waiting_ DL - 0:00.00 [sctp_iterator] 0 9 0 0 -16 0 0 0 ipmireq DL - 0:00.00 [ipmi0: kcs] 0 10 0 0 -16 0 0 0 audit_wo DL - 0:00.00 [audit] 0 11 0 0 155 0 0 0 - RL - 0:00.00 [idle] 0 12 0 0 -84 0 0 0 - WL - 0:00.00 [intr] 0 13 0 0 -8 0 0 0 - DL - 0:00.00 [geom] 0 14 0 0 -16 0 0 0 - DL - 0:00.00 [rand_harvestq] 0 15 0 0 -68 0 0 0 - DL - 0:00.00 [usb] 0 16 0 0 -20 0 0 0 VBoxIS DL - 0:00.00 [TIMER] 0 17 0 0 -16 0 0 0 psleep DL - 0:00.00 [pagedaemon] 0 18 0 0 -16 0 0 0 psleep DL - 0:00.00 [vmdaemon] 0 19 0 0 155 0 0 0 pgzero DL - 0:00.00 [pagezero] 0 20 0 0 -16 0 0 0 psleep DL - 0:00.00 [bufdaemon] 0 21 0 0 16 0 0 0 syncer DL - 0:00.00 [syncer] 0 22 0 0 -16 0 0 0 vlruwt DL - 0:00.00 [vnlru] 0 23 0 0 -16 0 0 0 sdflush DL - 0:00.00 [softdepflush] 0 24 1 0 52 0 16992 0 wait Ds+ - 0:00.02 [sh] 0 72 24 0 52 0 16992 0 wait D+ - 0:00.00 [sh] 0 75 72 0 39 0 40064 0 zio->io_ D+ - 0:00.00 [zfs] ------------------------------------------------------------------------ vmstat -s 42891 cpu context switches 5520 device interrupts 462 software interrupts 5061 traps 5879 system calls 23 kernel threads created 37 fork() calls 15 vfork() calls 0 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 0 swap pager pageouts 0 swap pager pages paged out 135 vnode pager pageins 923 vnode pager pages paged in 0 vnode pager pageouts 0 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 0 pages reactivated 1770 copy-on-write faults 15 copy-on-write optimized faults 2266 zero fill pages zeroed 0 zero fill pages prezeroed 0 intransit blocking page faults 4682 total VM faults taken 112 page faults requiring I/O 0 pages affected by kernel thread creation 1350 pages affected by fork() 525 pages affected by vfork() 0 pages affected by rfork() 0 pages cached 55124 pages freed 0 pages freed by daemon 0 pages freed by exiting processes 473 pages active 869 pages inactive 0 pages in VM cache 140410 pages wired down 15933660 pages free 4096 bytes per page 1934 total name lookups cache hits (80% pos + 4% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) cdev 8 2K - 8 256 ppbusdev 2 1K - 2 256 filedesc 27 54K - 76 2048 kdtrace 330 78K - 522 64,256 kenv 87 12K - 115 16,32,64,128 proc-args 3 1K - 31 32,64,128 hhook 2 1K - 2 256 ithread 125 22K - 125 32,128,256 KTRACE 100 13K - 100 128 entropy 1026 65K - 1026 32,64 acpiintr 1 1K - 1 64 linker 403 101K - 533 16,32,64,128,256,512,1024,2048,4096 lockf 2 1K - 2 64,128 loginclass 2 1K - 2 64 cache 1 1K - 1 32 devbuf 17314 34391K - 18687 16,32,64,128,256,512,1024,2048,4096 temp 57 18K - 548 16,32,64,128,256,512,1024,2048 ip6ndp 3 1K - 3 64 ata_pci 1 1K - 1 64 acpica 1824 187K - 63680 16,32,64,128,256,512,1024,2048 kbdmux 7 18K - 7 16,512,1024,2048 module 521 66K - 521 128 mtx_pool 2 16K - 2 LED 4 1K - 4 16,128 CAM XPT 58 4K - 309 16,32,64,128,512,1024,2048 osd 6 1K - 12 16,32,64,128 pmchooks 1 1K - 1 128 CAM DEV 15 30K - 24 2048 acpitask 1 8K - 1 hdaa 4 5K - 4 512,1024,2048 pgrp 2 1K - 2 128 session 2 1K - 2 128 proc 2 256K - 2 subproc 100 145K - 149 512,4096 cred 54 9K - 254 64,256 plimit 2 1K - 2 256 uidinfo 2 33K - 2 128 hdac 1 1K - 1 512 hdacc 1 1K - 1 32 vtbuf 24 5712K - 24 4096 acpisem 22 3K - 22 128 vt 11 3K - 11 256 sysctl 0 0K - 50 16,32,64 sysctloid 7607 378K - 7779 16,32,64,128 sysctltmp 0 0K - 6 32,64 tidhash 1 256K - 1 callout 9 3208K - 9 umtx 684 86K - 684 128 p1003.1b 1 1K - 1 16 SWAP 12 19681K - 12 64 bus 2257 362K - 8440 16,32,64,128,256,512,1024 bus-sc 157 310K - 5479 16,32,64,128,256,512,1024,2048,4096 devstat 32 65K - 32 32,4096 eventhandler 104 9K - 104 64,128 DEVFS3 230 58K - 270 256 kobj 349 1396K - 1111 4096 DEVFS1 202 101K - 238 512 Per-cpu 1 1K - 1 32 DEVFS 41 1K - 42 16,128 rman 360 41K - 754 16,32,128 sbuf 0 0K - 2295 16,32,64,128,256 sglist 3 1K - 3 32 taskqueue 127 19K - 171 16,32,64,128,256 terminal 11 3K - 11 256 Unitno 28 2K - 120 32,64 vmem 2 136K - 2 ioctlops 0 0K - 158 16,32,64 iov 1 1K - 34 64,256,512 msg 4 30K - 4 2048,4096 sem 4 106K - 4 2048,4096 shm 1 20K - 1 tty 14 14K - 14 1024 shmfd 1 8K - 1 pcb 12 8341K - 12 16,128,1024,2048 vfscache 1 16384K - 1 vfs_hash 1 8192K - 1 vnodes 1 1K - 1 256 mount 251 9K - 550 16,32,64,128,256 vnodemarker 0 0K - 5 512 BPF 3 1K - 3 128 ifnet 4 7K - 4 128,2048 ifaddr 34 10K - 34 32,64,256,512,2048,4096 clone 8 1K - 8 128 arpcom 2 1K - 2 16 lltable 6 3K - 6 512 routetbl 5 2K - 5 256,512 igmp 3 1K - 3 256 sctp_vrf 1 1K - 1 64 hostcache 1 28K - 1 syncache 1 64K - 1 mld 3 1K - 3 128 rpc 2 1K - 2 512 audit_evclass 187 6K - 228 32 ufs_quota 1 8192K - 1 vm_pgdata 7 8193K - 7 128 pfs_nodes 73 19K - 73 256 pfs_vncache 2 1K - 2 64 scsi_cd 0 0K - 11 16 GEOM 404 67K - 3278 16,32,64,128,256,512,1024,2048 memdesc 1 4K - 1 4096 feeder 20 2K - 24 32,128 acpidev 36 3K - 36 64 atkbddev 2 1K - 2 64 CAM CCB 0 0K - 5331 2048 mixer 3 12K - 3 4096 raid_data 0 0K - 480 32,128,256 CAM path 22 1K - 115 32 solaris 289279 163254K - 391115 16,32,64,128,256,512,1024,2048,4096 UART 6 5K - 6 16,1024 kstat_data 6 1K - 6 64 CAM periph 16 4K - 40 16,32,64,128,256 md_nvidia_data 0 0K - 78 512 pci_link 16 2K - 16 32,64,128 md_sii_data 0 0K - 78 512 acpi_perf 8 1K - 8 64 CAM queue 23 8K - 57 16,32,512 apmdev 1 1K - 1 128 madt_table 0 0K - 1 4096 CAM dev queue 8 1K - 8 64 CAM SIM 8 2K - 8 256 ddb_capture 1 48K - 1 io_apic 2 4K - 2 2048 MCA 8 1K - 8 128 msi 4 1K - 4 128 nexusdev 4 1K - 4 16 isadev 5 1K - 5 128 USB 46 59K - 52 16,32,64,128,256,512,1024,2048,4096 USBdev 35 4K - 35 32,64,128,256 linux 17 2K - 17 64 spicds 7 1K - 7 128 envy24ht 15 195K - 15 64,2048 cpuctl 1 1K - 1 64 crypto 1 1K - 1 512 cyclic 32 3K - 32 16,64,128 SDT 32 2K - 32 16,64 fbt 60661 7839K - 60661 128 iprtheap 17 54K - 17 32,64,128,256 nvidia 194 864K - 195 16,32,64,128,256,512,1024,2048,4096 ipmi 0 0K - 11 128 gem_name 59 10K - 62 32,4096 drm_global 2 1K - 2 128,256 drm_vblank 7 1K - 7 16,64 drm_dma 2 1K - 2 32 drm_sarea 1 1K - 1 16 drm_driver 32 2203K - 36 16,32,64,128,256,512,1024,4096 drm_ctxbitmap 1 4K - 1 4096 drm_sman 13 2K - 13 128 drm_hashtab 1 4096K - 1 drm_kms 90 18K - 107 16,32,64,128,256,2048 ttm_pd 6 9K - 6 16,2048 ttm_rman 2 1K - 2 256 ttm_zone 2 1K - 2 64 ttm_poolmgr 1 1K - 1 512 fdesc_mount 1 1K - 1 16 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 384, 0, 267, 3, 267, 0, 0 UMA Zones: 1664, 0, 267, 1, 267, 0, 0 UMA Slabs: 112, 0, 4719, 6, 7221, 0, 0 UMA RCntSlabs: 120, 0, 0, 0, 0, 0, 0 UMA Hash: 256, 0, 77, 13, 77, 0, 0 4 Bucket: 32, 0, 262, 854, 1813, 0, 0 6 Bucket: 48, 0, 276, 1052, 1590, 0, 0 8 Bucket: 64, 0, 62, 992, 883, 0, 0 12 Bucket: 96, 0, 36, 989, 167, 0, 0 16 Bucket: 128, 0, 131, 1016, 1263, 17, 0 32 Bucket: 256, 0, 130, 380, 285, 49, 0 64 Bucket: 512, 0, 119, 238, 465, 49, 0 128 Bucket: 1024, 0, 406, 46, 3736, 2, 0 vmem btag: 56, 0, 11416, 441, 11514, 167, 0 VM OBJECT: 256, 0, 590, 400, 1335, 0, 0 RADIX NODE: 144, 0, 6442, 416, 10926, 0, 0 MAP: 240, 0, 3, 61, 3, 0, 0 KMAP ENTRY: 128, 0, 8, 271, 8, 0, 0 MAP ENTRY: 128, 0, 103, 920, 1717, 0, 0 VMSPACE: 448, 0, 4, 204, 54, 0, 0 fakepg: 104, 0, 0, 0, 0, 0, 0 mt_zone: 4112, 0, 405, 0, 405, 0, 0 16: 16, 0, 6, 243, 6, 0, 0 16: 16, 0, 2762, 973, 3015, 0, 0 16: 16, 0, 147166, 740, 158653, 0, 0 16: 16, 0, 55, 941, 28215, 0, 0 16: 16, 0, 62, 685, 63, 0, 0 16: 16, 0, 732, 1011, 5473, 0, 0 16: 16, 0, 30, 219, 30, 0, 0 16: 16, 0, 1, 746, 18, 0, 0 32: 32, 0, 30, 1086, 117, 0, 0 32: 32, 0, 3091, 877, 3295, 0, 0 32: 32, 0, 65004, 716, 73960, 0, 0 32: 32, 0, 66, 554, 4216, 0, 0 32: 32, 0, 18, 1098, 98, 0, 0 32: 32, 0, 839, 897, 2874, 0, 0 32: 32, 0, 94, 650, 186, 0, 0 32: 32, 0, 8, 736, 164, 0, 0 64: 64, 0, 5, 181, 6, 0, 0 64: 64, 0, 517, 909, 589, 0, 0 64: 64, 0, 7078, 982, 33984, 0, 0 64: 64, 0, 767, 783, 1637, 0, 0 64: 64, 0, 80, 106, 80, 0, 0 64: 64, 0, 9187, 857, 9746, 0, 0 64: 64, 0, 131, 551, 131, 0, 0 64: 64, 0, 1038, 760, 1071, 0, 0 128: 128, 0, 34, 741, 95, 0, 0 128: 128, 0, 1899, 612, 1908, 0, 0 128: 128, 0, 121830, 806, 128094, 0, 0 128: 128, 0, 1077, 318, 27007, 0, 0 128: 128, 0, 112, 663, 192, 0, 0 128: 128, 0, 1895, 740, 4111, 0, 0 128: 128, 0, 29, 126, 30, 0, 0 128: 128, 0, 524, 499, 526, 0, 0 256: 256, 0, 2, 73, 2, 0, 0 256: 256, 0, 308, 307, 451, 0, 0 256: 256, 0, 372, 543, 2665, 0, 0 256: 256, 0, 64, 131, 740, 0, 0 256: 256, 0, 28, 347, 348, 0, 0 256: 256, 0, 909, 441, 1963, 0, 0 256: 256, 0, 31, 44, 31, 0, 0 256: 256, 0, 4, 191, 25, 0, 0 512: 512, 0, 2, 33, 9, 0, 0 512: 512, 0, 69, 197, 225, 0, 0 512: 512, 0, 130, 276, 32908, 0, 0 512: 512, 0, 16, 47, 35, 0, 0 512: 512, 0, 3, 32, 3, 0, 0 512: 512, 0, 327, 170, 2804, 0, 0 512: 512, 0, 47, 16, 47, 0, 0 512: 512, 0, 1, 62, 2, 0, 0 1024: 1024, 0, 0, 104, 99, 0, 0 1024: 1024, 0, 9, 19, 9, 0, 0 1024: 1024, 0, 8372, 68, 23684, 0, 0 1024: 1024, 0, 5, 23, 2074, 0, 0 1024: 1024, 0, 16, 12, 16, 0, 0 1024: 1024, 0, 230, 98, 1280, 0, 0 1024: 1024, 0, 2, 14, 2, 0, 0 1024: 1024, 0, 0, 0, 0, 0, 0 2048: 2048, 0, 2, 4, 9, 0, 0 2048: 2048, 0, 6, 4, 6, 0, 0 2048: 2048, 0, 11, 19, 39, 0, 0 2048: 2048, 0, 7, 53, 5343, 0, 0 2048: 2048, 0, 21, 9, 30, 0, 0 2048: 2048, 0, 48, 42, 466, 0, 0 2048: 2048, 0, 5, 1, 5, 0, 0 2048: 2048, 0, 0, 0, 0, 0, 0 4096: 4096, 0, 0, 0, 0, 0, 0 4096: 4096, 0, 5, 0, 5, 0, 0 4096: 4096, 0, 167, 4, 295, 0, 0 4096: 4096, 0, 10, 0, 12, 0, 0 4096: 4096, 0, 16, 0, 17, 0, 0 4096: 4096, 0, 25, 0, 415, 0, 0 4096: 4096, 0, 15, 0, 15, 0, 0 4096: 4096, 0, 349, 10, 1111, 0, 0 uint64 pcpu: 8, 0, 1398, 138, 1398, 0, 0 SLEEPQUEUE: 88, 0, 343, 680, 343, 0, 0 Files: 80, 0, 8, 874, 395, 0, 0 rl_entry: 40, 0, 6, 687, 6, 0, 0 TURNSTILE: 136, 0, 343, 277, 343, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1208, 0, 26, 46, 75, 0, 0 THREAD: 1168, 0, 302, 40, 445, 0, 0 cpuset: 72, 0, 287, 593, 430, 0, 0 cyclic_id_cache: 64, 0, 0, 0, 0, 0, 0 audit_record: 1248, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 25720710, 0, 10, 0, 0, 0 mbuf: 256, 25720710, 1, 134, 1, 0, 0 mbuf_cluster: 2048, 4018860, 0, 0, 0, 0, 0 mbuf_jumbo_page: 4096, 2009429, 0, 0, 0, 0, 0 mbuf_jumbo_9k: 9216, 1786158, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 1339616, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 sendfile_sync: 128, 0, 0, 0, 0, 0, 0 dtrace_state_cache: 4096, 0, 0, 0, 0, 0, 0 g_bio: 248, 0, 0, 672, 15403, 0, 0 DMAR_MAP_ENTRY: 120, 0, 0, 0, 0, 0, 0 ttyinq: 160, 0, 15, 57, 15, 0, 0 ttyoutq: 256, 0, 8, 67, 8, 0, 0 ata_request: 336, 0, 0, 88, 39, 0, 0 vtnet_tx_hdr: 24, 0, 0, 0, 0, 0, 0 cryptop: 88, 0, 0, 0, 0, 0, 0 cryptodesc: 72, 0, 0, 0, 0, 0, 0 nv_stack_t: 12288, 0, 2, 1, 6, 0, 0 FPU_save_area: 512, 0, 0, 0, 0, 0, 0 taskq_zone: 48, 0, 0, 415, 20, 0, 0 taskq_zone: 48, 0, 0, 0, 0, 0, 0 VNODE: 472, 0, 332, 164, 333, 0, 0 VNODEPOLL: 112, 0, 0, 0, 0, 0, 0 BUF TRIE: 144, 0, 0, 105948, 0, 0, 0 NAMEI: 1024, 0, 0, 104, 908, 0, 0 S VFS Cache: 108, 0, 248, 767, 294, 0, 0 STS VFS Cache: 148, 0, 0, 0, 0, 0, 0 L VFS Cache: 328, 0, 0, 0, 0, 0, 0 LTS VFS Cache: 368, 0, 0, 0, 0, 0, 0 NCLNODE: 528, 0, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 0, 0, 0, 0, 0 reference_cache: 40, 0, 0, 0, 0, 0, 0 reference_history_cache: 8, 0, 0, 0, 0, 0, 0 range_seg_cache: 64, 0, 9978, 934, 10433, 0, 0 zio_cache: 920, 0, 6, 814, 12019, 0, 0 zio_link_cache: 48, 0, 3, 1408, 7868, 0, 0 zio_buf_512: 512, 0, 590, 166, 1077, 0, 0 zio_data_buf_512: 512, 0, 54, 65, 56, 0, 0 zio_buf_1024: 1024, 0, 22, 58, 61, 0, 0 zio_data_buf_1024: 1024, 0, 40, 40, 40, 0, 0 zio_buf_1536: 1536, 0, 22, 24, 24, 0, 0 zio_data_buf_1536: 1536, 0, 23, 13, 23, 0, 0 zio_buf_2048: 2048, 0, 35, 25, 64, 0, 0 zio_data_buf_2048: 2048, 0, 14, 12, 15, 0, 0 zio_buf_2560: 2560, 0, 0, 15, 27, 0, 0 zio_data_buf_2560: 2560, 0, 17, 4, 17, 0, 0 zio_buf_3072: 3072, 0, 2, 4, 2, 0, 0 zio_data_buf_3072: 3072, 0, 8, 4, 8, 0, 0 zio_buf_3584: 3584, 0, 1, 0, 1, 0, 0 zio_data_buf_3584: 3584, 0, 2, 0, 2, 0, 0 zio_buf_4096: 4096, 0, 49, 706, 3790, 0, 0 zio_data_buf_4096: 4096, 0, 0, 24, 25, 0, 0 zio_buf_5120: 5120, 0, 1, 0, 1, 0, 0 zio_data_buf_5120: 5120, 0, 4, 0, 4, 0, 0 zio_buf_6144: 6144, 0, 1, 0, 1, 0, 0 zio_data_buf_6144: 6144, 0, 3, 0, 3, 0, 0 zio_buf_7168: 7168, 0, 0, 0, 0, 0, 0 zio_data_buf_7168: 7168, 0, 1, 0, 1, 0, 0 zio_buf_8192: 8192, 0, 1, 13, 187, 0, 0 zio_data_buf_8192: 8192, 0, 2, 1, 4, 0, 0 zio_buf_10240: 10240, 0, 1, 0, 1, 0, 0 zio_data_buf_10240: 10240, 0, 1, 0, 1, 0, 0 zio_buf_12288: 12288, 0, 1, 8, 45, 0, 0 zio_data_buf_12288: 12288, 0, 4, 0, 4, 0, 0 zio_buf_14336: 14336, 0, 0, 0, 0, 0, 0 zio_data_buf_14336: 14336, 0, 1, 0, 1, 0, 0 zio_buf_16384: 16384, 0, 398, 23, 543, 0, 0 zio_data_buf_16384: 16384, 0, 2, 0, 2, 0, 0 zio_buf_20480: 20480, 0, 0, 5, 19, 0, 0 zio_data_buf_20480: 20480, 0, 3, 0, 3, 0, 0 zio_buf_24576: 24576, 0, 0, 9, 16, 0, 0 zio_data_buf_24576: 24576, 0, 5, 0, 5, 0, 0 zio_buf_28672: 28672, 0, 0, 14, 83, 0, 0 zio_data_buf_28672: 28672, 0, 4, 0, 4, 0, 0 zio_buf_32768: 32768, 0, 0, 2, 3, 0, 0 zio_data_buf_32768: 32768, 0, 2, 0, 2, 0, 0 zio_buf_36864: 36864, 0, 1, 5, 8, 0, 0 zio_data_buf_36864: 36864, 0, 1, 2, 3, 0, 0 zio_buf_40960: 40960, 0, 0, 3, 3, 0, 0 zio_data_buf_40960: 40960, 0, 2, 0, 2, 0, 0 zio_buf_45056: 45056, 0, 0, 1, 1, 0, 0 zio_data_buf_45056: 45056, 0, 1, 0, 1, 0, 0 zio_buf_49152: 49152, 0, 0, 0, 0, 0, 0 zio_data_buf_49152: 49152, 0, 0, 0, 0, 0, 0 zio_buf_53248: 53248, 0, 0, 1, 1, 0, 0 zio_data_buf_53248: 53248, 0, 1, 0, 1, 0, 0 zio_buf_57344: 57344, 0, 0, 0, 0, 0, 0 zio_data_buf_57344: 57344, 0, 0, 0, 0, 0, 0 zio_buf_61440: 61440, 0, 0, 0, 0, 0, 0 zio_data_buf_61440: 61440, 0, 0, 0, 0, 0, 0 zio_buf_65536: 65536, 0, 0, 0, 0, 0, 0 zio_data_buf_65536: 65536, 0, 0, 0, 0, 0, 0 zio_buf_69632: 69632, 0, 0, 2, 2, 0, 0 zio_data_buf_69632: 69632, 0, 2, 0, 2, 0, 0 zio_buf_73728: 73728, 0, 0, 1, 1, 0, 0 zio_data_buf_73728: 73728, 0, 1, 0, 1, 0, 0 zio_buf_77824: 77824, 0, 0, 0, 0, 0, 0 zio_data_buf_77824: 77824, 0, 0, 0, 0, 0, 0 zio_buf_81920: 81920, 0, 0, 0, 0, 0, 0 zio_data_buf_81920: 81920, 0, 1, 0, 1, 0, 0 zio_buf_86016: 86016, 0, 0, 0, 0, 0, 0 zio_data_buf_86016: 86016, 0, 0, 0, 0, 0, 0 zio_buf_90112: 90112, 0, 0, 2, 2, 0, 0 zio_data_buf_90112: 90112, 0, 0, 1, 1, 0, 0 zio_buf_94208: 94208, 0, 0, 0, 0, 0, 0 zio_data_buf_94208: 94208, 0, 0, 0, 0, 0, 0 zio_buf_98304: 98304, 0, 1, 1, 2, 0, 0 zio_data_buf_98304: 98304, 0, 1, 0, 1, 0, 0 zio_buf_102400: 102400, 0, 0, 0, 0, 0, 0 zio_data_buf_102400: 102400, 0, 0, 0, 0, 0, 0 zio_buf_106496: 106496, 0, 0, 0, 0, 0, 0 zio_data_buf_106496: 106496, 0, 0, 0, 0, 0, 0 zio_buf_110592: 110592, 0, 0, 1, 1, 0, 0 zio_data_buf_110592: 110592, 0, 1, 0, 1, 0, 0 zio_buf_114688: 114688, 0, 0, 3, 14, 0, 0 zio_data_buf_114688: 114688, 0, 0, 0, 0, 0, 0 zio_buf_118784: 118784, 0, 0, 0, 0, 0, 0 zio_data_buf_118784: 118784, 0, 0, 0, 0, 0, 0 zio_buf_122880: 122880, 0, 0, 0, 0, 0, 0 zio_data_buf_122880: 122880, 0, 0, 0, 0, 0, 0 zio_buf_126976: 126976, 0, 0, 0, 0, 0, 0 zio_data_buf_126976: 126976, 0, 0, 0, 0, 0, 0 zio_buf_131072: 131072, 0, 1, 11, 61, 0, 0 zio_data_buf_131072: 131072, 0, 39, 5, 48, 0, 0 lz4_ctx: 16384, 0, 0, 0, 0, 0, 0 sa_cache: 80, 0, 272, 757, 272, 0, 0 dnode_t: 1096, 0, 746, 37, 1863, 0, 0 dmu_buf_impl_t: 336, 0, 1270, 127, 1729, 0, 0 arc_buf_hdr_t: 328, 0, 881, 163, 1332, 0, 0 arc_buf_t: 72, 0, 880, 770, 1359, 0, 0 zil_lwb_cache: 192, 0, 0, 0, 0, 0, 0 zfs_znode_cache: 368, 0, 272, 138, 272, 0, 0 pipe: 744, 0, 0, 40, 13, 0, 0 Mountpoints: 816, 0, 24, 41, 24, 0, 0 procdesc: 128, 0, 0, 0, 0, 0, 0 ksiginfo: 112, 0, 26, 1024, 26, 0, 0 itimer: 352, 0, 0, 0, 0, 0, 0 KNOTE: 128, 0, 0, 0, 0, 0, 0 socket: 696, 2062880, 0, 0, 0, 0, 0 ipq: 56, 125599, 0, 0, 0, 0, 0 udp_inpcb: 392, 2062880, 0, 0, 0, 0, 0 udpcb: 16, 2062965, 0, 0, 0, 0, 0 tcp_inpcb: 392, 2062880, 0, 0, 0, 0, 0 tcpcb: 1024, 2062880, 0, 0, 0, 0, 0 tcptw: 88, 27810, 0, 0, 0, 0, 0 syncache: 160, 15360, 0, 0, 0, 0, 0 hostcache: 136, 15370, 0, 0, 0, 0, 0 tcpreass: 40, 251262, 0, 0, 0, 0, 0 sackhole: 32, 0, 0, 0, 0, 0, 0 sctp_ep: 1408, 2062880, 0, 0, 0, 0, 0 sctp_asoc: 2352, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80012, 0, 0, 0, 0, 0 sctp_raddr: 728, 80000, 0, 0, 0, 0, 0 sctp_chunk: 136, 400026, 0, 0, 0, 0, 0 sctp_readq: 104, 400026, 0, 0, 0, 0, 0 sctp_stream_msg_out: 104, 400026, 0, 0, 0, 0, 0 sctp_asconf: 40, 400059, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400060, 0, 0, 0, 0, 0 ripcb: 392, 2062880, 0, 0, 0, 0, 0 unpcb: 240, 2062880, 0, 0, 0, 0, 0 rtentry: 200, 0, 0, 0, 0, 0, 0 selfd: 56, 0, 0, 0, 0, 0, 0 SWAPMETA: 288, 8037731, 0, 0, 0, 0, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq6: fdc0 22 0 irq14: ata0 55 0 irq17: uhci0 ehci0 55 0 irq18: uhci2+ 304 0 irq19: uhci1 ahci0+ 5075 13 cpu0:timer 2410 6 irq259: hdac0 9 0 cpu6:timer 442 1 cpu1:timer 404 1 cpu2:timer 482 1 cpu7:timer 548 1 cpu5:timer 477 1 cpu4:timer 484 1 cpu3:timer 765 2 Total 11532 31 ------------------------------------------------------------------------ pstat -T 8/2062880 files 0M/147455M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/#C:0xc0 50331392 0 50331392 0% /dev/ad14p2 50331392 0 50331392 0% /dev/usb/3.2.1 50331392 0 50331392 0% /dev/#C:0xd0 50331392 0 50331392 0% /dev/#C:0xd8 50331392 0 50331392 0% /dev/#C:0xe0 50331392 0 50331392 0% Total 301988352 0 301988352 0% ------------------------------------------------------------------------ iostat tty ada0 ada1 ada2 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 15 15.18 60 0.89 15.40 65 0.98 14.86 63 0.91 0 0 2 1 97 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) shminfo: shmmax: 536870912 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 131072 (max amount of shared memory in pages) seminfo: semmni: 50 (# of semaphore identifiers) semmns: 340 (# of semaphores in system) semmnu: 150 (# of undo structures in system) semmsl: 340 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 50 (max # of undo entries per process) semusz: 632 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat Client Info: Rpc Counts: Getattr Setattr Lookup Readlink Read Write Create Remove 2 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 1 1 0 0 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 0 0 4 Cache Info: Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Misses 0 0 0 0 0 0 0 0 BioRLHits Misses BioD Hits Misses DirE Hits Misses Accs Hits Misses 0 0 0 0 0 0 0 0 Server Info: Getattr Setattr Lookup Readlink Read Write Create Remove 0 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Server Ret-Failed 0 Server Faults 0 Server Cache Stats: Inprog Idem Non-idem Misses 0 0 0 0 Server Write Gathering: WriteOps WriteRPC Opsaved 0 0 0 ------------------------------------------------------------------------ netstat -s tcp: 0 packets sent 0 data packets (0 bytes) 0 data packets (0 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 0 ack-only packets (0 delayed) 0 URG only packets 0 window probe packets 0 window update packets 0 control packets 0 packets received 0 acks (for 0 bytes) 0 duplicate acks 0 acks for unsent data 0 packets (0 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 0 connection requests 0 connection accepts 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 0 connections established (including accepts) 0 connections closed (including 0 drops) 0 connections updated cached RTT on close 0 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 0 segments updated rtt (of 0 attempts) 0 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 0 correct ACK header predictions 0 correct data packet header predictions 0 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 0 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 0 cookies sent 0 cookies received 0 hostcache entries added 0 bucket overflow 0 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 0 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 0 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 0 dropped due to no socket 0 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 0 delivered 0 datagrams output 0 times multicast source filter matched ip: 0 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 0 packets for this host 0 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 0 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 0 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 0 calls to icmp_error 0 errors not generated in response to an icmp message 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored 0 message responses generated 0 invalid return addresses 0 no return routes igmp: 0 messages received 0 messages received with too few bytes 0 messages received with wrong TTL 0 messages received with bad checksum 0 V1/V2 membership queries received 0 V3 membership queries received 0 membership queries received with invalid field(s) 0 general queries received 0 group queries received 0 group-source queries received 0 group-source queries dropped 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 V3 reports received without Router Alert 0 membership reports sent arp: 0 ARP requests sent 0 ARP replies sent 0 ARP requests received 0 ARP replies received 0 ARP packets received 0 total packets dropped due to no ARP entry 0 ARP entrys timed out 0 Duplicate IPs seen ip6: 0 total packets received 0 with size smaller than minimum 0 with data size < data length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 fragments that exceeded limit 0 packets reassembled ok 0 packets for this host 0 packets forwarded 0 packets not forwardable 0 redirects sent 0 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 packets that violated scope rules 0 multicast packets which we don't join Mbuf statistics: 0 one mbuf 0 one ext mbuf 0 two or more ext mbuf 0 packets whose headers are not contiguous 0 tunneling packets that can't find gif 0 packets discarded because of too many headers 0 failures of source address selection Source addresses selection rule applied: icmp6: 0 calls to icmp6_error 0 errors not generated in response to an icmp6 message 0 errors not generated because of rate limitation 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Histogram of error messages to be generated: 0 no route 0 administratively prohibited 0 beyond scope 0 address unreachable 0 port unreachable 0 packet too big 0 time exceed transit 0 time exceed reassembly 0 erroneous header field 0 unrecognized next header 0 unrecognized option 0 redirect 0 unknown 0 message responses generated 0 messages with too many ND options 0 messages with bad ND options 0 bad neighbor solicitation messages 0 bad neighbor advertisement messages 0 bad router solicitation messages 0 bad router advertisement messages 0 bad redirect messages 0 path MTU changes rip6: 0 messages received 0 checksum calculations on inbound 0 messages with bad checksum 0 messages dropped due to no socket 0 multicast messages dropped due to no socket 0 messages dropped due to full socket buffers 0 delivered 0 datagrams output ------------------------------------------------------------------------ netstat -m netstat: invalid address (0x0) 1/144/145 mbufs in use (current/cache/total) 18446744073709551606/10/0/4018860 mbuf clusters in use (current/cache/total/max) 0/10 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/2009429 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/1786158 9k jumbo clusters in use (current/cache/total/max) 0/0/0/1339616 16k jumbo clusters in use (current/cache/total/max) 18014398509481964K/56K/36K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) ------------------------------------------------------------------------ netstat -anr Routing tables Internet: Destination Gateway Flags Netif Expire Internet6: Destination Gateway Flags Netif Expire ------------------------------------------------------------------------ netstat -anA ------------------------------------------------------------------------ netstat -aL ------------------------------------------------------------------------ fstat fstat: can't read file 1 at 0x200007fffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 7 at 0x200007fffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x200007fffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 7 at 0x200007fffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x200007fffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 7 at 0x200007fffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root zfs 75 root - - error - root zfs 75 wd - - error - root zfs 75 text - - error - root zfs 75 ctty /dev 13 crw------- console rw root zfs 75 0 /dev 13 crw------- console rw root zfs 75 6 /dev 13 crw------- console rw root sh 72 root - - error - root sh 72 wd - - error - root sh 72 text - - error - root sh 72 ctty /dev 13 crw------- console rw root sh 72 0 /dev 13 crw------- console rw root sh 72 6 /dev 13 crw------- console rw root sh 24 root - - error - root sh 24 wd - - error - root sh 24 text - - error - root sh 24 ctty /dev 13 crw------- console rw root sh 24 0 /dev 13 crw------- console rw root sh 24 6 /dev 13 crw------- console rw root init 1 root - - error - root init 1 wd - - error - root init 1 text - - error - root kernel 0 root - - error - root kernel 0 wd - - error - ------------------------------------------------------------------------ dmesg Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #1 r260896: Mon Jan 20 12:31:46 CST 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 info: [drm] Initialized drm 1.1.0 20060810 CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (2327.55-MHz K8-class CPU) Origin="GenuineIntel" Id=0x10676 Family=0x6 Model=0x17 Stepping=6 Features=0xbfebfbff Features2=0xce3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 68719476736 (65536 MB) avail memory = 65641644032 (62600 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard random: initialized kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) unknown: I/O range not supported cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 350 Event timer "HPET1" frequency 14318180 Hz quality 340 Event timer "HPET2" frequency 14318180 Hz quality 340 atrtc0: port 0x70-0x71 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 pcib5: at device 0.2 on pci3 pci5: on pcib5 pcib6: irq 18 at device 2.0 on pci2 pci6: on pcib6 em0: port 0x2000-0x201f mem 0xd9220000-0xd923ffff,0xd9200000-0xd921ffff irq 18 at device 0.0 on pci6 em0: Using an MSI interrupt em0: Ethernet address: 00:30:48:f2:29:9c em1: port 0x2020-0x203f mem 0xd9260000-0xd927ffff,0xd9240000-0xd925ffff irq 19 at device 0.1 on pci6 em1: Using an MSI interrupt em1: Ethernet address: 00:30:48:f2:29:9d pcib7: at device 0.3 on pci1 pci7: on pcib7 pcib8: at device 4.0 on pci0 pci8: on pcib8 vgapci0: port 0x3000-0x307f mem 0xd8000000-0xd8ffffff,0xc0000000-0xc7ffffff,0xc8000000-0xc9ffffff irq 16 at device 0.0 on pci8 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io hdac0: mem 0xd9000000-0xd9003fff irq 17 at device 0.1 on pci8 pcib9: at device 6.0 on pci0 pci9: on pcib9 pci0: at device 8.0 (no driver attached) pcib10: irq 17 at device 28.0 on pci0 pci10: on pcib10 pcib11: irq 16 at device 0.0 on pci10 pci11: on pcib11 pcm0: port 0x4080-0x409f,0x4000-0x407f irq 16 at device 0.0 on pci11 pcm0: system configuration SubVendorID: 0x1412, SubDeviceID: 0x2403 XIN2 Clock Source: 24.576MHz(96kHz*256) MPU-401 UART(s) #: not implemented ADC #: 1 and SPDIF receiver connected DAC #: 4 Multi-track converter type: AC'97(SDATA_OUT:packed) S/PDIF(IN/OUT): 1/1 ID# 0x00 GPIO(mask/dir/state): 0xff/0xff/0xff uhci0: port 0x1800-0x181f irq 17 at device 29.0 on pci0 usbus0 on uhci0 uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 usbus1 on uhci1 uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 usbus2 on uhci2 ehci0: mem 0xd9600400-0xd96007ff irq 17 at device 29.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib12: at device 30.0 on pci0 pci12: on pcib12 vgapci1: port 0x5000-0x50ff mem 0xd0000000-0xd7ffffff,0xd9300000-0xd930ffff irq 18 at device 1.0 on pci12 drmn1: on vgapci1 info: [drm] RADEON_IS_PCI info: [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080). info: [drm] register mmio base: 0xD9300000 info: [drm] register mmio size: 65536 info: [drm] radeon_atrm_get_bios: ===> Try ATRM... info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:8:0:0, vendor=10de, device=104a info: [drm] radeon_atrm_get_bios: Get ACPI device handle info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0xd0000000 info: [drm] igp_read_bios_from_vram: Map address: 0xfffff800d0000000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x0000 info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] radeon_read_bios: Map address: 0xfffff800000c0000 (131072 bytes) drmn1: info: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used) drmn1: info: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] radeon: irq initialized. info: [drm] Detected VRAM RAM=128M, BAR=128M info: [drm] RAM width 64bits SDR [TTM] Zone kernel: Available graphics memory: 33006090 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator info: [drm] radeon: 16M of VRAM memory ready info: [drm] radeon: 512M of GTT memory ready. info: [drm] GART: num cpu pages 131072, num gpu pages 131072 info: [drm] PCI GART of 512M enabled (table at 0x0000000011200000). drmn1: info: WB disabled drmn1: info: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0x0xfffff8001083c000 info: [drm] Loading R100 Microcode info: [drm] radeon: ring at 0x00000000B0001000 info: [drm] ring test succeeded in 1 usecs info: [drm] ib test succeeded in 0 usecs info: [drm] radeon_device_init: Taking over the fictitious range 0xd0000000-0xd4000000 iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iicbus1: on iicbb1 addr 0xff iic1: on iicbus1 iicbus2: on iicbb2 addr 0xff iic2: on iicbus2 iicbus3: on iicbb3 addr 0xff iic3: on iicbus3 info: [drm] Radeon Display Connectors info: [drm] Connector 0: info: [drm] VGA-1 info: [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60 info: [drm] Encoders: info: [drm] CRT1: INTERNAL_DAC1 info: [drm] Connector 1: info: [drm] DVI-I-1 info: [drm] HPD2 info: [drm] DDC: 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c info: [drm] Encoders: info: [drm] CRT2: INTERNAL_DAC2 info: [drm] DFP2: INTERNAL_DVO1 composite sync not supported composite sync not supported info: [drm] fb mappable at 0xD0040000 info: [drm] vram apper at 0xD0000000 info: [drm] size 2076672 info: [drm] fb depth is 8 info: [drm] pitch is 1920 fbd1 on drmn1 vt_allocate: Replace existing VT driver. info: [drm] Initialized radeon 2.29.0 20080528 vgapci1: Boot video device isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: at channel 0 on atapci0 ahci0: port 0x18a0-0x18a7,0x1874-0x1877,0x1878-0x187f,0x1870-0x1873,0x1880-0x189f mem 0xd9600800-0xd9600bff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ichsmb0: port 0x1100-0x111f irq 19 at device 31.3 on pci0 smbus0: on ichsmb0 acpi_button0: on acpi0 ipmi0: port 0xca2-0xca3 on acpi0 ipmi0: KCS mode found at io 0xca2 on acpi atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ichwd0 on isa0 orm0: at iomem 0xc0000-0xcafff on isa0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 coretemp4: on cpu4 est4: on cpu4 p4tcc4: on cpu4 coretemp5: on cpu5 est5: on cpu5 p4tcc5: on cpu5 coretemp6: on cpu6 est6: on cpu6 p4tcc6: on cpu6 coretemp7: on cpu7 est7: on cpu7 p4tcc7: on cpu7 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x387 offMax=0x491 hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm1: at nid 4 on hdaa0 pcm2: at nid 5 on hdaa0 random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen3.1: at usbus3 uhub0: on usbus3 ugen2.1: at usbus2 uhub1: on usbus2 ugen1.1: at usbus1 uhub2: on usbus1 ugen0.1: at usbus0 uhub3: on usbus0 ipmi0: IPMI device rev. 1, firmware rev. 1.64, version 2.0 ata0: DMA limited to UDMA33, controller found non-ATA66 cable ipmi0: Number of channels 8 ipmi0: Attached watchdog uhub2: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: Serial Number 5YDA1ZL4 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus2 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: Serial Number 5YD6FPLG ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada1: quirks=0x1<4K> ada1: Previously was known as ad6 ada2 at ahcich2 bus 0 scbus3 target 0 lun 0 ada2: ATA-8 SATA 3.x device ada2: Serial Number 5YDA3PC5 ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada2: quirks=0x1<4K> ada2: Previously was known as ad8 ada3 at ahcich3 bus 0 scbus4 target 0 lun 0 ada3: ATA-8 SATA 3.x device ada3: Serial Number 5YD9Y0P4 ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3: quirks=0x1<4K> ada3: Previously was known as ad10 ada4 at ahcich4 bus 0 scbus5 target 0 lun 0 ada4: ATA-8 SATA 3.x device ada4: Serial Number 5YDA1R5W ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada4: quirks=0x1<4K> ada4: Previously was known as ad12 ada5 at ahcich5 bus 0 scbus6 target 0 lun 0 ada5: ATA-8 SATA 3.x device ada5: Serial Number 5YD5RBS8 ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada5: quirks=0x1<4K> ada5: Previously was known as ad14 cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present Netvsc initializing... done! SMP: AP CPU #6 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #3 Launched! Root mount waiting for: usbus3 uhub0: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 Root mount waiting for: usbus3 ugen3.2: at usbus3 ukbd0: on usbus3 kbd2 at ukbd0 Trying to mount root from zfs:zroot/ROOT/default []... ugen0.2: at usbus0 ugen1.2: at usbus1 Setting hostuuid: 53d19f64-d663-a017-8922-0030488e9ff3. Setting hostid: 0xf53a926e. Entropy harvesting: interrupts ethernet point_to_point swi. Starting file system checks: Mounting local file systems:. panic: solaris assert: l->l_phys->l_hdr.lh_block_type == ((1ULL << 63) + 0) (0x0 == 0x8000000000000000), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c, line: 534 cpuid = 7 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe100c499090 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe100c499140 vpanic() at vpanic+0x126/frame 0xfffffe100c499180 panic() at panic+0x43/frame 0xfffffe100c4991e0 assfail3() at assfail3+0x2f/frame 0xfffffe100c499200 zap_get_leaf_byblk() at zap_get_leaf_byblk+0x4e1/frame 0xfffffe100c499250 zap_deref_leaf() at zap_deref_leaf+0xd1/frame 0xfffffe100c4992a0 fzap_cursor_retrieve() at fzap_cursor_retrieve+0xce/frame 0xfffffe100c499310 zap_cursor_retrieve() at zap_cursor_retrieve+0x20a/frame 0xfffffe100c499390 ddt_zap_walk() at ddt_zap_walk+0x5e/frame 0xfffffe100c499650 ddt_walk() at ddt_walk+0x78/frame 0xfffffe100c499680 dsl_scan_sync() at dsl_scan_sync+0x6ec/frame 0xfffffe100c4999e0 spa_sync() at spa_sync+0x5c4/frame 0xfffffe100c499ad0 txg_sync_thread() at txg_sync_thread+0x256/frame 0xfffffe100c499bb0 fork_exit() at fork_exit+0x84/frame 0xfffffe100c499bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe100c499bf0 --- trap 0, rip = 0, rsp = 0xfffffe100c499cb0, rbp = 0 --- KDB: enter: panic Uptime: 14s Dumping 2263 out of 64465 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% ------------------------------------------------------------------------ kernel config options CONFIG_AUTOGENERATED ident VT-LER machine amd64 cpu HAMMER makeoptions WITH_CTF=1 makeoptions DEBUG=-g options ZFS options XENHVM options USB_DEBUG options ATH_ENABLE_11N options AH_AR5416_INTERRUPT_MITIGATION options AH_SUPPORT_AR5416 options IEEE80211_SUPPORT_MESH options IEEE80211_AMPDU_AGE options IEEE80211_DEBUG options SC_PIXEL_MODE options VESA options AHD_REG_PRETTY_PRINT options AHC_REG_PRETTY_PRINT options ATA_STATIC_ID options ACPI_DMAR options SMP options MALLOC_DEBUG_MAXZONES=8 options INVARIANT_SUPPORT options INVARIANTS options DEADLKRES options GDB options DDB options KDB_TRACE options KDB options INCLUDE_CONFIG_FILE options DDB_CTF options KDTRACE_HOOKS options KDTRACE_FRAME options MAC options CAPABILITIES options CAPABILITY_MODE options AUDIT options HWPMC_HOOKS options KBD_INSTALL_CDEV options PRINTF_BUFR_SIZE=128 options _KPOSIX_PRIORITY_SCHEDULING options SYSVSEM options SYSVMSG options SYSVSHM options STACK options KTRACE options SCSI_DELAY=5000 options COMPAT_FREEBSD7 options COMPAT_FREEBSD6 options COMPAT_FREEBSD5 options COMPAT_FREEBSD4 options COMPAT_FREEBSD32 options GEOM_LABEL options GEOM_RAID options GEOM_PART_GPT options PSEUDOFS options PROCFS options CD9660 options MSDOSFS options NFS_ROOT options NFSLOCKD options NFSD options NFSCL options MD_ROOT options QUOTA options UFS_GJOURNAL options UFS_DIRHASH options UFS_ACL options SOFTUPDATES options FFS options SCTP options TCP_OFFLOAD options INET6 options INET options PREEMPTION options SCHED_ULE options NEW_PCIB options GEOM_PART_MBR options GEOM_PART_EBR_COMPAT options GEOM_PART_EBR options GEOM_PART_BSD device isa device mem device io device uart_ns8250 device cpufreq device acpi device pci device fdc device ahci device ata device mvs device siis device ahc device ahd device esp device hptiop device isp device mpt device mps device sym device trm device adv device adw device aic device bt device isci device scbus device ch device da device sa device cd device pass device ses device amr device arcmsr device ciss device dpt device hptmv device hptnr device hptrr device hpt27xx device iir device ips device mly device twa device tws device aac device aacp device aacraid device ida device mfi device mlx device twe device atkbdc device atkbd device psm device kbdmux device splash device agp device cbb device pccard device cardbus device uart device ppc device ppbus device lpt device ppi device puc device bxe device de device em device igb device ixgbe device le device ti device txp device vx device miibus device ae device age device alc device ale device bce device bfe device bge device cas device dc device et device fxp device gem device hme device jme device lge device msk device nfe device nge device pcn device re device rl device sf device sge device sis device sk device ste device stge device tl device tx device vge device vr device wb device xl device cs device ed device ex device ep device fe device sn device xe device wlan device wlan_wep device wlan_ccmp device wlan_tkip device wlan_amrr device an device ath device ath_pci device ath_hal device ath_rate_sample device ipw device iwi device iwn device malo device mwl device ral device wi device wpi device loop device random device padlock_rng device rdrand_rng device ether device vlan device tun device md device gif device faith device firmware device bpf device uhci device ohci device ehci device xhci device usb device ukbd device umass device sound device snd_cmi device snd_csa device snd_emu10kx device snd_es137x device snd_hda device snd_ich device snd_via8233 device mmc device mmcsd device sdhci device virtio device virtio_pci device vtnet device virtio_blk device virtio_scsi device virtio_balloon device hyperv device xenpci device vmx device vt device vt_vga ------------------------------------------------------------------------ ddb capture buffer -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Wed Jan 22 19:38:44 2014 Return-Path: Delivered-To: freebsd-current@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 13A2D936 for ; Wed, 22 Jan 2014 19:38:44 +0000 (UTC) Received: from mta04.bitpro.no (mta04.bitpro.no [92.42.64.203]) by mx1.freebsd.org (Postfix) with ESMTP id C155F1AE1 for ; Wed, 22 Jan 2014 19:38:43 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta04.bitpro.no (Postfix) with ESMTPS id 68B8710058C; Wed, 22 Jan 2014 20:38:42 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 418AE1605FA; Wed, 22 Jan 2014 20:39:32 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrSTKlbBBrYT; Wed, 22 Jan 2014 20:39:31 +0100 (CET) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id F0FE91605F9; Wed, 22 Jan 2014 20:39:30 +0100 (CET) Message-ID: <52E01E80.2060008@bitfrost.no> Date: Wed, 22 Jan 2014 20:39:44 +0100 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22olivier=40cochard=2Eme_=3E=3E_Olivier_Cochard?= =?ISO-8859-1?Q?-Labb=E9=22?= , FreeBSD Current Subject: Re: Bad support of Kingston DataTraveler/DT USB key since 9.2 (not fixed in 10.0) References: <52DF9FCE.6010603@bitfrost.no> In-Reply-To: <52DF9FCE.6010603@bitfrost.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 19:38:44 -0000 On 01/22/14 11:39, Hans Petter Selasky wrote: > On 01/22/14 11:31, Olivier Cochard-Labbé wrote: >> Hi all, >> There is a regression since 9.2 (still not fixed on 10.0) regarding a >> list >> of Kingston DataTraveler/DT USB keys >> - usb/180837, regarding "Kingston DT 101 G2": This PR include a patch for >> 9.2 and a link to netbsd code that include other Kingston USB keys; >> - usb/184014, regarding "Kingston DT 100 G2" (include tips for debugging) >> - usb/185747, regarding "Kingston DT 101 G2" (duplicate PR with >> usb/180837), that include a patch for 10.0; >> - misc/185837, regarding "Kingston DataTraveler 2.0". >> >> Can someone check with the netbsd code for the full list of known buggy >> Kingston USB key and commit these quirks patches ? >> > > Hi, > > Can you make a list of VID+PID and the minimum of quirks needed. > > Many Kingston devices I've got work just fine. Maybe they are not original? > s/original/genuine BTW: What revision of FreeBSD are you seeing this? Have you updated the kernel to the latest? --HPS From owner-freebsd-current@FreeBSD.ORG Wed Jan 22 20:29:51 2014 Return-Path: Delivered-To: current@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 197997D2; Wed, 22 Jan 2014 20:29:51 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CA6191FEC; Wed, 22 Jan 2014 20:29:50 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9DD3EB964; Wed, 22 Jan 2014 15:29:49 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: possible selrecord optimization ? Date: Wed, 22 Jan 2014 14:29:56 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: In-Reply-To: X-KMail-Markup: true MIME-Version: 1.0 Message-Id: <201401221429.56745.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 22 Jan 2014 15:29:49 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Luigi Rizzo , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 20:29:51 -0000 On Tuesday, January 21, 2014 9:25:27 pm Luigi Rizzo wrote: > Looking at how selrecord() / selwakeup() and their Linux counterparts > poll_wait() and wake_up() are used, i noticed the following: > > - linux tends to call wake_up() unconditionally > at the beginning of the poll handler > > - FreeBSD tends to call selrecord() only when it detects a blocking > situation, and this also requires something (a lock or a retry; > the lock in selinfo is not good for this) to avoid the race between > the blocking_test..selrecord pair and the selwakeup(). > > FreeBSD could call selrecord unconditionally (and save the extra > lock/retry), but selrecord is expensive as it queues the thread on > the struct selinfo, and this takes a lock. > > I wonder if we could use the same optimization as Linux: > as soon as pollscan/selscan detects a non-blocking fd, > make selrecord a no-op (which is probably as simple > as setting SELTD_RESCAN; and since it only goes up > we do not need to lock to check it). Yes, I think this would work fine. I think setting SELTD_RESCAN as a way to do it is fine as well. > This way, we would pay at most for one extra selrecord per > poll/select. > > Even more interesting, it could simplify the logic and locking > in poll handlers. > > As an example, in sys/uipc_socket.c :: sopoll_generic() > we could completely decouple the locks on so_snd and so_rcv. Splitting the locks up is not really feasible because the so_rcv lock doubles as SOCK_LOCK() and is needed even in the POLLOUT case as sowritable() needs it for so_state. What you might be able to do instead is be a bit fancier and only lock so_snd if writing is being polled for by making it conditional on the values in events. This would avoid locking so_snd when just polling for read: Index: uipc_socket.c =================================================================== --- uipc_socket.c (revision 261029) +++ uipc_socket.c (working copy) @@ -2912,7 +2912,12 @@ sopoll_generic(struct socket *so, int events, stru { int revents = 0; - SOCKBUF_LOCK(&so->so_snd); + if (events & (POLLOUT | POLLWRNORM)) + SOCKBUF_LOCK(&so->so_snd); + /* + * The so_rcv lock doubles as SOCK_LOCK so it it is needed for + * all requests. + */ SOCKBUF_LOCK(&so->so_rcv); if (events & (POLLIN | POLLRDNORM)) if (soreadabledata(so)) @@ -2947,7 +2952,8 @@ sopoll_generic(struct socket *so, int events, stru } SOCKBUF_UNLOCK(&so->so_rcv); - SOCKBUF_UNLOCK(&so->so_snd); + if (events & (POLLOUT | POLLWRNORM)) + SOCKBUF_UNLOCK(&so->so_snd); return (revents); } -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jan 22 20:42:05 2014 Return-Path: Delivered-To: freebsd-current@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 57DF0EC8 for ; Wed, 22 Jan 2014 20:42:05 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 106B6118E for ; Wed, 22 Jan 2014 20:42:04 +0000 (UTC) Received: by mail-vc0-f170.google.com with SMTP id hu8so550494vcb.1 for ; Wed, 22 Jan 2014 12:42:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=rrVZSgJFkx2mamAg0xMeR7CryftCe3eS/sZKj10sBoA=; b=k1qPamA26IaxkIZ9Q7225UtOwIw1nXhmmIbl96VpHC3U4gukkVm4SHYZjGuCWrJqh3 wTgSReqgg6ZFWitFtsYBjpYVD7V1fRYZ3P9trVdgWZ6iAZdrcn6KO+GRK3tFEFVLbjKv QE17Hmv8kecCPDgj9r/Dz9yCGbOFt0BejWY0qBTdJKEQP2zn05AUsO7ncELy4Cu2zbZ+ qawwO6tiuLQVfncMxaBAXBQmB+S0jj30SLVAl/ilZ2hyZXk3B1uvCrfFvlx9U8tynZGr 0gcnCsumjl1Lz98P/k4aO1/mvfNlws05Rkdeej7TtG1RnIICR3C6Vn4yZSQM2biQlhwW FRwg== X-Received: by 10.221.51.5 with SMTP id vg5mr1327069vcb.40.1390423323997; Wed, 22 Jan 2014 12:42:03 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.171.1 with HTTP; Wed, 22 Jan 2014 12:41:43 -0800 (PST) In-Reply-To: <52E01E80.2060008@bitfrost.no> References: <52DF9FCE.6010603@bitfrost.no> <52E01E80.2060008@bitfrost.no> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Wed, 22 Jan 2014 21:41:43 +0100 X-Google-Sender-Auth: reaY2R6AD73uDFIjOpgH4MgpapI Message-ID: Subject: Re: Bad support of Kingston DataTraveler/DT USB key since 9.2 (not fixed in 10.0) To: Hans Petter Selasky Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Current , Patrick Lamaiziere X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 20:42:05 -0000 On Wed, Jan 22, 2014 at 8:39 PM, Hans Petter Selasky wrote= : > On 01/22/14 11:39, Hans Petter Selasky wrote: > >> On 01/22/14 11:31, Olivier Cochard-Labb=E9 wrote: >> >>> Hi all, >>> There is a regression since 9.2 (still not fixed on 10.0) regarding a >>> list >>> of Kingston DataTraveler/DT USB keys >>> - usb/180837, regarding "Kingston DT 101 G2": This PR include a patch f= or >>> 9.2 and a link to netbsd code that include other Kingston USB keys; >>> - usb/184014, regarding "Kingston DT 100 G2" (include tips for debuggin= g) >>> - usb/185747, regarding "Kingston DT 101 G2" (duplicate PR with >>> usb/180837), that include a patch for 10.0; >>> - misc/185837, regarding "Kingston DataTraveler 2.0". >>> >>> Can someone check with the netbsd code for the full list of known buggy >>> Kingston USB key and commit these quirks patches ? >>> >>> >> Hi, >> >> Can you make a list of VID+PID and the minimum of quirks needed. >> >> Many Kingston devices I've got work just fine. Maybe they are not >> original? >> >> > s/original/genuine > > BTW: What revision of FreeBSD are you seeing this? Have you updated the > kernel to the latest? > I've meet the problem on FreeBSD 10.0 with a Kingston DT 101 G2 (this is why I've fill the PR usb/185747), but it wasn't my key then I didn't have access to it anymore. Then the author of the PR usb/180837 confirms the problem on FreeBSD 9.2 with this same key (but he didn't have to use the same quirks on 9.2 as me on 10.0) and notice that the NetBSD quirks list include a list of Kingston DataTraveler USB keys And just after a new PR misc/185837 was created by another user=85 This why= I wonder if there is something wrong with somes of the Kingston DataTraveler. FYI, I've just ordered 3 differents Kingston Datatraveler keys for testing them: - Kingston DataTraveler SE9 - Kingston DataTraveler 100 G3 - Kingston DataTraveler i G4 8 I will test them once received. From owner-freebsd-current@FreeBSD.ORG Wed Jan 22 22:36:04 2014 Return-Path: Delivered-To: current@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 82389FFB for ; Wed, 22 Jan 2014 22:36:04 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 461A51AFC for ; Wed, 22 Jan 2014 22:36:03 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id A84567300A; Wed, 22 Jan 2014 23:38:36 +0100 (CET) Date: Wed, 22 Jan 2014 23:38:36 +0100 From: Luigi Rizzo To: current@freebsd.org Subject: any use for sys/sys/selinfo.h outside the kernel ? Message-ID: <20140122223836.GA292@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 22:36:04 -0000 Looking at sys/sys/selinfo.h i see that parts of it are in #ifdef _KERNEL ... #endif but it seems to me that also the remaining content (definition of struct selinfo) is only of use within the kernel -- or possibly to programs who want to peek into kmem. So i wonder, does it make sense to have the #ifdef _KERNEL guard at all, or should we push it to the entire content of the file ? Same goes probably for other files in sys/sys describing kernel data structures, e.g. sys/sys/socketvar.h etc. cheers luigi From owner-freebsd-current@FreeBSD.ORG Thu Jan 23 00:37:15 2014 Return-Path: Delivered-To: freebsd-current@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 BD2D54EE; Thu, 23 Jan 2014 00:37:15 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 7C9E1161B; Thu, 23 Jan 2014 00:37:15 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 25AE07300A; Thu, 23 Jan 2014 01:39:48 +0100 (CET) Date: Thu, 23 Jan 2014 01:39:48 +0100 From: Luigi Rizzo To: John Baldwin Subject: Re: possible selrecord optimization ? Message-ID: <20140123003948.GC292@onelab2.iet.unipi.it> References: <201401221429.56745.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201401221429.56745.jhb@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 00:37:15 -0000 On Wed, Jan 22, 2014 at 02:29:56PM -0500, John Baldwin wrote: > On Tuesday, January 21, 2014 9:25:27 pm Luigi Rizzo wrote: > > Looking at how selrecord() / selwakeup() and their Linux counterparts > > poll_wait() and wake_up() are used, i noticed the following: .... > > I wonder if we could use the same optimization as Linux: > > as soon as pollscan/selscan detects a non-blocking fd, > > make selrecord a no-op (which is probably as simple > > as setting SELTD_RESCAN; and since it only goes up > > we do not need to lock to check it). > > Yes, I think this would work fine. I think setting SELTD_RESCAN as a way to > do it is fine as well. excellent, thanks. I also have two related questions: 1. why isn't the struct mtx part of the struct selinfo instead of being grabbed from the mtxpool_select ? 2. am i correct that we do need to protect concurrent invocations of selrecord() on the same selinfo because mtx_pool_find() return the same mutex for a given struct selinfo ? In case, any objections if i add some comments to the code to explain the above ? cheers luigi From owner-freebsd-current@FreeBSD.ORG Thu Jan 23 04:10:59 2014 Return-Path: Delivered-To: freebsd-current@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 7BDCC15A for ; Thu, 23 Jan 2014 04:10:59 +0000 (UTC) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 19785186A for ; Thu, 23 Jan 2014 04:10:58 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id w62so723612wes.10 for ; Wed, 22 Jan 2014 20:10:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Vyg3po3HKHrvNBCCq/cNZRuqqCSTrHa2DA3aiDm7cA0=; b=hgbPe1jZcvl+08SuujWSaMgo3XI+SYf27LbnOwsvfSsYGr13PdxonZRPTu55JttQ7I P0aBzcx9G/4guIB9sCdfnPCO5x8Gk0UNktIN/DZ1h6f9WmIvY1aKEypE5kOEmnGXKBeC t09t0XY6oNkTZ3J/Eq4KBVvE2e6Bm+by6S0nJDNG0Im84SidsNq1e9TtcD6xn3H+yu3Y MBPQIR0myO9D/5qNbTYiCj3/sn/Z0P1SXr7JbDzlyuv3P694Dtk+F44D8MVtNEO8VfHv Gm89d4olxhpHmfTrrGH1KuOxZAUx8HKnXpwFYxbhksrttIEnZwMiTXRrfdQUV0JZIWPW aBzw== X-Received: by 10.180.211.68 with SMTP id na4mr23123716wic.0.1390450257402; Wed, 22 Jan 2014 20:10:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.240.135 with HTTP; Wed, 22 Jan 2014 20:10:37 -0800 (PST) From: Miguel Clara Date: Thu, 23 Jan 2014 04:10:37 +0000 Message-ID: Subject: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 04:10:59 -0000 Getting a panic: Unregistered use of FPU in kernel There seems to be a patch for FreeBSD 10, but not sure if it wold apply http://www.freebsd.org/cgi/query-pr.cgi?pr=165622&sourceid=opensearch Thanks From owner-freebsd-current@FreeBSD.ORG Thu Jan 23 04:50:00 2014 Return-Path: Delivered-To: freebsd-current@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 2DBAFEEB; Thu, 23 Jan 2014 04:50:00 +0000 (UTC) Received: from smtpin1.utoledo.edu (smtpin1.utoledo.edu [131.183.2.213]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 958651B78; Thu, 23 Jan 2014 04:49:59 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUBAEKe4FKDtwIWl2dsb2JhbABbg0RWgn66BxYOAQEBAQEIFgc8gk8VGzsgAgUWCwILAwIBAgFLAQwIAQEFh3wFCKg+lx2EfxeBKYEzi16DOIFJBIlHkA2FFY1AgVyBTEA X-IronPort-AV: E=Sophos;i="4.95,704,1384318800"; d="scan'208";a="308139471" Received: from dlpint00.utoledo.edu ([131.183.2.22]) by smtpin1.utoledo.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jan 2014 23:49:58 -0500 Received: from MSGAPP12.utad.utoledo.edu (msgapp12.utad.utoledo.edu [131.183.3.8]) by dlpint00.utoledo.edu (RSA Interceptor); Wed, 22 Jan 2014 23:49:46 -0500 Received: from [192.168.1.79] (76.238.196.183) by Email.Utoledo.Edu (131.183.3.18) with Microsoft SMTP Server (TLS) id 14.3.169.1; Wed, 22 Jan 2014 23:49:46 -0500 Message-ID: <52E09F68.8020804@UToledo.edu> Date: Wed, 22 Jan 2014 23:49:44 -0500 From: Robert Burmeister User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: , Subject: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release. X-Priority: 1 (Highest) Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [76.238.196.183] X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Mailman-Approved-At: Thu, 23 Jan 2014 05:04:21 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 04:50:00 -0000 Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release. A) Clang is needed to compile FreeBSD 10 due to use of the updated libstdc++ in world. My workaround was to upgrade FreeBSD 9.2 to Clang 3.3 in the base system and remove GCC 4.2.1 from base 9.2. This was accomplished by using /etc/src.conf flags WITH_CLANG=yes WITH_LIBCPLUSPLUS=yes WITH_CLANG_EXTRAS=yes WITH_CLANG_IS_CC=yes WITHOUT_GCC=yes and recompiling world and FreeBSD as per http://www.freebsd.org/doc/handbook/makeworld.html B) FreeBSD 10's change to pkg(8) (a.k.a. PKGNG) affects the portupgrade tools as well as the package tools. Even if you are not using packages, before upgrading to FreeBSD 10 install pkg(8) as described in: http://www5.us.freebsd.org/doc/handbook/pkgng-intro.html and be sure to run pkg2ng. C) FreeBSD 10 moves converters/libiconv into the base system, which directly or indirectly affects many ports. This migration has largely been taken care of for the official packages, however, if you are rebuilding from the ports tree "pkg_delete libiconv" must be run, or converters/libiconv must be deinstalled, before your post OS recompile of all your ports. Most of the iconv hardcodes have been addressed in the ports tree, but this is still being worked on. I have suggested that this information be noted in the FreeBSD 10 release notes. From owner-freebsd-current@FreeBSD.ORG Thu Jan 23 07:21:53 2014 Return-Path: Delivered-To: freebsd-current@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 4C7F410F for ; Thu, 23 Jan 2014 07:21:53 +0000 (UTC) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0BB471A42 for ; Thu, 23 Jan 2014 07:21:52 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id ii20so1729881qab.19 for ; Wed, 22 Jan 2014 23:21:52 -0800 (PST) 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=iUPNbeLhbqQO/1ehbUnHMbZVUZHAOyvJGYNw3bWqU24=; b=hVHPPs5VwGJNaJoGAgtEzKCftpO6gLd2wYra3kw2dJ5R2cTSvj+hvJCFAcOQoaVQWY Y7YUPGq8cFYe4m+TZnFwJkiElZIUqHAB9sjYgHo6LH3JZ/vAvv9wvuFUqCR2L6qL3TwV qu84CabGnSbk1b1lORu5X0n/tuDQCeUBsd7DzTiAAiNyvosQU5zlopOKSoz0JNCrqhYl olWR81dv4sTfw88R68+ZrVRD4EE+2Oxs0S8PHiNf4WNrT+E8eHyO57B4+owBb3d62Zwv M63utXvzBesgQNYkaebvuZjSYJ0SNQBxSjfcipD2gbfoEvIwY32qFGZAEvVW0m6n+AVU hjgQ== MIME-Version: 1.0 X-Received: by 10.140.24.71 with SMTP id 65mr8804313qgq.12.1390461712225; Wed, 22 Jan 2014 23:21:52 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Wed, 22 Jan 2014 23:21:52 -0800 (PST) In-Reply-To: References: Date: Wed, 22 Jan 2014 23:21:52 -0800 X-Google-Sender-Auth: xfbpFVf7XHGjU5E9V7T8P1ZnOpk Message-ID: Subject: Re: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC From: Adrian Chadd To: Miguel Clara Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 07:21:53 -0000 It's actually fpu code in ndis drivers. I'm going to deprecate NDIS this year, so .. OTOH, the FPU save support would be cool. -a On 22 January 2014 20:10, Miguel Clara wrote: > Getting a panic: Unregistered use of FPU in kernel > > > There seems to be a patch for FreeBSD 10, but not sure if it wold apply > > http://www.freebsd.org/cgi/query-pr.cgi?pr=165622&sourceid=opensearch > > > Thanks > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Jan 23 09:39:51 2014 Return-Path: Delivered-To: freebsd-current@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 F0168D6A; Thu, 23 Jan 2014 09:39:50 +0000 (UTC) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 550D217C6; Thu, 23 Jan 2014 09:39:50 +0000 (UTC) Received: by mail-bk0-f45.google.com with SMTP id v16so265662bkz.32 for ; Thu, 23 Jan 2014 01:39:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:in-reply-to:references:mime-version:content-type:subject :from:date:to:cc:message-id; bh=JkmqaWq3ZVJI24rvK+nmrLJ/NoAkWuPYyG7osLupCQQ=; b=acHQIH1PmmAteqX23OmOtPmosxZ6fO2vGhjopbLXpt/6eV6sXn700T3TtoNKaXTcIW EWxf9TEadpR15EJ0xi5k40aRxU1n7vBX3QgDNMpp3NjH7+LmLluVwxHJS/SOdGomnQPn YjZUruZ48unM2f0bBMrOEbW9XSNzoV+AyDDh6fmtQ93HjkdFjb647EwFQLh8VhDFt4+W kB2J/7wUnz43rgSmOOd3DX1yMSbrC9w6yzvBcamHBceLM/5pQpawPpq0FskF9ltO2RwA iPpeOTJgd+rzxbHEbHBmKwQlB+dWOXpuK4CrK7PeDsEyqzGawXMqTQAQWMOSrjiIoRTi yNlg== X-Received: by 10.205.97.69 with SMTP id cj5mr6385bkc.132.1390469988578; Thu, 23 Jan 2014 01:39:48 -0800 (PST) Received: from ?IPV6:2001:470:7b2f:0:2c0f:597c:387d:c2a2? ([2001:470:7b2f:0:2c0f:597c:387d:c2a2]) by mx.google.com with ESMTPSA id q5sm8630142bkr.5.2014.01.23.01.39.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Jan 2014 01:39:47 -0800 (PST) User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Subject: Re: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC From: "Mike C." Date: Thu, 23 Jan 2014 09:39:42 +0000 To: Adrian Chadd Message-ID: <9ec5437a-eb1f-4ed0-809d-7fd41cdcd4df@email.android.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 09:39:51 -0000 hum... the driver I need is for broadcom 4313 wireless, It seems the modules available don't work for that one... wonder of they ever will? I would definitely prefer that to using ndis. Adrian Chadd wrote: >It's actually fpu code in ndis drivers. I'm going to deprecate NDIS >this year, so .. > >OTOH, the FPU save support would be cool. > > >-a > > >On 22 January 2014 20:10, Miguel Clara wrote: >> Getting a panic: Unregistered use of FPU in kernel >> >> >> There seems to be a patch for FreeBSD 10, but not sure if it wold >apply >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=165622&sourceid=opensearch >> >> >> Thanks >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >"freebsd-current-unsubscribe@freebsd.org" -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From owner-freebsd-current@FreeBSD.ORG Thu Jan 23 14:10:31 2014 Return-Path: Delivered-To: freebsd-current@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 78A9E7B0 for ; Thu, 23 Jan 2014 14:10:31 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5A43A122D for ; Thu, 23 Jan 2014 14:10:30 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1W6KzA-0008WS-GG for freebsd-current@freebsd.org; Thu, 23 Jan 2014 06:10:24 -0800 Date: Thu, 23 Jan 2014 06:10:24 -0800 (PST) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1390486224478-5879039.post@n5.nabble.com> In-Reply-To: <52E09F68.8020804@UToledo.edu> References: <52E09F68.8020804@UToledo.edu> Subject: Re: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 14:10:31 -0000 I plan to stay some time on 9.2-STABLE (already pkgng and clangfied) waiting maybe till next release from 10-STABLE tree, however 10-STABLE will be where I will be eventually heading, so notes in this spirit are valuable reminders at least, I appreciate it. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Lessons-learned-from-source-upgrade-from-FreeBSD-i386-9-2-Stable-to-FreeBSD-i386-10-0-Release-tp5878896p5879039.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Thu Jan 23 14:56:03 2014 Return-Path: Delivered-To: freebsd-current@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 82560E22 for ; Thu, 23 Jan 2014 14:56:03 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 35992164F for ; Thu, 23 Jan 2014 14:56:03 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id s0NEu1kt077352; Thu, 23 Jan 2014 07:56:02 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id s0NEu1cp077349; Thu, 23 Jan 2014 07:56:01 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 23 Jan 2014 07:56:01 -0700 (MST) From: Warren Block To: Jakub Lach Subject: Re: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release. In-Reply-To: <1390486224478-5879039.post@n5.nabble.com> Message-ID: References: <52E09F68.8020804@UToledo.edu> <1390486224478-5879039.post@n5.nabble.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Thu, 23 Jan 2014 07:56:02 -0700 (MST) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 14:56:03 -0000 On Thu, 23 Jan 2014, Jakub Lach wrote: > I plan to stay some time on 9.2-STABLE (already pkgng and clangfied) waiting > maybe till next release from 10-STABLE tree, however 10-STABLE will be where > I will be eventually heading, so notes in this spirit are valuable reminders > at least, I appreciate it. My experiences converting a couple of systems from 9-STABLE to 10-STABLE over the last couple of months were really pretty easy. These were source updates for both base and ports. Despite changing from pkg_* to pkg and KMS X drivers at the same time, it was surprisingly smooth. If you have devel/ccache installed, remove it before starting, though, it has problems with clang. Using -DNOCLEAN with an existing /usr/obj can go even faster than ccache: less than two minutes for a buildworld on my frequently updated i5/SSD system, sometimes less than one minute. From owner-freebsd-current@FreeBSD.ORG Thu Jan 23 15:25:34 2014 Return-Path: Delivered-To: freebsd-current@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 2778DAEF; Thu, 23 Jan 2014 15:25:34 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D575F18EE; Thu, 23 Jan 2014 15:25:33 +0000 (UTC) Received: from [192.168.2.2] (unknown [77.243.161.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id DE62B5C44; Thu, 23 Jan 2014 16:25:22 +0100 (CET) Subject: Re: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release. Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8A8A9D86-F424-461E-9144-4CCAA4DE1AB6"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.1 (6062eb4) From: Dimitry Andric In-Reply-To: <52E09F68.8020804@UToledo.edu> Date: Thu, 23 Jan 2014 16:25:14 +0100 Message-Id: <96B0440B-B147-4A18-A8F9-22FE8BB08DE8@FreeBSD.org> References: <52E09F68.8020804@UToledo.edu> To: Robert Burmeister X-Mailer: Apple Mail (2.1827) Cc: Current FreeBSD , FreeBSD Mailing List X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 15:25:34 -0000 --Apple-Mail=_8A8A9D86-F424-461E-9144-4CCAA4DE1AB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 23 Jan 2014, at 05:49, Robert Burmeister = wrote: > Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to = FreeBSD i386 10.0 Release. >=20 > A) > Clang is needed to compile FreeBSD 10 due to use of the updated = libstdc++ in world. Ehrm, no? You should be able to run stock 9-stable, which has gcc as the default compiler, and build 10.0 release without any trouble. Can you please explain which problems you encountered with libstdc++? -Dimitry --Apple-Mail=_8A8A9D86-F424-461E-9144-4CCAA4DE1AB6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlLhNF8ACgkQsF6jCi4glqPHzQCgusNUbm8/pBApFoJIyX0z8H4x /KcAn0QDo8Gw/tnpXTifi95RzqSbvnTI =w8i5 -----END PGP SIGNATURE----- --Apple-Mail=_8A8A9D86-F424-461E-9144-4CCAA4DE1AB6-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 23 15:47:29 2014 Return-Path: Delivered-To: freebsd-current@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 89071B89 for ; Thu, 23 Jan 2014 15:47:29 +0000 (UTC) Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 399A21B27 for ; Thu, 23 Jan 2014 15:47:29 +0000 (UTC) Received: by mail-vb0-f48.google.com with SMTP id q16so1122844vbe.7 for ; Thu, 23 Jan 2014 07:47:28 -0800 (PST) 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=z6WNYwZfLka6J0Afxnv68Gp7L5wgPoSTfwu81OsQccU=; b=h4t0NjbDamtgdb6eIc8av1mlSlSM70FhrvYY9UpeZyGYun+YcLy2KjxzGN/CcwXp4b vwpdxQXWrxdUHDPVpgINVmq9LPCuttcercD+4dh5tX6slOVXJEjdvN6Y7BT9/WJc4h4p dF4vXx7ZbcrdxPrxMYapg87NAaT2XpIEpXkg+qGVQd79j4pLKmADbVL8wKvjQeECnCOT otuSodjMD5GPZV0Mpghr77E0LUga1Ql2RfAG+cmrw7zgFSK5CyUgUytvWvJI/VXU7LHu hMA6T/0igWAHCC/G4iJcmoEF3N6DGsT++dfm57xA5ldXPYqtmHaNeuX/kF2/J+8rqQJw xTWg== MIME-Version: 1.0 X-Received: by 10.58.7.1 with SMTP id f1mr4768297vea.15.1390492048384; Thu, 23 Jan 2014 07:47:28 -0800 (PST) Received: by 10.220.168.135 with HTTP; Thu, 23 Jan 2014 07:47:28 -0800 (PST) In-Reply-To: References: <52E09F68.8020804@UToledo.edu> <1390486224478-5879039.post@n5.nabble.com> Date: Thu, 23 Jan 2014 10:47:28 -0500 Message-ID: Subject: Re: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release. From: Thomas Hoffmann To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Warren Block , Jakub Lach X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 15:47:29 -0000 On Thu, Jan 23, 2014 at 9:56 AM, Warren Block wrote: > > > Using -DNOCLEAN with an existing /usr/obj can go even faster than ccache: > less than two minutes for a buildworld on my frequently updated i5/SSD > system, sometimes less than one minute. Can you elaborate on this, please? I always clear my /usr/obj before starting a buildworld, which takes 2 hours to run on my system. Are you saying if I do "make -DNOCLEAN buildworld" I do not have to clear /usr/obj first AND my buildworld will run faster (AND with no downside)? Thanks. -Tom From owner-freebsd-current@FreeBSD.ORG Thu Jan 23 16:14:59 2014 Return-Path: Delivered-To: freebsd-current@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 6F50EC2D for ; Thu, 23 Jan 2014 16:14:59 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2E92A1EF6 for ; Thu, 23 Jan 2014 16:14:59 +0000 (UTC) Received: by mail-vc0-f170.google.com with SMTP id hu8so1185286vcb.1 for ; Thu, 23 Jan 2014 08:14:58 -0800 (PST) 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=F8IiIC0BGxLi9gGWOpOVH4beiyL1su9TxJHzgdGRGzo=; b=maMrRFuP06RMwX3K2m2uYT40oxlfqOoWqUjQevVnCSwDA3BQJUa+uJ2J3QFCeeRiTw SyYzsF0QqUnaa4NyIznJk8GobT8BDuxmHuOqFunyS2oiswetq5PvSKeI37ttqK1RJL4/ QDcZq/QTNNA0/KOa33hBHeGRn4XVSgTNs/GM2y+WrvYAQW7U6CCin1p0CVQ29d3DLnhz 9ES7ToB0HbUaUi6vWuJvToZplnqq11ixDSkNOjWV7C+/iWsq2nHToa5VvT4kMOOy4a/i m/nZ1u/rDjrmWiSqZDvN4FreXn9mfpDHURnKl9RJj4Ba/0mdF/DDl6P2+PW9G8ugoAV8 SitQ== MIME-Version: 1.0 X-Received: by 10.220.252.71 with SMTP id mv7mr88047vcb.68.1390493698308; Thu, 23 Jan 2014 08:14:58 -0800 (PST) Received: by 10.220.168.135 with HTTP; Thu, 23 Jan 2014 08:14:58 -0800 (PST) Date: Thu, 23 Jan 2014 11:14:58 -0500 Message-ID: Subject: lock order reversals w/ backtrace From: Thomas Hoffmann To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 16:14:59 -0000 A few days ago I started running 11.0-CURRENT at r260971 for the first time. The last couple of times I shutdown my system I noticed 2 or 3 short "lock order reversal" messages with accompanying backtraces scroll by. Do these messages represent a problem that I should report or can I ignore them as debug in nature? If I should report them, how or where do these messages get logged? I can find no reference to them in syslog or anywhere else upon my subsequent reboot. I also had a couple of these messages pop up the other day while mounting/umounting USB thumb drives. I did not think anything of them at the time as the mounts/umounts completed successfully. Please advise. Thanks. -Tom From owner-freebsd-current@FreeBSD.ORG Thu Jan 23 16:44:21 2014 Return-Path: Delivered-To: freebsd-current@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 53C72854 for ; Thu, 23 Jan 2014 16:44:21 +0000 (UTC) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 257B511BC for ; Thu, 23 Jan 2014 16:44:21 +0000 (UTC) Received: by mail-pb0-f48.google.com with SMTP id rr13so2043063pbb.21 for ; Thu, 23 Jan 2014 08:44:20 -0800 (PST) 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=UP+MdyDdGBw1I+L5+rlM4e9dShybmW00PuPa02S0des=; b=xpCdBsOWR4u0BHDPmhzxtQpmCwA94roGYGwwz4yFM5OIn9fuX5rFpr4Z4mWBFvdVDN kSz67G8ylz3+eZEbEsbgbhYjYOh5ENtWEuhwYjAfKgjbRs+tjCt8fwM0pFYnwGuqgaUl 0y96AXESusJ0ELPL0i0iyPAYXoZi2TJwBGqOVARLgRiQI5BNLInxkiwJ25XRbQe3jJuX is0C3bTLmQGHKQebdhAmaG+VsE2GGNDN8T6WmWAbBQ/TiPX3nKOIulThIx3tAuCBZwMm hWMQQAwpgsqA1txkv8H8pfyqz/LHW81ZNRHOpnTiCfOHDi//AOzEPE1T8NflRns4ngNx CXKA== MIME-Version: 1.0 X-Received: by 10.68.76.68 with SMTP id i4mr9002780pbw.73.1390495460497; Thu, 23 Jan 2014 08:44:20 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.67.30.1 with HTTP; Thu, 23 Jan 2014 08:44:20 -0800 (PST) In-Reply-To: References: <52E09F68.8020804@UToledo.edu> <1390486224478-5879039.post@n5.nabble.com> Date: Thu, 23 Jan 2014 08:44:20 -0800 X-Google-Sender-Auth: YlpN0lF-k50uMm0664Vrnt_vNA4 Message-ID: Subject: Re: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release. From: Kevin Oberman To: Thomas Hoffmann Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Warren Block , freebsd-current , Jakub Lach X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 16:44:21 -0000 On Thu, Jan 23, 2014 at 7:47 AM, Thomas Hoffmann wrote: > On Thu, Jan 23, 2014 at 9:56 AM, Warren Block wrote: > > > > > > Using -DNOCLEAN with an existing /usr/obj can go even faster than ccache: > > less than two minutes for a buildworld on my frequently updated i5/SSD > > system, sometimes less than one minute. > > > Can you elaborate on this, please? I always clear my /usr/obj before > starting a buildworld, which takes 2 hours to run on my system. Are you > saying if I do "make -DNOCLEAN buildworld" I do not have to clear /usr/obj > first AND my buildworld will run faster (AND with no downside)? > > Thanks. > -Tom > I moved to pkg after the upgrade from 9.2 to 10.0 and had no real problems. Of course, I did have to install pkg and run pkg2ng, but I would have had to run those at some point, anyway. Exactly what problems did you hit? -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu Jan 23 16:52:57 2014 Return-Path: Delivered-To: freebsd-current@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 784DDBC1 for ; Thu, 23 Jan 2014 16:52:57 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 24CF61299 for ; Thu, 23 Jan 2014 16:52:56 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id s0NGqt3a078482; Thu, 23 Jan 2014 09:52:55 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id s0NGqts3078479; Thu, 23 Jan 2014 09:52:55 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 23 Jan 2014 09:52:55 -0700 (MST) From: Warren Block To: Kevin Oberman Subject: Re: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release. In-Reply-To: Message-ID: References: <52E09F68.8020804@UToledo.edu> <1390486224478-5879039.post@n5.nabble.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Thu, 23 Jan 2014 09:52:55 -0700 (MST) Cc: Thomas Hoffmann , Jakub Lach , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 16:52:57 -0000 On Thu, 23 Jan 2014, Kevin Oberman wrote: > On Thu, Jan 23, 2014 at 7:47 AM, Thomas Hoffmann wrote: > On Thu, Jan 23, 2014 at 9:56 AM, Warren Block wrote: > > > > > > Using -DNOCLEAN with an existing /usr/obj can go even faster than ccache: > > less than two minutes for a buildworld on my frequently updated i5/SSD > > system, sometimes less than one minute. > > > Can you elaborate on this, please? I always clear my /usr/obj before > starting a buildworld, which takes 2 hours to run on my system. Are you > saying if I do "make -DNOCLEAN buildworld" I do not have to clear /usr/obj > first Yes. Removing /usr/obj is a faster way of doing 'make clean', mostly. > AND my buildworld will run faster Yes, because make will see that many/most files have already been built. > (AND with no downside)? Well... mostly. :) I noticed that after 10.0-RELEASE, uname on my system still said "PRERELEASE". That code had not been rebuilt because make did not see it as needing a rebuild. You can still delete /usr/obj and run a full buildworld from scratch every so often. I should give credit to bdrewery@ for reminding me about -DNOCLEAN when I was whining about ccache not working on 10.0. It turned out to be a better solution. From owner-freebsd-current@FreeBSD.ORG Thu Jan 23 16:48:44 2014 Return-Path: Delivered-To: freebsd-current@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 202B7AB7 for ; Thu, 23 Jan 2014 16:48:44 +0000 (UTC) Received: from mta04.bitpro.no (mta04.bitpro.no [92.42.64.203]) by mx1.freebsd.org (Postfix) with ESMTP id B9EBC1202 for ; Thu, 23 Jan 2014 16:48:43 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta04.bitpro.no (Postfix) with ESMTPS id 2FF3610058C; Thu, 23 Jan 2014 17:48:36 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 24F42160923; Thu, 23 Jan 2014 17:49:26 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKvNWUj-K3XL; Thu, 23 Jan 2014 17:49:25 +0100 (CET) Received: from mail.lockless.no (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 2481D160922; Thu, 23 Jan 2014 17:49:25 +0100 (CET) Subject: RE: lock order reversals w/ backtrace From: =?utf-8?Q?Hans_Petter_Selasky?= To: =?utf-8?Q?Thomas_Hoffmann?= , =?utf-8?Q?freebsd-current?= Date: Thu, 23 Jan 2014 17:49:25 +0100 Mime-Version: 1.0 In-Reply-To: References: X-Priority: 3 (Normal) X-Mailer: Zarafa 7.1.4-41394 Message-Id: X-Mailman-Approved-At: Thu, 23 Jan 2014 17:00:28 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 16:48:44 -0000 Hi,=0D=0A=0D=0ACan you see if you can snap some keywords of the backtrace= s, like usb_xxx usbdx_xxx cam scsi or something like that.=0D=0A=0D=0AEls= e I believe there are some sysctl options to prevent the final reboot som= ehow so that you can write down the messages.=0D=0A=0D=0A--HPS=0D=0A=20=0D= =0A-----Original message-----=0D=0A> From:Thomas Hoffmann >=0D=0A> Sent: Thursday 23rd January 2014 17= :15=0D=0A> To: freebsd-current >=0D=0A> Subject: lock order reversals w/ backtra= ce=0D=0A>=20=0D=0A> A few days ago I started running 11.0-CURRENT at r260= 971 for the first time.=0D=0A>=20=0D=0A> The last couple of times I shutd= own my system I noticed 2 or 3 short "lock=0D=0A> order reversal" message= s with accompanying backtraces scroll by. Do these=0D=0A> messages repres= ent a problem that I should report or can I ignore them as=0D=0A> debug i= n nature=3F If I should report them, how or where do these messages=0D=0A= > get logged=3F I can find no reference to them in syslog or anywhere els= e upon=0D=0A> my subsequent reboot.=0D=0A>=20=0D=0A> I also had a couple = of these messages pop up the other day while=0D=0A> mounting/umounting US= B thumb drives. I did not think anything of them at=0D=0A> the time as th= e mounts/umounts completed successfully.=0D=0A>=20=0D=0A> Please advise. = Thanks.=0D=0A>=20=0D=0A> -Tom=0D=0A> ____________________________________= ___________=0D=0A> freebsd-current@freebsd.org mailing list=0D=0A> http://lists.freebsd.org/mailman/listinfo= /freebsd-current =20=0D=0A> To unsubscribe, send any mail to "freebsd-current-unsubscri= be@freebsd.org "=0D=0A>=20= =0D=0A=0D=0A From owner-freebsd-current@FreeBSD.ORG Thu Jan 23 17:11:14 2014 Return-Path: Delivered-To: freebsd-current@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 42BE6393 for ; Thu, 23 Jan 2014 17:11:14 +0000 (UTC) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EE4A6146A for ; Thu, 23 Jan 2014 17:11:13 +0000 (UTC) Received: by mail-ve0-f173.google.com with SMTP id oz11so1285251veb.32 for ; Thu, 23 Jan 2014 09:11:13 -0800 (PST) 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=ewBZuJOMa1nfvWCmOC9MHRyp2rS1Iw+ZB5Q6vgtekBE=; b=SyjdGZnm2PQkkGQcd0HQAmrFUydKRqffBgJG8KMirpLbvsokgXNOqeouJ2CsqTofm7 6zgvlYqQh4laEkLhxgY1LbdAZhacjNpH3pOjEWi6r6NxQuU8F/FpfImD8Qh2iSou412w 9qspQThVEH2DFRHS52Ay/WM4SfwT5XGQ7aIVGp+jHHASpbH/tVV7CbVD2iNNUCRGKz+C 2BaIsbH2bJWkCKP9ASq0G3ElFSBYq5Tye0TR72GSooiB4UdJmbBMSQMg7ok0rUuDl7c+ iwEAICf0pmLnYAeoHzdR9bdFhrSbILZU77+7G/iL3UIdClAM8AhvlLgz//Ju9vfU0Sv9 cSng== MIME-Version: 1.0 X-Received: by 10.220.193.70 with SMTP id dt6mr5037390vcb.17.1390497073172; Thu, 23 Jan 2014 09:11:13 -0800 (PST) Received: by 10.220.168.135 with HTTP; Thu, 23 Jan 2014 09:11:13 -0800 (PST) In-Reply-To: References: <52E09F68.8020804@UToledo.edu> <1390486224478-5879039.post@n5.nabble.com> Date: Thu, 23 Jan 2014 12:11:13 -0500 Message-ID: Subject: Re: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release. From: Thomas Hoffmann To: Warren Block , freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Jakub Lach X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 17:11:14 -0000 On Thu, Jan 23, 2014 at 11:52 AM, Warren Block wrote: > On Thu, 23 Jan 2014, Kevin Oberman wrote: > > On Thu, Jan 23, 2014 at 7:47 AM, Thomas Hoffmann >> wrote: >> On Thu, Jan 23, 2014 at 9:56 AM, Warren Block >> wrote: >> > >> > >> > Using -DNOCLEAN with an existing /usr/obj can go even faster than >> ccache: >> > less than two minutes for a buildworld on my frequently updated >> i5/SSD >> > system, sometimes less than one minute. >> >> >> Can you elaborate on this, please? I always clear my /usr/obj before >> starting a buildworld, which takes 2 hours to run on my system. Are you >> saying if I do "make -DNOCLEAN buildworld" I do not have to clear /usr/obj >> first >> > > Yes. Removing /usr/obj is a faster way of doing 'make clean', mostly. > > > AND my buildworld will run faster >> > > Yes, because make will see that many/most files have already been built. > > (AND with no downside)? >> > > Well... mostly. :) > > I noticed that after 10.0-RELEASE, uname on my system still said > "PRERELEASE". That code had not been rebuilt because make did not see it > as needing a rebuild. You can still delete /usr/obj and run a full > buildworld from scratch every so often. > > I should give credit to bdrewery@ for reminding me about -DNOCLEAN when I > was whining about ccache not working on 10.0. It turned out to be a better > solution. > Hmm, I particularly like your suggestion of running a full buildworld periodically. With two hour buildworlds (from scratch) I was planning on rebuilding every couple of weeks. If using -DNOCLEAN can significantly reduce my buildworld time, I'll rebuild weekly and do a full build every fourth week. I'm anxious to give this approach a go and see how much time I can save on the buildworlds. Thanks for the info and tips. -Tom From owner-freebsd-current@FreeBSD.ORG Thu Jan 23 19:28:39 2014 Return-Path: Delivered-To: freebsd-current@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 D2BB7199 for ; Thu, 23 Jan 2014 19:28:39 +0000 (UTC) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8D945110B for ; Thu, 23 Jan 2014 19:28:39 +0000 (UTC) Received: by mail-vc0-f180.google.com with SMTP id ks9so1305994vcb.39 for ; Thu, 23 Jan 2014 11:28:37 -0800 (PST) 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=SNEPGrle/L2jl6U9MhmS5n7+gM4QiBXXpgYH4pdjNyo=; b=kOiHRA3mLD2O4ZfQb2zPEvZCgHs/iXTOSUM/1zGQDLjGHXglKC/HqI8pVmhCbCdl9a XL9wMK5PHJN1m1SSZEVtORlKrq8dtcmFEr62lG2e5bhds1Csdn6/pmITVnlJR2Zy5Ekf 85OIgj7WKXY4tBzve2ZX3IBGznKRV/itIJwhlhcN/XnFIWsZgFTy90FIyOi8/8Ixj2Eq UCO2h11kEZj9dGdSH3KahfIIDedAI9au65Rqh1SZw/bphUY0iTtjBY01Ry+2Oy6k6LPE hn0QxwJ4Pe7WFZfaLbQs2pPTjNI90DZLvG6MMYia6+8v8WdSlZck5vtiKLEiyIyq1jta 9TiQ== MIME-Version: 1.0 X-Received: by 10.58.37.67 with SMTP id w3mr5367034vej.22.1390505317731; Thu, 23 Jan 2014 11:28:37 -0800 (PST) Received: by 10.220.168.135 with HTTP; Thu, 23 Jan 2014 11:28:37 -0800 (PST) In-Reply-To: <20140123201535.000018e9@unknown> References: <20140123201535.000018e9@unknown> Date: Thu, 23 Jan 2014 14:28:37 -0500 Message-ID: Subject: Re: Fw: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release. From: Thomas Hoffmann To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Matthew Rezny X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 19:28:39 -0000 On Thu, Jan 23, 2014 at 2:15 PM, Matthew Rezny wrote: > Forwarded because my attempt to reply on list was rejected by > heavy-handed and oblivious moderation: > > "The freebsd-current mailing list is for issues involving > FreeBSD-CURRENT, not FreeBSD-STABLE. Neither FreeBSD 9.x nor 10.x is > "current" -- CURRENT became FreeBSD 11.x as of Thu Oct 10 18:05:13 > 2013 UTC." > > Feel free to forward on to the list if you feel this is valuable to > others. Apparently list owner looked only at the topic, ignore the fact > it's a reply several levels deep, and did NOT look at the content. > > Begin forwarded message: > > Date: Thu, 23 Jan 2014 18:22:50 +0100 > From: Matthew Rezny > To: freebsd-current@freebsd.org > Subject: Re: Lessons learned from source upgrade from FreeBSD i386 9.2 > Stable to FreeBSD i386 10.0 Release. > > > > On Thu, Jan 23, 2014 at 9:56 AM, Warren Block > > wrote: > > > > > > > > > Using -DNOCLEAN with an existing /usr/obj can go even faster than > > > ccache: less than two minutes for a buildworld on my frequently > > > updated i5/SSD system, sometimes less than one minute. > > > > > > Can you elaborate on this, please? I always clear my /usr/obj before > > starting a buildworld, which takes 2 hours to run on my system. Are > > you saying if I do "make -DNOCLEAN buildworld" I do not have to > > clear /usr/obj first AND my buildworld will run faster (AND with no > > downside)? > > > > Thanks. > > -Tom > > If you always clear your /usr/obj, you can safely add -DNOCLEAN to the > build and it will shave off a minute or two (depending on drive speed) > that would have been spent attempting to delete thousands of non- > existent files and directories. I've never actually benchmarked, but rm > -rf /usr/obj followed by make -DNOCLEAN buildworld should take slightly > less time than a regular buildworld (unless perhaps you use a tmpfs > backed /usr/obj). > > Yes, you can safely do a make -DNOCLEAN bulidworld without first > clearing out /usr/obj iff conditions are right. If you change anything > in src.conf or make.conf, then you must clean. If you switch what > branch you are checking out from then you must clean. If you are > tracking -STABLE or -CURRENT with regularity (as Warren does) then you > can usually get away with not cleaning. If you go too long between > updates to your /usr/src then you might have to clean. If there is a > disruptive commit, you might have to clean. Sometimes it will be > obvious because the buildworld won't complete without error, but > sometimes it will finish with apparent success however some binaries > will be bad. So, if you get some rather strange behavior shortly after > installworld, go clean it and build again. > > If you are doing your own local development, then you can safely use > -DNOCLEAN throughout the process. Only if you make a disruptive > change yourself or possibly if you merge changes from svn would you > need to clean the build. > This is good to know, especially the info on when using -DNOCLEAN might cause problems and how they might manifest themselves. Thanks. -Tom From owner-freebsd-current@FreeBSD.ORG Thu Jan 23 20:34:42 2014 Return-Path: Delivered-To: freebsd-current@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 4CE2C2D7; Thu, 23 Jan 2014 20:34:42 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2490217F8; Thu, 23 Jan 2014 20:34:42 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1C355B948; Thu, 23 Jan 2014 15:34:41 -0500 (EST) From: John Baldwin To: Luigi Rizzo Subject: Re: possible selrecord optimization ? Date: Thu, 23 Jan 2014 14:52:41 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201401221429.56745.jhb@freebsd.org> <20140123003948.GC292@onelab2.iet.unipi.it> In-Reply-To: <20140123003948.GC292@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201401231452.41509.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 23 Jan 2014 15:34:41 -0500 (EST) Cc: freebsd-current@freebsd.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 20:34:42 -0000 On Wednesday, January 22, 2014 7:39:48 pm Luigi Rizzo wrote: > On Wed, Jan 22, 2014 at 02:29:56PM -0500, John Baldwin wrote: > > On Tuesday, January 21, 2014 9:25:27 pm Luigi Rizzo wrote: > > > Looking at how selrecord() / selwakeup() and their Linux counterparts > > > poll_wait() and wake_up() are used, i noticed the following: > .... > > > I wonder if we could use the same optimization as Linux: > > > as soon as pollscan/selscan detects a non-blocking fd, > > > make selrecord a no-op (which is probably as simple > > > as setting SELTD_RESCAN; and since it only goes up > > > we do not need to lock to check it). > > > > Yes, I think this would work fine. I think setting SELTD_RESCAN as a way to > > do it is fine as well. > > excellent, thanks. > > I also have two related questions: > > 1. why isn't the struct mtx part of the struct selinfo instead > of being grabbed from the mtxpool_select ? I think this is because there is no selinfo_init() and no selinfo_destroy(), so there is no way to manage the lifetime of the mutex were it embedded into the structure. Also, if there are a lot of these structures, but only a subset of them are ever accessed, then a smaller set of locks that are hashed onto the structures may work just fine without introducing extra contention (but with the benefit of saving space in the structures). > 2. am i correct that we do need to protect concurrent invocations > of selrecord() on the same selinfo because mtx_pool_find() > return the same mutex for a given struct selinfo ? If you mean 'do not need', yes. mtx_pool_find() does a hash on the address, so it will always return the same lock for a given selinfo, and no external locking should be needed by callers. However, callers often need to check other state for which they need to hold a lock anyway. OTOH, if, for example, socket buffer locks were reader/writer locks, sopoll_generic() could use read locks on the socket buffers even while calling selrecord(). > In case, any objections if i add some comments to the code > to explain the above ? Not from me. :) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jan 23 20:42:24 2014 Return-Path: Delivered-To: freebsd-current@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 6BB30AC6 for ; Thu, 23 Jan 2014 20:42:24 +0000 (UTC) Received: from newton.metanet.ch (newton.metanet.ch [80.74.158.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B071718C0 for ; Thu, 23 Jan 2014 20:42:23 +0000 (UTC) Received: (qmail 27324 invoked from network); 23 Jan 2014 21:35:39 +0100 Received: from udp003908uds.hawaiiantel.net (HELO ?192.168.1.16?) (72.234.77.86) by newton.metanet.ch with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 23 Jan 2014 21:35:39 +0100 Message-ID: <52E17D18.60808@thieprojects.ch> Date: Thu, 23 Jan 2014 10:35:36 -1000 From: Werner Thie Organization: Thie & Co Projects User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-ports@freebsd.org Subject: port hyperic-sigar - marked broken, is anybody fixing this port? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: werner@thieprojects.ch List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 20:42:24 -0000 Hi Java is probably not the first programming language which comes to mind, when working with FreeBSD. But still I sadly had to forgive to deploy OpenKM because it can't start LibreOffice as service due to the fact, that the author used hyperic-sigar for this functionality. My question: Is anybody working on this problem, that instead of using utmp.h and diddling with the related files directly, one should rely on utmpx.h and its db manipulating functionality. I could give it a try for FreeBSD9, but I'm mostly a noob, be it Java or Java extensions and also for ports. Maybe some kindred soul could fill me in such, that this itch can be scratched. Werner From owner-freebsd-current@FreeBSD.ORG Thu Jan 23 21:08:35 2014 Return-Path: Delivered-To: freebsd-current@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 0AF72724 for ; Thu, 23 Jan 2014 21:08:35 +0000 (UTC) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D2A6B1AF0 for ; Thu, 23 Jan 2014 21:08:34 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id kp14so2362489pab.20 for ; Thu, 23 Jan 2014 13:08:34 -0800 (PST) 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=iz82waX/DtLpyxcSlYxYCIG+IQe4Kt7R32HUdgs1qY8=; b=l7Pc+0eeMXHwDJCI9jKpLhf4V83CjDpDgGRV2x/lMBcd/FgLuamFycfq6ssyiWIHIB ksqNXDYBEnzTuGuRxDTwmgEZDABnxvRU3hoghM/BvayqQAC4688PSzCxIQB22yKIduXu mZFZ29d3nvTFJtGC225pUodovAcO3KoJnEYyMH1WoqBPYMvozL8xvhy7BQ8aJd4uLYX8 MQY3QKlihCaUKWwsGmpTvbuaxoT/KK1yQpJtjVG/RsrTClINAwh63WwgDxZboMU34ZRH 1Pl9VLLGLYz52b7oLTqoj0bmwO2T2v9R6nJ4hQYd8+YLlTN4/UBOFtDspoDt3lz+Qqyv nv7g== MIME-Version: 1.0 X-Received: by 10.68.231.169 with SMTP id th9mr10175063pbc.113.1390511314369; Thu, 23 Jan 2014 13:08:34 -0800 (PST) Received: by 10.66.192.72 with HTTP; Thu, 23 Jan 2014 13:08:34 -0800 (PST) In-Reply-To: <9ec5437a-eb1f-4ed0-809d-7fd41cdcd4df@email.android.com> References: <9ec5437a-eb1f-4ed0-809d-7fd41cdcd4df@email.android.com> Date: Thu, 23 Jan 2014 23:08:34 +0200 Message-ID: Subject: Re: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC From: Vlad Movchan To: "Mike C." Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 21:08:35 -0000 I've just tested second patch from kern/165622 - it still applies clean and runs good on recent current. If after applying this patch you trigger some other kind of panic/problem you might also want to take a look on https://github.com/NDISulator/ndisulator. Ndis module version from github differs a bit and it has several fixes which are not present in the base tree. On Thu, Jan 23, 2014 at 11:39 AM, Mike C. wrote: > hum... the driver I need is for broadcom 4313 wireless, It seems the > modules available don't work for that one... wonder of they ever will? > > I would definitely prefer that to using ndis. > > > Adrian Chadd wrote: > >It's actually fpu code in ndis drivers. I'm going to deprecate NDIS > >this year, so .. > > > >OTOH, the FPU save support would be cool. > > > > > >-a > > > > > >On 22 January 2014 20:10, Miguel Clara wrote: > >> Getting a panic: Unregistered use of FPU in kernel > >> > >> > >> There seems to be a patch for FreeBSD 10, but not sure if it wold > >apply > >> > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=165622&sourceid=opensearch > >> > >> > >> Thanks > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to > >"freebsd-current-unsubscribe@freebsd.org" > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Have a nice day, Vlad Movchan From owner-freebsd-current@FreeBSD.ORG Thu Jan 23 22:54:55 2014 Return-Path: Delivered-To: current@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 57FB05F4; Thu, 23 Jan 2014 22:54:55 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 14C5B1626; Thu, 23 Jan 2014 22:54:54 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 492C97300A; Thu, 23 Jan 2014 23:57:23 +0100 (CET) Date: Thu, 23 Jan 2014 23:57:23 +0100 From: Luigi Rizzo To: John Baldwin Subject: Re: possible selrecord optimization ? Message-ID: <20140123225723.GB11319@onelab2.iet.unipi.it> References: <201401221429.56745.jhb@freebsd.org> <20140123003948.GC292@onelab2.iet.unipi.it> <201401231452.41509.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201401231452.41509.jhb@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 22:54:55 -0000 On Thu, Jan 23, 2014 at 02:52:41PM -0500, John Baldwin wrote: > On Wednesday, January 22, 2014 7:39:48 pm Luigi Rizzo wrote: ... > > 2. am i correct that we do need to protect concurrent invocations > > of selrecord() on the same selinfo because mtx_pool_find() > > return the same mutex for a given struct selinfo ? > > If you mean 'do not need', yes. mtx_pool_find() does a hash on the address, yes, i meant "do not need". thanks luigi From owner-freebsd-current@FreeBSD.ORG Fri Jan 24 00:55:02 2014 Return-Path: Delivered-To: freebsd-current@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 5F6D971E; Fri, 24 Jan 2014 00:55:02 +0000 (UTC) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C95431023; Fri, 24 Jan 2014 00:55:01 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id x55so1996669wes.22 for ; Thu, 23 Jan 2014 16:55:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SRe45hiS4XUIcZAG/a+jG/yZSLhF9L0V9NDlnwAB/sM=; b=ZMGpo+CYXvrHFLjx7e3T6zZzM7ceBx7MmlJ++vLHSQg68XFqu/w2f1Y9kfV69/a/zG 97zT8kYnqXSCerfmWsdcMvM0Q/NSFm41QhOiOoHeC1a50oKhA/wkiXIIY0/n4/qBJ3Jn C6u0AxXpjtnhp5fvKRegMiyi4ZZB7aF3it9XZGqZOf4Uig26q68deoPv6HR8XzJyJbVk K3wb9X1xPfOZOFI+vYDITfswRNp4pYCkquWi0i4qff9n8+HPxik+8LVSFQBE5+8BU4Ur XvvftUeFFi9hqu6uRUTrGxmXRLWTbBpMYjB1XKlDJSzlVWHyNCFnCvxQAQ05UvqjTPJ+ n6Rg== X-Received: by 10.180.211.68 with SMTP id na4mr1302285wic.0.1390524900103; Thu, 23 Jan 2014 16:55:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.240.135 with HTTP; Thu, 23 Jan 2014 16:54:39 -0800 (PST) In-Reply-To: References: From: Miguel Clara Date: Fri, 24 Jan 2014 00:54:39 +0000 Message-ID: Subject: Re: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 00:55:02 -0000 Hi Adrian, when you say "I'm going to deprecate NDIS", does this also mean there a change to have this driver working without ndis in freebsd? I tried kldload if_bwi kldload if_bwn But none of them work for 4313 it seems! :( On Thu, Jan 23, 2014 at 7:21 AM, Adrian Chadd wrote: > It's actually fpu code in ndis drivers. I'm going to deprecate NDIS > this year, so .. > > OTOH, the FPU save support would be cool. > > > -a > > > On 22 January 2014 20:10, Miguel Clara wrote: >> Getting a panic: Unregistered use of FPU in kernel >> >> >> There seems to be a patch for FreeBSD 10, but not sure if it wold apply >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=165622&sourceid=opensearch >> >> >> Thanks >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Jan 24 00:56:02 2014 Return-Path: Delivered-To: freebsd-current@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 BED2B8A5; Fri, 24 Jan 2014 00:56:02 +0000 (UTC) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 34528105C; Fri, 24 Jan 2014 00:56:02 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id y10so2355361wgg.10 for ; Thu, 23 Jan 2014 16:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4DGVODheVOhvABhYrdNuLRBCH4GDcluDFWlSDCEPZtc=; b=HdLtlEyikvsWmUsGmBd6vtVWKdZLlnWH/3EF1wwQ/QyuQsMyamhiohYcrf29ZPcwwC Auptbu4ovZOntE5CG4vkpdDsP9mkqiqS25p+9dSjaxbOXaHJ2YSEN9tQVM6cCSsHqFCU dFEH2dbbwtK4KHfym/2hfZUI/OGXkqU2D0vwl0ODHhruV5foucztO42E9lyHOceXGjhG bEMIYtsVexlL9PvnoXL1bdXK38s2H+fh2f+EGOoXObQiQ+Lk6rYDa89c0+6mesHMLp8z 4f7f2OP4LkxM3w0PPoX87jw35wRg8mBf8IruwJ1N2xBj0UJZrfa8sm2MPZB+4IUTcHLO zdFg== X-Received: by 10.180.9.74 with SMTP id x10mr988167wia.52.1390524960518; Thu, 23 Jan 2014 16:56:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.240.135 with HTTP; Thu, 23 Jan 2014 16:55:40 -0800 (PST) In-Reply-To: References: From: Miguel Clara Date: Fri, 24 Jan 2014 00:55:40 +0000 Message-ID: Subject: Re: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 00:56:02 -0000 *sorry "mean there a change" --> "mean there's a chance" On Fri, Jan 24, 2014 at 12:54 AM, Miguel Clara wrote: > Hi Adrian, when you say "I'm going to deprecate NDIS", does this also > mean there a change to have this driver working without ndis in > freebsd? > > I tried > kldload if_bwi > kldload if_bwn > > But none of them work for 4313 it seems! :( > > On Thu, Jan 23, 2014 at 7:21 AM, Adrian Chadd wrote: >> It's actually fpu code in ndis drivers. I'm going to deprecate NDIS >> this year, so .. >> >> OTOH, the FPU save support would be cool. >> >> >> -a >> >> >> On 22 January 2014 20:10, Miguel Clara wrote: >>> Getting a panic: Unregistered use of FPU in kernel >>> >>> >>> There seems to be a patch for FreeBSD 10, but not sure if it wold apply >>> >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=165622&sourceid=opensearch >>> >>> >>> Thanks >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Jan 24 02:18:37 2014 Return-Path: Delivered-To: freebsd-current@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 71D23188 for ; Fri, 24 Jan 2014 02:18:37 +0000 (UTC) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2E8A81658 for ; Fri, 24 Jan 2014 02:18:37 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id cm18so3182283qab.37 for ; Thu, 23 Jan 2014 18:18:36 -0800 (PST) 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=bbp8YVJsqt22xRHvDH+g4bsr3VomqsUQ6u0+3zGRxYo=; b=z6e6GsFK2pjsxP9h91E1oF4VMw4JqabFE2xLcnSw+cNLTYYQHoIb6GGCYDYcCmTlf5 Ry/hUhURskrub53G/XyVJo5wDsYyTE+xkZJEydj8g3vhR1oKsEuxvLmv45IQZdag1Qgu 4aKXJVxKB+1mfRBhITe8q0qDLI/zQPoPlW1Q51DsFbdPPWP8ZM1ao4TEi+pzYTyu4bu3 meKKQ6jzLznzolXfPncK8A1ZkZhorIKGHXHpp6uRGDbSq3lXq+19BefXN6+gYtejRdzz 0kzupNh7aQOGIStn+QH1eyQPH9nuY9Edw2BoKuLbdN9OaEgNEZGxpR7C4awLtRnusi06 k+AA== MIME-Version: 1.0 X-Received: by 10.224.89.71 with SMTP id d7mr16849105qam.26.1390529916206; Thu, 23 Jan 2014 18:18:36 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Thu, 23 Jan 2014 18:18:36 -0800 (PST) In-Reply-To: References: Date: Thu, 23 Jan 2014 18:18:36 -0800 X-Google-Sender-Auth: kwRawVJHFAU0w5u_0z8yqL1uRXE Message-ID: Subject: Re: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC From: Adrian Chadd To: Miguel Clara Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 02:18:37 -0000 Hi, yes. I'm going to deprecate NDIS and yes, this means that people using hardware that doesn't have a driver will have to go without. It sucks, but noone has stepped up to maintain NDIS and it can't work for later NDIS APIs. -a On 23 January 2014 16:54, Miguel Clara wrote: > Hi Adrian, when you say "I'm going to deprecate NDIS", does this also > mean there a change to have this driver working without ndis in > freebsd? > > I tried > kldload if_bwi > kldload if_bwn > > But none of them work for 4313 it seems! :( > > On Thu, Jan 23, 2014 at 7:21 AM, Adrian Chadd wrote: >> It's actually fpu code in ndis drivers. I'm going to deprecate NDIS >> this year, so .. >> >> OTOH, the FPU save support would be cool. >> >> >> -a >> >> >> On 22 January 2014 20:10, Miguel Clara wrote: >>> Getting a panic: Unregistered use of FPU in kernel >>> >>> >>> There seems to be a patch for FreeBSD 10, but not sure if it wold apply >>> >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=165622&sourceid=opensearch >>> >>> >>> Thanks >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Jan 24 02:27:25 2014 Return-Path: Delivered-To: freebsd-current@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 C4AE4520; Fri, 24 Jan 2014 02:27:25 +0000 (UTC) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 360BB1714; Fri, 24 Jan 2014 02:27:25 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id t60so2039211wes.37 for ; Thu, 23 Jan 2014 18:27:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8wHYzQRTTjpDjkv0DLkpikUrAvvOLjmYFpIgwVZArQE=; b=bdq7cSzD9sDIRb2v3TctWLc3T14tE6KBQhQ4FCXylUjx4LUNhAdmDRWTOofV1csCtC AjAiws+546V8GtMVHR/ydX5YH4VfM4DlKNxA+daggOkwDDFH/2vw7W7ff+WeW/pAG9q2 qsnNb6TRVLN/Ul9hZDByYITy9CN4sk7kTGzm0KR0a9N5A0xHlZ089WFqTyhUEapeQBXI Slm075ShAB2RD9/Mhi0vNtfYg0pWjUAY9ydAAGCOeQw93LxbOgDaU8y8vKCmfEBX/3Ng ow34K2pTehhyGaWPNYcv4yGxXuVoWpY24nYoM4p6+evKK+YYhfILbp3dqDOeqkhKHaxs eX9A== X-Received: by 10.180.211.68 with SMTP id na4mr1495827wic.0.1390530443680; Thu, 23 Jan 2014 18:27:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.240.135 with HTTP; Thu, 23 Jan 2014 18:27:03 -0800 (PST) In-Reply-To: References: From: Miguel Clara Date: Fri, 24 Jan 2014 02:27:03 +0000 Message-ID: Subject: Re: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 02:27:25 -0000 Pity this is not an old laptop... I7 processor sadly a bad wifi card, gave all kinds of problems on Windows to be honest! No point on applying the patch then if it will stop working anyway! I think I might be able to substitute the card with one from another asus, unless BIOS doesn't allow me too! thanks for clarifying! On Fri, Jan 24, 2014 at 2:18 AM, Adrian Chadd wrote: > Hi, > > yes. I'm going to deprecate NDIS and yes, this means that people using > hardware that doesn't have a driver will have to go without. It sucks, > but noone has stepped up to maintain NDIS and it can't work for later > NDIS APIs. > > > -a > > On 23 January 2014 16:54, Miguel Clara wrote: >> Hi Adrian, when you say "I'm going to deprecate NDIS", does this also >> mean there a change to have this driver working without ndis in >> freebsd? >> >> I tried >> kldload if_bwi >> kldload if_bwn >> >> But none of them work for 4313 it seems! :( >> >> On Thu, Jan 23, 2014 at 7:21 AM, Adrian Chadd wrote: >>> It's actually fpu code in ndis drivers. I'm going to deprecate NDIS >>> this year, so .. >>> >>> OTOH, the FPU save support would be cool. >>> >>> >>> -a >>> >>> >>> On 22 January 2014 20:10, Miguel Clara wrote: >>>> Getting a panic: Unregistered use of FPU in kernel >>>> >>>> >>>> There seems to be a patch for FreeBSD 10, but not sure if it wold apply >>>> >>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=165622&sourceid=opensearch >>>> >>>> >>>> Thanks >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Jan 24 05:25:58 2014 Return-Path: Delivered-To: freebsd-current@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 D355E25E for ; Fri, 24 Jan 2014 05:25:58 +0000 (UTC) Received: from mxout1.rambler.ru (mxout1.rambler.ru [81.19.67.58]) by mx1.freebsd.org (Postfix) with ESMTP id 89CAF1583 for ; Fri, 24 Jan 2014 05:25:58 +0000 (UTC) Received: from saddam4.rambler.ru (saddam4.rambler.ru [10.32.16.4]) by mxout1.rambler.ru (Postfix) with ESMTP id 0B95936D8 for ; Fri, 24 Jan 2014 09:25:57 +0400 (MSK) Received: from localhost.localdomain (localhost [127.0.0.1]) by saddam4.rambler.ru (Postfix) with ESMTP id ECF7A4277D9 for ; Fri, 24 Jan 2014 09:25:56 +0400 (MSK) Received: from [195.98.78.162] by mail.rambler.ru with HTTP; Fri, 24 Jan 2014 09:25:56 +0400 From: =?koi8-r?B?88XSx8XKIPTB0sHTz9c=?= To: freebsd-current@freebsd.org Subject: CAM Target Layer (LUN masking) Date: Fri, 24 Jan 2014 09:25:56 +0400 Message-Id: <1390541156.892401.13795.10327@mail.rambler.ru> MIME-Version: 1.0 X-Mailer: Rambler WebMail, http://mail.rambler.ru/ X-Rambler-User: tar85sa@rambler.ru/195.98.78.162 Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: =?koi8-r?B?88XSx8XKIPTB0sHTz9c=?= List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 05:25:58 -0000 Hi I found that Kenneth D. Merry ken at FreeBSD.org Thu Jan 5 04:51:03 UTC 2012 wrote: Configuring and Running CTL: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D ..... Note that all CTL LUNs are presented to all frontends. There is no LUN masking, or separate, per-port configuration. ..... Are there any plans to implement any kind of zoning or lun masking? It is very desirable feature for the project I'm working on now. Now I'm surfing isp's sources trying to get its architecture. I'd like to contribute in this filed (development, testing, whatever) if possible. Please let me know if I can help or if someone has beta-versions to try and fix. Thanks Sergey From owner-freebsd-current@FreeBSD.ORG Fri Jan 24 10:42:58 2014 Return-Path: Delivered-To: freebsd-current@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 916EDDA1 for ; Fri, 24 Jan 2014 10:42:58 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2594A1F6B for ; Fri, 24 Jan 2014 10:42:57 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1W6eDq-000D5e-JL>; Fri, 24 Jan 2014 11:42:50 +0100 Received: from g225038049.adsl.alicedsl.de ([92.225.38.49] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1W6eDq-000QtD-Do>; Fri, 24 Jan 2014 11:42:50 +0100 Date: Fri, 24 Jan 2014 11:42:45 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: r261034: buildworld fails: undefined reference to `DES_ecb_encrypt' Message-ID: <20140124114245.54ba8db7@thor.walstatt.dyndns.org> Organization: FU Berlin X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/rteT=z7Vjjn.fIRHm5Xi_V0"; protocol="application/pgp-signature" X-Originating-IP: 92.225.38.49 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 10:42:58 -0000 --Sig_/rteT=z7Vjjn.fIRHm5Xi_V0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable With r261034, I get the error shown below on one specific box running kernel/world 11.0-CURRENT #0 r261034: Wed Jan 22 20:14:05 CET 2014 amd64 Another box compiles the same source without any problems (running kernel/world=20 11.0-CURRENT #4 r261091: Thu Jan 23 22:46:03 CET 2014 amd64 My buildworld process on all systems is to delete the content of /usr/obj first before building the world/kernel, so remnants of faulty code or inconsistencies regarding the source tree are not likely. How to repair this strange behaviour? Regards, Oliver [...] (cd /usr/src/rescue/rescue/../../usr.bin/id && make -DRESCUE CRUNCH_CFLAGS=3D-DRESCUE DIRPRFX=3Drescue/rescue/id/ depend && make -DRESCUE CRUNCH_CFLAGS=3D-DRESCUE DIRPRFX=3Drescue/rescue/id/ id.o) `id.o' is up to date. (cd /usr/src/rescue/rescue/../../usr.sbin/chroot && make -DRESCUE CRUNCH_CFLAGS=3D-DRESCUE DIRPRFX=3Drescue/rescue/chroot/ depend && make -DRESCUE CRUNCH_CFLAGS=3D-DRESCUE DIRPRFX=3Drescue/rescue/chroot/ chroot.o) `chroot.o' is up to date. (cd /usr/src/rescue/rescue/../../usr.sbin/chown && make -DRESCUE CRUNCH_CFLAGS=3D-DRESCUE DIRPRFX=3Drescue/rescue/chown/ depend && make -DRESCUE CRUNCH_CFLAGS=3D-DRESCUE DIRPRFX=3Drescue/rescue/chown/ chown.o) `chown.o' is up to date. cc -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo savecore.lo spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo bsdlabel.lo fdisk.lo dhclient.lo head.lo mt.lo nc.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo less.lo xz.lo tar.lo vi.lo id.lo chroot.lo chown.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o /usr/obj/usr/sr= c/rescue/rescue/../librescue/getusershell.o /usr/obj/usr/src/rescue/rescue/= ../librescue/login_class.o /usr/obj/usr/src/rescue/rescue/../librescue/pope= n.o /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o /usr/obj/usr/src/r= escue/rescue/../librescue/sysctl.o /usr/obj/usr/src/rescue/rescue/../libres= cue/system.o -lcrypt -ledit -lkvm -ll -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -lipsec -lipx -lavl -ljail -lzfs_core -lzfs -lnvpair -lpthread -luutil -lumem -lgeom -lbsdxml -lkiconv -lmd -lsbuf -lufs -lz -lbz2 -llzma -larchive -lcrypto -lm nc.lo: In function `_$$hide$$ nc.lo main': (.text+0x622): warning: warning: mktemp() possibly used unsafely; consider using mkstemp() ed.lo: In function `_$$hide$$ ed.lo cbc_decode': (.text+0xddc): undefined reference to `DES_ecb_encrypt' ed.lo: In function `_$$hide$$ ed.lo cbc_encode': (.text+0xf81): undefined reference to `DES_ecb_encrypt' ed.lo: In function `_$$hide$$ ed.lo cbc_encode': (.text+0x100a): undefined reference to `DES_ecb_encrypt' ed.lo: In function `_$$hide$$ ed.lo get_keyword': (.text+0x1187): undefined reference to `DES_set_odd_parity' ed.lo: In function `_$$hide$$ ed.lo get_keyword': (.text+0x1194): undefined reference to `DES_set_key' ed.lo: In function `_$$hide$$ ed.lo set_des_key': (.text+0x15a3): undefined reference to `DES_set_odd_parity' ed.lo: In function `_$$hide$$ ed.lo set_des_key': (.text+0x15b4): undefined reference to `DES_set_key' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. make[5]: stopped in /usr/obj/usr/src/rescue/rescue *** Error code 1 --Sig_/rteT=z7Vjjn.fIRHm5Xi_V0 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJS4kOpAAoJEOgBcD7A/5N8IqwIALQTEcFElxTvXUYapRvHZffQ FqJ2VK+t5ATYPAcAG+2Pui2+NkWnOrUCpgnlhxpCUKFQAdxdIawEdTZHhJ0Bcw3O k0ytxroUqdiZGxA3O9dsAuEO950v50UEBPHHXI7miW1COLoDD57j5YLEsWTFO6XU Oj+DK1leXWVN5R1DqyC3/9sbdDZMjSaNAxB7EXLEbsh25FREPlyORKNPMo/FfcfN U6NDf6/qNxkrVNMrVq/CUr71vMrD0YTlkWj7sC2h+Um8hZDfcpewdvX7rkqBI0jE M8+MJ151J3AIOpLdeL37cI0GuC9Yuu4AodtfvG4Dbt9TbsyQfN+UGCiS48z0e7k= =ZPbO -----END PGP SIGNATURE----- --Sig_/rteT=z7Vjjn.fIRHm5Xi_V0-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 24 11:57:59 2014 Return-Path: Delivered-To: freebsd-current@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 000FBC9D for ; Fri, 24 Jan 2014 11:57:58 +0000 (UTC) Received: from nm24-vm2.access.bullet.mail.gq1.yahoo.com (nm24-vm2.access.bullet.mail.gq1.yahoo.com [216.39.63.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9DC8E151A for ; Fri, 24 Jan 2014 11:57:58 +0000 (UTC) Received: from [216.39.60.169] by nm24.access.bullet.mail.gq1.yahoo.com with NNFMP; 24 Jan 2014 11:52:00 -0000 Received: from [67.195.23.145] by tm5.access.bullet.mail.gq1.yahoo.com with NNFMP; 24 Jan 2014 11:52:00 -0000 Received: from [127.0.0.1] by smtp117.sbc.mail.gq1.yahoo.com with NNFMP; 24 Jan 2014 11:52:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1390564320; bh=9GAQGNT4jWKth/nMjaywMSUWTPHXIu34Q5Yhy2CYK2g=; h=X-Yahoo-Newman-Id:Message-ID:Date:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:From:To:CC:References:Subject; b=27JcCsGpa+ekFDHkhmlGeGTHDFzJq5iMFPiaQ6a9ZHlVmD7eZQ/pDcQN/GSkZ0/nhzez8GPDFGm5N8jQyf9A8+oRanW0yNFRiRTNll4VBBiY4QMHAksnViXskgw5i0DbNh3c+G/TZgQ1vLYRosysa6byviYqwVCZ6GfpyCOq0cY= X-Yahoo-Newman-Id: 610447.24251.bm@smtp117.sbc.mail.gq1.yahoo.com Message-ID: <610447.24251.bm@smtp117.sbc.mail.gq1.yahoo.com> Date: Fri, 24 Jan 2014 11:52:00 +0000 (UTC) X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: KwjxqD0VM1ksj6z3fbtd3SCutudeDdpAy0nSBcnIdFdRpcd KGKwkCQ34y0UI1aj2F7pPHhMB1Sl0E8QAFtrTiUYqDD5KQIK2tsw.ZiI29yD xAQcf3gNSq82FEmNRxVJGbtcI2KcpT8gNK_yrZlvLp.GWXH7eCT8AW4IS2.a ralQvojELXErwpPBSD5C656oYGhfVdvYlHHPQREGL275WZnKXUSIbsKkSkzM HbW.vdLe6K1guvNnSKjqZRBAc66QkFomchFVWVgPG0HPBb0_YbGiuboKf4jp OB0EapfdcRzMplotk1sWBvRgj1ivk42CbUJlSRUBI6ZxjZWOMNE1BRfXsNMr GiGt.IKSScC5Jt9Rnlaxi4oHtchF8bMY7z5DndIfiVhq1CiHDNLuORBY0sUc YKqT6oYGrnqmAZ..CEEyzlb5dhY6K0pt8YQ4lQEqTfouCKH3gbTlq3autt5I _MNjw4K9DTb.wulxboPLPFkxIuhxcvhTZaidVde0K8agmVSJmn.m5Z4UJh87 PsiaRYWDMujGmo.TwiSe7qC.uw2KPebNtS8cmJQIvskW0_CIzlT1hovzH1AH dlAqNRkKqde5GNJy_K1JhYj46u8ayCx23az9gQk3khSxp8nezBTnOZ2uL9sX 83QwR4j.RV6xb8ZNzqvowcMqXS6AxYb1px6VjCdTSpw-- X-Yahoo-SMTP: Kz_aW1.swBBYof3zAD7.RWzXz9ZAQVDMml1VADsbgPT4Kq79LC0- X-Rocket-Received: from localhost (mueller6724@96.28.178.143 with plain [67.195.15.66]) by smtp117.sbc.mail.gq1.yahoo.com with SMTP; 24 Jan 2014 11:52:00 +0000 UTC From: "Thomas Mueller" To: freebsd-current@freebsd.org References: Subject: Re: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC Cc: Adrian Chadd , Miguel Clara X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 11:57:59 -0000 To Miguel Clara, you might try a USB wireless adapter. I use Hiro H50191, driver rsu. But you would need to do good research to find what the chip is, and which FreeBSD driver, if any, would it work with, before you buy. NDISulator looks worth trying. FreeBSD users will want to know if it works. https://github.com/NDISulator/ndisulator Regarding deprecation of NDIS, is it a matter of something that is compatible with Linux but very difficult to port to BSD? There is the problem with newer MS-Windows drivers that they don't come with .sys and .inf files, or maybe they have to be unpacked and installed from MS-Windows. Then NDIS would have nothing to work with. Tom From owner-freebsd-current@FreeBSD.ORG Fri Jan 24 13:59:01 2014 Return-Path: Delivered-To: freebsd-current@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 34C07CD8 for ; Fri, 24 Jan 2014 13:59:01 +0000 (UTC) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E35A91F45 for ; Fri, 24 Jan 2014 13:59:00 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id e16so4334983qcx.24 for ; Fri, 24 Jan 2014 05:59:00 -0800 (PST) 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=FYtpGB5E3HISeD6l78TJxen6JUJGnfiWWs65Ycemt8g=; b=Ofi/ookReB4L7PH1TpHnVa5a8Ocawq7ccXJPByCK8JyONrq253QrwPGAtY0x5xeoTk YvQSbsLUrATdssVR8ET5JbSbChfG8ckDkQTsG0co5niGVHQbJ53Bm7UeSSh9bL4gW4W0 gnziqDbm7320hEPIwAIrrI/en+Lb/QL81aqSAEdOo9La71Is7+mdCqdSEnqr2XD2RwGu fn8vE8qYMhH7IEcH7V0H+iO4o/jOqtWDZd2qA+9sO38yBHKlaBLYlMT1ii7tFB2zIdva ubyIZVIR51kCvvdMmcQxswG/ixQ4cMctJkg0sj+Mwbya29Z4RrtqFc5zqnfszE6OR84a wkDw== MIME-Version: 1.0 X-Received: by 10.140.98.135 with SMTP id o7mr19201650qge.102.1390571940144; Fri, 24 Jan 2014 05:59:00 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Fri, 24 Jan 2014 05:59:00 -0800 (PST) In-Reply-To: <610447.24251.bm@smtp117.sbc.mail.gq1.yahoo.com> References: <610447.24251.bm@smtp117.sbc.mail.gq1.yahoo.com> Date: Fri, 24 Jan 2014 05:59:00 -0800 X-Google-Sender-Auth: 3PSdam81MglGhvkqjkOEBNX3vIc Message-ID: Subject: Re: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC From: Adrian Chadd To: Thomas Mueller Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current , Miguel Clara X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 13:59:01 -0000 ... who's the author of this? Why aren't they posting updates to FreeBSD-HEAD so it can be included in the base system? Does anyone have a contact email for the author, Vadislav? -a On 24 January 2014 03:52, Thomas Mueller wrote: > To Miguel Clara, you might try a USB wireless adapter. I use Hiro H50191, driver rsu. > > But you would need to do good research to find what the chip is, and which FreeBSD driver, if any, would it work with, before you buy. > > NDISulator looks worth trying. FreeBSD users will want to know if it works. > > https://github.com/NDISulator/ndisulator > > Regarding deprecation of NDIS, is it a matter of something that is compatible with Linux but very difficult to port to BSD? > > There is the problem with newer MS-Windows drivers that they don't come with .sys and .inf files, or maybe they have to be unpacked and installed from MS-Windows. Then NDIS would have nothing to work with. > > Tom > From owner-freebsd-current@FreeBSD.ORG Fri Jan 24 14:34:31 2014 Return-Path: Delivered-To: freebsd-current@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 E9791729 for ; Fri, 24 Jan 2014 14:34:31 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CAD7D12AE for ; Fri, 24 Jan 2014 14:34:31 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1W6hpw-0000Wy-EM for freebsd-current@freebsd.org; Fri, 24 Jan 2014 06:34:24 -0800 Date: Fri, 24 Jan 2014 06:34:24 -0800 (PST) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1390574064411-5879448.post@n5.nabble.com> In-Reply-To: <52E09F68.8020804@UToledo.edu> References: <52E09F68.8020804@UToledo.edu> Subject: Re: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 14:34:32 -0000 I've made a switch early. What gave me some bumps: - removal of ntfs module - vorbis-tools-1.4.0_6,3 with ogg123 missing (??) - ports built on db42 - malloc.conf - gcc48 entries in libmap.conf (my fault) - subversion-static looks broken a bit, nls problems e.g. $ sudo svn up Password: Service unavailableService unavailableService unavailableUpdating '.': -- View this message in context: http://freebsd.1045724.n5.nabble.com/Lessons-learned-from-source-upgrade-from-FreeBSD-i386-9-2-Stable-to-FreeBSD-i386-10-0-Release-tp5878896p5879448.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Fri Jan 24 14:52:06 2014 Return-Path: Delivered-To: freebsd-current@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 643B6DF5 for ; Fri, 24 Jan 2014 14:52:06 +0000 (UTC) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1F41E1470 for ; Fri, 24 Jan 2014 14:52:06 +0000 (UTC) Received: by mail-ve0-f182.google.com with SMTP id jy13so1984761veb.41 for ; Fri, 24 Jan 2014 06:52:05 -0800 (PST) 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=+7T7Gfalg1fhZpOXrgMunDzTQjR90U9NC2jI6haDSNE=; b=G7l3XwOnhPp3vSgn6d0doLMPxIoI74x+XIkSZQYFz1WtGOPU/BH5rnVAw78tG70kYB IiSPzzYVSZunuQfZeRYXFhG28SQgS8w+k8woOQMypA2ufktcHAiSeX6Hx+eyAGr8JxS8 9W5FDFHJwvayIeO1WIq/pLTYyK28wJsFRh/0/ChEBRxyCD9FNQLW6bZYk5iMG7IiC7La qd+OEe2zmI+Ub84dCNtgU93IGL92rsYYkJslbfcxw5HmxG7dbWeLoqMqcFvBZDNcuu1+ QP9wifGlR6Gp3R/8Ehgk1yCYOzNdsV6AFdLy819f2SGoHSNfL35MH6rnd+JZ1Otbakq6 Rn2Q== MIME-Version: 1.0 X-Received: by 10.220.139.136 with SMTP id e8mr4910238vcu.34.1390575125226; Fri, 24 Jan 2014 06:52:05 -0800 (PST) Received: by 10.220.168.135 with HTTP; Fri, 24 Jan 2014 06:52:05 -0800 (PST) In-Reply-To: References: Date: Fri, 24 Jan 2014 09:52:05 -0500 Message-ID: Subject: Re: lock order reversals w/ backtrace From: Thomas Hoffmann To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Hans Petter Selasky X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 14:52:06 -0000 On Thu, Jan 23, 2014 at 11:49 AM, Hans Petter Selasky < hans.petter.selasky@bitfrost.no> wrote: > Hi, > > Can you see if you can snap some keywords of the backtraces, like usb_xxx usbdx_xxx cam scsi or something like that. > > Else I believe there are some sysctl options to prevent the final reboot somehow so that you can write down the messages. > > --HPS > > > -----Original message----- > > From:Thomas Hoffmann > > Sent: Thursday 23rd January 2014 17:15 > > To: freebsd-current > > Subject: lock order reversals w/ backtrace > > > > A few days ago I started running 11.0-CURRENT at r260971 for the first time. > > > > The last couple of times I shutdown my system I noticed 2 or 3 short "lock > > order reversal" messages with accompanying backtraces scroll by. Do these > > messages represent a problem that I should report or can I ignore them as > > debug in nature? If I should report them, how or where do these messages > > get logged? I can find no reference to them in syslog or anywhere else upon > > my subsequent reboot. > > > > I also had a couple of these messages pop up the other day while > > mounting/umounting USB thumb drives. I did not think anything of them at > > the time as the mounts/umounts completed successfully. > > > > Please advise. Thanks. > > > > -Tom > > I managed to snap a photo of my screen during shutdown. Here is the full text of the first of two lock order reversals I got last night during system shutdown, both of which are zfs-related to (it appears?) unmounts. A few lines got chopped as they were out-of-frame when I took the photo: shutting down local daemons: lock order reversal: 1st 0xfffff801194f67c8 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237 2nd 0xfffff801194f6420 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:22[..chopped...] KDB: stack backtrace: db_trace_self_wrapper() at db_trace_delf_wrapper+0x2b/frame 0xfffffe01ac78[...chopped...] kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe01ac784650 witness_checkorder() at witness_checkorder+0xd23/frame 0xfffffe01ac7846e0 __lockmgr_args() __lockmgr_args+0x878/frame 0xfffffe01ac784810 vop_stdlock() at vop_stdlock+0x3c/frame 0xfffffe01ac784830 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfffffe01ac784860 _vn_lock() at _vn_lock+0xab/frame 0xfffffe01ac7848d0 vputx() at vputx+0x240/frame 0xfffffe01ac784930 dounmount at dounmount+0x327/frame 0xfffffe01ac7849b0 sys_unmount() at sys_unmount+0x356/frame 0xfffffe01ac784ac0 amd64_syscall() at amd64_syscall+0x265/frame 0xfffffe01ac784bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe01ac784bf0 --- syscall (22, FreeBSD ELF64, sys_unmount, rip = 0x80191c72a, rsp[...chopped...] I have a zpool on an external USB HDD that I export at shutdown via rc.shutdown.local. Don't know if that is contributing to this or not. When I get a chance to bring down the system I will manually export it before shutdown to see if that makes any difference. From owner-freebsd-current@FreeBSD.ORG Fri Jan 24 16:47:47 2014 Return-Path: Delivered-To: freebsd-current@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 513555F4; Fri, 24 Jan 2014 16:47:47 +0000 (UTC) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1AB1811AA; Fri, 24 Jan 2014 16:47:47 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id lf10so3462331pab.18 for ; Fri, 24 Jan 2014 08:47:46 -0800 (PST) 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=k+y+9eoRJSyynHMuU6m7ZVC8AAlNOizVQFwXR5zGsZ0=; b=oBx5t/ovXSa/l8BkdgRi4uKfTocEuha1uQDC8dnPneaCLE1YWAEme9ImLAl4o4jlle uXfn+XJ6GWc8oZaCg9U/cqe4Cnt6RWl50ndfZtSmDYJGkIk5TH8zKJDr/W78jQhMfrcH QJV1H2HPriYmNiLSxru3v8S3tAGxsyacjoSDSDlmxiPPuUGptENsQIuWrhEyHiLThg8F c1UxQCLwx3nkyIkSFDzFNDMaP8TEQD2QFjjwl2iUyvqADnXLht4Ljz0NUzJcDCRrzJrm wKh1+7gZHi5JWdaz1RRugUAAD1YX6ldLogG9z2pp96wkkmAVEUqC18qgcThXZn4bPH2C OFwQ== MIME-Version: 1.0 X-Received: by 10.66.27.107 with SMTP id s11mr15568645pag.64.1390582066378; Fri, 24 Jan 2014 08:47:46 -0800 (PST) Received: by 10.66.192.72 with HTTP; Fri, 24 Jan 2014 08:47:46 -0800 (PST) In-Reply-To: References: <610447.24251.bm@smtp117.sbc.mail.gq1.yahoo.com> Date: Fri, 24 Jan 2014 18:47:46 +0200 Message-ID: Subject: Re: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC From: Vlad Movchan To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Thomas Mueller , freebsd-current , Miguel Clara X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 16:47:47 -0000 NDISulator on github (and mirror on gitorious) is a FreeBSD ndis module+binaries forked by Paul B. Mahol in 2009 (I've sent Paul's email address privately to Adrian). Almost every change in this project was made by Paul. My part is small - I've just discovered and fixed several panic/problems. I've tried to submit my changes back to FreeBSD base tree via problem reports: One was commited: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165630 Another one is hanging without feedback: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165622 Few more fixes are depend on kern/165622. I have not created more PRs as without fix for panic described in 165622 new reports would be like: "I'm running something different than FreeBSD sources and it panics. And I have a fix for it. But you won't be able to reproduce and/or test it on your machine." I bet there are not much people who would like to spend their time on reports like this :) On Fri, Jan 24, 2014 at 3:59 PM, Adrian Chadd wrote: > ... who's the author of this? Why aren't they posting updates to > FreeBSD-HEAD so it can be included in the base system? > > Does anyone have a contact email for the author, Vadislav? > > > -a > > > On 24 January 2014 03:52, Thomas Mueller > wrote: > > To Miguel Clara, you might try a USB wireless adapter. I use Hiro > H50191, driver rsu. > > > > But you would need to do good research to find what the chip is, and > which FreeBSD driver, if any, would it work with, before you buy. > > > > NDISulator looks worth trying. FreeBSD users will want to know if it > works. > > > > https://github.com/NDISulator/ndisulator > > > > Regarding deprecation of NDIS, is it a matter of something that is > compatible with Linux but very difficult to port to BSD? > > > > There is the problem with newer MS-Windows drivers that they don't come > with .sys and .inf files, or maybe they have to be unpacked and installed > from MS-Windows. Then NDIS would have nothing to work with. > > > > Tom > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Have a nice day, Vlad Movchan From owner-freebsd-current@FreeBSD.ORG Fri Jan 24 16:50:03 2014 Return-Path: Delivered-To: freebsd-current@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 2603C71B; Fri, 24 Jan 2014 16:50:03 +0000 (UTC) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6F2A01219; Fri, 24 Jan 2014 16:50:02 +0000 (UTC) Received: by mail-lb0-f178.google.com with SMTP id u14so2715872lbd.37 for ; Fri, 24 Jan 2014 08:50:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=72rwKFEN0Abl3t84Qjvkxhb0szgMyrVd/aseFOuyTVA=; b=YTTZq5mEq3jEZESa03ldcbdWsX5dnettYnPCeXSJqeHkjrZlD4WuT0GjSKt5/LWTc/ 9KhsmsOjA5JR3yPZQtoDLCJCZFDzNixBJXIXHzP9L04lXqtMjXofdeO01hRwycQBb72d I/vx2fEgLTnOYHZTvNPZ3zBSklKv3A3UG7nQiFJxDhlIaxm34RpY/8XRHh57esl9llkh uM3tx4ad8Uzwu4SszKadzP8NCpTzv+B6AwhxnL1fkukZlWS6tG4i1bztdGwpsHXOvMJf 2Ng16kRlwU0UpAa9Y0/1wTA3AHdA3MDdbsLU7jJB9se+uDVlNITMPuwRPcU+Hy2/VmFT 19Lw== X-Received: by 10.112.157.234 with SMTP id wp10mr765138lbb.50.1390582200390; Fri, 24 Jan 2014 08:50:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.62.163 with HTTP; Fri, 24 Jan 2014 08:49:40 -0800 (PST) In-Reply-To: References: <610447.24251.bm@smtp117.sbc.mail.gq1.yahoo.com> From: Miguel Clara Date: Fri, 24 Jan 2014 16:49:40 +0000 Message-ID: Subject: Re: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Thomas Mueller , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 16:50:03 -0000 NOTE: tried NDISulator pciconf -lv | grep -i bcm -B2 none2@pci0:13:0:0: class=0x028000 card=0x145c103c chip=0x472714e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM4313 802.11b/g/n Wireless LAN Controller' # ndisload -p -s /home/user/bcmWireless/bcmwl564.sys -n bcmw -v 0x14e4 -d 0x4721 and get this in dmesg: NDIS: no match for ZwQueryInformationFile I'll report it in the github page, but it seems its not working! # tail /var/log/messages Jan 24 16:44:37 hpbsd kernel: NDIS: no match for ZwQueryInformationFile Jan 24 16:46:10 hpbsd kernel: NDIS: no match for ZwQueryInformationFile Jan 24 16:48:27 hpbsd kernel: Warning: memory type ndis_ntoskrnl leaked memory on destroy (8 allocations, 2304 bytes leaked). On Fri, Jan 24, 2014 at 1:59 PM, Adrian Chadd wrote: > ... who's the author of this? Why aren't they posting updates to > FreeBSD-HEAD so it can be included in the base system? > > Does anyone have a contact email for the author, Vadislav? > > > -a > > > On 24 January 2014 03:52, Thomas Mueller wrote: >> To Miguel Clara, you might try a USB wireless adapter. I use Hiro H50191, driver rsu. >> >> But you would need to do good research to find what the chip is, and which FreeBSD driver, if any, would it work with, before you buy. >> >> NDISulator looks worth trying. FreeBSD users will want to know if it works. >> >> https://github.com/NDISulator/ndisulator >> >> Regarding deprecation of NDIS, is it a matter of something that is compatible with Linux but very difficult to port to BSD? >> >> There is the problem with newer MS-Windows drivers that they don't come with .sys and .inf files, or maybe they have to be unpacked and installed from MS-Windows. Then NDIS would have nothing to work with. >> >> Tom >> From owner-freebsd-current@FreeBSD.ORG Fri Jan 24 16:52:21 2014 Return-Path: Delivered-To: freebsd-current@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 88E8DA57; Fri, 24 Jan 2014 16:52:21 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D2417123F; Fri, 24 Jan 2014 16:52:20 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id hr17so2774072lab.34 for ; Fri, 24 Jan 2014 08:52:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VV9lRpAdkXDR72OKyY+RRCLfs/dxKwtKg+Y2fd+ro5Y=; b=oCbu3UmxmM8y9Bnns4HZ820PbOSHsyDMFtjJWp/6MkudfTPfpCYs5+slMu0YOR2mn7 tJ5Dqo9mLbV43y7IXHFgnwREHFJGK3VuShgYBbvB5zGQIbBPgl5c0B8XdANZYyis7/DG 6bUWMqhmLudPt3Q9yKEQfE2ooxwnvTxuDrfEgOR08gmvhFKq+8VjGPS+Z22JGsBT/buL OxBVuduvloLIu3GSvkKXiS2wIsOhIlhze11I+Dqb+q/dIyZ6ZRbvhdnPKtlKsZdWDIOe LfUIZVc9UEDmtAUFFmlIG0JqLrORbqCp88Ibk1CpACbRILxfrYZ/MM0V40Va1k7odjN+ gZ6g== X-Received: by 10.112.148.104 with SMTP id tr8mr1947610lbb.42.1390582338797; Fri, 24 Jan 2014 08:52:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.62.163 with HTTP; Fri, 24 Jan 2014 08:51:58 -0800 (PST) In-Reply-To: References: <610447.24251.bm@smtp117.sbc.mail.gq1.yahoo.com> From: Miguel Clara Date: Fri, 24 Jan 2014 16:51:58 +0000 Message-ID: Subject: Re: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Thomas Mueller , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 16:52:21 -0000 Ah.. my bad its "0x47217" not 21 :P works: ndis0: flags=8802 metric 0 mtu 1500 ether ac:81:12:35:79:73 nd6 options=29 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect ) status: no carrier On Fri, Jan 24, 2014 at 4:49 PM, Miguel Clara wrote: > NOTE: tried NDISulator > > pciconf -lv | grep -i bcm -B2 > none2@pci0:13:0:0: class=0x028000 card=0x145c103c chip=0x472714e4 > rev=0x01 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM4313 802.11b/g/n Wireless LAN Controller' > > > # ndisload -p -s /home/user/bcmWireless/bcmwl564.sys -n bcmw -v 0x14e4 -d 0x4721 > > > and get this in dmesg: > > NDIS: no match for ZwQueryInformationFile > > > I'll report it in the github page, but it seems its not working! > > > # tail /var/log/messages > Jan 24 16:44:37 hpbsd kernel: NDIS: no match for ZwQueryInformationFile > Jan 24 16:46:10 hpbsd kernel: NDIS: no match for ZwQueryInformationFile > Jan 24 16:48:27 hpbsd kernel: Warning: memory type ndis_ntoskrnl > leaked memory on destroy (8 allocations, 2304 bytes leaked). > > On Fri, Jan 24, 2014 at 1:59 PM, Adrian Chadd wrote: >> ... who's the author of this? Why aren't they posting updates to >> FreeBSD-HEAD so it can be included in the base system? >> >> Does anyone have a contact email for the author, Vadislav? >> >> >> -a >> >> >> On 24 January 2014 03:52, Thomas Mueller wrote: >>> To Miguel Clara, you might try a USB wireless adapter. I use Hiro H50191, driver rsu. >>> >>> But you would need to do good research to find what the chip is, and which FreeBSD driver, if any, would it work with, before you buy. >>> >>> NDISulator looks worth trying. FreeBSD users will want to know if it works. >>> >>> https://github.com/NDISulator/ndisulator >>> >>> Regarding deprecation of NDIS, is it a matter of something that is compatible with Linux but very difficult to port to BSD? >>> >>> There is the problem with newer MS-Windows drivers that they don't come with .sys and .inf files, or maybe they have to be unpacked and installed from MS-Windows. Then NDIS would have nothing to work with. >>> >>> Tom >>> From owner-freebsd-current@FreeBSD.ORG Fri Jan 24 18:16:45 2014 Return-Path: Delivered-To: freebsd-current@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 7FD7CB39 for ; Fri, 24 Jan 2014 18:16:45 +0000 (UTC) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 375281A8C for ; Fri, 24 Jan 2014 18:16:45 +0000 (UTC) Received: by mail-qc0-f181.google.com with SMTP id e9so4883011qcy.12 for ; Fri, 24 Jan 2014 10:16:44 -0800 (PST) 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=fNhiYPhMMuRdL3ZSgsMdXAXEzLRcG/75Onu7L+oXNtc=; b=XgIAL5kRKqGy0pKpLcRCqK1RZGPCkDRjbLSp2LRd6VPwqMZmJgIh61CH+Sd+0v3wWK as7gFtk6WNATJKIUiHE50323IbVVYNaa2D0LbFXvWsXfnQAU+QqR948VNjvCvVvIG+wh zrhAcAUyGAuyJC2Gz2XETvGDF8aOhy/I3RsTUHkrYV1RACOd3ToDL51TTsX0+Kd+rg5R 1L8Yg6Pf5/GYoZIHy+Gv9mmvt+vim8uPez2URDbTlO08Vceg+udWV4/QkkLQQRlUfiD9 hHrFRUN2o4Tm3U5o+++GbLLSTkBmv4H4VS/GymX5NRTR0PEjodqZNiuKSbSig0A7wmuC zuNw== MIME-Version: 1.0 X-Received: by 10.224.46.8 with SMTP id h8mr23014444qaf.49.1390587404402; Fri, 24 Jan 2014 10:16:44 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Fri, 24 Jan 2014 10:16:44 -0800 (PST) In-Reply-To: References: <610447.24251.bm@smtp117.sbc.mail.gq1.yahoo.com> Date: Fri, 24 Jan 2014 10:16:44 -0800 X-Google-Sender-Auth: nMmUGbPIp-gooR0ewVLayvPD8WM Message-ID: Subject: Re: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC From: Adrian Chadd To: Vlad Movchan Content-Type: text/plain; charset=ISO-8859-1 Cc: Thomas Mueller , freebsd-current , Miguel Clara X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 18:16:45 -0000 On 24 January 2014 08:47, Vlad Movchan wrote: > NDISulator on github (and mirror on gitorious) is a FreeBSD ndis > module+binaries forked by Paul B. Mahol in 2009 (I've sent Paul's email > address privately to Adrian). > Almost every change in this project was made by Paul. > My part is small - I've just discovered and fixed several panic/problems. Is i kept up to date with -head changes? > I've tried to submit my changes back to FreeBSD base tree via problem > reports: > One was commited: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165630 > Another one is hanging without feedback: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165622 > > Few more fixes are depend on kern/165622. I have not created more PRs as > without fix for panic described in 165622 new reports would be like: > "I'm running something different than FreeBSD sources and it panics. And I > have a fix for it. But you won't be able to reproduce and/or test it on your > machine." > I bet there are not much people who would like to spend their time on > reports like this :) > HI, Well, someone needs to break the fork up into pieces and submit those. The FPU change is a good candidate - but it needs to be a sepaate PR for that. So, how about we start with the fpu change? Get it into a separate enhancement PR, then email -arch and -current. I'll help you get it reviewed and put into -head. -a From owner-freebsd-current@FreeBSD.ORG Fri Jan 24 19:31:46 2014 Return-Path: Delivered-To: freebsd-current@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 AD462421 for ; Fri, 24 Jan 2014 19:31:46 +0000 (UTC) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7B522116E for ; Fri, 24 Jan 2014 19:31:46 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 631DD20CA1 for ; Fri, 24 Jan 2014 14:31:40 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Fri, 24 Jan 2014 14:31:40 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=zcCC4y6VcJCPqkQOcw3TplwADjA=; b=Mq6 +PKxgeEWNOlk4rR6kNELWKLtA22mP4RQNDjKxeUIgv3Iz23zi/yON3I8H6UwE8kp 0tkZL8QydwP42jo5sjJ0SX5YaD+girIl7qT53wlqCX1yYxp61ApMVdPH/6rzmFNs D+joVM4zJElPg+6yA9mi3r2hY++gnw2QxAMCNxSM= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 42ABC11219B; Fri, 24 Jan 2014 14:31:40 -0500 (EST) Message-Id: <1390591900.23972.74968289.53788D17@webmail.messagingengine.com> X-Sasl-Enc: avC2R+bwzghOspjrL6zwuRJRp4RmTag+6PUzK6DEZtY/ 1390591900 From: Mark Felder To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-aec78a11 In-Reply-To: References: <5F09668C-0DEA-4074-A06C-BC4D29F92368@FreeBSD.org> <201401211149.45793.jhb@freebsd.org> Subject: Re: freebsd-update Date: Fri, 24 Jan 2014 13:31:40 -0600 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 19:31:46 -0000 I agree with the rest of this thread. This is just awful. I'm basically forced to do source based updates when jumping major versions because freebsd-update is a nightmare to use. From owner-freebsd-current@FreeBSD.ORG Fri Jan 24 19:46:29 2014 Return-Path: Delivered-To: freebsd-current@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 854A7771 for ; Fri, 24 Jan 2014 19:46:29 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 40F40123A for ; Fri, 24 Jan 2014 19:46:28 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.146.73]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 207F854171 for ; Fri, 24 Jan 2014 19:40:41 +0000 (UTC) Message-ID: <52E2C1BC.10202@allanjude.com> Date: Fri, 24 Jan 2014 14:40:44 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: freebsd-update References: <5F09668C-0DEA-4074-A06C-BC4D29F92368@FreeBSD.org> <201401211149.45793.jhb@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Arq91lVgAp7o36hCdNUACGat4Iukbast5" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 19:46:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Arq91lVgAp7o36hCdNUACGat4Iukbast5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-01-21 15:42, Kevin Oberman wrote: > On Tue, Jan 21, 2014 at 8:49 AM, John Baldwin wrote: > >> On Tuesday, January 21, 2014 10:46:37 am David Chisnall wrote: >>> On 21 Jan 2014, at 07:13, Antonio Olivares >> wrote: >>>> On Tue, Jan 21, 2014 at 7:49 AM, Ivan Voras >> wrote: >>>>> Hi, >>>>> >>>>> Is there any way I can avoid manually resolving hundreds of merge >>>>> conflicts of the following type while using freebsd-update ? >>>>> >>>>> 1 <<<<<<< current version >>>>> >>>>> >>>>> 2 # $FreeBSD: release/9.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:1= 0Z >>>>> peter $ >>>>> >>>>> 3 =3D=3D=3D=3D=3D=3D=3D >>>>> >>>>> >>>>> 4 # $FreeBSD: release/10.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:= 10Z >>>>> peter $ >>>>> >>>>> 5 >>>>>>> 10.0-RELEASE >>>>> >>>>> >>>>> >>>>> ? >>>>> >>>>> I can't be the only one seeing those...? >>>>> >>>> Yes, One has to manually go one by one to fix these :( >>>> I tried at one point a sed command like sed -i "" '>>>>' to fix >>>> these, but it did not work correctly. I see errrors when booting wh= en >>>> I don't correct these :( >>> I thought this was fixed already (I didn't see these in the 9.2->10-R= C3 >> upgrade). Doesn't freebsd-update pass -F (If the files differ only by= VCS >> Id >> ($FreeBSD) install the new file) to mergemaster? >> >> AFAIK it doesn't use mergemaster? I thought it used its own tool? I >> really >> want to figure out a way to let it use etcupdate instead since it hand= les >> this case even for locally modified files cleanly. >> > Having just gone through this on a 10.0-rc5 to 10.0-RELEASE run, I can > assure you that it is not completely fixed. One huge part is fixed... e= very > file's ID line is no longer is changed on every release. OTOH, for file= s > that are modified, thy still show up. It hit many of the sendmail .cf > files. Annoying as I don't even use sendmail. > > Not sure if there was a good reason Colin re-invented the wheel on this= =2E It > does not use mergemaster or even a reasonable differences editor such a= s > the one mergemaster uses. Just going to the mergemaster code for handli= ng > diffs would be a HUGE win. I am getting really tired of > "/<<<<3ddddn". I discussed this a bit with Colin on Wednesday during our interview with him for BSDNow.tv He had some problems with mergemaster so wrote his own tool. In 10 it ignores the $Id tags, but there are still other changes that have to either be merged or the file replaced with the new one. I am all for further improvement here. --=20 Allan Jude --Arq91lVgAp7o36hCdNUACGat4Iukbast5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS4sHBAAoJEJrBFpNRJZKf82kP/iDgK60klkTEAbppXOKzixIu 4OSX9UGkdt5A/dgVWkp+E3WnZoGVOkh1dcVOlyewo80zVD+E+GpCbBSJ762Rz5WS 4uM+63ouZgDKr9fl9s9jIHOG+yv8+yv2oWAzIUoi/UACfTlPNvAeiQqDsPMW0o6e Q19C+gwYQv7c8sl6EiA7eKnLNd9CLrUSjpbI9+nMb6cDkWPMYvHDxw03EPECX9ai ayuZ/R3d5JjB8zj+hZ+YZJlLjdsIhel/KClx2ftNCJS+KZeDwmj41k1dSiZm2vwT u4Y4D+oyl8Izj5k5kfdSVpf7ekUyaWkVrKxrroEKcKdoc5LaO7jTXlqDwBX5sGrQ wmjp1v7QFQiUA6R0oNfFJKnEWITvaSMl64sLYts+Upsav3QkWXeoKmTMjZPAtYDU Uh4pNrAP2PlVmgloGK1Gd8kPMXcovc+Mz4+BMgO3jSERzVjx0BAUpcB/ujwXAZ5u IPjMIHQLsp6r9t5c4G8GO0d13My+wssWKgd9laH3MhvP56i/VsTDaQca6POQDOV9 wRfPgRtjG1Vnz4bA671l5RPhTEXcoRITQu6vFxrcQIaaQix1fxoWGkPuSQyxtphF ZqcVkQUIsM35nvHY9pW35Rc3ZlMSSwWAh8yjHMn+Ox/Q/Vd2IK6O8IY08ovChAt3 BIRlNVJcLQj97KooML07 =wUWy -----END PGP SIGNATURE----- --Arq91lVgAp7o36hCdNUACGat4Iukbast5-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 24 20:11:28 2014 Return-Path: Delivered-To: freebsd-current@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 CC3A7275; Fri, 24 Jan 2014 20:11:28 +0000 (UTC) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6CC5114B8; Fri, 24 Jan 2014 20:11:28 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id cm18so4473269qab.12 for ; Fri, 24 Jan 2014 12:11:27 -0800 (PST) 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=pKTqW+95oOytjHK89j7aOjS5z4lre/biNoT8hT2algI=; b=yajmY2R/JaYExdZcrMdNeAqP6MwWdOW9sua1wdt1Z9Dxve34tFyZ2xe0QSRQDivSB1 srIiUdy8U/yD+K4cfHGsDMFxZy1TCegmM3B7DUNDdclXcasQV7mvPQ4v5m0OUTZY6yGH /fb7SbmxyY99TePC/Srbbuob/iNLvc55m1gc6ymtNShvO5nA3/ITbJ8Opavz9nBnTQnz rMQqvq+MGXk5sTEbmQJ5siOo4Bte3AEXjnq1bUCVVzwcKhBumR+7V8NdILAtc2nQfjyV dXnEOdHJPuEMiTA6slfA+jusrUmrrhNEAaKZkCW/SDorDMkwUaxwO1MTxsoOYbJKo8iD p4mw== MIME-Version: 1.0 X-Received: by 10.140.105.35 with SMTP id b32mr22389826qgf.36.1390594287695; Fri, 24 Jan 2014 12:11:27 -0800 (PST) Received: by 10.140.25.129 with HTTP; Fri, 24 Jan 2014 12:11:27 -0800 (PST) In-Reply-To: References: <610447.24251.bm@smtp117.sbc.mail.gq1.yahoo.com> Date: Fri, 24 Jan 2014 22:11:27 +0200 Message-ID: Subject: Re: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC From: Vlad Movchan To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Thomas Mueller , freebsd-current , Miguel Clara X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 20:11:29 -0000 On Fri, Jan 24, 2014 at 8:16 PM, Adrian Chadd wrote: > > Is i kept up to date with -head changes? > > As far as I know it was kept up to date with -head changes. HI, > > Well, someone needs to break the fork up into pieces and submit those. > The FPU change is a good candidate - but it needs to be a sepaate PR > for that. > > So, how about we start with the fpu change? Get it into a separate > enhancement PR, then email -arch and -current. I'll help you get it > reviewed and put into -head. > > > -a > Sounds good, I'll try. Thank you. -- Have a nice day, Vlad Movchan From owner-freebsd-current@FreeBSD.ORG Fri Jan 24 21:28:22 2014 Return-Path: Delivered-To: freebsd-current@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 2E76461B for ; Fri, 24 Jan 2014 21:28:22 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BA3071A10 for ; Fri, 24 Jan 2014 21:28:21 +0000 (UTC) Received: from [10.11.96.123] ([213.61.179.114]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LtZfc-1V895V19eO-010rIS for ; Fri, 24 Jan 2014 22:28:13 +0100 Message-ID: <52E2DAF3.4000802@gmx.de> Date: Fri, 24 Jan 2014 22:28:19 +0100 From: olli hauer User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: freebsd-update References: <5F09668C-0DEA-4074-A06C-BC4D29F92368@FreeBSD.org> <201401211149.45793.jhb@freebsd.org> <1390591900.23972.74968289.53788D17@webmail.messagingengine.com> In-Reply-To: <1390591900.23972.74968289.53788D17@webmail.messagingengine.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:AyD3BlwtVHVOnYPsTVzpCt65V4QJzUeX5jLoT8FlZvdd9o8901o 1lsBIjTqBNnYhctE0rPvDo89RjE816mHlKLnuLoFST/Sj4z+1lljmtuuF6zNi9bzUXS1wpj zZr92AjFl/jGcnzHnUzQRldvj4y+nL9ZmjhUxlLmtu95mymrUHG2OSP5cHMjgJ11LaxtJlV np2UG1W1gdoddgnHLEMOg== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 21:28:22 -0000 On 2014-01-24 20:31, Mark Felder wrote: > I agree with the rest of this thread. This is just awful. I'm basically > forced to do source based updates when jumping major versions because > freebsd-update is a nightmare to use. Not tested, but maybe this works. a) use etcmerge before freebsd-upgrade and exclude /etc in freebsd-update.conf b) manually extract the sources, then use mergemaster and then run freebsd-update c) if you have more then one system fix once freebsd-update and deploy the script to the rest of the systems I use myself a mix of mergemaster and upgrade via the (kernel|src|man|...).txz and base.txz (exclude ^./etc). Going this way since 6.x and also major upgrades 6.x->7.x->8.x ... main issue on older systems is the space required by the kernel symbols. From owner-freebsd-current@FreeBSD.ORG Fri Jan 24 21:52:12 2014 Return-Path: Delivered-To: freebsd-current@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 4B1D1D47 for ; Fri, 24 Jan 2014 21:52:12 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2B47B1CFC for ; Fri, 24 Jan 2014 21:52:10 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1W6ofZ-0005MM-PL for freebsd-current@freebsd.org; Fri, 24 Jan 2014 13:52:09 -0800 Date: Fri, 24 Jan 2014 13:52:09 -0800 (PST) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1390600329779-5879565.post@n5.nabble.com> In-Reply-To: <1390574064411-5879448.post@n5.nabble.com> References: <52E09F68.8020804@UToledo.edu> <1390574064411-5879448.post@n5.nabble.com> Subject: Re: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 21:52:12 -0000 Unfortunately, I think there is measurable penalty going to BSD licensed tools, same system: http://pastebin.com/BNfhevBa -- View this message in context: http://freebsd.1045724.n5.nabble.com/Lessons-learned-from-source-upgrade-from-FreeBSD-i386-9-2-Stable-to-FreeBSD-i386-10-0-Release-tp5878896p5879565.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Fri Jan 24 22:01:46 2014 Return-Path: Delivered-To: freebsd-current@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 55917311 for ; Fri, 24 Jan 2014 22:01:46 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2E11B1DD8 for ; Fri, 24 Jan 2014 22:01:46 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 35351B99B; Fri, 24 Jan 2014 17:01:45 -0500 (EST) From: John Baldwin To: Ilya Bakulin Subject: Re: installworld for -CURRENT is broken on 9.1-R Date: Fri, 24 Jan 2014 16:25:52 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <52E2D027.9020604@bakulin.de> In-Reply-To: <52E2D027.9020604@bakulin.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201401241625.52839.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 24 Jan 2014 17:01:45 -0500 (EST) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 22:01:46 -0000 On Friday, January 24, 2014 3:42:15 pm Ilya Bakulin wrote: > Hi John, > > seems that your commit 261030 has broken installworld target when the > installation is done on 9.1-RELEASE (and, actually, all releases > before). Installing world fails with the following error: > > cd > /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd- git/freebsd/etc; > install -N > /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd- git/freebsd/etc > -o root -g wheel -m 644 crontab devd.conf devfs.conf ddb.conf > dhclient.conf disktab fbtab ftpusers gettytab group hosts > hosts.allow hosts.equiv inetd.conf libalias.conf libmap.conf > login.access login.conf mac.conf motd netconfig network.subr > networks newsyslog.conf nsswitch.conf phones profile protocols rc > rc.bsdextended rc.firewall rc.initdiskless rc.sendmail rc.shutdown > rc.subr remote rpc services shells sysctl.conf syslog.conf > termcap.small etc.i386/ttys snmpd.config hosts.lpd printcap ntp.conf > pf.os csh.cshrc csh.login csh.logout regdomain.xml > /home/kibab/repos/freebsd-git/gs0/obj/_.w/etc; cap_mkdb -l > /home/kibab/repos/freebsd-git/gs0/obj/_.w/etc/login.conf; services_mkdb > -l -q -o /home/kibab/repos/freebsd-git/gs0/obj/_.w/var/db/services.db > /home/kibab/repos/freebsd-git/gs0/obj/_.w/etc/services; install -N > /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd- git/freebsd/etc > -o root -g wheel -m 755 netstart pccard_ether rc.suspend rc.resume > /home/kibab/repos/freebsd-git/gs0/obj/_.w/etc; install -N > /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd- git/freebsd/etc > -o root -g wheel -m 600 master.passwd nsmb.conf opieaccess > /home/kibab/repos/freebsd-git/gs0/obj/_.w/etc; > services_mkdb: illegal option -- l > Usage: services_mkdb [-q] [-o ] [] > services_mkdb -u [] > *** Error code 1 > > Stop. > bmake[1]: stopped in > /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd- git/freebsd/etc > *** Error code 1 > > Stop. > bmake: stopped in > /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd-git/freebsd > *** [distribution] Error code 1 > > Stop in > /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd-git/freebsd. > > > So services_mkdb is taken from base system, and it indeed doesn't have > -l switch introduced by your commit. This isn't from installworld. 'make distribute' doesn't get run as part of 'installworld'. Can you tell me what command you actually ran? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jan 24 23:22:50 2014 Return-Path: Delivered-To: freebsd-current@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 22876524 for ; Fri, 24 Jan 2014 23:22:50 +0000 (UTC) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CC5C9136A for ; Fri, 24 Jan 2014 23:22:49 +0000 (UTC) Received: by mail-qc0-f173.google.com with SMTP id i8so5320030qcq.32 for ; Fri, 24 Jan 2014 15:22:49 -0800 (PST) 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=9j6DYkHifLALbavth9BVeOxOZf0XNuLKKhBzWchl/7c=; b=Mu+uDTBiv4JEzT7GGFYVDQvRZnf75oqya6KSA70u2qf1UqLnsmwvsY39bLoKsWjX7r cp+8zJDXmo1eTE5XyWfI4FdwnD80nzA+qFcFHAAMbobnRz+BVK/3KAoM3cJUSjXCRYzc JYJsAOMaJGgef/NBR5G8AGjKw+jHckYrkYfY1zVYSM3zLWaaQPkilqFxhaf+GXoQpH11 SZ4dGbM173JClrrbNGfV4Vims5gZRteE2QTk7imSxlJDzwbOw2FJFjjNio7wuYm0VxcT IgKsAZhAiZUtJFqDyAjZOhDCUIvw6hqh3c+UTPQ5V2psKMzhZNOxIBxrxGxk/xkl7PvI leLQ== MIME-Version: 1.0 X-Received: by 10.140.24.71 with SMTP id 65mr23509681qgq.12.1390605769031; Fri, 24 Jan 2014 15:22:49 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Fri, 24 Jan 2014 15:22:48 -0800 (PST) In-Reply-To: References: <610447.24251.bm@smtp117.sbc.mail.gq1.yahoo.com> Date: Fri, 24 Jan 2014 15:22:48 -0800 X-Google-Sender-Auth: GXJViD_P95DvQorzkXded2eL87Q Message-ID: Subject: Re: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC From: Adrian Chadd To: Vlad Movchan Content-Type: text/plain; charset=ISO-8859-1 Cc: Thomas Mueller , freebsd-current , Miguel Clara X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 23:22:50 -0000 Oh! The NDIS FPU patch is limited to the NDIS module. Tell you what, I'll get that committed to -HEAD soon. Would you poke the original author and see if he's willing to work with you and I on getting this stuff into -HEAD? -a From owner-freebsd-current@FreeBSD.ORG Fri Jan 24 20:42:18 2014 Return-Path: Delivered-To: freebsd-current@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 10119A48; Fri, 24 Jan 2014 20:42:18 +0000 (UTC) Received: from olymp.kibab.com (olymp6.kibab.com [IPv6:2a01:4f8:160:84c1::2]) by mx1.freebsd.org (Postfix) with ESMTP id C708216F2; Fri, 24 Jan 2014 20:42:17 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com E30C73F438 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1390596136; bh=gVxyrwEqauAHgKDNrWCSEmWuF9bZgJB743wlEA7Nphg=; h=Date:From:To:CC:Subject; b=JKh/sbxRNLSXrUFlKGkqPr+po+KozqW1X2CFjTmG7NIo+GCoT3iV6+b1hPZex3Yho 10udGS/5MvVV9NoNyH1JgS4QWu8cfG7TTtnnAyKMm12OQF6mhFu/DUNZqcy3Dfef/R JUvpCQbMMkIYPZB7BMziv18lTI9JieKgw2mpRylA= Message-ID: <52E2D027.9020604@bakulin.de> Date: Fri, 24 Jan 2014 21:42:15 +0100 From: Ilya Bakulin MIME-Version: 1.0 To: John Baldwin Subject: installworld for -CURRENT is broken on 9.1-R Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 24 Jan 2014 23:51:12 +0000 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 20:42:18 -0000 Hi John, seems that your commit 261030 has broken installworld target when the installation is done on 9.1-RELEASE (and, actually, all releases before). Installing world fails with the following error: cd /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd-git/freebsd/etc; install -N /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd-git/freebsd/etc -o root -g wheel -m 644 crontab devd.conf devfs.conf ddb.conf dhclient.conf disktab fbtab ftpusers gettytab group hosts hosts.allow hosts.equiv inetd.conf libalias.conf libmap.conf login.access login.conf mac.conf motd netconfig network.subr networks newsyslog.conf nsswitch.conf phones profile protocols rc rc.bsdextended rc.firewall rc.initdiskless rc.sendmail rc.shutdown rc.subr remote rpc services shells sysctl.conf syslog.conf termcap.small etc.i386/ttys snmpd.config hosts.lpd printcap ntp.conf pf.os csh.cshrc csh.login csh.logout regdomain.xml /home/kibab/repos/freebsd-git/gs0/obj/_.w/etc; cap_mkdb -l /home/kibab/repos/freebsd-git/gs0/obj/_.w/etc/login.conf; services_mkdb -l -q -o /home/kibab/repos/freebsd-git/gs0/obj/_.w/var/db/services.db /home/kibab/repos/freebsd-git/gs0/obj/_.w/etc/services; install -N /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd-git/freebsd/etc -o root -g wheel -m 755 netstart pccard_ether rc.suspend rc.resume /home/kibab/repos/freebsd-git/gs0/obj/_.w/etc; install -N /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd-git/freebsd/etc -o root -g wheel -m 600 master.passwd nsmb.conf opieaccess /home/kibab/repos/freebsd-git/gs0/obj/_.w/etc; services_mkdb: illegal option -- l Usage: services_mkdb [-q] [-o ] [] services_mkdb -u [] *** Error code 1 Stop. bmake[1]: stopped in /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd-git/freebsd/etc *** Error code 1 Stop. bmake: stopped in /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd-git/freebsd *** [distribution] Error code 1 Stop in /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd-git/freebsd. So services_mkdb is taken from base system, and it indeed doesn't have -l switch introduced by your commit. -- Regards, Ilya Bakulin From owner-freebsd-current@FreeBSD.ORG Sat Jan 25 01:12:54 2014 Return-Path: Delivered-To: freebsd-current@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 1CE86300; Sat, 25 Jan 2014 01:12:54 +0000 (UTC) Received: from luigi.brtsvcs.net (luigi.brtsvcs.net [IPv6:2607:fc50:1000:1f00::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E19601D53; Sat, 25 Jan 2014 01:12:53 +0000 (UTC) Received: from chombo.houseloki.net (c-76-115-19-22.hsd1.or.comcast.net [76.115.19.22]) by luigi.brtsvcs.net (Postfix) with ESMTPSA id 5FB302D4FB2; Fri, 24 Jan 2014 17:12:52 -0800 (PST) Received: from [IPv6:2601:7:880:bd0:b40d:eb14:4f81:f42f] (unknown [IPv6:2601:7:880:bd0:b40d:eb14:4f81:f42f]) by chombo.houseloki.net (Postfix) with ESMTPSA id 84ABE4F3; Fri, 24 Jan 2014 17:12:50 -0800 (PST) Message-ID: <52E30F9C.7090607@bluerosetech.com> Date: Fri, 24 Jan 2014 17:13:00 -0800 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mark Felder , freebsd-current@freebsd.org Subject: Re: freebsd-update References: <5F09668C-0DEA-4074-A06C-BC4D29F92368@FreeBSD.org> <201401211149.45793.jhb@freebsd.org> <1390591900.23972.74968289.53788D17@webmail.messagingengine.com> In-Reply-To: <1390591900.23972.74968289.53788D17@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 01:12:54 -0000 On 1/24/2014 11:31 AM, Mark Felder wrote: > I agree with the rest of this thread. This is just awful. I'm basically > forced to do source based updates when jumping major versions because > freebsd-update is a nightmare to use. I've yet to go through a freebsd-update process that didn't require a manual clean-up afterward. It's easier (and faster) to build an obj tree on my desktop, ship it to my servers via NFS over a tunnel. Another scenario I've run into more than once: - Install release m.x - Realize there's a kernel/driver bug, fixed in m-stable - Source upgrade to m-stable - Release m.z happens, contains fix - Freebsd-update upgrade to m.z The updater will discover that all of /etc differs by $Id tag. A few will have non-edit differences. The rest are either default-empty files or files not found in the distribution (pf.conf, sshd keys, etc.). Freebsd-update will force me to manually approve every single change. With mergemaster, automatic upgrade takes care of all but the edits and provides a MUCH nicer diff editor for those. Mergemaster is a <1 minute process, even on I/O-constrained hardware. I understand that when freebsd-update was written there were "some problems" with the existing install/merge tools used for source upgrades; but I have to wonder: what issues could be so bad that the above is the lesser evil? Freebsd-update's merge needs to learn what mergemaster's can do. Until then, freebsd-update is a non-starter, IMO. From owner-freebsd-current@FreeBSD.ORG Sat Jan 25 03:18:06 2014 Return-Path: Delivered-To: current@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 1BDC5D0D; Sat, 25 Jan 2014 03:18:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D4D9F1639; Sat, 25 Jan 2014 03:18:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id s0P2nXnP019473; Fri, 24 Jan 2014 21:49:33 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s0P2nXx9019466; Sat, 25 Jan 2014 02:49:33 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 25 Jan 2014 02:49:33 GMT Message-Id: <201401250249.s0P2nXx9019466@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 03:18:06 -0000 TB --- 2014-01-25 02:18:18 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-01-25 02:18:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-01-25 02:18:18 - starting HEAD tinderbox run for i386/pc98 TB --- 2014-01-25 02:18:18 - cleaning the object tree TB --- 2014-01-25 02:18:18 - /usr/local/bin/svn stat /src TB --- 2014-01-25 02:18:35 - At svn revision 261138 TB --- 2014-01-25 02:18:36 - building world TB --- 2014-01-25 02:18:36 - CROSS_BUILD_TESTING=YES TB --- 2014-01-25 02:18:36 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-25 02:18:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-25 02:18:36 - SRCCONF=/dev/null TB --- 2014-01-25 02:18:36 - TARGET=pc98 TB --- 2014-01-25 02:18:36 - TARGET_ARCH=i386 TB --- 2014-01-25 02:18:36 - TZ=UTC TB --- 2014-01-25 02:18:36 - __MAKE_CONF=/dev/null TB --- 2014-01-25 02:18:36 - cd /src TB --- 2014-01-25 02:18:36 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Jan 25 02:18:45 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools [...] c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/pc98.i386/src/tmp\" -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaCodeComplete.cpp -o SemaCodeComplete.o c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/pc98.i386/src/tmp\" -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaConsumer.cpp -o SemaConsumer.o c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/pc98.i386/src/tmp\" -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaDecl.cpp -o SemaDecl.o /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaDecl.cpp: In member function 'clang::Decl* clang::Sema::ActOnTag(clang::Scope*, unsigned int, clang::Sema::TagUseKind, clang::SourceLocation, clang::CXXScopeSpec&, clang::IdentifierInfo*, clang::SourceLocation, clang::AttributeList*, clang::AccessSpecifier, clang::SourceLocation, clang::MultiTemplateParamsArg, bool&, bool&, clang::SourceLocation, bool, clang::TypeResult)': /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaDecl.cpp:9480: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[3]: stopped in /src/lib/clang/libclangsema *** Error code 1 Stop. bmake[2]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-01-25 02:49:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-25 02:49:33 - ERROR: failed to build world TB --- 2014-01-25 02:49:33 - 1531.10 user 198.98 system 1875.05 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 25 03:36:54 2014 Return-Path: Delivered-To: freebsd-current@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 9A074FCA; Sat, 25 Jan 2014 03:36:54 +0000 (UTC) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 59B1F1767; Sat, 25 Jan 2014 03:36:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=apOy3yejHFAeRXIqAPB8jdV9/w3geiG3hQ7TfxT55ys=; b=uYNNratvTIsfl/42JJmSLjhq0jU4b3Q5/uRR6oK8BHNQWLszA2WWno8cL5N5Sb9LErETiJ8dBMz2zJD3nEvIAovAQLd7EO6VZyqPPwhkx/urwCTAalScxqFpQLApJBX73jPSmnPZE5ZXzlm1TCYtzmvdlHL+PVuZ76JF3Xvwxuk=; Received: from localhost.lerctr.org ([127.0.0.1]:47940 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpa (Exim 4.82 (FreeBSD)) (envelope-from ) id 1W6u34-000Pub-GZ; Fri, 24 Jan 2014 21:36:52 -0600 Received: from 107-128-180-255.lightspeed.austtx.sbcglobal.net ([107.128.180.255]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Fri, 24 Jan 2014 21:36:46 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 24 Jan 2014 21:36:46 -0600 From: Larry Rosenman To: Freebsd current , Freebsd fs Subject: Fwd: Panic/Solaris Assert/ZAP.c:534 Message-ID: <3b2a67b62965f564578b5b084480c84b@webmail.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/0.9.5 X-Spam-Score: 2.0 (++) X-LERCTR-Spam-Score: 2.0 (++) X-Spam-Report: SpamScore (2.0/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, KAM_STOCKTIP=5.5, RP_MATCHES_RCVD=-0.634 X-LERCTR-Spam-Report: SpamScore (2.0/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, KAM_STOCKTIP=5.5, RP_MATCHES_RCVD=-0.634 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 03:36:54 -0000 Still looking for help here so I can move forward on 11-CURRENT. -------- Original Message -------- Subject: Fwd: Panic/Solaris Assert/ZAP.c:534 Date: 2014-01-22 08:25 From: Larry Rosenman To: Freebsd fs , Freebsd current Repost, including the FS guys. Ideas? -------- Original Message -------- Subject: Panic/Solaris Assert/ZAP.c:534 Date: 2014-01-20 21:23 From: Larry Rosenman To: freebsd-current@freebsd.org Ideas? I'm getting this on a regular basis, and scrub/etc doesn't seem to get around it, but booting off: FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #113 r260864: Fri Jan 17 19:10:06 CST 2014 root@:/usr/obj/usr/src/sys/BORG-DTRACE amd64 Seems to avoid it. HELP. borg.lerctr.org dumped core - see /var/crash/vmcore.1 Mon Jan 20 21:18:41 CST 2014 FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r260896: Mon Jan 20 12:31:46 CST 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 panic: solaris assert: l->l_phys->l_hdr.lh_block_type == ((1ULL << 63) + 0) (0x0 == 0x8000000000000000), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c, line: 534 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: Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #1 r260896: Mon Jan 20 12:31:46 CST 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 info: [drm] Initialized drm 1.1.0 20060810 CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (2327.55-MHz K8-class CPU) Origin="GenuineIntel" Id=0x10676 Family=0x6 Model=0x17 Stepping=6 Features=0xbfebfbff Features2=0xce3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 68719476736 (65536 MB) avail memory = 65641644032 (62600 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard random: initialized kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) unknown: I/O range not supported cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 350 Event timer "HPET1" frequency 14318180 Hz quality 340 Event timer "HPET2" frequency 14318180 Hz quality 340 atrtc0: port 0x70-0x71 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 pcib5: at device 0.2 on pci3 pci5: on pcib5 pcib6: irq 18 at device 2.0 on pci2 pci6: on pcib6 em0: port 0x2000-0x201f mem 0xd9220000-0xd923ffff,0xd9200000-0xd921ffff irq 18 at device 0.0 on pci6 em0: Using an MSI interrupt em0: Ethernet address: 00:30:48:f2:29:9c em1: port 0x2020-0x203f mem 0xd9260000-0xd927ffff,0xd9240000-0xd925ffff irq 19 at device 0.1 on pci6 em1: Using an MSI interrupt em1: Ethernet address: 00:30:48:f2:29:9d pcib7: at device 0.3 on pci1 pci7: on pcib7 pcib8: at device 4.0 on pci0 pci8: on pcib8 vgapci0: port 0x3000-0x307f mem 0xd8000000-0xd8ffffff,0xc0000000-0xc7ffffff,0xc8000000-0xc9ffffff irq 16 at device 0.0 on pci8 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io hdac0: mem 0xd9000000-0xd9003fff irq 17 at device 0.1 on pci8 pcib9: at device 6.0 on pci0 pci9: on pcib9 pci0: at device 8.0 (no driver attached) pcib10: irq 17 at device 28.0 on pci0 pci10: on pcib10 pcib11: irq 16 at device 0.0 on pci10 pci11: on pcib11 pcm0: port 0x4080-0x409f,0x4000-0x407f irq 16 at device 0.0 on pci11 pcm0: system configuration SubVendorID: 0x1412, SubDeviceID: 0x2403 XIN2 Clock Source: 24.576MHz(96kHz*256) MPU-401 UART(s) #: not implemented ADC #: 1 and SPDIF receiver connected DAC #: 4 Multi-track converter type: AC'97(SDATA_OUT:packed) S/PDIF(IN/OUT): 1/1 ID# 0x00 GPIO(mask/dir/state): 0xff/0xff/0xff uhci0: port 0x1800-0x181f irq 17 at device 29.0 on pci0 usbus0 on uhci0 uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 usbus1 on uhci1 uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 usbus2 on uhci2 ehci0: mem 0xd9600400-0xd96007ff irq 17 at device 29.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib12: at device 30.0 on pci0 pci12: on pcib12 vgapci1: port 0x5000-0x50ff mem 0xd0000000-0xd7ffffff,0xd9300000-0xd930ffff irq 18 at device 1.0 on pci12 drmn1: on vgapci1 info: [drm] RADEON_IS_PCI info: [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080). info: [drm] register mmio base: 0xD9300000 info: [drm] register mmio size: 65536 info: [drm] radeon_atrm_get_bios: ===> Try ATRM... info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:8:0:0, vendor=10de, device=104a info: [drm] radeon_atrm_get_bios: Get ACPI device handle info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0xd0000000 info: [drm] igp_read_bios_from_vram: Map address: 0xfffff800d0000000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x0000 info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] radeon_read_bios: Map address: 0xfffff800000c0000 (131072 bytes) drmn1: info: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used) drmn1: info: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] radeon: irq initialized. info: [drm] Detected VRAM RAM=128M, BAR=128M info: [drm] RAM width 64bits SDR [TTM] Zone kernel: Available graphics memory: 33006090 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator info: [drm] radeon: 16M of VRAM memory ready info: [drm] radeon: 512M of GTT memory ready. info: [drm] GART: num cpu pages 131072, num gpu pages 131072 info: [drm] PCI GART of 512M enabled (table at 0x0000000011200000). drmn1: info: WB disabled drmn1: info: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0x0xfffff8001083c000 info: [drm] Loading R100 Microcode info: [drm] radeon: ring at 0x00000000B0001000 info: [drm] ring test succeeded in 1 usecs info: [drm] ib test succeeded in 0 usecs info: [drm] radeon_device_init: Taking over the fictitious range 0xd0000000-0xd4000000 iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iicbus1: on iicbb1 addr 0xff iic1: on iicbus1 iicbus2: on iicbb2 addr 0xff iic2: on iicbus2 iicbus3: on iicbb3 addr 0xff iic3: on iicbus3 info: [drm] Radeon Display Connectors info: [drm] Connector 0: info: [drm] VGA-1 info: [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60 info: [drm] Encoders: info: [drm] CRT1: INTERNAL_DAC1 info: [drm] Connector 1: info: [drm] DVI-I-1 info: [drm] HPD2 info: [drm] DDC: 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c info: [drm] Encoders: info: [drm] CRT2: INTERNAL_DAC2 info: [drm] DFP2: INTERNAL_DVO1 composite sync not supported composite sync not supported info: [drm] fb mappable at 0xD0040000 info: [drm] vram apper at 0xD0000000 info: [drm] size 2076672 info: [drm] fb depth is 8 info: [drm] pitch is 1920 fbd1 on drmn1 vt_allocate: Replace existing VT driver. info: [drm] Initialized radeon 2.29.0 20080528 vgapci1: Boot video device isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: at channel 0 on atapci0 ahci0: port 0x18a0-0x18a7,0x1874-0x1877,0x1878-0x187f,0x1870-0x1873,0x1880-0x189f mem 0xd9600800-0xd9600bff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ichsmb0: port 0x1100-0x111f irq 19 at device 31.3 on pci0 smbus0: on ichsmb0 acpi_button0: on acpi0 ipmi0: port 0xca2-0xca3 on acpi0 ipmi0: KCS mode found at io 0xca2 on acpi atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ichwd0 on isa0 orm0: at iomem 0xc0000-0xcafff on isa0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 coretemp4: on cpu4 est4: on cpu4 p4tcc4: on cpu4 coretemp5: on cpu5 est5: on cpu5 p4tcc5: on cpu5 coretemp6: on cpu6 est6: on cpu6 p4tcc6: on cpu6 coretemp7: on cpu7 est7: on cpu7 p4tcc7: on cpu7 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x387 offMax=0x491 hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm1: at nid 4 on hdaa0 pcm2: at nid 5 on hdaa0 random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen3.1: at usbus3 uhub0: on usbus3 ugen2.1: at usbus2 uhub1: on usbus2 ugen1.1: at usbus1 uhub2: on usbus1 ugen0.1: at usbus0 uhub3: on usbus0 ipmi0: IPMI device rev. 1, firmware rev. 1.64, version 2.0 ata0: DMA limited to UDMA33, controller found non-ATA66 cable ipmi0: Number of channels 8 ipmi0: Attached watchdog uhub2: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: Serial Number 5YDA1ZL4 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus2 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: Serial Number 5YD6FPLG ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada1: quirks=0x1<4K> ada1: Previously was known as ad6 ada2 at ahcich2 bus 0 scbus3 target 0 lun 0 ada2: ATA-8 SATA 3.x device ada2: Serial Number 5YDA3PC5 ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada2: quirks=0x1<4K> ada2: Previously was known as ad8 ada3 at ahcich3 bus 0 scbus4 target 0 lun 0 ada3: ATA-8 SATA 3.x device ada3: Serial Number 5YD9Y0P4 ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3: quirks=0x1<4K> ada3: Previously was known as ad10 ada4 at ahcich4 bus 0 scbus5 target 0 lun 0 ada4: ATA-8 SATA 3.x device ada4: Serial Number 5YDA1R5W ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada4: quirks=0x1<4K> ada4: Previously was known as ad12 ada5 at ahcich5 bus 0 scbus6 target 0 lun 0 ada5: ATA-8 SATA 3.x device ada5: Serial Number 5YD5RBS8 ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada5: quirks=0x1<4K> ada5: Previously was known as ad14 cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present Netvsc initializing... done! SMP: AP CPU #6 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #3 Launched! Root mount waiting for: usbus3 uhub0: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 Root mount waiting for: usbus3 ugen3.2: at usbus3 ukbd0: on usbus3 kbd2 at ukbd0 Trying to mount root from zfs:zroot/ROOT/default []... ugen0.2: at usbus0 ugen1.2: at usbus1 <118>Setting hostuuid: 53d19f64-d663-a017-8922-0030488e9ff3. <118>Setting hostid: 0xf53a926e. <118>Entropy harvesting: interrupts ethernet point_to_point swi. <118>Starting file system checks: <118>Mounting local file systems:. panic: solaris assert: l->l_phys->l_hdr.lh_block_type == ((1ULL << 63) + 0) (0x0 == 0x8000000000000000), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c, line: 534 cpuid = 7 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe100c499090 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe100c499140 vpanic() at vpanic+0x126/frame 0xfffffe100c499180 panic() at panic+0x43/frame 0xfffffe100c4991e0 assfail3() at assfail3+0x2f/frame 0xfffffe100c499200 zap_get_leaf_byblk() at zap_get_leaf_byblk+0x4e1/frame 0xfffffe100c499250 zap_deref_leaf() at zap_deref_leaf+0xd1/frame 0xfffffe100c4992a0 fzap_cursor_retrieve() at fzap_cursor_retrieve+0xce/frame 0xfffffe100c499310 zap_cursor_retrieve() at zap_cursor_retrieve+0x20a/frame 0xfffffe100c499390 ddt_zap_walk() at ddt_zap_walk+0x5e/frame 0xfffffe100c499650 ddt_walk() at ddt_walk+0x78/frame 0xfffffe100c499680 dsl_scan_sync() at dsl_scan_sync+0x6ec/frame 0xfffffe100c4999e0 spa_sync() at spa_sync+0x5c4/frame 0xfffffe100c499ad0 txg_sync_thread() at txg_sync_thread+0x256/frame 0xfffffe100c499bb0 fork_exit() at fork_exit+0x84/frame 0xfffffe100c499bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe100c499bf0 --- trap 0, rip = 0, rsp = 0xfffffe100c499cb0, rbp = 0 --- KDB: enter: panic Uptime: 14s Dumping 2263 out of 64465 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel.old/linux.ko.symbols...done. Loaded symbols for /boot/kernel.old/linux.ko.symbols Reading symbols from /boot/kernel.old/if_lagg.ko.symbols...done. Loaded symbols for /boot/kernel.old/if_lagg.ko.symbols Reading symbols from /boot/kernel.old/snd_envy24ht.ko.symbols...done. Loaded symbols for /boot/kernel.old/snd_envy24ht.ko.symbols Reading symbols from /boot/kernel.old/snd_spicds.ko.symbols...done. Loaded symbols for /boot/kernel.old/snd_spicds.ko.symbols Reading symbols from /boot/kernel.old/coretemp.ko.symbols...done. Loaded symbols for /boot/kernel.old/coretemp.ko.symbols Reading symbols from /boot/kernel.old/ichsmb.ko.symbols...done. Loaded symbols for /boot/kernel.old/ichsmb.ko.symbols Reading symbols from /boot/kernel.old/smbus.ko.symbols...done. Loaded symbols for /boot/kernel.old/smbus.ko.symbols Reading symbols from /boot/kernel.old/ichwd.ko.symbols...done. Loaded symbols for /boot/kernel.old/ichwd.ko.symbols Reading symbols from /boot/kernel.old/cpuctl.ko.symbols...done. Loaded symbols for /boot/kernel.old/cpuctl.ko.symbols Reading symbols from /boot/kernel.old/crypto.ko.symbols...done. Loaded symbols for /boot/kernel.old/crypto.ko.symbols Reading symbols from /boot/kernel.old/cryptodev.ko.symbols...done. Loaded symbols for /boot/kernel.old/cryptodev.ko.symbols Reading symbols from /boot/kernel.old/dtraceall.ko.symbols...done. Loaded symbols for /boot/kernel.old/dtraceall.ko.symbols Reading symbols from /boot/kernel.old/profile.ko.symbols...done. Loaded symbols for /boot/kernel.old/profile.ko.symbols Reading symbols from /boot/kernel.old/cyclic.ko.symbols...done. Loaded symbols for /boot/kernel.old/cyclic.ko.symbols Reading symbols from /boot/kernel.old/dtrace.ko.symbols...done. Loaded symbols for /boot/kernel.old/dtrace.ko.symbols Reading symbols from /boot/kernel.old/systrace_freebsd32.ko.symbols...done. Loaded symbols for /boot/kernel.old/systrace_freebsd32.ko.symbols Reading symbols from /boot/kernel.old/systrace.ko.symbols...done. Loaded symbols for /boot/kernel.old/systrace.ko.symbols Reading symbols from /boot/kernel.old/sdt.ko.symbols...done. Loaded symbols for /boot/kernel.old/sdt.ko.symbols Reading symbols from /boot/kernel.old/lockstat.ko.symbols...done. Loaded symbols for /boot/kernel.old/lockstat.ko.symbols Reading symbols from /boot/kernel.old/fasttrap.ko.symbols...done. Loaded symbols for /boot/kernel.old/fasttrap.ko.symbols Reading symbols from /boot/kernel.old/fbt.ko.symbols...done. Loaded symbols for /boot/kernel.old/fbt.ko.symbols Reading symbols from /boot/kernel.old/dtnfscl.ko.symbols...done. Loaded symbols for /boot/kernel.old/dtnfscl.ko.symbols Reading symbols from /boot/kernel.old/dtmalloc.ko.symbols...done. Loaded symbols for /boot/kernel.old/dtmalloc.ko.symbols Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel.old/ipmi.ko.symbols...done. Loaded symbols for /boot/kernel.old/ipmi.ko.symbols Reading symbols from /boot/kernel.old/ipmi_linux.ko.symbols...done. Loaded symbols for /boot/kernel.old/ipmi_linux.ko.symbols Reading symbols from /boot/kernel.old/radeonkms.ko.symbols...done. Loaded symbols for /boot/kernel.old/radeonkms.ko.symbols Reading symbols from /boot/kernel.old/iicbb.ko.symbols...done. Loaded symbols for /boot/kernel.old/iicbb.ko.symbols Reading symbols from /boot/kernel.old/iicbus.ko.symbols...done. Loaded symbols for /boot/kernel.old/iicbus.ko.symbols Reading symbols from /boot/kernel.old/iic.ko.symbols...done. Loaded symbols for /boot/kernel.old/iic.ko.symbols Reading symbols from /boot/kernel.old/drm2.ko.symbols...done. Loaded symbols for /boot/kernel.old/drm2.ko.symbols Reading symbols from /boot/kernel.old/radeonkmsfw_R100_cp.ko.symbols...done. Loaded symbols for /boot/kernel.old/radeonkmsfw_R100_cp.ko.symbols Reading symbols from /boot/kernel.old/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel.old/fdescfs.ko.symbols Reading symbols from /boot/kernel.old/linprocfs.ko.symbols...done. Loaded symbols for /boot/kernel.old/linprocfs.ko.symbols #0 doadump (textdump=1) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0xffffffff809b98d7 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:452 #2 0xffffffff809b9de5 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff809b9e33 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:688 #4 0xffffffff80327a2f in assfail3 (a=, lv=, op=, rv=, f=, l=) at /usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:91 #5 0xffffffff803bad81 in zap_get_leaf_byblk (zap=, blkid=, tx=0x0, lt=, lp=0xfffffe100c4994e8) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:534 #6 0xffffffff803b8461 in zap_deref_leaf (zap=0xfffff80020a4ec00, h=9377620324092215296, tx=0x0, lt=RW_READER, lp=0xfffffe100c4994e8) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:585 #7 0xffffffff803ba24e in fzap_cursor_retrieve (zap=0xfffff80020a4ec00, zc=0xfffffe100c4994d8, za=0xfffffe100c4993c0) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:1181 #8 0xffffffff803c076a in zap_cursor_retrieve (zc=0xfffffe100c4994d8, za=0xfffffe100c4993c0) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:1290 #9 0xffffffff80352fde in ddt_zap_walk (os=0xfffff8002031bc00, object=156, dde=0xfffffe100c499828, walk=0xfffff800201ce3d0) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ddt_zap.c:117 #10 0xffffffff80352c88 in ddt_walk (spa=0xfffffe000d377000, ddb=0xfffff800201ce3b8, dde=0xfffffe100c499828) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ddt.c:219 #11 0xffffffff803800dc in dsl_scan_sync (dp=0xfffff8002031f800, tx=0xfffff80022180000) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c:1204 #12 0xffffffff803999b4 in spa_sync (spa=0xfffffe000d377000, txg=14079627) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:6549 #13 0xffffffff803a4e96 in txg_sync_thread (arg=0xfffff8002031f800) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c:518 #14 0xffffffff80988f94 in fork_exit ( callout=0xffffffff803a4c40 , arg=0xfffff8002031f800, frame=0xfffffe100c499c00) at /usr/src/sys/kern/kern_fork.c:977 #15 0xffffffff80d9576e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:605 #16 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) ------------------------------------------------------------------------ ps -axlww UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -8 0 0 0 - DLs - 0:00.10 [kernel] 0 1 0 0 21 0 9432 0 wait DLs - 0:00.00 [init] 0 2 0 0 -16 0 0 0 ftcl DL - 0:00.00 [ftcleanup] 0 3 0 0 -16 0 0 0 crypto_w DL - 0:00.00 [crypto] 0 4 0 0 -16 0 0 0 crypto_r DL - 0:00.00 [crypto returns] 0 5 0 0 -16 0 0 0 ccb_scan DL - 0:00.00 [cam] 0 6 0 0 -16 0 0 0 - DL - 0:00.00 [fdc0] 0 7 0 0 -8 0 0 0 - RL - 0:00.00 [zfskern] 0 8 0 0 -16 0 0 0 waiting_ DL - 0:00.00 [sctp_iterator] 0 9 0 0 -16 0 0 0 ipmireq DL - 0:00.00 [ipmi0: kcs] 0 10 0 0 -16 0 0 0 audit_wo DL - 0:00.00 [audit] 0 11 0 0 155 0 0 0 - RL - 0:00.00 [idle] 0 12 0 0 -84 0 0 0 - WL - 0:00.00 [intr] 0 13 0 0 -8 0 0 0 - DL - 0:00.00 [geom] 0 14 0 0 -16 0 0 0 - DL - 0:00.00 [rand_harvestq] 0 15 0 0 -68 0 0 0 - DL - 0:00.00 [usb] 0 16 0 0 -20 0 0 0 VBoxIS DL - 0:00.00 [TIMER] 0 17 0 0 -16 0 0 0 psleep DL - 0:00.00 [pagedaemon] 0 18 0 0 -16 0 0 0 psleep DL - 0:00.00 [vmdaemon] 0 19 0 0 155 0 0 0 pgzero DL - 0:00.00 [pagezero] 0 20 0 0 -16 0 0 0 psleep DL - 0:00.00 [bufdaemon] 0 21 0 0 16 0 0 0 syncer DL - 0:00.00 [syncer] 0 22 0 0 -16 0 0 0 vlruwt DL - 0:00.00 [vnlru] 0 23 0 0 -16 0 0 0 sdflush DL - 0:00.00 [softdepflush] 0 24 1 0 52 0 16992 0 wait Ds+ - 0:00.02 [sh] 0 72 24 0 52 0 16992 0 wait D+ - 0:00.00 [sh] 0 75 72 0 39 0 40064 0 zio->io_ D+ - 0:00.00 [zfs] ------------------------------------------------------------------------ vmstat -s 42891 cpu context switches 5520 device interrupts 462 software interrupts 5061 traps 5879 system calls 23 kernel threads created 37 fork() calls 15 vfork() calls 0 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 0 swap pager pageouts 0 swap pager pages paged out 135 vnode pager pageins 923 vnode pager pages paged in 0 vnode pager pageouts 0 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 0 pages reactivated 1770 copy-on-write faults 15 copy-on-write optimized faults 2266 zero fill pages zeroed 0 zero fill pages prezeroed 0 intransit blocking page faults 4682 total VM faults taken 112 page faults requiring I/O 0 pages affected by kernel thread creation 1350 pages affected by fork() 525 pages affected by vfork() 0 pages affected by rfork() 0 pages cached 55124 pages freed 0 pages freed by daemon 0 pages freed by exiting processes 473 pages active 869 pages inactive 0 pages in VM cache 140410 pages wired down 15933660 pages free 4096 bytes per page 1934 total name lookups cache hits (80% pos + 4% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) cdev 8 2K - 8 256 ppbusdev 2 1K - 2 256 filedesc 27 54K - 76 2048 kdtrace 330 78K - 522 64,256 kenv 87 12K - 115 16,32,64,128 proc-args 3 1K - 31 32,64,128 hhook 2 1K - 2 256 ithread 125 22K - 125 32,128,256 KTRACE 100 13K - 100 128 entropy 1026 65K - 1026 32,64 acpiintr 1 1K - 1 64 linker 403 101K - 533 16,32,64,128,256,512,1024,2048,4096 lockf 2 1K - 2 64,128 loginclass 2 1K - 2 64 cache 1 1K - 1 32 devbuf 17314 34391K - 18687 16,32,64,128,256,512,1024,2048,4096 temp 57 18K - 548 16,32,64,128,256,512,1024,2048 ip6ndp 3 1K - 3 64 ata_pci 1 1K - 1 64 acpica 1824 187K - 63680 16,32,64,128,256,512,1024,2048 kbdmux 7 18K - 7 16,512,1024,2048 module 521 66K - 521 128 mtx_pool 2 16K - 2 LED 4 1K - 4 16,128 CAM XPT 58 4K - 309 16,32,64,128,512,1024,2048 osd 6 1K - 12 16,32,64,128 pmchooks 1 1K - 1 128 CAM DEV 15 30K - 24 2048 acpitask 1 8K - 1 hdaa 4 5K - 4 512,1024,2048 pgrp 2 1K - 2 128 session 2 1K - 2 128 proc 2 256K - 2 subproc 100 145K - 149 512,4096 cred 54 9K - 254 64,256 plimit 2 1K - 2 256 uidinfo 2 33K - 2 128 hdac 1 1K - 1 512 hdacc 1 1K - 1 32 vtbuf 24 5712K - 24 4096 acpisem 22 3K - 22 128 vt 11 3K - 11 256 sysctl 0 0K - 50 16,32,64 sysctloid 7607 378K - 7779 16,32,64,128 sysctltmp 0 0K - 6 32,64 tidhash 1 256K - 1 callout 9 3208K - 9 umtx 684 86K - 684 128 p1003.1b 1 1K - 1 16 SWAP 12 19681K - 12 64 bus 2257 362K - 8440 16,32,64,128,256,512,1024 bus-sc 157 310K - 5479 16,32,64,128,256,512,1024,2048,4096 devstat 32 65K - 32 32,4096 eventhandler 104 9K - 104 64,128 DEVFS3 230 58K - 270 256 kobj 349 1396K - 1111 4096 DEVFS1 202 101K - 238 512 Per-cpu 1 1K - 1 32 DEVFS 41 1K - 42 16,128 rman 360 41K - 754 16,32,128 sbuf 0 0K - 2295 16,32,64,128,256 sglist 3 1K - 3 32 taskqueue 127 19K - 171 16,32,64,128,256 terminal 11 3K - 11 256 Unitno 28 2K - 120 32,64 vmem 2 136K - 2 ioctlops 0 0K - 158 16,32,64 iov 1 1K - 34 64,256,512 msg 4 30K - 4 2048,4096 sem 4 106K - 4 2048,4096 shm 1 20K - 1 tty 14 14K - 14 1024 shmfd 1 8K - 1 pcb 12 8341K - 12 16,128,1024,2048 vfscache 1 16384K - 1 vfs_hash 1 8192K - 1 vnodes 1 1K - 1 256 mount 251 9K - 550 16,32,64,128,256 vnodemarker 0 0K - 5 512 BPF 3 1K - 3 128 ifnet 4 7K - 4 128,2048 ifaddr 34 10K - 34 32,64,256,512,2048,4096 clone 8 1K - 8 128 arpcom 2 1K - 2 16 lltable 6 3K - 6 512 routetbl 5 2K - 5 256,512 igmp 3 1K - 3 256 sctp_vrf 1 1K - 1 64 hostcache 1 28K - 1 syncache 1 64K - 1 mld 3 1K - 3 128 rpc 2 1K - 2 512 audit_evclass 187 6K - 228 32 ufs_quota 1 8192K - 1 vm_pgdata 7 8193K - 7 128 pfs_nodes 73 19K - 73 256 pfs_vncache 2 1K - 2 64 scsi_cd 0 0K - 11 16 GEOM 404 67K - 3278 16,32,64,128,256,512,1024,2048 memdesc 1 4K - 1 4096 feeder 20 2K - 24 32,128 acpidev 36 3K - 36 64 atkbddev 2 1K - 2 64 CAM CCB 0 0K - 5331 2048 mixer 3 12K - 3 4096 raid_data 0 0K - 480 32,128,256 CAM path 22 1K - 115 32 solaris 289279 163254K - 391115 16,32,64,128,256,512,1024,2048,4096 UART 6 5K - 6 16,1024 kstat_data 6 1K - 6 64 CAM periph 16 4K - 40 16,32,64,128,256 md_nvidia_data 0 0K - 78 512 pci_link 16 2K - 16 32,64,128 md_sii_data 0 0K - 78 512 acpi_perf 8 1K - 8 64 CAM queue 23 8K - 57 16,32,512 apmdev 1 1K - 1 128 madt_table 0 0K - 1 4096 CAM dev queue 8 1K - 8 64 CAM SIM 8 2K - 8 256 ddb_capture 1 48K - 1 io_apic 2 4K - 2 2048 MCA 8 1K - 8 128 msi 4 1K - 4 128 nexusdev 4 1K - 4 16 isadev 5 1K - 5 128 USB 46 59K - 52 16,32,64,128,256,512,1024,2048,4096 USBdev 35 4K - 35 32,64,128,256 linux 17 2K - 17 64 spicds 7 1K - 7 128 envy24ht 15 195K - 15 64,2048 cpuctl 1 1K - 1 64 crypto 1 1K - 1 512 cyclic 32 3K - 32 16,64,128 SDT 32 2K - 32 16,64 fbt 60661 7839K - 60661 128 iprtheap 17 54K - 17 32,64,128,256 nvidia 194 864K - 195 16,32,64,128,256,512,1024,2048,4096 ipmi 0 0K - 11 128 gem_name 59 10K - 62 32,4096 drm_global 2 1K - 2 128,256 drm_vblank 7 1K - 7 16,64 drm_dma 2 1K - 2 32 drm_sarea 1 1K - 1 16 drm_driver 32 2203K - 36 16,32,64,128,256,512,1024,4096 drm_ctxbitmap 1 4K - 1 4096 drm_sman 13 2K - 13 128 drm_hashtab 1 4096K - 1 drm_kms 90 18K - 107 16,32,64,128,256,2048 ttm_pd 6 9K - 6 16,2048 ttm_rman 2 1K - 2 256 ttm_zone 2 1K - 2 64 ttm_poolmgr 1 1K - 1 512 fdesc_mount 1 1K - 1 16 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 384, 0, 267, 3, 267, 0, 0 UMA Zones: 1664, 0, 267, 1, 267, 0, 0 UMA Slabs: 112, 0, 4719, 6, 7221, 0, 0 UMA RCntSlabs: 120, 0, 0, 0, 0, 0, 0 UMA Hash: 256, 0, 77, 13, 77, 0, 0 4 Bucket: 32, 0, 262, 854, 1813, 0, 0 6 Bucket: 48, 0, 276, 1052, 1590, 0, 0 8 Bucket: 64, 0, 62, 992, 883, 0, 0 12 Bucket: 96, 0, 36, 989, 167, 0, 0 16 Bucket: 128, 0, 131, 1016, 1263, 17, 0 32 Bucket: 256, 0, 130, 380, 285, 49, 0 64 Bucket: 512, 0, 119, 238, 465, 49, 0 128 Bucket: 1024, 0, 406, 46, 3736, 2, 0 vmem btag: 56, 0, 11416, 441, 11514, 167, 0 VM OBJECT: 256, 0, 590, 400, 1335, 0, 0 RADIX NODE: 144, 0, 6442, 416, 10926, 0, 0 MAP: 240, 0, 3, 61, 3, 0, 0 KMAP ENTRY: 128, 0, 8, 271, 8, 0, 0 MAP ENTRY: 128, 0, 103, 920, 1717, 0, 0 VMSPACE: 448, 0, 4, 204, 54, 0, 0 fakepg: 104, 0, 0, 0, 0, 0, 0 mt_zone: 4112, 0, 405, 0, 405, 0, 0 16: 16, 0, 6, 243, 6, 0, 0 16: 16, 0, 2762, 973, 3015, 0, 0 16: 16, 0, 147166, 740, 158653, 0, 0 16: 16, 0, 55, 941, 28215, 0, 0 16: 16, 0, 62, 685, 63, 0, 0 16: 16, 0, 732, 1011, 5473, 0, 0 16: 16, 0, 30, 219, 30, 0, 0 16: 16, 0, 1, 746, 18, 0, 0 32: 32, 0, 30, 1086, 117, 0, 0 32: 32, 0, 3091, 877, 3295, 0, 0 32: 32, 0, 65004, 716, 73960, 0, 0 32: 32, 0, 66, 554, 4216, 0, 0 32: 32, 0, 18, 1098, 98, 0, 0 32: 32, 0, 839, 897, 2874, 0, 0 32: 32, 0, 94, 650, 186, 0, 0 32: 32, 0, 8, 736, 164, 0, 0 64: 64, 0, 5, 181, 6, 0, 0 64: 64, 0, 517, 909, 589, 0, 0 64: 64, 0, 7078, 982, 33984, 0, 0 64: 64, 0, 767, 783, 1637, 0, 0 64: 64, 0, 80, 106, 80, 0, 0 64: 64, 0, 9187, 857, 9746, 0, 0 64: 64, 0, 131, 551, 131, 0, 0 64: 64, 0, 1038, 760, 1071, 0, 0 128: 128, 0, 34, 741, 95, 0, 0 128: 128, 0, 1899, 612, 1908, 0, 0 128: 128, 0, 121830, 806, 128094, 0, 0 128: 128, 0, 1077, 318, 27007, 0, 0 128: 128, 0, 112, 663, 192, 0, 0 128: 128, 0, 1895, 740, 4111, 0, 0 128: 128, 0, 29, 126, 30, 0, 0 128: 128, 0, 524, 499, 526, 0, 0 256: 256, 0, 2, 73, 2, 0, 0 256: 256, 0, 308, 307, 451, 0, 0 256: 256, 0, 372, 543, 2665, 0, 0 256: 256, 0, 64, 131, 740, 0, 0 256: 256, 0, 28, 347, 348, 0, 0 256: 256, 0, 909, 441, 1963, 0, 0 256: 256, 0, 31, 44, 31, 0, 0 256: 256, 0, 4, 191, 25, 0, 0 512: 512, 0, 2, 33, 9, 0, 0 512: 512, 0, 69, 197, 225, 0, 0 512: 512, 0, 130, 276, 32908, 0, 0 512: 512, 0, 16, 47, 35, 0, 0 512: 512, 0, 3, 32, 3, 0, 0 512: 512, 0, 327, 170, 2804, 0, 0 512: 512, 0, 47, 16, 47, 0, 0 512: 512, 0, 1, 62, 2, 0, 0 1024: 1024, 0, 0, 104, 99, 0, 0 1024: 1024, 0, 9, 19, 9, 0, 0 1024: 1024, 0, 8372, 68, 23684, 0, 0 1024: 1024, 0, 5, 23, 2074, 0, 0 1024: 1024, 0, 16, 12, 16, 0, 0 1024: 1024, 0, 230, 98, 1280, 0, 0 1024: 1024, 0, 2, 14, 2, 0, 0 1024: 1024, 0, 0, 0, 0, 0, 0 2048: 2048, 0, 2, 4, 9, 0, 0 2048: 2048, 0, 6, 4, 6, 0, 0 2048: 2048, 0, 11, 19, 39, 0, 0 2048: 2048, 0, 7, 53, 5343, 0, 0 2048: 2048, 0, 21, 9, 30, 0, 0 2048: 2048, 0, 48, 42, 466, 0, 0 2048: 2048, 0, 5, 1, 5, 0, 0 2048: 2048, 0, 0, 0, 0, 0, 0 4096: 4096, 0, 0, 0, 0, 0, 0 4096: 4096, 0, 5, 0, 5, 0, 0 4096: 4096, 0, 167, 4, 295, 0, 0 4096: 4096, 0, 10, 0, 12, 0, 0 4096: 4096, 0, 16, 0, 17, 0, 0 4096: 4096, 0, 25, 0, 415, 0, 0 4096: 4096, 0, 15, 0, 15, 0, 0 4096: 4096, 0, 349, 10, 1111, 0, 0 uint64 pcpu: 8, 0, 1398, 138, 1398, 0, 0 SLEEPQUEUE: 88, 0, 343, 680, 343, 0, 0 Files: 80, 0, 8, 874, 395, 0, 0 rl_entry: 40, 0, 6, 687, 6, 0, 0 TURNSTILE: 136, 0, 343, 277, 343, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1208, 0, 26, 46, 75, 0, 0 THREAD: 1168, 0, 302, 40, 445, 0, 0 cpuset: 72, 0, 287, 593, 430, 0, 0 cyclic_id_cache: 64, 0, 0, 0, 0, 0, 0 audit_record: 1248, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 25720710, 0, 10, 0, 0, 0 mbuf: 256, 25720710, 1, 134, 1, 0, 0 mbuf_cluster: 2048, 4018860, 0, 0, 0, 0, 0 mbuf_jumbo_page: 4096, 2009429, 0, 0, 0, 0, 0 mbuf_jumbo_9k: 9216, 1786158, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 1339616, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 sendfile_sync: 128, 0, 0, 0, 0, 0, 0 dtrace_state_cache: 4096, 0, 0, 0, 0, 0, 0 g_bio: 248, 0, 0, 672, 15403, 0, 0 DMAR_MAP_ENTRY: 120, 0, 0, 0, 0, 0, 0 ttyinq: 160, 0, 15, 57, 15, 0, 0 ttyoutq: 256, 0, 8, 67, 8, 0, 0 ata_request: 336, 0, 0, 88, 39, 0, 0 vtnet_tx_hdr: 24, 0, 0, 0, 0, 0, 0 cryptop: 88, 0, 0, 0, 0, 0, 0 cryptodesc: 72, 0, 0, 0, 0, 0, 0 nv_stack_t: 12288, 0, 2, 1, 6, 0, 0 FPU_save_area: 512, 0, 0, 0, 0, 0, 0 taskq_zone: 48, 0, 0, 415, 20, 0, 0 taskq_zone: 48, 0, 0, 0, 0, 0, 0 VNODE: 472, 0, 332, 164, 333, 0, 0 VNODEPOLL: 112, 0, 0, 0, 0, 0, 0 BUF TRIE: 144, 0, 0, 105948, 0, 0, 0 NAMEI: 1024, 0, 0, 104, 908, 0, 0 S VFS Cache: 108, 0, 248, 767, 294, 0, 0 STS VFS Cache: 148, 0, 0, 0, 0, 0, 0 L VFS Cache: 328, 0, 0, 0, 0, 0, 0 LTS VFS Cache: 368, 0, 0, 0, 0, 0, 0 NCLNODE: 528, 0, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 0, 0, 0, 0, 0 reference_cache: 40, 0, 0, 0, 0, 0, 0 reference_history_cache: 8, 0, 0, 0, 0, 0, 0 range_seg_cache: 64, 0, 9978, 934, 10433, 0, 0 zio_cache: 920, 0, 6, 814, 12019, 0, 0 zio_link_cache: 48, 0, 3, 1408, 7868, 0, 0 zio_buf_512: 512, 0, 590, 166, 1077, 0, 0 zio_data_buf_512: 512, 0, 54, 65, 56, 0, 0 zio_buf_1024: 1024, 0, 22, 58, 61, 0, 0 zio_data_buf_1024: 1024, 0, 40, 40, 40, 0, 0 zio_buf_1536: 1536, 0, 22, 24, 24, 0, 0 zio_data_buf_1536: 1536, 0, 23, 13, 23, 0, 0 zio_buf_2048: 2048, 0, 35, 25, 64, 0, 0 zio_data_buf_2048: 2048, 0, 14, 12, 15, 0, 0 zio_buf_2560: 2560, 0, 0, 15, 27, 0, 0 zio_data_buf_2560: 2560, 0, 17, 4, 17, 0, 0 zio_buf_3072: 3072, 0, 2, 4, 2, 0, 0 zio_data_buf_3072: 3072, 0, 8, 4, 8, 0, 0 zio_buf_3584: 3584, 0, 1, 0, 1, 0, 0 zio_data_buf_3584: 3584, 0, 2, 0, 2, 0, 0 zio_buf_4096: 4096, 0, 49, 706, 3790, 0, 0 zio_data_buf_4096: 4096, 0, 0, 24, 25, 0, 0 zio_buf_5120: 5120, 0, 1, 0, 1, 0, 0 zio_data_buf_5120: 5120, 0, 4, 0, 4, 0, 0 zio_buf_6144: 6144, 0, 1, 0, 1, 0, 0 zio_data_buf_6144: 6144, 0, 3, 0, 3, 0, 0 zio_buf_7168: 7168, 0, 0, 0, 0, 0, 0 zio_data_buf_7168: 7168, 0, 1, 0, 1, 0, 0 zio_buf_8192: 8192, 0, 1, 13, 187, 0, 0 zio_data_buf_8192: 8192, 0, 2, 1, 4, 0, 0 zio_buf_10240: 10240, 0, 1, 0, 1, 0, 0 zio_data_buf_10240: 10240, 0, 1, 0, 1, 0, 0 zio_buf_12288: 12288, 0, 1, 8, 45, 0, 0 zio_data_buf_12288: 12288, 0, 4, 0, 4, 0, 0 zio_buf_14336: 14336, 0, 0, 0, 0, 0, 0 zio_data_buf_14336: 14336, 0, 1, 0, 1, 0, 0 zio_buf_16384: 16384, 0, 398, 23, 543, 0, 0 zio_data_buf_16384: 16384, 0, 2, 0, 2, 0, 0 zio_buf_20480: 20480, 0, 0, 5, 19, 0, 0 zio_data_buf_20480: 20480, 0, 3, 0, 3, 0, 0 zio_buf_24576: 24576, 0, 0, 9, 16, 0, 0 zio_data_buf_24576: 24576, 0, 5, 0, 5, 0, 0 zio_buf_28672: 28672, 0, 0, 14, 83, 0, 0 zio_data_buf_28672: 28672, 0, 4, 0, 4, 0, 0 zio_buf_32768: 32768, 0, 0, 2, 3, 0, 0 zio_data_buf_32768: 32768, 0, 2, 0, 2, 0, 0 zio_buf_36864: 36864, 0, 1, 5, 8, 0, 0 zio_data_buf_36864: 36864, 0, 1, 2, 3, 0, 0 zio_buf_40960: 40960, 0, 0, 3, 3, 0, 0 zio_data_buf_40960: 40960, 0, 2, 0, 2, 0, 0 zio_buf_45056: 45056, 0, 0, 1, 1, 0, 0 zio_data_buf_45056: 45056, 0, 1, 0, 1, 0, 0 zio_buf_49152: 49152, 0, 0, 0, 0, 0, 0 zio_data_buf_49152: 49152, 0, 0, 0, 0, 0, 0 zio_buf_53248: 53248, 0, 0, 1, 1, 0, 0 zio_data_buf_53248: 53248, 0, 1, 0, 1, 0, 0 zio_buf_57344: 57344, 0, 0, 0, 0, 0, 0 zio_data_buf_57344: 57344, 0, 0, 0, 0, 0, 0 zio_buf_61440: 61440, 0, 0, 0, 0, 0, 0 zio_data_buf_61440: 61440, 0, 0, 0, 0, 0, 0 zio_buf_65536: 65536, 0, 0, 0, 0, 0, 0 zio_data_buf_65536: 65536, 0, 0, 0, 0, 0, 0 zio_buf_69632: 69632, 0, 0, 2, 2, 0, 0 zio_data_buf_69632: 69632, 0, 2, 0, 2, 0, 0 zio_buf_73728: 73728, 0, 0, 1, 1, 0, 0 zio_data_buf_73728: 73728, 0, 1, 0, 1, 0, 0 zio_buf_77824: 77824, 0, 0, 0, 0, 0, 0 zio_data_buf_77824: 77824, 0, 0, 0, 0, 0, 0 zio_buf_81920: 81920, 0, 0, 0, 0, 0, 0 zio_data_buf_81920: 81920, 0, 1, 0, 1, 0, 0 zio_buf_86016: 86016, 0, 0, 0, 0, 0, 0 zio_data_buf_86016: 86016, 0, 0, 0, 0, 0, 0 zio_buf_90112: 90112, 0, 0, 2, 2, 0, 0 zio_data_buf_90112: 90112, 0, 0, 1, 1, 0, 0 zio_buf_94208: 94208, 0, 0, 0, 0, 0, 0 zio_data_buf_94208: 94208, 0, 0, 0, 0, 0, 0 zio_buf_98304: 98304, 0, 1, 1, 2, 0, 0 zio_data_buf_98304: 98304, 0, 1, 0, 1, 0, 0 zio_buf_102400: 102400, 0, 0, 0, 0, 0, 0 zio_data_buf_102400: 102400, 0, 0, 0, 0, 0, 0 zio_buf_106496: 106496, 0, 0, 0, 0, 0, 0 zio_data_buf_106496: 106496, 0, 0, 0, 0, 0, 0 zio_buf_110592: 110592, 0, 0, 1, 1, 0, 0 zio_data_buf_110592: 110592, 0, 1, 0, 1, 0, 0 zio_buf_114688: 114688, 0, 0, 3, 14, 0, 0 zio_data_buf_114688: 114688, 0, 0, 0, 0, 0, 0 zio_buf_118784: 118784, 0, 0, 0, 0, 0, 0 zio_data_buf_118784: 118784, 0, 0, 0, 0, 0, 0 zio_buf_122880: 122880, 0, 0, 0, 0, 0, 0 zio_data_buf_122880: 122880, 0, 0, 0, 0, 0, 0 zio_buf_126976: 126976, 0, 0, 0, 0, 0, 0 zio_data_buf_126976: 126976, 0, 0, 0, 0, 0, 0 zio_buf_131072: 131072, 0, 1, 11, 61, 0, 0 zio_data_buf_131072: 131072, 0, 39, 5, 48, 0, 0 lz4_ctx: 16384, 0, 0, 0, 0, 0, 0 sa_cache: 80, 0, 272, 757, 272, 0, 0 dnode_t: 1096, 0, 746, 37, 1863, 0, 0 dmu_buf_impl_t: 336, 0, 1270, 127, 1729, 0, 0 arc_buf_hdr_t: 328, 0, 881, 163, 1332, 0, 0 arc_buf_t: 72, 0, 880, 770, 1359, 0, 0 zil_lwb_cache: 192, 0, 0, 0, 0, 0, 0 zfs_znode_cache: 368, 0, 272, 138, 272, 0, 0 pipe: 744, 0, 0, 40, 13, 0, 0 Mountpoints: 816, 0, 24, 41, 24, 0, 0 procdesc: 128, 0, 0, 0, 0, 0, 0 ksiginfo: 112, 0, 26, 1024, 26, 0, 0 itimer: 352, 0, 0, 0, 0, 0, 0 KNOTE: 128, 0, 0, 0, 0, 0, 0 socket: 696, 2062880, 0, 0, 0, 0, 0 ipq: 56, 125599, 0, 0, 0, 0, 0 udp_inpcb: 392, 2062880, 0, 0, 0, 0, 0 udpcb: 16, 2062965, 0, 0, 0, 0, 0 tcp_inpcb: 392, 2062880, 0, 0, 0, 0, 0 tcpcb: 1024, 2062880, 0, 0, 0, 0, 0 tcptw: 88, 27810, 0, 0, 0, 0, 0 syncache: 160, 15360, 0, 0, 0, 0, 0 hostcache: 136, 15370, 0, 0, 0, 0, 0 tcpreass: 40, 251262, 0, 0, 0, 0, 0 sackhole: 32, 0, 0, 0, 0, 0, 0 sctp_ep: 1408, 2062880, 0, 0, 0, 0, 0 sctp_asoc: 2352, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80012, 0, 0, 0, 0, 0 sctp_raddr: 728, 80000, 0, 0, 0, 0, 0 sctp_chunk: 136, 400026, 0, 0, 0, 0, 0 sctp_readq: 104, 400026, 0, 0, 0, 0, 0 sctp_stream_msg_out: 104, 400026, 0, 0, 0, 0, 0 sctp_asconf: 40, 400059, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400060, 0, 0, 0, 0, 0 ripcb: 392, 2062880, 0, 0, 0, 0, 0 unpcb: 240, 2062880, 0, 0, 0, 0, 0 rtentry: 200, 0, 0, 0, 0, 0, 0 selfd: 56, 0, 0, 0, 0, 0, 0 SWAPMETA: 288, 8037731, 0, 0, 0, 0, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq6: fdc0 22 0 irq14: ata0 55 0 irq17: uhci0 ehci0 55 0 irq18: uhci2+ 304 0 irq19: uhci1 ahci0+ 5075 13 cpu0:timer 2410 6 irq259: hdac0 9 0 cpu6:timer 442 1 cpu1:timer 404 1 cpu2:timer 482 1 cpu7:timer 548 1 cpu5:timer 477 1 cpu4:timer 484 1 cpu3:timer 765 2 Total 11532 31 ------------------------------------------------------------------------ pstat -T 8/2062880 files 0M/147455M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/#C:0xc0 50331392 0 50331392 0% /dev/ad14p2 50331392 0 50331392 0% /dev/usb/3.2.1 50331392 0 50331392 0% /dev/#C:0xd0 50331392 0 50331392 0% /dev/#C:0xd8 50331392 0 50331392 0% /dev/#C:0xe0 50331392 0 50331392 0% Total 301988352 0 301988352 0% ------------------------------------------------------------------------ iostat tty ada0 ada1 ada2 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 15 15.18 60 0.89 15.40 65 0.98 14.86 63 0.91 0 0 2 1 97 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) shminfo: shmmax: 536870912 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 131072 (max amount of shared memory in pages) seminfo: semmni: 50 (# of semaphore identifiers) semmns: 340 (# of semaphores in system) semmnu: 150 (# of undo structures in system) semmsl: 340 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 50 (max # of undo entries per process) semusz: 632 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat Client Info: Rpc Counts: Getattr Setattr Lookup Readlink Read Write Create Remove 2 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 1 1 0 0 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 0 0 4 Cache Info: Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Misses 0 0 0 0 0 0 0 0 BioRLHits Misses BioD Hits Misses DirE Hits Misses Accs Hits Misses 0 0 0 0 0 0 0 0 Server Info: Getattr Setattr Lookup Readlink Read Write Create Remove 0 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Server Ret-Failed 0 Server Faults 0 Server Cache Stats: Inprog Idem Non-idem Misses 0 0 0 0 Server Write Gathering: WriteOps WriteRPC Opsaved 0 0 0 ------------------------------------------------------------------------ netstat -s tcp: 0 packets sent 0 data packets (0 bytes) 0 data packets (0 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 0 ack-only packets (0 delayed) 0 URG only packets 0 window probe packets 0 window update packets 0 control packets 0 packets received 0 acks (for 0 bytes) 0 duplicate acks 0 acks for unsent data 0 packets (0 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 0 connection requests 0 connection accepts 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 0 connections established (including accepts) 0 connections closed (including 0 drops) 0 connections updated cached RTT on close 0 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 0 segments updated rtt (of 0 attempts) 0 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 0 correct ACK header predictions 0 correct data packet header predictions 0 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 0 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 0 cookies sent 0 cookies received 0 hostcache entries added 0 bucket overflow 0 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 0 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 0 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 0 dropped due to no socket 0 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 0 delivered 0 datagrams output 0 times multicast source filter matched ip: 0 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 0 packets for this host 0 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 0 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 0 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 0 calls to icmp_error 0 errors not generated in response to an icmp message 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored 0 message responses generated 0 invalid return addresses 0 no return routes igmp: 0 messages received 0 messages received with too few bytes 0 messages received with wrong TTL 0 messages received with bad checksum 0 V1/V2 membership queries received 0 V3 membership queries received 0 membership queries received with invalid field(s) 0 general queries received 0 group queries received 0 group-source queries received 0 group-source queries dropped 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 V3 reports received without Router Alert 0 membership reports sent arp: 0 ARP requests sent 0 ARP replies sent 0 ARP requests received 0 ARP replies received 0 ARP packets received 0 total packets dropped due to no ARP entry 0 ARP entrys timed out 0 Duplicate IPs seen ip6: 0 total packets received 0 with size smaller than minimum 0 with data size < data length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 fragments that exceeded limit 0 packets reassembled ok 0 packets for this host 0 packets forwarded 0 packets not forwardable 0 redirects sent 0 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 packets that violated scope rules 0 multicast packets which we don't join Mbuf statistics: 0 one mbuf 0 one ext mbuf 0 two or more ext mbuf 0 packets whose headers are not contiguous 0 tunneling packets that can't find gif 0 packets discarded because of too many headers 0 failures of source address selection Source addresses selection rule applied: icmp6: 0 calls to icmp6_error 0 errors not generated in response to an icmp6 message 0 errors not generated because of rate limitation 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Histogram of error messages to be generated: 0 no route 0 administratively prohibited 0 beyond scope 0 address unreachable 0 port unreachable 0 packet too big 0 time exceed transit 0 time exceed reassembly 0 erroneous header field 0 unrecognized next header 0 unrecognized option 0 redirect 0 unknown 0 message responses generated 0 messages with too many ND options 0 messages with bad ND options 0 bad neighbor solicitation messages 0 bad neighbor advertisement messages 0 bad router solicitation messages 0 bad router advertisement messages 0 bad redirect messages 0 path MTU changes rip6: 0 messages received 0 checksum calculations on inbound 0 messages with bad checksum 0 messages dropped due to no socket 0 multicast messages dropped due to no socket 0 messages dropped due to full socket buffers 0 delivered 0 datagrams output ------------------------------------------------------------------------ netstat -m netstat: invalid address (0x0) 1/144/145 mbufs in use (current/cache/total) 18446744073709551606/10/0/4018860 mbuf clusters in use (current/cache/total/max) 0/10 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/2009429 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/1786158 9k jumbo clusters in use (current/cache/total/max) 0/0/0/1339616 16k jumbo clusters in use (current/cache/total/max) 18014398509481964K/56K/36K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) ------------------------------------------------------------------------ netstat -anr Routing tables Internet: Destination Gateway Flags Netif Expire Internet6: Destination Gateway Flags Netif Expire ------------------------------------------------------------------------ netstat -anA ------------------------------------------------------------------------ netstat -aL ------------------------------------------------------------------------ fstat fstat: can't read file 1 at 0x200007fffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 7 at 0x200007fffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x200007fffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 7 at 0x200007fffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x200007fffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 7 at 0x200007fffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root zfs 75 root - - error - root zfs 75 wd - - error - root zfs 75 text - - error - root zfs 75 ctty /dev 13 crw------- console rw root zfs 75 0 /dev 13 crw------- console rw root zfs 75 6 /dev 13 crw------- console rw root sh 72 root - - error - root sh 72 wd - - error - root sh 72 text - - error - root sh 72 ctty /dev 13 crw------- console rw root sh 72 0 /dev 13 crw------- console rw root sh 72 6 /dev 13 crw------- console rw root sh 24 root - - error - root sh 24 wd - - error - root sh 24 text - - error - root sh 24 ctty /dev 13 crw------- console rw root sh 24 0 /dev 13 crw------- console rw root sh 24 6 /dev 13 crw------- console rw root init 1 root - - error - root init 1 wd - - error - root init 1 text - - error - root kernel 0 root - - error - root kernel 0 wd - - error - ------------------------------------------------------------------------ dmesg Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #1 r260896: Mon Jan 20 12:31:46 CST 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 info: [drm] Initialized drm 1.1.0 20060810 CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (2327.55-MHz K8-class CPU) Origin="GenuineIntel" Id=0x10676 Family=0x6 Model=0x17 Stepping=6 Features=0xbfebfbff Features2=0xce3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 68719476736 (65536 MB) avail memory = 65641644032 (62600 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard random: initialized kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) unknown: I/O range not supported cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 350 Event timer "HPET1" frequency 14318180 Hz quality 340 Event timer "HPET2" frequency 14318180 Hz quality 340 atrtc0: port 0x70-0x71 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 pcib5: at device 0.2 on pci3 pci5: on pcib5 pcib6: irq 18 at device 2.0 on pci2 pci6: on pcib6 em0: port 0x2000-0x201f mem 0xd9220000-0xd923ffff,0xd9200000-0xd921ffff irq 18 at device 0.0 on pci6 em0: Using an MSI interrupt em0: Ethernet address: 00:30:48:f2:29:9c em1: port 0x2020-0x203f mem 0xd9260000-0xd927ffff,0xd9240000-0xd925ffff irq 19 at device 0.1 on pci6 em1: Using an MSI interrupt em1: Ethernet address: 00:30:48:f2:29:9d pcib7: at device 0.3 on pci1 pci7: on pcib7 pcib8: at device 4.0 on pci0 pci8: on pcib8 vgapci0: port 0x3000-0x307f mem 0xd8000000-0xd8ffffff,0xc0000000-0xc7ffffff,0xc8000000-0xc9ffffff irq 16 at device 0.0 on pci8 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io hdac0: mem 0xd9000000-0xd9003fff irq 17 at device 0.1 on pci8 pcib9: at device 6.0 on pci0 pci9: on pcib9 pci0: at device 8.0 (no driver attached) pcib10: irq 17 at device 28.0 on pci0 pci10: on pcib10 pcib11: irq 16 at device 0.0 on pci10 pci11: on pcib11 pcm0: port 0x4080-0x409f,0x4000-0x407f irq 16 at device 0.0 on pci11 pcm0: system configuration SubVendorID: 0x1412, SubDeviceID: 0x2403 XIN2 Clock Source: 24.576MHz(96kHz*256) MPU-401 UART(s) #: not implemented ADC #: 1 and SPDIF receiver connected DAC #: 4 Multi-track converter type: AC'97(SDATA_OUT:packed) S/PDIF(IN/OUT): 1/1 ID# 0x00 GPIO(mask/dir/state): 0xff/0xff/0xff uhci0: port 0x1800-0x181f irq 17 at device 29.0 on pci0 usbus0 on uhci0 uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 usbus1 on uhci1 uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 usbus2 on uhci2 ehci0: mem 0xd9600400-0xd96007ff irq 17 at device 29.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib12: at device 30.0 on pci0 pci12: on pcib12 vgapci1: port 0x5000-0x50ff mem 0xd0000000-0xd7ffffff,0xd9300000-0xd930ffff irq 18 at device 1.0 on pci12 drmn1: on vgapci1 info: [drm] RADEON_IS_PCI info: [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080). info: [drm] register mmio base: 0xD9300000 info: [drm] register mmio size: 65536 info: [drm] radeon_atrm_get_bios: ===> Try ATRM... info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:8:0:0, vendor=10de, device=104a info: [drm] radeon_atrm_get_bios: Get ACPI device handle info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0xd0000000 info: [drm] igp_read_bios_from_vram: Map address: 0xfffff800d0000000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x0000 info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] radeon_read_bios: Map address: 0xfffff800000c0000 (131072 bytes) drmn1: info: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used) drmn1: info: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] radeon: irq initialized. info: [drm] Detected VRAM RAM=128M, BAR=128M info: [drm] RAM width 64bits SDR [TTM] Zone kernel: Available graphics memory: 33006090 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator info: [drm] radeon: 16M of VRAM memory ready info: [drm] radeon: 512M of GTT memory ready. info: [drm] GART: num cpu pages 131072, num gpu pages 131072 info: [drm] PCI GART of 512M enabled (table at 0x0000000011200000). drmn1: info: WB disabled drmn1: info: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0x0xfffff8001083c000 info: [drm] Loading R100 Microcode info: [drm] radeon: ring at 0x00000000B0001000 info: [drm] ring test succeeded in 1 usecs info: [drm] ib test succeeded in 0 usecs info: [drm] radeon_device_init: Taking over the fictitious range 0xd0000000-0xd4000000 iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iicbus1: on iicbb1 addr 0xff iic1: on iicbus1 iicbus2: on iicbb2 addr 0xff iic2: on iicbus2 iicbus3: on iicbb3 addr 0xff iic3: on iicbus3 info: [drm] Radeon Display Connectors info: [drm] Connector 0: info: [drm] VGA-1 info: [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60 info: [drm] Encoders: info: [drm] CRT1: INTERNAL_DAC1 info: [drm] Connector 1: info: [drm] DVI-I-1 info: [drm] HPD2 info: [drm] DDC: 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c info: [drm] Encoders: info: [drm] CRT2: INTERNAL_DAC2 info: [drm] DFP2: INTERNAL_DVO1 composite sync not supported composite sync not supported info: [drm] fb mappable at 0xD0040000 info: [drm] vram apper at 0xD0000000 info: [drm] size 2076672 info: [drm] fb depth is 8 info: [drm] pitch is 1920 fbd1 on drmn1 vt_allocate: Replace existing VT driver. info: [drm] Initialized radeon 2.29.0 20080528 vgapci1: Boot video device isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: at channel 0 on atapci0 ahci0: port 0x18a0-0x18a7,0x1874-0x1877,0x1878-0x187f,0x1870-0x1873,0x1880-0x189f mem 0xd9600800-0xd9600bff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ichsmb0: port 0x1100-0x111f irq 19 at device 31.3 on pci0 smbus0: on ichsmb0 acpi_button0: on acpi0 ipmi0: port 0xca2-0xca3 on acpi0 ipmi0: KCS mode found at io 0xca2 on acpi atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ichwd0 on isa0 orm0: at iomem 0xc0000-0xcafff on isa0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 coretemp4: on cpu4 est4: on cpu4 p4tcc4: on cpu4 coretemp5: on cpu5 est5: on cpu5 p4tcc5: on cpu5 coretemp6: on cpu6 est6: on cpu6 p4tcc6: on cpu6 coretemp7: on cpu7 est7: on cpu7 p4tcc7: on cpu7 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x387 offMax=0x491 hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm1: at nid 4 on hdaa0 pcm2: at nid 5 on hdaa0 random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen3.1: at usbus3 uhub0: on usbus3 ugen2.1: at usbus2 uhub1: on usbus2 ugen1.1: at usbus1 uhub2: on usbus1 ugen0.1: at usbus0 uhub3: on usbus0 ipmi0: IPMI device rev. 1, firmware rev. 1.64, version 2.0 ata0: DMA limited to UDMA33, controller found non-ATA66 cable ipmi0: Number of channels 8 ipmi0: Attached watchdog uhub2: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: Serial Number 5YDA1ZL4 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus2 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: Serial Number 5YD6FPLG ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada1: quirks=0x1<4K> ada1: Previously was known as ad6 ada2 at ahcich2 bus 0 scbus3 target 0 lun 0 ada2: ATA-8 SATA 3.x device ada2: Serial Number 5YDA3PC5 ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada2: quirks=0x1<4K> ada2: Previously was known as ad8 ada3 at ahcich3 bus 0 scbus4 target 0 lun 0 ada3: ATA-8 SATA 3.x device ada3: Serial Number 5YD9Y0P4 ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3: quirks=0x1<4K> ada3: Previously was known as ad10 ada4 at ahcich4 bus 0 scbus5 target 0 lun 0 ada4: ATA-8 SATA 3.x device ada4: Serial Number 5YDA1R5W ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada4: quirks=0x1<4K> ada4: Previously was known as ad12 ada5 at ahcich5 bus 0 scbus6 target 0 lun 0 ada5: ATA-8 SATA 3.x device ada5: Serial Number 5YD5RBS8 ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada5: quirks=0x1<4K> ada5: Previously was known as ad14 cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present Netvsc initializing... done! SMP: AP CPU #6 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #3 Launched! Root mount waiting for: usbus3 uhub0: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 Root mount waiting for: usbus3 ugen3.2: at usbus3 ukbd0: on usbus3 kbd2 at ukbd0 Trying to mount root from zfs:zroot/ROOT/default []... ugen0.2: at usbus0 ugen1.2: at usbus1 Setting hostuuid: 53d19f64-d663-a017-8922-0030488e9ff3. Setting hostid: 0xf53a926e. Entropy harvesting: interrupts ethernet point_to_point swi. Starting file system checks: Mounting local file systems:. panic: solaris assert: l->l_phys->l_hdr.lh_block_type == ((1ULL << 63) + 0) (0x0 == 0x8000000000000000), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c, line: 534 cpuid = 7 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe100c499090 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe100c499140 vpanic() at vpanic+0x126/frame 0xfffffe100c499180 panic() at panic+0x43/frame 0xfffffe100c4991e0 assfail3() at assfail3+0x2f/frame 0xfffffe100c499200 zap_get_leaf_byblk() at zap_get_leaf_byblk+0x4e1/frame 0xfffffe100c499250 zap_deref_leaf() at zap_deref_leaf+0xd1/frame 0xfffffe100c4992a0 fzap_cursor_retrieve() at fzap_cursor_retrieve+0xce/frame 0xfffffe100c499310 zap_cursor_retrieve() at zap_cursor_retrieve+0x20a/frame 0xfffffe100c499390 ddt_zap_walk() at ddt_zap_walk+0x5e/frame 0xfffffe100c499650 ddt_walk() at ddt_walk+0x78/frame 0xfffffe100c499680 dsl_scan_sync() at dsl_scan_sync+0x6ec/frame 0xfffffe100c4999e0 spa_sync() at spa_sync+0x5c4/frame 0xfffffe100c499ad0 txg_sync_thread() at txg_sync_thread+0x256/frame 0xfffffe100c499bb0 fork_exit() at fork_exit+0x84/frame 0xfffffe100c499bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe100c499bf0 --- trap 0, rip = 0, rsp = 0xfffffe100c499cb0, rbp = 0 --- KDB: enter: panic Uptime: 14s Dumping 2263 out of 64465 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% ------------------------------------------------------------------------ kernel config options CONFIG_AUTOGENERATED ident VT-LER machine amd64 cpu HAMMER makeoptions WITH_CTF=1 makeoptions DEBUG=-g options ZFS options XENHVM options USB_DEBUG options ATH_ENABLE_11N options AH_AR5416_INTERRUPT_MITIGATION options AH_SUPPORT_AR5416 options IEEE80211_SUPPORT_MESH options IEEE80211_AMPDU_AGE options IEEE80211_DEBUG options SC_PIXEL_MODE options VESA options AHD_REG_PRETTY_PRINT options AHC_REG_PRETTY_PRINT options ATA_STATIC_ID options ACPI_DMAR options SMP options MALLOC_DEBUG_MAXZONES=8 options INVARIANT_SUPPORT options INVARIANTS options DEADLKRES options GDB options DDB options KDB_TRACE options KDB options INCLUDE_CONFIG_FILE options DDB_CTF options KDTRACE_HOOKS options KDTRACE_FRAME options MAC options CAPABILITIES options CAPABILITY_MODE options AUDIT options HWPMC_HOOKS options KBD_INSTALL_CDEV options PRINTF_BUFR_SIZE=128 options _KPOSIX_PRIORITY_SCHEDULING options SYSVSEM options SYSVMSG options SYSVSHM options STACK options KTRACE options SCSI_DELAY=5000 options COMPAT_FREEBSD7 options COMPAT_FREEBSD6 options COMPAT_FREEBSD5 options COMPAT_FREEBSD4 options COMPAT_FREEBSD32 options GEOM_LABEL options GEOM_RAID options GEOM_PART_GPT options PSEUDOFS options PROCFS options CD9660 options MSDOSFS options NFS_ROOT options NFSLOCKD options NFSD options NFSCL options MD_ROOT options QUOTA options UFS_GJOURNAL options UFS_DIRHASH options UFS_ACL options SOFTUPDATES options FFS options SCTP options TCP_OFFLOAD options INET6 options INET options PREEMPTION options SCHED_ULE options NEW_PCIB options GEOM_PART_MBR options GEOM_PART_EBR_COMPAT options GEOM_PART_EBR options GEOM_PART_BSD device isa device mem device io device uart_ns8250 device cpufreq device acpi device pci device fdc device ahci device ata device mvs device siis device ahc device ahd device esp device hptiop device isp device mpt device mps device sym device trm device adv device adw device aic device bt device isci device scbus device ch device da device sa device cd device pass device ses device amr device arcmsr device ciss device dpt device hptmv device hptnr device hptrr device hpt27xx device iir device ips device mly device twa device tws device aac device aacp device aacraid device ida device mfi device mlx device twe device atkbdc device atkbd device psm device kbdmux device splash device agp device cbb device pccard device cardbus device uart device ppc device ppbus device lpt device ppi device puc device bxe device de device em device igb device ixgbe device le device ti device txp device vx device miibus device ae device age device alc device ale device bce device bfe device bge device cas device dc device et device fxp device gem device hme device jme device lge device msk device nfe device nge device pcn device re device rl device sf device sge device sis device sk device ste device stge device tl device tx device vge device vr device wb device xl device cs device ed device ex device ep device fe device sn device xe device wlan device wlan_wep device wlan_ccmp device wlan_tkip device wlan_amrr device an device ath device ath_pci device ath_hal device ath_rate_sample device ipw device iwi device iwn device malo device mwl device ral device wi device wpi device loop device random device padlock_rng device rdrand_rng device ether device vlan device tun device md device gif device faith device firmware device bpf device uhci device ohci device ehci device xhci device usb device ukbd device umass device sound device snd_cmi device snd_csa device snd_emu10kx device snd_es137x device snd_hda device snd_ich device snd_via8233 device mmc device mmcsd device sdhci device virtio device virtio_pci device vtnet device virtio_blk device virtio_scsi device virtio_balloon device hyperv device xenpci device vmx device vt device vt_vga ------------------------------------------------------------------------ ddb capture buffer -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Sat Jan 25 04:47:18 2014 Return-Path: Delivered-To: freebsd-current@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 57ACA2F7 for ; Sat, 25 Jan 2014 04:47:18 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1087A1E1D for ; Sat, 25 Jan 2014 04:47:17 +0000 (UTC) Received: by mail-vc0-f171.google.com with SMTP id le5so2348502vcb.16 for ; Fri, 24 Jan 2014 20:47:17 -0800 (PST) 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=pqMUcuSsoArXHoGaug0C8TJLWptR1nsZq20TmEGs/y4=; b=tBJ5ud25nAoF3Q5xh1tloe+kCx3WqPvG7cH/obyCR9W2KO9LFgJh2A+qkj3BdxOPq6 qd+Os0r8cLHMNov0tcqZcC1XEsTJ8LpBWNY4WH70EjCVM2ABMKT6kcefguLbttcQCIqX ROKFmh+5vpQpG2DBEXPQJcL08grla8JGnYWqQqWeBMvKhDuWq8a8ADr2o4ASRnObS/c9 Bk9Xvm9vxm35UblrFbUdwkvC5SMM5K0RXFElVQyW4pWCY6PwLN4WXNT+frIPr9jnvVBA kfhLyStGZU2hCuGztmnE9JUb8WVFo57WHggBpvqP7vPd4AXGS/tFCpsDhIImcomRd3NG tiPg== MIME-Version: 1.0 X-Received: by 10.220.139.136 with SMTP id e8mr6564282vcu.34.1390625237035; Fri, 24 Jan 2014 20:47:17 -0800 (PST) Received: by 10.220.168.135 with HTTP; Fri, 24 Jan 2014 20:47:16 -0800 (PST) In-Reply-To: References: Date: Fri, 24 Jan 2014 23:47:16 -0500 Message-ID: Subject: Re: lock order reversals w/ backtrace From: Thomas Hoffmann To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Hans Petter Selasky X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 04:47:18 -0000 On Fri, Jan 24, 2014 at 9:52 AM, Thomas Hoffmann wrote: > On Thu, Jan 23, 2014 at 11:49 AM, Hans Petter Selasky < > hans.petter.selasky@bitfrost.no> wrote: > >> Hi, >> >> Can you see if you can snap some keywords of the backtraces, like usb_xxx usbdx_xxx cam scsi or something like that. >> >> Else I believe there are some sysctl options to prevent the final reboot somehow so that you can write down the messages. >> >> --HPS >> >> >> -----Original message----- >> > From:Thomas Hoffmann >> > Sent: Thursday 23rd January 2014 17:15 >> >> > To: freebsd-current >> > Subject: lock order reversals w/ backtrace >> > >> > A few days ago I started running 11.0-CURRENT at r260971 for the first time. >> >> > >> > The last couple of times I shutdown my system I noticed 2 or 3 short "lock >> > order reversal" messages with accompanying backtraces scroll by. Do these >> > messages represent a problem that I should report or can I ignore them as >> >> > debug in nature? If I should report them, how or where do these messages >> > get logged? I can find no reference to them in syslog or anywhere else upon >> > my subsequent reboot. >> > >> > I also had a couple of these messages pop up the other day while >> >> > mounting/umounting USB thumb drives. I did not think anything of them at >> > the time as the mounts/umounts completed successfully. >> > >> > Please advise. Thanks. >> > >> > -Tom >> >> I managed to snap a photo of my screen during shutdown. > Here is the full text of the first of two lock order reversals I got last > night during system shutdown, both of which are zfs-related to (it > appears?) unmounts. A few lines got chopped as they were out-of-frame when > I took the photo: > > shutting down local daemons: > lock order reversal: > 1st 0xfffff801194f67c8 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237 > 2nd 0xfffff801194f6420 syncer (syncer) @ > /usr/src/sys/kern/vfs_subr.c:22[..chopped...] > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_delf_wrapper+0x2b/frame > 0xfffffe01ac78[...chopped...] > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe01ac784650 > witness_checkorder() at witness_checkorder+0xd23/frame 0xfffffe01ac7846e0 > __lockmgr_args() __lockmgr_args+0x878/frame 0xfffffe01ac784810 > vop_stdlock() at vop_stdlock+0x3c/frame 0xfffffe01ac784830 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfffffe01ac784860 > _vn_lock() at _vn_lock+0xab/frame 0xfffffe01ac7848d0 > vputx() at vputx+0x240/frame 0xfffffe01ac784930 > dounmount at dounmount+0x327/frame 0xfffffe01ac7849b0 > sys_unmount() at sys_unmount+0x356/frame 0xfffffe01ac784ac0 > amd64_syscall() at amd64_syscall+0x265/frame 0xfffffe01ac784bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe01ac784bf0 > --- syscall (22, FreeBSD ELF64, sys_unmount, rip = 0x80191c72a, > rsp[...chopped...] > > I have a zpool on an external USB HDD that I export at shutdown via > rc.shutdown.local. Don't know if that is contributing to this or not. When > I get a chance to bring down the system I will manually export it before > shutdown to see if that makes any difference. > Was able to capture the full text of the lock order reversal I've been experiencing at shutdown. Turns out to be associated with the export of one of my zpools that is hosted on an external USB HDD. Normally I export the zpool from rc.shutdown.local, but tonight I exported it manually before I shutdown and got the following. lock order reversal: : 1st 0xfffff8011952b5f0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237 : 2nd 0xfffff8011952b068 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2212 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe01add6e5a0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe01add6e650 witness_checkorder() at witness_checkorder+0xd23/frame 0xfffffe01add6e6e0 __lockmgr_args() at __lockmgr_args+0x878/frame 0xfffffe01add6e810 vop_stdlock() at vop_stdlock+0x3c/frame 0xfffffe01add6e830 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfffffe01add6e860 _vn_lock() at _vn_lock+0xab/frame 0xfffffe01add6e8d0 vputx() at vputx+0x240/frame 0xfffffe01add6e930 dounmount() at dounmount+0x327/frame 0xfffffe01add6e9b0 sys_unmount() at sys_unmount+0x356/frame 0xfffffe01add6eae0 amd64_syscall() at amd64_syscall+0x265/frame 0xfffffe01add6ebf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe01add6ebf0 --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x80191c72a, rsp = 0x7fffffffc4c8, rbp = 0x7fffffffc960 --- When imported and mounted, the zpool reports no errors and I have not experienced any anomalies reading or writing to the zpool. Should I be concerned? From owner-freebsd-current@FreeBSD.ORG Sat Jan 25 10:01:22 2014 Return-Path: Delivered-To: freebsd-current@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 AC607517 for ; Sat, 25 Jan 2014 10:01:22 +0000 (UTC) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 79AC51201 for ; Sat, 25 Jan 2014 10:01:22 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id wo20so4699589obc.10 for ; Sat, 25 Jan 2014 02:01:21 -0800 (PST) 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=rGuT0cWJfWd/r3ViL1dp1rJOrWb1+7IkO/Duhp5Zizc=; b=LTqb4od6JLOPHy2wm01S5P8xf19qaXymRXjN69E5flEttOPmwiJHegs6Lv6Ehkg7qk mFJ6iZixLKDZmAjD1DBRt7r54RhF8ouUDe/iK65UtH7s/Q99BSpcPyVuxQpBIdbf9rUZ cuGSM9FPSJ6mHOE8N9ziWMwx2ahZ96bz76imlOwAzEzft5Ub0DDFUDDiNtGRNT7rMeod KEgI+LCSilrBgJxLacGsQJ0kPEIpIEjgo2vS5imUDyFeDGStHVvZAXEHsjmh8GECJtq0 Vts1P/SD2OJy/9gIeDcF1bett4mugMtGlwcGcNd3MKtcIfxY8IV8CqL4dWh/EvfGJ/1O j6XQ== MIME-Version: 1.0 X-Received: by 10.182.2.170 with SMTP id 10mr370874obv.50.1390644081808; Sat, 25 Jan 2014 02:01:21 -0800 (PST) Received: by 10.60.63.107 with HTTP; Sat, 25 Jan 2014 02:01:21 -0800 (PST) Date: Sat, 25 Jan 2014 11:01:21 +0100 Message-ID: Subject: FOSDEM 2014 BSD devroom: A/V recording volunteers needed From: Benny Siegert To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 10:01:22 -0000 Hi all, FOSDEM 2014 is coming up (Feb 1 and 2 in Brussels), and there will be a BSD devroom on Saturday, Feb 1. There are several interesting FreeBSD-related talks. The schedule is here: https://fosdem.org/2014/schedule/track/bsd/ We still need one or more volunteers to help with recording the talks. Please contact me off-list if you are interested. See you there! --Benny. From owner-freebsd-current@FreeBSD.ORG Sat Jan 25 11:32:41 2014 Return-Path: Delivered-To: freebsd-current@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 86246427 for ; Sat, 25 Jan 2014 11:32:41 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1B79F18D6 for ; Sat, 25 Jan 2014 11:32:40 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 6A8E56A6006; Sat, 25 Jan 2014 12:32:38 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id s0PBWcav039772; Sat, 25 Jan 2014 12:32:38 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id s0PBWakL039716; Sat, 25 Jan 2014 12:32:36 +0100 (CET) (envelope-from lars) Date: Sat, 25 Jan 2014 12:32:36 +0100 From: Lars Engels To: Allan Jude Subject: Re: freebsd-update Message-ID: <20140125113236.GX86491@e-new.0x20.net> References: <5F09668C-0DEA-4074-A06C-BC4D29F92368@FreeBSD.org> <201401211149.45793.jhb@freebsd.org> <52E2C1BC.10202@allanjude.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+smLgjZrX8DJCqNF" Content-Disposition: inline In-Reply-To: <52E2C1BC.10202@allanjude.com> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p4 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 11:32:41 -0000 --+smLgjZrX8DJCqNF Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 24, 2014 at 02:40:44PM -0500, Allan Jude wrote: > On 2014-01-21 15:42, Kevin Oberman wrote: > > On Tue, Jan 21, 2014 at 8:49 AM, John Baldwin wrote: > > > >> On Tuesday, January 21, 2014 10:46:37 am David Chisnall wrote: > >>> On 21 Jan 2014, at 07:13, Antonio Olivares > >> wrote: > >>>> On Tue, Jan 21, 2014 at 7:49 AM, Ivan Voras > >> wrote: > >>>>> Hi, > >>>>> > >>>>> Is there any way I can avoid manually resolving hundreds of merge > >>>>> conflicts of the following type while using freebsd-update ? > >>>>> > >>>>> 1 <<<<<<< current version > >>>>> > >>>>> > >>>>> 2 # $FreeBSD: release/9.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:1= 0Z > >>>>> peter $ > >>>>> > >>>>> 3 =3D=3D=3D=3D=3D=3D=3D > >>>>> > >>>>> > >>>>> 4 # $FreeBSD: release/10.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:= 10Z > >>>>> peter $ > >>>>> > >>>>> 5 >>>>>>> 10.0-RELEASE > >>>>> > >>>>> > >>>>> > >>>>> ? > >>>>> > >>>>> I can't be the only one seeing those...? > >>>>> > >>>> Yes, One has to manually go one by one to fix these :( > >>>> I tried at one point a sed command like sed -i "" '>>>>' to fix > >>>> these, but it did not work correctly. I see errrors when booting wh= en > >>>> I don't correct these :( > >>> I thought this was fixed already (I didn't see these in the 9.2->10-R= C3 > >> upgrade). Doesn't freebsd-update pass -F (If the files differ only by= VCS > >> Id > >> ($FreeBSD) install the new file) to mergemaster? > >> > >> AFAIK it doesn't use mergemaster? I thought it used its own tool? I > >> really > >> want to figure out a way to let it use etcupdate instead since it hand= les > >> this case even for locally modified files cleanly. > >> > > Having just gone through this on a 10.0-rc5 to 10.0-RELEASE run, I can > > assure you that it is not completely fixed. One huge part is fixed... e= very > > file's ID line is no longer is changed on every release. OTOH, for files > > that are modified, thy still show up. It hit many of the sendmail .cf > > files. Annoying as I don't even use sendmail. > > > > Not sure if there was a good reason Colin re-invented the wheel on this= =2E It > > does not use mergemaster or even a reasonable differences editor such as > > the one mergemaster uses. Just going to the mergemaster code for handli= ng > > diffs would be a HUGE win. I am getting really tired of > > "/<<<<3ddddn". >=20 > I discussed this a bit with Colin on Wednesday during our interview with > him for BSDNow.tv >=20 > He had some problems with mergemaster so wrote his own tool. In 10 it > ignores the $Id tags, but there are still other changes that have to > either be merged or the file replaced with the new one. >=20 > I am all for further improvement here. Also using freebsd-update behind a proxy is really slow. Even with a very fast internet connection (normally download rates ca. 3 MBytes / s) downloading all the tiny binary diff files took more than 8 hours. Maybe freebsd-update's backend could create a tarball of all those diffs and provide this?=20 --+smLgjZrX8DJCqNF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iEYEARECAAYFAlLjoNQACgkQKc512sD3afjlQQCgq14NXTvy402XPx9z3L0o6eyG Kz0AnjGleQjoXiCGdAXmKOx+3/zWH6Wv =awd7 -----END PGP SIGNATURE----- --+smLgjZrX8DJCqNF-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 25 00:20:47 2014 Return-Path: Delivered-To: freebsd-current@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 AC8EF509; Sat, 25 Jan 2014 00:20:47 +0000 (UTC) Received: from olymp.kibab.com (olymp6.kibab.com [IPv6:2a01:4f8:160:84c1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6FE0217D3; Sat, 25 Jan 2014 00:20:46 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com 763813F438 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1390609245; bh=QnD5Xllbn9l00OP71g5JZOkhSR2ZfEC4qmpyULX7QN4=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=Pq6dBRW9ozL/kVBtT21ySP8pskP7gtxp6qzE42d0M5PzixnsJ4TGCC0vNzOU/oP8n bNnf1fBSd4FEEUe+FvO2JUQtj/jTRyyLjC1wlbyzoig94N2L85tAvN47FjQpgTQGxj kjWrjWruaFjsOAYaiwmnRsltBsoglyJPZwv6GGuE= Message-ID: <52E3035D.2060808@bakulin.de> Date: Sat, 25 Jan 2014 01:20:45 +0100 From: Ilya Bakulin MIME-Version: 1.0 To: John Baldwin Subject: Re: installworld for -CURRENT is broken on 9.1-R References: <52E2D027.9020604@bakulin.de> <201401241625.52839.jhb@freebsd.org> In-Reply-To: <201401241625.52839.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 25 Jan 2014 12:05:23 +0000 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 00:20:47 -0000 On 24.01.14, 22:25, John Baldwin wrote: >> So services_mkdb is taken from base system, and it indeed doesn't have >> -l switch introduced by your commit. > > This isn't from installworld. 'make distribute' doesn't get run as part of > 'installworld'. Can you tell me what command you actually ran? > Hm, actually this is a nanobsd script, tools/tools/nanobsd/nanobsd.sh. The failing call is in install_etc(). By the way, I had to add -DDB_FROM_SRC to the 'make distribution' call there, because otherwise it fails here with 'required used auditdistd now found'. -- Regards, Ilya Bakulin From owner-freebsd-current@FreeBSD.ORG Sat Jan 25 14:54:03 2014 Return-Path: Delivered-To: freebsd-current@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 2A214517 for ; Sat, 25 Jan 2014 14:54:03 +0000 (UTC) Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D684117C7 for ; Sat, 25 Jan 2014 14:54:02 +0000 (UTC) Received: by mail-vb0-f52.google.com with SMTP id p14so2447249vbm.39 for ; Sat, 25 Jan 2014 06:54:01 -0800 (PST) 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=BlEgZ516CjjlPUM8A+El/6/L31vdYK+oWBUz1u4ynN8=; b=Lz7uKDuX+ZoE983J4PaLKpCre2A/8tuARaZxb9hv8DtFtIPrIxtlOy6hMo6y1XUPpV /RqtyT+pVY2zXKR7MY9+1Up6KhODMQC7915nsGp1Q0qL2pnNToFrOr0hps3ri0amW4Hd KMQhX9j5rhLkftYKSasWiswdd2svifZ5InQd0HIVA5Fj1JEerYeonO8Z3CEQO/A0rlTR rTj/MttFqL3xtgGCX2Jn9FeUqIdzjqcsWNV5nxhUGiA7ZsqCZdcpXuxAPkxMsPekgBUA STvojwZNEYYlqOcYCvC3w7udPQ8Sse+pkuOlCGjcllKzIAyrx9zz1mndx/72cwQhcCzD 252w== MIME-Version: 1.0 X-Received: by 10.58.24.196 with SMTP id w4mr1885vef.48.1390661641801; Sat, 25 Jan 2014 06:54:01 -0800 (PST) Received: by 10.220.168.135 with HTTP; Sat, 25 Jan 2014 06:54:01 -0800 (PST) In-Reply-To: References: Date: Sat, 25 Jan 2014 09:54:01 -0500 Message-ID: Subject: Re: lock order reversals w/ backtrace From: Thomas Hoffmann To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Hans Petter Selasky X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 14:54:03 -0000 On Fri, Jan 24, 2014 at 11:47 PM, Thomas Hoffmann wrote: > On Fri, Jan 24, 2014 at 9:52 AM, Thomas Hoffmann wrote: > >> On Thu, Jan 23, 2014 at 11:49 AM, Hans Petter Selasky < >> hans.petter.selasky@bitfrost.no> wrote: >> >>> Hi, >>> >>> Can you see if you can snap some keywords of the backtraces, like usb_xxx usbdx_xxx cam scsi or something like that. >>> >>> Else I believe there are some sysctl options to prevent the final reboot somehow so that you can write down the messages. >>> >>> >>> --HPS >>> >>> >>> -----Original message----- >>> > From:Thomas Hoffmann >>> > Sent: Thursday 23rd January 2014 17:15 >>> >>> > To: freebsd-current >>> > Subject: lock order reversals w/ backtrace >>> > >>> > A few days ago I started running 11.0-CURRENT at r260971 for the first time. >>> >>> >>> > >>> > The last couple of times I shutdown my system I noticed 2 or 3 short "lock >>> > order reversal" messages with accompanying backtraces scroll by. Do these >>> > messages represent a problem that I should report or can I ignore them as >>> >>> >>> > debug in nature? If I should report them, how or where do these messages >>> > get logged? I can find no reference to them in syslog or anywhere else upon >>> > my subsequent reboot. >>> > >>> > I also had a couple of these messages pop up the other day while >>> >>> >>> > mounting/umounting USB thumb drives. I did not think anything of them at >>> > the time as the mounts/umounts completed successfully. >>> > >>> > Please advise. Thanks. >>> > >>> > -Tom >>> >>> I managed to snap a photo of my screen during shutdown. >> Here is the full text of the first of two lock order reversals I got last >> night during system shutdown, both of which are zfs-related to (it >> appears?) unmounts. A few lines got chopped as they were out-of-frame when >> I took the photo: >> >> shutting down local daemons: >> lock order reversal: >> 1st 0xfffff801194f67c8 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237 >> 2nd 0xfffff801194f6420 syncer (syncer) @ >> /usr/src/sys/kern/vfs_subr.c:22[..chopped...] >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_delf_wrapper+0x2b/frame >> 0xfffffe01ac78[...chopped...] >> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe01ac784650 >> witness_checkorder() at witness_checkorder+0xd23/frame 0xfffffe01ac7846e0 >> __lockmgr_args() __lockmgr_args+0x878/frame 0xfffffe01ac784810 >> vop_stdlock() at vop_stdlock+0x3c/frame 0xfffffe01ac784830 >> VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfffffe01ac784860 >> _vn_lock() at _vn_lock+0xab/frame 0xfffffe01ac7848d0 >> vputx() at vputx+0x240/frame 0xfffffe01ac784930 >> dounmount at dounmount+0x327/frame 0xfffffe01ac7849b0 >> sys_unmount() at sys_unmount+0x356/frame 0xfffffe01ac784ac0 >> amd64_syscall() at amd64_syscall+0x265/frame 0xfffffe01ac784bf0 >> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe01ac784bf0 >> --- syscall (22, FreeBSD ELF64, sys_unmount, rip = 0x80191c72a, >> rsp[...chopped...] >> >> I have a zpool on an external USB HDD that I export at shutdown via >> rc.shutdown.local. Don't know if that is contributing to this or not. When >> I get a chance to bring down the system I will manually export it before >> shutdown to see if that makes any difference. >> > > Was able to capture the full text of the lock order reversal I've been > experiencing at shutdown. Turns out to be associated with the export of one > of my zpools that is hosted on an external USB HDD. Normally I export the > zpool from rc.shutdown.local, but tonight I exported it manually before I > shutdown and got the following. > > lock order reversal: > : 1st 0xfffff8011952b5f0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237 > : 2nd 0xfffff8011952b068 syncer (syncer) @ > /usr/src/sys/kern/vfs_subr.c:2212 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe01add6e5a0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe01add6e650 > witness_checkorder() at witness_checkorder+0xd23/frame 0xfffffe01add6e6e0 > __lockmgr_args() at __lockmgr_args+0x878/frame 0xfffffe01add6e810 > vop_stdlock() at vop_stdlock+0x3c/frame 0xfffffe01add6e830 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfffffe01add6e860 > _vn_lock() at _vn_lock+0xab/frame 0xfffffe01add6e8d0 > vputx() at vputx+0x240/frame 0xfffffe01add6e930 > dounmount() at dounmount+0x327/frame 0xfffffe01add6e9b0 > sys_unmount() at sys_unmount+0x356/frame 0xfffffe01add6eae0 > amd64_syscall() at amd64_syscall+0x265/frame 0xfffffe01add6ebf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe01add6ebf0 > --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x80191c72a, rsp = > 0x7fffffffc4c8, rbp = 0x7fffffffc960 --- > > When imported and mounted, the zpool reports no errors and I have not > experienced any anomalies reading or writing to the zpool. Should I be > concerned? > > Hmm, seems like I'm the only one interested in this. I think I have resolved the problem with the zpool on the external USB HDD. I copied off the data, destroyed the datasets and zpool, recreated the zpool and datasets and restored the data. I have executed several exports on the zpool and have received no "lock order reversal" messages. I am still getting lock order reversal messages for my bootpool and zroot zpools at shutdown. Recreating bootpool would be relatively easy, but if I'm going to recreate zroot, I might as well do a reinistall, am I am not prepared to do at this time. So I'm still in search of an alternative way to resolve this issue. My zpools all show "no known data errors", scrub cleanly, zpool upgrade reports that all zpools support all features, and I've not experienced any other issues related to my zpools. Based on the above lock order reversal data, the error is in this block of code (, specifically /usr/src/sys/kern/vfs_mount.c:1237) if ((coveredvp = mp->mnt_vnodecovered) != NULL) { mnt_gen_r = mp->mnt_gen; VI_LOCK(coveredvp); vholdl(coveredvp); vn_lock(coveredvp, LK_EXCLUSIVE | LK_INTERLOCK | LK_RETRY); /* LINE 1237 */ vdrop(coveredvp); /* * Check for mp being unmounted while waiting for the * covered vnode lock. */ if (coveredvp->v_mountedhere != mp || coveredvp->v_mountedhere->mnt_gen != mnt_gen_r) { VOP_UNLOCK(coveredvp, 0); return (EBUSY); } } -Tom From owner-freebsd-current@FreeBSD.ORG Sat Jan 25 15:11:06 2014 Return-Path: Delivered-To: freebsd-current@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 9DBBF897 for ; Sat, 25 Jan 2014 15:11:06 +0000 (UTC) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6BB221913 for ; Sat, 25 Jan 2014 15:11:06 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9A5C220B91 for ; Sat, 25 Jan 2014 10:11:04 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Sat, 25 Jan 2014 10:11:04 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=x11wfbG/mwa659UMqPT/8LdNkPE=; b=c6W JUQ5of60pbU+IlzDwFUeRU6Zp3yTINd2GRKjeWjXpOutLs9H2f6SLH3GApx1fUP/ Om1Qsf3WIh2wQklv+aO/fmtMa91gNJq6JertIMpFWfOG7jufet9rv1r4mbBGR0L0 Q0GrdCNFzv8hTIqq3r4YnwFHWSYujh27qGS0AYew= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 6FC4F116168; Sat, 25 Jan 2014 10:11:04 -0500 (EST) Message-Id: <1390662664.13404.75208481.39F16B29@webmail.messagingengine.com> X-Sasl-Enc: K0LEw9zzMrM7JzNqdey7kG64wvXEcIpaJwZ9xdd5kJCB 1390662664 From: Mark Felder To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-aec78a11 In-Reply-To: <20140125113236.GX86491@e-new.0x20.net> References: <5F09668C-0DEA-4074-A06C-BC4D29F92368@FreeBSD.org> <201401211149.45793.jhb@freebsd.org> <52E2C1BC.10202@allanjude.com> <20140125113236.GX86491@e-new.0x20.net> Subject: Re: freebsd-update Date: Sat, 25 Jan 2014 09:11:04 -0600 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 15:11:06 -0000 On Sat, Jan 25, 2014, at 5:32, Lars Engels wrote: > > > Also using freebsd-update behind a proxy is really slow. Even with a > very fast internet connection (normally download rates ca. 3 MBytes / s) > downloading all the tiny binary diff files took more than 8 hours. > Maybe freebsd-update's backend could create a tarball of all those diffs > and provide this? Even streaming the tar instead of waiting for the freebsd-update server to produce the tarball would be an improvement. I have no experience doing that over a WAN but I don't see why it would be unreliable. From owner-freebsd-current@FreeBSD.ORG Sat Jan 25 17:36:58 2014 Return-Path: Delivered-To: freebsd-current@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 2D49572 for ; Sat, 25 Jan 2014 17:36:58 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DEEC912C5 for ; Sat, 25 Jan 2014 17:36:57 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id s0PHL7FH067611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 25 Jan 2014 09:21:07 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id s0PHL6CZ067610 for freebsd-current@freebsd.org; Sat, 25 Jan 2014 09:21:06 -0800 (PST) (envelope-from sgk) Date: Sat, 25 Jan 2014 09:21:06 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Subject: Instant panic CAM or USB subsystem Message-ID: <20140125172106.GA67590@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 17:36:58 -0000 If I plug my Samsung Intensity II cellphone into a usb port, I get an instant panic. This is 100% reproducible. I have the core and kernel for further debugging. Dmesg.boot follows my sig. % kgdb /boot/kernel/kernel /vmcore.0 Unread portion of the kernel message buffer: cd1 at umass-sim1 bus 1 scbus4 target 0 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: Serial Number 000000000002 cd1: 1.000MB/s transfers cd1: cd present [3840000 x 512 byte records] cd1: quirks=0x10<10_BYTE_ONLY> panic: mutex CAM device lock not owned at /usr/src/sys/cam/cam_periph.c:301 cpuid = 0 KDB: enter: panic (kgdb) bt #0 doadump (textdump=0) at pcpu.h:233 #1 0xc04cf211 in db_dump (dummy=-1065835907, dummy2=0, dummy3=-1, dummy4=0xe2af25e4 "") at /usr/src/sys/ddb/db_command.c:543 #2 0xc04cecd7 in db_command (cmd_table=) at /usr/src/sys/ddb/db_command.c:449 #3 0xc04cea10 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 #4 0xc04d12a2 in db_trap (type=, code=-1056387128) at /usr/src/sys/ddb/db_main.c:231 #5 0xc078a9f8 in kdb_trap (type=, code=, tf=) at /usr/src/sys/kern/subr_kdb.c:656 #6 0xc0a112f2 in trap (frame=) at /usr/src/sys/i386/i386/trap.c:711 #7 0xc09fa8cc in calltrap () at /usr/src/sys/i386/i386/exception.s:169 #8 0xc078a27d in kdb_enter (why=0xc0ad8ea3 "panic", msg=) at cpufunc.h:71 #9 0xc07546c3 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:752 #10 0xc0754702 in panic (fmt=0xc0ad6b73 "mutex %s not owned at %s:%d") at /usr/src/sys/kern/kern_shutdown.c:688 #11 0xc07401d9 in __mtx_assert (c=0x35db, what=, file=0x12
, line=1309824) at /usr/src/sys/kern/kern_mutex.c:793 #12 0xc047333c in cam_periph_find (name=) at /usr/src/sys/cam/cam_periph.c:301 #13 0xc0491062 in cdregister (periph=, arg=0xc72ee22c) at /usr/src/sys/cam/scsi/scsi_cd.c:1007 #14 0xc047313c in cam_periph_alloc (name=, path=0xc752d490, ac_callback=, code=) at /usr/src/sys/cam/cam_periph.c:249 #15 0xc04907cc in cdasync (callback_arg=, code=, arg=0xc78cd000) at /usr/src/sys/cam/scsi/scsi_cd.c:548 #16 0xc047d485 in xpt_async_process_dev (device=, arg=0xc78cd800) at /usr/src/sys/cam/cam_xpt.c:4206 #17 0xc047b126 in xpt_async_process (periph=0x0, ccb=0xc78cd800) at /usr/src/sys/cam/cam_xpt.c:4171 #18 0xc047baf5 in xpt_done_process (ccb_h=0xc78cd800) at /usr/src/sys/cam/cam_xpt.c:5247 #19 0xc047ecf4 in xpt_done_td (arg=) at /usr/src/sys/cam/cam_xpt.c:5274 #20 0xc07234df in fork_exit (callout=0xc047eb90 ) at /usr/src/sys/kern/kern_fork.c:977 #21 0xc09fa944 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:278 Current language: auto; currently minimal (kgdb) quit laptop-kargl:root[202] exit exit Script done on Sat Jan 25 09:11:35 2014 -- Steve Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #1 r260692: Wed Jan 15 14:10:51 PST 2014 kargl@laptop-kargl.apl.washington.edu:/dsk1/obj/usr/src/sys/MOBILE i386 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz 686-class CPU) Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20000000 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 3221225472 (3072 MB) avail memory = 3140329472 (2994 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard random: initialized kbd1 at kbdmux0 acpi0: on motherboard hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 acpi0: reservation of 0, 9f000 (3) failed acpi0: reservation of 100000, bf5c0400 (3) failed cpu0: on acpi0 cpu1: on acpi0 atrtc0: port 0x70-0x71,0x72-0x77 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 2 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xefe8-0xefef mem 0xfea00000-0xfeafffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 7676k stolen memory drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) info: [drm] AGP at 0xe0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 vgapci0: Boot video device vgapci1: mem 0xfeb00000-0xfebfffff at device 2.1 on pci0 uhci0: port 0x6f20-0x6f3f irq 20 at device 26.0 on pci0 usbus0 on uhci0 uhci1: port 0x6f00-0x6f1f irq 21 at device 26.1 on pci0 usbus1 on uhci1 ehci0: mem 0xfed1c400-0xfed1c7ff irq 22 at device 26.7 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci0 hdac0: mem 0xfe9fc000-0xfe9fffff irq 21 at device 27.0 on pci0 pcib1: at device 28.0 on pci0 pci11: on pcib1 pcib2: at device 28.1 on pci0 pci12: on pcib2 wpi0: mem 0xfe8ff000-0xfe8fffff irq 17 at device 0.0 on pci12 pcib3: at device 28.5 on pci0 pci9: on pcib3 bge0: mem 0xfe7f0000-0xfe7fffff irq 17 at device 0.0 on pci9 bge0: CHIP ID 0x0000a002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:1d:09:ba:cc:0d uhci2: port 0x6f80-0x6f9f irq 20 at device 29.0 on pci0 usbus3 on uhci2 uhci3: port 0x6f60-0x6f7f irq 21 at device 29.1 on pci0 usbus4 on uhci3 uhci4: port 0x6f40-0x6f5f irq 22 at device 29.2 on pci0 usbus5 on uhci4 ehci1: mem 0xfed1c000-0xfed1c3ff irq 20 at device 29.7 on pci0 usbus6: EHCI version 1.0 usbus6 on ehci1 pcib4: at device 30.0 on pci0 pci3: on pcib4 cbb0: at device 1.0 on pci3 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pci3: at device 1.4 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x6fa0-0x6faf irq 16 at device 31.1 on pci0 ata0: at channel 0 on atapci0 atapci1: port 0x6eb0-0x6eb7,0x6eb8-0x6ebb,0x6ec0-0x6ec7,0x6ec8-0x6ecb,0x6ee0-0x6eef,0xeff0-0xefff irq 17 at device 31.2 on pci0 ata2: at channel 0 on atapci1 ata3: at channel 1 on atapci1 ichsmb0: port 0x10c0-0x10df mem 0xfe9fbf00-0xfe9fbfff irq 17 at device 31.3 on pci0 smbus0: on ichsmb0 smb0: on smbus0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64,0x62,0x66 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ichwd0 on isa0 ichwd0: resuming after hardware watchdog timeout orm0: at iomem 0xc0000-0xcefff,0xcf000-0xcffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <8 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 Timecounters tick every 1.000 msec hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 13,10 and 12,11 on hdaa0 random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 480Mbps High Speed USB v2.0 ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: at usbus0 uhub1: on usbus0 ugen4.1: at usbus4 uhub2: on usbus4 ugen3.1: at usbus3 uhub3: on usbus3 ugen2.1: at usbus2 uhub4: on usbus2 ugen6.1: at usbus6 uhub5: on usbus6 ugen5.1: at usbus5 uhub6: on usbus5 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered uhub4: 4 ports with 4 removable, self powered ada0 at ata2 bus 0 scbus1 target 0 lun 0 ada0: ATA-7 SATA 1.x device ada0: Sercd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present ial Number WD-WXCZ07905963 ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) ada0: 76319MB (156301488 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 SMP: AP CPU #1 Launched! Root mount waiting for: usbus6 uhub5: 6 ports with 6 removable, self powered Root mount waiting for: usbus6 Root mount waiting for: usbus6 ugen6.2: at usbus6 umass0: on usbus6 (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: Error code 0x0 (probe0:umass-sim0:0:0:0): Error 22, Unretryable error da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 da0: Fixed Direct Access SCSI-6 device da0: Serial Number 2010110600754 da0: 40.000MB/s transfers da0: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) da0: quirks=0x2 ugen4.2: at usbus4 ums0: on usbus4 ums0: 8 buttons and [XYZT] coordinates ID=0 uhid0: on usbus4 Trying to mount root from ufs:/dev/ad0s3a [rw]... WARNING: / was not properly dismounted wlan0: Ethernet address: 00:1c:bf:90:ab:44 From owner-freebsd-current@FreeBSD.ORG Sat Jan 25 17:44:00 2014 Return-Path: Delivered-To: freebsd-current@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 4EED5601 for ; Sat, 25 Jan 2014 17:44:00 +0000 (UTC) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D578A1367 for ; Sat, 25 Jan 2014 17:43:59 +0000 (UTC) Received: by mail-bk0-f51.google.com with SMTP id w10so1946811bkz.38 for ; Sat, 25 Jan 2014 09:43:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:mime-version:content-type:subject:from:date:to :message-id; bh=trAW0vV/9cZFiiCIt08cuj1fdJBIu/FOS9qwwWCCNmU=; b=AiLwzd2Ur/uj2a2ZoOB+/KdcaUSc20bNYU38AUHFpm3W7g/Tsu+yR3hGqMdf6UsvNQ nzb/TnrESNB7Qkj7IGFoSFAKTT9XmGLE4IYkl5swSJDNUspILwBUS9MNNDjnhf85gUnh NuENa9zhN5JuFY4ElqxwOAaB+E6gdytpvt4aeaHUVqfm9u9L8jIx/PbEh7ZtRHcTRwwM y/j8WwrtgAmFOhcE8i6aKg5c4/wEEY3JTigbzpjLqrDBPTZxD+6QH+QLOqQHw84H8384 2V0UaLfHxbwLzagP3o6ckCCt2nr+gTfhs0llGgg0YOms946BXznOflcAQeAXOSaUrLzE aztQ== X-Received: by 10.204.71.134 with SMTP id h6mr5159bkj.109.1390671838100; Sat, 25 Jan 2014 09:43:58 -0800 (PST) Received: from ?IPV6:2001:470:7b2f:0:d02b:d335:23e4:fe54? ([2001:470:7b2f:0:d02b:d335:23e4:fe54]) by mx.google.com with ESMTPSA id dj5sm6975972bkc.7.2014.01.25.09.43.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Jan 2014 09:43:57 -0800 (PST) User-Agent: K-9 Mail for Android MIME-Version: 1.0 Subject: Newcons radeonkms - Failed to load firmware "radeonkmsfw_TURKS_PFP" From: "Mike C." Date: Sat, 25 Jan 2014 17:43:53 +0000 To: "freebsd-current@freebsd.org" Message-ID: <1367fd4d-9128-4df0-a250-fb3c1f67f0c5@email.android.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 17:44:00 -0000 Please see the attached jpeg for the full error. After rebuilding the kernel with newcons support (which is working) I've placed radeonkms_load="YES" in boot loader and rebooted and get this screen. what am I doing wrong? thanks -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From owner-freebsd-current@FreeBSD.ORG Sat Jan 25 17:50:28 2014 Return-Path: Delivered-To: freebsd-current@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 67A6D9A9 for ; Sat, 25 Jan 2014 17:50:28 +0000 (UTC) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1979613AC for ; Sat, 25 Jan 2014 17:50:28 +0000 (UTC) Received: by mail-vb0-f49.google.com with SMTP id x14so2519221vbb.36 for ; Sat, 25 Jan 2014 09:50:27 -0800 (PST) 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=3Ydu62L02XnSS9WaAc443uX/VaI85cqOjv4H2U6JLGY=; b=qfbf4H3+471TH/4aCIIspWL7+JAe1PGv56V8EKlW6Jja2hFxL8vTzptBAMt138Fn1T SE/N8z6O5+e0wHtmaHS1c2vnibBXlzp3o3w1xzRXv+9Rn9bACIB6nJ1B0sONzqe5PeRr CMulCcpMa1v8zb+9tL6eG+DEUAFndnvJ0EkDw34gETkHqTh37FSiiY98g+B+Dft4svSX pmmlhJNRM8L/QgPCRdyHVg0gGVDOLMaAfWH4/TBU9p4XX1FgxJvpSuIat2a0LEmCbYU2 CN3ymS+XzfZbxuNxQS6LQ+IgMTE8FvZ5qlphhTts0BmkBIuIU7/qNohUCZxhxJFIHq+M BG/w== MIME-Version: 1.0 X-Received: by 10.220.247.68 with SMTP id mb4mr2006164vcb.37.1390672226812; Sat, 25 Jan 2014 09:50:26 -0800 (PST) Received: by 10.58.251.10 with HTTP; Sat, 25 Jan 2014 09:50:26 -0800 (PST) Date: Sat, 25 Jan 2014 18:50:26 +0100 Message-ID: Subject: =?windows-1252?Q?SDHC_Sony_SF=2D8UX=2C_advertised_as_94MB=2Fs_max_read_spee?= =?windows-1252?Q?d=2C_don=92t_works=2E?= From: "Ranjan1018 ." <214748mv@gmail.com> To: freebsd-current@freebsd.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 17:50:28 -0000 I=92m trying to use this SDHC as a ZFS cache on a Samsung laptop: da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: Serial Number 058F63666438 da0: 40.000MB/s transfers da0: 7667MB (15702016 512 byte sectors: 255H 63S/T 977C) da0: quirks=3D0x2 After some minutes of usage this error is displayed : (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 0a 97 9f 00 00 05 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready to ready change, medium may have changed) (da0:umass-sim0:0:0:0): Command Specific Info: 0xaa5501 (da0:umass-sim0:0:0:0): Retrying command (per sense data) (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 0a 97 9f 00 00 05 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da0:umass-sim0:0:0:0): Command Specific Info: 0xaa5501 (da0:umass-sim0:0:0:0): Error 6, Unretryable error (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 00 01 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready to ready change, medium may have changed) (da0:umass-sim0:0:0:0): Command Specific Info: 0xaa5501 (da0:umass-sim0:0:0:0): Retrying command (per sense data) (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 00 01 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da0:umass-sim0:0:0:0): Command Specific Info: 0xaa5501 (da0:umass-sim0:0:0:0): Error 6, Unretryable error GEOM: da0: corrupt or invalid GPT detected. GEOM: da0: GPT rejected -- may not be recoverable. Trying to use the SDHC as a MS-DOS device I have receive the error: (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 4a 00 00 00 00 80 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready to ready change, medium may have changed) (da0:umass-sim0:0:0:0): Command Specific Info: 0xaa5501 (da0:umass-sim0:0:0:0): Retrying command (per sense data) (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 4a 00 00 00 00 80 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da0:umass-sim0:0:0:0): Command Specific Info: 0xaa5501 (da0:umass-sim0:0:0:0): Error 6, Unretryable error I=92m using: [root@ativ ~/bin]# uname -a FreeBSD ativ.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r260700: Thu Jan 16 07:03:04 CET 2014 root@ativ.local:/usr/obj/usr/src/sys/NEWCONS amd64 I=92ve tested the card in Mac OS X on a Mac mini and in Windows 8 on the sa= me laptop, without problems. I=92ve only noted that the I/O speed is much low= er on the Mac mini. Mac Write: mac-mini:~ maurizio$ sudo dd if=3D/dev/zero of=3D/dev/disk1 bs=3D1048576 count=3D200 209715200 bytes transferred in 138.019361 secs (1519462 bytes/sec) Mac Read: mac-mini:~ maurizio$ sudo dd of=3D/dev/null if=3D/dev/disk1 bs=3D1048576 count=3D200 209715200 bytes transferred in 23.719487 secs (8841473 bytes/sec) FreeBSD Write: [root@ativ ~]# dd if=3D/dev/zero of=3D/dev/da0 bs=3D1048576 count=3D200 209715200 bytes transferred in 13.647264 secs (15366831 bytes/sec) FreeBSD Read: [root@ativ ~]# dd of=3D/dev/null if=3D/dev/da0 bs=3D1048576 count=3D200 209715200 bytes transferred in 11.050251 secs (18978320 bytes/sec) Windows Write: with DH_Speed 1 min. test 16M/sec Windows Read: with DH_Speed 1 min. test 17.4M/sec Regards, Maurizio From owner-freebsd-current@FreeBSD.ORG Sat Jan 25 17:56:26 2014 Return-Path: Delivered-To: freebsd-current@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 DEAD7D24 for ; Sat, 25 Jan 2014 17:56:25 +0000 (UTC) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 68CDC14A9 for ; Sat, 25 Jan 2014 17:56:25 +0000 (UTC) Received: by mail-bk0-f51.google.com with SMTP id w10so1936678bkz.24 for ; Sat, 25 Jan 2014 09:56:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:in-reply-to:references:mime-version:content-type:subject :from:date:to:message-id; bh=ju45PvSvMTRHKJr2A+2FOArfPBBL6Id6exgNdVA1vWM=; b=qSjiak9cKNt46K4K/DwS0y9XFjGHTjRwGXcTxQNo+BNA6RngnLfQXpmI92gZxlX+8j dnFYUu545z7nHArmBVO+QDcX92LsgWAkl560XIeVQw9G9vMctxmbCVWMlT8J+RS0bg0u OjWuhQiBNHu4g/XSTJgon5TnFScUQH4HzTrz3fMgq6Husr62e/34kJgGIhMaa+u/daFO vtceOsZ98y4QkGmKrNS0ZXeFy5uvvD4hi5FNCsjjyYABy+FL7xNGNZ0HLMtk9w0tnzlx rMco/mYpThKgRl6vcVoad3297zH6pJQtkY3q5NghVWtRJtofWxoLSi5jYBDCk05K5abr vang== X-Received: by 10.204.171.204 with SMTP id i12mr37648bkz.126.1390672583817; Sat, 25 Jan 2014 09:56:23 -0800 (PST) Received: from ?IPV6:2001:470:7b2f:0:d02b:d335:23e4:fe54? ([2001:470:7b2f:0:d02b:d335:23e4:fe54]) by mx.google.com with ESMTPSA id o11sm6993370bkg.13.2014.01.25.09.56.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Jan 2014 09:56:23 -0800 (PST) User-Agent: K-9 Mail for Android In-Reply-To: <1367fd4d-9128-4df0-a250-fb3c1f67f0c5@email.android.com> References: <1367fd4d-9128-4df0-a250-fb3c1f67f0c5@email.android.com> MIME-Version: 1.0 Subject: Re: Newcons radeonkms - Failed to load firmware "radeonkmsfw_TURKS_PFP" From: "Mike C." Date: Sat, 25 Jan 2014 17:56:19 +0000 To: "freebsd-current@freebsd.org" Message-ID: <83d3287c-e2d1-4512-92a8-4bed5be1455b@email.android.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 17:56:26 -0000 the line: error: [drm:pid0evergreen_startup] *ERROR* radeon: MC ucode required for NI+ is maybe more relevant? the other error seems to be related with GPU acceleration, but this one seems to be causing me init failure? Or not... Thanks "Mike C." wrote: > >Please see the attached jpeg for the full error. > >After rebuilding the kernel with newcons support (which is working) >I've placed radeonkms_load="YES" in boot loader and rebooted and get >this screen. > >what am I doing wrong? > >thanks >-- >Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From owner-freebsd-current@FreeBSD.ORG Sat Jan 25 18:58:40 2014 Return-Path: Delivered-To: freebsd-current@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 AE741688 for ; Sat, 25 Jan 2014 18:58:40 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 72CA21957 for ; Sat, 25 Jan 2014 18:58:40 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id s0PIwdUp068155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 25 Jan 2014 10:58:39 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id s0PIwdsw068154 for freebsd-current@freebsd.org; Sat, 25 Jan 2014 10:58:39 -0800 (PST) (envelope-from sgk) Date: Sat, 25 Jan 2014 10:58:39 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Subject: Re: Instant panic CAM or USB subsystem Message-ID: <20140125185839.GA68145@troutmask.apl.washington.edu> References: <20140125172106.GA67590@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140125172106.GA67590@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 18:58:40 -0000 On Sat, Jan 25, 2014 at 09:21:06AM -0800, Steve Kargl wrote: > If I plug my Samsung Intensity II cellphone into a usb port, > I get an instant panic. This is 100% reproducible. I have > the core and kernel for further debugging. Dmesg.boot follows > my sig. Panic occurs with a kernel compiled with either clang or gcc. -- steve From owner-freebsd-current@FreeBSD.ORG Sat Jan 25 20:02:09 2014 Return-Path: Delivered-To: current@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 D7A2F597; Sat, 25 Jan 2014 20:02:09 +0000 (UTC) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C188310EB; Sat, 25 Jan 2014 20:02:08 +0000 (UTC) Received: by mail-ea0-f182.google.com with SMTP id r15so1592562ead.27 for ; Sat, 25 Jan 2014 12:02:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:organization:mime-version :content-type:content-transfer-encoding; bh=9OrG1crjScIS5qBul504Q91aeahDnazNQ/C384mH5c0=; b=ieXXUj857YjuOhgCL+dG4EkU6iDk3fk5irmNNNMzApQqUCL7RjnXmhB1b/Bd2kCozH E5AGoWwwmjfuTQfluy4ro07u5UPN9Y1CwBPQNljMMY9wimnayOka+mS7KPZ1gO4SmCaE cpvclhadjJy3uyExaHvXk9ehf/cvus6XfXjOsL+HZBe+w8qHpMDsCQWsICr79rCNd6GZ IgOyPFiJHP5zVG5zuKb1CKefQ5pLEjtGkKm5TmyCAZU5LJlGKjK7Dr2482A601jjrxmA hnWrjxVhRQYuL7KFog/Z9GL2a3D6LWMMdOKgWCAw75RbDvIIdPoFhLY6LQu67+vHRzb4 0tfQ== X-Received: by 10.14.10.73 with SMTP id 49mr252139eeu.96.1390680126946; Sat, 25 Jan 2014 12:02:06 -0800 (PST) Received: from funktor (catv-80-99-67-72.catv.broadband.hu. [80.99.67.72]) by mx.google.com with ESMTPSA id n7sm19770939eef.5.2014.01.25.12.02.04 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sat, 25 Jan 2014 12:02:06 -0800 (PST) Sender: =?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?= Date: Sat, 25 Jan 2014 21:02:01 +0100 From: Gabor Pali To: hackers@freebsd.org Subject: FreeBSD Quarterly Status Report, October-December 2013 Message-ID: <20140125210201.0310e35e@funktor> Organization: The FreeBSD Project X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.22; i386-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 20:02:09 -0000 FreeBSD Quarterly Status Report, October-December 2013 Introduction This report covers FreeBSD-related projects between October and December 2013. This is the last of four reports planned for 2013. The last quarter of 2013 was very active for the FreeBSD community, much like the preceding quarters. Many advances were made in getting FreeBSD to run on ARM-based System-on-Chip boards like Cubieboard, Rockchip, Snapdragon, S4, Freescale i.MX6 and Vybrid VF6xx. FreeBSD is also becoming a better platform for Xen and the Amazon Elastic Compute Cloud. There are plans for FreeBSD to become a fully supported compute host for OpenStack. The I/O stack has again received some performance boosts on multi-processor systems through work touching the CAM and GEOM subsystems, and through better adaptation of UMA caches to system memory constraints for ZFS. The FreeBSD Foundation did an excellent job in this quarter, and many of their sponsored projects like VT-d and UEFI support, iSCSI stack, Capsicum, and auditdistd are about to complete. At the same time, new projects like Automounter and Intel GPU updates have just been launched. The Newcons project has been merged into -CURRENT, which will make it possible to finally move to the latest version of X.Org in the Ports Collection. Efforts are also under way to improve testing with Jenkins and Kyua. It is an exciting time for users and developers of FreeBSD! Thanks to all the reporters for the excellent work! This report contains 37 entries and we hope you enjoy reading it. The deadline for submissions covering between January and March 2014 is April 7th, 2014. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Cluster Administration Team * FreeBSD Core Team * FreeBSD Port Management Team * FreeBSD Postmaster Team * FreeBSD Release Engineering Team Projects * CBSD * Jenkins Continuous Integration for FreeBSD Kernel * GEOM Direct Dispatch and Fine-Grained CAM Locking * Intel 802.11n NIC (iwn(4)) Work * Intel GPU Driver Update * Native iSCSI Stack * New Automounter * UEFI Boot * UMA/ZFS and RPC/NFS Performance Improvements * Updated vt(9) System Console Architectures * FreeBSD Host Support for OpenStack and OpenContrail * FreeBSD on Cubieboard{1,2} * FreeBSD on Freescale i.MX6 processors * FreeBSD on Freescale Vybrid VF6xx * FreeBSD on Newer ARM Boards * FreeBSD/EC2 * FreeBSD/Xen * Intel IOMMU (VT-d, DMAR) Support Userland Programs * auditdistd(8) * Base GCC Updates * BSDInstall ZFSBoot * Capsicum and Casper * Centralized Panic Reporting * FreeBSD Test Suite * The LLDB Debugger Ports * FreeBSD Python Ports * GNOME/FreeBSD * KDE/FreeBSD * Wine/FreeBSD * X.Org on FreeBSD * Xfce/FreeBSD Miscellaneous * The FreeBSD Foundation __________________________________________________________________ FreeBSD Cluster Administration Team Contact: FreeBSD Cluster Administration Team The FreeBSD Cluster Administration Team consists of the people responsible for administering the machines that the project relies on for its distributed work and communications to be synchronised. In the last quarter of 2013, they continued general maintenance of the FreeBSD cluster across all sites. In addition to general upkeep tasks, additional cluster-related items were addressed. Some of these items include: * Added several machines for the Kyua testing framework. * Replaced failed hardware hosting various web services. * Coordinated with the FreeBSD Security Officer and Ports Management Teams to implement signed binary packages. * Added the redports.org machines to the list of machines managed by the Cluster Administration Team. * Began discussion with contacts at Yandex regarding the addition of a mirror site for binary packages and Subversion repositories. __________________________________________________________________ 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. In the fourth quarter of 2013, the Core Team finally reached its previous goal of launching the official repositories for pkg(8)-based binary packages. The Core Team also unified the commit bit expiration policies for all Project repositories, allowing committers to idle for 18 months before their commit bits are automatically taken into safekeeping. This was then followed by an extension to suspension of cluster accounts for the committers who lost all of their commit bits. This helps to improve the security of the Project server cluster by temporarily disabling inactive accounts. In addition to the above efforts, Thomas Abthorpe resurrected the "Grim Reaper" service which helps to enforce the aforementioned policy. With the work of John Baldwin, Hiroki Sato, and others, many licenses in the base system source code have been revisited and cleaned up. Furthermore, the Core Team is hoping that the situation can be improved by introducing periodic automated checks of the license agreements, and by providing developers guidelines on questions of licensing. John Baldwin and David Chisnall have been guiding the work of the FreeBSD Graphics Team on moving to the newer version of X.Org and related software in the Ports Collection, in coordination with the switch to Newcons on FreeBSD 10.x. It was a busy quarter for the src repository as well. The Core Team was happy to welcome Jordan K. Hubbard (jkh) back who has recently returned to the FreeBSD business, and joined iXsystems as project manager and release engineer of FreeNAS. In addition to this, there were 3 commit bits offered for new developers, 2 committers were upgraded, 1 commit bit was taken for safekeeping, and 1 src bit was reactivated. __________________________________________________________________ FreeBSD Port Management Team URL: http://www.FreeBSD.org/ports/ URL: http://www.freebsd.org/doc/en/articles/contributing-ports/ 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: FreeBSD Port Management Team The FreeBSD Ports collection is a package management system for the FreeBSD operating system, providing an easy and consistent way of installing software packages. The FreeBSD Ports Collection now contains approximately 24,500 ports, while the PR count exceeds 1,900. The FreeBSD Port Management Team ensures that the FreeBSD ports developer community provides a Ports Collection that is functional, stable, up-to-date and full-featured. Its secondary responsibility is to coordinate among the committers and developers who work on it. As part of these efforts, we added 3 new committers, took in 3 commit bits for safe keeping, and reinstated 1 commit bit in the fourth quarter of 2013. Ongoing effort went into testing larger changes, as many as 8 a week, including sweeping changes to the tree, moderization of the infrastructure, and basic quality assurance (QA) runs. Many iterations of tests against 10.0-RELEASE were run to ensure that the maximum number of packages would be available for the release. We now have pkg(8) packages for the releases 8.3, 8.4, 9.1, 9.2, 10.0 and -CURRENT on pkg.FreeBSD.org. During this same time, further enhancements were put into pkg(8), including secure package signing. Commencing November 1, the Port Management Team undertook a "portmgr-lurkers" pilot project in which ports committers could volunteer to assist the Port Management Team for a four-month duration. The first two candiates are Mathieu Arnold (mat) and Antoine Brodin (antoine). Ongoing maintenance goes into redports.org, including QAT runs, ports and security updates. Open tasks: 1. As previously noted, many PRs continue to languish; we would like to see some committers dedicate themselves to closing as many as possible! __________________________________________________________________ FreeBSD Postmaster Team URL: http://lists.freebsd.org/mailman/listinfo/svn-src-stable-10 URL: http://lists.freebsd.org/mailman/listinfo/ctm-src-10 URL: http://lists.freebsd.org/mailman/listinfo/ctm-src-10-fast URL: http://www.freebsd.org/doc/en/articles/committers-guide/pgpkeys.html Contact: FreeBSD Postmaster Team In the fourth quarter of 2013, the FreeBSD Postmaster Team has implemented the following items that may be interest of the general public: * Retired the freebsd-aic7xxx mailing list. * Created a graphics-team alias, requested by Niclas Zeising. * Worked with the FreeBSD Port Management Team to set up portmgr-lurkers so port managers can move addresses between those two aliases at their discretion. * Created the lists associated with the new stable/10 branch: svn-src-stable-10, ctm-src-10, and ctm-src-10-fast. * Redirected the vbox alias to the emulation list, requested by Bernhard Fr=C3=B6hlich. * Continued a discussion on current and possible future mail and spam filtering. * Disbanded lua and transferred it to Baptiste Daroussin, requested by Matthias Andree and Baptiste Daroussin. * Modified the list moderators/administrators for ports-secteam, requested by Dag-Erling Sm=C3=B8rgrav. * Assisted Warren Block with an update to the "OpenPGP Keys for FreeBSD" section of the Committer's Guide. __________________________________________________________________ FreeBSD Release Engineering Team URL: http://www.FreeBSD.org/releases/10.0R/schedule.html URL: http://ftp.FreeBSD.org/pub/FreeBSD/snapshots/VM-IMAGES/ URL: http://ftp.FreeBSD.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is finishing the 10.0-RELEASE cycle. The release cycle changed with two last-minute release candidate builds, each addressing fixes critical to include in the final release. The FreeBSD 10.0-RELEASE cycle is expected to be completed by mid-January, approximately eight weeks behind the original schedule. __________________________________________________________________ CBSD URL: http://www.bsdstore.ru/ URL: https://github.com/olevole/cbsd Contact: Oleg Ginzburg CBSD is another FreeBSD jail management solution, aimed at combining various features, such as racct(8), vnet, zfs(8), carp(4), and hastd(8), into a single tool. This provides a more comprehensive way to build application servers using pre-installed jails with a typical set of software, and requires minimal effort to configure. Open tasks: 1. Proper English translation of the website and the documentation. __________________________________________________________________ Jenkins Continuous Integration for FreeBSD URL: http://www.ixsystems.com/whats-new/jenkins-bhyve-and-webdriver-cont= inuous-integration-testing-on-freenas/ Contact: Craig Rodrigues At the November 2013 FreeBSD Vendor Summit, some of the work was presented that Craig Rodrigues has been doing with Continuous Integration and Testing at iXsystems. Craig's presentation described how iXsystems is using modern best practices for building and testing the FreeNAS code. Jenkins is a framework for doing continuous builds and integration that is used by hundreds of companies. BHyve (BSD Hypvervisor) is the new virtual machine system which will be part of FreeBSD 10. Webdriver is a Python toolkit for testing web applications. By combining these technologies, iXsystems is developing a modern and sophisticated workflow for testing and improving the quality of FreeNAS. Ed Maste from The FreeBSD Foundation was interested in this work, and based on this interest, it is now being ported to FreeBSD. Currently, a machine in the FreeBSD cluster has been allocated for this purpose, where a bhyve(4)-based virtual machine was set up and Jenkins was installed. The remainder is still in progress. Open tasks: 1. Finish setting up Jenkins. 2. Add more builds to Jenkins. 3. Integrate testing with Jenkins. __________________________________________________________________ GEOM Direct Dispatch and Fine-Grained CAM Locking URL: http://people.freebsd.org/~mav/disk.pdf URL: http://svnweb.freebsd.org/changeset/base/260387 URL: http://svnweb.freebsd.org/changeset/base/260385 Contact: Alexander Motin The CAM and GEOM multi-processor scalability improvement project has completed. The corresponding code has been committed to FreeBSD head and recently merged to the stable/10 branch; it shall appear in 10.1-RELEASE. As part of this project, cam(4) (the ATA/SCSI subsystem) has received more fine-grained locking for better utilization of multi-core systems. In addition, the locking in geom(4) (the block storage subsystem) has also been polished, and a new direct dispatch functionality was implemented to spread the load between multiple threads and processors, and reduce the number of context switches. Thanks to these cam(4) and geom(4) changes, the peak I/O rate has doubled on comptemporary hardware, reaching up to 1,000,000 IOPS! This project is sponsored by iXsystems, Inc. Open tasks: 1. Some CAM controller drivers (SIMs) could also be optimized to get more benefits from this project, utilizing the new locking models and direct command completions from multiple interrupt threads. __________________________________________________________________ Intel 802.11n NIC (iwn(4)) Work Contact: Adrian Chadd There has been a large amount of work on iwn(4) over the last six months: * New hardware support: 2xxx, 6xxx, 1xx series hardware. * Many bugs were fixed, including scanning, association, EAPOL related fixes. * iwn(4) now natively works with 802.11n rates from the net80211 rate control code, rather than mapping non-11n rates to 11n rates. Open tasks: 1. There are still some scan hangs, due to how net80211 scans a single channel at a time. This needs to be resolved. 2. The transmit, receive, scan and calibration code needs to be refactored out of if_iwn.c and into separate source files. 3. There still seem to be some issues surrounding 2 GHz versus 5 GHz association attempts leading to firmware assertions, especially on the Intel 4965 NIC. __________________________________________________________________ Intel GPU Driver Update Contact: Konstantin Belousov This project will update the Intel graphics chipset driver, i915kms, to a recent snapshot of the Linux upstream code. The update will provide at least 1.5 years of bugfixes from the Intel team, and introduce support for the newest hardware -- in particular Haswell and ValleyView. The IvyBridge code will also be updated. The addition of several features, which are required in order to update X.Org and Mesa, is also planned. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Native iSCSI Stack URL: https://wiki.freebsd.org/Native%20iSCSI%20target Contact: Edward Tomasz Napiera=C5=82a iSCSI is a popular block storage protocol. Under this project, a new, fast, and reliable kernel-based iSCSI initiator (client) and target (server) have been implemented. During October to December, the work focused on performance and scalability. The target and the initiator now spread the load over multiple kernel threads, and the locking is optimized to reduce contention. This makes better use of multiple processor cores. Work to finish iSER support is ongoing. All those optimizations will be gradually merged to head in February, and are expected to merged back to stable/10 and finally arrive in 10.1-RELEASE. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ New Automounter Contact: Edward Tomasz Napiera=C5=82a Research and prototyping has begun on a new project to implement autofs(4) -- an automounter filesystem -- and its userland counterpart, automountd(8). The idea is to provide a very similar user experience to the automounters available on Linux, MacOS X, and Solaris, including using the same map format. The automounter will also integrate with directory services, such as LDAP. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ UEFI Boot URL: https://wiki.freebsd.org/UEFI URL: http://svnweb.freebsd.org/base/projects/uefi/ Contact: Ed Maste The Unified Extensible Firmware Interface (UEFI) provides boot- and run-time services for x86 computers, and is a replacement for 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. In 2013, The FreeBSD Foundation sponsored Benno Rice for a short project to improve the UEFI bootloader. This resulted in a working proof-of-concept in the UEFI project branch, but it was not ready to be merged to FreeBSD head. Ed Maste has taken that original work and, with review feedback from Konstantin Belousov, been preparing it for integration into FreeBSD head. Some changes have been merged to head already. The rest will be merged as they are refined. Intel provided a motherboard and CPU for the project, which proved invaluable for addressing bugs that did not appear while testing with the QEMU emulator. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Resolve a 32- versus 64-bit libstand(3) build issue. 2. Merge kernel parsing of EFI memory map metadata. 3. Integrate the EFI framebuffer with vt(9) (also known as Newcons). 4. Connect efiloader to the build. 5. Document manual installation for dual-boot configurations. 6. Integrate UEFI configuration with the FreeBSD installer. 7. Support secure boot. __________________________________________________________________ UMA/ZFS and RPC/NFS Performance Improvements URL: http://docs.freebsd.org/cgi/mid.cgi?52894C92.60905 Contact: Alexander Motin The performance of ZFS and NFS was suboptimal in FreeBSD, so we have recently investigated some possible improvement paths. The uma(9) memory allocator caching code was improved to adapt better to system memory constraints. Combined with other virtual memory subsystem improvements done in the previous years, it should be safe to actively use uma(9) caches now. Their use in ZFS for ZIO/ARC may be enabled via the vfs.zfs.zio.use_uma loader(8) tunable, which is now the default for amd64, where it is recommended. Use of uma(9) caches for LZ4 compression buffers is unconditionally enabled on all architectures as it is has no serious drawbacks. On systems with many CPUs, these changes doubled the performance in the benchmarks. Several areas of the NFS server stack (RPC, FHA, DRC) got a number of fixes and performance optimizations that significantly improve performance and reduce the CPU usage in a number of tests. Together with the ZFS memory allocator changes mentioned above, it was possible to reach 200K NFS block read IOPS and 55K SPEC NFS IOPS. The code was committed to head. The uma(9) ZFS commits have been already merged to stable/10, and the remainder will be done soon as well. This project is sponsored by iXsystems, Inc. Open tasks: 1. The SPEC NFS test hits lock congestion on several global locks in the file system layer when a quite intensive READDIRPLUS NFS request is received. Fixing this problem could improve performance on large systems even further. __________________________________________________________________ Updated vt(9) System Console URL: https://wiki.freebsd.org/Newcons Contact: Aleksandr Rybalko Contact: Ed Maste Contact: Ed Schouten Colloquially known as Newcons, vt(9) is a modern replacement for the existing, quite old, virtual terminal emulator called syscons(4). Initially motivated by the lack of Unicode support in syscons(4), the project was later expanded to cover the new requirement to support Kernel Mode Switching (KMS). The project is now approaching completion and is ready for wider testing as the related code was already merged to FreeBSD head. Hence, vt(9) can be tested easily by replacing the following two lines in the kernel config file: device sc device vga with the following ones: device vt device vt_vga 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 -- Works, but without X.Org yet. * SPARC -- works on certain hardware (e.g., Ultra 5). * vesa(4) -- in progress. * i386/amd64 nVidia driver -- need testing. * Xbox framebuffer driver -- need testing. Known Issues: * Switching to vty0 from X.Org on Fatal events will not work. * Certain hardware (e.g., Lenovo X220) get a black screen when i915kms is preloaded. * Scrolling can be slow; * Screen borders are not cleared when changing fonts. * vt(9) locks up with the gallant12x22 font in VirtualBox. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Create sub-directories for vt(9) under /usr/share/ to store key maps and fonts. 2. Implement remaining features supported by vidcontrol(1). 3. Write the vt(9) manual page. 4. Support keyboard handled directly by device kbd (without kbdmux(4)). 5. CJK fonts (in progress). __________________________________________________________________ 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: Micha=C5=82 Dubiel Contact: Rafa=C5=82 Jaworowski OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources in a data center. OpenContrail is a network virtualization (SDN) solution comprising a network controller, a virtual router, and an 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 the following: * OpenStack compute driver (nova-compute) for the FreeBSD bhyve(4) hypervisor. * OpenContrail vRouter (forwarding-plane kernel module) port to FreeBSD. * Integration and performance optimizations. The current state of development features a working demo of OpenStack with compute node components running on a FreeBSD host: * The native bhyve(4) hypervisor is driven by a nova-compute component for spawning guest instances and a nova-network component for providing simple networking between those guests. * The nova-network approach (based on local host bridging) is becoming an obsolete technology in OpenStack and was used here only for demonstration and proof-of-concept purposes, without exploring all the possible features. * The main objective is to move to OpenContrail-based networking, therefore becoming compliant with the modern OpenStack networking API ("neutron"). This project is sponsored by Juniper Networks, Inc. Open tasks: 1. Decide how to integrate bhyve(4) with nova-compute, either natively or via the libvirt management layer. __________________________________________________________________ FreeBSD on Cubieboard{1,2} URL: https://github.com/tsgan/allwinner_a10/blob/master/if_emac.c Contact: Ganbold Tsagaankhuu Cubieboard is a single-board computer based on the AllWinner A10 SoC, popular on cheap tablets, phones and media PCs. The second version enhances the board mainly by replacing the AllWinner A10 SoC with an AllWinner A20 which contains 2 ARM Cortex-A7 MPCore CPUs and 2 Mali-400 GPUs (Mali-400MP2). In the last few months, work has continued on their FreeBSD port, and some work was done on the EMAC 10/100 Ethernet driver (see link). The driver is now in a good shape, however the RX side is very slow and there is need to have an external DMA driver that can be used in this case. __________________________________________________________________ FreeBSD on Freescale i.MX6 processors URL: http://lists.freebsd.org/pipermail/freebsd-arm/2013-November/006877= .html Contact: Ian Lepore The i.MX range is a family of Freescale Semiconductor proprietary microprocessors for multimedia applications based on the ARM architecture and focused on low-power consumption. The i.MX6x series is based on the ARM Cortex A9 solo, dual or quad cores. Initial support for them has been committed to head, and merged to stable/10. All members of the i.MX6 family (Solo, Dual, and Quad core) are supported, but SMP support on the multi-core SoCs has not yet been enabled. Initial driver support includes: * USB (EHCI) * Ethernet (Gigabit) * SD Card * UART The initial hardware bringup was done on Wandboard hardware, see the announcement on freebsd-arm in the links section for more information. Open tasks: 1. Write drivers for additional on-chip hardware, including I2C, SPI, AHCI, audio, and video. 2. Add support to FreeBSD-crochet script to generate Wandboard images __________________________________________________________________ FreeBSD on Freescale Vybrid VF6xx URL: http://svnweb.freebsd.org/changeset/base/258057 Contact: Ruslan Bukin Basic support for the Freescale Vybrid Family VF6xx heterogeneous ARM Cortex-A5/M4 System-on-Chip (SoC) was added to FreeBSD head. The Vybrid VF6xx family is an implementation of the new modern Cortex-A5-based low-power ARM SoC boards. Vybrid devices are ideal for applications including simple HMI in appliances and industrial machines, secure control of infrastructure and manufacturing equipment, energy conversion applications such as motor drives and power inverters, ruggedized wired and wireless connectivity, and control of mobile battery-operated systems such as robots and industrial vehicles. Supported device drivers: * NAND Flash Controller (NFC) * USB Enhanced Host Controller Interface (EHCI) * General-Purpose Input/Output (GPIO) * Universal Asynchronous Receiver/Transmitter (UART) Also supported: * Generic Interrupt Controller (GIC) * MPCore timer * ffec Ethernet driver Open tasks: 1. Add support for a number of different VF5xx- and VF6xx-based development boards. 2. Expand device driver support, including framebuffer and other devices. __________________________________________________________________ FreeBSD on Newer ARM Boards URL: https://wiki.freebsd.org/FreeBSD/arm/Radxa%20Rock URL: http://svnweb.freebsd.org/changeset/base/256949 URL: https://github.com/tsgan/qualcomm Contact: Ganbold Tsagaankhuu Rockchip is a series of SoC (System on Chip) integrated circuits that are mainly for embedded systems applications in mobile entertainment devices such as smartphones, tablets, e-books, set-top boxes, media players, personal video, and MP3 players. Due to their evolution from the MP3/MP4 player market, most Rockchip ICs feature advanced media decoding logic but lack integrated cellular radio basebands. Initial support for the Rockchip RK3188 (Quad core Cortex A9) SoC is committed to head. Now FreeBSD runs on Radxa Rock and it supports the following peripherals: * Existing DWC OTG driver in host mode * GPIO Some work was also done on initial support for the Qualcomm Snapdragon S4 SoC, featuring the Krait CPU, which is considered a "platform" for use in smartphones, tablets, and smartbook devices. Krait has many similarities with the ARM Cortex-A15 CPU and is also based on the ARMv7 instruction set. A minimal console driver was written, and FreeBSD's early boot messages can be now seen on the serial console. The timer driver works too, and the boot now stops at the mountroot prompt. __________________________________________________________________ FreeBSD/EC2 URL: http://www.daemonology.net/freebsd-on-ec2/ URL: http://www.daemonology.net/blog/2013-12-09-FreeBSD-EC2-configinit.h= tml Contact: Colin Percival An Amazon Machine Image (AMI) is a special type of virtual appliance that is used to create a virtual machine within the Amazon Elastic Compute Cloud ("EC2"). It serves as the basic unit of deployment for services delivered using EC2. Such AMIs are available for 8.3-RELEASE and later FreeBSD releases, and every ALPHA, BETA, and RC of FreeBSD 10.0. Starting from FreeBSD 10.0-BETA1, FreeBSD/EC2 images are running "fully supported" FreeBSD binaries, and starting from FreeBSD 10.0-RC1, FreeBSD/EC2 images include a "configinit" system for autoconfiguration using EC2 user-data. Due to limitations of old (m1, m2, c1, t1) instance types, "Windows"-labelled images are required for those instance types; however all of the recent instances types -- m3 (general purpose), c3 (high-CPU), and i2 (high-I/O) -- support FreeBSD at the "unix" pricing rates. The maintainer of this platform considers it to be ready for production use. Open tasks: 1. Hand over the task of building FreeBSD AMIs to the Release Engineering Team. 2. Get Amazon to add "FreeBSD" to the list of platforms supported by EC2, so that it can stop showing up as "Other Linux". __________________________________________________________________ FreeBSD/Xen URL: http://wiki.xen.org/wiki/FreeBSD_PVH Contact: Roger Pau Monn=C3=A9 Contact: Justin T. Gibbs Xen is a native (bare-metal) hypervisor providing services that allow multiple computer operating systems to execute on the same computer hardware concurrently. Xen 4.4 will bring a virtualization mode called PVH -- PV (paravirtualization) in an HVM (fully-virtual) container. This is essentially a paravirtualized guest using paravirtualized drivers for boot and I/O. Otherwise it uses hardware virtualization extensions, without the need for emulation. After merging the changes in order to improve Xen PVHVM support, work has shifted on getting PVH DomU support on FreeBSD. Patches have been posted, and after a couple of rounds of review the series looks almost ready for merging into head. Also, very initial patches for FreeBSD PVH Dom0 support has been posted. So far the posted series only focuses on getting FreeBSD booting as a Dom0 and being able to interact with the hardware. This project is sponsored by Citrix Systems R&D, and Spectra Logic Corporation. Open tasks: 1. Finish reviewing and commit the PVH DomU support. 2. Work on PVH Dom0 support. __________________________________________________________________ Intel IOMMU (VT-d, DMAR) Support URL: http://svnweb.freebsd.org/changeset/base/257251 URL: http://svnweb.freebsd.org/changeset/base/259512 Contact: Konstantin Belousov An Input/Output Memory Management Unit (IOMMU) is a Memory Management Unit (MMU) that connects a Direct Memory Access-capable (DMA-capable) I/O bus to main memory; therefore, I/O virtualization is performed by the chipset. An example IOMMU is the graphics address remapping table (GART) used by AGP and PCI Express graphics cards. Intel has published a specification for IOMMU technology as Virtualization Technology for Directed I/O, abbreviated VT-d. A VT-d driver was committed to head and stable/10, so busdma(9) is now able to utilize VT-d. The feature is disabled by default, but it may be enabled via the hw.dmar.enable loader(8) tunable -- see the links for more information. The immediate plans include increasing the support for this kind of hardware by testing and providing workarounds for specific issues, and by adding features of the next generation of Intel IOMMU. Hopefully, the existing and new consumers of VT-d will start to use the driver soon. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ auditdistd(8) Contact: Pawel Jakub Dawidek The auditdistd(8) daemon is responsible for distributing audit trail files over TCP/IP network securely and reliably. Currently, the daemon uses Transport Layer Security (TLS) for communication, but only server-side certificates are verified, based on the certificate's fingerprint. The ongoing work will make it possible to use client-side certificates and will support more complete public-key infastructure, which includes validation of the entire certificate chain, including revocation checking against Certification Revocation Lists at every level. From now on, auditdistd(8) will support TLSv1.2 and PFS modes only. In addition, it will be possible to send audit trail files to multiple receivers. The work will be completed at the beginning of February 2014. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Base GCC Updates Contact: Pedro Giffuni The GCC compiler in the FreeBSD base system is on its way to deprecation and is only used by some Tier-2 platforms at this time. While Clang is much better in many aspects, we still cannot use in the base system all the new features that it brings until we can drop GCC completely. As a stop-gap solution, several bug fixes and features from Apple GCC and other sources have been ported to our version of GCC 4.2.1 to make it more compatible with Clang. FreeBSD's GCC has added more warnings and some enhancements like -Wmost and -Wnewline-eof. An implementation for Apple's blocks extension is now available, too, and it will be very useful to enhance FreeBSD's support for Apple's Grand Central Dispatch (GCD). Open tasks: 1. A merge from head to stable/9 is being considered but it disables nested functions by default, so the impact on the Ports Collection needs to be evaluated. 2. No further development of GCC 4.2 in the base system is planned. __________________________________________________________________ BSDInstall ZFSBoot URL: http://lists.freebsd.org/mailman/listinfo/freebsd-sysinstall URL: https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/9.0-RELEASE Contact: Allan Jude Contact: Devin Teske Contact: Warren Block BSDInstall has been the default installation program since FreeBSD 9.0-RELEASE. However, it could not utilize one of the best features of FreeBSD, ZFS. The ZFSBoot project started at EuroBSDCon 2013 and reached stable status in December, just in time for FreeBSD 10.0-RELEASE. Currently, ZFSBoot implements root-on-ZFS with 4k partition alignment, optional forced 4k sectors, optional geli(8) full disk encryption, and support for boot environments. As part of ZFSBoot, BSDInstall itself also received a number of updates, including enhanced debugging, more scriptability, a new keymap selection menu, and a number of other small changes to streamline the installation process. The new keymap menu allows the user to test the selected keymap before continuing, to ensure it is the desired keymap. Minor changes were made to the network configuration dialogues to make the identification of wireless interfaces easier. A number of additional features are also planned. The user should be able to create additional datasets and adjust the properties on all datasets in an interactive menu. There should also be integration with BSDConfig to allow users to install packages and the various other functionality that was previously provided by sysinstall. Open tasks: 1. Interactive dataset editor. 2. Dataset property editor. 3. Consider using shell geom(4) parser. 4. BSDConfig integration. 5. UFS as a file system option, to allow users to create encrypted UFS installs. 6. Optionally make the boot pool UFS or reside on USB device(s). 7. Further streamline the installation process. __________________________________________________________________ Capsicum and Casper URL: http://freebsdfoundation.blogspot.com/2013/12/freebsd-foundation-an= nounces-capsicum.html Contact: Pawel Jakub Dawidek Capsicum is a lightweight OS capability and sandbox framework implementing a hybrid capability system model. The Casper daemon enables sandboxed application to use functionality normally unavailable in capability-mode sandboxes. The Casper daemon, libcasper, libcapsicum(3), libnv(3) and Casper services (system.dns, system.grp, system.pwd, system.random and system.sysctl) have been committed to FreeBSD head. The tcpdump(8) utility in head now uses the system.dns service to do DNS lookups. The kdump(1) utility in head now uses the system.pwd and system.grp services to convert user and group identifiers to user and group names. There is ongoing work to sandbox more applications. If you are interested in helping to make FreeBSD more secure and would like to learn about Capsicum and Casper, do not hesitate to contact Pawel -- he can provide candidate programs that could use sandboxing. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Centralized Panic Reporting URL: http://www.daemonology.net/blog/2013-11-06-automated-freebsd-panic-= reporting.html Contact: Colin Percival With the sysutils/panicmail port, a mechanism is now in place for automated submission of kernel panic reports to a central location. It is hoped that this will prove useful, as similar systems have for other operating systems, in identifying common panics so that developers can be alerted and they can be fixed faster. In the first two months that this mechanism has been in place, 28 kernel panics have been reported. This is nowhere near enough to be useful, so readers are strongly encouraged to install the sysutils/panicmail port and follow the instructions to enable it. Open tasks: 1. Get more systems set up to automatically submit panic reports! __________________________________________________________________ FreeBSD Test Suite URL: http://wiki.FreeBSD.org/TestSuite URL: http://kyua1.nyi.FreeBSD.org/ URL: http://lists.freebsd.org/pipermail/freebsd-testing/2013-December/00= 0109.html URL: http://julipedia.meroh.net/2013/12/introducing-freebsd-test-suite.h= tml Contact: Julio Merino The FreeBSD Test Suite project aims to equip FreeBSD with a comprehensive test suite that is easy to run out of the box and during the development of the system. The test suite is installed into /usr/tests/ and the kyua(1) command-line tool (devel/kyua in the Ports Collection) is used to run them. The benefits of having a test suite that is easy to use and continuously run are obvious: regressions can be caught sooner rather than later and the Release Engineering Team can better assess the quality of the tree before deciding to cut a release. Additionally, because we choose to install the tests, we allow any end user to perform sanity checks on new installations of the system on their particular hardware configuration -- a very attractive thing to do when deploying production servers. During the last few months, we have added the necessary pieces to the build system to support building and installing test programs of various kinds. To demonstrate the functionality of these, some test programs were added and others were migrated from the old testing tree in tools/regression/ to the new layout for tests. The current test suite should be seen as a proof of concept at this point: it is only composed of a small set of test programs and the goal is to get the infrastructure in place before mass-migrating existing test code and/or importing external tests. As part of this work, two new releases of Kyua were published. Of special interest is the addition of a TAP-compliant backend so that existing tests from tools/regression/ can be plugged into the test suite with minimum effort. As of December 31st, the basic continuous testing infrastructure is up and running, see the links section for the home page. For further information, please see the related announcement and blog post on the subject (also in the links section). Open tasks: 1. We have three machines for the test cluster. At the moment, only one of them is in use to continuously test amd64 on both head and stable/10. We need to figure out the right level of parallelization to put other machines to use -- but a first easy cut may be to just test different architectures (with the help of QEMU). 2. Related to the above, the Kyua reporting engine needs significant tuning to make the reports nice and clean. Ideally, Kyua should be able to coalesce results from different runs into a single location and generate cohesive reports out of them. Fixing this is a high priority. 3. A tutorial on writing tests for FreeBSD has been proposed for AsiaBSDCon 2014. The outcome of the proposal is still unknown, but stay tuned! 4. Port, port, and port more tests to the new test suite. A test suite is worthless if it does not validate stuff. Stay tuned for a request for help once we have put all basic pieces in place and have streamlined the migration process. __________________________________________________________________ The LLDB Debugger URL: https://wiki.freebsd.org/lldb Contact: Ed Maste LLDB is the debugger in the LLVM family of projects. It supports Mac OS X, Linux, and FreeBSD, with ongoing work to support Windows. In the last quarter of 2013, LLDB gained support for live (ptrace(2)-based) debugging of multithreaded processes on FreeBSD. Initial FreeBSD MIPS target support has also been committed, along with a number of endianness fixes in the general LLDB infrastructure. The LLDB snapshot in the FreeBSD tree was updated to r196322. Currently disabled by default, it will be enabled for amd64 after the import of Clang 3.4. In the interim, it may be enabled by adding WITH_LLDB=3D to src.conf(5). This project is sponsored by DARPA/AFRL, SRI International, and University of Cambridge. Open tasks: 1. Update the in-tree snapshot to build after the Clang 3.4 import. 2. Fix amd64 watchpoints. 3. Test and fix the i386 port. 4. Implement FreeBSD ARM support. 5. Add support for kernel debugging (live local and remote debugging, and core files). 6. Fix the remaining test suite failures. 7. Enable by default on the amd64 architecture. __________________________________________________________________ FreeBSD Python Ports URL: https://wiki.FreeBSD.org/Python URL: irc://freebsd-python@irc.freenode.net Contact: FreeBSD Python Team Python is a widely used general-purpose, high-level programming language. For many operating systems, Python is a standard component; it ships with FreeBSD as well. A lot of progress has been made around the FreeBSD Python ports in the last quarter. The devel/py-distribute port has been replaced by the refreshed devel/py-setuptools port, which comes with a lot of features that simplify the ways of installing Python packages. The change also led us to install everything through Setuptools now, which resembles a PyIP a bit and allows us to perform some major cleanup on the distutils installation behaviour. The implicit lang/python build and run-time dependency was removed from the ports infrastructure. Every port now depends on a specific Python version or on the lang/python metaport. This prevents compatibility issues for ports that depend on Python 2.x OR Python 3.x exclusively, but use the python command, which might point to a version of incompatible user choice. The lang/python27 port was updated to version 2.7.6, and the lang/python33 port was updated to version 3.3.3, and the lang/pypy port was updated to version 2.2.1. We are currently working on the necessary infrastructure quirks to support different Python versions for the same port. Most of the work has been done and needs to be tested before it can be integrated. Open tasks: 1. Develop a high-level and lightweight Python Ports Policy. 2. Add support for granular dependencies (for example >=3D1.0 or <2.0). 3. Look at what adding pip support looks like. 4. Convert all USE_PYDISTUTILS=3Deasy_install entries to yes and remove the use of easy_install from the ports infrastructure. 5. More tasks can be found on the team's wiki page (see links). __________________________________________________________________ GNOME/FreeBSD URL: http://www.FreeBSD.org/gnome/ URL: http://svnweb.freebsd.org/changeset/ports/334661 Contact: FreeBSD GNOME Team GNOME is a desktop environment and graphical user interface that runs on top of a computer operating system. GNOME is part of the GNU Project and can be used with various Unix-like operating systems, including FreeBSD. In this quarter, MATE 1.6 was finally imported into the Ports Collection, thanks to the efforts of Jeremy Messenger. MATE is a desktop environment forked from the now-unmaintained code base of GNOME 2, therefore it is basically a replacement for GNOME 2. It recommended for users wanting to keep GNOME 2 as their desktop to switch since GNOME 2 will be replaced by GNOME 3 in the near future. This switch will be announced in advance, so people will have time to move to MATE if they have not already. The complete MATE-based desktop environment can be installed via the x11/mate port, or, for a minimal install, x11/mate-base. Our home page is quite out of date. An update for it for GNOME 3.6 is underway. Part of this update is rewriting and updating the old GNOME porting guide as a chapter of the Porter's Handbook. Another major task required for getting a bleeding-edge GNOME to build on FreeBSD mostly out-of-the box is moving to JHbuild with some custom rules. This is done to find and fix compile issues on other BSDs more quickly. Open tasks: 1. GNOME 2 ports still need to be sorted out to evaluate which GNOME 2 components will be gone or be replaced with their newer GNOME 3 versions. This task is current halted until we can get the documentation into a shape good enough to gather the issues and document the migration, including how to avoid the migration if the upgrade is not preferred. (This does not mean we do not want to know about issues with upgrading, though). 2. Help the X11 Team with Cairo 1.12, since the next version of GNOME 3 (3.12) will need an up-to-date version of Pango and GTK 3. __________________________________________________________________ KDE/FreeBSD URL: http://FreeBSD.kde.org URL: http://FreeBSD.kde.org/area51.php URL: http://portscout.freebsd.org/kde@freebsd.org.html Contact: KDE FreeBSD Team KDE is an international free software community producing an integrated set of cross-platform applications designed to run on Linux, FreeBSD, Solaris, Microsoft Windows, and OS X systems. The KDE/FreeBSD Team have continued to improve the experience of KDE software and Qt under FreeBSD. During last quarter, the team has kept most of the KDE and Qt ports up-to-date, working on the following releases: * KDE SC (area51): 4.11.2, 4.11.3, 4.11.4 * Qt: 4.8.5 and 5.2 (area51) * PyQt: 4.10.3; SIP: 4.15.2; QScintilla2: 2.8 * Qt Creator 2.8.0 * KDevelop: 4.5.2 * Calligra: 2.7.5 * CMake: 2.8.12, 2.8.12.1 As a result, according to PortScout, our team has 464 ports (down from 473), of which 88.15% are up-to-date (down from 98.73%). 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 or visit our home page (see links). 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. Update out-of-date ports, see links for a list. 2. Worke on KDE 4.12 and Qt 5. 3. Make sure the whole KDE stack (including Qt) builds and works correctly with Clang and libc++. 4. Remove the dependency on HAL. __________________________________________________________________ Wine/FreeBSD URL: http://wiki.FreeBSD.org/Wine URL: http://wiki.FreeBSD.org/i386-Wine URL: http://www.winehq.org/ Contact: Gerald Pfeiffer Contact: David Naylor Wine is a free and open source software application that aims to allow applications designed for Microsoft Windows to run on Unix-like operating systems, such as FreeBSD. The Wine/FreeBSD Team have continued to improve the experience of Wine under FreeBSD. During the fourth quarter of 2013, the team has kept Wine updated by porting: * Stable releases: 1.6 and 1.6.1 * Development releases: 1.7.4 through 1.7.8 The ports have included packages built for amd64 (available through the Ports Collection). The Wine ports have been kept up-to-date with the changes in the Ports Collection, including some improvements: * Building with Clang by default (via USES=3Dcompiler:c11). * Conditional X11 support (on by default; allowing for headless instances of Wine). * Staging support and other ports best practices. Support in improving the experience of Wine on FreeBSD is needed. Key areas including fixing regressions, adding copy protection scheme support and fixing regressions when using Wine under FreeBSD/amd64. Open tasks: 1. Open Tasks and Known Problems (see links for the wiki page). 2. FreeBSD/amd64 integration (see links for the i386-Wine wiki page). 3. Porting WoW64 and Wine64. __________________________________________________________________ X.Org on FreeBSD URL: https://wiki.freebsd.org/Graphics URL: http://trillian.chruetertee.ch/ports/browser/trunk URL: http://lists.freebsd.org/pipermail/freebsd-x11/2014-January/014003.= html Contact: FreeBSD X11 Team The newer graphics stack (WITH_NEW_XORG) is now built by default on head and is provided as binary packages from the official FreeBSD pkg(8) repository for 11-CURRENT. The major updates are: * X.Org server 1.12. * Mesa 9.1. * Recent Intel and Radeon X.Org drivers, using exclusively the KMS kernel drivers available in FreeBSD 9.x (Intel) and FreeBSD 10.x (Radeon). This change makes X.Org on FreeBSD head work out-of-the-box on workstations and laptops based on recent Intel and Radeon GPUs. FreeBSD 10.x will follow in a few weeks or months. Some software has started to require Cairo 1.12, for example GTK+ 3.10 and Pango. Unfortunately, this version of Cairo triggers a bug in the old Intel driver (2.7.1, installed when WITH_NEW_XORG is not set), which causes display artifacts. A "Call For Testers" mail was posted on the freebsd-x11 mailing-list (see the links above) to gather information about the behavior on other configurations (new Intel driver and non-Intel drivers). As of this writing, the reports received talk about improvements or, at least, no change noticed. To better manage changes such as the WITH_NEW_XORG and Cairo 1.12 changes mentioned above, we asked on the freebsd-x11 mailing-list if people are using FreeBSD 8.x on their desktop computers and why they do not upgrade to FreeBSD 9.x or 10.x. So far, we received very few answers to this. The Radeon KMS driver in FreeBSD 10.x is now considered stable, especially that integrated GPUs are now properly initialized. One of the next steps will be to merge this to stable/9. A "Graphics" wiki article (see links) was created to centralize and coordinate the work being done on both the ports and the kernel. It contains the following important information: * A roadmap of the team. * A matrix of supported hardware. * Instructions on upgrading to KMS. * Project status and results. This starting page then points to project- and topic-specific articles where more detailed information is available. Open tasks: 1. Report why FreeBSD 8.x is still used on your desktop and why moving to FreeBSD 9.x or 10.x is not an option. 2. Report about the Cairo 1.12 update on your system. 3. See the "Graphics" wiki page for up-to-date information. __________________________________________________________________ Xfce/FreeBSD URL: https://wiki.freebsd.org/Xfce URL: https://people.freebsd.org/~olivierd/xfce-core-unstable.html URL: https://people.freebsd.org/~olivierd/parole-unstable.html Contact: FreeBSD Xfce Team Xfce is a free software desktop environment for Unix and Unix-like platforms, such as FreeBSD. It aims to be fast and lightweight, while still being visually appealing and easy to use. The FreeBSD Xfce Team has kept most of the Xfce ports up-to-date, while fixing many issues along the way in this quarter. Currently, the following components with the following versions are available: Applications: * Orage (4.10.0) * Midori (0.5.6) * xfce4-terminal (0.6.3) * xfce4-parole (0.5.3, 0.5.4) Panel plugins: * xfce4-whiskermenu-plugin (1.2.0, 1.2.1, 1.2.2, 1.3.0) * xfce4-mailwatch-plugin (1.2.0) * xfce4-wmdock-plugin (0.6.0) We helped Midori's upstream switch from Waf (Python script) to CMake. Xfce now also supports Gtk2, Gtk3, and the new WebKitGtk API, available from the 2.x branch, not present in our ports tree at the moment, though. Most of the ports now use stage directories, with only some plugins left to convert. We also removed obsolete ports: * x11-themes/lila-xfwm4 (Xfwm4 theme) * multimedia/xfce4-media (multimedia player) * net-im/xfce4-messenger-plugin Besides, we followed the development of the Xfce core components and Parole closely. See the links for documentation on how to upgrade those libraries. Open tasks: 1. Fix Midori's build on DragonFly, through DPorts. 2. Fix build of the Granite framework (it is an extension to Gtk and Midori uses it) on FreeBSD 10 and head. Those are mostly LLVM failures. 3. Add support for Berkeley DB 5 and higher to Orage. __________________________________________________________________ The FreeBSD Foundation URL: http://www.FreeBSDFoundation.org/ URL: http://www.freebsdfoundation.org/press/2013Dec-newsletter 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 held our year-end fundraising campaign. We are still processing donations and will post the final numbers by mid-January. We are extremely grateful to all the individuals and organizations that supported us and the Project by making a donation in 2013. We have already started our fundraising efforts for 2014. Some of the highlights from this past quarter include: * We sponsored or are sponsoring the following projects: + Projects completed last quarter: Capsicum, Casper daemon, and Intel I/O Memory Management Unit driver. + Projects in progress: Native in-kernel iSCSI stack, network stack layer 2 modernization, UEFI boot, updated vt(9) system console. + Projects started last quarter: Automounter, Intel graphics driver update. * Continued work on the FreeBSD Journal, our new online FreeBSD magazine, which debuts on January 27th (see links). * Sponsored, organized, and ran the Bay Area Developer Summit. * Sponsored and attended the first ever vBSDCon, which had an impressive attendance. * Sponsored and attended the OpenZFS developer summit. * Represented the foundation at the following conferences: All Things Open in Raleigh, NC and LISA in Washington, DC. * Sponsored the FreeBSD 20th Birthday Party, held in San Francisco. * Attended the ICANN meeting in Buenos Aires in November and gave a short presentation on the change from BIND to unbound in FreeBSD 10.0 during the ccNSO Tech Day. * Met with a few companies to discuss their FreeBSD use, what they would like to see supported in FreeBSD, and assist with collaboration between them and the Project. * Purchased an 80-core server to reside at Sentex for the Project to use for stability, scalability, and performance improvements. It is a big step forwards for the Foundation in providing this kind of hardware to the Project's developers. It will let us test our scaling to 80 simultaneous cores and 1 TB of RAM. It will also be used to do performance analysis on large workloads, such as large databases etc. * Acquired a second rack to use at Sentex. * We received a commitment from VMware, Inc. for BSD-licensed drivers. They also committed to a yearly silver level donation. * Signed up as a Google Compute trusted tester for the Project. * Funded a project to produce a white paper titled "Managed Services Using FreeBSD at NYI". * Finally, we published our semi-annual newsletter (see links) highlighting what we did to support the FreeBSD Project and Community in 2013. __________________________________________________________________ Love FreeBSD? Support the development with a donation to the FreeBSD Foundation! https://www.freebsdfoundation.org/donate/ From owner-freebsd-current@FreeBSD.ORG Sat Jan 25 21:19:00 2014 Return-Path: Delivered-To: freebsd-current@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 DFB5917B for ; Sat, 25 Jan 2014 21:19:00 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A0067177E for ; Sat, 25 Jan 2014 21:19:00 +0000 (UTC) Received: from 2a02-8428-011a-a000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11a:a000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1W7Acy-0000nr-Sc for freebsd-current@freebsd.org; Sat, 25 Jan 2014 22:18:58 +0100 Message-ID: <52E42A3A.7000901@FreeBSD.org> Date: Sat, 25 Jan 2014 22:18:50 +0100 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Newcons radeonkms - Failed to load firmware "radeonkmsfw_TURKS_PFP" References: <1367fd4d-9128-4df0-a250-fb3c1f67f0c5@email.android.com> In-Reply-To: <1367fd4d-9128-4df0-a250-fb3c1f67f0c5@email.android.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mk91iKqE4tx1TerfwgRfvI4KV816FewJa" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 21:19:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mk91iKqE4tx1TerfwgRfvI4KV816FewJa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 25.01.2014 18:43, Mike C. wrote: > After rebuilding the kernel with newcons support (which is working) > I've placed radeonkms_load=3D"YES" in boot loader and rebooted and get > this screen. >=20 > what am I doing wrong? Hello! If you want to load radeonkms at boot time (from /boot/loader.conf), you need to load the required firmwares too, otherwise they can't be loaded automatically during boot (/ isn't mounted yet). To find the list of firmwares you need to load, you can read instructions on the wiki: https://wiki.freebsd.org/Graphics#Video_driver_loaded_at_boot_time --=20 Jean-S=E9bastien P=E9dron --mk91iKqE4tx1TerfwgRfvI4KV816FewJa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJS5CpAXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMzZEQAIZO6fkfGLEYlQ8rVBqp31hf JQlTiEA05kaTzVjUfvWbLwOVYS3V1WB6fCwdQ2DZKziM3yIqW7Orsgj2dFeG8Isl X5xVxwed4qI374B90VlqUqtOQbsX8XiMDi8C7idQ9Dr0326hDZ+cGVd7ZXzt5blC TUMW4GPBLFWzUo91OF8aZU/gmUVp2vb8Ngcp0Hlo3c6aDaaK1pIgrDPKaZ6tdCiH 3u+NNTdhfdMMP0r/Zvg7/T/Nc7dosAIkfQHF32LcRBqjCbEOdtzRhIfEA5bhMGRi BPvYrcLlOwFCmOZXAqmd++J6QOP7UOOtuckmG5pkMmehtw5fYBi7HnX73B0FCB5+ 13fwAd6hsOXvRo4GPjxCjafc5ii/lvzJrEJiwV+382ETz8NueKugjx+765Urn2nP q0DHr5uAL4O9K6MDC8R/RWeBzosPYJj0ZwpJV1Zg8fBhJ/osLjFYJ40/eHd2bPJ5 4sR5JqRbbFB0Oad2oxlDh6iDKuSHtVA9h6qbEwRUeRB6ncaGZcE91qci0xPZlFhl P+6sEBUy33uQCpKIYiFagMGHVWmqQYuwZa3NVW7ElEtqa1/pjbs2Yeo8nukWE3Hl 51TFhGm2B0FPNvooDiNEH8aDLyZLTTwbow9njZqetEdjZQ/hHKCHallZzDyRT8H7 R+zEW59PLAmufbQMBZyn =Mauv -----END PGP SIGNATURE----- --mk91iKqE4tx1TerfwgRfvI4KV816FewJa-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 25 21:30:16 2014 Return-Path: Delivered-To: freebsd-current@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 D47CD830; Sat, 25 Jan 2014 21:30:16 +0000 (UTC) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 90F731860; Sat, 25 Jan 2014 21:30:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=V42EvLgsMe4aOdUy0tlK9Z2M2bcPVis+0zzxtk8HXYw=; b=Y6jt7+hMhbufRbTRd+Tfl8XN5hk4cK/T9mdDJTv7pHaIIbxNC8zdqynsPDcWKa6nuaayunQ/cTW4N4kKF/2cx9RNlm8pbtMjrZb6Sx4mj42Rp0FLscnjkYGfNLwED9LVyGxN4NehhAFQFWsL368D3kYmDIXLJbaa9k0rfbLyhmc=; Received: from 107-128-180-255.lightspeed.austtx.sbcglobal.net ([107.128.180.255]:21935 helo=borg.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1W7Anm-0009fI-FE; Sat, 25 Jan 2014 15:30:12 -0600 Date: Sat, 25 Jan 2014 15:29:55 -0600 From: Larry Rosenman To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org, freebsd-zfs@freebsd.org Subject: Panic / Solaris Assert / ZAP.c:479 Message-ID: <20140125212954.GA1645@borg.lerctr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Score: 2.6 (++) X-LERCTR-Spam-Score: 2.6 (++) X-Spam-Report: SpamScore (2.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, KAM_STOCKTIP=5.5, TVD_RCVD_IP=0.001 X-LERCTR-Spam-Report: SpamScore (2.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, KAM_STOCKTIP=5.5, TVD_RCVD_IP=0.001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 21:30:16 -0000 Ok, I just did a full rebuild at -CURRENT -HEAD and still get this (basic) panic. How can I get some help to fix it? This version stays up: FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #113 r260864: Fri Jan 17 19:10:06 CST 2014 root@:/usr/obj/usr/src/sys/BORG-DTRACE amd64 Below is the latest panic. borg.lerctr.org dumped core - see /var/crash/vmcore.2 Sat Jan 25 15:25:30 CST 2014 FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r261166: Sat Jan 25 14:55:24 CST 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 panic: solaris assert: l->l_phys->l_hdr.lh_pad1 == 0 (0xffff000000000000 == 0x0), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c, line: 479 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: Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #3 r261166: Sat Jan 25 14:55:24 CST 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 info: [drm] Initialized drm 1.1.0 20060810 CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (2327.55-MHz K8-class CPU) Origin="GenuineIntel" Id=0x10676 Family=0x6 Model=0x17 Stepping=6 Features=0xbfebfbff Features2=0xce3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 68719476736 (65536 MB) avail memory = 65641644032 (62600 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard random: initialized kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) unknown: I/O range not supported cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 350 Event timer "HPET1" frequency 14318180 Hz quality 340 Event timer "HPET2" frequency 14318180 Hz quality 340 atrtc0: port 0x70-0x71 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 pcib5: at device 0.2 on pci3 pci5: on pcib5 pcib6: irq 18 at device 2.0 on pci2 pci6: on pcib6 em0: port 0x2000-0x201f mem 0xd9220000-0xd923ffff,0xd9200000-0xd921ffff irq 18 at device 0.0 on pci6 em0: Using an MSI interrupt em0: Ethernet address: 00:30:48:f2:29:9c em1: port 0x2020-0x203f mem 0xd9260000-0xd927ffff,0xd9240000-0xd925ffff irq 19 at device 0.1 on pci6 em1: Using an MSI interrupt em1: Ethernet address: 00:30:48:f2:29:9d pcib7: at device 0.3 on pci1 pci7: on pcib7 pcib8: at device 4.0 on pci0 pci8: on pcib8 vgapci0: port 0x3000-0x307f mem 0xd8000000-0xd8ffffff,0xc0000000-0xc7ffffff,0xc8000000-0xc9ffffff irq 16 at device 0.0 on pci8 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io hdac0: mem 0xd9000000-0xd9003fff irq 17 at device 0.1 on pci8 pcib9: at device 6.0 on pci0 pci9: on pcib9 pci0: at device 8.0 (no driver attached) pcib10: irq 17 at device 28.0 on pci0 pci10: on pcib10 pcib11: irq 16 at device 0.0 on pci10 pci11: on pcib11 pcm0: port 0x4080-0x409f,0x4000-0x407f irq 16 at device 0.0 on pci11 pcm0: system configuration SubVendorID: 0x1412, SubDeviceID: 0x2403 XIN2 Clock Source: 24.576MHz(96kHz*256) MPU-401 UART(s) #: not implemented ADC #: 1 and SPDIF receiver connected DAC #: 4 Multi-track converter type: AC'97(SDATA_OUT:packed) S/PDIF(IN/OUT): 1/1 ID# 0x00 GPIO(mask/dir/state): 0xff/0xff/0xff uhci0: port 0x1800-0x181f irq 17 at device 29.0 on pci0 usbus0 on uhci0 uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 usbus1 on uhci1 uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 usbus2 on uhci2 ehci0: mem 0xd9600400-0xd96007ff irq 17 at device 29.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib12: at device 30.0 on pci0 pci12: on pcib12 vgapci1: port 0x5000-0x50ff mem 0xd0000000-0xd7ffffff,0xd9300000-0xd930ffff irq 18 at device 1.0 on pci12 drmn1: on vgapci1 info: [drm] RADEON_IS_PCI info: [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080). info: [drm] register mmio base: 0xD9300000 info: [drm] register mmio size: 65536 info: [drm] radeon_atrm_get_bios: ===> Try ATRM... info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:8:0:0, vendor=10de, device=104a info: [drm] radeon_atrm_get_bios: Get ACPI device handle info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0xd0000000 info: [drm] igp_read_bios_from_vram: Map address: 0xfffff800d0000000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x0000 info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] radeon_read_bios: Map address: 0xfffff800000c0000 (131072 bytes) drmn1: info: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used) drmn1: info: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] radeon: irq initialized. info: [drm] Detected VRAM RAM=128M, BAR=128M info: [drm] RAM width 64bits SDR [TTM] Zone kernel: Available graphics memory: 33006090 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator info: [drm] radeon: 16M of VRAM memory ready info: [drm] radeon: 512M of GTT memory ready. info: [drm] GART: num cpu pages 131072, num gpu pages 131072 info: [drm] PCI GART of 512M enabled (table at 0x0000000011200000). drmn1: info: WB disabled drmn1: info: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0x0xfffff8001083c000 info: [drm] Loading R100 Microcode info: [drm] radeon: ring at 0x00000000B0001000 info: [drm] ring test succeeded in 1 usecs info: [drm] ib test succeeded in 0 usecs info: [drm] radeon_device_init: Taking over the fictitious range 0xd0000000-0xd4000000 iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iicbus1: on iicbb1 addr 0xff iic1: on iicbus1 iicbus2: on iicbb2 addr 0xff iic2: on iicbus2 iicbus3: on iicbb3 addr 0xff iic3: on iicbus3 info: [drm] Radeon Display Connectors info: [drm] Connector 0: info: [drm] VGA-1 info: [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60 info: [drm] Encoders: info: [drm] CRT1: INTERNAL_DAC1 info: [drm] Connector 1: info: [drm] DVI-I-1 info: [drm] HPD2 info: [drm] DDC: 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c info: [drm] Encoders: info: [drm] CRT2: INTERNAL_DAC2 info: [drm] DFP2: INTERNAL_DVO1 composite sync not supported composite sync not supported info: [drm] fb mappable at 0xD0040000 info: [drm] vram apper at 0xD0000000 info: [drm] size 2076672 info: [drm] fb depth is 8 info: [drm] pitch is 1920 fbd1 on drmn1 vt_allocate: Replace existing VT driver. info: [drm] Initialized radeon 2.29.0 20080528 vgapci1: Boot video device isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: at channel 0 on atapci0 ahci0: port 0x18a0-0x18a7,0x1874-0x1877,0x1878-0x187f,0x1870-0x1873,0x1880-0x189f mem 0xd9600800-0xd9600bff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ichsmb0: port 0x1100-0x111f irq 19 at device 31.3 on pci0 smbus0: on ichsmb0 acpi_button0: on acpi0 ipmi0: port 0xca2-0xca3 on acpi0 ipmi0: KCS mode found at io 0xca2 on acpi atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ichwd0 on isa0 orm0: at iomem 0xc0000-0xcafff on isa0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 coretemp4: on cpu4 est4: on cpu4 p4tcc4: on cpu4 coretemp5: on cpu5 est5: on cpu5 p4tcc5: on cpu5 coretemp6: on cpu6 est6: on cpu6 p4tcc6: on cpu6 coretemp7: on cpu7 est7: on cpu7 p4tcc7: on cpu7 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x387 offMax=0x50f hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm1: at nid 4 on hdaa0 pcm2: at nid 5 on hdaa0 random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen3.1: at usbus3 uhub0: on usbus3 ugen2.1: at usbus2 uhub1: on usbus2 ugen1.1: at usbus1 uhub2: on usbus1 ugen0.1: at usbus0 uhub3: on usbus0 ipmi0: IPMI device rev. 1, firmware rev. 1.64, version 2.0 ata0: DMA limited to UDMA33, controller found non-ATA66 cable ipmi0: Number of channels 8 ipmi0: Attached watchdog uhub2: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: Serial Number 5YDA1ZL4 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus2 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: Serial Number 5YD6FPLG ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada1: quirks=0x1<4K> ada1: Previously was known as ad6 ada2 at ahcich2 bus 0 scbus3 target 0 lun 0 ada2: ATA-8 SATA 3.x device ada2: Serial Number 5YDA3PC5 ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada2: quirks=0x1<4K> ada2: Previously was known as ad8 ada3 at ahcich3 bus 0 scbus4 target 0 lun 0 ada3: ATA-8 SATA 3.x device ada3: Serial Number 5YD9Y0P4 ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3: quirks=0x1<4K> ada3: Previously was known as ad10 ada4 at ahcich4 bus 0 scbus5 target 0 lun 0 ada4: ATA-8 SATA 3.x device ada4: Serial Number 5YDA1R5W ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada4: quirks=0x1<4K> ada4: Previously was known as ad12 ada5 at ahcich5 bus 0 scbus6 target 0 lun 0 ada5: ATA-8 SATA 3.x device ada5: Serial Number 5YD5RBS8 ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada5: quirks=0x1<4K> ada5: Previously was known as ad14 cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present Netvsc initializing... done! SMP: AP CPU #7 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #5 Launched! Root mount waiting for: usbus3 uhub0: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 Root mount waiting for: usbus3 ugen3.2: at usbus3 ukbd0: on usbus3 kbd2 at ukbd0 Trying to mount root from zfs:zroot/ROOT/default []... ugen0.2: at usbus0 ugen1.2: at usbus1 <118>Setting hostuuid: 53d19f64-d663-a017-8922-0030488e9ff3. <118>Setting hostid: 0xf53a926e. <118>Entropy harvesting: interrupts ethernet point_to_point swi. <118>Starting file system checks: <118>Mounting local file systems:. panic: solaris assert: l->l_phys->l_hdr.lh_pad1 == 0 (0xffff000000000000 == 0x0), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c, line: 479 cpuid = 7 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe100c55d350 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe100c55d400 vpanic() at vpanic+0x126/frame 0xfffffe100c55d440 panic() at panic+0x43/frame 0xfffffe100c55d4a0 assfail3() at assfail3+0x2f/frame 0xfffffe100c55d4c0 zap_get_leaf_byblk() at zap_get_leaf_byblk+0x2ea/frame 0xfffffe100c55d510 zap_deref_leaf() at zap_deref_leaf+0xd1/frame 0xfffffe100c55d560 fzap_length() at fzap_length+0x31/frame 0xfffffe100c55d5d0 zap_length_uint64() at zap_length_uint64+0xbf/frame 0xfffffe100c55d630 ddt_zap_lookup() at ddt_zap_lookup+0x3d/frame 0xfffffe100c55d790 ddt_lookup() at ddt_lookup+0x17e/frame 0xfffffe100c55d960 zio_ddt_write() at zio_ddt_write+0xf2/frame 0xfffffe100c55dad0 zio_execute() at zio_execute+0x1eb/frame 0xfffffe100c55db30 taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame 0xfffffe100c55db80 taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame 0xfffffe100c55dbb0 fork_exit() at fork_exit+0x84/frame 0xfffffe100c55dbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe100c55dbf0 --- trap 0, rip = 0, rsp = 0xfffffe100c55dcb0, rbp = 0 --- KDB: enter: panic Uptime: 23s Dumping 2330 out of 64465 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/kernel/if_lagg.ko.symbols...done. Loaded symbols for /boot/kernel/if_lagg.ko.symbols Reading symbols from /boot/kernel/snd_envy24ht.ko.symbols...done. Loaded symbols for /boot/kernel/snd_envy24ht.ko.symbols Reading symbols from /boot/kernel/snd_spicds.ko.symbols...done. Loaded symbols for /boot/kernel/snd_spicds.ko.symbols Reading symbols from /boot/kernel/coretemp.ko.symbols...done. Loaded symbols for /boot/kernel/coretemp.ko.symbols Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. Loaded symbols for /boot/kernel/ichsmb.ko.symbols Reading symbols from /boot/kernel/smbus.ko.symbols...done. Loaded symbols for /boot/kernel/smbus.ko.symbols Reading symbols from /boot/kernel/ichwd.ko.symbols...done. Loaded symbols for /boot/kernel/ichwd.ko.symbols Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. Loaded symbols for /boot/kernel/cpuctl.ko.symbols Reading symbols from /boot/kernel/crypto.ko.symbols...done. Loaded symbols for /boot/kernel/crypto.ko.symbols Reading symbols from /boot/kernel/cryptodev.ko.symbols...done. Loaded symbols for /boot/kernel/cryptodev.ko.symbols Reading symbols from /boot/kernel/dtraceall.ko.symbols...done. Loaded symbols for /boot/kernel/dtraceall.ko.symbols Reading symbols from /boot/kernel/profile.ko.symbols...done. Loaded symbols for /boot/kernel/profile.ko.symbols Reading symbols from /boot/kernel/cyclic.ko.symbols...done. Loaded symbols for /boot/kernel/cyclic.ko.symbols Reading symbols from /boot/kernel/dtrace.ko.symbols...done. Loaded symbols for /boot/kernel/dtrace.ko.symbols Reading symbols from /boot/kernel/systrace_freebsd32.ko.symbols...done. Loaded symbols for /boot/kernel/systrace_freebsd32.ko.symbols Reading symbols from /boot/kernel/systrace.ko.symbols...done. Loaded symbols for /boot/kernel/systrace.ko.symbols Reading symbols from /boot/kernel/sdt.ko.symbols...done. Loaded symbols for /boot/kernel/sdt.ko.symbols Reading symbols from /boot/kernel/lockstat.ko.symbols...done. Loaded symbols for /boot/kernel/lockstat.ko.symbols Reading symbols from /boot/kernel/fasttrap.ko.symbols...done. Loaded symbols for /boot/kernel/fasttrap.ko.symbols Reading symbols from /boot/kernel/fbt.ko.symbols...done. Loaded symbols for /boot/kernel/fbt.ko.symbols Reading symbols from /boot/kernel/dtnfscl.ko.symbols...done. Loaded symbols for /boot/kernel/dtnfscl.ko.symbols Reading symbols from /boot/kernel/dtmalloc.ko.symbols...done. Loaded symbols for /boot/kernel/dtmalloc.ko.symbols Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/ipmi.ko.symbols...done. Loaded symbols for /boot/kernel/ipmi.ko.symbols Reading symbols from /boot/kernel/ipmi_linux.ko.symbols...done. Loaded symbols for /boot/kernel/ipmi_linux.ko.symbols Reading symbols from /boot/kernel/radeonkms.ko.symbols...done. Loaded symbols for /boot/kernel/radeonkms.ko.symbols Reading symbols from /boot/kernel/iicbb.ko.symbols...done. Loaded symbols for /boot/kernel/iicbb.ko.symbols Reading symbols from /boot/kernel/iicbus.ko.symbols...done. Loaded symbols for /boot/kernel/iicbus.ko.symbols Reading symbols from /boot/kernel/iic.ko.symbols...done. Loaded symbols for /boot/kernel/iic.ko.symbols Reading symbols from /boot/kernel/drm2.ko.symbols...done. Loaded symbols for /boot/kernel/drm2.ko.symbols Reading symbols from /boot/kernel/radeonkmsfw_R100_cp.ko.symbols...done. Loaded symbols for /boot/kernel/radeonkmsfw_R100_cp.ko.symbols 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 #0 doadump (textdump=1) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0xffffffff809b9c67 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:452 #2 0xffffffff809ba175 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff809ba1c3 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:688 #4 0xffffffff80327abf in assfail3 (a=, lv=, op=, rv=, f=, l=) at /usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:91 #5 0xffffffff803bac1a in zap_get_leaf_byblk (zap=, blkid=4858, tx=0x0, lt=RW_READER, lp=0xfffffe100c55d5a0) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:479 #6 0xffffffff803b84f1 in zap_deref_leaf (zap=0xfffff800220bf680, h=1610088556361285632, tx=0x0, lt=RW_READER, lp=0xfffffe100c55d5a0) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:585 #7 0xffffffff803b9481 in fzap_length (zn=0xfffff80028e95600, integer_size=0xfffffe100c55d658, num_integers=0xfffffe100c55d650) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:897 #8 0xffffffff803bf5bf in zap_length_uint64 (os=, zapobj=, key=, key_numints=, integer_size=0xfffffe100c55d658, num_integers=0xfffffe100c55d650) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:934 #9 0xffffffff80352e7d in ddt_zap_lookup (os=0xfffff80020793c00, object=155, dde=0xfffff80028e96600) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ddt_zap.c:64 #10 0xffffffff8035146e in ddt_lookup (ddt=0xfffffe000d515000, bp=, add=) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ddt.c:178 #11 0xffffffff803fb242 in zio_ddt_write (zio=0xfffff800288a0730) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:2242 #12 0xffffffff803f893b in zio_execute (zio=0xfffff800288a0730) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1355 #13 0xffffffff80a01970 in taskqueue_run_locked (queue=0xfffff80020127000) at /usr/src/sys/kern/subr_taskqueue.c:355 #14 0xffffffff80a022cb in taskqueue_thread_loop (arg=) at /usr/src/sys/kern/subr_taskqueue.c:576 #15 0xffffffff80989324 in fork_exit ( callout=0xffffffff80a02230 , arg=0xfffff800200fd4e0, frame=0xfffffe100c55dc00) at /usr/src/sys/kern/kern_fork.c:977 #16 0xffffffff80d95b0e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:605 #17 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) ------------------------------------------------------------------------ ps -axlww UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -8 0 0 0 - DLs - 0:00.10 [kernel] 0 1 0 0 24 0 9368 0 wait DLs - 0:00.00 [init] 0 2 0 0 -16 0 0 0 ftcl DL - 0:00.00 [ftcleanup] 0 3 0 0 -16 0 0 0 crypto_w DL - 0:00.00 [crypto] 0 4 0 0 -16 0 0 0 crypto_r DL - 0:00.00 [crypto returns] 0 5 0 0 -16 0 0 0 ccb_scan DL - 0:00.00 [cam] 0 6 0 0 -16 0 0 0 - DL - 0:00.00 [fdc0] 0 7 0 0 -8 0 0 0 zio->io_ DL - 0:00.00 [zfskern] 0 8 0 0 -16 0 0 0 waiting_ DL - 0:00.00 [sctp_iterator] 0 9 0 0 -16 0 0 0 ipmireq DL - 0:00.00 [ipmi0: kcs] 0 10 0 0 -16 0 0 0 audit_wo DL - 0:00.00 [audit] 0 11 0 0 155 0 0 0 - RL - 0:00.00 [idle] 0 12 0 0 -84 0 0 0 - WL - 0:00.00 [intr] 0 13 0 0 -8 0 0 0 - DL - 0:00.00 [geom] 0 14 0 0 -16 0 0 0 - DL - 0:00.00 [rand_harvestq] 0 15 0 0 -68 0 0 0 - DL - 0:00.00 [usb] 0 16 0 0 -20 0 0 0 VBoxIS DL - 0:00.00 [TIMER] 0 17 0 0 -16 0 0 0 psleep DL - 0:00.00 [pagedaemon] 0 18 0 0 -16 0 0 0 psleep DL - 0:00.00 [vmdaemon] 0 19 0 0 155 0 0 0 pgzero DL - 0:00.00 [pagezero] 0 20 0 0 -16 0 0 0 psleep DL - 0:00.00 [bufdaemon] 0 21 0 0 16 0 0 0 syncer DL - 0:00.00 [syncer] 0 22 0 0 -16 0 0 0 vlruwt DL - 0:00.00 [vnlru] 0 23 0 0 -16 0 0 0 sdflush DL - 0:00.00 [softdepflush] 0 24 1 0 52 0 16928 0 wait Ds+ - 0:00.01 [sh] 0 72 24 0 52 0 16928 0 wait D+ - 0:00.00 [sh] 0 75 72 0 52 0 40000 0 tx->tx_s D+ - 0:00.00 [zfs] ------------------------------------------------------------------------ vmstat -s 158237 cpu context switches 22164 device interrupts 800 software interrupts 5019 traps 5843 system calls 23 kernel threads created 37 fork() calls 15 vfork() calls 0 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 0 swap pager pageouts 0 swap pager pages paged out 136 vnode pager pageins 911 vnode pager pages paged in 0 vnode pager pageouts 0 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 0 pages reactivated 1771 copy-on-write faults 15 copy-on-write optimized faults 2232 zero fill pages zeroed 0 zero fill pages prezeroed 0 intransit blocking page faults 4649 total VM faults taken 113 page faults requiring I/O 0 pages affected by kernel thread creation 1334 pages affected by fork() 525 pages affected by vfork() 0 pages affected by rfork() 0 pages cached 55169 pages freed 0 pages freed by daemon 0 pages freed by exiting processes 465 pages active 860 pages inactive 0 pages in VM cache 190921 pages wired down 15883166 pages free 4096 bytes per page 1886 total name lookups cache hits (80% pos + 4% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) cdev 8 2K - 8 256 ppbusdev 2 1K - 2 256 filedesc 27 54K - 76 2048 kdtrace 323 76K - 515 64,256 kenv 86 11K - 114 16,32,64,128 proc-args 3 1K - 31 32,64,128 hhook 2 1K - 2 256 ithread 125 22K - 125 32,128,256 KTRACE 100 13K - 100 128 entropy 1026 65K - 1026 32,64 acpiintr 1 1K - 1 64 linker 403 101K - 533 16,32,64,128,256,512,1024,2048,4096 lockf 2 1K - 2 64,128 loginclass 2 1K - 2 64 cache 1 1K - 1 32 devbuf 17314 34391K - 18687 16,32,64,128,256,512,1024,2048,4096 temp 57 18K - 538 16,32,64,128,256,512,1024,2048 ip6ndp 3 1K - 3 64 ata_pci 1 1K - 1 64 acpica 1824 187K - 63680 16,32,64,128,256,512,1024,2048 kbdmux 7 18K - 7 16,512,1024,2048 module 521 66K - 521 128 mtx_pool 2 16K - 2 LED 4 1K - 4 16,128 CAM XPT 58 4K - 308 16,32,64,128,512,1024,2048 osd 5 1K - 11 16,32,64,128 pmchooks 1 1K - 1 128 CAM DEV 15 30K - 24 2048 acpitask 1 8K - 1 hdaa 4 5K - 4 512,1024,2048 pgrp 2 1K - 2 128 session 2 1K - 2 128 proc 2 256K - 2 subproc 100 145K - 149 512,4096 cred 40 7K - 240 64,256 plimit 2 1K - 2 256 uidinfo 2 33K - 2 128 hdac 1 1K - 1 512 hdacc 1 1K - 1 32 vtbuf 24 5712K - 24 4096 acpisem 22 3K - 22 128 vt 11 3K - 11 256 sysctl 0 0K - 43 16,32,64 sysctloid 7607 378K - 7779 16,32,64,128 sysctltmp 0 0K - 6 32,64 tidhash 1 256K - 1 callout 9 3208K - 9 umtx 666 84K - 666 128 p1003.1b 1 1K - 1 16 SWAP 12 19681K - 12 64 bus 2257 362K - 8440 16,32,64,128,256,512,1024 bus-sc 157 310K - 5479 16,32,64,128,256,512,1024,2048,4096 devstat 32 65K - 32 32,4096 eventhandler 104 9K - 104 64,128 DEVFS3 230 58K - 270 256 kobj 349 1396K - 1111 4096 DEVFS1 202 101K - 238 512 Per-cpu 1 1K - 1 32 DEVFS 41 1K - 42 16,128 rman 360 41K - 754 16,32,128 sbuf 0 0K - 2295 16,32,64,128,256 sglist 3 1K - 3 32 taskqueue 115 17K - 159 16,32,64,128,256 terminal 11 3K - 11 256 Unitno 28 2K - 120 32,64 vmem 2 160K - 3 ioctlops 0 0K - 158 16,32,64 iov 1 1K - 27 64,256,512 msg 4 30K - 4 2048,4096 sem 4 106K - 4 2048,4096 shm 1 20K - 1 tty 14 14K - 14 1024 shmfd 1 8K - 1 pcb 12 8341K - 12 16,128,1024,2048 vfscache 1 16384K - 1 vfs_hash 1 8192K - 1 vnodes 1 1K - 1 256 mount 194 7K - 402 16,32,64,128,256 vnodemarker 0 0K - 8 512 BPF 3 1K - 3 128 ifnet 4 7K - 4 128,2048 ifaddr 34 10K - 34 32,64,256,512,2048,4096 clone 8 1K - 8 128 arpcom 2 1K - 2 16 lltable 6 3K - 6 512 routetbl 5 2K - 5 256,512 igmp 3 1K - 3 256 sctp_vrf 1 1K - 1 64 hostcache 1 28K - 1 syncache 1 64K - 1 mld 3 1K - 3 128 rpc 2 1K - 2 512 audit_evclass 187 6K - 228 32 ufs_quota 1 8192K - 1 vm_pgdata 7 8193K - 7 128 UMAHash 19 10K - 19 512 pfs_nodes 73 19K - 73 256 pfs_vncache 2 1K - 2 64 scsi_cd 0 0K - 11 16 GEOM 404 67K - 3278 16,32,64,128,256,512,1024,2048 memdesc 1 4K - 1 4096 feeder 20 2K - 24 32,128 acpidev 36 3K - 36 64 atkbddev 2 1K - 2 64 CAM CCB 1 2K - 22943 2048 mixer 3 12K - 3 4096 raid_data 0 0K - 480 32,128,256 CAM path 22 1K - 110 32 solaris 326492 166906K - 672607 16,32,64,128,256,512,1024,2048,4096 UART 6 5K - 6 16,1024 kstat_data 6 1K - 6 64 CAM periph 16 4K - 40 16,32,64,128,256 md_nvidia_data 0 0K - 78 512 pci_link 16 2K - 16 32,64,128 md_sii_data 0 0K - 78 512 acpi_perf 8 1K - 8 64 CAM queue 23 8K - 57 16,32,512 apmdev 1 1K - 1 128 madt_table 0 0K - 1 4096 CAM dev queue 8 1K - 8 64 CAM SIM 8 2K - 8 256 ddb_capture 1 48K - 1 io_apic 2 4K - 2 2048 MCA 8 1K - 8 128 msi 4 1K - 4 128 nexusdev 4 1K - 4 16 isadev 5 1K - 5 128 USB 46 59K - 52 16,32,64,128,256,512,1024,2048,4096 USBdev 35 4K - 35 32,64,128,256 linux 17 2K - 17 64 spicds 7 1K - 7 128 envy24ht 15 195K - 15 64,2048 cpuctl 1 1K - 1 64 crypto 1 1K - 1 512 cyclic 32 3K - 32 16,64,128 SDT 32 2K - 32 16,64 fbt 60661 7839K - 60661 128 iprtheap 17 54K - 17 32,64,128,256 nvidia 194 864K - 195 16,32,64,128,256,512,1024,2048,4096 ipmi 0 0K - 11 128 gem_name 59 10K - 62 32,4096 drm_global 2 1K - 2 128,256 drm_vblank 7 1K - 7 16,64 drm_dma 2 1K - 2 32 drm_sarea 1 1K - 1 16 drm_driver 32 2203K - 36 16,32,64,128,256,512,1024,4096 drm_ctxbitmap 1 4K - 1 4096 drm_sman 13 2K - 13 128 drm_hashtab 1 4096K - 1 drm_kms 90 18K - 108 16,32,64,128,256,2048 ttm_pd 6 9K - 6 16,2048 ttm_rman 2 1K - 2 256 ttm_zone 2 1K - 2 64 ttm_poolmgr 1 1K - 1 512 fdesc_mount 1 1K - 1 16 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 384, 0, 267, 3, 267, 0, 0 UMA Zones: 1664, 0, 267, 1, 267, 0, 0 UMA Slabs: 112, 0, 12325, 30, 14833, 0, 0 UMA RCntSlabs: 120, 0, 0, 0, 0, 0, 0 UMA Hash: 256, 0, 58, 32, 77, 0, 0 4 Bucket: 32, 0, 1296, 1184, 9186, 0, 0 6 Bucket: 48, 0, 310, 1018, 1646, 0, 0 8 Bucket: 64, 0, 103, 1199, 2674, 0, 0 12 Bucket: 96, 0, 64, 1084, 1327, 0, 0 16 Bucket: 128, 0, 100, 1171, 1676, 17, 0 32 Bucket: 256, 0, 240, 630, 4097, 49, 0 64 Bucket: 512, 0, 238, 287, 1922, 49, 0 128 Bucket: 1024, 0, 1190, 102, 6750, 0, 0 vmem btag: 56, 0, 14856, 409, 14954, 215, 0 VM OBJECT: 256, 0, 583, 407, 1328, 0, 0 RADIX NODE: 144, 0, 8773, 272, 13246, 0, 0 MAP: 240, 0, 3, 61, 3, 0, 0 KMAP ENTRY: 128, 0, 8, 271, 8, 0, 0 MAP ENTRY: 128, 0, 103, 1044, 1717, 0, 0 VMSPACE: 448, 0, 4, 172, 54, 0, 0 fakepg: 104, 0, 0, 0, 0, 0, 0 mt_zone: 4112, 0, 405, 0, 405, 0, 0 16: 16, 0, 6, 243, 6, 0, 0 16: 16, 0, 2762, 724, 3015, 0, 0 16: 16, 0, 154129, 749, 173890, 0, 0 16: 16, 0, 54, 693, 28214, 0, 0 16: 16, 0, 62, 436, 63, 0, 0 16: 16, 0, 690, 804, 5386, 0, 0 16: 16, 0, 30, 219, 30, 0, 0 16: 16, 0, 1, 746, 18, 0, 0 32: 32, 0, 30, 962, 116, 0, 0 32: 32, 0, 3092, 876, 3286, 0, 0 32: 32, 0, 74071, 577, 140388, 0, 0 32: 32, 0, 66, 430, 4216, 0, 0 32: 32, 0, 18, 1098, 98, 0, 0 32: 32, 0, 833, 903, 2868, 0, 0 32: 32, 0, 94, 526, 186, 0, 0 32: 32, 0, 8, 612, 164, 0, 0 64: 64, 0, 5, 181, 6, 0, 0 64: 64, 0, 516, 786, 586, 0, 0 64: 64, 0, 20714, 1172, 73124, 0, 0 64: 64, 0, 767, 659, 1637, 0, 0 64: 64, 0, 80, 106, 80, 0, 0 64: 64, 0, 9171, 749, 9688, 0, 0 64: 64, 0, 131, 303, 131, 0, 0 64: 64, 0, 1038, 884, 1071, 0, 0 128: 128, 0, 34, 865, 95, 0, 0 128: 128, 0, 1899, 364, 1908, 0, 0 128: 128, 0, 121894, 13359, 190707, 0, 0 128: 128, 0, 1077, 318, 27008, 0, 0 128: 128, 0, 112, 911, 192, 0, 0 128: 128, 0, 1877, 882, 4086, 0, 0 128: 128, 0, 29, 126, 30, 0, 0 128: 128, 0, 524, 499, 526, 0, 0 256: 256, 0, 2, 73, 2, 0, 0 256: 256, 0, 301, 254, 444, 0, 0 256: 256, 0, 7514, 4696, 54916, 0, 0 256: 256, 0, 64, 131, 740, 0, 0 256: 256, 0, 28, 287, 348, 0, 0 256: 256, 0, 903, 447, 1957, 0, 0 256: 256, 0, 31, 44, 31, 0, 0 256: 256, 0, 4, 251, 18, 0, 0 512: 512, 0, 2, 33, 9, 0, 0 512: 512, 0, 88, 206, 244, 0, 0 512: 512, 0, 347, 500, 78882, 0, 0 512: 512, 0, 16, 47, 35, 0, 0 512: 512, 0, 3, 32, 3, 0, 0 512: 512, 0, 327, 198, 2807, 0, 0 512: 512, 0, 47, 16, 47, 0, 0 512: 512, 0, 1, 62, 2, 0, 0 1024: 1024, 0, 0, 92, 99, 0, 0 1024: 1024, 0, 9, 19, 9, 0, 0 1024: 1024, 0, 8351, 125, 23312, 0, 0 1024: 1024, 0, 5, 23, 2074, 0, 0 1024: 1024, 0, 16, 12, 16, 0, 0 1024: 1024, 0, 230, 82, 1273, 0, 0 1024: 1024, 0, 2, 14, 2, 0, 0 1024: 1024, 0, 0, 0, 0, 0, 0 2048: 2048, 0, 2, 4, 9, 0, 0 2048: 2048, 0, 6, 4, 6, 0, 0 2048: 2048, 0, 11, 25, 39, 0, 0 2048: 2048, 0, 8, 58, 22955, 0, 0 2048: 2048, 0, 21, 9, 30, 0, 0 2048: 2048, 0, 48, 38, 466, 0, 0 2048: 2048, 0, 5, 1, 5, 0, 0 2048: 2048, 0, 0, 0, 0, 0, 0 4096: 4096, 0, 0, 0, 0, 0, 0 4096: 4096, 0, 5, 0, 5, 0, 0 4096: 4096, 0, 298, 2, 497, 0, 0 4096: 4096, 0, 10, 0, 12, 0, 0 4096: 4096, 0, 16, 0, 17, 0, 0 4096: 4096, 0, 25, 0, 415, 0, 0 4096: 4096, 0, 15, 0, 15, 0, 0 4096: 4096, 0, 349, 9, 1111, 0, 0 uint64 pcpu: 8, 0, 1398, 138, 1398, 0, 0 SLEEPQUEUE: 88, 0, 334, 565, 334, 0, 0 Files: 80, 0, 8, 1021, 395, 0, 0 rl_entry: 40, 0, 6, 588, 6, 0, 0 TURNSTILE: 136, 0, 334, 226, 334, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1208, 0, 26, 46, 75, 0, 0 THREAD: 1168, 0, 295, 38, 438, 0, 0 cpuset: 72, 0, 282, 488, 425, 0, 0 cyclic_id_cache: 64, 0, 0, 0, 0, 0, 0 audit_record: 1248, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 25720710, 0, 10, 0, 0, 0 mbuf: 256, 25720710, 1, 134, 1, 0, 0 mbuf_cluster: 2048, 4018860, 0, 0, 0, 0, 0 mbuf_jumbo_page: 4096, 2009429, 0, 0, 0, 0, 0 mbuf_jumbo_9k: 9216, 1786158, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 1339616, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 sendfile_sync: 128, 0, 0, 0, 0, 0, 0 dtrace_state_cache: 4096, 0, 0, 0, 0, 0, 0 g_bio: 248, 0, 3, 669, 68266, 0, 0 DMAR_MAP_ENTRY: 120, 0, 0, 0, 0, 0, 0 ttyinq: 160, 0, 15, 57, 15, 0, 0 ttyoutq: 256, 0, 8, 67, 8, 0, 0 ata_request: 336, 0, 0, 88, 42, 0, 0 vtnet_tx_hdr: 24, 0, 0, 0, 0, 0, 0 cryptop: 88, 0, 0, 0, 0, 0, 0 cryptodesc: 72, 0, 0, 0, 0, 0, 0 nv_stack_t: 12288, 0, 2, 1, 6, 0, 0 FPU_save_area: 512, 0, 0, 0, 0, 0, 0 taskq_zone: 48, 0, 0, 664, 47, 0, 0 taskq_zone: 48, 0, 0, 0, 0, 0, 0 VNODE: 472, 0, 4245, 139, 4246, 0, 0 VNODEPOLL: 112, 0, 0, 0, 0, 0, 0 BUF TRIE: 144, 0, 0, 105948, 0, 0, 0 NAMEI: 1024, 0, 0, 104, 887, 0, 0 S VFS Cache: 108, 0, 247, 908, 285, 0, 0 STS VFS Cache: 148, 0, 0, 0, 0, 0, 0 L VFS Cache: 328, 0, 0, 0, 0, 0, 0 LTS VFS Cache: 368, 0, 0, 0, 0, 0, 0 NCLNODE: 528, 0, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 0, 0, 0, 0, 0 reference_cache: 40, 0, 0, 0, 0, 0, 0 reference_history_cache: 8, 0, 0, 0, 0, 0, 0 range_seg_cache: 64, 0, 15246, 81288, 176756, 0, 0 zio_cache: 920, 0, 2874, 3294, 146114, 0, 0 zio_link_cache: 48, 0, 2867, 4686, 145725, 0, 0 zio_buf_512: 512, 0, 4917, 221, 5752, 0, 0 zio_data_buf_512: 512, 0, 362, 247, 801, 0, 0 zio_buf_1024: 1024, 0, 95, 113, 269, 0, 0 zio_data_buf_1024: 1024, 0, 421, 99, 521, 0, 0 zio_buf_1536: 1536, 0, 35, 127, 335, 0, 0 zio_data_buf_1536: 1536, 0, 717, 85, 845, 0, 0 zio_buf_2048: 2048, 0, 45, 91, 262, 0, 0 zio_data_buf_2048: 2048, 0, 295, 51, 408, 0, 0 zio_buf_2560: 2560, 0, 11, 70, 131, 0, 0 zio_data_buf_2560: 2560, 0, 202, 32, 291, 0, 0 zio_buf_3072: 3072, 0, 4, 53, 79, 0, 0 zio_data_buf_3072: 3072, 0, 151, 29, 225, 0, 0 zio_buf_3584: 3584, 0, 5, 28, 49, 0, 0 zio_data_buf_3584: 3584, 0, 106, 11, 153, 0, 0 zio_buf_4096: 4096, 0, 3767, 1199, 45373, 0, 0 zio_data_buf_4096: 4096, 0, 97, 116, 2911, 0, 0 zio_buf_5120: 5120, 0, 2, 55, 89, 0, 0 zio_data_buf_5120: 5120, 0, 185, 21, 272, 0, 0 zio_buf_6144: 6144, 0, 5, 35, 62, 0, 0 zio_data_buf_6144: 6144, 0, 150, 13, 206, 0, 0 zio_buf_7168: 7168, 0, 2, 37, 51, 0, 0 zio_data_buf_7168: 7168, 0, 110, 10, 164, 0, 0 zio_buf_8192: 8192, 0, 2, 286, 1766, 0, 0 zio_data_buf_8192: 8192, 0, 102, 9, 192, 0, 0 zio_buf_10240: 10240, 0, 1, 49, 59, 0, 0 zio_data_buf_10240: 10240, 0, 145, 10, 215, 0, 0 zio_buf_12288: 12288, 0, 1, 176, 1011, 0, 0 zio_data_buf_12288: 12288, 0, 102, 10, 149, 0, 0 zio_buf_14336: 14336, 0, 0, 24, 27, 0, 0 zio_data_buf_14336: 14336, 0, 67, 12, 100, 0, 0 zio_buf_16384: 16384, 0, 718, 40, 2238, 0, 0 zio_data_buf_16384: 16384, 0, 57, 8, 86, 0, 0 zio_buf_20480: 20480, 0, 0, 57, 571, 0, 0 zio_data_buf_20480: 20480, 0, 59, 7, 102, 0, 0 zio_buf_24576: 24576, 0, 0, 40, 565, 0, 0 zio_data_buf_24576: 24576, 0, 44, 6, 67, 0, 0 zio_buf_28672: 28672, 0, 0, 131, 1560, 0, 0 zio_data_buf_28672: 28672, 0, 40, 13, 60, 0, 0 zio_buf_32768: 32768, 0, 0, 27, 290, 0, 0 zio_data_buf_32768: 32768, 0, 31, 5, 43, 0, 0 zio_buf_36864: 36864, 0, 1, 16, 244, 0, 0 zio_data_buf_36864: 36864, 0, 32, 3, 40, 0, 0 zio_buf_40960: 40960, 0, 0, 14, 139, 0, 0 zio_data_buf_40960: 40960, 0, 18, 1, 19, 0, 0 zio_buf_45056: 45056, 0, 0, 13, 99, 0, 0 zio_data_buf_45056: 45056, 0, 21, 3, 25, 0, 0 zio_buf_49152: 49152, 0, 0, 18, 89, 0, 0 zio_data_buf_49152: 49152, 0, 16, 3, 22, 0, 0 zio_buf_53248: 53248, 0, 1, 17, 148, 0, 0 zio_data_buf_53248: 53248, 0, 22, 3, 26, 0, 0 zio_buf_57344: 57344, 0, 0, 11, 73, 0, 0 zio_data_buf_57344: 57344, 0, 14, 1, 15, 0, 0 zio_buf_61440: 61440, 0, 0, 12, 56, 0, 0 zio_data_buf_61440: 61440, 0, 10, 3, 13, 0, 0 zio_buf_65536: 65536, 0, 0, 11, 46, 0, 0 zio_data_buf_65536: 65536, 0, 4, 1, 5, 0, 0 zio_buf_69632: 69632, 0, 0, 8, 27, 0, 0 zio_data_buf_69632: 69632, 0, 8, 1, 9, 0, 0 zio_buf_73728: 73728, 0, 0, 9, 27, 0, 0 zio_data_buf_73728: 73728, 0, 5, 0, 5, 0, 0 zio_buf_77824: 77824, 0, 0, 9, 41, 0, 0 zio_data_buf_77824: 77824, 0, 6, 1, 7, 0, 0 zio_buf_81920: 81920, 0, 0, 13, 84, 0, 0 zio_data_buf_81920: 81920, 0, 9, 1, 10, 0, 0 zio_buf_86016: 86016, 0, 0, 8, 25, 0, 0 zio_data_buf_86016: 86016, 0, 5, 3, 8, 0, 0 zio_buf_90112: 90112, 0, 0, 10, 33, 0, 0 zio_data_buf_90112: 90112, 0, 3, 1, 4, 0, 0 zio_buf_94208: 94208, 0, 0, 6, 15, 0, 0 zio_data_buf_94208: 94208, 0, 4, 1, 5, 0, 0 zio_buf_98304: 98304, 0, 1, 5, 20, 0, 0 zio_data_buf_98304: 98304, 0, 9, 0, 9, 0, 0 zio_buf_102400: 102400, 0, 0, 7, 13, 0, 0 zio_data_buf_102400: 102400, 0, 2, 1, 3, 0, 0 zio_buf_106496: 106496, 0, 0, 16, 99, 0, 0 zio_data_buf_106496: 106496, 0, 12, 2, 14, 0, 0 zio_buf_110592: 110592, 0, 0, 12, 72, 0, 0 zio_data_buf_110592: 110592, 0, 6, 1, 7, 0, 0 zio_buf_114688: 114688, 0, 0, 22, 79, 0, 0 zio_data_buf_114688: 114688, 0, 6, 0, 6, 0, 0 zio_buf_118784: 118784, 0, 0, 8, 22, 0, 0 zio_data_buf_118784: 118784, 0, 0, 0, 0, 0, 0 zio_buf_122880: 122880, 0, 0, 9, 28, 0, 0 zio_data_buf_122880: 122880, 0, 6, 0, 6, 0, 0 zio_buf_126976: 126976, 0, 0, 10, 22, 0, 0 zio_data_buf_126976: 126976, 0, 0, 0, 0, 0, 0 zio_buf_131072: 131072, 0, 160, 79, 862, 0, 0 zio_data_buf_131072: 131072, 0, 383, 8, 556, 0, 0 lz4_ctx: 16384, 0, 0, 0, 0, 0, 0 sa_cache: 80, 0, 4199, 848, 4199, 0, 0 dnode_t: 1096, 0, 4649, 31, 5833, 0, 0 dmu_buf_impl_t: 336, 0, 9678, 68, 14441, 0, 0 arc_buf_hdr_t: 328, 0, 10162, 134, 11502, 0, 0 arc_buf_t: 72, 0, 9396, 614, 12289, 0, 0 zil_lwb_cache: 192, 0, 0, 0, 0, 0, 0 zfs_znode_cache: 368, 0, 4199, 151, 4199, 0, 0 pipe: 744, 0, 0, 55, 13, 0, 0 Mountpoints: 816, 0, 17, 23, 17, 0, 0 procdesc: 128, 0, 0, 0, 0, 0, 0 ksiginfo: 112, 0, 24, 1026, 24, 0, 0 itimer: 352, 0, 0, 0, 0, 0, 0 KNOTE: 128, 0, 0, 0, 0, 0, 0 socket: 696, 2062880, 0, 0, 0, 0, 0 ipq: 56, 125599, 0, 0, 0, 0, 0 udp_inpcb: 392, 2062880, 0, 0, 0, 0, 0 udpcb: 16, 2062965, 0, 0, 0, 0, 0 tcp_inpcb: 392, 2062880, 0, 0, 0, 0, 0 tcpcb: 1024, 2062880, 0, 0, 0, 0, 0 tcptw: 88, 27810, 0, 0, 0, 0, 0 syncache: 160, 15360, 0, 0, 0, 0, 0 hostcache: 136, 15370, 0, 0, 0, 0, 0 tcpreass: 40, 251262, 0, 0, 0, 0, 0 sackhole: 32, 0, 0, 0, 0, 0, 0 sctp_ep: 1408, 2062880, 0, 0, 0, 0, 0 sctp_asoc: 2352, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80012, 0, 0, 0, 0, 0 sctp_raddr: 728, 80000, 0, 0, 0, 0, 0 sctp_chunk: 136, 400026, 0, 0, 0, 0, 0 sctp_readq: 104, 400026, 0, 0, 0, 0, 0 sctp_stream_msg_out: 104, 400026, 0, 0, 0, 0, 0 sctp_asconf: 40, 400059, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400060, 0, 0, 0, 0, 0 ripcb: 392, 2062880, 0, 0, 0, 0, 0 unpcb: 240, 2062880, 0, 0, 0, 0, 0 rtentry: 200, 0, 0, 0, 0, 0, 0 selfd: 56, 0, 0, 0, 0, 0, 0 SWAPMETA: 288, 8037731, 0, 0, 0, 0, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq6: fdc0 22 0 irq14: ata0 61 0 irq17: uhci0 ehci0 54 0 irq18: uhci2+ 306 2 irq19: uhci1 ahci0+ 21712 146 cpu0:timer 3524 23 irq259: hdac0 9 0 cpu7:timer 2042 13 cpu1:timer 1450 9 cpu3:timer 3609 24 cpu2:timer 1414 9 cpu6:timer 1949 13 cpu4:timer 1408 9 cpu5:timer 1575 10 Total 39135 264 ------------------------------------------------------------------------ pstat -T 8/2062880 files 0M/147455M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/#C:0xc0 50331392 0 50331392 0% /dev/ad14p2 50331392 0 50331392 0% /dev/usb/3.2.1 50331392 0 50331392 0% /dev/#C:0xd0 50331392 0 50331392 0% /dev/#C:0xd8 50331392 0 50331392 0% /dev/#C:0xe0 50331392 0 50331392 0% Total 301988352 0 301988352 0% ------------------------------------------------------------------------ iostat tty ada0 ada1 ada2 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 9 15.20 161 2.39 14.99 169 2.47 15.24 167 2.49 0 0 4 1 96 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) shminfo: shmmax: 536870912 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 131072 (max amount of shared memory in pages) seminfo: semmni: 50 (# of semaphore identifiers) semmns: 340 (# of semaphores in system) semmnu: 150 (# of undo structures in system) semmsl: 340 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 50 (max # of undo entries per process) semusz: 632 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat Client Info: Rpc Counts: Getattr Setattr Lookup Readlink Read Write Create Remove 2 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 1 1 0 0 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 0 0 4 Cache Info: Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Misses 0 0 0 0 0 0 0 0 BioRLHits Misses BioD Hits Misses DirE Hits Misses Accs Hits Misses 0 0 0 0 0 0 0 0 Server Info: Getattr Setattr Lookup Readlink Read Write Create Remove 0 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Server Ret-Failed 0 Server Faults 0 Server Cache Stats: Inprog Idem Non-idem Misses 0 0 0 0 Server Write Gathering: WriteOps WriteRPC Opsaved 0 0 0 ------------------------------------------------------------------------ netstat -s tcp: 0 packets sent 0 data packets (0 bytes) 0 data packets (0 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 0 ack-only packets (0 delayed) 0 URG only packets 0 window probe packets 0 window update packets 0 control packets 0 packets received 0 acks (for 0 bytes) 0 duplicate acks 0 acks for unsent data 0 packets (0 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 0 connection requests 0 connection accepts 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 0 connections established (including accepts) 0 connections closed (including 0 drops) 0 connections updated cached RTT on close 0 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 0 segments updated rtt (of 0 attempts) 0 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 0 correct ACK header predictions 0 correct data packet header predictions 0 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 0 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 0 cookies sent 0 cookies received 0 hostcache entries added 0 bucket overflow 0 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 0 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 0 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 0 dropped due to no socket 0 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 0 delivered 0 datagrams output 0 times multicast source filter matched ip: 0 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 0 packets for this host 0 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 0 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 0 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 0 calls to icmp_error 0 errors not generated in response to an icmp message 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored 0 message responses generated 0 invalid return addresses 0 no return routes igmp: 0 messages received 0 messages received with too few bytes 0 messages received with wrong TTL 0 messages received with bad checksum 0 V1/V2 membership queries received 0 V3 membership queries received 0 membership queries received with invalid field(s) 0 general queries received 0 group queries received 0 group-source queries received 0 group-source queries dropped 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 V3 reports received without Router Alert 0 membership reports sent arp: 0 ARP requests sent 0 ARP replies sent 0 ARP requests received 0 ARP replies received 0 ARP packets received 0 total packets dropped due to no ARP entry 0 ARP entrys timed out 0 Duplicate IPs seen ip6: 0 total packets received 0 with size smaller than minimum 0 with data size < data length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 fragments that exceeded limit 0 packets reassembled ok 0 packets for this host 0 packets forwarded 0 packets not forwardable 0 redirects sent 0 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 packets that violated scope rules 0 multicast packets which we don't join Mbuf statistics: 0 one mbuf 0 one ext mbuf 0 two or more ext mbuf 0 packets whose headers are not contiguous 0 tunneling packets that can't find gif 0 packets discarded because of too many headers 0 failures of source address selection Source addresses selection rule applied: icmp6: 0 calls to icmp6_error 0 errors not generated in response to an icmp6 message 0 errors not generated because of rate limitation 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Histogram of error messages to be generated: 0 no route 0 administratively prohibited 0 beyond scope 0 address unreachable 0 port unreachable 0 packet too big 0 time exceed transit 0 time exceed reassembly 0 erroneous header field 0 unrecognized next header 0 unrecognized option 0 redirect 0 unknown 0 message responses generated 0 messages with too many ND options 0 messages with bad ND options 0 bad neighbor solicitation messages 0 bad neighbor advertisement messages 0 bad router solicitation messages 0 bad router advertisement messages 0 bad redirect messages 0 path MTU changes rip6: 0 messages received 0 checksum calculations on inbound 0 messages with bad checksum 0 messages dropped due to no socket 0 multicast messages dropped due to no socket 0 messages dropped due to full socket buffers 0 delivered 0 datagrams output ------------------------------------------------------------------------ netstat -m netstat: invalid address (0x0) 1/144/145 mbufs in use (current/cache/total) 18446744073709551606/10/0/4018860 mbuf clusters in use (current/cache/total/max) 0/10 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/2009429 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/1786158 9k jumbo clusters in use (current/cache/total/max) 0/0/0/1339616 16k jumbo clusters in use (current/cache/total/max) 18014398509481964K/56K/36K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) ------------------------------------------------------------------------ netstat -anr Routing tables Internet: Destination Gateway Flags Netif Expire Internet6: Destination Gateway Flags Netif Expire ------------------------------------------------------------------------ netstat -anA ------------------------------------------------------------------------ netstat -aL ------------------------------------------------------------------------ fstat fstat: can't read file 1 at 0x200007fffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 7 at 0x200007fffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x200007fffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 7 at 0x200007fffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x200007fffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 7 at 0x200007fffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root zfs 75 root - - error - root zfs 75 wd - - error - root zfs 75 text - - error - root zfs 75 ctty /dev 13 crw------- console rw root zfs 75 0 /dev 13 crw------- console rw root zfs 75 6 /dev 13 crw------- console rw root sh 72 root - - error - root sh 72 wd - - error - root sh 72 text - - error - root sh 72 ctty /dev 13 crw------- console rw root sh 72 0 /dev 13 crw------- console rw root sh 72 6 /dev 13 crw------- console rw root sh 24 root - - error - root sh 24 wd - - error - root sh 24 text - - error - root sh 24 ctty /dev 13 crw------- console rw root sh 24 0 /dev 13 crw------- console rw root sh 24 6 /dev 13 crw------- console rw root init 1 root - - error - root init 1 wd - - error - root init 1 text - - error - root kernel 0 root - - error - root kernel 0 wd - - error - ------------------------------------------------------------------------ dmesg Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #3 r261166: Sat Jan 25 14:55:24 CST 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 info: [drm] Initialized drm 1.1.0 20060810 CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (2327.55-MHz K8-class CPU) Origin="GenuineIntel" Id=0x10676 Family=0x6 Model=0x17 Stepping=6 Features=0xbfebfbff Features2=0xce3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 68719476736 (65536 MB) avail memory = 65641644032 (62600 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard random: initialized kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) unknown: I/O range not supported cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 350 Event timer "HPET1" frequency 14318180 Hz quality 340 Event timer "HPET2" frequency 14318180 Hz quality 340 atrtc0: port 0x70-0x71 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 pcib5: at device 0.2 on pci3 pci5: on pcib5 pcib6: irq 18 at device 2.0 on pci2 pci6: on pcib6 em0: port 0x2000-0x201f mem 0xd9220000-0xd923ffff,0xd9200000-0xd921ffff irq 18 at device 0.0 on pci6 em0: Using an MSI interrupt em0: Ethernet address: 00:30:48:f2:29:9c em1: port 0x2020-0x203f mem 0xd9260000-0xd927ffff,0xd9240000-0xd925ffff irq 19 at device 0.1 on pci6 em1: Using an MSI interrupt em1: Ethernet address: 00:30:48:f2:29:9d pcib7: at device 0.3 on pci1 pci7: on pcib7 pcib8: at device 4.0 on pci0 pci8: on pcib8 vgapci0: port 0x3000-0x307f mem 0xd8000000-0xd8ffffff,0xc0000000-0xc7ffffff,0xc8000000-0xc9ffffff irq 16 at device 0.0 on pci8 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io hdac0: mem 0xd9000000-0xd9003fff irq 17 at device 0.1 on pci8 pcib9: at device 6.0 on pci0 pci9: on pcib9 pci0: at device 8.0 (no driver attached) pcib10: irq 17 at device 28.0 on pci0 pci10: on pcib10 pcib11: irq 16 at device 0.0 on pci10 pci11: on pcib11 pcm0: port 0x4080-0x409f,0x4000-0x407f irq 16 at device 0.0 on pci11 pcm0: system configuration SubVendorID: 0x1412, SubDeviceID: 0x2403 XIN2 Clock Source: 24.576MHz(96kHz*256) MPU-401 UART(s) #: not implemented ADC #: 1 and SPDIF receiver connected DAC #: 4 Multi-track converter type: AC'97(SDATA_OUT:packed) S/PDIF(IN/OUT): 1/1 ID# 0x00 GPIO(mask/dir/state): 0xff/0xff/0xff uhci0: port 0x1800-0x181f irq 17 at device 29.0 on pci0 usbus0 on uhci0 uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 usbus1 on uhci1 uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 usbus2 on uhci2 ehci0: mem 0xd9600400-0xd96007ff irq 17 at device 29.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib12: at device 30.0 on pci0 pci12: on pcib12 vgapci1: port 0x5000-0x50ff mem 0xd0000000-0xd7ffffff,0xd9300000-0xd930ffff irq 18 at device 1.0 on pci12 drmn1: on vgapci1 info: [drm] RADEON_IS_PCI info: [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080). info: [drm] register mmio base: 0xD9300000 info: [drm] register mmio size: 65536 info: [drm] radeon_atrm_get_bios: ===> Try ATRM... info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:8:0:0, vendor=10de, device=104a info: [drm] radeon_atrm_get_bios: Get ACPI device handle info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0xd0000000 info: [drm] igp_read_bios_from_vram: Map address: 0xfffff800d0000000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x0000 info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] radeon_read_bios: Map address: 0xfffff800000c0000 (131072 bytes) drmn1: info: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used) drmn1: info: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] radeon: irq initialized. info: [drm] Detected VRAM RAM=128M, BAR=128M info: [drm] RAM width 64bits SDR [TTM] Zone kernel: Available graphics memory: 33006090 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator info: [drm] radeon: 16M of VRAM memory ready info: [drm] radeon: 512M of GTT memory ready. info: [drm] GART: num cpu pages 131072, num gpu pages 131072 info: [drm] PCI GART of 512M enabled (table at 0x0000000011200000). drmn1: info: WB disabled drmn1: info: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0x0xfffff8001083c000 info: [drm] Loading R100 Microcode info: [drm] radeon: ring at 0x00000000B0001000 info: [drm] ring test succeeded in 1 usecs info: [drm] ib test succeeded in 0 usecs info: [drm] radeon_device_init: Taking over the fictitious range 0xd0000000-0xd4000000 iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iicbus1: on iicbb1 addr 0xff iic1: on iicbus1 iicbus2: on iicbb2 addr 0xff iic2: on iicbus2 iicbus3: on iicbb3 addr 0xff iic3: on iicbus3 info: [drm] Radeon Display Connectors info: [drm] Connector 0: info: [drm] VGA-1 info: [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60 info: [drm] Encoders: info: [drm] CRT1: INTERNAL_DAC1 info: [drm] Connector 1: info: [drm] DVI-I-1 info: [drm] HPD2 info: [drm] DDC: 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c info: [drm] Encoders: info: [drm] CRT2: INTERNAL_DAC2 info: [drm] DFP2: INTERNAL_DVO1 composite sync not supported composite sync not supported info: [drm] fb mappable at 0xD0040000 info: [drm] vram apper at 0xD0000000 info: [drm] size 2076672 info: [drm] fb depth is 8 info: [drm] pitch is 1920 fbd1 on drmn1 vt_allocate: Replace existing VT driver. info: [drm] Initialized radeon 2.29.0 20080528 vgapci1: Boot video device isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: at channel 0 on atapci0 ahci0: port 0x18a0-0x18a7,0x1874-0x1877,0x1878-0x187f,0x1870-0x1873,0x1880-0x189f mem 0xd9600800-0xd9600bff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ichsmb0: port 0x1100-0x111f irq 19 at device 31.3 on pci0 smbus0: on ichsmb0 acpi_button0: on acpi0 ipmi0: port 0xca2-0xca3 on acpi0 ipmi0: KCS mode found at io 0xca2 on acpi atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ichwd0 on isa0 orm0: at iomem 0xc0000-0xcafff on isa0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 coretemp4: on cpu4 est4: on cpu4 p4tcc4: on cpu4 coretemp5: on cpu5 est5: on cpu5 p4tcc5: on cpu5 coretemp6: on cpu6 est6: on cpu6 p4tcc6: on cpu6 coretemp7: on cpu7 est7: on cpu7 p4tcc7: on cpu7 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x387 offMax=0x50f hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm1: at nid 4 on hdaa0 pcm2: at nid 5 on hdaa0 random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen3.1: at usbus3 uhub0: on usbus3 ugen2.1: at usbus2 uhub1: on usbus2 ugen1.1: at usbus1 uhub2: on usbus1 ugen0.1: at usbus0 uhub3: on usbus0 ipmi0: IPMI device rev. 1, firmware rev. 1.64, version 2.0 ata0: DMA limited to UDMA33, controller found non-ATA66 cable ipmi0: Number of channels 8 ipmi0: Attached watchdog uhub2: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: Serial Number 5YDA1ZL4 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus2 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: Serial Number 5YD6FPLG ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada1: quirks=0x1<4K> ada1: Previously was known as ad6 ada2 at ahcich2 bus 0 scbus3 target 0 lun 0 ada2: ATA-8 SATA 3.x device ada2: Serial Number 5YDA3PC5 ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada2: quirks=0x1<4K> ada2: Previously was known as ad8 ada3 at ahcich3 bus 0 scbus4 target 0 lun 0 ada3: ATA-8 SATA 3.x device ada3: Serial Number 5YD9Y0P4 ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3: quirks=0x1<4K> ada3: Previously was known as ad10 ada4 at ahcich4 bus 0 scbus5 target 0 lun 0 ada4: ATA-8 SATA 3.x device ada4: Serial Number 5YDA1R5W ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada4: quirks=0x1<4K> ada4: Previously was known as ad12 ada5 at ahcich5 bus 0 scbus6 target 0 lun 0 ada5: ATA-8 SATA 3.x device ada5: Serial Number 5YD5RBS8 ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada5: quirks=0x1<4K> ada5: Previously was known as ad14 cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present Netvsc initializing... done! SMP: AP CPU #7 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #5 Launched! Root mount waiting for: usbus3 uhub0: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 Root mount waiting for: usbus3 ugen3.2: at usbus3 ukbd0: on usbus3 kbd2 at ukbd0 Trying to mount root from zfs:zroot/ROOT/default []... ugen0.2: at usbus0 ugen1.2: at usbus1 Setting hostuuid: 53d19f64-d663-a017-8922-0030488e9ff3. Setting hostid: 0xf53a926e. Entropy harvesting: interrupts ethernet point_to_point swi. Starting file system checks: Mounting local file systems:. panic: solaris assert: l->l_phys->l_hdr.lh_pad1 == 0 (0xffff000000000000 == 0x0), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c, line: 479 cpuid = 7 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe100c55d350 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe100c55d400 vpanic() at vpanic+0x126/frame 0xfffffe100c55d440 panic() at panic+0x43/frame 0xfffffe100c55d4a0 assfail3() at assfail3+0x2f/frame 0xfffffe100c55d4c0 zap_get_leaf_byblk() at zap_get_leaf_byblk+0x2ea/frame 0xfffffe100c55d510 zap_deref_leaf() at zap_deref_leaf+0xd1/frame 0xfffffe100c55d560 fzap_length() at fzap_length+0x31/frame 0xfffffe100c55d5d0 zap_length_uint64() at zap_length_uint64+0xbf/frame 0xfffffe100c55d630 ddt_zap_lookup() at ddt_zap_lookup+0x3d/frame 0xfffffe100c55d790 ddt_lookup() at ddt_lookup+0x17e/frame 0xfffffe100c55d960 zio_ddt_write() at zio_ddt_write+0xf2/frame 0xfffffe100c55dad0 zio_execute() at zio_execute+0x1eb/frame 0xfffffe100c55db30 taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame 0xfffffe100c55db80 taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame 0xfffffe100c55dbb0 fork_exit() at fork_exit+0x84/frame 0xfffffe100c55dbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe100c55dbf0 --- trap 0, rip = 0, rsp = 0xfffffe100c55dcb0, rbp = 0 --- KDB: enter: panic Uptime: 23s Dumping 2330 out of 64465 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% ------------------------------------------------------------------------ kernel config options CONFIG_AUTOGENERATED ident VT-LER machine amd64 cpu HAMMER makeoptions WITH_CTF=1 makeoptions DEBUG=-g options ZFS options XENHVM options USB_DEBUG options ATH_ENABLE_11N options AH_AR5416_INTERRUPT_MITIGATION options AH_SUPPORT_AR5416 options IEEE80211_SUPPORT_MESH options IEEE80211_AMPDU_AGE options IEEE80211_DEBUG options SC_PIXEL_MODE options VESA options AHD_REG_PRETTY_PRINT options AHC_REG_PRETTY_PRINT options ATA_STATIC_ID options ACPI_DMAR options SMP options MALLOC_DEBUG_MAXZONES=8 options INVARIANT_SUPPORT options INVARIANTS options DEADLKRES options GDB options DDB options KDB_TRACE options KDB options INCLUDE_CONFIG_FILE options DDB_CTF options KDTRACE_HOOKS options KDTRACE_FRAME options MAC options CAPABILITIES options CAPABILITY_MODE options AUDIT options HWPMC_HOOKS options KBD_INSTALL_CDEV options PRINTF_BUFR_SIZE=128 options _KPOSIX_PRIORITY_SCHEDULING options SYSVSEM options SYSVMSG options SYSVSHM options STACK options KTRACE options SCSI_DELAY=5000 options COMPAT_FREEBSD7 options COMPAT_FREEBSD6 options COMPAT_FREEBSD5 options COMPAT_FREEBSD4 options COMPAT_FREEBSD32 options GEOM_LABEL options GEOM_RAID options GEOM_PART_GPT options PSEUDOFS options PROCFS options CD9660 options MSDOSFS options NFS_ROOT options NFSLOCKD options NFSD options NFSCL options MD_ROOT options QUOTA options UFS_GJOURNAL options UFS_DIRHASH options UFS_ACL options SOFTUPDATES options FFS options SCTP options TCP_OFFLOAD options INET6 options INET options PREEMPTION options SCHED_ULE options NEW_PCIB options GEOM_PART_MBR options GEOM_PART_EBR_COMPAT options GEOM_PART_EBR options GEOM_PART_BSD device isa device mem device io device uart_ns8250 device cpufreq device acpi device pci device fdc device ahci device ata device mvs device siis device ahc device ahd device esp device hptiop device isp device mpt device mps device sym device trm device adv device adw device aic device bt device isci device scbus device ch device da device sa device cd device pass device ses device amr device arcmsr device ciss device dpt device hptmv device hptnr device hptrr device hpt27xx device iir device ips device mly device twa device tws device aac device aacp device aacraid device ida device mfi device mlx device twe device atkbdc device atkbd device psm device kbdmux device splash device agp device cbb device pccard device cardbus device uart device ppc device ppbus device lpt device ppi device puc device bxe device de device em device igb device ixgbe device le device ti device txp device vx device miibus device ae device age device alc device ale device bce device bfe device bge device cas device dc device et device fxp device gem device hme device jme device lge device msk device nfe device nge device pcn device re device rl device sf device sge device sis device sk device ste device stge device tl device tx device vge device vr device wb device xl device cs device ed device ex device ep device fe device sn device xe device wlan device wlan_wep device wlan_ccmp device wlan_tkip device wlan_amrr device an device ath device ath_pci device ath_hal device ath_rate_sample device ipw device iwi device iwn device malo device mwl device ral device wi device wpi device loop device random device padlock_rng device rdrand_rng device ether device vlan device tun device md device gif device faith device firmware device bpf device uhci device ohci device ehci device xhci device usb device ukbd device umass device sound device snd_cmi device snd_csa device snd_emu10kx device snd_es137x device snd_hda device snd_ich device snd_via8233 device mmc device mmcsd device sdhci device virtio device virtio_pci device vtnet device virtio_blk device virtio_scsi device virtio_balloon device hyperv device xenpci device vmx device vt device vt_vga ------------------------------------------------------------------------ ddb capture buffer -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Sat Jan 25 21:34:38 2014 Return-Path: Delivered-To: freebsd-current@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 09D8EB12; Sat, 25 Jan 2014 21:34:38 +0000 (UTC) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 648BC1909; Sat, 25 Jan 2014 21:34:37 +0000 (UTC) Received: by mail-bk0-f45.google.com with SMTP id v16so2010289bkz.4 for ; Sat, 25 Jan 2014 13:34:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:in-reply-to:references:mime-version:content-type:subject :from:date:to:message-id; bh=vJLlmpjUkJigCqWU+9ITZee6ODgv9nFi5ga7xqbotDc=; b=wYf5bMznYecG2OtDijyu9HbkMZW/as9jbgOZJTCyJZLn1Gng8c9Fx6haNNRyAuhUEU xBogQTSeFlq7fR2xk4WM8lsf71oIDyMxIDSg3b953GA8Bh6Pyn28gz8326zLqFntOsE5 bGdrXXuz8oArB/6IibuJWozJ0Ubr4dEYMTKMalWc6wvO7jJodbH3u+QRVjr6UxMsygxK nIUNbuY9IWDVWJsGdEfnDmXE88zmyIN+i4GFgKpNLzYc5sLKjaA7sIV/wmQjuj5/WsIe eBOE0Qi8vmKA7v4T58RWe0gLbG402PY34LlT44fMhHwK9egD73UPp78Auj1OZ+LQvV+H JkLw== X-Received: by 10.204.80.78 with SMTP id s14mr15390430bkk.6.1390685675592; Sat, 25 Jan 2014 13:34:35 -0800 (PST) Received: from ?IPV6:2001:470:7b2f:0:d02b:d335:23e4:fe54? ([2001:470:7b2f:0:d02b:d335:23e4:fe54]) by mx.google.com with ESMTPSA id ch4sm7560256bkc.8.2014.01.25.13.34.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Jan 2014 13:34:35 -0800 (PST) User-Agent: K-9 Mail for Android In-Reply-To: <52E42A3A.7000901@FreeBSD.org> References: <1367fd4d-9128-4df0-a250-fb3c1f67f0c5@email.android.com> <52E42A3A.7000901@FreeBSD.org> MIME-Version: 1.0 Subject: Re: Newcons radeonkms - Failed to load firmware "radeonkmsfw_TURKS_PFP" From: "Mike C." Date: Sat, 25 Jan 2014 21:34:31 +0000 To: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= , freebsd-current@freebsd.org Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 21:34:38 -0000 Ah I was wrongly assuming that loading readonkms would do that, but as you say and the guide the filesystem isn't mounted... stupid me! Many thanks. "Jean-Sébastien Pédron" wrote: >On 25.01.2014 18:43, Mike C. wrote: >> After rebuilding the kernel with newcons support (which is working) >> I've placed radeonkms_load="YES" in boot loader and rebooted and get >> this screen. >> >> what am I doing wrong? > >Hello! > >If you want to load radeonkms at boot time (from /boot/loader.conf), >you >need to load the required firmwares too, otherwise they can't be loaded >automatically during boot (/ isn't mounted yet). > >To find the list of firmwares you need to load, you can read >instructions on the wiki: >https://wiki.freebsd.org/Graphics#Video_driver_loaded_at_boot_time > >-- >Jean-Sébastien Pédron -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From owner-freebsd-current@FreeBSD.ORG Sat Jan 25 21:45:57 2014 Return-Path: Delivered-To: freebsd-current@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 29BEB200; Sat, 25 Jan 2014 21:45:57 +0000 (UTC) Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 84B5819E9; Sat, 25 Jan 2014 21:45:56 +0000 (UTC) Received: by mail-bk0-f43.google.com with SMTP id mx11so2016344bkb.16 for ; Sat, 25 Jan 2014 13:45:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:in-reply-to:references:mime-version:content-type:subject :from:date:to:message-id; bh=zUe+iXMWI41vy1UDrOD6UrO4KE+0Zp7fRpc/JvuUAvA=; b=KRm2hpsOYS6A4lDqnBDoCUvakNJTxvawnOSTGthHh3rP5Mab+2CAfenDOkVXmJ4igY m9yCzps81zP3dO48p7BCib3tqLSAN+O7T1keIRaTv87kwGUGL6txGuhEfPeQKWCTXHy8 rsHdEte+EQwUdVBUhVN00cJmIvdbpWy+2ZGCbgKjgrQs8LYjfYG5EuC6GcyKpKwUEPum Ebhdt+xb9hKfJxiBqJ2ijZGU0ANpDi0ykQMp5+k7Q/BYRpH5hhGukK4gOOd1wG6iXiXN A8UO5G5/BbgC9z3XgSbRh9QWjl8yBKPPzaSM43GHF0kQDluNCdhuziKmGjK4iu2gP97V XFoQ== X-Received: by 10.204.167.81 with SMTP id p17mr12214772bky.59.1390686354874; Sat, 25 Jan 2014 13:45:54 -0800 (PST) Received: from ?IPV6:2001:470:7b2f:0:d02b:d335:23e4:fe54? ([2001:470:7b2f:0:d02b:d335:23e4:fe54]) by mx.google.com with ESMTPSA id kk3sm7581644bkb.12.2014.01.25.13.45.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Jan 2014 13:45:54 -0800 (PST) User-Agent: K-9 Mail for Android In-Reply-To: <52E42A3A.7000901@FreeBSD.org> References: <1367fd4d-9128-4df0-a250-fb3c1f67f0c5@email.android.com> <52E42A3A.7000901@FreeBSD.org> MIME-Version: 1.0 Subject: Re: Newcons radeonkms - Failed to load firmware "radeonkmsfw_TURKS_PFP" From: "Mike C." Date: Sat, 25 Jan 2014 21:45:50 +0000 To: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= , freebsd-current@freebsd.org Message-ID: <712a6e8d-e34b-4321-8c23-aa9edfe6147f@email.android.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 21:45:57 -0000 Worked but I'm still stuck in this case at 'vt_allocate: Replace existing VT driver.' a few lines up I see: No connectors reported connected with modes. should I post to freebsd-x11@FreeBSD.org? Thanks "Jean-Sébastien Pédron" wrote: >On 25.01.2014 18:43, Mike C. wrote: >> After rebuilding the kernel with newcons support (which is working) >> I've placed radeonkms_load="YES" in boot loader and rebooted and get >> this screen. >> >> what am I doing wrong? > >Hello! > >If you want to load radeonkms at boot time (from /boot/loader.conf), >you >need to load the required firmwares too, otherwise they can't be loaded >automatically during boot (/ isn't mounted yet). > >To find the list of firmwares you need to load, you can read >instructions on the wiki: >https://wiki.freebsd.org/Graphics#Video_driver_loaded_at_boot_time > >-- >Jean-Sébastien Pédron -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From owner-freebsd-current@FreeBSD.ORG Sat Jan 25 22:07:41 2014 Return-Path: Delivered-To: freebsd-current@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 318BADEF for ; Sat, 25 Jan 2014 22:07:41 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E45681B4E for ; Sat, 25 Jan 2014 22:07:40 +0000 (UTC) Received: from 2a02-8428-011a-a000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11a:a000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1W7BO5-00017q-VE for freebsd-current@freebsd.org; Sat, 25 Jan 2014 23:07:39 +0100 Message-ID: <52E435A3.6010900@FreeBSD.org> Date: Sat, 25 Jan 2014 23:07:31 +0100 From: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Newcons radeonkms - Failed to load firmware "radeonkmsfw_TURKS_PFP" References: <1367fd4d-9128-4df0-a250-fb3c1f67f0c5@email.android.com> <52E42A3A.7000901@FreeBSD.org> <712a6e8d-e34b-4321-8c23-aa9edfe6147f@email.android.com> In-Reply-To: <712a6e8d-e34b-4321-8c23-aa9edfe6147f@email.android.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1fp8NdnLBQOgR6orkQ7CGJgWvDwBrPagT" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 22:07:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1fp8NdnLBQOgR6orkQ7CGJgWvDwBrPagT Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 25.01.2014 22:45, Mike C. wrote: > Worked but I'm still stuck in this case at 'vt_allocate: Replace existi= ng VT driver.' >=20 > a few lines up I see: > No connectors reported connected with modes. Could you please boot without loading the Radeon driver from loader.conf, and run "kldload radeonkms", then post a full dmesg? > should I post to freebsd-x11@FreeBSD.org? Yes, this will be more on topic. --=20 Jean-S=C3=A9bastien P=C3=A9dron --1fp8NdnLBQOgR6orkQ7CGJgWvDwBrPagT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJS5DWpXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMGnMQAOMp5nK21w69KmNtgL0MQQOd XCm6SAoKiDonBrTgGBIEAsg77IkHArd6YwJEC/kN4dhQvBJJR7v5wzD8fMphJ/24 2r5SHiJ+FFTkJoI5WRG40yiyJHEt8lUPRUilneLDR4SsVaZtqB5HhuDpXoyaWrAO D29fIKbfcMPYZJbF8IruvP5xMG8Qtj0GUXju8CiOaSzMnVKIT8rsu8zfWfpEFnbJ z9Tg5F1UckjgenEbAH33KnEt72uwvP/IZZ2P/PBnQoA4p5lmWrdP8/KbJjV06rTH 9d4kSzOVuKv9qIb0TOoMJg8DcbRzXZYjGbSs4pL5mR+9kuPHSdfy6fxfpaz1ppdS kTJKlAhifyB5Kg2L8g3jt9C5OMW4aXhTzBJ40NohJGYCNep3PmYx5dbuzptsVJ0O t9eVbSH3HAGsWyLI6W+/vWh1lMPqoX8fLJ+F/eT30VdymIQo+k6kejSPsq8ppvTv woIDeQtx8P7onioS6XyoUFPPxT/o3AsH6Bwja9nvmqAbuyeFI9q2YxFmT615hqPe Cvm3hd8a4XTtTJTZzFoWNVJxRl3Xi6q0gXsJ597vnOXtaFqgkhLnnpVCy99x7Qe8 1ax0hwsnxMFX1dojl4/t8bUb0EovI3FMnOCwE+jkXFUzZSFgon/hn1bsXhEoN3DZ xqZ4zeXs1MKJ1/r1Wq8u =4Mid -----END PGP SIGNATURE----- --1fp8NdnLBQOgR6orkQ7CGJgWvDwBrPagT-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 25 23:16:53 2014 Return-Path: Delivered-To: freebsd-current@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 4E6CB3B7; Sat, 25 Jan 2014 23:16:53 +0000 (UTC) Received: from mail-bk0-x235.google.com (mail-bk0-x235.google.com [IPv6:2a00:1450:4008:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A8BE310DE; Sat, 25 Jan 2014 23:16:52 +0000 (UTC) Received: by mail-bk0-f53.google.com with SMTP id my13so2037590bkb.26 for ; Sat, 25 Jan 2014 15:16:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:in-reply-to:references:mime-version:content-type:subject :from:date:to:message-id; bh=CdYccSJxbtMYsFLZzoc0bOE/qt6TDfV3/MDsmLAoN/g=; b=gWt7L+9ccPiPR4MPGVSbocT8rQXxRajvrLeo7HvlOofdKGi8NgxbAsCH6ykhUVHpxI QfWmU09DOPG1jMseiGe/VQqxxZSOQMiUZk/PUssR2i30KKcxBm4r7Km5tvbObpz4sfUH rl+L3bvLW9Emzf46yVSFtfhOIfgqUI1rT/LRYxWW9pEFsFE/lbanBJ6/FK6wJQwuBv0g 5DvV2daEaATiKTAJ+IrtBISxnJcWEO1uakY7+a+OcayeQQVcf9oMbtKE8ZHmXCvY3o2D 7LlbIu9QQ3MCRF9+p0QXpjwnt8DVZfYh6KwVNs33xI1SwwoA0kx7oZBQmt/DM5mxst1g Kyrg== X-Received: by 10.204.118.131 with SMTP id v3mr14623516bkq.30.1390691810977; Sat, 25 Jan 2014 15:16:50 -0800 (PST) Received: from ?IPV6:2001:470:7b2f:0:d02b:d335:23e4:fe54? ([2001:470:7b2f:0:d02b:d335:23e4:fe54]) by mx.google.com with ESMTPSA id bf8sm7818490bkb.14.2014.01.25.15.16.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Jan 2014 15:16:50 -0800 (PST) User-Agent: K-9 Mail for Android In-Reply-To: <52E435A3.6010900@FreeBSD.org> References: <1367fd4d-9128-4df0-a250-fb3c1f67f0c5@email.android.com> <52E42A3A.7000901@FreeBSD.org> <712a6e8d-e34b-4321-8c23-aa9edfe6147f@email.android.com> <52E435A3.6010900@FreeBSD.org> MIME-Version: 1.0 Subject: Re: Newcons radeonkms - Failed to load firmware "radeonkmsfw_TURKS_PFP" From: "Mike C." Date: Sat, 25 Jan 2014 23:16:46 +0000 To: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= , freebsd-current@freebsd.org Message-ID: <1ab937f2-aca2-41d0-a1a7-a7eb232b9c83@email.android.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 23:16:53 -0000 Sure, Btw, I wonder if there's a way to ignore loader.conf at boot? Otherwise I can boot from an install image, just courious tough, would be nice if there a way to do it. I will post the output on the other mailing list "Jean-Sébastien Pédron" wrote: >On 25.01.2014 22:45, Mike C. wrote: >> Worked but I'm still stuck in this case at 'vt_allocate: Replace >existing VT driver.' >> >> a few lines up I see: >> No connectors reported connected with modes. > >Could you please boot without loading the Radeon driver from >loader.conf, and run "kldload radeonkms", then post a full dmesg? > >> should I post to freebsd-x11@FreeBSD.org? > >Yes, this will be more on topic. > >-- >Jean-Sébastien Pédron -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From owner-freebsd-current@FreeBSD.ORG Sat Jan 25 23:57:58 2014 Return-Path: Delivered-To: freebsd-current@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 CA496DAC; Sat, 25 Jan 2014 23:57:58 +0000 (UTC) Received: from mail-gw13.york.ac.uk (mail-gw13.york.ac.uk [144.32.129.163]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7FD64136A; Sat, 25 Jan 2014 23:57:58 +0000 (UTC) Received: from ury.york.ac.uk ([144.32.64.162]:40059) by mail-gw13.york.ac.uk with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1W7D1H-0007yk-AY; Sat, 25 Jan 2014 23:52:11 +0000 Date: Sat, 25 Jan 2014 23:52:11 +0000 (GMT) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: "Lundberg, Johannes" Subject: Re: Install 10.0-RC3 on MacBookPro Late 2013 In-Reply-To: Message-ID: References: <52CA56E5.8030101@bitfrost.no> <52CA6E3F.9000301@bitfrost.no> <52CA7CE0.7070202@bitfrost.no> <52CACBB8.1020905@bitfrost.no> <52CB2591.9050401@bitfrost.no> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-2022-jp X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Hans Petter Selasky , =?GB2312?B?u8bOxLvU?= , Adrian Chadd , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 23:57:59 -0000 On Tue, 7 Jan 2014, Lundberg, Johannes wrote: > I have also experienced random hangs. However, I'm not sure if they are > really hangs or just the USB driver stopped working. Since mouse pad, > keyboard everything is run through USB I couldn't tell really what happened. It seems that the frequency of these hangs depends on the speed of the CPU. With "powerd -a max -b max" the machine can last hours without hanging, with the CPU throttled down the machine can hang within seconds. The MBA at least defaults to a CPU speed midway between minimum and maximum. > Did you have any problems with the identifier of the ssd? When I first > tried FreeBSD on MBA2013 it couldn't identify the ssd because there was > some weird characters in the ssd's identifier. Gavin helped me create a > patch that solved the problem temporary (by hard coding a different ident) > but I'm not sure if a permanent fix has been merged. Yes, mav@ committed the real fix for this in r258683. Thanks, Gavin > -- > Johannes Lundberg > BRILLIANTSERVICE CO., LTD. > > > On Tue, Jan 7, 2014 at 12:05 PM, Huang Wen Hui wrote: > > > USB problem fixed by revert to r245731, > > set "hint.ahci.0.msi=0" seem to fixed timeout problem of AHCI. > > > > Random hang I think still exist, will check later... > > > > Cheers, > > Huang Wen Hui > > > > > > 2014/1/7 Lundberg, Johannes > > > >> Hi Huang > >> > >> Good job!! By "works", which parts do you mean has been fixed? > >> > >> 1. USB problem > >> or > >> 2. AHCI timeout problem > >> or > >> 3. Random hang > >> > >> Best regards! > >> > >> -- > >> Johannes Lundberg > >> BRILLIANTSERVICE CO., LTD. > >> > >> > >> On Tue, Jan 7, 2014 at 11:30 AM, Huang Wen Hui wrote: > >> > >>> Hans, > >>> > >>> This wild guess do NOT works. > >>> I binary sect xhci.c in SVN, found that *r245732 > >>> ** > >>> introduce the bug.* > >>> > >>> > >>> revert to r345731 fixed this USB problem in 9.2R > >>> > >>> I also copy xhci_interrupt(struct xhci_softc *sc) from 9.1R to CURRENT, > >>> CURRENT also works! > >>> > >>> Cheers, > >>> Huang Wen Hui. > >>> > >>> > >>> 2014/1/7 Hans Petter Selasky > >>> > >>> > On 01/06/14 16:28, Hans Petter Selasky wrote: > >>> > > >>> >> On 01/06/14 15:17, Adrian Chadd wrote: > >>> >> > >>> >>> Right, but it used to work. That's the confusing bit. How'd you make > >>> >>> it not work? :) > >>> >>> > >>> >> > >>> >> Binary sect the sys/dev/usb/controller/xhci.c revision history? There > >>> >> has been several bug reports for the Lynx point, and others XHCI > >>> >> chipsets are working just fine. > >>> >> > >>> >> > >>> > A wild guess: > >>> > > >>> > Copy the USB-code from -current. > >>> > > >>> > Add "#if 0" as shown sys/dev/usb/controller/xhci_pci.c > >>> > > >>> > static int > >>> > xhci_pci_port_route(device_t self, uint32_t set, uint32_t clear) > >>> > { > >>> > #if 0 > >>> > uint32_t temp; > >>> > > >>> > temp = pci_read_config(self, PCI_XHCI_INTEL_USB3_PSSEN, 4) | > >>> > pci_read_config(self, PCI_XHCI_INTEL_XUSB2PR, 4); > >>> > > >>> > temp |= set; > >>> > temp &= ~clear; > >>> > > >>> > pci_write_config(self, PCI_XHCI_INTEL_USB3_PSSEN, temp, 4); > >>> > pci_write_config(self, PCI_XHCI_INTEL_XUSB2PR, temp, 4); > >>> > > >>> > device_printf(self, "Port routing mask set to 0x%08x\n", temp); > >>> > #endif > >>> > return (0); > >>> > } > >>> > > >>> > --HPS > >>> > > >>> _______________________________________________ > >>> freebsd-current@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >>> To unsubscribe, send any mail to " > >>> freebsd-current-unsubscribe@freebsd.org" > >>> > >> > >> > >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > >> $BHkL)J];}$K$D$$$F!'$3$NEE;R%a!<%k$O!"L>08?M$KAw?.$7$?$b$N$G$"$j!"HkF?FC8"$NBP>]$H$J$k>pJs$r4^$s$G$$$^$9!#(J > >> $B$b$7!"L>08?M0J30$NJ}$,l9g!"$3$N%a!<%k$NGK4~!"$*$h$S$3$N%a!<%k$K4X$9$k0l@Z$N3+<(!"(J > >> $BJ#$NMxMQ!"$^$?$O5-:\FbMF$K4p$E$/$$$+$J$k9TF0$b$5$l$J$$$h$&$*4j$$?=$7>e$2$^$9!#(J > >> --- > >> CONFIDENTIALITY NOTE: The information in this email is confidential > >> and intended solely for the addressee. > >> Disclosure, copying, distribution or any other action of use of this > >> email by person other than intended recipient, is prohibited. > >> If you are not the intended recipient and have received this email in > >> error, please destroy the original message. > >> > > > > > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > $BHkL)J];}$K$D$$$F!'$3$NEE;R%a!<%k$O!"L>08?M$KAw?.$7$?$b$N$G$"$j!"HkF?FC8"$NBP>]$H$J$k>pJs$r4^$s$G$$$^$9!#(J > $B$b$7!"L>08?M0J30$NJ}$,l9g!"$3$N%a!<%k$NGK4~!"$*$h$S$3$N%a!<%k$K4X$9$k0l@Z$N3+<(!"(J > $BJ#$NMxMQ!"$^$?$O5-:\FbMF$K4p$E$/$$$+$J$k9TF0$b$5$l$J$$$h$&$*4j$$?=$7>e$2$^$9!#(J > --- > CONFIDENTIALITY NOTE: The information in this email is confidential > and intended solely for the addressee. > Disclosure, copying, distribution or any other action of use of this > email by person other than intended recipient, is prohibited. > If you are not the intended recipient and have received this email in > error, please destroy the original message. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >