From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 19 00:53:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB9C7A3F for ; Sun, 19 Oct 2014 00:53:39 +0000 (UTC) Received: from know-smtprelay-omc-1.server.virginmedia.net (know-smtprelay-omc-1.server.virginmedia.net [80.0.253.65]) by mx1.freebsd.org (Postfix) with ESMTP id 46A58FBF for ; Sun, 19 Oct 2014 00:53:38 +0000 (UTC) Received: from [192.168.1.100] ([86.20.122.200]) by know-smtprelay-1-imp with bizsmtp id 4osU1p00q4KXVwe01osUum; Sun, 19 Oct 2014 01:52:28 +0100 X-Originating-IP: [86.20.122.200] X-Spam: 0 X-Authority: v=2.1 cv=RcseCjdv c=1 sm=1 tr=0 a=WByauD8lJrWvBFCNrxRoEQ==:117 a=WByauD8lJrWvBFCNrxRoEQ==:17 a=TlgFaoZnv2EA:10 a=uObrxnre4hsA:10 a=8nJEP1OIZ-IA:10 a=NLZqzBF-AAAA:8 a=JjLgQdwQY_S_jpjqNbAA:9 a=bwXatPVJ6H-v4hfr:21 a=fReGTqKZwTuZqI_N:21 a=wPNLvfGTeEIA:10 a=XdyKOaxJwVsA:10 Message-ID: <54430B41.3010301@NTLWorld.com> Date: Sun, 19 Oct 2014 01:52:17 +0100 From: Jonathan de Boyne Pollard User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: FreeBSD Hackers Subject: nosh version 1.9 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 19 Oct 2014 01:19:28 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 00:53:39 -0000 nosh version 1.9 is out. If you've not heard of it, here's the blurb: * http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html If you also read the worked example, make sure that you read all of the way to the bottom. (-: If you want to read more, there's a whole Guide in the package, and lots of manual pages. There's now a command for converting FreeBSD /etc/rc.conf{,.local} preset information (the *_enable variables) to service bundle preset information. For kicks, I've also added a small shim for the OpenBSD "rcctl" command that they're busy inventing. It's worth noting that OpenBSD 5.6 now specifies that /etc/rc.conf{,.local} doesn't have shell expansions and isn't necessarily sourced by a shell, which is change that I welcome with open arms. I will be looking at conversion of OpenBSD *_flags variables; but the big thing that remains in this area is a utility that pushes all of the other variables, apart from *_enable, into envdirs in the appropriate service bundles, which is going to be a tedious one-by-one slog because sometimes the variable names don't match the service names, as you no doubt know. I set myself a task of converting to service bundles all but two of the 157 non-target scripts that I found in a stock FreeBSD /etc/rc.d/ . I've reached 85. A lot of the remaining scripts are complex, often one-shot, shell scripts onto the side of which the rc.d start/stop system has been bolted, with varying degrees of success. If you are interested in helping, one of the things that would help greatly is factoring out the meat of some of these into helper commands of some kind, reducing the lopsided hulks to something more like (say) /etc/rc.d/rpcbind . (I can supply a list.) As reciprocal payment in advance, I'm letting you know that /etc/rc.d/msgs is missing all of the rc.d mechanism, and so does the same thing on every start/stop/restart/whatever command verb. Although I suggest that factoring out things in this way is a gain for the rc.d system, too, and of mutual benefit. From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 19 01:51:27 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25715F5E for ; Sun, 19 Oct 2014 01:51:27 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 137766AB for ; Sun, 19 Oct 2014 01:51:27 +0000 (UTC) Received: from AlfredMacbookAir.local (162-222-103-181.webpass.net [162.222.103.181]) by elvis.mu.org (Postfix) with ESMTPSA id 40C76341F830; Sat, 18 Oct 2014 18:51:26 -0700 (PDT) Message-ID: <5443191E.5050208@mu.org> Date: Sat, 18 Oct 2014 18:51:26 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, Jonathan de Boyne Pollard Subject: Re: nosh version 1.9 References: <54430B41.3010301@NTLWorld.com> In-Reply-To: <54430B41.3010301@NTLWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 01:51:27 -0000 Very cool. Wondering about the idea of /etc/rc.conf *not* being a shell script... this is sort of bad imo as I can't see any other way to provide the settings dynamically for the startup scripts at a glance. I'll give you an example... FreeNAS (and by extension the appliance we are building at Norse) has /etc/rc.conf.local as a shell script that pulls data from an sqlite database, this allows us to set various services on/off based on the contents of that sqlite database file. This in turn allows us to leverage most of the existing /etc/rc.d and by extension the /usr/local/etc/rc.d files provided by ports. I'm wondering how one could still do that if /etc/rc.conf and /etc/rc.conf.local were no longer scripts? -Alfred On 10/18/14, 5:52 PM, Jonathan de Boyne Pollard wrote: > nosh version 1.9 is out. If you've not heard of it, here's the blurb: > > * > http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html > > If you also read the worked example, make sure that you read all of > the way to the bottom. (-: If you want to read more, there's a whole > Guide in the package, and lots of manual pages. > > There's now a command for converting FreeBSD /etc/rc.conf{,.local} > preset information (the *_enable variables) to service bundle preset > information. For kicks, I've also added a small shim for the OpenBSD > "rcctl" command that they're busy inventing. It's worth noting that > OpenBSD 5.6 now specifies that /etc/rc.conf{,.local} doesn't have > shell expansions and isn't necessarily sourced by a shell, which is > change that I welcome with open arms. I will be looking at conversion > of OpenBSD *_flags variables; but the big thing that remains in this > area is a utility that pushes all of the other variables, apart from > *_enable, into envdirs in the appropriate service bundles, which is > going to be a tedious one-by-one slog because sometimes the variable > names don't match the service names, as you no doubt know. > > I set myself a task of converting to service bundles all but two of > the 157 non-target scripts that I found in a stock FreeBSD /etc/rc.d/ > . I've reached 85. A lot of the remaining scripts are complex, often > one-shot, shell scripts onto the side of which the rc.d start/stop > system has been bolted, with varying degrees of success. If you are > interested in helping, one of the things that would help greatly is > factoring out the meat of some of these into helper commands of some > kind, reducing the lopsided hulks to something more like (say) > /etc/rc.d/rpcbind . (I can supply a list.) As reciprocal payment in > advance, I'm letting you know that /etc/rc.d/msgs is missing all of > the rc.d mechanism, and so does the same thing on every > start/stop/restart/whatever command verb. Although I suggest that > factoring out things in this way is a gain for the rc.d system, too, > and of mutual benefit. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 19 02:08:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07E47196 for ; Sun, 19 Oct 2014 02:08:39 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 861137D6 for ; Sun, 19 Oct 2014 02:08:38 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id l18so3203590wgh.5 for ; Sat, 18 Oct 2014 19:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=u6Jv/5hNX8mYu8aTOCrhoEgLQ3hVBVK9JfZ2r4r5v40=; b=mJsd9JFmRaMxcfU+7QGdrapraKxW8U1TtBAyyp3tdnAb7i8HA2cvquOxJCKIV1Zur+ 5lgHoTsaekGMUnSkTZvGWLdLPGwiSR0/DI3mA/1BBQQXxBnUDArPv0OJSpwBRjouyVV7 QB1Rem/Okz3aCCvwZaaHwXt5eeo1J2EyGk59F2gwV/lemcYOJUsmUEzHM2FfUUmN3duO nRahWm9Hzftvm9FoP4Ow1FwPj6SZyliASaM3ritMEPkvBojyOR+UtiI937qocNt144ZM SxypPLTAwmJnVY0aFJa5Qz4LeyiOKYiS+UfnoxoYaOPuImFrSH5hEFLcSEu2mwgMCeHW /LYg== MIME-Version: 1.0 X-Received: by 10.194.192.161 with SMTP id hh1mr22567116wjc.72.1413684516629; Sat, 18 Oct 2014 19:08:36 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Sat, 18 Oct 2014 19:08:36 -0700 (PDT) In-Reply-To: References: Date: Sat, 18 Oct 2014 19:08:36 -0700 X-Google-Sender-Auth: eyQvoDrA6vviWT-L5OxDZpUHViQ Message-ID: Subject: Re: help with backlight control and memory From: Adrian Chadd To: Wojciech Puchar Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 02:08:39 -0000 Ok, does the sysctl work? You have to have drm2 and i915kms loaded before it'll all plumb together correctly. -a On 18 October 2014 14:03, Wojciech Puchar wrote: > tried. jsut after kernel is loaded backlight control keys stops working. > tried loading every acpi_* kernel module that is available, with no results > > > On Thu, 16 Oct 2014, Adrian Chadd wrote: > >> Hi! >> >> Please try the latest FreeBSD-11 snapshot and see if it still works >> once you've started Xorg. >> >> >> -a >> >> >> On 16 October 2014 05:19, Wojciech Puchar wrote: >>> >>> bought new laptop. it's lenovo B590 >>> >>> most things works fine. but brightness control keys doesn't work after >>> FreeBSD is loaded. they work before it. >>> >>> i don't ask for a solution but any point to start. What should i check? >>> >>> is it ACPI tables problem (kernel shows some errors). >>> >>> Other question - can amount of memory dedicated to GFX card be changed? >>> There is no option in BIOS setup to do this. and i have lots of memory >>> wasted as you may see below. >>> >>> >>> >>> Copyright (c) 1992-2014 The FreeBSD Project. >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >>> The Regents of the University of California. All rights reserved. >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>> FreeBSD 10.1-BETA1 #4: Wed Oct 15 23:56:56 CEST 2014 >>> root@laptop:/usr/src/sys/amd64/compile/laptop amd64 >>> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 >>> CPU: Intel(R) Celeron(R) CPU 1005M @ 1.90GHz (1895.73-MHz K8-class CPU) >>> Origin = "GenuineIntel" Id = 0x306a9 Family = 0x6 Model = 0x3a >>> Stepping = 9 >>> >>> >>> Features=0xbfebfbff >>> >>> >>> Features2=0xdbae3bf >>> AMD Features=0x28100800 >>> AMD Features2=0x1 >>> Structured Extended Features=0x281 >>> VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID >>> TSC: P-state invariant, performance statistics >>> real memory = 2147483648 (2048 MB) >>> avail memory = 1585037312 (1511 MB) >>> Event timer "LAPIC" quality 600 >>> ACPI APIC Table: >>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >>> FreeBSD/SMP: 1 package(s) x 2 core(s) >>> cpu0 (BSP): APIC ID: 0 >>> cpu1 (AP): APIC ID: 2 >>> ioapic0 irqs 0-23 on motherboard >>> random: initialized >>> iscsi: version 2.3.1 >>> kbd1 at kbdmux0 >>> cryptosoft0: on motherboard >>> acpi0: on motherboard >>> ACPI Error: No handler for Region [ECOR] (0xfffff80001710400) >>> [EmbeddedControl] (20130823/evregion-178) >>> ACPI Error: Region EmbeddedControl (ID=3) has no handler >>> (20130823/exfldio-320) >>> ACPI Error: Method parse/execution failed [\134_SB_.PCI0.LPCB.H_EC._REG] >>> (Node 0xfffff8000171e200), AE_NOT_EXIST (20130823/psparse-553) >>> acpi0: Power Button (fixed) >>> cpu0: on acpi0 >>> cpu1: on acpi0 >>> hpet0: iomem 0xfed00000-0xfed003ff on acpi0 >>> Timecounter "HPET" frequency 14318180 Hz quality 950 >>> Event timer "HPET" frequency 14318180 Hz quality 550 >>> Event timer "HPET1" frequency 14318180 Hz quality 440 >>> Event timer "HPET2" frequency 14318180 Hz quality 440 >>> Event timer "HPET3" frequency 14318180 Hz quality 440 >>> Event timer "HPET4" frequency 14318180 Hz quality 440 >>> Event timer "HPET5" frequency 14318180 Hz quality 440 >>> Event timer "HPET6" frequency 14318180 Hz quality 440 >>> atrtc0: port 0x70-0x77 irq 8 on acpi0 >>> atrtc0: Warning: Couldn't map I/O. >>> Event timer "RTC" frequency 32768 Hz quality 0 >>> attimer0: port 0x40-0x43,0x50-0x53 irq 0 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 0x408-0x40b on acpi0 >>> acpi_ec0: port 0x62,0x66 on acpi0 >>> pcib0: port 0xcf8-0xcff on acpi0 >>> pci0: on pcib0 >>> vgapci0: port 0x3000-0x303f mem >>> 0x90000000-0x903fffff,0x80000000-0x8fffffff irq 16 at device 2.0 on pci0 >>> agp0: on vgapci0 >>> agp0: aperture size is 256M, detected 32764k stolen memory >>> vgapci0: Boot video device >>> xhci0: mem 0x90600000-0x9060ffff >>> irq 21 at device 20.0 on pci0 >>> xhci0: 32 byte context size. >>> xhci0: Port routing mask set to 0xffffffff >>> usbus0 on xhci0 >>> pci0: at device 22.0 (no driver attached) >>> ehci0: mem 0x9061a000-0x9061a3ff >>> irq 16 at device 26.0 on pci0 >>> usbus1: EHCI version 1.0 >>> usbus1 on ehci0 >>> hdac0: mem 0x90610000-0x90613fff irq >>> 22 >>> at device 27.0 on pci0 >>> pcib1: irq 16 at device 28.0 on pci0 >>> pci1: on pcib1 >>> pcib2: irq 17 at device 28.1 on pci0 >>> pci2: on pcib2 >>> pci2: at device 0.0 (no driver attached) >>> pcib3: irq 19 at device 28.3 on pci0 >>> pci3: on pcib3 >>> re0: port >>> 0x2000-0x20ff mem 0x90404000-0x90404fff,0x90400000-0x90403fff irq 19 at >>> device 0.0 on pci3 >>> re0: Using 1 MSI-X message >>> re0: ASPM disabled >>> re0: Chip rev. 0x2c800000 >>> re0: MAC rev. 0x00100000 >>> miibus0: on re0 >>> ukphy0: PHY 1 on miibus0 >>> ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >>> 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow >>> re0: Ethernet address: 54:ee:75:13:f2:6b >>> ehci1: mem 0x90619000-0x906193ff >>> irq 23 at device 29.0 on pci0 >>> usbus2: EHCI version 1.0 >>> usbus2 on ehci1 >>> isab0: at device 31.0 on pci0 >>> isa0: on isab0 >>> ahci0: port >>> 0x3088-0x308f,0x3094-0x3097,0x3080-0x3087,0x3090-0x3093,0x3060-0x307f mem >>> 0x90618000-0x906187ff irq 19 at device 31.2 on pci0 >>> ahci0: AHCI v1.30 with 4 6Gbps ports, Port Multiplier not supported >>> ahcich0: at channel 0 on ahci0 >>> ahcich4: at channel 4 on ahci0 >>> ahciem0: on ahci0 >>> acpi_acad0: on acpi0 >>> acpi_lid0: on acpi0 >>> acpi_button0: on acpi0 >>> acpi_tz0: on acpi0 >>> acpi_tz1: on acpi0 >>> atkbdc0: port 0x60,0x64 irq 1 on acpi0 >>> atkbd0: irq 1 on atkbdc0 >>> kbd0 at atkbd0 >>> atkbd0: [GIANT-LOCKED] >>> psm0: irq 12 on atkbdc0 >>> psm0: [GIANT-LOCKED] >>> psm0: model Generic PS/2 mouse, device ID 0 >>> battery0: on acpi0 >>> acpi_ibm0: on acpi0 >>> orm0: at iomem 0xc0000-0xcefff 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 >>> est0: on cpu0 >>> p4tcc0: on cpu0 >>> est1: on cpu1 >>> p4tcc1: on cpu1 >>> fuse-freebsd: version 0.4.4, FUSE ABI 7.8 >>> Timecounters tick every 1.000 msec >>> ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to >>> accept, >>> logging disabled >>> DUMMYNET 0 with IPv6 initialized (100409) >>> load_dn_sched dn_sched RR loaded >>> load_dn_sched dn_sched WF2Q+ loaded >>> load_dn_sched dn_sched FIFO loaded >>> load_dn_sched dn_sched PRIO loaded >>> load_dn_sched dn_sched QFQ loaded >>> hdacc0: at cad 0 on hdac0 >>> hdaa0: at nid 1 on hdacc0 >>> pcm0: at nid 20,21 and 24,25 on >>> hdaa0 >>> hdacc1: at cad 3 on hdac0 >>> hdaa1: at nid 1 on hdacc1 >>> pcm1: at nid 5 on hdaa1 >>> random: unblocking device. >>> usbus0: 5.0Gbps Super Speed USB v3.0 >>> usbus1: 480Mbps High Speed USB v2.0 >>> usbus2: 480Mbps High Speed USB v2.0 >>> ACPI Error: No handler for Region [ECRM] (0xfffff800017dd180) >>> [EmbeddedControl] (20130823/evregion-178) >>> ACPI Error: Region EmbeddedControl (ID=3) has no handler >>> (20130823/exfldio-320) >>> ACPI Error: Method parse/execution failed [\134_TZ_.MDEC] (Node >>> 0xfffff80001725b40), AE_NOT_EXIST (20130823/psparse-553) >>> ACPI Error: Method parse/execution failed [\134_TZ_.TZS0._SCP] (Node >>> 0xfffff80001725a40), AE_NOT_EXIST (20130823/psparse-553) >>> ugen2.1: at usbus2 >>> uhub0: on usbus2 >>> ugen1.1: at usbus1 >>> ugen0.1: <0x8086> at usbus0 >>> uhub1: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 >>> uhub2: on usbus1 >>> ses0 at ahciem0 bus 0 scbus2 target 0 lun 0 >>> ses0: SEMB S-E-S 2.00 device >>> ses0: SEMB SES Device >>> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >>> ada0: ATA-8 SATA 2.x device >>> ada0: Serial Number WD-WXL1EB3KUNR5 >>> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >>> ada0: Command Queueing enabled >>> cd0 at ahcich4 bus 0 scbus1 target 0 lun 0 >>> cd0: Removable CD-ROM SCSI-0 device cd0: >>> Serial >>> Number KW9E4571958 >>> cd0: 150.000MB/s transfers (SATA 1.x, UDMA2, ATAPI 12bytes, PIO >>> 8192bytes) >>> cd0: Attempt to query device size failed: NOT READY, Medium not present - >>> tray closed >>> ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) >>> ada0: quirks=0x1<4K> >>> ada0: Previously was known as ad0 >>> Enter passphrase for ada0d: SMP: AP CPU #1 Launched! >>> hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 >>> IAP/8/48/0x3ff >>> IAF/3/48/0x67 >>> Timecounter "TSC" frequency 1895731156 Hz quality 1000 >>> uhub1: 8 ports with 8 removable, self powered >>> uhub0: 3 ports with 3 removable, self powered >>> uhub2: 3 ports with 3 removable, self powered >>> ugen2.2: at usbus2 >>> uhub3: >>> on >>> usbus2 >>> ugen1.2: at usbus1 >>> uhub4: >>> on >>> usbus1 >>> uhub3: 4 ports with 4 removable, self powered >>> uhub4: 4 ports with 4 removable, self powered >>> ugen1.3: at usbus1 >>> ugen1.4: at usbus1 >>> umass0: >> 4> >>> on usbus1 >>> da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 >>> da0: Removable Direct Access SCSI-0 device >>> da0: >>> Serial Number 058F63666435 >>> da0: 40.000MB/s transfers >>> da0: Attempt to query device size failed: NOT READY, Medium not present >>> da0: quirks=0x2 >>> ugen1.5: at usbus1 >>> GEOM_ELI: Device ada0d.eli created. >>> GEOM_ELI: Encryption: AES-CBC 128 >>> GEOM_ELI: Crypto: software >>> Trying to mount root from ufs:ada0d.eli []... >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to >>> "freebsd-hackers-unsubscribe@freebsd.org" >> >> >> > From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 19 02:16:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 082132DE for ; Sun, 19 Oct 2014 02:16:29 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 966DD897 for ; Sun, 19 Oct 2014 02:16:28 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id em10so3794865wid.13 for ; Sat, 18 Oct 2014 19:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VSrU9HPpDgGnO5npPV9QezwiWE5Kn5xzs9WgWbJBA3Y=; b=W0DBSZoXNTnW7/SwapUjQ6x3NX7DS8a/417/X+Nb8ePyenTfEQGxRV7fnXPO5TIwRK 0CxS1N0Bz4deIr4+2GafTggy5jerQQtXxPloPr7S8Xok7vMrt/bIbizYeGbWGtYI7JQW t2HO4FamZ3Vsv7QIk8DR9WVRWnOWCKZWnVS2pzWZV4Q6/szF9znp2IvEEgz1vUVR6nXP 8O9upspakxrTri51PgKtTGyaKU3LoVGMX9LFsjSfmXt5TwkOVrmhncoZZjUzhYC/+klq IOIxgr9cGbL/czGmK7GTZG8Tw07PktsG+pqaYuMEMBX8BV9h9u2h+ARu7jk0MnCAQ4YI qLnQ== MIME-Version: 1.0 X-Received: by 10.180.11.200 with SMTP id s8mr4156873wib.20.1413684986794; Sat, 18 Oct 2014 19:16:26 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Sat, 18 Oct 2014 19:16:26 -0700 (PDT) In-Reply-To: <5443191E.5050208@mu.org> References: <54430B41.3010301@NTLWorld.com> <5443191E.5050208@mu.org> Date: Sat, 18 Oct 2014 19:16:26 -0700 X-Google-Sender-Auth: o_Y06TP0MC0Dxe5CW9rniyHhrwU Message-ID: Subject: Re: nosh version 1.9 From: Adrian Chadd To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Jonathan de Boyne Pollard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 02:16:29 -0000 On 18 October 2014 18:51, Alfred Perlstein wrote: > Very cool. > > Wondering about the idea of /etc/rc.conf *not* being a shell script... this > is sort of bad imo as I can't see any other way to provide the settings > dynamically for the startup scripts at a glance. > > I'll give you an example... FreeNAS (and by extension the appliance we are > building at Norse) has /etc/rc.conf.local as a shell script that pulls data > from an sqlite database, this allows us to set various services on/off based > on the contents of that sqlite database file. > > This in turn allows us to leverage most of the existing /etc/rc.d and by > extension the /usr/local/etc/rc.d files provided by ports. > > I'm wondering how one could still do that if /etc/rc.conf and > /etc/rc.conf.local were no longer scripts? The same way /etc/rc.conf and /etc/rc.conf.local is pulled in - via the little snippet of stuff at the end of /etc/defaults/rc.conf , and this bit of config in that file: local_startup="/usr/local/etc/rc.d" # startup script dirs. script_name_sep=" " # Change if your startup scripts' names contain spaces rc_conf_files="/etc/rc.conf /etc/rc.conf.local" So, we just need some method of pulling in environment variables in whatever order we need from whatever place we need. (God, why do I know this stuff? Then I remembered - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=17595 . God damnit.) The tricky bit is trying to make it so we don't call sqlite like a thousand times to pull out all of the environment variables for each invocation of an rc script. -adrian From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 19 02:38:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CECA04CB; Sun, 19 Oct 2014 02:38:20 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id BB0B2A01; Sun, 19 Oct 2014 02:38:20 +0000 (UTC) Received: from [100.77.89.211] (254.sub-70-211-79.myvzw.com [70.211.79.254]) by elvis.mu.org (Postfix) with ESMTPSA id 88441341F83D; Sat, 18 Oct 2014 19:38:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: nosh version 1.9 From: Alfred Perlstein X-Mailer: iPhone Mail (12A405) In-Reply-To: Date: Sat, 18 Oct 2014 19:38:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <34F30D28-DE9B-444F-885E-F438FEEA46EC@mu.org> References: <54430B41.3010301@NTLWorld.com> <5443191E.5050208@mu.org> To: Adrian Chadd Cc: "freebsd-hackers@freebsd.org" , Jonathan de Boyne Pollard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 02:38:20 -0000 Adding lazy variable extension to sh should be relatively easy.=20 Sent from my iPhone > On Oct 18, 2014, at 7:16 PM, Adrian Chadd wrote: >=20 >> On 18 October 2014 18:51, Alfred Perlstein wrote: >> Very cool. >>=20 >> Wondering about the idea of /etc/rc.conf *not* being a shell script... th= is >> is sort of bad imo as I can't see any other way to provide the settings >> dynamically for the startup scripts at a glance. >>=20 >> I'll give you an example... FreeNAS (and by extension the appliance we ar= e >> building at Norse) has /etc/rc.conf.local as a shell script that pulls da= ta >> from an sqlite database, this allows us to set various services on/off ba= sed >> on the contents of that sqlite database file. >>=20 >> This in turn allows us to leverage most of the existing /etc/rc.d and by >> extension the /usr/local/etc/rc.d files provided by ports. >>=20 >> I'm wondering how one could still do that if /etc/rc.conf and >> /etc/rc.conf.local were no longer scripts? >=20 > The same way /etc/rc.conf and /etc/rc.conf.local is pulled in - via > the little snippet of stuff at the end of /etc/defaults/rc.conf , and > this bit of config in that file: >=20 > local_startup=3D"/usr/local/etc/rc.d" # startup script dirs. > script_name_sep=3D" " # Change if your startup scripts' names contain s= paces > rc_conf_files=3D"/etc/rc.conf /etc/rc.conf.local" >=20 > So, we just need some method of pulling in environment variables in > whatever order we need from whatever place we need. >=20 > (God, why do I know this stuff? Then I remembered - > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D17595 . God damnit.) >=20 > The tricky bit is trying to make it so we don't call sqlite like a > thousand times to pull out all of the environment variables for each > invocation of an rc script. >=20 >=20 > -adrian > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= >=20 From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 19 02:59:38 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96D1B62A; Sun, 19 Oct 2014 02:59:38 +0000 (UTC) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E41CEB74; Sun, 19 Oct 2014 02:59:37 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id q1so2386335lam.32 for ; Sat, 18 Oct 2014 19:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xtpshZwoePCAENk0cKiol7IvmDboQQmMwqC8lSTGqm4=; b=G3YtB0dQ24i2xE740hAU92uNzFf+IpXyhcXcuZbO54CL4Z3V6anAmCQwi++esKrrpW LxWicVMzsRfim/UnJWbb2YYBk2tWKf7RoppTxdmjWm5AWEj5jhxJJHRgiEV3s4ZCIuEo HaWnUdhMQtND+03RK9dihEwjydWruYzY174poCkmtxXWMqCih0+KfJ9EQk7Fdk6yBJaO ex5BY/der0EstreajFOHOK9UhEOU+d+ROqTWyPLqzIlcJgeGAUs/WrwpwXWZeMmBnvir uaItfqW/TeN0Uvxefq978guHMchyRq3/d3qlGhapBzTIlF6x9KJY98aynJiwzFL4vd1l d7YA== MIME-Version: 1.0 X-Received: by 10.153.4.7 with SMTP id ca7mr18338247lad.31.1413687575758; Sat, 18 Oct 2014 19:59:35 -0700 (PDT) Received: by 10.152.22.195 with HTTP; Sat, 18 Oct 2014 19:59:35 -0700 (PDT) In-Reply-To: <34F30D28-DE9B-444F-885E-F438FEEA46EC@mu.org> References: <54430B41.3010301@NTLWorld.com> <5443191E.5050208@mu.org> <34F30D28-DE9B-444F-885E-F438FEEA46EC@mu.org> Date: Sun, 19 Oct 2014 13:59:35 +1100 Message-ID: Subject: Re: nosh version 1.9 From: Outback Dingo To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , Jonathan de Boyne Pollard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 02:59:38 -0000 On Sun, Oct 19, 2014 at 1:38 PM, Alfred Perlstein wrote: > Adding lazy variable extension to sh should be relatively easy. > > Sent from my iPhone > > > On Oct 18, 2014, at 7:16 PM, Adrian Chadd wrote: > > > >> On 18 October 2014 18:51, Alfred Perlstein wrote: > >> Very cool. > >> > >> Wondering about the idea of /etc/rc.conf *not* being a shell script... > this > >> is sort of bad imo as I can't see any other way to provide the settings > >> dynamically for the startup scripts at a glance. > >> > >> I'll give you an example... FreeNAS (and by extension the appliance we > are > >> building at Norse) has /etc/rc.conf.local as a shell script that pulls > data > >> from an sqlite database, this allows us to set various services on/off > based > >> on the contents of that sqlite database file. > >> > >> This in turn allows us to leverage most of the existing /etc/rc.d and by > >> extension the /usr/local/etc/rc.d files provided by ports. > >> > >> I'm wondering how one could still do that if /etc/rc.conf and > >> /etc/rc.conf.local were no longer scripts? > > > > The same way /etc/rc.conf and /etc/rc.conf.local is pulled in - via > > the little snippet of stuff at the end of /etc/defaults/rc.conf , and > > this bit of config in that file: > > > > local_startup="/usr/local/etc/rc.d" # startup script dirs. > > script_name_sep=" " # Change if your startup scripts' names contain > spaces > > rc_conf_files="/etc/rc.conf /etc/rc.conf.local" > > > > So, we just need some method of pulling in environment variables in > > whatever order we need from whatever place we need. > > > > (God, why do I know this stuff? Then I remembered - > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=17595 . God damnit.) > > > > The tricky bit is trying to make it so we don't call sqlite like a > > thousand times to pull out all of the environment variables for each > > invocation of an rc script. > > > > > > -adrian > IMHO I think we'd be better off with launchd... but this does show intelligence.... > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 19 05:53:35 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B5C1961 for ; Sun, 19 Oct 2014 05:53:35 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F20EEBFC for ; Sun, 19 Oct 2014 05:53:34 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 3CC4E1534E7 for ; Sun, 19 Oct 2014 07:53:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Xyv4z0w2pf9; Sun, 19 Oct 2014 07:53:14 +0200 (CEST) Received: from [192.168.10.9] (vaio [192.168.10.9]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id DE4B6153AA6 for ; Sun, 19 Oct 2014 00:39:32 +0200 (CEST) Message-ID: <5442EC24.5090101@digiware.nl> Date: Sun, 19 Oct 2014 00:39:32 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: hackers@freebsd.org Subject: tip has -n and cu not Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 05:53:35 -0000 Hi, is there any particular reason why tip has the -n flag to disable escape handeling, but cu does not? Reason for the question: Looking for a way to get external access to bhyve consoles connected to /dev/nmdmXXXA. I'd like to use cu as "shell" to make it possible to give user access to a /dev/nmdmXXXB port thru ssh. And this is the only thing that user is able to do.... And without the -n flag, cu allows all kinds of nasty escape tricks. --WjW From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 19 10:28:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2DD2AD6; Sun, 19 Oct 2014 10:28:53 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8DE695F5; Sun, 19 Oct 2014 10:28:53 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id B87BD6A600F; Sun, 19 Oct 2014 12:28:49 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id s9JASnv7087984; Sun, 19 Oct 2014 12:28:49 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id s9JASm9O087950; Sun, 19 Oct 2014 12:28:48 +0200 (CEST) (envelope-from lars) Date: Sun, 19 Oct 2014 12:28:48 +0200 From: Lars Engels To: Wojciech Puchar Subject: Re: help with backlight control and memory Message-ID: <20141019102848.GR72082@e-new.0x20.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uLzYCuFow5JXEQYy" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p16 User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Sun, 19 Oct 2014 11:39:39 +0000 Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 10:28:53 -0000 --uLzYCuFow5JXEQYy Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 18, 2014 at 11:03:38PM +0200, Wojciech Puchar wrote: > tried. jsut after kernel is loaded backlight control keys stops working. > tried loading every acpi_* kernel module that is available, with no=20 > results On my X230 running HEAD brightness keys only work when acpi_video.ko is _not_ loaded. When it is loaded, I can control brightness with sysctl, though. --uLzYCuFow5JXEQYy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJUQ5JgXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tugMIAIvr7HTlIgaL+S/dxlQppzJY Q9sa5v8wAUcE4FJJtbgJDOkgfOzfIaob/5LGersPOD/uRYjYk3BKH3InGAs4AGzL 6P+no8tR1LaukGVVKBanOlj33Zc/TczUQiJPLB4vy1gnVxHVv2/gId2JScQyf2or WitPrbdolb4j/UGon0Y6wsSliY7nvdpCWvXkSTPJqX6Har8zegqDbr7PIKZfAEcV ed/B9GrJR1sbiXObtDpvyP1bsuLZJOBBfKbG/N8lRNhyfoIXvFyag4azDLhHFtlC 24+fdXc/Z+1OsuCKrhPp48DY8FlGPBGu9toAiVvWXVjejbLysNN3/7YHDmQNZos= =pWmT -----END PGP SIGNATURE----- --uLzYCuFow5JXEQYy-- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 19 13:00:18 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0FAD39C for ; Sun, 19 Oct 2014 13:00:18 +0000 (UTC) Received: from platinum.linux.pl (platinum.edu.pl [81.161.192.4]) by mx1.freebsd.org (Postfix) with ESMTP id 711BA35E for ; Sun, 19 Oct 2014 13:00:17 +0000 (UTC) Received: by platinum.linux.pl (Postfix, from userid 87) id 1C48D45218C; Sun, 19 Oct 2014 14:50:13 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on platinum.linux.pl X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=ALL_TRUSTED,AWL, TO_NO_BRKTS_PCNT autolearn=disabled version=3.4.0 Received: from [10.255.0.2] (unknown [83.151.38.73]) by platinum.linux.pl (Postfix) with ESMTPA id 916BA4520C0 for ; Sun, 19 Oct 2014 14:50:12 +0200 (CEST) Message-ID: <5443B2D4.3020407@platinum.linux.pl> Date: Sun, 19 Oct 2014 14:47:16 +0200 From: Adam Nowacki User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: panic in ivy_rng_store() when compiled with -O0 References: <54384ABD.5080806@FreeBSD.org> <2533199.DHZybpy49d@ralph.baldwin.cx> <54415E13.4000203@delphij.net> <7A5C3D84-1B1F-4BA3-818D-37231BF424FE@FreeBSD.org> In-Reply-To: <7A5C3D84-1B1F-4BA3-818D-37231BF424FE@FreeBSD.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 13:00:18 -0000 On 2014-10-17 20:33, Dimitry Andric wrote: > On 17 Oct 2014, at 20:21, Xin Li wrote: >> On 10/17/14 08:53, John Baldwin wrote: >>> On Friday, October 10, 2014 02:08:13 PM Navdeep Parhar wrote: > ... >> movq %rdi,(%rdi) is obviously wrong (%rdi holds the result from >> rdrand), which I believed to be a compiler bug in register allocation. >> >> Navdeep have committed a change to mark 'tmp' input+output, which does >> fix the output but I'm not 100% sure if that's right, as 'tmp' is not >> considered an input of the inline assembler block, and this may break >> compile on other compilers, but for now it's better than previous >> situation. >> >> Speaking for the compiler issue, Dimitry have reported this upstream at: >> >> http://llvm.org/bugs/show_bug.cgi?id=21273 >> >> There is a suggestion in the reply, that change 'tmp' to early clobber >> would workaround the issue, like: >> >> Index: ivy.c >> =================================================================== >> - --- ivy.c (revision 273195) >> +++ ivy.c (working copy) >> @@ -79,7 +79,7 @@ >> "2:\n\t" >> "mov %2,%1\n\t" /* *buf = tmp */ >> "3:" >> - - : "+q" (retry), "=m" (*buf), "+q" (tmp) : : "cc"); >> + : "+q" (retry), "=m" (*buf), "=&q" (tmp) : : "cc"); > > Yes, this generates the correct code for all cases I tried, e.g. with > gcc 4.2 from base, gcc 4.7 through 5.0 from ports, clang 3.4, clang 3.5 > and clang trunk, all at -O0 through -O3, and -Os. > > So at the moment this fix is the best option, I think. GCC documentation explains what happens: "The same problem can occur if one output parameter (a) allows a register constraint and another output parameter (b) allows a memory constraint. The code generated by GCC to access the memory address in b can contain registers which might be shared by a, and GCC considers those registers to be inputs to the asm. As above, GCC assumes that such input registers are consumed before any outputs are written. This assumption may result in incorrect behavior if the asm writes to a before using b. Combining the `&' constraint with the register constraint ensures that modifying a will not affect what address is referenced by b. Omitting the `&' constraint means that the location of b will be undefined if a is modified before using b. " Both tmp and retry need the '&' constraint. : "+&q" (retry), "=m" (*buf), "=&q" (tmp) : : "cc"); From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 19 14:36:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3B46F7B; Sun, 19 Oct 2014 14:36:11 +0000 (UTC) Received: from scorpius.renatoaguiar.net.br (unknown [IPv6:2604:5800:0:c:fcbe:cfff:fede:8ed4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "scorpius.renatoaguiar.bet.br", Issuer "scorpius.renatoaguiar.bet.br" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B9AE2CE1; Sun, 19 Oct 2014 14:36:11 +0000 (UTC) Received: from localhost (c-24-4-63-13.hsd1.ca.comcast.net [24.4.63.13]) (authenticated bits=0) by scorpius.renatoaguiar.net.br (8.14.7/8.14.7) with ESMTP id s9JEa2r8091587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Oct 2014 09:36:03 -0500 (CDT) (envelope-from renato@aguiar.info) References: <20141019102848.GR72082@e-new.0x20.net> From: Renato Aguiar To: Lars Engels Subject: Re: help with backlight control and memory Date: Sun, 19 Oct 2014 07:34:14 -0700 In-reply-to: <20141019102848.GR72082@e-new.0x20.net> Message-ID: <86d29ot9dg.fsf@aguiar.info> MIME-Version: 1.0 Content-Type: text/plain Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , Wojciech Puchar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 14:36:12 -0000 Hi Lars, On my X230 I only can change brightness calling acpi directly using acpi_call. Did you make some additional configuration to be able to use sysctl to control brightness? Thanks, Lars Engels writes: > On Sat, Oct 18, 2014 at 11:03:38PM +0200, Wojciech Puchar wrote: >> tried. jsut after kernel is loaded backlight control keys stops working. >> tried loading every acpi_* kernel module that is available, with no >> results > > On my X230 running HEAD brightness keys only work when acpi_video.ko is > _not_ loaded. When it is loaded, I can control brightness with sysctl, > though. -- Renato Aguiar From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 19 17:20:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1FDC2982 for ; Sun, 19 Oct 2014 17:20:20 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ABA1EE74 for ; Sun, 19 Oct 2014 17:20:19 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id hi2so5380924wib.9 for ; Sun, 19 Oct 2014 10:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=JIbFlcearu/HDiRfUKkTnEu5LUbeTlRj7zRPuJGZgW8=; b=EbI4a7GukB84FBeTQ2OBnYEMGYaG5gpNP2lyZyoSu0uAPhjhvBWswDn2SwUakiM25E XjZU1vTCpfu3BxXYM+dOCgC5DeNuSsOwkwb5JDWnlkzQMBARdBiQAhBqvSgyY/wKAG73 mYp0GUGuyM6rN/DYZIFQp1lZ6pKy3yezf++uoRfA96wyMupyJdUNsx65nQ1Z17SAmCqH PlOflxLoupMZwjQEJWQUpdc2ezrmb++voyTVK1hcHJSZ8DLn0gPUqn5ULNGtDnpTpTc5 njgwKaBxX+rkgXDiFObOtE3m8/1IjwlEAf05SwK0suMoXesEctyJugO0b/k8+xXo9hSo WP1g== MIME-Version: 1.0 X-Received: by 10.180.74.4 with SMTP id p4mr13995132wiv.20.1413739218019; Sun, 19 Oct 2014 10:20:18 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Sun, 19 Oct 2014 10:20:17 -0700 (PDT) In-Reply-To: <86d29ot9dg.fsf@aguiar.info> References: <20141019102848.GR72082@e-new.0x20.net> <86d29ot9dg.fsf@aguiar.info> Date: Sun, 19 Oct 2014 10:20:17 -0700 X-Google-Sender-Auth: drzZlmstGgKNZVZUot-EPU-qaRI Message-ID: Subject: Re: help with backlight control and memory From: Adrian Chadd To: Renato Aguiar Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Lars Engels , Wojciech Puchar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 17:20:20 -0000 Is this running the latest -HEAD? Yes, some extra code was glued into the i915kms / drm2 code from Linux that correctly selected the right video output device for the brightness controls. (the opcontrol patch that I committed a couple months back.) The buttons don't work on my X series laptop, but the sysctl does. the buttons work for others on other X series laptops. It's likely some more ACPI and i915kms things need porting. -a On 19 October 2014 07:34, Renato Aguiar wrote: > Hi Lars, > > On my X230 I only can change brightness calling acpi directly using > acpi_call. Did you make some additional configuration to be able to use > sysctl to control brightness? > > Thanks, > > Lars Engels writes: > >> On Sat, Oct 18, 2014 at 11:03:38PM +0200, Wojciech Puchar wrote: >>> tried. jsut after kernel is loaded backlight control keys stops working. >>> tried loading every acpi_* kernel module that is available, with no >>> results >> >> On my X230 running HEAD brightness keys only work when acpi_video.ko is >> _not_ loaded. When it is loaded, I can control brightness with sysctl, >> though. > > -- > Renato Aguiar From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 20 01:11:38 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2FEC2FC; Mon, 20 Oct 2014 01:11:38 +0000 (UTC) Received: from scorpius.renatoaguiar.net.br (unknown [IPv6:2604:5800:0:c:fcbe:cfff:fede:8ed4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "scorpius.renatoaguiar.bet.br", Issuer "scorpius.renatoaguiar.bet.br" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D01ADC; Mon, 20 Oct 2014 01:11:38 +0000 (UTC) Received: from localhost (c-24-4-63-13.hsd1.ca.comcast.net [24.4.63.13]) (authenticated bits=0) by scorpius.renatoaguiar.net.br (8.14.7/8.14.7) with ESMTP id s9K1BQ37093096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Oct 2014 20:11:29 -0500 (CDT) (envelope-from renato@aguiar.info) References: <20141019102848.GR72082@e-new.0x20.net> <86d29ot9dg.fsf@aguiar.info> From: Renato Aguiar To: Adrian Chadd Subject: Re: help with backlight control and memory Date: Sun, 19 Oct 2014 18:05:45 -0700 In-reply-to: Message-ID: <86bnp7tuix.fsf@aguiar.info> MIME-Version: 1.0 Content-Type: text/plain Cc: "freebsd-hackers@freebsd.org" , Lars Engels , Wojciech Puchar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 01:11:38 -0000 Hi Adrian, No, I switched back to stable branch some months ago. I'm currently using 10.1-RC2. I've tried to test using snapshot install image, but my screen goes blank when I try to load i915kms without running Xorg. Is the xbacklight tool working for you on X230 as well? Thanks, Adrian Chadd writes: > Is this running the latest -HEAD? > > Yes, some extra code was glued into the i915kms / drm2 code from Linux > that correctly selected the right video output device for the > brightness controls. (the opcontrol patch that I committed a couple > months back.) > > The buttons don't work on my X series laptop, but the sysctl does. the > buttons work for others on other X series laptops. It's likely some > more ACPI and i915kms things need porting. > > > > -a > > > On 19 October 2014 07:34, Renato Aguiar wrote: >> Hi Lars, >> >> On my X230 I only can change brightness calling acpi directly using >> acpi_call. Did you make some additional configuration to be able to use >> sysctl to control brightness? >> >> Thanks, >> >> Lars Engels writes: >> >>> On Sat, Oct 18, 2014 at 11:03:38PM +0200, Wojciech Puchar wrote: >>>> tried. jsut after kernel is loaded backlight control keys stops working. >>>> tried loading every acpi_* kernel module that is available, with no >>>> results >>> >>> On my X230 running HEAD brightness keys only work when acpi_video.ko is >>> _not_ loaded. When it is loaded, I can control brightness with sysctl, >>> though. >> >> -- >> Renato Aguiar > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Renato Aguiar From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 20 03:07:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E14AA8C; Mon, 20 Oct 2014 03:07:52 +0000 (UTC) Received: from scorpius.renatoaguiar.net.br (unknown [IPv6:2604:5800:0:c:fcbe:cfff:fede:8ed4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "scorpius.renatoaguiar.bet.br", Issuer "scorpius.renatoaguiar.bet.br" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 28929D3D; Mon, 20 Oct 2014 03:07:51 +0000 (UTC) Received: from localhost (c-24-4-63-13.hsd1.ca.comcast.net [24.4.63.13]) (authenticated bits=0) by scorpius.renatoaguiar.net.br (8.14.7/8.14.7) with ESMTP id s9K37f3X093383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Oct 2014 22:07:42 -0500 (CDT) (envelope-from renato@aguiar.info) References: <20141019102848.GR72082@e-new.0x20.net> <86d29ot9dg.fsf@aguiar.info> <86bnp7tuix.fsf@aguiar.info> From: Renato Aguiar To: Adrian Chadd Subject: Re: help with backlight control and memory Date: Sun, 19 Oct 2014 20:05:40 -0700 In-reply-to: <86bnp7tuix.fsf@aguiar.info> Message-ID: <86lhobl9qh.fsf@aguiar.info> MIME-Version: 1.0 Content-Type: text/plain Cc: "freebsd-hackers@freebsd.org" , Lars Engels , Wojciech Puchar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 03:07:52 -0000 Hi Adrian, I've applied your patch into 10.1-RC2 and now I can set brightness using sysctl, but I still can't use xbacklight. At least I don't need acpi_call anymore. Thanks, Renato Aguiar writes: > Hi Adrian, > > No, I switched back to stable branch some months ago. I'm currently > using 10.1-RC2. I've tried to test using snapshot install image, but my > screen goes blank when I try to load i915kms without running Xorg. > > Is the xbacklight tool working for you on X230 as well? > > Thanks, > > Adrian Chadd writes: > >> Is this running the latest -HEAD? >> >> Yes, some extra code was glued into the i915kms / drm2 code from Linux >> that correctly selected the right video output device for the >> brightness controls. (the opcontrol patch that I committed a couple >> months back.) >> >> The buttons don't work on my X series laptop, but the sysctl does. the >> buttons work for others on other X series laptops. It's likely some >> more ACPI and i915kms things need porting. >> >> >> >> -a >> >> >> On 19 October 2014 07:34, Renato Aguiar wrote: >>> Hi Lars, >>> >>> On my X230 I only can change brightness calling acpi directly using >>> acpi_call. Did you make some additional configuration to be able to use >>> sysctl to control brightness? >>> >>> Thanks, >>> >>> Lars Engels writes: >>> >>>> On Sat, Oct 18, 2014 at 11:03:38PM +0200, Wojciech Puchar wrote: >>>>> tried. jsut after kernel is loaded backlight control keys stops working. >>>>> tried loading every acpi_* kernel module that is available, with no >>>>> results >>>> >>>> On my X230 running HEAD brightness keys only work when acpi_video.ko is >>>> _not_ loaded. When it is loaded, I can control brightness with sysctl, >>>> though. >>> >>> -- >>> Renato Aguiar >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Renato Aguiar From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 20 05:48:18 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62E5B208; Mon, 20 Oct 2014 05:48:18 +0000 (UTC) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id 37088C9D; Mon, 20 Oct 2014 05:48:16 +0000 (UTC) Received: from freebsd.my.domain (unknown [58.211.218.74]) by newmailweb.ustc.edu.cn (Coremail) with SMTP id LkAmygDXuRYXokRUphN7AA--.13686S2; Mon, 20 Oct 2014 13:48:13 +0800 (CST) From: Tiwei Bie To: kostikbel@gmail.com Subject: Re: Re: Fwd: Questions with the in_cksumdata() function in sys/amd64/amd64/in_cksum.c Date: Mon, 20 Oct 2014 13:47:55 +0800 Message-Id: <1413784075-42531-1-git-send-email-btw@mail.ustc.edu.cn> X-Mailer: git-send-email 2.1.0 X-CM-TRANSID: LkAmygDXuRYXokRUphN7AA--.13686S2 X-Coremail-Antispam: 1UD129KBjvJXoW3Zr4fAw1xCw4xJF1rGFW3KFg_yoWkKF4fpr 9xGryayr47JF9xJw4ktrZ3tw1rZa9rWF1ayrWUW34xZa4jyw1fX343KrW8WayUWFW2yry3 uFn8tFy2qF1xWwUanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkFb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1Y6r17McIj6I8E87Iv67AKxVW8JVWxJw Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lc2xSY4AK67AK6r4rMxAIw28I cxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2 IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI 42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42 IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07bFfO7UUUUU= X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQUBAVQhl8bqJQAVs6 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 05:48:18 -0000 > I would be not surprised if this manual prefetching by explicit reads > causes slowdown of the function. I suspect it could confuse hardware > prefetcher by breaking the linear pattern, or the patch could break > the logic of the limited forward-looking oracle by reading too far > from the current linear read tip. > > Also, it could confuse the data flow engine if the register allocator > is unable to see that the read value is needed not right now, and cause > unneeded stall while next cache line is fetched. > > Sure, all my speculations are pure garbage until confirmed by > measurements with pmc, but I think that the patch below must be > benchmarked to confirm any value it provides as well. My opinion is, > we should either remove the manual prefetch, or do it with PREFETCHLX > instructions only, instead of real read. I have done a rather simple test. And the results are listed as follows: #1. Read 32 bytes with manual pre-read in each loop: $ cc main.c -D_32BYTES_WITH_PRE_READ $ for i in `seq 3`; do ./a.out; done 0.768854 0.770332 0.773803 #2. Read 64 bytes with manual pre-read in each loop: $ cc main.c -D_64BYTES_WITH_PRE_READ $ for i in `seq 3`; do ./a.out; done 0.702416 0.703648 0.704498 #3. Read 32 bytes without manual prefetch in each loop: $ cc main.c -D_32BYTES_WITHOUT_MANUAL_PREFETCH $ for i in `seq 3`; do ./a.out; done 0.726651 0.728841 0.725956 #4. Read 64 bytes without manual prefetch in each loop: $ cc main.c -D_64BYTES_WITHOUT_MANUAL_PREFETCH $ for i in `seq 3`; do ./a.out; done 0.698071 0.697971 0.698314 #5. Read 64 bytes with PREFETCH instruction: $ cc main.c -D_64BYTES_WITH_PREFETCH_INSTRUCTION $ for i in `seq 3`; do ./a.out; done 0.715883 0.712118 0.711962 The test is very simple. I just run the in_cksumdata() function on one million packets. And the result is the time spent on calculating these checksums. As we can see from the results, when reading 64 bytes data without manual prefetch operation in each loop, the speed is fastest. So, I think read a whole cache line in each loop is helpful. --- The computer that I run the test program on: $ dmesg | grep CPU: CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz (3093.03-MHz K8-class CPU) --- The test program: #include #include #include /* ------------------------------------------------------------------------ */ #define PACKET_SIZE 1500 #define BUFFER_SIZE ((PACKET_SIZE) << 20) static unsigned char buffer[BUFFER_SIZE]; /* ------------------------------------------------------------------------ */ /* * Checksum routine for Internet Protocol family headers * (Portable Alpha version). * * This routine is very heavily used in the network * code and should be modified for each CPU to be as fast as possible. */ #define ADDCARRY(x) (x > 65535 ? x -= 65535 : x) #define REDUCE32 \ { \ q_util.q = sum; \ sum = q_util.s[0] + q_util.s[1] + q_util.s[2] + q_util.s[3]; \ } #define REDUCE16 \ { \ q_util.q = sum; \ l_util.l = q_util.s[0] + q_util.s[1] + q_util.s[2] + q_util.s[3]; \ sum = l_util.s[0] + l_util.s[1]; \ ADDCARRY(sum); \ } static const u_int32_t in_masks[] = { /*0 bytes*/ /*1 byte*/ /*2 bytes*/ /*3 bytes*/ 0x00000000, 0x000000FF, 0x0000FFFF, 0x00FFFFFF, /* offset 0 */ 0x00000000, 0x0000FF00, 0x00FFFF00, 0xFFFFFF00, /* offset 1 */ 0x00000000, 0x00FF0000, 0xFFFF0000, 0xFFFF0000, /* offset 2 */ 0x00000000, 0xFF000000, 0xFF000000, 0xFF000000, /* offset 3 */ }; union l_util { u_int16_t s[2]; u_int32_t l; }; union q_util { u_int16_t s[4]; u_int32_t l[2]; u_int64_t q; }; /* ------------------------------------------------------------------------ */ //#define _32BYTES_WITH_PRE_READ //#define _64BYTES_WITH_PRE_READ //#define _32BYTES_WITHOUT_MANUAL_PREFETCH //#define _64BYTES_WITHOUT_MANUAL_PREFETCH //#define _64BYTES_WITH_PREFETCH_INSTRUCTION #ifdef _32BYTES_WITH_PRE_READ static u_int64_t in_cksumdata(const void *buf, int len) { const u_int32_t *lw = (const u_int32_t *) buf; u_int64_t sum = 0; u_int64_t prefilled; int offset; union q_util q_util; if ((3 & (long) lw) == 0 && len == 20) { sum = (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3] + lw[4]; REDUCE32; return sum; } if ((offset = 3 & (long) lw) != 0) { const u_int32_t *masks = in_masks + (offset << 2); lw = (u_int32_t *) (((long) lw) - offset); sum = *lw++ & masks[len >= 3 ? 3 : len]; len -= 4 - offset; if (len <= 0) { REDUCE32; return sum; } } #if 0 /* * Force to cache line boundary. */ offset = 32 - (0x1f & (long) lw); if (offset < 32 && len > offset) { len -= offset; if (4 & offset) { sum += (u_int64_t) lw[0]; lw += 1; } if (8 & offset) { sum += (u_int64_t) lw[0] + lw[1]; lw += 2; } if (16 & offset) { sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; lw += 4; } } #endif /* * access prefilling to start load of next cache line. * then add current cache line * save result of prefilling for loop iteration. */ prefilled = lw[0]; while ((len -= 32) >= 4) { u_int64_t prefilling = lw[8]; sum += prefilled + lw[1] + lw[2] + lw[3] + lw[4] + lw[5] + lw[6] + lw[7]; lw += 8; prefilled = prefilling; } if (len >= 0) { sum += prefilled + lw[1] + lw[2] + lw[3] + lw[4] + lw[5] + lw[6] + lw[7]; lw += 8; } else { len += 32; } while ((len -= 16) >= 0) { sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; lw += 4; } len += 16; while ((len -= 4) >= 0) { sum += (u_int64_t) *lw++; } len += 4; if (len > 0) sum += (u_int64_t) (in_masks[len] & *lw); REDUCE32; return sum; } #endif #ifdef _64BYTES_WITH_PRE_READ static u_int64_t in_cksumdata(const void *buf, int len) { const u_int32_t *lw = (const u_int32_t *) buf; u_int64_t sum = 0; u_int64_t prefilled; int offset; union q_util q_util; if ((3 & (long) lw) == 0 && len == 20) { sum = (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3] + lw[4]; REDUCE32; return sum; } if ((offset = 3 & (long) lw) != 0) { const u_int32_t *masks = in_masks + (offset << 2); lw = (u_int32_t *) (((long) lw) - offset); sum = *lw++ & masks[len >= 3 ? 3 : len]; len -= 4 - offset; if (len <= 0) { REDUCE32; return sum; } } #if 0 /* * Force to cache line boundary. */ offset = 32 - (0x1f & (long) lw); if (offset < 32 && len > offset) { len -= offset; if (4 & offset) { sum += (u_int64_t) lw[0]; lw += 1; } if (8 & offset) { sum += (u_int64_t) lw[0] + lw[1]; lw += 2; } if (16 & offset) { sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; lw += 4; } } #endif /* * access prefilling to start load of next cache line. * then add current cache line * save result of prefilling for loop iteration. */ prefilled = lw[0]; while ((len -= 64) >= 4) { u_int64_t prefilling = lw[16]; sum += prefilled + lw[1] + lw[2] + lw[3] + lw[4] + lw[5] + lw[6] + lw[7] + lw[8] + lw[9] + lw[10] + lw[11] + lw[12] + lw[13] + lw[14] + lw[15]; lw += 16; prefilled = prefilling; } if (len >= 0) { sum += prefilled + lw[1] + lw[2] + lw[3] + lw[4] + lw[5] + lw[6] + lw[7] + lw[8] + lw[9] + lw[10] + lw[11] + lw[12] + lw[13] + lw[14] + lw[15]; lw += 16; } else { len += 64; } while ((len -= 16) >= 0) { sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; lw += 4; } len += 16; while ((len -= 4) >= 0) { sum += (u_int64_t) *lw++; } len += 4; if (len > 0) sum += (u_int64_t) (in_masks[len] & *lw); REDUCE32; return sum; } #endif #ifdef _32BYTES_WITHOUT_MANUAL_PREFETCH static u_int64_t in_cksumdata(const void *buf, int len) { const u_int32_t *lw = (const u_int32_t *) buf; u_int64_t sum = 0; int offset; union q_util q_util; if ((3 & (long) lw) == 0 && len == 20) { sum = (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3] + lw[4]; REDUCE32; return sum; } if ((offset = 3 & (long) lw) != 0) { const u_int32_t *masks = in_masks + (offset << 2); lw = (u_int32_t *) (((long) lw) - offset); sum = *lw++ & masks[len >= 3 ? 3 : len]; len -= 4 - offset; if (len <= 0) { REDUCE32; return sum; } } #if 0 /* * Force to cache line boundary. */ offset = 32 - (0x1f & (long) lw); if (offset < 32 && len > offset) { len -= offset; if (4 & offset) { sum += (u_int64_t) lw[0]; lw += 1; } if (8 & offset) { sum += (u_int64_t) lw[0] + lw[1]; lw += 2; } if (16 & offset) { sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; lw += 4; } } #endif /* * access prefilling to start load of next cache line. * then add current cache line * save result of prefilling for loop iteration. */ while ((len -= 32) >= 4) { sum += lw[0] + lw[1] + lw[2] + lw[3] + lw[4] + lw[5] + lw[6] + lw[7]; lw += 8; } if (len >= 0) { sum += lw[0] + lw[1] + lw[2] + lw[3] + lw[4] + lw[5] + lw[6] + lw[7]; lw += 8; } else { len += 32; } while ((len -= 16) >= 0) { sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; lw += 4; } len += 16; while ((len -= 4) >= 0) { sum += (u_int64_t) *lw++; } len += 4; if (len > 0) sum += (u_int64_t) (in_masks[len] & *lw); REDUCE32; return sum; } #endif #ifdef _64BYTES_WITHOUT_MANUAL_PREFETCH static u_int64_t in_cksumdata(const void *buf, int len) { const u_int32_t *lw = (const u_int32_t *) buf; u_int64_t sum = 0; int offset; union q_util q_util; if ((3 & (long) lw) == 0 && len == 20) { sum = (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3] + lw[4]; REDUCE32; return sum; } if ((offset = 3 & (long) lw) != 0) { const u_int32_t *masks = in_masks + (offset << 2); lw = (u_int32_t *) (((long) lw) - offset); sum = *lw++ & masks[len >= 3 ? 3 : len]; len -= 4 - offset; if (len <= 0) { REDUCE32; return sum; } } #if 0 /* * Force to cache line boundary. */ offset = 32 - (0x1f & (long) lw); if (offset < 32 && len > offset) { len -= offset; if (4 & offset) { sum += (u_int64_t) lw[0]; lw += 1; } if (8 & offset) { sum += (u_int64_t) lw[0] + lw[1]; lw += 2; } if (16 & offset) { sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; lw += 4; } } #endif /* * access prefilling to start load of next cache line. * then add current cache line * save result of prefilling for loop iteration. */ while ((len -= 64) >= 4) { sum += lw[0] + lw[1] + lw[2] + lw[3] + lw[4] + lw[5] + lw[6] + lw[7] + lw[8] + lw[9] + lw[10] + lw[11] + lw[12] + lw[13] + lw[14] + lw[15]; lw += 16; } if (len >= 0) { sum += lw[0] + lw[1] + lw[2] + lw[3] + lw[4] + lw[5] + lw[6] + lw[7] + lw[8] + lw[9] + lw[10] + lw[11] + lw[12] + lw[13] + lw[14] + lw[15]; lw += 16; } else { len += 64; } while ((len -= 16) >= 0) { sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; lw += 4; } len += 16; while ((len -= 4) >= 0) { sum += (u_int64_t) *lw++; } len += 4; if (len > 0) sum += (u_int64_t) (in_masks[len] & *lw); REDUCE32; return sum; } #endif #ifdef _64BYTES_WITH_PREFETCH_INSTRUCTION static u_int64_t in_cksumdata(const void *buf, int len) { const u_int32_t *lw = (const u_int32_t *) buf; u_int64_t sum = 0; int offset; union q_util q_util; if ((3 & (long) lw) == 0 && len == 20) { sum = (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3] + lw[4]; REDUCE32; return sum; } if ((offset = 3 & (long) lw) != 0) { const u_int32_t *masks = in_masks + (offset << 2); lw = (u_int32_t *) (((long) lw) - offset); sum = *lw++ & masks[len >= 3 ? 3 : len]; len -= 4 - offset; if (len <= 0) { REDUCE32; return sum; } } #if 0 /* * Force to cache line boundary. */ offset = 32 - (0x1f & (long) lw); if (offset < 32 && len > offset) { len -= offset; if (4 & offset) { sum += (u_int64_t) lw[0]; lw += 1; } if (8 & offset) { sum += (u_int64_t) lw[0] + lw[1]; lw += 2; } if (16 & offset) { sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; lw += 4; } } #endif /* * access prefilling to start load of next cache line. * then add current cache line * save result of prefilling for loop iteration. */ __builtin_prefetch(&lw[0]); while ((len -= 64) >= 4) { __builtin_prefetch(&lw[16]); sum += lw[0] + lw[1] + lw[2] + lw[3] + lw[4] + lw[5] + lw[6] + lw[7] + lw[8] + lw[9] + lw[10] + lw[11] + lw[12] + lw[13] + lw[14] + lw[15]; lw += 16; } if (len >= 0) { sum += lw[0] + lw[1] + lw[2] + lw[3] + lw[4] + lw[5] + lw[6] + lw[7] + lw[8] + lw[9] + lw[10] + lw[11] + lw[12] + lw[13] + lw[14] + lw[15]; lw += 16; } else { len += 64; } while ((len -= 16) >= 0) { sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; lw += 4; } len += 16; while ((len -= 4) >= 0) { sum += (u_int64_t) *lw++; } len += 4; if (len > 0) sum += (u_int64_t) (in_masks[len] & *lw); REDUCE32; return sum; } #endif /* ------------------------------------------------------------------------ */ int main(void) { int i; int sum; struct timeval tv1, tv2, res; gettimeofday(&tv1, NULL); for (i = 0; i < BUFFER_SIZE; i += PACKET_SIZE) sum = in_cksumdata(&buffer[i], PACKET_SIZE); gettimeofday(&tv2, NULL); timersub(&tv2, &tv1, &res); printf("%ld.%6ld\n", res.tv_sec, res.tv_usec); return (0); } From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 20 06:15:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0DE71763; Mon, 20 Oct 2014 06:15:15 +0000 (UTC) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id 290B2EDD; Mon, 20 Oct 2014 06:15:13 +0000 (UTC) Received: from freebsd.my.domain (unknown [58.211.218.74]) by newmailweb.ustc.edu.cn (Coremail) with SMTP id LkAmygCnVzxoqERUIDh7AA--.13718S2; Mon, 20 Oct 2014 14:15:11 +0800 (CST) From: Tiwei Bie To: kostikbel@gmail.com Subject: Re: Re: Re: Fwd: Questions with the in_cksumdata() function in sys/amd64/amd64/in_cksum.c Date: Mon, 20 Oct 2014 14:14:53 +0800 Message-Id: <1413785693-56400-1-git-send-email-btw@mail.ustc.edu.cn> X-Mailer: git-send-email 2.1.0 X-CM-TRANSID: LkAmygCnVzxoqERUIDh7AA--.13718S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUUY87k0a2IF6F4UM7kC6x804xWl14x267AK xVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw A2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26F1j 6w1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26F4j6r4UJwA2z4x0Y4vEx4A2jsIE14v26r xl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv 0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z2 80aVAFwI0_Gr0_Cr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JMxkIecxE wVAFwVW8AwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F4 0E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1l IxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxV AFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v2 6r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU0 nYFtUUUUU== X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQUBAVQhl8bqJQAXs4 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 06:15:15 -0000 Minor fix to the test program, lol. diff --git a/misc/test/prefetch/main.c b/misc/test/prefetch/main.c index 8f72085..9d2577d 100644 --- a/misc/test/prefetch/main.c +++ b/misc/test/prefetch/main.c @@ -490,7 +490,7 @@ int main(void) gettimeofday(&tv2, NULL); timersub(&tv2, &tv1, &res); - printf("%ld.%6ld\n", res.tv_sec, res.tv_usec); + printf("%ld.%06ld\n", res.tv_sec, res.tv_usec); return (0); } From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 20 08:34:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3BDA45B8; Mon, 20 Oct 2014 08:34:02 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 77583EB2; Mon, 20 Oct 2014 08:34:01 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s9K8Xopq075341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2014 11:33:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s9K8Xopq075341 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s9K8XnGL075340; Mon, 20 Oct 2014 11:33:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 20 Oct 2014 11:33:49 +0300 From: Konstantin Belousov To: Tiwei Bie Subject: Re: Re: Fwd: Questions with the in_cksumdata() function in sys/amd64/amd64/in_cksum.c Message-ID: <20141020083349.GM2153@kib.kiev.ua> References: <1413784075-42531-1-git-send-email-btw@mail.ustc.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1413784075-42531-1-git-send-email-btw@mail.ustc.edu.cn> User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 08:34:02 -0000 On Mon, Oct 20, 2014 at 01:47:55PM +0800, Tiwei Bie wrote: > > I would be not surprised if this manual prefetching by explicit reads > > causes slowdown of the function. I suspect it could confuse hardware > > prefetcher by breaking the linear pattern, or the patch could break > > the logic of the limited forward-looking oracle by reading too far > > from the current linear read tip. > > > > Also, it could confuse the data flow engine if the register allocator > > is unable to see that the read value is needed not right now, and cause > > unneeded stall while next cache line is fetched. > > > > Sure, all my speculations are pure garbage until confirmed by > > measurements with pmc, but I think that the patch below must be > > benchmarked to confirm any value it provides as well. My opinion is, > > we should either remove the manual prefetch, or do it with PREFETCHLX > > instructions only, instead of real read. > > I have done a rather simple test. And the results are listed as follows: > Yes, too simple to draw conclusion, IMO. Please look at the ministat(1). I think that the test run length is too short to come with any decisions. The length x 3 runs does not give enough confidence; but ministat would provide the numbers to judge. > #1. Read 32 bytes with manual pre-read in each loop: > > $ cc main.c -D_32BYTES_WITH_PRE_READ > $ for i in `seq 3`; do ./a.out; done > 0.768854 > 0.770332 > 0.773803 > > #2. Read 64 bytes with manual pre-read in each loop: > > $ cc main.c -D_64BYTES_WITH_PRE_READ > $ for i in `seq 3`; do ./a.out; done > 0.702416 > 0.703648 > 0.704498 > > #3. Read 32 bytes without manual prefetch in each loop: > > $ cc main.c -D_32BYTES_WITHOUT_MANUAL_PREFETCH > $ for i in `seq 3`; do ./a.out; done > 0.726651 > 0.728841 > 0.725956 > > #4. Read 64 bytes without manual prefetch in each loop: > > $ cc main.c -D_64BYTES_WITHOUT_MANUAL_PREFETCH > $ for i in `seq 3`; do ./a.out; done > 0.698071 > 0.697971 > 0.698314 > > #5. Read 64 bytes with PREFETCH instruction: > > $ cc main.c -D_64BYTES_WITH_PREFETCH_INSTRUCTION > $ for i in `seq 3`; do ./a.out; done > 0.715883 > 0.712118 > 0.711962 > > The test is very simple. I just run the in_cksumdata() function on one > million packets. And the result is the time spent on calculating these > checksums. > > As we can see from the results, when reading 64 bytes data without manual > prefetch operation in each loop, the speed is fastest. So, I think read > a whole cache line in each loop is helpful. > > --- > > The computer that I run the test program on: > > $ dmesg | grep CPU: > CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz (3093.03-MHz K8-class CPU) > > --- > > The test program: > > #include > #include > #include > > /* ------------------------------------------------------------------------ */ > > #define PACKET_SIZE 1500 > #define BUFFER_SIZE ((PACKET_SIZE) << 20) > static unsigned char buffer[BUFFER_SIZE]; > > /* ------------------------------------------------------------------------ */ > > /* > * Checksum routine for Internet Protocol family headers > * (Portable Alpha version). > * > * This routine is very heavily used in the network > * code and should be modified for each CPU to be as fast as possible. > */ > > #define ADDCARRY(x) (x > 65535 ? x -= 65535 : x) > #define REDUCE32 \ > { \ > q_util.q = sum; \ > sum = q_util.s[0] + q_util.s[1] + q_util.s[2] + q_util.s[3]; \ > } > #define REDUCE16 \ > { \ > q_util.q = sum; \ > l_util.l = q_util.s[0] + q_util.s[1] + q_util.s[2] + q_util.s[3]; \ > sum = l_util.s[0] + l_util.s[1]; \ > ADDCARRY(sum); \ > } > > static const u_int32_t in_masks[] = { > /*0 bytes*/ /*1 byte*/ /*2 bytes*/ /*3 bytes*/ > 0x00000000, 0x000000FF, 0x0000FFFF, 0x00FFFFFF, /* offset 0 */ > 0x00000000, 0x0000FF00, 0x00FFFF00, 0xFFFFFF00, /* offset 1 */ > 0x00000000, 0x00FF0000, 0xFFFF0000, 0xFFFF0000, /* offset 2 */ > 0x00000000, 0xFF000000, 0xFF000000, 0xFF000000, /* offset 3 */ > }; > > union l_util { > u_int16_t s[2]; > u_int32_t l; > }; > union q_util { > u_int16_t s[4]; > u_int32_t l[2]; > u_int64_t q; > }; > > /* ------------------------------------------------------------------------ */ > > //#define _32BYTES_WITH_PRE_READ > //#define _64BYTES_WITH_PRE_READ > //#define _32BYTES_WITHOUT_MANUAL_PREFETCH > //#define _64BYTES_WITHOUT_MANUAL_PREFETCH > //#define _64BYTES_WITH_PREFETCH_INSTRUCTION > > #ifdef _32BYTES_WITH_PRE_READ > static u_int64_t > in_cksumdata(const void *buf, int len) > { > const u_int32_t *lw = (const u_int32_t *) buf; > u_int64_t sum = 0; > u_int64_t prefilled; > int offset; > union q_util q_util; > > if ((3 & (long) lw) == 0 && len == 20) { > sum = (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3] + lw[4]; > REDUCE32; > return sum; > } > > if ((offset = 3 & (long) lw) != 0) { > const u_int32_t *masks = in_masks + (offset << 2); > lw = (u_int32_t *) (((long) lw) - offset); > sum = *lw++ & masks[len >= 3 ? 3 : len]; > len -= 4 - offset; > if (len <= 0) { > REDUCE32; > return sum; > } > } > #if 0 > /* > * Force to cache line boundary. > */ > offset = 32 - (0x1f & (long) lw); > if (offset < 32 && len > offset) { > len -= offset; > if (4 & offset) { > sum += (u_int64_t) lw[0]; > lw += 1; > } > if (8 & offset) { > sum += (u_int64_t) lw[0] + lw[1]; > lw += 2; > } > if (16 & offset) { > sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; > lw += 4; > } > } > #endif > /* > * access prefilling to start load of next cache line. > * then add current cache line > * save result of prefilling for loop iteration. > */ > prefilled = lw[0]; > while ((len -= 32) >= 4) { > u_int64_t prefilling = lw[8]; > sum += prefilled + lw[1] + lw[2] + lw[3] > + lw[4] + lw[5] + lw[6] + lw[7]; > lw += 8; > prefilled = prefilling; > } > if (len >= 0) { > sum += prefilled + lw[1] + lw[2] + lw[3] > + lw[4] + lw[5] + lw[6] + lw[7]; > lw += 8; > } else { > len += 32; > } > while ((len -= 16) >= 0) { > sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; > lw += 4; > } > len += 16; > while ((len -= 4) >= 0) { > sum += (u_int64_t) *lw++; > } > len += 4; > if (len > 0) > sum += (u_int64_t) (in_masks[len] & *lw); > REDUCE32; > return sum; > } > #endif > > #ifdef _64BYTES_WITH_PRE_READ > static u_int64_t > in_cksumdata(const void *buf, int len) > { > const u_int32_t *lw = (const u_int32_t *) buf; > u_int64_t sum = 0; > u_int64_t prefilled; > int offset; > union q_util q_util; > > if ((3 & (long) lw) == 0 && len == 20) { > sum = (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3] + lw[4]; > REDUCE32; > return sum; > } > > if ((offset = 3 & (long) lw) != 0) { > const u_int32_t *masks = in_masks + (offset << 2); > lw = (u_int32_t *) (((long) lw) - offset); > sum = *lw++ & masks[len >= 3 ? 3 : len]; > len -= 4 - offset; > if (len <= 0) { > REDUCE32; > return sum; > } > } > #if 0 > /* > * Force to cache line boundary. > */ > offset = 32 - (0x1f & (long) lw); > if (offset < 32 && len > offset) { > len -= offset; > if (4 & offset) { > sum += (u_int64_t) lw[0]; > lw += 1; > } > if (8 & offset) { > sum += (u_int64_t) lw[0] + lw[1]; > lw += 2; > } > if (16 & offset) { > sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; > lw += 4; > } > } > #endif > /* > * access prefilling to start load of next cache line. > * then add current cache line > * save result of prefilling for loop iteration. > */ > prefilled = lw[0]; > while ((len -= 64) >= 4) { > u_int64_t prefilling = lw[16]; > sum += prefilled + lw[1] + lw[2] + lw[3] > + lw[4] + lw[5] + lw[6] + lw[7] > + lw[8] + lw[9] + lw[10] + lw[11] > + lw[12] + lw[13] + lw[14] + lw[15]; > lw += 16; > prefilled = prefilling; > } > if (len >= 0) { > sum += prefilled + lw[1] + lw[2] + lw[3] > + lw[4] + lw[5] + lw[6] + lw[7] > + lw[8] + lw[9] + lw[10] + lw[11] > + lw[12] + lw[13] + lw[14] + lw[15]; > lw += 16; > } else { > len += 64; > } > while ((len -= 16) >= 0) { > sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; > lw += 4; > } > len += 16; > while ((len -= 4) >= 0) { > sum += (u_int64_t) *lw++; > } > len += 4; > if (len > 0) > sum += (u_int64_t) (in_masks[len] & *lw); > REDUCE32; > return sum; > } > #endif > > #ifdef _32BYTES_WITHOUT_MANUAL_PREFETCH > static u_int64_t > in_cksumdata(const void *buf, int len) > { > const u_int32_t *lw = (const u_int32_t *) buf; > u_int64_t sum = 0; > int offset; > union q_util q_util; > > if ((3 & (long) lw) == 0 && len == 20) { > sum = (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3] + lw[4]; > REDUCE32; > return sum; > } > > if ((offset = 3 & (long) lw) != 0) { > const u_int32_t *masks = in_masks + (offset << 2); > lw = (u_int32_t *) (((long) lw) - offset); > sum = *lw++ & masks[len >= 3 ? 3 : len]; > len -= 4 - offset; > if (len <= 0) { > REDUCE32; > return sum; > } > } > #if 0 > /* > * Force to cache line boundary. > */ > offset = 32 - (0x1f & (long) lw); > if (offset < 32 && len > offset) { > len -= offset; > if (4 & offset) { > sum += (u_int64_t) lw[0]; > lw += 1; > } > if (8 & offset) { > sum += (u_int64_t) lw[0] + lw[1]; > lw += 2; > } > if (16 & offset) { > sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; > lw += 4; > } > } > #endif > /* > * access prefilling to start load of next cache line. > * then add current cache line > * save result of prefilling for loop iteration. > */ > while ((len -= 32) >= 4) { > sum += lw[0] + lw[1] + lw[2] + lw[3] > + lw[4] + lw[5] + lw[6] + lw[7]; > lw += 8; > } > if (len >= 0) { > sum += lw[0] + lw[1] + lw[2] + lw[3] > + lw[4] + lw[5] + lw[6] + lw[7]; > lw += 8; > } else { > len += 32; > } > while ((len -= 16) >= 0) { > sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; > lw += 4; > } > len += 16; > while ((len -= 4) >= 0) { > sum += (u_int64_t) *lw++; > } > len += 4; > if (len > 0) > sum += (u_int64_t) (in_masks[len] & *lw); > REDUCE32; > return sum; > } > #endif > > #ifdef _64BYTES_WITHOUT_MANUAL_PREFETCH > static u_int64_t > in_cksumdata(const void *buf, int len) > { > const u_int32_t *lw = (const u_int32_t *) buf; > u_int64_t sum = 0; > int offset; > union q_util q_util; > > if ((3 & (long) lw) == 0 && len == 20) { > sum = (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3] + lw[4]; > REDUCE32; > return sum; > } > > if ((offset = 3 & (long) lw) != 0) { > const u_int32_t *masks = in_masks + (offset << 2); > lw = (u_int32_t *) (((long) lw) - offset); > sum = *lw++ & masks[len >= 3 ? 3 : len]; > len -= 4 - offset; > if (len <= 0) { > REDUCE32; > return sum; > } > } > #if 0 > /* > * Force to cache line boundary. > */ > offset = 32 - (0x1f & (long) lw); > if (offset < 32 && len > offset) { > len -= offset; > if (4 & offset) { > sum += (u_int64_t) lw[0]; > lw += 1; > } > if (8 & offset) { > sum += (u_int64_t) lw[0] + lw[1]; > lw += 2; > } > if (16 & offset) { > sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; > lw += 4; > } > } > #endif > /* > * access prefilling to start load of next cache line. > * then add current cache line > * save result of prefilling for loop iteration. > */ > while ((len -= 64) >= 4) { > sum += lw[0] + lw[1] + lw[2] + lw[3] > + lw[4] + lw[5] + lw[6] + lw[7] > + lw[8] + lw[9] + lw[10] + lw[11] > + lw[12] + lw[13] + lw[14] + lw[15]; > lw += 16; > } > if (len >= 0) { > sum += lw[0] + lw[1] + lw[2] + lw[3] > + lw[4] + lw[5] + lw[6] + lw[7] > + lw[8] + lw[9] + lw[10] + lw[11] > + lw[12] + lw[13] + lw[14] + lw[15]; > lw += 16; > } else { > len += 64; > } > while ((len -= 16) >= 0) { > sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; > lw += 4; > } > len += 16; > while ((len -= 4) >= 0) { > sum += (u_int64_t) *lw++; > } > len += 4; > if (len > 0) > sum += (u_int64_t) (in_masks[len] & *lw); > REDUCE32; > return sum; > } > #endif > > #ifdef _64BYTES_WITH_PREFETCH_INSTRUCTION > static u_int64_t > in_cksumdata(const void *buf, int len) > { > const u_int32_t *lw = (const u_int32_t *) buf; > u_int64_t sum = 0; > int offset; > union q_util q_util; > > if ((3 & (long) lw) == 0 && len == 20) { > sum = (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3] + lw[4]; > REDUCE32; > return sum; > } > > if ((offset = 3 & (long) lw) != 0) { > const u_int32_t *masks = in_masks + (offset << 2); > lw = (u_int32_t *) (((long) lw) - offset); > sum = *lw++ & masks[len >= 3 ? 3 : len]; > len -= 4 - offset; > if (len <= 0) { > REDUCE32; > return sum; > } > } > #if 0 > /* > * Force to cache line boundary. > */ > offset = 32 - (0x1f & (long) lw); > if (offset < 32 && len > offset) { > len -= offset; > if (4 & offset) { > sum += (u_int64_t) lw[0]; > lw += 1; > } > if (8 & offset) { > sum += (u_int64_t) lw[0] + lw[1]; > lw += 2; > } > if (16 & offset) { > sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; > lw += 4; > } > } > #endif > /* > * access prefilling to start load of next cache line. > * then add current cache line > * save result of prefilling for loop iteration. > */ > __builtin_prefetch(&lw[0]); > while ((len -= 64) >= 4) { > __builtin_prefetch(&lw[16]); > sum += lw[0] + lw[1] + lw[2] + lw[3] > + lw[4] + lw[5] + lw[6] + lw[7] > + lw[8] + lw[9] + lw[10] + lw[11] > + lw[12] + lw[13] + lw[14] + lw[15]; > lw += 16; > } > if (len >= 0) { > sum += lw[0] + lw[1] + lw[2] + lw[3] > + lw[4] + lw[5] + lw[6] + lw[7] > + lw[8] + lw[9] + lw[10] + lw[11] > + lw[12] + lw[13] + lw[14] + lw[15]; > lw += 16; > } else { > len += 64; > } > while ((len -= 16) >= 0) { > sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; > lw += 4; > } > len += 16; > while ((len -= 4) >= 0) { > sum += (u_int64_t) *lw++; > } > len += 4; > if (len > 0) > sum += (u_int64_t) (in_masks[len] & *lw); > REDUCE32; > return sum; > } > #endif > > /* ------------------------------------------------------------------------ */ > > int main(void) > { > int i; > int sum; > struct timeval tv1, tv2, res; > > gettimeofday(&tv1, NULL); > for (i = 0; i < BUFFER_SIZE; i += PACKET_SIZE) > sum = in_cksumdata(&buffer[i], PACKET_SIZE); > gettimeofday(&tv2, NULL); > > timersub(&tv2, &tv1, &res); > printf("%ld.%6ld\n", res.tv_sec, res.tv_usec); > > return (0); > } > From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 20 10:35:26 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0759E3; Mon, 20 Oct 2014 10:35:26 +0000 (UTC) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id A5F41F1D; Mon, 20 Oct 2014 10:35:25 +0000 (UTC) Received: from freebsd.my.domain (unknown [58.211.218.74]) by newmailweb.ustc.edu.cn (Coremail) with SMTP id LkAmygBXORaH40RUxoJ8AA--.12897S2; Mon, 20 Oct 2014 18:27:26 +0800 (CST) From: Tiwei Bie To: kostikbel@gmail.com Subject: Re: Re: Re: Fwd: Questions with the in_cksumdata() function in sys/amd64/amd64/in_cksum.c Date: Mon, 20 Oct 2014 18:27:07 +0800 Message-Id: <1413800827-78140-1-git-send-email-btw@mail.ustc.edu.cn> X-Mailer: git-send-email 2.1.0 X-CM-TRANSID: LkAmygBXORaH40RUxoJ8AA--.12897S2 X-Coremail-Antispam: 1UD129KBjvAXoW3Zr4fAw1xZr4kKFWxWr4kJFb_yoW8XF4kCo W5Zr17ZF48Aw1avw1kt34YgrnrGa4Dt3y7ZFyrJrZ3Cwnxt3Z8urn7Xa1rGFZxJrWfA3W8 ZFZrXr1UAry7Grs8n29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73VFW2AGmfu7bjvjm3 AaLaJ3UjIYCTnIWjp_UUUY87k0a2IF6w4kM7kC6x804xWl14x267AKxVWUJVW8JwAFc2x0 x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj4 1l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26F1j6w1UM28EF7xvwVC0 I7IYx2IY6xkF7I0E14v26F4j6r4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Cr0_Gr 1UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCY02Avz4vE14v_Gw1l42xK 82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGw C20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48J MIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMI IF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvE x4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU5xWFUUUUUU== X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQUBAVQhl8bqJQAbs0 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 10:35:26 -0000 > > > I would be not surprised if this manual prefetching by explicit reads > > > causes slowdown of the function. I suspect it could confuse hardware > > > prefetcher by breaking the linear pattern, or the patch could break > > > the logic of the limited forward-looking oracle by reading too far > > > from the current linear read tip. > > > > > > Also, it could confuse the data flow engine if the register allocator > > > is unable to see that the read value is needed not right now, and cause > > > unneeded stall while next cache line is fetched. > > > > > > Sure, all my speculations are pure garbage until confirmed by > > > measurements with pmc, but I think that the patch below must be > > > benchmarked to confirm any value it provides as well. My opinion is, > > > we should either remove the manual prefetch, or do it with PREFETCHLX > > > instructions only, instead of real read. > > > > I have done a rather simple test. And the results are listed as follows: > > > Yes, too simple to draw conclusion, IMO. > > Please look at the ministat(1). I think that the test run length > is too short to come with any decisions. The length x 3 runs does not > give enough confidence; but ministat would provide the numbers to judge. I have run ministat with these results, and the following is the output of ministat. It said that the difference is at 99.5% confidence. $ ministat -w 80 -s -c 99.5 32BYTES_WITH_PRE_READ 32BYTES_WITHOUT_MANUAL_PREFETCH 64BYTES_WITH_PRE_READ 64BYTES_WITHOUT_MANUAL_PREFETCH 64BYTES_WITH_PREFETCH_INSTRUCTION x 32BYTES_WITH_PRE_READ + 32BYTES_WITHOUT_MANUAL_PREFETCH * 64BYTES_WITH_PRE_READ % 64BYTES_WITHOUT_MANUAL_PREFETCH # 64BYTES_WITH_PREFETCH_INSTRUCTION +--------------------------------------------------------------------------------+ |% # | |% *** # # ++ + xx x| | |_MA__|| | |A_| | | |A| | |A | | |MA_| | +--------------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 3 0.768854 0.773803 0.770332 0.77099633 0.0025405028 + 3 0.725956 0.728841 0.726651 0.72714933 0.0015056754 Difference at 99.5% confidence -0.043847 +/- 0.0122301 -5.68706% +/- 1.58627% (Student's t, pooled s = 0.00208821) * 3 0.702416 0.704498 0.703648 0.70352067 0.0010468244 Difference at 99.5% confidence -0.0674757 +/- 0.0113792 -8.75175% +/- 1.47591% (Student's t, pooled s = 0.00194294) % 3 0.697971 0.698314 0.698071 0.69811867 0.00017639822 Difference at 99.5% confidence -0.0728777 +/- 0.0105464 -9.4524% +/- 1.36789% (Student's t, pooled s = 0.00180073) # 3 0.711962 0.715883 0.712118 0.713321 0.0022201277 Difference at 99.5% confidence -0.0576753 +/- 0.0139724 -7.48062% +/- 1.81225% (Student's t, pooled s = 0.0023857) > > #1. Read 32 bytes with manual pre-read in each loop: > > > > $ cc main.c -D_32BYTES_WITH_PRE_READ > > $ for i in `seq 3`; do ./a.out; done > > 0.768854 > > 0.770332 > > 0.773803 > > > > #2. Read 64 bytes with manual pre-read in each loop: > > > > $ cc main.c -D_64BYTES_WITH_PRE_READ > > $ for i in `seq 3`; do ./a.out; done > > 0.702416 > > 0.703648 > > 0.704498 > > > > #3. Read 32 bytes without manual prefetch in each loop: > > > > $ cc main.c -D_32BYTES_WITHOUT_MANUAL_PREFETCH > > $ for i in `seq 3`; do ./a.out; done > > 0.726651 > > 0.728841 > > 0.725956 > > > > #4. Read 64 bytes without manual prefetch in each loop: > > > > $ cc main.c -D_64BYTES_WITHOUT_MANUAL_PREFETCH > > $ for i in `seq 3`; do ./a.out; done > > 0.698071 > > 0.697971 > > 0.698314 > > > > #5. Read 64 bytes with PREFETCH instruction: > > > > $ cc main.c -D_64BYTES_WITH_PREFETCH_INSTRUCTION > > $ for i in `seq 3`; do ./a.out; done > > 0.715883 > > 0.712118 > > 0.711962 > > > > The test is very simple. I just run the in_cksumdata() function on one > > million packets. And the result is the time spent on calculating these > > checksums. > > > > As we can see from the results, when reading 64 bytes data without manual > > prefetch operation in each loop, the speed is fastest. So, I think read > > a whole cache line in each loop is helpful. > > > > --- > > > > The computer that I run the test program on: > > > > $ dmesg | grep CPU: > > CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz (3093.03-MHz K8-class CPU) > > > > --- > > > > The test program: > > > > #include > > #include > > #include > > > > /* ------------------------------------------------------------------------ */ > > > > #define PACKET_SIZE 1500 > > #define BUFFER_SIZE ((PACKET_SIZE) << 20) > > static unsigned char buffer[BUFFER_SIZE]; > > > > /* ------------------------------------------------------------------------ */ > > > > /* > > * Checksum routine for Internet Protocol family headers > > * (Portable Alpha version). > > * > > * This routine is very heavily used in the network > > * code and should be modified for each CPU to be as fast as possible. > > */ > > > > #define ADDCARRY(x) (x > 65535 ? x -= 65535 : x) > > #define REDUCE32 \ > > { \ > > q_util.q = sum; \ > > sum = q_util.s[0] + q_util.s[1] + q_util.s[2] + q_util.s[3]; \ > > } > > #define REDUCE16 \ > > { \ > > q_util.q = sum; \ > > l_util.l = q_util.s[0] + q_util.s[1] + q_util.s[2] + q_util.s[3]; \ > > sum = l_util.s[0] + l_util.s[1]; \ > > ADDCARRY(sum); \ > > } > > > > static const u_int32_t in_masks[] = { > > /*0 bytes*/ /*1 byte*/ /*2 bytes*/ /*3 bytes*/ > > 0x00000000, 0x000000FF, 0x0000FFFF, 0x00FFFFFF, /* offset 0 */ > > 0x00000000, 0x0000FF00, 0x00FFFF00, 0xFFFFFF00, /* offset 1 */ > > 0x00000000, 0x00FF0000, 0xFFFF0000, 0xFFFF0000, /* offset 2 */ > > 0x00000000, 0xFF000000, 0xFF000000, 0xFF000000, /* offset 3 */ > > }; > > > > union l_util { > > u_int16_t s[2]; > > u_int32_t l; > > }; > > union q_util { > > u_int16_t s[4]; > > u_int32_t l[2]; > > u_int64_t q; > > }; > > > > /* ------------------------------------------------------------------------ */ > > > > //#define _32BYTES_WITH_PRE_READ > > //#define _64BYTES_WITH_PRE_READ > > //#define _32BYTES_WITHOUT_MANUAL_PREFETCH > > //#define _64BYTES_WITHOUT_MANUAL_PREFETCH > > //#define _64BYTES_WITH_PREFETCH_INSTRUCTION > > > > #ifdef _32BYTES_WITH_PRE_READ > > static u_int64_t > > in_cksumdata(const void *buf, int len) > > { > > const u_int32_t *lw = (const u_int32_t *) buf; > > u_int64_t sum = 0; > > u_int64_t prefilled; > > int offset; > > union q_util q_util; > > > > if ((3 & (long) lw) == 0 && len == 20) { > > sum = (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3] + lw[4]; > > REDUCE32; > > return sum; > > } > > > > if ((offset = 3 & (long) lw) != 0) { > > const u_int32_t *masks = in_masks + (offset << 2); > > lw = (u_int32_t *) (((long) lw) - offset); > > sum = *lw++ & masks[len >= 3 ? 3 : len]; > > len -= 4 - offset; > > if (len <= 0) { > > REDUCE32; > > return sum; > > } > > } > > #if 0 > > /* > > * Force to cache line boundary. > > */ > > offset = 32 - (0x1f & (long) lw); > > if (offset < 32 && len > offset) { > > len -= offset; > > if (4 & offset) { > > sum += (u_int64_t) lw[0]; > > lw += 1; > > } > > if (8 & offset) { > > sum += (u_int64_t) lw[0] + lw[1]; > > lw += 2; > > } > > if (16 & offset) { > > sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; > > lw += 4; > > } > > } > > #endif > > /* > > * access prefilling to start load of next cache line. > > * then add current cache line > > * save result of prefilling for loop iteration. > > */ > > prefilled = lw[0]; > > while ((len -= 32) >= 4) { > > u_int64_t prefilling = lw[8]; > > sum += prefilled + lw[1] + lw[2] + lw[3] > > + lw[4] + lw[5] + lw[6] + lw[7]; > > lw += 8; > > prefilled = prefilling; > > } > > if (len >= 0) { > > sum += prefilled + lw[1] + lw[2] + lw[3] > > + lw[4] + lw[5] + lw[6] + lw[7]; > > lw += 8; > > } else { > > len += 32; > > } > > while ((len -= 16) >= 0) { > > sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; > > lw += 4; > > } > > len += 16; > > while ((len -= 4) >= 0) { > > sum += (u_int64_t) *lw++; > > } > > len += 4; > > if (len > 0) > > sum += (u_int64_t) (in_masks[len] & *lw); > > REDUCE32; > > return sum; > > } > > #endif > > > > #ifdef _64BYTES_WITH_PRE_READ > > static u_int64_t > > in_cksumdata(const void *buf, int len) > > { > > const u_int32_t *lw = (const u_int32_t *) buf; > > u_int64_t sum = 0; > > u_int64_t prefilled; > > int offset; > > union q_util q_util; > > > > if ((3 & (long) lw) == 0 && len == 20) { > > sum = (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3] + lw[4]; > > REDUCE32; > > return sum; > > } > > > > if ((offset = 3 & (long) lw) != 0) { > > const u_int32_t *masks = in_masks + (offset << 2); > > lw = (u_int32_t *) (((long) lw) - offset); > > sum = *lw++ & masks[len >= 3 ? 3 : len]; > > len -= 4 - offset; > > if (len <= 0) { > > REDUCE32; > > return sum; > > } > > } > > #if 0 > > /* > > * Force to cache line boundary. > > */ > > offset = 32 - (0x1f & (long) lw); > > if (offset < 32 && len > offset) { > > len -= offset; > > if (4 & offset) { > > sum += (u_int64_t) lw[0]; > > lw += 1; > > } > > if (8 & offset) { > > sum += (u_int64_t) lw[0] + lw[1]; > > lw += 2; > > } > > if (16 & offset) { > > sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; > > lw += 4; > > } > > } > > #endif > > /* > > * access prefilling to start load of next cache line. > > * then add current cache line > > * save result of prefilling for loop iteration. > > */ > > prefilled = lw[0]; > > while ((len -= 64) >= 4) { > > u_int64_t prefilling = lw[16]; > > sum += prefilled + lw[1] + lw[2] + lw[3] > > + lw[4] + lw[5] + lw[6] + lw[7] > > + lw[8] + lw[9] + lw[10] + lw[11] > > + lw[12] + lw[13] + lw[14] + lw[15]; > > lw += 16; > > prefilled = prefilling; > > } > > if (len >= 0) { > > sum += prefilled + lw[1] + lw[2] + lw[3] > > + lw[4] + lw[5] + lw[6] + lw[7] > > + lw[8] + lw[9] + lw[10] + lw[11] > > + lw[12] + lw[13] + lw[14] + lw[15]; > > lw += 16; > > } else { > > len += 64; > > } > > while ((len -= 16) >= 0) { > > sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; > > lw += 4; > > } > > len += 16; > > while ((len -= 4) >= 0) { > > sum += (u_int64_t) *lw++; > > } > > len += 4; > > if (len > 0) > > sum += (u_int64_t) (in_masks[len] & *lw); > > REDUCE32; > > return sum; > > } > > #endif > > > > #ifdef _32BYTES_WITHOUT_MANUAL_PREFETCH > > static u_int64_t > > in_cksumdata(const void *buf, int len) > > { > > const u_int32_t *lw = (const u_int32_t *) buf; > > u_int64_t sum = 0; > > int offset; > > union q_util q_util; > > > > if ((3 & (long) lw) == 0 && len == 20) { > > sum = (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3] + lw[4]; > > REDUCE32; > > return sum; > > } > > > > if ((offset = 3 & (long) lw) != 0) { > > const u_int32_t *masks = in_masks + (offset << 2); > > lw = (u_int32_t *) (((long) lw) - offset); > > sum = *lw++ & masks[len >= 3 ? 3 : len]; > > len -= 4 - offset; > > if (len <= 0) { > > REDUCE32; > > return sum; > > } > > } > > #if 0 > > /* > > * Force to cache line boundary. > > */ > > offset = 32 - (0x1f & (long) lw); > > if (offset < 32 && len > offset) { > > len -= offset; > > if (4 & offset) { > > sum += (u_int64_t) lw[0]; > > lw += 1; > > } > > if (8 & offset) { > > sum += (u_int64_t) lw[0] + lw[1]; > > lw += 2; > > } > > if (16 & offset) { > > sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; > > lw += 4; > > } > > } > > #endif > > /* > > * access prefilling to start load of next cache line. > > * then add current cache line > > * save result of prefilling for loop iteration. > > */ > > while ((len -= 32) >= 4) { > > sum += lw[0] + lw[1] + lw[2] + lw[3] > > + lw[4] + lw[5] + lw[6] + lw[7]; > > lw += 8; > > } > > if (len >= 0) { > > sum += lw[0] + lw[1] + lw[2] + lw[3] > > + lw[4] + lw[5] + lw[6] + lw[7]; > > lw += 8; > > } else { > > len += 32; > > } > > while ((len -= 16) >= 0) { > > sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; > > lw += 4; > > } > > len += 16; > > while ((len -= 4) >= 0) { > > sum += (u_int64_t) *lw++; > > } > > len += 4; > > if (len > 0) > > sum += (u_int64_t) (in_masks[len] & *lw); > > REDUCE32; > > return sum; > > } > > #endif > > > > #ifdef _64BYTES_WITHOUT_MANUAL_PREFETCH > > static u_int64_t > > in_cksumdata(const void *buf, int len) > > { > > const u_int32_t *lw = (const u_int32_t *) buf; > > u_int64_t sum = 0; > > int offset; > > union q_util q_util; > > > > if ((3 & (long) lw) == 0 && len == 20) { > > sum = (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3] + lw[4]; > > REDUCE32; > > return sum; > > } > > > > if ((offset = 3 & (long) lw) != 0) { > > const u_int32_t *masks = in_masks + (offset << 2); > > lw = (u_int32_t *) (((long) lw) - offset); > > sum = *lw++ & masks[len >= 3 ? 3 : len]; > > len -= 4 - offset; > > if (len <= 0) { > > REDUCE32; > > return sum; > > } > > } > > #if 0 > > /* > > * Force to cache line boundary. > > */ > > offset = 32 - (0x1f & (long) lw); > > if (offset < 32 && len > offset) { > > len -= offset; > > if (4 & offset) { > > sum += (u_int64_t) lw[0]; > > lw += 1; > > } > > if (8 & offset) { > > sum += (u_int64_t) lw[0] + lw[1]; > > lw += 2; > > } > > if (16 & offset) { > > sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; > > lw += 4; > > } > > } > > #endif > > /* > > * access prefilling to start load of next cache line. > > * then add current cache line > > * save result of prefilling for loop iteration. > > */ > > while ((len -= 64) >= 4) { > > sum += lw[0] + lw[1] + lw[2] + lw[3] > > + lw[4] + lw[5] + lw[6] + lw[7] > > + lw[8] + lw[9] + lw[10] + lw[11] > > + lw[12] + lw[13] + lw[14] + lw[15]; > > lw += 16; > > } > > if (len >= 0) { > > sum += lw[0] + lw[1] + lw[2] + lw[3] > > + lw[4] + lw[5] + lw[6] + lw[7] > > + lw[8] + lw[9] + lw[10] + lw[11] > > + lw[12] + lw[13] + lw[14] + lw[15]; > > lw += 16; > > } else { > > len += 64; > > } > > while ((len -= 16) >= 0) { > > sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; > > lw += 4; > > } > > len += 16; > > while ((len -= 4) >= 0) { > > sum += (u_int64_t) *lw++; > > } > > len += 4; > > if (len > 0) > > sum += (u_int64_t) (in_masks[len] & *lw); > > REDUCE32; > > return sum; > > } > > #endif > > > > #ifdef _64BYTES_WITH_PREFETCH_INSTRUCTION > > static u_int64_t > > in_cksumdata(const void *buf, int len) > > { > > const u_int32_t *lw = (const u_int32_t *) buf; > > u_int64_t sum = 0; > > int offset; > > union q_util q_util; > > > > if ((3 & (long) lw) == 0 && len == 20) { > > sum = (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3] + lw[4]; > > REDUCE32; > > return sum; > > } > > > > if ((offset = 3 & (long) lw) != 0) { > > const u_int32_t *masks = in_masks + (offset << 2); > > lw = (u_int32_t *) (((long) lw) - offset); > > sum = *lw++ & masks[len >= 3 ? 3 : len]; > > len -= 4 - offset; > > if (len <= 0) { > > REDUCE32; > > return sum; > > } > > } > > #if 0 > > /* > > * Force to cache line boundary. > > */ > > offset = 32 - (0x1f & (long) lw); > > if (offset < 32 && len > offset) { > > len -= offset; > > if (4 & offset) { > > sum += (u_int64_t) lw[0]; > > lw += 1; > > } > > if (8 & offset) { > > sum += (u_int64_t) lw[0] + lw[1]; > > lw += 2; > > } > > if (16 & offset) { > > sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; > > lw += 4; > > } > > } > > #endif > > /* > > * access prefilling to start load of next cache line. > > * then add current cache line > > * save result of prefilling for loop iteration. > > */ > > __builtin_prefetch(&lw[0]); > > while ((len -= 64) >= 4) { > > __builtin_prefetch(&lw[16]); > > sum += lw[0] + lw[1] + lw[2] + lw[3] > > + lw[4] + lw[5] + lw[6] + lw[7] > > + lw[8] + lw[9] + lw[10] + lw[11] > > + lw[12] + lw[13] + lw[14] + lw[15]; > > lw += 16; > > } > > if (len >= 0) { > > sum += lw[0] + lw[1] + lw[2] + lw[3] > > + lw[4] + lw[5] + lw[6] + lw[7] > > + lw[8] + lw[9] + lw[10] + lw[11] > > + lw[12] + lw[13] + lw[14] + lw[15]; > > lw += 16; > > } else { > > len += 64; > > } > > while ((len -= 16) >= 0) { > > sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; > > lw += 4; > > } > > len += 16; > > while ((len -= 4) >= 0) { > > sum += (u_int64_t) *lw++; > > } > > len += 4; > > if (len > 0) > > sum += (u_int64_t) (in_masks[len] & *lw); > > REDUCE32; > > return sum; > > } > > #endif > > > > /* ------------------------------------------------------------------------ */ > > > > int main(void) > > { > > int i; > > int sum; > > struct timeval tv1, tv2, res; > > > > gettimeofday(&tv1, NULL); > > for (i = 0; i < BUFFER_SIZE; i += PACKET_SIZE) > > sum = in_cksumdata(&buffer[i], PACKET_SIZE); > > gettimeofday(&tv2, NULL); > > > > timersub(&tv2, &tv1, &res); > > printf("%ld.%6ld\n", res.tv_sec, res.tv_usec); > > > > return (0); > > } > > From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 20 14:31:16 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0A86A66; Mon, 20 Oct 2014 14:31:16 +0000 (UTC) Received: from mail-out.m-online.net (mail-out.m-online.net [IPv6:2001:a60:0:28:0:1:25:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ADEA8A; Mon, 20 Oct 2014 14:31:16 +0000 (UTC) Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 3jM0ky1D0Yz3hk3Q; Mon, 20 Oct 2014 16:31:06 +0200 (CEST) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) by mail.mnet-online.de (Postfix) with ESMTP id 3jM0kx6wghzvlwR; Mon, 20 Oct 2014 16:31:05 +0200 (CEST) Received: by mail.embedded-brains.de (Postfix, from userid 65534) id 330FA652CFC; Mon, 20 Oct 2014 16:31:03 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fidibusdmz X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from [192.168.100.11] (unknown [192.168.100.11]) by mail.embedded-brains.de (Postfix) with ESMTP id E77FB652443; Mon, 20 Oct 2014 16:31:01 +0200 (CEST) Message-ID: <54451CA5.8080501@embedded-brains.de> Date: Mon, 20 Oct 2014 16:31:01 +0200 From: Sebastian Huber User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Jeremie Le Hen , freebsd-hackers@FreeBSD.org Subject: Re: struct bintime References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 14:31:17 -0000 Hello Jeremie, you find a very good document about the FreeBSD timecounters here: http://phk.freebsd.dk/pubs/timecounter.pdf -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 21 12:31:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11FC05C1; Tue, 21 Oct 2014 12:31:12 +0000 (UTC) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5AA11694; Tue, 21 Oct 2014 12:31:10 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id s9LCUvqI001517; Tue, 21 Oct 2014 14:30:59 +0200 (CEST) (envelope-from wojtek@puchar.net) Date: Tue, 21 Oct 2014 14:30:54 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop To: Henry Hu Subject: Re: help with backlight control and memory In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Tue, 21 Oct 2014 14:31:00 +0200 (CEST) Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 12:31:12 -0000 no error, no effect On Sat, 18 Oct 2014, Henry Hu wrote: > > > On Sat, Oct 18, 2014 at 5:03 PM, Wojciech Puchar wrote: > tried. jsut after kernel is loaded backlight control keys stops working. > tried loading every acpi_* kernel module that is available, with no results > >  Does it work if you set hw.acpi.video.lcd0.brightness directly? > > On Thu, 16 Oct 2014, Adrian Chadd wrote: > > Hi! > > Please try the latest FreeBSD-11 snapshot and see if it still works > once you've started Xorg. > > > -a > > > On 16 October 2014 05:19, Wojciech Puchar wrote: > bought new laptop. it's lenovo B590 > > most things works fine. but brightness control keys doesn't work after > FreeBSD is loaded. they work before it. > > i don't ask for a solution but any point to start. What should i check? > > is it ACPI tables problem (kernel shows some errors). > > Other question - can amount of memory dedicated to GFX card be changed? > There is no option in BIOS setup to do this. and i have lots of memory > wasted as you may see below. > > > > Copyright (c) 1992-2014 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >         The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 10.1-BETA1 #4: Wed Oct 15 23:56:56 CEST 2014 >     root@laptop:/usr/src/sys/amd64/compile/laptop amd64 > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 > CPU: Intel(R) Celeron(R) CPU 1005M @ 1.90GHz (1895.73-MHz K8-class CPU) >   Origin = "GenuineIntel"  Id = 0x306a9  Family = 0x6  Model = 0x3a > Stepping = 9 > > Features=0xbfebfbff TT,TM,PBE> > > Features2=0xdbae3bf ,OSXSAVE> >   AMD Features=0x28100800 >   AMD Features2=0x1 >   Structured Extended Features=0x281 >   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID >   TSC: P-state invariant, performance statistics > real memory  = 2147483648 (2048 MB) > avail memory = 1585037312 (1511 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) >  cpu0 (BSP): APIC ID:  0 >  cpu1 (AP): APIC ID:  2 > ioapic0 irqs 0-23 on motherboard > random: initialized > iscsi: version 2.3.1 > kbd1 at kbdmux0 > cryptosoft0: on motherboard > acpi0: on motherboard > ACPI Error: No handler for Region [ECOR] (0xfffff80001710400) > [EmbeddedControl] (20130823/evregion-178) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20130823/exfldio-320) > ACPI Error: Method parse/execution failed [\134_SB_.PCI0.LPCB.H_EC._REG] > (Node 0xfffff8000171e200), AE_NOT_EXIST (20130823/psparse-553) > acpi0: Power Button (fixed) > cpu0: on acpi0 > cpu1: on acpi0 > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 950 > Event timer "HPET" frequency 14318180 Hz quality 550 > Event timer "HPET1" frequency 14318180 Hz quality 440 > Event timer "HPET2" frequency 14318180 Hz quality 440 > Event timer "HPET3" frequency 14318180 Hz quality 440 > Event timer "HPET4" frequency 14318180 Hz quality 440 > Event timer "HPET5" frequency 14318180 Hz quality 440 > Event timer "HPET6" frequency 14318180 Hz quality 440 > atrtc0: port 0x70-0x77 irq 8 on acpi0 > atrtc0: Warning: Couldn't map I/O. > Event timer "RTC" frequency 32768 Hz quality 0 > attimer0: port 0x40-0x43,0x50-0x53 irq 0 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 0x408-0x40b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > vgapci0: port 0x3000-0x303f mem > 0x90000000-0x903fffff,0x80000000-0x8fffffff irq 16 at device 2.0 on pci0 > agp0: on vgapci0 > agp0: aperture size is 256M, detected 32764k stolen memory > vgapci0: Boot video device > xhci0: mem 0x90600000-0x9060ffff > irq 21 at device 20.0 on pci0 > xhci0: 32 byte context size. > xhci0: Port routing mask set to 0xffffffff > usbus0 on xhci0 > pci0: at device 22.0 (no driver attached) > ehci0: mem 0x9061a000-0x9061a3ff > irq 16 at device 26.0 on pci0 > usbus1: EHCI version 1.0 > usbus1 on ehci0 > hdac0: mem 0x90610000-0x90613fff irq 22 > at device 27.0 on pci0 > pcib1: irq 16 at device 28.0 on pci0 > pci1: on pcib1 > pcib2: irq 17 at device 28.1 on pci0 > pci2: on pcib2 > pci2: at device 0.0 (no driver attached) > pcib3: irq 19 at device 28.3 on pci0 > pci3: on pcib3 > re0: port > 0x2000-0x20ff mem 0x90404000-0x90404fff,0x90400000-0x90403fff irq 19 at > device 0.0 on pci3 > re0: Using 1 MSI-X message > re0: ASPM disabled > re0: Chip rev. 0x2c800000 > re0: MAC rev. 0x00100000 > miibus0: on re0 > ukphy0: PHY 1 on miibus0 > ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > re0: Ethernet address: 54:ee:75:13:f2:6b > ehci1: mem 0x90619000-0x906193ff > irq 23 at device 29.0 on pci0 > usbus2: EHCI version 1.0 > usbus2 on ehci1 > isab0: at device 31.0 on pci0 > isa0: on isab0 > ahci0: port > 0x3088-0x308f,0x3094-0x3097,0x3080-0x3087,0x3090-0x3093,0x3060-0x307f mem > 0x90618000-0x906187ff irq 19 at device 31.2 on pci0 > ahci0: AHCI v1.30 with 4 6Gbps ports, Port Multiplier not supported > ahcich0: at channel 0 on ahci0 > ahcich4: at channel 4 on ahci0 > ahciem0: on ahci0 > acpi_acad0: on acpi0 > acpi_lid0: on acpi0 > acpi_button0: on acpi0 > acpi_tz0: on acpi0 > acpi_tz1: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model Generic PS/2 mouse, device ID 0 > battery0: on acpi0 > acpi_ibm0: on acpi0 > orm0: at iomem 0xc0000-0xcefff 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 > est0: on cpu0 > p4tcc0: on cpu0 > est1: on cpu1 > p4tcc1: on cpu1 > fuse-freebsd: version 0.4.4, FUSE ABI 7.8 > Timecounters tick every 1.000 msec > ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to accept, > logging disabled > DUMMYNET 0 with IPv6 initialized (100409) > load_dn_sched dn_sched RR loaded > load_dn_sched dn_sched WF2Q+ loaded > load_dn_sched dn_sched FIFO loaded > load_dn_sched dn_sched PRIO loaded > load_dn_sched dn_sched QFQ loaded > hdacc0: at cad 0 on hdac0 > hdaa0: at nid 1 on hdacc0 > pcm0: at nid 20,21 and 24,25 on hdaa0 > hdacc1: at cad 3 on hdac0 > hdaa1: at nid 1 on hdacc1 > pcm1: at nid 5 on hdaa1 > random: unblocking device. > usbus0: 5.0Gbps Super Speed USB v3.0 > usbus1: 480Mbps High Speed USB v2.0 > usbus2: 480Mbps High Speed USB v2.0 > ACPI Error: No handler for Region [ECRM] (0xfffff800017dd180) > [EmbeddedControl] (20130823/evregion-178) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20130823/exfldio-320) > ACPI Error: Method parse/execution failed [\134_TZ_.MDEC] (Node > 0xfffff80001725b40), AE_NOT_EXIST (20130823/psparse-553) > ACPI Error: Method parse/execution failed [\134_TZ_.TZS0._SCP] (Node > 0xfffff80001725a40), AE_NOT_EXIST (20130823/psparse-553) > ugen2.1: at usbus2 > uhub0: on usbus2 > ugen1.1: at usbus1 > ugen0.1: <0x8086> at usbus0 > uhub1: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 > uhub2: on usbus1 > ses0 at ahciem0 bus 0 scbus2 target 0 lun 0 > ses0: SEMB S-E-S 2.00 device > ses0: SEMB SES Device > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-8 SATA 2.x device > ada0: Serial Number WD-WXL1EB3KUNR5 > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > cd0 at ahcich4 bus 0 scbus1 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device cd0: Serial > Number KW9E4571958 > cd0: 150.000MB/s transfers (SATA 1.x, UDMA2, ATAPI 12bytes, PIO 8192bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not present - > tray closed > ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada0: quirks=0x1<4K> > ada0: Previously was known as ad0 > Enter passphrase for ada0d: SMP: AP CPU #1 Launched! > hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 > IAP/8/48/0x3ff > IAF/3/48/0x67 > Timecounter "TSC" frequency 1895731156 Hz quality 1000 > uhub1: 8 ports with 8 removable, self powered > uhub0: 3 ports with 3 removable, self powered > uhub2: 3 ports with 3 removable, self powered > ugen2.2: at usbus2 > uhub3: on > usbus2 > ugen1.2: at usbus1 > uhub4: on > usbus1 > uhub3: 4 ports with 4 removable, self powered > uhub4: 4 ports with 4 removable, self powered > ugen1.3: at usbus1 > ugen1.4: at usbus1 > umass0: > on usbus1 > da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device da0: > Serial Number 058F63666435 > da0: 40.000MB/s transfers > da0: Attempt to query device size failed: NOT READY, Medium not present > da0: quirks=0x2 > ugen1.5: at usbus1 > GEOM_ELI: Device ada0d.eli created. > GEOM_ELI: Encryption: AES-CBC 128 > GEOM_ELI:     Crypto: software > Trying to mount root from ufs:ada0d.eli []... > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > > > -- > Cheers, > Henry > > From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 21 12:31:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00C276A5; Tue, 21 Oct 2014 12:31:57 +0000 (UTC) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 662666B0; Tue, 21 Oct 2014 12:31:57 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id s9LCVsTp001623; Tue, 21 Oct 2014 14:31:55 +0200 (CEST) (envelope-from wojtek@puchar.net) Date: Tue, 21 Oct 2014 14:31:51 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop To: Adrian Chadd Subject: Re: help with backlight control and memory In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Tue, 21 Oct 2014 14:31:55 +0200 (CEST) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 12:31:58 -0000 > Ok, does the sysctl work? i can read and set, but there is no actual effect. > > You have to have drm2 and i915kms loaded before it'll all plumb > together correctly. > all loaded and Xorg running fine From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 21 12:33:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9AE617A7; Tue, 21 Oct 2014 12:33:51 +0000 (UTC) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 230EF6C8; Tue, 21 Oct 2014 12:33:50 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id s9LCXcbG001744; Tue, 21 Oct 2014 14:33:40 +0200 (CEST) (envelope-from wojtek@puchar.net) Date: Tue, 21 Oct 2014 14:33:34 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop To: Adrian Chadd Subject: Re: help with backlight control and memory In-Reply-To: Message-ID: References: <20141019102848.GR72082@e-new.0x20.net> <86d29ot9dg.fsf@aguiar.info> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Tue, 21 Oct 2014 14:33:40 +0200 (CEST) Cc: "freebsd-hackers@freebsd.org" , Renato Aguiar , Lars Engels X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 12:33:51 -0000 OK so for now i will just keep it as is. it's not really a big deal On Sun, 19 Oct 2014, Adrian Chadd wrote: > Is this running the latest -HEAD? > > Yes, some extra code was glued into the i915kms / drm2 code from Linux > that correctly selected the right video output device for the > brightness controls. (the opcontrol patch that I committed a couple > months back.) > > The buttons don't work on my X series laptop, but the sysctl does. the > buttons work for others on other X series laptops. It's likely some > more ACPI and i915kms things need porting. > > > > -a > > > On 19 October 2014 07:34, Renato Aguiar wrote: >> Hi Lars, >> >> On my X230 I only can change brightness calling acpi directly using >> acpi_call. Did you make some additional configuration to be able to use >> sysctl to control brightness? >> >> Thanks, >> >> Lars Engels writes: >> >>> On Sat, Oct 18, 2014 at 11:03:38PM +0200, Wojciech Puchar wrote: >>>> tried. jsut after kernel is loaded backlight control keys stops working. >>>> tried loading every acpi_* kernel module that is available, with no >>>> results >>> >>> On my X230 running HEAD brightness keys only work when acpi_video.ko is >>> _not_ loaded. When it is loaded, I can control brightness with sysctl, >>> though. >> >> -- >> Renato Aguiar > > From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 21 14:52:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 371FC8AA for ; Tue, 21 Oct 2014 14:52:12 +0000 (UTC) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BBB7591A for ; Tue, 21 Oct 2014 14:52:10 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBDB4C.dip0.t-ipconnect.de [93.203.219.76]) (authenticated bits=128) by land.berklix.org (8.14.5/8.14.5) with ESMTP id s9LEmbD1056672 for ; Tue, 21 Oct 2014 14:48:40 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id s9LEpnSF046695 for ; Tue, 21 Oct 2014 16:51:50 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id s9LEpbEc023384 for ; Tue, 21 Oct 2014 16:51:49 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <201410211451.s9LEpbEc023384@fire.js.berklix.net> To: freebsd-hackers@freebsd.org Subject: DOC obstructs encryption export again - Non USA crypto base again ? From: "Julian H. Stacey" Organization: http://berklix.com BSD Linux Unix Consultants, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com/~jhs/cv/ Date: Tue, 21 Oct 2014 16:51:37 +0200 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 14:52:12 -0000 How can FreeBSD best re-segregate crypto components of its repository again, ready to move crypto components outside the USA, as USA DOC imperils again ? FreeBSD is now SVN based, we were CVS last time, Any new issues to solve ? Can smooth transition be planned before, in case of risk of USA DOC action ? Last time FreeBSD used South Africa; if that's not viable, FreeBSD based servers elsewhere are available (including in .EU). http://www.theregister.co.uk/2014/10/17/intel_subsidiary_crypto_export_fine/ "US government fines Intel's Wind River over crypto exports" "Now, as Techdirt notes, the conflict between government regulation and the tech industry is moving onto the renal original turf of the first crypto wars of the late 90s - the export of strong encryption." https://www.techdirt.com/articles/20141015/13561128840/first-commerce-department-fines-intel-subsidiary-exporting-encryption.shtml "For those who lived through the late 90's cryptowars, it's beginning to feel like history is repeating itself." http://lists.gnupg.org/pipermail/gnupg-users/2014-October/051131.html "maybe the decision to keep GnuPG infrastructure out of the US - even after the lifting of the export restrictions - was not too bad." USA Dept. of Commerce were obstructive idiots even back in the early 1980s: (DOC obstructed delivery of Unix systems with crypt binary (not source), though British Unix source licencees, associates, & even the communist East were all in possesion of crypt.c source With raised world tensions on many fronts, DOC crypto export obstruction will presumably increase, with NSA encouraging DOC. A non USA base for crypto parts of the FreeBSD repository would again safeguard the world FreeBSD community from the whims of the USA DOC, & remove or reduce risk of USA prosecution of USA FreeBSD administrators & cryptographic developers. Cheers, Julian -- Julian Stacey, BSD Linux Unix'78 C Sys Eng Consultant Munich http://berklix.com Indent previous with "> ". Interleave reply paragraphs like a play script. Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 21 15:12:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB221BAA for ; Tue, 21 Oct 2014 15:12:04 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 72BA0B17 for ; Tue, 21 Oct 2014 15:12:04 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s9LFBwnx056171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2014 18:11:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s9LFBwnx056171 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s9LFBviN056170; Tue, 21 Oct 2014 18:11:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 21 Oct 2014 18:11:57 +0300 From: Konstantin Belousov To: Adam Nowacki Subject: Re: panic in ivy_rng_store() when compiled with -O0 Message-ID: <20141021151157.GC1877@kib.kiev.ua> References: <54384ABD.5080806@FreeBSD.org> <2533199.DHZybpy49d@ralph.baldwin.cx> <54415E13.4000203@delphij.net> <7A5C3D84-1B1F-4BA3-818D-37231BF424FE@FreeBSD.org> <5443B2D4.3020407@platinum.linux.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5443B2D4.3020407@platinum.linux.pl> User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 15:12:05 -0000 On Sun, Oct 19, 2014 at 02:47:16PM +0200, Adam Nowacki wrote: > On 2014-10-17 20:33, Dimitry Andric wrote: > > On 17 Oct 2014, at 20:21, Xin Li wrote: > >> On 10/17/14 08:53, John Baldwin wrote: > >>> On Friday, October 10, 2014 02:08:13 PM Navdeep Parhar wrote: > > ... > >> movq %rdi,(%rdi) is obviously wrong (%rdi holds the result from > >> rdrand), which I believed to be a compiler bug in register allocation. > >> > >> Navdeep have committed a change to mark 'tmp' input+output, which does > >> fix the output but I'm not 100% sure if that's right, as 'tmp' is not > >> considered an input of the inline assembler block, and this may break > >> compile on other compilers, but for now it's better than previous > >> situation. > >> > >> Speaking for the compiler issue, Dimitry have reported this upstream at: > >> > >> http://llvm.org/bugs/show_bug.cgi?id=21273 > >> > >> There is a suggestion in the reply, that change 'tmp' to early clobber > >> would workaround the issue, like: > >> > >> Index: ivy.c > >> =================================================================== > >> - --- ivy.c (revision 273195) > >> +++ ivy.c (working copy) > >> @@ -79,7 +79,7 @@ > >> "2:\n\t" > >> "mov %2,%1\n\t" /* *buf = tmp */ > >> "3:" > >> - - : "+q" (retry), "=m" (*buf), "+q" (tmp) : : "cc"); > >> + : "+q" (retry), "=m" (*buf), "=&q" (tmp) : : "cc"); > > > > Yes, this generates the correct code for all cases I tried, e.g. with > > gcc 4.2 from base, gcc 4.7 through 5.0 from ports, clang 3.4, clang 3.5 > > and clang trunk, all at -O0 through -O3, and -Os. > > > > So at the moment this fix is the best option, I think. > > GCC documentation explains what happens: > "The same problem can occur if one output parameter (a) allows a > register constraint and another output parameter (b) allows a memory > constraint. The code generated by GCC to access the memory address in b > can contain registers which might be shared by a, and GCC considers > those registers to be inputs to the asm. As above, GCC assumes that such > input registers are consumed before any outputs are written. This > assumption may result in incorrect behavior if the asm writes to a > before using b. Combining the `&' constraint with the register > constraint ensures that modifying a will not affect what address is > referenced by b. Omitting the `&' constraint means that the location of > b will be undefined if a is modified before using b. " > > Both tmp and retry need the '&' constraint. > > : "+&q" (retry), "=m" (*buf), "=&q" (tmp) : : "cc"); The inline asm documentation was extensively rewritten for gcc 5.0, it seems. Thank you for the pointer, indeed, the situation in ivy_rng_store() exactly matches the paragraph you cite. Should the '&' modifier be applied for register output operands only ? In particular, I wonder if *buf operand should be fixed the same way. The gcc doc does not say explicitely which operand, (a) or (b), should be marked as earlyclobber at all. diff --git a/sys/dev/random/ivy.c b/sys/dev/random/ivy.c index 23fd542..9fbfbf0 100644 --- a/sys/dev/random/ivy.c +++ b/sys/dev/random/ivy.c @@ -79,7 +80,7 @@ ivy_rng_store(long *buf) "2:\n\t" "mov %2,%1\n\t" /* *buf = tmp */ "3:" - : "+q" (retry), "=m" (*buf), "+q" (tmp) : : "cc"); + : "+&q" (retry), "=&m" (*buf), "=&q" (tmp) : : "cc"); return (retry); #else /* __GNUCLIKE_ASM */ return (0); From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 21 15:38:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9F7C3FC for ; Tue, 21 Oct 2014 15:38:37 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 9F51EDB5 for ; Tue, 21 Oct 2014 15:38:37 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id D76673BD23; Tue, 21 Oct 2014 15:38:29 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id s9LFcS5A044624; Tue, 21 Oct 2014 15:38:29 GMT (envelope-from phk@phk.freebsd.dk) To: "Julian H. Stacey" Subject: Re: DOC obstructs encryption export again - Non USA crypto base again ? In-reply-to: <201410211451.s9LEpbEc023384@fire.js.berklix.net> From: "Poul-Henning Kamp" References: <201410211451.s9LEpbEc023384@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <44622.1413905908.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Oct 2014 15:38:28 +0000 Message-ID: <44623.1413905908@critter.freebsd.dk> X-Mailman-Approved-At: Tue, 21 Oct 2014 16:28:22 +0000 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 15:38:37 -0000 -------- In message <201410211451.s9LEpbEc023384@fire.js.berklix.net>, "Julian H. S= tacey " writes: >How can FreeBSD best re-segregate crypto components of its repository aga= in, >ready to move crypto components outside the USA, as USA DOC imperils agai= n ? >[...] > http://www.theregister.co.uk/2014/10/17/intel_subsidiary_crypto_export_= fine/ > "US government fines Intel's Wind River over crypto exports" As far as I have been able to uncover, this settlement is about a commercial closed source component, using specific hardware-crypto-assist, for which no programming details have been made publically available. That means that WR cannot fly under the Wassenaar Arrangement "in the public domain" carveout, and I guess somebody there overlooked that little detail. We on the other hand make everything we do available, so we're solidly inside that carveout. For details see: bottom of page 3 "GENERAL SOFTWARE NOTE" and the definition of "in the public domain" at the bottom of page 208 in this document: http://www.wassenaar.org/controllists/2013/WA-LIST%20%2813%29%201/WA-L= IST%20%2813%29%201.pdf In other words Julian: Don't panic. Worst case, we'll move the entire svn server out of USA. -- = 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-hackers@FreeBSD.ORG Tue Oct 21 17:37:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F34623A0 for ; Tue, 21 Oct 2014 17:37:30 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 89EBBD08 for ; Tue, 21 Oct 2014 17:37:30 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id bs8so1749225wib.17 for ; Tue, 21 Oct 2014 10:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Ti+Wn4mS+ODI6arXbnK0b/ggimt9d6sMaAcIhKPf2lA=; b=ojXg41xmwB4o3+me8afPjbbdNhv0jZjHHFO2cuHhu96bzCKXB7oNG/xPaqp4m3E+4C MIFHWYLpnlgUfPq1pPzGqUWIWB3Evd9iiTtPnwu0c1tzcGnXcCkBEkSi7FZQtc+gsM0+ 83tnx/t9B3DfONSbso7uj+z1MLv7TBiju1HYQ0a2ueW2P0foQr1UJiFJIkeabvx+vf04 sZCF9dhtvGWnhUN2cC7M4pia+5Ktnh4lywBpw/Xoq3Iw9EDH1Cax5mJzU4TFy65Z7y2+ otX9QeytRBkwyrih5W2h1b/u1PTnu4edkZqX7HvRyxf2HQMf8qVxfEu9lRSPIluUUQMv O2ww== MIME-Version: 1.0 X-Received: by 10.180.11.200 with SMTP id s8mr25567735wib.20.1413913045121; Tue, 21 Oct 2014 10:37:25 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Tue, 21 Oct 2014 10:37:25 -0700 (PDT) In-Reply-To: References: <20141019102848.GR72082@e-new.0x20.net> <86d29ot9dg.fsf@aguiar.info> Date: Tue, 21 Oct 2014 10:37:25 -0700 X-Google-Sender-Auth: Ljva1x3goR72Q-SFOqqgSn70d6Q Message-ID: Subject: Re: help with backlight control and memory From: Adrian Chadd To: Wojciech Puchar Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Renato Aguiar , Lars Engels X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 17:37:31 -0000 Hi, Please file a PR then. I'm not sure who can help with it at the moment. It's likely going to require us writing some other modules that control brightness via other methods (eg directly to the GPU hardware for some chips) and then expose that via the same sysctl API. Then it has to be glued up with the button press events.. -a On 21 October 2014 05:33, Wojciech Puchar wrote: > OK so for now i will just keep it as is. it's not really a big deal > > > On Sun, 19 Oct 2014, Adrian Chadd wrote: > >> Is this running the latest -HEAD? >> >> Yes, some extra code was glued into the i915kms / drm2 code from Linux >> that correctly selected the right video output device for the >> brightness controls. (the opcontrol patch that I committed a couple >> months back.) >> >> The buttons don't work on my X series laptop, but the sysctl does. the >> buttons work for others on other X series laptops. It's likely some >> more ACPI and i915kms things need porting. >> >> >> >> -a >> >> >> On 19 October 2014 07:34, Renato Aguiar wrote: >>> >>> Hi Lars, >>> >>> On my X230 I only can change brightness calling acpi directly using >>> acpi_call. Did you make some additional configuration to be able to use >>> sysctl to control brightness? >>> >>> Thanks, >>> >>> Lars Engels writes: >>> >>>> On Sat, Oct 18, 2014 at 11:03:38PM +0200, Wojciech Puchar wrote: >>>>> >>>>> tried. jsut after kernel is loaded backlight control keys stops >>>>> working. >>>>> tried loading every acpi_* kernel module that is available, with no >>>>> results >>>> >>>> >>>> On my X230 running HEAD brightness keys only work when acpi_video.ko is >>>> _not_ loaded. When it is loaded, I can control brightness with sysctl, >>>> though. >>> >>> >>> -- >>> Renato Aguiar >> >> >> > From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 22 14:25:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F8F1271 for ; Wed, 22 Oct 2014 14:25:09 +0000 (UTC) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 29793F5A for ; Wed, 22 Oct 2014 14:25:08 +0000 (UTC) Received: from mart.js.berklix.net (pD9FBFA1C.dip0.t-ipconnect.de [217.251.250.28]) (authenticated bits=128) by land.berklix.org (8.14.5/8.14.5) with ESMTP id s9MELbvt037043; Wed, 22 Oct 2014 14:21:38 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id s9MEOpp8054456; Wed, 22 Oct 2014 16:24:51 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id s9MEOWwT000965; Wed, 22 Oct 2014 16:24:45 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <201410221424.s9MEOWwT000965@fire.js.berklix.net> To: "Poul-Henning Kamp" Subject: Re: DOC obstructs encryption export again - Non USA crypto base again ? From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Tue, 21 Oct 2014 15:38:28 -0000." <44623.1413905908@critter.freebsd.dk> Date: Wed, 22 Oct 2014 16:24:32 +0200 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 14:25:09 -0000 "Poul-Henning Kamp" wrote: > In message <201410211451.s9LEpbEc023384@fire.js.berklix.net>, "Julian H. Stacey > " writes: > > >How can FreeBSD best re-segregate crypto components of its repository again, > >ready to move crypto components outside the USA, as USA DOC imperils again ? > >[...] > > http://www.theregister.co.uk/2014/10/17/intel_subsidiary_crypto_export_fine/ > > "US government fines Intel's Wind River over crypto exports" > > As far as I have been able to uncover, this settlement is about a > commercial closed source component, using specific hardware-crypto-assist, > for which no programming details have been made publically available. > > That means that WR cannot fly under the Wassenaar Arrangement "in the > public domain" carveout, and I guess somebody there overlooked that little > detail. > > We on the other hand make everything we do available, so we're solidly > inside that carveout. > > For details see: bottom of page 3 "GENERAL SOFTWARE NOTE" and > the definition of "in the public domain" at the bottom of page 208 > in this document: > > http://www.wassenaar.org/controllists/2013/WA-LIST%20%2813%29%201/WA-LIST%20%2813%29%201.pdf Thanks for the URL Poul-Henning, For info for others: ] P.3: ] GENERAL SOFTWARE NOTE ] The Lists do not control "software" ] which is any of ] the following: ] ... ] 2. "In the public domain"; or ] ... ] P.208 ] GTN "In the public domain" ] GSN This means "technology" or "software" which has been made available ] ML 22 without restrictions upon ] its further dissemination. ] Note Copyright restrictions do not remove "technology" or "software" ] from being "in the public domain". > In other words Julian: Don't panic. > > Worst case, we'll move the entire svn server out of USA. Good, can relax a bit then, Thanks :-) PS I've since read: http://lists.gnupg.org/pipermail/gnupg-users/2014-October/051182.html > ITAR has a couple > of nice commonsense exceptions. (See, e.g., ITAR 120.10 (5): ITAR "does > not include information concerning general scientific, mathematical, or > engineering principles commonly taught in schools, colleges, and > universities or information in the public domain.") > > Unfortunately, those exceptions aren't enough to save you from really > expensive legal bills. https://en.wikipedia.org/wiki/International_Traffic_in_Arms_Regulations Shows ITAR as USA national regs. I researched the ref. ITAR 120.10 (5) & wrote to gnupg-users@gnupg.org Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Indent previous with "> ". Interleave reply paragraphs like a play script. Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 22 14:46:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A8E9773 for ; Wed, 22 Oct 2014 14:46:58 +0000 (UTC) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E476624D for ; Wed, 22 Oct 2014 14:46:57 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id vb8so646588obc.39 for ; Wed, 22 Oct 2014 07:46:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=n9rJZmEn5VZANA2wuptJ+wspmpEQNGVInGOGh4gqFrg=; b=V4oyJPevk3nh/EBeMRSAeyGBC01whPV+qI4h+WRLEMWyzI8GfqYIySGN9A5zLueSgs ffMMdLmQS43uI3Zv1FSpHyBqtTd2VeRpxeEeL6izc5TxZm3MavZ0scq2OuOLxNlCvWeJ yIS7C9Y2mwoc067uTD2pUHYvl+LbbW5mQUMvZRBCVN6YyEQGJPIYT9aT7QUaF+wJs9rS w6rD5ARosH8C3TqjpRxW60rNuJm9HmFtWSYbDELkSMjneRMHwMSusv9/RxMaG1j53YVV GSorc2QuItKFWp2prSsAEuX836yp/5hf3me+LUCWxjeNr+Iy3U2JgLIlD1t2zAUzGRVZ zAAg== X-Gm-Message-State: ALoCoQmuM9hhZ4H3evhUmgppwocbS2ThlNYHhHWnL4FkoJl6h/Xz5o0GZGrm7sOzdAi/mLEUulcW X-Received: by 10.60.147.196 with SMTP id tm4mr35879637oeb.4.1413989216234; Wed, 22 Oct 2014 07:46:56 -0700 (PDT) Received: from [172.21.0.83] (65-36-83-120.static.grandenetworks.net. [65.36.83.120]) by mx.google.com with ESMTPSA id cy12sm6320145oec.5.2014.10.22.07.46.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Oct 2014 07:46:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: DOC obstructs encryption export again - Non USA crypto base again ? From: Jim Thompson X-Mailer: iPhone Mail (12B411) In-Reply-To: <201410221424.s9MEOWwT000965@fire.js.berklix.net> Date: Wed, 22 Oct 2014 09:46:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201410221424.s9MEOWwT000965@fire.js.berklix.net> To: "Julian H. Stacey" Cc: "freebsd-hackers@freebsd.org" , Poul-Henning Kamp X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 14:46:58 -0000 > As far as I have been able to uncover, this settlement is about a > commercial closed source component, using specific hardware-crypto-assist,= for which no programming details have been made publically available. I have strong reason to believe this was about Intel's EP89579 (Tolapai) "Qu= ickAssist" core.=20 In 2009 or 2010, FreeBSD was offered a driver, with attached source code, fr= om an Intel engineer in Ireland on one of our lists. Intel also had a NIC with the same core available during the period covered b= y the complaint against Wind River.=20 If it was QuickAssist, then said details are available for its descendants o= n 01.org, and in recent Linux trees.=20 jmg@, eri@ and a few others have been investigating a FreeBSD driver for sam= e.=20 At the end of the day, "nothing to see here, move along." Jim From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 22 22:07:43 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8F4AF0A for ; Wed, 22 Oct 2014 22:07:43 +0000 (UTC) Received: from know-smtprelay-omc-11.server.virginmedia.net (know-smtprelay-omc-11.server.virginmedia.net [80.0.253.75]) by mx1.freebsd.org (Postfix) with ESMTP id 2F005B1E for ; Wed, 22 Oct 2014 22:07:42 +0000 (UTC) Received: from [192.168.1.100] ([86.20.122.200]) by know-smtprelay-11-imp with bizsmtp id 6N6W1p04K4KXVwe01N6WDf; Wed, 22 Oct 2014 23:06:31 +0100 X-Originating-IP: [86.20.122.200] X-Spam: 0 X-Authority: v=2.1 cv=Cq4xcxID c=1 sm=1 tr=0 a=WByauD8lJrWvBFCNrxRoEQ==:117 a=WByauD8lJrWvBFCNrxRoEQ==:17 a=9cW_t1CCXrUA:10 a=TlgFaoZnv2EA:10 a=uObrxnre4hsA:10 a=IkcTkHD0fZMA:10 a=NLZqzBF-AAAA:8 a=3lyhV3dlu1MEQZMdgTkA:9 a=QEXdDO2ut3YA:10 Message-ID: <54482A5E.2050303@NTLWorld.com> Date: Wed, 22 Oct 2014 23:06:22 +0100 From: Jonathan de Boyne Pollard User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 CC: "freebsd-hackers@freebsd.org" Subject: Re: nosh version 1.9 References: <54430B41.3010301@NTLWorld.com> <5443191E.5050208@mu.org> <34F30D28-DE9B-444F-885E-F438FEEA46EC@mu.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 22:07:43 -0000 Outback Dingo: > > IMHO I think we'd be better off with launchd... but this does show > intelligence.... > A while ago, I lived in a comfortable little world. Yes, everyone else was getting the likes of Solaris SMF, AIX SRC, systemd, upstart, and whatnot. But BSD was alright. Someone was bound to come along and package up launchd. After all, MacOS is BSD ... right? Then I did some investigation. There have been, to my knowledge, three attempts (in 2005, 2008, and 2013) to give launchd to the general BSD world that have involved more than just talk. All have foundered. The discomforting truth is that we aren't going to get launchd for doing service and system management for the very same reasons that we aren't going to get systemd for doing service and system management. systemd is full of Linuxisms. launchd is full of Machisms. It's simply not a BSD program. It's a Mach program. (The fact that the initial process program isn't portable is obvious in hindsight. I kicked myself. I've written several initial process programs before. They aren't, and cannot be, limited to non-operating-system-specific stuff.) One attempt to port launchd involved stubbing out the Machisms. There has been a recent attempt to port systemd to FreeBSD that is in the same boat: stub out or remove all of the operating system specific parts, and one can get a program that will compile (with a lot of compiler warnings); but it doesn't function. The launchd train is never coming. It's this realization, in addition to several other motivating factors, that spurred me to aim high with nosh, and actually set that task of converting those rc.d scripts. Feel free to thank the valiant and noble failures of the launchd porters for the fact that there's one alternative to BSD init that doesn't put an XML parser into the program for process #1. (-: From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 22 22:59:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD0BF999 for ; Wed, 22 Oct 2014 22:59:47 +0000 (UTC) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 42762F6C for ; Wed, 22 Oct 2014 22:59:47 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id gf13so4249757lab.15 for ; Wed, 22 Oct 2014 15:59:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OAP32XKYpDMwyrJ+LRclZ9yJqVu0PfZiY15po/sAoVg=; b=M4z0ZTZFKVGK2sL4QvjaBHqMxX227uj1zVg2/FyLpNjs6V3gosWilRBZzvVz5w+ZHn 8paHqGl3+XGEhqMIgRcJjFQ0GKYH+n0s5uiyqSS4s08T3ryLgEiQianre5zBoJSxw9qr P0Di2HHWxUqswFApwroGZOIY8TnKu+VDg7DXhSFicUPtvq3oEBBMfa9u4JXNfXrL5e0d fSJ9tCdX+TQ9IyaQXkDrgHp1GsJEdrX3Sr0aUoxYhml5TAvuG54mwgngmzdTHzCp021F 25OHQB4hg2efbIXj/SAw2hipkr2CrDc1+/pGUbsTBL97VMsbX0LvVQGqdpoborqX1g5w BReA== MIME-Version: 1.0 X-Received: by 10.112.156.168 with SMTP id wf8mr1114114lbb.28.1414018785063; Wed, 22 Oct 2014 15:59:45 -0700 (PDT) Received: by 10.152.22.195 with HTTP; Wed, 22 Oct 2014 15:59:45 -0700 (PDT) In-Reply-To: <54482A5E.2050303@NTLWorld.com> References: <54430B41.3010301@NTLWorld.com> <5443191E.5050208@mu.org> <34F30D28-DE9B-444F-885E-F438FEEA46EC@mu.org> <54482A5E.2050303@NTLWorld.com> Date: Thu, 23 Oct 2014 09:59:45 +1100 Message-ID: Subject: Re: nosh version 1.9 From: Outback Dingo To: Jonathan de Boyne Pollard Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 22:59:47 -0000 On Thu, Oct 23, 2014 at 9:06 AM, Jonathan de Boyne Pollard < J.deBoynePollard-newsgroups@ntlworld.com> wrote: > Outback Dingo: > >> >> IMHO I think we'd be better off with launchd... but this does show >> intelligence.... >> >> > A while ago, I lived in a comfortable little world. Yes, everyone else > was getting the likes of Solaris SMF, AIX SRC, systemd, upstart, and > whatnot. But BSD was alright. Someone was bound to come along and package > up launchd. After all, MacOS is BSD ... right? > > Then I did some investigation. > > There have been, to my knowledge, three attempts (in 2005, 2008, and 2013) > to give launchd to the general BSD world that have involved more than just > talk. All have foundered. The discomforting truth is that we aren't going > to get launchd for doing service and system management for the very same > reasons that we aren't going to get systemd for doing service and system > management. systemd is full of Linuxisms. launchd is full of Machisms. > It's simply not a BSD program. It's a Mach program. (The fact that the > initial process program isn't portable is obvious in hindsight. I kicked > myself. I've written several initial process programs before. They aren't, > and cannot be, limited to non-operating-system-specific stuff.) One > attempt to port launchd involved stubbing out the Machisms. There has been > a recent attempt to port systemd to FreeBSD that is in the same boat: stub > out or remove all of the operating system specific parts, and one can get a > program that will compile (with a lot of compiler warnings); but it doesn't > function. > > The launchd train is never coming. It's this realization, in addition to > several other motivating factors, that spurred me to aim high with nosh, > and actually set that task of converting those rc.d scripts. Feel free to > thank the valiant and noble failures of the launchd porters for the fact > that there's one alternative to BSD init that doesn't put an XML parser > into the program for process #1. (-: > > Actually thats not true..... We did successfully port it, and it is not released on github..... and it does work. https://github.com/outbackdingo/launchd_xml > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 22 23:02:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A01DAD3 for ; Wed, 22 Oct 2014 23:02:10 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D1C936B for ; Wed, 22 Oct 2014 23:02:09 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id hz20so3855916lab.11 for ; Wed, 22 Oct 2014 16:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6Li+1kPj2siOsjU6bRa3OL0Tu2tN9jHqrPBstMmT21c=; b=SG+EvRGUfVA+KRcSMHODcOYFWyqdRZJzoCpLn56gFUaIVoUx2y/X9F7N5GkUJVao29 RCxqv2tsMIQeHa764KmcS/qoxnD4QmQFCTKFP62vJtokYi3AShZOkDQATDFLk/DCJTux Re9YJnUyD3NijPaPTyOM5xHGYw+nbrj4Fc9nq6JbspMiyyDKJwvzVCoRYpbvgiiDW2qE moxZV1ToR1VtdfrWYfUgVk8QUXCP0E0zImO+w8z6Z3x8q0ndYS9G8PQxYp2ZDC2fe+2V HHY4LSS26qFIcRtpJ7O6LW6Xhenpo+kH7lqXcoc9yH/zFnlhEcDbT5iVcYRVz0TILJ++ ls2A== MIME-Version: 1.0 X-Received: by 10.112.52.33 with SMTP id q1mr1137868lbo.42.1414018927706; Wed, 22 Oct 2014 16:02:07 -0700 (PDT) Received: by 10.152.22.195 with HTTP; Wed, 22 Oct 2014 16:02:07 -0700 (PDT) In-Reply-To: References: <54430B41.3010301@NTLWorld.com> <5443191E.5050208@mu.org> <34F30D28-DE9B-444F-885E-F438FEEA46EC@mu.org> <54482A5E.2050303@NTLWorld.com> Date: Thu, 23 Oct 2014 10:02:07 +1100 Message-ID: Subject: Re: nosh version 1.9 From: Outback Dingo To: Jonathan de Boyne Pollard Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 23:02:10 -0000 On Thu, Oct 23, 2014 at 9:59 AM, Outback Dingo wrote: > > > On Thu, Oct 23, 2014 at 9:06 AM, Jonathan de Boyne Pollard < > J.deBoynePollard-newsgroups@ntlworld.com> wrote: > >> Outback Dingo: >> >>> >>> IMHO I think we'd be better off with launchd... but this does show >>> intelligence.... >>> >>> >> A while ago, I lived in a comfortable little world. Yes, everyone else >> was getting the likes of Solaris SMF, AIX SRC, systemd, upstart, and >> whatnot. But BSD was alright. Someone was bound to come along and package >> up launchd. After all, MacOS is BSD ... right? >> >> Then I did some investigation. >> >> There have been, to my knowledge, three attempts (in 2005, 2008, and >> 2013) to give launchd to the general BSD world that have involved more than >> just talk. All have foundered. The discomforting truth is that we aren't >> going to get launchd for doing service and system management for the very >> same reasons that we aren't going to get systemd for doing service and >> system management. systemd is full of Linuxisms. launchd is full of >> Machisms. It's simply not a BSD program. It's a Mach program. (The fact >> that the initial process program isn't portable is obvious in hindsight. I >> kicked myself. I've written several initial process programs before. They >> aren't, and cannot be, limited to non-operating-system-specific stuff.) >> One attempt to port launchd involved stubbing out the Machisms. There has >> been a recent attempt to port systemd to FreeBSD that is in the same boat: >> stub out or remove all of the operating system specific parts, and one can >> get a program that will compile (with a lot of compiler warnings); but it >> doesn't function. >> >> The launchd train is never coming. It's this realization, in addition to >> several other motivating factors, that spurred me to aim high with nosh, >> and actually set that task of converting those rc.d scripts. Feel free to >> thank the valiant and noble failures of the launchd porters for the fact >> that there's one alternative to BSD init that doesn't put an XML parser >> into the program for process #1. (-: >> >> > Actually thats not true..... We did successfully port it, and it is not > released on github..... and it does work. > > https://github.com/outbackdingo/launchd_xml > And to further note, we have even used openrc successfully on FreeBSD, As it all boils down I think to users preferences I believe having a choice is good..... now there appear to be three alternatives in the mix...... > > > >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org >> " >> > > From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 22 23:05:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C25BFBEF for ; Wed, 22 Oct 2014 23:05:31 +0000 (UTC) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DEE0BF for ; Wed, 22 Oct 2014 23:05:31 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id p9so3644135lbv.5 for ; Wed, 22 Oct 2014 16:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=qCbBxaZwrYmoZjpG40BBEtwHToHSqC5tQ+XFBXbVQpo=; b=JfvIN3S6WF+ydDIf3Jtd74qDGkq/AYrIjQMRqMjOO1kAhNaWbWY8yKAzUu2KbT/71V mtcJouJ/1a8FhLsBYjQXv9tTwa69Q3tamFk06SyIF6OSPXHGHrs3CCYKh6l2GimbryEq 8VbF3C2dClFCfAWziqYC89BVwJrNpjGFF5suYNd0PIdwWCZonx0vUPprCkBY+EgzeXBh Xh9/AXoKRrkPGnwcqVz75WFt8kLPJXpnNvRfp886ukfVCDYSi2geOV74znmAdeifUbcJ VaOws7iEoGIv+yP7xVxkUFOFJSa6rgaz+92BDmtQRfYiSNIoJaUiLhdhwbLvqEuSXV13 dGmQ== MIME-Version: 1.0 X-Received: by 10.112.26.71 with SMTP id j7mr1057965lbg.96.1414019129204; Wed, 22 Oct 2014 16:05:29 -0700 (PDT) Received: by 10.152.22.195 with HTTP; Wed, 22 Oct 2014 16:05:29 -0700 (PDT) Date: Thu, 23 Oct 2014 10:05:29 +1100 Message-ID: Subject: Launchd ported / released to the wilds for FreeBSD From: Outback Dingo To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 23:05:31 -0000 A working port of Launchd to FreeBSD has been released and can be found on github https://github.com/outbackdingo/launchd_xml We have also supplied the codebase to the openlaunchd efforts. Its a but dated but does still work on 8/9/10 and CURRENT. Enjoy..... From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 23 00:52:46 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F5C1D1F for ; Thu, 23 Oct 2014 00:52:46 +0000 (UTC) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 41E1FCDE for ; Thu, 23 Oct 2014 00:52:45 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id nt9so15982obb.1 for ; Wed, 22 Oct 2014 17:52:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=1XElbq66pIm3/Sgk0rjQSEmEd+Y3AxZAYUCYB9vb8o8=; b=he1cQyoVEPprE2ymioFyoLTGHWvlC62DIPgR56EZsf0KslCvRAHV/Z7Y13o424lWd4 s0MhSCisBz4+BvR6Igkbm/5X8bq8PoOdaXvxwsKSG87aeldifDPXaih4qE7XSI0rCi6c 7pkPs77YmW/H6S8LTLH5jHbt54TRAkDQF0EobrMxbevJYJmq13BZACD4B4mtSjSxECmm XWu5A/KdlbW8LZwHUQRDDnaTxo8KXLTRqPmIBFGbdfdWJMIbDgVF/4cnQJ4qHoAGJHk2 /fYUmUCyzLG0BUTXYVM9Zh4QQ7OndWZNeYmhPQxc1uMZguqkcAlJ6Q3U4Lf6L5DmPs+G asQw== X-Gm-Message-State: ALoCoQkuaqhsvxQMcpe6Klfycuqv3Pg8HSJBmTb6u0mar3UGGvfqDj8FFEAug/dVueCC/D0YUsSa X-Received: by 10.202.84.77 with SMTP id i74mr1129890oib.29.1414025559401; Wed, 22 Oct 2014 17:52:39 -0700 (PDT) Received: from [30.135.45.255] (66-87-121-255.pools.spcsdns.net. [66.87.121.255]) by mx.google.com with ESMTPSA id 2sm175396obq.29.2014.10.22.17.52.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Oct 2014 17:52:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: nosh version 1.9 From: Jim Thompson X-Mailer: iPhone Mail (12B411) In-Reply-To: Date: Wed, 22 Oct 2014 19:52:36 -0500 Content-Transfer-Encoding: 7bit Message-Id: <8DE09AE3-91C9-4B0A-9232-F6736BCBE133@netgate.com> References: <54430B41.3010301@NTLWorld.com> <5443191E.5050208@mu.org> <34F30D28-DE9B-444F-885E-F438FEEA46EC@mu.org> <54482A5E.2050303@NTLWorld.com> To: Outback Dingo Cc: "freebsd-hackers@freebsd.org" , Jonathan de Boyne Pollard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 00:52:46 -0000 > On Oct 22, 2014, at 5:59 PM, Outback Dingo wrote: > > Actually thats not true..... We did successfully port it, and it is not > released on github..... and it does work. > > https://github.com/outbackdingo/launchd_xml And they used it in a forked version of pfSense. :-) From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 22 23:05:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4C7EBEE for ; Wed, 22 Oct 2014 23:05:30 +0000 (UTC) Received: from mail.iXsystems.com (mail.ixsystems.com [12.229.62.4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B4718BE for ; Wed, 22 Oct 2014 23:05:30 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 497B6884E7; Wed, 22 Oct 2014 16:05:29 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 40177-09; Wed, 22 Oct 2014 16:05:29 -0700 (PDT) Received: from [10.2.0.80] (unknown [10.2.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id B8640884E2; Wed, 22 Oct 2014 16:05:28 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: nosh version 1.9 From: Jordan Hubbard In-Reply-To: <54482A5E.2050303@NTLWorld.com> Date: Wed, 22 Oct 2014 16:07:58 -0700 Message-Id: <6C9A0CEC-2169-48BB-8B80-EB3C37EE170E@turbofuzz.com> References: <54430B41.3010301@NTLWorld.com> <5443191E.5050208@mu.org> <34F30D28-DE9B-444F-885E-F438FEEA46EC@mu.org> <54482A5E.2050303@NTLWorld.com> To: Jonathan de Boyne Pollard X-Mailer: Apple Mail (2.1990.1) X-Mailman-Approved-At: Thu, 23 Oct 2014 01:49:42 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 23:05:31 -0000 > On Oct 22, 2014, at 3:06 PM, Jonathan de Boyne Pollard = > wrote: >=20 > There have been, to my knowledge, three attempts (in 2005, 2008, and = 2013) to give launchd to the general BSD world that have involved more = than just talk. All have foundered. The discomforting truth is that we = aren't going to get launchd for doing service and system management for = the very same reasons that we aren't going to get systemd for doing = service and system management. systemd is full of Linuxisms. launchd = is full of Machisms. It's simply not a BSD program. It's a Mach = program. (The fact that the initial process program isn't portable is = obvious in hindsight. I kicked myself. I've written several initial = process programs before. They aren't, and cannot be, limited to = non-operating-system-specific stuff.) One attempt to port launchd = involved stubbing out the Machisms. There has been a recent attempt to = port systemd to FreeBSD that is in the same boat: stub out or remove all = of the operating system specific parts, and one can get a program that = will compile (with a lot of compiler warnings); but it doesn't function. >=20 > The launchd train is never coming. =20 I aim to disprove that assertion sometime in the next 12 months. I=E2=80=99ll also point out that it would have taken less time to port = NetBSD=E2=80=99s COMPAT_MACH code than it=E2=80=99s probably taken to = beat one=E2=80=99s head against mach ports in launchd. They would = certainly not be the first Mach code FreeBSD has ever seen (take a look = at the VM system sometime!). - Jordan From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 22 23:08:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD2FCCE8 for ; Wed, 22 Oct 2014 23:08:05 +0000 (UTC) Received: from mail.iXsystems.com (mail.ixsystems.com [12.229.62.4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA505DB for ; Wed, 22 Oct 2014 23:08:05 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 1FF5E88666; Wed, 22 Oct 2014 16:08:05 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 40333-08-3; Wed, 22 Oct 2014 16:08:04 -0700 (PDT) Received: from [10.2.0.80] (unknown [10.2.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 1FC4888648; Wed, 22 Oct 2014 16:07:50 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: nosh version 1.9 From: Jordan Hubbard In-Reply-To: <54482A5E.2050303@NTLWorld.com> Date: Wed, 22 Oct 2014 16:10:19 -0700 Message-Id: References: <54430B41.3010301@NTLWorld.com> <5443191E.5050208@mu.org> <34F30D28-DE9B-444F-885E-F438FEEA46EC@mu.org> <54482A5E.2050303@NTLWorld.com> To: Jonathan de Boyne Pollard X-Mailer: Apple Mail (2.1990.1) X-Mailman-Approved-At: Thu, 23 Oct 2014 01:50:34 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 23:08:06 -0000 > On Oct 22, 2014, at 3:06 PM, Jonathan de Boyne Pollard = wrote: >=20 > Feel free to thank the valiant and noble failures of the launchd = porters for the fact that there's one alternative to BSD init that = doesn't put an XML parser into the program for process #1. (-: Also, just to correct what has always been a rather blatant = misconception about launchd. Launchd knows *nothing* (NUH-THING) about = XML. There is no XML parser in process 1. Anyone who thinks this has = simply never even looked at how launchd works. It=E2=80=99s completely = agnostic to configuration file formats and wouldn=E2=80=99t know a = configuration file format if one bit it on the ass. That=E2=80=99s = actually one of the more elegant aspects of its design! - Jordan From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 23 02:16:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33B79475 for ; Thu, 23 Oct 2014 02:16:15 +0000 (UTC) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AC71B658 for ; Thu, 23 Oct 2014 02:16:14 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id w7so83124lbi.8 for ; Wed, 22 Oct 2014 19:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GVmO1sU2GuIbILCvKxbnQX88/bXTp6eTdRfTu6I3ifk=; b=sZhGalAUElEpycIGgruPjpDw20VI3s0KNnj98qKZXHyZh3I91bJ93OcoT75FUyFvSw 4rP2r7Bwh2jbrmtFb34/ys90rC9c7pB75te0eRVJww9Pj9/8edvtptqXqwXDoo+AYPmF bWVs3u4YLeOfBrctfTshoDPynqnsDTD1AVEjPOHpx7rgBGjLwCKuFHvCNsbi1crvI/XW kb4WxRZsuaiy1Nl159HCx2TaeVzveKI6A8XNagKnY1IpU9YVSkiQRRnsdWTSzoFoovwb vPTG2+bqwd0ddNlJc3Abxjzpfj7yGpMWJFzXUwki4tf9s/Uj9poUEwMw2XAt1rJd5B4w aX9w== MIME-Version: 1.0 X-Received: by 10.112.97.135 with SMTP id ea7mr1783524lbb.46.1414030572509; Wed, 22 Oct 2014 19:16:12 -0700 (PDT) Received: by 10.152.22.195 with HTTP; Wed, 22 Oct 2014 19:16:12 -0700 (PDT) In-Reply-To: References: <54430B41.3010301@NTLWorld.com> <5443191E.5050208@mu.org> <34F30D28-DE9B-444F-885E-F438FEEA46EC@mu.org> <54482A5E.2050303@NTLWorld.com> Date: Thu, 23 Oct 2014 13:16:12 +1100 Message-ID: Subject: Re: nosh version 1.9 From: Outback Dingo To: Jordan Hubbard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" , Jonathan de Boyne Pollard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 02:16:15 -0000 On Thu, Oct 23, 2014 at 10:10 AM, Jordan Hubbard wrote: > > > On Oct 22, 2014, at 3:06 PM, Jonathan de Boyne Pollard > wrote: > > > > Feel free to thank the valiant and noble failures of the launchd porter= s > for the fact that there's one alternative to BSD init that doesn't put an > XML parser into the program for process #1. (-: > > Also, just to correct what has always been a rather blatant misconception > about launchd. Launchd knows *nothing* (NUH-THING) about XML. There is = no > XML parser in process 1. Anyone who thinks this has simply never even > looked at how launchd works. It=E2=80=99s completely agnostic to config= uration > file formats and wouldn=E2=80=99t know a configuration file format if one= bit it on > the ass. That=E2=80=99s actually one of the more elegant aspects of its = design! > > - Jordan > > Actually our port is "very" xml aware :) see https://github.com/outbackdingo/launchd_xml/tree/master/launch_xml > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 23 02:47:03 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C261699F for ; Thu, 23 Oct 2014 02:47:03 +0000 (UTC) Received: from mail.iXsystems.com (mail.ixsystems.com [12.229.62.4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9FE73966 for ; Thu, 23 Oct 2014 02:47:03 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id A700380348; Wed, 22 Oct 2014 19:47:02 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 57526-10; Wed, 22 Oct 2014 19:47:02 -0700 (PDT) Received: from [10.2.0.80] (unknown [10.2.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 5E17D80343; Wed, 22 Oct 2014 19:47:02 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: nosh version 1.9 From: Jordan Hubbard In-Reply-To: Date: Wed, 22 Oct 2014 19:49:21 -0700 Message-Id: <527291AC-C5E2-420C-B566-C051BA82CA84@turbofuzz.com> References: <54430B41.3010301@NTLWorld.com> <5443191E.5050208@mu.org> <34F30D28-DE9B-444F-885E-F438FEEA46EC@mu.org> <54482A5E.2050303@NTLWorld.com> To: Outback Dingo X-Mailer: Apple Mail (2.1990.1) X-Mailman-Approved-At: Thu, 23 Oct 2014 02:50:59 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" , Jonathan de Boyne Pollard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 02:47:03 -0000 > On Oct 22, 2014, at 7:16 PM, Outback Dingo > wrote: >=20 > Actually our port is "very" xml aware :) see = https://github.com/outbackdingo/launchd_xml/tree/master/launch_xml = OK, well, launchd as originally designed certainly was not (and is not) = xml-aware. This was on purpose. You don=E2=80=99t want a lot of = surface area in pid 1, which can never crash, nor do you want to bake = your serialization format into stone tablets. launchctl(1) does all the XML parsing and then passes the results to = launchd using its own custom IPC format. Was there some particular = reason you violently inserted the XML parsing directly into launchd = after the original architect(s) went to such pains to avoid such blatant = penitentiary experiences? :-) - Jordan From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 23 03:40:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96A3C615 for ; Thu, 23 Oct 2014 03:40:37 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 80482F33 for ; Thu, 23 Oct 2014 03:40:37 +0000 (UTC) Received: from u10-2-32-011.office.norse-data.com (unknown [50.204.88.51]) by elvis.mu.org (Postfix) with ESMTPSA id 4474C341F83D for ; Wed, 22 Oct 2014 20:40:37 -0700 (PDT) Message-ID: <544878B4.1060804@mu.org> Date: Wed, 22 Oct 2014 20:40:36 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: nosh version 1.9 References: <54430B41.3010301@NTLWorld.com> <5443191E.5050208@mu.org> <34F30D28-DE9B-444F-885E-F438FEEA46EC@mu.org> <54482A5E.2050303@NTLWorld.com> <527291AC-C5E2-420C-B566-C051BA82CA84@turbofuzz.com> In-Reply-To: <527291AC-C5E2-420C-B566-C051BA82CA84@turbofuzz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 03:40:37 -0000 On 10/22/14 7:49 PM, Jordan Hubbard wrote: >> On Oct 22, 2014, at 7:16 PM, Outback Dingo > wrote: >> >> Actually our port is "very" xml aware :) see https://github.com/outbackdingo/launchd_xml/tree/master/launch_xml > OK, well, launchd as originally designed certainly was not (and is not) xml-aware. This was on purpose. You don’t want a lot of surface area in pid 1, which can never crash, nor do you want to bake your serialization format into stone tablets. > > launchctl(1) does all the XML parsing and then passes the results to launchd using its own custom IPC format. Was there some particular reason you violently inserted the XML parsing directly into launchd after the original architect(s) went to such pains to avoid such blatant penitentiary experiences? :-) > I could see the utility of that. One of our senior full stack devs says that XML is "triggering" and that they wouldn't want to work on such a system. Perhaps it's to keep web people out? -Alfred From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 23 04:08:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF317851 for ; Thu, 23 Oct 2014 04:08:56 +0000 (UTC) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A09B3183 for ; Thu, 23 Oct 2014 04:08:56 +0000 (UTC) Received: by mail-vc0-f179.google.com with SMTP id im17so153985vcb.10 for ; Wed, 22 Oct 2014 21:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=IcgWHZtR+B2JAlSjigxJQEC08DIV5qFNO2Z5v8XR4DM=; b=dBKOEgzqD3qXbGaHQ6Rz5BonTEZtqgydiL8neSTuCX99Eghbo7RkR+tmLZTfFjtXSA kz2BwTKE7nI0f4kU7uH/L4EmsrX+uSh2SKr+p4qieHJHfkF9AC/UNgyMjdnUmoGj4tDU UxE5j3m3OafEyxB5SAwQCFU+zkHFGFtZgutacblCc+eVRQ4FoPwQVfCrf+6RAniq9N/d o+ODJrYMUM7CJ+E74gJwhHbQkCFg4gXfi21pFUD2Vpeex+5TAn5MGXGWyTaNsNGvAoDp S9HOJIiPTGOVCS0KL2/S4kwX6gMhbixRlsXP8DXXLqqBCaVxSAfHF1dPYyU2vt3xA3ga 5iaQ== MIME-Version: 1.0 X-Received: by 10.221.46.4 with SMTP id um4mr1756134vcb.23.1414037335542; Wed, 22 Oct 2014 21:08:55 -0700 (PDT) Received: by 10.220.238.14 with HTTP; Wed, 22 Oct 2014 21:08:55 -0700 (PDT) Date: Thu, 23 Oct 2014 00:08:55 -0400 Message-ID: Subject: IPv6 provisioning for a FreeBSD ISP. From: Zaphod Beeblebrox To: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 04:08:57 -0000 Besides the fact that the ngX interfaces appear to have a quirk (or maybe it's mpd5 or quagga) where remote hosts can't talk to services residing on the ngX host, A FreeBSD machine with mpd5 and quagga that talk to freeradius and PostgreSQL serves as a really nice small ISP package. I already support ipv6 for many users (and have, for some time) using static gif tunnels. This works, but it is annoyingly suboptimal. Now my ISP doesn't allocate addresses from a pool. I don't care that people effectively have static addresses. managing the addresses isn't difficult and the average user is nailed up more than 98% of the time. So I assign a static IPv4 address in PostgreSQL. Freeradius reads this and sends it to mpd5 --- which hands out the static addresses ... and even routed ipv4 netblocks via ipcp (or ipv4cp). IPv6 works over my pppoe<-->l2tp links. I can set static addresses on the ngX connections at both ends, The traffic is passed. What stops me from implementing this is the equivalent of the PostgreSQL->freeradius->mpd5->ipcp communication of the addresses and settings. mpd5 doesn't seem to have any builtin handling of the ipv6 addresses and I don't see what other solution will properly hand out static addresses (and routed networks). How is this supposed to go together? DHCP6 doesn't seem to acknowledge that the user has already logged in via l2tp/ppp. rtsold doesn't seem to address static addressing. From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 23 04:34:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D61DA86 for ; Thu, 23 Oct 2014 04:34:30 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id E75B33F0 for ; Thu, 23 Oct 2014 04:34:29 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id B917B6359A for ; Thu, 23 Oct 2014 04:34:22 +0000 (UTC) Message-ID: <54488557.1080103@freebsd.org> Date: Thu, 23 Oct 2014 00:34:31 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: nosh version 1.9 References: <54430B41.3010301@NTLWorld.com> <5443191E.5050208@mu.org> <34F30D28-DE9B-444F-885E-F438FEEA46EC@mu.org> <54482A5E.2050303@NTLWorld.com> <527291AC-C5E2-420C-B566-C051BA82CA84@turbofuzz.com> In-Reply-To: <527291AC-C5E2-420C-B566-C051BA82CA84@turbofuzz.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RGu9sWi6tauwKMIaoNEJ227S93rk6dehv" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 04:34:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RGu9sWi6tauwKMIaoNEJ227S93rk6dehv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2014-10-22 22:49, Jordan Hubbard wrote: >=20 >> On Oct 22, 2014, at 7:16 PM, Outback Dingo > wrote: >> >> Actually our port is "very" xml aware :) see https://github.com/outbac= kdingo/launchd_xml/tree/master/launch_xml > OK, well, launchd as originally designed certainly was not (and is not)= xml-aware. This was on purpose. You don=E2=80=99t want a lot of surfac= e area in pid 1, which can never crash, nor do you want to bake your seri= alization format into stone tablets. >=20 > launchctl(1) does all the XML parsing and then passes the results to la= unchd using its own custom IPC format. Was there some particular reason = you violently inserted the XML parsing directly into launchd after the or= iginal architect(s) went to such pains to avoid such blatant penitentiary= experiences? :-) >=20 > - Jordan >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 The nice thing about this design is that it would allow replacing the XML with something more human readable/writing like UCL --=20 Allan Jude --RGu9sWi6tauwKMIaoNEJ227S93rk6dehv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUSIVaAAoJEJrBFpNRJZKfSx4P/2EfkM8DW5jsfzsf6aC3wwKJ GaPg6FRyAgZmaS5X4RITaFERhpG3CYbnx4h3nweQufwhSRF+rDMUunU0ZNC2h03I XHLKW9PUXUy9CnGeFVf5FqbXdI7eQ/4vOTgsQDePuO8Y+tmOEMq7sTqbkf03zfl1 beN3g4G/kGX/p+1z8Th6buVR9QOpz+jc5PBw/16M0LffAbmp8iO24LcyOUYJ6Wfo XccUIEKvWHVazK8pvNrIKf8tnR6WnM1h63LGka0AnpspEfj++2ZHoBbZ/G6qftzR CsT8yFFu1g4KlWTVgOxAWfe3OKlqcDVWlofBbPl60zbVLBPeIRzBjDIDRgKZpHp7 KwGtrdt7HyzSbEStmtqsz1rbVDyDVMfEYdOvUin656RChzAlBqHCLg4ViczmFa5Q kLeRYo7JguAxXD5Ke6ABd1vOg+s7PW8hc9NaLdy4NgdukWavMEezPuQVLtHc/rb0 Wrbgeera1G9/9LezfIL7eeKR5LjgCl44GdSQtTlU0OFj7UJqvG3Ce70lDOUX3egM UpN+hptMuVVd4GcBdyCF3VwcScSeh/9lqU4SMgJtsAmefGm7D2IveOS506h7AW4F plfTA+7Ba8MFNLEzj3ciSgP5xJWdTwMSnDfQv7sE99A7fJNiQlVRuY7CeGG5w8nG nvq0CJed+//7aD6JwzGz =rkVe -----END PGP SIGNATURE----- --RGu9sWi6tauwKMIaoNEJ227S93rk6dehv-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 23 04:42:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB077BB8 for ; Thu, 23 Oct 2014 04:42:13 +0000 (UTC) Received: from nm28-vm1.bullet.mail.ne1.yahoo.com (nm28-vm1.bullet.mail.ne1.yahoo.com [98.138.91.35]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9A89C68A for ; Thu, 23 Oct 2014 04:42:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1414039327; bh=mIn6nEAIqVU2HENPHRBYlYryph70x9sWa2D3v6W+oCY=; h=Subject:From:Date:To:From:Subject; b=F6BYdu4SSywWWaxPjNMm6z2tQKd0+LgYyPkcsGDvdvgmXm9YFynd8dAI5v1Yxfhr7/PFPh3agmCmbs8RmIBb9wuhDPw3cXJ+GlNbZzNN3ehfcP2hzHv7dted57WWkUwBxGFWSuxdxqNgpMCgOC6545CdurDAVQulmVc5IWVqqawALTtPCZBIH8CjI1s4FO11z6KnkBKY37VcJRjjSgDzGWPbxUMS9CCvQ9G6sck6n/UQ9i2HeunGC9dnYsUwSMlep1ehcRtMropb3U+765gpXrjgGL12+wie9gOdAXJIyrfxVqelc7Ha3LyB0i0xTiIfuYPQMSbvj3UGH31qTjGvkQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=rBUYubAogQInrMG+PcVf3+pdLOrcK8lfCERdieLFBZCW2ixsxOlgvgzYOQNX4+GVteHpQjHZ50+yFkYExAxNWH3PbVRwJPP+bnssmduDkssqfei5gWnlgchkU4VBa6wXtKVsg2GufMWWQbgi42wN/dZxhQIGMCgEUbgOP1f0oX1Tzr+Ahtdc+qdqiMTQ/StJMseleipMJbC4jKEgBHiby0ciSNOiRRGaadvudbLplmszXywab1yDUNQQ4aZOD93JPWrmiO4yLtGKtuo4t3gG4Do+eNMpBdCZk5h85AiRrk0PuLmnOL43YbUnIhmqTT2H45Hm34cGOGfz1MSxCxRomg==; Received: from [98.138.100.113] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 23 Oct 2014 04:42:07 -0000 Received: from [98.138.226.129] by tm104.bullet.mail.ne1.yahoo.com with NNFMP; 23 Oct 2014 04:42:07 -0000 Received: from [127.0.0.1] by smtp216.mail.ne1.yahoo.com with NNFMP; 23 Oct 2014 04:42:07 -0000 X-Yahoo-Newman-Id: 289952.50328.bm@smtp216.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 86XMsdoVM1kKSt3N_ep4mLUedfxqvuxS_I5KbgcSummGCxf cqQyyfTR8plePEw1HG4fwRKlnb_mLdy96lQUAiT5uuxAkDaXLf5Un8f_e2NW 4IRmTYziPKwbJ06GvWJimYo5uFrWc8fax3C8xyHNEe9OfU9LXkJtYAY0TAt_ L2VFykYKt93QWsfHZxcJ_1wJ.J95lXn8dtmQLvncXjAMcAXYMfxhWYScOPhR M5WfDIUeQelSxdKobinfw4FCy97LScZQal8YUo1RyfyyuSKGvhbBA91AXt8X XOP51jrJkc4cEGq9SpgIRNdMw0vMsoocVvM6YqDTWEMFJzxPJ8vOchd__DcB Lsv3cGJQuaAt5ZCKR1517lQaxlnX_YXIM6rQvmUeD_9s7sdzFiIZ7vdoCHM2 2cJjzLB32PjTYK4sCDRwZLiqpAMej46dkuhOwnrIn8ZRtckbPgWZpUBNg7fp qXj2XuXIEtoQmclW2jMVsKhPxG5BsqNzaVkQOOPks9wb.IkRDnz8fNl5qHJO ZhtFLPQoqTI6tQEYP1ggfZ69QUZghJSD74TDdFJcvQVMLtaqhTOLB4wVs0cM UmdZj X-Yahoo-SMTP: LAFNfTaswBDguI7meB90l2l3wOU- Subject: FreeBSD Home Page From: by Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (11D257) Message-Id: Date: Thu, 23 Oct 2014 12:41:59 +0800 To: freebsd-hackers@freebsd.org Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 04:42:13 -0000 freebsd.org home page seems strange with "Production" and "Upcoming". by From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 23 04:44:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31320C9F for ; Thu, 23 Oct 2014 04:44:01 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 0BD1C698 for ; Thu, 23 Oct 2014 04:44:00 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id D8DE4635BF; Thu, 23 Oct 2014 04:43:58 +0000 (UTC) Message-ID: <5448879A.7030802@freebsd.org> Date: Thu, 23 Oct 2014 00:44:10 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Home Page References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ru6cfsAOcSmiOdNUQlh20apwk1GdbLwWx" Cc: free7by@yahoo.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 04:44:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ru6cfsAOcSmiOdNUQlh20apwk1GdbLwWx Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2014-10-23 00:41, by via freebsd-hackers wrote: > freebsd.org home page seems strange with "Production" and "Upcoming". >=20 > by > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 This was an improvement over the original names, where were 'Production: 10.0' and 'Legacy: 8.4, 9.3' Do you have a suggestion for better working? --=20 Allan Jude --Ru6cfsAOcSmiOdNUQlh20apwk1GdbLwWx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUSIebAAoJEJrBFpNRJZKfc54P/1u/58WFHb65OFm79P/Tahyd to88QH7OVdRDGoNagHmAK+VhWrHKBNL2cy6Wn37lbkYuQj3UVW5SmIZklNs5WP3i xCtV25PgvOJhRMVDi4/PRhX/l5Bsuj8ZxgKA1ZyHsJ0oFa/AOTnfLSwtwtb1Sl9o C46nNjuk72fPPADRz/JHEq8JQekOj2ZEaYR+7FQZbqbFgrxwCTykEl6pkEkmq1KT 5BCu7fgHyM95rFwGuWowSzXMBWW1K/eZ9Dnav4oNBzsLQxGPnG4QHI+snxdaXTP6 nMpfdCiq0kKr9dEjKl+RIem7Jls4+NrhFD6TZNOVRJ8DaLHMxC1k3R2QNSNMGiKV kfOmviOsLvVOvd7dvR0BlH9V7b6nkjMtpr6kJ47lwWIoth/3pv38f8eUT5mlyiFJ GGisSzEyDGsOa/f25Vw9Fy5YSiLi50m0vFY8GOtAX/HjnpfKMq2uHjo38vjjsyf6 Do9bjMdroHsFVnkFbaJ8SYB4t0XvWCAVXTESJNZeHJd0Wrj+mp3uTJ8p/LQjeq3b cOLIaCqx90HMu+pQKgQiX1aLGehlOmTKyVPY7N64Jp4uFr+NalDPaOLctbv2/K+R PdxUv6p4yzELo2PXExNPCv1ra0aKTg1X7NgtvPIEUuDpcP1abKjmZnsrjmXoZBsj n75jvtOX/jtG/QqJM7ro =sHvc -----END PGP SIGNATURE----- --Ru6cfsAOcSmiOdNUQlh20apwk1GdbLwWx-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 23 04:46:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6C2BDB1 for ; Thu, 23 Oct 2014 04:46:20 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id C12226AA for ; Thu, 23 Oct 2014 04:46:20 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 4F0EE635DA for ; Thu, 23 Oct 2014 04:46:19 +0000 (UTC) Message-ID: <54488826.9090908@freebsd.org> Date: Thu, 23 Oct 2014 00:46:30 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Home Page References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5gAmDt346UtABHsWmqq5sIjgo23fNLJGj" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 04:46:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5gAmDt346UtABHsWmqq5sIjgo23fNLJGj Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2014-10-23 00:41, by via freebsd-hackers wrote: > freebsd.org home page seems strange with "Production" and "Upcoming". >=20 > by > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 Er, ohh, I see what you are talking about. The entities seem to be broken= =2E --=20 Allan Jude --5gAmDt346UtABHsWmqq5sIjgo23fNLJGj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUSIgmAAoJEJrBFpNRJZKfjvkP/iMDJ/ANEmtfWkPLzHuTWH1K 7sdoBZwX6Sx7Qe2gx3CIPI5yERioBCYLQTHx7KtBS0jqXkE8EVXVPHgKUNslpVBz Tqp2orZN8UimQPJZ9UBRFU5lmW9fiXdmT4YeQ16h+zqiZlMJXwW9WcRjbacXG4HS ST5aDV//r8Bk+z7/Xk+niUsmmv1A21lIzslbZp0Cj12ykJXrjOo9232vZq5+opAI MIXL3YKkFcfhLvnIU2xjcIDCm2dNPX6t18WNrR2n9h0FSQAB85bT6CwECpTkdtlg 0ibj//Tfr/vnXcyAzhNa6ZGr49uLPYRouUG3Z+PhlrZcLKYeiApurvOhP1JQbVL2 NR0c6tSD1jwFTQD4rBQUMMjpFnz1pBra4AH0i9/pFGjh15oQh8CLakXBhDbrc7BW ElqrkwtPvr5PmLQfaMk0fQiAgAkJjUUDs05oMVeLBaffrpCUOHs0bU8b25YomYlI 2+kxoNS9pfkiFyRNow4N2BN1aUqN755vh7wRSwCqbNbtfniWtCP6966jtPl3FTU+ DTdCWzN6JfIfXJN1QkB8rm6OkxlIxhXDLlcNmqsBUI9uwPsU2Cfg1M+d7W+qyj7Y F8y9PvAR0bHEbhxSY6CoGMN/t9bOQ3QNna1cEEKjhtQY9jr0L1Prtu7yBqsP1r1W 1gE42/OiAOYWUZC+PSii =JdgX -----END PGP SIGNATURE----- --5gAmDt346UtABHsWmqq5sIjgo23fNLJGj-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 23 04:46:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DBBA4E8E; Thu, 23 Oct 2014 04:46:47 +0000 (UTC) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3987D6B7; Thu, 23 Oct 2014 04:46:47 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id gi9so196237lab.33 for ; Wed, 22 Oct 2014 21:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=X87zS9UTLfnYRiMb+fxJnAITRdU930izaJbg5aAMmxY=; b=aE95L3ztOm24L2Gvb3BzrQaRZk0bYpDvwz64gcUxgCXS6jluyaLFskrDomw3lJDs5W DMbINvTtO/eOAnmLELSqGMS6cOxRC0zQAad+e+Hyb9HsZ3xf3IMw9Auv6BUrcErE6DnY veFgOJTibmhDr4hzjVh75W5EkRrxIYz1zsKXOh9E1cRQCaVOdribZHfjjP3TC//3AWhb 0mmpHei0KWmyMw5AV1ZyjoVnu0739UNaaOx3+++zj4Ru9WWG2e830NOeTjhIoyzBTwfb sqDp7zmLR33/fmUwD9xdEHK5ELcHYimALr+eAqo7pkzGG/AvN2l4WXrJYckhGUtjhDrV OFBQ== MIME-Version: 1.0 X-Received: by 10.112.134.39 with SMTP id ph7mr2227456lbb.45.1414039605162; Wed, 22 Oct 2014 21:46:45 -0700 (PDT) Received: by 10.25.19.142 with HTTP; Wed, 22 Oct 2014 21:46:45 -0700 (PDT) In-Reply-To: <5448879A.7030802@freebsd.org> References: <5448879A.7030802@freebsd.org> Date: Thu, 23 Oct 2014 07:46:45 +0300 Message-ID: Subject: Re: FreeBSD Home Page From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= To: Allan Jude Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-hackers@freebsd.org, free7by@yahoo.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 04:46:48 -0000 Hi, On FreeBSD.org, Release numbers are lost. Something have a problem. Production release and upcoming releases not shown! LATEST RELEASES Production: , , Upcoming: On Thu, Oct 23, 2014 at 7:44 AM, Allan Jude wrote: > On 2014-10-23 00:41, by via freebsd-hackers wrote: > > freebsd.org home page seems strange with "Production" and "Upcoming". > > > > by > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > > > > This was an improvement over the original names, where were 'Production: > 10.0' and 'Legacy: 8.4, 9.3' > > Do you have a suggestion for better working? > > -- > Allan Jude > > From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 23 04:50:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C540414F for ; Thu, 23 Oct 2014 04:50:17 +0000 (UTC) Received: from nm18-vm0.bullet.mail.ne1.yahoo.com (nm18-vm0.bullet.mail.ne1.yahoo.com [98.138.91.37]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 81F256D1 for ; Thu, 23 Oct 2014 04:50:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1414039815; bh=qRGHeNxu0l9mZoyLAuyuUxwd5CpUVT1h+4kzC2evqNQ=; h=Subject:References:From:In-Reply-To:Date:To:From:Subject; b=hLO4nPBTJ2fnjlQEhR9DeX/4W0bIJDok5IClZ0pnmHt9IxPlyoQm/i9mn640cWhhwU8EbgsNx9L0XcTn2cDjfleUz20YzuezYjyUQZgtIR9wkk+vnWahKRtcx9fbLhNluA59H8dDPqA3jYlFu2o55ozBSuWLQC9c2SIvUPf5+Wl648e8lvOVraKMJ52fL6qQimdNJkVU5fpIkvIyXmUPGDJTAaO/D3ToK0JYVAtXuN49lN7IT6ZDwsXTZorr/sR7Cvye2GjedZRadVFR2AsGtlHCeoeNGjQoMC04+HWSJS7mJYKL3YgDqSXFwG6uIOJ90JHrWYk4rvzv0GG5mN9qQQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=K4VEDsO36G52obTPu3zlSPY237HVqvGZ/da87SibcGCAoEJWJ/+bXK9ySjy1A/bE4flviyljpw35jV3nB1icaJqv/nuOUfDc2+XgST7gfeQ9bCJNS6OHeHvM9YCmVPaQCeTeOaLClWtTjJCTL/Ng+9vMXnNEn8YxHhX2AEaiMyeUTcGcPWbyPDdzhi9HKLuhGIFqGFPg64m0aaFcyb88t1/BT0KhCxyMZjVavV+VKN0+RuDypX9kF9rqKo57H74M5Q5jpvzTrJ7+LB+efh4SOxJ1MqjmimkWhEY9k5VuBaCmDpf1g9YW1+OG4FkI9cPVDE1AYb48RljxE0t58xcDoQ==; Received: from [98.138.101.131] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 23 Oct 2014 04:50:15 -0000 Received: from [98.138.104.112] by tm19.bullet.mail.ne1.yahoo.com with NNFMP; 23 Oct 2014 04:50:15 -0000 Received: from [127.0.0.1] by smtp221.mail.ne1.yahoo.com with NNFMP; 23 Oct 2014 04:50:15 -0000 X-Yahoo-Newman-Id: 747395.37870.bm@smtp221.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: BuSSr1wVM1lh6cq9QEPxRduRZF4okHW5QkNc1C3Ce65NqCJ g5_qK5u5dqWjDsRHvIZ_ZZIWnfoTZy3.rdvZjS7UPCHk89HFiDnO.zSeoY1c UMOhR1VO3u_8DVFM6.TZW.CdOhyNtR_iRiZbA9ulXh8b6e7tn7Tw2wax4Fvw v7Yz9ZW7WVq4zWn5Oe0lRKAYNHr5UTtFch29Sk_kXO7SfRCa3tIxWbFElrzm H9zI5n9vU9dYFuyjIRXD8eRmDpOmxy4Iotsmzt4KhLlo6aUzbTzW0YocByDG 2mZ4ZZGtzOS_bX3Ia1R4CLYijJ6wr6WKmhYu_3vXY9U4Ge2R8oSgoEJKyXzW vEKU3olCPaLgG355oSgeyNnLLFL9y3QgbHaw6FgTDhHR.4DYbIsKb3jrjgHv lRsOZX_mFM1c5_EluHgDbIKGLmT7ft_W0z50Dq4n10GyBL7H_SJ.LpbThPkr 0QHv_tHnGNzzgC7OtVGTnFPCe4ae.AzUJw6XbbUv0X0.0EWcdtJSF7CK1LpD hj0fYAzYmHI0HVo8tuxC2ufQopxfRlDKaCJOjoGVaJO68ivfmmsg- X-Yahoo-SMTP: LAFNfTaswBDguI7meB90l2l3wOU- Subject: Re: FreeBSD Home Page References: <54488826.9090908@freebsd.org> From: by Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (11D257) In-Reply-To: <54488826.9090908@freebsd.org> Message-Id: Date: Thu, 23 Oct 2014 12:50:04 +0800 To: freebsd-hackers@freebsd.org Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 04:50:17 -0000 Yes. by > On Oct 23, 2014, at 12:46, Allan Jude wrote: > >> On 2014-10-23 00:41, by via freebsd-hackers wrote: >> freebsd.org home page seems strange with "Production" and "Upcoming". >> >> by >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > Er, ohh, I see what you are talking about. The entities seem to be broken. > > -- > Allan Jude > From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 23 04:57:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D13A2307 for ; Thu, 23 Oct 2014 04:57:33 +0000 (UTC) Received: from nm13-vm5.bullet.mail.ne1.yahoo.com (nm13-vm5.bullet.mail.ne1.yahoo.com [98.138.91.235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8EAB1800 for ; Thu, 23 Oct 2014 04:57:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1414040246; bh=Z9uMYSpniWO4sRQoIAJ8LfM4Z0DDf9ILTOCXmN0u9s0=; h=Subject:References:From:In-Reply-To:Date:To:From:Subject; b=ab97iY94dl8IGdgQflUKAO+WQnDc7TJaNrcV1mpobn3Cz7fSdw205rFwGt9ZzjpBPsgGFUZEfxVch1UUv/I6y+j8edvbhUjmk4o6ymPL68hExxKFMUojZANzzMfsyPs9mROEiyl7RdIIElgbb8dw9b1VPdICiMfUfwPvmvQZvVULAIn34Ll0sPHTGb95Aan6xxM0H/20vLKVYLIavZk/cU1EH6SB51piF+G6RIIAZPHX+Ge72VQLzqXckrGM5cTG/eSZP/Cngm71/QFwyNR9wlWrXGjxvR1iRaJqsKuSTi4R8bm5JdNqOYJzmGwleB3KMgvLGkLJGlkh3gigyiXV4A== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=a+oEbryhtPJhCbw3DmCfUGBoWDzsn4kLqQnxONqCAWuKkSqOGIz4MT2fKqL1ykhf0EBMzG7c9fMETvGdqrBXSo9fuQeAWiGwlUl8zBQKql+rtNAgqgkn4MBE7RYiByudcWQuNJbzW9cABe36nNXgP9rvwFqgBsmcFAXylyRICgqpb3Y5pWLBw/M0GikkUd6pQu9ntEpEbhQVtTWCTDuoDFqtD7zoX7L+zDq6a1Wn8eKFPV4iFWI9ydVHdEnO0iwYZKGLmMdgHAU8mtdNC2zK2SoOlAZ7UaNPeER0NIGWP7JLSfpZ/s7x68vcLCRv+z39ihEcT3JljkrpZE94whHDug==; Received: from [98.138.100.103] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 23 Oct 2014 04:57:26 -0000 Received: from [98.138.84.44] by tm102.bullet.mail.ne1.yahoo.com with NNFMP; 23 Oct 2014 04:57:26 -0000 Received: from [127.0.0.1] by smtp112.mail.ne1.yahoo.com with NNFMP; 23 Oct 2014 04:57:26 -0000 X-Yahoo-Newman-Id: 5384.68704.bm@smtp112.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: JIIVmzQVM1kKZXsfUBiVXht9_cGZGayszlCYfWObKE2161y leMnrQV05pnxpBUHf9LaSFpTxuPTd3EdpHmZkXOyewL7t34VvMUTaH8850Fu e.7n5Hh5qRfqjhFBa9xpPRHknr6tYcstSgmXfkEq.yVIEYziwf40._HNHqwp 9zuucFpgKwP_mV1aEvBUs9T2NiC3R7SlzZSjN2lJ4p3bWQ9pWB7jcH0TSSmt Ku.5mFdek_DHIFNfc7qjx4rKGmpXKtbYIAJfO6MxPQch1FlxgtwmSvQmXf52 YosIKlIED7HogabePQkhHMixHVLYztw3P69UQATdZZsM_g4qxNLd5RJUyoNy PYshpIt80cnq04XofEHK.WdLmmkahcOfl5jq0tOJ4SIxsZ_tpBktJEXVFb9q WYbk1IO9IyF80YktGlgb4yaecXkkTlgQCApI07_Ophb09ID5q8r_gEVkmkRJ DXSWMb9N7uVzgYkrUssj9HumoDwVmoRRLUy8F7YZg9E3naPEbHArxzAYuGmz 7zET2CGXnPrhu0dF7szDHOVT9K.SSwyXNXUooC77xx4Jvdp41 X-Yahoo-SMTP: LAFNfTaswBDguI7meB90l2l3wOU- Subject: Re: FreeBSD Home Page References: <54488826.9090908@freebsd.org> From: by Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (11D257) In-Reply-To: <54488826.9090908@freebsd.org> Message-Id: <384B87AA-4255-4A8A-B464-8C44BC507592@yahoo.com> Date: Thu, 23 Oct 2014 12:57:19 +0800 To: freebsd-hackers@freebsd.org Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 04:57:33 -0000 I think it needs fix. by > On Oct 23, 2014, at 12:46, Allan Jude wrote: > >> On 2014-10-23 00:41, by via freebsd-hackers wrote: >> freebsd.org home page seems strange with "Production" and "Upcoming". >> >> by >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > Er, ohh, I see what you are talking about. The entities seem to be broken. > > -- > Allan Jude > From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 23 05:10:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 427304D5; Thu, 23 Oct 2014 05:10:42 +0000 (UTC) Date: Thu, 23 Oct 2014 05:10:37 +0000 From: Glen Barber To: freebsd-doc@FreeBSD.org Subject: Re: FreeBSD Home Page Message-ID: <20141023051037.GB1237@hub.FreeBSD.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jho1yZJdad60DJr+" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 05:10:42 -0000 --jho1yZJdad60DJr+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Oct 23, 2014 at 12:41:59PM +0800, by via freebsd-hackers wrote: > freebsd.org home page seems strange with "Production" and "Upcoming". Copying the proper list. Glen --jho1yZJdad60DJr+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUSI3NAAoJEAMUWKVHj+KToGQQAJiHFA8bSDefewSO0YAU9fPV gJYrm03nq98KN1VNO5aRM1mAUC7r4rZS5ePN3fxedjY3hZ6R0/PrtHTxdABT8IKh EtxcTnXrrohhtuzg8yjwwNQPxVL1awCDWSiuY6n0z3PeaRDgZ9WB7X/VN5pwDBUe o8hY1EN/RFPN7XaUOEqBjfsK1o/RY1QGuCbZcK79fhywZJttw1kfVDI7kjx35kM5 MynE/nGjBjSBY4dpN0Ma5xbErIF63GVzDWuS1h5FogNuU/RmnTEtzdvYerNnQiAj zMNmZKOGvSbmakwAgk4O1aKB/9Bms4FMCxRc6giHb8Ve8VsNmTuku3YoTKTmZj39 /6PZ7B5zsY/MKEbXRdU9tmFiN4aG4mNdpqdPuW4uhiUrsbnoSqgO0oyP3WeTy097 k0YMiQSMp/wrt3G84G7vsANa8X4cIqQCRtRjdM+Vs5j12n6Nge64ObQbhnLaF3P7 DXQ3QiJKR3gAiJ5z0OtvuUj2K/MGunxpSCa1geRxZY1X59TGJbeQU6qDrNuXfzcp 85U8QBAfzUfiau9heKxUkHtBMSAgfRKM0n1R7GNKwESpI3Go76LatNimjI6qDLWl bfV1rw8jZXghLq2SR4j9gmDlZOYz5FuEWc3JAEXIoZkbZ7h7VWmJgQUp4JnXXaZO GSyawLHJZOwLHP/Ty0Xu =hD/a -----END PGP SIGNATURE----- --jho1yZJdad60DJr+-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 23 05:10:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A60C5F7 for ; Thu, 23 Oct 2014 05:10:56 +0000 (UTC) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D138958 for ; Thu, 23 Oct 2014 05:10:55 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id wm4so198901obc.26 for ; Wed, 22 Oct 2014 22:10:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=1/6xB5DzCPiGNlcqLSP+GHwvatuXC/IjatklkBhbRjs=; b=LRFqGeZeb+DWKunsh1+JeopCWzMFo3MmmOMFwmcjBDQAbKTLoZYNT8Q04rAniBIcZd KwJ7f0TbqghSzDoNFBJbBBuiF5BETsNxLhaa833aKhoaBE1PbQHghgYrPuvz8jO9TXRR xSSd8sd5YU41WtdlrI6hSBveGydfRF4UIzGhu34q8Gf3mdMuzFnSSi4q2YffON+cOFDr VuQrnvn6wyktyxipGVOm1zMjdluJiTqzkRUsnHP+VTTFsXGBCV8YiO0PJt39WtUaWmqW EcJ5YeieItN3bw40kWvtF54TMdOHdmNF4ES042Khic7MI5SgoKAbuzpKHvDotKhqECYl qoZQ== X-Gm-Message-State: ALoCoQnnepVU7tQpf7vGUj1EnjE0YyzU49d2a3qYeeDSJlZgZY81t/gNUyq7mKq3t6b4WaXVXnV5 X-Received: by 10.60.177.137 with SMTP id cq9mr268258oec.45.1414041049080; Wed, 22 Oct 2014 22:10:49 -0700 (PDT) Received: from [172.21.0.83] (65-36-83-120.static.grandenetworks.net. [65.36.83.120]) by mx.google.com with ESMTPSA id ln10sm388242obc.24.2014.10.22.22.10.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Oct 2014 22:10:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: nosh version 1.9 From: Jim Thompson X-Mailer: iPhone Mail (12B411) In-Reply-To: <54488557.1080103@freebsd.org> Date: Thu, 23 Oct 2014 00:10:47 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <54430B41.3010301@NTLWorld.com> <5443191E.5050208@mu.org> <34F30D28-DE9B-444F-885E-F438FEEA46EC@mu.org> <54482A5E.2050303@NTLWorld.com> <527291AC-C5E2-420C-B566-C051BA82CA84@turbofuzz.com> <54488557.1080103@freebsd.org> To: Allan Jude Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 05:10:56 -0000 > On Oct 22, 2014, at 11:34 PM, Allan Jude wrote: > > The nice thing about this design is that it would allow replacing the > XML with something more human readable/writing like UCL. Dude, that's not web-scale. You're gonna want yaml. From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 23 05:13:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 244FC71E for ; Thu, 23 Oct 2014 05:13:39 +0000 (UTC) Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D9CEC97B for ; Thu, 23 Oct 2014 05:13:38 +0000 (UTC) Received: by mail-oi0-f53.google.com with SMTP id v63so189687oia.40 for ; Wed, 22 Oct 2014 22:13:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=AJbGRswbzM6SwL7x+hfONtPToW3IDVnRGqkSsY/prwY=; b=eSwXi3MvxM8zG4OMUHbq7wXt3bisOzmu9LQwpXVwOqOV6QW0/G3lOxYGobrhGqkfgC 9iKvcTaJJCcYaj0SZagR9dv7XvAN3HmLHPYCnyYWg9imO/OqWgj566rEOCAdlCD03HBy bfJEAXlsgg0NOx9xYLh9NHsveot9ydD1uUe/4eMdnVmnufzGfvG3b6yvnHtk+SB21Fwe DDMh16dpz1ZWH78H5D1OPCB3uLm/9mmjgpw8nGyf4+TcbE9Zm41iRJ6WzyI8Q4BkZ0/K 69eR8Mgc5+jifTdu2dCZJyW/r/6oWbT/WKc7mxrEM6kzadrHBCUSYXNJyPjuvkrat6vR FOzQ== X-Gm-Message-State: ALoCoQnJIo//1JohiDgQx6yasYC5NQ7zS0/f076lUqFHUDnkAEYYVh0JC17CVW3kO1deqEHrKMFk X-Received: by 10.60.62.8 with SMTP id u8mr2181609oer.39.1414041211508; Wed, 22 Oct 2014 22:13:31 -0700 (PDT) Received: from [172.21.0.83] (65-36-83-120.static.grandenetworks.net. [65.36.83.120]) by mx.google.com with ESMTPSA id 66sm391010oid.20.2014.10.22.22.13.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Oct 2014 22:13:31 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: nosh version 1.9 From: Jim Thompson X-Mailer: iPhone Mail (12B411) In-Reply-To: <527291AC-C5E2-420C-B566-C051BA82CA84@turbofuzz.com> Date: Thu, 23 Oct 2014 00:13:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8CF2B921-A3A6-49CF-A759-0808FA6F35AB@netgate.com> References: <54430B41.3010301@NTLWorld.com> <5443191E.5050208@mu.org> <34F30D28-DE9B-444F-885E-F438FEEA46EC@mu.org> <54482A5E.2050303@NTLWorld.com> <527291AC-C5E2-420C-B566-C051BA82CA84@turbofuzz.com> To: Jordan Hubbard Cc: Outback Dingo , Jonathan de Boyne Pollard , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 05:13:39 -0000 > On Oct 22, 2014, at 9:49 PM, Jordan Hubbard wrote: >=20 > launchctl(1) does all the XML parsing and then passes the results to launc= hd using its own custom IPC format. Was there some particular reason you vi= olently inserted the XML parsing directly into launchd after the original ar= chitect(s) went to such pains to avoid such blatant penitentiary experiences= ? They forked pfSense.=20 See figure 1.=20 (Even I, lead on one of the larger consumers of XML in freebsd, think it's abhorrent.)= From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 23 05:15:35 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7569286D; Thu, 23 Oct 2014 05:15:34 +0000 (UTC) Date: Thu, 23 Oct 2014 05:15:31 +0000 From: Glen Barber To: freebsd-doc@FreeBSD.org Subject: Re: FreeBSD Home Page Message-ID: <20141023051531.GC1237@hub.FreeBSD.org> References: <20141023051037.GB1237@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bAmEntskrkuBymla" Content-Disposition: inline In-Reply-To: <20141023051037.GB1237@hub.FreeBSD.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Thu, 23 Oct 2014 05:18:31 +0000 Cc: FreeBSD Documentation Engineering Team X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 05:15:35 -0000 --bAmEntskrkuBymla Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Move hackers@ to BCC to prevent further noise there, added doceng@.] On Thu, Oct 23, 2014 at 05:10:37AM +0000, Glen Barber wrote: > On Thu, Oct 23, 2014 at 12:41:59PM +0800, by via freebsd-hackers wrote: > > freebsd.org home page seems strange with "Production" and "Upcoming". >=20 > Copying the proper list. >=20 This is related to one of the recent textproc/libxml2 updates, confirmed locally. Either ports r371120 or r371269 is suspect here. Glen --bAmEntskrkuBymla Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUSI7zAAoJEAMUWKVHj+KTEU4P/iqkrYHO5IzwKt0nlzDNecgZ GKcqs+bbUWmeyHG0vsMYGOhBbOBX3w5ThwVXXQHxzyMzSsz3gSj4bXcbIo7qn4bc sELHDeN6m8JMLY0XCA3296cR+wCmCI8U6cBeHt8XLTgObPrI3BujrEAp7i1k5fdN /AKbxTc1890s3Z1R2h+h3Evs5TRiz1Ia1EVZsoGE5nbJt/8MjHzZVgw0nfddvNiv tzLECPO0iGfli77v0d/PwgQrMmtzLxCOJuagsb9sAxdtYDDRFRzwyy3vLoNRaoA6 lFIQ1tr9tJvUTG4yI7VbO+tDKiUFgOA9LoboJ2sm4+hEUQh8RB4o1f3EqCOehXQf O5Tv9RrHrKE8pSGVDAdp6EXAbINq+R3fTXMdOJV8CMU/2vbVljRBiwMD0dV7KpTr BrJxcA2ArK35T4PyT+4o7F6eAn5EHyHqLDdQghP35Qy7HThknlLOW8S0vu2rSLaF DUfahE7o+1cYmhM7ZzsLkwKilG2yNz+ALkJVgahq40DWjp1MleAVMf77WbLKttFS VqvWBzZZ0VXJkJMGNz2u1dXnNkqOl6tEkgu3DVZzeYaec79L+S9GTtusBfhaZtTc YkKJHfvC5BRDH7SVcpahyioYAtLeEmi2VyErUz+QZQAK401SnXV6r2qpLcWjHVSv +rmwEQ/TMeBLymktzLgj =BGcJ -----END PGP SIGNATURE----- --bAmEntskrkuBymla-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 23 05:35:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0EB8B4D for ; Thu, 23 Oct 2014 05:35:56 +0000 (UTC) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B4908B1C for ; Thu, 23 Oct 2014 05:35:56 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id nt9so252032obb.29 for ; Wed, 22 Oct 2014 22:35:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ECIOiFOsoANbG82fhS9EBjZei1VUfsfl7G24/rr/LOU=; b=M+6MIMAsdWHu/hj3LswRoqBF5iBXwiJbPppRdiFrEDZzzPUbxvt1uBdFSsgiBOcKVr mQjjH+NOHi4hryLhvKSrn/+fp30LwL0BkuFaacXnkZfd7Q+nn+m4rieQzZ1N3dUnpYFj dMwvbRP8BUObCroKVy6aAYgzaSy0rArZ6ykG2NpkbIH0vdV4uTqkY2GdWx9WlmfoQEyT rQE0Eq0elFjQXpLqo37zoip/ejAz0vwScVAPtIA0skg5sH4qtRpm14BhJ2UKtQfbA79P poaRB9MMdwdtVfYveYbe9T94JTg/RbE/O5EN05KrejXgqcPj2eSSeCqfxDg7mdEd8I/8 U2Bg== X-Gm-Message-State: ALoCoQmEQUGj+QNOP86EuFYV/+iz03aYlJeSf9wT6SsyrIzDv5ZdiF0FhnYdeqrs5lROMVS80KiN X-Received: by 10.60.38.1 with SMTP id c1mr93439oek.51.1414042117305; Wed, 22 Oct 2014 22:28:37 -0700 (PDT) Received: from [172.21.0.83] (65-36-83-120.static.grandenetworks.net. [65.36.83.120]) by mx.google.com with ESMTPSA id sm4sm396657oeb.7.2014.10.22.22.28.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Oct 2014 22:28:36 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: nosh version 1.9 From: Jim Thompson X-Mailer: iPhone Mail (12B411) In-Reply-To: Date: Thu, 23 Oct 2014 00:28:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54430B41.3010301@NTLWorld.com> <5443191E.5050208@mu.org> <34F30D28-DE9B-444F-885E-F438FEEA46EC@mu.org> <54482A5E.2050303@NTLWorld.com> To: Jordan Hubbard Cc: "freebsd-hackers@freebsd.org" , Jonathan de Boyne Pollard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 05:35:57 -0000 > On Oct 22, 2014, at 6:10 PM, Jordan Hubbard wrote: >=20 > That=E2=80=99s actually one of the more elegant aspects of its design! Now I'm waiting for esr to appear and explain BCPL to Robert Firth.=20 https://groups.google.com/forum/m/#!topic/comp.arch/GUA7AtDPy84= From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 23 05:41:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 047F4C60 for ; Thu, 23 Oct 2014 05:41:13 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id CD229BD5 for ; Thu, 23 Oct 2014 05:41:12 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 7B1A86368D for ; Thu, 23 Oct 2014 05:41:11 +0000 (UTC) Message-ID: <544894FB.4060607@freebsd.org> Date: Thu, 23 Oct 2014 01:41:15 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: nosh version 1.9 References: <54430B41.3010301@NTLWorld.com> <5443191E.5050208@mu.org> <34F30D28-DE9B-444F-885E-F438FEEA46EC@mu.org> <54482A5E.2050303@NTLWorld.com> <527291AC-C5E2-420C-B566-C051BA82CA84@turbofuzz.com> <54488557.1080103@freebsd.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T0eeoSOF9biSWsNea0LEPGc1mPRR3svIH" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 05:41:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --T0eeoSOF9biSWsNea0LEPGc1mPRR3svIH Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2014-10-23 01:10, Jim Thompson wrote: >=20 >> On Oct 22, 2014, at 11:34 PM, Allan Jude wrote= : >> >> The nice thing about this design is that it would allow replacing the >> XML with something more human readable/writing like UCL.=20 >=20 > Dude, that's not web-scale. You're gonna want yaml.=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 UCL can read YAML and JSON, it is just less sensitive than either, so missing whitespace, or a trailing comma won't break the parsing of your config file. (A trailing comma on the last array element is nice to have, as it reduces the diff when you add a new item) So it means the config files can be valid JSON or YAML, or something that looks similar but is less fussy, so that it is more human writable. --=20 Allan Jude --T0eeoSOF9biSWsNea0LEPGc1mPRR3svIH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUSJUCAAoJEJrBFpNRJZKfDpQQAINsALgmwrDpDWXiWEsnXhfX Pk7A6Qqd+p3z8A4+9bT07iv4HpASZ0yVb0ht9HyfxV45PcxXAi8m/B4Oc3HWP6xn sADPPEaV/VQA3PyRc/u99GdWNqmtpJviKGGGPcXCFCHTlm/RpR/g0iPEdMB2jRNk Jvor0PUQspvfNjZ6ksF9UgU7jtoiCRtj1MV2UaCQXljeeusaINty/KaVLYGrKaul /EtWWNdYcjH28xNJ4xv3Hn2J5JrbANoPwsiUM9MqIxmyPVlGHJc9g27AxS7Kmmhy 77d6astvPZRvqdu9WxpAR4U4LOXX1YWnBBssIs2ak2t+4TUOmwY1OIGN8ZlSDnrD ef+loph5+1V+uEVUZhq/7VwvhL82LaK/r8qfPawpvjjZlQY51FCNss5/1LyWWkP9 9FbEg05JLN3xxyWr14mUc9cu0q78JOceo8JEoA7rmu/jJ6Y3ngPZNDeZoZN3oVIH 6Rf8VEYHJpOMdEXYP93KWh9uJkSyzGg39SdZJuqRvRbF895Kimet/fZerPIxx6zp 8kA97wHMbnvOfcMrS/hkg7gID5jqK4ae+rDTmbXWOKd2WrkoKDEUZXosSAusRQlP E/41d/6EwZ00LN9p3sVrf+gsuj7BpKRJpoEEvXuu7hDnZlupSAVWwKvQj2Ce+DTT V+s+eAFnJasDyBv9/77T =1O5s -----END PGP SIGNATURE----- --T0eeoSOF9biSWsNea0LEPGc1mPRR3svIH-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 23 06:08:03 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB13A3D0 for ; Thu, 23 Oct 2014 06:08:03 +0000 (UTC) Received: from mail.iXsystems.com (mail.ixsystems.com [12.229.62.4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C21DDC9 for ; Thu, 23 Oct 2014 06:08:03 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id ADB22882D4; Wed, 22 Oct 2014 23:08:02 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 71212-09; Wed, 22 Oct 2014 23:08:02 -0700 (PDT) Received: from [10.20.30.117] (75-101-82-48.static.sonic.net [75.101.82.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 8393A882D1; Wed, 22 Oct 2014 23:08:00 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: nosh version 1.9 From: Jordan Hubbard In-Reply-To: <544878B4.1060804@mu.org> Date: Wed, 22 Oct 2014 23:07:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3E97280E-D38A-4085-A4DD-03C181F47BF5@mail.turbofuzz.com> References: <54430B41.3010301@NTLWorld.com> <5443191E.5050208@mu.org> <34F30D28-DE9B-444F-885E-F438FEEA46EC@mu.org> <54482A5E.2050303@NTLWorld.com> <527291AC-C5E2-420C-B566-C051BA82CA84@turbofuzz.com> <544878B4.1060804@mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1990.1) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 06:08:03 -0000 > On Oct 22, 2014, at 8:40 PM, Alfred Perlstein wrote: >=20 >> launchctl(1) does all the XML parsing and then passes the results to = launchd using its own custom IPC format. Was there some particular = reason you violently inserted the XML parsing directly into launchd = after the original architect(s) went to such pains to avoid such blatant = penitentiary experiences? :-) >>=20 > I could see the utility of that. One of our senior full stack devs = says that XML is "triggering" and that they wouldn't want to work on = such a system. Perhaps it's to keep web people out? Well, whatever the rationale the pfsense-forkers (that sounds dirty) = might have had, I think it=E2=80=99s fair to say that this is an = abstraction layer that would be easy to add back since it exists that = way in the original source code base, and I would certainly be happy to = see it done (it could be done via a socket and a -h argument = added to launchctl if =E2=80=9Csomething other than Mach ports=E2=80=9D = was the desired IPC mechanism and you even wanted to be able to drive a = remote launchd through its paces). Either way, it=E2=80=99s the = launchctl(1) command that ought to speak XML or YAML or any other = reasonably structured format people like. Not embedding it in launchd = is good for a lot more than architectural cleanliness. As far as Mach IPC is concerned, it=E2=80=99s so prevalent in OS X and = iOS largely because: A) It=E2=80=99s already there. B) The Mach port space confers certain security advantages (port rights, = bootstrap sets, security trailers on all IPC). C) It=E2=80=99s easy to create interfaces for it (MiG isn=E2=80=99t = pretty, but it=E2=80=99s more than you get with sockets). However, given that launchd starts up as pid 1 and can bind to a = suitably secure low-numbered port for IPC (making it correspondingly = harder to spoof launchctl) I don=E2=80=99t really see any reason, other = than code compatibility, not to use another IPC mechanism in FreeBSD. = I=E2=80=99d kind of like Mach ports in FreeBSD just to remove this final = barrier to compatibility for a wide range of software that would = otherwise cross the divide, but I also get that they=E2=80=99re a bit = retro. - Jordan From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 24 05:37:03 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99A4EF0F; Fri, 24 Oct 2014 05:37:03 +0000 (UTC) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 51CA693D; Fri, 24 Oct 2014 05:37:03 +0000 (UTC) Received: by mail-yh0-f54.google.com with SMTP id 29so3062252yhl.27 for ; Thu, 23 Oct 2014 22:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=c6ZkRAUbIRWwGH3uHVrRkYWQynjytiqagvAo0EHCMk8=; b=caoPG358yUXk1XmE4nHevt5MDsb+Ok3Z9sL+gc8RsTBFqgSavjZgnYoaucMNNaat2L 830WK0a2gswGjPF5qvU6YjNDWwB3dbQ0MmToxV6TzOpPP7RTgO2gJczfEmbnWTlvAAHF t2/sudRUcLTdZwJ42grn9kt8amjqbTYPrxtR7IpPOuPGzBaWqRsYzVeKsKchh4ZhH5g3 d4pQdTzCz9U93k4pRI59noCm7mCMP3Or4hOwXVnzX97eRDOaDCgl6jt6DIGN8BEcMeum XQXUQt4KL+3dK8EM0zOjDl/uQvjur/bAaaUjWtNjqEadufvQkOIX0hdhbEe5fVyRtPNO DVAQ== MIME-Version: 1.0 X-Received: by 10.170.199.138 with SMTP id q132mr2981290yke.17.1414129022593; Thu, 23 Oct 2014 22:37:02 -0700 (PDT) Received: by 10.220.238.14 with HTTP; Thu, 23 Oct 2014 22:37:02 -0700 (PDT) Date: Fri, 24 Oct 2014 01:37:02 -0400 Message-ID: Subject: ZFS errors on the array but not the disk. From: Zaphod Beeblebrox To: FreeBSD Hackers , freebsd-fs Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 05:37:03 -0000 What does it mean when checksum errors appear on the array (and the vdev) but not on any of the disks? See the paste below. One would think that there isn't some ephemeral data stored somewhere that is not one of the disks, yet "cksum" errors show only on the vdev and the array lines. Help? [2:17:316]root@virtual:/vr2/torrent/in> zpool status pool: vr2 state: ONLINE status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scan: resilver in progress since Thu Oct 23 23:11:29 2014 1.53T scanned out of 22.6T at 62.4M/s, 98h23m to go 119G resilvered, 6.79% done config: NAME STATE READ WRITE CKSUM vr2 ONLINE 0 0 36 raidz1-0 ONLINE 0 0 72 label/vr2-d0 ONLINE 0 0 0 label/vr2-d1 ONLINE 0 0 0 gpt/vr2-d2c ONLINE 0 0 0 block size: 512B configured, 4096B native (resilvering) gpt/vr2-d3b ONLINE 0 0 0 block size: 512B configured, 4096B native gpt/vr2-d4a ONLINE 0 0 0 block size: 512B configured, 4096B native ada14 ONLINE 0 0 0 label/vr2-d6 ONLINE 0 0 0 label/vr2-d7c ONLINE 0 0 0 label/vr2-d8 ONLINE 0 0 0 raidz1-1 ONLINE 0 0 0 gpt/vr2-e0 ONLINE 0 0 0 block size: 512B configured, 4096B native gpt/vr2-e1 ONLINE 0 0 0 block size: 512B configured, 4096B native gpt/vr2-e2 ONLINE 0 0 0 block size: 512B configured, 4096B native gpt/vr2-e3 ONLINE 0 0 0 gpt/vr2-e4 ONLINE 0 0 0 block size: 512B configured, 4096B native gpt/vr2-e5 ONLINE 0 0 0 block size: 512B configured, 4096B native gpt/vr2-e6 ONLINE 0 0 0 block size: 512B configured, 4096B native gpt/vr2-e7 ONLINE 0 0 0 block size: 512B configured, 4096B native errors: 43 data errors, use '-v' for a list From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 24 12:15:59 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E64B2AD4 for ; Fri, 24 Oct 2014 12:15:59 +0000 (UTC) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 723E6AB0 for ; Fri, 24 Oct 2014 12:15:59 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id s18so2538162lam.37 for ; Fri, 24 Oct 2014 05:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-transfer-encoding; bh=/eWaR/TZFxCCS2MWTSSZzCAzRsjINS1WC2cs9C8S6aA=; b=j1tGPeSlIpgt9zSCjIXh+m8D7RvEH3cD7Q/D8+AXFNv2Gp6TMQ13L/dT5gcK0GCDHH dhUIkxFw1Z0ElakT+AmMyFcqkY90gW5HvG+GFOCGYopqw9gBTPzxtLci0JN9zt/mfVJD hvy0Pv2dtDUQu1NhKgsfvdIUUuwbtPS3vyB5cN4cBqUT+0kH7C30Tg1VEOVvtlbhGr3e OjOh130unRWlj6YZXF7Z59Q6ZkOS3Ct8SJ+rz0AIJH+qmZrSwCWOhpN41VIZ6PPpTJU4 1ALHqkRyPLwbgES0UK59ON3qbj92v2cGPMlQCrS2oJo4qoBRSrj336kB3utRrtjnQQE6 6sjg== X-Received: by 10.112.137.202 with SMTP id qk10mr4187319lbb.0.1414152957493; Fri, 24 Oct 2014 05:15:57 -0700 (PDT) Received: from localhost ([82.193.208.225]) by mx.google.com with ESMTPSA id w8sm1797940lbp.46.2014.10.24.05.15.56 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 24 Oct 2014 05:15:56 -0700 (PDT) Date: Fri, 24 Oct 2014 14:15:52 +0200 From: To: freebsd-hackers@freebsd.org Subject: tar behavior 9.* -> 10.* Message-ID: <20141024141552.000048ac@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 12:16:00 -0000 https://forums.freebsd.org/threads/tar-errors-when-file-content-extracted-to-stdout-is-piped.48626/ Bug? From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 24 14:43:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 120AA866 for ; Fri, 24 Oct 2014 14:43:31 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id E0398D3D for ; Fri, 24 Oct 2014 14:43:30 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 0BC6764A44; Fri, 24 Oct 2014 14:43:24 +0000 (UTC) Message-ID: <544A6595.2070204@freebsd.org> Date: Fri, 24 Oct 2014 10:43:33 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rank1seeker@gmail.com, freebsd-hackers@freebsd.org Subject: Re: tar behavior 9.* -> 10.* References: <20141024141552.000048ac@gmail.com> In-Reply-To: <20141024141552.000048ac@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="836KVKkt9jNBMe1IUUViDkJ3ngT11f5NQ" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 14:43:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --836KVKkt9jNBMe1IUUViDkJ3ngT11f5NQ Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2014-10-24 08:15, rank1seeker@gmail.com wrote: > https://forums.freebsd.org/threads/tar-errors-when-file-content-extract= ed-to-stdout-is-piped.48626/ >=20 > Bug? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 What happens if you pipe it to something that doesn't close the pipe prematurely try: tar ... | cat - It makes sense that it throws an error when you pipe to head, which then closes the pipe before the file has finished being written. --=20 Allan Jude --836KVKkt9jNBMe1IUUViDkJ3ngT11f5NQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUSmWeAAoJEJrBFpNRJZKf5cAP/A3P8B7AqHuQQDzv7INpoNg7 hPUhiUkymg7FSi2hsxlT9WGSXiXemgGWsn0FkzkQY6ndVfyqPEHpZQd1YHPvtf67 h/yR/E3zj+joQLijRhTYEDds739eSOzjbeQyopjcvRZMLvOax9JuXuDhevWZt0D7 P40bVAGbRKQDnecAwod4uA6YNGtErie2FzWfzxePnmEwF7R6B889hr2eDZck7sW/ 8glwVL5tyUi5MIodqixAtaxacOkEn63PqmJfZPyI5h5ph3U23+oEUOIU+lz+xC12 jesIOKAV1lMukiRea9/vfI5L2/teA8Os/L1DVFpHlPXniLzIRY+If2Bzpl5Xvnb9 wlfPMvEX+8W5oT0fMjZXTlFt3T4uxFmlwXEhzsojjl09wSFRXKxm5RP+uV1QCfv5 4PMDQOGJo/+rRh5NzbO/VjnQ1KoAsXuuFW+8BLoTjW60AJ76RuRH+muLnmyHpaqG bhMA4LIw9BaJTfLJi9awlrilfEVfMFm89PJ0xdNgTUbD02IWKJ0bQJ6F3bP9Un0Q D45IaGbEoOXUR5rZwxWlG3tndgQJsG/uy0KaavK7/YSw2fwtthxBvITSc1N2BtgO nzQyHjCVuZ5qzNKxpMsdfRdR7EMJAlkVdHgRDCEHFpaPdUMcTi6s0k35AJ0dOsKj T5lVWJIJG8XOnvjh53ix =t1Gj -----END PGP SIGNATURE----- --836KVKkt9jNBMe1IUUViDkJ3ngT11f5NQ-- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 24 15:00:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C307CB09; Fri, 24 Oct 2014 15:00:56 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 80ED0E82; Fri, 24 Oct 2014 15:00:56 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id AEE4E64AE8; Fri, 24 Oct 2014 15:00:55 +0000 (UTC) Message-ID: <544A69B8.4020402@freebsd.org> Date: Fri, 24 Oct 2014 11:01:12 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Zaphod Beeblebrox , FreeBSD Hackers , freebsd-fs Subject: Re: ZFS errors on the array but not the disk. References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wkWRSt1dVbA0301swoKKkbEhTwaA6GPvs" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 15:00:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wkWRSt1dVbA0301swoKKkbEhTwaA6GPvs Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2014-10-24 01:37, Zaphod Beeblebrox wrote: > What does it mean when checksum errors appear on the array (and the vde= v) > but not on any of the disks? See the paste below. One would think tha= t > there isn't some ephemeral data stored somewhere that is not one of the= > disks, yet "cksum" errors show only on the vdev and the array lines. H= elp? >=20 > [2:17:316]root@virtual:/vr2/torrent/in> zpool status > pool: vr2 > state: ONLINE > status: One or more devices is currently being resilvered. The pool wi= ll > continue to function, possibly in a degraded state. > action: Wait for the resilver to complete. > scan: resilver in progress since Thu Oct 23 23:11:29 2014 > 1.53T scanned out of 22.6T at 62.4M/s, 98h23m to go > 119G resilvered, 6.79% done > config: >=20 > NAME STATE READ WRITE CKSUM > vr2 ONLINE 0 0 36 > raidz1-0 ONLINE 0 0 72 > label/vr2-d0 ONLINE 0 0 0 > label/vr2-d1 ONLINE 0 0 0 > gpt/vr2-d2c ONLINE 0 0 0 block size: 512B= > configured, 4096B native (resilvering) > gpt/vr2-d3b ONLINE 0 0 0 block size: 512B= > configured, 4096B native > gpt/vr2-d4a ONLINE 0 0 0 block size: 512B= > configured, 4096B native > ada14 ONLINE 0 0 0 > label/vr2-d6 ONLINE 0 0 0 > label/vr2-d7c ONLINE 0 0 0 > label/vr2-d8 ONLINE 0 0 0 > raidz1-1 ONLINE 0 0 0 > gpt/vr2-e0 ONLINE 0 0 0 block size: 512B= > configured, 4096B native > gpt/vr2-e1 ONLINE 0 0 0 block size: 512B= > configured, 4096B native > gpt/vr2-e2 ONLINE 0 0 0 block size: 512B= > configured, 4096B native > gpt/vr2-e3 ONLINE 0 0 0 > gpt/vr2-e4 ONLINE 0 0 0 block size: 512B= > configured, 4096B native > gpt/vr2-e5 ONLINE 0 0 0 block size: 512B= > configured, 4096B native > gpt/vr2-e6 ONLINE 0 0 0 block size: 512B= > configured, 4096B native > gpt/vr2-e7 ONLINE 0 0 0 block size: 512B= > configured, 4096B native >=20 > errors: 43 data errors, use '-v' for a list > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 I am guessing they were on the disk that is now resilvering. I am not sure if resilvering causes the devices error count to get reset, but it would make sense if it is considered a 'replaced' disk. --=20 Allan Jude --wkWRSt1dVbA0301swoKKkbEhTwaA6GPvs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUSmm6AAoJEJrBFpNRJZKflAkP/Re9F3VJOXgQQSJbG8jV0fO/ n6EzHLVUezMJUndq26DX6zzsuXl/7uSAXoxMoY52i5M2nf3DmK1n0Nn1cx+/k9Mx 4vDKWSIhrZsWfoHPR8aJHjIUYd2SPdEcmmrXb5N21YVencPtzqfHjyvCWf71kx8A ZJsqQQ1CBAh0jfcPmGJXXLxbj/8I7LTW7JCAdsZX942SYx9D6qi45uD9mObw/DfJ QWFrFS/JrjBMHjnIUaSMmElpoHuXYekpdS7bpAE2B6jsXNh26aVmb2QEA/w4gmK9 2JE9Q/NBYx0E31m5kYfooQVXczvDo5fV/dNBqF8tNIOFtqLOi0b3I34mwH1uu+uy 28JMQf2OxW8PWkpGbe4X9D6CBqV0vZbM74zRsdkNneCUlbGL5ETbSNDbt3w4Z/Gc c6Mdx4uOulYGIqdp0Gb9/2SJgFrmQq/vNkzNPFkg3urzm/y6R/VlcqUbLDpG/JOH SKRoDcKyWSyAMBE7bN7Tdg6Atf2kNSJGTFkgLrJ4S+tLpjHFHg6vuJs2NEDlVZ+0 3p5RvsjKfz+H/3WLyrIaqPXVYS1PCugMCGTDC3TCdtbMBHzl6yrCmj2vJYsM4H0c Cdvfy0wUTFnAXxb7BLFakrIMybhxEHhfgFVx60jN4jmWAmFtd6FYf5cdL4KkG2AL msJ7+3WYt7ZvRCPi10ip =2rG4 -----END PGP SIGNATURE----- --wkWRSt1dVbA0301swoKKkbEhTwaA6GPvs-- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 24 15:33:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10F94563; Fri, 24 Oct 2014 15:33:25 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 78FFC33F; Fri, 24 Oct 2014 15:33:24 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id a1so1328591wgh.11 for ; Fri, 24 Oct 2014 08:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wgXrmU+8kn1JH5xWfoyDqY0K1SagVeWCg58rIyA14Ro=; b=u5U1J+Gn1f5euOJ+sLti7ZS7B+VkHIHDVMUw7f8rTpEQl+rmAONsGO3ScdB0YV4pHM 02WKeiXkLKdFPe5mq1OH8rQ+p+cbFK0g7u2GXKulmdOgRQcplG0QFPshE+nLufqbMqXJ hh6d0tmOm1UrKqVkhF4mFHt4336ioLHXkcqX4yFzVDWyT4CkOr7WO7cAX90qBGwLOz4B S7OstHMV0q9LVX48Ef7+SLwr+QfaFdWQZlS4WuFnX/4Jxetx3762AVzmZ475+XSabpgH lwIpF+PL0G6/fvrEX96uqEr4LppaD6/ecB01lcfw3+iW0LdlJ7kFWl3gmfjyS5Bxmukg IR6g== MIME-Version: 1.0 X-Received: by 10.180.109.99 with SMTP id hr3mr4907955wib.82.1414164802558; Fri, 24 Oct 2014 08:33:22 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.194.220.227 with HTTP; Fri, 24 Oct 2014 08:33:22 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Oct 2014 09:33:22 -0600 X-Google-Sender-Auth: 8SCGdQ-LlO1ZTBX4V5xzL6yIcYw Message-ID: Subject: Re: ZFS errors on the array but not the disk. From: Alan Somers To: Zaphod Beeblebrox Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 15:33:25 -0000 On Thu, Oct 23, 2014 at 11:37 PM, Zaphod Beeblebrox wrote: > What does it mean when checksum errors appear on the array (and the vdev) > but not on any of the disks? See the paste below. One would think that > there isn't some ephemeral data stored somewhere that is not one of the > disks, yet "cksum" errors show only on the vdev and the array lines. Help? > > [2:17:316]root@virtual:/vr2/torrent/in> zpool status > pool: vr2 > state: ONLINE > status: One or more devices is currently being resilvered. The pool will > continue to function, possibly in a degraded state. > action: Wait for the resilver to complete. > scan: resilver in progress since Thu Oct 23 23:11:29 2014 > 1.53T scanned out of 22.6T at 62.4M/s, 98h23m to go > 119G resilvered, 6.79% done > config: > > NAME STATE READ WRITE CKSUM > vr2 ONLINE 0 0 36 > raidz1-0 ONLINE 0 0 72 > label/vr2-d0 ONLINE 0 0 0 > label/vr2-d1 ONLINE 0 0 0 > gpt/vr2-d2c ONLINE 0 0 0 block size: 512B > configured, 4096B native (resilvering) > gpt/vr2-d3b ONLINE 0 0 0 block size: 512B > configured, 4096B native > gpt/vr2-d4a ONLINE 0 0 0 block size: 512B > configured, 4096B native > ada14 ONLINE 0 0 0 > label/vr2-d6 ONLINE 0 0 0 > label/vr2-d7c ONLINE 0 0 0 > label/vr2-d8 ONLINE 0 0 0 > raidz1-1 ONLINE 0 0 0 > gpt/vr2-e0 ONLINE 0 0 0 block size: 512B > configured, 4096B native > gpt/vr2-e1 ONLINE 0 0 0 block size: 512B > configured, 4096B native > gpt/vr2-e2 ONLINE 0 0 0 block size: 512B > configured, 4096B native > gpt/vr2-e3 ONLINE 0 0 0 > gpt/vr2-e4 ONLINE 0 0 0 block size: 512B > configured, 4096B native > gpt/vr2-e5 ONLINE 0 0 0 block size: 512B > configured, 4096B native > gpt/vr2-e6 ONLINE 0 0 0 block size: 512B > configured, 4096B native > gpt/vr2-e7 ONLINE 0 0 0 block size: 512B > configured, 4096B native > > errors: 43 data errors, use '-v' for a list The checksum errors will appear on the raidz vdev instead of a leaf if vdev_raidz.c can't determine which leaf vdev was responsible. This could happen if two or more leaf vdevs return bad data for the same block, which would also lead to unrecoverable data errors. I see that you have some unrecoverable data errors, so maybe that's what happened to you. Subtle design bugs in ZFS can also lead to vdev_raidz.c being unable to determine which child was responsible for a checksum error. However, I've only seen that happen when a raidz vdev has a mirror child. That can only happen if the child is a spare or replacing vdev. Did you activate any spares, or did you manually replace a vdev? -Alan From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 24 18:42:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B689AB7; Fri, 24 Oct 2014 18:42:35 +0000 (UTC) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B9236C6B; Fri, 24 Oct 2014 18:42:34 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id id10so577411vcb.6 for ; Fri, 24 Oct 2014 11:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yacKNvcBnyT3CZOWf0Z7ax56esPKFstuCx7hDfawYfI=; b=bjkpgzh4wtQg5hKzfMigHqNXmQWQSwdfsPV/pAXVkUf8O4iUCfDm4/EgTjbc68MRZW EJ+VyqNNMB5qXTUKrnK5FZX0LZQ+3pmV8phmqWUT5Ug0eyyYZhSZJxqnnRpFT4woz+1k le4NoRlCt3Qf6sdRNIOZy/xAcEEcNgPNv1uU+z499h0Ps6RawnT9Y9odu/XgotAygWpE XF0+Ws6L+PXw3j4jdGA5ZkXl2QW4YzB3PX93RFRcK75YCCvAxAjpMFRBO1imZ1pW244M Xi/Vrw3iKykBGgVceTMOhfnXX8rn2NvoaiyfiYWUAxYWq/gyuLBzz4PPqYWNYBlnrwqX mucg== MIME-Version: 1.0 X-Received: by 10.221.46.4 with SMTP id um4mr4068777vcb.23.1414176153132; Fri, 24 Oct 2014 11:42:33 -0700 (PDT) Received: by 10.220.238.14 with HTTP; Fri, 24 Oct 2014 11:42:32 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Oct 2014 14:42:32 -0400 Message-ID: Subject: Re: ZFS errors on the array but not the disk. From: Zaphod Beeblebrox To: Alan Somers Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-fs , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 18:42:35 -0000 I manually replaced a disk... and the array was scrubbed recently. Interestingly, I seem to be in the "endless loop" of resilvering problem. Not much I can find on it. but resilvering will complete and I can then run another scrub. It will complete, too. Then rebooting causes another resilvering. Another odd data point: it seems as if the things that show up as "errors" change from resilvering to resilvering. One bug, it would seem, is that once ZFS has detected an error... another scrub can reset it, but no attempt is made to read-through the error if you access the object directly. On Fri, Oct 24, 2014 at 11:33 AM, Alan Somers wrote: > On Thu, Oct 23, 2014 at 11:37 PM, Zaphod Beeblebrox > wrote: > > What does it mean when checksum errors appear on the array (and the vdev) > > but not on any of the disks? See the paste below. One would think that > > there isn't some ephemeral data stored somewhere that is not one of the > > disks, yet "cksum" errors show only on the vdev and the array lines. > Help? > > > > [2:17:316]root@virtual:/vr2/torrent/in> zpool status > > pool: vr2 > > state: ONLINE > > status: One or more devices is currently being resilvered. The pool will > > continue to function, possibly in a degraded state. > > action: Wait for the resilver to complete. > > scan: resilver in progress since Thu Oct 23 23:11:29 2014 > > 1.53T scanned out of 22.6T at 62.4M/s, 98h23m to go > > 119G resilvered, 6.79% done > > config: > > > > NAME STATE READ WRITE CKSUM > > vr2 ONLINE 0 0 36 > > raidz1-0 ONLINE 0 0 72 > > label/vr2-d0 ONLINE 0 0 0 > > label/vr2-d1 ONLINE 0 0 0 > > gpt/vr2-d2c ONLINE 0 0 0 block size: 512B > > configured, 4096B native (resilvering) > > gpt/vr2-d3b ONLINE 0 0 0 block size: 512B > > configured, 4096B native > > gpt/vr2-d4a ONLINE 0 0 0 block size: 512B > > configured, 4096B native > > ada14 ONLINE 0 0 0 > > label/vr2-d6 ONLINE 0 0 0 > > label/vr2-d7c ONLINE 0 0 0 > > label/vr2-d8 ONLINE 0 0 0 > > raidz1-1 ONLINE 0 0 0 > > gpt/vr2-e0 ONLINE 0 0 0 block size: 512B > > configured, 4096B native > > gpt/vr2-e1 ONLINE 0 0 0 block size: 512B > > configured, 4096B native > > gpt/vr2-e2 ONLINE 0 0 0 block size: 512B > > configured, 4096B native > > gpt/vr2-e3 ONLINE 0 0 0 > > gpt/vr2-e4 ONLINE 0 0 0 block size: 512B > > configured, 4096B native > > gpt/vr2-e5 ONLINE 0 0 0 block size: 512B > > configured, 4096B native > > gpt/vr2-e6 ONLINE 0 0 0 block size: 512B > > configured, 4096B native > > gpt/vr2-e7 ONLINE 0 0 0 block size: 512B > > configured, 4096B native > > > > errors: 43 data errors, use '-v' for a list > > The checksum errors will appear on the raidz vdev instead of a leaf if > vdev_raidz.c can't determine which leaf vdev was responsible. This > could happen if two or more leaf vdevs return bad data for the same > block, which would also lead to unrecoverable data errors. I see that > you have some unrecoverable data errors, so maybe that's what happened > to you. > > Subtle design bugs in ZFS can also lead to vdev_raidz.c being unable > to determine which child was responsible for a checksum error. > However, I've only seen that happen when a raidz vdev has a mirror > child. That can only happen if the child is a spare or replacing > vdev. Did you activate any spares, or did you manually replace a > vdev? > > -Alan > From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 25 17:01:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4851CC7 for ; Sat, 25 Oct 2014 17:01:30 +0000 (UTC) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "nyi.unixathome.org", Issuer "StartCom Class 2 Primary Intermediate Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 18C30E2E for ; Sat, 25 Oct 2014 17:01:29 +0000 (UTC) Received: from nyi.unixathome.org (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id AD4135084A for ; Sat, 25 Oct 2014 17:01:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by nyi.unixathome.org (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8t7EmLHhWyHG for ; Sat, 25 Oct 2014 17:01:12 +0000 (UTC) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 12B1650843 for ; Sat, 25 Oct 2014 17:01:11 +0000 (UTC) From: Dan Langille Content-Type: multipart/signed; boundary="Apple-Mail=_C9BFF911-04E2-4BC1-974C-1CC49FA40CF8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: perl isvaliddate function Message-Id: <4EA9EE9C-5049-4C50-B361-07F58FA19896@langille.org> Date: Sat, 25 Oct 2014 12:56:34 -0400 To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 17:01:30 -0000 --Apple-Mail=_C9BFF911-04E2-4BC1-974C-1CC49FA40CF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I=92m coding up a sanity check for FreshPorts. It will verify that = field that should be dates are dates. Feedback welcome. The system is already using the DATE module, so I=92m = leveraging that. Pasted at http://dpaste.com/1H0Q8RR.txt but included below, because. $ cat test-date.pl #!/usr/bin/perl use Date::Parse qw( str2time ); sub IsValidDate($) { my ($string) =3D @_; =20 my $Date =3D str2time($string); =20 return defined($Date); } my $a =3D '2014-11-30 unless *coin ports remain unfixed'; if (IsValidDate($a)) { print "'$a' is a valid date\n"; } else { print "'$a' is NOT a valid date\n"; } my $b =3D '2014-02-30'; if (IsValidDate($b)) { print "'$b' is a valid date\n"; } else { print "'$b' is NOT a valid date\n"; } my $c =3D '2014-02-28'; if (IsValidDate($c)) { print "'$c' is a valid date\n"; } else { print "'$c' is NOT a valid date\n"; } $ perl test-date.pl '2014-11-30 unless *coin ports remain unfixed' is NOT a valid date '2014-02-30' is NOT a valid date '2014-02-28' is a valid date $=20 =97=20 Dan Langille --Apple-Mail=_C9BFF911-04E2-4BC1-974C-1CC49FA40CF8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iKYEARECAGYFAlRL1kJfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDA3REZBQjJGRUQ3NEE5QkE0NTNGOUJCNzBB MEIxNzE0Q0ZGQjlEM0MACgkQCgsXFM/7nTyhfgCg/SK0coJwLJQpv31L++hagpWF +hEAoM5eEXn29a2nUOYH9AE8NU7ouBVa =xqxU -----END PGP SIGNATURE----- --Apple-Mail=_C9BFF911-04E2-4BC1-974C-1CC49FA40CF8-- From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 25 18:21:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DED77CFD for ; Sat, 25 Oct 2014 18:21:56 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F0377F3 for ; Sat, 25 Oct 2014 18:21:56 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id u7so874718qaz.27 for ; Sat, 25 Oct 2014 11:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aRZ9QO5sCi9vo3mI41Ox0uaWr3E0mgMXDouCNds6VgA=; b=xE7VgWaLe4aCvgYe5+FztP00S9OjfJE1drirpyEsl0og3FjDMQbvtepZPR1PhPGJKo uDTb03+tCe4KkgOYfy9mqnL3lVwEyxnc+kJRqfSY2/FCj2sucnQxek3khDruOk//M7a8 o0UFiladfmh75Qrgr8erx3cE2NnZ8WJEYTdOk/P+7RbS4MKZdD0AgVltKN3kcR95mYjR LXw1P6RyqD0OX7E2TIjzqfxgWX+TIqDMCxvkXFmQrdGAmA/+5vlIefjtB/fsux5bczaV 7IfpSANbGGboh74kOu75TvczP2JTN+U+OaCsJFIVu3Gz3GUVxoonBEXZ4/3ULtlkq1Hu 4WAQ== X-Received: by 10.140.92.37 with SMTP id a34mr16649293qge.103.1414261315252; Sat, 25 Oct 2014 11:21:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.89.133 with HTTP; Sat, 25 Oct 2014 11:21:35 -0700 (PDT) In-Reply-To: <4EA9EE9C-5049-4C50-B361-07F58FA19896@langille.org> References: <4EA9EE9C-5049-4C50-B361-07F58FA19896@langille.org> From: "B. Estrade" Date: Sat, 25 Oct 2014 13:21:35 -0500 Message-ID: Subject: Re: perl isvaliddate function To: Dan Langille Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 18:21:57 -0000 Looks fine to just get it working. If you wanted to be more efficient, I believe there is a way to use the core POSIX::strfmtime in a way that would verify that the date you start with is the same date as the one returned after the format. This core function is also very useful for date addition and subtraction. I don't have time at this moment to create a proof of concept, but if you're interested let me know and I will when I have a minute. Cheers, Brett On Sat, Oct 25, 2014 at 11:56 AM, Dan Langille wrote: > I=E2=80=99m coding up a sanity check for FreshPorts. It will verify that= field > that should be dates are dates. > > Feedback welcome. The system is already using the DATE module, so I=E2= =80=99m > leveraging that. > > Pasted at http://dpaste.com/1H0Q8RR.txt but included below, because. > > $ cat test-date.pl > #!/usr/bin/perl > > use Date::Parse qw( str2time ); > > sub IsValidDate($) { > my ($string) =3D @_; > > my $Date =3D str2time($string); > > return defined($Date); > } > > my $a =3D '2014-11-30 unless *coin ports remain unfixed'; > > if (IsValidDate($a)) { > print "'$a' is a valid date\n"; > } else { > print "'$a' is NOT a valid date\n"; > } > > my $b =3D '2014-02-30'; > > if (IsValidDate($b)) { > print "'$b' is a valid date\n"; > } else { > print "'$b' is NOT a valid date\n"; > } > > my $c =3D '2014-02-28'; > > if (IsValidDate($c)) { > print "'$c' is a valid date\n"; > } else { > print "'$c' is NOT a valid date\n"; > } > > > $ perl test-date.pl > '2014-11-30 unless *coin ports remain unfixed' is NOT a valid date > '2014-02-30' is NOT a valid date > '2014-02-28' is a valid date > $ > > =E2=80=94 > Dan Langille > > From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 25 19:50:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7486A745 for ; Sat, 25 Oct 2014 19:50:32 +0000 (UTC) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "nyi.unixathome.org", Issuer "StartCom Class 2 Primary Intermediate Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4390069 for ; Sat, 25 Oct 2014 19:50:31 +0000 (UTC) Received: from nyi.unixathome.org (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 7C46A5084A; Sat, 25 Oct 2014 19:50:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by nyi.unixathome.org (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6Xb6ywWAGSI; Sat, 25 Oct 2014 19:50:19 +0000 (UTC) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id CD50950843 ; Sat, 25 Oct 2014 19:50:18 +0000 (UTC) Content-Type: multipart/signed; boundary="Apple-Mail=_B718EA43-FD52-42BD-9BB0-D51D04C39FAC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: perl isvaliddate function From: Dan Langille In-Reply-To: Date: Sat, 25 Oct 2014 15:50:26 -0400 Message-Id: References: <4EA9EE9C-5049-4C50-B361-07F58FA19896@langille.org> To: "B. Estrade" X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 19:50:32 -0000 --Apple-Mail=_B718EA43-FD52-42BD-9BB0-D51D04C39FAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 25, 2014, at 2:21 PM, B. Estrade wrote: > Looks fine to just get it working. If you wanted to be more efficient, = I believe there is a way to use the core POSIX::strfmtime in a way that = would verify that the date you start with is the same date as the one = returned after the format. This core function is also very useful for = date addition and subtraction. >=20 > I don't have time at this moment to create a proof of concept, but if = you're interested let me know and I will when I have a minute. Yes, please, when you have time, please try that proof for me. I would = appreciate that. FYI: I believe all dates within the ports tree must be YYYY-MM-DD so = using something like that would be useful. Comparing the starting date to the supplied date is good too, to catch = edge cases like the first example. =97=20 Dan Langille --Apple-Mail=_B718EA43-FD52-42BD-9BB0-D51D04C39FAC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iKYEARECAGYFAlRL/wJfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDA3REZBQjJGRUQ3NEE5QkE0NTNGOUJCNzBB MEIxNzE0Q0ZGQjlEM0MACgkQCgsXFM/7nTzacACg3MgIw1fzLkST1jlIOGeFh+eX EIsAoKz4O3nkkrwrZHa6LSwN8PBGirEX =ijMl -----END PGP SIGNATURE----- --Apple-Mail=_B718EA43-FD52-42BD-9BB0-D51D04C39FAC-- From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 25 20:45:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55E366F3; Sat, 25 Oct 2014 20:45:42 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BDA60895; Sat, 25 Oct 2014 20:45:41 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id h11so1588013wiw.8 for ; Sat, 25 Oct 2014 13:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-type:content-disposition:user-agent; bh=e48qxjoogQL6icgMC5OeXHPs760d61OeXLwfTiPej5w=; b=HNYrZmVWcl9+xImvSQUQg7aDnv6gZUH0tazbxRsM8tbyf9N4LXB4nz28aGyphwTJGP +3twamRmLL5h2t9ea7pwkFJPOVYPpTZid5aYNpX+HaMgKQ9OoEr8tY3DkBFd9njk9co0 s8hh2RhfB5hnKuzL9npNjewXV3V32AprpU6mjTy2uPWi7XWPLQL1oHhZGGV5H0XgcyGC T1eMa/+4+zGSwXz/0byxVfKzC8RSIaVeAuRlq+uBSr50ann27lc5v6MEFhkKBb/3MesA 9j/89Rl33eHMqO21vK++54PToaa1E4SoKhtTCb65VbPcpjwt7whNP/5bmQEqL1NVBO4C 8I/A== X-Received: by 10.195.13.14 with SMTP id eu14mr12811642wjd.31.1414269939982; Sat, 25 Oct 2014 13:45:39 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id q10sm9793801wjq.35.2014.10.25.13.45.38 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 25 Oct 2014 13:45:39 -0700 (PDT) Date: Sat, 25 Oct 2014 22:45:36 +0200 From: Mateusz Guzik To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: junior kernel tasks Message-ID: <20141025204536.GD19066@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 20:45:42 -0000 Hello, In short, nice kernel tasks people with C language skills can do in few evenings. https://wiki.freebsd.org/JuniorJobs It is assumed you know how to obtain sources and build the kernel. What you can get in return: - your own code in FreeBSD tree - eternal glory [1] - fun [2] If you are not interested, but know someone who does, please pass it down. [1] - not really, no [2] - well, I guess that's subjective, so that's not a "no" Cheers, -- Mateusz Guzik