From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 14 11:46:15 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 40A7C17C for ; Sun, 14 Jul 2013 11:46:15 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm2-vm1.bullet.mail.ird.yahoo.com (nm2-vm1.bullet.mail.ird.yahoo.com [77.238.189.200]) by mx1.freebsd.org (Postfix) with SMTP id 74368E07 for ; Sun, 14 Jul 2013 11:46:13 +0000 (UTC) Received: from [77.238.189.56] by nm2.bullet.mail.ird.yahoo.com with NNFMP; 14 Jul 2013 11:46:12 -0000 Received: from [46.228.39.80] by tm9.bullet.mail.ird.yahoo.com with NNFMP; 14 Jul 2013 11:46:12 -0000 Received: from [127.0.0.1] by smtp117.mail.ir2.yahoo.com with NNFMP; 14 Jul 2013 11:46:12 -0000 X-Yahoo-Newman-Id: 715895.7846.bm@smtp117.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ZzF43IYVM1mXYdFWXBVNfhujYWFkG6.2kP06V3PHHzpXN4s 3td09ckvDbdBCbTyXmYyiFTg.PU7ktz.zvxJLOXftfJBhX1hK3p8oquVuVVk OH9I9oAGae02jTZzpLwwvWudaMPuiOwdhKCzZ2zZinZ_npm_yS0aBvwi1e5h 75kTYBBfG72XeRTnH0GlTgsAF.P_oa7k9Jj_TXXTaoRh0s6O9jgT0JsJGXH. fIydt8.ToLyyg3I49FrlAQ1tfmMEdOTqDBeZe6dq9_Utr566uU9GEddxdwxS MXVpeNnqrqaGo9VGdV21EBzNjZSP4P.dASFx92SVmKRxZgX0lZkcV48eqb13 5fBqXHS6naG0vJjIR8Uz.GcHDjy7VqOD1almBTYRLQCwKB26Q2Pmkh9MC9Oi 38skfmvZeS4Zgpwyczieqh5R48p9K5.WmE2nbT_fZzCA4TBiaspo85FgugML joc9yrt9YSKjCePBZz6y68T_wxnjuLndfLZci6ugY0gjWqSo6IzqEnx3.2D6 O X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. X-Rocket-Received: from [192.168.119.26] (se@87.158.21.37 with ) by smtp117.mail.ir2.yahoo.com with SMTP; 14 Jul 2013 11:46:12 +0000 UTC Message-ID: <51E28F7B.7090303@freebsd.org> Date: Sun, 14 Jul 2013 13:46:03 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: linnemannr@gmail.com Subject: Re: Attempting to roll back zfs transactions on a disk to recover a destroyed ZFS filesystem References: <51DFF79C.905@gmail.com> In-Reply-To: <51DFF79C.905@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 11:46:15 -0000 Am 12.07.2013 14:33, schrieb Volodymyr Kostyrko: > You can try to experiment with zpool hidden flags. Look at this command: > > zpool import -N -o readonly=on -f -R /pool > > It will try to import pool in readonly mode so no data would be written > on it. It also doesn't mount anything on import so if any fs is damaged > you have less chances triggering a coredump. Also zpool import has a > hidden -T switch that gives you ability to select transaction that you > want to try to restore. You'll need a list of available transaction though: > > zdb -ul > > This one when given a vdev lists all uberblocks with their respective > transaction ids. You can take the highest one (it's not the last one) > and try to mount pool with: > > zpool import -N -o readonly=on -f -R /pool -F -T I had good luck with ZFS recovery with the following approach: 1) Use zdb to identify a TXG for which the data structures are intact 2) Select recovery mode by loading the ZFS KLD with "vfs.zfs.recover=1" set in /boot/loader.conf 3) Import the pool with the above -T option referring to a suitable TXG found with the help zdb. The zdb commands to use are: # zdb -AAA -L -t -bcdmu (Both -AAA and -L reduce the amount of consistency checking performed. A pool (at TXG) that needs these options to allow zdb to succeed is damaged, but may still allow recovery of most or all files. Be sure to only import that pool R/O, or your data will probably be lost!) A list of TXGs to try can be retrieved with "zdb -hh ". You may need to add "-e" to the list of zdb options, since the port is exported / not currently mounted). Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 14 12:10:19 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4F76159C for ; Sun, 14 Jul 2013 12:10:19 +0000 (UTC) (envelope-from bryan-lists@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id E6D0AEE0 for ; Sun, 14 Jul 2013 12:10:18 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=sweb; b=FW3T4z92pGSnqDWy++f WoSGrmTSxRVryVPvvavygL9cgPZ0R8orDlPtXhNrduAeVj6onSzCSF6h7ejjgf8D UTm2GJnAe8M6z4D5VrFupK322Eukm7seqJwDYFce9F6lCBnFTljd8WznA+KWZLKd YBV4IS3YbnVDt3hBF6BACxeQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=sweb; bh=Hu08+QviH0Gwzwbfqn94oor10 0KeiKrcC5swMx9Ni/E=; b=WYv/RRICCqplRnHTDFBz5uOplA5cwqx5oHLb7Kq++ 0avqUkY/IX/ppJD93sSo8u0QpVzqtUJPUtP5GRGjSgCpp9aBIFDL23v7z/+I5Iax ZhD4IsTTZQPUHdFnFkkAsxlvi2GXvwMJsgrwxA0gMJd+3lnC4sroUAhAW5xgFtzh 6Q= Received: (qmail 55743 invoked from network); 14 Jul 2013 07:10:11 -0500 Received: from unknown (HELO ?10.10.0.24?) (bryan@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 14 Jul 2013 07:10:11 -0500 Message-ID: <51E29522.1010803@shatow.net> Date: Sun, 14 Jul 2013 07:10:10 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: FreeBSD Hackers Subject: make installworld: btxld: No such file or directory [solved] X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 12:10:19 -0000 This post is just to inform others that run into this problem. For years I have ran into this error while running 'make installworld': > # make installworld > [...] > ===> sys/boot/i386/boot2 (install) > /usr/local/libexec/ccache/world/cc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mregparm=3 -DUSE_XREAD -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/boot2/../../common -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -march=i386 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -std=gnu99 -S -o boot2.s.tmp /usr/src/sys/boot/i386/boot2/boot2.c > sed -e '/align/d' -e '/nop/d' < boot2.s.tmp > boot2.s > rm -f boot2.s.tmp > /usr/local/libexec/ccache/world/cc -m32 -c boot2.s > ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x2000 -o boot2.out /usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o > objcopy -S -O binary boot2.out boot2.bin > btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin > btxld: No such file or directory > *** [boot2.ld] Error code 1 > > Stop in /usr/src/sys/boot/i386/boot2. > *** [realinstall] Error code 1 > There's several other mailing list posts that insist that build orders are wrong or that the date/time is incorrect or off. I always had strictly followed buildworld/installworld all while running ntpd. My workaround was to 'make -C /usr/src/sys/boot/i386' before installworld to avoid this issue, as others have done as well. I realized this time that I was applying local patches to the tree before buildworld, then reverting the patches before installworld. This changed timestamps of various source files that forced the rebuild during installworld. The real solution was to not revert the files until after installworld and to not change the source tree in any other way between buildworld/installworld. Cheers, Bryan Drewery From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 14 16:58:55 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 38F8279C; Sun, 14 Jul 2013 16:58:55 +0000 (UTC) (envelope-from robertames@hotmail.com) Received: from blu0-omc3-s21.blu0.hotmail.com (blu0-omc3-s21.blu0.hotmail.com [65.55.116.96]) by mx1.freebsd.org (Postfix) with ESMTP id 0A27096F; Sun, 14 Jul 2013 16:58:54 +0000 (UTC) Received: from BLU177-W33 ([65.55.116.74]) by blu0-omc3-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 14 Jul 2013 09:58:47 -0700 X-TMN: [az5R9k9ZrJOUAEX+8NOKtPYFu50f23Mv] X-Originating-Email: [robertames@hotmail.com] Message-ID: From: Robert Ames To: John Baldwin , "freebsd-hackers@freebsd.org" Subject: RE: Intel D2500CC serial ports Date: Sun, 14 Jul 2013 12:58:47 -0400 Importance: Normal In-Reply-To: <201307111014.42903.jhb@freebsd.org> References: , <201307111014.42903.jhb@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Jul 2013 16:58:47.0967 (UTC) FILETIME=[686B0AF0:01CE80B3] X-Mailman-Approved-At: Sun, 14 Jul 2013 21:10:28 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 16:58:55 -0000 > From: jhb@freebsd.org=0A= > To: freebsd-hackers@freebsd.org=0A= > Subject: Re: Intel D2500CC serial ports=0A= > Date: Thu=2C 11 Jul 2013 10:14:42 -0400=0A= > CC: robertames@hotmail.com=0A= > =0A= > On Sunday=2C June 30=2C 2013 1:24:27 pm Robert Ames wrote:=0A= >> I just picked up an Intel D2500CCE motherboard and was disappointed=0A= >> to find the serial ports didn't work. There has been discussion=0A= >> about this problem here:=0A= >> =0A= >> http://lists.freebsd.org/pipermail/freebsd-current/2013-April/040897.htm= l=0A= >> http://lists.freebsd.org/pipermail/freebsd-current/2013-May/042088.html= =0A= >> =0A= >> As seen in the second link=2C Juergen Weiss was able to work around=0A= >> the problem. This patch (for 8.4-RELEASE amd64) makes all 4 serial=0A= >> ports functional.=0A= >> =0A= >> --- /usr/src/sys/amd64/amd64/io_apic.c.orig 2013-06-02 13:23:05.00000000= 0 -0500=0A= >> +++ /usr/src/sys/amd64/amd64/io_apic.c 2013-06-28 18:52:03.00000000= 0 -0500=0A= >> @@ -452=2C6 +452=2C10 @@=0A= >> KASSERT(!(trig =3D=3D INTR_TRIGGER_CONFORM || pol =3D=3D INTR_PO= LARITY_CONFORM)=2C=0A= >> ("%s: Conforming trigger or polarity\n"=2C __func__))=3B=0A= >> =0A= >> + if (trig =3D=3D INTR_TRIGGER_EDGE && pol =3D=3D INTR_POLARITY_LO= W) {=0A= >> + pol =3D INTR_POLARITY_HIGH=3B=0A= >> + }=0A= >> +=0A= > =0A= > Hmm=2C so this is your BIOS doing the wrong thing in its ASL.=0A= > =0A= > Maybe try this:=0A= > =0A= > --- //depot/user/jhb/acpipci/dev/acpica/acpi_resource.c 2011-07-22 17:59:= 31.000000000 0000=0A= > +++ /home/jhb/work/p4/acpipci/dev/acpica/acpi_resource.c 2011-07-22 17:59= :31.000000000 0000=0A= > @@ -141=2C6 +141=2C10 @@=0A= > default:=0A= > panic("%s: bad resource type %u"=2C __func__=2C res->Type)=3B=0A= > }=0A= > +#if defined(__amd64__) || defined(__i386__)=0A= > + if (irq < 16 && trig =3D=3D ACPI_EDGE_SENSITIVE && pol =3D=3D ACPI_A= CTIVE_LOW)=0A= > + pol =3D ACPI_ACTIVE_HIGH=3B=0A= > +#endif=0A= > BUS_CONFIG_INTR(dev=2C irq=2C (trig =3D=3D ACPI_EDGE_SENSITIVE) ?=0A= > INTR_TRIGGER_EDGE : INTR_TRIGGER_LEVEL=2C (pol =3D=3D ACPI_ACTIVE_HIGH)= ?=0A= > INTR_POLARITY_HIGH : INTR_POLARITY_LOW)=3B=0A= > =0A= > -- =0A= > John Baldwin=0A= =0A= Yes=2C this patch works too.=A0 All 4 serial ports are functional.=A0 Is=0A= this something that could be committed so that the serial ports on=0A= this board work out of the box on future releases?=0A= =0A= And for what it's worth=2C I seem to be running the latest BIOS=0A= identified as: CCCDT10N.86A.0039.2013.0425.1625 = From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 15 00:51:22 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F335AC66; Mon, 15 Jul 2013 00:51:21 +0000 (UTC) (envelope-from torek@torek.net) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) by mx1.freebsd.org (Postfix) with ESMTP id CD826B83; Mon, 15 Jul 2013 00:51:21 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id r6F0pEKj032863; Sun, 14 Jul 2013 18:51:14 -0600 (MDT) (envelope-from torek@torek.net) Message-Id: <201307150051.r6F0pEKj032863@elf.torek.net> From: Chris Torek To: Neel Natu Subject: Re: expanding amd64 past the 1TB limit In-reply-to: Your message of "Thu, 11 Jul 2013 00:41:38 -0700." Date: Sun, 14 Jul 2013 18:51:14 -0600 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Sun, 14 Jul 2013 18:51:14 -0600 (MDT) Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, kib@freebsd.org, alc@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 00:51:22 -0000 >The changes associated with pt_p, pd_p and p4_p are cosmetic and IMHO >detract from the meat of the change. > >My preference would be for the cosmetic changes to be committed >separately from the changes that rearrange the KVA. I can split these out. >> - DMPDPphys = allocpages(firstaddr, NDMPML4E); >> + ndmpdpphys = howmany(ndmpdp, NPML4EPG); > >NPDPEPG should be used here instead of NPML4EPG even though they are >numerically identical. Ah, late-night editing thinko. :-) >> + * KERNBASE. Similarly, if KMPL4I < (base+N), extra level 4 PDEs are > >level 2 PDE's, right? Er, yes (and L1s of course), and that should be < (base+N-1). The idea here is that if for some reason KERNBASE were "in the middle" of the NKPML4E entries, you'd have, at least initially when only a few things are valid at VM_MIN_ADDRESS and at KERNBASE: L4 table L3 page ... mapping: +-------+ VM_MIN_KERNEL_ADDRESS KPMLBASE | * ---> [valid at 0 --> L2, then all-0s] +-------+ | * ---> [all-0s] +-------+ | * ---> [all-0s] +-------+ | ... | +-------+ KERNBASE KPML4I | * ---> [mostly-0s; the KDPDI'th --> L2] +-------+ base+N-1 | * ---> [all-0s] +-------+ VM_MAX_KERNEL_ADDRESS but then eventually allocating something between KERNBASE and VM_MAX_KERNEL_ADDRESS would cause that last page of "all-0s" to get filled in, etc. Of course KPML4I should be the very last (511'th) L4 table entry always, unless the kernel grows really huge :-) I'll fix the comments in the split-up patch. Chris From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 15 02:05:47 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AEF3AD76; Mon, 15 Jul 2013 02:05:47 +0000 (UTC) (envelope-from torek@torek.net) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) by mx1.freebsd.org (Postfix) with ESMTP id 620E4ECC; Mon, 15 Jul 2013 02:05:46 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id r6F25kWM033189; Sun, 14 Jul 2013 20:05:46 -0600 (MDT) (envelope-from torek@torek.net) Message-Id: <201307150205.r6F25kWM033189@elf.torek.net> From: Chris Torek To: Neel Natu Subject: Re: expanding amd64 past the 1TB limit In-reply-to: Your message of "Thu, 11 Jul 2013 00:41:38 -0700." MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <33186.1373853912.0@elf.torek.net> Date: Sun, 14 Jul 2013 20:05:46 -0600 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Sun, 14 Jul 2013 20:05:46 -0600 (MDT) X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, kib@freebsd.org, alc@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 02:05:47 -0000 ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <33186.1373853912.1@elf.torek.net> Here's the split-up version with the additional comment corrections. Chris ------- =_aaaaaaaaaa0-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 15 05:50:11 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A0B8AB30 for ; Mon, 15 Jul 2013 05:50:11 +0000 (UTC) (envelope-from selphie.keller@gmail.com) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id 406729DC for ; Mon, 15 Jul 2013 05:50:11 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id w56so9517802wes.25 for ; Sun, 14 Jul 2013 22:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=oUVZpJfWZI2GgbpTJHiGA+ghtWHvfjXES8eYMo19lDE=; b=J9hCvg7i6e3uWBwj9OOTtQclyRcsoq3H3qqPpfRrzPEtGKl1Sbzj8e/2RYC2G0oNBC OSRQQPcXIbIY6o0kAZbvIUDRx6scfNlRDOLaqfHoj5EeffYW21ygmkHMyaQQv+UL+Y4f N/SxNhhcfU12M4vYYpLZiOZOD6kMKnCjSorgKpk8lIe2JNbENH6rlZ7i7A3HAXkP+qoj xCbAoE7TiL7zwDHfs7LHpMhtVMHQY/naMW1/U5XgmF9tec7lCosQlBfKY7vW5pa2uqIp xC1JEewPtqkxpSsBMfTd0HRowF5tgBM3eo7zteLC53bMIsHFJc6/FC3OJhPk/bCBQByi JaTg== MIME-Version: 1.0 X-Received: by 10.194.8.163 with SMTP id s3mr30816807wja.41.1373867410195; Sun, 14 Jul 2013 22:50:10 -0700 (PDT) Received: by 10.216.170.5 with HTTP; Sun, 14 Jul 2013 22:50:10 -0700 (PDT) Date: Sun, 14 Jul 2013 22:50:10 -0700 Message-ID: Subject: GPT issues with device path lengths involving make_dev_physpath_alias From: Selphie Keller To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 05:50:11 -0000 hello hackers, I recently ran into a issue with a storage server that has some of the drives in gpt vs mbr, tracked it down to a 64 char limit that is preventing aliases in function make_dev_physpath_alias. I was curious if there was any reason why this couldn't be bumped from 64 to 128 which would make room for the device paths of gpt roughly around 94 and 96 chars long. - #define SPECNAMELEN 63 */* max length of devicename */ + *#define SPECNAMELEN 127 */* max length of devicename */* http://fxr.watson.org/fxr/source/sys/param.h#L106 Jul 14 22:10:17 fbsd9 kernel: make_dev_physpath_alias: WARNING - Unable to alias gptid/4d177c56-ce17-26e3-843e-9c8a9faf1e0f to enc@n5003048000ba7d7d /type@0/slot@b/elmdesc@Slot_11/gptid/4d177c56-ce17-26e3-843e-9c8a9faf1e0f - path too long Jul 14 22:10:17 fbsd9 kernel: make_dev_physpath_alias: WARNING - Unable to alias gptid/4b1caf38-d967-24ee-c3a0-badff404e7ed to enc@n5003048000ba7d7d /type@0/slot@5/elmdesc@Slot_05/gptid/4b1caf38-d967-24ee-c3a0-badff404e7ed - path too long -Selphie (Estella Mystagic) From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 15 07:22:35 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AC27A5D9 for ; Mon, 15 Jul 2013 07:22:35 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 9AD9CD05 for ; Mon, 15 Jul 2013 07:22:35 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r6F7MS6P005288 for ; Mon, 15 Jul 2013 00:22:28 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <51E3A334.8020203@rawbw.com> Date: Mon, 15 Jul 2013 00:22:28 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Subject: Kernel crashes after sleep: how to debug? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 07:22:35 -0000 After sleep/wakeup cycle my 9.1-STABLE r253105 amd64 system has a tendency to sometimes randomly crash after a while. It doesn't happen every time. See kgdb log below. I am not sure there is enough information to lead to the cause of the issue. It looks like it crashes near the line: #7 0xffffffff8091a181 in _mtx_trylock (m=0x100000000, opts=0, file=, line=0) at /usr/src/sys/kern/kern_mutex.c:295 295 if (SCHEDULER_STOPPED()) Current language: auto; currently c (kgdb) l 290 uint64_t waittime = 0; 291 int contested = 0; 292 #endif 293 int rval; 294 295 if (SCHEDULER_STOPPED()) 296 return (1); 297 298 KASSERT(m->mtx_lock != MTX_DESTROYED, 299 ("mtx_trylock() of destroyed mutex @ %s:%d", file, line)); Current thread was: * 67 Thread 100064 (PID=5: pagedaemon) doadump (textdump=) at pcpu.h:234 How to find the cause of the crash? Yuri --- kgdb log --- # kgdb /boot/kernel/kernel vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x100000018 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8091a181 stack pointer = 0x28:0xffffff80d51c6ab0 frame pointer = 0x28:0xffffff80d51c6ad0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 5 (pagedaemon) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xffffffff80968416 at kdb_backtrace+0x66 #1 0xffffffff8092e43e at panic+0x1ce #2 0xffffffff80d12940 at trap_fatal+0x290 #3 0xffffffff80d12ca1 at trap_pfault+0x211 #4 0xffffffff80d13254 at trap+0x344 #5 0xffffffff80cfc583 at calltrap+0x8 #6 0xffffffff80baea78 at vm_pageout+0x998 #7 0xffffffff808fc10f at fork_exit+0x11f #8 0xffffffff80cfcaae at fork_trampoline+0xe Uptime: 2h21m27s Dumping 407 out of 2919 MB:..4%..12%..24%..32%..44%..52%..63%..71%..83%..91% Reading symbols from /boot/modules/cuse4bsd.ko...done. Loaded symbols for /boot/modules/cuse4bsd.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /usr/local/libexec/linux_adobe/linux_adobe.ko...done. Loaded symbols for /usr/local/libexec/linux_adobe/linux_adobe.ko Reading symbols from /boot/kernel/radeon.ko...Reading symbols from /boot/kernel/radeon.ko.symbols...done. done. Loaded symbols for /boot/kernel/radeon.ko Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kernel/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko #0 doadump (textdump=) at pcpu.h:234 234 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump (textdump=) at pcpu.h:234 #1 0xffffffff8092df16 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0xffffffff8092e417 in panic (fmt=0x1
) at /usr/src/sys/kern/kern_shutdown.c:637 #3 0xffffffff80d12940 in trap_fatal (frame=0xc, eva=) at /usr/src/sys/amd64/amd64/trap.c:879 #4 0xffffffff80d12ca1 in trap_pfault (frame=0xffffff80d51c6a00, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:795 #5 0xffffffff80d13254 in trap (frame=0xffffff80d51c6a00) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0xffffffff80cfc583 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #7 0xffffffff8091a181 in _mtx_trylock (m=0x100000000, opts=0, file=, line=0) at /usr/src/sys/kern/kern_mutex.c:295 #8 0xffffffff80baea78 in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:829 #9 0xffffffff808fc10f in fork_exit (callout=0xffffffff80bae0e0 , arg=0x0, frame=0xffffff80d51c6c40) at /usr/src/sys/kern/kern_fork.c:988 #10 0xffffffff80cfcaae in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:606 #11 0x0000000000000000 in ?? () From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 15 07:36:11 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B16BCA82 for ; Mon, 15 Jul 2013 07:36:11 +0000 (UTC) (envelope-from torek@torek.net) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) by mx1.freebsd.org (Postfix) with ESMTP id 7D790DA7 for ; Mon, 15 Jul 2013 07:36:11 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id r6F7aAmR039943 for ; Mon, 15 Jul 2013 01:36:10 -0600 (MDT) (envelope-from torek@torek.net) Message-Id: <201307150736.r6F7aAmR039943@elf.torek.net> From: Chris Torek To: freebsd-hackers@freebsd.org Subject: Re: expanding amd64 past the 1TB limit In-reply-to: Your message of "Thu, 11 Jul 2013 00:41:38 -0700." Date: Mon, 15 Jul 2013 01:36:10 -0600 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Mon, 15 Jul 2013 01:36:10 -0600 (MDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 07:36:11 -0000 (Durn mailing list software, eating attachments... there are just the two so I will just send them one at a time here. I took the individual people off the to/cc since presumably you all got the attachments already.) Date: Sun, 14 Jul 2013 19:39:51 -0600 Subject: [PATCH 1/2] create_pagetables: cosmetics Using local variables with the appropriate types, eliminate a bunch of casts and shorten the code a bit. --- amd64/amd64/pmap.c | 62 +++++++++++++++++++++++++++--------------------------- 1 file changed, 31 insertions(+), 31 deletions(-) diff --git a/amd64/amd64/pmap.c b/amd64/amd64/pmap.c index 8dcf232..46f6940 100644 --- a/amd64/amd64/pmap.c +++ b/amd64/amd64/pmap.c @@ -531,6 +531,10 @@ static void create_pagetables(vm_paddr_t *firstaddr) { int i, j, ndm1g, nkpdpe; + pt_entry_t *pt_p; + pd_entry_t *pd_p; + pdp_entry_t *pdp_p; + pml4_entry_t *p4_p; /* Allocate page table pages for the direct map */ ndmpdp = (ptoa(Maxmem) + NBPDP - 1) >> PDPSHIFT; @@ -561,32 +565,26 @@ create_pagetables(vm_paddr_t *firstaddr) KPDphys = allocpages(firstaddr, nkpdpe); /* Fill in the underlying page table pages */ - /* Read-only from zero to physfree */ + /* Nominally read-only (but really R/W) from zero to physfree */ /* XXX not fully used, underneath 2M pages */ - for (i = 0; (i << PAGE_SHIFT) < *firstaddr; i++) { - ((pt_entry_t *)KPTphys)[i] = i << PAGE_SHIFT; - ((pt_entry_t *)KPTphys)[i] |= PG_RW | PG_V | PG_G; - } + pt_p = (pt_entry_t *)KPTphys; + for (i = 0; ptoa(i) < *firstaddr; i++) + pt_p[i] = ptoa(i) | PG_RW | PG_V | PG_G; /* Now map the page tables at their location within PTmap */ - for (i = 0; i < nkpt; i++) { - ((pd_entry_t *)KPDphys)[i] = KPTphys + (i << PAGE_SHIFT); - ((pd_entry_t *)KPDphys)[i] |= PG_RW | PG_V; - } + pd_p = (pd_entry_t *)KPDphys; + for (i = 0; i < nkpt; i++) + pd_p[i] = (KPTphys + ptoa(i)) | PG_RW | PG_V; /* Map from zero to end of allocations under 2M pages */ /* This replaces some of the KPTphys entries above */ - for (i = 0; (i << PDRSHIFT) < *firstaddr; i++) { - ((pd_entry_t *)KPDphys)[i] = i << PDRSHIFT; - ((pd_entry_t *)KPDphys)[i] |= PG_RW | PG_V | PG_PS | PG_G; - } + for (i = 0; (i << PDRSHIFT) < *firstaddr; i++) + pd_p[i] = (i << PDRSHIFT) | PG_RW | PG_V | PG_PS | PG_G; /* And connect up the PD to the PDP */ - for (i = 0; i < nkpdpe; i++) { - ((pdp_entry_t *)KPDPphys)[i + KPDPI] = KPDphys + - (i << PAGE_SHIFT); - ((pdp_entry_t *)KPDPphys)[i + KPDPI] |= PG_RW | PG_V | PG_U; - } + pdp_p = (pdp_entry_t *)KPDPphys; + for (i = 0; i < nkpdpe; i++) + pdp_p[i + KPDPI] = (KPDphys + ptoa(i)) | PG_RW | PG_V | PG_U; /* * Now, set up the direct map region using 2MB and/or 1GB pages. If @@ -596,37 +594,39 @@ create_pagetables(vm_paddr_t *firstaddr) * memory, pmap_change_attr() will demote any 2MB or 1GB page mappings * that are partially used. */ + pd_p = (pd_entry_t *)DMPDphys; for (i = NPDEPG * ndm1g, j = 0; i < NPDEPG * ndmpdp; i++, j++) { - ((pd_entry_t *)DMPDphys)[j] = (vm_paddr_t)i << PDRSHIFT; + pd_p[j] = (vm_paddr_t)i << PDRSHIFT; /* Preset PG_M and PG_A because demotion expects it. */ - ((pd_entry_t *)DMPDphys)[j] |= PG_RW | PG_V | PG_PS | PG_G | + pd_p[j] |= PG_RW | PG_V | PG_PS | PG_G | PG_M | PG_A; } + pdp_p = (pdp_entry_t *)DMPDPphys; for (i = 0; i < ndm1g; i++) { - ((pdp_entry_t *)DMPDPphys)[i] = (vm_paddr_t)i << PDPSHIFT; + pdp_p[i] = (vm_paddr_t)i << PDPSHIFT; /* Preset PG_M and PG_A because demotion expects it. */ - ((pdp_entry_t *)DMPDPphys)[i] |= PG_RW | PG_V | PG_PS | PG_G | + pdp_p[i] |= PG_RW | PG_V | PG_PS | PG_G | PG_M | PG_A; } for (j = 0; i < ndmpdp; i++, j++) { - ((pdp_entry_t *)DMPDPphys)[i] = DMPDphys + (j << PAGE_SHIFT); - ((pdp_entry_t *)DMPDPphys)[i] |= PG_RW | PG_V | PG_U; + pdp_p[i] = DMPDphys + ptoa(j); + pdp_p[i] |= PG_RW | PG_V | PG_U; } /* And recursively map PML4 to itself in order to get PTmap */ - ((pdp_entry_t *)KPML4phys)[PML4PML4I] = KPML4phys; - ((pdp_entry_t *)KPML4phys)[PML4PML4I] |= PG_RW | PG_V | PG_U; + p4_p = (pml4_entry_t *)KPML4phys; + p4_p[PML4PML4I] = KPML4phys; + p4_p[PML4PML4I] |= PG_RW | PG_V | PG_U; /* Connect the Direct Map slot(s) up to the PML4. */ for (i = 0; i < NDMPML4E; i++) { - ((pdp_entry_t *)KPML4phys)[DMPML4I + i] = DMPDPphys + - (i << PAGE_SHIFT); - ((pdp_entry_t *)KPML4phys)[DMPML4I + i] |= PG_RW | PG_V | PG_U; + p4_p[DMPML4I + i] = DMPDPphys + ptoa(i); + p4_p[DMPML4I + i] |= PG_RW | PG_V | PG_U; } /* Connect the KVA slot up to the PML4 */ - ((pdp_entry_t *)KPML4phys)[KPML4I] = KPDPphys; - ((pdp_entry_t *)KPML4phys)[KPML4I] |= PG_RW | PG_V | PG_U; + p4_p[KPML4I] = KPDPphys; + p4_p[KPML4I] |= PG_RW | PG_V | PG_U; } /* -- 1.8.2.1 From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 15 07:36:50 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 730F2B6E for ; Mon, 15 Jul 2013 07:36:50 +0000 (UTC) (envelope-from torek@torek.net) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) by mx1.freebsd.org (Postfix) with ESMTP id 4BCC4DB3 for ; Mon, 15 Jul 2013 07:36:50 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id r6F7aoaw039955 for ; Mon, 15 Jul 2013 01:36:50 -0600 (MDT) (envelope-from torek@torek.net) Message-Id: <201307150736.r6F7aoaw039955@elf.torek.net> From: Chris Torek To: freebsd-hackers@freebsd.org Subject: Re: expanding amd64 past the 1TB limit In-reply-to: Your message of "Thu, 11 Jul 2013 00:41:38 -0700." Date: Mon, 15 Jul 2013 01:36:50 -0600 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Mon, 15 Jul 2013 01:36:50 -0600 (MDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 07:36:50 -0000 (Durn mailing list software, eating attachments... there are just the two so I will just send them one at a time here. I took the individual people off the to/cc since presumably you all got the attachments already.) Date: Thu, 27 Jun 2013 18:49:29 -0600 Subject: [PATCH 2/2] increase physical and virtual memory limits Increase kernel VM space: go from .5 TB of KVA and 1 TB of direct map, to 8 TB of KVA and 16 TB of direct map. However, we allocate less direct map space for small physical-memory systems. Also, if Maxmem is so large that there is not enough direct map space, reduce Maxmem to fit, so that the system can boot unassisted. --- amd64/amd64/pmap.c | 44 +++++++++++++++++++++++++++++++++----------- amd64/include/pmap.h | 36 +++++++++++++++++++++++++++++------- amd64/include/vmparam.h | 13 +++++++------ 3 files changed, 69 insertions(+), 24 deletions(-) diff --git a/amd64/amd64/pmap.c b/amd64/amd64/pmap.c index 46f6940..5e43c93 100644 --- a/amd64/amd64/pmap.c +++ b/amd64/amd64/pmap.c @@ -232,6 +232,7 @@ u_int64_t KPML4phys; /* phys addr of kernel level 4 */ static u_int64_t DMPDphys; /* phys addr of direct mapped level 2 */ static u_int64_t DMPDPphys; /* phys addr of direct mapped level 3 */ +static int ndmpdpphys; /* number of DMPDPphys pages */ static struct rwlock_padalign pvh_global_lock; @@ -540,7 +541,18 @@ create_pagetables(vm_paddr_t *firstaddr) ndmpdp = (ptoa(Maxmem) + NBPDP - 1) >> PDPSHIFT; if (ndmpdp < 4) /* Minimum 4GB of dirmap */ ndmpdp = 4; - DMPDPphys = allocpages(firstaddr, NDMPML4E); + ndmpdpphys = howmany(ndmpdp, NPDPEPG); + if (ndmpdpphys > NDMPML4E) { + /* + * Each NDMPML4E allows 512 GB, so limit to that, + * and then readjust ndmpdp and ndmpdpphys. + */ + printf("NDMPML4E limits system to %d GB\n", NDMPML4E * 512); + Maxmem = atop(NDMPML4E * NBPML4); + ndmpdpphys = NDMPML4E; + ndmpdp = NDMPML4E * NPDEPG; + } + DMPDPphys = allocpages(firstaddr, ndmpdpphys); ndm1g = 0; if ((amd_feature & AMDID_PAGE1GB) != 0) ndm1g = ptoa(Maxmem) >> PDPSHIFT; @@ -557,6 +569,10 @@ create_pagetables(vm_paddr_t *firstaddr) * bootstrap. We defer this until after all memory-size dependent * allocations are done (e.g. direct map), so that we don't have to * build in too much slop in our estimate. + * + * Note that when NKPML4E > 1, we have an empty page underneath + * all but the KPML4I'th one, so we need NKPML4E-1 extra (zeroed) + * pages. (pmap_enter requires a PD page to exist for each KPML4E.) */ nkpt_init(*firstaddr); nkpdpe = NKPDPE(nkpt); @@ -581,8 +597,8 @@ create_pagetables(vm_paddr_t *firstaddr) for (i = 0; (i << PDRSHIFT) < *firstaddr; i++) pd_p[i] = (i << PDRSHIFT) | PG_RW | PG_V | PG_PS | PG_G; - /* And connect up the PD to the PDP */ - pdp_p = (pdp_entry_t *)KPDPphys; + /* And connect up the PD to the PDP (leaving room for L4 pages) */ + pdp_p = (pdp_entry_t *)(KPDPphys + ptoa(KPML4I - KPML4BASE)); for (i = 0; i < nkpdpe; i++) pdp_p[i + KPDPI] = (KPDphys + ptoa(i)) | PG_RW | PG_V | PG_U; @@ -619,14 +635,16 @@ create_pagetables(vm_paddr_t *firstaddr) p4_p[PML4PML4I] |= PG_RW | PG_V | PG_U; /* Connect the Direct Map slot(s) up to the PML4. */ - for (i = 0; i < NDMPML4E; i++) { + for (i = 0; i < ndmpdpphys; i++) { p4_p[DMPML4I + i] = DMPDPphys + ptoa(i); p4_p[DMPML4I + i] |= PG_RW | PG_V | PG_U; } - /* Connect the KVA slot up to the PML4 */ - p4_p[KPML4I] = KPDPphys; - p4_p[KPML4I] |= PG_RW | PG_V | PG_U; + /* Connect the KVA slots up to the PML4 */ + for (i = 0; i < NKPML4E; i++) { + p4_p[KPML4BASE + i] = KPDPphys + ptoa(i); + p4_p[KPML4BASE + i] |= PG_RW | PG_V | PG_U; + } } /* @@ -1685,8 +1703,11 @@ pmap_pinit(pmap_t pmap) pagezero(pmap->pm_pml4); /* Wire in kernel global address entries. */ - pmap->pm_pml4[KPML4I] = KPDPphys | PG_RW | PG_V | PG_U; - for (i = 0; i < NDMPML4E; i++) { + for (i = 0; i < NKPML4E; i++) { + pmap->pm_pml4[KPML4BASE + i] = (KPDPphys + (i << PAGE_SHIFT)) | + PG_RW | PG_V | PG_U; + } + for (i = 0; i < ndmpdpphys; i++) { pmap->pm_pml4[DMPML4I + i] = (DMPDPphys + (i << PAGE_SHIFT)) | PG_RW | PG_V | PG_U; } @@ -1941,8 +1962,9 @@ pmap_release(pmap_t pmap) m = PHYS_TO_VM_PAGE(pmap->pm_pml4[PML4PML4I] & PG_FRAME); - pmap->pm_pml4[KPML4I] = 0; /* KVA */ - for (i = 0; i < NDMPML4E; i++) /* Direct Map */ + for (i = 0; i < NKPML4E; i++) /* KVA */ + pmap->pm_pml4[KPML4BASE + i] = 0; + for (i = 0; i < ndmpdpphys; i++)/* Direct Map */ pmap->pm_pml4[DMPML4I + i] = 0; pmap->pm_pml4[PML4PML4I] = 0; /* Recursive Mapping */ diff --git a/amd64/include/pmap.h b/amd64/include/pmap.h index dc02e49..eda0295 100644 --- a/amd64/include/pmap.h +++ b/amd64/include/pmap.h @@ -113,28 +113,50 @@ ((unsigned long)(l2) << PDRSHIFT) | \ ((unsigned long)(l1) << PAGE_SHIFT)) -#define NKPML4E 1 /* number of kernel PML4 slots */ +/* + * Number of kernel PML4 slots. Can be anywhere from 1 to 64 or so, + * but setting it larger than NDMPML4E makes no sense. + * + * Each slot provides .5 TB of kernel virtual space. + */ +#define NKPML4E 16 #define NUPML4E (NPML4EPG/2) /* number of userland PML4 pages */ #define NUPDPE (NUPML4E*NPDPEPG)/* number of userland PDP pages */ #define NUPDE (NUPDPE*NPDEPG) /* number of userland PD entries */ /* - * NDMPML4E is the number of PML4 entries that are used to implement the - * direct map. It must be a power of two. + * NDMPML4E is the maximum number of PML4 entries that will be + * used to implement the direct map. It must be a power of two, + * and should generally exceed NKPML4E. The maximum possible + * value is 64; using 128 will make the direct map intrude into + * the recursive page table map. */ -#define NDMPML4E 2 +#define NDMPML4E 32 /* - * The *PDI values control the layout of virtual memory. The starting address + * These values control the layout of virtual memory. The starting address * of the direct map, which is controlled by DMPML4I, must be a multiple of * its size. (See the PHYS_TO_DMAP() and DMAP_TO_PHYS() macros.) + * + * Note: KPML4I is the index of the (single) level 4 page that maps + * the KVA that holds KERNBASE, while KPML4BASE is the index of the + * first level 4 page that maps VM_MIN_KERNEL_ADDRESS. If NKPML4E + * is 1, these are the same, otherwise KPML4BASE < KPML4I and extra + * level 4 PDEs are needed to map from VM_MIN_KERNEL_ADDRESS up to + * KERNBASE. Similarly, if KMPL4I < (base+N-1), extra level 2 PDEs are + * needed to map from somewhere-above-KERNBASE to VM_MAX_KERNEL_ADDRESS. + * + * (KPML4I combines with KPDPI to choose where KERNBASE starts. + * Or, in other words, KPML4I provides bits 39..46 of KERNBASE, + * and KPDPI provides bits 30..38.) */ #define PML4PML4I (NPML4EPG/2) /* Index of recursive pml4 mapping */ -#define KPML4I (NPML4EPG-1) /* Top 512GB for KVM */ -#define DMPML4I rounddown(KPML4I - NDMPML4E, NDMPML4E) /* Below KVM */ +#define KPML4BASE (NPML4EPG-NKPML4E) /* KVM at highest addresses */ +#define DMPML4I rounddown(KPML4BASE-NDMPML4E, NDMPML4E) /* Below KVM */ +#define KPML4I (NPML4EPG-1) #define KPDPI (NPDPEPG-2) /* kernbase at -2GB */ /* diff --git a/amd64/include/vmparam.h b/amd64/include/vmparam.h index 33f62bd..cff2558 100644 --- a/amd64/include/vmparam.h +++ b/amd64/include/vmparam.h @@ -145,18 +145,19 @@ * 0x0000000000000000 - 0x00007fffffffffff user map * 0x0000800000000000 - 0xffff7fffffffffff does not exist (hole) * 0xffff800000000000 - 0xffff804020100fff recursive page table (512GB slot) - * 0xffff804020101000 - 0xfffffdffffffffff unused - * 0xfffffe0000000000 - 0xfffffeffffffffff 1TB direct map - * 0xffffff0000000000 - 0xffffff7fffffffff unused - * 0xffffff8000000000 - 0xffffffffffffffff 512GB kernel map + * 0xffff804020101000 - 0xffffdfffffffffff unused + * 0xffffe00000000000 - 0xffffefffffffffff 16TB direct map + * 0xfffff00000000000 - 0xfffff7ffffffffff unused + * 0xfffff80000000000 - 0xffffffffffffffff 8TB kernel map * * Within the kernel map: * * 0xffffffff80000000 KERNBASE */ -#define VM_MAX_KERNEL_ADDRESS KVADDR(KPML4I, NPDPEPG-1, NPDEPG-1, NPTEPG-1) -#define VM_MIN_KERNEL_ADDRESS KVADDR(KPML4I, NPDPEPG-512, 0, 0) +#define VM_MIN_KERNEL_ADDRESS KVADDR(KPML4BASE, 0, 0, 0) +#define VM_MAX_KERNEL_ADDRESS KVADDR(KPML4BASE + NKPML4E - 1, \ + NPDPEPG-1, NPDEPG-1, NPTEPG-1) #define DMAP_MIN_ADDRESS KVADDR(DMPML4I, 0, 0, 0) #define DMAP_MAX_ADDRESS KVADDR(DMPML4I + NDMPML4E, 0, 0, 0) -- 1.8.2.1 From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 15 10:35:50 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2093894A for ; Mon, 15 Jul 2013 10:35:50 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 10D7BE2D for ; Mon, 15 Jul 2013 10:35:49 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r6FAZniH039356 for ; Mon, 15 Jul 2013 03:35:49 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <51E3D085.2050504@rawbw.com> Date: Mon, 15 Jul 2013 03:35:49 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Kernel crashes after sleep: how to debug? References: <51E3A334.8020203@rawbw.com> In-Reply-To: <51E3A334.8020203@rawbw.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 10:35:50 -0000 On 07/15/2013 00:22, Yuri wrote: > How to find the cause of the crash? I added WITNESS and related options and next crash produced such messages: Jul 15 03:25:53 satellite kernel: panic: Bad link elm 0xfffffe00b780d000 next->prev != elm Jul 15 03:25:53 satellite kernel: cpuid = 1 Jul 15 03:25:53 satellite kernel: KDB: stack backtrace: Jul 15 03:25:53 satellite kernel: #0 0xffffffff8094b846 at kdb_backtrace+0x66 Jul 15 03:25:53 satellite kernel: #1 0xffffffff809129c8 at panic+0x1d8 Jul 15 03:25:53 satellite kernel: #2 0xffffffff80b83994 at vm_page_requeue+0xe4 Jul 15 03:25:53 satellite kernel: #3 0xffffffff80b896c4 at vm_pageout+0xb04 Jul 15 03:25:53 satellite kernel: #4 0xffffffff808e3f65 at fork_exit+0x135 Jul 15 03:25:53 satellite kernel: #5 0xffffffff80cd72de at fork_trampoline+0xe Process was pagedaemon, like before. Yuri From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 15 13:23:50 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4FF6E660; Mon, 15 Jul 2013 13:23:50 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1A8F9A72; Mon, 15 Jul 2013 13:23:50 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:c43b:a26c:57b2:c3a3]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 4EBFC4AC58; Mon, 15 Jul 2013 17:23:48 +0400 (MSK) Date: Mon, 15 Jul 2013 17:23:44 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <782445112.20130715172344@serebryakov.spb.ru> To: John Baldwin Subject: Re: Intel D2500CC serial ports In-Reply-To: <201307111014.42903.jhb@freebsd.org> References: <201307111014.42903.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Robert Ames X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 13:23:50 -0000 Hello, John. You wrote 11 =D0=B8=D1=8E=D0=BB=D1=8F 2013 =D0=B3., 18:14:42: JB> Maybe try this: JB> --- //depot/user/jhb/acpipci/dev/acpica/acpi_resource.c 2011-07-22 = 17:59:31.000000000 0000 JB> +++ /home/jhb/work/p4/acpipci/dev/acpica/acpi_resource.c 2011-07= -22 17:59:31.000000000 0000 JB> @@ -141,6 +141,10 @@ JB> default: JB> panic("%s: bad resource type %u", __func__, res->Type); JB> } JB> +#if defined(__amd64__) || defined(__i386__) JB> + if (irq < 16 && trig =3D=3D ACPI_EDGE_SENSITIVE && pol =3D=3D ACPI= _ACTIVE_LOW) JB> + pol =3D ACPI_ACTIVE_HIGH; JB> +#endif JB> BUS_CONFIG_INTR(dev, irq, (trig =3D=3D ACPI_EDGE_SENSITIVE) ? JB> INTR_TRIGGER_EDGE : INTR_TRIGGER_LEVEL, (pol =3D=3D ACPI_ACTIVE= _HIGH) ? JB> INTR_POLARITY_HIGH : INTR_POLARITY_LOW); This patch helps me too! Could it be integrated? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 15 15:33:04 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C1AD9F0B for ; Mon, 15 Jul 2013 15:33:04 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by mx1.freebsd.org (Postfix) with ESMTP id 88F36369 for ; Mon, 15 Jul 2013 15:33:04 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id f11so1657223qae.3 for ; Mon, 15 Jul 2013 08:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=y07o6dhG3q0ESnqRI59eKRYeEpVuL8G1AJZZnsyMZK0=; b=MNNTcfmM0ADbjHTASWCcxycwzpiSNqOFVWwdkggqgIEr/3LyAatJFzDtFnCAgp2HP7 Mh/KEVUanHynuQAtanB2WK3VgFLz+c6Xl1fTW9hBxs/PNdLL2AaNftJ0FifAyECCMFbA 25ZtQNxE9GoFOF8CqyILVpVha2cFZvrrYJQuVCMWYy9fJjSSFGAIz9gzqoqIgbDjJ4Ca EMn0BLEjDo8o5Cgk8H6rEsghsjXCVBfKIR18jmu1qXLAD9wYvpU3acHtnkgNngzYqHbL JDuhnuU6TTyd6cdVelZrrY/3ymr2BbxzBFGuO9xhcK8uBKgLr2uDeMr5d4Z8bpr3OV0Y VuRw== MIME-Version: 1.0 X-Received: by 10.229.179.200 with SMTP id br8mr12109768qcb.9.1373902384028; Mon, 15 Jul 2013 08:33:04 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.49.37.226 with HTTP; Mon, 15 Jul 2013 08:33:03 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jul 2013 09:33:03 -0600 X-Google-Sender-Auth: R3je7vdYCxa7WsHPhHWoeRMDxU8 Message-ID: Subject: Re: GPT issues with device path lengths involving make_dev_physpath_alias From: Alan Somers To: Selphie Keller Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 15:33:04 -0000 It's a compatibility problem. If you change that constant, then any binaries built with the old value will break if they rely on it having a fixed value in a system or library call. For example, the MFIIO_QUERY_DISK ioctl in the mfi(4) driver passes a structure with an array of size SPECNAMELEN + 1. If you change SPECNAMELEN, then you'll have to add a compatibility mechanism for this ioctl. I'm sure there are other places that would have the same problem. Happy Hacking. On Sun, Jul 14, 2013 at 11:50 PM, Selphie Keller wrote: > hello hackers, > > I recently ran into a issue with a storage server that has some of the > drives in gpt vs mbr, tracked it down to a 64 char limit that is preventing > aliases in function make_dev_physpath_alias. I was curious if there was any > reason why this couldn't be bumped from 64 to 128 which would make room for > the device paths of gpt roughly around 94 and 96 chars long. > > - #define SPECNAMELEN > 63 > */* max length of devicename */ > + *#define SPECNAMELEN > 127 > */* max length of devicename */* > > > http://fxr.watson.org/fxr/source/sys/param.h#L106 > > Jul 14 22:10:17 fbsd9 kernel: make_dev_physpath_alias: WARNING - Unable to > alias gptid/4d177c56-ce17-26e3-843e-9c8a9faf1e0f to enc@n5003048000ba7d7d > /type@0/slot@b/elmdesc@Slot_11/gptid/4d177c56-ce17-26e3-843e-9c8a9faf1e0f - > path too long > Jul 14 22:10:17 fbsd9 kernel: make_dev_physpath_alias: WARNING - Unable to > alias gptid/4b1caf38-d967-24ee-c3a0-badff404e7ed to enc@n5003048000ba7d7d > /type@0/slot@5/elmdesc@Slot_05/gptid/4b1caf38-d967-24ee-c3a0-badff404e7ed - > path too long > > -Selphie (Estella Mystagic) > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 15 21:05:44 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ECAF5E4E for ; Mon, 15 Jul 2013 21:05:43 +0000 (UTC) (envelope-from torek@torek.net) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) by mx1.freebsd.org (Postfix) with ESMTP id B9831A75 for ; Mon, 15 Jul 2013 21:05:43 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id r6FL5g1B053031 for ; Mon, 15 Jul 2013 15:05:42 -0600 (MDT) (envelope-from torek@torek.net) Message-Id: <201307152105.r6FL5g1B053031@elf.torek.net> From: Chris Torek To: freebsd-hackers@freebsd.org Subject: am I abusing the UMA allocator? Date: Mon, 15 Jul 2013 15:05:42 -0600 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Mon, 15 Jul 2013 15:05:42 -0600 (MDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:05:44 -0000 I have been experimenting with using the UMA (slab) allocator for special-purpose physical address ranges. (The underlying issue is that we need zone-like and/or mbuf-like data structures to talk to hardware that has "special needs" in terms of which physical pages it can in turn use. Each device has a limited memory window it can access.) For my purposes it's nice that the allocation function receives a "zone" argument, even though the comment in the call says "zone is passed for legacy reasons". However, the free function does not get the zone argument, or anything other than a single bit -- up to 4 if you cheat harder. This is ... less convenient (although in my case I can use the VA being free'd, instead). What I'm wondering is what this single bit is really for; whether the allocation and free might be made more flexible for special- purpose back-end allocators; and whether this is really using things as intended. Details: In the allocator, there's a per-"keg" uk_allocf and uk_freef ("alloc"ation and "free" "f"unction) pointer, and you can set your own allocation and free functions for any zone with: void uma_zone_set_allocf(uma_zone_t zone, uma_alloc allocf); void uma_zone_set_freef(uma_zone_t zone, uma_free freef); (Aside: it seems a bit weird that you set these per *zone* but they're stored in the *kegs*, specifically the special "first keg", but never mind... :-) ) Each allocf is called as: /* arguments: uma_zone_t zone, int size, uint8_t *pflag, int wait */ mem = allocf(zone, nbytes, &flags, wait); where "wait" is made up of malloc flags (M_WAITOK, M_NOWAIT, M_ZERO, M_USE_RESERVE). The "flags" argument is not initialized at this point, so the allocation function must fill it in. The filled-in value is stored in the per-slab us_flags and eventually passed back to each freef function: /* arguments: void *mem, int size, uint8_t flag */ freef(mem, nbytes, pflag); /* where pflag = us->us_flags */ The flags are defined in sys/vm/uma.h and are the UMA_SLAB_* flags (BOOT, KMEM, KERNEL, "PRIV", OFFP, MALLOC). UMA_SLAB_PRIV is described as "private". The bit is never tested though, so it seems that a "private" allocator can set UMA_SLAB_PRIV, or not set it, freely. It appears to be the only UMA_SLAB_* bit that has no other defined meaning in uma_core.c or elsewhere. (Not entirely true, there's also UMA_SLAB_OFFP which is never tested or set, and bits 0x40 and 0x80 are unused. There's also an unused us_pad right after that. It looks like OFFP is a leftover, with "on" vs "off" page slab management controlled through UMA_ZONE_HASH and also the PG_SLAB bit in the underlying "struct vm_page".) There's also a per-keg flag spelled UMA_ZFLAG_PRIVALLOC, along with UMA_ZONE_NOFREE. But UMA_ZFLAG_PRIVALLOC is never tested; and UMA_ZONE_NOFREE is really per-keg, and you can't set it from outside the UMA code. When the system gets low on memory, it calls uma_reclaim(), which does (simplified): zone_foreach(zone_drain) | zone_drain(zone) | zone_drain_wait(zone) | bucket_cache_drain() | zone_foreach_keg() | keg_drain() | test: (UMA_ZONE_NOFREE || keg->uk_freef==NULL) | if either is the case, return now, can't free The issue here is that draining these special purpose, special- physical-page-backed zones is not actually going to help the system any (though freeing internal bucket data structures could help slightly). Of course I can have uk_freef == NULL, but it is nice to keep some statistics, and maybe be able to trade pages between various special-purpose physical spaces (by doing my own zone_drain()s on them -- the one in uma_reclaim() is not going to help the OS much as the physical pages cannot be handed out to processes, and they "run out" against themselves, not the VM system). All in all, I'm now thinking that I'm abusing the slab allocator too much here. But I wonder if perhaps some minor changes to uma_core might make this more useable, or if this is really within the intent of the UMA code at all. Chris From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 15 23:31:20 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B0DECED5 for ; Mon, 15 Jul 2013 23:31:20 +0000 (UTC) (envelope-from westsidefamily13@hotmail.com) Received: from dub0-omc2-s5.dub0.hotmail.com (dub0-omc2-s5.dub0.hotmail.com [157.55.1.144]) by mx1.freebsd.org (Postfix) with ESMTP id 194DB150 for ; Mon, 15 Jul 2013 23:31:19 +0000 (UTC) Received: from DUB118-W27 ([157.55.1.136]) by dub0-omc2-s5.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Jul 2013 16:30:11 -0700 X-TMN: [OtmtNSw1Loc8toP1cDqYVeGDwWx96D+V] X-Originating-Email: [westsidefamily13@hotmail.com] Message-ID: Content-Type: multipart/mixed; boundary="_6651206e-2cb2-487d-b13f-2d12e38684f6_" From: West Side Family To: "freebsd-hackers@freebsd.org" Subject: ***HELP*** Date: Tue, 16 Jul 2013 02:30:11 +0300 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 15 Jul 2013 23:30:11.0384 (UTC) FILETIME=[4009DB80:01CE81B3] X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 23:31:20 -0000 --_6651206e-2cb2-487d-b13f-2d12e38684f6_ Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable I Need help from all of you guys for this site www.zoo.g ( Admin.zoo.gr = ) to broke up the password!!! THANKS=20 = --_6651206e-2cb2-487d-b13f-2d12e38684f6_-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 16 00:08:25 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EF223489 for ; Tue, 16 Jul 2013 00:08:25 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id B8869265 for ; Tue, 16 Jul 2013 00:08:25 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id k13so147324iea.32 for ; Mon, 15 Jul 2013 17:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=fngMC7VkRwV0qOm2tRyiXipLaARowbDv3v5LE99zTEs=; b=W5XE3GYbd875rmXOImikukTMUYFbIZUMQGRbx5MMStkV6gwzqwMMnQCgM5ZfTrYoA5 wU7YgJ/aSnHq4gsf/OSdaUrswXTW9dAvapwk76CkOMGZM+3rrcjsp8eMbr7dKV2p7WPP QyusZSkotYv9YfHKtQk7J3wbDFalnmSQdcR2U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=fngMC7VkRwV0qOm2tRyiXipLaARowbDv3v5LE99zTEs=; b=jGCZp/EVp8YQ4IAy3mYb39z0m9+O4fNi7vCrDTSy90Qh08fKgTeHigW2Wf6gwnkqIg fORjemA7/usTzRXJex7J7KMsNz/clgcVZSUPU77oWcNHo7LMo2svo7kRD4OOrdFTE1UM 8GwQnFkOlPIijCIVX7ilYiMz4E0omLyXoQsTGdEdkbvN+Uf/3H6ntB8yZdzZ0PTKhEBu If/SOSe4L3efhjo+kdZOcyLk016l+hajMqWuRkYnsg7czoC8CqNXKVWumWjfxEC+HsEn yPWbGAVx1AryQBFEeW+Pb13+Yxd/8ZtyPdlSiim/FK8s/A6Qr+n5rjETkEHIyx4j0TiX Hz/A== X-Received: by 10.43.15.68 with SMTP id pt4mr2432421icb.35.1373933305369; Mon, 15 Jul 2013 17:08:25 -0700 (PDT) Received: from [10.24.132.116] (h96-60-216-253.wyngmi.dedicated.static.tds.net. [96.60.216.253]) by mx.google.com with ESMTPSA id d14sm21434841igz.6.2013.07.15.17.08.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Jul 2013 17:08:24 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9EC8F351-7B59-4509-85E9-D7B5A9DF2EC2; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B329) From: Jason Hellenthal Subject: Re: ***HELP*** Date: Mon, 15 Jul 2013 20:08:14 -0400 To: West Side Family X-Gm-Message-State: ALoCoQnQdfRgU2b9ShktZ1ks4+FqDNoFiw4Yeq2yMxubThuYAIJKewFnuun6JWI2dirx3VZQcIyN X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 00:08:26 -0000 --Apple-Mail-9EC8F351-7B59-4509-85E9-D7B5A9DF2EC2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Grandma doesn't have strong enough glasses to see the keyboard sorry. --=20 Jason Hellenthal Inbox: jhellenthal@DataIX.net Voice: +1 (616) 953-0176 JJH48-ARIN On Jul 15, 2013, at 19:30, West Side Family w= rote: > I Need help from all of you guys for this site www.zoo.g ( Admin.zoo.gr= ) to broke up the password!!! THANKS=20 > =20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= --Apple-Mail-9EC8F351-7B59-4509-85E9-D7B5A9DF2EC2 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGNDCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYxggNvMIIDawIBATCB lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEg UHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wCQYFKw4DAhoFAKCCAa8wGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNzE2MDAwODE4WjAjBgkqhkiG 9w0BCQQxFgQUReMse6Clii2ufpY81fUS2cBUWwgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IElu dGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaijjANBgkqhkiG9w0BAQEFAASCAQBkNzyQ1knWasAqvcEE xS59HLpm5yn/MghHEonU3V/NZKoCMT3Ic2w/zEnqUiUkAsjArIrO4E+rnxBh55GKgOW2sWyhkSd+ pg0gUQb6phzXSJ17Nuwy7adKkl9Tm40dlS+r5Dl8GSpubjNLWC50gmF8+zN3Zau26SpigmnKOPt0 3FmQYoxw3M0OhKSzIGOoHtG8l1p87QmbFVvbwfFMIB/L+unW/yBQO0YUleN8ozFdjeeIARi3RkDU YtV78iRdQCZRWtcqbwln/l3vebD7HHlmnfkJOoXmHlcZI7uxNbJDFcnEcjqGe6gSj42wlpOqxaRH orsVrGf+eHBeK7Qna8roAAAAAAAA --Apple-Mail-9EC8F351-7B59-4509-85E9-D7B5A9DF2EC2-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 16 01:44:04 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1CDF3EB5; Tue, 16 Jul 2013 01:44:04 +0000 (UTC) (envelope-from pali.gabor@gmail.com) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by mx1.freebsd.org (Postfix) with ESMTP id C084F765; Tue, 16 Jul 2013 01:44:03 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id wc20so128981obb.4 for ; Mon, 15 Jul 2013 18:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=eiU0bHWt2PPCjM/f+XHAGONCb7ChhI/9TwJD/Gh0hHc=; b=g+wwmm2u5iOxvdmqubZhGD8TRdKg+iqd0w6wGLi0Fafcq7s2cfuT1C1CLJkObkHX8j QQRpox7WcciSYk/Jz1D0b+HcklzIzG8xoWUH68Fg8jYv0B2wPw7i47NZGDLZhDVdpDmd +bgHpBL2WqvHEYPjjBAaL7+4uNtIxabmD0HcU9xi50snWwL2t5gfn4841T6oMh9gKfOw qlnhPmE6O9nIyHewnR0UA1T3fmMBt293aBoSmHCpvoGu28ZDPLIOSLlzIzvoa2UmMibs gvMRxyhrZa0tKVnbOueagKJCtIXxt9DpmDG9ZSmKtKPz143HGkj+LCXWQClb4W0llE7+ Gkkw== MIME-Version: 1.0 X-Received: by 10.182.134.229 with SMTP id pn5mr45889080obb.9.1373939043000; Mon, 15 Jul 2013 18:44:03 -0700 (PDT) Sender: pali.gabor@gmail.com Received: by 10.182.27.101 with HTTP; Mon, 15 Jul 2013 18:44:02 -0700 (PDT) Date: Tue, 16 Jul 2013 02:44:02 +0100 X-Google-Sender-Auth: wu2nkY5cC1bAM12UNUjwBy24gyY Message-ID: Subject: FreeBSD Quarterly Status Report, April-June, 2013 From: Gabor Pali To: hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 01:44:04 -0000 FreeBSD Quarterly Status Report, April-June 2013 Introduction This report covers FreeBSD-related projects between April and June, 2013. This is the second of four reports planned for 2013. The last three months have been very active for the FreeBSD developer community, including events such as BSDCan and the FreeBSD Developer Summit collocated with it (covered in a separate report, see the BSDCan Developer Summit Special) and BSD-Day 2013. It has also seen improvements from the top to the bottom of the FreeBSD system. Desktop users will be pleased to note work on improving the state of AMD GPUs and making the console interaction with kernel mode setting -- required for recent xorg drivers -- cleaner and from continued work to make binary packages easier to use. Developers will note continued improvements to our toolchain, with a new debugger being prepared for integration. Server users will benefit from various improvements to virtualization support and scalability in the kernel. Of course, the FreeBSD system is nothing without applications to run atop it, and this quarter has seen some tireless work by members of the ports team to ensure that users have a wide choice of desktop and development environments, with highlights from the GNOME, KDE, Xfce, and Haskell teams in this report. Thanks to all the reporters for the excellent work! This report contains 33 entries and we hope you enjoy reading it. The deadline for submissions covering between July and September, 2013 is October 7th, 2013. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Core Team * FreeBSD Postmaster Team * FreeBSD Release Engineering Team * FreeBSD Security Team Projects * PC-BSD * Virtual Private Systems Kernel * AMD GPU Kernel Mode-setting Support * Improved TCP SYN Cookies * Multi-threaded Pagedaemon * Native iSCSI Stack * Newcons Reboot * Realtek RTL8188CU/RTL8192CU USB Wireless Driver * SDIO Driver * V4L2 Update in the Linuxulator * Wireless Networking Improvements * Xen Support Improvements * ZFS TRIM and Enhanced BIO_DELETE Support Architectures * Intel IOMMU (VT-d, DMAR) Support * Superpages for ARMv7 Userland Programs * bsdconfig(8) and sysrc(8) * bsnmpd(1) Support in hastd(8) * Capsicum * LLDB Debugger Port Ports * FreeBSD Haskell Ports * GNOME/FreeBSD * KDE/FreeBSD * Xfce/FreeBSD * xorg on FreeBSD Documentation * Upgrading the Documentation Set to DocBook 5.0 Events * BSD-Day 2013 Google Summer of Code * New Capsicum Features * Qt and GTK+ Frontends for pkg(8) Miscellaneous * The FreeBSD Foundation __________________________________________________________________ AMD GPU Kernel Mode-setting Support URL: https://wiki.freebsd.org/AMD_GPU Contact: Jean-S=C3=A9bastien P=C3=A9dron Contact: Konstantin Belousov Due to non-FreeBSD-related activities from April to end of June, the project progressed slowly: * Some important problems in TTM were fixed and several others are being worked out. Applications affected by these bugs are non-linear video editing software (which do not use Xv to preview the video) or "screen" of VirtualBox, for instance. * Regarding the locking issue with OpenGL, no work has been done yet. glxgears works but some modern desktop environments or WebGL demos hang. Once TTM bugs described above are fixed, this is the next target. * Patches to Mesa to make it build out-of-the-box were submitted upstream. As of writing, some were committed but not all of them. Additionally, as result of a joint work with Jonathan Gray (of OpenBSD), Mesa should work on FreeBSD, OpenBSD, and hopefully on other BSD flavors without additional patches. Several users tested the driver. Andriy Gapon, Jonathan Gray, and Mark Kettenis (of OpenBSD) submitted patches. kyzh kindly donated several discrete cards from different series. A big thanks to all those contributors! The driver is still not stable enough for a wider call for testers. Open tasks: 1. Write instructions for the wiki to explain how to test the driver. __________________________________________________________________ BSD-Day 2013 URL: http://bsdday.eu/2013 URL: http://www.youtube.com/playlist?list=3DPLJJHfhjb5TOjB-sHRwJBGWd8XA7= nc1gk_ URL: https://picasaweb.google.com/116452848880746560170/BSDDay2013?authk= ey=3DGv1sRgCNvIoMWoxNTRYw Contact: G=C3=A1bor P=C3=A1li The BSD-Day is a now recurring excuse for BSD developers and users to meet up in person, share some beers and talk about what they are working on these days. There was a detour this year to visit the beautiful city of Naples of Italy, the home of pizza. Fortunately, the event has again gained support from numerous and generous sponsors, such as The FreeBSD Foundation, the EMC Corporation, iXsystems, FreeBSDMall, BSD Magazine, and many others which enabled us to cover the costs of travel and accommodation for the speakers. We are really grateful for this. Similarly to the previous years, the whole event started with a dinner in the downtown (somewhere around the Irish Pub) on Friday which suddenly turned into a do-it-yourself pizza-fest. Then it was followed by the Saturday event at the Institute of Biostructures and Bioimaging. There we had a lot of attendees for the associated BSDA exam in the morning -- 8 persons. The event itself had many interesting topics as well, for example moving MCLinker into the BSD world, organization and culture of the FreeBSD Project, the new callout(9) framework, building and testing ports with Poudriere and Tinderbox, FreeBSD in the embedded space, or building reliable VPN networks with OpenBSD. See the links in the report for more. __________________________________________________________________ bsdconfig(8) and sysrc(8) URL: http://druidbsd.sourceforge.net/ Contact: Devin Teske New utilities have been introduced in FreeBSD base system: bsdconfig(8) and sysrc(8). bsdconfig(8) is a replacement for the post-install abilities of deprecated sysinstall(8), while sysrc(8) is a robust utility for managing rc.conf(5) from the command line without a text editor. __________________________________________________________________ bsnmpd(1) Support in hastd(8) Contact: Mikolaj Golub A hastd(8) module for bsnmpd(1) has been committed to FreeBSD head and merged to the stable/8 and stable/9 branches recently. This module makes it possible to monitor and manage hastd(8) via the SNMP protocol. __________________________________________________________________ Capsicum URL: http://www.cl.cam.ac.uk/research/security/capsicum/ URL: https://lists.cam.ac.uk/mailman/listinfo/cl-capsicum-discuss Contact: Pawel Jakub Dawidek Contact: Capsicum Mailing List Capsicum, a lightweight OS capability and sandboxing framework, is being actively worked on. In the last few months the following tasks have been completed: * Committed Capsicum overhaul to FreeBSD head (r247602). This allows to use capability rights in more places, simplifies kernel code and implements ability to limit ioctl(2) and fcntl(2) system calls. * hastd(8) is now using Capsicum for sandboxing, as whitelisting ioctls is possible (r248297). * auditdistd(8) is now using Capsicum for sandboxing, as it is now possible to setup append-only restriction on file descriptor (available in Perforce). * Implemented connectat(2) and bindat(2) system calls for UNIX domain sockets that are allowed in capability mode (r247667). * Implemented chflagsat(2) system call (r248599). * Revised the Casper daemon for application capabilities. * Implemented libcapsicum for application capabilities. * Implemented various Casper services to be able to use more functionality within a sandbox: system.dns, system.pwd, system.grp, system.random, system.filesystem, system.socket, system.sysctl. * Implemented Capsicum sandboxing for kdump(1) (from r251073 to r251167). The version in Perforce also supports sandboxing for the -r flag, using Casper services. * Implemented Capsicum sandboxing for dhclient(8) (from r252612 to r252697). * Implemented Capsicum sandboxing for tcpdump(8) (available in Perforce). * Implemented Capsicum sandboxing for libmagic(3) (available in Perforce). * Implemented the libnv library for name/value pairs handling in the hope of wider adaptation across FreeBSD. For Capsicum-based sandboxing in the FreeBSD base system, the commits referenced above and the provided code aim to serve as examples. We would like to see more FreeBSD tools to be sandboxed -- every tool that can parse data from untrusted sources, for example. This requires deep understanding of how the tool in question works, not necessarily only Capsicum. This work is being sponsored by The FreeBSD Foundation. Open tasks: 1. Get involved, make the Internet finally(!) a secure place. Contact us at the cl-capsicum-discuss mailing list, where we can provide guidelines on how to do sandboxing properly. The fame is there, waiting. __________________________________________________________________ FreeBSD Core Team Contact: FreeBSD Core Team In the second quarter of 2013, the Core Team approved a new Security Officer, Dag-Erling Sm=C3=B8rgrav and his deputy, Xin Li. The Core Team acknowledges Simon Nielsen, the outgoing Security Officer, for his work in the role. Peter Wemm took the lead on the reorganization and administration of the FreeBSD cluster, and with the Core Team's approval, Glen Barber and Ryan Steinmetz were welcomed to the cluster administration team. Based on the recommendation and experiences of Martin Wilke, the Core Team also supported establishing a liaison role between port managers and release engineers in order to improve their communication, especially for preparing releases. The Core Team welcomes Bryan Drewery to this role. Following up on the request from Eitan Adler, the Core Team agreed to remove CVS from the base system, which was soon followed by importing a lightweight version of Subversion tools, implemented by Peter Wemm. There were src commit bits issued for 3 new developers and 1 existing committer received extension in this quarter. __________________________________________________________________ FreeBSD Haskell Ports URL: http://wiki.freebsd.org/Haskell URL: https://github.com/freebsd-haskell/ports/ URL: http://haskell.inf.elte.hu/packages/ Contact: G=C3=A1bor P=C3=A1li Contact: Ashish SHUKLA We are proud to announce that the FreeBSD Haskell Team has updated the Haskell Platform to 2013.2.0.0, GHC to 7.6.3, as well as updated existing ports to their latest stable versions. In this update, we provided experimental support for LLVM-based code generation (disabled by default) to Haskell ports. We also added a number of new ports, which brings their count in the FreeBSD Ports Collection to 402, and now Haskell ports play nicer with portmaster(8)-based upgrades. In cooperation with Konstantin Belousov and Dimitry Andric, we have managed to unbreak the build of GHC on 32-bit 10.x systems, so we have packages for 10.x again. However, it turned out that this bug (in thread signal delivery) can also affect the building process for other platforms as well, which explains some of the strange build breakages our users experienced in the past. We have also learned that there is ongoing work in the GHC upstream which will allow us to provide support for building with Clang natively once GHC 7.8 becomes part of the Haskell Platform. Open tasks: 1. Test experimental Clang/LLVM code generation support to enable it by default. 2. Commit pending Haskell ports to the ports tree. 3. Port more (popular) Cabal packages. __________________________________________________________________ FreeBSD Postmaster Team Contact: FreeBSD Postmaster Team In the second quarter of 2013, the FreeBSD Postmaster Team has implemented the following items that may be interest of the general public: * With help from clusteradm, found that unbound (the resolver used on mx1 and mx2) is configured to perform DNSSEC validation which implies that if a signed zone fails validation, unbound refuses to use the information. This had caused one person to be unable to exchange email with FreeBSD.org until the zone signatures were refreshed. * Created the freebsd-dtrace mailing list, requested by George Neville-Neil. * Resurrected the freebsd-testing mailing list, requested by Garrett Cooper. * Created the freebsd-tex mailing list, requested by Hiroki Sato. * In response to another comment that our message rejection message was unclear in the case that greylisting was the reason, re-worded that message. * Augmented the allowable MIME types for secteam with the following to permit sending encrypted messages: + application/pgp-encrypted + application/pkcs7-encrypted + application/x-pkcs7-encrypted + multipart/encrypted * Began replacing freebsd-mozilla with freebsd-gecko. __________________________________________________________________ FreeBSD Release Engineering Team URL: http://www.freebsd.org/releases/8.4R/errata.html URL: http://www.freebsd.org/releases/9.2R/schedule.html Contact: FreeBSD Release Engineering Team The FreeBSD 8.4-RELEASE cycle completed on June 7, 2013, approximately two months behind the original schedule. Please be sure to read the Errata Notices for any post-release issues discovered after 8.4-RELEASE. The FreeBSD 9.2-RELEASE process will begin July 6, 2013. Unless any critical issues arise, FreeBSD 9.2-RELEASE is expected to be available late August or early September. Users tracking the FreeBSD 9.X branch are encouraged to test the -BETA and -RC builds whenever possible, and provide feedback and report issues to the freebsd-stable mailing list. __________________________________________________________________ FreeBSD Security Team Contact: FreeBSD Security Team On April 15th Dag-Erling Sm=C3=B8rgrav and Xin Li took over as security officers for the FreeBSD Project, and the team welcomed Qing Li back to the team in June. This report briefly summarizes the work of the Security Team from April until the end of June. The Security Team has released the following advisories: * FreeBSD-SA-13:05.nfsserver: Insufficient input validation in the NFS server (nfsd(8)), reported by Adam Nowacki. * FreeBSD-SA-13:06.mmap: Privilege escalation via mmap(), reported by Konstantin Belousov. The Security Team has contributed to the following errata notices: * FreeBSD-EN-13:02.vtnet: Frames are not properly forwarded to vtnet(4) when two or more MAC addresses are configured on QEMU 1.4.0 and later in 8.4-RELEASE, reported by Julian Stecklina. * FreeBSD-EN-13:01.fxp: Initialization of fxp(4) network interfaces results in an infinite loop with dhclient(8) in 8.4-RELEASE, reported by Michael L. Squires. Per the request of Baptiste Daroussin, the Security Team has also reviewed the source code of Poudriere, the port build and test system which is planned to be used for producing pkg(8) ("new-style") packages on the FreeBSD cluster. __________________________________________________________________ GNOME/FreeBSD URL: http://www.FreeBSD.org/gnome/ Contact: FreeBSD GNOME Team The GNOME 3.6 work is moving along slowly but steadily. Almost all the GNOME 3 desktop ports were updated to their corresponding 3.6 versions. A big challenge was taken by getting the webkit-gtk3 port updated to 2.0.3. Currently programs using webkit-gtk3 crash on launch. It is hard to find the causes as the debug build of webkit-gtk either runs out of memory or disk space on the developement system used. Open tasks: 1. Update the FreeBSD GNOME website with recent changes in the ports tree, add new items in preparation for GNOME 3 and Mate, etc. 2. Merge Glib 2.36, GTK+ 3.8 and related ports back to the Ports Collection. 3. Continue work on GNOME 3.6, fix bugs and write code for missing features. 4. Complete the port of MATE. __________________________________________________________________ Improved TCP SYN Cookies URL: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D28838+0+current/free= bsd-net URL: http://people.freebsd.org/~andre/syncookie-20130708.diff Contact: Andre Oppermann We have had a SYN cookie implementation for quite some time now but it has some limitations with current realities for window scaling and SACK encoding the in the few available bits. This patch updates and improves SYN cookies mainly by: 1. Encoding of MSS, WSCALE (window scaling) and SACK into the ISN (initial sequence number) without the use of timestamp bits. 2. Switching to the very fast and cryptographically strong SipHash-2-4 hash MAC algorithm to protect the SYN cookie against forgery. The common parameters used on TCP sessions have changed quite a bit since SYN cookies were invented some 17 years ago. Today we have a lot more bandwidth which makes use of window scaling almost mandatory. Also SACK has become standard as it makes recovering from packet loss much more efficient. The original SYN cookies method only stored an indexed MSS value in the cookie. This obviously is not sufficient any more and breaks in the presence of WSCALE. WSCALE information is only exchanged during SYN and SYN-ACK. If we cannot keep track of it then we severely underestimate the available send or receive window, compounded with the fact that with large window scaling the window size information on the TCP segment header would be even lower numerically. A number of years back, SYN cookies were extended to store the additional state in the TCP timestamp fields, if available on a connection. It has been adopted by Linux as well. While timestamps are common among the BSD, Linux and other Unix systems, Windows never enabled them by default, thus they are not present for the vast majority of clients seen on the Internet. The new improvement in this patch moves all necessary information into the ISN again, removing the need for timestamps. Both the MSS and send WSCALE are stored in 3 bit indexed form together with a single bit for SACK. While we cannot represent all possible MSS and WSCALE values in only 3 bits each (both are 16-bit fields in the TCP header), it turns out that is not actually necessary. These improvements allow one to run with SYN cookies only on Internet-facing servers. However while SYN cookies are calculated and sent all the time, they are only used when the syn cache overflows due to attacks or overload. In that case though, you can rest assured that no significant degradation in TCP connection setup happens any more and that even Windows clients can make use of window scaling and SACK. Open tasks: 1. Additional testing on busy servers. __________________________________________________________________ Intel IOMMU (VT-d, DMAR) Support URL: http://www.intel.com/content/www/us/en/intelligent-systems/intel-te= chnology/vt-directed-io-spec.html URL: http://lists.freebsd.org/pipermail/freebsd-arch/2013-May/014368.htm= l URL: http://people.freebsd.org/~kib/misc/dmar.1.patch Contact: Konstantin Belousov Intel VT-d is a set of extensions that were originally designed to allow virtualizing devices. It allows safe access to physical devices from virtual machines and can also be used for better isolation and performance increases. A VT-d driver was developed that implements the busdma(9) interface using the DMA Remap units (DMARs) found in current Intel chipsets. The driver provides reliability and security improvements for the system by facilitating restricted access to main memory from busmastering devices. It also eliminates bounce buffering (copying) by allocating remapped regions that satisfy a device's access limitations. With additional work to define a suitable interface the VT-d driver will also provide PCI pass-through functionality for hypervisors. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Implement workarounds for chipset errata. 2. Commit to HEAD after additional testing. 3. Rebalance MSI/MSI-X using interrupt remapping unit, also required for x2APIC use on big machines. 4. Integrate with the Intel GPU MMU and handle Ironlake and SandyBridge errata for the GFXVTd unit. 5. Provide an interface for VMM (hypervisors). 6. Consider implementing a driver for AMD's IOMMU. __________________________________________________________________ KDE/FreeBSD URL: http://FreeBSD.kde.org URL: http://FreeBSD.kde.org/area51.php Contact: KDE FreeBSD The KDE/FreeBSD Team has continued to improve the experience of KDE software and Qt under FreeBSD. During this quarter, the team has kept most of the KDE and Qt ports up-to-date, working on the following releases: * KDE SC: 4.10.2, 4.10.3, 4.10.4 * Qt: 5.0.2 (area51) * PyQt: 4.10.2; QScintilla 2.7.2; SIP: 4.14.7 * KDevelop: 4.5.1 * Calligra: 2.6.2 * CMake: 2.8.11.1 * Digikam (and KIPI-plugins): 3.1.0, 3.2.0 * KDE Telepathy: 0.6.0, 0.6.1 As a result -- according to PortScout -- kde@ has 473 ports (up from 431), of which 98.73% are up-to-date (up from 93.5%). iXsystems Inc. continues to provided 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. This quarter, we would also like to thank Steve Wills (swills@) for providing access to another machine so that we can do our work even faster. While a great deal of the team's efforts are focused towards packaging released code, we also take a proactive stand in making sure future versions of the software we port is also going to work well on FreeBSD. This involves being in close contact with upstream, raising awareness of FreeBSD as an active project and also sending actual patches that most of the time benefit many other operating systems besides FreeBSD itself. In this regard, we have been dedicating a lot of time making sure both clang and libc++ are fully supported in KDE and Qt. Not only has this resulted in many patches being sent to these projects, but the exposure to these large code bases have been beneficial to the Clang-on-FreeBSD project as well. Dimitry Andric (dim@) has been of great help as a point of contact for all the issues we have faced. As usual, the team is always looking for more testers and porters so please contact us and visit our home page. 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 PortScout for a list. 2. Work on KDE 4.11 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. __________________________________________________________________ LLDB Debugger Port URL: https://wiki.freebsd.org/lldb Contact: Ed Maste LLDB is the the debugger project in the LLVM family. It supports the Mac OS X, Linux, and FreeBSD platforms, but the latter has recently suffered under a lack of maintenance. After cleaning bit rot in LLDB's FreeBSD support, it again builds and can be used for basic debugging of single-threaded applications. The test suite also runs to completion, although it experiences a large number of failures. Ed Maste has been granted an LLDB commit bit, and is now committing ongoing bug fixes and development directly to the upstream repository. There is a significant amount of work still to be done, with one goal being the incorporation of lldb into the base system. This project is sponsored by DARPA/AFRL in collaboration with SRI International and the University of Cambridge. Open tasks: 1. Add support for multithreaded processes. 2. Fix watchpoints. 3. Add support for remote debuging (gdbserver / debugserver). 4. Add support for core files. 5. Add support for kernel debugging. 6. Verify i386 and ARM architectures. 7. Implement MIPS target support. 8. Verify cross-debugging. 9. Investigate and fix test suite failures. 10. Prepare lldb for incorporation into the base system. __________________________________________________________________ Multi-threaded Pagedaemon URL: http://people.freebsd.org/~kib/misc/pagedaemon-numa.1.patch Contact: Konstantin Belousov This project aims to improve scalability of the virtual memory subsystem. Based on a prototype change from Jeff Roberson, per-domain page queues and per-domain pagedaemon working threads have been implemented to enable this. At the moment, the domains coincide with the NUMA proximity domains, but this is not neccessary and could be improved with further separation to allow more parallelism in the pagedaemon. The patch is relatively simple, with the most delicate parts being the page laundry and OOM logic, which requires coordination between all pagedaemon threads to prevent false triggering. Testing on diverse workloads and on real multi-socket machines is required. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Debug on multi-domain NUMA machine. 2. Test, get review and commit. __________________________________________________________________ Native iSCSI Stack URL: https://wiki.freebsd.org/Native%20iSCSI%20target Contact: Edward Tomasz Napiera=C5=82a The native kernel iSCSI target and initiator project progressed well over the April to June period. The primary focus was to introduce support for iSER (iSCSI over RDMA) in both the initiator and the target. Prerequisite for this was merging some common parts together and implementing a workaround for the lack of iSER support in userspace. Apart from that, there were a myriad of smaller improvements. Such as creating more user-friendly administration utilities, for example iscsictl(8) which displays SCSI device nodes for each iSCSI session. This frees the user from getting the same information through camcontrol(8). There are also improvements in logging and manual pages. Once the iSER support becomes stable, the work will focus on performance optimizations. The plan is to commit both the new initiator and target in August to allow shipping them in 10.0. The project will continue with implementing support for software iWARP stack (useful mostly for testing and development), SCSI passthrough and various other improvements. This project is being sponsored by The FreeBSD Foundation. Open tasks: 1. Performance optimization. 2. Merge to FreeBSD head. __________________________________________________________________ New Capsicum Features URL: https://wiki.freebsd.org/SummerOfCode2013/CapsicumFeatures Contact: Mariusz Zaborski Contact: Pawel Jakub Dawidek Capsicum is a lightweight OS capability and sandboxing framework implemented in FreeBSD. This is still a new technology, so there is a lot of space for improvements. Thanks to the Google Summer of Code program and Pawel Jakub Dawidek for volunteering as mentor, Mariusz will have the chance to work on this project in the summer. The work on sandboxing the rwho(1) and rwhod(8) utilities was completed recently. There is also a plan to implement two new modules for Casper. Casper is a daemon to provide services for applications using Capsicum's capability mode. Some experimentation with implementing two new capability rights is in progress, so is porting one more program to use the existing features of the Capsicum framework. Open tasks: 1. system.unix -- a Casper module provides connect and listen on Unix domain socket. 2. system.udp -- a Casper module enabling connect, listen, send, and receive of UDP packets. 3. Implementing sandboxing for fetch(1). 4. Introduce new capability rights: CAP_SEND_RIGHTS and CAP_RECV_RIGHTS. __________________________________________________________________ Newcons Reboot Contact: Aleksandr Rybalko The purpose of the Newcons project is to provide a new interface for console and video output to graphic devices. This will allow simple drivers access the console and terminal mode early, and framebuffer access for xorg. Drivers will not need embedded font bitmaps, color maps, or mouse cursor bitmaps, as the whole infrastructure will be provided by the vt(4) Newcons driver. As the project includes Kernel Mode Setting (KMS) integration, one of the goals is support for modern Xorg releases, allowing the kernel to switch back to virtual terminal mode after graphics mode or resolution used with xorg changes. There are a lot of changes involved in the project. Main tasks include: * Core functionality (almost done). * Mouse support. * KMS (kernel mode setting) support. * USB keyboard support. * Splash screen support (partially working). * Driver support. * vidcontrol(1) support. The first deliverables of the project, including moused(8), ukbd(4), and KMS support are expected to arrive around the middle or end of August 2013. The whole project is expected to complete in November 2013. This project is being sponsored by The FreeBSD Foundation. Many thanks to Ed Schouten who started Newcons project and did most of the work. Open tasks: 1. Provide different flavors of hardware for testing the implementation. Do not hesitate to volunteer when a call for testing is announced. __________________________________________________________________ PC-BSD URL: http://www.pcbsd.org Contact: Kris Moore Progress on moving PC-BSD & TrueOS to a "rolling release" is happening quickly. We have implemented our own package repository, fully based on pkg(8), which is updated twice monthly, and are now hosting dedicated freebsd-update(8) systems. In addition to the 9.1-RELEASE ISO images, we have begun to create a 9-STABLE branch as well, using freebsd-update(8) to push out the latest world and kernel binaries on a monthly basis. We are currently working on an implementation of ZFS Boot Environments for desktops and servers. These users to install updates or experimental versions in separate ZFS clones and select the one to run at boot time, providing an easy way of testing upgrades before deployment. __________________________________________________________________ Qt and GTK+ Frontends for pkg(8) URL: https://wiki.freebsd.org/SummerOfCode2013/pkgQtGtk Contact: Justin Muniz Contact: Eitan Adler This project is part of Google Summer of Code. Work has only just begun, and the code is in its infancy. The Subversion repository holds experimental code that is actively being developed. Development should be concluded before the end of September, and the project will enter the maintenance phase of its life cycle. Open tasks: 1. Work with Matt Windsor to create a pkg(8) backend for PackageKit. 2. Extend PackageKit's Qt frontend to offer more functionality through pkg(8). 3. Extend PackageKit's GKT+ frontend to offer more functionality through pkg(8). __________________________________________________________________ Realtek RTL8188CU/RTL8192CU USB Wireless Driver Contact: Rui Paulo Contact: Kevin Lo The urtwn(4) driver was imported from OpenBSD. This is a driver for very small Realtek USB WiFi cards which are pretty inexpensive and can do 802.11n at the maximum theoretical speed of 150 Mbps. They make a good addition to embedded systems such as the Raspberry Pi and the BeagleBone. The driver requires firmware that is available in the FreeBSD Ports Collection (net/urtwn-firmware-kmod). Note that 802.11n is not yet supported. __________________________________________________________________ SDIO Driver URL: https://wiki.freebsd.org/SDIO URL: https://github.com/kibab/freebsd/tree/kibab-dplug Contact: Ilya Bakulin SDIO is an interface designed as an extension for the existing SD card standard, to allow connecting different peripherals to the host with the standard SD controller. Peripherals currently sold at the general market include WLAN/BT modules, cameras, fingerprint readers, barcode scanners. The driver is implemented as an extension to the existing MMC bus, adding a lot of new SDIO-specific bus methods. Getting information about the card works, including querying all the supported I/O functions. Simple byte transfers and multi-byte reads work. A prototype of the driver for Marvell SDIO WLAN/BT module is also being developed, using the existing Linux driver as a reference. Open tasks: 1. Extend MMC bus interface with more SDIO-specific bus methods to allow child drivers to perform multi-byte in/out transfers. 2. Write firmware loading code for the prototype of the WLAN driver. Further work on the WLAN driver should probably be done as a separate project. 3. Implement detach path. It has not been tested yet because the DreamPlug hardware available does not have an external SDIO-capable slot. __________________________________________________________________ Superpages for ARMv7 URL: http://static.usenix.org/events/osdi02/tech/full_papers/navarro/nav= arro.pdf URL: https://wiki.freebsd.org/ARMSuperpages URL: https://github.com/semihalf-bodek-zbigniew/freebsd-arm-superpages.g= it Contact: Zbigniew Bodek Contact: Grzegorz Bernacki Contact: Rafa=C5=82 Jaworowski The ARM architecture is becoming more and more prevalent, with increasing usage beyond the mobile and embedded space. Among the more interesting industry trends emerging in the recent months, there has been the concept of "ARM server". Some top-tier companies, e.g. Dell and HP, have already started to develop such systems. Key to success of FreeBSD in these new areas is dealing with the sophisticated features of the platform, for example adding support for superpages. The objective of this project is to enable FreeBSD/arm to utilize superpages which would allow efficient use of TLB translations (by enlarging TLB coverage), leading to improved performance in many applications and scalability. This is intended to work on ARMv7-based processors, however compatibility with ARMv6 will be preserved. The following steps have been made since the last status report: * Implement pmap_copy() to support fork() system calls. * Support for multiple page sizes. * Implement superpage creation, promotion, demotion, and eviction mechanisms. * Implement PV entry management for superpages. * Partially integrate code to the head branch. Next steps: * Test and benchmark. * Complete integration into FreeBSD head. This project is jointly sponsored by The FreeBSD Foundation and Semihalf. Open tasks: 1. Start utilizing superpages on ARMv6/v7. 2. Find bugs and debug. __________________________________________________________________ The FreeBSD Foundation URL: http://www.FreeBSDFoundation.org/ Contact: Deb Goodkin We started the quarter with our "Raise a Million -- Spend a Million" Spring Fundraiser. This was the first of three major fundraisers scheduled for the year. We were pleased to have raised $365,291 by the end of the campaign -- May 31. Last year, by the same time, we had raised only $56,196. We have started this year off with a much better fundraising strategy. We want to send a big thank you to everyone out there that has made a donation in 2013. Your early donations have made a significant impact on our fundraising endeavors so far this year. Some things we accomplished this last quarter are: * Attended BSDCan in Ottawa, Texas LinuxFest in Austin, SouthEast LinuxFest in Charlotte, and ICANN 46 meeting in Beijing. * We were a Gold Sponsor for BSDCan 2013 and sponsored 7 developers to attend the conference. * We signed up to be a Platinum Sponsor for EuroBSDCon 2013. * We sponsored 1 developer to attend OpenHelp. * Recognized Mark Linimon, Simon L. B. Nielsen, Bjoern A. Zeeb, and Ken Smith, at BSDCan, for their significant contributions to FreeBSD. We also recognized Dan Langille for his tireless effort of putting on BSDCan for 10 years. * We sponsored the developer and vendor summits at BSDCan, with 100 and 30 attendees respectively. * We sponsored BSD-Day 2013 that was held in Naples, Italy on April 6. * We held our annual board meeting in Ottawa. * We sponsored the following projects: Capsicum, ARM Superpages, iSCSI, Page Queue Locking, Input/Output Memory Management Unit, Documentation project infrastructure, and writing white papers. * We hired Edward Tomasz Napieral/a as the second member of our technical staff to work on FreeBSD projects full-time. * We hired Ed Maste as Director of Project Development. * With our continued support of building out the FreeBSD infrastructure, we purchased high-end servers for the Sentex Lab to be used with the latest 40 Gbps Ethernet cards from Chelsio to do performance testing and analysis, smaller servers for firewalls for NYI and ISC, and cables to connect our Juniper switches together into a bigger Juniper switch we purchased for NYI. __________________________________________________________________ Upgrading the Documentation Set to DocBook 5.0 Contact: G=C3=A1bor K=C3=B6vesd=C3=A1n The Documentation Project has been using old versions of markup standards until recently when we switched to a real XML toolchain and DocBook 4.5. However, we still depend on obsolete technologies -- DSSSL and Jade. DocBook 5.0 provides cleaner markup and some nice new features. The objective of this project is to upgrade the documentation set to DocBook 5.0 and to find a way to properly render our sources without using DSSSL, since the DSSSL stylesheets are discontinued and cannot render DocBook 5.0. The documentation sources have already been successfully transformed to DocBook 5.0 and updates to the rendering process are under development. The common opinion among FreeBSD developers is that Java is a heavy dependency that should be avoided. This has suggested the transformation of DocBook sources to TeX and use TeX as a rendering backend. There are two ways to do this; the sources can be transformed either directly or through the XSL FO output generated by the stylesheets provided for the DocBook Project. The latter approach has been chosen as a preferred way since it better fits the existing documentation infrastructure and provides easier customization. This project is generously funded by The FreeBSD Foundation. Open tasks: 1. Finish the implementation of the rendering process. 2. Integrate the rendering solution into the infrastructure. 3. Merge back changes to head. __________________________________________________________________ V4L2 Update in the Linuxulator Contact: Alexander Leidinger The V4L2 support in the linuxulator was updated in FreeBSD head. This lets Skype v4 display video. Open tasks: 1. Find out why audio in Skype v4 stops working after some calls. __________________________________________________________________ Virtual Private Systems URL: http://www.7he.at/freebsd/vps/ URL: http://svnweb.freebsd.org/base/projects/vps/ Contact: Klaus Ohrhallinger VPS for FreeBSD is an OS-level based virtualization implementation that supports advanced features like live migration. It has been recently imported into the Project's Subversion repository as a project branch. The code is currently of alpha quality. Open tasks: 1. Test with many different guest setups/applications. All feedback is highly appreciated. __________________________________________________________________ Wireless Networking Improvements Contact: Adrian Chadd Recently the FreeBSD wireless networking stack has received updates in the following areas: * Improved transmit locking in net80211(4) to eliminate a whole class of subtle race conditions leading to out-of-order packets being handed to the driver. * Spectral scan (FFT) information is now available for the AR9280, AR9285, AR9287 series NICs. * Added support for AR93xx, AR94xx, AR95xx NICs -- hostap, adhoc and station modes have been tested, including 3x3 stream support for the those NICs where appropriate. * Implemented ps-poll handling in hostap mode. This was required for correct behaviour with stations that implement aggressive power save. * Added AR933x SoC support -- including all on-board peripherals -- the 8devices.com Carambola-2 board is now fully supported and will run FreeBSD from NOR flash. __________________________________________________________________ Xen Support Improvements URL: http://xenbits.xen.org/gitweb/?p=3Dpeople/royger/freebsd.git;a=3Dsu= mmary Contact: Justin T. Gibbs Contact: Will Andrews Contact: Andre Oppermann Contact: Roger Pau Monn=C3=A9 FreeBSD Xen HVM can be further improved by using more PV interfaces inside a HVM guest. So far the following items have been completed: * Update Xen interface files. (Merged into head) * Add support for the vector callback injection mechanism. This replaces the PCI interrupt and provides a per-cpu callback, which was not possible when using the PCI interrupt. * Rework event channel implementation and use the same code paths for both PV and PVHVM. * Implement PV one-shot event timers and timecounters. * Implement PV IPIs. * Live migration support for PV timers and PV IPIs. With this changes, FreeBSD will have a complete PVHVM port, this will also set the ground for a future PVH port (when PVH support is merged into Xen). PVHVM allows a virtual machine that boots as a native guest to be able to take full advantage of paravirtualized drivers, giving a performance improvement in most I/O related tasks. PVH allows a guest to take advantage of hardware assistance for memory management, but uses fully paravirtualized events and boot procedure, which brings two significant advantages beyond performance. The first is that domain 0 does not have to run a QEMU instance for emulated boot for PVH guests, which is a common reason for hosting providers to charge more for Windows and other HVM guests. The second is that PVH domains can be used as domain 0, without requiring different pmap (memory management) code from the conventional kernel. This will allow us to ship a single kernel binary supporting bare metal hardware, running as a Xen unprivileged guest, and eventually as Xen domain 0. Further improvements on blkfront and netfront have also been commited: * Fix netfront crash when detaching an interface. * Enable netfront to specify a maximum TSO length limiting the segment chain to what the Xen host side can handle after defragmentation. * Add barriers and flush support to blkfront. Netfront changes have been merged to stable branches, blkfront changes are only in head. Open tasks: 1. Merge remaining changes into head. __________________________________________________________________ Xfce/FreeBSD URL: https://wiki.freebsd.org/Xfce Contact: FreeBSD Xfce Team The FreeBSD Xfce Team has updated its ports to the latest stable releases, especially: * Core (mostly bugfixes and translation updates): * deskutils/xfce4-tumbler (0.1.29) * x11-wm/xfce4-panel (4.10.1) * sysutils/xfce4-settings (4.10.1) * x11-wm/xfce4-session (4.10.1) * sysutils/garcon (0.2.1) * x11/libxfce4util (4.10.1) * x11-wm/xfce4-wm (4.10.1) Applications: * multimedia/xfce4-parole (0.5.1) * www/midori (0.5.2) * deskutils/xfce4-notifyd (0.2.4) * misc/xfce4-appfinder (4.10.1) * x11/xfce4-terminal (0.6.2) * x11-fm/thunar (1.6.3) Panel plugins: * deskutils/xfce4-xkb-plugin (0.5.6) * textproc/xfce4-dict-plugin (0.7.0) * x11-clocks/xfce4-timer-plugin (1.5.0) * x11/xfce4-embed-plugin (new) Thunar plugins: * audio/thunar-media-tags-plugin (0.2.1) * archivers/thunar-archive-plugin (0.3.1) x11/xfce4-embed-plugin can integrate any application window into the Xfce panel. A new plugin is also available which monitors and displays earthquakes, it is called xfce4-equake-plugin. Open tasks: 1. Fix CPU issue with textproc/xfce4-dict-plugin (bug #10103). 2. Investigate why midori-gtk3 crashes too often. (The port is finished, but some libraries are not present by default in ports tree). 3. Fix x11-themes/gtk-xfce-engine with Gtk+ >=3D3.6. __________________________________________________________________ xorg on FreeBSD URL: http://wiki.freebsd.org/Xorg URL: http://trillian.chruetertee.ch/ports/browser/trunk Contact: Contact: Niclas Zeising Contact: Koop Mast During the beginning of this quarter, work focused on making the xorg update as robust and stable as possible in preparation for the merge to ports. As a part of this, ports exp-runs were performed to find and resolve regressions and other issues. Once this was completed, xorg was updated to version 7.7 on May 25, after more than a year of hard work. After the update, work immediately shifted to focus on updating and patching xorg client libraries, since numerous security issues had been identified in those. Unfortunately, this took a little longer than anticipated, but all fixes were comitted eventually. There has also been work on making the new xorg distribution the default for FreeBSD 9.1 and later. A patch was sent out and tested with good results, but this is currently postponed because switching virtual terminals is not working with the KMS driver. Currently, work is focusing on keeping xorg drivers and libraries up to date. Instead of making big updates every year or less, minor updates to some libraries, applications and drivers happen fairly regularly. Focus is also starting to shift towards newer versions of MESA and xorg-server, but this is still very experimental. Open tasks: 1. Continue the porting effort of recent versions of MESA. This is ongoing work, but integrating this into the development repo is hard work. Once this is completed, and KMS support for ATI is more mature, more testing can be done. 2. Port Wayland. The future of graphical environments in open source operating system seems to be Wayland. This needs to be ported to FreeBSD so that a wider audience can test it, and so that it eventually can be integrated into the ports tree, perhaps as a replacement for the current xorg. 3. Look into replacements for HAL. HAL is used for hot-plugging of devices, but it has been long abandoned by Linux. A replacement, perhaps built on top of devd(8), would be nice to have. This work should be coordinated with the FreeBSD GNOME and KDE teams. __________________________________________________________________ ZFS TRIM and Enhanced BIO_DELETE Support Contact: Pawel Jakub Dawidek Contact: Steven Hartland As of the end of June, FreeBSD's ZFS implementation now includes TRIM support in head, stable/9, and stable/8 branches. This allows ZFS to help maintain high performance on flash-based devices such as SSD's even under high-load conditions. When creating new pools and adding new devices to existing pools it first performs a full-device level TRIM to help ensure optimum starting performance. This behaviour can be overridden by setting the vfs.zfs.vdev.trim_on_init sysctl variable to 0 if for example the disks are new or have already been secure erased, which can also now be done using camcontrol(8) security actions. In order to support TRIM, the kernel requires the underlying device driver supports BIO_DELETE. This is currently mapped through to hardware methods such as ATA TRIM and SCSI UNMAP, which are commonly supported by SSDs via CAM. In order to increase the supported hardware base, CAM's SCSI layer was also enhanced to allow ATA TRIM via SATL ATA Passthrough to be used in addition to the existing UNMAP and WS methods. This allows SATA disks attached to SCSI controllers with CAM based drivers such as mps(4) and mpt(4) to provide delete support. Stats for ZFS TRIM can be monitored by looking at the sysctl variables under kstat.zfs.misc.zio_trim in addition to live GEOM delete stats via the gstat -d command. This project was sponsored by Multiplay and implemented by Pawel Jakub Dawidek. __________________________________________________________________ From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 16 12:12:29 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 610B9C03 for ; Tue, 16 Jul 2013 12:12:29 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) by mx1.freebsd.org (Postfix) with ESMTP id EE4981C6 for ; Tue, 16 Jul 2013 12:12:28 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id t56so528924wes.21 for ; Tue, 16 Jul 2013 05:12:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=Q4xOgm1ZmIa1gzfeQZffZk/+lamUJs8KtvthSIg7oIo=; b=iGlx3OVWKRoW6bgoSqvug9YpmAKPSmgViESYhLXbZppGpdOCKoDvtRkxhWsixMr4YU ApIl0RCqePUa16w0ddBKb2kbS95dG27yGGbxuin1p4ydveZyUWFOkw+cY9ZCtyunRCSB +ctZjwtSpMzcafKDk4Tx9oIAFUyxhcm+et42aX6qpkfkm9+t0lyDu60YmZvVSC7ZgBPL goXvfpnODwnswGzUqKJG+Sc/hSt2ZU9zvwGIcJDErdZPTYgmHX9kkMpHIAoU/6Q8Id5l z9H9nAGLiR2VT3/N3U/hS10EDpMseaJ9LN/uAeq3Ji1cpJaRx1NqE92MMYZkCuLVuBkH 9s0w== X-Received: by 10.180.98.4 with SMTP id ee4mr12065850wib.41.1373975265113; Tue, 16 Jul 2013 04:47:45 -0700 (PDT) Received: from [100.79.37.81] (22.26.90.92.rev.sfr.net. [92.90.26.22]) by mx.google.com with ESMTPSA id w4sm1833990wia.9.2013.07.16.04.47.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Jul 2013 04:47:44 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <770208FD-4DB8-43FD-A85F-A6C2A97B68ED@my.gd> X-Mailer: iPhone Mail (10B144) From: Damien Fleuriot Subject: Re: ***HELP*** Date: Tue, 16 Jul 2013 13:46:19 +0200 To: West Side Family X-Gm-Message-State: ALoCoQkAlFW+wLOUHH3OgiwKaz0LbPcuLL3+A7VSdmxTIplJ545gCEcsom5gNxiJQMMrku2EJ13t Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 12:12:29 -0000 I'VE DONE IT FOR YOU BRO, THE PASSWORD IS "4hLoLum4dBr0", MAKE SURE TO ENTER= IT ALL IN CAPS LOCK EVEN THE NUMBERS OR IT WON'T WORK. IF THAT WORKED FOR YOU MAKE SURE TO SEND MONEY VIA PAYPAL TO oHg4wdwHY@freeb= sd.org. AGAIN MAKE SURE YOU TYPE IT ALL IN CAPS LOCK BRO OR IT WON'T WORK !!!1! I NEED TO GET BACK TO MY BROS SEE YOU BRO On 16 Jul 2013, at 01:30, West Side Family wr= ote: > I Need help from all of you guys for this site www.zoo.g ( Admin.zoo.gr= ) to broke up the password!!! THANKS=20 > =20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 16 15:33:37 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 10D1CE55 for ; Tue, 16 Jul 2013 15:33:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id AFC28E92 for ; Tue, 16 Jul 2013 15:33:36 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 11BC4B964; Tue, 16 Jul 2013 11:33:36 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Kernel crashes after sleep: how to debug? Date: Tue, 16 Jul 2013 11:07:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <51E3A334.8020203@rawbw.com> In-Reply-To: <51E3A334.8020203@rawbw.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201307161107.37460.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 16 Jul 2013 11:33:36 -0400 (EDT) Cc: Yuri X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 15:33:37 -0000 On Monday, July 15, 2013 3:22:28 am Yuri wrote: > > After sleep/wakeup cycle my 9.1-STABLE r253105 amd64 system has a > tendency to sometimes randomly crash after a while. It doesn't happen > every time. > See kgdb log below. I am not sure there is enough information to lead to > the cause of the issue. > > It looks like it crashes near the line: > #7 0xffffffff8091a181 in _mtx_trylock (m=0x100000000, opts=0, > file=, line=0) at /usr/src/sys/kern/kern_mutex.c:295 > 295 if (SCHEDULER_STOPPED()) > Current language: auto; currently c > (kgdb) l > 290 uint64_t waittime = 0; > 291 int contested = 0; > 292 #endif > 293 int rval; > 294 > 295 if (SCHEDULER_STOPPED()) > 296 return (1); > 297 > 298 KASSERT(m->mtx_lock != MTX_DESTROYED, > 299 ("mtx_trylock() of destroyed mutex @ %s:%d", file, > line)); > > Current thread was: > * 67 Thread 100064 (PID=5: pagedaemon) doadump (textdump= optimized out>) at pcpu.h:234 > > How to find the cause of the crash? > > Yuri > > > --- kgdb log --- > # kgdb /boot/kernel/kernel vmcore.0 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x100000018 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff8091a181 > stack pointer = 0x28:0xffffff80d51c6ab0 > frame pointer = 0x28:0xffffff80d51c6ad0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 5 (pagedaemon) > trap number = 12 > panic: page fault > cpuid = 0 > KDB: stack backtrace: > #0 0xffffffff80968416 at kdb_backtrace+0x66 > #1 0xffffffff8092e43e at panic+0x1ce > #2 0xffffffff80d12940 at trap_fatal+0x290 > #3 0xffffffff80d12ca1 at trap_pfault+0x211 > #4 0xffffffff80d13254 at trap+0x344 > #5 0xffffffff80cfc583 at calltrap+0x8 > #6 0xffffffff80baea78 at vm_pageout+0x998 > #7 0xffffffff808fc10f at fork_exit+0x11f > #8 0xffffffff80cfcaae at fork_trampoline+0xe > Uptime: 2h21m27s > Dumping 407 out of 2919 MB:..4%..12%..24%..32%..44%..52%..63%..71%..83%..91% > > Reading symbols from /boot/modules/cuse4bsd.ko...done. > Loaded symbols for /boot/modules/cuse4bsd.ko > Reading symbols from /boot/kernel/linux.ko...Reading symbols from > /boot/kernel/linux.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/linux.ko > Reading symbols from /usr/local/libexec/linux_adobe/linux_adobe.ko...done. > Loaded symbols for /usr/local/libexec/linux_adobe/linux_adobe.ko > Reading symbols from /boot/kernel/radeon.ko...Reading symbols from > /boot/kernel/radeon.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/radeon.ko > Reading symbols from /boot/kernel/drm.ko...Reading symbols from > /boot/kernel/drm.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/drm.ko > #0 doadump (textdump=) at pcpu.h:234 > 234 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump (textdump=) at pcpu.h:234 > #1 0xffffffff8092df16 in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:449 > #2 0xffffffff8092e417 in panic (fmt=0x1
) at > /usr/src/sys/kern/kern_shutdown.c:637 > #3 0xffffffff80d12940 in trap_fatal (frame=0xc, eva= out>) at /usr/src/sys/amd64/amd64/trap.c:879 > #4 0xffffffff80d12ca1 in trap_pfault (frame=0xffffff80d51c6a00, > usermode=0) at /usr/src/sys/amd64/amd64/trap.c:795 > #5 0xffffffff80d13254 in trap (frame=0xffffff80d51c6a00) at > /usr/src/sys/amd64/amd64/trap.c:463 > #6 0xffffffff80cfc583 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:232 > #7 0xffffffff8091a181 in _mtx_trylock (m=0x100000000, opts=0, > file=, line=0) at /usr/src/sys/kern/kern_mutex.c:295 > #8 0xffffffff80baea78 in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:829 > #9 0xffffffff808fc10f in fork_exit (callout=0xffffffff80bae0e0 > , arg=0x0, frame=0xffffff80d51c6c40) > at /usr/src/sys/kern/kern_fork.c:988 > #10 0xffffffff80cfcaae in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:606 > #11 0x0000000000000000 in ?? () Can you go to frame 8 and do 'l' in kgdb? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 16 15:38:44 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2D8E421E for ; Tue, 16 Jul 2013 15:38:44 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id D92B9F09 for ; Tue, 16 Jul 2013 15:38:43 +0000 (UTC) Received: by mail-vc0-f172.google.com with SMTP id ib11so569932vcb.17 for ; Tue, 16 Jul 2013 08:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=iyjhjGFKyvTc9mcjEcMqfYMajQknww7M3I2snWDz9G0=; b=JkPb9d6BiYUv/Njb2Ab7K0NBMN7I+bXMlFJCuI71KA1DIQL2NV2KmpkBeqFpm+MJEM 7DDa8m9A+ESxk+Zw1nEMmpATi6SBs0xdMxRTvUB29LEuCmDwjk/5vP2G7Tr2Au0ZFt80 ml/8Sa/z8XFUBmkCluaV4PC/orjQi/qYi8iys= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=iyjhjGFKyvTc9mcjEcMqfYMajQknww7M3I2snWDz9G0=; b=NhipIhRy3pdDkge5bpzOYCupgcCV11YltfDRFF8qRombQ3IXC9J/K70hjadaInko1N hAaufbF73k+Jrmd7Afa+i5sUe+ffMR2OdPpMhMk7Qrby6y3Vl9PFDuJIDLPy4XVydL9Y 3CmErFkADcivV7sRXmjK9esFJ2OAG3pIw5Q8qNHzmXRL5d4adwn4LzPAMZGjjFfbhWsZ 1fbVsGGZcM3T4g99gbQJ1ChYvAqXJsKAMO1MXitfxXPtY7AEvLRz9oUjhG/eVbW8tbVT 341XGfCMJta9GA2/AvWmPen6p1U2ujf9K34Kf1FsvSv6ZhJY3jNvrUv73yXGR5WrXVu8 V7YA== X-Received: by 10.58.165.70 with SMTP id yw6mr630654veb.19.1373989123324; Tue, 16 Jul 2013 08:38:43 -0700 (PDT) Received: from [192.168.31.72] (68-188-148-148.dhcp.aldl.mi.charter.com. [68.188.148.148]) by mx.google.com with ESMTPSA id ir5sm337419veb.6.2013.07.16.08.38.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Jul 2013 08:38:42 -0700 (PDT) References: <770208FD-4DB8-43FD-A85F-A6C2A97B68ED@my.gd> Mime-Version: 1.0 (1.0) In-Reply-To: <770208FD-4DB8-43FD-A85F-A6C2A97B68ED@my.gd> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-B83185E9-03D3-4FCB-B421-F1B33A7B7B1B; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B329) From: Jason Hellenthal Subject: Re: ***HELP*** Date: Tue, 16 Jul 2013 11:38:37 -0400 To: Damien Fleuriot X-Gm-Message-State: ALoCoQn5/OLP2e8MShy5u4KS6LR9cU7BNB49n0kCVtlJfYkArFpPUYYTa+DFaBG94uJv88Vpgg/l X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 15:38:44 -0000 --Apple-Mail-B83185E9-03D3-4FCB-B421-F1B33A7B7B1B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Lol --=20 Jason Hellenthal Inbox: jhellenthal@DataIX.net Voice: +1 (616) 953-0176 JJH48-ARIN On Jul 16, 2013, at 7:46, Damien Fleuriot wrote: > I'VE DONE IT FOR YOU BRO, THE PASSWORD IS "4hLoLum4dBr0", MAKE SURE TO ENT= ER IT ALL IN CAPS LOCK EVEN THE NUMBERS OR IT WON'T WORK. >=20 >=20 > IF THAT WORKED FOR YOU MAKE SURE TO SEND MONEY VIA PAYPAL TO oHg4wdwHY@fre= ebsd.org. >=20 > AGAIN MAKE SURE YOU TYPE IT ALL IN CAPS LOCK BRO OR IT WON'T WORK !!!1! >=20 >=20 > I NEED TO GET BACK TO MY BROS SEE YOU BRO >=20 >=20 > On 16 Jul 2013, at 01:30, West Side Family w= rote: >=20 >> I Need help from all of you guys for this site www.zoo.g ( Admin.zoo.g= r ) to broke up the password!!! THANKS=20 >>=20 >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= --Apple-Mail-B83185E9-03D3-4FCB-B421-F1B33A7B7B1B Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGNDCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYxggNvMIIDawIBATCB lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEg UHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wCQYFKw4DAhoFAKCCAa8wGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNzE2MTUzODM5WjAjBgkqhkiG 9w0BCQQxFgQUtejhZ5k9+E8jpUfS77lqHKFOMJEwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IElu dGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaijjANBgkqhkiG9w0BAQEFAASCAQAv/C1yc07waz53Dx2d R6SMw1xXnoaP521ezog7+yjnMeQqvldN/eLwVV6A+3cyTQYlukVYQILFrVbOQsO5Py6Ef+BJgpHy zvoS0G7O7kJ0mJf2WYRuy7QiCXoa8rg6xMbT14unOMHptHBG3aLcd+BCqK7hua4YZW5wJfut92Cy Y8sSv6dn5Sqes/uShoL+CZiV8R2OcAPCZzYc1TVypa8+V55rE5iAGt/tWziLJZ9mvm8Gr9IzScKX i0HsFOxqJTxNy3KcH9zmQ6J7u9oka7n7j9hkDwiopzDHPghbTyZ5pK3gcGYzi1f6R4YHp6HLXJtu gZWbEBgT5sbOd13V579AAAAAAAAA --Apple-Mail-B83185E9-03D3-4FCB-B421-F1B33A7B7B1B-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 18 18:15:54 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 358C33D4; Thu, 18 Jul 2013 18:15:54 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 25FAEE5B; Thu, 18 Jul 2013 18:15:54 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r6IIFmox006235; Thu, 18 Jul 2013 11:15:48 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <51E830D4.7060302@rawbw.com> Date: Thu, 18 Jul 2013 11:15:48 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Baldwin Subject: Re: Kernel crashes after sleep: how to debug? References: <51E3A334.8020203@rawbw.com> <201307161107.37460.jhb@freebsd.org> In-Reply-To: <201307161107.37460.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 18:15:54 -0000 On 07/16/2013 08:07, John Baldwin wrote: > Can you go to frame 8 and do 'l' in kgdb? (kgdb) up 8 #8 0xffffffff80baea78 in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:829 829 if (!VM_OBJECT_TRYLOCK(object) && (kgdb) l 824 if (!vm_pageout_page_lock(m, &next)) { 825 vm_page_unlock(m); 826 continue; 827 } 828 object = m->object; 829 if (!VM_OBJECT_TRYLOCK(object) && 830 !vm_pageout_fallback_object_lock(m, &next)) { 831 vm_page_unlock(m); 832 VM_OBJECT_UNLOCK(object); 833 continue; From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 18 18:42:55 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DE4CAD7A; Thu, 18 Jul 2013 18:42:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id BB8EAF85; Thu, 18 Jul 2013 18:42:55 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1F0C9B939; Thu, 18 Jul 2013 14:42:55 -0400 (EDT) From: John Baldwin To: Yuri Subject: Re: Kernel crashes after sleep: how to debug? Date: Thu, 18 Jul 2013 14:42:35 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <51E3A334.8020203@rawbw.com> <201307161107.37460.jhb@freebsd.org> <51E830D4.7060302@rawbw.com> In-Reply-To: <51E830D4.7060302@rawbw.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201307181442.35401.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 18 Jul 2013 14:42:55 -0400 (EDT) Cc: Alan Cox , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 18:42:55 -0000 On Thursday, July 18, 2013 2:15:48 pm Yuri wrote: > On 07/16/2013 08:07, John Baldwin wrote: > > Can you go to frame 8 and do 'l' in kgdb? > > (kgdb) up 8 > #8 0xffffffff80baea78 in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:829 > 829 if (!VM_OBJECT_TRYLOCK(object) && > (kgdb) l > 824 if (!vm_pageout_page_lock(m, &next)) { > 825 vm_page_unlock(m); > 826 continue; > 827 } > 828 object = m->object; > 829 if (!VM_OBJECT_TRYLOCK(object) && > 830 !vm_pageout_fallback_object_lock(m, &next)) { > 831 vm_page_unlock(m); > 832 VM_OBJECT_UNLOCK(object); > 833 continue; Hmm, so this seems to indicate you have a page on the active queue that doesn't have an associated VM object. Can you maybe 'p *m'? Maybe some temporary page is allocated during suspend but isn't freed appropriately? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 18 19:56:47 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 73F54BC4; Thu, 18 Jul 2013 19:56:47 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 482B35E4; Thu, 18 Jul 2013 19:56:46 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r6IJukKh036011; Thu, 18 Jul 2013 12:56:46 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <51E8487E.40800@rawbw.com> Date: Thu, 18 Jul 2013 12:56:46 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Baldwin Subject: Re: Kernel crashes after sleep: how to debug? References: <51E3A334.8020203@rawbw.com> <201307161107.37460.jhb@freebsd.org> <51E830D4.7060302@rawbw.com> <201307181442.35401.jhb@freebsd.org> In-Reply-To: <201307181442.35401.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alan Cox , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 19:56:47 -0000 On 07/18/2013 11:42, John Baldwin wrote: > Hmm, so this seems to indicate you have a page on the active queue that > doesn't have an associated VM object. Can you maybe 'p *m'? Maybe some > temporary page is allocated during suspend but isn't freed appropriately? Unfortunately, I get this: (kgdb) p *m No symbol "m" in current context. even though kernel was built with "makeoptions DEBUG=-g", same for other symbols there. Is there a way to identify when and by whom the page has been allocated? Yuri From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 18 20:52:58 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5AAC4CEA; Thu, 18 Jul 2013 20:52:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2C3D18C7; Thu, 18 Jul 2013 20:52:58 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 00625B964; Thu, 18 Jul 2013 16:52:53 -0400 (EDT) From: John Baldwin To: Yuri Subject: Re: Kernel crashes after sleep: how to debug? Date: Thu, 18 Jul 2013 16:52:48 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <51E3A334.8020203@rawbw.com> <201307181442.35401.jhb@freebsd.org> <51E8487E.40800@rawbw.com> In-Reply-To: <51E8487E.40800@rawbw.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201307181652.48757.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 18 Jul 2013 16:52:54 -0400 (EDT) Cc: Alan Cox , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 20:52:58 -0000 On Thursday, July 18, 2013 3:56:46 pm Yuri wrote: > On 07/18/2013 11:42, John Baldwin wrote: > > Hmm, so this seems to indicate you have a page on the active queue that > > doesn't have an associated VM object. Can you maybe 'p *m'? Maybe some > > temporary page is allocated during suspend but isn't freed appropriately? > > Unfortunately, I get this: > (kgdb) p *m > No symbol "m" in current context. > > even though kernel was built with "makeoptions DEBUG=-g", same for > other symbols there. > > Is there a way to identify when and by whom the page has been allocated? Are you in frame 8? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 18 21:04:23 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8FC921ED; Thu, 18 Jul 2013 21:04:23 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 64DCD938; Thu, 18 Jul 2013 21:04:23 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r6IL4KFC055301; Thu, 18 Jul 2013 14:04:20 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <51E85854.2010408@rawbw.com> Date: Thu, 18 Jul 2013 14:04:20 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Baldwin Subject: Re: Kernel crashes after sleep: how to debug? References: <51E3A334.8020203@rawbw.com> <201307181442.35401.jhb@freebsd.org> <51E8487E.40800@rawbw.com> <201307181652.48757.jhb@freebsd.org> In-Reply-To: <201307181652.48757.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alan Cox , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 21:04:23 -0000 On 07/18/2013 13:52, John Baldwin wrote: > Are you in frame 8? Yes. Yuri From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 19 00:56:59 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 75154498; Fri, 19 Jul 2013 00:56:59 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 4969832C; Fri, 19 Jul 2013 00:56:59 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r6J0uwR2014890; Thu, 18 Jul 2013 17:56:58 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <51E88EDA.50000@rawbw.com> Date: Thu, 18 Jul 2013 17:56:58 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Baldwin Subject: Re: Kernel crashes after sleep: how to debug? References: <51E3A334.8020203@rawbw.com> <201307181442.35401.jhb@freebsd.org> <51E8487E.40800@rawbw.com> <201307181652.48757.jhb@freebsd.org> In-Reply-To: <201307181652.48757.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alan Cox , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 00:56:59 -0000 On 07/18/2013 13:52, John Baldwin wrote: > Are you in frame 8? For some reason the debug info is missing in frame 8, but is present in surrounding frames 7 and 9. The might be a bug in makefiles that debug flag isn't passed into sys/vm/ directory. Yuri From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 19 15:29:15 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F1B3CE12; Fri, 19 Jul 2013 15:29:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id D0DABFCA; Fri, 19 Jul 2013 15:29:15 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3496BB94C; Fri, 19 Jul 2013 11:29:15 -0400 (EDT) From: John Baldwin To: Yuri Subject: Re: Kernel crashes after sleep: how to debug? Date: Fri, 19 Jul 2013 11:00:08 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <51E3A334.8020203@rawbw.com> <201307181652.48757.jhb@freebsd.org> <51E88EDA.50000@rawbw.com> In-Reply-To: <51E88EDA.50000@rawbw.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201307191100.08549.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Jul 2013 11:29:15 -0400 (EDT) Cc: Alan Cox , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 15:29:16 -0000 On Thursday, July 18, 2013 8:56:58 pm Yuri wrote: > On 07/18/2013 13:52, John Baldwin wrote: > > Are you in frame 8? > > For some reason the debug info is missing in frame 8, but is present in > surrounding frames 7 and 9. > The might be a bug in makefiles that debug flag isn't passed into > sys/vm/ directory. Well, you can probably find the value of 'm' in a register if you look at the dissassembly around the fault. You can then cast that pointer to the right type and print its contents. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 19 17:45:14 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F39469B9 for ; Fri, 19 Jul 2013 17:45:13 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 791618E0 for ; Fri, 19 Jul 2013 17:45:13 +0000 (UTC) Received: by mail-ea0-f171.google.com with SMTP id m14so2515852eaj.16 for ; Fri, 19 Jul 2013 10:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:x-mailer; bh=DMEyeBKPEqsn1qM45tLl/dJ2kGbFOdU5IB/DYT3O5Fo=; b=XwtyjgYHMgVh0wHDzbZ0rzanidHh3ERuP9JM6DC4PlKyUwKGutcfQ1EzPvRx/eeq+M iJz8lS+rixogP1S8I1orBpEF5YkV5XgYGVXlLK0mwbtvqIK+i7b93F0Af+m6QJSQaACU pm9imasmMC0/foSrP54ofMHrG8PBT26QdLDI61KEDV2kyWXsupnAW9uJ6v1bFyjplbEy oYO3VcsLUbnCc3u4aZ8D0NJwpMs9arqlsPhVxp9fH+su4auxokWBS3cyilm6lIKpuNJS h747qo1fZ2LZAsfQJpdV+tdP6HTSBjHX8La9ce8FiWUdfIRZe7nvp8ZZ9Pw0247yD0F8 HKNQ== X-Received: by 10.15.107.6 with SMTP id ca6mr16779907eeb.120.1374255912675; Fri, 19 Jul 2013 10:45:12 -0700 (PDT) Received: from DOMYPC (78-2-157-252.adsl.net.t-com.hr. [78.2.157.252]) by mx.google.com with ESMTPSA id a4sm29191374eez.0.2013.07.19.10.45.10 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 19 Jul 2013 10:45:11 -0700 (PDT) Message-ID: <20130719.174511.786.3@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Subject: UFS related panic (daily <-> find) Date: Fri, 19 Jul 2013 19:45:11 +0200 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable X-Mailer: POP Peeper (3.8.1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:45:14 -0000 I had 2 panics: (Both occured at 3 AM, so had to be daily = task)=0D=0A=0D=0AFirst (Jul 2 03:06:50 2013):=0D=0A--=0D=0AFatal trap = 12: page fault while in kernel mode=0D=0Afault virtual address =3D = 0x19=0D=0Afault code =3D supervisor read, page not = present=0D=0Ainstruction pointer =3D 0x20:0xc06caf34=0D=0Astack = pointer =3D 0x28:0xe76248fc=0D=0Aframe pointer =3D = 0x28:0xe7624930=0D=0Acode segment =3D base 0x0, limit 0xfffff, = type 0x1b=0D=0A =3D DPL 0, pres 1, def32 1, gran = 1=0D=0Aprocessor eflags =3D interrupt enabled, resume, IOPL =3D = 0=0D=0Acurrent process =3D 76562 (find)=0D=0Atrap number = =3D 12=0D=0Apanic: page fault=0D=0AUptime: 23h0m41s=0D=0APhysical = memory: 1014 MB=0D=0ADumping 186 MB: 171 155 139 123 107 91 75 59 43 27 = 11=0D=0A=0D=0ANo symbol "stopped_cpus" in current context.=0D=0ANo symbol = "stoppcbs" in current context.=0D=0AReading symbols from = /boot/kernel/nfscl.ko...Reading symbols from = /boot/kernel/nfscl.ko.symbols...done.=0D=0Adone.=0D=0ALoaded symbols for = /boot/kernel/nfscl.ko=0D=0AReading symbols from = /boot/kernel/nfslock.ko...Reading symbols from = /boot/kernel/nfslock.ko.symbols...done.=0D=0Adone.=0D=0ALoaded symbols = for /boot/kernel/nfslock.ko=0D=0AReading symbols from = /boot/kernel/nfssvc.ko...Reading symbols from = /boot/kernel/nfssvc.ko.symbols...done.=0D=0Adone.=0D=0ALoaded symbols for = /boot/kernel/nfssvc.ko=0D=0AReading symbols from = /boot/kernel/krpc.ko...Reading symbols from = /boot/kernel/krpc.ko.symbols...done.=0D=0Adone.=0D=0ALoaded symbols for = /boot/kernel/krpc.ko=0D=0AReading symbols from = /boot/kernel/nfscommon.ko...Reading symbols from = /boot/kernel/nfscommon.ko.symbols...done.=0D=0Adone.=0D=0ALoaded symbols = for /boot/kernel/nfscommon.ko=0D=0AReading symbols from = /boot/kernel/nfsd.ko...Reading symbols from = /boot/kernel/nfsd.ko.symbols...done.=0D=0Adone.=0D=0ALoaded symbols for = /boot/kernel/nfsd.ko=0D=0AReading symbols from = /boot/kernel/nfslockd.ko...Reading symbols from = /boot/kernel/nfslockd.ko.symbols...done.=0D=0Adone.=0D=0ALoaded symbols = for /boot/kernel/nfslockd.ko=0D=0AReading symbols from = /usr/local/modules/fuse.ko...done.=0D=0ALoaded symbols for = /usr/local/modules/fuse.ko=0D=0AReading symbols from = /usr/local/lib/oss/modules/osscore.ko...done.=0D=0ALoaded symbols for = /usr/local/lib/oss/modules/osscore.ko=0D=0AReading symbols from = /usr/local/lib/oss/modules/oss_audigyls.ko...done.=0D=0ALoaded symbols = for /usr/local/lib/oss/modules/oss_audigyls.ko=0D=0AReading symbols from = /boot/kernel/cpuctl.ko...Reading symbols from = /boot/kernel/cpuctl.ko.symbols...done.=0D=0Adone.=0D=0ALoaded symbols for = /boot/kernel/cpuctl.ko=0D=0AReading symbols from = /boot/kernel/nullfs.ko...Reading symbols from = /boot/kernel/nullfs.ko.symbols...done.=0D=0Adone.=0D=0ALoaded symbols for = /boot/kernel/nullfs.ko=0D=0AReading symbols from = /boot/kernel/if_urtw.ko...Reading symbols from = /boot/kernel/if_urtw.ko.symbols...done.=0D=0Adone.=0D=0ALoaded symbols = for /boot/kernel/if_urtw.ko=0D=0A#0 doadump (textdump=3D1) at = pcpu.h:244=0D=0A244 pcpu.h: No such file or directory.=0D=0A = in pcpu.h=0D=0A(kgdb) #0 doadump (textdump=3D1) at pcpu.h:244=0D=0A#1 = 0xc06564e9 in kern_reboot (howto=3D260)=0D=0A at = /usr/src/sys/kern/kern_shutdown.c:448=0D=0A#2 0xc065671f in panic = (fmt=3DVariable "fmt" is not available.=0D=0A) at = /usr/src/sys/kern/kern_shutdown.c:636=0D=0A#3 0xc08aa88a in trap_fatal = (frame=3D0xe76248bc, eva=3D25)=0D=0A at = /usr/src/sys/i386/i386/trap.c:1018=0D=0A#4 0xc08aa974 in trap_pfault = (frame=3D0xe76248bc, usermode=3D0, eva=3D25)=0D=0A at = /usr/src/sys/i386/i386/trap.c:870=0D=0A#5 0xc08ab621 in trap = (frame=3D0xe76248bc) at /usr/src/sys/i386/i386/trap.c:545=0D=0A#6 = 0xc0898c5c in calltrap () at = /usr/src/sys/i386/i386/exception.s:169=0D=0A#7 0xc06caf34 in = cache_lookup_times (dvp=3D0xc784a990, vpp=3D0xe7624ae8,=0D=0A = cnp=3D0xe7624afc, tsp=3D0x0, ticksp=3D0x0) at = /usr/src/sys/kern/vfs_cache.c:547=0D=0A#8 0xc06cb752 in vfs_cache_lookup = (ap=3D0xe76249e4)=0D=0A at /usr/src/sys/kern/vfs_cache.c:1032=0D=0A#9 = 0xc08c3e91 in VOP_LOOKUP_APV (vop=3D0xc0983520, a=3D0xe76249e4)=0D=0A = at vnode_if.c:123=0D=0A#10 0xc06d2e24 in lookup (ndp=3D0xe7624abc) at = vnode_if.h:54=0D=0A#11 0xc06d3dd2 in namei (ndp=3D0xe7624abc) at = /usr/src/sys/kern/vfs_lookup.c:297=0D=0A#12 0xc06e54e3 in = kern_statat_vnhook (td=3D0xc47e35c0, flag=3D512, fd=3D-100,=0D=0A = path=3D0x284f3cb8
,=0D=0A = pathseg=3DUIO_USERSPACE, sbp=3D0xe7624be8, hook=3D0)=0D=0A at = /usr/src/sys/kern/vfs_syscalls.c:2432=0D=0A#13 0xc06e562c in kern_statat = (td=3D0xc47e35c0, flag=3D512, fd=3D-100,=0D=0A path=3D0x284f3cb8 =
,=0D=0A pathseg=3DUIO_USERSPACE, = sbp=3D0xe7624be8)=0D=0A at = /usr/src/sys/kern/vfs_syscalls.c:2413=0D=0A#14 0xc06e5664 in kern_lstat = (td=3D0xc47e35c0,=0D=0A path=3D0x284f3cb8
,=0D=0A pathseg=3DUIO_USERSPACE, sbp=3D0xe7624be8)=0D=0A at = /usr/src/sys/kern/vfs_syscalls.c:2486=0D=0A#15 0xc06e56f8 in sys_lstat = (td=3D0xc47e35c0, uap=3D0xe7624ccc)=0D=0A at = /usr/src/sys/kern/vfs_syscalls.c:2476=0D=0A#16 0xc08aae52 in syscall = (frame=3D0xe7624d08) at subr_syscall.c:135=0D=0A#17 0xc0898cc1 in = Xint0x80_syscall ()=0D=0A at = /usr/src/sys/i386/i386/exception.s:267=0D=0A#18 0x00000033 in ?? = ()=0D=0APrevious frame inner to this frame (corrupt = stack?)=0D=0A(kgdb)=0D=0A=0D=0A=0D=0ASecond (Jul 18 03:06:38 = 2013):=0D=0A--=0D=0AFatal trap 12: page fault while in kernel = mode=0D=0Afault virtual address =3D 0x19=0D=0Afault code = =3D supervisor read, page not present=0D=0Ainstruction pointer =3D = 0x20:0xc06caf34=0D=0Astack pointer =3D = 0x28:0xe76e98fc=0D=0Aframe pointer =3D = 0x28:0xe76e9930=0D=0Aath0: stuck beacon; resetting (bmiss count = 4)=0D=0Acode segment =3D base 0x0, limit 0xfffff, type = 0x1b=0D=0A =3D DPL 0, pres 1, def32 1, gran = 1=0D=0Aprocessor eflags =3D interrupt enabled, resume, IOPL =3D = 0=0D=0Acurrent process =3D 44985 (find)=0D=0Atrap number = =3D 12=0D=0Apanic: page fault=0D=0AUptime: 2d11h46m24s=0D=0APhysical = memory: 1014 MB=0D=0ADumping 207 MB: 192 176 160 144 128 112 96 80 64 48 = 32 16=0D=0A=0D=0ANo symbol "stopped_cpus" in current context.=0D=0ANo = symbol "stoppcbs" in current context.=0D=0AReading symbols from = /boot/kernel/nfscl.ko...Reading symbols from = /boot/kernel/nfscl.ko.symbols...done.=0D=0Adone.=0D=0ALoaded symbols for = /boot/kernel/nfscl.ko=0D=0AReading symbols from = /boot/kernel/nfslock.ko...Reading symbols from = /boot/kernel/nfslock.ko.symbols...done.=0D=0Adone.=0D=0ALoaded symbols = for /boot/kernel/nfslock.ko=0D=0AReading symbols from = /boot/kernel/nfssvc.ko...Reading symbols from = /boot/kernel/nfssvc.ko.symbols...done.=0D=0Adone.=0D=0ALoaded symbols for = /boot/kernel/nfssvc.ko=0D=0AReading symbols from = /boot/kernel/krpc.ko...Reading symbols from = /boot/kernel/krpc.ko.symbols...done.=0D=0Adone.=0D=0ALoaded symbols for = /boot/kernel/krpc.ko=0D=0AReading symbols from = /boot/kernel/nfscommon.ko...Reading symbols from = /boot/kernel/nfscommon.ko.symbols...done.=0D=0Adone.=0D=0ALoaded symbols = for /boot/kernel/nfscommon.ko=0D=0AReading symbols from = /boot/kernel/nfsd.ko...Reading symbols from = /boot/kernel/nfsd.ko.symbols...done.=0D=0Adone.=0D=0ALoaded symbols for = /boot/kernel/nfsd.ko=0D=0AReading symbols from = /boot/kernel/nfslockd.ko...Reading symbols from = /boot/kernel/nfslockd.ko.symbols...done.=0D=0Adone.=0D=0ALoaded symbols = for /boot/kernel/nfslockd.ko=0D=0AReading symbols from = /usr/local/modules/fuse.ko...done.=0D=0ALoaded symbols for = /usr/local/modules/fuse.ko=0D=0AReading symbols from = /usr/local/lib/oss/modules/osscore.ko...done.=0D=0ALoaded symbols for = /usr/local/lib/oss/modules/osscore.ko=0D=0AReading symbols from = /usr/local/lib/oss/modules/oss_audigyls.ko...done.=0D=0ALoaded symbols = for /usr/local/lib/oss/modules/oss_audigyls.ko=0D=0AReading symbols from = /boot/kernel/cpuctl.ko...Reading symbols from = /boot/kernel/cpuctl.ko.symbols...done.=0D=0Adone.=0D=0ALoaded symbols for = /boot/kernel/cpuctl.ko=0D=0A#0 doadump (textdump=3D1) at = pcpu.h:244=0D=0A244 pcpu.h: No such file or directory.=0D=0A = in pcpu.h=0D=0A(kgdb) #0 doadump (textdump=3D1) at pcpu.h:244=0D=0A#1 = 0xc06564e9 in kern_reboot (howto=3D260)=0D=0A at = /usr/src/sys/kern/kern_shutdown.c:448=0D=0A#2 0xc065671f in panic = (fmt=3DVariable "fmt" is not available.=0D=0A) at = /usr/src/sys/kern/kern_shutdown.c:636=0D=0A#3 0xc08aa88a in trap_fatal = (frame=3D0xe76e98bc, eva=3D25)=0D=0A at = /usr/src/sys/i386/i386/trap.c:1018=0D=0A#4 0xc08aa974 in trap_pfault = (frame=3D0xe76e98bc, usermode=3D0, eva=3D25)=0D=0A at = /usr/src/sys/i386/i386/trap.c:870=0D=0A#5 0xc08ab621 in trap = (frame=3D0xe76e98bc) at /usr/src/sys/i386/i386/trap.c:545=0D=0A#6 = 0xc0898c5c in calltrap () at = /usr/src/sys/i386/i386/exception.s:169=0D=0A#7 0xc06caf34 in = cache_lookup_times (dvp=3D0xc7b21660, vpp=3D0xe76e9ae8,=0D=0A = cnp=3D0xe76e9afc, tsp=3D0x0, ticksp=3D0x0) at = /usr/src/sys/kern/vfs_cache.c:547=0D=0A#8 0xc06cb752 in vfs_cache_lookup = (ap=3D0xe76e99e4)=0D=0A at /usr/src/sys/kern/vfs_cache.c:1032=0D=0A#9 = 0xc08c3e91 in VOP_LOOKUP_APV (vop=3D0xc0983520, a=3D0xe76e99e4)=0D=0A = at vnode_if.c:123=0D=0A#10 0xc06d2e24 in lookup (ndp=3D0xe76e9abc) at = vnode_if.h:54=0D=0A#11 0xc06d3dd2 in namei (ndp=3D0xe76e9abc) at = /usr/src/sys/kern/vfs_lookup.c:297=0D=0A#12 0xc06e54e3 in = kern_statat_vnhook (td=3D0xc4fad5c0, flag=3D512, fd=3D-100,=0D=0A = path=3D0x284515b8
,=0D=0A = pathseg=3DUIO_USERSPACE, sbp=3D0xe76e9be8, hook=3D0)=0D=0A at = /usr/src/sys/kern/vfs_syscalls.c:2432=0D=0A#13 0xc06e562c in kern_statat = (td=3D0xc4fad5c0, flag=3D512, fd=3D-100,=0D=0A path=3D0x284515b8 =
,=0D=0A pathseg=3DUIO_USERSPACE, = sbp=3D0xe76e9be8)=0D=0A at = /usr/src/sys/kern/vfs_syscalls.c:2413=0D=0A#14 0xc06e5664 in kern_lstat = (td=3D0xc4fad5c0,=0D=0A path=3D0x284515b8
,=0D=0A pathseg=3DUIO_USERSPACE, sbp=3D0xe76e9be8)=0D=0A at = /usr/src/sys/kern/vfs_syscalls.c:2486=0D=0A#15 0xc06e56f8 in sys_lstat = (td=3D0xc4fad5c0, uap=3D0xe76e9ccc)=0D=0A at = /usr/src/sys/kern/vfs_syscalls.c:2476=0D=0A#16 0xc08aae52 in syscall = (frame=3D0xe76e9d08) at subr_syscall.c:135=0D=0A#17 0xc0898cc1 in = Xint0x80_syscall ()=0D=0A at = /usr/src/sys/i386/i386/exception.s:267=0D=0A#18 0x00000033 in ?? = ()=0D=0APrevious frame inner to this frame (corrupt = stack?)=0D=0A(kgdb)=0D=0A=0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6 From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 19 19:32:44 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 348DD695; Fri, 19 Jul 2013 19:32:44 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 1271AD53; Fri, 19 Jul 2013 19:32:43 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r6JJWhTf031547; Fri, 19 Jul 2013 12:32:43 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <51E9945B.1050907@rawbw.com> Date: Fri, 19 Jul 2013 12:32:43 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Baldwin Subject: Re: Kernel crashes after sleep: how to debug? References: <51E3A334.8020203@rawbw.com> <201307181652.48757.jhb@freebsd.org> <51E88EDA.50000@rawbw.com> <201307191100.08549.jhb@freebsd.org> In-Reply-To: <201307191100.08549.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Alan Cox , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 19:32:44 -0000 On 07/19/2013 08:00, John Baldwin wrote: > Well, you can probably find the value of 'm' in a register if you look at the > dissassembly around the fault. You can then cast that pointer to the right > type and print its contents. Here is the value of *m in frame 8: (kgdb) p *(struct vm_page*)0xfffffe00b460abf8 $3 = {pageq = {tqe_next = 0xfe26, tqe_prev = 0xfffffe00b5a124d8}, listq = {tqe_next = 0xfffffe0081ad8f70, tqe_prev = 0xfffffe0081ad8f78}, left = 0x6, right = 0xd00000201, object = 0x100000000, pindex = 4294901765, phys_addr = 18446741877712530608, md = {pv_list = { tqh_first = 0xfffffe00b460abc0, tqh_last = 0xfffffe00b5579020}, pat_mode = -1268733096}, queue = 72 'H', segind = -85 '�', hold_count = -19360, order = 0 '\0', pool = 254 '�', cow = 65535, wire_count = 0, aflags = 0 '\0', flags = 0 '\0', oflags = 0, act_count = 0 '\0', busy = 176 '�', valid = 208 '�', dirty = 126 '~'} Yuri From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 19 21:04:54 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EF7D4AE3; Fri, 19 Jul 2013 21:04:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id CD716137; Fri, 19 Jul 2013 21:04:54 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3407BB926; Fri, 19 Jul 2013 17:04:54 -0400 (EDT) From: John Baldwin To: Yuri Subject: Re: Kernel crashes after sleep: how to debug? Date: Fri, 19 Jul 2013 17:04:47 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <51E3A334.8020203@rawbw.com> <201307191100.08549.jhb@freebsd.org> <51E9945B.1050907@rawbw.com> In-Reply-To: <51E9945B.1050907@rawbw.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201307191704.47622.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Jul 2013 17:04:54 -0400 (EDT) Cc: Alan Cox , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 21:04:55 -0000 On Friday, July 19, 2013 3:32:43 pm Yuri wrote: > On 07/19/2013 08:00, John Baldwin wrote: > > Well, you can probably find the value of 'm' in a register if you look = at=20 the > > dissassembly around the fault. You can then cast that pointer to the=20 right > > type and print its contents. >=20 > Here is the value of *m in frame 8: > (kgdb) p *(struct vm_page*)0xfffffe00b460abf8 > $3 =3D {pageq =3D {tqe_next =3D 0xfe26, tqe_prev =3D 0xfffffe00b5a124d8},= listq=20 > =3D {tqe_next =3D 0xfffffe0081ad8f70, tqe_prev =3D 0xfffffe0081ad8f78}, > left =3D 0x6, right =3D 0xd00000201, object =3D 0x100000000, pindex =3D=20 > 4294901765, phys_addr =3D 18446741877712530608, md =3D {pv_list =3D { > tqh_first =3D 0xfffffe00b460abc0, tqh_last =3D 0xfffffe00b5579020}, pat_m= ode=20 > =3D -1268733096}, queue =3D 72 'H', segind =3D -85 '=EF=BF=BD', > hold_count =3D -19360, order =3D 0 '\0', pool =3D 254 '=EF=BF=BD', cow = =3D 65535,=20 > wire_count =3D 0, aflags =3D 0 '\0', flags =3D 0 '\0', oflags =3D 0, > act_count =3D 0 '\0', busy =3D 176 '=EF=BF=BD', valid =3D 208 '=EF=BF=BD'= , dirty =3D 126 '~'} Hmm, that definitely looks like garbage. How are you with gdb scripting? You could write a script that walks the PQ_ACTIVE queue and see if this pointers ends up in there. It would then be interesting to see if the previous page's next pointer is corrupted, or if the pageq.tqe_prev referen= ces=20 that page then it could be that this vm_page structure has been stomped on= =20 instead. Ultimately I think you will need to look at any malloc/VM/page operations done in the suspend and resume paths to see where this happens. It might be slightly easier if the same page gets trashed every time as you could print out the relevant field periodically during suspend and resume to narrow down where the breakage occurs. =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 20 02:16:18 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EAE38F24; Sat, 20 Jul 2013 02:16:17 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id BABCCC56; Sat, 20 Jul 2013 02:16:17 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r6K2GGel013105; Fri, 19 Jul 2013 19:16:16 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <51E9F2EF.6000908@rawbw.com> Date: Fri, 19 Jul 2013 19:16:15 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Baldwin Subject: Re: Kernel crashes after sleep: how to debug? References: <51E3A334.8020203@rawbw.com> <201307191100.08549.jhb@freebsd.org> <51E9945B.1050907@rawbw.com> <201307191704.47622.jhb@freebsd.org> In-Reply-To: <201307191704.47622.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Alan Cox , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 02:16:18 -0000 On 07/19/2013 14:04, John Baldwin wrote: > Hmm, that definitely looks like garbage. How are you with gdb scripting? > You could write a script that walks the PQ_ACTIVE queue and see if this > pointers ends up in there. It would then be interesting to see if the > previous page's next pointer is corrupted, or if the pageq.tqe_prev references > that page then it could be that this vm_page structure has been stomped on > instead. As you suggested, I printed the list of pages. Actually, iteration in frame 8 goes through PQ_INACTIVE pages. So I printed those. <...skipped...> ### page#2245 ### $4492 = (struct vm_page *) 0xfffffe00b5a27658 $4493 = {pageq = {tqe_next = 0xfffffe00b5a124d8, tqe_prev = 0xfffffe00b5b79038}, listq = {tqe_next = 0x0, tqe_prev = 0xfffffe00b5a276e0}, left = 0x0, right = 0x0, object = 0xfffffe005e3f7658, pindex = 5, phys_addr = 1884901376, md = {pv_list = {tqh_first = 0xfffffe005e439ce8, tqh_last = 0xfffffe00795eacc0}, pat_mode = 6}, queue = 0 '\0', segind = 2 '\002', hold_count = 0, order = 13 '\r', pool = 0 '\0', cow = 0, wire_count = 0, aflags = 1 '\001', flags = 64 '@', oflags = 0, act_count = 9 '\t', busy = 0 '\0', valid = 255 '�', dirty = 255 '�'} ### page#2246 ### $4494 = (struct vm_page *) 0xfffffe00b5a124d8 $4495 = {pageq = {tqe_next = 0xfffffe00b460abf8, tqe_prev = 0xfffffe00b5a27658}, listq = {tqe_next = 0x0, tqe_prev = 0xfffffe005e3f7cf8}, left = 0x0, right = 0x0, object = 0xfffffe005e3f7cb0, pindex = 1, phys_addr = 1881952256, md = {pv_list = {tqh_first = 0xfffffe005e42dd48, tqh_last = 0xfffffe007adb03a8}, pat_mode = 6}, queue = 0 '\0', segind = 2 '\002', hold_count = 0, order = 13 '\r', pool = 0 '\0', cow = 0, wire_count = 0, aflags = 1 '\001', flags = 64 '@', oflags = 0, act_count = 9 '\t', busy = 0 '\0', valid = 255 '�', dirty = 255 '�'} ### page#2247 ### $4496 = (struct vm_page *) 0xfffffe00b460abf8 $4497 = {pageq = {tqe_next = 0xfe26, tqe_prev = 0xfffffe00b5a124d8}, listq = {tqe_next = 0xfffffe0081ad8f70, tqe_prev = 0xfffffe0081ad8f78}, left = 0x6, right = 0xd00000201, object = 0x100000000, pindex = 4294901765, phys_addr = 18446741877712530608, md = {pv_list = { tqh_first = 0xfffffe00b460abc0, tqh_last = 0xfffffe00b5579020}, pat_mode = -1268733096}, queue = 72 'H', segind = -85 '�', hold_count = -19360, order = 0 '\0', pool = 254 '�', cow = 65535, wire_count = 0, aflags = 0 '\0', flags = 0 '\0', oflags = 0, act_count = 0 '\0', busy = 176 '�', valid = 208 '�', dirty = 126 '~'} ### page#2248 ### $4498 = (struct vm_page *) 0xfe26 The page #2247 is the same that caused the problem in frame 8. tqe_next is apparently invalid, so iteration stopped here. It appears that this structure has been stomped on. This page is probably supposed to be a valid inactive page. > > Ultimately I think you will need to look at any malloc/VM/page operations > done in the suspend and resume paths to see where this happens. It might > be slightly easier if the same page gets trashed every time as you could > print out the relevant field periodically during suspend and resume to > narrow down where the breakage occurs. I am thinking to put code walking through all page queues and verifying that they are not damaged in this way into the code when each device is waking up from sleep. dev/acpica/acpi.c has acpi_EnterSleepState, which, as I understand, contains top-level code for S3 sleep. Before sleep it invokes event 'power_suspend' on all devices, and after sleep it calls 'power_resume' on devices. So maybe I will call the page check procedure after 'power_suspend' and 'power_resume'. But it is possible that memory gets damaged somewhere else after power_resume happens. Do you have any thought/suggestions? Yuri From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 20 14:31:58 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5120875B for ; Sat, 20 Jul 2013 14:31:58 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 35E8F384 for ; Sat, 20 Jul 2013 14:31:57 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 6E1FD3AD8F for ; Sat, 20 Jul 2013 07:31:52 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-hackers@freebsd.org Subject: bin/176713: [patch] nc(1) closes network socket too soon Date: Sat, 20 Jul 2013 07:31:52 -0700 Message-ID: <9921.1374330712@server1.tristatelogic.com> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 14:31:58 -0000 Could someone please take a look at this bug report (bin/176713) and also at the simple patch that I provided to fix the problem? This is quite a serious problem, and my PR has been pending with no action since Wed, 6 Mar 2013. Regards, rfg P.S. Please note that in reality, I do not believe that it is necessary to add a new -q option in order to preserve backwards compatability, however I proposed one because in my experience there is always going to be some purist who will claim that *any* change in semantics, however small or helpful, in *any* software ``may'' break something. In reality, the problem in this can most easily be solved simply by removing the one statement: shutdown(nfd, SHUT_WR); entirely from the source, rather than making it conditional on -q, as I suggested in my PR, bin/176713. P.P.S. I have just realized that yet one more critical enhancement for nc is called for, and I will be filing a separate and additional PR for that soon. I hope that someone will be able to take a look at that as soon as it is filed. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 20 15:58:54 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E7B2A139 for ; Sat, 20 Jul 2013 15:58:53 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 7009499A for ; Sat, 20 Jul 2013 15:58:53 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id q55so768082wes.2 for ; Sat, 20 Jul 2013 08:58:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g2FpI4tDidYSek3VO2tSIOno1OfM272FCu6vpVfiWy0=; b=sa/0G+a7U20vfl2WmnjuEzRck52ovv4fdsOKxO0bH77c7uJuMsc1g514MI+XxjRU5u 1E8+CLjlSxeDNQqTmPV97WLZeozO6mG+52a9hTxar+Sy2y+v2KSEBNgtdXpdmxJQbQ6O /BJmhaBFUb5ARD10F7/aR+zm37A7PATqK6pYboNzNxCE9g3/D0zuJeKt3kUHMVgg/gEp N9srvrAPiqiC6asWyQkuyjjItT5ZNWhbutXIljKTfe9wX5iC0rhzLSxW8vMncGRVqnBn fJm6dsdxblwTVKAvA4/NHkHAw40MJNPDniQP0qHrCp7Y77qRSoffE3WyYwv8VTcz2Hp/ SBQg== MIME-Version: 1.0 X-Received: by 10.194.157.99 with SMTP id wl3mr14911846wjb.76.1374335932478; Sat, 20 Jul 2013 08:58:52 -0700 (PDT) Received: by 10.180.187.162 with HTTP; Sat, 20 Jul 2013 08:58:52 -0700 (PDT) In-Reply-To: <9921.1374330712@server1.tristatelogic.com> References: <9921.1374330712@server1.tristatelogic.com> Date: Sat, 20 Jul 2013 17:58:52 +0200 Message-ID: Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon From: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= To: "Ronald F. Guilmette" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 15:58:54 -0000 On Sat, Jul 20, 2013 at 4:31 PM, Ronald F. Guilmette wrote: > > > Could someone please take a look at this bug report (bin/176713) and > also at the simple patch that I provided to fix the problem? > > This is quite a serious problem, and my PR has been pending with no > action since Wed, 6 Mar 2013. > > > Regards, > rfg > > > P.S. Please note that in reality, I do not believe that it is necessary > to add a new -q option in order to preserve backwards compatability, > however > I proposed one because in my experience there is always going to be some > purist who will claim that *any* change in semantics, however small or > helpful, in *any* software ``may'' break something. In reality, the > problem in this can most easily be solved simply by removing the one > statement: > > shutdown(nfd, SHUT_WR); > > entirely from the source, rather than making it conditional on -q, as I > suggested in my PR, bin/176713. > It seems to work for me: Old version: $ echo 193.0.6.139 | nc whois.ripe.net 43 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf with the patched version: echo 193.0.6.139 | ./nc -q whois.ripe.net 43 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '193.0.0.0 - 193.0.7.255' % Abuse contact for '193.0.0.0 - 193.0.7.255' is 'abuse@ripe.net' inetnum: 193.0.0.0 - 193.0.7.255 netname: RIPE-NCC descr: RIPE Network Coordination Centre org: ORG-RIEN1-RIPE descr: Amsterdam, Netherlands remarks: Used for RIPE NCC infrastructure. country: NL admin-c: JDR-RIPE admin-c: BRD-RIPE tech-c: OPS4-RIPE status: ASSIGNED PI source: RIPE # Filtered mnt-by: RIPE-NCC-MNT mnt-lower: RIPE-NCC-MNT organisation: ORG-RIEN1-RIPE org-name: Reseaux IP Europeens Network Coordination Centre (RIPE NCC) org-type: RIR descr: RIPE NCC Operations address: Reseaux IP Europeens Network Coordination Centre (RIPE NCC) P.O. Box 10096 1016 EB Amsterdam Netherlands phone: +31205354444 fax-no: +31205354445 admin-c: AP110-RIPE admin-c: MENN1-RIPE abuse-c: ops4-ripe mnt-ref: RIPE-NCC-MNT mnt-ref: RIPE-NCC-HM-MNT mnt-by: RIPE-NCC-HM-MNT source: RIPE # Filtered role: RIPE NCC Operations address: Singel 258 address: 1016 AB Amsterdam address: The Netherlands phone: +31 20 535 4444 fax-no: +31 20 535 4445 abuse-mailbox: abuse@ripe.net admin-c: JDR-RIPE admin-c: BRD-RIPE tech-c: GL7321-RIPE tech-c: JA47 tech-c: MENN1-RIPE tech-c: EMIL-RIPE tech-c: RCO-RIPE tech-c: APZ-RIPE tech-c: CNAG-RIPE tech-c: RPM-RIPE tech-c: SO2011-RIPE tech-c: RH5357-RIPE tech-c: DCW-RIPE tech-c: FMUL-RIPE nic-hdl: OPS4-RIPE mnt-by: RIPE-NCC-MNT source: RIPE # Filtered person: Brian Riddle address: IT Manager address: RIPE NCC - Operations address: Singel 258 address: 1016AB Amsterdam address: The Netherlands phone: +31 20 535 4444 fax-no: +31 20 535 4445 nic-hdl: BRD-RIPE source: RIPE # Filtered mnt-by: RIPE-NCC-MNT person: Jochem de Ruig address: RIPE NCC address: Singel 258 address: 1016AB Amsterdam address: The Netherlands phone: +31 20 535 4444 fax-no: +31 20 535 4445 nic-hdl: JDR-RIPE source: RIPE # Filtered mnt-by: RIPE-NCC-MNT % Information related to '193.0.0.0/21AS3333' route: 193.0.0.0/21 descr: RIPE-NCC origin: AS3333 mnt-by: RIPE-NCC-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.66.3 (WHOIS2) Tested on: FreeBSD hammer 9.1-RELEASE-p3 FreeBSD 9.1-RELEASE-p3 #0: Mon Apr 29 18:27:25 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > > P.P.S. I have just realized that yet one more critical enhancement for > nc is called for, and I will be filing a separate and additional PR for > that soon. I hope that someone will be able to take a look at that as > soon as it is filed. > Just out of curiosity. What is it about? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >