From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 00:13:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 79F9229E; Sun, 24 Mar 2013 00:13:22 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ea0-x234.google.com (mail-ea0-x234.google.com [IPv6:2a00:1450:4013:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id BBD1623F; Sun, 24 Mar 2013 00:13:21 +0000 (UTC) Received: by mail-ea0-f180.google.com with SMTP id m14so697663eaj.11 for ; Sat, 23 Mar 2013 17:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=IMPVbdDhOirLwGPj3Iu/13PaX2NCtWu/gLuHIf00DRQ=; b=P5Iv9Fss/RvGFYyvNc6RI5zD+mNu8EHvAnTV6lYBXKO5V3nRL2gfKv7kpVNSs2t15M VXTeE8Yu6eIfIlNAWydvQaXK/j9JBprI0FVPIxGXwnJrisXTh3s+qeGYj81gRBofexTS afQYQhqX1Busb4aSVmAUETL2cyN7rVb9pQKOdvbLOSiB09F8sg0Oy6NFlYajSyF6ZZcN gVYUmT4+qoiVxyJhCK3rkF+069EITS/YTSzwLB7QvIbdjjIiNR44wRtjXeQbQhthqcsS KR6xfSAbf9h6r9BcyROpBpOF2+OzfRkHhQfVEqh5YiOY64klhZpesEYrOdKdf4wynKgm hlWA== MIME-Version: 1.0 X-Received: by 10.14.184.68 with SMTP id r44mr18523587eem.40.1364084000449; Sat, 23 Mar 2013 17:13:20 -0700 (PDT) Received: by 10.14.133.204 with HTTP; Sat, 23 Mar 2013 17:13:19 -0700 (PDT) In-Reply-To: References: Date: Sat, 23 Mar 2013 17:13:19 -0700 Message-ID: Subject: Re: hwpmc support for haswell From: hiren panchasara To: Jim Harris Content-Type: text/plain; charset=UTF-8 Cc: Davide Italiano , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 00:13:22 -0000 On Sat, Mar 23, 2013 at 8:58 AM, hiren panchasara wrote: > > On Mar 22, 2013 10:48 PM, "Jim Harris" wrote: >> >> >> >> On Friday, March 22, 2013, hiren panchasara wrote: >>> >>> On Thu, Jan 31, 2013 at 6:26 PM, hiren panchasara >>> wrote: >>> > On Thu, Jan 31, 2013 at 5:47 PM, Davide Italiano >>> > wrote: >>> >> On Fri, Feb 1, 2013 at 2:17 AM, hiren panchasara >>> >> wrote: >>> >>> Hi, >>> >>> >>> >>> I've prepared a patch to add core and uncore events support for >>> >>> haswell processor. >>> >>> I do not have the hardware to test this. It applies cleanly and >>> >>> compiles fine though. >>> >>> >>> >>> http://www.strugglingcoder.info/patches/hwpmc_hw.txt >>> >>> >>> >>> This is initial version of patch and manpage is still missing. I will >>> >>> add it in a few days. >>> >>> >>> >>> Any help in testing is appreciated. >>> >>> >>> >>> Thanks, >>> >>> Hiren >>> >> >>> >> It seems Intel won't release this before June (at least to my >>> >> knowledge). >>> >> I would claim it'll be difficult to real test this before that date >>> >> unless someone has prerelease hardware. >>> > >>> > Indeed. I've posted it here just to let larger audience know and avoid >>> > possible duplicate work. >>> > >>> > We will wait till we get the hardware to test with. >>> >>> I recently got a ref haswell box to play with. >>> >>> Initial dmesg looks like this: >>> >>> CPU: Genuine Intel(R) CPU 0000 @ 2.60GHz (2594.05-MHz K8-class CPU) >>> Origin = "GenuineIntel" Id = 0x306c2 Family = 0x6 Model = 0x3c >>> Stepping = 2 >>> >>> Features=0xbfebfbff >>> >>> Features2=0x7ffafbff,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> >>> AMD Features=0x2c100800 >>> AMD Features2=0x21 >>> Standard Extended >>> Features=0x2fbb >>> TSC: P-state invariant, performance statistics >>> real memory = 8589934592 (8192 MB) >>> avail memory = 8034803712 (7662 MB) >>> Event timer "LAPIC" quality 600 >>> ACPI APIC Table: >>> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs >>> FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads >>> cpu0 (BSP): APIC ID: 0 >>> cpu1 (AP): APIC ID: 1 >>> cpu2 (AP): APIC ID: 2 >>> cpu3 (AP): APIC ID: 3 >>> cpu4 (AP): APIC ID: 4 >>> cpu5 (AP): APIC ID: 5 >>> cpu6 (AP): APIC ID: 6 >>> cpu7 (AP): APIC ID: 7 >>> >>> Diffs at: >>> http://www.strugglingcoder.info/patches/hwpmc_hw.txt >>> Tests I've done: >>> http://www.strugglingcoder.info/patches/hwpmc_hw_pmccontrol.txt >>> http://www.strugglingcoder.info/patches/hwpmc_hw_pmctest.txt >>> >>> I am following 325462-045US Jan 2013 sw dev manual and below are the >>> counters >>> which I cannot poke at via pmcstat: >>> >>> Core: >>> "L2_RQSTS.DEMAND_DATA_RD_MISS" >>> "L2_RQSTS.DEMAND_DATA_RD_HIT" >>> "L2_RQSTS.ALL_DEMAND_DATA_RD" >>> "L2_RQSTS.ALL_DEMAND_MISS" >>> "L2_RQSTS.ALL_DEMAND_REFERENCES" >>> "L2_RQSTS.MISS" >>> "CYCLE_ACTIVITY.STALLS_L2_PENDING" >>> "PAGE_WALKER_LOADS.DTLB_L1" >>> "PAGE_WALKER_LOADS.ITLB_L1" >>> "BACLEARS.ANY" >>> "L2_LINES_OUT.DEMAND_CLEAN" >>> >>> Uncore: >>> "UNC_CBO_XSNP_RESPONSE.INVAL_M" >>> "UNC_CBO_CACHE_LOOKUP.ES" >>> >>> For all of them, I get error like this: >>> >>> # pmcstat -p L2_RQSTS.MISS ls >>> pmcstat: ERROR: Cannot allocate process-mode pmc with specification >>> "L2_RQSTS.MISS": Invalid argument >>> >>> Box does not panic or anything. >>> >>> I've tried to double check my changes without success. >>> Is it possible that the documentation has some inconsistencies? >>> >> >> It looks like IAF_F_FM is missing from most (all?) of the new event w/ >> umask entries you added that are specific to Haswell. Can you try adding >> these and see if it clears anything up? A cursory look seemed to show most >> of these failures are on event/umasks that are missing this flag. >> > Ah, good point. Let me try that and let you know. Jim, thanks for spotting this. Missing counters are fixed now. cheers, Hiren > > Thanks, > Hiren. >> Thanks, >> >> -Jim From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 02:07:54 2013 Return-Path: Delivered-To: freebsd-current@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 071242D7 for ; Sun, 24 Mar 2013 02:07:54 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (neu.net [199.48.129.194]) by mx1.freebsd.org (Postfix) with ESMTP id 8653A6B6 for ; Sun, 24 Mar 2013 02:07:53 +0000 (UTC) Received: from neu.net (neu.net [199.48.129.194]) by mail.neu.net (8.14.6/8.14.5) with ESMTP id r2O27iXH091010 for ; Sat, 23 Mar 2013 22:07:44 -0400 (EDT) (envelope-from andy@neu.net) Date: Sat, 23 Mar 2013 22:07:44 -0400 (EDT) From: AN To: freebsd-current@freebsd.org Subject: buildworld fails In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.97.7 at my.mail.server X-Virus-Status: Clean X-Spam-Status: No, score=1.8 required=4.5 tests=RP_MATCHES_RCVD,URIBL_BLACK autolearn=no version=3.3.2 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.neu.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 02:07:54 -0000 FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #38 r248401: Sat Mar 16 21:39:04 CDT 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 248671 cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/lang.c cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/macro.c cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/makeinfo.c cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/multi.c cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/node.c cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/sectioning.c /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/sectioning.c:494:31: warning: passing 'unsigned char *' to parameter of type 'const char *' converts between pointers to integer types with different sign [-Wpointer-sign] toc_add_entry (substring (starting_pos, ending_pos - 1), ^~~~~~~~~~~~ /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib/system.h:35:37: note: passing argument to parameter here extern char *substring (const char *, const char *); ^ /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/sectioning.c:494:45: warning: passing 'unsigned char *' to parameter of type 'const char *' converts between pointers to integer types with different sign [-Wpointer-sign] toc_add_entry (substring (starting_pos, ending_pos - 1), ^~~~~~~~~~~~~~ cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/toc.c /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib/system.h:35:51: note: passing argument to parameter here extern char *substring (const char *, const char *); ^ /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/sectioning.c:537:31: warning: passing 'unsigned char *' to parameter of type 'const char *' converts between pointers to integer types with different sign [-Wpointer-sign] toc_anchor = substring (starting_pos + sizeof (a_name) - 1, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib/system.h:35:37: note: passing argument to parameter here extern char *substring (const char *, const char *); ^ /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/sectioning.c:538:31: warning: passing 'unsigned char *' to parameter of type 'const char *' converts between pointers to integer types with different sign [-Wpointer-sign] output_paragraph + output_paragraph_offset); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib/system.h:35:51: note: passing argument to parameter here extern char *substring (const char *, const char *); ^ /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/sectioning.c:588:31: warning: passing 'unsigned char *' to parameter of type 'const char *' converts between pointers to integer types with different sign [-Wpointer-sign] toc_add_entry (substring (starting_pos, ending_pos), ^~~~~~~~~~~~ /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib/system.h:35:37: note: passing argument to parameter here extern char *substring (const char *, const char *); ^ /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/sectioning.c:588:45: warning: passing 'unsigned char *' to parameter of type 'const char *' converts between pointers to integer types with different sign [-Wpointer-sign] toc_add_entry (substring (starting_pos, ending_pos), ^~~~~~~~~~ /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib/system.h:35:51: note: passing argument to parameter here extern char *substring (const char *, const char *); ^ cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/xml.c cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/xref.c 6 warnings generated. gzip -cn /usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/doc/makeinfo.1 > makeinfo.1.gz cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -o makeinfo cmds.o defun.o files.o float.o footnote.o html.o index.o insertion.o lang.o macro.o makeinfo.o multi.o node.o sectioning.o toc.o xml.o xref.o /usr/obj/usr/src/gnu/usr.bin/texinfo/makeinfo/../libtxi/libtxi.a ===> gnu/usr.bin/texinfo/info (all) cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/dir.c cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/display.c cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/doc.c cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/dribble.c cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/echo-area.c cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/filesys.c cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/footnotes.c cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/gc.c cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/indices.c cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/info-utils.c cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/info.c cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/infodoc.c cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/infomap.c cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/m-x.c cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/man.c cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/nodemenu.c cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/nodes.c cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/search.c cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/session.c cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/signals.c cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/terminal.c cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/tilde.c cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/variables.c cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/info/window.c gzip -cn /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/doc/info.1 > info.1.gz gzip -cn /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/doc/info.5 > info.5.gz gzip -cn /usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/doc/texinfo.5 > texinfo.5.gz cc -O2 -pipe -DINFODIR=\"/usr/share/info:/usr/local/info:.\" -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -o info dir.o display.o doc.o dribble.o echo-area.o filesys.o footnotes.o gc.o indices.o info-utils.o info.o infodoc.o infomap.o m-x.o man.o nodemenu.o nodes.o search.o session.o signals.o terminal.o tilde.o variables.o window.o -ltermcap /usr/obj/usr/src/gnu/usr.bin/texinfo/info/../libtxi/libtxi.a ===> gnu/usr.bin/texinfo/infokey (all) cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo/info/infokey.c cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo/info/key.c gzip -cn /usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo/doc/infokey.1 > infokey.1.gz cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/infokey/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -o infokey infokey.o key.o /usr/obj/usr/src/gnu/usr.bin/texinfo/infokey/../libtxi/libtxi.a ===> gnu/usr.bin/texinfo/install-info (all) cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/util/install-info.c gzip -cn /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/doc/install-info.1 > install-info.1.gz /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/util/install-info.c:1179:28: warning: expression result unused [-Wunused-value] bindtextdomain (PACKAGE, LOCALEDIR); ^~~~~~~~~ :2:19: note: expanded from macro 'LOCALEDIR' #define LOCALEDIR "/usr/share/locale" ^~~~~~~~~~~~~~~~~~~ /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib/gettext.h:54:63: note: expanded from macro 'bindtextdomain' # define bindtextdomain(Domainname, Dirname) ((const char *) (Dirname)) ^ /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/util/install-info.c:1180:15: warning: expression result unused [-Wunused-value] textdomain (PACKAGE); ^~~~~~~ /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/config.h:338:17: note: expanded from macro 'PACKAGE' #define PACKAGE "texinfo" ^~~~~~~~~ /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib/gettext.h:53:50: note: expanded from macro 'textdomain' # define textdomain(Domainname) ((const char *) (Domainname)) ^ 2 warnings generated. cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -o install-info install-info.o /usr/obj/usr/src/gnu/usr.bin/texinfo/install-info/../libtxi/libtxi.a ===> gnu/usr.bin/texinfo/texindex (all) cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/util/texindex.c gzip -cn /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/doc/texindex.1 > texindex.1.gz /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/util/texindex.c:166:28: warning: expression result unused [-Wunused-value] bindtextdomain (PACKAGE, LOCALEDIR); ^~~~~~~~~ :2:19: note: expanded from macro 'LOCALEDIR' #define LOCALEDIR "/usr/share/locale" ^~~~~~~~~~~~~~~~~~~ /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/lib/gettext.h:54:63: note: expanded from macro 'bindtextdomain' # define bindtextdomain(Domainname, Dirname) ((const char *) (Dirname)) ^ /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/util/texindex.c:167:15: warning: expression result unused [-Wunused-value] textdomain (PACKAGE); ^~~~~~~ /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/config.h:338:17: note: expanded from macro 'PACKAGE' #define PACKAGE "texinfo" ^~~~~~~~~ /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/lib/gettext.h:53:50: note: expanded from macro 'textdomain' # define textdomain(Domainname) ((const char *) (Domainname)) ^ 2 warnings generated. cc -O2 -pipe -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -o texindex texindex.o /usr/obj/usr/src/gnu/usr.bin/texinfo/texindex/../libtxi/libtxi.a ===> gnu/usr.bin/texinfo/doc (all) makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info.texi -o info.info makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info-stnd.texi -o info-stnd.info ln -fs /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/texinfo.txi texinfo.texi makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc texinfo.texi -o texinfo.info gzip -cn info.info > info.info.gz gzip -cn info-stnd.info > info-stnd.info.gz gzip -cn texinfo.info > texinfo.info.gz 2 errors *** [everything] Error code 2 1 error *** [buildworld] Error code 2 1 error From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 02:48:46 2013 Return-Path: Delivered-To: current@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 25B9784A; Sun, 24 Mar 2013 02:48:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E50E67BD; Sun, 24 Mar 2013 02:48:45 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2O2mdiD061095; Sat, 23 Mar 2013 22:48:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2O2mdfR061076; Sun, 24 Mar 2013 02:48:39 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Mar 2013 02:48:39 GMT Message-Id: <201303240248.r2O2mdfR061076@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 02:48:46 -0000 TB --- 2013-03-24 01:10:23 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-24 01:10:23 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-24 01:10:23 - starting HEAD tinderbox run for arm/arm TB --- 2013-03-24 01:10:23 - cleaning the object tree TB --- 2013-03-24 01:10:23 - /usr/local/bin/svn stat /src TB --- 2013-03-24 01:10:27 - At svn revision 248671 TB --- 2013-03-24 01:10:28 - building world TB --- 2013-03-24 01:10:28 - CROSS_BUILD_TESTING=YES TB --- 2013-03-24 01:10:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-24 01:10:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-24 01:10:28 - SRCCONF=/dev/null TB --- 2013-03-24 01:10:28 - TARGET=arm TB --- 2013-03-24 01:10:28 - TARGET_ARCH=arm TB --- 2013-03-24 01:10:28 - TZ=UTC TB --- 2013-03-24 01:10:28 - __MAKE_CONF=/dev/null TB --- 2013-03-24 01:10:28 - cd /src TB --- 2013-03-24 01:10:28 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 24 01:10:33 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] echo fsck_ffs: /obj/arm.arm/src/tmp/usr/lib/libc.a /obj/arm.arm/src/tmp/usr/lib/libufs.a >> .depend cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/dir.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:511: warning: format '%d' expects type 'int', but argument 2 has type 'time_t' /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%4d' expects type 'int', but argument 6 has type 'time_t' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/arm.arm/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-24 02:48:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-24 02:48:39 - ERROR: failed to build world TB --- 2013-03-24 02:48:39 - 4831.23 user 839.29 system 5895.55 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 02:48:46 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DE85684B; Sun, 24 Mar 2013 02:48:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5F82D7C0; Sun, 24 Mar 2013 02:48:46 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2O2mevU061177; Sat, 23 Mar 2013 22:48:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2O2meBb061176; Sun, 24 Mar 2013 02:48:40 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Mar 2013 02:48:40 GMT Message-Id: <201303240248.r2O2meBb061176@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 02:48:46 -0000 TB --- 2013-03-24 01:10:23 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-24 01:10:23 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-24 01:10:23 - starting HEAD tinderbox run for armv6/arm TB --- 2013-03-24 01:10:23 - cleaning the object tree TB --- 2013-03-24 01:10:23 - /usr/local/bin/svn stat /src TB --- 2013-03-24 01:10:27 - At svn revision 248671 TB --- 2013-03-24 01:10:28 - building world TB --- 2013-03-24 01:10:28 - CROSS_BUILD_TESTING=YES TB --- 2013-03-24 01:10:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-24 01:10:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-24 01:10:28 - SRCCONF=/dev/null TB --- 2013-03-24 01:10:28 - TARGET=arm TB --- 2013-03-24 01:10:28 - TARGET_ARCH=armv6 TB --- 2013-03-24 01:10:28 - TZ=UTC TB --- 2013-03-24 01:10:28 - __MAKE_CONF=/dev/null TB --- 2013-03-24 01:10:28 - cd /src TB --- 2013-03-24 01:10:28 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 24 01:10:33 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] echo fsck_ffs: /obj/arm.armv6/src/tmp/usr/lib/libc.a /obj/arm.armv6/src/tmp/usr/lib/libufs.a >> .depend cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/dir.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:511: warning: format '%d' expects type 'int', but argument 2 has type 'time_t' /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%4d' expects type 'int', but argument 6 has type 'time_t' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/arm.armv6/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-24 02:48:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-24 02:48:40 - ERROR: failed to build world TB --- 2013-03-24 02:48:40 - 4829.59 user 837.49 system 5897.02 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 02:50:25 2013 Return-Path: Delivered-To: current@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 AF497B4C; Sun, 24 Mar 2013 02:50:25 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 885E5802; Sun, 24 Mar 2013 02:50:25 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:ff:29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 5A7EB23F66A; Sat, 23 Mar 2013 22:50:24 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.0 onyx.glenbarber.us 5A7EB23F66A Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sat, 23 Mar 2013 22:50:21 -0400 From: Glen Barber To: FreeBSD Tinderbox Subject: Re: [head tinderbox] failure on arm/arm Message-ID: <20130324025021.GD1512@glenbarber.us> References: <201303240248.r2O2mdfR061076@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="R+My9LyyhiUvIEro" Content-Disposition: inline In-Reply-To: <201303240248.r2O2mdfR061076@freebsd-current.sentex.ca> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 02:50:25 -0000 --R+My9LyyhiUvIEro Content-Type: text/plain; charset=us-ascii Content-Disposition: inline sbruno already fixed this. Glen On Sun, Mar 24, 2013 at 02:48:39AM +0000, FreeBSD Tinderbox wrote: > [...] --R+My9LyyhiUvIEro Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRTmntAAoJEFJPDDeguUaje6QH/j+Q+PNKYlXYKOhWHtiaTl3K sEYWm5Lc7ZWF3DUkVd86Isz/M2j/VMlHs6hQiePRzKcUWcRxs+DOMIOJIp65QSvW eUopxK69Nrsvnsq3+5PH25AMPCe0ZOWlq8uONesG8ltsSNLX8APDFn9EZeUrzfwD UchwCJN76Qhdhm8agsHkoiOq+TqS1IJk+sBh/cT7iJ2TTsxMSQGfO47GQ5z1JWED 7nz5RH5LIgs2iq3oJZ5ySEShLTmtxBSblt5Ehna0rXHSDBMq7jAUYzjO3bbXYgAm rLuRe/cnLG4uSOaGDU3VQAAXwhhdDxOBvEuPgObd903LRAehUbbnENnJ21spm/k= =cmtp -----END PGP SIGNATURE----- --R+My9LyyhiUvIEro-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 03:27:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BADA43AF for ; Sun, 24 Mar 2013 03:27:13 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8C0709B9 for ; Sun, 24 Mar 2013 03:27:13 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id i18so5491421oag.1 for ; Sat, 23 Mar 2013 20:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=NP7Sjxq88X3K0GljJ2zceOlqT3O5tffCq/N2pdLr8kM=; b=BqLrYCL8Vpqa/sbKJvlypKsdv3Wo7mvxLvXhfZQhCVHqHJ7G9A9Wkp1qHAxWuvKyLr RTnSBmiEnIew1ZCDZZFcVsIKPNLnfpHlqZmB6/rzmMB4akyBevJn8eHSmKVG33hH4R59 ya2NbukIz+EopxoC6faNdJei03QL4ZruxLh1G5/fJBewnBVwz9E96Eafd9E88/ldm/oe AYnOSEmhy8/bhgI0x/Ob3S82HqTvo4OPKHTACS7tOefynTE80rgFsZeIlK31svsYY7x/ Z2aZLiqm1kAGT3DSLMFIdOYU2nmMD0U+zjImoQD/AlqW6LvwvT4S9eQtYjQJ0Z5ew9fX DAdA== MIME-Version: 1.0 X-Received: by 10.60.24.197 with SMTP id w5mr6692714oef.6.1364095627248; Sat, 23 Mar 2013 20:27:07 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.33.7 with HTTP; Sat, 23 Mar 2013 20:27:07 -0700 (PDT) In-Reply-To: <20130323215236.GA17446@localhost> References: <20130323215236.GA17446@localhost> Date: Sat, 23 Mar 2013 20:27:07 -0700 X-Google-Sender-Auth: kG24_VWNtnMKf--G4Y4Lu26KNEo Message-ID: Subject: Re: Report on issues with fusefs From: Kevin Oberman To: Pavel Gorshkov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org, Marko Zec X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 03:27:13 -0000 On Sat, Mar 23, 2013 at 2:52 PM, Pavel Gorshkov wrote: > On Fri, Mar 22, 2013 at 10:16:09PM -0700, Kevin Oberman wrote: >> I've now been using fusefs regularly for a few months and I have found >> a few issues that i wanted to report. >> >> Most disturbing is corrupted NTFS systems. On several occasions I have >> found an NTFS system could not be written to with either FreeBSD or >> Windows. I had to user Windows disk check to repair the file system, >> but a few files were lost. this may be an issue with either fusefs or >> ntfs-3g. Not sure which, but it is likely tied to the next issue. > > This patch, also referenced in ports/169165, might help solve at > least some of the issues: > > http://www.mail-archive.com/freebsd-users-jp@jp.freebsd.org/msg04947.html > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/169165 Thanks, Pavel, but my problem has not involved permissions nor does it cause a panic, so while this patch looks reasonable and I suspect it (or something similar) is needed, I don't see how it would fix the problems I am seeing. -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 03:43:17 2013 Return-Path: Delivered-To: current@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 C763E640; Sun, 24 Mar 2013 03:43:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7986FA32; Sun, 24 Mar 2013 03:43:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2O3hGWT052091; Sat, 23 Mar 2013 23:43:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2O3hGlS052090; Sun, 24 Mar 2013 03:43:16 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Mar 2013 03:43:16 GMT Message-Id: <201303240343.r2O3hGlS052090@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 03:43:17 -0000 TB --- 2013-03-24 01:10:23 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-24 01:10:23 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-24 01:10:23 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-03-24 01:10:23 - cleaning the object tree TB --- 2013-03-24 01:10:23 - /usr/local/bin/svn stat /src TB --- 2013-03-24 01:10:27 - At svn revision 248671 TB --- 2013-03-24 01:10:28 - building world TB --- 2013-03-24 01:10:28 - CROSS_BUILD_TESTING=YES TB --- 2013-03-24 01:10:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-24 01:10:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-24 01:10:28 - SRCCONF=/dev/null TB --- 2013-03-24 01:10:28 - TARGET=amd64 TB --- 2013-03-24 01:10:28 - TARGET_ARCH=amd64 TB --- 2013-03-24 01:10:28 - TZ=UTC TB --- 2013-03-24 01:10:28 - __MAKE_CONF=/dev/null TB --- 2013-03-24 01:10:28 - cd /src TB --- 2013-03-24 01:10:28 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 24 01:10:33 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ^~~~~~~~~~~~~~~~~~ /src/sbin/fsck_ffs/fsutil.c:526:7: error: format specifies type 'intmax_t' (aka 'long') but the argument has type 'long long' [-Werror,-Wformat] msec * 100 / totalmsec, (msec * 1000 / totalmsec) % 10); ^~~~~~~~~~~~~~~~~~~~~~ /src/sbin/fsck_ffs/fsutil.c:526:31: error: format specifies type 'intmax_t' (aka 'long') but the argument has type 'long long' [-Werror,-Wformat] msec * 100 / totalmsec, (msec * 1000 / totalmsec) % 10); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4 errors generated. *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/amd64.amd64/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-24 03:43:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-24 03:43:16 - ERROR: failed to build world TB --- 2013-03-24 03:43:16 - 7668.75 user 1017.40 system 9173.02 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 03:57:13 2013 Return-Path: Delivered-To: current@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 5A6FA8EF; Sun, 24 Mar 2013 03:57:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 17963A94; Sun, 24 Mar 2013 03:57:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2O3vCPX030392; Sat, 23 Mar 2013 23:57:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2O3vCDg030387; Sun, 24 Mar 2013 03:57:12 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Mar 2013 03:57:12 GMT Message-Id: <201303240357.r2O3vCDg030387@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 03:57:13 -0000 TB --- 2013-03-24 02:48:40 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-24 02:48:40 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-24 02:48:40 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-03-24 02:48:40 - cleaning the object tree TB --- 2013-03-24 02:48:40 - /usr/local/bin/svn stat /src TB --- 2013-03-24 02:48:43 - At svn revision 248671 TB --- 2013-03-24 02:48:44 - building world TB --- 2013-03-24 02:48:44 - CROSS_BUILD_TESTING=YES TB --- 2013-03-24 02:48:44 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-24 02:48:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-24 02:48:44 - SRCCONF=/dev/null TB --- 2013-03-24 02:48:44 - TARGET=ia64 TB --- 2013-03-24 02:48:44 - TARGET_ARCH=ia64 TB --- 2013-03-24 02:48:44 - TZ=UTC TB --- 2013-03-24 02:48:44 - __MAKE_CONF=/dev/null TB --- 2013-03-24 02:48:44 - cd /src TB --- 2013-03-24 02:48:44 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 24 02:48:49 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O2 -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:511: warning: format '%d' expects type 'int', but argument 2 has type 'time_t' /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%4d' expects type 'int', but argument 6 has type 'time_t' /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%2jd' expects type 'intmax_t', but argument 8 has type 'long long int' /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%jd' expects type 'intmax_t', but argument 9 has type 'long long int' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/ia64.ia64/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-24 03:57:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-24 03:57:12 - ERROR: failed to build world TB --- 2013-03-24 03:57:12 - 3280.14 user 574.62 system 4111.29 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 04:32:51 2013 Return-Path: Delivered-To: current@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 33BBD1CE; Sun, 24 Mar 2013 04:32:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E2E40BE2; Sun, 24 Mar 2013 04:32:50 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2O4WoJX071184; Sun, 24 Mar 2013 00:32:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2O4WocX071168; Sun, 24 Mar 2013 04:32:50 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Mar 2013 04:32:50 GMT Message-Id: <201303240432.r2O4WocX071168@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 04:32:51 -0000 TB --- 2013-03-24 03:43:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-24 03:43:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-24 03:43:16 - starting HEAD tinderbox run for mips/mips TB --- 2013-03-24 03:43:17 - cleaning the object tree TB --- 2013-03-24 03:43:17 - /usr/local/bin/svn stat /src TB --- 2013-03-24 03:43:34 - At svn revision 248671 TB --- 2013-03-24 03:43:35 - building world TB --- 2013-03-24 03:43:35 - CROSS_BUILD_TESTING=YES TB --- 2013-03-24 03:43:35 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-24 03:43:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-24 03:43:35 - SRCCONF=/dev/null TB --- 2013-03-24 03:43:35 - TARGET=mips TB --- 2013-03-24 03:43:35 - TARGET_ARCH=mips TB --- 2013-03-24 03:43:35 - TZ=UTC TB --- 2013-03-24 03:43:35 - __MAKE_CONF=/dev/null TB --- 2013-03-24 03:43:35 - cd /src TB --- 2013-03-24 03:43:35 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 24 03:43:40 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] echo fsck_ffs: /obj/mips.mips/src/tmp/usr/lib/libc.a /obj/mips.mips/src/tmp/usr/lib/libufs.a >> .depend cc -O -pipe -G0 -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/dir.c cc -O -pipe -G0 -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O -pipe -G0 -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:511: warning: format '%d' expects type 'int', but argument 2 has type 'time_t' /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%4d' expects type 'int', but argument 6 has type 'time_t' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/mips.mips/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-24 04:32:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-24 04:32:50 - ERROR: failed to build world TB --- 2013-03-24 04:32:50 - 2142.62 user 571.26 system 2973.07 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 04:46:53 2013 Return-Path: Delivered-To: current@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 104CE6FB; Sun, 24 Mar 2013 04:46:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C45BECB8; Sun, 24 Mar 2013 04:46:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2O4kq9A038924; Sun, 24 Mar 2013 00:46:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2O4kqMx038923; Sun, 24 Mar 2013 04:46:52 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Mar 2013 04:46:52 GMT Message-Id: <201303240446.r2O4kqMx038923@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 04:46:53 -0000 TB --- 2013-03-24 03:57:12 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-24 03:57:12 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-24 03:57:12 - starting HEAD tinderbox run for mips64/mips TB --- 2013-03-24 03:57:12 - cleaning the object tree TB --- 2013-03-24 03:57:12 - /usr/local/bin/svn stat /src TB --- 2013-03-24 03:57:15 - At svn revision 248671 TB --- 2013-03-24 03:57:16 - building world TB --- 2013-03-24 03:57:16 - CROSS_BUILD_TESTING=YES TB --- 2013-03-24 03:57:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-24 03:57:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-24 03:57:16 - SRCCONF=/dev/null TB --- 2013-03-24 03:57:16 - TARGET=mips TB --- 2013-03-24 03:57:16 - TARGET_ARCH=mips64 TB --- 2013-03-24 03:57:16 - TZ=UTC TB --- 2013-03-24 03:57:16 - __MAKE_CONF=/dev/null TB --- 2013-03-24 03:57:16 - cd /src TB --- 2013-03-24 03:57:16 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 24 03:57:21 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -G0 -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O -pipe -G0 -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:511: warning: format '%d' expects type 'int', but argument 2 has type 'time_t' /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%4d' expects type 'int', but argument 6 has type 'time_t' /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%2jd' expects type 'intmax_t', but argument 8 has type 'long long int' /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%jd' expects type 'intmax_t', but argument 9 has type 'long long int' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/mips.mips64/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-24 04:46:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-24 04:46:51 - ERROR: failed to build world TB --- 2013-03-24 04:46:51 - 2151.31 user 544.34 system 2979.59 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 06:57:58 2013 Return-Path: Delivered-To: current@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 D70FB1CA; Sun, 24 Mar 2013 06:57:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 97E2B9C1; Sun, 24 Mar 2013 06:57:58 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2O6vvA3022497; Sun, 24 Mar 2013 02:57:57 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2O6vvWE022496; Sun, 24 Mar 2013 06:57:57 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Mar 2013 06:57:57 GMT Message-Id: <201303240657.r2O6vvWE022496@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 06:57:58 -0000 TB --- 2013-03-24 04:46:52 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-24 04:46:52 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-24 04:46:52 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-03-24 04:46:52 - cleaning the object tree TB --- 2013-03-24 04:46:52 - /usr/local/bin/svn stat /src TB --- 2013-03-24 04:46:55 - At svn revision 248671 TB --- 2013-03-24 04:46:56 - building world TB --- 2013-03-24 04:46:56 - CROSS_BUILD_TESTING=YES TB --- 2013-03-24 04:46:56 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-24 04:46:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-24 04:46:56 - SRCCONF=/dev/null TB --- 2013-03-24 04:46:56 - TARGET=powerpc TB --- 2013-03-24 04:46:56 - TARGET_ARCH=powerpc64 TB --- 2013-03-24 04:46:56 - TZ=UTC TB --- 2013-03-24 04:46:56 - __MAKE_CONF=/dev/null TB --- 2013-03-24 04:46:56 - cd /src TB --- 2013-03-24 04:46:56 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 24 04:47:01 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O2 -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:511: warning: format '%d' expects type 'int', but argument 2 has type 'time_t' /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%4d' expects type 'int', but argument 6 has type 'time_t' /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%2jd' expects type 'intmax_t', but argument 8 has type 'long long int' /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%jd' expects type 'intmax_t', but argument 9 has type 'long long int' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/powerpc.powerpc64/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-24 06:57:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-24 06:57:57 - ERROR: failed to build world TB --- 2013-03-24 06:57:57 - 6641.45 user 900.60 system 7865.41 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 07:07:37 2013 Return-Path: Delivered-To: current@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 8EBB456E; Sun, 24 Mar 2013 07:07:37 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 6A24FABB; Sun, 24 Mar 2013 07:07:37 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:ff:29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 7B9AE23F66B; Sun, 24 Mar 2013 03:07:36 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.0 onyx.glenbarber.us 7B9AE23F66B Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 24 Mar 2013 03:07:34 -0400 From: Glen Barber To: FreeBSD Tinderbox Subject: Re: [head tinderbox] failure on powerpc64/powerpc Message-ID: <20130324070734.GF1514@glenbarber.us> References: <201303240657.r2O6vvWE022496@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5Mfx4RzfBqgnTE/w" Content-Disposition: inline In-Reply-To: <201303240657.r2O6vvWE022496@freebsd-current.sentex.ca> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 07:07:37 -0000 --5Mfx4RzfBqgnTE/w Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This is being worked on... There are some casting issues that are causing problems on 32-bit systems, which are not causing errors on 64-bit systems. Glen On Sun, Mar 24, 2013 at 06:57:57AM +0000, FreeBSD Tinderbox wrote: > [...] --5Mfx4RzfBqgnTE/w Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRTqY2AAoJEFJPDDeguUajvT8IAJMzdjHmfmbWYIbNa1OBh+Pd tNyh2jUHHJ8cIS0u6X/R/mVUx7V5Iw+0RreG9oNm+fBONpaYmeFxnlLt4Tp51TAZ EOp1tae5rEOeU6Tm8ijbWHfnKf11jFjaNuQxOYEnGYDeSjhTT4iOBbbVDhS3ejbw Cly0lGja7yjK9vy3kGTzDW8M/7TmXFRC1T+/ilFzZ8CGOj9zgH79UVAR78UuxPVt cH9PMDwCSK6TA4hqd7h5kCb75nvhudNl3pHNbnJpe96QObxOJ2YeoXeU8DYonrw+ FwOWYGXex1OfhFGxMW0Ga5UNUakMsyJ4d2Yav843DtZcFNCDrPi+o2nzx6rWgLk= =HgK8 -----END PGP SIGNATURE----- --5Mfx4RzfBqgnTE/w-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 07:20:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 216D9B13; Sun, 24 Mar 2013 07:20:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D5C6DC25; Sun, 24 Mar 2013 07:20:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2O7KYqI029728; Sun, 24 Mar 2013 03:20:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2O7KYEY029727; Sun, 24 Mar 2013 07:20:34 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Mar 2013 07:20:34 GMT Message-Id: <201303240720.r2O7KYEY029727@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 07:20:35 -0000 TB --- 2013-03-24 06:26:48 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-24 06:26:48 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-24 06:26:48 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-03-24 06:26:48 - cleaning the object tree TB --- 2013-03-24 06:26:48 - /usr/local/bin/svn stat /src TB --- 2013-03-24 06:26:53 - At svn revision 248671 TB --- 2013-03-24 06:26:54 - building world TB --- 2013-03-24 06:26:54 - CROSS_BUILD_TESTING=YES TB --- 2013-03-24 06:26:54 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-24 06:26:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-24 06:26:54 - SRCCONF=/dev/null TB --- 2013-03-24 06:26:54 - TARGET=sparc64 TB --- 2013-03-24 06:26:54 - TARGET_ARCH=sparc64 TB --- 2013-03-24 06:26:54 - TZ=UTC TB --- 2013-03-24 06:26:54 - __MAKE_CONF=/dev/null TB --- 2013-03-24 06:26:54 - cd /src TB --- 2013-03-24 06:26:54 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 24 06:26:59 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O2 -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:511: warning: format '%d' expects type 'int', but argument 2 has type 'time_t' /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%4d' expects type 'int', but argument 6 has type 'time_t' /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%2jd' expects type 'intmax_t', but argument 8 has type 'long long int' /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%jd' expects type 'intmax_t', but argument 9 has type 'long long int' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/sparc64.sparc64/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-24 07:20:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-24 07:20:34 - ERROR: failed to build world TB --- 2013-03-24 07:20:34 - 2446.69 user 443.98 system 3225.84 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 09:19:17 2013 Return-Path: Delivered-To: current@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 9C9B54EA; Sun, 24 Mar 2013 09:19:17 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 81DDCCEB; Sun, 24 Mar 2013 09:19:17 +0000 (UTC) Received: from delphij-macbook.local (c-67-188-85-47.hsd1.ca.comcast.net [67.188.85.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 271285680; Sun, 24 Mar 2013 02:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1364116757; bh=WxbkfVmLhL5NylDRj3orfb0VxTQp5DPLZwMzHvPRTDg=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=04knuL51BWokxmSJP7Qv/+MbesnzgGvheyA9UZdqHX9Mw9hrm76XRoPZUod7+CVue hb2kezyTeBM1uGkutFn7hfljQgnqf8Kq15SG4MViPCXz4dtZ/KVZ7FsXHyGjUFShKU /SYYYNGF/uELVXsIhk3l/rXFedXFeAqfVpTjFHzo= Message-ID: <514EC514.6080504@delphij.net> Date: Sun, 24 Mar 2013 02:19:16 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: FreeBSD Tinderbox Subject: Re: [head tinderbox] failure on sparc64/sparc64 References: <201303240720.r2O7KYEY029727@freebsd-current.sentex.ca> In-Reply-To: <201303240720.r2O7KYEY029727@freebsd-current.sentex.ca> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Marshall Kirk McKusick , current@freebsd.org, sparc64@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 09:19:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 3/24/13 12:20 AM, FreeBSD Tinderbox wrote: > TB --- 2013-03-24 06:26:48 - tinderbox 2.10 running on > freebsd-current.sentex.ca TB --- 2013-03-24 06:26:48 - FreeBSD > freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: > Mon Mar 26 13:54:12 EDT 2012 > des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 > TB --- 2013-03-24 06:26:48 - starting HEAD tinderbox run for > sparc64/sparc64 TB --- 2013-03-24 06:26:48 - cleaning the object > tree TB --- 2013-03-24 06:26:48 - /usr/local/bin/svn stat /src TB > --- 2013-03-24 06:26:53 - At svn revision 248671 TB --- 2013-03-24 > 06:26:54 - building world TB --- 2013-03-24 06:26:54 - > CROSS_BUILD_TESTING=YES TB --- 2013-03-24 06:26:54 - > MAKEOBJDIRPREFIX=/obj TB --- 2013-03-24 06:26:54 - > PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-24 06:26:54 - > SRCCONF=/dev/null TB --- 2013-03-24 06:26:54 - TARGET=sparc64 TB > --- 2013-03-24 06:26:54 - TARGET_ARCH=sparc64 TB --- 2013-03-24 > 06:26:54 - TZ=UTC TB --- 2013-03-24 06:26:54 - > __MAKE_CONF=/dev/null TB --- 2013-03-24 06:26:54 - cd /src TB --- > 2013-03-24 06:26:54 - /usr/bin/make -B buildworld >>>> Building an up-to-date make(1) World build started on Sun Mar >>>> 24 06:26:59 UTC 2013 Rebuilding the temporary build tree >>>> stage 1.1: legacy release compatibility shims stage 1.2: >>>> bootstrap tools stage 2.1: cleaning up the object tree stage >>>> 2.2: rebuilding the object tree stage 2.3: build tools stage >>>> 3: cross tools stage 4.1: building includes stage 4.2: >>>> building libraries stage 4.3: make dependencies stage 4.4: >>>> building everything > [...] cc -O2 -pipe -I/src/sbin/fsck_ffs > -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -fstack-protector > -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized > -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O2 -pipe > -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE > -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall > -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c > /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors > /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': > /src/sbin/fsck_ffs/fsutil.c:511: warning: format '%d' expects type > 'int', but argument 2 has type 'time_t' > /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%4d' expects type > 'int', but argument 6 has type 'time_t' > /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%2jd' expects > type 'intmax_t', but argument 8 has type 'long long int' > /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%jd' expects type > 'intmax_t', but argument 9 has type 'long long int' *** [fsutil.o] > Error code 1 This should fix the issue, can someone review and commit it? Index: sbin/fsck_ffs/fsutil.c =================================================================== - --- sbin/fsck_ffs/fsutil.c (revision 248678) +++ sbin/fsck_ffs/fsutil.c (working copy) @@ -507,8 +507,8 @@ static void printIOstats(void) clock_gettime(CLOCK_REALTIME_PRECISE, &finishpass); timespecsub(&finishpass, &startpass); - - printf("Running time: %ld.%03ld msec\n", - - finishpass.tv_sec, finishpass.tv_nsec / 1000000); + printf("Running time: %jd.%03jd msec\n", + (intmax_t)finishpass.tv_sec, (intmax_t)finishpass.tv_nsec / 1000000); printf("buffer reads by type:\n"); for (totalmsec = 0, i = 0; i < BT_NUMBUFTYPES; i++) totalmsec += readtime[i].tv_sec * 1000 + @@ -519,10 +519,10 @@ static void printIOstats(void) if (readcnt[i] == 0) continue; msec = readtime[i].tv_sec * 1000 + readtime[i].tv_nsec / 1000000; - - printf("%21s:%8ld %2ld.%ld%% %4ld.%03ld sec %2lld.%lld%%\n", + printf("%21s:%8ld %2ld.%ld%% %4jd.%03jd sec %2lld.%lld%%\n", buftype[i], readcnt[i], readcnt[i] * 100 / diskreads, (readcnt[i] * 1000 / diskreads) % 10, - - readtime[i].tv_sec, readtime[i].tv_nsec / 1000000, + (intmax_t)readtime[i].tv_sec, (intmax_t)readtime[i].tv_nsec / 1000000, msec * 100 / totalmsec, (msec * 1000 / totalmsec) % 10); } printf("\n"); Cheers, -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJRTsUUAAoJEG80Jeu8UPuziSkIAImVgY8aEExJ1b2zLu2wLL2y hHpQ+oMf63WFEQ3XN+wYnY0sZyjpBCTUULkdSQPbnj9eymJ8UkaPkdvE2JN4jWDu UqTuSI4E7IYZpoH06LiAZTnNFI0+H072sdFTw7bUVwLTm4x7lOUD2G9JFZCOhBKi QyXJ1r6i/jTORoRH+3oAYEl5hZk9IniFBkQp7i5Elzm/mxFpT/H7b48ptTmv+3+o fKRLduuu6zNd+DtCOUmPAgyOOLyh1szAxhoIdQj5iopRgzdS1f5uQ7xP+SWqDhrl PdT8YtEfFuXFeAg+PpgDWTank7lMKn4QBNn9g4CsvLrs4eA/JN3aSStuMWkzfgQ= =VsRR -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 09:41:08 2013 Return-Path: Delivered-To: current@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 070D8CA3; Sun, 24 Mar 2013 09:41:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BB16F91; Sun, 24 Mar 2013 09:41:07 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2O9f6cx096789; Sun, 24 Mar 2013 05:41:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2O9f6V8096787; Sun, 24 Mar 2013 09:41:06 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Mar 2013 09:41:06 GMT Message-Id: <201303240941.r2O9f6V8096787@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 09:41:08 -0000 TB --- 2013-03-24 08:00:26 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-24 08:00:26 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-24 08:00:26 - starting HEAD tinderbox run for arm/arm TB --- 2013-03-24 08:00:26 - cleaning the object tree TB --- 2013-03-24 08:03:22 - /usr/local/bin/svn stat /src TB --- 2013-03-24 08:03:25 - At svn revision 248678 TB --- 2013-03-24 08:03:26 - building world TB --- 2013-03-24 08:03:26 - CROSS_BUILD_TESTING=YES TB --- 2013-03-24 08:03:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-24 08:03:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-24 08:03:26 - SRCCONF=/dev/null TB --- 2013-03-24 08:03:26 - TARGET=arm TB --- 2013-03-24 08:03:26 - TARGET_ARCH=arm TB --- 2013-03-24 08:03:26 - TZ=UTC TB --- 2013-03-24 08:03:26 - __MAKE_CONF=/dev/null TB --- 2013-03-24 08:03:26 - cd /src TB --- 2013-03-24 08:03:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 24 08:03:30 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] echo fsck_ffs: /obj/arm.arm/src/tmp/usr/lib/libc.a /obj/arm.arm/src/tmp/usr/lib/libufs.a >> .depend cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/dir.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:511: warning: format '%ld' expects type 'long int', but argument 2 has type 'time_t' /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%4ld' expects type 'long int', but argument 6 has type 'time_t' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/arm.arm/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-24 09:41:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-24 09:41:06 - ERROR: failed to build world TB --- 2013-03-24 09:41:06 - 4705.08 user 839.47 system 6040.21 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 09:41:08 2013 Return-Path: Delivered-To: current@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 14A0ACA4; Sun, 24 Mar 2013 09:41:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C96D492; Sun, 24 Mar 2013 09:41:07 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2O9f6Ml096788; Sun, 24 Mar 2013 05:41:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2O9f66f096786; Sun, 24 Mar 2013 09:41:06 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Mar 2013 09:41:06 GMT Message-Id: <201303240941.r2O9f66f096786@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 09:41:08 -0000 TB --- 2013-03-24 08:00:26 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-24 08:00:26 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-24 08:00:26 - starting HEAD tinderbox run for armv6/arm TB --- 2013-03-24 08:00:26 - cleaning the object tree TB --- 2013-03-24 08:03:21 - /usr/local/bin/svn stat /src TB --- 2013-03-24 08:03:25 - At svn revision 248678 TB --- 2013-03-24 08:03:26 - building world TB --- 2013-03-24 08:03:26 - CROSS_BUILD_TESTING=YES TB --- 2013-03-24 08:03:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-24 08:03:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-24 08:03:26 - SRCCONF=/dev/null TB --- 2013-03-24 08:03:26 - TARGET=arm TB --- 2013-03-24 08:03:26 - TARGET_ARCH=armv6 TB --- 2013-03-24 08:03:26 - TZ=UTC TB --- 2013-03-24 08:03:26 - __MAKE_CONF=/dev/null TB --- 2013-03-24 08:03:26 - cd /src TB --- 2013-03-24 08:03:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 24 08:03:30 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] echo fsck_ffs: /obj/arm.armv6/src/tmp/usr/lib/libc.a /obj/arm.armv6/src/tmp/usr/lib/libufs.a >> .depend cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/dir.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:511: warning: format '%ld' expects type 'long int', but argument 2 has type 'time_t' /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%4ld' expects type 'long int', but argument 6 has type 'time_t' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/arm.armv6/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-24 09:41:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-24 09:41:06 - ERROR: failed to build world TB --- 2013-03-24 09:41:06 - 4701.84 user 840.66 system 6040.16 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 09:46:36 2013 Return-Path: Delivered-To: freebsd-current@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 5DBD5204F for ; Sun, 24 Mar 2013 09:46:36 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep12.mx.upcmail.net (fep12.mx.upcmail.net [62.179.121.32]) by mx1.freebsd.org (Postfix) with ESMTP id ABDD1FB for ; Sun, 24 Mar 2013 09:46:35 +0000 (UTC) Received: from edge03.upcmail.net ([192.168.13.238]) by viefep12-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20130324094628.NJDQ14414.viefep12-int.chello.at@edge03.upcmail.net> for ; Sun, 24 Mar 2013 10:46:28 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge03.upcmail.net with edge id FMmT1l01W2xdvHc03MmTDo; Sun, 24 Mar 2013 10:46:28 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 9813F6D449; Sun, 24 Mar 2013 10:46:27 +0100 (CET) Date: Sun, 24 Mar 2013 10:46:27 +0100 From: Stefan Farfeleder To: freebsd-current@freebsd.org Subject: Re: sysctl panic on cold boot Message-ID: <20130324094627.GA1440@mole.fafoe.narf.at> References: <20130321082838.GA1468@mole.fafoe.narf.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130321082838.GA1468@mole.fafoe.narf.at> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 09:46:36 -0000 I'd like to report that my notebook is now booting fine again with r248646. Stefan From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 10:31:47 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 18CB72AA4; Sun, 24 Mar 2013 10:31:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id CC753216; Sun, 24 Mar 2013 10:31:46 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2OAVkQS082431; Sun, 24 Mar 2013 06:31:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2OAVkjc082426; Sun, 24 Mar 2013 10:31:46 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Mar 2013 10:31:46 GMT Message-Id: <201303241031.r2OAVkjc082426@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 10:31:47 -0000 TB --- 2013-03-24 08:00:26 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-24 08:00:26 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-24 08:00:26 - starting HEAD tinderbox run for i386/i386 TB --- 2013-03-24 08:00:26 - cleaning the object tree TB --- 2013-03-24 08:00:26 - /usr/local/bin/svn stat /src TB --- 2013-03-24 08:00:30 - At svn revision 248678 TB --- 2013-03-24 08:00:31 - building world TB --- 2013-03-24 08:00:31 - CROSS_BUILD_TESTING=YES TB --- 2013-03-24 08:00:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-24 08:00:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-24 08:00:31 - SRCCONF=/dev/null TB --- 2013-03-24 08:00:31 - TARGET=i386 TB --- 2013-03-24 08:00:31 - TARGET_ARCH=i386 TB --- 2013-03-24 08:00:31 - TZ=UTC TB --- 2013-03-24 08:00:31 - __MAKE_CONF=/dev/null TB --- 2013-03-24 08:00:31 - cd /src TB --- 2013-03-24 08:00:31 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 24 08:00:37 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/sbin/fsck_ffs/fsutil.c /src/sbin/fsck_ffs/fsutil.c:511:3: error: format specifies type 'long' but the argument has type 'time_t' (aka 'int') [-Werror,-Wformat] finishpass.tv_sec, finishpass.tv_nsec / 1000000); ^~~~~~~~~~~~~~~~~ /src/sbin/fsck_ffs/fsutil.c:525:7: error: format specifies type 'long' but the argument has type 'time_t' (aka 'int') [-Werror,-Wformat] readtime[i].tv_sec, readtime[i].tv_nsec / 1000000, ^~~~~~~~~~~~~~~~~~ 2 errors generated. *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/i386.i386/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-24 10:31:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-24 10:31:46 - ERROR: failed to build world TB --- 2013-03-24 10:31:46 - 7476.37 user 990.50 system 9079.44 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 10:47:31 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EEC1F103A; Sun, 24 Mar 2013 10:47:31 +0000 (UTC) (envelope-from seanwbruno@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id BEED727D; Sun, 24 Mar 2013 10:47:31 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id fa10so571529pad.41 for ; Sun, 24 Mar 2013 03:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:from:reply-to:to:cc:in-reply-to:references :content-type:date:message-id:mime-version:x-mailer; bh=+HqJRG6Lqbdgywb1DQieBKGnPAUti3broKyHCLWPVo8=; b=IT+nQIjoX6cRy3UUtDrjxOaHjSZsPJ6r59e7r+u1pYr0KQvrbKVFMxIJupIh1vs+hu hXC04ZVja5RxBKDGx1XEDSkMJbkZHri0Q/tTvHp+hGsIPS6WZo2nBZWZUZk7ZFicw/g9 zwN4/RzuE3YnbJUp7Q7oUxhFwRlXgaBHbjn3ULmJmiN9PGTQxhj/JJ+NNtXAvOpF+riV kZkB54s7CVHfzB9JLZQW1sj/xrJKvagHmvollKwr95GU5ffiK//BgNYuSdJOO3+7b0fL soeYj9jfUgoL3/o7y7d8icwagSJAyyc++BO5BIhScguwW+Q5oJSRzWXEYHfDwve84kv6 Rk0A== X-Received: by 10.66.100.138 with SMTP id ey10mr12211680pab.131.1364122051212; Sun, 24 Mar 2013 03:47:31 -0700 (PDT) Received: from [192.168.1.210] (c-71-202-40-63.hsd1.ca.comcast.net. [71.202.40.63]) by mx.google.com with ESMTPS id oq3sm10369146pac.16.2013.03.24.03.47.28 (version=SSLv3 cipher=RC4-SHA bits=128/128); Sun, 24 Mar 2013 03:47:29 -0700 (PDT) Subject: Re: [head tinderbox] failure on i386/i386 From: Sean Bruno To: FreeBSD Tinderbox In-Reply-To: <201303241031.r2OAVkjc082426@freebsd-current.sentex.ca> References: <201303241031.r2OAVkjc082426@freebsd-current.sentex.ca> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-oDb4iXW5IBllQeyKz935" Date: Sun, 24 Mar 2013 03:47:27 -0700 Message-ID: <1364122047.16261.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: current@freebsd.org, i386@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 10:47:32 -0000 --=-oDb4iXW5IBllQeyKz935 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > [...] > cc -O2 -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE= -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror= -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body= -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-pare= ntheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-swit= ch-enum -Wno-knr-promoted-parameter -c /src/sbin/fsck_ffs/fsutil.c > /src/sbin/fsck_ffs/fsutil.c:511:3: error: format specifies type 'long' bu= t the argument has type 'time_t' (aka 'int') [-Werror,-Wformat] > finishpass.tv_sec, finishpass.tv_nsec / 1000000); > ^~~~~~~~~~~~~~~~~ > /src/sbin/fsck_ffs/fsutil.c:525:7: error: format specifies type 'long' bu= t the argument has type 'time_t' (aka 'int') [-Werror,-Wformat] > readtime[i].tv_sec, readtime[i].tv_nsec / 1000000, > ^~~~~~~~~~~~~~~~~~ > 2 errors generated. > *** [fsutil.o] Error code 1 Should be squished now. r248680 --=-oDb4iXW5IBllQeyKz935 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAABAgAGBQJRTtm/AAoJEBkJRdwI6BaH+WwH/A912sb6WKRtPLWHeW1mXiuB 9AEij9vrGbbatwVTZTh48Df7pih0U365ik7ntK7gngWVGZwlRH5SXUXZsAf6qk2i c0cZmUfbmJcYQ6HIKGl1+J8hLyHogF8fyrMAI7Gj9oC1e3trnj97pPUbvDGql1LO TNEyQy3Tp4/gAtSKMXDeU+oTsyT93rLcSrNJ3T0GBIzAX+sXpitsKd+x+eHf48Jl KGRlqMhke0UXOVJfDkxSPAavYK7384+tVcsr0Kqw45P/0FpzZCp78tYrHlx8EWga ipsW5BvUDnj0jHmZDezYjitQPepUtM2LE1jPKTTb+uEFhLp9ortWgFsA8t4rTW4= =zSvo -----END PGP SIGNATURE----- --=-oDb4iXW5IBllQeyKz935-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 10:50:42 2013 Return-Path: Delivered-To: current@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 ECB6311BB; Sun, 24 Mar 2013 10:50:42 +0000 (UTC) (envelope-from seanwbruno@gmail.com) Received: from mail-da0-x229.google.com (mail-da0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) by mx1.freebsd.org (Postfix) with ESMTP id BE2652A1; Sun, 24 Mar 2013 10:50:42 +0000 (UTC) Received: by mail-da0-f41.google.com with SMTP id w4so2843654dam.0 for ; Sun, 24 Mar 2013 03:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:from:reply-to:to:cc:in-reply-to:references :content-type:date:message-id:mime-version:x-mailer; bh=vmC1mvxyR3HSNQn3O4uGlReoZNNZQUBRZl6XZ1KfARs=; b=01Me0bTZ7+L4hPNl6PxqIvLD0ngC1zp9SCri2bxvHYUiHLooAqIo3XwQQkyeqwP8W2 3CQ6ZQft0uYC7rJzHDKmBb42gHz30gbGQ1XM7sZN3gfbh78CWjan2Kknn4AqbrFABc7A /ufBSYcN2WuDfpM9ERGKumokCfQ68dhwAZWVmn9dSgncUGOB2EKKVlGZNXauY5OktLPc 9Ptn7PNzaY2G/XXZOIeUUSaJRGi4a/y22LkxH3d8E32uxVIglXR6oIWe09ZYrvSVyMav gqroe02VUN23ptH+qk3Tu1IlOjvzIFcqN+MR/LPq4xeOkgSJFfeOP+jSrkQy+kGis3vG HxXQ== X-Received: by 10.68.49.106 with SMTP id t10mr11778814pbn.63.1364122242151; Sun, 24 Mar 2013 03:50:42 -0700 (PDT) Received: from [192.168.1.210] (c-71-202-40-63.hsd1.ca.comcast.net. [71.202.40.63]) by mx.google.com with ESMTPS id wi7sm10400098pac.9.2013.03.24.03.50.40 (version=SSLv3 cipher=RC4-SHA bits=128/128); Sun, 24 Mar 2013 03:50:40 -0700 (PDT) Subject: Re: [head tinderbox] failure on ia64/ia64 From: Sean Bruno To: FreeBSD Tinderbox In-Reply-To: <201303240357.r2O3vCDg030387@freebsd-current.sentex.ca> References: <201303240357.r2O3vCDg030387@freebsd-current.sentex.ca> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-harvPyL9F/atV3yj8rkR" Date: Sun, 24 Mar 2013 03:50:39 -0700 Message-ID: <1364122239.16261.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: current@freebsd.org, ia64@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 10:50:43 -0000 --=-harvPyL9F/atV3yj8rkR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Sun, 2013-03-24 at 03:57 +0000, FreeBSD Tinderbox wrote: > cc -O2 -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount > -DRESCUE -std=3Dgnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k > -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c > cc -O2 -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount > -DRESCUE -std=3Dgnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k > -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c > cc1: warnings being treated as errors > /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': > /src/sbin/fsck_ffs/fsutil.c:511: warning: format '%d' expects type > 'int', but argument 2 has type 'time_t' > /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%4d' expects type > 'int', but argument 6 has type 'time_t' > /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%2jd' expects type > 'intmax_t', but argument 8 has type 'long long int' > /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%jd' expects type > 'intmax_t', but argument 9 has type 'long long int' > *** [fsutil.o] Error code 1 >=20 > Stop in /src/sbin/fsck_ffs. > *** [fsck_ffs_make] Error code 1=20 Seems happy now at svn r248680 --=-harvPyL9F/atV3yj8rkR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAABAgAGBQJRTtp/AAoJEBkJRdwI6BaHeNUH/A7fOmAUNU3ogXfmUtmqghyZ P67O73WV1TGn99MHFVQpsu9qhw1Q8u+FA5fskrcg35+kSp5GAO5637Kd46VH9t45 mJ9nXicjJlUJoWsrmX5WwpMzxYXXk1VfzRym2Qs47b/NfQ/JsNlx5ANdF4LQFY5o xssFwMoO7NpD+SetLrTyzn93VSy/87gomBMJPpOiqNNihZtPZsdB6gGcjwC41gWF Zt2ShZ4EzquMwEdyv5JuKE8nXJW7BRmxEVxQnyui4Eu3PomaU6rv6n8OT545Rzwj ZMHqahlOLSk5zBxYqKZ6bKhqaexjxoYkLgx/kvr7GpWnC2+Is9ajL/+kz0ltPHk= =HKnC -----END PGP SIGNATURE----- --=-harvPyL9F/atV3yj8rkR-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 11:23:06 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 205EA1910; Sun, 24 Mar 2013 11:23:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D296C378; Sun, 24 Mar 2013 11:23:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2OBN440061919; Sun, 24 Mar 2013 07:23:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2OBN4Oc061918; Sun, 24 Mar 2013 11:23:04 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Mar 2013 11:23:04 GMT Message-Id: <201303241123.r2OBN4Oc061918@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 11:23:06 -0000 TB --- 2013-03-24 10:31:46 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-24 10:31:46 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-24 10:31:46 - starting HEAD tinderbox run for mips/mips TB --- 2013-03-24 10:31:46 - cleaning the object tree TB --- 2013-03-24 10:32:22 - /usr/local/bin/svn stat /src TB --- 2013-03-24 10:32:25 - At svn revision 248678 TB --- 2013-03-24 10:32:26 - building world TB --- 2013-03-24 10:32:26 - CROSS_BUILD_TESTING=YES TB --- 2013-03-24 10:32:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-24 10:32:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-24 10:32:26 - SRCCONF=/dev/null TB --- 2013-03-24 10:32:26 - TARGET=mips TB --- 2013-03-24 10:32:26 - TARGET_ARCH=mips TB --- 2013-03-24 10:32:26 - TZ=UTC TB --- 2013-03-24 10:32:26 - __MAKE_CONF=/dev/null TB --- 2013-03-24 10:32:26 - cd /src TB --- 2013-03-24 10:32:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 24 10:32:31 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] echo fsck_ffs: /obj/mips.mips/src/tmp/usr/lib/libc.a /obj/mips.mips/src/tmp/usr/lib/libufs.a >> .depend cc -O -pipe -G0 -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/dir.c cc -O -pipe -G0 -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O -pipe -G0 -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:511: warning: format '%ld' expects type 'long int', but argument 2 has type 'time_t' /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%4ld' expects type 'long int', but argument 6 has type 'time_t' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/mips.mips/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-24 11:23:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-24 11:23:04 - ERROR: failed to build world TB --- 2013-03-24 11:23:04 - 2146.46 user 608.43 system 3078.52 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 12:05:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C5A2016FA; Sun, 24 Mar 2013 12:05:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3FEEA820; Sun, 24 Mar 2013 12:05:11 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2OC57k0082412; Sun, 24 Mar 2013 14:05:07 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2OC57k0082412 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2OC57g2082407; Sun, 24 Mar 2013 14:05:07 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 24 Mar 2013 14:05:07 +0200 From: Konstantin Belousov To: Ivan Klymenko Subject: Re: Kernel panic CURRENT r248596 at virtualbox-ose-kmod module load Message-ID: <20130324120507.GX3794@kib.kiev.ua> References: <20130323132627.04bf7ef4@nonamehost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vEdmTXXA9+5BA9oB" Content-Disposition: inline In-Reply-To: <20130323132627.04bf7ef4@nonamehost> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 12:05:11 -0000 --vEdmTXXA9+5BA9oB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 23, 2013 at 01:26:27PM +0200, Ivan Klymenko wrote: > I have > uname -a > FreeBSD nonamehost 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248596: Fri > Mar 22 01:17:08 EET 2013 > ivan@nonamehost:/usr/obj/usr/src/sys/GENERIC amd64 >=20 > I updated the ports tree to r314921 and recompiled virtualbox-ose-kmod >=20 > After load the module a have kernel panic. >=20 > Panic String: Lock vm object not exclusively locked @ > /usr/src/sys/vm/vm_page.c:1396 >=20 > http://pkgupdate.nevosoft.ru/backtrace.txt This looks like a vbox issue, the driver did not properly locked the object passed to the vm_page_alloc_contig(). If you want this fixed, you probably need to look up the code yourself, compiling the vbox kld with debugging, finding the offending call to vm_page_alloc_contig() and looking around it to see which object is passed and why it is not locked. --vEdmTXXA9+5BA9oB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRTuvyAAoJEJDCuSvBvK1BtA0P/3MSDsivMhCMTgXZrkxxW1Ih LqA4LFGMeSrPpEaCXBIb4JceREUPJHJj4lajhS5uXtmX8Pl5SfF6YKaPH6E5Vm9G vD2h5Wg2vjaI3l6Hb6DqEZBRvscu7nJywpAfFFG8ML3WPD28QawBx985wWdFraBz YL3Hex7s0ORudnrRNAsqVMGIgCTH0PRxlTtis5ZvRs0N/9LNS1S7mdP4nP+RU229 RzsoBCeKbETv2r2BbAPzeUVbkxA+TOH+wljzH9cZ7DVusASQCAfkOzGBBt9soijp PiWzCZgh6QtWfzMu9aCVskWNjnD7BFunSROxJjF8XArnCEkxYQ3m0oiuhcIS7lIV /uHY3BPUijgoXJchrwLf1FwVnQtiQpQfVPpy3gXYYHLEPD7LJVdFV9DTF/154PZD z8SoFwiO+zW+U//lIN7cdUNBoupIFOgBPlm5QvfNDSuq8n1kz/t0Eu05ta6Crmr6 9hUD7eHyK+QlJA5897NHUUHGKsD0gbznl8bPaue5HOCyL6VNLgAaKyn8+774L84F kgW84MPVaQfsZJ3zBMCglRd6ZGgdRWm3QF4XQphIEX1PId5+hBccheqOmjN0wInI hoRiaaiebov1XW2ipCtG6K+IzwxfXM00DO1hG9xEEXcnAcjXLnlwj3f1RIrj6F7c w97YKMpC7NAo3qWq86X2 =0wUr -----END PGP SIGNATURE----- --vEdmTXXA9+5BA9oB-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 12:17:13 2013 Return-Path: Delivered-To: current@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 B4A651D82; Sun, 24 Mar 2013 12:17:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 71BF58B7; Sun, 24 Mar 2013 12:17:13 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2OCHCpe041175; Sun, 24 Mar 2013 08:17:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2OCHCkC041168; Sun, 24 Mar 2013 12:17:12 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Mar 2013 12:17:12 GMT Message-Id: <201303241217.r2OCHCkC041168@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 12:17:13 -0000 TB --- 2013-03-24 09:41:07 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-24 09:41:07 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-24 09:41:07 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-03-24 09:41:07 - cleaning the object tree TB --- 2013-03-24 09:41:07 - /usr/local/bin/svn stat /src TB --- 2013-03-24 09:41:12 - At svn revision 248678 TB --- 2013-03-24 09:41:13 - building world TB --- 2013-03-24 09:41:13 - CROSS_BUILD_TESTING=YES TB --- 2013-03-24 09:41:13 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-24 09:41:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-24 09:41:13 - SRCCONF=/dev/null TB --- 2013-03-24 09:41:13 - TARGET=pc98 TB --- 2013-03-24 09:41:13 - TARGET_ARCH=i386 TB --- 2013-03-24 09:41:13 - TZ=UTC TB --- 2013-03-24 09:41:13 - __MAKE_CONF=/dev/null TB --- 2013-03-24 09:41:13 - cd /src TB --- 2013-03-24 09:41:13 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 24 09:41:18 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/sbin/fsck_ffs/fsutil.c /src/sbin/fsck_ffs/fsutil.c:511:3: error: format specifies type 'long' but the argument has type 'time_t' (aka 'int') [-Werror,-Wformat] finishpass.tv_sec, finishpass.tv_nsec / 1000000); ^~~~~~~~~~~~~~~~~ /src/sbin/fsck_ffs/fsutil.c:525:7: error: format specifies type 'long' but the argument has type 'time_t' (aka 'int') [-Werror,-Wformat] readtime[i].tv_sec, readtime[i].tv_nsec / 1000000, ^~~~~~~~~~~~~~~~~~ 2 errors generated. *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/pc98.i386/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-24 12:17:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-24 12:17:12 - ERROR: failed to build world TB --- 2013-03-24 12:17:12 - 7725.13 user 1097.77 system 9365.73 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 14:19:58 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 578DE934; Sun, 24 Mar 2013 14:19:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 16FD0D14; Sun, 24 Mar 2013 14:19:57 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2OEJvLd018022; Sun, 24 Mar 2013 10:19:57 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2OEJvI5018008; Sun, 24 Mar 2013 14:19:57 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Mar 2013 14:19:57 GMT Message-Id: <201303241419.r2OEJvI5018008@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 14:19:58 -0000 TB --- 2013-03-24 12:10:45 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-24 12:10:45 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-24 12:10:45 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-03-24 12:10:45 - cleaning the object tree TB --- 2013-03-24 12:10:45 - /usr/local/bin/svn stat /src TB --- 2013-03-24 12:10:49 - At svn revision 248678 TB --- 2013-03-24 12:10:50 - building world TB --- 2013-03-24 12:10:50 - CROSS_BUILD_TESTING=YES TB --- 2013-03-24 12:10:50 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-24 12:10:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-24 12:10:50 - SRCCONF=/dev/null TB --- 2013-03-24 12:10:50 - TARGET=powerpc TB --- 2013-03-24 12:10:50 - TARGET_ARCH=powerpc TB --- 2013-03-24 12:10:50 - TZ=UTC TB --- 2013-03-24 12:10:50 - __MAKE_CONF=/dev/null TB --- 2013-03-24 12:10:50 - cd /src TB --- 2013-03-24 12:10:50 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 24 12:10:55 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] echo fsck_ffs: /obj/powerpc.powerpc/src/tmp/usr/lib/libc.a /obj/powerpc.powerpc/src/tmp/usr/lib/libufs.a >> .depend cc -O2 -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/dir.c cc -O2 -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O2 -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:511: warning: format '%ld' expects type 'long int', but argument 2 has type 'time_t' /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%4ld' expects type 'long int', but argument 6 has type 'time_t' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/powerpc.powerpc/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-24 14:19:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-24 14:19:56 - ERROR: failed to build world TB --- 2013-03-24 14:19:56 - 6499.12 user 820.65 system 7751.77 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 24 22:33:08 2013 Return-Path: Delivered-To: current@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 614B8B4F; Sun, 24 Mar 2013 22:33:08 +0000 (UTC) (envelope-from moonwonje@gmail.com) Received: from mail-gh0-f185.google.com (mail-gh0-f185.google.com [209.85.160.185]) by mx1.freebsd.org (Postfix) with ESMTP id 0F89F93E; Sun, 24 Mar 2013 22:33:07 +0000 (UTC) Received: by mail-gh0-f185.google.com with SMTP id z17so684804ghb.2 for ; Sun, 24 Mar 2013 15:33:01 -0700 (PDT) X-Received: by 10.50.93.33 with SMTP id cr1mr785380igb.5.1364164381626; Sun, 24 Mar 2013 15:33:01 -0700 (PDT) Path: glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: fa.freebsd.current Date: Sun, 24 Mar 2013 15:33:01 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=116.33.147.136; posting-account=4YXSIgoAAACJewrxKogB2dHIrFhGS-nD NNTP-Posting-Host: 116.33.147.136 References: User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-IP: 116.33.147.136 MIME-Version: 1.0 Message-ID: Subject: Re: [head tinderbox] failure on mips/mips From: moonwonje@gmail.com To: fa.freebsd.current@googlegroups.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 24 Mar 2013 23:37:52 +0000 Cc: mips@freebsd.org, FreeBSD Tinderbox , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 22:33:08 -0000 On Tuesday, March 19, 2013 4:11:32 PM UTC+9, FreeBSD Tinderbox wrote: > TB --- 2013-03-19 04:49:40 - tinderbox 2.10 running on freebsd-current.se= ntex.ca TB --- 2013-03-19 04:49:40 - FreeBSD freebsd-current.sentex.ca 8.3-= PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@free= bsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-19 = 04:49:40 - starting HEAD tinderbox run for mips/mips TB --- 2013-03-19 04:4= 9:40 - cleaning the object tree TB --- 2013-03-19 04:49:40 - /usr/local/bin= /svn stat /src TB --- 2013-03-19 04:49:59 - At svn revision 248477 TB --- 2= 013-03-19 04:50:00 - building world TB --- 2013-03-19 04:50:00 - CROSS_BUIL= D_TESTING=3DYES TB --- 2013-03-19 04:50:00 - MAKEOBJDIRPREFIX=3D/obj TB ---= 2013-03-19 04:50:00 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-= 19 04:50:00 - SRCCONF=3D/dev/null TB --- 2013-03-19 04:50:00 - TARGET=3Dmip= s TB --- 2013-03-19 04:50:00 - TARGET_ARCH=3Dmips TB --- 2013-03-19 04:50:0= 0 - TZ=3DUTC TB --- 2013-03-19 04:50:00 - __MAKE_CONF=3D/dev/null TB --- 20= 13-03-19 04:50:00 - cd /src TB --- 2013-03-19 04:50:00 - /usr/bin/make -B b= uildworld >>> Building an up-to-date make(1) >>> World build started on Tue= Mar 19 04:50:05 UTC 2013 >>> Rebuilding the temporary build tree >>> stage= 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>>= stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the objec= t tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: b= uilding includes >>> stage 4.2: building libraries >>> stage 4.3: make depe= ndencies >>> stage 4.4: building everything >>> World build completed on Tu= e Mar 19 05:53:22 UTC 2013 TB --- 2013-03-19 05:53:22 - cd /src/sys/mips/co= nf TB --- 2013-03-19 05:53:22 - /usr/sbin/config -m ADM5120 TB --- 2013-03-= 19 05:53:22 - skipping ADM5120 kernel TB --- 2013-03-19 05:53:22 - cd /src/= sys/mips/conf TB --- 2013-03-19 05:53:22 - /usr/sbin/config -m ALCHEMY TB -= -- 2013-03-19 05:53:22 - skipping ALCHEMY kernel TB --- 2013-03-19 05:53:22= - cd /src/sys/mips/conf TB --- 2013-03-19 05:53:22 - /usr/sbin/config -m A= P91 TB --- 2013-03-19 05:53:22 - building AP91 kernel TB --- 2013-03-19 05:= 53:22 - CROSS_BUILD_TESTING=3DYES TB --- 2013-03-19 05:53:22 - MAKEOBJDIRPR= EFIX=3D/obj TB --- 2013-03-19 05:53:22 - PATH=3D/usr/bin:/usr/sbin:/bin:/sb= in TB --- 2013-03-19 05:53:22 - SRCCONF=3D/dev/null TB --- 2013-03-19 05:53= :22 - TARGET=3Dmips TB --- 2013-03-19 05:53:22 - TARGET_ARCH=3Dmips TB --- = 2013-03-19 05:53:22 - TZ=3DUTC TB --- 2013-03-19 05:53:22 - __MAKE_CONF=3D/= dev/null TB --- 2013-03-19 05:53:22 - cd /src TB --- 2013-03-19 05:53:22 - = /usr/bin/make -B buildkernel KERNCONF=3DAP91 >>> Kernel build for AP91 star= ted on Tue Mar 19 05:53:22 UTC 2013 >>> stage 1: configuring the kernel >>>= stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the objec= t tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> st= age 3.2: building everything >>> Kernel build for AP91 completed on Tue Mar= 19 05:57:31 UTC 2013 TB --- 2013-03-19 05:57:31 - cd /src/sys/mips/conf TB= --- 2013-03-19 05:57:31 - /usr/sbin/config -m AP93 TB --- 2013-03-19 05:57= :31 - building AP93 kernel TB --- 2013-03-19 05:57:31 - CROSS_BUILD_TESTING= =3DYES TB --- 2013-03-19 05:57:31 - MAKEOBJDIRPREFIX=3D/obj TB --- 2013-03-= 19 05:57:31 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 05:57:= 31 - SRCCONF=3D/dev/null TB --- 2013-03-19 05:57:31 - TARGET=3Dmips TB --- = 2013-03-19 05:57:31 - TARGET_ARCH=3Dmips TB --- 2013-03-19 05:57:31 - TZ=3D= UTC TB --- 2013-03-19 05:57:31 - __MAKE_CONF=3D/dev/null TB --- 2013-03-19 = 05:57:31 - cd /src TB --- 2013-03-19 05:57:31 - /usr/bin/make -B buildkerne= l KERNCONF=3DAP93 >>> Kernel build for AP93 started on Tue Mar 19 05:57:31 = UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the= object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build= tools >>> stage 3.1: making dependencies >>> stage 3.2: building everythin= g >>> Kernel build for AP93 completed on Tue Mar 19 06:01:20 UTC 2013 TB --= - 2013-03-19 06:01:20 - cd /src/sys/mips/conf TB --- 2013-03-19 06:01:20 - = /usr/sbin/config -m AP94 TB --- 2013-03-19 06:01:20 - building AP94 kernel = TB --- 2013-03-19 06:01:20 - CROSS_BUILD_TESTING=3DYES TB --- 2013-03-19 06= :01:20 - MAKEOBJDIRPREFIX=3D/obj TB --- 2013-03-19 06:01:20 - PATH=3D/usr/b= in:/usr/sbin:/bin:/sbin TB --- 2013-03-19 06:01:20 - SRCCONF=3D/dev/null TB= --- 2013-03-19 06:01:20 - TARGET=3Dmips TB --- 2013-03-19 06:01:20 - TARGE= T_ARCH=3Dmips TB --- 2013-03-19 06:01:20 - TZ=3DUTC TB --- 2013-03-19 06:01= :20 - __MAKE_CONF=3D/dev/null TB --- 2013-03-19 06:01:20 - cd /src TB --- 2= 013-03-19 06:01:20 - /usr/bin/make -B buildkernel KERNCONF=3DAP94 >>> Kerne= l build for AP94 started on Tue Mar 19 06:01:20 UTC 2013 >>> stage 1: confi= guring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2:= rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: makin= g dependencies >>> stage 3.2: building everything >>> Kernel build for AP94= completed on Tue Mar 19 06:06:20 UTC 2013 TB --- 2013-03-19 06:06:20 - cd = /src/sys/mips/conf TB --- 2013-03-19 06:06:20 - /usr/sbin/config -m AP96 TB= --- 2013-03-19 06:06:20 - building AP96 kernel TB --- 2013-03-19 06:06:20 = - CROSS_BUILD_TESTING=3DYES TB --- 2013-03-19 06:06:20 - MAKEOBJDIRPREFIX= =3D/obj TB --- 2013-03-19 06:06:20 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin T= B --- 2013-03-19 06:06:20 - SRCCONF=3D/dev/null TB --- 2013-03-19 06:06:20 = - TARGET=3Dmips TB --- 2013-03-19 06:06:20 - TARGET_ARCH=3Dmips TB --- 2013= -03-19 06:06:20 - TZ=3DUTC TB --- 2013-03-19 06:06:20 - __MAKE_CONF=3D/dev/= null TB --- 2013-03-19 06:06:20 - cd /src TB --- 2013-03-19 06:06:20 - /usr= /bin/make -B buildkernel KERNCONF=3DAP96 >>> Kernel build for AP96 started = on Tue Mar 19 06:06:20 UTC 2013 >>> stage 1: configuring the kernel >>> sta= ge 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tr= ee >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage = 3.2: building everything >>> Kernel build for AP96 completed on Tue Mar 19 = 06:11:01 UTC 2013 TB --- 2013-03-19 06:11:01 - cd /src/sys/mips/conf TB ---= 2013-03-19 06:11:01 - /usr/sbin/config -m AR71XX_BASE TB --- 2013-03-19 06= :11:01 - building AR71XX_BASE kernel TB --- 2013-03-19 06:11:01 - CROSS_BUI= LD_TESTING=3DYES TB --- 2013-03-19 06:11:01 - MAKEOBJDIRPREFIX=3D/obj TB --= - 2013-03-19 06:11:01 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03= -19 06:11:01 - SRCCONF=3D/dev/null TB --- 2013-03-19 06:11:01 - TARGET=3Dmi= ps TB --- 2013-03-19 06:11:01 - TARGET_ARCH=3Dmips TB --- 2013-03-19 06:11:= 01 - TZ=3DUTC TB --- 2013-03-19 06:11:01 - __MAKE_CONF=3D/dev/null TB --- 2= 013-03-19 06:11:01 - cd /src TB --- 2013-03-19 06:11:01 - /usr/bin/make -B = buildkernel KERNCONF=3DAR71XX_BASE >>> Kernel build for AR71XX_BASE started= on Tue Mar 19 06:11:01 UTC 2013 >>> stage 1: configuring the kernel >>> st= age 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object t= ree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage= 3.2: building everything >>> Kernel build for AR71XX_BASE completed on Tue= Mar 19 06:15:59 UTC 2013 TB --- 2013-03-19 06:15:59 - cd /src/sys/mips/con= f TB --- 2013-03-19 06:15:59 - /usr/sbin/config -m AR724X_BASE TB --- 2013-= 03-19 06:15:59 - building AR724X_BASE kernel TB --- 2013-03-19 06:15:59 - C= ROSS_BUILD_TESTING=3DYES TB --- 2013-03-19 06:15:59 - MAKEOBJDIRPREFIX=3D/o= bj TB --- 2013-03-19 06:15:59 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin TB ---= 2013-03-19 06:15:59 - SRCCONF=3D/dev/null TB --- 2013-03-19 06:15:59 - TAR= GET=3Dmips TB --- 2013-03-19 06:15:59 - TARGET_ARCH=3Dmips TB --- 2013-03-1= 9 06:15:59 - TZ=3DUTC TB --- 2013-03-19 06:15:59 - __MAKE_CONF=3D/dev/null = TB --- 2013-03-19 06:15:59 - cd /src TB --- 2013-03-19 06:15:59 - /usr/bin/= make -B buildkernel KERNCONF=3DAR724X_BASE >>> Kernel build for AR724X_BASE= started on Tue Mar 19 06:15:59 UTC 2013 >>> stage 1: configuring the kerne= l >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the = object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >= >> stage 3.2: building everything >>> Kernel build for AR724X_BASE complete= d on Tue Mar 19 06:19:44 UTC 2013 TB --- 2013-03-19 06:19:44 - cd /src/sys/= mips/conf TB --- 2013-03-19 06:19:44 - /usr/sbin/config -m AR91XX_BASE TB -= -- 2013-03-19 06:19:44 - building AR91XX_BASE kernel TB --- 2013-03-19 06:1= 9:44 - CROSS_BUILD_TESTING=3DYES TB --- 2013-03-19 06:19:44 - MAKEOBJDIRPRE= FIX=3D/obj TB --- 2013-03-19 06:19:44 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbi= n TB --- 2013-03-19 06:19:44 - SRCCONF=3D/dev/null TB --- 2013-03-19 06:19:= 44 - TARGET=3Dmips TB --- 2013-03-19 06:19:44 - TARGET_ARCH=3Dmips TB --- 2= 013-03-19 06:19:44 - TZ=3DUTC TB --- 2013-03-19 06:19:44 - __MAKE_CONF=3D/d= ev/null TB --- 2013-03-19 06:19:44 - cd /src TB --- 2013-03-19 06:19:44 - /= usr/bin/make -B buildkernel KERNCONF=3DAR91XX_BASE >>> Kernel build for AR9= 1XX_BASE started on Tue Mar 19 06:19:44 UTC 2013 >>> stage 1: configuring t= he kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuild= ing the object tree >>> stage 2.3: build tools >>> stage 3.1: making depend= encies >>> stage 3.2: building everything >>> Kernel build for AR91XX_BASE = completed on Tue Mar 19 06:24:33 UTC 2013 TB --- 2013-03-19 06:24:33 - cd /= src/sys/mips/conf TB --- 2013-03-19 06:24:33 - /usr/sbin/config -m BERI_DE4= _MDROOT TB --- 2013-03-19 06:24:33 - skipping BERI_DE4_MDROOT kernel TB ---= 2013-03-19 06:24:33 - cd /src/sys/mips/conf TB --- 2013-03-19 06:24:33 - /= usr/sbin/config -m BERI_DE4_SDROOT TB --- 2013-03-19 06:24:33 - skipping BE= RI_DE4_SDROOT kernel TB --- 2013-03-19 06:24:33 - cd /src/sys/mips/conf TB = --- 2013-03-19 06:24:33 - /usr/sbin/config -m BERI_SIM_MDROOT TB --- 2013-0= 3-19 06:24:33 - skipping BERI_SIM_MDROOT kernel TB --- 2013-03-19 06:24:33 = - cd /src/sys/mips/conf TB --- 2013-03-19 06:24:33 - /usr/sbin/config -m BE= RI_TEMPLATE TB --- 2013-03-19 06:24:33 - skipping BERI_TEMPLATE kernel TB -= -- 2013-03-19 06:24:33 - cd /src/sys/mips/conf TB --- 2013-03-19 06:24:33 -= /usr/sbin/config -m DIR-825 TB --- 2013-03-19 06:24:33 - building DIR-825 = kernel TB --- 2013-03-19 06:24:33 - CROSS_BUILD_TESTING=3DYES TB --- 2013-0= 3-19 06:24:33 - MAKEOBJDIRPREFIX=3D/obj TB --- 2013-03-19 06:24:33 - PATH= =3D/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 06:24:33 - SRCCONF=3D/de= v/null TB --- 2013-03-19 06:24:33 - TARGET=3Dmips TB --- 2013-03-19 06:24:3= 3 - TARGET_ARCH=3Dmips TB --- 2013-03-19 06:24:33 - TZ=3DUTC TB --- 2013-03= -19 06:24:33 - __MAKE_CONF=3D/dev/null TB --- 2013-03-19 06:24:33 - cd /src= TB --- 2013-03-19 06:24:33 - /usr/bin/make -B buildkernel KERNCONF=3DDIR-8= 25 >>> Kernel build for DIR-825 started on Tue Mar 19 06:24:34 UTC 2013 >>>= stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree= >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> s= tage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel= build for DIR-825 completed on Tue Mar 19 06:28:09 UTC 2013 TB --- 2013-03= -19 06:28:09 - cd /src/sys/mips/conf TB --- 2013-03-19 06:28:09 - /usr/sbin= /config -m GXEMUL TB --- 2013-03-19 06:28:09 - skipping GXEMUL kernel TB --= - 2013-03-19 06:28:09 - cd /src/sys/mips/conf TB --- 2013-03-19 06:28:09 - = /usr/sbin/config -m IDT TB --- 2013-03-19 06:28:09 - skipping IDT kernel TB= --- 2013-03-19 06:28:09 - cd /src/sys/mips/conf TB --- 2013-03-19 06:28:09= - /usr/sbin/config -m MALTA TB --- 2013-03-19 06:28:09 - skipping MALTA ke= rnel TB --- 2013-03-19 06:28:09 - cd /src/sys/mips/conf TB --- 2013-03-19 0= 6:28:09 - /usr/sbin/config -m MALTA64 TB --- 2013-03-19 06:28:09 - skipping= MALTA64 kernel TB --- 2013-03-19 06:28:09 - cd /src/sys/mips/conf TB --- 2= 013-03-19 06:28:09 - /usr/sbin/config -m OCTEON1 TB --- 2013-03-19 06:28:09= - skipping OCTEON1 kernel TB --- 2013-03-19 06:28:09 - cd /src/sys/mips/co= nf TB --- 2013-03-19 06:28:09 - /usr/sbin/config -m PB47 TB --- 2013-03-19 = 06:28:09 - building PB47 kernel TB --- 2013-03-19 06:28:09 - CROSS_BUILD_TE= STING=3DYES TB --- 2013-03-19 06:28:09 - MAKEOBJDIRPREFIX=3D/obj TB --- 201= 3-03-19 06:28:09 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 0= 6:28:09 - SRCCONF=3D/dev/null TB --- 2013-03-19 06:28:09 - TARGET=3Dmips TB= --- 2013-03-19 06:28:09 - TARGET_ARCH=3Dmips TB --- 2013-03-19 06:28:09 - = TZ=3DUTC TB --- 2013-03-19 06:28:09 - __MAKE_CONF=3D/dev/null TB --- 2013-0= 3-19 06:28:09 - cd /src TB --- 2013-03-19 06:28:09 - /usr/bin/make -B build= kernel KERNCONF=3DPB47 >>> Kernel build for PB47 started on Tue Mar 19 06:2= 8:09 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning u= p the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: = build tools >>> stage 3.1: making dependencies >>> stage 3.2: building ever= ything >>> Kernel build for PB47 completed on Tue Mar 19 06:32:43 UTC 2013 = TB --- 2013-03-19 06:32:43 - cd /src/sys/mips/conf TB --- 2013-03-19 06:32:= 43 - /usr/sbin/config -m PB92 TB --- 2013-03-19 06:32:43 - building PB92 ke= rnel TB --- 2013-03-19 06:32:43 - CROSS_BUILD_TESTING=3DYES TB --- 2013-03-= 19 06:32:43 - MAKEOBJDIRPREFIX=3D/obj TB --- 2013-03-19 06:32:43 - PATH=3D/= usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 06:32:43 - SRCCONF=3D/dev/nu= ll TB --- 2013-03-19 06:32:43 - TARGET=3Dmips TB --- 2013-03-19 06:32:43 - = TARGET_ARCH=3Dmips TB --- 2013-03-19 06:32:43 - TZ=3DUTC TB --- 2013-03-19 = 06:32:43 - __MAKE_CONF=3D/dev/null TB --- 2013-03-19 06:32:43 - cd /src TB = --- 2013-03-19 06:32:43 - /usr/bin/make -B buildkernel KERNCONF=3DPB92 >>> = Kernel build for PB92 started on Tue Mar 19 06:32:43 UTC 2013 >>> stage 1: = configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage= 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: = making dependencies >>> stage 3.2: building everything >>> Kernel build for= PB92 completed on Tue Mar 19 06:36:45 UTC 2013 TB --- 2013-03-19 06:36:45 = - cd /src/sys/mips/conf TB --- 2013-03-19 06:36:45 - /usr/sbin/config -m QE= MU TB --- 2013-03-19 06:36:45 - skipping QEMU kernel TB --- 2013-03-19 06:3= 6:45 - cd /src/sys/mips/conf TB --- 2013-03-19 06:36:45 - /usr/sbin/config = -m ROUTERSTATION TB --- 2013-03-19 06:36:45 - building ROUTERSTATION kernel= TB --- 2013-03-19 06:36:45 - CROSS_BUILD_TESTING=3DYES TB --- 2013-03-19 0= 6:36:45 - MAKEOBJDIRPREFIX=3D/obj TB --- 2013-03-19 06:36:45 - PATH=3D/usr/= bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 06:36:45 - SRCCONF=3D/dev/null T= B --- 2013-03-19 06:36:45 - TARGET=3Dmips TB --- 2013-03-19 06:36:45 - TARG= ET_ARCH=3Dmips TB --- 2013-03-19 06:36:45 - TZ=3DUTC TB --- 2013-03-19 06:3= 6:45 - __MAKE_CONF=3D/dev/null TB --- 2013-03-19 06:36:45 - cd /src TB --- = 2013-03-19 06:36:45 - /usr/bin/make -B buildkernel KERNCONF=3DROUTERSTATION= >>> Kernel build for ROUTERSTATION started on Tue Mar 19 06:36:45 UTC 2013= >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object = tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >= >> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Ke= rnel build for ROUTERSTATION completed on Tue Mar 19 06:41:18 UTC 2013 TB -= -- 2013-03-19 06:41:18 - cd /src/sys/mips/conf TB --- 2013-03-19 06:41:18 -= /usr/sbin/config -m ROUTERSTATION_MFS TB --- 2013-03-19 06:41:18 - buildin= g ROUTERSTATION_MFS kernel TB --- 2013-03-19 06:41:18 - CROSS_BUILD_TESTING= =3DYES TB --- 2013-03-19 06:41:18 - MAKEOBJDIRPREFIX=3D/obj TB --- 2013-03-= 19 06:41:18 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 06:41:= 18 - SRCCONF=3D/dev/null TB --- 2013-03-19 06:41:18 - TARGET=3Dmips TB --- = 2013-03-19 06:41:18 - TARGET_ARCH=3Dmips TB --- 2013-03-19 06:41:18 - TZ=3D= UTC TB --- 2013-03-19 06:41:18 - __MAKE_CONF=3D/dev/null TB --- 2013-03-19 = 06:41:18 - cd /src TB --- 2013-03-19 06:41:18 - /usr/bin/make -B buildkerne= l KERNCONF=3DROUTERSTATION_MFS >>> Kernel build for ROUTERSTATION_MFS start= ed on Tue Mar 19 06:41:18 UTC 2013 >>> stage 1: configuring the kernel >>> = stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object= tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> sta= ge 3.2: building everything >>> Kernel build for ROUTERSTATION_MFS complete= d on Tue Mar 19 06:45:59 UTC 2013 TB --- 2013-03-19 06:45:59 - cd /src/sys/= mips/conf TB --- 2013-03-19 06:45:59 - /usr/sbin/config -m RSPRO TB --- 201= 3-03-19 06:45:59 - building RSPRO kernel TB --- 2013-03-19 06:45:59 - CROSS= _BUILD_TESTING=3DYES TB --- 2013-03-19 06:45:59 - MAKEOBJDIRPREFIX=3D/obj T= B --- 2013-03-19 06:45:59 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin TB --- 201= 3-03-19 06:45:59 - SRCCONF=3D/dev/null TB --- 2013-03-19 06:45:59 - TARGET= =3Dmips TB --- 2013-03-19 06:45:59 - TARGET_ARCH=3Dmips TB --- 2013-03-19 0= 6:45:59 - TZ=3DUTC TB --- 2013-03-19 06:45:59 - __MAKE_CONF=3D/dev/null TB = --- 2013-03-19 06:45:59 - cd /src TB --- 2013-03-19 06:45:59 - /usr/bin/mak= e -B buildkernel KERNCONF=3DRSPRO >>> Kernel build for RSPRO started on Tue= Mar 19 06:45:59 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1= : cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>>= stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: b= uilding everything >>> Kernel build for RSPRO completed on Tue Mar 19 06:50= :38 UTC 2013 TB --- 2013-03-19 06:50:38 - cd /src/sys/mips/conf TB --- 2013= -03-19 06:50:38 - /usr/sbin/config -m RSPRO_MFS TB --- 2013-03-19 06:50:38 = - building RSPRO_MFS kernel TB --- 2013-03-19 06:50:38 - CROSS_BUILD_TESTIN= G=3DYES TB --- 2013-03-19 06:50:38 - MAKEOBJDIRPREFIX=3D/obj TB --- 2013-03= -19 06:50:38 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 06:50= :38 - SRCCONF=3D/dev/null TB --- 2013-03-19 06:50:38 - TARGET=3Dmips TB ---= 2013-03-19 06:50:38 - TARGET_ARCH=3Dmips TB --- 2013-03-19 06:50:38 - TZ= =3DUTC TB --- 2013-03-19 06:50:38 - __MAKE_CONF=3D/dev/null TB --- 2013-03-= 19 06:50:38 - cd /src TB --- 2013-03-19 06:50:38 - /usr/bin/make -B buildke= rnel KERNCONF=3DRSPRO_MFS >>> Kernel build for RSPRO_MFS started on Tue Mar= 19 06:50:38 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cl= eaning up the object tree >>> stage 2.2: rebuilding the object tree >>> sta= ge 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: build= ing everything >>> Kernel build for RSPRO_MFS completed on Tue Mar 19 06:55= :08 UTC 2013 TB --- 2013-03-19 06:55:08 - cd /src/sys/mips/conf TB --- 2013= -03-19 06:55:08 - /usr/sbin/config -m RSPRO_STANDALONE TB --- 2013-03-19 06= :55:08 - building RSPRO_STANDALONE kernel TB --- 2013-03-19 06:55:08 - CROS= S_BUILD_TESTING=3DYES TB --- 2013-03-19 06:55:08 - MAKEOBJDIRPREFIX=3D/obj = TB --- 2013-03-19 06:55:08 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin TB --- 20= 13-03-19 06:55:08 - SRCCONF=3D/dev/null TB --- 2013-03-19 06:55:08 - TARGET= =3Dmips TB --- 2013-03-19 06:55:08 - TARGET_ARCH=3Dmips TB --- 2013-03-19 0= 6:55:08 - TZ=3DUTC TB --- 2013-03-19 06:55:08 - __MAKE_CONF=3D/dev/null TB = --- 2013-03-19 06:55:08 - cd /src TB --- 2013-03-19 06:55:08 - /usr/bin/mak= e -B buildkernel KERNCONF=3DRSPRO_STANDALONE >>> Kernel build for RSPRO_STA= NDALONE started on Tue Mar 19 06:55:09 UTC 2013 >>> stage 1: configuring th= e kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuildi= ng the object tree >>> stage 2.3: build tools >>> stage 3.1: making depende= ncies >>> stage 3.2: building everything >>> Kernel build for RSPRO_STANDAL= ONE completed on Tue Mar 19 07:00:09 UTC 2013 TB --- 2013-03-19 07:00:09 - = cd /src/sys/mips/conf TB --- 2013-03-19 07:00:09 - /usr/sbin/config -m RT30= 5X TB --- 2013-03-19 07:00:09 - skipping RT305X kernel TB --- 2013-03-19 07= :00:09 - cd /src/sys/mips/conf TB --- 2013-03-19 07:00:09 - /usr/sbin/confi= g -m SENTRY5 TB --- 2013-03-19 07:00:09 - skipping SENTRY5 kernel TB --- 20= 13-03-19 07:00:09 - cd /src/sys/mips/conf TB --- 2013-03-19 07:00:09 - /usr= /sbin/config -m SWARM TB --- 2013-03-19 07:00:09 - building SWARM kernel TB= --- 2013-03-19 07:00:09 - CROSS_BUILD_TESTING=3DYES TB --- 2013-03-19 07:0= 0:09 - MAKEOBJDIRPREFIX=3D/obj TB --- 2013-03-19 07:00:09 - PATH=3D/usr/bin= :/usr/sbin:/bin:/sbin TB --- 2013-03-19 07:00:09 - SRCCONF=3D/dev/null TB -= -- 2013-03-19 07:00:09 - TARGET=3Dmips TB --- 2013-03-19 07:00:09 - TARGET_= ARCH=3Dmips TB --- 2013-03-19 07:00:09 - TZ=3DUTC TB --- 2013-03-19 07:00:0= 9 - __MAKE_CONF=3D/dev/null TB --- 2013-03-19 07:00:09 - cd /src TB --- 201= 3-03-19 07:00:09 - /usr/bin/make -B buildkernel KERNCONF=3DSWARM >>> Kernel= build for SWARM started on Tue Mar 19 07:00:09 UTC 2013 >>> stage 1: confi= guring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2:= rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: makin= g dependencies >>> stage 3.2: building everything >>> Kernel build for SWAR= M completed on Tue Mar 19 07:02:57 UTC 2013 TB --- 2013-03-19 07:02:57 - cd= /src/sys/mips/conf TB --- 2013-03-19 07:02:57 - /usr/sbin/config -m SWARM6= 4 TB --- 2013-03-19 07:02:57 - skipping SWARM64 kernel TB --- 2013-03-19 07= :02:57 - cd /src/sys/mips/conf TB --- 2013-03-19 07:02:57 - /usr/sbin/confi= g -m SWARM64_SMP TB --- 2013-03-19 07:02:57 - skipping SWARM64_SMP kernel T= B --- 2013-03-19 07:02:57 - cd /src/sys/mips/conf TB --- 2013-03-19 07:02:5= 7 - /usr/sbin/config -m SWARM_SMP TB --- 2013-03-19 07:02:57 - building SWA= RM_SMP kernel TB --- 2013-03-19 07:02:57 - CROSS_BUILD_TESTING=3DYES TB ---= 2013-03-19 07:02:57 - MAKEOBJDIRPREFIX=3D/obj TB --- 2013-03-19 07:02:57 -= PATH=3D/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 07:02:57 - SRCCONF= =3D/dev/null TB --- 2013-03-19 07:02:57 - TARGET=3Dmips TB --- 2013-03-19 0= 7:02:57 - TARGET_ARCH=3Dmips TB --- 2013-03-19 07:02:57 - TZ=3DUTC TB --- 2= 013-03-19 07:02:57 - __MAKE_CONF=3D/dev/null TB --- 2013-03-19 07:02:57 - c= d /src TB --- 2013-03-19 07:02:57 - /usr/bin/make -B buildkernel KERNCONF= =3DSWARM_SMP >>> Kernel build for SWARM_SMP started on Tue Mar 19 07:02:57 = UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the= object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build= tools >>> stage 3.1: making dependencies >>> stage 3.2: building everythin= g >>> Kernel build for SWARM_SMP completed on Tue Mar 19 07:05:50 UTC 2013 = TB --- 2013-03-19 07:05:50 - cd /src/sys/mips/conf TB --- 2013-03-19 07:05:= 50 - /usr/sbin/config -m TP-WN1043ND TB --- 2013-03-19 07:05:50 - building = TP-WN1043ND kernel TB --- 2013-03-19 07:05:50 - CROSS_BUILD_TESTING=3DYES T= B --- 2013-03-19 07:05:50 - MAKEOBJDIRPREFIX=3D/obj TB --- 2013-03-19 07:05= :50 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 07:05:50 - SRC= CONF=3D/dev/null TB --- 2013-03-19 07:05:50 - TARGET=3Dmips TB --- 2013-03-= 19 07:05:50 - TARGET_ARCH=3Dmips TB --- 2013-03-19 07:05:50 - TZ=3DUTC TB -= -- 2013-03-19 07:05:50 - __MAKE_CONF=3D/dev/null TB --- 2013-03-19 07:05:50= - cd /src TB --- 2013-03-19 07:05:50 - /usr/bin/make -B buildkernel KERNCO= NF=3DTP-WN1043ND >>> Kernel build for TP-WN1043ND started on Tue Mar 19 07:= 05:50 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning = up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3:= build tools >>> stage 3.1: making dependencies >>> stage 3.2: building eve= rything >>> Kernel build for TP-WN1043ND completed on Tue Mar 19 07:10:32 U= TC 2013 TB --- 2013-03-19 07:10:32 - cd /src/sys/mips/conf TB --- 2013-03-1= 9 07:10:32 - /usr/sbin/config -m XLP TB --- 2013-03-19 07:10:32 - building = XLP kernel TB --- 2013-03-19 07:10:32 - CROSS_BUILD_TESTING=3DYES TB --- 20= 13-03-19 07:10:32 - MAKEOBJDIRPREFIX=3D/obj TB --- 2013-03-19 07:10:32 - PA= TH=3D/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-19 07:10:32 - SRCCONF=3D/= dev/null TB --- 2013-03-19 07:10:32 - TARGET=3Dmips TB --- 2013-03-19 07:10= :32 - TARGET_ARCH=3Dmips TB --- 2013-03-19 07:10:32 - TZ=3DUTC TB --- 2013-= 03-19 07:10:32 - __MAKE_CONF=3D/dev/null TB --- 2013-03-19 07:10:32 - cd /s= rc TB --- 2013-03-19 07:10:32 - /usr/bin/make -B buildkernel KERNCONF=3DXLP= >>> Kernel build for XLP started on Tue Mar 19 07:10:33 UTC 2013 >>> stage= 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> s= tage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3= .1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -= pipe -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-protot= ypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno= -pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show= -option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib= /libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-c= ommon -finline-limit=3D8000 --param inline-unit-growth=3D10000 --param larg= e-function-growth=3D100000 --param max-inline-insns-single=3D10000 -fno-pic= -mno-abicalls -G0 -DKERNLOADADDR=3D0x80100000 -march=3Dmips32 -msoft-float= -ffreestanding -Werror /src/sys/dev/e1000/e1000_phy.c -I/src/sys/dev/e1000= cc -c -O -pipe -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs -Wst= rict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -= Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagn= ostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/= sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glob= al.h -fno-common -finline-limit=3D8000 --param inline-unit-growth=3D10000 -= -param large-function-growth=3D100000 --param max-inline-insns-single=3D100= 00 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=3D0x80100000 -march=3Dmips32 -= msoft-float -ffreestanding -Werror /src/sys/dev/e1000/e1000_vf.c -I/src/sys= /dev/e1000 cc -c -O -pipe -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-ex= terns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wc= ast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-di= rs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/al= tq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -includ= e opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-growth= =3D10000 --param large-function-growth=3D100000 --param max-inline-insns-si= ngle=3D10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=3D0x80100000 -march= =3Dmips32 -msoft-float -ffreestanding -Werror /src/sys/dev/e1000/e1000_mbx.= c -I/src/sys/dev/e1000 cc -c -O -pipe -std=3Dc99 -g -Wall -Wredundant-decls= -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith = -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissin= g-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sy= s/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEA= DERS -include opt_global.h -fno-common -finline-limit=3D8000 --param inline= -unit-growth=3D10000 --param large-function-growth=3D100000 --param max-inl= ine-insns-single=3D10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=3D0x8010= 0000 -march=3Dmips32 -msoft-float -ffreestanding -Werror /src/sys/dev/e1000= /e1000_osdep.c -I/src/sys/dev/e1000 cc -c -O -pipe -std=3Dc99 -g -Wall -Wre= dundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wp= ointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extens= ions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/= sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERN= EL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D8000 -= -param inline-unit-growth=3D10000 --param large-function-growth=3D100000 --= param max-inline-insns-single=3D10000 -fno-pic -mno-abicalls -G0 -DKERNLOAD= ADDR=3D0x80100000 -march=3Dmips32 -msoft-float -ffreestanding -Werror /src/= sys/dev/fdt/fdt_common.c cc1: warnings being treated as errors /src/sys/dev= /fdt/fdt_common.c: In function 'fdt_reg_to_rl': /src/sys/dev/fdt/fdt_common= .c:451: warning: passing argument 4 of 'fdt_data_to_res' from incompatible = pointer type *** [fdt_common.o] Error code 1 Stop in /obj/mips.mips/src/sys= /XLP. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in= /src. TB --- 2013-03-19 07:11:16 - WARNING: /usr/bin/make returned exit co= de 1 TB --- 2013-03-19 07:11:16 - ERROR: failed to build XLP kernel TB --- = 2013-03-19 07:11:16 - 6435.88 user 1184.38 system 8495.88 real http://tinde= rbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips-mips.full ______________= _________________________________ freebsd-current@freebsd.org mailing list = http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, s= end any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Mar 25 00:03:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C982D7BA; Mon, 25 Mar 2013 00:03:52 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.120]) by mx1.freebsd.org (Postfix) with ESMTP id 7F939D0D; Mon, 25 Mar 2013 00:03:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=SdweTkZgTVsakIWN4p9kGkhl6CXaqwfrw4oZ5lKOFFc=; b=HgHwOuO5U0QZfx5VVlJbLkza6a3zRzL+yYYeo3odYpD6HAVMQ6N5VlINpe2H6VmXv6VdXjIBcM7/NarYg6mbSdNnUPj3hjx646Bh9mSdlYhEO5cQN68/XqRjSpoOlogrgfjaEZr8ogV6Lfd64k6WWipm6TZ6Rs5r3LxP1kzuuJg=; Received: from [178.137.138.140] (helo=nonamehost) by fsm1.ukr.net with esmtpsa ID 1UJut3-000Hy4-GY ; Mon, 25 Mar 2013 02:03:41 +0200 Date: Mon, 25 Mar 2013 02:03:40 +0200 From: Ivan Klymenko To: Konstantin Belousov Subject: Re: Kernel panic CURRENT r248596 at virtualbox-ose-kmod module load Message-ID: <20130325020340.02c5ace0@nonamehost> In-Reply-To: <20130324120507.GX3794@kib.kiev.ua> References: <20130323132627.04bf7ef4@nonamehost> <20130324120507.GX3794@kib.kiev.ua> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; amd64-portbld-freebsd10.0) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWpqak/Pz/i4uIfHx8GBwZwcHAQEBA6o92AAAACHElEQVQ4jWWUTY7bMAyF6QzUPSEoa8PFHEBgqwuM4bVVg7MvZOj+R+ijpMTpjIwgkT7z75EKrdfattpXERG6zqvUOtAr2LCRYfEKcB4l/Q+2cc6XjQH7hv+2YZYreIk5nevZEPvuzUzptizHLzgDMnC5Wpbl7ewJlOEqlQF+DlCjgVLki0WV6FMDMsBxjlJiQulIznwZ+DxHiQyDyIg0wN3Oo6o6ZQ5s5AIfar+W2Wlmz+kCcb8tg6j3voMEwNrBQk69dDBDqw/urpqJH+m+Q6u/4QnoAeYpnUXC/s1iup9rhCd6xMgAqdDyAyFegbKkVAHeLCcOulPLawaoUIDos4M88iLNrVkU7uu5ccTDO6naJzWLum51C6Yb7y4HKKbdArLWir0PBiS8glJRBZHeyHl7J9lENpAC6qT9NlNG4u5hsVYDyJP6mlJJtY3oVju4WSUzHal1sDU17NASoBWSk40J2eBLBJhYrVmzC5gVALGpNIAiQgN6eGstOp9Oa6zFbbLTISYi28BGZDRUJKWeroECkCEkzXjUtbmmaKMfAx2RfbT69/cO+tgHcmx6AfyZOmj3NDIah0F0GB66d4CrdIoplNFFGHSpSheRxbo0W4S8azNItEoMWbw3uXAeJgCrmX5joz7CGXqSg6PcryEhnFr/C1C2ntPxBOYbdwY+8dO3+wZJyFlbMX9s8zNnvp/tLwAv03NB4j3HVpn8Awwm+GrlP6MVAAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 00:03:52 -0000 =D0=92 Sun, 24 Mar 2013 14:05:07 +0200 Konstantin Belousov =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Sat, Mar 23, 2013 at 01:26:27PM +0200, Ivan Klymenko wrote: > > I have > > uname -a > > FreeBSD nonamehost 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248596: Fri > > Mar 22 01:17:08 EET 2013 > > ivan@nonamehost:/usr/obj/usr/src/sys/GENERIC amd64 > >=20 > > I updated the ports tree to r314921 and recompiled > > virtualbox-ose-kmod > >=20 > > After load the module a have kernel panic. > >=20 > > Panic String: Lock vm object not exclusively locked @ > > /usr/src/sys/vm/vm_page.c:1396 > >=20 > > http://pkgupdate.nevosoft.ru/backtrace.txt >=20 > This looks like a vbox issue, the driver did not properly locked > the object passed to the vm_page_alloc_contig(). >=20 > If you want this fixed, you probably need to look up the code > yourself, compiling the vbox kld with debugging, finding the > offending call to vm_page_alloc_contig() and looking around it to see > which object is passed and why it is not locked. The problem is that port commiter did not listen your advice: http://docs.freebsd.org/cgi/mid.cgi?20130312151751.GJ3794 and used in the patch is not the functions that need http://svnweb.freebsd.org/ports/head/emulators/virtualbox-ose-kmod/files/pa= tch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd_VM_OBJECT_RENAME.c?= r1=3D314794&r2=3D314796 I replaced the all function "VM_OBJECT_RLOCK" on "VM_OBJECT_WLOCK" and "VM_OBJECT_RUNLOCK" on "VM_OBJECT_WUNLOCK" and the kernel panic ceased. Thanks. This problem is solved. From owner-freebsd-current@FreeBSD.ORG Mon Mar 25 08:04:46 2013 Return-Path: Delivered-To: freebsd-current@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 B00DD8B8 for ; Mon, 25 Mar 2013 08:04:46 +0000 (UTC) (envelope-from decke@bluelife.at) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by mx1.freebsd.org (Postfix) with ESMTP id 78D8734F for ; Mon, 25 Mar 2013 08:04:46 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id n1so3241585oag.23 for ; Mon, 25 Mar 2013 01:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bluelife.at; s=google; h=mime-version:x-received:sender:x-originating-ip:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=RUnzdHwtKDgXrJS8pMy2Lf45H5naUDJc7VpVn698LOU=; b=CnHLTTGRutF/Dw6KsyMPcfz0iOaVwBvzqfanbijXTLQ75WtF5ecZ1SrolMSNjgalVr kQ/cya4ceuL7718Dvy6ocLKMlW+0C/VVslBo5hU/b518S5GEffmZuZK7kV2zF+MNlCcT v5PpITkIHbGiNfsCnxb0B+h5ke1hq6bqQcPqk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:x-originating-ip:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding:x-gm-message-state; bh=RUnzdHwtKDgXrJS8pMy2Lf45H5naUDJc7VpVn698LOU=; b=GvgRcB238GjSSpYHYBL3fbHo+pMPBSw5YPB7jy/Byp4UOHwPrZhK8Ebwh111AxpToo Zat8i+AOx7bxEUvzlp3WSzs72/O7ljZIVmHCNbR45iEORXVxah3MBS9SXuohCDHi9CrC h1C+i4loTWzotrQzVn0s32ZtFm/1tSK2kJELBIrjti5SMzU+BlYkuOdQw/8AL6jNdta2 lE7gpMf5mo6ySBrl2OGRtK6J8poBzjy18fPQVgTpRWAo8ZsGPjyqMuOpKBneK13oPE98 iMv5wJAzhDAu48SAIWW+TO4ON2zYtmK8EVeb795p1ufKdAt9yHCobkdOifcGi9a/Pwls cJoA== MIME-Version: 1.0 X-Received: by 10.60.62.70 with SMTP id w6mr1587229oer.38.1364198680371; Mon, 25 Mar 2013 01:04:40 -0700 (PDT) Sender: decke@bluelife.at Received: by 10.76.99.114 with HTTP; Mon, 25 Mar 2013 01:04:40 -0700 (PDT) X-Originating-IP: [80.123.233.199] In-Reply-To: <20130325020340.02c5ace0@nonamehost> References: <20130323132627.04bf7ef4@nonamehost> <20130324120507.GX3794@kib.kiev.ua> <20130325020340.02c5ace0@nonamehost> Date: Mon, 25 Mar 2013 09:04:40 +0100 X-Google-Sender-Auth: jz4VKzPaZaaMELDg8_a4h0HYo4A Message-ID: Subject: Re: Kernel panic CURRENT r248596 at virtualbox-ose-kmod module load From: =?ISO-8859-1?Q?Bernhard_Fr=F6hlich?= To: Ivan Klymenko Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn9mfxqjcy1MXuR0usP7k9EAEIeXHbvkOr7F0zPaBh4486SxIQT9hsTQg62crD3XvobdkOY Cc: Konstantin Belousov , freebsd-current@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 08:04:46 -0000 On Mon, Mar 25, 2013 at 1:03 AM, Ivan Klymenko wrote: > =D0=92 Sun, 24 Mar 2013 14:05:07 +0200 > Konstantin Belousov =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >> On Sat, Mar 23, 2013 at 01:26:27PM +0200, Ivan Klymenko wrote: >> > I have >> > uname -a >> > FreeBSD nonamehost 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248596: Fri >> > Mar 22 01:17:08 EET 2013 >> > ivan@nonamehost:/usr/obj/usr/src/sys/GENERIC amd64 >> > >> > I updated the ports tree to r314921 and recompiled >> > virtualbox-ose-kmod >> > >> > After load the module a have kernel panic. >> > >> > Panic String: Lock vm object not exclusively locked @ >> > /usr/src/sys/vm/vm_page.c:1396 >> > >> > http://pkgupdate.nevosoft.ru/backtrace.txt >> >> This looks like a vbox issue, the driver did not properly locked >> the object passed to the vm_page_alloc_contig(). >> >> If you want this fixed, you probably need to look up the code >> yourself, compiling the vbox kld with debugging, finding the >> offending call to vm_page_alloc_contig() and looking around it to see >> which object is passed and why it is not locked. > > The problem is that port commiter did not listen your advice: > http://docs.freebsd.org/cgi/mid.cgi?20130312151751.GJ3794 > > and used in the patch is not the functions that need > http://svnweb.freebsd.org/ports/head/emulators/virtualbox-ose-kmod/files/= patch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd_VM_OBJECT_RENAME.= c?r1=3D314794&r2=3D314796 > > I replaced the all function "VM_OBJECT_RLOCK" on "VM_OBJECT_WLOCK" > and > "VM_OBJECT_RUNLOCK" on "VM_OBJECT_WUNLOCK" > > and the kernel panic ceased. > > Thanks. This problem is solved. Thanks a lot! I've fixed it in the port now. Would be great if you could ve= rify that it's correct now. --=20 Bernhard Froehlich http://www.bluelife.at/ From owner-freebsd-current@FreeBSD.ORG Mon Mar 25 08:46:02 2013 Return-Path: Delivered-To: freebsd-current@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 0ECE04D9 for ; Mon, 25 Mar 2013 08:46:02 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by mx1.freebsd.org (Postfix) with ESMTP id D7A177C0 for ; Mon, 25 Mar 2013 08:46:01 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id n1so3306782oag.37 for ; Mon, 25 Mar 2013 01:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=mjQ95cILwXOg+XtvTznezDUrQgO/r4/IOPkwiaE31Co=; b=KxDkqygFqhiMbPhns7RWYYKzwN1z31al/BQjPMZMwDwMnwQifEtZFhLfnXyrMvpw9j tU6AqpkyO+B/ZNBwLy2clsXESNJ0QhulkEhPXjJOoV0lV9UKEVJ2oJN3m8l2eRTf3rrS lwL9sicN142UassCQ0hp8QEbFAJ433n7JCGAQQ5qUY2f/0RUXVNSEcj5sVtMs6qWQqw0 wxuSfE5DcnTuyvf47bdq4GRNLwGBGl+2+lwBpgIJXBRZe95Vwfy0N9wiQZYjl5QEzNQv +l4i1ume4E0VjBs3nhOqJjl9fzPlmsTfVLBweZ3KIy1Z7P+N6YNMVxiyLCjIra/SGLSe N+vA== MIME-Version: 1.0 X-Received: by 10.60.26.137 with SMTP id l9mr10498473oeg.17.1364201161212; Mon, 25 Mar 2013 01:46:01 -0700 (PDT) Received: by 10.182.116.196 with HTTP; Mon, 25 Mar 2013 01:46:01 -0700 (PDT) Date: Mon, 25 Mar 2013 04:46:01 -0400 Message-ID: Subject: On 10.0, Clang is not accepted as compiler From: Super Bisquit To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 08:46:02 -0000 What argument do I need to add to /etc/make.conf to correct this? Thanks muchly. From owner-freebsd-current@FreeBSD.ORG Mon Mar 25 09:20:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 57684F59 for ; Mon, 25 Mar 2013 09:20:05 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by mx1.freebsd.org (Postfix) with ESMTP id E643F957 for ; Mon, 25 Mar 2013 09:20:04 +0000 (UTC) Received: by mail-ee0-f53.google.com with SMTP id c13so338558eek.26 for ; Mon, 25 Mar 2013 02:20:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=o1CFa8yujVH3zm/mSY42WH7O8RVj7gCrPrN/SZBG9DE=; b=DdelPGtY3qyrP8U5IQ6sSy635IP1hQl97v96u4EVrqOYBJmjIwwNHwfnpKEgS+R3CT jtUhABUAMAMEJmj3BPcYA9yYPMgcTkDFX9TwlDOGvaeWmKPB9S8jwwS9QkyV0X14Tcpe JHje2JZiJu+Qyv/p4Id/leMHu43GI5KDwmc4kgrjWetBDhzsOyPeLDugMDdeKPlkuAzJ UlmQcN2oL3scnwqM74F7m8EaY/HGs6hmhC9tqBhv9VHwvVGw+02QZWHnGhrch0VSOlSN iRxUPUEAzzZAKDXVwBoR2scQSw4XywcxQzGFOz8hZY2Sx0yo4CdI43yY1Sn+nLMEZaud /Lug== X-Received: by 10.14.223.69 with SMTP id u45mr31897616eep.23.1364203203939; Mon, 25 Mar 2013 02:20:03 -0700 (PDT) Received: from [192.168.50.105] (double-l.xs4all.nl. [80.126.205.144]) by mx.google.com with ESMTPS id z45sm17651479eeu.10.2013.03.25.02.20.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Mar 2013 02:20:03 -0700 (PDT) Message-ID: <515016C2.1020201@gmail.com> Date: Mon, 25 Mar 2013 10:20:02 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Super Bisquit Subject: Re: On 10.0, Clang is not accepted as compiler References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 09:20:05 -0000 Super Bisquit schreef: > What argument do I need to add to /etc/make.conf to correct this? > > Thanks muchly. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" On CURRENT aka 10, Clang is the default compiler. As far as i know, you do not have to set anything in /etc/make.conf. regards Johan From owner-freebsd-current@FreeBSD.ORG Mon Mar 25 11:21:04 2013 Return-Path: Delivered-To: freebsd-current@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 72BE3E25; Mon, 25 Mar 2013 11:21:04 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.120]) by mx1.freebsd.org (Postfix) with ESMTP id 26E5A38F; Mon, 25 Mar 2013 11:21:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=CtfpXersyIVoNisC6tzS25WhjLYaFbCqxWGsXEMlRBg=; b=vhA7R95HKNdNznnl1gqol7HYj969TZ367lGbJsRcILj17ZG8xKaCrn9rZZ0h1k8Dihj98IOy429QC/l+IGyl3k365UTDsbMnzVL8EnHkZc7rte4/zZELtBF6j+kDXXgdTn3mxhSCU7vYyy5G86DCdrCw3vjLpHmal7Y0BccDnBk=; Received: from [178.137.138.140] (helo=nonamehost) by fsm1.ukr.net with esmtpsa ID 1UK5SV-000Jfi-9E ; Mon, 25 Mar 2013 13:20:59 +0200 Date: Mon, 25 Mar 2013 13:20:57 +0200 From: Ivan Klymenko To: Bernhard =?UTF-8?B?RnLDtmhsaWNo?= Subject: Re: Kernel panic CURRENT r248596 at virtualbox-ose-kmod module load Message-ID: <20130325132057.494627a2@nonamehost> In-Reply-To: References: <20130323132627.04bf7ef4@nonamehost> <20130324120507.GX3794@kib.kiev.ua> <20130325020340.02c5ace0@nonamehost> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; amd64-portbld-freebsd10.0) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWpqak/Pz/i4uIfHx8GBwZwcHAQEBA6o92AAAACHElEQVQ4jWWUTY7bMAyF6QzUPSEoa8PFHEBgqwuM4bVVg7MvZOj+R+ijpMTpjIwgkT7z75EKrdfattpXERG6zqvUOtAr2LCRYfEKcB4l/Q+2cc6XjQH7hv+2YZYreIk5nevZEPvuzUzptizHLzgDMnC5Wpbl7ewJlOEqlQF+DlCjgVLki0WV6FMDMsBxjlJiQulIznwZ+DxHiQyDyIg0wN3Oo6o6ZQ5s5AIfar+W2Wlmz+kCcb8tg6j3voMEwNrBQk69dDBDqw/urpqJH+m+Q6u/4QnoAeYpnUXC/s1iup9rhCd6xMgAqdDyAyFegbKkVAHeLCcOulPLawaoUIDos4M88iLNrVkU7uu5ccTDO6naJzWLum51C6Yb7y4HKKbdArLWir0PBiS8glJRBZHeyHl7J9lENpAC6qT9NlNG4u5hsVYDyJP6mlJJtY3oVju4WSUzHal1sDU17NASoBWSk40J2eBLBJhYrVmzC5gVALGpNIAiQgN6eGstOp9Oa6zFbbLTISYi28BGZDRUJKWeroECkCEkzXjUtbmmaKMfAx2RfbT69/cO+tgHcmx6AfyZOmj3NDIah0F0GB66d4CrdIoplNFFGHSpSheRxbo0W4S8azNItEoMWbw3uXAeJgCrmX5joz7CGXqSg6PcryEhnFr/C1C2ntPxBOYbdwY+8dO3+wZJyFlbMX9s8zNnvp/tLwAv03NB4j3HVpn8Awwm+GrlP6MVAAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Konstantin Belousov , freebsd-current@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 11:21:04 -0000 =D0=92 Mon, 25 Mar 2013 09:04:40 +0100 Bernhard Fr=C3=B6hlich =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Mon, Mar 25, 2013 at 1:03 AM, Ivan Klymenko wrote: > > =D0=92 Sun, 24 Mar 2013 14:05:07 +0200 > > Konstantin Belousov =D0=BF=D0=B8=D1=88=D0=B5=D1= =82: > > > >> On Sat, Mar 23, 2013 at 01:26:27PM +0200, Ivan Klymenko wrote: > >> > I have > >> > uname -a > >> > FreeBSD nonamehost 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248596: > >> > Fri Mar 22 01:17:08 EET 2013 > >> > ivan@nonamehost:/usr/obj/usr/src/sys/GENERIC amd64 > >> > > >> > I updated the ports tree to r314921 and recompiled > >> > virtualbox-ose-kmod > >> > > >> > After load the module a have kernel panic. > >> > > >> > Panic String: Lock vm object not exclusively locked @ > >> > /usr/src/sys/vm/vm_page.c:1396 > >> > > >> > http://pkgupdate.nevosoft.ru/backtrace.txt > >> > >> This looks like a vbox issue, the driver did not properly locked > >> the object passed to the vm_page_alloc_contig(). > >> > >> If you want this fixed, you probably need to look up the code > >> yourself, compiling the vbox kld with debugging, finding the > >> offending call to vm_page_alloc_contig() and looking around it to > >> see which object is passed and why it is not locked. > > > > The problem is that port commiter did not listen your advice: > > http://docs.freebsd.org/cgi/mid.cgi?20130312151751.GJ3794 > > > > and used in the patch is not the functions that need > > http://svnweb.freebsd.org/ports/head/emulators/virtualbox-ose-kmod/file= s/patch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd_VM_OBJECT_RENAM= E.c?r1=3D314794&r2=3D314796 > > > > I replaced the all function "VM_OBJECT_RLOCK" on "VM_OBJECT_WLOCK" > > and > > "VM_OBJECT_RUNLOCK" on "VM_OBJECT_WUNLOCK" > > > > and the kernel panic ceased. > > > > Thanks. This problem is solved. >=20 > Thanks a lot! I've fixed it in the port now. Would be great if you > could verify that it's correct now. >=20 Yes - it is correctly http://svnweb.freebsd.org/ports/head/emulators/virtualbox-ose-kmod/files/pa= tch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd_VM_OBJECT_RENAME.c?= r1=3D314797&r2=3D315200 From owner-freebsd-current@FreeBSD.ORG Mon Mar 25 11:49:29 2013 Return-Path: Delivered-To: freebsd-current@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 01E00B5D; Mon, 25 Mar 2013 11:49:29 +0000 (UTC) (envelope-from seanwbruno@gmail.com) Received: from mail-ea0-x234.google.com (mail-ea0-x234.google.com [IPv6:2a00:1450:4013:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id 4473675D; Mon, 25 Mar 2013 11:49:28 +0000 (UTC) Received: by mail-ea0-f180.google.com with SMTP id d10so405937eaj.39 for ; Mon, 25 Mar 2013 04:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tSPQ93RaDa9JKcuSmdV7+8mQ5kf4Aqk6RhyvJXqCiDY=; b=Heue1KqgU6QPTZJjO8gg/Nm3Gi7Phjco5v8zW5H7H38PmkzKoxKHbMgSz7b7yvttEp JB1OWmnhUO8qjy/qTmM9ZDa65V9jAQhCyojlxFZvydiXh4S1fklwAkGR3mzbsmXZBrdw S8j5LVGukPNDN8BGhab5VSqi6yoZSP/j724OAAA+6S5XsJcEDmy8y4zhDJ/PwNjioLT8 dmZ8qyH9uN2Wh7L/iPOIIJikpVHhz0zmnHI4k/mYQpHu5fuQPaDrfrLfR3jZhLx+VD5t lOKscWBMO2/ByjDOm3oKeTUcCBJHVHeISRAfx9SbWf6I8AFQSlZq02frxkijXc2LDKBg bGAw== MIME-Version: 1.0 X-Received: by 10.14.182.72 with SMTP id n48mr6839861eem.3.1364212167244; Mon, 25 Mar 2013 04:49:27 -0700 (PDT) Sender: seanwbruno@gmail.com Received: by 10.223.61.79 with HTTP; Mon, 25 Mar 2013 04:49:27 -0700 (PDT) In-Reply-To: <20130325132057.494627a2@nonamehost> References: <20130323132627.04bf7ef4@nonamehost> <20130324120507.GX3794@kib.kiev.ua> <20130325020340.02c5ace0@nonamehost> <20130325132057.494627a2@nonamehost> Date: Mon, 25 Mar 2013 04:49:27 -0700 X-Google-Sender-Auth: nUfnFGL0JnzXTVkyIcXiAxR1RBo Message-ID: Subject: Re: Kernel panic CURRENT r248596 at virtualbox-ose-kmod module load From: sean bruno To: Ivan Klymenko Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , freebsd-current@freebsd.org, =?UTF-8?Q?Bernhard_Fr=C3=B6hlich?= , freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 11:49:29 -0000 > > Yes - it is correctly > http://svnweb.freebsd.org/ports/head/emulators/virtualbox-ose-kmod/files/patch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd_VM_OBJECT_RENAME.c?r1=314797&r2=315200 Ah, thank you. My patch definitely was not right and I was wondering where the kpanic on load/startup was coming from. :-) From owner-freebsd-current@FreeBSD.ORG Mon Mar 25 12:22:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0068A7F1 for ; Mon, 25 Mar 2013 12:22:04 +0000 (UTC) (envelope-from erich@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id C6BC598A for ; Mon, 25 Mar 2013 12:22:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:Message-ID:Subject:To:From:Date; bh=bVhlEHq79bCBgOnk9IRVAhaVg2Hww2jghwGt/+iPLic=; b=mfP4fjLYfC3k8ldV1tPupQDmNpAkG6j7Aq54XvKo1O+LTOb9BCqR12WV4TIXTjg6ripiLtk7eIBDaeCWOOSyAO9elcMigBHvB4l6OsRq6M+9GOc95ZR3B7VumddIFyJld2HIA5r5m874CedQoEiwHD5nKEuvy2s/HNdcCmJPCcQ=; Received: from [122.129.203.50] (port=15699 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UK6PW-001yLF-PX for freebsd-current@freebsd.org; Mon, 25 Mar 2013 06:22:04 -0600 Date: Mon, 25 Mar 2013 19:21:05 +0700 From: Erich Dollansky To: "freebsd-current@freebsd.org" Subject: X220 loses keyboard when Logitech USB wireless adaptor is unplugged Message-ID: <20130325192105.4e94db17@X220.ovitrap.com> Organization: ALO Green Technologies X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erich@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Mon, 25 Mar 2013 12:44:55 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 12:22:05 -0000 Hi, I just got this from /var/log/messages: Mar 25 19:12:01 X220 kernel: ugen0.3: at usbus0 (disconnected) Mar 25 19:12:01 X220 kernel: ukbd0: at uhub3, port 2, addr 3 (disconnected) Mar 25 19:12:01 X220 kernel: ums0: at uhub3, port 2, addr 3 (disconnected) Mar 25 19:12:01 X220 kernel: uhid0: at uhub3, port 2, addr 3 (disconnected) Mar 25 19:12:09 X220 kernel: ugen0.3: at usbus0 Mar 25 19:12:09 X220 kernel: ukbd0: on usbus0 Mar 25 19:12:09 X220 kernel: kbd2 at ukbd0 Mar 25 19:12:09 X220 kernel: ums0: on usbus0 Mar 25 19:12:09 X220 kernel: ums0: 16 buttons and [XYZT] coordinates ID=2 Mar 25 19:12:09 X220 kernel: uhid0: on usbus0 As you can see, I took the adaptor connected to ugne0.3 out. In addition, the keyboard ukbd0 was disconnected too. When I put the adaptor back in, the keyboard comes back too. As you can imagine, it is a bit hard to unplug the built-in keyboard on a notebook. uname -a says: FreeBSD X220.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #23: Sat Feb 23 17:24:19 WIT 2013 erich@X220.ovitrap.com:/usr/obj/usr/src/sys/X220 amd64 Any thing I could do to help fix this? Erich From owner-freebsd-current@FreeBSD.ORG Mon Mar 25 12:59:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E85AEFA3 for ; Mon, 25 Mar 2013 12:59:55 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id B8873B59 for ; Mon, 25 Mar 2013 12:59:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=/6tsmYEvLrmyESOV1k5ecs2WTXyG27oqUnBPMrKpeH4=; b=BM94d+O4P3qUXZnl9OmXuyWDC/OfuMV4bAZ+X9v7/UYY1nI8H8AhPXlsY8GexafS3Ag/0sK/+rUbmK6yvf8NfuRc58DxsQ2SaT8ylg6ADvMf3yQAExtSpH5Rbp8IQpvTUpO+WxiFSRcltzetZ+Eb+8u0rxHN+6Dszo41rg1IT+E=; Received: from [122.129.203.50] (port=64849 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UK70E-002CtF-3P; Mon, 25 Mar 2013 06:59:55 -0600 Date: Mon, 25 Mar 2013 19:59:49 +0700 From: Erich Dollansky To: Erich Dollansky Subject: Re: X220 loses keyboard when Logitech USB wireless adaptor is unplugged Message-ID: <20130325195949.228c2dea@X220.ovitrap.com> In-Reply-To: <20130325192105.4e94db17@X220.ovitrap.com> References: <20130325192105.4e94db17@X220.ovitrap.com> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 12:59:56 -0000 Hi, On Mon, 25 Mar 2013 19:21:05 +0700 Erich Dollansky wrote: > As you can see, I took the adaptor connected to ugne0.3 out. In > addition, the keyboard ukbd0 was disconnected too. When I put the > adaptor back in, the keyboard comes back too. As you can imagine, it > is a bit hard to unplug the built-in keyboard on a notebook. > the situation changes when I do not use X and KMS. I can do with the Logitech adaptor what I want but the keyboard stays connected. The moment I start X, it is back to the behaviour from above. Erich From owner-freebsd-current@FreeBSD.ORG Mon Mar 25 13:14:29 2013 Return-Path: Delivered-To: freebsd-current@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 C2A8C68A for ; Mon, 25 Mar 2013 13:14:29 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 82AC2CF7 for ; Mon, 25 Mar 2013 13:14:29 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r2PD7EqZ035903; Mon, 25 Mar 2013 09:07:14 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.netplex.net [204.213.176.10]); Mon, 25 Mar 2013 09:07:14 -0400 (EDT) Date: Mon, 25 Mar 2013 09:07:14 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Erich Dollansky Subject: Re: X220 loses keyboard when Logitech USB wireless adaptor is unplugged In-Reply-To: <20130325195949.228c2dea@X220.ovitrap.com> Message-ID: References: <20130325192105.4e94db17@X220.ovitrap.com> <20130325195949.228c2dea@X220.ovitrap.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-current@freebsd.org" , Erich Dollansky X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 13:14:29 -0000 On Mon, 25 Mar 2013, Erich Dollansky wrote: > Hi, > > On Mon, 25 Mar 2013 19:21:05 +0700 > Erich Dollansky wrote: > >> As you can see, I took the adaptor connected to ugne0.3 out. In >> addition, the keyboard ukbd0 was disconnected too. When I put the >> adaptor back in, the keyboard comes back too. As you can imagine, it >> is a bit hard to unplug the built-in keyboard on a notebook. >> > the situation changes when I do not use X and KMS. I can do with the > Logitech adaptor what I want but the keyboard stays connected. The > moment I start X, it is back to the behaviour from above. Can you use, or are you using, moused? Tell X to use sysmouse. Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5 6 7" EndSection -- DE From owner-freebsd-current@FreeBSD.ORG Mon Mar 25 13:34:30 2013 Return-Path: Delivered-To: freebsd-current@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 1E119B7A for ; Mon, 25 Mar 2013 13:34:30 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id CE9B6E02 for ; Mon, 25 Mar 2013 13:34:29 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1UK7Xd-0001sP-Ot; Mon, 25 Mar 2013 15:34:25 +0200 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id CC8B81E08A; Mon, 25 Mar 2013 15:34:24 +0200 (EET) Date: Mon, 25 Mar 2013 15:34:24 +0200 From: Andrey Simonenko To: Rick Macklem Subject: Re: Possible bug in NFSv4 with krb5p security? Message-ID: <20130325133424.GA1342@pm513-1.comsys.ntu-kpi.kiev.ua> References: <20130220122826.GA13613@pm513-1.comsys.ntu-kpi.kiev.ua> <423251068.3167476.1361402947119.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423251068.3167476.1361402947119.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 28-Apr-2011 07:11:12) X-Date: 2013-03-25 15:34:25 X-Connected-IP: 10.18.52.101:51062 X-Message-Linecount: 92 X-Body-Linecount: 75 X-Message-Size: 3462 X-Body-Size: 2634 Cc: freebsd-current@freebsd.org, Elias Martenson , Benjamin Kaduk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 13:34:30 -0000 On Wed, Feb 20, 2013 at 06:29:07PM -0500, Rick Macklem wrote: > Andrey Simonnenko wrote: > > > > Another variant. This is a program that can be used for verifying > > correctness of the function, just change PWBUF_SIZE_* values and put > > some printfs to see when buffer is reallocated. sizehint is updated > > only when malloc() succeeded. > > > > --------------------------------- > > static int > > getpwnam_r_func(const char *name, uid_t *uidp) > > { > > #define PWBUF_SIZE_INI (2 * MAXLOGNAME + MAXPATHLEN + _PASSWORD_LEN) > > #define PWBUF_SIZE_INC 128 > > > > static size_t sizehint = PWBUF_SIZE_INI; > > > > struct passwd pwd; > > struct passwd *pw; > > char *buf; > > size_t size; > > int error; > > char lname[MAXLOGNAME]; > > char bufs[PWBUF_SIZE_INI]; > > > > strncpy(lname, name, sizeof(lname)); > > > > buf = bufs; > > size = sizeof(bufs); > > for (;;) { > > error = getpwnam_r(lname, &pwd, buf, size, &pw); > > if (buf != bufs) > > free(buf); > > if (pw != NULL) { > > *uidp = pw->pw_uid; > > return (GSS_S_COMPLETE); > > } else if (error != ERANGE || size > SIZE_MAX - PWBUF_SIZE_INC) > > return (GSS_S_FAILURE); > > if (size != sizehint) > > size = sizehint; > > else > > size += PWBUF_SIZE_INC; > > buf = malloc(size); > > if (buf == NULL) > > return (GSS_S_FAILURE); > > sizehint = size; > > } > > } > > > All looks fine to me. (Before my mailer messed with the whitespace;-) > > Thanks, rick > ps: I will commit it in April, unless someone else does so sooner. I was thinking about this approach once again and made a conclusion that it is wrong. Using static buffer at first and then allocate memory for next calls can cause slowdown, depends on number of entries and used database backend of course. The libc code for getpwnam() allocates memory for the buffer and does not free it on exit from the function, If the above written code or any of its modification is going to be committed to the source base (by you or by some another committer), then I ask and require to not write/mention my name and email address neither in source file nor in commit log message. Appropriate commit log message for the above written code can be the following: -------------------------------------------------------------------------- Since FreeBSD does not support sysconf(_SC_GETPW_R_SIZE_MAX), then allocate a buffer of sufficient size for getpwnam_r() as it is suggested in EXAMPLES of SUSv4 documentation for the getpwnam_r() function. -------------------------------------------------------------------------- since this documentation has similar code. From owner-freebsd-current@FreeBSD.ORG Mon Mar 25 14:01:45 2013 Return-Path: Delivered-To: freebsd-current@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 B6393A8E for ; Mon, 25 Mar 2013 14:01:43 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 700F888 for ; Mon, 25 Mar 2013 14:01:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:Message-ID:Subject:To:Sender:From:Date; bh=QwckH0VQf22kI4lC0zsrTi8x9Ci3vLw7G+lGDZkvQhI=; b=CLiI9hDkDQSv7Z4Mu18OAZnD/jXLytI/7Pv6BKE6i+S5Sle39LAV+uzvX0eLxNi40XhDl8UGSFy84Rtxcc1LrLMhmC2fYGRc/bip3kmf/IecFyV+wTfAHWbEk3E/N1Da9Ti8QRIl407/HS4Ge+24SBnz/7biwO1For8r9GxFCTw=; Received: from cpe-72-182-19-162.austin.res.rr.com ([72.182.19.162]:20807 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UK7xu-00050f-4E for freebsd-current@freebsd.org; Mon, 25 Mar 2013 09:01:43 -0500 Date: Mon, 25 Mar 2013 09:01:30 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: freebsd-current@freebsd.org Subject: [CRASH] ZFS recv Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Spam-Score: 2.6 (++) X-LERCTR-Spam-Score: 2.6 (++) X-Spam-Report: SpamScore (2.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, KAM_STOCKTIP=5.5 X-LERCTR-Spam-Report: SpamScore (2.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, KAM_STOCKTIP=5.5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 14:01:45 -0000 Greetings, I'm getting a zfs recv crash on 10.0-CURRENT.... I was ssh'd to my 8.4 box and did: zfs send -R -D vault@2013-03-24 | ssh home.lerctr.org zfs recv -F -u -v -d zroot/backups/TBH And on the 2nd (or so) filesystem got the following panic. I have the vmcore as well as sources, and can give ssh access. I can also reproduce this at will. ideas? borg.lerctr.org dumped core - see /var/crash/vmcore.4 Mon Mar 25 08:52:46 CDT 2013 FreeBSD borg.lerctr.org 10.0-CURRENT FreeBSD 10.0-CURRENT #129 r248695: Mon Mar 25 05:03:32 CDT 2013 root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG-DTRACE amd64 panic: page fault 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 = 0x378 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80531426 stack pointer = 0x28:0xffffff91579193d0 frame pointer = 0x28:0xffffff9157919470 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 = 1044 (zfs) trap number = 12 panic: page fault cpuid = 0 Uptime: 2m10s Dumping 4913 out of 64747 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/acl_nfs4.ko...Reading symbols from /boot/kernel/acl_nfs4.ko.symbols...done. done. Loaded symbols for /boot/kernel/acl_nfs4.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.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 /boot/kernel/coretemp.ko...Reading symbols from /boot/kernel/coretemp.ko.symbols...done. done. Loaded symbols for /boot/kernel/coretemp.ko Reading symbols from /boot/kernel/ichsmb.ko...Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. done. Loaded symbols for /boot/kernel/ichsmb.ko Reading symbols from /boot/kernel/smbus.ko...Reading symbols from /boot/kernel/smbus.ko.symbols...done. done. Loaded symbols for /boot/kernel/smbus.ko Reading symbols from /boot/kernel/ichwd.ko...Reading symbols from /boot/kernel/ichwd.ko.symbols...done. done. Loaded symbols for /boot/kernel/ichwd.ko Reading symbols from /boot/kernel/cpuctl.ko...Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. done. Loaded symbols for /boot/kernel/cpuctl.ko Reading symbols from /boot/kernel/crypto.ko...Reading symbols from /boot/kernel/crypto.ko.symbols...done. done. Loaded symbols for /boot/kernel/crypto.ko Reading symbols from /boot/kernel/cryptodev.ko...Reading symbols from /boot/kernel/cryptodev.ko.symbols...done. done. Loaded symbols for /boot/kernel/cryptodev.ko Reading symbols from /boot/kernel/dtraceall.ko...Reading symbols from /boot/kernel/dtraceall.ko.symbols...done. done. Loaded symbols for /boot/kernel/dtraceall.ko Reading symbols from /boot/kernel/profile.ko...Reading symbols from /boot/kernel/profile.ko.symbols...done. done. Loaded symbols for /boot/kernel/profile.ko Reading symbols from /boot/kernel/cyclic.ko...Reading symbols from /boot/kernel/cyclic.ko.symbols...done. done. Loaded symbols for /boot/kernel/cyclic.ko Reading symbols from /boot/kernel/dtrace.ko...Reading symbols from /boot/kernel/dtrace.ko.symbols...done. done. Loaded symbols for /boot/kernel/dtrace.ko Reading symbols from /boot/kernel/systrace_freebsd32.ko...Reading symbols from /boot/kernel/systrace_freebsd32.ko.symbols...done. done. Loaded symbols for /boot/kernel/systrace_freebsd32.ko Reading symbols from /boot/kernel/systrace.ko...Reading symbols from /boot/kernel/systrace.ko.symbols...done. done. Loaded symbols for /boot/kernel/systrace.ko Reading symbols from /boot/kernel/sdt.ko...Reading symbols from /boot/kernel/sdt.ko.symbols...done. done. Loaded symbols for /boot/kernel/sdt.ko Reading symbols from /boot/kernel/lockstat.ko...Reading symbols from /boot/kernel/lockstat.ko.symbols...done. done. Loaded symbols for /boot/kernel/lockstat.ko Reading symbols from /boot/kernel/fasttrap.ko...Reading symbols from /boot/kernel/fasttrap.ko.symbols...done. done. Loaded symbols for /boot/kernel/fasttrap.ko Reading symbols from /boot/kernel/fbt.ko...Reading symbols from /boot/kernel/fbt.ko.symbols...done. done. Loaded symbols for /boot/kernel/fbt.ko Reading symbols from /boot/kernel/dtnfscl.ko...Reading symbols from /boot/kernel/dtnfscl.ko.symbols...done. done. Loaded symbols for /boot/kernel/dtnfscl.ko Reading symbols from /boot/kernel/dtmalloc.ko...Reading symbols from /boot/kernel/dtmalloc.ko.symbols...done. done. Loaded symbols for /boot/kernel/dtmalloc.ko Reading symbols from /boot/kernel/dtio.ko...Reading symbols from /boot/kernel/dtio.ko.symbols...done. done. Loaded symbols for /boot/kernel/dtio.ko Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/fdescfs.ko Reading symbols from /boot/kernel/uhid.ko...Reading symbols from /boot/kernel/uhid.ko.symbols...done. done. Loaded symbols for /boot/kernel/uhid.ko Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /boot/kernel/netgraph.ko.symbols...done. done. Loaded symbols for /boot/kernel/netgraph.ko Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from /boot/kernel/ng_ether.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ether.ko Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko #0 doadump (textdump=) at pcpu.h:229 229 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:229 #1 0xffffffff80529060 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0xffffffff805293e7 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0xffffffff80732cd5 in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:872 #4 0xffffffff807330d9 in trap_pfault (frame=0x0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:730 #5 0xffffffff807326bc in trap (frame=0xffffff9157919320) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0xffffffff8071cc62 in calltrap () at exception.S:228 #7 0xffffffff80531426 in _sx_xlock_hard (sx=0xfffffe01d5b64db8, tid=18446741877920023696, opts=, file=0x0, line=250541281) at /usr/src/sys/kern/kern_sx.c:556 #8 0xffffffff80530f8c in _sx_xlock (sx=0x0, opts=0, file=0x0, line=0) at sx.h:152 #9 0xffffffff80e67251 in dmu_objset_from_ds (ds=0xfffffe01d5b64c00, osp=0xffffff91579195b0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:434 #10 0xffffffff80e649ef in dmu_recv_stream (drc=0xffffff9157919750, fp=, voffp=0xffffff9157919740, cleanup_fd=8, action_handlep=) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c:1318 #11 0xffffffff80ed9226 in zfs_ioc_recv (zc=0xffffff8012cc8000) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:4084 #12 0xffffffff80ed44a1 in zfsdev_ioctl (dev=, zcmd=, arg=0xffffff8012cc8000 "zroot/backups/TBH/home", flag=, td=) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:5902 #13 0xffffffff80427e0f in devfs_ioctl_f (fp=0xfffffe00c0b360a0, com=3517471259, data=0xffffff8012cc8000, cred=, td=0xfffffe00c0bec490) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 #14 0xffffffff8057359b in kern_ioctl (td=0xfffffe00c0bec490, fd=, com=18446741877920023696) at file.h:306 #15 0xffffffff8057331f in sys_ioctl (td=0xfffffe00c0bec490, uap=0xffffff9157919b80) at /usr/src/sys/kern/sys_generic.c:693 #16 0xffffffff807335d7 in amd64_syscall (td=0xfffffe00c0bec490, traced=0) at subr_syscall.c:134 #17 0xffffffff8071cf4b in Xfast_syscall () at exception.S:387 #18 0x00000008019dacea in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) ------------------------------------------------------------------------ ps -axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -8 0 0 0 - DLs - 0:02.51 [kernel] 0 1 0 0 20 0 9428 0 wait DLs - 0:00.10 [init] 0 2 0 0 -16 0 0 0 crypto_w DL - 0:00.00 [crypto] 0 3 0 0 -16 0 0 0 crypto_r DL - 0:00.00 [crypto returns 0 4 0 0 -16 0 0 0 - DL - 0:00.00 [fdc0] 0 5 0 0 -8 0 0 0 tx->tx_s DL - 0:00.08 [zfskern] 0 6 0 0 -16 0 0 0 waiting_ DL - 0:00.00 [sctp_iterator] 0 7 0 0 -16 0 0 0 ccb_scan DL - 0:00.00 [xpt_thrd] 0 8 0 0 -16 0 0 0 - RL - 0:00.00 [pagedaemon] 0 9 0 0 -16 0 0 0 psleep DL - 0:00.00 [vmdaemon] 0 10 0 0 -16 0 0 0 audit_wo DL - 0:00.00 [audit] 0 11 0 0 155 0 0 0 - RL - 6:41.28 [idle] 0 12 0 0 -84 0 0 0 - WL - 0:00.26 [intr] 0 13 0 0 -8 0 0 0 - DL - 0:00.33 [geom] 0 14 0 0 -16 0 0 0 - DL - 0:00.01 [yarrow] 0 15 0 0 -68 0 0 0 - DL - 0:00.01 [usb] 0 16 0 0 -20 0 0 0 VBoxIS DL - 0:00.00 [TIMER] 0 17 0 0 155 0 0 0 pgzero DL - 0:00.00 [pagezero] 0 18 0 0 -16 0 0 0 psleep DL - 0:00.00 [bufdaemon] 0 19 0 0 16 0 0 0 - RL - 0:00.00 [syncer] 0 20 0 0 -16 0 0 0 vlruwt DL - 0:00.00 [vnlru] 0 632 1 0 20 0 13196 0 select Ds - 0:00.00 [devd] 0 757 1 0 20 0 14376 0 select Ds - 0:00.04 [syslogd] 0 760 1 0 -52 0 6180 2088 - Rs - 0:00.00 [watchdogd] 0 774 1 0 20 0 16456 0 select Ds - 0:00.01 [rpcbind] 0 809 1 0 52 0 38948 0 select Ds - 0:00.02 [mountd] 0 815 1 0 52 0 36792 0 select Ds - 0:00.04 [nfsd] 0 817 815 0 52 0 12216 0 rpcsvc D - 0:00.00 [nfsd] 0 853 1 0 20 0 25196 0 select Ds - 0:00.01 [ntpd] 0 874 0 0 -16 0 0 0 sleep DL - 0:00.00 [ng_queue] 0 886 1 0 20 0 34708 0 nanslp Ds - 0:00.01 [perl] 0 890 1 0 52 0 30780 0 nanslp D - 0:00.43 [smartd] 70 899 1 0 20 0 84416 0 select Ds - 0:00.22 [postgres] 70 903 899 0 20 0 84416 0 select Ds - 0:00.00 [postgres] 70 904 899 0 20 0 84416 0 select Ds - 0:00.00 [postgres] 70 905 899 0 20 0 84416 0 select Ds - 0:00.00 [postgres] 70 906 899 0 20 0 44120 0 select Ds - 0:00.00 [postgres] 26 928 1 0 52 0 48644 0 select Ds - 0:00.00 [exim-4.80.1-2] 0 938 1 0 20 0 103216 0 - Rs - 0:00.02 [cupsd] 1028 944 1 0 155 0 40308 0 select Ds - 0:00.05 [boinc_client] 910 948 1 0 20 0 59412 0 uwait Ds - 0:00.00 [bacula-sd] 0 951 1 0 20 0 57068 0 uwait Ds - 0:00.00 [bacula-fd] 910 954 1 0 20 0 72404 0 - Rs - 0:00.00 [bacula-dir] 0 959 1 0 20 0 56264 0 select Ds - 0:00.00 [sshd] 0 969 1 0 20 0 16460 0 nanslp Ds - 0:00.00 [cron] 0 990 1 0 52 0 18576 0 select Ds - 0:00.00 [inetd] 0 1010 1 0 21 0 47584 0 wait Ds - 0:00.00 [login] 0 1011 1 0 52 0 14364 0 ttyin Ds+ - 0:00.00 [getty] 0 1012 1 0 52 0 14364 0 ttyin Ds+ - 0:00.00 [getty] 0 1013 1 0 52 0 14364 0 ttyin Ds+ - 0:00.00 [getty] 0 1014 1 0 52 0 14364 0 ttyin Ds+ - 0:00.00 [getty] 0 1015 1 0 52 0 14364 0 ttyin Ds+ - 0:00.00 [getty] 0 1016 1 0 52 0 14364 0 ttyin Ds+ - 0:00.00 [getty] 0 1017 1 0 52 0 14364 0 ttyin Ds+ - 0:00.00 [getty] 0 1020 1010 0 20 0 16928 0 wait D - 0:00.00 [sh] 0 1022 1020 0 20 0 47640 0 select D+ - 0:00.00 [ssh] 1028 1024 944 0 155 19 54272 0 - RN - 0:17.51 [wcg_hpf2_roset 1028 1025 944 0 155 19 54272 0 - RN - 0:18.11 [wcg_hpf2_roset 1028 1026 944 0 155 19 129292 0 - RN - 0:03.57 [wcgrid_faah_7. 1028 1027 944 0 155 19 1892 0 - RN - 0:00.03 [wcgrid_cep2_6. 1028 1028 944 0 155 19 74216 0 m DN - 0:17.23 [setiathome-6.1 1028 1029 944 0 155 19 74216 0 - RN - 0:19.34 [setiathome-6.1 1028 1030 944 0 155 19 74216 0 m DN - 0:16.21 [setiathome-6.1 1028 1031 944 0 155 19 129292 0 i DN - 0:00.00 [wcgrid_faah_7. 1028 1032 944 0 155 19 74216 0 m DN - 0:17.25 [setiathome-6.1 1028 1033 1027 0 155 19 1892 0 i DN - 0:00.00 [wcgrid_cep2_6. 1028 1034 1033 0 155 19 1892 0 i DN - 0:00.00 [wcgrid_cep2_6. 1028 1035 1024 0 155 19 54272 0 6 DN - 0:00.00 [wcg_hpf2_roset 1028 1036 1035 0 155 19 54272 0 - RN - 0:00.00 [wcg_hpf2_roset 1028 1037 1025 0 155 19 54272 0 6 DN - 0:00.00 [wcg_hpf2_roset 1028 1038 1037 0 155 19 54272 0 6 DN - 0:00.00 [wcg_hpf2_roset 0 1040 959 0 20 0 81532 0 select Ds - 0:00.00 [sshd] 0 1042 1040 0 27 0 20304 0 pause Ds - 0:00.00 [csh] 0 1044 1042 0 21 0 39968 0 - R - 0:00.00 [zfs] ------------------------------------------------------------------------ vmstat -s 339379 cpu context switches 36990 device interrupts 6821 software interrupts 362408 traps 34071033 system calls 21 kernel threads created 834 fork() calls 182 vfork() calls 7 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 0 swap pager pageouts 0 swap pager pages paged out 1567 vnode pager pageins 11054 vnode pager pages paged in 8 vnode pager pageouts 16 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 11 pages reactivated 33160 copy-on-write faults 209 copy-on-write optimized faults 284971 zero fill pages zeroed 0 zero fill pages prezeroed 107 intransit blocking page faults 405648 total VM faults taken 3427 page faults requiring I/O 0 pages affected by kernel thread creation 32298 pages affected by fork() 6408 pages affected by vfork() 22897 pages affected by rfork() 0 pages cached 407800 pages freed 0 pages freed by daemon 0 pages freed by exiting processes 67444 pages active 20205 pages inactive 8 pages in VM cache 860785 pages wired down 15199607 pages free 4096 bytes per page 247996 total name lookups cache hits (93% pos + 1% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) DEVFS3 207 52K - 226 256 filedesc 78 251K - 1058 16,32,64,128,2048,4096 filedesc_to_leader 11 1K - 11 64 sigio 1 1K - 1 64 kdtrace 500 112K - 1633 64,256 kenv 84 11K - 112 16,32,64,128 kqueue 2 3K - 52 256,2048 proc-args 46 4K - 373 16,32,64,128,256 DEVFS1 181 91K - 199 512 hhook 2 1K - 2 128 ithread 119 21K - 119 32,128,256 KTRACE 100 13K - 100 128 DEVFS 40 1K - 41 16,128 linker 351 171K - 477 16,32,64,128,256,512,1024,2048,4096 DEVFSP 1 1K - 11 64 lockf 50 6K - 86 64,128 loginclass 2 1K - 6 64 cache 1 1K - 1 32 devbuf 17037 34759K - 17243 16,32,64,128,256,512,1024,2048,4096 temp 56 35K - 10350 16,32,64,128,256,512,1024,2048,4096 ip6ndp 5 1K - 6 64,128 module 293 37K - 293 128 mtx_pool 2 16K - 2 osd 8 1K - 20 16,32,64,128 pmchooks 1 1K - 1 128 pgrp 36 5K - 51 128 session 34 5K - 45 128 proc 2 256K - 2 subproc 231 350K - 1202 512,4096 cred 108 17K - 8456 64,256 plimit 19 5K - 202 256 uidinfo 6 33K - 9 128 NFS fh 1 1K - 7 16 sysctl 0 0K - 380 16,32,64 sysctloid 6406 317K - 6553 16,32,64,128 sysctltmp 0 0K - 338 16,32,64,128,256,4096 tidhash 1 256K - 1 callout 9 3208K - 9 umtx 1062 133K - 1062 128 p1003.1b 1 1K - 1 16 SWAP 12 19681K - 12 64 bus 900 86K - 4751 16,32,64,128,256,512,1024 bus-sc 135 290K - 1989 16,32,64,128,256,512,1024,2048,4096 devstat 24 49K - 24 32,4096 eventhandler 86 7K - 86 64,128 kobj 169 676K - 681 4096 Per-cpu 1 1K - 1 32 rman 292 33K - 686 16,32,128 sbuf 0 0K - 2785 16,32,64,128,256,512,1024,2048,4096 stack 0 0K - 2 256 taskqueue 105 16K - 135 16,32,64,256,1024 Unitno 19 2K - 227 32,64 ioctlops 1 8K - 13701 16,32,64,128,256,512,1024,2048 select 34 5K - 34 128 iov 0 0K - 1301 16,64,128,256,512 msg 4 30K - 4 2048,4096 sem 4 106K - 4 2048,4096 shm 11 40K - 22 2048 tty 19 19K - 21 1024,2048 mbuf_tag 0 0K - 58 32,128 shmfd 1 8K - 1 soname 7 1K - 697 16,32,128 pcb 38 8341K - 95 16,32,128,1024,2048 vfscache 1 16384K - 1 vfs_hash 1 8192K - 1 vnodes 1 1K - 1 256 mount 397 20K - 1897 16,32,64,128,256,512 vnodemarker 0 0K - 202 512 BPF 3 1K - 3 128 ifnet 4 7K - 4 128,2048 ifaddr 48 15K - 48 32,64,128,256,512,2048,4096 ether_multi 40 3K - 46 16,32,64 clone 6 1K - 6 128 arpcom 2 1K - 2 16 lltable 12 5K - 12 256,512 newnfsmnt 1 1K - 1 1024 pfs_nodes 21 6K - 21 256 pfs_vncache 76 5K - 81 64 GEOM 344 60K - 2226 16,32,64,128,256,512,1024,2048 routetbl 35 5K - 240 32,64,128,256,512 igmp 3 1K - 3 256 in_multi 2 1K - 2 256 ppbusdev 2 1K - 2 256 entropy 1024 64K - 1024 64 sctp_a_it 0 0K - 3 16 sctp_vrf 1 1K - 1 64 sctp_ifa 5 1K - 5 128 sctp_ifn 2 1K - 2 128 sctp_iter 0 0K - 3 256 hostcache 1 28K - 1 syncache 1 100K - 1 in6_mfilter 1 1K - 1 1024 in6_multi 22 3K - 22 32,256 ip6_moptions 2 1K - 2 32,256 CAM DEV 15 30K - 24 2048 UART 6 5K - 6 16,1024 mld 3 1K - 3 128 ata_pci 1 1K - 1 64 CAM CCB 13 26K - 101 2048 rpc 22 6K - 28 32,64,128,256,512,1024 audit_evclass 188 6K - 227 32 vm_pgdata 7 8193K - 7 128 UMAHash 1 1K - 1 512 raid_data 0 0K - 336 32,128,256 acpiintr 1 1K - 1 64 acpica 1830 187K - 57239 16,32,64,128,256,512,1024,2048 CAM path 22 1K - 68 32 CAM periph 16 4K - 41 16,32,64,128,256 acpitask 1 8K - 1 acpisem 21 3K - 21 128 CAM queue 39 2K - 133 16,32,64 memdesc 1 4K - 1 4096 acpidev 36 3K - 36 64 atkbddev 2 1K - 2 64 CAM dev queue 8 1K - 8 128 USB 38 41K - 40 16,32,64,128,256,512,1024,4096 md_nvidia_data 0 0K - 54 512 USBdev 30 6K - 40 64,128,512 md_sii_data 0 0K - 54 512 CAM SIM 8 2K - 8 256 CAM XPT 58 4K - 204 16,32,64,128,1024 kbdmux 7 18K - 7 16,512,1024,2048 apmdev 1 1K - 1 128 madt_table 0 0K - 1 4096 LED 4 1K - 4 16,128 isadev 5 1K - 5 128 io_apic 2 4K - 2 2048 MCA 8 1K - 8 128 pci_link 16 2K - 16 32,64,128 msi 2 1K - 2 128 nexusdev 4 1K - 4 16 acpi_perf 8 1K - 8 64 scsi_cd 0 0K - 11 16 cdev 8 2K - 8 256 solaris 62374 344297K - 749641 16,32,64,128,256,512,1024,2048,4096 linux 36 2K - 36 32,64 cpuctl 1 1K - 9 64,4096 crypto 1 1K - 1 512 xform 0 0K - 206 16,32 cyclic 32 3K - 32 16,64,128 kstat_data 5 1K - 5 64 fbt 1 256K - 1 iprtheap 23 56K - 23 32,64,128,256,2048 fdesc_mount 1 1K - 1 16 netgraph_node 4 1K - 4 128,256 netgraph 2 1K - 2 64 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 208, 0, 254, 1, 254, 0, 0 UMA Zones: 1408, 0, 254, 0, 254, 0, 0 UMA Slabs: 568, 0, 16533, 120, 31690, 0, 0 UMA RCntSlabs: 568, 0, 1217, 1, 1217, 0, 0 UMA Hash: 256, 0, 82, 8, 83, 0, 0 16 Bucket: 152, 0, 391, 9, 391, 0, 0 32 Bucket: 280, 0, 317, 5, 317, 15, 0 64 Bucket: 536, 0, 358, 6, 358, 84, 0 128 Bucket: 1048, 0, 1365, 0, 1365,4185, 0 VM OBJECT: 240, 0, 3359, 257, 14724, 0, 0 RADIX NODE: 144, 16148184, 20410,16127826, 76441, 0, 0 MAP: 232, 0, 8, 24, 8, 0, 0 KMAP ENTRY: 120, 4230725, 255, 1233, 48042, 0, 0 MAP ENTRY: 120, 0, 1670, 407, 34695, 0, 0 fakepg: 104, 0, 0, 0, 0, 0, 0 mt_zone: 4112, 0, 283, 22, 283, 0, 0 16: 16, 0, 6, 1170, 8417, 0, 0 16: 16, 0, 3274, 758, 56874, 0, 0 16: 16, 0, 2, 166, 2, 0, 0 16: 16, 0, 87, 1089, 23969, 0, 0 16: 16, 0, 2339, 1021, 2911, 0, 0 16: 16, 0, 550, 962, 3590, 0, 0 16: 16, 0, 8, 832, 41, 0, 0 16: 16, 0, 62, 946, 270, 0, 0 32: 32, 0, 31, 878, 4358, 0, 0 32: 32, 0, 2152, 1989, 31736, 0, 0 32: 32, 0, 29, 577, 29, 0, 0 32: 32, 0, 122, 787, 4245, 0, 0 32: 32, 0, 2388, 945, 2665, 0, 0 32: 32, 0, 241, 971, 2379, 0, 0 32: 32, 0, 71, 838, 280, 0, 0 32: 32, 0, 200, 406, 329, 0, 0 64: 64, 0, 84, 476, 810, 0, 0 64: 64, 0, 24198, 3130, 222936, 0, 0 64: 64, 0, 1107, 517, 2080, 0, 0 64: 64, 0, 729, 559, 25092, 0, 0 64: 64, 0, 324, 460, 358, 0, 0 64: 64, 0, 8983, 873, 16224, 0, 0 64: 64, 0, 33, 135, 33, 0, 0 64: 64, 0, 65, 495, 237, 0, 0 128: 128, 0, 34, 198, 80, 0, 0 128: 128, 0, 9778, 1300, 81357, 0, 0 128: 128, 0, 85, 234, 100, 0, 0 128: 128, 0, 1220, 404, 2193, 0, 0 128: 128, 0, 2953, 585, 3025, 0, 0 128: 128, 0, 567, 361, 1209, 0, 0 128: 128, 0, 16, 100, 16, 0, 0 128: 128, 0, 80, 239, 427, 0, 0 256: 256, 0, 10, 20, 12, 0, 0 256: 256, 0, 2880, 3525, 105923, 0, 0 256: 256, 0, 490, 80, 783, 0, 0 256: 256, 0, 240, 75, 1045, 0, 0 256: 256, 0, 5, 70, 7, 0, 0 256: 256, 0, 302, 208, 4700, 0, 0 256: 256, 0, 22, 23, 22, 0, 0 256: 256, 0, 129, 216, 1507, 0, 0 512: 512, 0, 169, 41, 210, 0, 0 512: 512, 0, 10146, 347, 128131, 0, 0 512: 512, 0, 4, 59, 76, 0, 0 512: 512, 0, 217, 77, 1180, 0, 0 512: 512, 0, 12, 44, 120, 0, 0 512: 512, 0, 137, 136, 357, 0, 0 512: 512, 0, 0, 0, 0, 0, 0 512: 512, 0, 0, 252, 877, 0, 0 1024: 1024, 0, 2, 66, 84, 0, 0 1024: 1024, 0, 325, 187, 2938, 0, 0 1024: 1024, 0, 4, 4, 4, 0, 0 1024: 1024, 0, 6, 14, 1917, 0, 0 1024: 1024, 0, 19, 9, 19, 0, 0 1024: 1024, 0, 15, 321, 2674, 0, 0 1024: 1024, 0, 1, 7, 1, 0, 0 1024: 1024, 0, 13, 15, 164, 0, 0 2048: 2048, 0, 38, 96, 326, 0, 0 2048: 2048, 0, 411, 237, 4477, 0, 0 2048: 2048, 0, 0, 0, 0, 0, 0 2048: 2048, 0, 81, 133, 1080, 0, 0 2048: 2048, 0, 1, 7, 3, 0, 0 2048: 2048, 0, 23, 95, 170, 0, 0 2048: 2048, 0, 0, 0, 0, 0, 0 2048: 2048, 0, 0, 8, 65, 0, 0 4096: 4096, 0, 67, 100, 1038, 0, 0 4096: 4096, 0, 6394, 4781, 99018, 0, 0 4096: 4096, 0, 169, 100, 681, 0, 0 4096: 4096, 0, 24, 41, 28, 0, 0 4096: 4096, 0, 10, 44, 12, 0, 0 4096: 4096, 0, 27, 63, 7787, 0, 0 4096: 4096, 0, 0, 0, 0, 0, 0 4096: 4096, 0, 0, 0, 0, 0, 0 Files: 80, 0, 192, 393, 17327, 0, 0 TURNSTILE: 136, 0, 532, 108, 532, 0, 0 rl_entry: 40, 0, 75, 681, 75, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1208, 0, 73, 89, 1044, 0, 0 THREAD: 1168, 0, 425, 106, 587, 0, 0 SLEEPQUEUE: 80, 0, 532, 164, 532, 0, 0 VMSPACE: 392, 0, 46, 134, 1022, 0, 0 cpuset: 72, 0, 274, 326, 425, 0, 0 cyclic_id_cache: 64, 0, 0, 0, 0, 0, 0 audit_record: 1240, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 26520435, 1023, 1163, 1760, 0, 0 mbuf: 256, 26520435, 7, 1027, 1874, 0, 0 mbuf_cluster: 2048, 4143818, 2176, 230, 2176, 0, 0 mbuf_jumbo_page: 4096, 2071909, 0, 14, 7, 0, 0 mbuf_jumbo_9k: 9216, 1841694, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 1381272, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 dtrace_state_cache: 4096, 0, 0, 0, 0, 0, 0 g_bio: 248, 0, 2, 538, 109938, 0, 0 ttyinq: 160, 0, 120, 144, 255, 0, 0 ttyoutq: 256, 0, 64, 101, 136, 0, 0 ata_request: 336, 0, 0, 143, 77, 0, 0 ata_composite: 336, 0, 0, 0, 0, 0, 0 vtnet_tx_hdr: 24, 0, 0, 0, 0, 0, 0 cryptop: 88, 0, 0, 0, 0, 0, 0 cryptodesc: 72, 0, 0, 0, 0, 0, 0 FPU_save_area: 512, 0, 0, 0, 0, 0, 0 taskq_zone: 48, 0, 0, 504, 92, 0, 0 VNODE: 472, 0, 9393, 279, 9518, 0, 0 VNODEPOLL: 112, 0, 0, 0, 0, 0, 0 NAMEI: 1024, 0, 0, 128, 53101, 0, 0 S VFS Cache: 108, 0, 9441, 360, 11402, 0, 0 STS VFS Cache: 148, 0, 0, 0, 0, 0, 0 L VFS Cache: 328, 0, 84, 132, 112, 0, 0 LTS VFS Cache: 368, 0, 0, 0, 0, 0, 0 NCLNODE: 528, 0, 1, 13, 1, 0, 0 pipe: 744, 0, 12, 93, 553, 0, 0 space_seg_cache: 64, 0, 9593, 80007, 278530, 0, 0 zio_cache: 944, 0, 5, 7883, 318981, 0, 0 zio_link_cache: 48, 0, 3, 8709, 303395, 0, 0 zio_buf_512: 512, 0, 0, 0, 0, 0, 0 zio_data_buf_512: 512, 0, 0, 0, 0, 0, 0 zio_buf_1024: 1024, 0, 0, 0, 0, 0, 0 zio_data_buf_1024: 1024, 0, 0, 0, 0, 0, 0 zio_buf_1536: 1536, 0, 0, 0, 0, 0, 0 zio_data_buf_1536: 1536, 0, 0, 0, 0, 0, 0 zio_buf_2048: 2048, 0, 0, 0, 0, 0, 0 zio_data_buf_2048: 2048, 0, 0, 0, 0, 0, 0 zio_buf_2560: 2560, 0, 0, 0, 0, 0, 0 zio_data_buf_2560: 2560, 0, 0, 0, 0, 0, 0 zio_buf_3072: 3072, 0, 0, 0, 0, 0, 0 zio_data_buf_3072: 3072, 0, 0, 0, 0, 0, 0 zio_buf_3584: 3584, 0, 0, 0, 0, 0, 0 zio_data_buf_3584: 3584, 0, 0, 0, 0, 0, 0 zio_buf_4096: 4096, 0, 0, 0, 0, 0, 0 zio_data_buf_4096: 4096, 0, 0, 0, 0, 0, 0 zio_buf_5120: 5120, 0, 0, 0, 0, 0, 0 zio_data_buf_5120: 5120, 0, 0, 0, 0, 0, 0 zio_buf_6144: 6144, 0, 0, 0, 0, 0, 0 zio_data_buf_6144: 6144, 0, 0, 0, 0, 0, 0 zio_buf_7168: 7168, 0, 0, 0, 0, 0, 0 zio_data_buf_7168: 7168, 0, 0, 0, 0, 0, 0 zio_buf_8192: 8192, 0, 0, 0, 0, 0, 0 zio_data_buf_8192: 8192, 0, 0, 0, 0, 0, 0 zio_buf_10240: 10240, 0, 0, 0, 0, 0, 0 zio_data_buf_10240: 10240, 0, 0, 0, 0, 0, 0 zio_buf_12288: 12288, 0, 0, 0, 0, 0, 0 zio_data_buf_12288: 12288, 0, 0, 0, 0, 0, 0 zio_buf_14336: 14336, 0, 0, 0, 0, 0, 0 zio_data_buf_14336: 14336, 0, 0, 0, 0, 0, 0 zio_buf_16384: 16384, 0, 0, 0, 0, 0, 0 zio_data_buf_16384: 16384, 0, 0, 0, 0, 0, 0 zio_buf_20480: 20480, 0, 0, 0, 0, 0, 0 zio_data_buf_20480: 20480, 0, 0, 0, 0, 0, 0 zio_buf_24576: 24576, 0, 0, 0, 0, 0, 0 zio_data_buf_24576: 24576, 0, 0, 0, 0, 0, 0 zio_buf_28672: 28672, 0, 0, 0, 0, 0, 0 zio_data_buf_28672: 28672, 0, 0, 0, 0, 0, 0 zio_buf_32768: 32768, 0, 0, 0, 0, 0, 0 zio_data_buf_32768: 32768, 0, 0, 0, 0, 0, 0 zio_buf_36864: 36864, 0, 0, 0, 0, 0, 0 zio_data_buf_36864: 36864, 0, 0, 0, 0, 0, 0 zio_buf_40960: 40960, 0, 0, 0, 0, 0, 0 zio_data_buf_40960: 40960, 0, 0, 0, 0, 0, 0 zio_buf_45056: 45056, 0, 0, 0, 0, 0, 0 zio_data_buf_45056: 45056, 0, 0, 0, 0, 0, 0 zio_buf_49152: 49152, 0, 0, 0, 0, 0, 0 zio_data_buf_49152: 49152, 0, 0, 0, 0, 0, 0 zio_buf_53248: 53248, 0, 0, 0, 0, 0, 0 zio_data_buf_53248: 53248, 0, 0, 0, 0, 0, 0 zio_buf_57344: 57344, 0, 0, 0, 0, 0, 0 zio_data_buf_57344: 57344, 0, 0, 0, 0, 0, 0 zio_buf_61440: 61440, 0, 0, 0, 0, 0, 0 zio_data_buf_61440: 61440, 0, 0, 0, 0, 0, 0 zio_buf_65536: 65536, 0, 0, 0, 0, 0, 0 zio_data_buf_65536: 65536, 0, 0, 0, 0, 0, 0 zio_buf_69632: 69632, 0, 0, 0, 0, 0, 0 zio_data_buf_69632: 69632, 0, 0, 0, 0, 0, 0 zio_buf_73728: 73728, 0, 0, 0, 0, 0, 0 zio_data_buf_73728: 73728, 0, 0, 0, 0, 0, 0 zio_buf_77824: 77824, 0, 0, 0, 0, 0, 0 zio_data_buf_77824: 77824, 0, 0, 0, 0, 0, 0 zio_buf_81920: 81920, 0, 0, 0, 0, 0, 0 zio_data_buf_81920: 81920, 0, 0, 0, 0, 0, 0 zio_buf_86016: 86016, 0, 0, 0, 0, 0, 0 zio_data_buf_86016: 86016, 0, 0, 0, 0, 0, 0 zio_buf_90112: 90112, 0, 0, 0, 0, 0, 0 zio_data_buf_90112: 90112, 0, 0, 0, 0, 0, 0 zio_buf_94208: 94208, 0, 0, 0, 0, 0, 0 zio_data_buf_94208: 94208, 0, 0, 0, 0, 0, 0 zio_buf_98304: 98304, 0, 0, 0, 0, 0, 0 zio_data_buf_98304: 98304, 0, 0, 0, 0, 0, 0 zio_buf_102400: 102400, 0, 0, 0, 0, 0, 0 zio_data_buf_102400: 102400, 0, 0, 0, 0, 0, 0 zio_buf_106496: 106496, 0, 0, 0, 0, 0, 0 zio_data_buf_106496: 106496, 0, 0, 0, 0, 0, 0 zio_buf_110592: 110592, 0, 0, 0, 0, 0, 0 zio_data_buf_110592: 110592, 0, 0, 0, 0, 0, 0 zio_buf_114688: 114688, 0, 0, 0, 0, 0, 0 zio_data_buf_114688: 114688, 0, 0, 0, 0, 0, 0 zio_buf_118784: 118784, 0, 0, 0, 0, 0, 0 zio_data_buf_118784: 118784, 0, 0, 0, 0, 0, 0 zio_buf_122880: 122880, 0, 0, 0, 0, 0, 0 zio_data_buf_122880: 122880, 0, 0, 0, 0, 0, 0 zio_buf_126976: 126976, 0, 0, 0, 0, 0, 0 zio_data_buf_126976: 126976, 0, 0, 0, 0, 0, 0 zio_buf_131072: 131072, 0, 0, 0, 0, 0, 0 zio_data_buf_131072: 131072, 0, 0, 0, 0, 0, 0 sa_cache: 80, 0, 9194, 211, 9286, 0, 0 dnode_t: 856, 0, 9829, 335, 11053, 0, 0 dmu_buf_impl_t: 224, 0, 17993, 384, 21797, 0, 0 arc_buf_hdr_t: 216, 0, 11850, 264, 12999, 0, 0 arc_buf_t: 72, 0, 10407, 443, 14007, 0, 0 zil_lwb_cache: 192, 0, 4, 176, 56, 0, 0 zfs_znode_cache: 368, 0, 9194, 226, 9286, 0, 0 Mountpoints: 816, 0, 30, 25, 30, 0, 0 ksiginfo: 112, 0, 313, 842, 3205, 0, 0 itimer: 352, 0, 1, 21, 1, 0, 0 KNOTE: 128, 0, 6, 226, 67, 0, 0 socket: 680, 2071914, 57, 93, 480, 0, 0 unpcb: 240, 2071920, 11, 165, 114, 0, 0 ipq: 56, 129528, 0, 0, 0, 0, 0 udp_inpcb: 392, 2071920, 21, 99, 324, 0, 0 udpcb: 16, 2071944, 21, 1155, 324, 0, 0 tcp_inpcb: 392, 2071920, 24, 96, 36, 0, 0 tcpcb: 1016, 2071916, 24, 44, 36, 0, 0 tcptw: 72, 27800, 0, 100, 2, 0, 0 syncache: 152, 15375, 0, 50, 1, 0, 0 hostcache: 136, 15372, 0, 0, 0, 0, 0 tcpreass: 40, 259056, 0, 0, 0, 0, 0 sackhole: 32, 0, 0, 0, 0, 0, 0 sctp_ep: 1408, 2071914, 0, 0, 0, 0, 0 sctp_asoc: 2344, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80064, 0, 288, 4, 0, 0 sctp_raddr: 728, 80000, 0, 0, 0, 0, 0 sctp_chunk: 136, 400008, 0, 0, 0, 0, 0 sctp_readq: 104, 400032, 0, 0, 0, 0, 0 sctp_stream_msg_out: 104, 400032, 0, 0, 0, 0, 0 sctp_asconf: 40, 400008, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400032, 0, 0, 0, 0, 0 ripcb: 392, 2071920, 0, 0, 0, 0, 0 rtentry: 200, 0, 17, 135, 17, 0, 0 selfd: 56, 0, 83, 484, 5931, 0, 0 SWAPMETA: 288, 8074092, 0, 0, 0, 0, 0 NetGraph items: 72, 4118, 0, 0, 0, 0, 0 NetGraph data items: 72, 522, 0, 0, 0, 0, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq1: atkbd0 2 0 irq6: fdc0 22 0 irq14: ata0 131 0 irq17: uhci0 ehci0 371 1 irq19: uhci1 ahci0+ 35224 136 cpu0:timer 21581 83 irq256: em0 1240 4 cpu7:timer 18860 72 cpu1:timer 17194 66 cpu2:timer 22448 86 cpu3:timer 17242 66 cpu4:timer 21918 84 cpu6:timer 19999 77 cpu5:timer 20715 79 Total 196947 760 ------------------------------------------------------------------------ pstat -T 192/2071909 files 0M/147455M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/gpt/swap0 50331392 0 50331392 0% /dev/gpt/swap1 50331392 0 50331392 0% /dev/gpt/swap2 50331392 0 50331392 0% /dev/gpt/swap3 50331392 0 50331392 0% /dev/gpt/swap4 50331392 0 50331392 0% /dev/gpt/swap5 50331392 0 50331392 0% Total 301988352 0 301988352 0% ------------------------------------------------------------------------ iostat iostat: kvm_read(_tk_nin): invalid address (0x0) iostat: disabling TTY statistics ada0 ada1 ada2 cpu KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 14.49 24 0.33 14.56 23 0.32 14.28 24 0.33 0 10 2 0 88 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME m 65536 5432001 --rw------- pgsql pgsql pgsql pgsql 4 41263104 899 899 8:44:47 8:45:50 8:44:47 m 65537 28975112 --rw-rw-rw- boinc nobody boinc nobody 2 8192 944 1028 8:45:34 8:45:34 8:45:33 m 65538 28975113 --rw-rw-rw- boinc nobody boinc nobody 2 8192 944 1029 8:45:34 8:45:34 8:45:33 m 65539 28975114 --rw-rw-rw- boinc nobody boinc nobody 2 8192 944 1030 8:45:34 8:45:34 8:45:33 m 65540 28975115 --rw-rw-rw- boinc nobody boinc nobody 2 8192 944 1032 8:45:34 8:45:34 8:45:34 Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME s 65536 5432001 --rw------- pgsql pgsql pgsql pgsql 17 8:44:47 8:44:47 s 65537 5432002 --rw------- pgsql pgsql pgsql pgsql 17 8:44:47 8:44:47 s 65538 5432003 --rw------- pgsql pgsql pgsql pgsql 17 8:44:47 8:44:47 s 65539 5432004 --rw------- pgsql pgsql pgsql pgsql 17 8:44:47 8:44:47 s 65540 5432005 --rw------- pgsql pgsql pgsql pgsql 17 8:44:47 8:44:47 s 65541 5432006 --rw------- pgsql pgsql pgsql pgsql 17 8:44:47 8:44:47 s 65542 5432007 --rw------- pgsql pgsql pgsql pgsql 17 8:44:47 8:44:47 ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) shminfo: shmmax: 536870912 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 131072 (max amount of shared memory in pages) seminfo: semmni: 50 (# of semaphore identifiers) semmns: 340 (# of semaphores in system) semmnu: 150 (# of undo structures in system) semmsl: 340 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 50 (max # of undo entries per process) semusz: 632 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat Client Info: Rpc Counts: Getattr Setattr Lookup Readlink Read Write Create Remove 2 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 1 1 0 0 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 0 0 4 Cache Info: Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Misses 0 0 0 0 0 0 0 0 BioRLHits Misses BioD Hits Misses DirE Hits Misses Accs Hits Misses 0 0 0 0 0 0 0 0 Server Info: Getattr Setattr Lookup Readlink Read Write Create Remove 0 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Server Ret-Failed 0 Server Faults 0 Server Cache Stats: Inprog Idem Non-idem Misses 0 0 0 0 Server Write Gathering: WriteOps WriteRPC Opsaved 0 0 0 ------------------------------------------------------------------------ netstat -s tcp: 541 packets sent 224 data packets (18558 bytes) 0 data packets (0 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 308 ack-only packets (123 delayed) 0 URG only packets 0 window probe packets 0 window update packets 9 control packets 541 packets received 208 acks (for 17554 bytes) 3 duplicate acks 0 acks for unsent data 511 packets (432616 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 1 window update packet 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 6 connection requests 1 connection accept 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 7 connections established (including accepts) 12 connections closed (including 0 drops) 0 connections updated cached RTT on close 0 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 208 segments updated rtt (of 178 attempts) 0 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 7 correct ACK header predictions 318 correct data packet header predictions 1 syncache entry added 0 retransmitted 0 dupsyn 0 dropped 1 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 1 cookie sent 0 cookies received 0 hostcache entries added 0 bucket overflow 0 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 0 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 120 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 0 dropped due to no socket 26 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 94 delivered 95 datagrams output 0 times multicast source filter matched ip: 612 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 610 packets for this host 2 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 0 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 585 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 0 calls to icmp_error 0 errors not generated in response to an icmp message 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored 0 message responses generated 0 invalid return addresses 0 no return routes igmp: 2 messages received 0 messages received with too few bytes 0 messages received with wrong TTL 0 messages received with bad checksum 1 V1/V2 membership query received 0 V3 membership queries received 0 membership queries received with invalid field(s) 1 general query received 0 group queries received 0 group-source queries received 0 group-source queries dropped 1 membership report received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 V3 reports received without Router Alert 0 membership reports sent arp: 4 ARP requests sent 3 ARP replies sent 40 ARP requests received 2 ARP replies received 42 ARP packets received 1 total packet dropped due to no ARP entry 0 ARP entrys timed out 0 Duplicate IPs seen ip6: 51 total packets received 0 with size smaller than minimum 0 with data size < data length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 fragments that exceeded limit 0 packets reassembled ok 51 packets for this host 0 packets forwarded 0 packets not forwardable 0 redirects sent 58 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 9 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 packets that violated scope rules 0 multicast packets which we don't join Input histogram: UDP: 51 Mbuf statistics: 27 one mbuf 24 one ext mbuf 0 two or more ext mbuf 0 packets whose headers are not contiguous 0 tunneling packets that can't find gif 0 packets discarded because of too many headers 0 failures of source address selection Source addresses selection rule applied: icmp6: 0 calls to icmp6_error 0 errors not generated in response to an icmp6 message 0 errors not generated because of rate limitation Output histogram: neighbor solicitation: 1 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Histogram of error messages to be generated: 0 no route 0 administratively prohibited 0 beyond scope 0 address unreachable 0 port unreachable 0 packet too big 0 time exceed transit 0 time exceed reassembly 0 erroneous header field 0 unrecognized next header 0 unrecognized option 0 redirect 0 unknown 0 message responses generated 0 messages with too many ND options 0 messages with bad ND options 0 bad neighbor solicitation messages 0 bad neighbor advertisement messages 0 bad router solicitation messages 0 bad router advertisement messages 0 bad redirect messages 0 path MTU changes rip6: 0 messages received 0 checksum calculations on inbound 0 messages with bad checksum 0 messages dropped due to no socket 0 multicast messages dropped due to no socket 0 messages dropped due to full socket buffers 0 delivered 0 datagrams output ------------------------------------------------------------------------ netstat -m 1030/2190/3220 mbufs in use (current/cache/total) 1013/1393/2406/4143818 mbuf clusters in use (current/cache/total/max) 1023/1163 mbuf+clusters out of packet secondary zone in use (current/cache) 0/14/14/2071909 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/1841694 9k jumbo clusters in use (current/cache/total/max) 0/0/0/1381272 16k jumbo clusters in use (current/cache/total/max) 2283K/3389K/5673K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines ------------------------------------------------------------------------ netstat -id Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop em0 1500 00:30:48:f2:29:9c 654 0 0 591 0 0 0 em0 1500 192.168.200.0 borg 588 - - 585 - - - em0 1500 fe80::230:48f fe80::230:48ff:fe 0 - - 4 - - - em1* 1500 00:30:48:f2:29:9d 0 0 0 0 0 0 0 lo0 16384 51 0 0 51 0 0 0 lo0 16384 localhost ::1 51 - - 51 - - - lo0 16384 fe80::1%lo0 fe80::1 0 - - 0 - - - lo0 16384 your-net localhost 0 - - 0 - - - ------------------------------------------------------------------------ netstat -anr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.200.11 UGS 0 560 em0 127.0.0.1 link#3 UH 0 0 lo0 192.168.200.0/24 link#1 U 0 25 em0 192.168.200.4 link#1 UHS 0 0 lo0 Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 ::1 link#3 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 fe80::/10 ::1 UGRS lo0 fe80::%em0/64 link#1 U em0 fe80::230:48ff:fef2:299c%em0 link#1 UHS lo0 fe80::%lo0/64 link#3 U lo0 fe80::1%lo0 link#3 UHS lo0 ff01::%em0/32 fe80::230:48ff:fef2:299c%em0 U em0 ff01::%lo0/32 ::1 U lo0 ff02::/16 ::1 UGRS lo0 ff02::%em0/32 fe80::230:48ff:fef2:299c%em0 U em0 ff02::%lo0/32 ::1 U lo0 ------------------------------------------------------------------------ netstat -anA Active Internet connections (including servers) Tcpcb Proto Recv-Q Send-Q Local Address Foreign Address (state) fffffe01c28423f8 tcp4 0 1008 192.168.200.4.22 192.147.25.65.4400 ESTABLISHED fffffe01038a5000 tcp4 0 0 192.168.200.4.1391 198.20.8.246.80 CLOSE_WAIT fffffe01c2272be8 tcp4 0 0 127.0.0.1.31416 *.* LISTEN fffffe01d5855be8 tcp4 0 0 192.168.200.4.1551 192.147.25.65.22 ESTABLISHED fffffe01c28427f0 tcp4 0 0 *.9101 *.* LISTEN fffffe010370f7f0 tcp4 0 0 *.22 *.* LISTEN fffffe010370fbe8 tcp6 0 0 *.22 *.* LISTEN fffffe010381dbe8 tcp4 0 0 *.9102 *.* LISTEN fffffe01c2273000 tcp4 0 0 *.9103 *.* LISTEN fffffe0103a3bbe8 tcp4 0 0 *.631 *.* LISTEN fffffe0103a3c000 tcp6 0 0 *.631 *.* LISTEN fffffe010381a000 tcp4 0 0 127.0.0.1.587 *.* LISTEN fffffe010381a3f8 tcp4 0 0 127.0.0.1.25 *.* LISTEN fffffe010381a7f0 tcp4 0 0 192.168.200.4.587 *.* LISTEN fffffe010381abe8 tcp4 0 0 192.168.200.4.25 *.* LISTEN fffffe010370e7f0 tcp4 0 0 127.0.0.1.5432 *.* LISTEN fffffe010370e000 tcp6 0 0 ::1.5432 *.* LISTEN fffffe01038a7000 tcp6 0 0 *.2049 *.* LISTEN fffffe01038a73f8 tcp4 0 0 *.2049 *.* LISTEN fffffe010381b000 tcp4 0 0 *.843 *.* LISTEN fffffe010381b3f8 tcp6 0 0 *.843 *.* LISTEN fffffe010381d3f8 tcp4 0 0 *.111 *.* LISTEN fffffe010381d7f0 tcp6 0 0 *.111 *.* LISTEN fffffe010370e3f8 tcp4 0 0 192.168.200.4.952 192.168.200.23.204 ESTABLISHED fffffe010313bdc8 udp4 0 0 *.69 *.* fffffe0103106930 udp4 0 0 *.631 *.* fffffe0103131ab8 udp6 0 0 ::1.47400 ::1.47400 fffffe0103199930 udp4 0 0 127.0.0.1.123 *.* fffffe010319a188 udp6 0 0 fe80:3::1.123 *.* fffffe010319a620 udp6 0 0 ::1.123 *.* fffffe010319a310 udp6 0 0 fe80:1::230:48ff.1 *.* fffffe010319a000 udp4 0 0 192.168.200.4.123 *.* fffffe0103199dc8 udp6 0 0 *.123 *.* fffffe0103199ab8 udp4 0 0 *.123 *.* fffffe0103199000 udp6 0 0 *.2049 *.* fffffe0103199498 udp4 0 0 *.2049 *.* fffffe0103197930 udp4 0 0 *.843 *.* fffffe0103197620 udp6 0 0 *.843 *.* fffffe0103199c40 udp6 0 0 *.* *.* fffffe010314cab8 udp4 0 0 *.1009 *.* fffffe010314c7a8 udp4 0 0 *.111 *.* fffffe010314c498 udp6 0 0 *.998 *.* fffffe010314c188 udp6 0 0 *.111 *.* fffffe0103197310 udp4 0 0 *.514 *.* fffffe0103197498 udp6 0 0 *.514 *.* Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr fffffe0103a5b870 stream 0 0 fffffe01c22c71d8 0 0 0 /var/run/cups.sock fffffe010349ed20 stream 0 0 fffffe0103e66588 0 0 0 /tmp/.s.PGSQL.5432 fffffe01034a60f0 stream 0 0 fffffe0103457938 0 0 0 /var/run/rpcbind.sock fffffe01034a63c0 stream 0 0 fffffe01034981d8 0 0 0 /var/run/devd.pipe fffffe0103a5b780 dgram 0 0 0 fffffe0103517b40 0 fffffe010349b0f0 fffffe01035174b0 dgram 0 0 0 fffffe0103517c30 0 fffffe010349dc30 fffffe010349dc30 dgram 0 0 0 fffffe0103517c30 0 fffffe0103a5b960 fffffe0103a5b960 dgram 0 0 0 fffffe0103517c30 0 0 fffffe010349b0f0 dgram 0 0 0 fffffe0103517b40 0 0 fffffe0103517b40 dgram 0 0 fffffe01037f1000 0 fffffe0103a5b780 0 /var/run/logpriv fffffe0103517c30 dgram 0 0 fffffe00c0b14ce8 0 fffffe01035174b0 0 /var/run/log ------------------------------------------------------------------------ netstat -aL Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address tcp4 0/0/128 localhost.31416 tcp4 0/0/50 *.bacula-dir tcp4 0/0/128 *.ssh tcp6 0/0/128 *.ssh tcp4 0/0/50 *.bacula-fd tcp4 0/0/50 *.bacula-sd tcp4 0/0/128 *.ipp tcp6 0/0/128 *.ipp tcp4 0/0/20 localhost.submission tcp4 0/0/20 localhost.smtp tcp4 0/0/20 borg.submission tcp4 0/0/20 borg.smtp tcp4 0/0/128 localhost.postgresql tcp6 0/0/128 localhost.postgresql tcp6 0/0/5 *.nfsd tcp4 0/0/5 *.nfsd tcp4 0/0/128 *.843 tcp6 0/0/128 *.843 tcp4 0/0/128 *.sunrpc tcp6 0/0/128 *.sunrpc unix 0/0/128 /var/run/cups.sock unix 0/0/128 /tmp/.s.PGSQL.5432 unix 0/0/128 /var/run/rpcbind.sock unix 0/0/4 /var/run/devd.pipe ------------------------------------------------------------------------ fstat fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read file 13 at 0xfffffffffffffff fstat: can't read file 14 at 0x78 fstat: can't read file 16 at 0xffff fstat: can't read file 19 at 0xfffffffffffffff fstat: can't read file 20 at 0x78 fstat: can't read file 22 at 0xffff fstat: can't read file 23 at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read file 7 at 0xfffffffffffffff fstat: can't read file 8 at 0x78 fstat: can't read file 10 at 0xffff fstat: can't read file 13 at 0xfffffffffffffff fstat: can't read file 14 at 0x78 fstat: can't read file 16 at 0xffff fstat: can't read file 19 at 0xfffffffffffffff fstat: can't read file 20 at 0x78 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0xfffffffffffffff fstat: can't read file 2 at 0x78 fstat: can't read file 4 at 0xffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root zfs 1044 root - - error - root zfs 1044 wd - - error - root zfs 1044 text - - error - root zfs 1044 0* pipe fffffe00c0d6f000 <-> fffffe00c0d6f160 65224 rw root zfs 1044 6* pipe fffffe00c0d97730 <-> fffffe00c0d975d0 0 rw root csh 1042 root - - error - root csh 1042 wd - - error - root csh 1042 text - - error - root sshd 1040 root - - error - root sshd 1040 wd - - error - root sshd 1040 text - - error - root sshd 1040 0 /dev 28 crw-rw-rw- null rw root sshd 1040 6 /dev 28 crw-rw-rw- null rw boinc wcg_hpf2_rosetta_6 1038 root - - error - boinc wcg_hpf2_rosetta_6 1038 wd - - error - boinc wcg_hpf2_rosetta_6 1038 text - - error - boinc wcg_hpf2_rosetta_6 1038 0 /dev 28 crw-rw-rw- null rw boinc wcg_hpf2_rosetta_6 1038 6 - - error - boinc wcg_hpf2_rosetta_6 1037 root - - error - boinc wcg_hpf2_rosetta_6 1037 wd - - error - boinc wcg_hpf2_rosetta_6 1037 text - - error - boinc wcg_hpf2_rosetta_6 1037 0 /dev 28 crw-rw-rw- null rw boinc wcg_hpf2_rosetta_6 1037 6 - - error - boinc wcg_hpf2_rosetta_6 1036 root - - error - boinc wcg_hpf2_rosetta_6 1036 wd - - error - boinc wcg_hpf2_rosetta_6 1036 text - - error - boinc wcg_hpf2_rosetta_6 1036 0 /dev 28 crw-rw-rw- null rw boinc wcg_hpf2_rosetta_6 1036 6 - - error - boinc wcg_hpf2_rosetta_6 1035 root - - error - boinc wcg_hpf2_rosetta_6 1035 wd - - error - boinc wcg_hpf2_rosetta_6 1035 text - - error - boinc wcg_hpf2_rosetta_6 1035 0 /dev 28 crw-rw-rw- null rw boinc wcg_hpf2_rosetta_6 1035 6 - - error - boinc wcgrid_cep2_6.40_i 1034 root - - error - boinc wcgrid_cep2_6.40_i 1034 wd - - error - boinc wcgrid_cep2_6.40_i 1034 text - - error - boinc wcgrid_cep2_6.40_i 1034 0 /dev 28 crw-rw-rw- null rw boinc wcgrid_cep2_6.40_i 1034 6 - - error - boinc wcgrid_cep2_6.40_i 1033 root - - error - boinc wcgrid_cep2_6.40_i 1033 wd - - error - boinc wcgrid_cep2_6.40_i 1033 text - - error - boinc wcgrid_cep2_6.40_i 1033 0 /dev 28 crw-rw-rw- null rw boinc wcgrid_cep2_6.40_i 1033 6 - - error - boinc setiathome-6.12.am 1032 root - - error - boinc setiathome-6.12.am 1032 wd - - error - boinc setiathome-6.12.am 1032 text - - error - boinc setiathome-6.12.am 1032 0 /dev 28 crw-rw-rw- null rw boinc setiathome-6.12.am 1032 6 /dev 28 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1031 root - - error - boinc wcgrid_faah_7.15_i 1031 wd - - error - boinc wcgrid_faah_7.15_i 1031 text - - error - boinc wcgrid_faah_7.15_i 1031 0 /dev 28 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1031 6 /dev 28 crw-rw-rw- null rw boinc setiathome-6.12.am 1030 root - - error - boinc setiathome-6.12.am 1030 wd - - error - boinc setiathome-6.12.am 1030 text - - error - boinc setiathome-6.12.am 1030 0 /dev 28 crw-rw-rw- null rw boinc setiathome-6.12.am 1030 6 /dev 28 crw-rw-rw- null rw boinc setiathome-6.12.am 1029 root - - error - boinc setiathome-6.12.am 1029 wd - - error - boinc setiathome-6.12.am 1029 text - - error - boinc setiathome-6.12.am 1029 0 /dev 28 crw-rw-rw- null rw boinc setiathome-6.12.am 1029 6 /dev 28 crw-rw-rw- null rw boinc setiathome-6.12.am 1028 root - - error - boinc setiathome-6.12.am 1028 wd - - error - boinc setiathome-6.12.am 1028 text - - error - boinc setiathome-6.12.am 1028 0 /dev 28 crw-rw-rw- null rw boinc setiathome-6.12.am 1028 6 /dev 28 crw-rw-rw- null rw boinc wcgrid_cep2_6.40_i 1027 root - - error - boinc wcgrid_cep2_6.40_i 1027 wd - - error - boinc wcgrid_cep2_6.40_i 1027 text - - error - boinc wcgrid_cep2_6.40_i 1027 0 /dev 28 crw-rw-rw- null rw boinc wcgrid_cep2_6.40_i 1027 6 - - error - boinc wcgrid_faah_7.15_i 1026 root - - error - boinc wcgrid_faah_7.15_i 1026 wd - - error - boinc wcgrid_faah_7.15_i 1026 text - - error - boinc wcgrid_faah_7.15_i 1026 0 /dev 28 crw-rw-rw- null rw boinc wcgrid_faah_7.15_i 1026 6 /dev 28 crw-rw-rw- null rw boinc wcg_hpf2_rosetta_6 1025 root - - error - boinc wcg_hpf2_rosetta_6 1025 wd - - error - boinc wcg_hpf2_rosetta_6 1025 text - - error - boinc wcg_hpf2_rosetta_6 1025 0 /dev 28 crw-rw-rw- null rw boinc wcg_hpf2_rosetta_6 1025 6 - - error - boinc wcg_hpf2_rosetta_6 1024 root - - error - boinc wcg_hpf2_rosetta_6 1024 wd - - error - boinc wcg_hpf2_rosetta_6 1024 text - - error - boinc wcg_hpf2_rosetta_6 1024 0 /dev 28 crw-rw-rw- null rw boinc wcg_hpf2_rosetta_6 1024 6 - - error - root ssh 1022 root - - error - root ssh 1022 wd - - error - root ssh 1022 text - - error - root ssh 1022 ctty /dev 71 crw------- ttyv0 rw root ssh 1022 0 /dev 71 crw------- ttyv0 rw root ssh 1022 6 /dev 71 crw------- ttyv0 rw root sh 1020 root - - error - root sh 1020 wd - - error - root sh 1020 text - - error - root sh 1020 ctty /dev 71 crw------- ttyv0 rw root sh 1020 0 /dev 71 crw------- ttyv0 rw root sh 1020 6 /dev 71 crw------- ttyv0 rw root getty 1017 root - - error - root getty 1017 wd - - error - root getty 1017 text - - error - root getty 1017 ctty /dev 78 crw------- ttyv7 rw root getty 1017 0 /dev 78 crw------- ttyv7 rw root getty 1016 root - - error - root getty 1016 wd - - error - root getty 1016 text - - error - root getty 1016 ctty /dev 77 crw------- ttyv6 rw root getty 1016 0 /dev 77 crw------- ttyv6 rw root getty 1015 root - - error - root getty 1015 wd - - error - root getty 1015 text - - error - root getty 1015 ctty /dev 76 crw------- ttyv5 rw root getty 1015 0 /dev 76 crw------- ttyv5 rw root getty 1014 root - - error - root getty 1014 wd - - error - root getty 1014 text - - error - root getty 1014 ctty /dev 75 crw------- ttyv4 rw root getty 1014 0 /dev 75 crw------- ttyv4 rw root getty 1013 root - - error - root getty 1013 wd - - error - root getty 1013 text - - error - root getty 1013 ctty /dev 74 crw------- ttyv3 rw root getty 1013 0 /dev 74 crw------- ttyv3 rw root getty 1012 root - - error - root getty 1012 wd - - error - root getty 1012 text - - error - root getty 1012 ctty /dev 73 crw------- ttyv2 rw root getty 1012 0 /dev 73 crw------- ttyv2 rw root getty 1011 root - - error - root getty 1011 wd - - error - root getty 1011 text - - error - root getty 1011 ctty /dev 72 crw------- ttyv1 rw root getty 1011 0 /dev 72 crw------- ttyv1 rw root login 1010 root - - error - root login 1010 wd - - error - root login 1010 text - - error - root login 1010 ctty /dev 71 crw------- ttyv0 rw root login 1010 0 /dev 71 crw------- ttyv0 rw root inetd 990 root - - error - root inetd 990 wd - - error - root inetd 990 text - - error - root inetd 990 0 /dev 28 crw-rw-rw- null rw root inetd 990 6 /dev 28 crw-rw-rw- null rw root cron 969 root - - error - root cron 969 wd - - error - root cron 969 text - - error - root cron 969 0 /dev 28 crw-rw-rw- null rw root sshd 959 root - - error - root sshd 959 wd - - error - root sshd 959 text - - error - root sshd 959 0 /dev 28 crw-rw-rw- null rw bacula bacula-dir 954 root - - error - bacula bacula-dir 954 wd - - error - bacula bacula-dir 954 text - - error - bacula bacula-dir 954 0 /dev 28 crw-rw-rw- null r root bacula-fd 951 root - - error - root bacula-fd 951 wd - - error - root bacula-fd 951 text - - error - root bacula-fd 951 0 /dev 28 crw-rw-rw- null r bacula bacula-sd 948 root - - error - bacula bacula-sd 948 wd - - error - bacula bacula-sd 948 text - - error - bacula bacula-sd 948 0 /dev 28 crw-rw-rw- null r boinc boinc_client 944 root - - error - boinc boinc_client 944 wd - - error - boinc boinc_client 944 text - - error - boinc boinc_client 944 0 /dev 28 crw-rw-rw- null rw boinc boinc_client 944 6 - - error - root cupsd 938 root - - error - root cupsd 938 wd - - error - root cupsd 938 text - - error - root cupsd 938 0 /dev 28 crw-rw-rw- null r root cupsd 938 6 /dev 28 crw-rw-rw- null w root cupsd 938 12 /dev 28 crw-rw-rw- null w mailnull exim-4.80.1-2 928 root - - error - mailnull exim-4.80.1-2 928 wd - - error - mailnull exim-4.80.1-2 928 text - - error - mailnull exim-4.80.1-2 928 0 /dev 28 crw-rw-rw- null rw mailnull exim-4.80.1-2 928 6 /dev 28 crw-rw-rw- null rw pgsql postgres 906 root - - error - pgsql postgres 906 wd - - error - pgsql postgres 906 text - - error - pgsql postgres 906 0 /dev 28 crw-rw-rw- null r pgsql postgres 906 6 - - error - pgsql postgres 905 root - - error - pgsql postgres 905 wd - - error - pgsql postgres 905 text - - error - pgsql postgres 905 0 /dev 28 crw-rw-rw- null r pgsql postgres 905 6 - - error - pgsql postgres 904 root - - error - pgsql postgres 904 wd - - error - pgsql postgres 904 text - - error - pgsql postgres 904 0 /dev 28 crw-rw-rw- null r pgsql postgres 904 6 - - error - pgsql postgres 903 root - - error - pgsql postgres 903 wd - - error - pgsql postgres 903 text - - error - pgsql postgres 903 0 /dev 28 crw-rw-rw- null r pgsql postgres 903 6 - - error - pgsql postgres 899 root - - error - pgsql postgres 899 wd - - error - pgsql postgres 899 text - - error - pgsql postgres 899 0 /dev 28 crw-rw-rw- null r pgsql postgres 899 6 - - error - root smartd 890 root - - error - root smartd 890 wd - - error - root smartd 890 text - - error - root smartd 890 0 /dev 28 crw-rw-rw- null rw root perl 886 root - - error - root perl 886 wd - - error - root perl 886 text - - error - root perl 886 0 - - error - root ng_queue 874 root - - error - root ng_queue 874 wd - - error - root ntpd 853 root - - error - root ntpd 853 wd - - error - root ntpd 853 text - - error - root ntpd 853 0 /dev 28 crw-rw-rw- null rw root ntpd 853 6 /dev 28 crw-rw-rw- null rw root ntpd 853 12 /dev 28 crw-rw-rw- null rw root ntpd 853 18* local dgram fffffe010349b0f0 <-> fffffe0103517b40 root nfsd 817 root - - error - root nfsd 817 wd - - error - root nfsd 817 text - - error - root nfsd 817 0 /dev 28 crw-rw-rw- null rw root nfsd 815 root - - error - root nfsd 815 wd - - error - root nfsd 815 text - - error - root nfsd 815 0 /dev 28 crw-rw-rw- null rw root nfsd 815 6 /dev 28 crw-rw-rw- null rw root mountd 809 root - - error - root mountd 809 wd - - error - root mountd 809 text - - error - root mountd 809 0 /dev 28 crw-rw-rw- null rw root mountd 809 6 /dev 28 crw-rw-rw- null rw root rpcbind 774 root - - error - root rpcbind 774 wd - - error - root rpcbind 774 text - - error - root rpcbind 774 0 /dev 28 crw-rw-rw- null rw root rpcbind 774 6 /dev 28 crw-rw-rw- null rw root watchdogd 760 root - - error - root watchdogd 760 wd - - error - root watchdogd 760 text - - error - root watchdogd 760 0 /dev 28 crw-rw-rw- null rw root syslogd 757 root - - error - root syslogd 757 wd - - error - root syslogd 757 text - - error - root syslogd 757 0 /dev 28 crw-rw-rw- null rw root syslogd 757 6 /dev 28 crw-rw-rw- null rw root syslogd 757 12 /dev 28 crw-rw-rw- null rw root syslogd 757 18 - - error - root devd 632 root - - error - root devd 632 wd - - error - root devd 632 text - - error - root devd 632 0 /dev 28 crw-rw-rw- null rw root init 1 root - - error - root init 1 wd - - error - root init 1 text - - error - root kernel 0 root - - error - root kernel 0 wd - - error - ------------------------------------------------------------------------ dmesg Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #129 r248695: Mon Mar 25 05:03:32 CDT 2013 root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG-DTRACE amd64 FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (2327.54-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 0x6 Model = 0x17 Stepping = 6 Features=0xbfebfbff Features2=0xce3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 68719476736 (65536 MB) avail memory = 63193878528 (60266 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 netmap: loaded module cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) unknown: I/O range not supported cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 350 Event timer "HPET1" frequency 14318180 Hz quality 340 Event timer "HPET2" frequency 14318180 Hz quality 340 atrtc0: port 0x70-0x71 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 pcib5: at device 0.2 on pci3 pci5: on pcib5 pcib6: irq 18 at device 2.0 on pci2 pci6: on pcib6 em0: port 0x2000-0x201f mem 0xd8020000-0xd803ffff,0xd8000000-0xd801ffff irq 18 at device 0.0 on pci6 em0: Using an MSI interrupt em0: Ethernet address: 00:30:48:f2:29:9c 001.000008 netmap_attach [1680] success for em0 em1: port 0x2020-0x203f mem 0xd8060000-0xd807ffff,0xd8040000-0xd805ffff irq 19 at device 0.1 on pci6 em1: Using an MSI interrupt em1: Ethernet address: 00:30:48:f2:29:9d 001.000009 netmap_attach [1680] success for em1 pcib7: at device 0.3 on pci1 pci7: on pcib7 pcib8: at device 4.0 on pci0 pci8: on pcib8 pcib9: at device 6.0 on pci0 pci9: on pcib9 pci0: at device 8.0 (no driver attached) pcib10: irq 17 at device 28.0 on pci0 pci10: on pcib10 uhci0: port 0x1800-0x181f irq 17 at device 29.0 on pci0 usbus0 on uhci0 uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 usbus1 on uhci1 uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 usbus2 on uhci2 ehci0: mem 0xd8500400-0xd85007ff irq 17 at device 29.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib11: at device 30.0 on pci0 pci11: on pcib11 vgapci0: port 0x3000-0x30ff mem 0xd0000000-0xd7ffffff,0xd8200000-0xd820ffff irq 18 at device 1.0 on pci11 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: at channel 0 on atapci0 ahci0: port 0x18a0-0x18a7,0x1874-0x1877,0x1878-0x187f,0x1870-0x1873,0x1880-0x189f mem 0xd8500800-0xd8500bff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ichsmb0: port 0x1100-0x111f irq 19 at device 31.3 on pci0 smbus0: on ichsmb0 acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ichwd0 on isa0 orm0: at iomem 0xc0000-0xcafff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 coretemp4: on cpu4 est4: on cpu4 p4tcc4: on cpu4 coretemp5: on cpu5 est5: on cpu5 p4tcc5: on cpu5 coretemp6: on cpu6 est6: on cpu6 p4tcc6: on cpu6 coretemp7: on cpu7 est7: on cpu7 p4tcc7: on cpu7 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x40c offMax=0x58d usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: at usbus0 uhub1: on usbus0 ugen3.1: at usbus3 uhub2: on usbus3 ugen2.1: at usbus2 uhub3: on usbus2 ata0: DMA limited to UDMA33, controller found non-ATA66 cable ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus2 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 ada2 at ahcich2 bus 0 scbus3 target 0 lun 0 ada2: ATA-8 SATA 3.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad8 ada3 at ahcich3 bus 0 scbus4 target 0 lun 0 ada3: ATA-8 SATA 3.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3: Previously was known as ad10 ada4 at ahcich4 bus 0 scbus5 target 0 lun 0 ada4: ATA-8 SATA 3.x device ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada4: Previously was known as ad12 ada5 at ahcich5 bus 0 scbus6 target 0 lun 0 ada5: ATA-8 SATA 3.x device ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada5: Previously was known as ad14 cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #7 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #5 Launched! uhub1: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered Root mount waiting for: usbus3 uhub2: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 ugen3.2: at usbus3 ukbd0: on usbus3 kbd2 at ukbd0 Trying to mount root from zfs:zroot/ROOT/default []... ffclock reset: HPET (14318180 Hz), time = 1364219053.500000000 Setting hostuuid: 53d19f64-d663-a017-8922-0030488e9ff3. Setting hostid: 0xf53a926e. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: Mounting local file systems:. Writing entropy file:. Setting hostname: borg.lerctr.org. Starting Network: lo0 em0 em1. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 em0: flags=8843 metric 0 mtu 1500 options=4219b ether 00:30:48:f2:29:9c inet 192.168.200.4 netmask 0xffffff00 broadcast 192.168.200.255 inet6 fe80::230:48ff:fef2:299c%em0 prefixlen 64 scopeid 0x1 nd6 options=29 media: Ethernet autoselect status: no carrier em1: flags=8c02 metric 0 mtu 1500 options=4219b ether 00:30:48:f2:29:9d nd6 options=29 media: Ethernet autoselect status: no carrier Starting devd. Starting Network: em1. em1: flags=8c02 metric 0 mtu 1500 options=4219b ether 00:30:48:f2:29:9d nd6 options=29 media: Ethernet autoselect status: no carrier uhid0: on usbus3 add net default: gateway 192.168.200.11 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net fe80::: gateway ::1 add net ff02::: gateway ::1 Mounting NFS file systems:. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/kde4/lib /usr/local/lib/compat /usr/local/lib/dbmail /usr/local/lib/event2 /usr/local/lib/pth /usr/local/lib/qt4 /usr/local/lib/virtualbox 32-bit compatibility ldconfig path: /usr/lib32 /usr/local/lib32/compat Creating and/or trimming log files. Starting syslogd. Starting watchdogd. No core dumps found. Additional ABI support: linux. Starting rpcbind. NFS access cache time=60 Clearing /tmp (X related). Starting mountd. NFSv4 is disabled Starting nfsd. Updating motd:. Starting ntpd. Starting sshblock. Starting smartd. Updating cpucodes... /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl0 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl1 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl2 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl3 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl4 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl5 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl6 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl7 from rev 0x60c to rev 0x60f... done. Done. Starting exim. Starting cupsd. Starting boinc_client. Starting bacula_sd. Starting bacula_fd. Starting bacula_dir. Performing sanity check on sshd configuration. Starting sshd. Configuring syscons: blanktime. Starting cron. Starting inetd. Starting background file system checks in 60 seconds. Mon Mar 25 08:44:56 CDT 2013 Mar 25 08:45:03 borg login: ROOT LOGIN (root) ON ttyv0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x378 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80531426 stack pointer = 0x28:0xffffff91579193d0 frame pointer = 0x28:0xffffff9157919470 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 = 1044 (zfs) trap number = 12 panic: page fault cpuid = 0 Uptime: 2m10s Dumping 4913 out of 64747 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% ------------------------------------------------------------------------ kernel config options CONFIG_AUTOGENERATED ident BORG-DTRACE machine amd64 cpu HAMMER makeoptions WITH_CTF=1 makeoptions DEBUG=-g options FFCLOCK options USB_DEBUG options RDRAND_RNG options PADLOCK_RNG options ATH_ENABLE_11N options AH_AR5416_INTERRUPT_MITIGATION options AH_SUPPORT_AR5416 options IEEE80211_SUPPORT_MESH options IEEE80211_AMPDU_AGE options IEEE80211_DEBUG options SC_PIXEL_MODE options VESA options CTL_DISABLE options AHD_REG_PRETTY_PRINT options AHC_REG_PRETTY_PRINT options ATA_STATIC_ID options ATA_CAM options SMP options MALLOC_DEBUG_MAXZONES=8 options INCLUDE_CONFIG_FILE options DDB_CTF options KDTRACE_HOOKS options KDTRACE_FRAME options MAC options CAPABILITIES options CAPABILITY_MODE options AUDIT options HWPMC_HOOKS options KBD_INSTALL_CDEV options PRINTF_BUFR_SIZE=128 options _KPOSIX_PRIORITY_SCHEDULING options SYSVSEM options SYSVMSG options SYSVSHM options STACK options KTRACE options SCSI_DELAY=5000 options COMPAT_FREEBSD7 options COMPAT_FREEBSD6 options COMPAT_FREEBSD5 options COMPAT_FREEBSD4 options COMPAT_FREEBSD32 options GEOM_LABEL options GEOM_RAID options GEOM_PART_GPT options PSEUDOFS options PROCFS options CD9660 options MSDOSFS options NFS_ROOT options NFSLOCKD options NFSD options NFSCL options QUOTA options SCTP options TCP_OFFLOAD options INET6 options INET options PREEMPTION options SCHED_ULE options NEW_PCIB options GEOM_PART_MBR options GEOM_PART_EBR_COMPAT options GEOM_PART_EBR options GEOM_PART_BSD device isa device mem device io device uart_ns8250 device cpufreq device acpi device pci device fdc device ahci device ata device esp device isci device scbus device ch device da device sa device cd device pass device ses device ctl device atkbdc device atkbd device psm device kbdmux device vga device splash device sc device agp device uart device ppc device ppbus device lpt device ppi device em device miibus device cas device gem device hme device nfe device nge device loop device random device ether device vlan device tun device md device gif device faith device firmware device bpf device uhci device ohci device ehci device xhci device usb device ukbd device umass device virtio device virtio_pci device vtnet device virtio_blk device virtio_scsi device virtio_balloon device netmap ------------------------------------------------------------------------ ddb capture buffer ddb: ddb_capture: kvm_nlist -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Mon Mar 25 14:14:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 125BCFD2 for ; Mon, 25 Mar 2013 14:14:26 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id CE59F192 for ; Mon, 25 Mar 2013 14:14:25 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAGFbUFGDaFvO/2dsb2JhbABEiEW9GYIVdIIkAQEBAwEBAQEgBCcgCwUWDgoCAg0ZAikBCSYGCAcEARwEh20GDLA1kiCBI4w1EHw0B4ItgRMDlCmCPoEfj2WDJiAygQU1 X-IronPort-AV: E=Sophos;i="4.84,905,1355115600"; d="scan'208";a="20638042" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 25 Mar 2013 10:13:54 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 9BB20B3F12; Mon, 25 Mar 2013 10:13:54 -0400 (EDT) Date: Mon, 25 Mar 2013 10:13:54 -0400 (EDT) From: Rick Macklem To: Andrey Simonenko Message-ID: <1394893012.119341.1364220834625.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20130325133424.GA1342@pm513-1.comsys.ntu-kpi.kiev.ua> Subject: Re: Possible bug in NFSv4 with krb5p security? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org, Elias Martenson , Benjamin Kaduk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 14:14:26 -0000 Andrey Simonenko wrote: > On Wed, Feb 20, 2013 at 06:29:07PM -0500, Rick Macklem wrote: > > Andrey Simonnenko wrote: > > > > > > Another variant. This is a program that can be used for verifying > > > correctness of the function, just change PWBUF_SIZE_* values and > > > put > > > some printfs to see when buffer is reallocated. sizehint is > > > updated > > > only when malloc() succeeded. > > > > > > --------------------------------- > > > static int > > > getpwnam_r_func(const char *name, uid_t *uidp) > > > { > > > #define PWBUF_SIZE_INI (2 * MAXLOGNAME + MAXPATHLEN + > > > _PASSWORD_LEN) > > > #define PWBUF_SIZE_INC 128 > > > > > > static size_t sizehint = PWBUF_SIZE_INI; > > > > > > struct passwd pwd; > > > struct passwd *pw; > > > char *buf; > > > size_t size; > > > int error; > > > char lname[MAXLOGNAME]; > > > char bufs[PWBUF_SIZE_INI]; > > > > > > strncpy(lname, name, sizeof(lname)); > > > > > > buf = bufs; > > > size = sizeof(bufs); > > > for (;;) { > > > error = getpwnam_r(lname, &pwd, buf, size, &pw); > > > if (buf != bufs) > > > free(buf); > > > if (pw != NULL) { > > > *uidp = pw->pw_uid; > > > return (GSS_S_COMPLETE); > > > } else if (error != ERANGE || size > SIZE_MAX - PWBUF_SIZE_INC) > > > return (GSS_S_FAILURE); > > > if (size != sizehint) > > > size = sizehint; > > > else > > > size += PWBUF_SIZE_INC; > > > buf = malloc(size); > > > if (buf == NULL) > > > return (GSS_S_FAILURE); > > > sizehint = size; > > > } > > > } > > > > > All looks fine to me. (Before my mailer messed with the > > whitespace;-) > > > > Thanks, rick > > ps: I will commit it in April, unless someone else does so sooner. > > I was thinking about this approach once again and made a conclusion > that > it is wrong. Using static buffer at first and then allocate memory for > next calls can cause slowdown, depends on number of entries and used > database backend of course. The libc code for getpwnam() allocates > memory for the buffer and does not free it on exit from the function, > Not sure what you were saying by the last sentence? Using a static buffer here would make the code unsafe for multiple threads. Although the gssd is currently single threaded, that might change someday, maybe? (Using the static as a "hint" should be safe for multiple threads, since it is just a hint.) > If the above written code or any of its modification is going to be > committed to the source base (by you or by some another committer), > then I ask and require to not write/mention my name and email address > neither in source file nor in commit log message. > Ok, that's your choice. I think the code is fine, since the likelyhood of the first getpwuid_r() with the buffer on the stack failing is nearly 0, given that it is much bigger than 128. (Although I think a loop on ERANGE should be in the code, just making the buffer a lot bigger than 128 will fix the problem for 99.99999% of the cases.) The only change I was planning to the above was moving the free(buf) down until after "pwd" has been used, so it is safe for fields like pw_name, which I think will live in "buf". That way the code won't be broken if/when someone uses it for pw_name. rick > Appropriate commit log message for the above written code can be the > following: > > -------------------------------------------------------------------------- > Since FreeBSD does not support sysconf(_SC_GETPW_R_SIZE_MAX), then > allocate > a buffer of sufficient size for getpwnam_r() as it is suggested in > EXAMPLES > of SUSv4 documentation for the getpwnam_r() function. > -------------------------------------------------------------------------- > > since this documentation has similar code. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Mar 25 14:25:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6E5CD38A; Mon, 25 Mar 2013 14:25:09 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id 367A3231; Mon, 25 Mar 2013 14:25:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=yfT+UgEwocTvMBSnsee1ahZv7D5ocTOzdpkonWtbhjA=; b=uYTrhqc33JJ9vi58GLOKHJaWcHlACEwx9m9L/CjdGXrb5wOQIaj9WQBwVk1SIN8heON7vCKZ4rpnlZ9t6qA0uI3DG2JzhtCidyPe4I65TDuAoVCo9Gvtb7EI8xULQSbVsSwMRNchWDKygbAIK3UpQrRGUhV4XtSMpoXypCCZzRk=; Received: from [122.129.203.50] (port=62938 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UK8Kc-002jjY-8c; Mon, 25 Mar 2013 08:25:02 -0600 Date: Mon, 25 Mar 2013 21:24:58 +0700 From: Erich Dollansky To: Daniel Eischen Subject: Re: X220 loses keyboard when Logitech USB wireless adaptor is unplugged Message-ID: <20130325212458.15241453@X220.ovitrap.com> In-Reply-To: References: <20130325192105.4e94db17@X220.ovitrap.com> <20130325195949.228c2dea@X220.ovitrap.com> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 14:25:09 -0000 Hi, On Mon, 25 Mar 2013 09:07:14 -0400 (EDT) Daniel Eischen wrote: > On Mon, 25 Mar 2013, Erich Dollansky wrote: > > > Hi, > > > > On Mon, 25 Mar 2013 19:21:05 +0700 > > Erich Dollansky wrote: > > > >> As you can see, I took the adaptor connected to ugne0.3 out. In > >> addition, the keyboard ukbd0 was disconnected too. When I put the > >> adaptor back in, the keyboard comes back too. As you can imagine, > >> it is a bit hard to unplug the built-in keyboard on a notebook. > >> > > the situation changes when I do not use X and KMS. I can do with the > > Logitech adaptor what I want but the keyboard stays connected. The > > moment I start X, it is back to the behaviour from above. > > Can you use, or are you using, moused? Tell X to use sysmouse. > > Section "InputDevice" > Identifier "Mouse0" > Driver "mouse" > Option "Protocol" "auto" > Option "Device" "/dev/sysmouse" > Option "ZAxisMapping" "4 5 6 7" > EndSection > I did this and do not see a difference. The log file says: Mar 25 21:17:09 X220 kernel: ugen1.2: at usbus1 (disconnected) Mar 25 21:17:09 X220 kernel: ukbd0: at uhub1, port 3, addr 1 (disconnected) Mar 25 21:17:09 X220 kernel: ums0: at uhub1, port 3, addr 1 (disconnected) Mar 25 21:17:09 X220 kernel: uhid0: at uhub1, port 3, addr 1 (disconnected) Mar 25 21:17:25 X220 kernel: ugen1.2: at usbus1 Mar 25 21:17:25 X220 kernel: ukbd0: on usbus1 Mar 25 21:17:25 X220 kernel: kbd2 at ukbd0 Mar 25 21:17:25 X220 kernel: ums0: on usbus1 Mar 25 21:17:25 X220 kernel: ums0: 16 buttons and [XYZT] coordinates ID=2 Mar 25 21:17:25 X220 kernel: uhid0: on usbus1 Still, the keyboard ukdb0 gets disconnected together with the mouse. Erich From owner-freebsd-current@FreeBSD.ORG Mon Mar 25 14:26:55 2013 Return-Path: Delivered-To: freebsd-current@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 A5F435B7; Mon, 25 Mar 2013 14:26:55 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by mx1.freebsd.org (Postfix) with ESMTP id 687B6289; Mon, 25 Mar 2013 14:26:55 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id j6so6349315oag.8 for ; Mon, 25 Mar 2013 07:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=LTgyhSrnC87/GqhQWKLeQam71Tuq0hrPJSoF4bARTLs=; b=zmAnWRwrhNOpc2mCqkq7F3DMPIqI/+N3ExIhOZc1M2ONjCI+NjAsOd+5cTbgX7JI6v //zKEprmadwYGWVtQrUVKym8hlXUYePV2+azVzEDiwCZktXF2jfSUggO1ccUTwXbrrUB O6Ovw6pj8Y7CoUKN+IYxd5tvKfHgR1Gp3BcDw3lxH3zgL45yZThcD8QbDLZtiLGz5jAH RsyozXEn5eqxv41XiwUF0keQgbZK2/sigU7T+Yckm11iQlPvc22MRMDclEiu4vFs4Yrn UmiSWIDmmYwowd9yq9QQFqG9kp28X5NsupGgKogcV2pO3Vf8x2nECRTrjQKjtbKT/k/G ZESw== MIME-Version: 1.0 X-Received: by 10.182.96.136 with SMTP id ds8mr59502obb.22.1364221614412; Mon, 25 Mar 2013 07:26:54 -0700 (PDT) Received: by 10.76.122.81 with HTTP; Mon, 25 Mar 2013 07:26:54 -0700 (PDT) In-Reply-To: <20130325212458.15241453@X220.ovitrap.com> References: <20130325192105.4e94db17@X220.ovitrap.com> <20130325195949.228c2dea@X220.ovitrap.com> <20130325212458.15241453@X220.ovitrap.com> Date: Mon, 25 Mar 2013 15:26:54 +0100 Message-ID: Subject: Re: X220 loses keyboard when Logitech USB wireless adaptor is unplugged From: Andreas Nilsson To: Erich Dollansky Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Daniel Eischen , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 14:26:55 -0000 On Mon, Mar 25, 2013 at 3:24 PM, Erich Dollansky < erichsfreebsdlist@alogt.com> wrote: > Hi, > > On Mon, 25 Mar 2013 09:07:14 -0400 (EDT) > Daniel Eischen wrote: > > > On Mon, 25 Mar 2013, Erich Dollansky wrote: > > > > > Hi, > > > > > > On Mon, 25 Mar 2013 19:21:05 +0700 > > > Erich Dollansky wrote: > > > > > >> As you can see, I took the adaptor connected to ugne0.3 out. In > > >> addition, the keyboard ukbd0 was disconnected too. When I put the > > >> adaptor back in, the keyboard comes back too. As you can imagine, > > >> it is a bit hard to unplug the built-in keyboard on a notebook. > > >> > > > the situation changes when I do not use X and KMS. I can do with the > > > Logitech adaptor what I want but the keyboard stays connected. The > > > moment I start X, it is back to the behaviour from above. > > > > Can you use, or are you using, moused? Tell X to use sysmouse. > > > > Section "InputDevice" > > Identifier "Mouse0" > > Driver "mouse" > > Option "Protocol" "auto" > > Option "Device" "/dev/sysmouse" > > Option "ZAxisMapping" "4 5 6 7" > > EndSection > > > I did this and do not see a difference. The log file says: > > Mar 25 21:17:09 X220 kernel: ugen1.2: at usbus1 (disconnected) > Mar 25 21:17:09 X220 kernel: ukbd0: at uhub1, port 3, addr 1 (disconnected) > Mar 25 21:17:09 X220 kernel: ums0: at uhub1, port 3, addr 1 (disconnected) > Mar 25 21:17:09 X220 kernel: uhid0: at uhub1, port 3, addr 1 (disconnected) > Mar 25 21:17:25 X220 kernel: ugen1.2: at usbus1 > Mar 25 21:17:25 X220 kernel: ukbd0: 2.0012.01, addr 1> on usbus1 > Mar 25 21:17:25 X220 kernel: kbd2 at ukbd0 > Mar 25 21:17:25 X220 kernel: ums0: 2.00/2.01, addr 1> on usbus1 > Mar 25 21:17:25 X220 kernel: ums0: 16 buttons and [XYZT] coordinates ID=2 > Mar 25 21:17:25 X220 kernel: uhid0: 2.0012.01, addr 1> on usbus1 > > Still, the keyboard ukdb0 gets disconnected together with the mouse. > > Erich > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > What does a 'usbconfig devlist' before and after unplugging show? Best regards Andreas From owner-freebsd-current@FreeBSD.ORG Mon Mar 25 14:34:58 2013 Return-Path: Delivered-To: freebsd-current@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 40745AC7; Mon, 25 Mar 2013 14:34:58 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id 06AC9332; Mon, 25 Mar 2013 14:34:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=jTBTCynWO8/RThwIV2kocdqedmZjwe9j2iqy1qQdpqE=; b=dbq+sBVAAi5rO8ypUw/c28Ww0e9Af/D4WNOPz9Kt6j2rPw8i2nwrhaRygYUzjYRsJqb9jJWiBVZyGT1wWfjJ8weaL9F0+Og8FK4lhEqWXywboSRWfTpVuv9B2ltQJ5HSLHslUUZ6hH0DNdUfRzPNRRY7NoZ3LC6mpaGLBoy474E=; Received: from [122.129.203.50] (port=25082 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UK8UC-002nkU-SH; Mon, 25 Mar 2013 08:34:57 -0600 Date: Mon, 25 Mar 2013 21:34:52 +0700 From: Erich Dollansky To: Andreas Nilsson Subject: Re: X220 loses keyboard when Logitech USB wireless adaptor is unplugged Message-ID: <20130325213452.02000811@X220.ovitrap.com> In-Reply-To: References: <20130325192105.4e94db17@X220.ovitrap.com> <20130325195949.228c2dea@X220.ovitrap.com> <20130325212458.15241453@X220.ovitrap.com> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: Daniel Eischen , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 14:34:58 -0000 Hi, On Mon, 25 Mar 2013 15:26:54 +0100 Andreas Nilsson wrote: > On Mon, Mar 25, 2013 at 3:24 PM, Erich Dollansky < > erichsfreebsdlist@alogt.com> wrote: > > > What does a 'usbconfig devlist' before and after unplugging show? > do you mean this? Before usbconfig dump_info ugen0.1: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.1: at usbus1, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen2.1: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen2.2: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) ugen0.4: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (0mA) ugen0.5: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (200mA) ugen1.2: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (98mA) after: ugen0.1: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.1: at usbus1, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen2.1: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen2.2: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) ugen0.4: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (0mA) ugen0.5: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (200mA) Erich From owner-freebsd-current@FreeBSD.ORG Mon Mar 25 15:05:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9E012420 for ; Mon, 25 Mar 2013 15:05:41 +0000 (UTC) (envelope-from lattera@gmail.com) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by mx1.freebsd.org (Postfix) with ESMTP id 80CC96EA for ; Mon, 25 Mar 2013 15:05:41 +0000 (UTC) Received: by mail-pb0-f47.google.com with SMTP id rp2so4210207pbb.34 for ; Mon, 25 Mar 2013 08:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=zK0sr9+lje5cSXtQGZLzIvTu8mxYxcmFoZiF8vbJE4Q=; b=dGKgDG7+4ALxHop6E7qKE3/hF0iagok1W9wb2xefshIJlQFAAY32biOhry/tQTkYkN B5E3NZYWYr3XCyTOuf5oFHXmrXw4zCWPReEkk+ZPjFcy2jBVC16gGLGOoIgWQ24YZvkT 6/iWcB06R+E1/9dkhDho/0DyHfYaZ8KAQbG0/DNQQ0+RQQSUNoZODV8ESq4QV2nd0CEY cJcD68Jq8uUsxdfBCbkdgKUV0Qs8tj2m4KD1SAIHZ9gNoan0scGne3ey1rAqYNm2fI72 kwJsuamd6pNlL2vz/T7U89jMEBrzpqqZjUdr18bjXv5YYW0JcDYkblGfAsqIOTI6HXgn hk4Q== MIME-Version: 1.0 X-Received: by 10.66.234.33 with SMTP id ub1mr18454403pac.29.1364223940992; Mon, 25 Mar 2013 08:05:40 -0700 (PDT) Received: by 10.68.247.38 with HTTP; Mon, 25 Mar 2013 08:05:40 -0700 (PDT) Date: Mon, 25 Mar 2013 11:05:40 -0400 Message-ID: Subject: Kernel Panic From: Shawn Webb To: FreeBSD-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 15:05:41 -0000 Hey All, I just got a kernel panic on a recent build of 10-current on my amd64 box. The core.txt file has been pasted here: http://ix.io/4T7 If you need any other info, let me know. Thanks, Shawn From owner-freebsd-current@FreeBSD.ORG Mon Mar 25 17:01:48 2013 Return-Path: Delivered-To: freebsd-current@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 2A40D979; Mon, 25 Mar 2013 17:01:48 +0000 (UTC) (envelope-from lenzi.sergio@gmail.com) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id B169026A; Mon, 25 Mar 2013 17:01:47 +0000 (UTC) Received: by mail-yh0-f46.google.com with SMTP id q15so442060yhf.19 for ; Mon, 25 Mar 2013 10:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:from:to:cc:in-reply-to:references :disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; bh=ix819ImxFaBJ25baJ/w/xnvoEav7IHrY00VnGZyMB04=; b=cq6P+Au9/bOMf8MihV4WfI2DB0JQZXC1dQ/JHKXKerP+ojjc4udY477y4kP07zvGXo WPHxmIIjEIv13btU23RTEsF75zZl09KXtfZHnawF5a8kWlwg20pT5eFi+6+D5k5kTts3 QaVqfBexJ3p4EoMj0D7PCjFqVEFYcHg6meyot5FKYpc8XMZKTSlwvbYvGXKUKu22esMm ht5pw6Qm9NFjZJC3PptJ9YCkrsc+ABK4L4K8O5uepKKhYIiyslQXqFjAZeY1u927oDqm mZQWk2ylo5e5AUy9Wn1JF+UISuC++9g68I5dJ/xiyuyp5kxuKHFFfRpMS3X3odw9tTiT vYmg== X-Received: by 10.236.71.199 with SMTP id r47mr7214595yhd.174.1364230907258; Mon, 25 Mar 2013 10:01:47 -0700 (PDT) Received: from [192.168.6.230] ([189.123.220.17]) by mx.google.com with ESMTPS id q28sm19706448yhm.24.2013.03.25.10.01.43 (version=SSLv3 cipher=RC4-SHA bits=128/128); Mon, 25 Mar 2013 10:01:46 -0700 (PDT) Subject: Re: Kernel panic CURRENT r248596 at virtualbox-ose-kmod module load From: Sergio de Almeida Lenzi To: sean bruno In-Reply-To: References: <20130323132627.04bf7ef4@nonamehost> <20130324120507.GX3794@kib.kiev.ua> <20130325020340.02c5ace0@nonamehost> <20130325132057.494627a2@nonamehost> Date: Mon, 25 Mar 2013 14:01:42 -0300 Message-ID: <1364230902.85237.8.camel@z6000.lenzicasa> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-Mailman-Approved-At: Mon, 25 Mar 2013 17:42:17 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Ivan Klymenko , Konstantin Belousov , freebsd-current@freebsd.org, Bernhard =?ISO-8859-1?Q?Fr=F6hlich?= , freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 17:01:48 -0000 Em Seg, 2013-03-25 às 04:49 -0700, sean bruno escreveu: > > > > Yes - it is correctly > > http://svnweb.freebsd.org/ports/head/emulators/virtualbox-ose-kmod/files/patch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd_VM_OBJECT_RENAME.c?r1=314797&r2=315200 > > > Ah, thank you. My patch definitely was not right and I was wondering > where the kpanic on load/startup was coming from. :-) > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" Hello, I am running BSD10 svn=248699 and virtualbox runs without problems From owner-freebsd-current@FreeBSD.ORG Mon Mar 25 20:44:15 2013 Return-Path: Delivered-To: freebsd-current@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 B0DDCE00; Mon, 25 Mar 2013 20:44:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C0E1EF77; Mon, 25 Mar 2013 20:44:14 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA28554; Mon, 25 Mar 2013 22:44:13 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UKEFZ-000PDL-4Y; Mon, 25 Mar 2013 22:44:13 +0200 Message-ID: <5150B71B.6060106@FreeBSD.org> Date: Mon, 25 Mar 2013 22:44:11 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130321 Thunderbird/17.0.4 MIME-Version: 1.0 To: FreeBSD Current , freebsd-hackers@FreeBSD.org Subject: Fwd: kern/122838: [devfs] devfs doesn't handle complex paths (like zvol/pool/vms) good References: <5150B598.7050700@FreeBSD.org> In-Reply-To: <5150B598.7050700@FreeBSD.org> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <5150B598.7050700@FreeBSD.org> Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 20:44:15 -0000 Would like to ask for opinions on this topic... Please read this PR for context: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122838 Especially Jaakko's insightful description of the problem. -------- Original Message -------- Message-ID: <5150B598.7050700@FreeBSD.org> Date: Mon, 25 Mar 2013 22:37:44 +0200 From: Andriy Gapon Subject: Re: kern/122838: [devfs] devfs doesn't handle complex paths (like zvol/pool/vms) good Can't believe that we are still where we were more than two years ago... I think that we have to make this change even if it _might_ break some existing rulesets. Rationale: - current behavior is contrary to any documentation - current behavior is contrary to common sense - current behavior is very hard to describe and account for - I presume that very few people actually fully understand the current behavior - I presume that even fewer people made a conscious choice to depend or make use of its non-trivial features of the current behavior So, we should make the behavior of devfs pattern consistent with the documentation and the common sense. In addition to Jaakko's patch I propose that we pass FNM_PATHNAME to fnmatch(9), so that the matching is indeed consistent with glob(3) / shell glob-ing rules for filesystem paths. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Mar 25 20:58:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6BFF5238; Mon, 25 Mar 2013 20:58:49 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id B5208D9; Mon, 25 Mar 2013 20:58:48 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id t11so3467387wey.34 for ; Mon, 25 Mar 2013 13:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=NjV7IsSndrzfxsxeWH9SrUdQiCmqSO2rPRRuaQqUldU=; b=m+5wQNwR7LOH4/+spcnWTMnSTnUDEhAsnyfxFsIjT1gLv0+msk8Gcbio0o9Ltc2onG s4v55o4sHgkqA0VNTD10kVWTJSPTs2OYZojAXdVfMdpp0tE7o6Mt+b8cs7TnnYRGYji8 k+l+Mb+JNG+vsmZGgTCf/GJlsU21V+5XCkuITzRRVoHs8wuSgj4bU8ew/Il786ZgIaPZ PX0dCFo08Ng6zjPLUKz5LESx33FrLPkDykxi5Jh5RiUY11JHzOh1ytPgwuZIC/24xmBA TGOXfIqvgHcqCcjhKebx8zBhippyHRU7kSmaY9zeE90s0H9Q+EzftrZ79Wi0/tdnk+1S NmwA== MIME-Version: 1.0 X-Received: by 10.180.73.6 with SMTP id h6mr4359094wiv.27.1364245127844; Mon, 25 Mar 2013 13:58:47 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Mon, 25 Mar 2013 13:58:47 -0700 (PDT) In-Reply-To: <5150B71B.6060106@FreeBSD.org> References: <5150B598.7050700@FreeBSD.org> <5150B71B.6060106@FreeBSD.org> Date: Mon, 25 Mar 2013 22:58:47 +0200 Message-ID: Subject: Re: kern/122838: [devfs] devfs doesn't handle complex paths (like zvol/pool/vms) good From: Kimmo Paasiala To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 20:58:49 -0000 On Mon, Mar 25, 2013 at 10:44 PM, Andriy Gapon wrote: > > Would like to ask for opinions on this topic... > Please read this PR for context: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122838 > Especially Jaakko's insightful description of the problem. > > > -------- Original Message -------- > Message-ID: <5150B598.7050700@FreeBSD.org> > Date: Mon, 25 Mar 2013 22:37:44 +0200 > From: Andriy Gapon > Subject: Re: kern/122838: [devfs] devfs doesn't handle complex paths (like > zvol/pool/vms) good > > > Can't believe that we are still where we were more than two years ago... > > I think that we have to make this change even if it _might_ break some existing > rulesets. > > Rationale: > - current behavior is contrary to any documentation > - current behavior is contrary to common sense > - current behavior is very hard to describe and account for > - I presume that very few people actually fully understand the current behavior > - I presume that even fewer people made a conscious choice to depend or make use > of its non-trivial features of the current behavior > > So, we should make the behavior of devfs pattern consistent with the > documentation and the common sense. > > In addition to Jaakko's patch I propose that we pass FNM_PATHNAME to fnmatch(9), > so that the matching is indeed consistent with glob(3) / shell glob-ing rules > for filesystem paths. > > -- > Andriy Gapon > > > Absolutely yes. Any kind of rule based matching should default to matching full strings. The rule syntax should then offer options to narrow down the matching to a specific part(s) of the matched strings. -Kimmo From owner-freebsd-current@FreeBSD.ORG Tue Mar 26 01:06:21 2013 Return-Path: Delivered-To: freebsd-current@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 09201FAF for ; Tue, 26 Mar 2013 01:06:21 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (neu.net [199.48.129.194]) by mx1.freebsd.org (Postfix) with ESMTP id C8DD4D73 for ; Tue, 26 Mar 2013 01:06:20 +0000 (UTC) Received: from neu.net (neu.net [199.48.129.194]) by mail.neu.net (8.14.6/8.14.5) with ESMTP id r2Q169N5069474 for ; Mon, 25 Mar 2013 21:06:09 -0400 (EDT) (envelope-from andy@neu.net) Date: Mon, 25 Mar 2013 21:06:09 -0400 (EDT) From: AN To: freebsd-current@freebsd.org Subject: kernel panic - Fatal Trap 12 on boot @svn 248711 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.97.7 at my.mail.server X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=4.5 tests=RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.neu.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 01:06:21 -0000 After updating to svn 248711 I am getting a kernel panic and reboot when booting my system. The last line I see while booting is: Entropy harvesting interrupts: Ethernet point to point, and then Fatal Trap 12 in kernel mode then an automatic reboot. I am currently booting into kernel.old @svn FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #38 r248401: Sat Mar 16 21:39:04 CDT 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 Is anyone else seeing this behavior? From owner-freebsd-current@FreeBSD.ORG Tue Mar 26 01:15:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B848F4A3 for ; Tue, 26 Mar 2013 01:15:36 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by mx1.freebsd.org (Postfix) with ESMTP id 7B45ADEF for ; Tue, 26 Mar 2013 01:15:36 +0000 (UTC) Received: by mail-qe0-f46.google.com with SMTP id a11so3628555qen.33 for ; Mon, 25 Mar 2013 18:15:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type; bh=6Hy54xQrvCTA1xDrz2AbpWUnh9Ap3tfUP8WeOUGa3PA=; b=0aaZhNoTRUSKUtyqn9qNWK/BPFlF1CCJRIhAWGMc+oZwsShxwzqJhANul2wZCv1nGX kQukEgFz17IUEQVyp2UKs3Bg4avqgyw9A2hpqwbj9SUrVDo5I/ENZnHSx85tRwO2tQbi MvxX5Eigfhbs+ClbZbZ8XxQjDpywBrii+S+LKKd9NB0NN6ksAJ0hwWPDp1FpXBuFuRaR gq2gp3Wdu3Ppj+Gxo7YRQCwpFcCRLuniwmCYJK0hb9tg0EtLFDrhRcJempVK44anj0vJ CXPIkvdahGt02bty8xZlun5EhCY/K1FUmZvSzlcYzC9L1UIS6KYaIztMZT6XumnQvbjZ GB+w== X-Received: by 10.224.167.83 with SMTP id p19mr1452732qay.73.1364260529810; Mon, 25 Mar 2013 18:15:29 -0700 (PDT) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id h5sm435805qai.9.2013.03.25.18.15.28 (version=SSLv3 cipher=RC4-SHA bits=128/128); Mon, 25 Mar 2013 18:15:29 -0700 (PDT) Date: Mon, 25 Mar 2013 21:15:21 -0400 From: Alexander Kabaev To: AN Subject: Re: kernel panic - Fatal Trap 12 on boot @svn 248711 Message-ID: <20130325211521.252696bf@kan.dyndns.org> In-Reply-To: References: X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/bsY=LAgzeWXq=An.+wz04vM"; protocol="application/pgp-signature" Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 01:15:36 -0000 --Sig_/bsY=LAgzeWXq=An.+wz04vM Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 25 Mar 2013 21:06:09 -0400 (EDT) AN wrote: >=20 > After updating to svn 248711 I am getting a kernel panic and reboot > when booting my system. The last line I see while booting is: >=20 > Entropy harvesting interrupts: Ethernet point to point, and then > Fatal Trap 12 in kernel mode > then an automatic reboot. >=20 > I am currently booting into kernel.old @svn FreeBSD FBSD10 > 10.0-CURRENT FreeBSD 10.0-CURRENT #38 r248401: Sat Mar 16 21:39:04 > CDT 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 >=20 > Is anyone else seeing this behavior? >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" You run dconschat by any chance? --=20 Alexander Kabaev --Sig_/bsY=LAgzeWXq=An.+wz04vM Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iD8DBQFRUPavQ6z1jMm+XZYRAuPOAKCMqRm6qjvBeiMB+7R5SwjthCOq2wCgjUnz oNt6LkL2t7rfy55ZPop+L54= =gllm -----END PGP SIGNATURE----- --Sig_/bsY=LAgzeWXq=An.+wz04vM-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 26 01:21:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3B46B79F for ; Tue, 26 Mar 2013 01:21:09 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (neu.net [199.48.129.194]) by mx1.freebsd.org (Postfix) with ESMTP id 07915E29 for ; Tue, 26 Mar 2013 01:21:08 +0000 (UTC) Received: from neu.net (neu.net [199.48.129.194]) by mail.neu.net (8.14.6/8.14.5) with ESMTP id r2Q1L73T070530; Mon, 25 Mar 2013 21:21:07 -0400 (EDT) (envelope-from andy@neu.net) Date: Mon, 25 Mar 2013 21:21:07 -0400 (EDT) From: AN To: Alexander Kabaev Subject: Re: kernel panic - Fatal Trap 12 on boot @svn 248711 In-Reply-To: <20130325211521.252696bf@kan.dyndns.org> Message-ID: References: <20130325211521.252696bf@kan.dyndns.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.97.7 at my.mail.server X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=4.5 tests=RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.neu.net Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 01:21:09 -0000 On Mon, 25 Mar 2013, Alexander Kabaev wrote: > On Mon, 25 Mar 2013 21:06:09 -0400 (EDT) > AN wrote: > >> >> After updating to svn 248711 I am getting a kernel panic and reboot >> when booting my system. The last line I see while booting is: >> >> Entropy harvesting interrupts: Ethernet point to point, and then >> Fatal Trap 12 in kernel mode >> then an automatic reboot. >> >> I am currently booting into kernel.old @svn FreeBSD FBSD10 >> 10.0-CURRENT FreeBSD 10.0-CURRENT #38 r248401: Sat Mar 16 21:39:04 >> CDT 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 >> >> Is anyone else seeing this behavior? >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" > > You run dconschat by any chance? > > -- > Alexander Kabaev > Hi Alexander: No, I do not think so. How can I tell? I have never intentionally configured it. From owner-freebsd-current@FreeBSD.ORG Tue Mar 26 01:28:25 2013 Return-Path: Delivered-To: freebsd-current@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 C245D9E3 for ; Tue, 26 Mar 2013 01:28:25 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by mx1.freebsd.org (Postfix) with ESMTP id 8467AE77 for ; Tue, 26 Mar 2013 01:28:25 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id t2so2958882qcq.28 for ; Mon, 25 Mar 2013 18:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type; bh=4DObeD41/0W9knUor3hX9a+nKRT+YqiL8ZlTFvywF18=; b=ajn+FfbYcIP72XZBI3Zv9M4JhS72fjRDfzp/LAoo3kpVIWE+Q0u0mbhjBQUbNyksUP f6gDu86J4HPcqBywP5Qy9YoLuSmoL+iC0QkCu91seRLFqyoSefB3kQk7PRgS6+aD9UuC CnzeDO4nONG1lfqx8r8sn/QhzIL0/hY5Du1BlO1eqbiGtaYz7fx7C7LSJkKoKjL5sFCK fD/2Pd24rjOd3ElqOZJ4KhDQnK9QjoBdFX94UKP/EW3xuMgNMq1+PLFUtMgH2Dt4/h8g 6guug8ni57qkzosI7D2jLwFoQOrcC567IBVCHMQzOy4rGx/8CdwWoGI6KbXNSF5ICdrV Twlg== X-Received: by 10.229.56.90 with SMTP id x26mr2103824qcg.88.1364261305064; Mon, 25 Mar 2013 18:28:25 -0700 (PDT) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id dt10sm4490679qab.0.2013.03.25.18.28.24 (version=SSLv3 cipher=RC4-SHA bits=128/128); Mon, 25 Mar 2013 18:28:24 -0700 (PDT) Date: Mon, 25 Mar 2013 21:28:17 -0400 From: Alexander Kabaev To: AN Subject: Re: kernel panic - Fatal Trap 12 on boot @svn 248711 Message-ID: <20130325212817.30083046@kan.dyndns.org> In-Reply-To: References: <20130325211521.252696bf@kan.dyndns.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/sNUlefVHT1jk1AnRK6bu4J7"; protocol="application/pgp-signature" Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 01:28:25 -0000 --Sig_/sNUlefVHT1jk1AnRK6bu4J7 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 25 Mar 2013 21:21:07 -0400 (EDT) AN wrote: >=20 >=20 > On Mon, 25 Mar 2013, Alexander Kabaev wrote: >=20 > > On Mon, 25 Mar 2013 21:06:09 -0400 (EDT) > > AN wrote: > > > >> > >> After updating to svn 248711 I am getting a kernel panic and reboot > >> when booting my system. The last line I see while booting is: > >> > >> Entropy harvesting interrupts: Ethernet point to point, and then > >> Fatal Trap 12 in kernel mode > >> then an automatic reboot. > >> > >> I am currently booting into kernel.old @svn FreeBSD FBSD10 > >> 10.0-CURRENT FreeBSD 10.0-CURRENT #38 r248401: Sat Mar 16 21:39:04 > >> CDT 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 > >> > >> Is anyone else seeing this behavior? > >> > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to > >> "freebsd-current-unsubscribe@freebsd.org" > > > > You run dconschat by any chance? > > > > --=20 > > Alexander Kabaev > > >=20 > Hi Alexander: >=20 > No, I do not think so. How can I tell? I have never intentionally=20 > configured it. Then you probably are not running it and the and the question is moot. I would suggest trying r248712 anyway, just for kicks. If that does not help, then try with vfs.unmapped_buf_allowed=3D"0" in loader.conf. --=20 Alexander Kabaev --Sig_/sNUlefVHT1jk1AnRK6bu4J7 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iD8DBQFRUPm3Q6z1jMm+XZYRAiWmAJ9Ex1z9T+qcpAkK6MzqGURNrRdmZgCfeXJP vImhJNcmVm4l79jUZa3WcNw= =Ufh0 -----END PGP SIGNATURE----- --Sig_/sNUlefVHT1jk1AnRK6bu4J7-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 26 02:06:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2E89BDFA for ; Tue, 26 Mar 2013 02:06:53 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by mx1.freebsd.org (Postfix) with ESMTP id 00892F8D for ; Tue, 26 Mar 2013 02:06:52 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id j6so7217598oag.36 for ; Mon, 25 Mar 2013 19:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=+v6v2+KufTWiKf7cGjmCZ/lTA7ckmwVhI6qmACIG47M=; b=mK2VCsdut1VMh8bnd5vd/d3IhfqDFJ7djMLF+F59mkebg3ZsYLV1ay/jhNEn5OlR1e ScZNId758OS6qV6g0HLe0IuNE5EKlQ23Iplq8/IO6XS8jPE0nahSdUe3ufbF0Eg30qFW O2vYNiYnje6yruq3RHkpgi649YMQxws4yDkA9y8rOZI1ido9zPZIznG5786y1cU4Hmjf H4nj1JGCuOc1UAFxnP95WV9KxaF0fg/aomB3BBrar95xriSeJNdgtBrDNPeRBNE+vfe2 MdJA0d7YtOYtuZFpo5Zb3znNytbbrRdiXHAVs/Fvbtl7MnQlewlbxHwohVJO4QYnBNNt qGUg== MIME-Version: 1.0 X-Received: by 10.60.7.3 with SMTP id f3mr12534568oea.64.1364263605892; Mon, 25 Mar 2013 19:06:45 -0700 (PDT) Received: by 10.182.116.196 with HTTP; Mon, 25 Mar 2013 19:06:45 -0700 (PDT) In-Reply-To: <515016C2.1020201@gmail.com> References: <515016C2.1020201@gmail.com> Date: Mon, 25 Mar 2013 22:06:45 -0400 Message-ID: Subject: Re: On 10.0, Clang is not accepted as compiler From: Super Bisquit To: Johan Hendriks Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 02:06:53 -0000 In file included from tools/qsimd.cpp:42: In file included from tools/qsimd_p.h:203: In file included from /usr/include/clang/3.2/mm3dnow.h:27: /usr/include/clang/3.2/mmintrin.h:28:2: error: "MMX instruction set not enabled" #error "MMX instruction set not enabled" ^ In file included from tools/qsimd.cpp:42: In file included from tools/qsimd_p.h:203: /usr/include/clang/3.2/mm3dnow.h:36:19: error: unknown type name '__m64' static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.2/mm3dnow.h:36:25: error: expected unqualified-id static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.2/mm3dnow.h:41:19: error: unknown type name '__m64' static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.2/mm3dnow.h:41:25: error: expected unqualified-id static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.2/mm3dnow.h:46:19: error: unknown type name '__m64' static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.2/mm3dnow.h:46:25: error: expected unqualified-id static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.2/mm3dnow.h:51:19: error: unknown type name '__m64' static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.2/mm3dnow.h:51:25: error: expected unqualified-id static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.2/mm3dnow.h:56:19: error: unknown type name '__m64' static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.2/mm3dnow.h:56:25: error: expected unqualified-id static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.2/mm3dnow.h:61:19: error: unknown type name '__m64' static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.2/mm3dnow.h:61:25: error: expected unqualified-id static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.2/mm3dnow.h:66:19: error: unknown type name '__m64' static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.2/mm3dnow.h:66:25: error: expected unqualified-id static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.2/mm3dnow.h:71:19: error: unknown type name '__m64' static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.2/mm3dnow.h:71:25: error: expected unqualified-id static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.2/mm3dnow.h:76:19: error: unknown type name '__m64' static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ /usr/include/clang/3.2/mm3dnow.h:76:25: error: expected unqualified-id static __inline__ __m64 __attribute__((__always_inline__, __nodebug__)) ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. *** [.obj/release-shared/qsimd.o] Error code 1 1 error *** [do-build] Error code 1 Stop in /usr/ports/devel/qt4-corelib. *** [build-depends] Error code 1 Stop in /usr/ports/audio/mixxx. *** [build] Error code 1 Stop in /usr/ports/audio/mixxx. On Mon, Mar 25, 2013 at 5:20 AM, Johan Hendriks wrote: > Super Bisquit schreef: >> >> What argument do I need to add to /etc/make.conf to correct this? >> >> Thanks muchly. >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > On CURRENT aka 10, Clang is the default compiler. > As far as i know, you do not have to set anything in /etc/make.conf. > > regards > Johan From owner-freebsd-current@FreeBSD.ORG Tue Mar 26 02:43:54 2013 Return-Path: Delivered-To: freebsd-current@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 A95E21B9 for ; Tue, 26 Mar 2013 02:43:54 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (neu.net [199.48.129.194]) by mx1.freebsd.org (Postfix) with ESMTP id 5AC8C126 for ; Tue, 26 Mar 2013 02:43:53 +0000 (UTC) Received: from neu.net (neu.net [199.48.129.194]) by mail.neu.net (8.14.6/8.14.5) with ESMTP id r2Q2hpjJ075990; Mon, 25 Mar 2013 22:43:51 -0400 (EDT) (envelope-from andy@neu.net) Date: Mon, 25 Mar 2013 22:43:51 -0400 (EDT) From: AN To: Alexander Kabaev Subject: Re: kernel panic - Fatal Trap 12 on boot @svn 248711 In-Reply-To: <20130325212817.30083046@kan.dyndns.org> Message-ID: References: <20130325211521.252696bf@kan.dyndns.org> <20130325212817.30083046@kan.dyndns.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.97.7 at my.mail.server X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=4.5 tests=RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.neu.net Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 02:43:54 -0000 On Mon, 25 Mar 2013, Alexander Kabaev wrote: > On Mon, 25 Mar 2013 21:21:07 -0400 (EDT) > AN wrote: > >> >> >> On Mon, 25 Mar 2013, Alexander Kabaev wrote: >> >>> On Mon, 25 Mar 2013 21:06:09 -0400 (EDT) >>> AN wrote: >>> >>>> >>>> After updating to svn 248711 I am getting a kernel panic and reboot >>>> when booting my system. The last line I see while booting is: >>>> >>>> Entropy harvesting interrupts: Ethernet point to point, and then >>>> Fatal Trap 12 in kernel mode >>>> then an automatic reboot. >>>> >>>> I am currently booting into kernel.old @svn FreeBSD FBSD10 >>>> 10.0-CURRENT FreeBSD 10.0-CURRENT #38 r248401: Sat Mar 16 21:39:04 >>>> CDT 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 >>>> >>>> Is anyone else seeing this behavior? >>>> >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to >>>> "freebsd-current-unsubscribe@freebsd.org" >>> >>> You run dconschat by any chance? >>> >>> -- >>> Alexander Kabaev >>> >> >> Hi Alexander: >> >> No, I do not think so. How can I tell? I have never intentionally >> configured it. > > > Then you probably are not running it and the and the question is moot. > I would suggest trying r248712 anyway, just for kicks. If that does not > help, then try with vfs.unmapped_buf_allowed="0" in loader.conf. > > -- > Alexander Kabaev > Alexander: I tried to boot with vfs.unmapped_buf_allowed="0" in loader.conf and I get Fatal Trap 9 General protection fault, and auto reboot. So that does not fix the problem for me. Will try updating to svn 712 and report back. From owner-freebsd-current@FreeBSD.ORG Tue Mar 26 02:47:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 86E0B2F5 for ; Tue, 26 Mar 2013 02:47:47 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 6A412154 for ; Tue, 26 Mar 2013 02:47:47 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r2Q2lfC0056489; Mon, 25 Mar 2013 19:47:41 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r2Q2lfIG056488; Mon, 25 Mar 2013 19:47:41 -0700 (PDT) (envelope-from sgk) Date: Mon, 25 Mar 2013 19:47:41 -0700 From: Steve Kargl To: Super Bisquit Subject: Re: On 10.0, Clang is not accepted as compiler Message-ID: <20130326024741.GA56445@troutmask.apl.washington.edu> References: <515016C2.1020201@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Johan Hendriks , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 02:47:47 -0000 On Mon, Mar 25, 2013 at 10:06:45PM -0400, Super Bisquit wrote: > In file included from tools/qsimd.cpp:42: > In file included from tools/qsimd_p.h:203: > In file included from /usr/include/clang/3.2/mm3dnow.h:27: > /usr/include/clang/3.2/mmintrin.h:28:2: error: "MMX instruction set not enabled" > #error "MMX instruction set not enabled" > ^ You either need to explicitly set CPUTYPE in make.conf to your specific cpu or recompile everything (and I mean everything on the system) with gcc. -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Mar 26 03:14:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 612EDA71 for ; Tue, 26 Mar 2013 03:14:07 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (neu.net [199.48.129.194]) by mx1.freebsd.org (Postfix) with ESMTP id 2C8CE2FD for ; Tue, 26 Mar 2013 03:14:06 +0000 (UTC) Received: from neu.net (neu.net [199.48.129.194]) by mail.neu.net (8.14.6/8.14.5) with ESMTP id r2Q3E4Fc077966; Mon, 25 Mar 2013 23:14:04 -0400 (EDT) (envelope-from andy@neu.net) Date: Mon, 25 Mar 2013 23:14:04 -0400 (EDT) From: AN To: Alexander Kabaev Subject: Re: kernel panic - Fatal Trap 12 on boot @svn 248711 In-Reply-To: <20130325212817.30083046@kan.dyndns.org> Message-ID: References: <20130325211521.252696bf@kan.dyndns.org> <20130325212817.30083046@kan.dyndns.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.97.7 at my.mail.server X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=4.5 tests=RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.neu.net Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 03:14:07 -0000 On Mon, 25 Mar 2013, Alexander Kabaev wrote: > On Mon, 25 Mar 2013 21:21:07 -0400 (EDT) > AN wrote: > >> >> >> On Mon, 25 Mar 2013, Alexander Kabaev wrote: >> >>> On Mon, 25 Mar 2013 21:06:09 -0400 (EDT) >>> AN wrote: >>> >>>> >>>> After updating to svn 248711 I am getting a kernel panic and reboot >>>> when booting my system. The last line I see while booting is: >>>> >>>> Entropy harvesting interrupts: Ethernet point to point, and then >>>> Fatal Trap 12 in kernel mode >>>> then an automatic reboot. >>>> >>>> I am currently booting into kernel.old @svn FreeBSD FBSD10 >>>> 10.0-CURRENT FreeBSD 10.0-CURRENT #38 r248401: Sat Mar 16 21:39:04 >>>> CDT 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 >>>> >>>> Is anyone else seeing this behavior? >>>> >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to >>>> "freebsd-current-unsubscribe@freebsd.org" >>> >>> You run dconschat by any chance? >>> >>> -- >>> Alexander Kabaev >>> >> >> Hi Alexander: >> >> No, I do not think so. How can I tell? I have never intentionally >> configured it. > > > Then you probably are not running it and the and the question is moot. > I would suggest trying r248712 anyway, just for kicks. If that does not > help, then try with vfs.unmapped_buf_allowed="0" in loader.conf. > > -- > Alexander Kabaev > I tried svn 248712, but I still get a panic and auto reboot. So up to svn 248712 is broken on my system. The only way I can boot is to use kernel.old @svn 248401. From owner-freebsd-current@FreeBSD.ORG Tue Mar 26 07:58:54 2013 Return-Path: Delivered-To: freebsd-current@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 4587BDD9; Tue, 26 Mar 2013 07:58:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 0CDF4657; Tue, 26 Mar 2013 07:58:54 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::c002:48a7:fd67:52d4] (unknown [IPv6:2001:7b8:3a7:0:c002:48a7:fd67:52d4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 684CC5C5B; Tue, 26 Mar 2013 08:58:50 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: On 10.0, Clang is not accepted as compiler From: Dimitry Andric In-Reply-To: Date: Tue, 26 Mar 2013 08:58:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9A7E9656-014A-4897-AB37-F68397CBD1F3@FreeBSD.org> References: <515016C2.1020201@gmail.com> To: Super Bisquit X-Mailer: Apple Mail (2.1503) Cc: Johan Hendriks , Koop Mast , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 07:58:54 -0000 On Mar 26, 2013, at 03:06, Super Bisquit wrote: > In file included from tools/qsimd.cpp:42: > In file included from tools/qsimd_p.h:203: > In file included from /usr/include/clang/3.2/mm3dnow.h:27: > /usr/include/clang/3.2/mmintrin.h:28:2: error: "MMX instruction set = not enabled" > #error "MMX instruction set not enabled" > ^ ... > Stop in /usr/ports/devel/qt4-corelib. > *** [build-depends] Error code 1 This is a problem with the qt4 port; I think the ports guys are still = investigating this one. In any case, you must compile it with CPUTYPE = i686 or higher in /etc/make.conf, otherwise it will not build. From owner-freebsd-current@FreeBSD.ORG Tue Mar 26 22:07:11 2013 Return-Path: Delivered-To: freebsd-current@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 09306428 for ; Tue, 26 Mar 2013 22:07:11 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from popeye.kernel32.de (popeye.kernel32.de [46.4.9.204]) by mx1.freebsd.org (Postfix) with ESMTP id C13FA666 for ; Tue, 26 Mar 2013 22:07:10 +0000 (UTC) Received: from popeye.kernel32.de (localhost [127.0.0.1]) by popeye.kernel32.de (Postfix) with ESMTP id 717D14273C for ; Tue, 26 Mar 2013 23:00:12 +0100 (CET) X-Virus-Scanned: amavisd-new at popeye.kernel32.de Received: from popeye.kernel32.de ([127.0.0.1]) by popeye.kernel32.de (popeye.kernel32.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6oufZLVw72F for ; Tue, 26 Mar 2013 23:00:10 +0100 (CET) Received: from popeye.kernel32.de (localhost [127.0.0.1]) by popeye.kernel32.de (Postfix) with ESMTPA id 8EB8B42727 for ; Tue, 26 Mar 2013 23:00:10 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 26 Mar 2013 23:00:10 +0100 From: mh@kernel32.de To: Subject: panic at serial boot Message-ID: X-Sender: mh@kernel32.de User-Agent: RoundCube WebMail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 22:07:11 -0000 Hi Ho, I'm trying to install FreeBSD 10.0-CURRENT snapshot from 23.03.2013 on a Dell M620 blade. However, I'm getting a panic and drop to db while booting. Looks like that: Root mount waiting for: usbus1 usbus0 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 Root mount waiting for: usbus1 usbus0 uhub2: 6 ports with 6 removable, self powered uhub3: 8 ports with 8 removable, self powered ugen0.3: at usbus0 uhub4: on usbus0 Root mount waiting for: usbus1 usbus0 ugen1.3: at usbus1 ukbd0: on usbus1 kbd0 at ukbd0 kbd0: ukbd0, generic (0), config:0x0, flags:0x3d0000 uhub4: 6 ports with 6 removable, self powered Root mount waiting for: usbus0 ugen0.4: at usbus0 ukbd1: on usbus0 kbd2 at ukbd1 kbd2: ukbd1, generic (0), config:0x0, flags:0x3d0000 Trying to mount root from ufs:/dev/md0 []... start_init: trying /sbin/init panic: vm_fault: fault on nofault entry, addr: ffffff80002be000 cpuid = 15 KDB: enter: panic [ thread pid 4 tid 100101 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why db> Any idea where to go from here? initially I tried 9.1-STABLE snapshot from the same date, but that one doesn't even give serial output while booting. odd thing, but that's another story. I just thought since I'm giving -current on this hardware a short and there is a problem, it might be worth reporting. Anything I should do? Cheers, Marian PS.: What I really like to do here is get FreeBSD 9.1-RELEASE or -STABLE up and running on a blade like that. But it looks like this will fail anyway since the broadcom BCM57810 nic is not (yet) supported in FreeBSD. I contacted the authors of bxe(4). Friendly folks! :) From owner-freebsd-current@FreeBSD.ORG Tue Mar 26 22:27:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 49F791EE; Tue, 26 Mar 2013 22:27:16 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (neu.net [199.48.129.194]) by mx1.freebsd.org (Postfix) with ESMTP id 2121181A; Tue, 26 Mar 2013 22:27:15 +0000 (UTC) Received: from neu.net (neu.net [199.48.129.194]) by mail.neu.net (8.14.6/8.14.5) with ESMTP id r2QMRCBZ082438; Tue, 26 Mar 2013 18:27:13 -0400 (EDT) (envelope-from andy@neu.net) Date: Tue, 26 Mar 2013 18:27:12 -0400 (EDT) From: AN To: will@FreeBSD.org Subject: Revision 248649 - causes panic during boot Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.97.7 at my.mail.server X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=4.5 tests=RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.neu.net Cc: ken@FreeBSD.org, freebsd-current@freebsd.org, kib@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 22:27:16 -0000 Hello: I have identified svn Revision 248649 as causing my system to panic during boot up. http://svnweb.freebsd.org/base?view=revision&revision=248649 I have verified this by doing the following: svn up -r 248648 - buildkernel, installkernel, reboot = boot successful svn up -r 248649 - buildkernel, installkernel, reboot = causes panic The panic happens just after the line that says: Entropy harvesting interrupts: Ethernet point to point, then Fatal Trap 9 General Protection Fault, and then an automatic reboot. Here is some system info: FreeBSD 10.0-CURRENT #49 r248648: Tue Mar 26 14:55:28 CDT 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 CPU: AMD Phenom(tm) II X6 1045T Processor (2700.05-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100fa0 Family = 0x10 Model = 0xa Stepping = 0 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 15951269888 (15212 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 6 CPUs FreeBSD/SMP: 1 package(s) x 6 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 ACPI BIOS Bug: Warning: Optional FADT field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20130214/tbfadt-626) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ctl: CAM Target Layer loaded acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of ffb80000, 80000 (3) failed acpi0: reservation of fec10000, 20 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, c7f00000 (3) failed cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 450 Event timer "HPET2" frequency 14318180 Hz quality 450 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 The following is the last commit that works: # cd /usr/src # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 248648 Node Kind: directory Schedule: normal Last Changed Author: des Last Changed Rev: 248648 Last Changed Date: 2013-03-23 09:52:31 -0500 (Sat, 23 Mar 2013) Would you please review the commit for anything that may cause a panic during boot up. Let me know if there is any more info that I should provide. Should I file a PR? Thank you in advance for reviewing this. From owner-freebsd-current@FreeBSD.ORG Tue Mar 26 22:36:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2A5A861D for ; Tue, 26 Mar 2013 22:36:43 +0000 (UTC) (envelope-from will@firepipe.net) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id F3CA28D2 for ; Tue, 26 Mar 2013 22:36:42 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id aq17so6626921iec.33 for ; Tue, 26 Mar 2013 15:36:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=PldyZTMQZHkwXRkgatrsdNi4aX0SUKBZxUemRD/Pjwc=; b=OFFl4kZrM0Xhvb3lfQrUb6ZMlXUIWqi2x5K78ij5+IGbibBTuFV3ZxrwyA18NbwtVn coCVHmm1WWmlzNnMmfpZVqibmNLVRfjhPHbJo62yWHIn9VGDvQFdBGmqTURZxhQ5Tk9x cNxLcCs84OwJACjm+Eo4XNRtESigyHjJYshhYOctR+ML6SlBdv7FWk5fsANpipklu5+/ 2QP6TITwLz7DfPWGR40pvcNqdkvellq4jrVuH6L8SHQ/JQjNaZfbb8/+9mXMnijD5d0x uiCbgfCH8xdB+W2NDmeyhIlN4zGLeZkKg2FlY7q+kuB728iU1ika2a2gfOVkfgZcjArb 2Y+A== MIME-Version: 1.0 X-Received: by 10.50.119.102 with SMTP id kt6mr2743713igb.12.1364337402547; Tue, 26 Mar 2013 15:36:42 -0700 (PDT) Received: by 10.231.247.74 with HTTP; Tue, 26 Mar 2013 15:36:42 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Mar 2013 16:36:42 -0600 Message-ID: Subject: Re: Revision 248649 - causes panic during boot From: Will Andrews To: AN X-Gm-Message-State: ALoCoQmaaZQqqyi8JjGXh0Zv1kSmuxW4j4ZVHkrqHQYtRPnjq3qWdes98b43axRBZelN9ogHPVtn Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "Kenneth D. Merry" , freebsd-current@freebsd.org, kib@freebsd.org, Will Andrews X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 22:36:43 -0000 A stack trace would be helpful. Thanks, --Will. On Tue, Mar 26, 2013 at 4:27 PM, AN wrote: > Hello: > > I have identified svn Revision 248649 as causing my system to panic during > boot up. http://svnweb.freebsd.org/**base?view=revision&revision=**248649 > > I have verified this by doing the following: > > svn up -r 248648 - buildkernel, installkernel, reboot = boot successful > svn up -r 248649 - buildkernel, installkernel, reboot = causes panic > > The panic happens just after the line that says: > Entropy harvesting interrupts: Ethernet point to point, then > Fatal Trap 9 General Protection Fault, and then an automatic reboot. > > Here is some system info: > FreeBSD 10.0-CURRENT #49 r248648: Tue Mar 26 14:55:28 CDT 2013 > root@FBSD10:/usr/obj/usr/src/**sys/MYKERNEL amd64 > FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 > CPU: AMD Phenom(tm) II X6 1045T Processor (2700.05-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x100fa0 Family = 0x10 Model = 0xa > Stepping = 0 > > Features=0x178bfbff APIC,SEP,MTRR,PGE,MCA,CMOV,**PAT,PSE36,CLFLUSH,MMX,FXSR,**SSE,SSE2,HTT> > Features2=0x802009 > AMD Features=0xee500800 LM,3DNow!+,3DNow!> > AMD Features2=0x37ff Prefetch,OSVW,IBS,SKINIT,WDT> > TSC: P-state invariant, performance statistics > real memory = 17179869184 (16384 MB) > avail memory = 15951269888 (15212 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 6 CPUs > FreeBSD/SMP: 1 package(s) x 6 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 > cpu4 (AP): APIC ID: 4 > cpu5 (AP): APIC ID: 5 > ACPI BIOS Bug: Warning: Optional FADT field Pm2ControlBlock has zero > address or length: 0x0000000000000000/0x1 (20130214/tbfadt-626) > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > ctl: CAM Target Layer loaded > acpi0: on motherboard > acpi0: Power Button (fixed) > acpi0: reservation of fee00000, 1000 (3) failed > acpi0: reservation of ffb80000, 80000 (3) failed > acpi0: reservation of fec10000, 20 (3) failed > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, c7f00000 (3) failed > cpu0: on acpi0 > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > cpu4: on acpi0 > cpu5: on acpi0 > attimer0: port 0x40-0x43 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > Event timer "RTC" frequency 32768 Hz quality 0 > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 950 > Event timer "HPET" frequency 14318180 Hz quality 450 > Event timer "HPET1" frequency 14318180 Hz quality 450 > Event timer "HPET2" frequency 14318180 Hz quality 450 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > > The following is the last commit that works: > # cd /usr/src > # svn info > Path: . > Working Copy Root Path: /usr/src > URL: svn://svn.freebsd.org/base/**head > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-**001c23d0bc1f > Revision: 248648 > Node Kind: directory > Schedule: normal > Last Changed Author: des > Last Changed Rev: 248648 > Last Changed Date: 2013-03-23 09:52:31 -0500 (Sat, 23 Mar 2013) > > Would you please review the commit for anything that may cause a panic > during boot up. Let me know if there is any more info that I should > provide. Should I file a PR? > > Thank you in advance for reviewing this. > From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 00:36:49 2013 Return-Path: Delivered-To: freebsd-current@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 26EF5AB9; Wed, 27 Mar 2013 00:36:49 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by mx1.freebsd.org (Postfix) with ESMTP id D12A719C; Wed, 27 Mar 2013 00:36:48 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id n1so5445938oag.37 for ; Tue, 26 Mar 2013 17:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=EnyVJrgOAjwwwmTu4bWCf3pjBUsERbDJEjyPrQW7aDk=; b=RfMIZdmXOf90MPmq4P3f+LuuF9o1NiUYxxGpqrv4sH7t++5Kze+QCPbN6+AuS9PNZ3 oUipDCiOq6xVi3/bdlGMfnUqtkvkLLXhqrGGbkxDwKRfwxnlhmAqV81CT+kB95l990Th DJsmBdfV2GB85IYUbDvYBKkR0OjwbJxR/L7ruCSM81lBxAJB1PrBxS+lwOubyVf7NuKh 25SEmTXsTeI1pGaDG83jCDFVZAKJCA/XF5qrzfNspw3HbCG8W7lf2i33FbWwSJmjEQso 7Tut0XldVtMAH2M2HFyopXdaOG2ltRvF8fAE30flmj2kVh+n1adw1ItU9mr93vc254n9 vJ4Q== MIME-Version: 1.0 X-Received: by 10.60.0.129 with SMTP id 1mr10977028oee.5.1364344608006; Tue, 26 Mar 2013 17:36:48 -0700 (PDT) Received: by 10.182.116.196 with HTTP; Tue, 26 Mar 2013 17:36:47 -0700 (PDT) In-Reply-To: <9A7E9656-014A-4897-AB37-F68397CBD1F3@FreeBSD.org> References: <515016C2.1020201@gmail.com> <9A7E9656-014A-4897-AB37-F68397CBD1F3@FreeBSD.org> Date: Tue, 26 Mar 2013 20:36:47 -0400 Message-ID: Subject: Re: On 10.0, Clang is not accepted as compiler From: Super Bisquit To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Cc: Johan Hendriks , Koop Mast , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 00:36:49 -0000 No go on this one. I received the same errors. Rebuilding the entire system isn't an option that I currently have. Qt4 and anything dependent upon it will just have to wait. Thanks much, though. On Tue, Mar 26, 2013 at 3:58 AM, Dimitry Andric wrote: > On Mar 26, 2013, at 03:06, Super Bisquit wrote: >> In file included from tools/qsimd.cpp:42: >> In file included from tools/qsimd_p.h:203: >> In file included from /usr/include/clang/3.2/mm3dnow.h:27: >> /usr/include/clang/3.2/mmintrin.h:28:2: error: "MMX instruction set not enabled" >> #error "MMX instruction set not enabled" >> ^ > ... >> Stop in /usr/ports/devel/qt4-corelib. >> *** [build-depends] Error code 1 > > This is a problem with the qt4 port; I think the ports guys are still investigating this one. In any case, you must compile it with CPUTYPE i686 or higher in /etc/make.conf, otherwise it will not build. > From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 03:00:22 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 544407BB; Wed, 27 Mar 2013 03:00:22 +0000 (UTC) (envelope-from marcelorossi@gmail.com) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id AE2C78E9; Wed, 27 Mar 2013 03:00:21 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id fe20so14889582lab.1 for ; Tue, 26 Mar 2013 20:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=c2x782PZurrXjS6+VgKd7owUlb1q3KXR5EW/y9zP3Ww=; b=W5ajdW7asflr+MwYwPMzmpxG5Ox7yHjf5CmHKCf5Mf/O+13GxUVK7ogSmGW80JpJ1w qwEQQ3UGei7nTkNOK7fUHcWQibEHGnY5WgJ4zaK4LWOfL1Uh9u9PCV4xmEjSEX76Fo2p d2e23DuvtM71bM59N64bAIg9+r27CI58gAeHNZY7RC4nnNGLbGALwZ64ZnRELNAtFEFy +sWy6N0JpZ3jPUG//HhVEqKHByyHN/sjS0XOF4rw2Vh4f7VUngY19SjQO6tpuPzLaBMC FxpT7Fp+h/SSPVvVz8DqT87LwHW/AvqG79sN9srY2kqci2HgaMWZgHcHfBcGKNkq1zWW 5qpA== MIME-Version: 1.0 X-Received: by 10.152.87.243 with SMTP id bb19mr7572241lab.12.1364353219485; Tue, 26 Mar 2013 20:00:19 -0700 (PDT) Received: by 10.114.21.227 with HTTP; Tue, 26 Mar 2013 20:00:19 -0700 (PDT) Received: by 10.114.21.227 with HTTP; Tue, 26 Mar 2013 20:00:19 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Mar 2013 00:00:19 -0300 Message-ID: Subject: Re: sysutils/fusefs-kmod problem in CURRENT From: "Marcelo/Porks" To: attilio@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 03:00:22 -0000 On Mar 22, 2013 1:02 AM, "Attilio Rao" wrote: > > On Fri, Mar 22, 2013 at 2:02 AM, Marcelo/Porks wrote: > > Hi, I'm facing an error compiling the sysutils/fusefs-kmod. > > > > I'm using the CURRENT from today (2013-03-21). > > > > Can someone using the CURRENT confirm if this also happens in your system? > > CURRENT should not allow you to build fusefs-kmod at all. > Use "option FUSEFS" from your kernel config. > Sorry, maybe I didnt understand what you said. I tried to use in my kernel conf: options FUSEFS option FUSEFS options fusefs option fusefs But they didnt work. The kernel does not compile. The result is above: -------------------------------------------------------------- >>> Kernel build for GENERIC started on Tue Mar 26 23:21:09 BRT 2013 -------------------------------------------------------------- ===> GENERIC -------------------------------------------------------------- >>> stage 1: configuring the kernel -------------------------------------------------------------- /usr/src/sys/amd64/conf/GENERIC: unknown option "FUSEFS" *** [buildkernel] Error code 1 1 error *** [buildkernel] Error code 2 1 error -------------------------------------------------------------- >>> Kernel build for GENERIC started on Tue Mar 26 23:33:24 BRT 2013 -------------------------------------------------------------- ===> GENERIC -------------------------------------------------------------- >>> stage 1: configuring the kernel -------------------------------------------------------------- /usr/src/sys/amd64/conf/GENERIC: unknown option "fusefs" *** [buildkernel] Error code 1 1 error *** [buildkernel] Error code 2 1 error -------------------------------------------------------------- >>> Kernel build for GENERIC started on Tue Mar 26 23:44:14 BRT 2013 -------------------------------------------------------------- ===> GENERIC -------------------------------------------------------------- >>> stage 1: configuring the kernel -------------------------------------------------------------- /usr/src/sys/amd64/conf/GENERIC: unknown option "FUSEFS" *** [buildkernel] Error code 1 1 error *** [buildkernel] Error code 2 1 error -------------------------------------------------------------- >>> Kernel build for GENERIC started on Tue Mar 26 23:51:52 BRT 2013 -------------------------------------------------------------- ===> GENERIC -------------------------------------------------------------- >>> stage 1: configuring the kernel -------------------------------------------------------------- /usr/src/sys/amd64/conf/GENERIC: unknown option "fusefs" *** [buildkernel] Error code 1 1 error *** [buildkernel] Error code 2 1 error > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 05:03:54 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9B7D5CE7 for ; Wed, 27 Mar 2013 05:03:54 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 718EBEC1 for ; Wed, 27 Mar 2013 05:03:54 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id c12so9909918ieb.34 for ; Tue, 26 Mar 2013 22:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Mkc+CXgFB+0C0aphavxNC2WtnRx6zeBrZbBLsJiLdDg=; b=Ik7Ke7nm4lecGl64J9/YAoFRNt93ZsB/JWGwWL6zNyZ82dGMg69JSIoUUzvD1f850S h38QnwH67Usmb1mUIKCPaZLoLuWz4jHwpnpvB05Z6os+IE5cJT2WvkdGHRDO2+uscyz8 RlQdX+aIBWphNmysRB9C8NOgc7T5KIAw4jnC3M6DqtlYKXx+829bse2QSUurxsijHbef +2taVwIMlv3IMlLZtV5Z6q0pypJVELJyXyL93hnKvDukHqP0n10sX9sKf4ciUmD350nm MI/neKmllTki+X7WbazqtVKE4Plza+QCMQECbUwQJivEKz81PxDAlMidL18v/3nqWlwu qfaQ== MIME-Version: 1.0 X-Received: by 10.50.140.67 with SMTP id re3mr3272258igb.100.1364360634167; Tue, 26 Mar 2013 22:03:54 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.42.117.134 with HTTP; Tue, 26 Mar 2013 22:03:53 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Mar 2013 06:03:53 +0100 X-Google-Sender-Auth: lrK7RW7DQx1GM-b-sSXIrf9531E Message-ID: Subject: Re: sysutils/fusefs-kmod problem in CURRENT From: Attilio Rao To: "Marcelo/Porks" Content-Type: text/plain; charset=UTF-8 Cc: current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 05:03:54 -0000 On Wed, Mar 27, 2013 at 4:00 AM, Marcelo/Porks wrote: > > On Mar 22, 2013 1:02 AM, "Attilio Rao" wrote: >> >> On Fri, Mar 22, 2013 at 2:02 AM, Marcelo/Porks >> wrote: >> > Hi, I'm facing an error compiling the sysutils/fusefs-kmod. >> > >> > I'm using the CURRENT from today (2013-03-21). >> > >> > Can someone using the CURRENT confirm if this also happens in your >> > system? >> >> CURRENT should not allow you to build fusefs-kmod at all. >> Use "option FUSEFS" from your kernel config. >> > > Sorry, maybe I didnt understand what you said. I tried to use in my kernel > conf: > > options FUSEFS > option FUSEFS > options fusefs > option fusefs Sorry, my fault, I mis-pelled it. it is: options FUSE Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 05:25:24 2013 Return-Path: Delivered-To: current@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 127D328A for ; Wed, 27 Mar 2013 05:25:24 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward19.mail.yandex.net (forward19.mail.yandex.net [IPv6:2a02:6b8:0:1402::4]) by mx1.freebsd.org (Postfix) with ESMTP id BCD7311C for ; Wed, 27 Mar 2013 05:25:23 +0000 (UTC) Received: from smtp19.mail.yandex.net (smtp19.mail.yandex.net [95.108.252.19]) by forward19.mail.yandex.net (Yandex) with ESMTP id 5922D1120EEC; Wed, 27 Mar 2013 09:25:22 +0400 (MSK) Received: from smtp19.mail.yandex.net (localhost [127.0.0.1]) by smtp19.mail.yandex.net (Yandex) with ESMTP id D627CBE02D7; Wed, 27 Mar 2013 09:25:21 +0400 (MSK) Received: from v10-164-116.yandex.net (v10-164-116.yandex.net [84.201.164.116]) by smtp19.mail.yandex.net (nwsmtp/Yandex) with ESMTP id PKaGpERC-PLa4qHqw; Wed, 27 Mar 2013 09:25:21 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1364361921; bh=ynKRtwKYcZy+zd8tUceAleYaQ+iu1p61TfHUAmaCtYI=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=rz2QIGMF290I9/JhH5hdBybBQJb9avIGcdwgK0xqh7FSShxg/91W6cENa0gFBbQoB Wmukavndj6vuUuOZ8DGv9vonYhsoUX+Mp0k0Sv5DGv3aadL2oqj06/snMii5be1r9W jXCZndCaf5xLikUos1yBHt4SE/9NwDi7KjVu0axk= Message-ID: <51528256.2080809@yandex.ru> Date: Wed, 27 Mar 2013 09:23:34 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Marcelo/Porks Subject: Re: sysutils/fusefs-kmod problem in CURRENT References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 05:25:24 -0000 On 27.03.2013 07:00, Marcelo/Porks wrote: > Sorry, maybe I didnt understand what you said. I tried to use in my kernel > conf: > > options FUSEFS > option FUSEFS > options fusefs > option fusefs > > But they didnt work. The kernel does not compile. The result is above: Hi, you can just load the kernel module fuse.ko. Fuse is in the base system. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 05:55:02 2013 Return-Path: Delivered-To: freebsd-current@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 6802D8F8 for ; Wed, 27 Mar 2013 05:55:02 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id ACB5537D for ; Wed, 27 Mar 2013 05:55:01 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id HAA19040; Wed, 27 Mar 2013 07:54:52 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UKjJz-0008Da-Vt; Wed, 27 Mar 2013 07:54:52 +0200 Message-ID: <515289AC.3050204@FreeBSD.org> Date: Wed, 27 Mar 2013 07:54:52 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130321 Thunderbird/17.0.4 MIME-Version: 1.0 To: mh@kernel32.de Subject: Re: panic at serial boot References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 05:55:02 -0000 on 27/03/2013 00:00 mh@kernel32.de said the following: > Hi Ho, > > I'm trying to install FreeBSD 10.0-CURRENT snapshot from 23.03.2013 on a Dell > M620 blade. > However, I'm getting a panic and drop to db while booting. > > Looks like that: > > Root mount waiting for: usbus1 usbus0 > ugen0.2: at usbus0 > uhub2: on usbus0 > ugen1.2: at usbus1 > uhub3: on usbus1 > Root mount waiting for: usbus1 usbus0 > uhub2: 6 ports with 6 removable, self powered > uhub3: 8 ports with 8 removable, self powered > ugen0.3: at usbus0 > uhub4: on usbus0 > Root mount waiting for: usbus1 usbus0 > ugen1.3: at usbus1 > ukbd0: on usbus1 > kbd0 at ukbd0 > kbd0: ukbd0, generic (0), config:0x0, flags:0x3d0000 > uhub4: 6 ports with 6 removable, self powered > Root mount waiting for: usbus0 > ugen0.4: at usbus0 > ukbd1: on usbus0 > kbd2 at ukbd1 > kbd2: ukbd1, generic (0), config:0x0, flags:0x3d0000 > Trying to mount root from ufs:/dev/md0 []... > start_init: trying /sbin/init > panic: vm_fault: fault on nofault entry, addr: ffffff80002be000 > cpuid = 15 > KDB: enter: panic > [ thread pid 4 tid 100101 ] > Stopped at kdb_enter+0x3e: movq $0,kdb_why > db> > > Any idea where to go from here? > > initially I tried 9.1-STABLE snapshot from the same date, but that one doesn't > even give serial output while booting. odd thing, but that's another story. > > I just thought since I'm giving -current on this hardware a short and there is a > problem, it might be worth reporting. > Anything I should do? 'bt' command at the 'db>' prompt -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 12:56:35 2013 Return-Path: Delivered-To: freebsd-current@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 4C88C32D for ; Wed, 27 Mar 2013 12:56:35 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from popeye.kernel32.de (popeye.kernel32.de [46.4.9.204]) by mx1.freebsd.org (Postfix) with ESMTP id D0427986 for ; Wed, 27 Mar 2013 12:56:34 +0000 (UTC) Received: from popeye.kernel32.de (localhost [127.0.0.1]) by popeye.kernel32.de (Postfix) with ESMTP id 7D8A547B0F for ; Wed, 27 Mar 2013 13:56:32 +0100 (CET) X-Virus-Scanned: amavisd-new at popeye.kernel32.de Received: from popeye.kernel32.de ([127.0.0.1]) by popeye.kernel32.de (popeye.kernel32.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXUeoizsoDey for ; Wed, 27 Mar 2013 13:56:30 +0100 (CET) Received: from popeye.kernel32.de (localhost [127.0.0.1]) by popeye.kernel32.de (Postfix) with ESMTPA id 92E7747AFF; Wed, 27 Mar 2013 13:56:29 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 27 Mar 2013 13:56:29 +0100 From: mh@kernel32.de To: Andriy Gapon Subject: Re: panic at serial boot In-Reply-To: <515289AC.3050204@FreeBSD.org> References: <515289AC.3050204@FreeBSD.org> Message-ID: <936608f069b988fcd58707edb9b4dde0@kernel32.de> X-Sender: mh@kernel32.de User-Agent: RoundCube WebMail Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 12:56:35 -0000 Am 2013-03-27 06:54, schrieb Andriy Gapon: > on 27/03/2013 00:00 mh@kernel32.de said the following: >> Hi Ho, >> >> I'm trying to install FreeBSD 10.0-CURRENT snapshot from 23.03.2013 >> on a Dell >> M620 blade. >> However, I'm getting a panic and drop to db while booting. >> >> Looks like that: >> >> Root mount waiting for: usbus1 usbus0 >> ugen0.2: at usbus0 >> uhub2: > 2> on usbus0 >> ugen1.2: at usbus1 >> uhub3: > 2> on usbus1 >> Root mount waiting for: usbus1 usbus0 >> uhub2: 6 ports with 6 removable, self powered >> uhub3: 8 ports with 8 removable, self powered >> ugen0.3: at usbus0 >> uhub4: > addr 3> on usbus0 >> Root mount waiting for: usbus1 usbus0 >> ugen1.3: at usbus1 >> ukbd0: on usbus1 >> kbd0 at ukbd0 >> kbd0: ukbd0, generic (0), config:0x0, flags:0x3d0000 >> uhub4: 6 ports with 6 removable, self powered >> Root mount waiting for: usbus0 >> ugen0.4: at usbus0 >> ukbd1: on usbus0 >> kbd2 at ukbd1 >> kbd2: ukbd1, generic (0), config:0x0, flags:0x3d0000 >> Trying to mount root from ufs:/dev/md0 []... >> start_init: trying /sbin/init >> panic: vm_fault: fault on nofault entry, addr: ffffff80002be000 >> cpuid = 15 >> KDB: enter: panic >> [ thread pid 4 tid 100101 ] >> Stopped at kdb_enter+0x3e: movq $0,kdb_why >> db> >> >> Any idea where to go from here? >> >> initially I tried 9.1-STABLE snapshot from the same date, but that >> one doesn't >> even give serial output while booting. odd thing, but that's another >> story. >> >> I just thought since I'm giving -current on this hardware a short >> and there is a >> problem, it might be worth reporting. >> Anything I should do? > > 'bt' command at the 'db>' prompt Here we go: db> bt Tracing pid 5 tid 100109 td 0xfffffe00466bf920 kdb_enter() at kdb_enter+0x3e/frame 0xffffff8688d3e340 vpanic() at vpanic+0x147/frame 0xffffff8688d3e380 panic() at panic+0x43/frame 0xffffff8688d3e3e0 vm_fault_hold() at vm_fault_hold+0x14ac/frame 0xffffff8688d3e630 vm_fault() at vm_fault+0x77/frame 0xffffff8688d3e670 trap_pfault() at trap_pfault+0x207/frame 0xffffff8688d3e720 trap() at trap+0x659/frame 0xffffff8688d3e930 calltrap() at calltrap+0x8/frame 0xffffff8688d3e930 --- trap 0xc, rip = 0xffffffff80c1a396, rsp = 0xffffff8688d3e9f0, rbp = 0xffffff8688d3ea20 --- bcopy() at bcopy+0x16/frame 0xffffff8688d3ea20 md_kthread() at md_kthread+0x17d/frame 0xffffff8688d3ea70 fork_exit() at fork_exit+0x84/frame 0xffffff8688d3eab0 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff8688d3eab0 --- trap 0, rip = 0, rsp = 0xffffff8688d3eb70, rbp = 0 --- db> where to go from now? :) Thanks, Marian From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 13:32:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 96555ECA; Wed, 27 Mar 2013 13:32:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0A7EAD4D; Wed, 27 Mar 2013 13:32:24 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2RDWKHB072147; Wed, 27 Mar 2013 15:32:20 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2RDWKHB072147 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2RDWKoL072146; Wed, 27 Mar 2013 15:32:20 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Mar 2013 15:32:20 +0200 From: Konstantin Belousov To: mh@kernel32.de Subject: Re: panic at serial boot Message-ID: <20130327133220.GZ3794@kib.kiev.ua> References: <515289AC.3050204@FreeBSD.org> <936608f069b988fcd58707edb9b4dde0@kernel32.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fgtZULS2sMs/xlF6" Content-Disposition: inline In-Reply-To: <936608f069b988fcd58707edb9b4dde0@kernel32.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org, Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 13:32:25 -0000 --fgtZULS2sMs/xlF6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 27, 2013 at 01:56:29PM +0100, mh@kernel32.de wrote: > Am 2013-03-27 06:54, schrieb Andriy Gapon: > > on 27/03/2013 00:00 mh@kernel32.de said the following: > >> Hi Ho, > >> > >> I'm trying to install FreeBSD 10.0-CURRENT snapshot from 23.03.2013=20 > >> on a Dell > >> M620 blade. > >> However, I'm getting a panic and drop to db while booting. > >> > >> Looks like that: > >> > >> Root mount waiting for: usbus1 usbus0 > >> ugen0.2: at usbus0 > >> uhub2: >> 2> on usbus0 > >> ugen1.2: at usbus1 > >> uhub3: >> 2> on usbus1 > >> Root mount waiting for: usbus1 usbus0 > >> uhub2: 6 ports with 6 removable, self powered > >> uhub3: 8 ports with 8 removable, self powered > >> ugen0.3: at usbus0 > >> uhub4: >> addr 3> on usbus0 > >> Root mount waiting for: usbus1 usbus0 > >> ugen1.3: at usbus1 > >> ukbd0: on usbus1 > >> kbd0 at ukbd0 > >> kbd0: ukbd0, generic (0), config:0x0, flags:0x3d0000 > >> uhub4: 6 ports with 6 removable, self powered > >> Root mount waiting for: usbus0 > >> ugen0.4: at usbus0 > >> ukbd1: on usbus0 > >> kbd2 at ukbd1 > >> kbd2: ukbd1, generic (0), config:0x0, flags:0x3d0000 > >> Trying to mount root from ufs:/dev/md0 []... > >> start_init: trying /sbin/init > >> panic: vm_fault: fault on nofault entry, addr: ffffff80002be000 > >> cpuid =3D 15 > >> KDB: enter: panic > >> [ thread pid 4 tid 100101 ] > >> Stopped at kdb_enter+0x3e: movq $0,kdb_why > >> db> > >> > >> Any idea where to go from here? > >> > >> initially I tried 9.1-STABLE snapshot from the same date, but that=20 > >> one doesn't > >> even give serial output while booting. odd thing, but that's another= =20 > >> story. > >> > >> I just thought since I'm giving -current on this hardware a short=20 > >> and there is a > >> problem, it might be worth reporting. > >> Anything I should do? > > > > 'bt' command at the 'db>' prompt >=20 > Here we go: >=20 > db> bt > Tracing pid 5 tid 100109 td 0xfffffe00466bf920 > kdb_enter() at kdb_enter+0x3e/frame 0xffffff8688d3e340 > vpanic() at vpanic+0x147/frame 0xffffff8688d3e380 > panic() at panic+0x43/frame 0xffffff8688d3e3e0 > vm_fault_hold() at vm_fault_hold+0x14ac/frame 0xffffff8688d3e630 > vm_fault() at vm_fault+0x77/frame 0xffffff8688d3e670 > trap_pfault() at trap_pfault+0x207/frame 0xffffff8688d3e720 > trap() at trap+0x659/frame 0xffffff8688d3e930 > calltrap() at calltrap+0x8/frame 0xffffff8688d3e930 > --- trap 0xc, rip =3D 0xffffffff80c1a396, rsp =3D 0xffffff8688d3e9f0, rbp= =3D=20 > 0xffffff8688d3ea20 --- > bcopy() at bcopy+0x16/frame 0xffffff8688d3ea20 > md_kthread() at md_kthread+0x17d/frame 0xffffff8688d3ea70 > fork_exit() at fork_exit+0x84/frame 0xffffff8688d3eab0 > fork_trampoline() at fork_trampoline+0xe/frame 0xffffff8688d3eab0 > --- trap 0, rip =3D 0, rsp =3D 0xffffff8688d3eb70, rbp =3D 0 --- > db> >=20 > where to go from now? :) Do you use preload md(4) ? If yes, try the following patch: diff --git a/sys/dev/md/md.c b/sys/dev/md/md.c index d32ddb3..e871d8f 100644 --- a/sys/dev/md/md.c +++ b/sys/dev/md/md.c @@ -1008,7 +1008,15 @@ mdinit(struct md_s *sc) pp =3D g_new_providerf(gp, "md%d", sc->unit); pp->mediasize =3D sc->mediasize; pp->sectorsize =3D sc->sectorsize; - pp->flags |=3D G_PF_ACCEPT_UNMAPPED; + switch (sc->type) { + case MD_MALLOC: + case MD_VNODE: + case MD_SWAP: + pp->flags |=3D G_PF_ACCEPT_UNMAPPED; + break; + case MD_PRELOAD: + break; + } sc->gp =3D gp; sc->pp =3D pp; g_error_provider(pp, 0); --fgtZULS2sMs/xlF6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRUvTjAAoJEJDCuSvBvK1BZdUP/jP8JrGjrmt7KHQBOXZQXmZK vA0fhArX+PPGa/YHMLlnpTZF3/lyCwmwb9CXm+hozb5vJWvnisaqxfZ2AMMBMqFZ VYL5Y7fZdQPqj5EiLUjOvOQhQDWS+6+KOJflSSzyyH4stUzGPJY2FfTuPumZTZip iq8oVOrQxvF1dKgM7eI1oPPNYZiWLRwHnmDl1ExpNc/jG8YREaxn/azYqZxD0h8q CjFT3KH7QB+MIlFNDBp27Cm4/K+HXOaO+TyhsLE2iVTEW4KNUEi430447IfPe4i+ bVnck8YOgsKQN7CX5h8V5eVcYzKf32GtqWzHhz+fMCKGwKL4zPGCvrbht0qCLSUf 5xuB6x19/WCRnPgRjFO0uJB9mvThTJvQnGpYqa7I0GLtyXLVNLnW7l9knVjGaAJO 7M0t46/x7/7JLZIvXGo8jFuAdMp7a7SsaXMMqCimt4b0yFEx1LBo/j8JRJTeV/dz M4a5TlJ/BgyHwLIjZMA4rPXC3P/DDrq1Yp3XVWERGQ3Tp3ljvWqMfEvqqw1+Z0Tz Kow5Wiv2LkXhw7Cf6wvFgyQKeWUwRAtMSTd5g54d1NhXJEDav/ed3vu+QK+XTXWT B4FRUskyTAigUc1BbmyjE4Uv4YI3HlrO/iqk8zKMMMlR2FhU/MNLSz2ngHcQ6lJM hrC2THyKrGc+9lWkQY/l =wiGO -----END PGP SIGNATURE----- --fgtZULS2sMs/xlF6-- From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 14:33:48 2013 Return-Path: Delivered-To: freebsd-current@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 7CC11C39 for ; Wed, 27 Mar 2013 14:33:48 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from popeye.kernel32.de (popeye.kernel32.de [46.4.9.204]) by mx1.freebsd.org (Postfix) with ESMTP id D52802E5 for ; Wed, 27 Mar 2013 14:33:47 +0000 (UTC) Received: from popeye.kernel32.de (localhost [127.0.0.1]) by popeye.kernel32.de (Postfix) with ESMTP id AA922286DE for ; Wed, 27 Mar 2013 15:33:45 +0100 (CET) X-Virus-Scanned: amavisd-new at popeye.kernel32.de Received: from popeye.kernel32.de ([127.0.0.1]) by popeye.kernel32.de (popeye.kernel32.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Av6fDI8VXhI7 for ; Wed, 27 Mar 2013 15:33:43 +0100 (CET) Received: from popeye.kernel32.de (localhost [127.0.0.1]) by popeye.kernel32.de (Postfix) with ESMTPA id B673A286D2 for ; Wed, 27 Mar 2013 15:33:43 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 27 Mar 2013 15:33:43 +0100 From: mh@kernel32.de To: Subject: Re: panic at serial boot In-Reply-To: <20130327133220.GZ3794@kib.kiev.ua> References: <515289AC.3050204@FreeBSD.org> <936608f069b988fcd58707edb9b4dde0@kernel32.de> <20130327133220.GZ3794@kib.kiev.ua> Message-ID: <24096f01453ab9d0fe898522874cd928@kernel32.de> X-Sender: mh@kernel32.de User-Agent: RoundCube WebMail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 14:33:48 -0000 Am 2013-03-27 14:32, schrieb Konstantin Belousov: > On Wed, Mar 27, 2013 at 01:56:29PM +0100, mh@kernel32.de wrote: >> Am 2013-03-27 06:54, schrieb Andriy Gapon: >> > on 27/03/2013 00:00 mh@kernel32.de said the following: >> >> Hi Ho, >> >> >> >> I'm trying to install FreeBSD 10.0-CURRENT snapshot from >> 23.03.2013 >> >> on a Dell >> >> M620 blade. >> >> However, I'm getting a panic and drop to db while booting. >> >> >> >> Looks like that: >> >> >> >> Root mount waiting for: usbus1 usbus0 >> >> ugen0.2: at usbus0 >> >> uhub2: > addr >> >> 2> on usbus0 >> >> ugen1.2: at usbus1 >> >> uhub3: > addr >> >> 2> on usbus1 >> >> Root mount waiting for: usbus1 usbus0 >> >> uhub2: 6 ports with 6 removable, self powered >> >> uhub3: 8 ports with 8 removable, self powered >> >> ugen0.3: at usbus0 >> >> uhub4: > >> addr 3> on usbus0 >> >> Root mount waiting for: usbus1 usbus0 >> >> ugen1.3: at usbus1 >> >> ukbd0: on usbus1 >> >> kbd0 at ukbd0 >> >> kbd0: ukbd0, generic (0), config:0x0, flags:0x3d0000 >> >> uhub4: 6 ports with 6 removable, self powered >> >> Root mount waiting for: usbus0 >> >> ugen0.4: at usbus0 >> >> ukbd1: on usbus0 >> >> kbd2 at ukbd1 >> >> kbd2: ukbd1, generic (0), config:0x0, flags:0x3d0000 >> >> Trying to mount root from ufs:/dev/md0 []... >> >> start_init: trying /sbin/init >> >> panic: vm_fault: fault on nofault entry, addr: ffffff80002be000 >> >> cpuid = 15 >> >> KDB: enter: panic >> >> [ thread pid 4 tid 100101 ] >> >> Stopped at kdb_enter+0x3e: movq $0,kdb_why >> >> db> >> >> >> >> Any idea where to go from here? >> >> >> >> initially I tried 9.1-STABLE snapshot from the same date, but >> that >> >> one doesn't >> >> even give serial output while booting. odd thing, but that's >> another >> >> story. >> >> >> >> I just thought since I'm giving -current on this hardware a short >> >> and there is a >> >> problem, it might be worth reporting. >> >> Anything I should do? >> > >> > 'bt' command at the 'db>' prompt >> >> Here we go: >> >> db> bt >> Tracing pid 5 tid 100109 td 0xfffffe00466bf920 >> kdb_enter() at kdb_enter+0x3e/frame 0xffffff8688d3e340 >> vpanic() at vpanic+0x147/frame 0xffffff8688d3e380 >> panic() at panic+0x43/frame 0xffffff8688d3e3e0 >> vm_fault_hold() at vm_fault_hold+0x14ac/frame 0xffffff8688d3e630 >> vm_fault() at vm_fault+0x77/frame 0xffffff8688d3e670 >> trap_pfault() at trap_pfault+0x207/frame 0xffffff8688d3e720 >> trap() at trap+0x659/frame 0xffffff8688d3e930 >> calltrap() at calltrap+0x8/frame 0xffffff8688d3e930 >> --- trap 0xc, rip = 0xffffffff80c1a396, rsp = 0xffffff8688d3e9f0, >> rbp = >> 0xffffff8688d3ea20 --- >> bcopy() at bcopy+0x16/frame 0xffffff8688d3ea20 >> md_kthread() at md_kthread+0x17d/frame 0xffffff8688d3ea70 >> fork_exit() at fork_exit+0x84/frame 0xffffff8688d3eab0 >> fork_trampoline() at fork_trampoline+0xe/frame 0xffffff8688d3eab0 >> --- trap 0, rip = 0, rsp = 0xffffff8688d3eb70, rbp = 0 --- >> db> >> >> where to go from now? :) > > Do you use preload md(4) ? If yes, try the following patch: > Yip. I do. Well, mfsbsd does. I just downloaded the snapshot and gave it to mfsbsd to build me an iso image. Transformed that into a pxe bootable hd image. I'm going to checkout -CURRENT sources, apply your patch and let mfsbsd build a new image. Not sure whether time permits that today, but I'm starting right away. Thanks so far. I will report back :) ./Marian > diff --git a/sys/dev/md/md.c b/sys/dev/md/md.c > index d32ddb3..e871d8f 100644 > --- a/sys/dev/md/md.c > +++ b/sys/dev/md/md.c > @@ -1008,7 +1008,15 @@ mdinit(struct md_s *sc) > pp = g_new_providerf(gp, "md%d", sc->unit); > pp->mediasize = sc->mediasize; > pp->sectorsize = sc->sectorsize; > - pp->flags |= G_PF_ACCEPT_UNMAPPED; > + switch (sc->type) { > + case MD_MALLOC: > + case MD_VNODE: > + case MD_SWAP: > + pp->flags |= G_PF_ACCEPT_UNMAPPED; > + break; > + case MD_PRELOAD: > + break; > + } > sc->gp = gp; > sc->pp = pp; > g_error_provider(pp, 0); From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 20:31:01 2013 Return-Path: Delivered-To: freebsd-current@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 E45FADBB for ; Wed, 27 Mar 2013 20:31:01 +0000 (UTC) (envelope-from pawelbsd@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 770EFE57 for ; Wed, 27 Mar 2013 20:31:01 +0000 (UTC) Received: by mail-ea0-f171.google.com with SMTP id b15so1590818eae.2 for ; Wed, 27 Mar 2013 13:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:subject:message-id:x-mailer :mime-version:content-type:content-transfer-encoding; bh=c2Q4iG53dI8yO1Yt/cLcqFI6x/19Pwf5mIQSaPJegg4=; b=faC0MZQTFEF3MfFoLFBx2LXbayXMWA8sRY9ZtkQZ1+WP1VkpfQ+UGhCv16khAHDNu0 LM28beBx8eIQoK5jA+BAfXBhhQwuDZFv7BRQSKw1uLFRSqmrYRUU/FyUmzyDWF1bDMmR E01T78Fe7KZnnu3tC5cG6mE7McHeUfuDrBCjkXXhWwuhgVMl5UlbSvS7BC0xP7Gf7P6L 4IUmcXhrURHPZJsYf8ZIftiqNXZ/SysmBnGrIlVFkZSKSwDyQAZfrgO8WqzWDtI2fPmp cB/moZ6Tb5rmx3qouWoQHi4n6OpWi+Jh9BnkFsVInyvFn74QD9eL2WqL7UOAwn3xujcY 2G7w== X-Received: by 10.14.211.65 with SMTP id v41mr58951627eeo.33.1364416260577; Wed, 27 Mar 2013 13:31:00 -0700 (PDT) Received: from localhost ([176.109.164.5]) by mx.google.com with ESMTPS id s3sm33608452eem.4.2013.03.27.13.30.58 (version=SSLv3 cipher=RC4-SHA bits=128/128); Wed, 27 Mar 2013 13:30:59 -0700 (PDT) Sender: =?UTF-8?B?UGF3ZcWCIFDEmWthbGE=?= Date: Wed, 27 Mar 2013 21:28:19 +0100 From: Pawel Pekala To: freebsd-current@freebsd.org Subject: Ports including sys/time.h broken Message-ID: <20130327212819.1a28b2e1@FreeBSD.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 20:31:02 -0000 For some time now (about month?) ports using sys/time.h include fail to build and I`m sure they were building ok before. At least those seems affected by this: math/atlas math/openblas x11-toolkits/c++-gtk-utils All fail with similar errors: /usr/include/sys/time.h:134:17: error: unknown type name 'sbintime_t' /usr/include/sys/time.h:141:1: error: unknown type name 'sbintime_t' /usr/include/sys/time.h: In function 'bttosbt': /usr/include/sys/time.h:144:12: error: 'sbintime_t' undeclared (first use in this function) /usr/include/sys/time.h:144:12: note: each undeclared identifier is reported only once for each function it appears in /usr/include/sys/time.h:144:23: error: expected ')' before 'bt' /usr/include/sys/time.h: At top level: /usr/include/sys/time.h:148:9: error: unknown type name 'sbintime_t' /usr/include/sys/time.h:206:9: error: unknown type name 'sbintime_t' /usr/include/sys/time.h:216:1: error: unknown type name 'sbintime_t' /usr/include/sys/time.h: In function 'tstosbt': /usr/include/sys/time.h:219:12: error: 'sbintime_t' undeclared (first use in this function) /usr/include/sys/time.h:219:23: error: expected ')' before 'ts' /usr/include/sys/time.h: At top level: /usr/include/sys/time.h:224:9: error: unknown type name 'sbintime_t' /usr/include/sys/time.h:234:1: error: unknown type name 'sbintime_t' /usr/include/sys/time.h: In function 'tvtosbt': /usr/include/sys/time.h:237:12: error: 'sbintime_t' undeclared (first use in this function) /usr/include/sys/time.h:237:23: error: expected ')' before 'tv' In file included from ../common.h:110:0, from swap.c:40: /usr/include/sys/time.h:134:17: error: unknown type name 'sbintime_t' /usr/include/sys/time.h:141:1: error: unknown type name 'sbintime_t' /usr/include/sys/time.h: In function 'bttosbt': /usr/include/sys/time.h:144:12: error: 'sbintime_t' undeclared (first use in this function) /usr/include/sys/time.h:144:12: note: each undeclared identifier is reported only once for each function it appears in /usr/include/sys/time.h:144:23: error: expected ')' before 'bt' /usr/include/sys/time.h: At top level: /usr/include/sys/time.h:148:9: error: unknown type name 'sbintime_t' /usr/include/sys/time.h:206:9: error: unknown type name 'sbintime_t' /usr/include/sys/time.h:216:1: error: unknown type name 'sbintime_t' /usr/include/sys/time.h: In function 'tstosbt': /usr/include/sys/time.h:219:12: error: 'sbintime_t' undeclared (first use in this function) /usr/include/sys/time.h:219:23: error: expected ')' before 'ts' /usr/include/sys/time.h: At top level: /usr/include/sys/time.h:224:9: error: unknown type name 'sbintime_t' /usr/include/sys/time.h:234:1: error: unknown type name 'sbintime_t' /usr/include/sys/time.h: In function 'tvtosbt': /usr/include/sys/time.h:237:12: error: 'sbintime_t' undeclared (first use in this function) /usr/include/sys/time.h:237:23: error: expected ')' before 'tv' --=20 pozdrawiam / with regards Pawe=B3 P=EAkala From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 20:43:38 2013 Return-Path: Delivered-To: current@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 A6AD9222 for ; Wed, 27 Mar 2013 20:43:38 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by mx1.freebsd.org (Postfix) with ESMTP id 7B912F04 for ; Wed, 27 Mar 2013 20:43:38 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id k1so9252082oag.19 for ; Wed, 27 Mar 2013 13:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=X/XJj5AzxQPTTJGKuznstuC2IA08fAOGrirF4gqPi2I=; b=YsFlAEhxzPG3gSWzGUZwjDAUEZBiBqDHOtef4L4MNfplu66qGD+e5R3uQVRVROo6OG izm/aGmncGzScRkFHTyguGICpI8H+QtnJo4Re/1JmiowZB+07BLFFi7COYQ1hpv0DKwC IgSTJb5OdgQEBMqgcndFFPEPqPkcpkhAs8TsCWDLL3g54AdAdGuZousTQPzHkya+8UVO T989l1ZFr9rUSKTTLH9wV58a8q8yf2fZ6xA07TlGza2pgMf3WQzl4XvEULhZvsA4Kzb7 FmyAqNnIAUgZB42Ro7eyBP5j30c1NYzkU0v33rEJFCNhrZyLm4nuHUyVYs9vOISu4YZf MB5Q== MIME-Version: 1.0 X-Received: by 10.182.144.73 with SMTP id sk9mr4533699obb.20.1364417012527; Wed, 27 Mar 2013 13:43:32 -0700 (PDT) Received: by 10.76.108.7 with HTTP; Wed, 27 Mar 2013 13:43:32 -0700 (PDT) Date: Wed, 27 Mar 2013 13:43:32 -0700 Message-ID: Subject: [RFC] vfs.read_min proposal From: Maksim Yevmenkin To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 20:43:38 -0000 Hello, i would like to get some reviews, opinions and/or comments on the patch below. a little bit background, as far as i understand, cluster_read() can initiate two disk i/o's: one for exact amount of data being requested (rounded up to a filesystem block size) and another for a configurable read ahead. read ahead data are always extra and do not super set data being requested. also, read ahead can be controlled via f_seqcount (on per descriptor basis) and/or vfs.read_max (global knob). in some cases and/or on some work loads it can be beneficial to bundle original data and read ahead data in one i/o request. in other words, read more than caller has requested, but only perform one larger i/o, i.e. super set data being requested and read ahead. === Index: trunk/cache/src/sys/kern/vfs_cluster.c =================================================================== diff -u -N -r515 -r1888 --- trunk/cache/src/sys/kern/vfs_cluster.c (.../vfs_cluster.c) (revision 515) +++ trunk/cache/src/sys/kern/vfs_cluster.c (.../vfs_cluster.c) (revision 1888) @@ -75,6 +75,10 @@ SYSCTL_INT(_vfs, OID_AUTO, read_max, CTLFLAG_RW, &read_max, 0, "Cluster read-ahead max block count"); +static int read_min = 1; +SYSCTL_INT(_vfs, OID_AUTO, read_min, CTLFLAG_RW, &read_min, 0, + "Cluster read min block count"); + /* Page expended to mark partially backed buffers */ extern vm_page_t bogus_page; @@ -169,13 +173,21 @@ } else { off_t firstread = bp->b_offset; int nblks; + long minread; KASSERT(bp->b_offset != NOOFFSET, ("cluster_read: no buffer offset")); ncontig = 0; /* + * Adjust totread if needed + */ + minread = read_min * size; + if (minread > totread) + totread = minread; + + /* * Compute the total number of blocks that we should read * synchronously. */ === thanks, max From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 20:54:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C222E624; Wed, 27 Mar 2013 20:54:49 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 966F4F72; Wed, 27 Mar 2013 20:54:49 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 10D80610E; Wed, 27 Mar 2013 16:54:41 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=Xkm2BYdxLGfKFsKbzfdHoLc3Auq/MNot9b/rF5QRF3CJl7qzU2Q32WmI34JG9t6ze GqRs1mXQR6Sy/fm5up66zysPw90kV+jKhek4qMNJ5e4MRnFgoRO3VwAB3BXfD0j Message-ID: <51535C90.7070507@protected-networks.net> Date: Wed, 27 Mar 2013 16:54:40 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Pawel Pekala Subject: Re: Ports including sys/time.h broken References: <20130327212819.1a28b2e1@FreeBSD.org> In-Reply-To: <20130327212819.1a28b2e1@FreeBSD.org> X-Enigmail-Version: 1.5.1 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 20:54:49 -0000 On 03/27/13 16:28, Pawel Pekala wrote: > For some time now (about month?) ports using sys/time.h include fail to > build and I`m sure they were building ok before. At least those seems > affected by this: > > math/atlas > math/openblas > x11-toolkits/c++-gtk-utils > > All fail with similar errors: > > /usr/include/sys/time.h:134:17: error: unknown type name 'sbintime_t' Rebuild whichever port of gcc you're using (gcc46?); it copies (and "fixes") some of the default include files for its own purposes. If it's behind, it'll be missing the addition of the sbintime_t typedef in types.h, imb From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 20:55:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A719780C; Wed, 27 Mar 2013 20:55:59 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 8459BFA2; Wed, 27 Mar 2013 20:55:59 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id DF0B837B512; Wed, 27 Mar 2013 15:45:59 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3Zbh7W1yHlzRS1; Wed, 27 Mar 2013 15:45:59 -0500 (CDT) Date: Wed, 27 Mar 2013 15:45:59 -0500 From: "Matthew D. Fuller" To: Pawel Pekala Subject: Re: Ports including sys/time.h broken Message-ID: <20130327204559.GO53758@over-yonder.net> References: <20130327212819.1a28b2e1@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130327212819.1a28b2e1@FreeBSD.org> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.6 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 20:55:59 -0000 On Wed, Mar 27, 2013 at 09:28:19PM +0100 I heard the voice of Pawel Pekala, and lo! it spake thus: > > For some time now (about month?) ports using sys/time.h include fail to > build and I`m sure they were building ok before. At least those seems > affected by this: > > math/atlas > math/openblas > x11-toolkits/c++-gtk-utils chromium also fails in a similar way. I presume that: > /usr/include/sys/time.h:134:17: error: unknown type name 'sbintime_t' is really the important bit; something needs sys/types.h to get sbintime_t and isn't pulling it in. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 21:02:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B2A7D9B4 for ; Wed, 27 Mar 2013 21:02:46 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7C1E167 for ; Wed, 27 Mar 2013 21:02:46 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id bv4so1167356qab.16 for ; Wed, 27 Mar 2013 14:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=PCGKOLUdJAU4bN6NYUEw/J9SZjHGQDt3+vZy9QH8WRc=; b=G6igMI+REvnvbtB+BAtwNpx4ZZQv/aeW1FG9ViJAnv3DvYlKQ3MkZIabz7UsM10dS/ p/v/xKIHaeVuynaM8FmIQNbOghq6YpQ2V3OYNSn+JV05DYuGXGZZ/WgGsGwQy4gKSrlc tfcMl/41wRu3vQZ+uRRQW/WPHkTkVd2pyt5lrC8IQeD5PFqj6h31YStOqCyw4d0jA33e W5K8cz8Bq0sm1FE5go9Qn99VyOfBoNegm6ol5HkkBsmFVSJYml5PboZbkO22wHbpQhN5 0YzNlfv45q9tey3ywaJLj2z33IR3I+6OIRjTeEalH0Khd+1VLtmbyoSJbQKxdO1c9vRZ 3m1w== MIME-Version: 1.0 X-Received: by 10.224.182.70 with SMTP id cb6mr14483098qab.80.1364418160270; Wed, 27 Mar 2013 14:02:40 -0700 (PDT) Received: by 10.49.50.67 with HTTP; Wed, 27 Mar 2013 14:02:40 -0700 (PDT) Date: Wed, 27 Mar 2013 14:02:40 -0700 Message-ID: Subject: CARP will not relinquish master state on one interface From: Freddie Cash To: FreeBSD-Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 21:02:46 -0000 Two systems running identical hardware and software (one system actually rsync'd from the other). Running 10-CURRENT just after the new CARP implementation went in: FreeBSD nexus2.sd73.bc.ca 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r245195: Thu Jan 10 10:29:16 PST 2013 root@nexus2.sd73.bc.ca:/usr/obj/usr/src/sys/NEXUS i386 Each box has 2 interfaces configured: em0 is part of an untagged vlan em1 is part of 8 tagged vlans The tagged vlan interfaces work correctly on both boxes, and CARP switches back and forth between MASTER and BACKUP correctly, whether it be via unplugging the network cable or via "ifconfig ... state" changes. The untagged vlan on both boxes will not relinquish MASTER status. If both boxes are up, both em0 interfaces are up, then both boxes configure the vhid as MASTER and nasty things happen to our traffic. The network configuration is: [remote site]------fibre link--------[fibre switch]----------[carp box1]--------[internet] [remote site]------fibre link----------/ \------------[carp box 2]-------/ [remote site]------fibre link---------/ The fibre links to the fibre switch are on untagged vlans; the link from the switch to each carp box is a tagged vlan trunk. And the link from each carp box to the Internet router is an untagged vlan. If only box1 is online, everything works correctly. If only box2 is online, everything works correctly. If both boxes are online, everything on em1 works correctly, and em0 shows MASTER on both boxes. If both boxes are online but em0 is down on 1 (either) box, everything works correctly. Running "tcpdump -n -i em0 -T carp | grep CARP" on both boxes shows the CARPv2 traffic from both boxes, with the correct vhid, advbase, advskew for each box. But the logs on box2 show "master down". I'm at a loss as to what to try next. Everything works for all the vlan interfaces on em1. But nothing I've tried works for em0. Within 2 seconds of the link showing UP, it becomes MASTER. On both boxes. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 21:07:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A23C9B06; Wed, 27 Mar 2013 21:07:03 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by mx1.freebsd.org (Postfix) with ESMTP id 510F7CD; Wed, 27 Mar 2013 21:07:03 +0000 (UTC) Received: by mail-ve0-f170.google.com with SMTP id 15so1885119vea.15 for ; Wed, 27 Mar 2013 14:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=j9wjKvs4dikIJWRyKIPSDN1/VND6Mx8K9ZTUX+EdQCs=; b=EwNmS5KvRnOSN7am7eplQfD1liur8ANZbzpPuoZ0dGUyxET6y3gG4Jc1Q6YODKAqjB 1Pyen7+pS9yyrb3++c6zixODE8JFdfv9GwV6VaIpxtfCSXi8Vq+MBBzsndPFEFT0IHMP USf2KRjf2catupD9kg00IUoUejFhBH4eIEXplB80lY//iXPC8Dp//bLDxhCG0A0CAtss FC1Oi9H5Nth1k8UsZ5Ay9967/9Sueo71R0pDwUDUYzgb0bnjt+pQa1ClAV5ZYgOLwyT0 dism3HI5HLo8gJCvqDgnna09B9BjtRdet0g+Tn4dd6kVVP+XVpQg4LQyFiiRZAnWVgkN VWEA== MIME-Version: 1.0 X-Received: by 10.220.8.75 with SMTP id g11mr24941789vcg.60.1364418422493; Wed, 27 Mar 2013 14:07:02 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.34.203 with HTTP; Wed, 27 Mar 2013 14:07:02 -0700 (PDT) In-Reply-To: <20130327212819.1a28b2e1@FreeBSD.org> References: <20130327212819.1a28b2e1@FreeBSD.org> Date: Wed, 27 Mar 2013 22:07:02 +0100 X-Google-Sender-Auth: vZA8Agx7ZPTKTOSTfjZe55NTtiQ Message-ID: Subject: Re: Ports including sys/time.h broken From: Davide Italiano To: Pawel Pekala Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 21:07:03 -0000 On Wed, Mar 27, 2013 at 9:28 PM, Pawel Pekala wrote: > For some time now (about month?) ports using sys/time.h include fail to > build and I`m sure they were building ok before. At least those seems > affected by this: > > math/atlas > math/openblas > x11-toolkits/c++-gtk-utils > > All fail with similar errors: > > /usr/include/sys/time.h:134:17: error: unknown type name 'sbintime_t' > /usr/include/sys/time.h:141:1: error: unknown type name 'sbintime_t' > /usr/include/sys/time.h: In function 'bttosbt': > /usr/include/sys/time.h:144:12: error: 'sbintime_t' undeclared (first > use in this function) /usr/include/sys/time.h:144:12: note: each > undeclared identifier is reported only once for each function it > appears in /usr/include/sys/time.h:144:23: error: expected ')' before > 'bt' /usr/include/sys/time.h: At top > level: /usr/include/sys/time.h:148:9: error: unknown type name > 'sbintime_t' /usr/include/sys/time.h:206:9: error: unknown type name > 'sbintime_t' /usr/include/sys/time.h:216:1: error: unknown type name > 'sbintime_t' /usr/include/sys/time.h: In function > 'tstosbt': /usr/include/sys/time.h:219:12: error: 'sbintime_t' > undeclared (first use in this function) /usr/include/sys/time.h:219:23: > error: expected ')' before 'ts' /usr/include/sys/time.h: At top > level: /usr/include/sys/time.h:224:9: error: unknown type name > 'sbintime_t' /usr/include/sys/time.h:234:1: error: unknown type name > 'sbintime_t' /usr/include/sys/time.h: In function > 'tvtosbt': /usr/include/sys/time.h:237:12: error: 'sbintime_t' > undeclared (first use in this function) /usr/include/sys/time.h:237:23: > error: expected ')' before 'tv' In file included > from ../common.h:110:0, from swap.c:40: /usr/include/sys/time.h:134:17: > error: unknown type name 'sbintime_t' /usr/include/sys/time.h:141:1: > error: unknown type name 'sbintime_t' /usr/include/sys/time.h: In > function 'bttosbt': /usr/include/sys/time.h:144:12: error: 'sbintime_t' > undeclared (first use in this function) /usr/include/sys/time.h:144:12: > note: each undeclared identifier is reported only once for each > function it appears in /usr/include/sys/time.h:144:23: error: expected > ')' before 'bt' /usr/include/sys/time.h: At top > level: /usr/include/sys/time.h:148:9: error: unknown type name > 'sbintime_t' /usr/include/sys/time.h:206:9: error: unknown type name > 'sbintime_t' /usr/include/sys/time.h:216:1: error: unknown type name > 'sbintime_t' /usr/include/sys/time.h: In function > 'tstosbt': /usr/include/sys/time.h:219:12: error: 'sbintime_t' > undeclared (first use in this function) /usr/include/sys/time.h:219:23: > error: expected ')' before 'ts' /usr/include/sys/time.h: At top > level: /usr/include/sys/time.h:224:9: error: unknown type name > 'sbintime_t' /usr/include/sys/time.h:234:1: error: unknown type name > 'sbintime_t' /usr/include/sys/time.h: In function > 'tvtosbt': /usr/include/sys/time.h:237:12: error: 'sbintime_t' > undeclared (first use in this function) /usr/include/sys/time.h:237:23: > error: expected ')' before 'tv' > > -- > pozdrawiam / with regards > Pawe=C5=82 P=C4=99kala > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " I'm able to build the ports you mentioned. Even if the informations you give are not enough to diagnose the problem (e.g. which version of which compiler was used to build) my guess is that you're using some version of gcc which is stale, i.e. it was build before changes to system headers. --=20 Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 21:22:19 2013 Return-Path: Delivered-To: freebsd-current@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 8C0442CA; Wed, 27 Mar 2013 21:22:19 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 02D281AF; Wed, 27 Mar 2013 21:22:18 +0000 (UTC) Received: by mail-ea0-f175.google.com with SMTP id r16so942618ead.34 for ; Wed, 27 Mar 2013 14:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=MTlu+UZE3yX57RtzoQ2geUxJlRwzGO2jEHD+sFXp0OY=; b=WJCxkl2Jk4UBSYzIVxhX9x/4MJ2+k8TtI9W8oacE/6YedYwpMwBf5hZvSRSAG0BXxu BJ/30KU6kqSbwK3v95AuzkrRYPxxIx+RAAceLdkLUMYyM+q0vS9IQzAPgqK55RI4QkDo jUatO4FOhNZKrH3fkV/8jlUmOy8lExQWVGBIqv8khlw09upONUw2Djt2h9k9p17ZZdB7 q/YPmb4HHhMxtWR0YRY3vuq+7tl51FDQQ0pvL5TpZs/pGmLlTt79Xq+yQUTZNeUR60rx OsC3c5bYH+1M4t6ssOIlZdGS2AM9cc2nDT4hwWUVHPvnypa6++RuHyCoiSMzpyshRChh gg1g== X-Received: by 10.15.36.135 with SMTP id i7mr39357547eev.34.1364419338167; Wed, 27 Mar 2013 14:22:18 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id h5sm33867550eem.1.2013.03.27.14.22.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Mar 2013 14:22:17 -0700 (PDT) Sender: Alexander Motin Message-ID: <51536306.5030907@FreeBSD.org> Date: Wed, 27 Mar 2013 23:22:14 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130326 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Any objections/comments on axing out old ATA stack? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 21:22:19 -0000 Hi. Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA stack, using only some controller drivers of old ata(4) by having `options ATA_CAM` enabled in all kernels by default. I have a wish to drop non-ATA_CAM ata(4) code, unused since that time from the head branch to allow further ATA code cleanup. Does any one here still uses legacy ATA stack (kernel explicitly built without `options ATA_CAM`) for some reason, for example as workaround for some regression? Does anybody have good ideas why we should not drop it now? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 21:23:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8C0C85D7 for ; Wed, 27 Mar 2013 21:23:59 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 52C9C1F1 for ; Wed, 27 Mar 2013 21:23:59 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id j3so3912654qcs.34 for ; Wed, 27 Mar 2013 14:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=mpRx0e8GhNblbxuTrKXSUk7S0O6f4KQatSiRAp6dtEg=; b=lD021Taw0G6AVp9gCVPiyQUJQroczsTYzImV7CQW1juKtjr8ZCKqV9yU5vkkFGZDLE Xoot7TvJ1EaoS1Ze39HRs4rG4n5iZu9oIfhJxvrtG4yJVU3XPl840egtVB0BrgdrApD3 klG5Ti9Z/PszHzGg2mGYrCSeWNmiz+dT/htexxntssEr64uaCUWlseypd9pn665pXRoT cKf0u/jTKHKvjH/AnSfLc7d/t4M1LpZ7WhZJFXvYmTf55niQRFmSzuKmOlhP5mB5vxpq iA/hnclqFBcSlZR3LixX6KSANbtdpy5dEr6mke1gZe9TlcPaAe95TNJxNr5tN+RpCdVS 4UOQ== MIME-Version: 1.0 X-Received: by 10.224.72.203 with SMTP id n11mr15023277qaj.72.1364419438828; Wed, 27 Mar 2013 14:23:58 -0700 (PDT) Received: by 10.49.50.67 with HTTP; Wed, 27 Mar 2013 14:23:58 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Mar 2013 14:23:58 -0700 Message-ID: Subject: Re: CARP will not relinquish master state on one interface From: Freddie Cash To: FreeBSD-Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 21:23:59 -0000 Figure it out. :( Was an IPFW rule. Seems the following two rules block CARP traffic: # Check for spoofed packets # Anti-spoof rules # These do roughly the same things: # verrevpath checks all incoming packets to see if the source IP matches any route on that interface # antispoof checks all incoming packets to make sure the source IP is not listed in a network of another interface $ipfw add 30 deny log ip from any to any not verrevpath in recv $if_public $ipfw add 40 deny log ip from any to any not antispoof in recv $if_public Removing those two rules on both boxes makes em0 fail-over correctly between the two. On Wed, Mar 27, 2013 at 2:02 PM, Freddie Cash wrote: > Two systems running identical hardware and software (one system actually > rsync'd from the other). Running 10-CURRENT just after the new CARP > implementation went in: > > FreeBSD nexus2.sd73.bc.ca 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r245195: > Thu Jan 10 10:29:16 PST 2013 root@nexus2.sd73.bc.ca:/usr/obj/usr/src/sys/NEXUS > i386 > > Each box has 2 interfaces configured: > em0 is part of an untagged vlan > em1 is part of 8 tagged vlans > > The tagged vlan interfaces work correctly on both boxes, and CARP switches > back and forth between MASTER and BACKUP correctly, whether it be via > unplugging the network cable or via "ifconfig ... state" changes. > > The untagged vlan on both boxes will not relinquish MASTER status. If > both boxes are up, both em0 interfaces are up, then both boxes configure > the vhid as MASTER and nasty things happen to our traffic. > > The network configuration is: > > [remote site]------fibre link--------[fibre switch]----------[carp > box1]--------[internet] > [remote site]------fibre link----------/ \------------[carp box > 2]-------/ > [remote site]------fibre link---------/ > > The fibre links to the fibre switch are on untagged vlans; the link from > the switch to each carp box is a tagged vlan trunk. And the link from each > carp box to the Internet router is an untagged vlan. > > If only box1 is online, everything works correctly. > > If only box2 is online, everything works correctly. > > If both boxes are online, everything on em1 works correctly, and em0 shows > MASTER on both boxes. > > If both boxes are online but em0 is down on 1 (either) box, everything > works correctly. > > Running "tcpdump -n -i em0 -T carp | grep CARP" on both boxes shows the > CARPv2 traffic from both boxes, with the correct vhid, advbase, advskew for > each box. But the logs on box2 show "master down". > > I'm at a loss as to what to try next. Everything works for all the vlan > interfaces on em1. But nothing I've tried works for em0. Within 2 seconds > of the link showing UP, it becomes MASTER. On both boxes. > > -- > Freddie Cash > fjwcash@gmail.com > -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 21:32:48 2013 Return-Path: Delivered-To: freebsd-current@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 8A1C0ACC; Wed, 27 Mar 2013 21:32:48 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 6EC99274; Wed, 27 Mar 2013 21:32:48 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r2RLWgZ5067899; Wed, 27 Mar 2013 14:32:42 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r2RLWgDb067898; Wed, 27 Mar 2013 14:32:42 -0700 (PDT) (envelope-from sgk) Date: Wed, 27 Mar 2013 14:32:42 -0700 From: Steve Kargl To: Alexander Motin Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130327213242.GA67876@troutmask.apl.washington.edu> References: <51536306.5030907@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51536306.5030907@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 21:32:48 -0000 On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: > Hi. > > Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA > stack, using only some controller drivers of old ata(4) by having > `options ATA_CAM` enabled in all kernels by default. I have a wish to > drop non-ATA_CAM ata(4) code, unused since that time from the head > branch to allow further ATA code cleanup. > > Does any one here still uses legacy ATA stack (kernel explicitly built > without `options ATA_CAM`) for some reason, for example as workaround > for some regression? Yes, I use the legacy ATA stack. > Does anybody have good ideas why we should not drop > it now? Because it works? -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 21:35:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1F16FD02; Wed, 27 Mar 2013 21:35:40 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id 874162B0; Wed, 27 Mar 2013 21:35:39 +0000 (UTC) Received: by mail-ea0-f177.google.com with SMTP id q14so1277741eaj.36 for ; Wed, 27 Mar 2013 14:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5Pjf4xUI6LXyQJOAE3BPcpHJpsONYfX76qISjUgI0go=; b=jAig+KYkeWbaa5aIkgoSeiC5/1EzomU0KTBnAiUPELIksc4ylMvF+ITbt9rEXnsBE+ n8SneM8hNBPJsNB7jNkohYRBjkxG8B7Vi8LWtgj86UXxCSj5T1ojXNtEupSolH9/pRRg HoayXc7Yl0cpN0/YDsifRKIGeRtSuPe3++0ukYkVLH3d9129SfsYukCxtn1hZhjVu5CS B2tT9iOUeSJcgiQes/XzJ2fdw1I5zKHM017xk8ickm4Ay5SNNHl8bmGLGApQqG2G8cYg 4sOxyQpjrsjGY9wOQNJLH566bNXWa/iEkptD8L0YUtfW8BBxXO3S/jbK1wuMVuG3GfCo 5OpA== X-Received: by 10.15.23.193 with SMTP id h41mr60107376eeu.17.1364420138641; Wed, 27 Mar 2013 14:35:38 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id d47sm33895142eem.9.2013.03.27.14.35.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Mar 2013 14:35:37 -0700 (PDT) Sender: Alexander Motin Message-ID: <51536627.7090005@FreeBSD.org> Date: Wed, 27 Mar 2013 23:35:35 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130326 Thunderbird/17.0.4 MIME-Version: 1.0 To: Steve Kargl Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <20130327213242.GA67876@troutmask.apl.washington.edu> In-Reply-To: <20130327213242.GA67876@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 21:35:40 -0000 On 27.03.2013 23:32, Steve Kargl wrote: > On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: >> Hi. >> >> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA >> stack, using only some controller drivers of old ata(4) by having >> `options ATA_CAM` enabled in all kernels by default. I have a wish to >> drop non-ATA_CAM ata(4) code, unused since that time from the head >> branch to allow further ATA code cleanup. >> >> Does any one here still uses legacy ATA stack (kernel explicitly built >> without `options ATA_CAM`) for some reason, for example as workaround >> for some regression? > > Yes, I use the legacy ATA stack. On 9.x or HEAD where new one is default? >> Does anybody have good ideas why we should not drop >> it now? > > Because it works? Any problems with new one? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 21:38:06 2013 Return-Path: Delivered-To: freebsd-current@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 34E14F2E; Wed, 27 Mar 2013 21:38:06 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by mx1.freebsd.org (Postfix) with ESMTP id CB9052E6; Wed, 27 Mar 2013 21:38:05 +0000 (UTC) Received: by mail-qc0-f178.google.com with SMTP id d10so3246411qca.9 for ; Wed, 27 Mar 2013 14:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8l2hnzsiGPYkT/lBsqaD4YPEoz/05Lntri6kz1olZN0=; b=ECvu2JCx1phA0VTOZrC8PfeOGkUkU2DTt1wkjToWE0MdyqfsFpemnvCkxj+/ETmI2c dgu8Oi2SPd/EzjXhMnJ0Lhl1ZwKkq802BWRDVdMZHJTOx2ZnEMI3UpmMeA/SKXhDDUFJ 6B90OC+Q/L1GU6ckT2zIQaB1llYVrP1olvSXkbzKjgsCNkC078KawhXy50AEw8iimnHU mSGg4MA0aeaREbjeBKGmm+vJEIxLnoKUxh6f0TZwiZndK2+MTbyhTHOkqpg9LDWcVUxn qNOUQUPTP9qZsMgbedWohsCG4kctVMfxwcE+ay2Bb9WH80oZ6ZGAXsLIdMlXs/eRdsPI e2OA== MIME-Version: 1.0 X-Received: by 10.49.118.137 with SMTP id km9mr17683224qeb.34.1364420285394; Wed, 27 Mar 2013 14:38:05 -0700 (PDT) Received: by 10.49.50.67 with HTTP; Wed, 27 Mar 2013 14:38:05 -0700 (PDT) In-Reply-To: <20130327213242.GA67876@troutmask.apl.washington.edu> References: <51536306.5030907@FreeBSD.org> <20130327213242.GA67876@troutmask.apl.washington.edu> Date: Wed, 27 Mar 2013 14:38:05 -0700 Message-ID: Subject: Re: Any objections/comments on axing out old ATA stack? From: Freddie Cash To: Steve Kargl Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Alexander Motin , FreeBSD-Current , FreeBSD Stable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 21:38:06 -0000 On Wed, Mar 27, 2013 at 2:32 PM, Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: > > Hi. > > > > Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA > > stack, using only some controller drivers of old ata(4) by having > > `options ATA_CAM` enabled in all kernels by default. I have a wish to > > drop non-ATA_CAM ata(4) code, unused since that time from the head > > branch to allow further ATA code cleanup. > > > > Does any one here still uses legacy ATA stack (kernel explicitly built > > without `options ATA_CAM`) for some reason, for example as workaround > > for some regression? > > Yes, I use the legacy ATA stack. > > You're missing the reason for why you're running the old ATA stack. Do you have hardware that doesn't work with ATA_CAM? Have you not tried ATA_CAM on that box? Some other reason? -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 21:49:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9F3313D2 for ; Wed, 27 Mar 2013 21:49:32 +0000 (UTC) (envelope-from pawelbsd@gmail.com) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 3C4F938D for ; Wed, 27 Mar 2013 21:49:32 +0000 (UTC) Received: by mail-ea0-f170.google.com with SMTP id a15so3753442eae.29 for ; Wed, 27 Mar 2013 14:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type :content-transfer-encoding; bh=NX0mFiPMfdWcDSvoXVrO4h20QTGa2Trz2mmhgOcpGV0=; b=B6+38JhcsNlkpQTDAyXxhhy+32OSHE5uCScbIIYL6iUXXinSPJPE/eNUxbDb75xa+E yg/jkr/T8LFtg+4So72Y9ZYMVYrA3lVAWkqwcP1nSRb0yYNOLrYT14eIWUncX41NOU2W Jdg+dcDO6T+ZTTcelSkJmkyKxDh6of724AgI4zbjdAVKzraMKxxvbQC/LIfPYE/eza/L QDSgm7eq6ro3bf9JEJo9HvxuOAWZHZ4ZjUupA8dTvunc3HjEwcgo5OF2GAHyj1+pmzFd tQ88/vlqyt5bjJKOcTl2I+yu9+L3erMn/Lrx8OqukbKQx1ntQaLSzH/0hvKYPOiur6wQ DLEA== X-Received: by 10.15.101.200 with SMTP id bp48mr38733249eeb.38.1364420971372; Wed, 27 Mar 2013 14:49:31 -0700 (PDT) Received: from localhost ([176.109.164.5]) by mx.google.com with ESMTPS id u44sm33967331eel.7.2013.03.27.14.49.29 (version=SSLv3 cipher=RC4-SHA bits=128/128); Wed, 27 Mar 2013 14:49:30 -0700 (PDT) Sender: =?UTF-8?B?UGF3ZcWCIFDEmWthbGE=?= Date: Wed, 27 Mar 2013 22:46:49 +0100 From: Pawel Pekala To: Michael Butler Subject: Re: Ports including sys/time.h broken Message-ID: <20130327224649.013b070d@FreeBSD.org> In-Reply-To: <51535C90.7070507@protected-networks.net> References: <20130327212819.1a28b2e1@FreeBSD.org> <51535C90.7070507@protected-networks.net> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 21:49:32 -0000 Dnia 2013-03-27, o godz. 16:54:40 Michael Butler napisa=B3(a): >Rebuild whichever port of gcc you're using (gcc46?); it copies (and >"fixes") some of the default include files for its own purposes. If >it's behind, it'll be missing the addition of the sbintime_t typedef >in types.h, That was it. After rebuilding lang/gcc46 port everything builds again. Sorry for the noise... --=20 pozdrawiam / with regards Pawe=B3 P=EAkala From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 22:05:14 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D638A7CA; Wed, 27 Mar 2013 22:05:14 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id A2357634; Wed, 27 Mar 2013 22:05:14 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r2RM5ETw068095; Wed, 27 Mar 2013 15:05:14 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r2RM5Eov068094; Wed, 27 Mar 2013 15:05:14 -0700 (PDT) (envelope-from sgk) Date: Wed, 27 Mar 2013 15:05:14 -0700 From: Steve Kargl To: Alexander Motin Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130327220514.GA68064@troutmask.apl.washington.edu> References: <51536306.5030907@FreeBSD.org> <20130327213242.GA67876@troutmask.apl.washington.edu> <51536627.7090005@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51536627.7090005@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 22:05:14 -0000 On Wed, Mar 27, 2013 at 11:35:35PM +0200, Alexander Motin wrote: > On 27.03.2013 23:32, Steve Kargl wrote: > > On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: > >> Hi. > >> > >> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA > >> stack, using only some controller drivers of old ata(4) by having > >> `options ATA_CAM` enabled in all kernels by default. I have a wish to > >> drop non-ATA_CAM ata(4) code, unused since that time from the head > >> branch to allow further ATA code cleanup. > >> > >> Does any one here still uses legacy ATA stack (kernel explicitly built > >> without `options ATA_CAM`) for some reason, for example as workaround > >> for some regression? > > > > Yes, I use the legacy ATA stack. > > On 9.x or HEAD where new one is default? Head. > >> Does anybody have good ideas why we should not drop > >> it now? > > > > Because it works? > > Any problems with new one? > Last time I tested the new one, and this was several months ago, the system (a Dell Latitude D530 laptop) would not boot. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 22:07:25 2013 Return-Path: Delivered-To: freebsd-current@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 02D0CA02 for ; Wed, 27 Mar 2013 22:07:25 +0000 (UTC) (envelope-from fbsd@opal.com) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by mx1.freebsd.org (Postfix) with ESMTP id CCB21679 for ; Wed, 27 Mar 2013 22:07:24 +0000 (UTC) Received: from pool-141-154-241-44.bos.east.verizon.net ([141.154.241.44] helo=homobox.opal.com) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UKyV4-000Ata-5M for freebsd-current@freebsd.org; Wed, 27 Mar 2013 22:07:18 +0000 Received: from shibato (shibato.opal.com [IPv6:2001:470:8cb8:4:221:63ff:fe5a:c9a7]) (authenticated bits=0) by homobox.opal.com (8.14.4/8.14.4) with ESMTP id r2RM7FxE045868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 27 Mar 2013 18:07:15 -0400 (EDT) (envelope-from fbsd@opal.com) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 141.154.241.44 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/H1NO0TNWKN2YM89/VQ1xZ Date: Wed, 27 Mar 2013 18:07:14 -0400 From: "J.R. Oldroyd" To: freebsd-current@freebsd.org Subject: DTrace of radeonkms on 9.1 Message-ID: <20130327180714.5beae7d6@shibato> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (homobox.opal.com [IPv6:2001:470:8cb8:4::1]); Wed, 27 Mar 2013 18:07:15 -0400 (EDT) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, RP_MATCHES_RCVD shortcircuit=no autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on homobox.opal.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 22:07:25 -0000 Is there any known magic involved in getting DTrace to do its thing on 9.1-release? I am trying to use it to debug a memory leak problem with the radeonkms driver under 9.x. Firstly, the following sequence works normally: boot system kldload drm2 kldload radeonkms start xorg stop xorg kldunload radeonkms kldunload drm2 The problem is that, when using xterm, there is a memory leak which shows as the Free mem counter in "top" reducing rapidly. The usual printf debugging isn't helping because we are in a heavily multi-threaded part of the driver and the printfs are being interleaved in the kernel buffer. DTrace's function boundary probes would be a big help if I could only get them to work. I've built a dtrace kernel per the instructions in the handbook and on the DTrace wiki page. I would now like to do this: boot system kldload dtraceall kldload drm2 dtrace -o dtrace.log -s script.d (the script will use fbt probes on various functions currently in the drm2 module) kldload radeonkms start xorg and do various things that provoke the leak stop xorg kldunload radeonkms kill the dtrace script kldunload drm2 kldunload dtraceall then go look at the log results. But, the system is stopping dead shortly after the radeonkms load. It also stops dead if I load radeonkms without starting the dtrace script. The presence of the dtraceall module appears to be causing the radeonkms module load to fail. Now the radeonkms module does initialize and switch the console to the graphics mode before the system stops. There is about 5-10 sec of what looks like the normal driver init sequence before the system stops. When the system stops there is no panic. It just stops dead. No keyboard/mouse, no netowrk/ssh - dead. A hard power-off and reboot is needed afterwards. It's perhaps worth mentioning that the leak I am trying to trace is probably not a simple malloc/free leak. There are no leak messages in the log after the normal module load/unload sequence. This driver also does VM allocs and manages its own pages and the problem could be there. Any suggestions on how to persuade DTrace to work would be great. Thanks, -jr From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 22:14:24 2013 Return-Path: Delivered-To: freebsd-current@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 1B3DBBEF for ; Wed, 27 Mar 2013 22:14:24 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from virtual.feral.com (virtual.feral.com [216.224.170.83]) by mx1.freebsd.org (Postfix) with ESMTP id DDB306CE for ; Wed, 27 Mar 2013 22:14:23 +0000 (UTC) Received: from [192.168.135.7] (76-14-49-207.sf-cable.astound.net [76.14.49.207]) by virtual.feral.com (8.14.4/8.14.4) with ESMTP id r2RMDGDG013177 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 27 Mar 2013 15:13:17 -0700 Message-ID: <51536EFD.4060202@freebsd.org> Date: Wed, 27 Mar 2013 15:13:17 -0700 From: Matthew Jacob Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> In-Reply-To: <51536306.5030907@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (virtual.feral.com [216.224.170.83]); Wed, 27 Mar 2013 15:13:17 -0700 (PDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mjacob@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 22:14:24 -0000 On 3/27/2013 2:22 PM, Alexander Motin wrote: > Hi. > > Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA > stack, using only some controller drivers of old ata(4) by having > `options ATA_CAM` enabled in all kernels by default. I have a wish to > drop non-ATA_CAM ata(4) code, unused since that time from the head > branch to allow further ATA code cleanup. > > Does any one here still uses legacy ATA stack (kernel explicitly built > without `options ATA_CAM`) for some reason, for example as workaround > for some regression? Does anybody have good ideas why we should not > drop it now? > Some people have expressed performance concerns about ATA_CAM. I have not validated those concerns. Does anyone know of any? From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 22:22:21 2013 Return-Path: Delivered-To: freebsd-current@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 814C3D4E; Wed, 27 Mar 2013 22:22:21 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by mx1.freebsd.org (Postfix) with ESMTP id E84FA70C; Wed, 27 Mar 2013 22:22:20 +0000 (UTC) Received: by mail-ea0-f176.google.com with SMTP id h10so3727313eaj.35 for ; Wed, 27 Mar 2013 15:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=n0ILBAJEmYbSebiH5E2NvzEIyIZJLagZ2UlCP0JUtPQ=; b=bE/qe0cuopf6flXjvatl/TZSxCGIBzdnQkqxz3D4pEBfSM7SuXkaMKTLhFKi9yxWpT mq6I2VASwx2bLuWWtoysndKVrX1uroYMhbPBakq2y4QNrjO6EaPwHFsX4BXXsrvNGESW W7BclSdwcUbjUKLRozzEJNpoeD2cogBV9ROgpE7tV0PONRJqmFCR3WitOVYykJngeDtO ZktGt0nkGQx4/QBWzFZf2E5KVu4InNRYYUEuQgvB1qmOgJ8xzlNQgSu+CP4mhy08ktc6 FR7kpiHNfLt2DARyLxJmaw3SJOjSt10AK9uBV0JO32y64vUQ9EECuaHV4ItjNT5fMsqB xs4w== X-Received: by 10.14.179.5 with SMTP id g5mr60308104eem.41.1364422939559; Wed, 27 Mar 2013 15:22:19 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id t4sm34133642eel.0.2013.03.27.15.22.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Mar 2013 15:22:18 -0700 (PDT) Sender: Alexander Motin Message-ID: <51537113.6080406@FreeBSD.org> Date: Thu, 28 Mar 2013 00:22:11 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130326 Thunderbird/17.0.4 MIME-Version: 1.0 To: Steve Kargl Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <20130327213242.GA67876@troutmask.apl.washington.edu> <51536627.7090005@FreeBSD.org> <20130327220514.GA68064@troutmask.apl.washington.edu> In-Reply-To: <20130327220514.GA68064@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 22:22:21 -0000 On 28.03.2013 00:05, Steve Kargl wrote: > On Wed, Mar 27, 2013 at 11:35:35PM +0200, Alexander Motin wrote: >> On 27.03.2013 23:32, Steve Kargl wrote: >>> On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: >>>> Hi. >>>> >>>> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA >>>> stack, using only some controller drivers of old ata(4) by having >>>> `options ATA_CAM` enabled in all kernels by default. I have a wish to >>>> drop non-ATA_CAM ata(4) code, unused since that time from the head >>>> branch to allow further ATA code cleanup. >>>> >>>> Does any one here still uses legacy ATA stack (kernel explicitly built >>>> without `options ATA_CAM`) for some reason, for example as workaround >>>> for some regression? >>> >>> Yes, I use the legacy ATA stack. >> >> On 9.x or HEAD where new one is default? > > Head. > >>>> Does anybody have good ideas why we should not drop >>>> it now? >>> >>> Because it works? >> >> Any problems with new one? >> > > Last time I tested the new one, and this was several months > ago, the system (a Dell Latitude D530 laptop) would not boot. Probably we should just fix that. Any more info? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 22:32:20 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4BDE0FD7; Wed, 27 Mar 2013 22:32:20 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by mx1.freebsd.org (Postfix) with ESMTP id BA14977B; Wed, 27 Mar 2013 22:32:19 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id d17so1035919eek.11 for ; Wed, 27 Mar 2013 15:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=trCb8Bk46mAXZWhQtKKr1naJfbEYtv7ZQVV24aSc2+o=; b=dknBOfb6cOr/vRzPU5W+KEgVkp5DkBN2ZDgeKneDNusKBhiq8oTSgAf+FG0clZHTSA LfptC+iyrS1MXVdjbfj79EMX2kUIi93i9MYTIh0d8Q+WpLdJ8R9H/C+D1yWv8a/TOZru 1ZmJl8v6ixmJpQCZKdFBzuMe4a7vVBVSyWw4vuSmlQ49otGt7o31CcSdjyQwsFU4kZqO 8i55j2szT0hS0cNWvBAGXpUvtmHaObJKq7NBEiIo3rremkB+NX4sXeK5ysNeUWCt2vZq K4+U/TaXUgekVLus9Dstx7s2iIAKkxMYfL/tbHlvohbwPFP3+sqL3GmqDB71uPef2qs9 T0eA== MIME-Version: 1.0 X-Received: by 10.15.22.76 with SMTP id e52mr51992429eeu.7.1364423532864; Wed, 27 Mar 2013 15:32:12 -0700 (PDT) Received: by 10.223.127.134 with HTTP; Wed, 27 Mar 2013 15:32:12 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Mar 2013 17:32:12 -0500 Message-ID: Subject: Re: [RFC] small VM patch to review From: Alan Cox To: Maksim Yevmenkin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: alc@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 22:32:20 -0000 On Wed, Mar 20, 2013 at 12:24 PM, Maksim Yevmenkin wrote: > hello, > > would anyone object to the following small patch? > > Yes, I don't think that we should entirely disable vm_lowmem events or uma_reclaim() on pass == 0 calls to vm_pageout_scan(). However, I do think it's reasonable to significantly reduce the frequency at which we do both. My recollection is that UMA only releases idle pages from zones when uma_reclaim() is called. In other words, there is no mechanism like a high water mark on the number of idle pages in a zone that triggers the return of some of these idle pages to the VM system. Given this, turning off vm_lowmem events or uma_reclaim() calls on pass == 0 is fine for machines under a steady-state workload. But, if there are changes in the workload then we won't adapt our overall memory allocation to the new workload. Specifically, the loser would be the file cache/inactive queue, because even under moderate memory pressure we typically meet our goals on pass 0 by reclaiming file cache/inactive queue pages. So, instead of repurposing unused pages from UMA to the file cache/inactive queue, we would leave them lingering in UMA. (Also note I've not said anything about the ZFS ARC, because I'm not exactly sure how it uses the vm_lowmem events. This may or may not be a problem. I don't know.) > == > > Index: vm_pageout.c > =================================================================== > --- vm_pageout.c (revision 248560) > +++ vm_pageout.c (working copy) > @@ -882,14 +882,17 @@ > > vm_pageout_init_marker(&marker, PQ_INACTIVE); > > - /* > - * Decrease registered cache sizes. > - */ > - EVENTHANDLER_INVOKE(vm_lowmem, 0); > - /* > - * We do this explicitly after the caches have been drained above. > - */ > - uma_reclaim(); > + if (pass) { > + /* > + * Decrease registered cache sizes. > + */ > + EVENTHANDLER_INVOKE(vm_lowmem, 0); > + /* > + * We do this explicitly after the caches have > + * been drained above. > + */ > + uma_reclaim(); > + } > > /* > * The addl_page_shortage is the number of temporarily > > == > > the idea is to not invoke lowmem handler etc. on first pass in > vm_pageout_scan(). it saves a few CPU cycles on a relatively busy > webserver with moderate amount of RAM serving large-ish files. > > thanks, > max > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 22:43:07 2013 Return-Path: Delivered-To: freebsd-current@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 6227C2DC; Wed, 27 Mar 2013 22:43:07 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 4566A800; Wed, 27 Mar 2013 22:43:07 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r2RMh6G1068345; Wed, 27 Mar 2013 15:43:06 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r2RMh6uF068344; Wed, 27 Mar 2013 15:43:06 -0700 (PDT) (envelope-from sgk) Date: Wed, 27 Mar 2013 15:43:06 -0700 From: Steve Kargl To: Alexander Motin Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130327224306.GA68321@troutmask.apl.washington.edu> References: <51536306.5030907@FreeBSD.org> <20130327213242.GA67876@troutmask.apl.washington.edu> <51536627.7090005@FreeBSD.org> <20130327220514.GA68064@troutmask.apl.washington.edu> <51537113.6080406@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51537113.6080406@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 22:43:07 -0000 On Thu, Mar 28, 2013 at 12:22:11AM +0200, Alexander Motin wrote: > On 28.03.2013 00:05, Steve Kargl wrote: > > > > Last time I tested the new one, and this was several months > > ago, the system (a Dell Latitude D530 laptop) would not boot. > > Probably we should just fix that. Any more info? > I can't remember all the details. I intended to try again as work was being done on the new code at the time. I never got around to it as my laptop worked fine with the old code and unfortunately I got busy with work and family. Reading the freebsd-current mailing lists suggests that now is not the time to be a hero. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 23:10:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C69E49CC for ; Wed, 27 Mar 2013 23:10:10 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by mx1.freebsd.org (Postfix) with ESMTP id 90583908 for ; Wed, 27 Mar 2013 23:10:10 +0000 (UTC) Received: by mail-qe0-f49.google.com with SMTP id 1so4827209qec.8 for ; Wed, 27 Mar 2013 16:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=wTu6pX70Bi78QG0sAkx+JOtSe0hFhZy9qaO9Mh5aUdM=; b=1A2xPKS3CMIe8AIzTml65SY+9WtuD5FYROqPZvqAny632XGJdxtp5Edkc/0DfpHG/8 fjOvmWMqSMQpqCpPrAXcZCJibWZj28qxK64EdkqjYoe16XJ7YALQ+nJqA5w9ySPbCmdp sLZ8RMEsVN0JrFcR26qBlDs8S2Bk18HgWcgi4bG79XnRGmLpCuEeDM0fZYlG0dW0xZHv hm4HyA5Wg06o8jbRn0NlbL97NwD/MjiAT+WBBn9G5mGqb+JeBNkW3feXs9COwEbv7oA1 XHee+tqw7WLH9qy1cjb9GAbVjwnPOLBBH/bkyx5/54zROWUSTTMdwBWYQPspxhblgcay s6eg== MIME-Version: 1.0 X-Received: by 10.49.24.101 with SMTP id t5mr15560773qef.37.1364425803902; Wed, 27 Mar 2013 16:10:03 -0700 (PDT) Received: by 10.49.50.67 with HTTP; Wed, 27 Mar 2013 16:10:03 -0700 (PDT) Date: Wed, 27 Mar 2013 16:10:03 -0700 Message-ID: Subject: Anyone have scripts for managing interfaces under new CARP setup? From: Freddie Cash To: FreeBSD-Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 23:10:10 -0000 Just curious if anyone has any scripts for managing fail-over of multiple interfaces using the new CARP setup in 10-CURRENT. Fail-over of all CARP vhids associated with a single interface is working correctly. But, I have 2 separate, physical interfaces running with CARP, and want to fail-over everything if one of the links (or boxes) goes down. Figured I'd ask around to see if anyone has done something like this already. I've been playing with devd.conf settings and logging events, but don't have anything written up to do the actual switch yet. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 00:43:09 2013 Return-Path: Delivered-To: freebsd-current@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 3AD7CAD7; Thu, 28 Mar 2013 00:43:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 7DF7AD0E; Thu, 28 Mar 2013 00:43:08 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hm11so2922217wib.3 for ; Wed, 27 Mar 2013 17:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ivtuaT2yM1fc6t7KWtfse8XM2dZ63RCxv6d7jOoPtT4=; b=Hln6Zgx3FTz1+hXq18bR8jQHlO80dauPPLSVQnj9kUcLiV4a31JYM6HsiloSnS6s6h TaykxWochrB6BK+SWWfGfs+VwsnEEHrMq+1KqYEzdWtZSi9+XWD9zHBNO7ZlUyvlqUhm siNNSHH49Dkdz3A43LMJUBwJTYq6gh1alWwtxCvFSfbcfymOsdHSSaqpUuRI7bxCpZpO 9H0Qbv7cvaI02/etPDzigZ6y9I+fWbEp15YEPBOU4sRm4cbUPrJzvuq2r713kbGwxhs1 9So08Q/g+WvmQO5zjoATzpwijq7lxXzVgFHenBfZRz/vZ7t1pksw2eKJ7I5YyCDxquWC dp1A== MIME-Version: 1.0 X-Received: by 10.180.13.34 with SMTP id e2mr13092100wic.29.1364431387607; Wed, 27 Mar 2013 17:43:07 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Wed, 27 Mar 2013 17:43:07 -0700 (PDT) In-Reply-To: <51536306.5030907@FreeBSD.org> References: <51536306.5030907@FreeBSD.org> Date: Wed, 27 Mar 2013 17:43:07 -0700 X-Google-Sender-Auth: 2YHBwHaFP9ql5MKmHWlQbxxp-io Message-ID: Subject: Re: Any objections/comments on axing out old ATA stack? From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 00:43:09 -0000 My main concern with the new stuff is that it requires CAM and that's reasonably big compared to the standalone ATA code. It'd be nice if we could slim down the CAM stack a bit first; it makes embedding it on the smaller devices really freaking painful. Thanks, adrian From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 01:45:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E8835573; Thu, 28 Mar 2013 01:45:26 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by mx1.freebsd.org (Postfix) with ESMTP id 9CE7EEF8; Thu, 28 Mar 2013 01:45:26 +0000 (UTC) Received: by mail-qe0-f45.google.com with SMTP id b4so4903106qen.4 for ; Wed, 27 Mar 2013 18:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=FS3mgNsZgh0E87awtM6qhaNO4G4sQSrgSsEaYl5XQpM=; b=x3oOiB0/sk3p0HvK/f9peduRw0JRH6nvxRIxknknFIFdolUfHm2/ZlHEEUWpdX2ufM o1tNmif3thx14P6hFFY/pT4aVkvMG9y1wZ1FBfxvd61g0ELD/4D3bY9JLaS+uyTO7Ibc Tct5RR+5ly9oudNzD1E29LL1c6Tte9/10zeTt14vMmE0vxKj8W9IhMyQfE7l07IuNTR6 8jrUbevS5Gbv1dPjDknB2ya6USsX6YZZz7DlWsakqTrx/3imis+ClRmPgGhwc4HZZ7yX nEbk7PKnxovWoj6ImuwwG4tSL76jkRpwbW8y+uX7atXp3QmX8ZD/LXUfWXn1zJq+PuiM I1Iw== MIME-Version: 1.0 X-Received: by 10.224.33.14 with SMTP id f14mr15790772qad.69.1364434672068; Wed, 27 Mar 2013 18:37:52 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.229.253.201 with HTTP; Wed, 27 Mar 2013 18:37:51 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Mar 2013 18:37:51 -0700 X-Google-Sender-Auth: 1Ya9g8m8aXcXnucHqY84C-jbqYY Message-ID: Subject: [RFC] use a shared lock for VOP_GETEXTATTR From: mdf@FreeBSD.org To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Content-Type: multipart/mixed; boundary=20cf3074b9a4f2ad3c04d8f23328 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 01:45:27 -0000 --20cf3074b9a4f2ad3c04d8f23328 Content-Type: text/plain; charset=ISO-8859-1 VOP_GETEXTATTR is currently called with an exclusive lock, which seems like overkill for what is essentially a read operation. I had a look over the various in-tree filesystems and it didn't look like any of them will have a problem if a shared-mode lock is used for vop_getextattr. Does anyone know otherwise? Is someone using extended attributes regularly who can test this? [sorry if this is a duplicate; I first sent from my non-FreeBSD mail] Thanks, matthew --20cf3074b9a4f2ad3c04d8f23328 Content-Type: application/octet-stream; name="0001-Use-a-shared-lock-for-VOP_GETEXTATTR-as-it-is-a-read.patch" Content-Disposition: attachment; filename="0001-Use-a-shared-lock-for-VOP_GETEXTATTR-as-it-is-a-read.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_het94ldq0 RnJvbSBhYTZkNmM3MTZiZDE5Y2UzMmUzYjkwODcyN2ZiZGE2NWQzNDViN2FiIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBNYXR0aGV3IEZsZW1pbmcgPG1kZkBGcmVlQlNELm9yZz4KRGF0 ZTogV2VkLCAyNyBNYXIgMjAxMyAxODoyMzoxNyAtMDcwMApTdWJqZWN0OiBbUEFUQ0hdIFVzZSBh IHNoYXJlZCBsb2NrIGZvciBWT1BfR0VURVhUQVRUUiwgYXMgaXQgaXMgYSByZWFkLWxpa2Ugb3Bl cmF0aW9uLgoKTUZDIGFmdGVyOgkxIHdlZWsKLS0tCiBzeXMva2Vybi92ZnNfZXh0YXR0ci5jIHwg ICAgMiArLQogc3lzL2tlcm4vdmZzX3Zub3BzLmMgICB8ICAgIDIgKy0KIDIgZmlsZXMgY2hhbmdl ZCwgMiBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3N5cy9rZXJu L3Zmc19leHRhdHRyLmMgYi9zeXMva2Vybi92ZnNfZXh0YXR0ci5jCmluZGV4IDg1ZmM4MzkuLjcw MGE3MGMgMTAwNjQ0Ci0tLSBhL3N5cy9rZXJuL3Zmc19leHRhdHRyLmMKKysrIGIvc3lzL2tlcm4v dmZzX2V4dGF0dHIuYwpAQCAtMzIxLDE3ICszMjEsMTcgQEAgZXh0YXR0cl9nZXRfdnAoc3RydWN0 IHZub2RlICp2cCwgaW50IGF0dHJuYW1lc3BhY2UsIGNvbnN0IGNoYXIgKmF0dHJuYW1lLAogICAg IHZvaWQgKmRhdGEsIHNpemVfdCBuYnl0ZXMsIHN0cnVjdCB0aHJlYWQgKnRkKQogewogCXN0cnVj dCB1aW8gYXVpbywgKmF1aW9wOwogCXN0cnVjdCBpb3ZlYyBhaW92OwogCXNzaXplX3QgY250Owog CXNpemVfdCBzaXplLCAqc2l6ZXA7CiAJaW50IGVycm9yOwogCi0Jdm5fbG9jayh2cCwgTEtfRVhD TFVTSVZFIHwgTEtfUkVUUlkpOworCXZuX2xvY2sodnAsIExLX1NIQVJFRCB8IExLX1JFVFJZKTsK IAogCS8qCiAJICogU2xpZ2h0bHkgdW51c3VhbCBzZW1hbnRpY3M6IGlmIHRoZSB1c2VyIHByb3Zp ZGVzIGEgTlVMTCBkYXRhCiAJICogcG9pbnRlciwgdGhleSBkb24ndCB3YW50IHRvIHJlY2VpdmUg dGhlIGRhdGEsIGp1c3QgdGhlIG1heGltdW0KIAkgKiByZWFkIGxlbmd0aC4KIAkgKi8KIAlhdWlv cCA9IE5VTEw7CiAJc2l6ZXAgPSBOVUxMOwpkaWZmIC0tZ2l0IGEvc3lzL2tlcm4vdmZzX3Zub3Bz LmMgYi9zeXMva2Vybi92ZnNfdm5vcHMuYwppbmRleCBjOGY4MzJmLi42ODQ5NzMwIDEwMDY0NAot LS0gYS9zeXMva2Vybi92ZnNfdm5vcHMuYworKysgYi9zeXMva2Vybi92ZnNfdm5vcHMuYwpAQCAt MTc1MywxNyArMTc1MywxNyBAQCB2bl9leHRhdHRyX2dldChzdHJ1Y3Qgdm5vZGUgKnZwLCBpbnQg aW9mbGcsIGludCBhdHRybmFtZXNwYWNlLAogCWF1aW8udWlvX2lvdmNudCA9IDE7CiAJYXVpby51 aW9fcncgPSBVSU9fUkVBRDsKIAlhdWlvLnVpb19zZWdmbGcgPSBVSU9fU1lTU1BBQ0U7CiAJYXVp by51aW9fdGQgPSB0ZDsKIAlhdWlvLnVpb19vZmZzZXQgPSAwOwogCWF1aW8udWlvX3Jlc2lkID0g KmJ1ZmxlbjsKIAogCWlmICgoaW9mbGcgJiBJT19OT0RFTE9DS0VEKSA9PSAwKQotCQl2bl9sb2Nr KHZwLCBMS19FWENMVVNJVkUgfCBMS19SRVRSWSk7CisJCXZuX2xvY2sodnAsIExLX1NIQVJFRCB8 IExLX1JFVFJZKTsKIAogCUFTU0VSVF9WT1BfTE9DS0VEKHZwLCAiSU9fTk9ERUxPQ0tFRCB3aXRo IG5vIHZwIGxvY2sgaGVsZCIpOwogCiAJLyogYXV0aG9yaXplIGF0dHJpYnV0ZSByZXRyaWV2YWwg YXMga2VybmVsICovCiAJZXJyb3IgPSBWT1BfR0VURVhUQVRUUih2cCwgYXR0cm5hbWVzcGFjZSwg YXR0cm5hbWUsICZhdWlvLCBOVUxMLCBOVUxMLAogCSAgICB0ZCk7CiAKIAlpZiAoKGlvZmxnICYg SU9fTk9ERUxPQ0tFRCkgPT0gMCkKLS0gCjEuNy4zLjIKCg== --20cf3074b9a4f2ad3c04d8f23328-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 03:14:06 2013 Return-Path: Delivered-To: current@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 EED05A84 for ; Thu, 28 Mar 2013 03:14:06 +0000 (UTC) (envelope-from marcelorossi@gmail.com) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 7BAAB336 for ; Thu, 28 Mar 2013 03:14:06 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id fq12so16936006lab.19 for ; Wed, 27 Mar 2013 20:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=TlcAJq7T6vX7NtxZFuqx2b8q3NZIOuL7PcQ1RRzhGek=; b=s0mQH24xi/CzxZFVLfEN8nvnOEtNKUN4CgCS5gdXI0sXrh6Hps3BBCJJHTWhAkJr0z PAPGxBNd2nfUmpSzpe6aUYzAwC92MZcuf6l9iUKUaoDlVfv1Y6bTpkMtuu8/toPPOIzY Zl1xLQNSEgRzS6HAOWxIQuDIY1rSf9WTPSp7gXTbRfhVDmRAwAQGls070HvtNlFQHAJb qrFnsQjtlLPRFfDWHYuQH3wfp06xCd8dimdnWRTnHWrWsVqyT+2hIRNzjos+dqWWPVe0 TmJ9Ykc05Lfg1fiCuoduPcYyIvb+GR6WahzF25k5pACN2Tmi9YdkbVh0wnbPFxPyXSE3 aKpA== X-Received: by 10.152.123.194 with SMTP id mc2mr655870lab.7.1364440445407; Wed, 27 Mar 2013 20:14:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.21.227 with HTTP; Wed, 27 Mar 2013 20:13:25 -0700 (PDT) In-Reply-To: References: From: "Marcelo/Porks" Date: Thu, 28 Mar 2013 00:13:25 -0300 Message-ID: Subject: Re: sysutils/fusefs-kmod problem in CURRENT To: current Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 03:14:07 -0000 On Wed, Mar 27, 2013 at 2:03 AM, Attilio Rao wrote: > On Wed, Mar 27, 2013 at 4:00 AM, Marcelo/Porks wrote: >> >> On Mar 22, 2013 1:02 AM, "Attilio Rao" wrote: >>> >>> On Fri, Mar 22, 2013 at 2:02 AM, Marcelo/Porks >>> wrote: >>> > Hi, I'm facing an error compiling the sysutils/fusefs-kmod. >>> > >>> > I'm using the CURRENT from today (2013-03-21). >>> > >>> > Can someone using the CURRENT confirm if this also happens in your >>> > system? >>> >>> CURRENT should not allow you to build fusefs-kmod at all. >>> Use "option FUSEFS" from your kernel config. >>> >> >> Sorry, maybe I didnt understand what you said. I tried to use in my kernel >> conf: >> >> options FUSEFS >> option FUSEFS >> options fusefs >> option fusefs > > Sorry, my fault, I mis-pelled it. it is: > options FUSE > Oh Thanks it worked (compiling the option in the kernel) And it also worked using the module like Andrey V. Elsukov said. # kldload fuse.ko Thanks again. -- Marcelo Rossi "This e-mail is provided "AS IS" with no warranties, and confers no rights." "I have nothing against God, I just hate His fan club" From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 05:32:09 2013 Return-Path: Delivered-To: freebsd-current@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 3A5911A1; Thu, 28 Mar 2013 05:32:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id A74138FE; Thu, 28 Mar 2013 05:32:08 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2S5W5u4047614; Thu, 28 Mar 2013 07:32:05 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2S5W5u4047614 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2S5W5T1047613; Thu, 28 Mar 2013 07:32:05 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 28 Mar 2013 07:32:05 +0200 From: Konstantin Belousov To: mdf@FreeBSD.org Subject: Re: [RFC] use a shared lock for VOP_GETEXTATTR Message-ID: <20130328053205.GF3794@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MZTSf4zogrZAfwtT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 05:32:09 -0000 --MZTSf4zogrZAfwtT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 27, 2013 at 06:37:51PM -0700, mdf@FreeBSD.org wrote: > VOP_GETEXTATTR is currently called with an exclusive lock, which seems > like overkill for what is essentially a read operation. I had a look > over the various in-tree filesystems and it didn't look like any of > them will have a problem if a shared-mode lock is used for > vop_getextattr. >=20 > Does anyone know otherwise? Is someone using extended attributes > regularly who can test this? I think this change should be fine. At least it seems to for UFS. What other filesystems did you audited ? --MZTSf4zogrZAfwtT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRU9XUAAoJEJDCuSvBvK1BKGgP+warWw/Mo9pcf9zIj+cBE3PZ 9sdXjWUcCKqIM1pOFlURH2odq9P1+5Va7wP2n5jYBYUdri0SoCfQ/C86jvUkvaNS xKrMtNXIq38eKCCWU34+rFNhF9bg+rS0KS8FXI5+nnsbDsWaB0PeCXBSrfudeTv+ HFfGFmGLQvJdzYfvZ6LWInWw8BhgyrLX0/A/xAnPwlZDLrw1RbtAL51XRH/PHliv KfsxlyMoiTqJLDR7jX0EPiIcg+WENyUgwQ/SJTZ4i3a52y8eXLlSzHIhrinHPmnE b3iCc3TTZCRJYx0cOJMjLzk/d1kIVTYgRZ+Sdap1UjHeFw+E8Ps3Ev2T3BCzYCzG eTZBdffzcDW6xxc7zYfNDeiUvKEq3uKsBY9AyQeZWn5vEOsFSYFXc4TV/Q/OT+VM /hcdbgqcjDh2rXVJo1XHkpb+6mMZN4HWOo/r8Q+jVk2q/5RCmeQCN8tmbmWI4jIr j/hYA4zvH6cuEJ3iDghDV4urgb11VZ/Ybyx3At26J4jlUqW0B9MvIbvyRTnGiQt5 A95rE6tR0sfiMCRYrXs+pWR82DboNtv5PaQ6Wo5M+/hcweU1xjuJ/ris6EJVXUuU vcHp2dGMabmPzzFNPuN6lLh0VtOx1M57wJ/3ZV6xdDdZAeKrI0/GoU+CvqT/ONPR pPPVG6W9gpNZ8OpRB1sl =4mql -----END PGP SIGNATURE----- --MZTSf4zogrZAfwtT-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 05:40:18 2013 Return-Path: Delivered-To: freebsd-current@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 37B5379C; Thu, 28 Mar 2013 05:40:18 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by mx1.freebsd.org (Postfix) with ESMTP id E260B977; Thu, 28 Mar 2013 05:40:17 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id b40so4068412qcq.10 for ; Wed, 27 Mar 2013 22:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4ffQ2MMb83OZN/KkxP4eFjkYTLMRzM7AvYSi8QxhsyA=; b=sovq3PEQrj0Xy/kr+XQ3HvLWs6oOsKsjXDE8A6ycE7CO44BKgckGg+mKSeSQwYCiAl MnRMvdPO0pMB+v9+tvVcqk0n6KQdMLaMK40+jZWGWTyjS1aFrqaG7OO9g2fekb6QZLRg r+T614tgfScnn7+8G+o5hw1XrwSeTQU+Znvmnpjysr3VpfdL2NR7ElcPUb3Y4KP+mgcD lAHLYLEkEgMHNczMCCsYk1bsD5r4T6JjdAweCNxYnaSodXhn7yxtxPFw825tvaKq0ttC aZ0qBCRlS0HcrQbCC5JDyEcujMgyMRlrfhVytzvbJowZKuLyOHUSdJmp3YlJqQHbpV1b SYpA== MIME-Version: 1.0 X-Received: by 10.49.25.202 with SMTP id e10mr20122125qeg.49.1364449217129; Wed, 27 Mar 2013 22:40:17 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.229.253.201 with HTTP; Wed, 27 Mar 2013 22:40:16 -0700 (PDT) In-Reply-To: <20130328053205.GF3794@kib.kiev.ua> References: <20130328053205.GF3794@kib.kiev.ua> Date: Wed, 27 Mar 2013 22:40:16 -0700 X-Google-Sender-Auth: zJ7rBN1qp88H4U2Qe7csJJKC1E4 Message-ID: Subject: Re: [RFC] use a shared lock for VOP_GETEXTATTR From: mdf@FreeBSD.org To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 05:40:18 -0000 On Wed, Mar 27, 2013 at 10:32 PM, Konstantin Belousov wrote: > On Wed, Mar 27, 2013 at 06:37:51PM -0700, mdf@FreeBSD.org wrote: >> VOP_GETEXTATTR is currently called with an exclusive lock, which seems >> like overkill for what is essentially a read operation. I had a look >> over the various in-tree filesystems and it didn't look like any of >> them will have a problem if a shared-mode lock is used for >> vop_getextattr. >> >> Does anyone know otherwise? Is someone using extended attributes >> regularly who can test this? > > I think this change should be fine. At least it seems to for UFS. > > What other filesystems did you audited ? I looked over zfs, pseudofs, unionfs, ffs/ufs. None seemed to have any asserts on the lock type nor anything that looked like it would try to modify anything. zfs, I think it was, even used VOP_ISLOCKED to get the lock type in one path (but I think that was after a lookup(), so it may have been on a different vnode). Cheers, matthew From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 05:56:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D3E8ECD9; Thu, 28 Mar 2013 05:56:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7461D9EC; Thu, 28 Mar 2013 05:56:27 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2S5uN0K052050; Thu, 28 Mar 2013 07:56:23 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2S5uN0K052050 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2S5uNj4052049; Thu, 28 Mar 2013 07:56:23 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 28 Mar 2013 07:56:23 +0200 From: Konstantin Belousov To: mdf@FreeBSD.org Subject: Re: [RFC] use a shared lock for VOP_GETEXTATTR Message-ID: <20130328055623.GG3794@kib.kiev.ua> References: <20130328053205.GF3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XsW72sOHJGfuGe9h" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 05:56:27 -0000 --XsW72sOHJGfuGe9h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 27, 2013 at 10:40:16PM -0700, mdf@FreeBSD.org wrote: > On Wed, Mar 27, 2013 at 10:32 PM, Konstantin Belousov > wrote: > > On Wed, Mar 27, 2013 at 06:37:51PM -0700, mdf@FreeBSD.org wrote: > >> VOP_GETEXTATTR is currently called with an exclusive lock, which seems > >> like overkill for what is essentially a read operation. I had a look > >> over the various in-tree filesystems and it didn't look like any of > >> them will have a problem if a shared-mode lock is used for > >> vop_getextattr. > >> > >> Does anyone know otherwise? Is someone using extended attributes > >> regularly who can test this? > > > > I think this change should be fine. At least it seems to for UFS. > > > > What other filesystems did you audited ? >=20 > I looked over zfs, pseudofs, unionfs, ffs/ufs. None seemed to have > any asserts on the lock type nor anything that looked like it would > try to modify anything. zfs, I think it was, even used VOP_ISLOCKED > to get the lock type in one path (but I think that was after a > lookup(), so it may have been on a different vnode). VOPs usually do not assert the lock state, unless the explicit unlock/lock is done, or some other call is made which asserts the lock. If zfs is fine =66rom your inspection, I think that the patch can be committed without an issue. --XsW72sOHJGfuGe9h Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRU9uHAAoJEJDCuSvBvK1B5+oP/1A+CLA6d4Uj4cBEZH71gsPd nI4QzQ8Mr1zOP2yLH9clbtT29NDXb/zwbFRzHFh4R8UD8mnQzr6Aebkt+obzctCz a3JT6WF4D+uCPL+E5cUTaVpaA/8guQO+MlP3ECN21KqqDI5mAfHEshSLcbHeJi2Q MAmWID6Wn0ONIk2027pjP2rayQE0ECpKEoEuahPNeHjTecstY2EKA4nITXb+dVLj mgC7zpHlLeH0PD6/PM47RBIc/AqTi6B2Mj3swYuIEUo2PJYMzNG+pdl9IYg+VNzZ KklxpSNRkBwUGfPGLiIKxR3Bvr404x3/C4rBWGyyIDYs75q5C4pUfUnKImJ8aerg fp4gfwSZ58xMV5yNUIPQRuKh7pQdf6ha5Kc4THEBKk4Cl4KL0SCRk1NS/vnn+IIR nDYog1g6h421Nvx9EIP/SoyYHlyni0J8Q9DDvu6eQEyUGwQdBkWqg8aKXF/7pRFr cjJTPHZ23zCbNQF+h4kIyrkqgcUYr1PQeCw77YN17rhfR7gfgAVoUxdCI6B+Un62 Pl/X9vte63S/LpbAu584ItlOrVFzFMXoYM+lcTmqra2InKtl0CtyzUg7lDrsuii8 j1SnN/EPuWJB8VNIWHp4n9O/Z5iHURbJLz1sT0POp+bocFiTHa8Nas8GGB8wcCYQ pqdGv5PhGVeLuQWQm+nT =2MpL -----END PGP SIGNATURE----- --XsW72sOHJGfuGe9h-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 07:17:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 649EE672; Thu, 28 Mar 2013 07:17:30 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 9DEE0144; Thu, 28 Mar 2013 07:17:29 +0000 (UTC) Received: by mail-ea0-f170.google.com with SMTP id a15so3697879eae.15 for ; Thu, 28 Mar 2013 00:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KcmKTCcAzgq9u2w8+sbUQZoVLFSXWg9DkzxmO5V22a4=; b=IaBz7Zkw++sJimL0ahuUpQPHgW/k+RSBYn5WDGz3C2zKwfHbnhZ9lORWGd6Gg9hZcG L1LeLfrNwEjlfF5x8nhZJsbddI5MLBUvfOmzvErRKtZUxw54iHNtYR3zEgaMHMuc9hgO JUZI5UOG3MASuPdRCe8EM2gq3jHBjS8rw71mWeMPrLqaecIBKmdvKVaIxhlE4OKqtdZi 9wypwLZ1gr7aWRGkXnsynv9HXTAsvF03UjpRbe0F09Tcq4VMWRU7teJm+x2HJYs1K6v+ 3ym0zEl1NTYTygeMUevR1bdRFrHg2jN9xUrvCZ2QeR3FtqYaaoT5y62d3Nw/O2pvboeY +x1A== X-Received: by 10.14.183.198 with SMTP id q46mr55684955eem.1.1364455048826; Thu, 28 Mar 2013 00:17:28 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id bc1sm24376334eeb.11.2013.03.28.00.17.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Mar 2013 00:17:28 -0700 (PDT) Sender: Alexander Motin Message-ID: <5153EE86.8000801@FreeBSD.org> Date: Thu, 28 Mar 2013 09:17:26 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130326 Thunderbird/17.0.4 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 07:17:30 -0000 On 28.03.2013 02:43, Adrian Chadd wrote: > My main concern with the new stuff is that it requires CAM and that's > reasonably big compared to the standalone ATA code. > > It'd be nice if we could slim down the CAM stack a bit first; it makes > embedding it on the smaller devices really freaking painful. Are there many boards now with ATA, but without USB? But I agree, it should be checked. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 07:29:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9B4F996F; Thu, 28 Mar 2013 07:29:49 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 29B4B1C8; Thu, 28 Mar 2013 07:29:49 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r2S7ThTb078636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Mar 2013 00:29:43 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r2S7Thma078635; Thu, 28 Mar 2013 00:29:43 -0700 (PDT) (envelope-from jmg) Date: Thu, 28 Mar 2013 00:29:43 -0700 From: John-Mark Gurney To: Alexander Motin Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130328072943.GC76354@funkthat.com> Mail-Followup-To: Alexander Motin , Adrian Chadd , freebsd-current@freebsd.org, freebsd-stable@freebsd.org References: <51536306.5030907@FreeBSD.org> <5153EE86.8000801@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5153EE86.8000801@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 28 Mar 2013 00:29:43 -0700 (PDT) Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 07:29:49 -0000 Alexander Motin wrote this message on Thu, Mar 28, 2013 at 09:17 +0200: > On 28.03.2013 02:43, Adrian Chadd wrote: > >My main concern with the new stuff is that it requires CAM and that's > >reasonably big compared to the standalone ATA code. > > > >It'd be nice if we could slim down the CAM stack a bit first; it makes > >embedding it on the smaller devices really freaking painful. > > Are there many boards now with ATA, but without USB? But I agree, it > should be checked. The net4501 board has ATA but no USB.. Also, depending upon use, you might choose to not include USB, but use ATA, or not use umass, but the rest of USB... Someone on a list was talking about trying to get FreeBSD down on a really small system, 16MB ram... /me thinks of the old wd driver. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 07:52:14 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 03FB1150 for ; Thu, 28 Mar 2013 07:52:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 566062D3 for ; Thu, 28 Mar 2013 07:52:13 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2S7q9gr072406; Thu, 28 Mar 2013 09:52:09 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2S7q9gr072406 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2S7q90K072405; Thu, 28 Mar 2013 09:52:09 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 28 Mar 2013 09:52:09 +0200 From: Konstantin Belousov To: Maksim Yevmenkin Subject: Re: [RFC] vfs.read_min proposal Message-ID: <20130328075209.GL3794@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DX8dQmZ7BQ17qNYG" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 07:52:14 -0000 --DX8dQmZ7BQ17qNYG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 27, 2013 at 01:43:32PM -0700, Maksim Yevmenkin wrote: > Hello, >=20 > i would like to get some reviews, opinions and/or comments on the patch b= elow. >=20 > a little bit background, as far as i understand, cluster_read() can > initiate two disk i/o's: one for exact amount of data being requested > (rounded up to a filesystem block size) and another for a configurable > read ahead. read ahead data are always extra and do not super set data > being requested. also, read ahead can be controlled via f_seqcount (on > per descriptor basis) and/or vfs.read_max (global knob). >=20 > in some cases and/or on some work loads it can be beneficial to bundle > original data and read ahead data in one i/o request. in other words, > read more than caller has requested, but only perform one larger i/o, > i.e. super set data being requested and read ahead. The totread argument to the cluster_read() is supplied by the filesystem to indicate how many data in the current request is specified. Always overriding this information means two things: - you fill the buffer and page cache with potentially unused data. For some situations, like partial reads, it would be really bad. - you increase the latency by forcing the reader to wait for the whole cluster which was not asked for. So it looks as very single- and special-purpose hack. Besides, the global knob is obscure and probably would not have any use except your special situation. Would a file flag be acceptable for you ? What is the difference in the numbers you see, and what numbers ? Is it targeted for read(2) optimizations, or are you also concerned with the read-ahead done at the fault time ? >=20 > =3D=3D=3D >=20 > Index: trunk/cache/src/sys/kern/vfs_cluster.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > diff -u -N -r515 -r1888 > --- trunk/cache/src/sys/kern/vfs_cluster.c (.../vfs_cluster.c) (revision = 515) > +++ trunk/cache/src/sys/kern/vfs_cluster.c (.../vfs_cluster.c) (revision = 1888) > @@ -75,6 +75,10 @@ > SYSCTL_INT(_vfs, OID_AUTO, read_max, CTLFLAG_RW, &read_max, 0, > "Cluster read-ahead max block count"); >=20 > +static int read_min =3D 1; > +SYSCTL_INT(_vfs, OID_AUTO, read_min, CTLFLAG_RW, &read_min, 0, > + "Cluster read min block count"); > + > /* Page expended to mark partially backed buffers */ > extern vm_page_t bogus_page; >=20 > @@ -169,13 +173,21 @@ > } else { > off_t firstread =3D bp->b_offset; > int nblks; > + long minread; >=20 > KASSERT(bp->b_offset !=3D NOOFFSET, > ("cluster_read: no buffer offset")); >=20 > ncontig =3D 0; >=20 > /* > + * Adjust totread if needed > + */ > + minread =3D read_min * size; > + if (minread > totread) > + totread =3D minread; > + > + /* > * Compute the total number of blocks that we should read > * synchronously. > */ >=20 > =3D=3D=3D >=20 > thanks, > max > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --DX8dQmZ7BQ17qNYG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIbBAEBAgAGBQJRU/aoAAoJEJDCuSvBvK1B+4oP9160js6W/5YvNaBOzagF54r/ wkLqFtQaBKU9QAMBY2mFOsTAvdVObrWnyHRW5PJxiHH3ZSb5qrwx6ChzcQcG73y1 ZsoUCVAKvqdEhbMpC5rgPIAxMgg96FdxkmojCDl4GBgXGOPd0tari/EJmYdnoBLB QmusXB8cnSTp162SClUGviKUpMMiON05aBH03Xx+xmPYuuwmTsoHCrTE2vTM39o2 6J/iC7wPHUcZdBKwGjAj3fDdgl0ptrh0fwPDYjSzQHhTKnZO8d8vs6MpKVaLdtUg yx8XMzme39piEGMBZN24hVNnqCyox6o/mhuD6VEC0n5G4p/OpgJmP9EEQfSi62Mv s+C58LEQuvTqgOZ3h31AhiqeL8yxf+B43mY/x6TodeKMlWz2831KIeNQ2avm5HQM U6nXeWLsbjeYMvuWLqwVH3guVcoaQwYxm6GDOLBtfNbu3J7kuYba0T8a72eEFWtj +yfopxKzGRTc9wAaKHK17hepb36YdNY6hoKt0qTGbrnRPQbuUeieV1OZ/53ufyDs WIgJHO8+4TLVey6bIXS+CqaeV4dWLYc6mdJmeMgK1vqJY7yDZT7GJaQ7SmXmfwdJ qfkq82IAdlxbttdhM83TTp0cozP/QoPPeszgsJw6/GBjCLhBGbyC0RhFYM51WXBM wo9UgUdATPhTX5c4sAQ= =I/Jw -----END PGP SIGNATURE----- --DX8dQmZ7BQ17qNYG-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 08:37:08 2013 Return-Path: Delivered-To: freebsd-current@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 B26DE15A; Thu, 28 Mar 2013 08:37:08 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C387F706; Thu, 28 Mar 2013 08:37:07 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA04091; Thu, 28 Mar 2013 10:36:59 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UL8KR-000DVf-H1; Thu, 28 Mar 2013 10:36:59 +0200 Message-ID: <5154012A.4010602@FreeBSD.org> Date: Thu, 28 Mar 2013 10:36:58 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130321 Thunderbird/17.0.4 MIME-Version: 1.0 To: FreeBSD Current , freebsd-hackers@FreeBSD.org Subject: big change to devfs rules path matching References: <5150B598.7050700@FreeBSD.org> <5150B71B.6060106@FreeBSD.org> In-Reply-To: <5150B71B.6060106@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 08:37:08 -0000 on 25/03/2013 22:44 Andriy Gapon said the following: > > Would like to ask for opinions on this topic... > Please read this PR for context: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122838 > Especially Jaakko's insightful description of the problem. So I would like to commit the following patch sooner rather than later: http://people.freebsd.org/~avg/devfs_rule.diff The only difference from the Jaakko's patch in the PR is FNM_PATHNAME. Please review and test. Especially if you rely on any non-trivial devfs rules. Thank you. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 09:53:32 2013 Return-Path: Delivered-To: freebsd-current@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 CC15A2D6 for ; Thu, 28 Mar 2013 09:53:32 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (ns25270.ovh.net [91.121.29.24]) by mx1.freebsd.org (Postfix) with ESMTP id 9689AAA9 for ; Thu, 28 Mar 2013 09:53:32 +0000 (UTC) Received: from [46.255.176.2] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UL9V8-000GHq-UJ for freebsd-current@freebsd.org; Thu, 28 Mar 2013 10:52:07 +0100 Message-ID: <515412C1.6020906@FreeBSD.org> Date: Thu, 28 Mar 2013 10:52:01 +0100 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: DTrace of radeonkms on 9.1 References: <20130327180714.5beae7d6@shibato> In-Reply-To: <20130327180714.5beae7d6@shibato> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2SXANXKWQKVWHSLVCJGUN" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 09:53:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2SXANXKWQKVWHSLVCJGUN Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 27.03.2013 23:07, J.R. Oldroyd wrote: > I've built a dtrace kernel per the instructions in the handbook and > on the DTrace wiki page. I would now like to do this: >=20 > boot system > kldload dtraceall > kldload drm2 > dtrace -o dtrace.log -s script.d > (the script will use fbt probes on various > functions currently in the drm2 module) > kldload radeonkms > start xorg and do various things that provoke the leak > stop xorg > kldunload radeonkms > kill the dtrace script > kldunload drm2 > kldunload dtraceall >=20 > then go look at the log results. >=20 > But, the system is stopping dead shortly after the radeonkms load. I would like to add that the same scenario works perfectly on 10-CURRENT.= --=20 Jean-S=E9bastien P=E9dron ------enig2SXANXKWQKVWHSLVCJGUN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFUEsYACgkQa+xGJsFYOlPyTQCgxz53kI4UElS0fx5WqSA3W/y3 nQkAn0+nT7aHSQOqMPtDOm5/5J2tARZw =jNZz -----END PGP SIGNATURE----- ------enig2SXANXKWQKVWHSLVCJGUN-- From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 14:00:56 2013 Return-Path: Delivered-To: freebsd-current@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 A3738671; Thu, 28 Mar 2013 14:00:56 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by mx1.freebsd.org (Postfix) with ESMTP id 7D04E9B8; Thu, 28 Mar 2013 14:00:56 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1ULDNv-0004sI-MW; Thu, 28 Mar 2013 14:00:55 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r2SE0rsD012965; Thu, 28 Mar 2013 08:00:53 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+xGW/8y2pQO9Q/fZJPv2OI Subject: Re: Any objections/comments on axing out old ATA stack? From: Ian Lepore To: Alexander Motin In-Reply-To: <5153EE86.8000801@FreeBSD.org> References: <51536306.5030907@FreeBSD.org> <5153EE86.8000801@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 Mar 2013 08:00:53 -0600 Message-ID: <1364479253.36972.77.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 14:00:56 -0000 On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote: > On 28.03.2013 02:43, Adrian Chadd wrote: > > My main concern with the new stuff is that it requires CAM and that's > > reasonably big compared to the standalone ATA code. > > > > It'd be nice if we could slim down the CAM stack a bit first; it makes > > embedding it on the smaller devices really freaking painful. > > Are there many boards now with ATA, but without USB? But I agree, it > should be checked. > It's not necessarily what the boards have but how they're used. We use industrial SBCs at work that have ata compact flash sockets on the board which we do use, and usb interfaces which we don't use. I've never tested the new ata+cam stuff on some of these boards, most based on Cyrix, Via, Geode, and VortexD86 chipsets. The older ata code works, but not always very well -- for example, we usually have to set hw.ata.ata_dma=0 for absolutely no reason we've ever been able to figure out except that if we leave it enabled we get DMA errors and panics on some CF cards and not on others. I have no idea whether to expect such things to be better, worse, or no different by changing to the ata+cam way of doing things (but I don't really have time to do extensive testing right now either). -- Ian From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 14:09:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D6DD0928; Thu, 28 Mar 2013 14:09:01 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 92B1EA27; Thu, 28 Mar 2013 14:09:01 +0000 (UTC) Received: from terran (unknown [192.168.99.1]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 375B0C4947; Thu, 28 Mar 2013 16:08:54 +0200 (EET) Date: Thu, 28 Mar 2013 16:09:53 +0200 From: Aleksandr Rybalko To: Adrian Chadd Subject: Re: Any objections/comments on axing out old ATA stack? Message-Id: <20130328160953.f0ca035403fb4b4adddfe6e0@ddteam.net> In-Reply-To: References: <51536306.5030907@FreeBSD.org> X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 14:09:01 -0000 On Wed, 27 Mar 2013 17:43:07 -0700 Adrian Chadd wrote: > My main concern with the new stuff is that it requires CAM and that's > reasonably big compared to the standalone ATA code. > > It'd be nice if we could slim down the CAM stack a bit first; it makes > embedding it on the smaller devices really freaking painful. /me never seen embedded devices with ATA/SATA and less than 64MB of RAM. (i386/i486 old machines does not count :) ) I'm missing something? > > Thanks, > > > > adrian > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Aleksandr Rybalko From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 15:29:27 2013 Return-Path: Delivered-To: freebsd-current@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 BC47AE3A; Thu, 28 Mar 2013 15:29:27 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 8A858EA4; Thu, 28 Mar 2013 15:29:26 +0000 (UTC) Received: from [127.0.0.1] (Scott4long@pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id r2SFTOXL046107; Thu, 28 Mar 2013 09:29:24 -0600 (MDT) (envelope-from scottl@samsco.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Any objections/comments on axing out old ATA stack? From: Scott Long In-Reply-To: Date: Thu, 28 Mar 2013 09:29:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <969B2F75-EBBF-40F3-B805-323E1BFAD7F9@samsco.org> References: <51536306.5030907@FreeBSD.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1503) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Alexander Motin , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 15:29:27 -0000 On Mar 27, 2013, at 6:43 PM, Adrian Chadd wrote: > My main concern with the new stuff is that it requires CAM and that's > reasonably big compared to the standalone ATA code. >=20 =46rom a code execution standpoint? No, it's not. > It'd be nice if we could slim down the CAM stack a bit first; it makes > embedding it on the smaller devices really freaking painful. >=20 =46rom a code segment size standpoint, there's definitely some stuff = that should be made modular and optional. Scott From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 15:31:28 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D9048147; Thu, 28 Mar 2013 15:31:28 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 8DA41EDC; Thu, 28 Mar 2013 15:31:28 +0000 (UTC) Received: from [127.0.0.1] (Scott4long@pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id r2SFVQhk046128; Thu, 28 Mar 2013 09:31:26 -0600 (MDT) (envelope-from scottl@samsco.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Any objections/comments on axing out old ATA stack? From: Scott Long In-Reply-To: <1364479253.36972.77.camel@revolution.hippie.lan> Date: Thu, 28 Mar 2013 09:31:26 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51536306.5030907@FreeBSD.org> <5153EE86.8000801@FreeBSD.org> <1364479253.36972.77.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1503) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Alexander Motin , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, Adrian Chadd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 15:31:28 -0000 On Mar 28, 2013, at 8:00 AM, Ian Lepore wrote: > On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote: >> On 28.03.2013 02:43, Adrian Chadd wrote: >>> My main concern with the new stuff is that it requires CAM and = that's >>> reasonably big compared to the standalone ATA code. >>>=20 >>> It'd be nice if we could slim down the CAM stack a bit first; it = makes >>> embedding it on the smaller devices really freaking painful. >>=20 >> Are there many boards now with ATA, but without USB? But I agree, it=20= >> should be checked. >>=20 >=20 > It's not necessarily what the boards have but how they're used. We = use > industrial SBCs at work that have ata compact flash sockets on the = board > which we do use, and usb interfaces which we don't use. >=20 > I've never tested the new ata+cam stuff on some of these boards, most > based on Cyrix, Via, Geode, and VortexD86 chipsets. The older ata = code > works, but not always very well -- for example, we usually have to set > hw.ata.ata_dma=3D0 for absolutely no reason we've ever been able to = figure > out except that if we leave it enabled we get DMA errors and panics on > some CF cards and not on others. I have no idea whether to expect = such > things to be better, worse, or no different by changing to the ata+cam > way of doing things (but I don't really have time to do extensive > testing right now either). >=20 The legacy ATA code was hard to maintain, very buggy (as you point out), = and is essentially unmaintained. Also, IIRC, the legacy stack simply cannot = support NCQ tagged queueing. I think that Alexander has done a superb job with both developing and = supporting the CAM_ATA stack. Scott From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 15:52:34 2013 Return-Path: Delivered-To: freebsd-current@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 712347F1; Thu, 28 Mar 2013 15:52:34 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 42540C2; Thu, 28 Mar 2013 15:52:33 +0000 (UTC) Received: from [127.0.0.1] (Scott4long@pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id r2SFRkju046102; Thu, 28 Mar 2013 09:27:47 -0600 (MDT) (envelope-from scottl@samsco.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Any objections/comments on axing out old ATA stack? From: Scott Long In-Reply-To: <51536EFD.4060202@freebsd.org> Date: Thu, 28 Mar 2013 09:27:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51536306.5030907@FreeBSD.org> <51536EFD.4060202@freebsd.org> To: mjacob@freebsd.org X-Mailer: Apple Mail (2.1503) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 15:52:34 -0000 On Mar 27, 2013, at 4:13 PM, Matthew Jacob wrote: > On 3/27/2013 2:22 PM, Alexander Motin wrote: >> Hi. >>=20 >> Since FreeBSD 9.0 we are successfully running on the new CAM-based = ATA stack, using only some controller drivers of old ata(4) by having = `options ATA_CAM` enabled in all kernels by default. I have a wish to = drop non-ATA_CAM ata(4) code, unused since that time from the head = branch to allow further ATA code cleanup. >>=20 >> Does any one here still uses legacy ATA stack (kernel explicitly = built without `options ATA_CAM`) for some reason, for example as = workaround for some regression? Does anybody have good ideas why we = should not drop it now? >>=20 > Some people have expressed performance concerns about ATA_CAM. I have = not validated those concerns. Does anyone know of any? The albatross of "CAM is slow" comes up over and over, but I never see = any data to support the claims. So here's an anecdote of my own. Several years ago, Paul Saab and I were looking at performance problems = with the CISS driver. To rule out the "CAM is slow" argument, he wrote = a shim for it that completely cut out CAM and gave it a thin block layer = attachment. The result was that his new driver was actually _slower_ = than the CAM driver. Why? CAM scheduler actually does a really good = job with keeping the pipeline to the driver full and free of stalls. = Also, the code overhead of going through CAM is also much smaller than = people assume, likely because no one actually reads the code before they = make the assumption. Scott From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 16:02:57 2013 Return-Path: Delivered-To: freebsd-current@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 D252BE79 for ; Thu, 28 Mar 2013 16:02:57 +0000 (UTC) (envelope-from mj@feral.com) Received: from virtual.feral.com (virtual.feral.com [216.224.170.83]) by mx1.freebsd.org (Postfix) with ESMTP id 9EDD315E for ; Thu, 28 Mar 2013 16:02:57 +0000 (UTC) Received: from [192.168.135.7] (76-14-49-207.sf-cable.astound.net [76.14.49.207]) by virtual.feral.com (8.14.4/8.14.4) with ESMTP id r2SG1t9F019043 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 28 Mar 2013 09:01:56 -0700 Message-ID: <51546975.3050103@feral.com> Date: Thu, 28 Mar 2013 09:01:57 -0700 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <51536EFD.4060202@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (virtual.feral.com [216.224.170.83]); Thu, 28 Mar 2013 09:01:56 -0700 (PDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 16:02:57 -0000 On 3/28/2013 8:27 AM, Scott Long wrote: > On Mar 27, 2013, at 4:13 PM, Matthew Jacob wrote: > >> On 3/27/2013 2:22 PM, Alexander Motin wrote: >>> Hi. >>> >>> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA stack, using only some controller drivers of old ata(4) by having `options ATA_CAM` enabled in all kernels by default. I have a wish to drop non-ATA_CAM ata(4) code, unused since that time from the head branch to allow further ATA code cleanup. >>> >>> Does any one here still uses legacy ATA stack (kernel explicitly built without `options ATA_CAM`) for some reason, for example as workaround for some regression? Does anybody have good ideas why we should not drop it now? >>> >> Some people have expressed performance concerns about ATA_CAM. I have not validated those concerns. Does anyone know of any? > The albatross of "CAM is slow" comes up over and over, but I never see any data to support the claims. So here's an anecdote of my own. > Yes, I understand that. Like I said, they didn't give me details about it, but it did seem like some data they were throwing around showed a falloff that was significant. However, they have a number of other differences which, for whatever reason, may not have played well. I'm waiting for more info on it. From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 16:05:14 2013 Return-Path: Delivered-To: freebsd-current@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 6554811C; Thu, 28 Mar 2013 16:05:14 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 1D1B3191; Thu, 28 Mar 2013 16:05:13 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:cd63:a817:556f:dff2]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id ED9064AC58; Thu, 28 Mar 2013 20:05:11 +0400 (MSK) Date: Thu, 28 Mar 2013 20:05:09 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <853249275.20130328200509@serebryakov.spb.ru> To: Aleksandr Rybalko Subject: Re: Any objections/comments on axing out old ATA stack? In-Reply-To: <20130328160953.f0ca035403fb4b4adddfe6e0@ddteam.net> References: <51536306.5030907@FreeBSD.org> <20130328160953.f0ca035403fb4b4adddfe6e0@ddteam.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Alexander Motin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 16:05:14 -0000 Hello, Aleksandr. You wrote 28 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2013 =D0=B3., 18:09:53: >> It'd be nice if we could slim down the CAM stack a bit first; it makes >> embedding it on the smaller devices really freaking painful. AR> /me never seen embedded devices with ATA/SATA and less than 64MB of RAM. AR> (i386/i486 old machines does not count :) ) AR> I'm missing something? Yes: USB UMASS. It uses CAM too, and useful for very small systems, like 4MiB FLASH and 16MiB RAM (yes, whole system image, kernel and all, should be packed to 4MiB). Please note, Adrian speaks about CAM, not only CAM + ATA. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 17:11:26 2013 Return-Path: Delivered-To: current@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 58DA0ED7 for ; Thu, 28 Mar 2013 17:11:26 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by mx1.freebsd.org (Postfix) with ESMTP id 29A5D70E for ; Thu, 28 Mar 2013 17:11:26 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id ef5so6815684obb.41 for ; Thu, 28 Mar 2013 10:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TzLWZPAREcNTV7+GyeqTRzKqasi2hCUZhV+WvlkliYg=; b=L1aJYI+xpBIoTqTMH5ojTGTSvevHZhN29zB1tjOQFoKpJovluF/djHUePu+opK7RYe ck5iN/ujf9Ow8PsgDfkKeUGDmTmP4+Bw1TH1Dz2efjLiu45zulDTzSp1PV2u3mfUIuJL dZOBFDncOdUBOPKHsYdNltPPpyMxhKn0WynJhZ/+4WHvJkez1OnaRZdLMeNr7LqoIfI2 WFxy7AVo34yrrkjWXNHG419Lg2VRxvek/46OwPe8Waycy3Hl2FwP+dVSv4Ntjzp5ZXij XZdzT6zhIzA0zErp6EnaTTY7TTb8knTuzv6Jx0eCUbGfEALxTNLagk4QH9tMSC0NxexW BuUA== MIME-Version: 1.0 X-Received: by 10.182.110.33 with SMTP id hx1mr5863835obb.32.1364490685696; Thu, 28 Mar 2013 10:11:25 -0700 (PDT) Received: by 10.76.108.7 with HTTP; Thu, 28 Mar 2013 10:11:25 -0700 (PDT) In-Reply-To: <20130328075209.GL3794@kib.kiev.ua> References: <20130328075209.GL3794@kib.kiev.ua> Date: Thu, 28 Mar 2013 10:11:25 -0700 Message-ID: Subject: Re: [RFC] vfs.read_min proposal From: Maksim Yevmenkin To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 17:11:26 -0000 On Thu, Mar 28, 2013 at 12:52 AM, Konstantin Belousov wrote: >> i would like to get some reviews, opinions and/or comments on the patch below. >> >> a little bit background, as far as i understand, cluster_read() can >> initiate two disk i/o's: one for exact amount of data being requested >> (rounded up to a filesystem block size) and another for a configurable >> read ahead. read ahead data are always extra and do not super set data >> being requested. also, read ahead can be controlled via f_seqcount (on >> per descriptor basis) and/or vfs.read_max (global knob). >> >> in some cases and/or on some work loads it can be beneficial to bundle >> original data and read ahead data in one i/o request. in other words, >> read more than caller has requested, but only perform one larger i/o, >> i.e. super set data being requested and read ahead. > > The totread argument to the cluster_read() is supplied by the filesystem > to indicate how many data in the current request is specified. Always > overriding this information means two things: > - you fill the buffer and page cache with potentially unused data. it very well could be > For some situations, like partial reads, it would be really bad. certainly possible > - you increase the latency by forcing the reader to wait for the whole > cluster which was not asked for. perhaps, however, modern drives are fast, and, in fact, are a lot better at reading continuous chunks without introducing significant delays. > So it looks as very single- and special-purpose hack. Besides, the > global knob is obscure and probably would not have any use except your > special situation. Would a file flag be acceptable for you ? flag would probably work just as well, but having global knob allows for runtime tuning without software re-configuration and re-start. > What is the difference in the numbers you see, and what numbers ? > Is it targeted for read(2) optimizations, or are you also concerned > with the read-ahead done at the fault time ? ok. please consider the following. modern high performance web server - nginx - with aio + sendfile(SF_NODISKIO) method of delivering data. for those who are not familiar how it works, here is a very quick overview of nginx's aio + sendfile 1) nginx always uses sendfile() with SF_NODISKIO to deliver content. it means that if requested pages are not in the buffer cache, send as much as available and return EBUSY 2) when nginx sees EBUSY return code from sendfile() it would issue aio_read() for 1 byte. the idea here being that OS will issue a read ahead and fill up buffer cache with some pages 3) when aio_read() completes, nginx calls sendfile() with SF_NODISKIO again, making an assumption that at least some of the pages will be in the buffer cache. this model allow for completely non-blocking asynchronous data send without copying anything back to user space. sounds awesome, right? well, it almost is. here is the problem: aio_read() for 1 byte will issue read for 1 filesystem block size, and, *another* read for read ahead data. say, we configure, read ahead to be 1mb (via ioctl(F_READAHEAD and/or vfs.read_max), and, say, our filesystem block size is 64k. we end up with 2 disk reads: one for 64k and another for 1mb, two trips to VM, and our average size per disk transfer is (64k + 1mb) / 2 = 544kb. now, if we use vfs.read_min and set it to 16, i.e. 1mb reads with 64k filesystem block size, turn off read ahead completely, i.e. set vfs.read_max to zero, then *all* cluster_reads() become nice 1mb chunks, and, we only do one disk i/o and one trip to VM to get the same data. so we effectively doubled (or halfed) our iops. also average size per disk transfer is around 900kb (there are still some filesystem block sized i/o that are not going via cluser_read()) which is a lot nicer for modern disks. finally, vfs.read_min allows us to control size of orignal disk reads, and, vfs.read_max allows us to control of additional read ahead. so, ww control both sides here. in fact, we can have 1mb reads and 1mb read aheads together. granted, its not going to be optimal for all loads. that is why vfs.read_min default is 1. however, i strongly suspect that there are quite a few workloads where this could really help with disk i/o. thanks, max From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 17:24:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 06039227; Thu, 28 Mar 2013 17:24:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id 1D286793; Thu, 28 Mar 2013 17:24:26 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id k14so5453034wer.13 for ; Thu, 28 Mar 2013 10:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=MKzBdXfu9ezhnoI7zwkiT1qAsSY7jayRLZvpO+clr6M=; b=Q1mtXwEbYFpr1c5lrkx0vY9TR7fGpeJpndKRPcjCym+UmA8VygjIoNg5DSWxal69R/ AubMmnG6U1xByWGk7JqjfA6NWmvXB3GZ6bJThbw1qcvDi1PwlMvB+zD7wF+uk1PuxA1n VL9i/9yAWGa9EDJwerzw70l0695/BbukwqHvcNR2dh2K9NoIBe40fMCA9EepZ2ajuiPb HaeKbL2ztbhWo4Z3YRKYEnCtFMPUzrxVLTu4E9I8Egkznkwa50PulFZ+4u6/X0VsAx23 HA9yeNMaz5cjKoQAbwz51Wjb8ZUnB6RNu3m4CYOBJp4TCfJWdDDpx6o4szSn9uQasojW aMGA== MIME-Version: 1.0 X-Received: by 10.180.89.105 with SMTP id bn9mr13516194wib.26.1364491466232; Thu, 28 Mar 2013 10:24:26 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Thu, 28 Mar 2013 10:24:26 -0700 (PDT) In-Reply-To: <853249275.20130328200509@serebryakov.spb.ru> References: <51536306.5030907@FreeBSD.org> <20130328160953.f0ca035403fb4b4adddfe6e0@ddteam.net> <853249275.20130328200509@serebryakov.spb.ru> Date: Thu, 28 Mar 2013 10:24:26 -0700 X-Google-Sender-Auth: pCA09woODXOpCKaYKIfIYyu3I7k Message-ID: Subject: Re: Any objections/comments on axing out old ATA stack? From: Adrian Chadd To: lev@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Aleksandr Rybalko , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Alexander Motin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 17:24:28 -0000 On 28 March 2013 09:05, Lev Serebryakov wrote: > Yes: USB UMASS. It uses CAM too, and useful for very small systems, > like 4MiB FLASH and 16MiB RAM (yes, whole system image, kernel and > all, should be packed to 4MiB). > > Please note, Adrian speaks about CAM, not only CAM + ATA. And I'm not at all saying we should keep the old ATA driver around. I'm just pointing out a set of use cases that most FreeBSD developers aren't involved with and I'd like to find a way to squeeze it more efficiently into embedded platforms. I've never had any noticable performance issues with CAM on my embedded MIPS boards because it's typically pushing packets. It's just the resultant binary size of the whole stack that's a problem. adrian@freefall:~/public_html/ath$ cat AP121-nodebug.txt | grep scsi text data bss dec hex filename 49372 10672 80 60124 eadc scsi_all.o 21200 2576 16 23792 5cf0 scsi_da.o 23288 1488 16 24792 60d8 scsi_xpt.o adrian@freefall:~/public_html/ath$ cat AP121-nodebug.txt | grep cam text data bss dec hex filename 3824 96 16 3936 f60 cam.o 13552 144 16 13712 3590 cam_periph.o 2344 144 0 2488 9b8 cam_queue.o 640 48 0 688 2b0 cam_sim.o 40684 752 192 41628 a29c cam_xpt.o adrian@freefall:~/public_html/ath$ cat AP121-nodebug.txt | grep umass text data bss dec hex filename 22592 1072 16 23680 5c80 umass.o adrian@freefall:~/public_html/ath$ cat AP121-nodebug.txt | egrep '(cam_|umass|scsi_)' 13552 144 16 13712 3590 cam_periph.o 2344 144 0 2488 9b8 cam_queue.o 640 48 0 688 2b0 cam_sim.o 40684 752 192 41628 a29c cam_xpt.o 49372 10672 80 60124 eadc scsi_all.o 21200 2576 16 23792 5cf0 scsi_da.o 23288 1488 16 24792 60d8 scsi_xpt.o 22592 1072 16 23680 5c80 umass.o adrian@freefall:~/public_html/ath$ cat AP121-nodebug.txt | egrep '(cam_|umass|scsi_)' | awk '{a+=$4} END {print a}' 190904 It doesn't seem like a lot, but it does add up.. Adrian From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 17:24:59 2013 Return-Path: Delivered-To: freebsd-current@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 8E7AD42E; Thu, 28 Mar 2013 17:24:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by mx1.freebsd.org (Postfix) with ESMTP id A0A8E7B8; Thu, 28 Mar 2013 17:24:58 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id hn17so3546277wib.10 for ; Thu, 28 Mar 2013 10:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=98jEQamiPMg+p7d2M5/FhWw74woD4ryfp8l0mhqour8=; b=w7DO6rY9tv90kuATIu4NHMMiG54McPXNGxy2SCDHJTDkC3S9KFkO4DYpRms+uZxxvR 3o2K7580JWxIToP0eA5vn7fGaf8zbZ5pk6eRvuVR0vLehcKnYLf+XqT7nXdA1osC8+mv re5N7nynfdTkU/HZjxAXv6YSkvXkXadvrqumfa2yN/A4PQvyK/d3qZq3YTQHJwMGVgIa JjY9yI73tR52EQ9fpv8tdprOoutOEzb3tUB40todBUEUe3ExFDuXGuGN+e3KDW+KmcFz odS2JjWxKa6KT4nJ+a8dAgMUD+6rliGIa06jQmwwTROJ6WMEer3qrq4BwoTN+0UrfBXJ 4edQ== MIME-Version: 1.0 X-Received: by 10.194.120.169 with SMTP id ld9mr39942536wjb.24.1364491494172; Thu, 28 Mar 2013 10:24:54 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Thu, 28 Mar 2013 10:24:54 -0700 (PDT) In-Reply-To: References: <51536306.5030907@FreeBSD.org> <20130328160953.f0ca035403fb4b4adddfe6e0@ddteam.net> <853249275.20130328200509@serebryakov.spb.ru> Date: Thu, 28 Mar 2013 10:24:54 -0700 X-Google-Sender-Auth: aCU-DnBzMgbP1FHmtf6rpj-LYSw Message-ID: Subject: Re: Any objections/comments on axing out old ATA stack? From: Adrian Chadd To: lev@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Aleksandr Rybalko , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Alexander Motin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 17:24:59 -0000 .. and before you ask - yes, there are embedded boards with limited RAM that also have ATA ports. :-) Adrian From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 17:32:42 2013 Return-Path: Delivered-To: freebsd-current@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 3DF108F0; Thu, 28 Mar 2013 17:32:42 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 0161C821; Thu, 28 Mar 2013 17:32:41 +0000 (UTC) Received: from critter.freebsd.dk (critter-phk.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id DF28A89FBE; Thu, 28 Mar 2013 17:26:53 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.6/8.14.6) with ESMTP id r2SHQo4c006396; Thu, 28 Mar 2013 17:26:50 GMT (envelope-from phk@phk.freebsd.dk) To: Adrian Chadd Subject: Re: Any objections/comments on axing out old ATA stack? In-reply-to: From: "Poul-Henning Kamp" References: <51536306.5030907@FreeBSD.org> <20130328160953.f0ca035403fb4b4adddfe6e0@ddteam.net> <853249275.20130328200509@serebryakov.spb.ru> Content-Type: text/plain; charset=ISO-8859-1 Date: Thu, 28 Mar 2013 17:26:50 +0000 Message-ID: <6395.1364491610@critter.freebsd.dk> Cc: Aleksandr Rybalko , lev@freebsd.org, freebsd-stable@freebsd.org, Alexander Motin , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 17:32:42 -0000 In message , Adrian Chadd wri tes: >On 28 March 2013 09:05, Lev Serebryakov wrote: >adrian@freefall:~/public_html/ath$ cat AP121-nodebug.txt | egrep >'(cam_|umass|scsi_)' | awk '{a+=$4} END {print a}' >190904 > >It doesn't seem like a lot, but it does add up.. Isn't there some kernel compile-time option to eliminate the huge tables used for errormessages etc ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 17:39:27 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2D4AEC40; Thu, 28 Mar 2013 17:39:27 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id E3779883; Thu, 28 Mar 2013 17:39:26 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r2SHdKvW021287; Thu, 28 Mar 2013 13:39:20 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.netplex.net [204.213.176.10]); Thu, 28 Mar 2013 13:39:20 -0400 (EDT) Date: Thu, 28 Mar 2013 13:39:20 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Ian Lepore Subject: Re: Any objections/comments on axing out old ATA stack? In-Reply-To: <1364479253.36972.77.camel@revolution.hippie.lan> Message-ID: References: <51536306.5030907@FreeBSD.org> <5153EE86.8000801@FreeBSD.org> <1364479253.36972.77.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexander Motin , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, Adrian Chadd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 17:39:27 -0000 On Thu, 28 Mar 2013, Ian Lepore wrote: > On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote: >> On 28.03.2013 02:43, Adrian Chadd wrote: >>> My main concern with the new stuff is that it requires CAM and that's >>> reasonably big compared to the standalone ATA code. >>> >>> It'd be nice if we could slim down the CAM stack a bit first; it makes >>> embedding it on the smaller devices really freaking painful. >> >> Are there many boards now with ATA, but without USB? But I agree, it >> should be checked. >> > > It's not necessarily what the boards have but how they're used. We use > industrial SBCs at work that have ata compact flash sockets on the board > which we do use, and usb interfaces which we don't use. > > I've never tested the new ata+cam stuff on some of these boards, most > based on Cyrix, Via, Geode, and VortexD86 chipsets. The older ata code > works, but not always very well -- for example, we usually have to set > hw.ata.ata_dma=0 for absolutely no reason we've ever been able to figure > out except that if we leave it enabled we get DMA errors and panics on > some CF cards and not on others. I have no idea whether to expect such > things to be better, worse, or no different by changing to the ata+cam > way of doing things (but I don't really have time to do extensive > testing right now either). Woa, I have to set hw.ata.ata_dma=0 also in order to get FreeBSD to boot on a PC104 board. I think ours is a Cyrix or Via also. -- DE From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 17:48:18 2013 Return-Path: Delivered-To: freebsd-current@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 635F3ED0; Thu, 28 Mar 2013 17:48:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by mx1.freebsd.org (Postfix) with ESMTP id 794908E6; Thu, 28 Mar 2013 17:48:16 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id x12so1807342wgg.12 for ; Thu, 28 Mar 2013 10:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=yMLu6MAfA964fV69chAgT+r57PcTyNSHI6zjgRUR6R8=; b=mUT+rIfPr9NPqMrfvlfbqT8RX352NjA3WmhzlqRfCx/mbjZgCKBfLZ0dXhMmJRVONu k4hQl3ZS2YOUIHp8q6j9RF96ehPcDYQ/T3r7GDo9Yes2LIxX8PjzCy3b61xXY/6/aa8+ wzwFAqJNAS3fHhMT714LofEtUjJO35wI2fv0vL4N/uxZ5Ug49OMjaV8ZRHd1CsJ45FGi ETxLY7ous93izSr4SEPSd+G+IZx/fB2p3I6ynBcKgrbu5Cru8IxFYxqEtv+/hvM7cv7F 78xcAyPpC3SIAryLKJLPsxro+u1KairCaCdRMolpv8IsU9uV0VlDg0D+lIgAE93x7hh6 KS1w== MIME-Version: 1.0 X-Received: by 10.180.13.34 with SMTP id e2mr18160916wic.29.1364492895286; Thu, 28 Mar 2013 10:48:15 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Thu, 28 Mar 2013 10:48:15 -0700 (PDT) In-Reply-To: <6395.1364491610@critter.freebsd.dk> References: <51536306.5030907@FreeBSD.org> <20130328160953.f0ca035403fb4b4adddfe6e0@ddteam.net> <853249275.20130328200509@serebryakov.spb.ru> <6395.1364491610@critter.freebsd.dk> Date: Thu, 28 Mar 2013 10:48:15 -0700 X-Google-Sender-Auth: n7GNo6aGgx06mNT2G1hIQnD_k6U Message-ID: Subject: Re: Any objections/comments on axing out old ATA stack? From: Adrian Chadd To: Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 Cc: Aleksandr Rybalko , lev@freebsd.org, freebsd-stable@freebsd.org, Alexander Motin , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 17:48:18 -0000 On 28 March 2013 10:26, Poul-Henning Kamp wrote: > Isn't there some kernel compile-time option to eliminate the huge > tables used for errormessages etc ? Yup. It doesn't save all that much in the grand scheme of things. Doubly so since my secondary size constraint is an 896k partition that I lzma compress the kernel to fit into. Those strings don't add much to the final lzma image size. Adrian From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 17:49:15 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4548E176 for ; Thu, 28 Mar 2013 17:49:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by mx1.freebsd.org (Postfix) with ESMTP id D3EBE910 for ; Thu, 28 Mar 2013 17:49:14 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id e11so1729463wgh.4 for ; Thu, 28 Mar 2013 10:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=aCpBduS4WSYIUS6dbVh7Aevyx+HFMzqmW+327EZnBPg=; b=0rzrluTtJWiCvzyykEwrRSiwmi5wYAPOIZclBHbKUCY224Pz40Z7Yoa9/BxnAsNPqd ppSwATmd5/JAiOm3BlwanNUfvpr6E+CA4A2odH9cDn7ER1HBeNMBdlXycR2RpyD7t6YV YtF1GCzFd0Be1B5eqGun1QDcTY3sCS92eyEBON7ndBTqMgIlaLgSBhti4aPE3VqCKX2z mHuE2c1v9kOFSrZGMZ2jDdfnc+LywDPsuh2Z1nrYspKIBB4UdKwYwzgsIdibJA/CF26S YuD7LkyYJ9hCMMTfYQDCWPriB5FvI0O5YbxlAapYdm+SdcJWy8CJIJkfqAs1TJYXmu3m dTKQ== MIME-Version: 1.0 X-Received: by 10.194.120.169 with SMTP id ld9mr40090458wjb.24.1364492954039; Thu, 28 Mar 2013 10:49:14 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Thu, 28 Mar 2013 10:49:13 -0700 (PDT) In-Reply-To: References: <20130328075209.GL3794@kib.kiev.ua> Date: Thu, 28 Mar 2013 10:49:13 -0700 X-Google-Sender-Auth: Ctsyu6-mrZQiYCfJ9x7u8BKFoOU Message-ID: Subject: Re: [RFC] vfs.read_min proposal From: Adrian Chadd To: Maksim Yevmenkin Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 17:49:15 -0000 ... you guys should think about writing an aio_sendfile() function for FreeBSD. Just saying. Adrian From owner-freebsd-current@FreeBSD.ORG Fri Mar 29 03:51:06 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C8F75AF2; Fri, 29 Mar 2013 03:51:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9EB1495E; Fri, 29 Mar 2013 03:51:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2T3p08J085856; Thu, 28 Mar 2013 23:51:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2T3p03o085823; Fri, 29 Mar 2013 03:51:00 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 29 Mar 2013 03:51:00 GMT Message-Id: <201303290351.r2T3p03o085823@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 03:51:06 -0000 TB --- 2013-03-29 02:48:53 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-29 02:48:53 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-29 02:48:53 - starting HEAD tinderbox run for mips/mips TB --- 2013-03-29 02:48:53 - cleaning the object tree TB --- 2013-03-29 02:48:53 - /usr/local/bin/svn stat /src TB --- 2013-03-29 02:49:26 - At svn revision 248853 TB --- 2013-03-29 02:49:27 - building world TB --- 2013-03-29 02:49:27 - CROSS_BUILD_TESTING=YES TB --- 2013-03-29 02:49:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-29 02:49:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-29 02:49:27 - SRCCONF=/dev/null TB --- 2013-03-29 02:49:27 - TARGET=mips TB --- 2013-03-29 02:49:27 - TARGET_ARCH=mips TB --- 2013-03-29 02:49:27 - TZ=UTC TB --- 2013-03-29 02:49:27 - __MAKE_CONF=/dev/null TB --- 2013-03-29 02:49:27 - cd /src TB --- 2013-03-29 02:49:27 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Mar 29 02:49:31 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Mar 29 03:50:59 UTC 2013 TB --- 2013-03-29 03:50:59 - cd /src/sys/mips/conf TB --- 2013-03-29 03:50:59 - /usr/sbin/config -m ADM5120 TB --- 2013-03-29 03:50:59 - skipping ADM5120 kernel TB --- 2013-03-29 03:50:59 - cd /src/sys/mips/conf TB --- 2013-03-29 03:50:59 - /usr/sbin/config -m ALCHEMY TB --- 2013-03-29 03:50:59 - skipping ALCHEMY kernel TB --- 2013-03-29 03:50:59 - cd /src/sys/mips/conf TB --- 2013-03-29 03:50:59 - /usr/sbin/config -m AP121 TB --- 2013-03-29 03:50:59 - building AP121 kernel TB --- 2013-03-29 03:50:59 - CROSS_BUILD_TESTING=YES TB --- 2013-03-29 03:50:59 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-29 03:50:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-29 03:50:59 - SRCCONF=/dev/null TB --- 2013-03-29 03:50:59 - TARGET=mips TB --- 2013-03-29 03:50:59 - TARGET_ARCH=mips TB --- 2013-03-29 03:50:59 - TZ=UTC TB --- 2013-03-29 03:50:59 - __MAKE_CONF=/dev/null TB --- 2013-03-29 03:50:59 - cd /src TB --- 2013-03-29 03:50:59 - /usr/bin/make -B buildkernel KERNCONF=AP121 >>> Kernel build for AP121 started on Fri Mar 29 03:50:59 UTC 2013 >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /src/sys/mips/conf; PATH=/obj/mips.mips/src/tmp/legacy/usr/sbin:/obj/mips.mips/src/tmp/legacy/usr/bin:/obj/mips.mips/src/tmp/legacy/usr/games:/obj/mips.mips/src/tmp/legacy/bin:/obj/mips.mips/src/tmp/usr/sbin:/obj/mips.mips/src/tmp/usr/bin:/obj/mips.mips/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /obj/mips.mips/src/sys/AP121 /src/sys/mips/conf/AP121 WARNING: duplicate option `AH_DEBUG_ALQ' encountered. /src/sys/mips/conf/AP121: unknown option "UMTX_NUM_CHAINS" *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-29 03:51:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-29 03:51:00 - ERROR: failed to build AP121 kernel TB --- 2013-03-29 03:51:00 - 2685.00 user 578.68 system 3726.91 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Mar 29 04:41:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 70A6F275; Fri, 29 Mar 2013 04:41:52 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id ABB2BAE4; Fri, 29 Mar 2013 04:41:51 +0000 (UTC) Received: by mail-ea0-f174.google.com with SMTP id m14so69209eaj.33 for ; Thu, 28 Mar 2013 21:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=C9CMUhcR14gRASCoe1GjZ0SvvXuQeu/dXQLpRGPToOY=; b=DXokpFTmRBZcLb2DpO2lRXoO3Cd9M7EGVQytRXwPgiZ8Pco4uKh2447faH0k3RYwxD qCLLqAy5ScDpdrUoJM12q/oJwwd+uTV4bYwkMzK5r8ZNAawuprz5vUSt8cGxKguGpSaG QOzw0D0VtkBjSxOEaMvq2yJ1Q0mlemEFtO9S+7XmM+2r0vnAObhgnhrULzxMvgIqqueq PQ2LR+w80ohCPTm84aG8pxzG/TGwW3KCKtlXo43syuI1nSKpIpAnuRoFsTJUvmRparjT /nOCTnk24EKoctOGH2wafNfIm1SjqzPfWF/8QEZUNtWg2x//fcFVFPSVk6whH9NnCgl5 OLng== MIME-Version: 1.0 X-Received: by 10.15.36.67 with SMTP id h43mr3710223eev.5.1364532110732; Thu, 28 Mar 2013 21:41:50 -0700 (PDT) Received: by 10.14.2.201 with HTTP; Thu, 28 Mar 2013 21:41:50 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Mar 2013 21:41:50 -0700 Message-ID: Subject: Re: hwpmc support for haswell From: hiren panchasara To: Jim Harris Content-Type: text/plain; charset=UTF-8 Cc: Davide Italiano , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 04:41:52 -0000 On Sat, Mar 23, 2013 at 5:13 PM, hiren panchasara wrote: > On Sat, Mar 23, 2013 at 8:58 AM, hiren panchasara > wrote: >> >> On Mar 22, 2013 10:48 PM, "Jim Harris" wrote: >>> >>> >>> >>> On Friday, March 22, 2013, hiren panchasara wrote: >>>> >>>> On Thu, Jan 31, 2013 at 6:26 PM, hiren panchasara >>>> wrote: >>>> > On Thu, Jan 31, 2013 at 5:47 PM, Davide Italiano >>>> > wrote: >>>> >> On Fri, Feb 1, 2013 at 2:17 AM, hiren panchasara >>>> >> wrote: >>>> >>> Hi, >>>> >>> >>>> >>> I've prepared a patch to add core and uncore events support for >>>> >>> haswell processor. >>>> >>> I do not have the hardware to test this. It applies cleanly and >>>> >>> compiles fine though. >>>> >>> >>>> >>> http://www.strugglingcoder.info/patches/hwpmc_hw.txt >>>> >>> >>>> >>> This is initial version of patch and manpage is still missing. I will >>>> >>> add it in a few days. >>>> >>> >>>> >>> Any help in testing is appreciated. >>>> >>> >>>> >>> Thanks, >>>> >>> Hiren >>>> >> >>>> >> It seems Intel won't release this before June (at least to my >>>> >> knowledge). >>>> >> I would claim it'll be difficult to real test this before that date >>>> >> unless someone has prerelease hardware. >>>> > >>>> > Indeed. I've posted it here just to let larger audience know and avoid >>>> > possible duplicate work. >>>> > >>>> > We will wait till we get the hardware to test with. >>>> >>>> I recently got a ref haswell box to play with. >>>> >>>> Initial dmesg looks like this: >>>> >>>> CPU: Genuine Intel(R) CPU 0000 @ 2.60GHz (2594.05-MHz K8-class CPU) >>>> Origin = "GenuineIntel" Id = 0x306c2 Family = 0x6 Model = 0x3c >>>> Stepping = 2 >>>> >>>> Features=0xbfebfbff >>>> >>>> Features2=0x7ffafbff,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> >>>> AMD Features=0x2c100800 >>>> AMD Features2=0x21 >>>> Standard Extended >>>> Features=0x2fbb >>>> TSC: P-state invariant, performance statistics >>>> real memory = 8589934592 (8192 MB) >>>> avail memory = 8034803712 (7662 MB) >>>> Event timer "LAPIC" quality 600 >>>> ACPI APIC Table: >>>> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs >>>> FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads >>>> cpu0 (BSP): APIC ID: 0 >>>> cpu1 (AP): APIC ID: 1 >>>> cpu2 (AP): APIC ID: 2 >>>> cpu3 (AP): APIC ID: 3 >>>> cpu4 (AP): APIC ID: 4 >>>> cpu5 (AP): APIC ID: 5 >>>> cpu6 (AP): APIC ID: 6 >>>> cpu7 (AP): APIC ID: 7 >>>> >>>> Diffs at: >>>> http://www.strugglingcoder.info/patches/hwpmc_hw.txt >>>> Tests I've done: >>>> http://www.strugglingcoder.info/patches/hwpmc_hw_pmccontrol.txt >>>> http://www.strugglingcoder.info/patches/hwpmc_hw_pmctest.txt >>>> >>>> I am following 325462-045US Jan 2013 sw dev manual and below are the >>>> counters >>>> which I cannot poke at via pmcstat: >>>> >>>> Core: >>>> "L2_RQSTS.DEMAND_DATA_RD_MISS" >>>> "L2_RQSTS.DEMAND_DATA_RD_HIT" >>>> "L2_RQSTS.ALL_DEMAND_DATA_RD" >>>> "L2_RQSTS.ALL_DEMAND_MISS" >>>> "L2_RQSTS.ALL_DEMAND_REFERENCES" >>>> "L2_RQSTS.MISS" >>>> "CYCLE_ACTIVITY.STALLS_L2_PENDING" >>>> "PAGE_WALKER_LOADS.DTLB_L1" >>>> "PAGE_WALKER_LOADS.ITLB_L1" >>>> "BACLEARS.ANY" >>>> "L2_LINES_OUT.DEMAND_CLEAN" >>>> >>>> Uncore: >>>> "UNC_CBO_XSNP_RESPONSE.INVAL_M" >>>> "UNC_CBO_CACHE_LOOKUP.ES" >>>> >>>> For all of them, I get error like this: >>>> >>>> # pmcstat -p L2_RQSTS.MISS ls >>>> pmcstat: ERROR: Cannot allocate process-mode pmc with specification >>>> "L2_RQSTS.MISS": Invalid argument >>>> >>>> Box does not panic or anything. >>>> >>>> I've tried to double check my changes without success. >>>> Is it possible that the documentation has some inconsistencies? >>>> >>> >>> It looks like IAF_F_FM is missing from most (all?) of the new event w/ >>> umask entries you added that are specific to Haswell. Can you try adding >>> these and see if it clears anything up? A cursory look seemed to show most >>> of these failures are on event/umasks that are missing this flag. >>> >> Ah, good point. Let me try that and let you know. > > Jim, thanks for spotting this. Missing counters are fixed now. Thanks a bunch to Sean for committing the changes: http://svnweb.freebsd.org/base?view=revision&revision=248842 cheers, Hiren > > cheers, > Hiren >> >> Thanks, >> Hiren. >>> Thanks, >>> >>> -Jim From owner-freebsd-current@FreeBSD.ORG Fri Mar 29 07:13:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A83767DB for ; Fri, 29 Mar 2013 07:13:25 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by mx1.freebsd.org (Postfix) with ESMTP id 3C476F20 for ; Fri, 29 Mar 2013 07:13:24 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id d17so93471eek.11 for ; Fri, 29 Mar 2013 00:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Wz5yReOSFz2XXhGZQQU6lkAe+FJlNwKB37DvmB2CiVc=; b=kqWNPiD3NhVjOSz8giIxCG8lOPljymwR6kMEFOBitkk5nr14NJxcYOE7XRupZDOBYT bBZpIvs3F56JEf3T6uXnrgpyWQH5MjYjlLtvk4/0itAc/sRv5rOo7No/kSfzHbIngrBd sgISGccd9G2+lTDJekWdBt1hGww+FCw+At2a8gOHWRhMJ6fkQ8YQ0xA6Li6yaE1FXGaV Mxly6+2KB2pG5DOrjmelLKqXNEqiWiO2IQtxml7mAvDZvFoPFzJpuXgoYw/v6c0Npr0x g8ymyassgpvzSFKETOJNd4CFA2Q0Scwo2eZzWBMiXziWvw0VYDpDL/n/ZTGQEqq7HN9t t8hQ== X-Received: by 10.15.36.67 with SMTP id h43mr4850742eev.5.1364541198527; Fri, 29 Mar 2013 00:13:18 -0700 (PDT) Received: from [192.168.1.80] (540213BD.dsl.pool.telekom.hu. [84.2.19.189]) by mx.google.com with ESMTPS id 44sm2233653eek.5.2013.03.29.00.13.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Mar 2013 00:13:17 -0700 (PDT) Message-ID: <51553F14.1050609@gmail.com> Date: Fri, 29 Mar 2013 08:13:24 +0100 From: deeptech71 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:18.0) Gecko/20100101 SeaMonkey/2.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: net/xmlrpc-c-devel port with GCC 4.8 References: <514A05FB.7020608@gmail.com> <45FF4CDD-66C2-4AA5-8A8D-B39677A4D6B1@FreeBSD.org> In-Reply-To: <45FF4CDD-66C2-4AA5-8A8D-B39677A4D6B1@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 07:13:25 -0000 On 03/20/2013 20:49, Dimitry Andric wrote:> On Mar 20, 2013, at 19:54, deeptech71 wrote: >> /usr/local/lib/gcc48/include/c++/bits/locale_facets.h:869: undefined reference to `std::ctype::_M_widen_init() const' >> [...] >> /usr/local/lib/gcc48/include/c++/bits/stl_list.h:1550: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)' >> [...] >> >> I worked around this by adding "/usr/local/lib/gcc48/libstdc++.so" to the make-rule. Weird. Why does this work? Should it? > > This is a general problem with the gcc ports: they should all pull in > their own version(s) of libstdc++.so instead of using the default linker > path. And possibly add rpath entries, to make sure the correct version > of libstdc++.so is used at runtime. On 03/28/2013 15:37, Renato Botelho wrote: > The problem here is -L/usr/lib, libwww-config --libs returned that, > maybe the issue is on libwww side. ! From owner-freebsd-current@FreeBSD.ORG Fri Mar 29 19:57:43 2013 Return-Path: Delivered-To: current@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 04796C0D; Fri, 29 Mar 2013 19:57:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D0077889; Fri, 29 Mar 2013 19:57:42 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2TJvfM1008803; Fri, 29 Mar 2013 15:57:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2TJvfXn008797; Fri, 29 Mar 2013 19:57:41 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 29 Mar 2013 19:57:41 GMT Message-Id: <201303291957.r2TJvfXn008797@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 19:57:43 -0000 TB --- 2013-03-29 18:54:33 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-29 18:54:33 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-29 18:54:33 - starting HEAD tinderbox run for mips/mips TB --- 2013-03-29 18:54:33 - cleaning the object tree TB --- 2013-03-29 18:56:02 - /usr/local/bin/svn stat /src TB --- 2013-03-29 18:56:58 - At svn revision 248877 TB --- 2013-03-29 18:56:59 - building world TB --- 2013-03-29 18:56:59 - CROSS_BUILD_TESTING=YES TB --- 2013-03-29 18:56:59 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-29 18:56:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-29 18:56:59 - SRCCONF=/dev/null TB --- 2013-03-29 18:56:59 - TARGET=mips TB --- 2013-03-29 18:56:59 - TARGET_ARCH=mips TB --- 2013-03-29 18:56:59 - TZ=UTC TB --- 2013-03-29 18:56:59 - __MAKE_CONF=/dev/null TB --- 2013-03-29 18:56:59 - cd /src TB --- 2013-03-29 18:56:59 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Mar 29 18:57:04 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Mar 29 19:57:40 UTC 2013 TB --- 2013-03-29 19:57:40 - cd /src/sys/mips/conf TB --- 2013-03-29 19:57:40 - /usr/sbin/config -m ADM5120 TB --- 2013-03-29 19:57:41 - skipping ADM5120 kernel TB --- 2013-03-29 19:57:41 - cd /src/sys/mips/conf TB --- 2013-03-29 19:57:41 - /usr/sbin/config -m ALCHEMY TB --- 2013-03-29 19:57:41 - skipping ALCHEMY kernel TB --- 2013-03-29 19:57:41 - cd /src/sys/mips/conf TB --- 2013-03-29 19:57:41 - /usr/sbin/config -m AP121 TB --- 2013-03-29 19:57:41 - building AP121 kernel TB --- 2013-03-29 19:57:41 - CROSS_BUILD_TESTING=YES TB --- 2013-03-29 19:57:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-29 19:57:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-29 19:57:41 - SRCCONF=/dev/null TB --- 2013-03-29 19:57:41 - TARGET=mips TB --- 2013-03-29 19:57:41 - TARGET_ARCH=mips TB --- 2013-03-29 19:57:41 - TZ=UTC TB --- 2013-03-29 19:57:41 - __MAKE_CONF=/dev/null TB --- 2013-03-29 19:57:41 - cd /src TB --- 2013-03-29 19:57:41 - /usr/bin/make -B buildkernel KERNCONF=AP121 >>> Kernel build for AP121 started on Fri Mar 29 19:57:41 UTC 2013 >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /src/sys/mips/conf; PATH=/obj/mips.mips/src/tmp/legacy/usr/sbin:/obj/mips.mips/src/tmp/legacy/usr/bin:/obj/mips.mips/src/tmp/legacy/usr/games:/obj/mips.mips/src/tmp/legacy/bin:/obj/mips.mips/src/tmp/usr/sbin:/obj/mips.mips/src/tmp/usr/bin:/obj/mips.mips/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /obj/mips.mips/src/sys/AP121 /src/sys/mips/conf/AP121 WARNING: duplicate option `AH_DEBUG_ALQ' encountered. /src/sys/mips/conf/AP121: unknown option "UMTX_NUM_CHAINS" *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-29 19:57:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-29 19:57:41 - ERROR: failed to build AP121 kernel TB --- 2013-03-29 19:57:41 - 2678.20 user 572.04 system 3788.11 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Mar 29 20:07:03 2013 Return-Path: Delivered-To: current@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 AA2D6D94; Fri, 29 Mar 2013 20:07:03 +0000 (UTC) (envelope-from adrian.chadd@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 E55848D0; Fri, 29 Mar 2013 20:07:02 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id r5so549678wey.25 for ; Fri, 29 Mar 2013 13:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8WjTerNTgTGCpAJZz0K9X6UxWumMU1cBvTkmQpIfEDg=; b=wRw8OiR2TLofO8GvnAE93tmVN1S+ymYOFpFKWtGFHb+Qelq4nwXEUEjh/EaCm1TLth ia4dGTdcItI7/abCQPrFgCYl0dJnYstQZDl7h0/BT6aw4lSjbzlseJ9AS27avPtUGo6N q3NS1fb8xxCJxCyvGfLN8Bq7T9uwJ+tAZYgWMU13l5BhyMwwazSp1lIqQJGtaXTJiEDa ZkQzR3sGNP/M51aM2Ty8euIlb3WxKAnNUniwNaZPGADkc6DNDjdnsoEKyvOmcC0q14tZ vIw8wR8v5MmKsIcVz7z1Vl706Pr02RHKOY/49L1aC+u5rGCNizv0Re+koZp4KAcNux5g 2I0Q== MIME-Version: 1.0 X-Received: by 10.180.81.232 with SMTP id d8mr981618wiy.25.1364587622096; Fri, 29 Mar 2013 13:07:02 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Fri, 29 Mar 2013 13:07:01 -0700 (PDT) In-Reply-To: <201303291957.r2TJvfXn008797@freebsd-current.sentex.ca> References: <201303291957.r2TJvfXn008797@freebsd-current.sentex.ca> Date: Fri, 29 Mar 2013 13:07:01 -0700 X-Google-Sender-Auth: DX-V6QkYuN5_C8A46CgLfFX7cDo Message-ID: Subject: Re: [head tinderbox] failure on mips/mips From: Adrian Chadd To: FreeBSD Tinderbox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: mips@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 20:07:03 -0000 ... damn, this kernel wasn't yet meant to be built. I'll fix that now. Adrian On 29 March 2013 12:57, FreeBSD Tinderbox wrote: > TB --- 2013-03-29 18:54:33 - tinderbox 2.10 running on > freebsd-current.sentex.ca > TB --- 2013-03-29 18:54:33 - FreeBSD freebsd-current.sentex.ca8.3-PRERELE= ASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 > des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 > TB --- 2013-03-29 18:54:33 - starting HEAD tinderbox run for mips/mips > TB --- 2013-03-29 18:54:33 - cleaning the object tree > TB --- 2013-03-29 18:56:02 - /usr/local/bin/svn stat /src > TB --- 2013-03-29 18:56:58 - At svn revision 248877 > TB --- 2013-03-29 18:56:59 - building world > TB --- 2013-03-29 18:56:59 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-29 18:56:59 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-29 18:56:59 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-29 18:56:59 - SRCCONF=3D/dev/null > TB --- 2013-03-29 18:56:59 - TARGET=3Dmips > TB --- 2013-03-29 18:56:59 - TARGET_ARCH=3Dmips > TB --- 2013-03-29 18:56:59 - TZ=3DUTC > TB --- 2013-03-29 18:56:59 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-29 18:56:59 - cd /src > TB --- 2013-03-29 18:56:59 - /usr/bin/make -B buildworld > >>> Building an up-to-date make(1) > >>> World build started on Fri Mar 29 18:57:04 UTC 2013 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > >>> World build completed on Fri Mar 29 19:57:40 UTC 2013 > TB --- 2013-03-29 19:57:40 - cd /src/sys/mips/conf > TB --- 2013-03-29 19:57:40 - /usr/sbin/config -m ADM5120 > TB --- 2013-03-29 19:57:41 - skipping ADM5120 kernel > TB --- 2013-03-29 19:57:41 - cd /src/sys/mips/conf > TB --- 2013-03-29 19:57:41 - /usr/sbin/config -m ALCHEMY > TB --- 2013-03-29 19:57:41 - skipping ALCHEMY kernel > TB --- 2013-03-29 19:57:41 - cd /src/sys/mips/conf > TB --- 2013-03-29 19:57:41 - /usr/sbin/config -m AP121 > TB --- 2013-03-29 19:57:41 - building AP121 kernel > TB --- 2013-03-29 19:57:41 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-29 19:57:41 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-29 19:57:41 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-29 19:57:41 - SRCCONF=3D/dev/null > TB --- 2013-03-29 19:57:41 - TARGET=3Dmips > TB --- 2013-03-29 19:57:41 - TARGET_ARCH=3Dmips > TB --- 2013-03-29 19:57:41 - TZ=3DUTC > TB --- 2013-03-29 19:57:41 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-29 19:57:41 - cd /src > TB --- 2013-03-29 19:57:41 - /usr/bin/make -B buildkernel KERNCONF=3DAP12= 1 > >>> Kernel build for AP121 started on Fri Mar 29 19:57:41 UTC 2013 > >>> stage 1: configuring the kernel > -------------------------------------------------------------- > cd /src/sys/mips/conf; > PATH=3D/obj/mips.mips/src/tmp/legacy/usr/sbin:/obj/mips.mips/src/tmp/leg= acy/usr/bin:/obj/mips.mips/src/tmp/legacy/usr/games:/obj/mips.mips/src/tmp/= legacy/bin:/obj/mips.mips/src/tmp/usr/sbin:/obj/mips.mips/src/tmp/usr/bin:/= obj/mips.mips/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > config -d /obj/mips.mips/src/sys/AP121 /src/sys/mips/conf/AP121 > WARNING: duplicate option `AH_DEBUG_ALQ' encountered. > /src/sys/mips/conf/AP121: unknown option "UMTX_NUM_CHAINS" > *** [buildkernel] Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2013-03-29 19:57:41 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2013-03-29 19:57:41 - ERROR: failed to build AP121 kernel > TB --- 2013-03-29 19:57:41 - 2678.20 user 572.04 system 3788.11 real > > > http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Fri Mar 29 20:59:02 2013 Return-Path: Delivered-To: current@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 7BB45E5C for ; Fri, 29 Mar 2013 20:59:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id C786CA6E for ; Fri, 29 Mar 2013 20:59:01 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2TKwrNt018150; Fri, 29 Mar 2013 22:58:53 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.2 kib.kiev.ua r2TKwrNt018150 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2TKwraJ018149; Fri, 29 Mar 2013 22:58:53 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 29 Mar 2013 22:58:53 +0200 From: Konstantin Belousov To: Maksim Yevmenkin Subject: Re: [RFC] vfs.read_min proposal Message-ID: <20130329205853.GB3794@kib.kiev.ua> References: <20130328075209.GL3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5i5vJnjh6kulLZLt" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 20:59:02 -0000 --5i5vJnjh6kulLZLt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 28, 2013 at 10:11:25AM -0700, Maksim Yevmenkin wrote: > On Thu, Mar 28, 2013 at 12:52 AM, Konstantin Belousov > wrote: >=20 > >> i would like to get some reviews, opinions and/or comments on the patc= h below. > >> > >> a little bit background, as far as i understand, cluster_read() can > >> initiate two disk i/o's: one for exact amount of data being requested > >> (rounded up to a filesystem block size) and another for a configurable > >> read ahead. read ahead data are always extra and do not super set data > >> being requested. also, read ahead can be controlled via f_seqcount (on > >> per descriptor basis) and/or vfs.read_max (global knob). > >> > >> in some cases and/or on some work loads it can be beneficial to bundle > >> original data and read ahead data in one i/o request. in other words, > >> read more than caller has requested, but only perform one larger i/o, > >> i.e. super set data being requested and read ahead. > > > > The totread argument to the cluster_read() is supplied by the filesystem > > to indicate how many data in the current request is specified. Always > > overriding this information means two things: > > - you fill the buffer and page cache with potentially unused data. >=20 > it very well could be >=20 > > For some situations, like partial reads, it would be really bad. >=20 > certainly possible >=20 > > - you increase the latency by forcing the reader to wait for the whole > > cluster which was not asked for. >=20 > perhaps, however, modern drives are fast, and, in fact, are a lot > better at reading continuous chunks without introducing significant > delays. >=20 > > So it looks as very single- and special-purpose hack. Besides, the > > global knob is obscure and probably would not have any use except your > > special situation. Would a file flag be acceptable for you ? >=20 > flag would probably work just as well, but having global knob allows > for runtime tuning without software re-configuration and re-start. My point is that the 'tuning' there has too wide scope to be acceptable as the feature for the general-puspose OS. >=20 > > What is the difference in the numbers you see, and what numbers ? > > Is it targeted for read(2) optimizations, or are you also concerned > > with the read-ahead done at the fault time ? >=20 > ok. please consider the following. modern high performance web server > - nginx - with aio + sendfile(SF_NODISKIO) method of delivering data. >=20 > for those who are not familiar how it works, here is a very quick > overview of nginx's aio + sendfile >=20 > 1) nginx always uses sendfile() with SF_NODISKIO to deliver content. > it means that if requested pages are not in the buffer cache, send as > much as available and return EBUSY >=20 > 2) when nginx sees EBUSY return code from sendfile() it would issue > aio_read() for 1 byte. the idea here being that OS will issue a read > ahead and fill up buffer cache with some pages >=20 > 3) when aio_read() completes, nginx calls sendfile() with SF_NODISKIO > again, making an assumption that at least some of the pages will be in > the buffer cache. >=20 > this model allow for completely non-blocking asynchronous data send > without copying anything back to user space. sounds awesome, right? > well, it almost is. here is the problem: aio_read() for 1 byte will > issue read for 1 filesystem block size, and, *another* read for read > ahead data. say, we configure, read ahead to be 1mb (via > ioctl(F_READAHEAD and/or vfs.read_max), and, say, our filesystem block > size is 64k. we end up with 2 disk reads: one for 64k and another for > 1mb, two trips to VM, and our average size per disk transfer is (64k + > 1mb) / 2 =3D 544kb. >=20 > now, if we use vfs.read_min and set it to 16, i.e. 1mb reads with 64k > filesystem block size, turn off read ahead completely, i.e. set > vfs.read_max to zero, then *all* cluster_reads() become nice 1mb > chunks, and, we only do one disk i/o and one trip to VM to get the > same data. so we effectively doubled (or halfed) our iops. also > average size per disk transfer is around 900kb (there are still some > filesystem block sized i/o that are not going via cluser_read()) which > is a lot nicer for modern disks. I think this is definitely a feature that should be set by a flag to either file descriptor used for aio_read, or aio_read call itself. Adding a flag to aio_read() might be cumbersome from the ABI perspective. >=20 > finally, vfs.read_min allows us to control size of orignal disk reads, > and, vfs.read_max allows us to control of additional read ahead. so, > ww control both sides here. in fact, we can have 1mb reads and 1mb > read aheads together. granted, its not going to be optimal for all > loads. that is why vfs.read_min default is 1. however, i strongly > suspect that there are quite a few workloads where this could really > help with disk i/o. In fact, the existing OS behaviour is reasonable for the arguments which are passed to the syscall. The specified read size is 1, and the current read-ahead algorithm tries to satisfy the request with minimal latency and without creating additional load under memory pressure, while starting the useful optimization of the background read. Not lying to the OS could be achieved by somehow specifying to aio_read() that you do not need copyout, and issuing the request for read of the full range. This is definitely more work than read_min, but I think that the result could be useful for the wide audience. --5i5vJnjh6kulLZLt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRVgCMAAoJEJDCuSvBvK1Bi90P/i9eXh1FUrOTDqrMnMLodW+/ /Fzk0GdoJVgNGT7BiInb8ntnT/tuCLBeloIzrlx4ZhhX+jRmdBwoHDoJw7nepVSX jv5M49ummgYV5X6bE8Mn7Q5Lbkv2aymdKsVvnU8O6Us7icFdSic3cl1HNfwca7JW ffMTII8QZmG3jrOSKgW/Gjzpexfnk+Y6e7TJ2wRaERzy4I1ii0IM7eGzlZqQ0K09 0OR5jzEPEt6um/7fGJKnSQ7yn7giLIWQA44Qgnv0Svfl1rpsX+bstGVxRuQUgzQ3 S0n5a7LPMIHRqpX2HSQtYLsQNO3u5aj6NQUsRrD2IMMxazCcYHVlIUB0zv31RDvv syC6OKNV/hpe45S7Ze9p9XJEID1xqIaQ/viSrJylrBQBs6/M3P7UxPEmHq86qUCa KldWPCu7TIkZVG1IdPoC47ULWoTGN2QFpImqqJLfVvMbGzmMtNy6EeRbs1ivQFVW k3Qe/feAOG7T9DeqJCjOg+swabNJJRzl0vKpbj8bQUadPAHNd6YwMKbBQTLsYUdL VsuYnRrkwvprUeLCkLWz5oMks9fZRxLYmEuxDZ3soaiLYx76wbkxC8zzqL6ZVkPQ imhLacyIFX2EN8BmEpFcwTzNpqtWAyDxYqRgCAqM5qg5k0n8zICMUCE1p36sKrsv zc57G9w9fqOKbkaPyau0 =mBhy -----END PGP SIGNATURE----- --5i5vJnjh6kulLZLt-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 29 23:57:56 2013 Return-Path: Delivered-To: current@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 1B11D8E9 for ; Fri, 29 Mar 2013 23:57:56 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by mx1.freebsd.org (Postfix) with ESMTP id DECC3D5 for ; Fri, 29 Mar 2013 23:57:55 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id i18so748459oag.1 for ; Fri, 29 Mar 2013 16:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lEhAqH39wzkmUDQ31puSqfKiRLLxirtTorzUYkGQz9g=; b=yrmUWboSJg/lDK6BHNOr0G8E82t/uoCLU3jyVK1jY5hiEKVdhSU9FSUhgqFlzL7gAS zEdyexdJ76UvNADyB7LyXgIm6i/V3cIedvjcZSvBwJFUO2xFZpoj1uwIs28ZeCgnQsHx UIyJzrwZ2ZSezCG2wgJfBCho1S7+3h0mdjEYoNGrDzALP3jIYeVU5obsz96lmRMuYT7P sidy0p2svj7V1Bkr2b91CYQIBQMA5DL9KhEGrDcOnhmwHbVA7hIghqysnMvQJ/WVJge1 fwudcJc39kqcuPpuLAN3EcZOigRVkYJNeQeZLrXYWfhrm/wMXQV5bB+osJtS6d16tu3P UqWw== MIME-Version: 1.0 X-Received: by 10.60.41.74 with SMTP id d10mr717377oel.30.1364601468988; Fri, 29 Mar 2013 16:57:48 -0700 (PDT) Received: by 10.76.108.7 with HTTP; Fri, 29 Mar 2013 16:57:48 -0700 (PDT) In-Reply-To: <20130329205853.GB3794@kib.kiev.ua> References: <20130328075209.GL3794@kib.kiev.ua> <20130329205853.GB3794@kib.kiev.ua> Date: Fri, 29 Mar 2013 16:57:48 -0700 Message-ID: Subject: Re: [RFC] vfs.read_min proposal From: Maksim Yevmenkin To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 23:57:56 -0000 On Fri, Mar 29, 2013 at 1:58 PM, Konstantin Belousov wrote: > On Thu, Mar 28, 2013 at 10:11:25AM -0700, Maksim Yevmenkin wrote: >> On Thu, Mar 28, 2013 at 12:52 AM, Konstantin Belousov >> wrote: >> >> >> i would like to get some reviews, opinions and/or comments on the patch below. >> >> >> >> a little bit background, as far as i understand, cluster_read() can >> >> initiate two disk i/o's: one for exact amount of data being requested >> >> (rounded up to a filesystem block size) and another for a configurable >> >> read ahead. read ahead data are always extra and do not super set data >> >> being requested. also, read ahead can be controlled via f_seqcount (on >> >> per descriptor basis) and/or vfs.read_max (global knob). >> >> >> >> in some cases and/or on some work loads it can be beneficial to bundle >> >> original data and read ahead data in one i/o request. in other words, >> >> read more than caller has requested, but only perform one larger i/o, >> >> i.e. super set data being requested and read ahead. >> > >> > The totread argument to the cluster_read() is supplied by the filesystem >> > to indicate how many data in the current request is specified. Always >> > overriding this information means two things: >> > - you fill the buffer and page cache with potentially unused data. >> >> it very well could be >> >> > For some situations, like partial reads, it would be really bad. >> >> certainly possible >> >> > - you increase the latency by forcing the reader to wait for the whole >> > cluster which was not asked for. >> >> perhaps, however, modern drives are fast, and, in fact, are a lot >> better at reading continuous chunks without introducing significant >> delays. >> >> > So it looks as very single- and special-purpose hack. Besides, the >> > global knob is obscure and probably would not have any use except your >> > special situation. Would a file flag be acceptable for you ? >> >> flag would probably work just as well, but having global knob allows >> for runtime tuning without software re-configuration and re-start. > My point is that the 'tuning' there has too wide scope to be acceptable > as the feature for the general-puspose OS. i understand. i was just making parallels with vfs.read_max which has just as wider scope. granted, it can be set on per-descriptor basis, but only lowered, imo. >> > What is the difference in the numbers you see, and what numbers ? >> > Is it targeted for read(2) optimizations, or are you also concerned >> > with the read-ahead done at the fault time ? >> >> ok. please consider the following. modern high performance web server >> - nginx - with aio + sendfile(SF_NODISKIO) method of delivering data. >> >> for those who are not familiar how it works, here is a very quick >> overview of nginx's aio + sendfile >> >> 1) nginx always uses sendfile() with SF_NODISKIO to deliver content. >> it means that if requested pages are not in the buffer cache, send as >> much as available and return EBUSY >> >> 2) when nginx sees EBUSY return code from sendfile() it would issue >> aio_read() for 1 byte. the idea here being that OS will issue a read >> ahead and fill up buffer cache with some pages >> >> 3) when aio_read() completes, nginx calls sendfile() with SF_NODISKIO >> again, making an assumption that at least some of the pages will be in >> the buffer cache. >> >> this model allow for completely non-blocking asynchronous data send >> without copying anything back to user space. sounds awesome, right? >> well, it almost is. here is the problem: aio_read() for 1 byte will >> issue read for 1 filesystem block size, and, *another* read for read >> ahead data. say, we configure, read ahead to be 1mb (via >> ioctl(F_READAHEAD and/or vfs.read_max), and, say, our filesystem block >> size is 64k. we end up with 2 disk reads: one for 64k and another for >> 1mb, two trips to VM, and our average size per disk transfer is (64k + >> 1mb) / 2 = 544kb. >> >> now, if we use vfs.read_min and set it to 16, i.e. 1mb reads with 64k >> filesystem block size, turn off read ahead completely, i.e. set >> vfs.read_max to zero, then *all* cluster_reads() become nice 1mb >> chunks, and, we only do one disk i/o and one trip to VM to get the >> same data. so we effectively doubled (or halfed) our iops. also >> average size per disk transfer is around 900kb (there are still some >> filesystem block sized i/o that are not going via cluser_read()) which >> is a lot nicer for modern disks. > I think this is definitely a feature that should be set by a flag to > either file descriptor used for aio_read, or aio_read call itself. > Adding a flag to aio_read() might be cumbersome from the ABI perspective. something along the lines of ioctl(F_READAHEAD)/f_seqcount might be acceptable, dont you think? >> finally, vfs.read_min allows us to control size of orignal disk reads, >> and, vfs.read_max allows us to control of additional read ahead. so, >> ww control both sides here. in fact, we can have 1mb reads and 1mb >> read aheads together. granted, its not going to be optimal for all >> loads. that is why vfs.read_min default is 1. however, i strongly >> suspect that there are quite a few workloads where this could really >> help with disk i/o. > > In fact, the existing OS behaviour is reasonable for the arguments > which are passed to the syscall. The specified read size is 1, and the > current read-ahead algorithm tries to satisfy the request with minimal > latency and without creating additional load under memory pressure, > while starting the useful optimization of the background read. like i said, i really don't buy latency argument here. i personally did not observe any noticeable latency increase. if anything, two side-by-side disk i/o's will like to have more latency than one i/o spanning across both ranges. there is also a potentially bad interaction with cache inside drive itself. but that is really hard to see as we dont get to see inside the drive. > Not lying to the OS could be achieved by somehow specifying to > aio_read() that you do not need copyout, and issuing the request for > read of the full range. This is definitely more work than read_min, > but I think that the result could be useful for the wide audience. the whole idea is to make sure we dont copy anything back user space. anyway... we will probably think of something similar. i just wanted to throw idea out there :) thanks max From owner-freebsd-current@FreeBSD.ORG Sat Mar 30 01:31:13 2013 Return-Path: Delivered-To: freebsd-current@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 28978807; Sat, 30 Mar 2013 01:31:13 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by mx1.freebsd.org (Postfix) with ESMTP id E43E93E0; Sat, 30 Mar 2013 01:31:12 +0000 (UTC) Received: by mail-oa0-f53.google.com with SMTP id m17so754981oag.40 for ; Fri, 29 Mar 2013 18:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=RZrhbTaS1AVkqkOdc5U6IsZFeHpPWrMz1zRP+YhJVwQ=; b=MT76b+kLodWG+ZMoWq3UxWHPy56SbmKZfnr4QbH6FeykO1vX782/dN6raGO2utR3cB kjdmR9vttPubYYgaGz/ICvE3nJ03yCWL7aqhnCy4q5c/ePEitr3RgM41w5s5DzWpL7Ox wsJ839uFLV2qat2cuV4I270ThDXtcGOK9qLh26KNK6a0hUGwLB1XB1Dye2AXy2kEDaGi ACY3LGVTlzeUd/d+tGNNPvvpWNSVAlbeVPSGpQq1k29s4kJpBE9RM+j2LPjzZvQwmdgH zaD3MwgYq7eSnFUexFyhWC9/y6Zy7dJXV7FTtC6TSAI08OdxLRzOC2BQ8AbzwRXPK5yB tMkQ== MIME-Version: 1.0 X-Received: by 10.182.235.49 with SMTP id uj17mr1487357obc.18.1364607072181; Fri, 29 Mar 2013 18:31:12 -0700 (PDT) Received: by 10.182.116.196 with HTTP; Fri, 29 Mar 2013 18:31:12 -0700 (PDT) Date: Fri, 29 Mar 2013 21:31:12 -0400 Message-ID: Subject: Question on building from sources. From: Super Bisquit To: FreeBSD PowerPC ML , freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 01:31:13 -0000 I have my QuickSilver and no internet connection. I have a few questions. 1. Do I download the latest for PowerPC(32bit) and then download the sources according to the Makefile. 2. Will I need to skip checking the hash/md sum so that the applications can build? 3. Has anyone else done this before? If yes, then what were your results? I'm asking on two lists because: 1. It is a PowerPC based machine. 2. It will be an installation of current. Thanks muchly. From owner-freebsd-current@FreeBSD.ORG Sat Mar 30 01:36:42 2013 Return-Path: Delivered-To: current@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 A43E29FA; Sat, 30 Mar 2013 01:36:42 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by mx1.freebsd.org (Postfix) with ESMTP id 5050D618; Sat, 30 Mar 2013 01:36:42 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id l10so771164oag.30 for ; Fri, 29 Mar 2013 18:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XSkgDStVEYXVtioUK4KfBBlA/zAW67F8poh2RNrBiVo=; b=yNurzsmL0WPkC1d6z5WWks5THRuLHG6dKichPfeSeANWhWpoiE2iwfIU7QjPsBUNz/ FMVH6NsvXJ5QOJrOBhieoU69LqrULc1cQbcypnk4u7aPpXiObcWcP5u76Fy3FFwZMs61 Ns99NHWaWJtglouq/rFyHUbwzfDfjselZ1YjTd1nWgRnFMyeq5yPGKG8dCBHoMm/mgD5 xABJr9iAgZmK4pe8jSz3MUdtpKH/VGSDKRGAYjL2nEw7BiWIkv9sO7sM36IKTVpM2Z6S j5OLMGQnOd6W/qSPnchsHDsDLUtov4sjkGHAM+GpB/IFGz00KeMDbUAsMvVbP2F7Sajs 9P0Q== MIME-Version: 1.0 X-Received: by 10.182.131.4 with SMTP id oi4mr1536357obb.64.1364607395843; Fri, 29 Mar 2013 18:36:35 -0700 (PDT) Received: by 10.182.161.100 with HTTP; Fri, 29 Mar 2013 18:36:35 -0700 (PDT) In-Reply-To: <20130330013337.GA19871@crysys.hu> References: <201303300112.r2U1Cr2Z015577@red.freebsd.org> <201303300120.r2U1K0te098396@freefall.freebsd.org> <20130330013337.GA19871@crysys.hu> Date: Sat, 30 Mar 2013 02:36:35 +0100 Message-ID: Subject: Re: ports/177488: qemu-1.4 From: Oliver Pinter To: FreeBSD-gnats-submit@freebsd.org Content-Type: multipart/mixed; boundary=e89a8f646b9d16549a04d91a6b1f Cc: freebsd-ports-bugs@freebsd.org, current@freebsd.org, Pinter Oliver ICTF X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 01:36:42 -0000 --e89a8f646b9d16549a04d91a6b1f Content-Type: text/plain; charset=ISO-8859-1 On 3/30/13, Pinter Oliver ICTF wrote: > CC other mail address > > On Sat, Mar 30, 2013 at 01:20:00AM +0000, FreeBSD-gnats-submit@FreeBSD.org > wrote: >> Thank you very much for your problem report. >> It has the internal identification `ports/177488'. >> The individual assigned to look at your >> report is: freebsd-ports-bugs. >> >> You can access the state of your problem report at any time >> via this link: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=177488 >> >> >Category: ports >> >Responsible: freebsd-ports-bugs >> >Synopsis: qemu-1.4 >> >Arrival-Date: Sat Mar 30 01:20:00 UTC 2013 >> disable some unneeded function, and make qemu 1.4 compilable on FreeBSD 9.1 > --e89a8f646b9d16549a04d91a6b1f Content-Type: text/plain; charset=US-ASCII; name="0001-fix-this-error.patch.txt" Content-Disposition: attachment; filename="0001-fix-this-error.patch.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: file1 RnJvbSA1NzljZjU4OWNhNDVlNmZkN2UxNWQ3YzIxNGRmYTYzYjU3YWU0MTYzIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBPbGl2ZXIgUGludGVyIDxvbGl2ZXIucG50ckBnbWFpbC5jb20+ CkRhdGU6IFNhdCwgMzAgTWFyIDIwMTMgMDE6MDY6NDggKzAxMDAKU3ViamVjdDogW1BBVENIIDEv NF0gZml4IHRoaXMgZXJyb3I6CgpJbiBmaWxlIGluY2x1ZGVkIGZyb20gcWVtdS1jaGFyLmM6NTk6 Ci91c3IvaW5jbHVkZS9saWJ1dGlsLmg6OTg6NjogZXJyb3I6IGNvbmZsaWN0aW5nIHR5cGVzIGZv ciAnaGV4ZHVtcCcKdm9pZCAgICBoZXhkdW1wKGNvbnN0IHZvaWQgKl9wdHIsIGludCBfbGVuZ3Ro LCBjb25zdCBjaGFyICpfaGRyLCBpbnQKCQlfZmxhZ3MpOwogICAgICAgIF4KCS90bXAvcWVtdS9p bmNsdWRlL3FlbXUtY29tbW9uLmg6NDQ5OjY6IG5vdGU6IHByZXZpb3VzCglkZWNsYXJhdGlvbiBp cyBoZXJlCgl2b2lkIGhleGR1bXAoY29uc3QgY2hhciAqYnVmLCBGSUxFICpmcCwgY29uc3QgY2hh ciAqcHJlZml4LAoJCQlzaXplX3Qgc2l6ZSk7CiAgICAgXgogICAgIDEgZXJyb3IgZ2VuZXJhdGVk LgogICAgIGdtYWtlOiAqKiogW3FlbXUtY2hhci5vXSBFcnJvciAxCgpTaWduZWQtb2ZmLWJ5OiBP bGl2ZXIgUGludGVyIDxvbGl2ZXIucG50ckBnbWFpbC5jb20+Ci0tLQogaHcvcGwzMzAuYyAgICAg ICAgICAgIHwgNCArKy0tCiBpbmNsdWRlL3FlbXUtY29tbW9uLmggfCAyICstCiB1dGlsL2hleGR1 bXAuYyAgICAgICAgfCAyICstCiAzIGZpbGVzIGNoYW5nZWQsIDQgaW5zZXJ0aW9ucygrKSwgNCBk ZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9ody9wbDMzMC5jIGIvaHcvcGwzMzAuYwppbmRleCAx YTA0NzczLi5hYzY2MWViIDEwMDY0NAotLS0gYS9ody9wbDMzMC5jCisrKyBiL2h3L3BsMzMwLmMK QEAgLTExNTgsNyArMTE1OCw3IEBAIHN0YXRpYyBpbnQgcGwzMzBfZXhlY19jeWNsZShQTDMzMENo YW4gKmNoYW5uZWwpCiAgICAgICAgIGlmIChQTDMzMF9FUlJfREVCVUcgPiAxKSB7CiAgICAgICAg ICAgICBEQl9QUklOVCgiUEwzMzAgcmVhZCBmcm9tIG1lbW9yeSBAJTA4eCAoc2l6ZSA9ICUwOHgp OlxuIiwKICAgICAgICAgICAgICAgICAgICAgICBxLT5hZGRyLCBsZW4pOwotICAgICAgICAgICAg aGV4ZHVtcCgoY2hhciAqKWJ1Ziwgc3RkZXJyLCAiIiwgbGVuKTsKKyAgICAgICAgICAgIHFlbXVf aGV4ZHVtcCgoY2hhciAqKWJ1Ziwgc3RkZXJyLCAiIiwgbGVuKTsKICAgICAgICAgfQogICAgICAg ICBmaWZvX3JlcyA9IHBsMzMwX2ZpZm9fcHVzaCgmcy0+ZmlmbywgYnVmLCBsZW4sIHEtPnRhZyk7 CiAgICAgICAgIGlmIChmaWZvX3JlcyA9PSBQTDMzMF9GSUZPX09LKSB7CkBAIC0xMTkwLDcgKzEx OTAsNyBAQCBzdGF0aWMgaW50IHBsMzMwX2V4ZWNfY3ljbGUoUEwzMzBDaGFuICpjaGFubmVsKQog ICAgICAgICAgICAgaWYgKFBMMzMwX0VSUl9ERUJVRyA+IDEpIHsKICAgICAgICAgICAgICAgICBE Ql9QUklOVCgiUEwzMzAgcmVhZCBmcm9tIG1lbW9yeSBAJTA4eCAoc2l6ZSA9ICUwOHgpOlxuIiwK ICAgICAgICAgICAgICAgICAgICAgICAgICBxLT5hZGRyLCBsZW4pOwotICAgICAgICAgICAgICAg IGhleGR1bXAoKGNoYXIgKilidWYsIHN0ZGVyciwgIiIsIGxlbik7CisgICAgICAgICAgICAgICAg cWVtdV9oZXhkdW1wKChjaGFyICopYnVmLCBzdGRlcnIsICIiLCBsZW4pOwogICAgICAgICAgICAg fQogICAgICAgICAgICAgaWYgKHEtPmluYykgewogICAgICAgICAgICAgICAgIHEtPmFkZHIgKz0g bGVuOwpkaWZmIC0tZ2l0IGEvaW5jbHVkZS9xZW11LWNvbW1vbi5oIGIvaW5jbHVkZS9xZW11LWNv bW1vbi5oCmluZGV4IDMxZmZmMjIuLmUzY2FkOGEgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUvcWVtdS1j b21tb24uaAorKysgYi9pbmNsdWRlL3FlbXUtY29tbW9uLmgKQEAgLTQ0Niw3ICs0NDYsNyBAQCBp bnQgdWxlYjEyOF9kZWNvZGVfc21hbGwoY29uc3QgdWludDhfdCAqaW4sIHVpbnQzMl90ICpuKTsK ICAqIEhleGR1bXAgYSBidWZmZXIgdG8gYSBmaWxlLiBBbiBvcHRpb25hbCBzdHJpbmcgcHJlZml4 IGlzIGFkZGVkIHRvIGV2ZXJ5IGxpbmUKICAqLwogCi12b2lkIGhleGR1bXAoY29uc3QgY2hhciAq YnVmLCBGSUxFICpmcCwgY29uc3QgY2hhciAqcHJlZml4LCBzaXplX3Qgc2l6ZSk7Cit2b2lkIHFl bXVfaGV4ZHVtcChjb25zdCBjaGFyICpidWYsIEZJTEUgKmZwLCBjb25zdCBjaGFyICpwcmVmaXgs IHNpemVfdCBzaXplKTsKIAogLyogdmVjdG9yIGRlZmluaXRpb25zICovCiAjaWZkZWYgX19BTFRJ VkVDX18KZGlmZiAtLWdpdCBhL3V0aWwvaGV4ZHVtcC5jIGIvdXRpbC9oZXhkdW1wLmMKaW5kZXgg MGQwZWZjOC4uOTY5YjM0MCAxMDA2NDQKLS0tIGEvdXRpbC9oZXhkdW1wLmMKKysrIGIvdXRpbC9o ZXhkdW1wLmMKQEAgLTE1LDcgKzE1LDcgQEAKIAogI2luY2x1ZGUgInFlbXUtY29tbW9uLmgiCiAK LXZvaWQgaGV4ZHVtcChjb25zdCBjaGFyICpidWYsIEZJTEUgKmZwLCBjb25zdCBjaGFyICpwcmVm aXgsIHNpemVfdCBzaXplKQordm9pZCBxZW11X2hleGR1bXAoY29uc3QgY2hhciAqYnVmLCBGSUxF ICpmcCwgY29uc3QgY2hhciAqcHJlZml4LCBzaXplX3Qgc2l6ZSkKIHsKICAgICB1bnNpZ25lZCBp bnQgYjsKIAotLSAKMS44LjIKCg== --e89a8f646b9d16549a04d91a6b1f Content-Type: text/plain; charset=US-ASCII; name="0002-removed-usb-redir-support-while-it-is-broken.patch.txt" Content-Disposition: attachment; filename="0002-removed-usb-redir-support-while-it-is-broken.patch.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: file2 RnJvbSAyNzgxMGFmYjk5OWM5YWNiNmRjODFmMGU5NDkwZmQ2OWRkMzc4MjUxIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBPbGl2ZXIgUGludGVyIDxvbGl2ZXIucG50ckBnbWFpbC5jb20+ CkRhdGU6IFNhdCwgMzAgTWFyIDIwMTMgMDE6MTE6NTggKzAxMDAKU3ViamVjdDogW1BBVENIIDIv NF0gcmVtb3ZlZCB1c2ItcmVkaXIgc3VwcG9ydCwgd2hpbGUgaXQgaXMgYnJva2VuIC4uLgoKU2ln bmVkLW9mZi1ieTogT2xpdmVyIFBpbnRlciA8b2xpdmVyLnBudHJAZ21haWwuY29tPgotLS0KIGNv bmZpZ3VyZSB8IDEgLQogMSBmaWxlIGNoYW5nZWQsIDEgZGVsZXRpb24oLSkKCmRpZmYgLS1naXQg YS9jb25maWd1cmUgYi9jb25maWd1cmUKaW5kZXggZjJhZjcxNC4uYmE0MDc1NiAxMDA3NTUKLS0t IGEvY29uZmlndXJlCisrKyBiL2NvbmZpZ3VyZQpAQCAtNTQwLDcgKzU0MCw2IEBAIGVzYWMKIAog aWYgWyAiJGJzZCIgPSAieWVzIiBdIDsgdGhlbgogICBpZiBbICIkZGFyd2luIiAhPSAieWVzIiBd IDsgdGhlbgotICAgIHVzYj0iYnNkIgogICAgIGJzZF91c2VyPSJ5ZXMiCiAgIGZpCiBmaQotLSAK MS44LjIKCg== --e89a8f646b9d16549a04d91a6b1f Content-Type: text/plain; charset=US-ASCII; name="0003-fix-round_page-redefinition.patch.txt" Content-Disposition: attachment; filename="0003-fix-round_page-redefinition.patch.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: file3 RnJvbSBmMmQ0YmJjNjE4YmQ2YWFjZDY5MjZkZDA1OWEyYTdlZTY0OWQ0ZmY4IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBPbGl2ZXIgUGludGVyIDxvbGl2ZXIucG50ckBnbWFpbC5jb20+ CkRhdGU6IFNhdCwgMzAgTWFyIDIwMTMgMDE6Mzg6NTMgKzAxMDAKU3ViamVjdDogW1BBVENIIDMv NF0gZml4IHJvdW5kX3BhZ2UgcmVkZWZpbml0aW9uCgovdG1wL3FlbXUvaHcvcHBjL21hY19vbGR3 b3JsZC5jOjYxOjE1OiBlcnJvcjogZXhwZWN0ZWQgaWRlbnRpZmllciBvciAnKCcKc3RhdGljIGh3 YWRkciByb3VuZF9wYWdlKGh3YWRkciBhZGRyKQogICAgICAgICAgICAgIF4KL3Vzci9pbmNsdWRl L21hY2hpbmUvcGFyYW0uaDoxMjg6Mjc6IG5vdGU6IGV4cGFuZGVkIGZyb20gbWFjcm8gJ3JvdW5k X3BhZ2UnCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBeCi90bXAvcWVtdS9ody9wcGMvbWFj X29sZHdvcmxkLmM6NjE6MTU6IGVycm9yOiBleHBlY3RlZCAnKScKc3RhdGljIGh3YWRkciByb3Vu ZF9wYWdlKGh3YWRkciBhZGRyKQogICAgICAgICAgICAgIF4KL3Vzci9pbmNsdWRlL21hY2hpbmUv cGFyYW0uaDoxMjg6Mjc6IG5vdGU6IGV4cGFuZGVkIGZyb20gbWFjcm8gJ3JvdW5kX3BhZ2UnCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICBeCi90bXAvcWVtdS9ody9wcGMvbWFjX29sZHdvcmxk LmM6NjE6MTU6IG5vdGU6IHRvIG1hdGNoIHRoaXMgJygnCnN0YXRpYyBod2FkZHIgcm91bmRfcGFn ZShod2FkZHIgYWRkcikKICAgICAgICAgICAgICBeCi91c3IvaW5jbHVkZS9tYWNoaW5lL3BhcmFt Lmg6MTI4OjI2OiBub3RlOiBleHBhbmRlZCBmcm9tIG1hY3JvICdyb3VuZF9wYWdlJwogICAgICAg ICAgICAgICAgICAgICAgICAgICBeCi90bXAvcWVtdS9ody9wcGMvbWFjX29sZHdvcmxkLmM6NjE6 MTU6IGVycm9yOiBleHBlY3RlZCAnKScKc3RhdGljIGh3YWRkciByb3VuZF9wYWdlKGh3YWRkciBh ZGRyKQogICAgICAgICAgICAgIF4KL3Vzci9pbmNsdWRlL21hY2hpbmUvcGFyYW0uaDoxMjg6NDY6 IG5vdGU6IGV4cGFuZGVkIGZyb20gbWFjcm8gJ3JvdW5kX3BhZ2UnCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXgovdG1wL3FlbXUvaHcvcHBjL21hY19vbGR3 b3JsZC5jOjYxOjE1OiBub3RlOiB0byBtYXRjaCB0aGlzICcoJwpzdGF0aWMgaHdhZGRyIHJvdW5k X3BhZ2UoaHdhZGRyIGFkZHIpCiAgICAgICAgICAgICAgXgovdXNyL2luY2x1ZGUvbWFjaGluZS9w YXJhbS5oOjEyODoyNDogbm90ZTogZXhwYW5kZWQgZnJvbSBtYWNybyAncm91bmRfcGFnZScKICAg ICAgICAgICAgICAgICAgICAgICAgIF4KL3RtcC9xZW11L2h3L3BwYy9tYWNfb2xkd29ybGQuYzo2 MToxNTogZXJyb3I6IGV4cGVjdGVkICcpJwpzdGF0aWMgaHdhZGRyIHJvdW5kX3BhZ2UoaHdhZGRy IGFkZHIpCiAgICAgICAgICAgICAgXgovdXNyL2luY2x1ZGUvbWFjaGluZS9wYXJhbS5oOjEyODo1 OTogbm90ZTogZXhwYW5kZWQgZnJvbSBtYWNybyAncm91bmRfcGFnZScKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXgovdG1wL3FlbXUv aHcvcHBjL21hY19vbGR3b3JsZC5jOjYxOjE1OiBub3RlOiB0byBtYXRjaCB0aGlzICcoJwpzdGF0 aWMgaHdhZGRyIHJvdW5kX3BhZ2UoaHdhZGRyIGFkZHIpCiAgICAgICAgICAgICAgXgovdXNyL2lu Y2x1ZGUvbWFjaGluZS9wYXJhbS5oOjEyODoyMzogbm90ZTogZXhwYW5kZWQgZnJvbSBtYWNybyAn cm91bmRfcGFnZScKICAgICAgICAgICAgICAgICAgICAgICAgXgo0IGVycm9ycyBnZW5lcmF0ZWQu CmdtYWtlWzFdOiAqKiogW2h3L3BwYy9tYWNfb2xkd29ybGQub10gRXJyb3IgMQpnbWFrZTogKioq IFtzdWJkaXItcHBjLXNvZnRtbXVdIEVycm9yIDIKLS0tCiBody9wcGMvbWFjX25ld3dvcmxkLmMg fCA0ICsrKysKIGh3L3BwYy9tYWNfb2xkd29ybGQuYyB8IDQgKysrKwogMiBmaWxlcyBjaGFuZ2Vk LCA4IGluc2VydGlvbnMoKykKCmRpZmYgLS1naXQgYS9ody9wcGMvbWFjX25ld3dvcmxkLmMgYi9o dy9wcGMvbWFjX25ld3dvcmxkLmMKaW5kZXggYTA4YTZiMi4uN2RmNDYyMiAxMDA2NDQKLS0tIGEv aHcvcHBjL21hY19uZXd3b3JsZC5jCisrKyBiL2h3L3BwYy9tYWNfbmV3d29ybGQuYwpAQCAtODIs NiArODIsMTAgQEAKICNkZWZpbmUgVU5JTl9EUFJJTlRGKGZtdCwgLi4uKQogI2VuZGlmCiAKKyNp ZmRlZiBfX0ZyZWVCU0RfXworI3VuZGVmCXJvdW5kX3BhZ2UKKyNlbmRpZiAvLyBfX0ZyZWVCU0Rf XworCiAvKiBVbmlOIGRldmljZSAqLwogc3RhdGljIHZvaWQgdW5pbl93cml0ZSh2b2lkICpvcGFx dWUsIGh3YWRkciBhZGRyLCB1aW50NjRfdCB2YWx1ZSwKICAgICAgICAgICAgICAgICAgICAgICAg dW5zaWduZWQgc2l6ZSkKZGlmZiAtLWdpdCBhL2h3L3BwYy9tYWNfb2xkd29ybGQuYyBiL2h3L3Bw Yy9tYWNfb2xkd29ybGQuYwppbmRleCAyNzc4ZTQ1Li45YTgzMjkwIDEwMDY0NAotLS0gYS9ody9w cGMvbWFjX29sZHdvcmxkLmMKKysrIGIvaHcvcHBjL21hY19vbGR3b3JsZC5jCkBAIC00Myw2ICs0 MywxMCBAQAogI2luY2x1ZGUgInN5c2VtdS9ibG9ja2Rldi5oIgogI2luY2x1ZGUgImV4ZWMvYWRk cmVzcy1zcGFjZXMuaCIKIAorI2lmZGVmCV9fRnJlZUJTRF9fCisjdW5kZWYJcm91bmRfcGFnZQor I2VuZGlmCS8vIF9fRnJlZUJTRF9fCisKICNkZWZpbmUgTUFYX0lERV9CVVMgMgogI2RlZmluZSBD RkdfQUREUiAweGYwMDAwNTEwCiAKLS0gCjEuOC4yCgo= --e89a8f646b9d16549a04d91a6b1f Content-Type: text/plain; charset=US-ASCII; name="0004-fix-CTLTYPE_QUAD-related-compile-error.patch.txt" Content-Disposition: attachment; filename="0004-fix-CTLTYPE_QUAD-related-compile-error.patch.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: file4 RnJvbSBlNmFlMmVmZTFlOGU4ZDA3MDZhNGNhYzIxNWRkZTJiODYyNWNhMDYyIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBPbGl2ZXIgUGludGVyIDxvbGl2ZXIucG50ckBnbWFpbC5jb20+ CkRhdGU6IFNhdCwgMzAgTWFyIDIwMTMgMDE6NDY6MDQgKzAxMDAKU3ViamVjdDogW1BBVENIIDQv NF0gZml4IENUTFRZUEVfUVVBRCByZWxhdGVkIGNvbXBpbGUgZXJyb3IKClNpZ25lZC1vZmYtYnk6 IE9saXZlciBQaW50ZXIgPG9saXZlci5wbnRyQGdtYWlsLmNvbT4KLS0tCiBic2QtdXNlci9zeXNj YWxsLmMgfCAyICsrCiAxIGZpbGUgY2hhbmdlZCwgMiBpbnNlcnRpb25zKCspCgpkaWZmIC0tZ2l0 IGEvYnNkLXVzZXIvc3lzY2FsbC5jIGIvYnNkLXVzZXIvc3lzY2FsbC5jCmluZGV4IDE4YjQzZjEu LjE1NmViYzYgMTAwNjQ0Ci0tLSBhL2JzZC11c2VyL3N5c2NhbGwuYworKysgYi9ic2QtdXNlci9z eXNjYWxsLmMKQEAgLTM2LDYgKzM2LDggQEAKICNpbmNsdWRlICJxZW11LmgiCiAjaW5jbHVkZSAi cWVtdS1jb21tb24uaCIKIAorI2RlZmluZQlDVExUWVBFX1FVQUQgQ1RMVFlQRV9VNjQKKwogLy8j ZGVmaW5lIERFQlVHCiAKIHN0YXRpYyBhYmlfdWxvbmcgdGFyZ2V0X2JyazsKLS0gCjEuOC4yCgo= --e89a8f646b9d16549a04d91a6b1f Content-Type: text/plain; charset=US-ASCII; name="0005-disable-bsd-user.patch.txt" Content-Disposition: attachment; filename="0005-disable-bsd-user.patch.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: file5 RnJvbSA5MWVjOWU0YmJlY2ZiNjQxZWZmMmNiZDA1ZWM0YmM3MDI2ZjZjNGFmIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBPbGl2ZXIgUGludGVyIDxvbGl2ZXIucG50ckBnbWFpbC5jb20+ CkRhdGU6IFNhdCwgMzAgTWFyIDIwMTMgMDI6MTA6MjIgKzAxMDAKU3ViamVjdDogW1BBVENIIDUv NV0gZGlzYWJsZSBic2QtdXNlcgoKU2lnbmVkLW9mZi1ieTogT2xpdmVyIFBpbnRlciA8b2xpdmVy LnBudHJAZ21haWwuY29tPgotLS0KIGNvbmZpZ3VyZSB8IDIgKy0KIDEgZmlsZSBjaGFuZ2VkLCAx IGluc2VydGlvbigrKSwgMSBkZWxldGlvbigtKQoKZGlmZiAtLWdpdCBhL2NvbmZpZ3VyZSBiL2Nv bmZpZ3VyZQppbmRleCBiYTQwNzU2Li4zYmYyODcxIDEwMDc1NQotLS0gYS9jb25maWd1cmUKKysr IGIvY29uZmlndXJlCkBAIC01NDAsNyArNTQwLDcgQEAgZXNhYwogCiBpZiBbICIkYnNkIiA9ICJ5 ZXMiIF0gOyB0aGVuCiAgIGlmIFsgIiRkYXJ3aW4iICE9ICJ5ZXMiIF0gOyB0aGVuCi0gICAgYnNk X3VzZXI9InllcyIKKwkgICMgbm90aGluZwogICBmaQogZmkKIAotLSAKMS44LjIKCg== --e89a8f646b9d16549a04d91a6b1f-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 30 02:03:16 2013 Return-Path: Delivered-To: freebsd-current@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 2B18B1CE; Sat, 30 Mar 2013 02:03:16 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 01F2C836; Sat, 30 Mar 2013 02:03:16 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id C83E023F804; Fri, 29 Mar 2013 22:03:13 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.0 onyx.glenbarber.us C83E023F804 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Fri, 29 Mar 2013 22:03:11 -0400 From: Glen Barber To: Super Bisquit Subject: Re: Question on building from sources. Message-ID: <20130330020311.GB1687@glenbarber.us> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5I6of5zJg18YgZEa" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current , FreeBSD PowerPC ML X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 02:03:16 -0000 --5I6of5zJg18YgZEa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 29, 2013 at 09:31:12PM -0400, Super Bisquit wrote: > I have my QuickSilver and no internet connection. I have a few questions. > 1. Do I download the latest for PowerPC(32bit) and then download the > sources according to the Makefile. For ports, yes, you will to do 'make fetch' or 'make fetch-recursive' for third-party software you want to install. > 2. Will I need to skip checking the hash/md sum so that the > applications can build? No. Hashes are generated locally and compared against information in the distinfo file. If there is a mismatch, that is a bug. > 3. Has anyone else done this before? If yes, then what were your results? >=20 It is painful. My suggestion is to identify everything you absolutely need, and do from a separate machine with internet access: # sh -c 'for i in `make -C /usr/ports/category/port all-depends-list`; \ do make -C $i fetch-recursive; \ done Note that if anything is missing, build will fail at compile time on the internet-less machine. Glen --5I6of5zJg18YgZEa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRVkffAAoJEFJPDDeguUajqvoH/R7MCaj17J2+Pey3QBQ5P3oQ 1rSpAIXCjO9HDEnb951S7uY+xFqz7hyv/ExnY9oP7Q/oOkmrpDefcbqKBXBfc5AP mJOs2u47sJilbL/SYSI4n5q6dPQqfeAa2jbMEWamAfTV8Fsv33RBYGsYqz9qv5u+ 16UfQsdky4E8qDAbZZohFN4W9Q/p2UTj0f2p5BB3T4g9inqWBJIV9CZPIg2DvJrV X0oj2gmLtYy6PpJVr3wQ1p/kGq6XFrGlXUidqop40ekhnc8uzGBvTUpDvDmhPyGi Z/faAxyovFT+G8fV41aRjzxczxXFa6fExC0OwHXTbOgt1IxZoTFkfn8+LBMF6i4= =EK6X -----END PGP SIGNATURE----- --5I6of5zJg18YgZEa-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 30 02:33:57 2013 Return-Path: Delivered-To: freebsd-current@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 D8AF08CA; Sat, 30 Mar 2013 02:33:57 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id 9E2F7935; Sat, 30 Mar 2013 02:33:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=c+7y8tuBYjoSTCq87BnSddYL2xI8ZoOk4gmTxmIpHts=; b=Cjig3rS2CLJyqJ+GWkUovyrcmRql3NmHofTXCw2SDXuZ8KBBvg1WZw8IMpI2n6EcYyW5K2gWgx/ILuq5aMRygg0fN0zw9RhAaSfPTtbNmIylZtRGH0+RcnowxY6gRFQ/gg6yLra3qP5EfVWrhzENWoJKknKLGta8DtE+JAXzyaw=; Received: from [122.129.203.50] (port=30799 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1ULlcC-0042HQ-Gp; Fri, 29 Mar 2013 20:33:57 -0600 Date: Sat, 30 Mar 2013 09:33:52 +0700 From: Erich Dollansky To: Glen Barber Subject: Re: Question on building from sources. Message-ID: <20130330093352.58bb5539@X220.ovitrap.com> In-Reply-To: <20130330020311.GB1687@glenbarber.us> References: <20130330020311.GB1687@glenbarber.us> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: Super Bisquit , freebsd-current , FreeBSD PowerPC ML X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 02:33:57 -0000 Hi, On Fri, 29 Mar 2013 22:03:11 -0400 Glen Barber wrote: > On Fri, Mar 29, 2013 at 09:31:12PM -0400, Super Bisquit wrote: > > I have my QuickSilver and no internet connection. I have a few > > questions. 1. Do I download the latest for PowerPC(32bit) and then > > download the sources according to the Makefile. > > For ports, yes, you will to do 'make fetch' or 'make fetch-recursive' > for third-party software you want to install. > yes. > > 3. Has anyone else done this before? If yes, then what were your > > results? > > > > It is painful. My suggestion is to identify everything you absolutely > need, and do from a separate machine with internet access: > I do this all the while as I have only random Internet connection. But I do this only for amd64. It works most of the time. Expect some returns to the machine with an Internet connection. > Note that if anything is missing, build will fail at compile time on > the internet-less machine. This should only be a problem for the ports. The sources can easily be downloaded in one go. Erich From owner-freebsd-current@FreeBSD.ORG Sat Mar 30 07:51:25 2013 Return-Path: Delivered-To: current@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 42812C09 for ; Sat, 30 Mar 2013 07:51:25 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 0724E66C for ; Sat, 30 Mar 2013 07:51:24 +0000 (UTC) Received: from [127.0.0.1] (Scott4long@pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id r2U7pF8G062998; Sat, 30 Mar 2013 01:51:15 -0600 (MDT) (envelope-from scottl@samsco.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [RFC] vfs.read_min proposal From: Scott Long In-Reply-To: <20130329205853.GB3794@kib.kiev.ua> Date: Sat, 30 Mar 2013 01:51:15 -0600 Content-Transfer-Encoding: 7bit Message-Id: <8F56D4EB-E63F-4D52-A495-903019E129AF@samsco.org> References: <20130328075209.GL3794@kib.kiev.ua> <20130329205853.GB3794@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1503) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: current@freebsd.org, Maksim Yevmenkin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 07:51:25 -0000 On Mar 29, 2013, at 2:58 PM, Konstantin Belousov wrote: >> > I think this is definitely a feature that should be set by a flag to > either file descriptor used for aio_read, or aio_read call itself. > Adding a flag to aio_read() might be cumbersome from the ABI perspective. > Fine if you think that there should be a corresponding fcntl() operation, but I see good reason to also have a vfs.read_min that compliments vfs_read_max. It's no less obscure. >> >> finally, vfs.read_min allows us to control size of orignal disk reads, >> and, vfs.read_max allows us to control of additional read ahead. so, >> ww control both sides here. in fact, we can have 1mb reads and 1mb >> read aheads together. granted, its not going to be optimal for all >> loads. that is why vfs.read_min default is 1. however, i strongly >> suspect that there are quite a few workloads where this could really >> help with disk i/o. > > In fact, the existing OS behaviour is reasonable for the arguments > which are passed to the syscall. The specified read size is 1, and the > current read-ahead algorithm tries to satisfy the request with minimal > latency and without creating additional load under memory pressure, > while starting the useful optimization of the background read. > The doubled transaction made a lot of sense back when disks were very slow. Now, let's use a modern example: Default UFS block size = 16k Default vfs.read_max = 8 (128k) Time spent transferring a 16k block over 3Gbps SATA: 54ns Time spent transferring a 128k block over 3Gbps SATA: 436ns Time spent seeking to the 16k/128k block: Average 8ms on modern disks. % time spent on data vs seek, 16k: 0.68% % time spent on data vs seek, 128k: 5.4% It'll take you 5% longer to get a completion back. Not nothing, but it's also not something that would be turned on by default, at least not right now. For 6Gbps SATA, it'll be half of that. However, this is a very idealized example. When you start getting a busy disk and the seek times reach the hundreds of milliseconds, this overhead goes well into the noise. At the same time, reducing the number of concurrent, unbalanced transactions to the disk makes them perform much better when they are at their performance saturation point, and we have very solid numbers to prove it. I think that there's still a place for doubled transactions for read ahead, and that place would likely be with low-latency flash, but there's a lot of other factors that get in the way of that right now in FreeBSD, like the overhead of the threaded handoffs in GEOM. As this area is developed over the next 6 months, and as we have more time to build and test more models, I'm sure well get some interesting data. But for now, I'll argue that Max's proposal is sound and is low maintenance. > Not lying to the OS could be achieved by somehow specifying to > aio_read() that you do not need copyout, and issuing the request for > read of the full range. This is definitely more work than read_min, > but I think that the result could be useful for the wide audience. A side-effect of the aio_mlock() work that's also going on right now is that we won't need to lie to the OS anymore. We still may not want to do a doubled transaction for read-ahead though because we're constrained on disk transactional bandwidth and we don't know that we'll always actually use the data that gets read-ahead. In any case, it's hard for me to resolve the arguments for giving freebsd the tools to let people make it faster in demonstrable ways, and then arguing that the tools offered won't be used and are too obscure. Let's move forward with this. Scott From owner-freebsd-current@FreeBSD.ORG Sat Mar 30 08:24:49 2013 Return-Path: Delivered-To: current@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 802B5237; Sat, 30 Mar 2013 08:24:49 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 41D7675D; Sat, 30 Mar 2013 08:24:48 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 0F9601E007A1; Sat, 30 Mar 2013 09:24:48 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.5/8.14.4) with ESMTP id r2U8Ni1O011719; Sat, 30 Mar 2013 09:23:44 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.5/8.14.3/Submit) id r2U8Ni94011718; Sat, 30 Mar 2013 09:23:44 +0100 (CET) (envelope-from nox) From: Juergen Lock Date: Sat, 30 Mar 2013 09:23:44 +0100 To: Oliver Pinter Subject: Re: ports/177488: qemu-1.4 Message-ID: <20130330082344.GA11534@triton8.kn-bremen.de> References: <201303300112.r2U1Cr2Z015577@red.freebsd.org> <201303300120.r2U1K0te098396@freefall.freebsd.org> <20130330013337.GA19871@crysys.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-ports-bugs@freebsd.org, current@freebsd.org, bug-followup@freebsd.org, Pinter Oliver ICTF X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 08:24:49 -0000 On Sat, Mar 30, 2013 at 02:36:35AM +0100, Oliver Pinter wrote: >[..] > > disable some unneeded function, and make qemu 1.4 compilable on FreeBSD 9.1 > I think you are building qemu git head as the hexdump function at least isn't in 1.4.0? Anyway I have meanwhile updated the qemu-devel port to 1.4.0 with some similar patches to yours and (among other things) preliminary bsd-user improvements mostly by ssson and cognet, will leave the PR open for when I need the hexdump patch for a future update. Thanx, Juergen From owner-freebsd-current@FreeBSD.ORG Sat Mar 30 12:55:06 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1AA67A54; Sat, 30 Mar 2013 12:55:06 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by mx1.freebsd.org (Postfix) with ESMTP id D05F73E6; Sat, 30 Mar 2013 12:55:05 +0000 (UTC) Received: from jh (a91-153-115-208.elisa-laajakaista.fi [91.153.115.208]) by gw03.mail.saunalahti.fi (Postfix) with SMTP id 0279D21658B; Sat, 30 Mar 2013 14:45:22 +0200 (EET) Date: Sat, 30 Mar 2013 14:45:22 +0200 From: Jaakko Heinonen To: Andriy Gapon Subject: Re: big change to devfs rules path matching Message-ID: <20130330120724.GB32407@jh> References: <5150B598.7050700@FreeBSD.org> <5150B71B.6060106@FreeBSD.org> <5154012A.4010602@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5154012A.4010602@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@FreeBSD.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 12:55:06 -0000 On 2013-03-28, Andriy Gapon wrote: > > Would like to ask for opinions on this topic... > > Please read this PR for context: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122838 > > Especially Jaakko's insightful description of the problem. > > So I would like to commit the following patch sooner rather than later: > http://people.freebsd.org/~avg/devfs_rule.diff > The only difference from the Jaakko's patch in the PR is FNM_PATHNAME. > > Please review and test. Good to see this moving forward! Maybe the change warrants an UPDATING entry? -- Jaakko From owner-freebsd-current@FreeBSD.ORG Sat Mar 30 17:22:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5F371AF5; Sat, 30 Mar 2013 17:22:42 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 154451C4; Sat, 30 Mar 2013 17:22:42 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id x4so1025491obh.30 for ; Sat, 30 Mar 2013 10:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PDmJmXz1fk4XuK1kXh1cF95YMoHBjc2H6ULD6ocubJ4=; b=uDctVgTTfijKE0Z37hDa52m/F/oBjubIRN4CYRTiFYIm39j1eH5MF7xNhf8/kAMy8V 5t5styQvkvvKelgvbslBfj61YUHWv1+/etfrdMOPY48Gf3aTwxoIoAbcH+cG9JE8Zs5X iB000V9osWhYP5T8aGJPo2GrrQsjadR38fb753Urf4l8+H96pYQDRXhALaGanZePRmH+ vNPGKYUM3/80EC8kA9PdGFUdO81UEFPz69PmNHu9uStzVkRAStrTQWAXkP0IarT7nBbo iQ2OzknONZkWyVaf59g7OUtEIrpLWtqeF5jRWgdYxkrgtSpypvmuUumWTMfh2+Aidhhi GLrg== MIME-Version: 1.0 X-Received: by 10.182.1.10 with SMTP id 10mr2230725obi.15.1364664161679; Sat, 30 Mar 2013 10:22:41 -0700 (PDT) Received: by 10.182.161.100 with HTTP; Sat, 30 Mar 2013 10:22:41 -0700 (PDT) In-Reply-To: <20130330082344.GA11534@triton8.kn-bremen.de> References: <201303300112.r2U1Cr2Z015577@red.freebsd.org> <201303300120.r2U1K0te098396@freefall.freebsd.org> <20130330013337.GA19871@crysys.hu> <20130330082344.GA11534@triton8.kn-bremen.de> Date: Sat, 30 Mar 2013 18:22:41 +0100 Message-ID: Subject: Re: ports/177488: qemu-1.4 From: Oliver Pinter To: Juergen Lock Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-ports-bugs@freebsd.org, current@freebsd.org, bug-followup@freebsd.org, Pinter Oliver ICTF X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 17:22:42 -0000 yes this is git head, sorry On 3/30/13, Juergen Lock wrote: > On Sat, Mar 30, 2013 at 02:36:35AM +0100, Oliver Pinter wrote: >>[..] >> >> disable some unneeded function, and make qemu 1.4 compilable on FreeBSD >> 9.1 >> > > I think you are building qemu git head as the hexdump function at least > isn't in 1.4.0? Anyway I have meanwhile updated the qemu-devel port > to 1.4.0 with some similar patches to yours and (among other things) > preliminary bsd-user improvements mostly by ssson and cognet, will > leave the PR open for when I need the hexdump patch for a future > update. > > Thanx, > Juergen > From owner-freebsd-current@FreeBSD.ORG Sat Mar 30 17:52:32 2013 Return-Path: Delivered-To: current@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 B156B269; Sat, 30 Mar 2013 17:52:32 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by mx1.freebsd.org (Postfix) with ESMTP id 62F292AD; Sat, 30 Mar 2013 17:52:31 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id k14so1118863oag.11 for ; Sat, 30 Mar 2013 10:52:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=s6Xs8JNXUAuX/cQRs2xfroeG53fG43ugVWjPC4cSTCE=; b=iREAiLbwKZeUu4vw/f7RNFIHqdMgaH94UiEUlnTSQmbX7n+ngjqqQGLsG+0NT9DiV+ xluwCZtIjyf7OqDEdwUmYLVccvKS11hjTluecBUSF0eDVJF/3z2doPoegN7INLrYUYoS nLiqgYyeGBFpd/D2Cs4UWpOvIkSACJHX///zB0SiUfvF+63B5DFYMELKek/DOQVHDwgs WpTipF/CCvMbwXHZra9sjvJWR2UqyJZn4SaZF3+TOLh1C7lLo39HRGoPyInBdxxmFzAb 0QQV1/XjFUu8UxBSpjDhpYCTfG1u2M3/b5+KQGDnaADFjoalT1kWYZD1vM2K+BSoNKfk Pq5g== MIME-Version: 1.0 X-Received: by 10.182.2.132 with SMTP id 4mr2232047obu.42.1364665945364; Sat, 30 Mar 2013 10:52:25 -0700 (PDT) Received: by 10.182.161.100 with HTTP; Sat, 30 Mar 2013 10:52:25 -0700 (PDT) In-Reply-To: References: <201303300112.r2U1Cr2Z015577@red.freebsd.org> <201303300120.r2U1K0te098396@freefall.freebsd.org> <20130330013337.GA19871@crysys.hu> <20130330082344.GA11534@triton8.kn-bremen.de> Date: Sat, 30 Mar 2013 18:52:25 +0100 Message-ID: Subject: Re: ports/177488: qemu-1.4 From: Oliver Pinter To: Juergen Lock Content-Type: multipart/mixed; boundary=f46d044519d9e91f1904d9280c81 Cc: freebsd-ports-bugs@freebsd.org, current@freebsd.org, bug-followup@freebsd.org, Pinter Oliver ICTF X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 17:52:32 -0000 --f46d044519d9e91f1904d9280c81 Content-Type: text/plain; charset=ISO-8859-1 and one more On 3/30/13, Oliver Pinter wrote: > yes this is git head, sorry > > On 3/30/13, Juergen Lock wrote: >> On Sat, Mar 30, 2013 at 02:36:35AM +0100, Oliver Pinter wrote: >>>[..] >>> >>> disable some unneeded function, and make qemu 1.4 compilable on FreeBSD >>> 9.1 >>> >> >> I think you are building qemu git head as the hexdump function at least >> isn't in 1.4.0? Anyway I have meanwhile updated the qemu-devel port >> to 1.4.0 with some similar patches to yours and (among other things) >> preliminary bsd-user improvements mostly by ssson and cognet, will >> leave the PR open for when I need the hexdump patch for a future >> update. >> >> Thanx, >> Juergen >> > --f46d044519d9e91f1904d9280c81 Content-Type: text/plain; charset=US-ASCII; name="0006-hexdump-fix.diff.txt" Content-Disposition: attachment; filename="0006-hexdump-fix.diff.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: file0 Y29tbWl0IDVkNmExY2NkOGNkOTdhMDcwOGFhYmNmYjUwODhiNDRjNmFlNTM5NWQKQXV0aG9yOiBP bGl2ZXIgUGludGVyIDxvbGl2ZXIucG50ckBnbWFpbC5jb20+CkRhdGU6ICAgU2F0IE1hciAzMCAx ODoyNDowMiAyMDEzICswMTAwCgogICAgb25lIG1vcmUgaGV4ZHVtcCBmaXgKICAgIAogICAgU2ln bmVkLW9mZi1ieTogT2xpdmVyIFBpbnRlciA8b2xpdmVyLnBudHJAZ21haWwuY29tPgoKZGlmZiAt LWdpdCBhL3V0aWwvaW92LmMgYi91dGlsL2lvdi5jCmluZGV4IDlkYWUzMTguLmJhYjM5OTggMTAw NjQ0Ci0tLSBhL3V0aWwvaW92LmMKKysrIGIvdXRpbC9pb3YuYwpAQCAtMjExLDcgKzIxMSw3IEBA IHZvaWQgaW92X2hleGR1bXAoY29uc3Qgc3RydWN0IGlvdmVjICppb3YsIGNvbnN0IHVuc2lnbmVk IGludCBpb3ZfY250LAogICAgIHNpemUgPSBzaXplID4gbGltaXQgPyBsaW1pdCA6IHNpemU7CiAg ICAgYnVmID0gZ19tYWxsb2Moc2l6ZSk7CiAgICAgaW92X3RvX2J1Zihpb3YsIGlvdl9jbnQsIDAs IGJ1Ziwgc2l6ZSk7Ci0gICAgaGV4ZHVtcChidWYsIGZwLCBwcmVmaXgsIHNpemUpOworICAgIHFl bXVfaGV4ZHVtcChidWYsIGZwLCBwcmVmaXgsIHNpemUpOwogICAgIGdfZnJlZShidWYpOwogfQog Cg== --f46d044519d9e91f1904d9280c81-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 30 23:05:48 2013 Return-Path: Delivered-To: freebsd-current@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 0625461F; Sat, 30 Mar 2013 23:05:48 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id ADBD5F43; Sat, 30 Mar 2013 23:05:47 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id va7so1111740obc.20 for ; Sat, 30 Mar 2013 16:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=kmM8Gg6IIy5+R0Hm0jW3/+TqfnLJlnR2qWBTc4JZ3hY=; b=PrVWuP2oOO0hcJw9+/eSlKmtppvfC+AVsM0xDNIVKtOFlz51SZKnSBeS3qu/rfujAe 7hfRIuLeDr9aSqYA+KBmIetTbNlY35q2TGuKu0rrQmiaoI+xLCFsmEt2RVb2MFjY9Tf1 h6RLtZtcb3xut1zNuL23hGEZJxwjuRTk9MOI9zKxy3pRv7iPipTFJXcMDOv69aQc8JPV 5yMIsEHgVP6+c/ofAtoAXGjYqdRTQYJHQV5iDbd1itoJVGJlEajSaT3NwZbDCMwL3b7N WA0wDf3OCSFgzjUQWc25D9XfJrEEvTnkn7oJ+R9ZnT2nAtVI3sF2GjaNpd3MmfZme1y6 fvPA== MIME-Version: 1.0 X-Received: by 10.60.19.161 with SMTP id g1mr2271471oee.101.1364684747228; Sat, 30 Mar 2013 16:05:47 -0700 (PDT) Received: by 10.182.116.196 with HTTP; Sat, 30 Mar 2013 16:05:47 -0700 (PDT) In-Reply-To: <20130330093352.58bb5539@X220.ovitrap.com> References: <20130330020311.GB1687@glenbarber.us> <20130330093352.58bb5539@X220.ovitrap.com> Date: Sat, 30 Mar 2013 19:05:47 -0400 Message-ID: Subject: Re: Question on building from sources. From: Super Bisquit To: Erich Dollansky Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Glen Barber , freebsd-current , FreeBSD PowerPC ML X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 23:05:48 -0000 Okay. I already have 10.0 on the machine from a year ago. What I have come up against is CLANG_IS_CC ="no" when trying to build run(4). What is the current state of clang as cc compiler on ppc32? <-- This needs to be fixed first. Thanks for the replies and sorry for any noise. On Fri, Mar 29, 2013 at 10:33 PM, Erich Dollansky < erichsfreebsdlist@alogt.com> wrote: > Hi, > > On Fri, 29 Mar 2013 22:03:11 -0400 > Glen Barber wrote: > > > On Fri, Mar 29, 2013 at 09:31:12PM -0400, Super Bisquit wrote: > > > I have my QuickSilver and no internet connection. I have a few > > > questions. 1. Do I download the latest for PowerPC(32bit) and then > > > download the sources according to the Makefile. > > > > For ports, yes, you will to do 'make fetch' or 'make fetch-recursive' > > for third-party software you want to install. > > > yes. > > > > 3. Has anyone else done this before? If yes, then what were your > > > results? > > > > > > > It is painful. My suggestion is to identify everything you absolutely > > need, and do from a separate machine with internet access: > > > I do this all the while as I have only random Internet connection. But > I do this only for amd64. It works most of the time. Expect some > returns to the machine with an Internet connection. > > > Note that if anything is missing, build will fail at compile time on > > the internet-less machine. > > This should only be a problem for the ports. The sources can easily be > downloaded in one go. > > Erich > From owner-freebsd-current@FreeBSD.ORG Sat Mar 30 23:09:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0B326793; Sat, 30 Mar 2013 23:09:36 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id B5434F6F; Sat, 30 Mar 2013 23:09:35 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 144CC23F804; Sat, 30 Mar 2013 19:09:34 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.0 onyx.glenbarber.us 144CC23F804 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sat, 30 Mar 2013 19:09:31 -0400 From: Glen Barber To: Super Bisquit Subject: Re: Question on building from sources. Message-ID: <20130330230931.GA1548@glenbarber.us> References: <20130330020311.GB1687@glenbarber.us> <20130330093352.58bb5539@X220.ovitrap.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Erich Dollansky , freebsd-current , FreeBSD PowerPC ML X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 23:09:36 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 30, 2013 at 07:05:47PM -0400, Super Bisquit wrote: > Okay. I already have 10.0 on the machine from a year ago. What I have come > up against is CLANG_IS_CC =3D"no" when trying to build run(4). If you are trying to disable clang, you want to use: WITHOUT_CLANG_IS_CC=3Dyes > What is the current state of clang as cc compiler on ppc32? <-- This needs > to be fixed first. I am not aware of any problems. Glen > Thanks for the replies and sorry for any noise. >=20 >=20 >=20 > On Fri, Mar 29, 2013 at 10:33 PM, Erich Dollansky < > erichsfreebsdlist@alogt.com> wrote: >=20 > > Hi, > > > > On Fri, 29 Mar 2013 22:03:11 -0400 > > Glen Barber wrote: > > > > > On Fri, Mar 29, 2013 at 09:31:12PM -0400, Super Bisquit wrote: > > > > I have my QuickSilver and no internet connection. I have a few > > > > questions. 1. Do I download the latest for PowerPC(32bit) and then > > > > download the sources according to the Makefile. > > > > > > For ports, yes, you will to do 'make fetch' or 'make fetch-recursive' > > > for third-party software you want to install. > > > > > yes. > > > > > > 3. Has anyone else done this before? If yes, then what were your > > > > results? > > > > > > > > > > It is painful. My suggestion is to identify everything you absolutely > > > need, and do from a separate machine with internet access: > > > > > I do this all the while as I have only random Internet connection. But > > I do this only for amd64. It works most of the time. Expect some > > returns to the machine with an Internet connection. > > > > > Note that if anything is missing, build will fail at compile time on > > > the internet-less machine. > > > > This should only be a problem for the ports. The sources can easily be > > downloaded in one go. > > > > Erich > > --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRV3CrAAoJEFJPDDeguUajqwsH/2qaeHSuwMk5EKganrTwRFF3 URXQ5LGiX+R73r2fp/5N+ncJSmFtUglUWcysNTEbLSk8rNNxdvEMqtTfWpbMBsTU ziuD9DurnBp78RKaMWIAzjxhMX6YUTO32I16PR7orauZo1FB/3Lal0EofDIFL9OA gcf3yBLX+aPffpb08xZXcAmM4O5Wfq/7tJbw+J8N+59rPK7TroCf0FrS9CQYVk5l yEPioch2jeW3K179ojBYEy/0s56/+vwuvFVkv+WSxrylZ+T4Lzji6lb1+P0EBceK 7tskR985HBy1MBVadmev81GcvEINQ8aLiFYACReK+ZBR5QZB6rwep6Df+fJeU8M= =5BRg -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 30 23:29:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mandree.no-ip.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id D3A8999C; Sat, 30 Mar 2013 23:29:57 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id 5424B23CEDF; Sun, 31 Mar 2013 00:29:55 +0100 (CET) Message-ID: <5157756F.4040908@FreeBSD.org> Date: Sun, 31 Mar 2013 00:29:51 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> In-Reply-To: <51536306.5030907@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig338DC6674EB2008BF0825764" Cc: Alexander Motin , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 23:29:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig338DC6674EB2008BF0825764 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 27.03.2013 22:22, schrieb Alexander Motin: > Hi. >=20 > Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA > stack, using only some controller drivers of old ata(4) by having > `options ATA_CAM` enabled in all kernels by default. I have a wish to > drop non-ATA_CAM ata(4) code, unused since that time from the head > branch to allow further ATA code cleanup. >=20 > Does any one here still uses legacy ATA stack (kernel explicitly built > without `options ATA_CAM`) for some reason, for example as workaround > for some regression? Does anybody have good ideas why we should not dro= p > it now? Alexander, The regression in http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/15739= 7 where the SATA NCQ slots stall for some Samsung drives in the new stack, and consequently hang the computer for prolonged episodes where it is in the NCQ error handling, disallows removal of the old driver. (Last checked with 9.1-RELEASE at current patchlevel.) Chances are that limiting the open queue slots to 31 might help, but that is hearsay from what Linux would be doing. Unless we get a fix, if you want to drop the old driver, you'll need to add features so that 1. the new driver to lets users (down-)configure the max. number of tagged openings 2. the new driver allows disabling NCQ altogether for individual drives 3. list the relevant Samsung drives in some quirks data base so that we avoid the stalls while permitting users to "open it up to 32 NCQ slots". So unless these are all addressed, I'd veto removal of the old ATA driver - sorry! Best regards Matthias --------------enig338DC6674EB2008BF0825764 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFXdW8ACgkQvmGDOQUufZVJ2ACg0eUnW4Xe5nVJo3zLTaYjUARG KcgAniDIIJ8oveV3YB5GV7sNTYc1+ar8 =2f7y -----END PGP SIGNATURE----- --------------enig338DC6674EB2008BF0825764--