From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 18 06:08:50 2015 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 81E39DEA for ; Sun, 18 Jan 2015 06:08:50 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 29BE8EC8 for ; Sun, 18 Jan 2015 06:08:49 +0000 (UTC) Received: from [93.104.5.178] (helo=c720-r276659) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1YCj2T-0002SY-2v; Sun, 18 Jan 2015 07:08:46 +0100 Date: Sun, 18 Jan 2015 07:08:43 +0100 From: Matthias Apitz To: freebsd-hackers@freebsd.org Subject: Fwd: kernel: MCA: CPU 0 COR (1) internal parity error Message-ID: <20150118060843.GA1184@c720-r276659> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-hackers@freebsd.org, Jeremy Chadwick MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 11.0-CURRENT r269739 (i386) User-Agent: Mutt/1.5.23 (2014-03-12) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 93.104.5.178 Cc: Jeremy Chadwick 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, 18 Jan 2015 06:08:50 -0000 Hello, I'm running since some days a recent -HEAD r276659 on an Acer C720 Chromebook which works very nicely and fast (I really have never seen such a fast KDE4 desktop). >From time to time (let's say 2-3 times a day) I see messages like this in /var/log/messages: Jan 16 12:04:24 c720-r276659 kernel: MCA: Bank 0, Status 0x90000040000f0005 Jan 16 12:04:24 c720-r276659 kernel: MCA: Global Cap 0x0000000000000c07, Status 0x0000000000000000 Jan 16 12:04:24 c720-r276659 kernel: MCA: Vendor "GenuineIntel", ID 0x40651, APIC ID 0 Jan 16 12:04:24 c720-r276659 kernel: MCA: CPU 0 COR (1) internal parity error the kernel is: # uname -a FreeBSD c720-r276659 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r276659M: Tue Jan 6 12:55:25 CET 2015 guru@vm-poudriere-r269739:/usr/local/acerC720/obj/usr/local/acerC720/src/sys/GENERIC i386 i.e. the i386 version (because I compile everything, kernel and ports, in a VMbox) I'm attaching below the complete 'dmesg' lines with the information details about the CPU. I raised questions about these MCA messages in freebsd-current@ and was pointed to a tool in ports/sysutils/mcelog. Jeremy Chadwick the maintainer of mcelog, made hints about the issue, see below, and asked me to bring this up in freebsd-hackers@ Are these messages really a hardware problem or do our kernel misreporting or mis-decoding of some hardware information. Despite of the messages, the system does not show any other faults or PANICs. Thanks matthias ----- Forwarded message from Jeremy Chadwick ----- Date: Sat, 17 Jan 2015 13:46:53 -0800 From: Jeremy Chadwick To: Matthias Apitz , Eric van Gyzen , freebsd-current@freebsd.org Subject: Re: kernel: MCA: CPU 0 COR (1) internal parity error On Sat, Jan 17, 2015 at 06:43:26PM +0100, Matthias Apitz wrote: > El día Friday, January 16, 2015 a las 03:04:52PM -0500, Eric van Gyzen escribió: > > > On 01/16/2015 14:45, Matthias Apitz wrote: > > > Jan 16 12:04:24 c720-r276659 kernel: MCA: Bank 0, Status 0x90000040000f0005 > > > Jan 16 12:04:24 c720-r276659 kernel: MCA: Global Cap 0x0000000000000c07, Status 0x0000000000000000 > > > Jan 16 12:04:24 c720-r276659 kernel: MCA: Vendor "GenuineIntel", ID 0x40651, APIC ID 0 > > > Jan 16 12:04:24 c720-r276659 kernel: MCA: CPU 0 COR (1) internal parity error > > > > Try ports/sysutils/mcelog. > > I have installed that port and launched it as > > # mcelog > mcelog.txt > ... > mcelog: Unsupported new Family 6 Model 45 CPU: only decoding architectural errors > mcelog: Unsupported new Family 6 Model 45 CPU: only decoding architectural errors > mcelog: Unsupported new Family 6 Model 45 CPU: only decoding architectural errors > ... > > (the messages are STDERR); > > in 'mcelog.txt' it has for the last event from /var/log/messages: > > Jan 17 18:23:54 c720-r276659 kernel: MCA: Bank 0, Status 0x90000040000f0005 > Jan 17 18:23:54 c720-r276659 kernel: MCA: Global Cap 0x0000000000000c07, Status 0x0000000000000000 > Jan 17 18:23:54 c720-r276659 kernel: MCA: Vendor "GenuineIntel", ID 0x40651, APIC ID 0 > Jan 17 18:23:54 c720-r276659 kernel: MCA: CPU 0 COR (1) internal parity error > > the following lines (the uptime matches): > > ... > HARDWARE ERROR. This is *NOT* a software problem! > Please contact your hardware vendor > MCE 32 > CPU 0 BANK 0 TSC 36eec80fd688 [at 1397 Mhz 0 days 12:0:41 uptime (unreliable)] > MCG status: > MCi status: > Error enabled > MCA: Unknown Error 5 > STATUS 90000040000f0005 MCGSTATUS 0 > MCGCAP c07 APICID 0 SOCKETID 0 > CPUID Vendor Intel Family 6 Model 69 > > Questions: > a) Is the output of mcelog valid (regardless of the msg on STDERR of > 'unsupported model')? It may or may not be reliable. For MCE decoding to work accurately, the software (read: kernel) needs to have full support for the processor model and revision in question. mcelog simply tries to decode the output that the kernel spits out and provide a more "user-friendly" explanation. That isn't as simple as just modifying some table of supported CPUs; it involves reading Intel documentation and implementing what can be figured out through that. VMware has a small KB about this, to give you some insight into the complexity: http://kb.vmware.com/kb/1005184 There are some capabilities of MCA that are "semi-universal" across series of CPUs, so sometimes those can be decoded (mostly) accurately, but other times such isn't the case. Sometimes there are certain MCEs that have be ignored by the kernel (i.e. the kernel MCE support has to be updated to reflect changes in MCEs for that newer model of processor). The version of mcelog available in ports is extremely old, and the amount of work to upgrade it to the latest Linux mcelog (1.08) I imagine would be quite large: http://git.kernel.org/cgit/utils/cpu/mce/mcelog.git The existing FreeBSD port involves a large number of patches written by John Baldwin, and whether or not those can be correctly backported to newer mcelog releases is unknown. I really need to renounce my maintainer flag of that port and let someone else take care of it. > b) Is it worth to contact the dealer or wait until it is broken > completely? To me, the above message indicates that one of the CPU cores is damaged/misbehaving. I cannot determine if it's referring to L1, L2, or L3 cache, but I don't see any clear indicator of that (possibly due to the aforementioned explanation I gave about accuracy). However, I will point you to this thread, which may indicate that the model of CPU in question (or series or models of Intel CPUs) have MCEs that happen which are considered "normal" and are thus not being decoded correctly: https://lists.freebsd.org/pipermail/freebsd-questions/2014-January/255873.html I would suggest providing relevant dmesg lines about your exact processor in this system and possibly ask for help from either John Baldwin or someone on freebsd-hackers@. I myself cannot help with this. The dmesg lines I'm referring to, by the way, look like this (all of them matter, particularly the first two): CPU: Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz (2833.59-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10677 Family = 0x6 Model = 0x17 Stepping = 7 Features=0xbfebfbff Features2=0x8e3fd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics The OP of that freebsd-questions thread should have provided this but didn't (instead just says "Intel i3-4310" -- this isn't precise enough), so whether or not you two are using the same CPU is unknown. There simply could be "new MCEs" or changes to the MCA that Intel implemented in some newer models of Core iX that aren't being handled correctly by the kernel (i.e. misreporting or mis-decoding). Good luck! -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | ----- End forwarded message ----- Here comes the dmesg' output: Copyright (c) 1992-2015 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r276659M: Tue Jan 6 12:55:25 CET 2015 guru@vm-poudriere-r269739:/usr/local/acerC720/obj/usr/local/acerC720/src/sys/GENERIC i386 FreeBSD clang version 3.5.0 (tags/RELEASE_350/final 216957) 20141124 VT: running with driver "vga". CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz 686-class CPU) Origin="GenuineIntel" Id=0x40651 Family=0x6 Model=0x45 Stepping=1 Features=0xbfebfbff Features2=0x4ddaebbf,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND> AMD Features=0x2c100000 AMD Features2=0x21 Structured Extended Features=0x2603 XSAVE Features=0x1 VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 2079825920 (1983 MB) avail memory = 2014580736 (1921 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-39 on motherboard Cuse4BSD v0.1.33 @ /dev/cuse random: entropy device infrastructure driver random: selecting highest priority adaptor kbd1 at kbdmux0 module_register_init: MOD_LOAD (vesa, 0xc0fb0310, 0) error 19 random: live provider: "Intel Secure Key RNG" random: SOFT: yarrow init() random: selecting highest priority adaptor vtvga0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) 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 cpu0: on acpi0 cpu1: on acpi0 atrtc0: port 0x70-0x77 on acpi0 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 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: irq 37 on acpi0 acpi_button2: irq 38 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x1800-0x183f mem 0xe0000000-0xe03fffff,0xd0000000-0xdfffffff at device 2.0 on pci0 vgapci0: Boot video device hdac0: mem 0xe0510000-0xe0513fff at device 3.0 on pci0 xhci0: mem 0xe0500000-0xe050ffff at device 20.0 on pci0 xhci0: 32 byte context size. xhci0: Port routing mask set to 0xffffffff usbus0 on xhci0 pci0: at device 21.0 (no driver attached) ig4iic0: mem 0xe051a000-0xe051afff,0xe051b000-0xe051bfff at device 21.1 on pci0 ig4iic0: Using MSI type 44570140 params 001f1fee general 55000000 (updated 55000004) swltr 00000800 autoltr 00000800 version 3131352a SS_SCL_HCNT=00000190 LCNT=000001d6 FS_SCL_HCNT=0000003c LCNT=00000082 HOLD 00000001 ig4iic1: mem 0xe051c000-0xe051cfff,0xe051d000-0xe051dfff at device 21.2 on pci0 ig4iic1: Using MSI type 44570140 params 001f1fee general 55000000 (updated 55000004) swltr 00000800 autoltr 00000800 version 3131352a SS_SCL_HCNT=00000190 LCNT=000001d6 FS_SCL_HCNT=0000003c LCNT=00000082 HOLD 00000001 hdac1: mem 0xe0514000-0xe0517fff at device 27.0 on pci0 pcib1: at device 28.0 on pci0 pci1: on pcib1 ath0: mem 0xe0400000-0xe047ffff at device 0.0 on pci1 ar9300_attach: calling ar9300_hw_attach ar9300_hw_attach: calling ar9300_eeprom_attach ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM Restoring Cal data from Flash Restoring Cal data from Flash Restoring Cal data from OTP ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] 2 RX streams; 2 TX streams ath0: AR9460 mac 640.2 RF5110 phy 1924.13 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 ehci0: mem 0xe051f800-0xe051fbff at device 29.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x1860-0x1867,0x1870-0x1873,0x1868-0x186f,0x1874-0x1877,0x1840-0x185f mem 0xe051f000-0xe051f7ff irq 22 at device 31.2 on pci0 ahci0: AHCI v1.30 with 2 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 acpi_tz0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] pmtimer0 on isa0 ata0: at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1: at port 0x170-0x177,0x376 irq 15 on isa0 ppc0: parallel port not found. coretemp0: on cpu0 est0: on cpu0 coretemp1: on cpu1 est1: on cpu1 Timecounters tick every 1.000 msec IP Filter: v5.1.2 initialized. Default = pass all, Logging = enabled hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 3 on hdaa0 smbus0: on ig4iic0 usbus0: 5.0Gbps Super Speed USB v3.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: <0x8086> at usbus0 uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 uhub0: 13 ports with 13 removable, self powered uhub1: 2 ports with 2 removable, self powered smbus0: Probed address 0x67 No address ptr set, parent smbus No address ptr set isl_probe called on unknown I2C device: 103 ugen0.2: at usbus0 ugen1.2: at usbus1 uhub2: on usbus1 uhub2: 8 ports with 8 removable, self powered cyapa0: on smbus0 cyapa0: cyapa init status 8f cyapa0: CYTRA-103006-00 buttons=LM- res=870x470 smbus1: on ig4iic1 smbus1: Probed address 0x44 No address ptr set, parent smbus No address ptr set usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT cyapa_probe called on unknown I2C device: 68 random: unblocking device. usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT isl0: on smbus1 isl0: Sending command 32 isl0: Sending command 64 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-9 SATA 3.x device ada0: Serial Number B862500493 ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 1024bytes) ada0: Command Queueing enabled ada0: 122104MB (250069680 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 isl0: Sending command 96 hdacc1: at cad 0 on hdac1 hdaa1: at nid 1 on hdacc1 pcm1: at nid 20,33 and 26,25 on hdaa1 SMP: AP CPU #1 Launched! Timecounter "TSC" frequency 1396798064 Hz quality 1000 Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT Root mount waiting for: usbus0 Root mount waiting for: usbus0 Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT Root mount waiting for: usbus0 Root mount waiting for: usbus0 Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT ugen0.3: at usbus0 (disconnected) uhub_reattach_port: could not allocate new device Trying to mount root from ufs:/dev/ada0p2 [rw,noatime]... wlan0: Ethernet address: 80:56:f2:83:c1:17 wlan0: link state changed to UP info: [drm] Initialized drm 1.1.0 20060810 MCA: Bank 0, Status 0x90000040000f0005 MCA: Global Cap 0x0000000000000c07, Status 0x0000000000000000 MCA: Vendor "GenuineIntel", ID 0x40651, APIC ID 2 MCA: CPU 1 COR (1) internal parity error MCA: Bank 0, Status 0x90000040000f0005 MCA: Global Cap 0x0000000000000c07, Status 0x0000000000000000 MCA: Vendor "GenuineIntel", ID 0x40651, APIC ID 2 MCA: CPU 1 COR (1) internal parity error -- Matthias Apitz, guru@unixarea.de, http://www.unixarea.de/ +49-170-4527211 1989-2014: The Wall was torn down so that we go to war together again. El Muro ha sido derribado para que nos unimos en ir a la guerra otra vez. Diese Grenze wurde aufgehoben damit wir gemeinsam wieder in den Krieg ziehen. From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 18 10:14:03 2015 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 170879EF for ; Sun, 18 Jan 2015 10:14:03 +0000 (UTC) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB58B74E for ; Sun, 18 Jan 2015 10:14:02 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id k14so27121377wgh.2 for ; Sun, 18 Jan 2015 02:14:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=6//2pnHNjbqmzEaPGeKpkfvnhsrhcRhCZEzK1Ogxmn4=; b=sMuHyq+FvdwhSxLL1QrTF/puCowqrPBc6L3nBbZaWOaSW2OJyQXZHNeOaH7paw23M0 10PWiq2pBDDkUqho1LpGtRB/o++dpwNwzsU9q2Z7Z2stNqmNaDG1fjHPR82WDZlXz/lI bg6OZLY3u6RdicuVhXUwxv37HJ0NW7tAGegZB9WgroSiWf6B0tEpPfvNylgvfo/fZB1/ XCAKlodBEtgj8ZWuGn+Y0c932QT2TXPxFCXBeib3cL9/wNMpfrIiHUjd9sJxIqtICrP4 V+1Dx+seVziw2fSuf17+7k1T9/66Rir5ksYW87Ebph+I8WTACR8zy74IcsYV2UfOkX5y CxAQ== X-Received: by 10.180.231.33 with SMTP id td1mr23088286wic.33.1421576041124; Sun, 18 Jan 2015 02:14:01 -0800 (PST) Received: from brick.home (adcv250.neoplus.adsl.tpnet.pl. [79.184.47.250]) by mx.google.com with ESMTPSA id vs8sm12853666wjc.6.2015.01.18.02.14.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Jan 2015 02:14:00 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sun, 18 Jan 2015 11:13:58 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: less xss Subject: Re: ctrl-d appends characters to output Message-ID: <20150118101358.GB1195@brick.home> Mail-Followup-To: less xss , freebsd-hackers@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Sun, 18 Jan 2015 10:14:03 -0000 On 0117T1259, less xss wrote: > I've searched around quite a bit with no luck on this matter. I currently > have an issue where I send EOF (ctrl-d) to some simple K&R2 exercises and > the terminal returns the D character appended to my data when EOF is sent. Does it also happen after you do "stty -echoctl"? From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 18 15:47:04 2015 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 09053E5A for ; Sun, 18 Jan 2015 15:47:04 +0000 (UTC) Received: from phlegethon.blisses.org (phlegethon.blisses.org [50.56.97.101]) (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 DC50CC72 for ; Sun, 18 Jan 2015 15:47:03 +0000 (UTC) Received: from blisses.org (cocytus.blisses.org [23.25.209.73]) by phlegethon.blisses.org (Postfix) with ESMTPSA id 2B3A114895A; Sun, 18 Jan 2015 10:38:27 -0500 (EST) Date: Sun, 18 Jan 2015 10:38:25 -0500 From: Mason Loring Bliss To: Jan Beich Subject: Re: usbhidctl / Logitech Message-ID: <20150118153825.GG4474@blisses.org> References: <20150106000213.GT4187@blisses.org> <54AB8F81.8070702@selasky.org> <20150106165926.GU4187@blisses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Hans Petter Selasky , 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, 18 Jan 2015 15:47:04 -0000 On Sun, Jan 18, 2015 at 03:12:01PM +0100, Jan Beich wrote: > Otherwise, add forced_attach=YES to uhidd.conf after applying > https://code.google.com/p/uhidd/source/detail?r=215 Why would I want to do this, though? I don't understand. Please explain. I want to fix usbhidaction specifically. I've got a workaround in the code that makes *my* device work for *me*, but it's not an appropriate fix for general consumption, as it ignores the device's declaration that it returns a range. I think what I need to do is to write to the original authors of the code and get some pointers about intent, and if this is misbehaviour in the device and not the code, I need to see about adding to or imlementing quirk tables of some sort. I'll try to put together some information later today to do just this, since I've gotten lazy as a result of my work-around working for me. It's still broken for everyone else, and my "fix" is incorrect in any event. I appreciate your time in responding, in any event. If you have any insights into uhid devices declaring a range when they evidently don't use one, I'd love to hear them. My Logitech keyboard generates static values on these key- presses, and they're lost when they go through the range converter, but forcing the code to ignore ranges all the time will doubtless break other devices that do use them. -- Mason Loring Bliss mason@blisses.org Ewige Blumenkraft! awake ? sleep : random() & 2 ? dream : sleep; -- Hamlet, Act III, Scene I From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 19 04:07:51 2015 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 5BDB6EFC for ; Mon, 19 Jan 2015 04:07:51 +0000 (UTC) Received: from vfemail.net (nine.vfemail.net [108.76.175.9]) (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 D96F3BF0 for ; Mon, 19 Jan 2015 04:07:45 +0000 (UTC) Received: (qmail 67753 invoked by uid 89); 18 Jan 2015 14:12:27 -0000 Received: from localhost (HELO freequeue.vfemail.net) (127.0.0.1) by localhost with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Jan 2015 14:12:27 -0000 Received: (qmail 67729 invoked by uid 89); 18 Jan 2015 14:12:10 -0000 Received: by simscan 1.3.1 ppid: 67722, pid: 67725, t: 0.1004s scanners:none Received: from unknown (HELO smtp102-2.vfemail.net) (172.16.100.62) by FreeQueue with SMTP; 18 Jan 2015 14:12:10 -0000 Received: (qmail 21538 invoked by uid 89); 18 Jan 2015 14:12:10 -0000 Received: by simscan 1.4.0 ppid: 21521, pid: 21534, t: 0.7184s scanners:none Received: from unknown (HELO nil) (amJlaWNoQHZmZW1haWwubmV0@172.16.100.27) by 172.16.100.62 with ESMTPA; 18 Jan 2015 14:12:09 -0000 From: Jan Beich To: Mason Loring Bliss Subject: Re: usbhidctl / Logitech References: <20150106000213.GT4187@blisses.org> <54AB8F81.8070702@selasky.org> <20150106165926.GU4187@blisses.org> Date: Sun, 18 Jan 2015 15:12:01 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Mailman-Approved-At: Mon, 19 Jan 2015 04:17:10 +0000 Cc: Hans Petter Selasky , 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, 19 Jan 2015 04:07:51 -0000 Mason Loring Bliss writes: >> Did you checkout "sysutils/uhidd" in ports yet? > > The docs say: > > "Note that before you can use uhidd with certain ugenX.Y device, you need > to make sure there is no kernel HID device driver attached to that > device. You could either remove 'device ukbd', 'device ums' and 'device > uhid' from your kernel config file and recomplie the kernel, or if these > drivers are loaded as kernel modules, kldunload(8) them." Only uhid(4) may conflict with -o (cc_attach) mode. Try $ kldload usb_quirk $ usbconfig add_dev_quirk_vplh 0x046d 0 0 0xffff UQ_HID_IGNORE $ usbconfig add_dev_quirk_vplh 0x046d 0 0 0xffff UQ_MATCH_VENDOR_ONLY $ kldunload uhid Otherwise, add forced_attach=YES to uhidd.conf after applying https://code.google.com/p/uhidd/source/detail?r=215 > > It would be unfortunate to have to build a custom kernel and resort to > something from ports when the in-tree tool is one bugfix away from supporting > my hardware perfectly. > > I guess I need to understand more of the background to figure out what the > most reasonable fix would be. I'll do some more research. ------------------------------------------------- VFEmail.net - http://www.vfemail.net ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options! From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 19 22:56:27 2015 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 EBFDBD5B for ; Mon, 19 Jan 2015 22:56:26 +0000 (UTC) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 707616D6 for ; Mon, 19 Jan 2015 22:56:26 +0000 (UTC) Received: by mail-lb0-f178.google.com with SMTP id u10so43918lbd.9 for ; Mon, 19 Jan 2015 14:56:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Jhoe0Yjss3WALBOSKrCtamxdsf6x4B69o/V9vH3MfZE=; b=ZLoCv9FwxQyXYyAckyjToL980gqQW/aqf6BDc3ipzPMxhODgmCoxW/xiF4WY41hzLF 21TYi341nTp9MV461xm1cCdt+vrSFMWZ4pZC+MYOWiZ13rTexUgeYfZlwilhXJaOXeBN hmH2Q0ws6ErwR6UI2P8JObw5th43BW9lHgL1dhhVgirmZEfrvNgONPvIMa/lnKkRy72t LrgAhFkpDWk2HiEvInLMAf362VZlockq1udBGuD0L7EBJ/uCJ3AzG7DuKKTkmaSNBzno 2suHaaGcHusPvZFeGNrWTNnb1h7O+zVzdlRRyhymW5W4JaSUBXvEISXYU8fAy8Dk6C5K geBQ== MIME-Version: 1.0 X-Received: by 10.112.164.102 with SMTP id yp6mr34009832lbb.15.1421708184469; Mon, 19 Jan 2015 14:56:24 -0800 (PST) Received: by 10.114.78.131 with HTTP; Mon, 19 Jan 2015 14:56:24 -0800 (PST) Date: Mon, 19 Jan 2015 17:56:24 -0500 Message-ID: Subject: Sleeping thread held mutex in vm_pageout_oom() From: Ryan Stone To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 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, 19 Jan 2015 22:56:27 -0000 I recently had a system where a DIMM failed and the OOM killer was constantly kicking in due to a memory-hungry daemon being constantly restarted. This ended up triggering a race condition in the OOM killer leading to this panic: Sleeping thread (tid 100075, pid 8) owns a non-sleepable lock sched_switch() at 0xffffffff8048386d = sched_switch+0x16d mi_switch() at 0xffffffff80469dd6 = mi_switch+0x186 sleepq_wait() at 0xffffffff80499204 = sleepq_wait+0x44 __lockmgr_args() at 0xffffffff8044b88b = __lockmgr_args+0x67b vop_stdlock() at 0xffffffff804d3689 = vop_stdlock+0x39 ---Type to continue, or q to quit--- VOP_LOCK1_APV() at 0xffffffff8069da42 = VOP_LOCK1_APV+0x52 _vn_lock() at 0xffffffff804ed627 = _vn_lock+0x47 vm_object_deallocate() at 0xffffffff8061eef3 = vm_object_deallocate+0x203 vm_map_entry_deallocate() at 0xffffffff80616d2c = vm_map_entry_deallocate+0x4c vm_map_process_deferred() at 0xffffffff80616d62 = vm_map_process_deferred+0x32 vm_map_remove() at 0xffffffff806183ff = vm_map_remove+0x6f vmspace_free() at 0xffffffff80619206 = vmspace_free+0x56 vm_pageout_oom() at 0xffffffff806230d1 = vm_pageout_oom+0x181 vm_pageout() at 0xffffffff8062410b = vm_pageout+0x90b fork_exit() at 0xffffffff8043a382 = fork_exit+0x112 fork_trampoline() at 0xffffffff8063385e = fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff80c3be1d00, rbp = 0 --- panic: sleeping thread cpuid = 5 curthread = grep/grep (82989/100544) cpu_ticks = 1848294656444 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff801e52ba = db_trace_self_wrapper+0x2a panic() at 0xffffffff80461608 = panic+0x228 propagate_priority() at 0xffffffff8049cbde = propagate_priority+0x15e turnstile_wait() at 0xffffffff8049d278 = turnstile_wait+0x1b8 _mtx_lock_sleep() at 0xffffffff80451af1 = _mtx_lock_sleep+0xf1 ---Type to continue, or q to quit--- _mtx_lock_flags() at 0xffffffff80451c75 = _mtx_lock_flags+0x75 exit1() at 0xffffffff804367de = exit1+0x36e sys_exit() at 0xffffffff8043731e = sys_exit+0xe syscallenter() at 0xffffffff8049b324 = syscallenter+0x104 syscall() at 0xffffffff80649bfc = syscall+0x4c Xfast_syscall() at 0xffffffff806335f2 = Xfast_syscall+0xe2 --- syscall (1, FreeBSD ELF64, sys_exit), rip = 0x300a2df9c, rsp = 0x7ffffffd40c8, rbp = 0x7ffffffd40e0 --- Uptime: 7m19s The root cause is that vm_pageout_oom() acquires a reference on a process's vmspace while holding its PROC_LOCK(), then the process exited. This left vm_pageout_oom() holding the only reference on the vmspace, so when it dropped the reference it called into vm_map_remove() and wound up sleeping while still holding the PROC_LOCK(). This was under FreeBSD 8 but the code in head does not seem to have changed here. I'm not quite familiar with the lock mechanisms here so I'm not sure how to fix it. Does vm_pageout_oom() need to _PHOLD() the process while holding the PROC_LOCK(), then drop the lock, then acquire the vmspace reference? It appears that's how other places that call vmspace_acquire_ref() work. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 01:31:13 2015 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 39973AD3 for ; Tue, 20 Jan 2015 01:31:13 +0000 (UTC) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d: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 E35F08DD for ; Tue, 20 Jan 2015 01:31:12 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id x12so26179340qac.11 for ; Mon, 19 Jan 2015 17:31:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=o/eXvGtHhrS7bd+/uqXCpykEa0Wfn1XYR+VXnNtUtYo=; b=OI/l7svQVKHKuvHOmuuDTrHZumjhQKl8JUJ3hhae/BjEesiX8+H+SKH0IGtZCAcLqs fXoSse1GGh/YJ3kRyxs4/Kev3ZN6HCeTeVXYjPUzNSdQv7Mw+2fivfza5HXEGvTIACuQ La+cZrxo8IUzV8gtDeBhFcyAMVEKU1+1AWTpgkJHd5pC3pxTfj2WxhPr1AlBvqzvNg9P C3xLOAFsUPKPdGr9hbuGCot3EOQ7Ev8b+x9yLmxYv6Fk2sUMDMCQF5D9l+mZEajwCJKU 0pVBer8xujuytNRGfZfy5ndrihSb4g7yKbd9PFPd7jaUNt5G1XQrEVgYTEwAP1IkAtSq Y5fg== X-Received: by 10.140.88.48 with SMTP id s45mr50697035qgd.28.1421717471837; Mon, 19 Jan 2015 17:31:11 -0800 (PST) Received: from [192.168.0.2] ([190.18.62.99]) by mx.google.com with ESMTPSA id 10sm13901454qap.39.2015.01.19.17.31.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jan 2015 17:31:11 -0800 (PST) Message-ID: <54BDAFDD.9040004@gmail.com> Date: Mon, 19 Jan 2015 22:31:09 -0300 From: lucaslucaslucas24 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: graphical assistant for pkg 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: Tue, 20 Jan 2015 01:31:13 -0000 Hello. Im thinking in graphical assistant for pkg, as synaptic in gnu/linux deb's. with options for select some, all, any packages; options for update, etc. ¿what you think about my idea? From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 04:49:01 2015 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 95200AD5; Tue, 20 Jan 2015 04:49:01 +0000 (UTC) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A4A0FE65; Tue, 20 Jan 2015 04:49:00 +0000 (UTC) X-AuditID: 1209190e-f799e6d000000cfe-39-54bddd07fdda Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 5B.DA.03326.70DDDB45; Mon, 19 Jan 2015 23:43:52 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t0K4hoOU015991; Mon, 19 Jan 2015 23:43:51 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t0K4hmMV022483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Jan 2015 23:43:50 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t0K4hl9V014970; Mon, 19 Jan 2015 23:43:47 -0500 (EST) Date: Mon, 19 Jan 2015 23:43:47 -0500 (EST) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: freebsd-hackers@freebsd.org Subject: FreeBSD Quarterly Status Report - Fourth Quarter 2014 Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCKsWRmVeSWpSXmKPExsUixG6nrstxd2+IwUN/i13XTrNbzHnzgcli ++Z/jBaHm4UcWDxmfJrPEsAYxWWTkpqTWZZapG+XwJXxbOVz9oJLR1kq5n/aydTA+OUocxcj J4eEgInEjUefWCFsMYkL99azdTFycQgJLGaSuHFtDzuEs5FRYv3zbiaQKiGBQ0wS0x5nQCQa GCWurpgP1MLBwSKgLfF+fzlIDZuAmsTjvc1QUxUlNp+axAxSIiIgL7HgvD1ImFnAWmLuuvVg JcICdhKTv75jB7F5BRwlelYsAjtOVEBHYvX+KSwQcUGJkzOfsED0Bkr0rJvDNIFRYBaS1Cwk KQhbR2LKxBWMELa2xP2bbWwLGFlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrr5WaW6KWmlG5i BAUypyTfDsavB5UOMQpwMCrx8L5YtTdEiDWxrLgy9xCjJAeTkihvzU2gEF9SfkplRmJxRnxR aU5q8SFGCQ5mJRHeo5eAcrwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxK ErxnbwM1ChalpqdWpGXmlCCkmTg4QYbzAA3fAlLDW1yQmFucmQ6RP8VoyfHk5O6ZTBz7LoLI vo0HZzIJseTl56VKiUM0CIA0ZJTmwc2EJaZXjOJALwrzBt8BquIBJjW4qa+AFjIBLRTbtQdk YUkiQkqqgXGpnZt9mPysVZ1zRUNeCNsIKbtkH/15cjuThuCxmkmvN18X1/v7geGjED9PxgW5 ZTnGrqa2Z3b0vFy+s/2za2nYIebdr+UmXGd+ZLSxJF5afFFHyu8ZJ03Wz65g2Hg/v0330XLm hKc+tWnHD/wziYw75fhL7QJTnpHBhccXdzvtWv/trFe30w8lluKMREMt5qLiRACMR5P1JwMA AA== Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current@freebsd.org, freebsd-stable@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, 20 Jan 2015 04:49:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 FreeBSD Project Quarterly Status Report: October - December 2014 This report covers FreeBSD-related projects between October and December 2014. This is the last of four reports planned for 2014. The fourth quarter of 2014 included a number of significant improvements to the FreeBSD system. In particular, compatibility with other systems was enhanced. This included significant improvements to the Linux compatibility layer, used to run Linux binaries on FreeBSD, and the port of WINE, used to run Windows applications. Hypervisor support improved, with FreeBSD gaining the ability to run as domain 0 on Xen's new high-performance PVH mode, bhyve gaining AMD support, and new tools for creating FreeBSD VM images arriving. This quarter was also an active time for the toolchain, with numerous improvements to the compiler, debugger, and other components, including initial support for C++14, which should be complete by FreeBSD 10.2. Thanks to all the reporters for the excellent work! The deadline for submissions covering the period from January to March 2015 is April 7th, 2015. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Release Engineering Team * Ports Collection * The FreeBSD Core Team Projects * bhyve * Clang, llvm, and lldb Updated to 3.5.0 * External Toolchain * FreeBSD on Google Cloud * FreeBSD on the Acer C720 Chromebook * Git Integration * Jenkins Continuous Integration for FreeBSD * Migration to ELF Tool Chain Tools * pkg(8) Kernel * FreeBSD Xen * Linux Emulation Layer, the Linuxulator * PCI SR-IOV Infrastructure * Process Management * Secure Boot * Timer Function Support for Linuxulator * Updating OpenCrypto Architectures * FreeBSD on POWER8 * FreeBSD/arm64 Userland Programs * libxo: Generate Text, XML, JSON, and HTML Output * mandoc(1) Support Ports * GNOME on FreeBSD * KDE on FreeBSD * Linux Emulation Ports * The Graphics Stack on FreeBSD * Wine/FreeBSD * Xfce Documentation * More Michael Lucas Books * New Translators Mailing List Miscellaneous * Creating Vagrant Images with Packer * FreeBSD Forum Software Migration * The FreeBSD Foundation __________________________________________________________________ FreeBSD Release Engineering Team URL: http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. The FreeBSD 10.1-RELEASE cycle completed on November 14th, marking the second official release point from the stable/10 branch, just short of three weeks later than the original schedule anticipated. Work to produce virtual machine images for platforms not currently supported has continued, with focus aimed primarily at Amazon EC2, Google Compute Engine, and Openstack. With huge thanks to Ian Lepore and Warner Losh, new ports exist for FreeBSD/arm where u-boot is required. Work has been in progress since late December to migrate the existing FreeBSD/arm release build tools to utilize the new ports. This project is sponsored by The FreeBSD Foundation . __________________________________________________________________ Ports Collection URL: http://www.FreeBSD.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-po= rts/ URL: http://portsmon.freebsd.org/index.html URL: http://portscout.freebsd.org/ URL: http://www.freebsd.org/portmgr/index.html URL: http://blogs.freebsdish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/portmgr URL: http://plus.google.com/communities/108335846196454338383 Contact: Frederic Culot Contact: Port Management Team As of the end of Q4 the ports tree holds more than 24,000 ports, and the PR count is just over 1,400. As during the previous quarter the tree saw a sustained activity with almost 6,000 commits and more than 1,600 ports PRs closed! In Q4, five new developers were granted a ports commit bit (gordon@, jmg@, jmmv@, bofh@, truckman@) and six were taken in for safekeeping (sylvio@, pclin@, flz@, jsa@, anders@, motoyuki@). On the management side, miwi@ decided to step down from his portmgr duties in November. No other changes were made to the team during Q4. This quarter also saw the release of the fourth quarterly branch, namely 2014Q4. On the QA side, 39 exp-runs were performed to validate sensitive updates or cleanups. Open tasks: 1. A tremendous work was done on the PR front in Q4 and we would be very pleased to see committers dedicate themselves to closing as many as possible in 2015 as well! 2. 2014 is the year that saw the highest number of commits in all of our ports tree's history! As for the PR front and to keep our beloved tree in good shape, we would love to see the same commitment from our developers next year! __________________________________________________________________ The FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team constitutes the project's "Board of Directors", responsible for deciding the project's overall goals and direction as well as managing specific areas of the FreeBSD project landscape. During the fourth quarter of 2014, the FreeBSD Core team saw the culmination of a long-running project to rebuild the FreeBSD Forums. The chosen solution was to license XenForo; core would like to thank the FreeBSD Foundation for paying the licensing costs of this software. Much discussion ensued concerning the "New Support Model" following Core's meeting at EuroBSDCon in September. It was recognised that trying to change the model immediately before 10.1-RELEASE was far too late, and the change will be targeted at 11.0-RELEASE. In order to ensure that 10.1-RELEASE shipped with support for up-to-date X Window Systems and KDE4, core approved the switch to 'new Xorg' as the default in time for building the packages for that release. Git was officially promoted from beta to an officially supported version control system. Git is available as a read-only resource for downstream consumers and contains an exported copy from SVN, the primary and only read-write repository. The FreeBSD git repositories (exported from the master SVN version control) will shortly be available at https://git.freebsd.org/, and core has been active in ensuring that there is a sufficient body of Git administrators available with access to appropriate documentation in order to maintain a good git service. Core mediated in disputes between a number of committers over some updates to system sources, and fielded complaints about code quality of some other work in critical areas. While such disagreements will occasionally occur, core is promoting the routine use of the Phabricator service in order to review work before committal. Catching problems early is in the project's best interests, and discussion of changes in an open review context should minimize confrontational demands for immediate back-out of changes. Core is working on a charter for a proposed new QA team, to encompass members of the Release Engineering and Security teams, as well as committers with interests in standards compliance. It is envisioned that the QA team will take responsibility for merging code from HEAD into the STABLE branches, run integration testing against those updates and handle merging patches and bug-fixes submitted to the FreeBSD project from third parties. During this quarter, core issued two new commit bits, and also took two commit bits into safe-keeping. __________________________________________________________________ bhyve URL: http://www.bhyve.org Contact: Peter Grehan Contact: Neel Natu Contact: John Baldwin Contact: Tycho Nightingale Contact: Allan Jude bhyve is a hypervisor that runs on the FreeBSD/amd64 platform. At present, it runs FreeBSD (8.x or later), Linux i386/x64, OpenBSD i386/amd64, and NetBSD/amd64 guests. Current development is focused on enabling additional guest operating systems and implementing features found in other hypervisors. Support for AMD processors was committed to -CURRENT in October 2014. This has also been merged to 10-STABLE and will be included in the 10.2 release. A bhyve status update presentation was given at the FreeBSD Vendor Summit in Nov 2014. The slides are available at http://people.freebsd.org/~neel/bhyve/bhyve_update_vendor_summit_2014.pd= f . A number of improvements have been made to bhyve this quarter: * OpenBSD/i386 guests are now able to boot with multiple vcpus. * NetBSD/amd64 guests are now fully supported. * Improvements to the AHCI emulation to be more resilient under heavy load. * Various improvements to PIC emulation to be able to boot legacy guests. * A fully featured RTC device emulation that allows date/time changes by the guest and supports periodic and alarm interrupts. * Consolidate all timer emulations in vmm.ko. This enables the use of a single clocksource for all timer emulations. * Allow tracing of every exception incurred by a guest. This is useful when debugging guest double and triple faults. * Emulate platform-specific MSRs accessed by recent Linux guests. * Various bug fixes to grub-bhyve to boot OpenBSD/i386 and Centos 4.x guests. * grub-bhyve is now able to connect to an nmdm(4) console using the --cons-dev option. Open tasks: 1. Improve documentation. 2. bhyveucl is a script for starting bhyve instances based on a libUCL config file. More information at https://github.com/allanjude/bhyveucl . 3. CSM BIOS boot support for non UEFI-aware guests. 4. Add support for virtio-scsi. 5. Improve virtio-net, add offload features, support multiple queues. 6. Implement Intel 82580 and e1000 NIC emulation. 7. Netmap support. 8. Flexible networking backend: wanproxy, vhost-net. 9. Move to a single process model, instead of bhyveload + bhyve. 10. Support running bhyve as non-root. 11. Add filters for popular VM file formats (VMDK, VHD, QCOW2). 12. Implement an abstraction layer for video (no X11 or SDL in base system). 13. Support for VNC as a video output. 14. Suspend/resume support. 15. Live Migration. 16. Nested VT-x support (bhyve in bhyve). 17. Support for other architectures (ARM, MIPS, PPC). __________________________________________________________________ Clang, llvm, and lldb Updated to 3.5.0 URL: http://llvm.org/releases/3.5.0/docs/ReleaseNotes.html URL: http://llvm.org/releases/3.5.0/tools/clang/docs/ReleaseNotes.html Contact: Dimitry Andric Contact: Ed Maste Contact: Roman Divacky Just before the end of the year, we updated clang, llvm, and lldb in the base system to 3.5.0 release. These all contain numerous improvements. Please see the linked release notes for more detailed information. This is the first release that requires C++11 support to build. At this point, FreeBSD 10.0 and later provide that support, at least on x86. In the near future, more components from llvm.org will be updated in base, with libc++ and libcompiler-rt most likely being the first to be updated. Thanks to Ed Maste, Roman Divacky, Andrew Turner, Justin Hibbits, and Antoine Brodin for their invaluable help with this import. Open tasks: 1. While most ports that were impacted by this update have already been fixed, there are still a few that do not work with the clang 3.5.0 update. In most cases, this is due to relatively simple issues, such as new warnings, or slightly stricter error checking (primarily for C++ programs). Fixing those issues should not take too much work. 2. There are still some open issues with the ARM, PowerPC, and Sparc64 architectures, and any help in this area is very much appreciated. __________________________________________________________________ External Toolchain URL: https://wiki.freebsd.org/ExternalToolchain Contact: Baptiste Daroussin Contact: Warner Losh Contact: Brooks Davis The main goal of the external toolchain project is to be able to build world and kernel with a non-default toolchain. It can be helpful to: * Prepare a migration to a newer version of toolchain components. * Port FreeBSD to a new architecture * Upgrade from a FreeBSD that ships with GCC 4.2 to a version that ships with clang 3.5+ (which needs a more modern toolchain than GCC 4.2 to bootstrap). The initial external toolchain work only supported clang. It has been extended to support recent GCC (4.9.1 has been tested) and recent binutils (2.24 and 2.25). A large number of fixes have been committed to HEAD to support incompatible behaviour changes between ld(1) from binutils 2.17.50 (the version in base) and binutils 2.24+. A large number of warnings have been deactivated when building the kernel to make sure it is possible to build the kernel with recent GCC (first 4.6 and then 4.9.1) The build system has been changed to build libc++ as the C++ standard library implementation when a recent enough GCC (4.6+) is used to build world. To simplify using an external toolchain, the following pre-seeded configurations have been added to the ports tree: * amd64-xtoolchain-gcc * powerpc64-xtoolchain-gcc * sparc64-xtoolchain-gcc Those packages will depend on special versions of GCC (minimalistic cross-built ready GCC) and on binutils. To use them, run: make CROSS_TOOLCHAIN=3Dpowerpc64-gcc TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 As a result of this effort, it is possible to successfully build and run a kernel and world built with GCC 4.9.1 and binutils 2.24 on sparc64, amd64 (with minor tweaks), powerpc and powerpc64. Open tasks: 1. Patch GCC 4.9 to support FreeBSD mips, arm and aarch64 and submit the patches to upstream. 2. Adapt and upstream the aarch64 patches for binutils 2.25. 3. Add more pre-seeded configurations. __________________________________________________________________ FreeBSD on Google Cloud URL: https://github.com/swills/FreeBSD-gcloud URL: https://plus.google.com/112202779615695172291/posts/eYajb8JKerY Contact: Steve Wills Google Cloud is a cloud computing platform that allows users to run hosted services and servers in a cloud maintained by Google. The goal of this project is to provide an easy way to create and manage FreeBSD installations running on Google Cloud. The good news: FreeBSD 10.1 runs fine. You can create an image and start it up and login via standard ssh, via the gcloud command or via the web console (ssh in a web browser window). More details on how to do all this can be found in the links. Basically, you should be able to gcutil addimage freebsd-101-release-amd64-20150101032704 gs://swills-test-bucket/FreeBSD-10.1-RELEASE-amd64-20150101032704.tar.gz Then spin up an image using gcloud compute instances create --zone us-central1-b --image freebsd-101-release-amd64-20150101032704 --boot-disk-size 20GB gtest1 These commands are part of the google-cloud-sdk port, which contains all the commands to interact with Google Cloud. There is also a google-daemon port which is used in running instances to create users and set them up and a google-startup-scripts port which handles running startup/shutdown scripts as specified in node metadata. Additionally, the firstboot-growfs port has been brought back so that new instances will grow their root filesystem. (Thanks to Colin Percival for having created that port initially.) There is also a firstboot-freebsd-update port which can be used to update a system on first boot but is currently disabled (see below). Similarly, the firstboot-pkgs port/scripts will install specified packages on first boot. Overall, Google Cloud Compute is quite nice; instances spin up in about 60 seconds and it is very reasonably priced with automatic discounts for longer term usage. There is a $300 credit for first time users that also makes it free to try out. That credit covers quite a lot of time, and the instances are pretty fast, as well, even the ones without SSDs. The bad news: Google does not make sharing non-official images as easy as AWS, so you have to create your own using my public tar file. The tar file was created using the script in the links section. That script can be used to produce customized images, even though there are no official image (nor will there be any time soon). There are some issues running FreeBSD on Google Cloud, listed in the tasks section. Open tasks: 1. The 8 and 16 cpu instances seem to reboot randomly. 2. Repeated UFS panics that Google folks have reported, but I do not think those are particular to Google Cloud. The panic message is "ffs_valloc dup alloc". 3. Running freebsd-update causes the system to become unbootable, so updates do not work. (Reboots work fine otherwise.) 4. There is no gcimagebundle command in the Ports Collection so you cannot easily create an image from a running machine. 5. There are a few minor issue with the startup script that is supposed to regenerate ssh keys (for when you create an image from an existing system). 6. 10.1 works, but 10.0 does not boot; other versions remain untested. 7. The kern.vm_guest sysctl node does not detect that it is in a guest. 8. The vtnet driver needs wq disabled on 16 cpu boxes, but it is just disabled everywhere for now since that is easier. 9. There is work needed for the Google safe_format_and_mount command which formats and mounts newly attached disks, but this is just a nicety really. 10. I need to look into irq affinity for vtnet. 11. We need to support virtualized clocks; bryanv@ is working on this. In fact, all his ongoing work in the virtualization area would probably make things work better. 12. It would be nice if there was the ability to disable the spinner before the loader, which clutters up the console log. The ability to disable it is in HEAD; hopefully it will be MFCd to 10-STABLE before 10.2. __________________________________________________________________ FreeBSD on the Acer C720 Chromebook URL: http://blog.grem.de/pages/c720.html Contact: Michael Gmelin The Acer C720 Chromebook is a powerful but inexpensive laptop designed to run Google's Chrome OS. This project aims to bring FreeBSD to the C720, providing an easy way for people to experience FreeBSD on hardware which is widely available and inexpensive. As of this update, most system features work, including the keyboard, WiFi, sound, VESA graphics, touchpad, and USB. The battery life is a reasonable 5 to 6 hours (compare to the published 8.5 hour lifetime for Chrome OS. Open tasks: 1. Streamline patches and merge them into HEAD. 2. Make suspend/resume work (depends on Haswell support). __________________________________________________________________ Git Integration URL: https://lists.freebsd.org/mailman/listinfo/freebsd-git URL: https://www.kernel.org/pub/software/scm/git/docs/git-svn.html URL: https://github.com/git/git/commit/83c9433e679635f8fbf8961081ea3581c= 93ca778 URL: https://wiki.freebsd.org/GitWorkflow URL: https://github.com/freebsd/freebsd URL: https://bugs.freebsd.org/bugzilla Contact: Git discussion list Several FreeBSD developers have expressed interest in improving the tools and documentation to facilitate the use of the Git source code management (SCM) system when working with FreeBSD code. Some highlights of the work in this area include the following: * At Alfred Perlstein's request, a new mailing list freebsd-git@FreeBSD.org was created for discussion of git use in the FreeBSD project. * Alfred Perlstein submitted a patch to git. This patch allows a developer to work on a source code tree in git and use git-svn to push changes from this tree directly to a Subversion repository and set Subversion properties. Before this patch, git-svn did not properly set Subversion properties. This is important for FreeBSD developers because the FreeBSD Subversion repo will block commits which do not properly set certain Subversion properties. The git project accepted this change in changeset 83c9433. * Alfred Perlstein updated the Git Workflow wiki document to include information for using git-svn to commit to the FreeBSD Subversion repository. * Bartek Rutkowski wrote a script which integrates Github and FreeBSD Bugzilla. When a user files a Github pull request against the FreeBSD source code tree on Github, this script will open a new PR in FreeBSD Bugzilla. This will allow users to contribute code and patches via Github pull requests, and have the request tracked by FreeBSD developers in Bugzilla. Github pull requests cannot currently be directly merged into the FreeBSD source tree on Github, because the main source code repository is currently Subversion. The FreeBSD source code tree on Github is a read-only mirror of the FreeBSD Subversion repository. Craig Rodrigues coordinated with Bartek Rutkowski and bugmeister@FreeBSD.org to move forward on this, and provide Bartek Rutkowski with enough access to Bugzilla to open PR's via a script. Open tasks: 1. The Github integration script is not deployed yet and is not active for all pull requests against the FreeBSD source tree on Github. Bartek Rutkowski and bugmeister@FreeBSD.org need to work out the final details for deploying this script into production. The script must be accessible via HTTP POST requests because it uses the Github REST API. Bartek Rutkowski and bugmeister@FreeBSD.org need to reach agreement on where this script lives, and do a security audit. __________________________________________________________________ Jenkins Continuous Integration for FreeBSD URL: https://jenkins.freebsd.org URL: http://jenkins-ci.org/content/freebsd-project-use-jenkins-os-testin= g URL: https://wiki.freebsd.org/201411DevAndVendorSummit?action=3DAttachFi= le&do=3Dview&target=3Dkyua_jenkins.pdf URL: https://issues.jenkins-ci.org/browse/JENKINS-21507 URL: https://issues.jenkins-ci.org/browse/JENKINS-24521 URL: https://github.com/rodrigc/kyua/wiki/Quickstart-Guide URL: http://www.freshports.org/textproc/igor/ URL: https://jenkins.freebsd.org/job/FreeBSD_Doc-igor URL: https://jenkins.freebsd.org/job/FreeBSD_HEAD_sparc64/ URL: https://lists.freebsd.org/pipermail/freebsd-testing/2014-November/0= 00609.html URL: https://lists.freebsd.org/pipermail/freebsd-testing/2014-December/0= 00697.html URL: https://lists.freebsd.org/pipermail/svn-src-all/2014-October/092212= =2Ehtml URL: http://lists.freebsd.org/pipermail/freebsd-testing/2015-January/000= 713. html URL: https://github.com/Homebrew/homebrew/pull/32346 URL: https://github.com/freebsd/freebsd-ci/pull/3 URL: https://lists.freebsd.org/pipermail/freebsd-testing/2015-January/00= 0723.html URL: https://lists.freebsd.org/pipermail/freebsd-testing/2015-January/00= 0722.html Contact: Craig Rodrigues Contact: Jenkins Administrators Contact: FreeBSD Testing Since the last status report, many people have contributed help in various areas to help with Continuous Integration and Testing in FreeBSD. Some of the highlights include: * The Jenkins project mentioned on their blog how FreeBSD is using Jenkins and kyua to run OS-level tests. * Craig Rodrigues submitted patches to upgrade Jenkins to use JNA 4.1.0. The Jenkins project accepted these patches [JENKINS-24521] in the Jenkins 1.586 release. This fixed problems with PAM authentication support in Jenkins on FreeBSD [JENKINS-21507]. * Craig Rodrigues gave a presentation "Kyua and Jenkins Testing Framework" for BSD at the Developer and Vendor summit on November 3, 2014 in San Jose, California. In the presentation, Craig Rodrigues described how, for every commit to the FreeBSD source tree, nearly 3000 tests are run using kyua inside a bhyve virtual machine. The kyua test results are exported to JUnit XML format, which is then used by Jenkins to generate web-based test reports with graphs. * Li-Wen Hsu set up a Jenkins build named FreeBSD_Doc-igor to run the Igor tool written by Warren Block. Igor proofreads FreeBSD documentation and reports various errors. * Craig Rodrigues set up a Jenkins build named FreeBSD_HEAD_sparc64 to build the FreeBSD HEAD branch for the sparc64 architecture * Garrett Cooper imported more tests from NetBSD. After this import, there are now over 3000 tests in the /usr/tests directory. * Susan Stanziano from Xinuous ran kyua tests and provided feedback about test errors, running the tests in a bhyve VM. * Andy Zhang from Microsoft ran kyua tests and provided feedback about test errors running in a Hyper-V 2012R2 VM. * Steve Wills ran the FreeBSD tests in Google Compute Engine and provided the test results. * Craig Rodrigues submitted a formula to create a package for kyua in the Homebrew packaging system on OS X. The Homebrew project accepted this. Now, kyua can easily be installed on OS X via a Homebrew package. Hopefully this will make it easier to share more test infrastructure and scripts with OS X. * Craig Rodrigues submitted to the Debian project a kyua package. Approval for this is still pending. A package will make it much easier to install kyua on Linux distributions which use Debian packages such as Debian, Ubuntu, and Linux Mint. Hopefully this will make it easier to share more test infrastructure and scripts with Linux. * Brian Gardner submitted scripts to run the Regression Test Harness for OpenJDK (jtreg). The test results are in JUnit XML format, which can be natively imported into Jenkins. * Ahmed Kamal, an experienced devops expert and past contributor to the Ubuntu project, offered to help Craig Rodrigues with improving the automation and deployment of Jenkins nodes in the FreeBSD cluster using the Saltstack automation framework. Ahmed is interested in helping the FreeBSD project. * Craig Rodrigues worked with Adrian Chadd to set up Jenkins builds of MIPS targets. The next step will be to get kyua tests running inside a QEMU MIPS VM. Open tasks: 1. Set up more builds based on different architectures. 2. Improve the maintenance of nodes in the Jenkins cluster using devops frameworks such as Saltstack. 3. Get feedback for improving the Kyua Quickstart Guide. 4. People interested in helping out should join the freebsd-testing@FreeBSD.org list. __________________________________________________________________ Migration to ELF Tool Chain Tools URL: http://elftoolchain.sourceforge.net Contact: Ed Maste The ELF Tool Chain project provides BSD-licensed implementations of compilation tools and libraries for building and analyzing ELF objects. It started as part of FreeBSD but has moved to a standalone project to encourage wider participation from others in the open-source developer community. FreeBSD's libelf and libdwarf are now imported from upstream sources in contrib/elftoolchain. ELF Tool Chain provides a set of tools equivalent to the GNU Binutils suite. This project's goal is to import these tools into the FreeBSD base system so that we have a set of up-to-date and maintained tools that also provide support for new CPU architectures of interest, such as arm64. The following tools have now been imported and are available by setting the src.conf knob WITH_ELFTOOLCHAIN_TOOLS=3Dyes: * addr2line * nm * size * strings * strip (elfcopy) A ports exp-run uncovered some bugs in these tools. The bugs are being fixed in the FreeBSD source tree and are in the process of being committed to the upstream project. ELF Tool Chain's readelf will be enabled as well once some missing functionality in ELF note parsing is added. ELF Tool Chain's elfcopy provides equivalent functionality to Binutils' objcopy, and accepts the same command-line arguments. For it to be a viable replacement for all uses of objcopy in the base system, it must gain support for writing portable exectuable (PE) format binaries, which are used by UEFI boot code. The ELF Tool Chain project does not currently provide replacements for as, ld, and objdump. For FreeBSD these tools will likely be obtained from the LLVM project. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Import readelf. 2. Add missing functionality to readelf. 3. Add missing functionality to elfcopy and migrate the base system build. 4. Fix issues found by fuzzing inputs to the tools. 5. Switch the default to WITH_ELFTOOLCHAIN_TOOLS. __________________________________________________________________ pkg(8) URL: https://github.com/freebsd/pkg Contact: The pkg team The package development team has released pkg(8) 1.4. This release fixes lots of bugs and adds some new features: * Stricter checking of paths passed via the plist * Change the ABI string to be closer to MACHINE_ARCH * Add three-way merge functionality * Add conservative upgrade support for multi repository configurations * Multirepository priority An important part of the development direction for the 1.4 release was stabilizing the existing features and improving the pkg(8) experience on small/embedded machines (reducing memory usage and speeding up operations). pkg(8) is not only the FreeBSD Package Manager, but also the Package Manager for DragonflyBSD. Support has been added to build pkg(8) on OS X and Linux. This work will allow other Operating Systems the option of adopting pkg(8) to manage their packages and bring new developers into the project. Open tasks: 1. Add more regression tests. 2. Package the FreeBSD base system. 3. Allow using mtree as a plist when creating a package. 4. Implement flexible dependencies. 5. Test the development branch. 6. More developers are needed, check the Issues on Github. __________________________________________________________________ FreeBSD Xen URL: http://wiki.xen.org/wiki/FreeBSD_PVH URL: http://wiki.xen.org/wiki/FreeBSD_Dom0 Contact: Roger Pau Monn=E9 Contact: Justin T. Gibbs During this quarter almost all pending Xen changes have been committed, enabling FreeBSD to be used as Dom0 under the new PVH mode. The set of features supported by FreeBSD is still limited, but it should allow for basic usage of FreeBSD as Dom0. Support for booting Xen from the FreeBSD boot loader will be committed very soon to HEAD. Apart from testing on a variety of hardware, work has now shifted to improve PVH support in Xen itself in order to have feature parity with a traditional PV Dom0 and to declare the PVH ABI as stable. Regarding guest improvements (running FreeBSD as a DomU), there is also ongoing work to add unmapped IO support to Xen blkfront, which is blocked pending some modifications to the generic bounce buffer code. This project is sponsored by Citrix Systems R&D, and Spectra Logic Corporation. Open tasks: 1. Test on different hardware. 2. Improve the performance of the netback and blkback backends. 3. Work with upstream Xen to improve PVH and make it stable. 4. Improve generic bounce buffer code for unmapped bios in order to support blkfront alignment requirements. __________________________________________________________________ Linux Emulation Layer, the Linuxulator URL: https://svnweb.freebsd.org/base/user/dchagin/lemul/ URL: https://reviews.freebsd.org/differential/query/i9Ua2XMYQtNX/ Contact: Dmitry Chagin The main goal of the Linux emulation layer project is the execution on FreeBSD of multithreaded Linux applications that require the glibc library version 2.20 or later to be available. Glibc 2.20 requires a Linux kernel (or emulation thereof) of version 2.6.32 or later. The main obstacle preventing this is that the current Linuxulator uses native FreeBSD processes for emulating Linux threads. This leads to several problems, including problems with process reparenting and dethreading, wait() and signal handling. It would be much better to reuse the FreeBSD kernel code for thread management than to create a completely new codebase for pseudothread management in the Linuxulator. At present, the linux emulation layer project has implemented all of the necessary system calls for supporting glibc 2.20, and more, bringing the emulated Linux kernel version to 2.6.32: * Using native threads for emulating Linux threads * Implemented VDSO support, including DWARF for signal trampolines, which are needed for stack unwinding in pthread_cancel() * Implemented the "vsyscall hack", used by some Linux-based distributions, including CentOS 6 * Implemented the epoll() system call emulation * Added support for x86_64 * Many bugs were fixed The project's code is located in the FreeBSD Project's Subversion repository at base/user/dchagin/lemul (a little bit old). To facilitate merging the improvements back to head, several patches have been placed on reviews.FreeBSD.org with the tag #lemul. Nearly half of the patches have already been approved by Ed Maste and Edward Tomasz Napierala. Open tasks: 1. Review and merge the lemul branch to head within the next month or two. 2. Implement native and Linuxulator inotify() system calls. 3. Implement the ptrace() system call for the x86_64 Linuxulator. 4. Implement the signalfd() and timerfd() system calls for the Linuxulator. 5. Implement Priority Inheritance Futexes for the Linuxulator. 6. Extend xucred support, required for many Linux applications. __________________________________________________________________ PCI SR-IOV Infrastructure URL: https://github.com/rysto32/freebsd/commits/iov_ixl Contact: Ryan Stone PCI Single Root I/O Virtualization (SR-IOV) is an optional part of the PCIe standard that provides hardware acceleration for the virtualization of PCIe devices. When SR-IOV is in use, a function in a PCI device (known as a Physical Function, or PF) will present multiple Virtual PCI Functions (VF) on the PCI bus. These VFs are fully independent PCI devices that have access to the resources of the PF. For example, on a network interface card, VFs could transmit and receive packets independently of the PF. The most obvious use case for SR-IOV is virtualization. A hypervisor like bhyve could instantiate a VF for every VM and use PCI passthrough to assign the VFs to the VMs. This would allow multiple VMs to share access to the PCI device without having to do any expensive communication with the hypervisor, greatly increasing the performance of I/O within a VM. Work on the core PCI infrastructure is complete and undergoing review. Currently it is planned to commit the PCI infrastructure to head by the end of January. In addition to the PCI infrastructure, individual PCI drivers must be extended to implement SR-IOV. An SR-IOV implementation is in progress for the ixl(4) driver, which supports the Intel XL710 family of 40G and 10G NICs. Currently it is planned to have this in review by the end of January. An implementation for ixgbe(4) is also in progress, but there is no timeline for completion. This project is sponsored by Sandvine Inc.. __________________________________________________________________ Process Management Contact: Konstantin Belousov Contact: Peter Holm There were several improvements made to FreeBSD's process management last quarter. The Reaper facility was added, allowing a process to reliably track the running and exiting state of the whole subtree of its processes. It is intended to improve tools like timeout(1) or poudriere, by making it impossible for a runaway grandchild to escape the controlling process. The feature was designed based on similar facilities in DragonFlyBSD and Linux, with some references to Solaris contracts. Committed to HEAD in r275800. The FreeBSD suspension code does not ensure that the system, both software and hardware, is in a steady and consistent state. One aspect is usermode process activity, which is not yet stopped, continuing to making requests to the hardware. It is not realistic to expect drivers to be able to correctly handle the calls after SUSPEND_CHILD. We developed a facility to stop usermode threads at safe points, where they are known to not own and to not wait for kernel resources, in particular, not waiting for device requests finishing. It is based on the existing single-threading code, but extending it to allow external thread to put some processes into stopped state. Also, a facility to sync filesystems before suspend was added, to ensure that consistent metadata and as much as possible of the cached user data are on stable storage, to minimize the damage that could be caused by a failed resume. The code stressed some parts of the system and has led to discovery of a number of bugs in different areas, including process management, buffer cache, and syscall handlers. The bugs were fixed, and the fixes and features commmitted by a series culminating in r275745. During the work described above, it was noted that process spinlock duties are significantly overloaded (the same is true for the process lock). The spinlock was split into per-feature locks in r275121. As a result, it was also possible to eliminate recursion on it in r275372. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Secure Boot URL: https://wiki.freebsd.org/SecureBoot Contact: Edward Tomasz Napiera=B3a UEFI Secure Boot is a mechanism that requires boot drivers and operating system loaders to be cryptographically signed by an authorized key. It will refuse to execute any software that is not correctly signed, and is intended to secure boot drivers and operating system loaders from malicious tampering or replacement. This project will deliver the initial phase of secure boot support for FreeBSD and consists of: * creating ports/packages of the gnu-efi toolchain, Matthew Garrett's shim loader, and sbsigntools * extending the shim to provide an API for boot1.efi to load and verify binaries signed by keys known to the shim * writing uefisign(8), a BSD-licensed utility to sign EFI binaries using Authenticode, as mandated by the UEFI specification. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Ensure that the signature format properly matches UEFI spec requirements. 2. Verify that correctly signed, incorrectly signed, and unsigned loader components are handled properly. 3. Investigate signed kernel ELF objects (including modules). __________________________________________________________________ Timer Function Support for Linuxulator Contact: Bjoern A. Zeeb Since 2006, initial support for Linux timer function compatibility support was present but untested. This update corrects the initial implementation and makes it available to the 32-bit Linuxulator on amd64, not just on i386. Starting with FreeBSD 10.1, this enables users to run another FPGA high-level synthesis toolchain and emulation platform on a FreeBSD system. This project is sponsored by DARPA, and AFRL. __________________________________________________________________ Updating OpenCrypto URL: https://svnweb.freebsd.org/changeset/base/r275732 URL: http://freebsdfoundation.blogspot.com/2014/08/freebsd-foundation-an= nounces-ipsec.html Contact: John-Mark Gurney The project adds support for AES-GCM and AES-CTR modes to the OpenCrypto framework. Both software and AES-NI accelerated versions are functional, working and committed. Ermal Lu=E7i (eri@) is working on adding support for the additional modes to IPsec. This project is sponsored by The FreeBSD Foundation, and Netgate. Open tasks: 1. Commit the port that provides the NIST KAT vectors so that the tests committed can run. __________________________________________________________________ FreeBSD on POWER8 URL: https://wiki.freebsd.org/POWER8 URL: http://www.tyan.com/campaign/openpower/ Contact: Nathan Whitehorn Contact: Justin Hibbits Contact: Adrian Chadd IBM and the OpenPOWER Foundation are pushing for a wider software and hardware ecosystem for POWER8-based systems. Beginning January 3, we have been doing bringup work on a Tyan GN70-BP010 POWER8 server, a quad-core 3 GHz system with 32 hardware threads. The main target for the port is the PowerKVM hypervisor provided on OpenPOWER hardware. This uses the same software interfaces as the PowerVM hypervisor already supported on earlier POWER hardware. The target is to have this operation mode fully supported by FreeBSD 10.2. FreeBSD currently runs under the hypervisor when using a mass storage driver other than the built-in virtualized SCSI; the issues with the SCSI driver should be solved shortly. The longer-term goal is to also operate on the bare system. This requires interaction with the OPAL system firmware and the development of device drivers for the on-board PCI, console, and interrupt controller hardware. As of January 4, the FreeBSD kernel had printed initial messages to the console. This project is sponsored by FreeBSD Foundation . Open tasks: 1. Fix virtualized SCSI driver in PowerKVM. 2. Write OPAL drivers. 3. Integrate loader(8) with petitboot bootloader. __________________________________________________________________ FreeBSD/arm64 URL: https://wiki.freebsd.org/arm64 URL: https://github.com/FreeBSDFoundation/freebsd/tree/arm64-dev Contact: Andrew Turner Contact: Ed Maste Contact: Zbigniew Bodek There is growing interest in ARM's 64-bit architecture. Officially named AArch64, it is also known as ARMv8 and arm64. Andrew Turner started initial work on the FreeBSD/arm64 port at the end of 2012. The FreeBSD Foundation is now collaborating with ARM, Cavium, the Semihalf team, and Andrew Turner to port FreeBSD to arm64, and significant progress was made on the port over the last quarter of 2014. As of the end of the year, FreeBSD boots to single-user mode on arm64, executing both static and dynamic applications. Patches in review allow FreeBSD to boot to multi-user mode, and these are expected to be merged soon. This includes implementing many stub functions in userland and the kernel. With this, FreeBSD has booted to multi-user mode on both the ARM Foundation Model and the QEMU full system emulation. Cavium has supplied a software simulator of their Thunder X hardware. Bringup of FreeBSD has started on this including writing new drivers for the ARM Generic Interrupt Controller v3 (GICv3) and a preliminary driver for the PCIe root complex. With these, FreeBSD is able to boot on this simulator in preparation for testing on hardware. Further work is progressing to add full PCIe bringup and to add support for the GICv3 Interrupt Translation Services (ITS) for MSI-X. Further improvements have been made to the loader to allow it to take the Flattened Device Tree data from UEFI and pass it to the kernel. In the kernel, busdma, CPU identification, and improvements to interrupt handling have been made, along with preliminary KDB support. Hardware for testing the port will be installed in the FreeBSD Test Cluster hosted by Sentex Communications. The first reference platform, Cavium's ThunderX, is expected to arrive in the cluster in mid-January. This project is sponsored by The FreeBSD Foundation, ARM, and Cavium. Open tasks: 1. Bring up and test kernel support on real hardware. 2. Implement the remaining userland libraries and binaries. 3. Produce installable images. __________________________________________________________________ libxo: Generate Text, XML, JSON, and HTML Output URL: http://juniper.github.io/libxo/libxo-manual.html Contact: Marcel Moolenaar Many FreeBSD utilities provide insight into the operational state of a running FreeBSD system and as such are used regularly to monitor the system. These utilities provide their output in a human readable form and sometimes even optimized for the limited width of traditional terminals. Often times these utilities are used by other programs that want to present the output in different ways or as part of other user interfaces. For such use cases, it is infinitely better to work with machine-readable output instead of human-readable output. Juniper Networks has created a library called libxo, which makes it easy for utilities to emit output in various formats. By default, text output is emitted, but with the introduction of the --libxo option this can be changed to XML, JSON, and HTML. The FreeBSD project has imported this library into the base system and is in the process of rewriting utilities to use libxo. Related to this, FreeBSD now also has the xo utility that allows scripts to grow the same capabilities. Instead of using echo or printf in scripts, output can be done using the xo utility. The df, w, and wc utilities have been converted to use libxo. The netstat utility is in the process of being converted and others are planned. Open tasks: 1. FreeBSD contains a lot of utilities that could benefit from having the ability to emit various output formats, too many for a few people to convert in time for FreeBSD 11.0-RELEASE. If you or your company would like to see a particular utility converted, consider learning about libxo and trying to perform the conversion of said utility to help out. __________________________________________________________________ mandoc(1) Support URL: http://mdocml.bsd.lv Contact: Baptiste Daroussin Contact: Ulrich Spoerlein Contact: The Documentation Team mandoc(1) has been made the default manual page formatter on HEAD -- man(1) will use mandoc(1) to format manual pages by default, then fall back to groff(1) if it fails. This change also fixes an issue with the FreeBSD man(1) command not being able to properly deal with ".so" in gzipped manual pages. The documentation team has spent a lot of time fixing issues reported by mandoc(1) in the FreeBSD manual pages. This greatly improves the quality of our manual pages. Most manual pages with remaining issues are from contrib/, for which changes should be reported and fixed upstream. The "manlint" target has also been switched to use mandoc -Tlint, which results in the target being more useful when working on manual pages. Some groff(1) versus mandoc(1) formatting differences have been spotted and reported to mandoc's upstream developers. Open tasks: 1. Switch makewhatis(1) to the version shipped with mandoc(1). 2. Figure out a way to detect mandoc(1)-unfriendly manpages in ports and create catpages with groff(1) for them. 3. Remove groff(1) from the base system. __________________________________________________________________ GNOME on FreeBSD URL: http://www.freebsd.org/gnome URL: https://github.com/freebsd/freebsd-ports-gnome URL: https://wiki.gnome.org/Projects/Jhbuild/FreeBSD Contact: FreeBSD GNOME Team The FreeBSD GNOME Team maintains the GNOME, MATE, and CINNAMON desktop environments and graphical user interfaces for FreeBSD. GNOME 3 is part of the GNU Project. MATE is a fork of the GNOME 2 desktop. CINNAMON is a desktop environment using GNOME 3 technologies but with a GNOME 2 look and feel. This quarter was an exciting time for the GNOME Team. We imported GNOME 3.14.0 and CINNAMON 2.2.16 into the ports tree. At the same time, we removed the old GNOME 2.32 desktop. And two weeks later we updated GNOME to 3.14.2 and CINNAMON to 2.4.2, which was collected while the preparation for the initial GNOME 3.14.0 import was under way. We moved our development repo to GitHub. The repo is structured as follows: the master branch is vanilla FreeBSD Ports, and we have theme branches for topics such as the porting of MATE 1.9 (the mate-1.10 branch) and GNOME 3.15 (the gnome-3.16 branch). The GNOME 3.14 branch (gnome-3.14) is not used or updated any more because the content has been committed to ports, but is kept around for the history. Open tasks: 1. The GNOME website is stale. Work is starting on updating the development section. We could use some help here. 2. MATE 1.10 porting is under way; the latest 1.9 releases are available in the mate-1.10 branch. 3. GNOME 3.16 porting is under way, and is available in the gnome-3.16 branch. __________________________________________________________________ KDE on FreeBSD URL: https://freebsd.kde.org/ URL: https://freebsd.kde.org/area51.php URL: https://wiki.freebsd.org/KDE URL: https://mail.kde.org/mailman/listinfo/kde-freebsd URL: http://portscout.freebsd.org/kde@freebsd.org.html Contact: KDE on FreeBSD team The KDE on FreeBSD team focuses on packaging and making sure that the experience of KDE and Qt on FreeBSD is as good as possible. As mentioned last quarter, Alonso Schaich (alonso@) became a committer and since then has made good progress helping his mentors Raphael Kubo da Costa (rakuco@) and Max Brazhnikov (makc@) maintain all Qt and KDE-related ports. This quarter, Qt 5.3 was finally committed to the ports tree. Extensive work was required, including cleaning up and/or changing a lot of the Qt5 ports infrastructure to make it both easier to maintain the Qt ports as well as finally make it possible to build newer versions when older ones are already installed on the system. We have also updated KDE in our experimental area51 repository and committed several updates to other ports such as KDevelop and KDE Telepathy. Overall, we have worked on the following releases: * CMake 3.1.0 (in area51, exp-run in progress for it to be committed to the ports tree) * Calligra 2.8.6 (in area51) * KDE 4.14.2 (committed to ports), 4.14.3 (in area51) * KDE Telepathy 0.8.0 (committed to ports) * KDevelop 4.7.0 (committed to ports) * Qt 5.3.2 (committed to ports) Tobias Berner has contributed patches to update QtCreator to 3.3.0 as well as KDE Frameworks 5 ports which are under review for inclusion in our experimental area51 repository. Open tasks: 1. Update Qt5 to 5.4.0. 2. Try to contribute to the work on getting rid of HAL on FreeBSD, which seems to be gaining more traction recently. 3. Add KDE Frameworks 5 ports to our experimental repository. __________________________________________________________________ Linux Emulation Ports URL: https://github.com/allanjude/linux-ports URL: https://github.com/vassilisl/freebsd-linux_base-f20 URL: https://svnweb.freebsd.org/base/user/dchagin/lemul/ Contact: Johannes Meixner Contact: Allan Jude Contact: Vassilis Laganakos The Linux emulation stack in the ports collection was upgraded to include CentOS 6.6 on November 11. After smoothing out several bugs that had been introduced, we were able to bump the default version of the Linux userland from Fedora 10 to CentOS 6.6 on December 9th. Providing a more modern Linux userland and support libraries allows a large number of Linux applications to be run on FreeBSD. The goal behind providing an updated Fedora-based userland is to support more desktop-oriented applications, which require newer libraries than are provided by CentOS 6. Providing 64-bit versions of the CentOS userland will allow applications that are only available in 64-bit form, such as a number of scientific and math related applications, to be run on FreeBSD. Support for 64-bit binaries also requires the 64-bit Linux kernel emulation layer from the lemul branch, which requires more testing and review before being merged into HEAD. This project is sponsored by Perceivon Hosting Inc., and ScaleEngine Inc.. Open tasks: 1. Update Allan Jude's 64-bit Linux ports to CentOS 6.6. 2. Add Fedora 20 base/userland ports to ports/head. 3. Refactor Mk/bsd.linux-*.mk to facilitate the above additions. 4. Promote testing and merging of Dmitry Chagin's lemul branch. (Updated Linux kernel emulation, and 64-bit support) __________________________________________________________________ The Graphics Stack on FreeBSD URL: https://wiki.freebsd.org/Graphics URL: http://blogs.freebsdish.org/graphics/ URL: https://github.com/freebsd/freebsd-ports-graphics Contact: FreeBSD Graphics team Mesa was upgraded to 10.3, then 10.4 for FreeBSD 10.1-RELEASE and 11-CURRENT. We test release candidates and therefore this port is now usually updated shortly after a new release. Mesa 10.x brings huge improvements in terms of OpenGL standards support, performance and stability, especially for Radeon owners. Mesa 9.1 is kept for FreeBSD 9.x, but we have plans to fix this; see below. graphics/gbm and devel/libclc are new ports used by Mesa to implement OpenCL. The next step is to finish the port for Mesa's libOpenCL.so, named Clover. This will permit users to run OpenCL programs on Radeon GPUs for now. xserver was upgraded from 1.12 to 1.14. This is the last version of xserver supporting Mesa 9.1. Changes are described in an article on the blog. The most noticeable one is the switch from the input device detection back-end based on HAL to the one based on devd(8). hald(8) is still required by many desktop environments, but the X.Org server itself is free from it. xserver was the last port supporting the WITH_NEW_XORG knob. The knob is now completely removed. This was the occasion to add WITH_NEW_XORG and WITH_KMS to the list of deprecated knobs to help people clean up their make.conf. At the same time, the new-xorg alternate pkg repository was deprecated. After discussion, two options were enabled by default: * TEXTURE_FLOAT in graphics/dri, which allows Mesa to advertise the support for OpenGL 3.0+; * LCD_FILTERING in print/freetype2, which enables the subpixel rendering engine, improving font anti-aliasing. These two packages now provide a better user experience out-of-the-box. Users who are uncomfortable with the options may unset them and rebuild the ports. There is no need to rebuild anything else. On the kernel side, Tijl Coosemans added AGP support back to the TTM memory manager and therefore to the Radeon driver. His work was merged back to stable/10 and will be available in FreeBSD 10.2-RELEASE. We migrated our Ports development tree to Git and GitHub. Tracking changes in the official Ports tree and preparing patches is much easier. Furthermore, we can accept pull requests. All of the reasons behind this change are detailed on the blog and the workflow is described on the wiki. The XDC 2014 (X Developer's Conference) was a great conference. Reviving the relationship with the developers of the graphics stack was a success! A report is available on the blog. Our next items on the roadmap are: 1. Provide FreeBSD 10.1-RELEASE's i915 driver to FreeBSD 9.x users through a new port. This is a work in progress, but it would allow us to remove Mesa 9.1 and make Mesa 10.4 available everywhere. 2. Once Mesa 9.1 is gone, we can update xserver to 1.16. Open tasks: 1. See the "Graphics" wiki page for up-to-date information. __________________________________________________________________ Wine/FreeBSD URL: http://wiki.FreeBSD.org/Wine URL: http://wiki.FreeBSD.org/i386-Wine URL: http://www.winehq.org Contact: Gerald Pfeifer Contact: David Naylor Contact: Kris Moore The Wine on FreeBSD project has been steadily forging ahead for the past three quarters and has updated the ports for the following versions: * Stable releases: 1.6.2 (3 port revisions) * Development releases: 1.7.16 through 1.7.33 The ports have packages built for amd64 (available through the ports emulators/i386-wine and i386-wine-devel) for FreeBSD 8.4, 9.1+, 10.0+, and CURRENT. Accomplishments include: * Upstreaming 33 patches to fix Wine on FreeBSD -- many thanks to Gerald for this work. * Migrating to the USES framework. * Building Wine with the X compositing extension. * Adding support for MPG123 and V4L. * Backporting changes made to the -devel ports to the stable ones and fixing minutiae here and there. * Creating a new Wine port for the Compholio patches. * Changing i386-wine(-devel) to set the LD_LIBRARY_PATH_RPATH variable. * Improving library bundling for i386-wine(-devel). * Various improvements to the patch-nvidia.sh script for i386-wine(-devel). * Various smaller changes. We would like to thank all the volunteers who contributed feedback or even patches. We would also like to welcome kmoore@ to the Wine team. He has been extensively involved in bringing wine-compholio to the Ports Collection. Future development on Wine will focus on: * Creating a 64-bit capable port of Wine (aka Wine64). * Creating a WoW64 capable port of Wine (aka Wine + Wine64). * Fixing directory listing on FreeBSD 8 and 9. Maintaining and improving Wine is a major undertaking that directly impacts end-users on FreeBSD, including many gamers. If you are interested in helping, please contact us. We will happily accept patches, suggest areas of focus, or have a chat. Open tasks: 1. Open Tasks and Known Problems (see the Wine wiki page). 2. FreeBSD/amd64 integration (see the i386-Wine wiki page). 3. Porting WoW64 and Wine64. __________________________________________________________________ Xfce URL: https://wiki.freebsd.org/Xfce Contact: FreeBSD Xfce Team Xfce is a free software desktop environment for Unix and Unix-like platforms, such as FreeBSD. It aims to be fast and lightweight, while still being visually appealing and easy to use. During this quarter, the team has kept these applications up-to-date: * misc/xfce4-weather-plugin 0.8.5 * science/xfce4-equake-plugin 1.3.6 * sysutils/xfce4-netload-plugin 1.2.4 * sysutils/xfce4-systemload-plugin 1.1.2 * www/midori 0.5.9 * x11/xfce4-taskmanager 1.1.0 * x11/xfce4-whiskermenu-plugin 1.4.2 * x11-wm/xfce4-desktop 4.10.3 Two new ports have also been added (taken from our repository): * deskutils/xfce4-volumed-pulse * x11/xfce4-dashboard Moreover, we are working on the next stable release, with these ports being updated: * sysutils/xfce4-power-manager 1.4.2 * x11/xfce4-dashboard 0.3.4 * x11-wm/xfce4-session 4.11.1 We sent some patches to upstream. * bug #11104, to keep 'wallpaper settings' in Ristretto with xfdesktop >=3D 4.11 * bug #11249, add 'Hidden' option in desktop item editor (refused) * bug #11413, to use sysctl(3) and acpi_video(4) for backlight support A FAQ is being written D1305. Open tasks: 1. Find a workaround for when acpi_video(4) is not functional (panel crashes); OpenBSD seems to have same problem. 2. Clean up patch in order to add new panel plugin in ports tree. 3. Continue to work on documentation, especially the Porter's Handbook. __________________________________________________________________ More Michael Lucas Books URL: https://www.michaelwlucas.com/nonfiction/freebsd-mastery-storage-es= sentials URL: http://blather.michaelwlucas.com Contact: Michael Lucas The first small FreeBSD Book, "FreeBSD Mastery: Storage Essentials" is available. Lucas is moving on to FreeBSD books on ZFS, Specialty Filesystems, and jails. They will hopefully be available by BSDCan 2015. Get status updates on his blog, or follow @mwlauthor on Twitter. Open tasks: 1. Push BSDCan out to June, so he has more time to write the new books. __________________________________________________________________ New Translators Mailing List Contact: FreeBSD Translators Mailing List A new mailing list has been created for people translating FreeBSD documents and programs from English into other languages. Discussions can include methods, tools, and techniques. Existing translators are encouraged to join so there is a single point of contact. New translators and those who wish to help with translation are welcome. New members are asked to introduce themselves and mention the languages they are interested in translating. Open tasks: 1. Encourage existing translators to join. 2. Welcome and educate new volunteers. 3. Work on implementing newer and easier translation systems and tools. __________________________________________________________________ Creating Vagrant Images with Packer URL: http://blogs.freebsdish.org/brd/2014/12/22/freebsd-packer-vagrant/ URL: https://github.com/so14k/packer-freebsd Contact: Brad Davis We have developed a recipe to use Packer to create FreeBSD Vagrant images to run on VMware and VirtualBox. Packer is a tool for creating identical machine images for multiple platforms from a single source configuration. Vagrant is a tool to create and configure lightweight, reproducible, and portable development environments. To get started, clone the Git repo and follow the directions in the README. More information is available from the Packer and Vagrant websites. __________________________________________________________________ FreeBSD Forum Software Migration Contact: FreeBSD Forums Administration Team With funding from the FreeBSD Foundation, the FreeBSD forums were migrated to XenForo software. The new software is far more capable and easy to use. While the entire forum team contributed, Daniel Gerzo did an excellent job importing existing users and messages and bringing back the often-requested "Thanks" feature. The upgrade was completed in time to be ready for the influx of new users from the release of FreeBSD 10.1, and we have already seen an increase in usage. Developers with an @FreeBSD.org address can contact forum administrators to obtain the highly-desired "@" suffix on their forum user name along with a Developer flag. We want to thank the Foundation for making this possible, and the users for their patience and continued presence on the forums! This project is sponsored by The FreeBSD Foundation . Open tasks: 1. Encourage more developers and users to try the new forums. 2. Continue getting feedback from users for tuning and improvements. __________________________________________________________________ The FreeBSD Foundation URL: http://www.FreeBSDFoundation.org/ URL: http://freebsdjournal.com/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Most of the funding is used to support FreeBSD development projects, conferences, and developer summits; purchase equipment to grow and improve the FreeBSD infrastructure; and provide legal support for the Project. We ended the year exceeding our fundraising goal, by raising over $2,372,132, from 1670 donors! Thank you to everyone who made a donation in 2014. We produced issues five and six of the FreeBSD Journal, ending the year with over 6300 subscribers, exceeding our first-year goal of 5000 subscribers. We also added the desktop/digital edition, so people can read the magazine from their browsers. We also hosted a meeting with the Journal Editorial Board and worked out the editorial calendar for the next two years. This includes topics and articles for the future issues. We were a gold sponsor of EuroBSDCon 2014, and a sponsor of the preceding Developer Summit. A few of our team members attended, which allowed us to have an informal face-to-face board meeting, with a focus on supporting the European region. Kirk McKusick gave a two-day FreeBSD tutorial and Erwin Lansing helped run the Developer Summit. We sponsored 5 FreeBSD contributors to attend the conference. We were a sponsor of the Grace Hopper Conference. Dru Lavigne gave an "introduction to FreeBSD" presentation, that was well attended. We also sponsored Shteryana Shopova to represent FreeBSD, along with Dru, at our booth. We were a sponsor of MeetBSD. Most of our team members attended this conference. Kirk McKusick gave a talk on BSD history. We also had a booth, and raised over $2,200 in donations. We sponsored one person to attend this conference. George organized and ran the two-day Silicon Valley Vendor and Developer Summit following MeetBSD. A lot of work gets started and accomplished at these summits, for example, Kirk worked with various folks to get the ino64 (64-bit inode numbers) project moving. It started in 2011 as a Summer of Code project and has sputtered since getting pushed into the system. In addition to the above conferences, we helped promote FreeBSD at the following conferences: * All Things Open * Ohio Linux Fest * LISA LISA had a great turnout for Dru Lavigne's FreeBSD BoF talk. We visited a few large FreeBSD users in the Bay Area to discuss their use of FreeBSD, plans, and needs, and help facilitate collaboration between them and the Project. Cheryl Blain joined our board, bringing a strong background in business development and fundraising. We received the largest donation in our history, and our treasurer put together an endowment strategy for us to follow. We increased our FreeBSD marketing efforts to help promote and advocate for FreeBSD, as well as educate people on FreeBSD. Some our FreeBSD marketing highlights include: * Created the FreeBSD 10 brochure * Created the Get Involved brochure for recruiting * Created a testimonial flyer to encourage more companies to write FreeBSD testimonials for us. These flyers are available on the FreeBSD Foundation site for FreeBSD advocates to promote FreeBSD at conferences around the world. We also put ads for the Foundation and FreeBSD in the FreeBSD Journal and USENIX ;login: magazine. We are producing a monthly newsletter to highlight what we did the previous month to support the FreeBSD Project. We also produced our December semi-annual newsletter. We redesigned and launched phase 1 of our website. It should be easier to navigate and find the information you need to get help from or to help the Foundation. Glen Barber visited the Microsoft main campus and worked with Microsoft Hyper-V developers to resolve outstanding issues with providing FreeBSD images for the Microsoft Azure platform. Glen also visited the NYI colocation facility to install and configure new servers purchased by the Foundation. We finished the 10.1-RELEASE cycle. Our project development staff and contractors have been working on various projects to add features to and improve FreeBSD. Some of their reports are included in this overall report. Some projects that were worked on this quarter were adding support for 64-bit ARM architecture to FreeBSD, integration work on the vt(4) updated console and UEFI boot support, Secure Boot, refining the in-kernel iSCSI target and initiator stack, an autofs-based automount daemon, migrating to the ELF Tool Chain, and implementing modern AES modes in FreeBSD's cryptographic framework. To read more about how we helped support the FreeBSD Project and community, read our semi-annual newsletter. __________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGgBAEBCgAGBQJUvdl5AAoJECjZpvNk63USvm4MIONtg7ZxQXtS6ebzHtKSyYxe fbj0bThjJBQwvgxuM8sqAI2tCmDI/BCKh5KsNGYQLs8kVYtFE+N8AWitLlx+fxT1 iOge5UTL2GK2jZObON20jqojJU5waYZvEDyu+cLZFBl92IA/Q1iBbtyhpMOS02Fc sLsMZv/mNmmw8xQbvVjOFFO98DeK67ulgj0g1in6iSiM+FWBPDm/aGbOVGhUmtFS OjmX4SnZlmOrm6WVpI84TAb7XqGXqJ09BbVKWaPK4nug+BrNH3k9LjAkMZGKtMmF Jls34T6JdxM+cSDik2VqkiAlr+k7nJUjKe8TnFrIBgCjq+5tRfTiq4Laly2/U25L 3GEYeoaAgColqVx3vDSKukbyaBOeDy79dtlqnCPS3Tjv1+Kob2w3zz6W7WfMX3cj Hg5ZfUivTPq2CI5+tVe3SM8eBP+BerxU4GXFWE+a6uWUS+L/Zxyu864z2bk6noNI Rd4aZkihamW2nzxqa/+pJMFq88y5afWgLFvHGwl9T092Pgc=3D =3DVGnI -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 07:30:57 2015 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 95655485 for ; Tue, 20 Jan 2015 07:30:57 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 288611AE for ; Tue, 20 Jan 2015 07:30:57 +0000 (UTC) Received: from maggot.black-earth.co.uk (maggot.black-earth.co.uk [81.2.117.101]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.15.1/8.15.1) with ESMTPSA id t0K7Ucs3050334 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 20 Jan 2015 07:30:39 GMT (envelope-from matthew@FreeBSD.org) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org DKIM-Filter: OpenDKIM Filter v2.9.2 smtp.infracaninophile.co.uk t0K7Ucs3050334 Authentication-Results: smtp.infracaninophile.co.uk/t0K7Ucs3050334; dkim=none reason="no signature"; dkim-adsp=none; dkim-atps=neutral Message-ID: <54BE041E.6060104@FreeBSD.org> Date: Tue, 20 Jan 2015 07:30:38 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: graphical assistant for pkg References: <54BDAFDD.9040004@gmail.com> In-Reply-To: <54BDAFDD.9040004@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.5 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk 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, 20 Jan 2015 07:30:57 -0000 On 2015/01/20 01:31, lucaslucaslucas24 wrote: > Im thinking in graphical assistant for pkg, as synaptic in gnu/linux deb's. > > with options for select some, all, any packages; options for update, etc. > > ¿what you think about my idea? We would welcome a contribution of a well written package management tool based on libpkg.so, and I would be happy to add it to the ports collection. There is already some work in this area -- see PC-BSD for instance, but nothing that I think is really a 'must have' for every desktop environment. Cheers, Matthew From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 08:32:22 2015 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 5DCBE2E3 for ; Tue, 20 Jan 2015 08:32:22 +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 00B5B9A5 for ; Tue, 20 Jan 2015 08:32:21 +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 t0K8WC1M089941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jan 2015 10:32:12 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t0K8WC1M089941 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t0K8WCSS089940; Tue, 20 Jan 2015 10:32:12 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 20 Jan 2015 10:32:12 +0200 From: Konstantin Belousov To: Ryan Stone Subject: Re: Sleeping thread held mutex in vm_pageout_oom() Message-ID: <20150120083212.GC42409@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, 20 Jan 2015 08:32:22 -0000 On Mon, Jan 19, 2015 at 05:56:24PM -0500, Ryan Stone wrote: > I recently had a system where a DIMM failed and the OOM killer was > constantly kicking in due to a memory-hungry daemon being constantly > restarted. This ended up triggering a race condition in the OOM > killer leading to this panic: > > Sleeping thread (tid 100075, pid 8) owns a non-sleepable lock > sched_switch() at 0xffffffff8048386d = sched_switch+0x16d > mi_switch() at 0xffffffff80469dd6 = mi_switch+0x186 > sleepq_wait() at 0xffffffff80499204 = sleepq_wait+0x44 > __lockmgr_args() at 0xffffffff8044b88b = __lockmgr_args+0x67b > vop_stdlock() at 0xffffffff804d3689 = vop_stdlock+0x39 > ---Type to continue, or q to quit--- > VOP_LOCK1_APV() at 0xffffffff8069da42 = VOP_LOCK1_APV+0x52 > _vn_lock() at 0xffffffff804ed627 = _vn_lock+0x47 > vm_object_deallocate() at 0xffffffff8061eef3 = vm_object_deallocate+0x203 > vm_map_entry_deallocate() at 0xffffffff80616d2c = vm_map_entry_deallocate+0x4c > vm_map_process_deferred() at 0xffffffff80616d62 = vm_map_process_deferred+0x32 > vm_map_remove() at 0xffffffff806183ff = vm_map_remove+0x6f > vmspace_free() at 0xffffffff80619206 = vmspace_free+0x56 > vm_pageout_oom() at 0xffffffff806230d1 = vm_pageout_oom+0x181 > vm_pageout() at 0xffffffff8062410b = vm_pageout+0x90b > fork_exit() at 0xffffffff8043a382 = fork_exit+0x112 > fork_trampoline() at 0xffffffff8063385e = fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff80c3be1d00, rbp = 0 --- > panic: sleeping thread > cpuid = 5 > curthread = grep/grep (82989/100544) > cpu_ticks = 1848294656444 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff801e52ba = db_trace_self_wrapper+0x2a > panic() at 0xffffffff80461608 = panic+0x228 > propagate_priority() at 0xffffffff8049cbde = propagate_priority+0x15e > turnstile_wait() at 0xffffffff8049d278 = turnstile_wait+0x1b8 > _mtx_lock_sleep() at 0xffffffff80451af1 = _mtx_lock_sleep+0xf1 > ---Type to continue, or q to quit--- > _mtx_lock_flags() at 0xffffffff80451c75 = _mtx_lock_flags+0x75 > exit1() at 0xffffffff804367de = exit1+0x36e > sys_exit() at 0xffffffff8043731e = sys_exit+0xe > syscallenter() at 0xffffffff8049b324 = syscallenter+0x104 > syscall() at 0xffffffff80649bfc = syscall+0x4c > Xfast_syscall() at 0xffffffff806335f2 = Xfast_syscall+0xe2 > --- syscall (1, FreeBSD ELF64, sys_exit), rip = 0x300a2df9c, rsp = > 0x7ffffffd40c8, rbp = 0x7ffffffd40e0 --- > Uptime: 7m19s > > > The root cause is that vm_pageout_oom() acquires a reference on a > process's vmspace while holding its PROC_LOCK(), then the process > exited. This left vm_pageout_oom() holding the only reference on the > vmspace, so when it dropped the reference it called into > vm_map_remove() and wound up sleeping while still holding the > PROC_LOCK(). This was under FreeBSD 8 but the code in head does not > seem to have changed here. Well, the root cause is that the vmspace reference is dropped while owning the process lock (a mutex). > > I'm not quite familiar with the lock mechanisms here so I'm not sure > how to fix it. Does vm_pageout_oom() need to _PHOLD() the process > while holding the PROC_LOCK(), then drop the lock, then acquire the > vmspace reference? It appears that's how other places that call > vmspace_acquire_ref() work. Yes, I think it is enough to keep a hold ref on the big process instead of keeping it locked. This should also allow to change trylock for the next iteration process to plain lock. On the other hand, it seems reasonable to keep trylock for vm_map locking, since in OOM situation usually some processes are stuck waiting for page while maps are locked. Holding the process lock for bigproc prevents not only exit, but also execve from executing while oom loop selected the victim. This makes it possible for a race where large process, selected for oom kill, performs exec meantime and becoming small process, and then being killed at the end of oom loop. I think it is acceptable. diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c index ca9d7f9..d9f28c3 100644 --- a/sys/vm/vm_pageout.c +++ b/sys/vm/vm_pageout.c @@ -1516,8 +1516,8 @@ vm_pageout_oom(int shortage) FOREACH_PROC_IN_SYSTEM(p) { int breakout; - if (PROC_TRYLOCK(p) == 0) - continue; + PROC_LOCK(p); + /* * If this is a system, protected or killed process, skip it. */ @@ -1557,11 +1557,14 @@ vm_pageout_oom(int shortage) PROC_UNLOCK(p); continue; } + _PHOLD(p); if (!vm_map_trylock_read(&vm->vm_map)) { - vmspace_free(vm); + _PRELE(p); PROC_UNLOCK(p); + vmspace_free(vm); continue; } + PROC_UNLOCK(p); size = vmspace_swap_count(vm); vm_map_unlock_read(&vm->vm_map); if (shortage == VM_OOM_MEM) @@ -1573,16 +1576,19 @@ vm_pageout_oom(int shortage) */ if (size > bigsize) { if (bigproc != NULL) - PROC_UNLOCK(bigproc); + PRELE(bigproc); bigproc = p; bigsize = size; - } else - PROC_UNLOCK(p); + } else { + PRELE(p); + } } sx_sunlock(&allproc_lock); if (bigproc != NULL) { + PROC_LOCK(bigproc); killproc(bigproc, "out of swap space"); sched_nice(bigproc, PRIO_MIN); + _PRELE(bigproc); PROC_UNLOCK(bigproc); wakeup(&vm_cnt.v_free_count); } From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 15:34:18 2015 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 1BE3AE5; Tue, 20 Jan 2015 15:34:18 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C18D3ED9; Tue, 20 Jan 2015 15:34:17 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id t0KFYGXC094187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 20 Jan 2015 08:34:16 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id t0KFYGOo094184; Tue, 20 Jan 2015 08:34:16 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 20 Jan 2015 08:34:16 -0700 (MST) From: Warren Block To: Matthew Seaman Subject: Re: graphical assistant for pkg In-Reply-To: <54BE041E.6060104@FreeBSD.org> Message-ID: References: <54BDAFDD.9040004@gmail.com> <54BE041E.6060104@FreeBSD.org> 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 (wonkity.com [127.0.0.1]); Tue, 20 Jan 2015 08:34:16 -0700 (MST) Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT 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: Tue, 20 Jan 2015 15:34:18 -0000 On Tue, 20 Jan 2015, Matthew Seaman wrote: > On 2015/01/20 01:31, lucaslucaslucas24 wrote: >> Im thinking in graphical assistant for pkg, as synaptic in gnu/linux deb's. >> >> with options for select some, all, any packages; options for update, etc. >> >> ¿what you think about my idea? > > We would welcome a contribution of a well written package management > tool based on libpkg.so, and I would be happy to add it to the ports > collection. > > There is already some work in this area -- see PC-BSD for instance, but > nothing that I think is really a 'must have' for every desktop environment. Wasn't there also a summer of code project for that recently? From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 17:14:16 2015 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 F054B359; Tue, 20 Jan 2015 17:14:16 +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 8FDB1D77; Tue, 20 Jan 2015 17:14:16 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id bs8so25715672wib.1; Tue, 20 Jan 2015 09:14:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=vRjZzkqvt96ySM3Ic+hHcbLv8Gtg5JfeFZKzxmeQctE=; b=nrJsyV+5arMi4wnhTQIta2gbdBp+Et7hDSzmAKGBHpDLgamoUeZz2g8dtzw/2R0TNq acZlxW2BSCA5VcBKINuuZadd+U9QsVbug2O2Y3pzfoOl2cxOEErlLQizAlZmBXAF2Kvv fZeV4WbeP4AoeTtDJ4ikeKU9zxmxhgodhTcIM2N4x6jyhiMyBSR9h9gMCzfgvmF8V965 Kzar7mAGfDPqJwWHaACVd9wiPTGYofYrR6W/7VLF3KP3v82CGzPLBCNFoIxSxBYOVxt7 /I0o6ZBoviT89NqIBzH7s5otyEy/Gz1wTp4PFMRqnX/GQeuEjz/zg6nL6F1Z7xgPFleS xV5w== X-Received: by 10.194.190.162 with SMTP id gr2mr65257473wjc.13.1421774055038; Tue, 20 Jan 2015 09:14:15 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id n3sm22039361wja.36.2015.01.20.09.14.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Jan 2015 09:14:14 -0800 (PST) Sender: Baptiste Daroussin Date: Tue, 20 Jan 2015 18:14:11 +0100 From: Baptiste Daroussin To: Warren Block Subject: Re: graphical assistant for pkg Message-ID: <20150120171411.GA13897@ivaldir.etoilebsd.net> References: <54BDAFDD.9040004@gmail.com> <54BE041E.6060104@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org, Matthew Seaman 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, 20 Jan 2015 17:14:17 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 20, 2015 at 08:34:16AM -0700, Warren Block wrote: > On Tue, 20 Jan 2015, Matthew Seaman wrote: >=20 > > On 2015/01/20 01:31, lucaslucaslucas24 wrote: > >> Im thinking in graphical assistant for pkg, as synaptic in gnu/linux d= eb's. > >> > >> with options for select some, all, any packages; options for update, e= tc. > >> > >> =BFwhat you think about my idea? > > > > We would welcome a contribution of a well written package management > > tool based on libpkg.so, and I would be happy to add it to the ports > > collection. > > > > There is already some work in this area -- see PC-BSD for instance, but > > nothing that I think is really a 'must have' for every desktop environm= ent. >=20 > Wasn't there also a summer of code project for that recently? There have been at least 2 last summer but nothing came out Bapt --/04w6evG8XlLl3ft Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlS+jOMACgkQ8kTtMUmk6ExeKACgob/R/acy8bMvtIdNpRqrZqnW lWkAnRVDX2BHvG4NuVWUq64KV1x5g7uS =pNXP -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 07:53:58 2015 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 A2792B94 for ; Wed, 21 Jan 2015 07:53:58 +0000 (UTC) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::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 5A0DC6C6 for ; Wed, 21 Jan 2015 07:53:58 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id n8so31946846qaq.6 for ; Tue, 20 Jan 2015 23:53:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=JlvLNA2gBMdLven74bNdXBpj1KrCLuDs+ba4wM6+TuQ=; b=Hqen2TmmdNZH3Y1nU13ztcPNIdDHIxjEcRhqQu0lyE3w6BSwHhjX0F4KX8FojWJGv/ 4vM9PAV9bFQRppsMRrQcmr1+IoPo+nSGZpeQjMMKc0X389Qhy4aDAm1YPTtAaQp3Cjbe a4Nw3xDQ0/mVFAtSuiEfjH7wTTil3RuL5yjWPTaZd6A8HALdxVnSgcjZb1ZLsMTfw62d tceenjTLxO+Y9SWhpSGv2hSQd17gPkm5ioVFUekqDH6meeCxnIDJhCBtGRlFZj90ioDe VWOLVbKINeVt+In66wO0KMEHkZfGpuDwNLjs4fsEh5XZXbjMfDM9XCOk9oTEkjh6RvPg QgIg== MIME-Version: 1.0 X-Received: by 10.229.225.195 with SMTP id it3mr18387375qcb.24.1421826837491; Tue, 20 Jan 2015 23:53:57 -0800 (PST) Sender: hiren.panchasara@gmail.com Received: by 10.96.73.69 with HTTP; Tue, 20 Jan 2015 23:53:57 -0800 (PST) In-Reply-To: References: Date: Tue, 20 Jan 2015 23:53:57 -0800 X-Google-Sender-Auth: z0Y-kfVLP8nGW7E8JYLaKISaAkY Message-ID: Subject: Re: etherswitchcfg - TPLINK TP-WR1043ND From: hiren panchasara 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: Wed, 21 Jan 2015 07:53:58 -0000 On Fri, Jan 16, 2015 at 11:07 AM, Wojciech Puchar wrote: > what i am doing wrong. > > I want all 5 ports to act just like one subnet. > > i do > > /sbin/etherswitchcfg vlangroup0 vlan 1 members 0,1,2,3,4,5 > /sbin/etherswitchcfg vlangroup1 members none > > > port 1,2,3 or 4 works fine. > > port 0 shows connection as well, but no ping. Can you post o/p of 'etherswitchcfg'? I've ran into this where port 0 is part of a different vlan. cheers, Hiren From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 12:00:59 2015 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 3922DBB8; Wed, 21 Jan 2015 12:00:59 +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 9EBBF6DF; Wed, 21 Jan 2015 12:00:58 +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 t0LC0mRY032242; Wed, 21 Jan 2015 13:00:49 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: puchar.net: Host laptop.wojtek.intra [10.1.0.2] claimed to be [10.1.0.2] Date: Wed, 21 Jan 2015 13:00:44 +0100 (CET) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: hiren panchasara Subject: Re: etherswitchcfg - TPLINK TP-WR1043ND 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]); Wed, 21 Jan 2015 13:00:49 +0100 (CET) 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, 21 Jan 2015 12:00:59 -0000 > > Can you post o/p of 'etherswitchcfg'? > I've ran into this where port 0 is part of a different vlan. not sure what "o/p" means but full output is etherswitchcfg -v info etherswitch0: Realtek RTL8366RB with 6 ports and 16 VLAN groups etherswitch0: VLAN capabilities=0<> port0: flags=0<> media: Ethernet autoselect (none) status: no carrier port1: flags=0<> media: Ethernet autoselect (1000baseT ) status: active port2: flags=0<> media: Ethernet autoselect (none) status: no carrier port3: flags=0<> media: Ethernet autoselect (none) status: no carrier port4: flags=0<> media: Ethernet autoselect (100baseTX ) status: active port5: flags=0<> media: Ethernet 1000baseT status: active vlangroup0: vlan: 1 members 0,1,2,3,4,5 vlangroup1: vlan: 2 members none vlangroup2: vlan: 3 members none vlangroup3: vlan: 4 vlangroup4: vlan: 5 members none vlangroup5: vlan: 6 members none vlangroup6: vlan: 7 members none vlangroup7: vlan: 8 members none vlangroup8: vlan: 9 members none vlangroup9: vlan: 10 members none vlangroup10: vlan: 11 members none vlangroup11: vlan: 12 members none vlangroup12: vlan: 13 members none vlangroup13: vlan: 14 members none vlangroup14: vlan: 15 members none vlangroup15: vlan: 16 members none if i connect cable to port0, etherswitch shows it is connected, but no communication From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 12:47:56 2015 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 7E0115DB for ; Wed, 21 Jan 2015 12:47:56 +0000 (UTC) Received: from sh4-5.1blu.de (sh4-5.1blu.de [178.254.11.41]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 42A0DB75 for ; Wed, 21 Jan 2015 12:47:56 +0000 (UTC) Received: from ftp51246-2575596 by sh4-5.1blu.de with local (Exim 4.76) (envelope-from ) id 1YDu7x-0004fQ-R9 for freebsd-hackers@freebsd.org; Wed, 21 Jan 2015 13:11:17 +0100 Date: Wed, 21 Jan 2015 13:11:17 +0100 From: Matthias Apitz To: freebsd-hackers@freebsd.org Subject: make installworld/kernel of an amd64 system into an i386 system Message-ID: <20150121121117.GA10645@sh4-5.1blu.de> Reply-To: Matthias Apitz MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 7.0-RELEASE (i386) 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: Wed, 21 Jan 2015 12:47:56 -0000 Hello, I actually run on one of my laptops (Acer C720) a very fresh -HEAD (r276659), but in 32bit; I want to change this to amd64; I produced a amd64 memstick which boots fine and also has the sources and obj tree which was used to create the memstick in /usr/local/acerc720/src /usr/local/acerc720/obj-amd64 What I now think as update procedure to install amd64 into the laptop is: - boot the amd64 system from USB - mount the old i386 root in /dev/ada0p2 as /mnt (there is only this one big file system, /dev/ada0p1 is boot and /dev/ada0p3 is swap) - run cd /usr/local/acerc720/src MAKEOBJDIRPREFIX=/usr/local/acerc720/obj-amd64 export MAKEOBJDIRPREFIX make installworld DESTDIR=/mnt make installkernel DESTDIR=/mnt make distrib-dirs DESTDIR=/mnt make distribution DESTDIR=/mnt mv /mnt/usr/local/lib /mnt/usr/local/lib32 cp /etc/rc.conf /mnt/etc cp /boot/loader.conf /mnt/boot echo 'ldconfig32_paths="/usr/lib32 /usr/local/lib32"' >> /mnt/etc/rc.conf reboot I know that it may happen that not all of the installed packages (with the shared objects now in /usr/local/lib32) will work, and I have to recompile some (or even all) of them, but the system should come up, I think. Any comments about the procedure or something I missed out? Thanks matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 13:00:43 2015 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 45807D51; Wed, 21 Jan 2015 13:00:43 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CD1F4CB4; Wed, 21 Jan 2015 13:00:42 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id fb4so20652538wid.2; Wed, 21 Jan 2015 05:00:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qClNatwEdgGi10PYAiEIhOy+QqjDJFQvKHRo58ZkZBg=; b=DfGL45Z89BmeN4KZhStFiSLL6FvX+uVsxi3XGygCFWr4nrh0jph5Qmvjly7byv/OD8 ol++mO4ZkuR2Avw3MdIMWzdmd3Vr6ZgNYWr0AaEV726ihEWCoU41zP9sziZL/X8nsCfE Huvyy6ouafV4xlA22u86ryKdEf0ujcG95s+klKCG6W/xEUl0J9Z+2K/NZe0+lToHBli6 /YugutvNn2jh2wxRoIM7hgoSL2Vmrufa0TCi2b3nvMCUfnNyqbe7Mh3s/KYRVkwZlijs 3iHFnB65yl9HxTzVJlHacT34374h0cwTcammLTyquRC23E/z0ZjeUmg7qjjKa/zhsJlq FV8g== MIME-Version: 1.0 X-Received: by 10.180.98.202 with SMTP id ek10mr32392097wib.56.1421845241219; Wed, 21 Jan 2015 05:00:41 -0800 (PST) Received: by 10.216.213.145 with HTTP; Wed, 21 Jan 2015 05:00:41 -0800 (PST) In-Reply-To: References: Date: Wed, 21 Jan 2015 11:00:41 -0200 Message-ID: Subject: Re: etherswitchcfg - TPLINK TP-WR1043ND From: Luiz Otavio O Souza To: Wojciech Puchar Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , hiren panchasara 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, 21 Jan 2015 13:00:43 -0000 On 21 January 2015 at 10:00, Wojciech Puchar wrote: >> >> Can you post o/p of 'etherswitchcfg'? >> I've ran into this where port 0 is part of a different vlan. > > not sure what "o/p" means but full output is > > etherswitchcfg -v info > etherswitch0: Realtek RTL8366RB with 6 ports and 16 VLAN groups > etherswitch0: VLAN capabilities=0<> ^^^^^^^ > port5: > flags=0<> > media: Ethernet 1000baseT > status: active Looks like you are using somewhat old code. I've committed a few fixes last time I tried my 1043. With latest fixes you should not see the 'half-duplex' on CPU port and VLAN capability is also set (together with a few other changes). Can you try with a more recent head ? Luiz From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 14:55:38 2015 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 5CE45A65 for ; Wed, 21 Jan 2015 14:55:38 +0000 (UTC) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F1981C86 for ; Wed, 21 Jan 2015 14:55:37 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.9/8.14.9) with ESMTP id t0LEtUTQ084004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Jan 2015 15:55:30 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.9/8.14.9/Submit) with ESMTP id t0LEtTWN084001; Wed, 21 Jan 2015 15:55:30 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Wed, 21 Jan 2015 15:55:29 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: Matthias Apitz Subject: Re: make installworld/kernel of an amd64 system into an i386 system In-Reply-To: <20150121121117.GA10645@sh4-5.1blu.de> Message-ID: References: <20150121121117.GA10645@sh4-5.1blu.de> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.fig.ol.no Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT 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, 21 Jan 2015 14:55:38 -0000 On Wed, 21 Jan 2015 13:11+0100, Matthias Apitz wrote: > > Hello, > > I actually run on one of my laptops (Acer C720) a very fresh -HEAD > (r276659), but in 32bit; I want to change this to amd64; I produced a > amd64 memstick which boots fine and also has the sources and obj tree which > was used to create the memstick in > > /usr/local/acerc720/src > /usr/local/acerc720/obj-amd64 > > What I now think as update procedure to install amd64 into the laptop > is: > > - boot the amd64 system from USB > - mount the old i386 root in /dev/ada0p2 as /mnt (there is only this one big > file system, /dev/ada0p1 is boot and /dev/ada0p3 is swap) > - run > cd /usr/local/acerc720/src > MAKEOBJDIRPREFIX=/usr/local/acerc720/obj-amd64 export MAKEOBJDIRPREFIX > make installworld DESTDIR=/mnt > make installkernel DESTDIR=/mnt > make distrib-dirs DESTDIR=/mnt > make distribution DESTDIR=/mnt > mv /mnt/usr/local/lib /mnt/usr/local/lib32 > cp /etc/rc.conf /mnt/etc > cp /boot/loader.conf /mnt/boot > echo 'ldconfig32_paths="/usr/lib32 /usr/local/lib32"' >> /mnt/etc/rc.conf > reboot > > I know that it may happen that not all of the installed packages (with the shared > objects now in /usr/local/lib32) will work, and I have to recompile > some (or even all) of them, but the system should come up, I think. > > Any comments about the procedure or something I missed out? I experimented with migrating i386 to amd64 earlier this January. I used the official snapshots to do the main part of the transition, and that route is a timesaver in my book. Be sure to omit /boot, /etc, /root, and /var from the base distribution (base.txz). I ensured all ports were up-to-date before committing the transition to amd64. And I never messed with /usr/local/lib, since I instantly rebuilt all ports. Using ports-mgmt/portmaster is better than using ports-mgmt/portupgrade, at least until all ports are 64-bit native executables/libraries. My writeup is available for anyone interested: http://ximalas.info/2015/01/17/migrating-freebsd-from-i386-to-amd64/ Use at your own risk. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 15:15:01 2015 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 6CD0C11F for ; Wed, 21 Jan 2015 15:15:01 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 2DD74EE0 for ; Wed, 21 Jan 2015 15:15:00 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t0LFEwPs030704; Wed, 21 Jan 2015 07:14:58 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t0LFEwLf030703; Wed, 21 Jan 2015 07:14:58 -0800 (PST) (envelope-from david) Date: Wed, 21 Jan 2015 07:14:58 -0800 From: David Wolfskill To: Matthias Apitz Subject: Re: make installworld/kernel of an amd64 system into an i386 system Message-ID: <20150121151458.GO1059@albert.catwhisker.org> Reply-To: hackers@freebsd.org Mail-Followup-To: hackers@freebsd.org, Matthias Apitz , freebsd-hackers@freebsd.org References: <20150121121117.GA10645@sh4-5.1blu.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="991t1H9DIskWxVIu" Content-Disposition: inline In-Reply-To: <20150121121117.GA10645@sh4-5.1blu.de> 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: Wed, 21 Jan 2015 15:15:01 -0000 --991t1H9DIskWxVIu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 21, 2015 at 01:11:17PM +0100, Matthias Apitz wrote: >=20 > Hello, >=20 > I actually run on one of my laptops (Acer C720) a very fresh -HEAD > (r276659), but in 32bit; I want to change this to amd64; I produced a > amd64 memstick which boots fine and also has the sources and obj tree whi= ch > was used to create the memstick in >=20 > /usr/local/acerc720/src > /usr/local/acerc720/obj-amd64 >=20 > What I now think as update procedure to install amd64 into the laptop > is: >=20 > - boot the amd64 system from USB > - mount the old i386 root in /dev/ada0p2 as /mnt (there is only this one = big > file system, /dev/ada0p1 is boot and /dev/ada0p3 is swap) > - run > cd /usr/local/acerc720/src > MAKEOBJDIRPREFIX=3D/usr/local/acerc720/obj-amd64 export MAKEOBJDIRPREFIX > make installworld DESTDIR=3D/mnt > make installkernel DESTDIR=3D/mnt > make distrib-dirs DESTDIR=3D/mnt > make distribution DESTDIR=3D/mnt > mv /mnt/usr/local/lib /mnt/usr/local/lib32 > cp /etc/rc.conf /mnt/etc > cp /boot/loader.conf /mnt/boot > echo 'ldconfig32_paths=3D"/usr/lib32 /usr/local/lib32"' >> /mnt/etc/rc.= conf > reboot > ... > Any comments about the procedure or something I missed out? > ... I am in the habit of setting up machines to use MBR, and have at least 2 of the resulting slices bootable. In a situation similar to yours, I had bootstrapped a new desktop to running stable/10 i386, and wanted to switch it to amd64 (while preserving the rest of the configuration). It was already set up so I could build world & kernel; I did that again, but issued "setenv TARGET_ARCH amd64" first. Once that completed, I mounted partitions 1 & 4 (a & d) from the "other slice" to a suitable mountpoint (e.g., /mnt), then: make installkernel DESTDIR=3D/mnt mergemaster -U -u 0022 -p -D /mnt rm -fr /mnt/usr/include.old mv -f /mnt/usr/include /mnt/usr/include.old rm -fr /mnt/usr/share/man make installworld DESTDIR=3D/mnt mergemaster -F -U -u 0022 -i -D /mnt make delete-old DESTDIR=3D/mnt I then rebooted from the "other slice"... and it came up running: FreeBSD 10.1-STABLE #127 r274634M/274637:1001502: Tue Nov 18 12:57:35 PST 2014 amd64 (I then used the procedure at the end of the portmaster man page to rebuild all ports, rebooted, and "cd /usr/src && make delete-old-libs".) That was back on 18 Nov, and the machine's been running without issues since. (I've been doing native source updates on it on Sundays recently, so it's now running FreeBSD 10.1-STABLE #129 r277317M/277317:1001506: Sun Jan 18 04:47:44 PST 2015 amd64.) Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --991t1H9DIskWxVIu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUv8JxXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7qEMP/13gMs/1NEr5kRVuXA/VQegD FNEFRGkhTzmDLU8qKNl726gwmu9a03KaHmcBJ1xZZpc6n+1rVbhjXTzy5jzYBFRh oIr2I94ylGKIHLL3y1ncaZy5PTOLrYc4Sk0uWVXnHLU/AM74nLc4oAh75suNKZaC g44a8CFlF6V1nLqz09vz41HxCjNKuFh1aweY008W7RUz8Hiw6OI87k91MpONhaLg /lGpuo5YZcGruvrE+z3CgxYgSCcmOrT0P5ccXxp+A4Ainczu2BE/nI1GqIcMo4bm fB5Ia4KQDYeS7Y4Y5QVrZ5QF4z8aMHgxw/e1NHwfjyx1pSfaq8DiAPWvrE7leJnt TCp41fPs5CloMzlSgxS4bXSEBgZBbX2BgVz08vmtXYgZGEuYdGf5so9F+cUozadw xEF0GsU7owSg+83YSzAarcdag+9+gF2u40r8GXS0RKoI+AzPzdH/Y98fW4YUzpdk 3du7Tu3zehxDK0v3ZSowRrdsIAKifmPbQ3ufeWsij9JnZXYa9rAwNmFlatDW1LYH QQCEc4+62DyiRy4yMBsh6vtfH2DkbFUDYu4XIaBwgTEdjf1fGbPEo5f72XXucpP/ OCy+qjBBiWQOZ3o3UFaL7UiW/cz/Nj/18DkB9a8zlRApTRzDERVi1HuyOJTDkc5Z QiOLRakINVZkNgyjEtV8 =HLtE -----END PGP SIGNATURE----- --991t1H9DIskWxVIu-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 01:50:16 2015 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 BC7B9F3E for ; Thu, 22 Jan 2015 01:50:16 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0099.outbound.protection.outlook.com [157.56.111.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 591CEF37 for ; Thu, 22 Jan 2015 01:50:15 +0000 (UTC) Received: from DM2PR0801MB652.namprd08.prod.outlook.com (10.242.127.155) by DM2PR0801MB652.namprd08.prod.outlook.com (10.242.127.155) with Microsoft SMTP Server (TLS) id 15.1.59.20; Thu, 22 Jan 2015 01:34:07 +0000 Received: from DM2PR0801MB652.namprd08.prod.outlook.com ([10.242.127.155]) by DM2PR0801MB652.namprd08.prod.outlook.com ([10.242.127.155]) with mapi id 15.01.0059.007; Thu, 22 Jan 2015 01:34:07 +0000 From: "Sinha, Prokash" To: "freebsd-hackers@freebsd.org" Subject: FW: elf linking problem Thread-Topic: elf linking problem Thread-Index: AQHQMTzB7oEYrYSqIUWAPLQ9gqdZQ5zCZqYAgAApdACACE5UgA== Date: Thu, 22 Jan 2015 01:34:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.92.229.68] authentication-results: spf=none (sender IP is ) smtp.mailfrom=psinha@panasas.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DM2PR0801MB652; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB652; x-forefront-prvs: 0464DBBBC4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(479174004)(377454003)(199003)(164054003)(51704005)(189002)(92566002)(106356001)(50986999)(107886001)(86362001)(2351001)(106116001)(54356999)(76176999)(36756003)(77156002)(122556002)(40100003)(450100001)(15975445007)(102836002)(68736005)(77096005)(1720100001)(2950100001)(2900100001)(2656002)(110136001)(66066001)(64706001)(97736003)(46102003)(101416001)(87936001)(19580395003)(105586002)(99286002)(19580405001)(94096001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB652; H:DM2PR0801MB652.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: panasas.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <36B8C2E957750A4886127D445C00D39D@namprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2015 01:34:06.3849 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0801MB652 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, 22 Jan 2015 01:50:16 -0000 I'm forwarding to the kernel group, in case someone can point me to the root of this problem. Would appreciate any insight ! Thanks, -prokash kldload: R_X86_64_PC32 retype switch <--- This is the first failure ( from dmesg ) ink_elf_obj: symbol pan_sys_once undefinedELF_RELOC_RELA ink_elf_load_file(...) -external relocation error=3D2 linker_load_file: trying to load /boot/kernel/panfs.ko linker_load_file: error !=3D ENOENT file=3D/boot/kernel/panfs.ko linker_load_file: Unsupported file type +++++ The code section - case R_X86_64_PC32: /* S + A - P */ addr =3D lookup(lf, symidx, 1); where32 =3D (Elf32_Addr *)where; val32 =3D (Elf32_Addr)(addr + addend - (Elf_Addr)where); if (addr =3D=3D 0){ printf("kldload: R_X86_64_PC32 rtype switch\n"); <--------- Lookup failure. return -1; } if (*where32 !=3D val32) *where32 =3D val32; break; On 1/16/15 10:43 AM, "Sinha, Prokash" wrote: >So what I'm looking for is that if some sums are defined in the kernel >namespace by some kernel component, it should be visible by other kernel >module at load time fix/resolve those references, which is what the gcc on >freebsd 7.2 seem to be doing. For freebsd 10.1 using the clang front, this >could be broken. > >Can anyone point me to some document along the line of freebsd ko >linking/loading. > >I used objdump, but I'm particularly looking for some internals related >document, so that I can see the linker actually trying to pull in and >fix/resolve ref from the kernel name space. > >Thanks, >-prokash > >On 1/16/15 8:15 AM, "Sinha, Prokash" wrote: > >>Has anyone seen this , when clang is being used for 10.1 compilation ? >> >>Thanks, >>-prokash >> >> >>On 1/15/15 7:30 PM, "Sinha, Prokash" wrote: >> >>>Hello, >>> >>>I'm trying to find out what could be the cause of a kldload problem I'm >>>facing. Here is the context detail -- >>> >>> >>>1. I'm building two ko module. And it has a dependency order, so when I >>>load the first module, it loads, and a function symbol ( F ) is defined >>>into kernel variable space sysctl -b kern.function_list | tr '\0' '\n' | >>>grep symname. >>>2. Now trying to load the 2nd module, and link_elf_obj flags error and >>>symbol undefined when freebsd10.1 is being used. >>>3. If I probe using the same sysctl as in step 1, I still the symbol is >>>defined. >>> >>>/var/log/messages shows - >>>kernel: link_elf_obj: symbol pan_sys_once undefined >>>kernel: linker_load_file: Unsupported file type >>> >>>The same two modules when complied using freebsd7.2, we don't see the >>>problem. >>> >>> >>>The question is - Is there changes along the elf formats ( in both case >>>it >>>64bit), also is there any changes >>>In the API between those two OS version, that I need to aware of ( and >>>possible flags I need to set). >>> >>>Using objdump -t modone.ko >>>00000000000fb940 g F .text 0000000000000062 pan_sys_once >>> >>> >>> >>>In modtwo.ko it is undefined >>>0000000000000000 *UND* 0000000000000000 pan_sys_once >>> >>> >>>Note the objdump on freebsd 7.2, is identical. So it is defined in the >>>module1 as F(function), and undefined(UND) in module two. >>> >>>Any suggestion, please ? >>> >>>Thanks, >>>-prokash >>> >>> >>>_______________________________________________ >>>freebsd-toolchain@freebsd.org mailing list >>>http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain >>>To unsubscribe, send any mail to >>>"freebsd-toolchain-unsubscribe@freebsd.org" >> > From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 02:04:54 2015 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 2AAC42AB for ; Thu, 22 Jan 2015 02:04:54 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB864146 for ; Thu, 22 Jan 2015 02:04:53 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id u14so6001552lbd.2 for ; Wed, 21 Jan 2015 18:04:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6nyP3bPDElnUuE1szYTN+ZuREG43pdbaMH9yoApF+Ok=; b=wJnnsxmq3pE1BRHM5xUgX7cdjEf+Ht5yamEHiJAQeTudNg/ucmQtqYhNF4NprGEONG iuK5KTC5biYC/rt6sZLftc1C5LGTM3ClJ4TagFe1gmT3HiFA/hN5LB5ISqkqXa7Gf8p7 D1vlfh635WOgKk1RG93JFpkEnX71rOkUcShbkI+fALzsT6EStMcVN/G3dt3S+vJAkVGT hry7/Sts1LlgKbdhA8hEgG0lNwRxd5VNCHrx5dnjf4kQfHtvEtbzGxSDwCAqpTbkteIH x+/z89JEb07YTjfK3K9ezzahZ1yhXsLJyZjkhaYkbPAwWe7PWnXIKrrhj7LiDOdxCHVk 0kGw== MIME-Version: 1.0 X-Received: by 10.112.160.33 with SMTP id xh1mr47869289lbb.60.1421892291591; Wed, 21 Jan 2015 18:04:51 -0800 (PST) Received: by 10.114.78.131 with HTTP; Wed, 21 Jan 2015 18:04:51 -0800 (PST) In-Reply-To: <20150120083212.GC42409@kib.kiev.ua> References: <20150120083212.GC42409@kib.kiev.ua> Date: Wed, 21 Jan 2015 21:04:51 -0500 Message-ID: Subject: Re: Sleeping thread held mutex in vm_pageout_oom() From: Ryan Stone To: Konstantin Belousov 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: Thu, 22 Jan 2015 02:04:54 -0000 Thanks for the patch. I tried it out this afternoon and got the following panic: panic: PHOLD of exiting process^M^M cpuid = 9^M^M curthread = pagedaemon/pagedaemon (8/100154)^M^M cpu_ticks = 979566002403^M^M KDB: stack backtrace:^M^M db_trace_self_wrapper() at 0xffffffff801e672a = db_trace_self_wrapper+0x2a^M^M panic() at 0xffffffff80480818 = panic+0x228^M^M vm_pageout_oom() at 0xffffffff80669a9b = vm_pageout_oom+0x58b^M^M vm_pageout() at 0xffffffff8066aa35 = vm_pageout+0x975^M^M fork_exit() at 0xffffffff80454ada = fork_exit+0x12a^M^M fork_trampoline() at 0xffffffff8067b37e = fork_trampoline+0xe^M^M I believe that we need to check for P_WEXIT before considering p as a candidate to be killed: diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c index ca9d7f9..64d4277 100644 --- a/sys/vm/vm_pageout.c +++ b/sys/vm/vm_pageout.c @@ -1516,13 +1516,13 @@ vm_pageout_oom(int shortage) FOREACH_PROC_IN_SYSTEM(p) { int breakout; - if (PROC_TRYLOCK(p) == 0) - continue; + PROC_LOCK(p); /* * If this is a system, protected or killed process, skip it. */ if (p->p_state != PRS_NORMAL || - (p->p_flag & (P_INEXEC | P_PROTECTED | P_SYSTEM)) || + (p->p_flag & + (P_INEXEC | P_PROTECTED | P_SYSTEM | P_WEXIT)) || (p->p_pid == 1) || P_KILLED(p) || ((p->p_pid < 48) && (swap_pager_avail != 0))) { PROC_UNLOCK(p); @@ -1557,11 +1557,14 @@ vm_pageout_oom(int shortage) PROC_UNLOCK(p); continue; } + _PHOLD(p); if (!vm_map_trylock_read(&vm->vm_map)) { - vmspace_free(vm); + _PRELE(p); PROC_UNLOCK(p); + vmspace_free(vm); continue; } + PROC_UNLOCK(p); size = vmspace_swap_count(vm); vm_map_unlock_read(&vm->vm_map); if (shortage == VM_OOM_MEM) @@ -1573,16 +1576,18 @@ vm_pageout_oom(int shortage) */ if (size > bigsize) { if (bigproc != NULL) - PROC_UNLOCK(bigproc); + PRELE(bigproc); bigproc = p; bigsize = size; } else - PROC_UNLOCK(p); + PRELE(p); } sx_sunlock(&allproc_lock); if (bigproc != NULL) { + PROC_LOCK(bigproc); killproc(bigproc, "out of swap space"); sched_nice(bigproc, PRIO_MIN); + _PRELE(bigproc); PROC_UNLOCK(bigproc); wakeup(&vm_cnt.v_free_count); } From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 08:35:20 2015 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 67A624DE for ; Thu, 22 Jan 2015 08:35:20 +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 08937D56 for ; Thu, 22 Jan 2015 08:35:19 +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 t0M8ZEwO061957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2015 10:35:14 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t0M8ZEwO061957 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t0M8ZEub061956; Thu, 22 Jan 2015 10:35:14 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 22 Jan 2015 10:35:14 +0200 From: Konstantin Belousov To: Ryan Stone Subject: Re: Sleeping thread held mutex in vm_pageout_oom() Message-ID: <20150122083514.GU42409@kib.kiev.ua> References: <20150120083212.GC42409@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Thu, 22 Jan 2015 08:35:20 -0000 On Wed, Jan 21, 2015 at 09:04:51PM -0500, Ryan Stone wrote: > Thanks for the patch. I tried it out this afternoon and got the > following panic: > > panic: PHOLD of exiting process^M^M > cpuid = 9^M^M > curthread = pagedaemon/pagedaemon (8/100154)^M^M > cpu_ticks = 979566002403^M^M > KDB: stack backtrace:^M^M > db_trace_self_wrapper() at 0xffffffff801e672a = db_trace_self_wrapper+0x2a^M^M > panic() at 0xffffffff80480818 = panic+0x228^M^M > vm_pageout_oom() at 0xffffffff80669a9b = vm_pageout_oom+0x58b^M^M > vm_pageout() at 0xffffffff8066aa35 = vm_pageout+0x975^M^M > fork_exit() at 0xffffffff80454ada = fork_exit+0x12a^M^M > fork_trampoline() at 0xffffffff8067b37e = fork_trampoline+0xe^M^M > > > I believe that we need to check for P_WEXIT before considering p as a > candidate to be killed: Sure, you are right. I also took opportunity to reformat the condition and to remove excessive () there. diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c index ca9d7f9..d2e0483 100644 --- a/sys/vm/vm_pageout.c +++ b/sys/vm/vm_pageout.c @@ -1516,15 +1542,15 @@ vm_pageout_oom(int shortage) FOREACH_PROC_IN_SYSTEM(p) { int breakout; - if (PROC_TRYLOCK(p) == 0) - continue; + PROC_LOCK(p); + /* * If this is a system, protected or killed process, skip it. */ - if (p->p_state != PRS_NORMAL || - (p->p_flag & (P_INEXEC | P_PROTECTED | P_SYSTEM)) || - (p->p_pid == 1) || P_KILLED(p) || - ((p->p_pid < 48) && (swap_pager_avail != 0))) { + if (p->p_state != PRS_NORMAL || (p->p_flag & (P_INEXEC | + P_PROTECTED | P_SYSTEM | P_WEXIT)) != 0 || + p->p_pid == 1 || P_KILLED(p) || + (p->p_pid < 48 && swap_pager_avail != 0)) { PROC_UNLOCK(p); continue; } @@ -1557,11 +1583,14 @@ vm_pageout_oom(int shortage) PROC_UNLOCK(p); continue; } + _PHOLD(p); if (!vm_map_trylock_read(&vm->vm_map)) { - vmspace_free(vm); + _PRELE(p); PROC_UNLOCK(p); + vmspace_free(vm); continue; } + PROC_UNLOCK(p); size = vmspace_swap_count(vm); vm_map_unlock_read(&vm->vm_map); if (shortage == VM_OOM_MEM) @@ -1573,16 +1602,19 @@ vm_pageout_oom(int shortage) */ if (size > bigsize) { if (bigproc != NULL) - PROC_UNLOCK(bigproc); + PRELE(bigproc); bigproc = p; bigsize = size; - } else - PROC_UNLOCK(p); + } else { + PRELE(p); + } } sx_sunlock(&allproc_lock); if (bigproc != NULL) { + PROC_LOCK(bigproc); killproc(bigproc, "out of swap space"); sched_nice(bigproc, PRIO_MIN); + _PRELE(bigproc); PROC_UNLOCK(bigproc); wakeup(&vm_cnt.v_free_count); } From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 10:38:35 2015 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 CC1AF23A for ; Thu, 22 Jan 2015 10:38:35 +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 54485CFC for ; Thu, 22 Jan 2015 10:38:35 +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 t0MAcTSC097331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2015 12:38:29 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t0MAcTSC097331 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t0MAcTxD097328; Thu, 22 Jan 2015 12:38:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 22 Jan 2015 12:38:29 +0200 From: Konstantin Belousov To: "Sinha, Prokash" Subject: Re: FW: elf linking problem Message-ID: <20150122103829.GA42409@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Thu, 22 Jan 2015 10:38:35 -0000 On Thu, Jan 22, 2015 at 01:34:06AM +0000, Sinha, Prokash wrote: > I'm forwarding to the kernel group, in case someone can point me to the > root of this problem. > > Would appreciate any insight ! > > Thanks, > -prokash > > kldload: R_X86_64_PC32 retype switch <--- This is the first failure ( > from dmesg ) > ink_elf_obj: symbol pan_sys_once undefinedELF_RELOC_RELA > ink_elf_load_file(...) -external relocation error=2 > linker_load_file: trying to load /boot/kernel/panfs.ko > linker_load_file: error != ENOENT file=/boot/kernel/panfs.ko > linker_load_file: Unsupported file type > > +++++ The code section - > > case R_X86_64_PC32: /* S + A - P */ > addr = lookup(lf, symidx, 1); > where32 = (Elf32_Addr *)where; > val32 = (Elf32_Addr)(addr + addend - > (Elf_Addr)where); > if (addr == 0){ > printf("kldload: R_X86_64_PC32 rtype > switch\n"); <--------- Lookup failure. > return -1; > } > if (*where32 != val32) > *where32 = val32; > break; > > > > > On 1/16/15 10:43 AM, "Sinha, Prokash" wrote: > > >So what I'm looking for is that if some sums are defined in the kernel > >namespace by some kernel component, it should be visible by other kernel > >module at load time fix/resolve those references, which is what the gcc on > >freebsd 7.2 seem to be doing. For freebsd 10.1 using the clang front, this > >could be broken. > > > >Can anyone point me to some document along the line of freebsd ko > >linking/loading. > > > >I used objdump, but I'm particularly looking for some internals related > >document, so that I can see the linker actually trying to pull in and > >fix/resolve ref from the kernel name space. > > > >Thanks, > >-prokash > > > >On 1/16/15 8:15 AM, "Sinha, Prokash" wrote: > > > >>Has anyone seen this , when clang is being used for 10.1 compilation ? > >> > >>Thanks, > >>-prokash > >> > >> > >>On 1/15/15 7:30 PM, "Sinha, Prokash" wrote: > >> > >>>Hello, > >>> > >>>I'm trying to find out what could be the cause of a kldload problem I'm > >>>facing. Here is the context detail -- > >>> > >>> > >>>1. I'm building two ko module. And it has a dependency order, so when I > >>>load the first module, it loads, and a function symbol ( F ) is defined > >>>into kernel variable space sysctl -b kern.function_list | tr '\0' '\n' | > >>>grep symname. > >>>2. Now trying to load the 2nd module, and link_elf_obj flags error and > >>>symbol undefined when freebsd10.1 is being used. > >>>3. If I probe using the same sysctl as in step 1, I still the symbol is > >>>defined. > >>> > >>>/var/log/messages shows - > >>>kernel: link_elf_obj: symbol pan_sys_once undefined > >>>kernel: linker_load_file: Unsupported file type > >>> > >>>The same two modules when complied using freebsd7.2, we don't see the > >>>problem. > >>> > >>> > >>>The question is - Is there changes along the elf formats ( in both case > >>>it > >>>64bit), also is there any changes > >>>In the API between those two OS version, that I need to aware of ( and > >>>possible flags I need to set). > >>> > >>>Using objdump -t modone.ko > >>>00000000000fb940 g F .text 0000000000000062 pan_sys_once > >>> > >>> > >>> > >>>In modtwo.ko it is undefined > >>>0000000000000000 *UND* 0000000000000000 pan_sys_once > >>> > >>> > >>>Note the objdump on freebsd 7.2, is identical. So it is defined in the > >>>module1 as F(function), and undefined(UND) in module two. > >>> > >>>Any suggestion, please ? This is unrelated to either compiler version, or ELF format. If module B depends on the symbol from a module A, the dependency must be declared with the MODULE_DEPEND() macro. Look for examples in the tree to see how to use it. Main kernel symbols are always visible to the loadable modules. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 14:49:06 2015 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 994DC234 for ; Thu, 22 Jan 2015 14:49:06 +0000 (UTC) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 505E8DF7 for ; Thu, 22 Jan 2015 14:49:06 +0000 (UTC) Received: by mail-qc0-f181.google.com with SMTP id l6so1494050qcy.12 for ; Thu, 22 Jan 2015 06:49:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=fd4oRV01iULsMUy1tNY7F+GOv+E6LlHgzByuCz+/ep4=; b=Ye0iBVIe779TufZK3ecPCnVIm8SkTA8UBa+JcWANcgP9+gzC8tBhKxCqXRuSdJVOSC 5MjbZrQGNDNkm3IsEdWOOoNa2YIBD9SjBhZJhYbPYksWYIudSZWv4UicihP+O10lC9QT QE2bfwjWN9iyoenOudDrOU2txu8acK32Q3buU+AxN3by+gqPh/BuTB1FPM14EkD6yjT1 AnUeZ/mslApwIrrGvYJWhIRxEwWmkGOdSpc8Cxgb19C73iA+F1EE8xxRTn0bBtAAiTEN sPbgGTmldPX6wEuMYzPrIBBWXtO2NiL+J8F6BcNo6DdhM6rz+7RcJHWX1InSB3JIDhfT IzuQ== X-Received: by 10.140.100.234 with SMTP id s97mr3065791qge.96.1421938145283; Thu, 22 Jan 2015 06:49:05 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.140.39.209 with HTTP; Thu, 22 Jan 2015 06:48:45 -0800 (PST) In-Reply-To: <20150122103829.GA42409@kib.kiev.ua> References: <20150122103829.GA42409@kib.kiev.ua> From: Ed Maste Date: Thu, 22 Jan 2015 09:48:45 -0500 X-Google-Sender-Auth: N9F-A9sboZ-PlUdUGQchrk-cuXA Message-ID: Subject: Re: FW: elf linking problem To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , "Sinha, Prokash" 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, 22 Jan 2015 14:49:06 -0000 On 22 January 2015 at 05:38, Konstantin Belousov wrote: > > If module B depends on the symbol from a module A, the dependency > must be declared with the MODULE_DEPEND() macro. Look for examples > in the tree to see how to use it. There's also a MODULE_DEPEND(9) man page with some information, although it is rather terse. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 17:52:11 2015 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 27D72F51 for ; Thu, 22 Jan 2015 17:52:11 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0057.outbound.protection.outlook.com [157.56.110.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F2FBBF6 for ; Thu, 22 Jan 2015 17:52:09 +0000 (UTC) Received: from DM2PR0801MB650.namprd08.prod.outlook.com (10.242.127.153) by DM2PR0801MB618.namprd08.prod.outlook.com (10.242.127.146) with Microsoft SMTP Server (TLS) id 15.1.59.20; Thu, 22 Jan 2015 16:18:58 +0000 Received: from DM2PR0801MB652.namprd08.prod.outlook.com (10.242.127.155) by DM2PR0801MB650.namprd08.prod.outlook.com (10.242.127.153) with Microsoft SMTP Server (TLS) id 15.1.59.20; Thu, 22 Jan 2015 16:18:57 +0000 Received: from DM2PR0801MB652.namprd08.prod.outlook.com ([10.242.127.155]) by DM2PR0801MB652.namprd08.prod.outlook.com ([10.242.127.155]) with mapi id 15.01.0059.007; Thu, 22 Jan 2015 16:18:56 +0000 From: "Sinha, Prokash" To: Konstantin Belousov Subject: Re: elf linking problem Thread-Topic: elf linking problem Thread-Index: AQHQNl8e7oEYrYSqIUWAPLQ9gqdZQw== Date: Thu, 22 Jan 2015 16:18:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.80.217.3] authentication-results: spf=none (sender IP is ) smtp.mailfrom=psinha@panasas.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005004); SRVR:DM2PR0801MB650; UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB650; x-forefront-prvs: 0464DBBBC4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(479174004)(164054003)(189002)(51704005)(377454003)(24454002)(199003)(77096005)(101416001)(64706001)(54356999)(122556002)(99286002)(36756003)(2656002)(46102003)(68736005)(87936001)(50986999)(62966003)(77156002)(40100003)(106116001)(105586002)(92566002)(2900100001)(102836002)(66066001)(97736003)(110136001)(19580395003)(19580405001)(1411001)(106356001)(86362001)(94096001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB650; H:DM2PR0801MB652.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: panasas.com does not designate permitted sender hosts) Content-Type: text/plain; charset="Windows-1252" Content-ID: <68C946CBEAE1974A8105C29265879948@namprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2015 16:18:56.2515 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0801MB650 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB618; X-OriginatorOrg: panasas.com 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, 22 Jan 2015 17:52:11 -0000 I looked at the MODULE_DEPEND, and it is a hint to the kernel, sort of load ordering ( in other OS terminology). Here I'm using kldload first to A module, which loads fine, there is a kernel variable that is defined in the Kernel space, that I can verify with - sysctl -b kern.function_list | tr '\0' '\n' | Now when I do the kldload of the dependent module B, I see these=8A By the way, the module loads works fine on freebsd7.2, I tested them. So I was thinking if new compiler/ld could have something to do with it ? -prokash On 1/22/15 2:38 AM, "Konstantin Belousov" wrote: >On Thu, Jan 22, 2015 at 01:34:06AM +0000, Sinha, Prokash wrote: >> I'm forwarding to the kernel group, in case someone can point me to the >> root of this problem. >>=20 >> Would appreciate any insight ! >>=20 >> Thanks, >> -prokash >>=20 >> kldload: R_X86_64_PC32 retype switch <--- This is the first failure ( >> from dmesg ) >> ink_elf_obj: symbol pan_sys_once undefinedELF_RELOC_RELA >> ink_elf_load_file(...) -external relocation error=3D2 >> linker_load_file: trying to load /boot/kernel/panfs.ko >> linker_load_file: error !=3D ENOENT file=3D/boot/kernel/panfs.ko >> linker_load_file: Unsupported file type >>=20 >> +++++ The code section - >>=20 >> case R_X86_64_PC32: /* S + A - P */ >> addr =3D lookup(lf, symidx, 1); >> where32 =3D (Elf32_Addr *)where; >> val32 =3D (Elf32_Addr)(addr + addend - >> (Elf_Addr)where); >> if (addr =3D=3D 0){ >> printf("kldload: R_X86_64_PC32 rtype >> switch\n"); <--------- Lookup failure. >> return -1; >> } >> if (*where32 !=3D val32) >> *where32 =3D val32; >> break; >>=20 >>=20 >>=20 >>=20 >> On 1/16/15 10:43 AM, "Sinha, Prokash" wrote: >>=20 >> >So what I'm looking for is that if some sums are defined in the kernel >> >namespace by some kernel component, it should be visible by other >>kernel >> >module at load time fix/resolve those references, which is what the >>gcc on >> >freebsd 7.2 seem to be doing. For freebsd 10.1 using the clang front, >>this >> >could be broken. >> > >> >Can anyone point me to some document along the line of freebsd ko >> >linking/loading. >> > >> >I used objdump, but I'm particularly looking for some internals related >> >document, so that I can see the linker actually trying to pull in and >> >fix/resolve ref from the kernel name space. >> > >> >Thanks, >> >-prokash >> > >> >On 1/16/15 8:15 AM, "Sinha, Prokash" wrote: >> > >> >>Has anyone seen this , when clang is being used for 10.1 compilation ? >> >> >> >>Thanks, >> >>-prokash >> >> >> >> >> >>On 1/15/15 7:30 PM, "Sinha, Prokash" wrote: >> >> >> >>>Hello, >> >>> >> >>>I'm trying to find out what could be the cause of a kldload problem >>I'm >> >>>facing. Here is the context detail -- >> >>> >> >>> >> >>>1. I'm building two ko module. And it has a dependency order, so >>when I >> >>>load the first module, it loads, and a function symbol ( F ) is >>defined >> >>>into kernel variable space sysctl -b kern.function_list | tr '\0' >>'\n' | >> >>>grep symname. >> >>>2. Now trying to load the 2nd module, and link_elf_obj flags error >>and >> >>>symbol undefined when freebsd10.1 is being used. >> >>>3. If I probe using the same sysctl as in step 1, I still the symbol >>is >> >>>defined. >> >>> >> >>>/var/log/messages shows - >> >>>kernel: link_elf_obj: symbol pan_sys_once undefined >> >>>kernel: linker_load_file: Unsupported file type >> >>> >> >>>The same two modules when complied using freebsd7.2, we don't see the >> >>>problem. >> >>> >> >>> >> >>>The question is - Is there changes along the elf formats ( in both >>case >> >>>it >> >>>64bit), also is there any changes >> >>>In the API between those two OS version, that I need to aware of ( >>and >> >>>possible flags I need to set). >> >>> >> >>>Using objdump -t modone.ko >> >>>00000000000fb940 g F .text 0000000000000062 pan_sys_once >> >>> >> >>> >> >>> >> >>>In modtwo.ko it is undefined >> >>>0000000000000000 *UND* 0000000000000000 pan_sys_once >> >>> >> >>> >> >>>Note the objdump on freebsd 7.2, is identical. So it is defined in >>the >> >>>module1 as F(function), and undefined(UND) in module two. >> >>> >> >>>Any suggestion, please ? > >This is unrelated to either compiler version, or ELF format. > >If module B depends on the symbol from a module A, the dependency >must be declared with the MODULE_DEPEND() macro. Look for examples >in the tree to see how to use it. > >Main kernel symbols are always visible to the loadable modules. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 19:05:42 2015 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 5759848A for ; Thu, 22 Jan 2015 19:05:42 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0072.outbound.protection.outlook.com [157.56.110.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB257694 for ; Thu, 22 Jan 2015 19:05:40 +0000 (UTC) Received: from DM2PR0801MB650.namprd08.prod.outlook.com (10.242.127.153) by DM2PR0801MB667.namprd08.prod.outlook.com (10.242.173.25) with Microsoft SMTP Server (TLS) id 15.1.59.20; Thu, 22 Jan 2015 19:05:33 +0000 Received: from DM2PR0801MB652.namprd08.prod.outlook.com (10.242.127.155) by DM2PR0801MB650.namprd08.prod.outlook.com (10.242.127.153) with Microsoft SMTP Server (TLS) id 15.1.59.20; Thu, 22 Jan 2015 19:05:30 +0000 Received: from DM2PR0801MB652.namprd08.prod.outlook.com ([10.242.127.155]) by DM2PR0801MB652.namprd08.prod.outlook.com ([10.242.127.155]) with mapi id 15.01.0059.007; Thu, 22 Jan 2015 19:05:30 +0000 From: "Sinha, Prokash" To: "Sinha, Prokash" , Konstantin Belousov Subject: Re: elf linking problem Thread-Topic: elf linking problem Thread-Index: AQHQNl8e7oEYrYSqIUWAPLQ9gqdZQ5zL+eoA Date: Thu, 22 Jan 2015 19:05:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.80.217.3] authentication-results: panasas.com; dkim=none (message not signed) header.d=none;panasas.com; dmarc=none action=none header.from=panasas.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005004); SRVR:DM2PR0801MB650; UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB650; x-forefront-prvs: 0464DBBBC4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(51704005)(52034003)(377454003)(24454002)(164054003)(479174004)(66066001)(102836002)(16601075003)(92566002)(2950100001)(2900100001)(19580405001)(1720100001)(19580395003)(86362001)(15975445007)(46102003)(77096005)(36756003)(2656002)(99286002)(54356999)(122556002)(76176999)(106116001)(50986999)(77156002)(62966003)(87936001)(40100003)(94096001)(2004002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB650; H:DM2PR0801MB652.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2015 19:05:29.8448 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0801MB650 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB667; X-OriginatorOrg: panasas.com 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, 22 Jan 2015 19:05:42 -0000 Thanks Konstantin, Yes it looks like MODULE_DEPEND(...) is a must include ... Here is a quick hack to test the idea . -prokash ++++ ++++ hello_fsm.c #include #include #include #include void mysymexternfunc( void ); void mysymexternfunc( void ) { uprintf("mysymexternfunc( ) in hello_fsm.c\n"); } /* The function called at load/unload. */ static int event_handler(struct module *module, int event, void *arg) { int e =3D 0; /* Error, 0 for normal return status */ switch (event) { case MOD_LOAD: uprintf("Hello Free Software Magazine Readers! \n"); break; case MOD_UNLOAD: uprintf("Bye Bye FSM reader, be sure to check http://freesoftwaremagazine.com !\n"); break; default: e =3D EOPNOTSUPP; /* Error, Operation Not Supported */ break; } return(e); } /* The second argument of DECLARE_MODULE. */ static moduledata_t hello_conf =3D { "hello_fsm", /* module name */ event_handler, /* event handler */ NULL /* extra data */ }; DECLARE_MODULE(hello_fsm, hello_conf, SI_SUB_DRIVERS, SI_ORDER_MIDDLE); MODULE_VERSION(hello_fsm, 1); +++++ end of hello_fsm.c ( this is the only src file is hello_fsm.ko ) OK now check if the hello_fsm.ko got loaded, also check if the function is defined in the kern.function_list name space root@mau-elcano-2:~/psinha/kernel # kldstat Id Refs Address Size Name 1 13 0xffffffff80200000 1755658 kernel 2 1 0xffffffff81a11000 357f ums.ko 3 1 0xffffffff81a15000 43bce linux.ko 4 1 0xffffffff81a59000 755d autofs.ko 5 1 0xffffffff81a61000 1ce hello_fsm.ko <--- so far so good oot@mau-elcano-2:~/psinha/kernel2 # !342 sysctl -b kern.function_list | tr '\0' '\n' | grep mysymexternfunc mysymexternfunc <--- okay we found the sum +++++ Start of hello_fsm2.c ( only file for hello_fsm2.ko ) #include #include #include #include extern void mysymexternfunc( void ); <-------- importing a function defined and in the kern.function_list /* The function called at load/unload. */ static int event_handler(struct module *module, int event, void *arg) { int e =3D 0; /* Error, 0 for normal return status */ switch (event) { case MOD_LOAD: mysymexternfunc(); uprintf("Hello Free Software Magazine Readers! \n"); break; case MOD_UNLOAD: mysymexternfunc(); uprintf("Bye Bye FSM reader, be sure to check http://freesoftwaremagazine.com !\n"); break; default: e =3D EOPNOTSUPP; /* Error, Operation Not Supported */ break; } return(e); } /* The second argument of DECLARE_MODULE. */ static moduledata_t hello_conf2=3D { "hello_fsm2", /* module name */ event_handler, /* event handler */ NULL /* extra data */ }; DECLARE_MODULE(hello_fsm2, hello_conf2, SI_SUB_DRIVERS, SI_ORDER_MIDDLE); MODULE_DEPEND(hello_fsm2, hello_fsm, 1,1,1); <----- This is to hint the kernel ( not really needed for manual load !!! ) ++++ Try to load module two. rroot@mau-elcano-2:~/psinha/kernel2 # kldload ./hello_fsm2.ko mysymexternfunc( ) in hello_fsm.c <---- found the kernel symbol Hello Free Software Magazine Readers! root@mau-elcano-2:~/psinha/kernel2 # kldstat Id Refs Address Size Name 1 15 0xffffffff80200000 1755658 kernel 2 1 0xffffffff81a11000 357f ums.ko 3 1 0xffffffff81a15000 43bce linux.ko 4 1 0xffffffff81a59000 755d autofs.ko 6 2 0xffffffff81a61000 1f6 hello_fsm.ko 7 1 0xffffffff81a62000 1d6 hello_fsm2.ko <---- loaded On 1/22/15 8:18 AM, "Sinha, Prokash" wrote: >I looked at the MODULE_DEPEND, and it is a hint to the kernel, sort of >load ordering ( in other OS terminology). > >Here I'm using kldload first to A module, which loads fine, there is a >kernel variable that is defined in the >Kernel space, that I can verify with - >sysctl -b kern.function_list | tr '\0' '\n' | > > >Now when I do the kldload of the dependent module B, I see these=A9 > >By the way, the module loads works fine on freebsd7.2, I tested them. > >So I was thinking if new compiler/ld could have something to do with it ? > > >-prokash > >On 1/22/15 2:38 AM, "Konstantin Belousov" wrote: > >>On Thu, Jan 22, 2015 at 01:34:06AM +0000, Sinha, Prokash wrote: >>> I'm forwarding to the kernel group, in case someone can point me to the >>> root of this problem. >>>=20 >>> Would appreciate any insight ! >>>=20 >>> Thanks, >>> -prokash >>>=20 >>> kldload: R_X86_64_PC32 retype switch <--- This is the first failure ( >>> from dmesg ) >>> ink_elf_obj: symbol pan_sys_once undefinedELF_RELOC_RELA >>> ink_elf_load_file(...) -external relocation error=3D2 >>> linker_load_file: trying to load /boot/kernel/panfs.ko >>> linker_load_file: error !=3D ENOENT file=3D/boot/kernel/panfs.ko >>> linker_load_file: Unsupported file type >>>=20 >>> +++++ The code section - >>>=20 >>> case R_X86_64_PC32: /* S + A - P */ >>> addr =3D lookup(lf, symidx, 1); >>> where32 =3D (Elf32_Addr *)where; >>> val32 =3D (Elf32_Addr)(addr + addend - >>> (Elf_Addr)where); >>> if (addr =3D=3D 0){ >>> printf("kldload: R_X86_64_PC32 rtype >>> switch\n"); <--------- Lookup failure. >>> return -1; >>> } >>> if (*where32 !=3D val32) >>> *where32 =3D val32; >>> break; >>>=20 >>>=20 >>>=20 >>>=20 >>> On 1/16/15 10:43 AM, "Sinha, Prokash" wrote: >>>=20 >>> >So what I'm looking for is that if some sums are defined in the kernel >>> >namespace by some kernel component, it should be visible by other >>>kernel >>> >module at load time fix/resolve those references, which is what the >>>gcc on >>> >freebsd 7.2 seem to be doing. For freebsd 10.1 using the clang front, >>>this >>> >could be broken. >>> > >>> >Can anyone point me to some document along the line of freebsd ko >>> >linking/loading. >>> > >>> >I used objdump, but I'm particularly looking for some internals >>>related >>> >document, so that I can see the linker actually trying to pull in and >>> >fix/resolve ref from the kernel name space. >>> > >>> >Thanks, >>> >-prokash >>> > >>> >On 1/16/15 8:15 AM, "Sinha, Prokash" wrote: >>> > >>> >>Has anyone seen this , when clang is being used for 10.1 compilation >>>? >>> >> >>> >>Thanks, >>> >>-prokash >>> >> >>> >> >>> >>On 1/15/15 7:30 PM, "Sinha, Prokash" wrote: >>> >> >>> >>>Hello, >>> >>> >>> >>>I'm trying to find out what could be the cause of a kldload problem >>>I'm >>> >>>facing. Here is the context detail -- >>> >>> >>> >>> >>> >>>1. I'm building two ko module. And it has a dependency order, so >>>when I >>> >>>load the first module, it loads, and a function symbol ( F ) is >>>defined >>> >>>into kernel variable space sysctl -b kern.function_list | tr '\0' >>>'\n' | >>> >>>grep symname. >>> >>>2. Now trying to load the 2nd module, and link_elf_obj flags error >>>and >>> >>>symbol undefined when freebsd10.1 is being used. >>> >>>3. If I probe using the same sysctl as in step 1, I still the symbol >>>is >>> >>>defined. >>> >>> >>> >>>/var/log/messages shows - >>> >>>kernel: link_elf_obj: symbol pan_sys_once undefined >>> >>>kernel: linker_load_file: Unsupported file type >>> >>> >>> >>>The same two modules when complied using freebsd7.2, we don't see >>>the >>> >>>problem. >>> >>> >>> >>> >>> >>>The question is - Is there changes along the elf formats ( in both >>>case >>> >>>it >>> >>>64bit), also is there any changes >>> >>>In the API between those two OS version, that I need to aware of ( >>>and >>> >>>possible flags I need to set). >>> >>> >>> >>>Using objdump -t modone.ko >>> >>>00000000000fb940 g F .text 0000000000000062 pan_sys_once >>> >>> >>> >>> >>> >>> >>> >>>In modtwo.ko it is undefined >>> >>>0000000000000000 *UND* 0000000000000000 pan_sys_once >>> >>> >>> >>> >>> >>>Note the objdump on freebsd 7.2, is identical. So it is defined in >>>the >>> >>>module1 as F(function), and undefined(UND) in module two. >>> >>> >>> >>>Any suggestion, please ? >> >>This is unrelated to either compiler version, or ELF format. >> >>If module B depends on the symbol from a module A, the dependency >>must be declared with the MODULE_DEPEND() macro. Look for examples >>in the tree to see how to use it. >> >>Main kernel symbols are always visible to the loadable modules. > >_______________________________________________ >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 Jan 22 20:13:04 2015 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 451DBFD7 for ; Thu, 22 Jan 2015 20:13:04 +0000 (UTC) Received: from know-smtprelay-omc-2.server.virginmedia.net (know-smtprelay-omc-2.server.virginmedia.net [80.0.253.66]) by mx1.freebsd.org (Postfix) with ESMTP id B791FDE3 for ; Thu, 22 Jan 2015 20:13:02 +0000 (UTC) Received: from [192.168.1.100] ([86.20.122.200]) by know-smtprelay-2-imp with bizsmtp id j8Br1p03w4KXVwe018BsYL; Thu, 22 Jan 2015 20:11:52 +0000 X-Originating-IP: [86.20.122.200] X-Spam: 0 X-Authority: v=2.1 cv=AoZg3YNP c=1 sm=1 tr=0 a=WByauD8lJrWvBFCNrxRoEQ==:117 a=WByauD8lJrWvBFCNrxRoEQ==:17 a=QUYuZ4s-nQIA:10 a=N659UExz7-8A:10 a=NLZqzBF-AAAA:8 a=87fYffSeWjY_g9tikLwA:9 a=pILNOxqGKmIA:10 a=mXT9DezMnvYA:10 a=4eCdy6saq1AA:10 a=FDpV8SSpbXUA:10 a=g9Him0aCsJQA:10 Message-ID: <54C15981.9010605@NTLWorld.com> Date: Thu, 22 Jan 2015 20:11:45 +0000 From: Jonathan de Boyne Pollard User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: FreeBSD Hackers Subject: Re: nosh version 1.12 References: <54430B41.3010301@NTLWorld.com> <54B86FD5.3090203@NTLWorld.com> In-Reply-To: <54B86FD5.3090203@NTLWorld.com> Content-Type: text/plain; charset=windows-1252; 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: Thu, 22 Jan 2015 20:13:04 -0000 Jonathan de Boyne Pollard: > And I know about the keyboard LEDs. I think that I've fixed them for version 1.13. I've discovered some interesting things about caps lock in VirtualBox along the way. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 21:11:47 2015 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 2DBDCD75 for ; Thu, 22 Jan 2015 21:11:47 +0000 (UTC) Received: from elektropost.org (elektropost.org [217.115.13.199]) (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 732916BD for ; Thu, 22 Jan 2015 21:11:46 +0000 (UTC) Received: (qmail 74260 invoked from network); 22 Jan 2015 21:11:37 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with ESMTPS (DHE-RSA-AES128-SHA encrypted); 22 Jan 2015 21:11:37 -0000 Message-ID: <54C16782.2010307@erdgeist.org> Date: Thu, 22 Jan 2015 22:11:30 +0100 From: Dirk Engling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: FreeBSD Hackers Subject: zero size memset Content-Type: text/plain; charset=utf-8 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, 22 Jan 2015 21:11:47 -0000 Dear fellow hackers, knowing that the memset API tends to be hard to remember from time to time, I grepped the FreeBSD source for occurences of memset with a length parameter of 0 and a character parameter that should have been a length and found the following: ./contrib/gdb/gdb/remote.c: memset (regs, rs->sizeof_g_packet, 0); ./contrib/gdb/gdb/std-regs.c: memset (buf, TYPE_LENGTH (VALUE_TYPE (val)), 0); ./contrib/gdb/gdb/std-regs.c: memset (buf, TYPE_LENGTH (VALUE_TYPE (val)), 0); ./contrib/gdb/gdb/std-regs.c: memset (buf, TYPE_LENGTH (VALUE_TYPE (val)), 0); Whom to nudge to have this fixed? I also grepped the tree for occurences of x = realloc(x ... but found too many of them to check all instances if they properly abort() when x is NULL. Does anyone know how to exclude false positives here? TIA, erdgeist From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 21:56:36 2015 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 C5320929 for ; Thu, 22 Jan 2015 21:56:36 +0000 (UTC) Received: from nm23-vm1.bullet.mail.bf1.yahoo.com (nm23-vm1.bullet.mail.bf1.yahoo.com [98.139.213.141]) (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 733EEB3A for ; Thu, 22 Jan 2015 21:56:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1421963788; bh=ePBfAPMVFeXSXfEUJjclSiPGXaVXmIxaWxcrQ7HXimE=; h=Date:From:To:CC:Subject:From:Subject; b=LwjBo2M4qe+ap5UQy4Jfj5IC9Ol5ZsH+Yh4iFUaOeyh3PDerdVfcL8r664A6LEkusL5wMrgveSg5kamvaHCXeZHsWv8gxZmL9eYmZaymz+tl2+9CvpPTu0kE7E6sBtaioH+TsfA/qoNT2Ij6VOq7aF15pok35HU86iHiFEhBitOwyQDfRfW17RvhOgv3aXWvGVaPSKkdr/Dz4AZLaroyzje2KdcnTHO6E+XnMEHA/0iLHaXmdl/gt3zpBsxc2XJHvR1JBWCNvVjJTQlfeemqyFnSVO76qJbIfWERh4nBKnm3Vgp0qte7YW5feZz913m24FLmXYeL6ZKDeVftmAUcYg== Received: from [98.139.212.151] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 22 Jan 2015 21:56:28 -0000 Received: from [98.139.211.194] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 22 Jan 2015 21:56:28 -0000 Received: from [127.0.0.1] by smtp203.mail.bf1.yahoo.com with NNFMP; 22 Jan 2015 21:56:28 -0000 X-Yahoo-Newman-Id: 904461.61489.bm@smtp203.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 5o6k3zsVM1k2aZJ79SiZQsI58lJRts0JanBgEcw7sLi_CyV U8C4cLw.RCey011Uc6V3n4d5s8YbANuz0jX9K2_Fd9oK8xTe2RM6vCpb47EI wK5MUoYIX587Wv_pn1ONthVWzUXp9Klfc08E4tVkm0mR5yaHPwUK.yKognQB tcfLJZvsXpP_KR5aTk0SGRTCDPhcr8dfdzEBVcnRdzn8t.VytIbsiVGrioT4 GI3fdHk5Hp.gppVrje7Sy0cEM28A333LhaX_rtJz2ZerO60H7lGa8KJgg3co rL23Gp669Btv29OXIjvb8mcVfeScyEC_qr3ES_FdXhCeBYexspxpapLyAm8o qt6TzAnycREHTI2_xQD.nNZa0GgmElCTdCVtIdL7T6MctqQ0brFUQikmPxVS sbeKt12yLEiSn1wFS8tz8moKra9abU3iDki8zGp3Swqe7gahUemYMUXjPzVX 1FxZ7ZB23csAQfFyNVp_G03i8A.ZY.fX4m_WhC.Dc46N09L5HPIjW2.7r0sK 3OGlEYZFH6TBlFTviqFHzI7Ict0TJaYmyeNLWF2qMB1hypaeIBMOxevOcPQ2 73NwGOpI2_yuNjT3rIOS70UaMXyt_9pHn X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Message-ID: <54C17215.8060700@FreeBSD.org> Date: Thu, 22 Jan 2015 16:56:37 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Dirk Engling Subject: Re: zero size memset Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: Thu, 22 Jan 2015 21:56:36 -0000 Hi Dirk; AFAICT, gdb is unmaintained and will be replaced by LLDB. About realloc, those are rather difficult to catch. Perhaps the clang static analyzer can give you some hints on what to look at: http://scan.freebsd.org/ And FWIW, we also have reallocf(). Regards, Pedro. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 22:04:19 2015 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 6A8DDAD8; Thu, 22 Jan 2015 22:04:19 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 01EA4C14; Thu, 22 Jan 2015 22:04:19 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id fb4so5992430wid.2; Thu, 22 Jan 2015 14:04:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6s52bRFpqr2oN/6xRCWAre/MrgIETuk+Hf1JKiFpvrg=; b=icYH7tKa/VX96oy+hE1fhk1fgbH/Qmbl5PU4nV+hHponJtX/9EbpKAA2iM0tSmyHSm m/wq/11Xhi2uOpRzeCn1JtKRhj4KMLcvHZ/jdAwN9pSrcYzs7CbIpwcHy0SS9WwHEY9r 5l8L71ECS5X8fChdalDfQG3rRUmUDLaQFisnZBO8AavA+8CowaS/p0OAT3FPkkUNA15N a0IYO4E8oClQ9lsdFfTGXQqDTSVYLsyA+puwZLDA2wveOba3OaN6twRMb8tOLDxwFrVC rN2yhAzEHgrXyWqhmiSEQ5tH0+6suP+gC/RlRfZriq7Uq0IbfsAs1AUfRyNMLDu2E8s8 rY6w== MIME-Version: 1.0 X-Received: by 10.194.60.70 with SMTP id f6mr7315568wjr.109.1421964257475; Thu, 22 Jan 2015 14:04:17 -0800 (PST) Sender: asomers@gmail.com Received: by 10.194.17.129 with HTTP; Thu, 22 Jan 2015 14:04:17 -0800 (PST) In-Reply-To: <54C17215.8060700@FreeBSD.org> References: <54C17215.8060700@FreeBSD.org> Date: Thu, 22 Jan 2015 15:04:17 -0700 X-Google-Sender-Auth: u3_tLcNv5S2Id9g7GmxOjVD5Fdg Message-ID: Subject: Re: zero size memset From: Alan Somers To: Pedro Giffuni Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Hackers , Dirk Engling 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, 22 Jan 2015 22:04:19 -0000 On Thu, Jan 22, 2015 at 2:56 PM, Pedro Giffuni wrote: > Hi Dirk; > > AFAICT, gdb is unmaintained and will be replaced by LLDB. > > About realloc, those are rather difficult to catch. Perhaps > the clang static analyzer can give you some hints on > what to look at: > > http://scan.freebsd.org/ > > And FWIW, we also have reallocf(). > > Regards, > > Pedro. > Both of these errors sound like things that Coverity ought to be able to detect. Have you looked in the Coverity reports yet? From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 22:34:49 2015 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 C204F452 for ; Thu, 22 Jan 2015 22:34:49 +0000 (UTC) Received: from nm34-vm2.bullet.mail.bf1.yahoo.com (nm34-vm2.bullet.mail.bf1.yahoo.com [72.30.239.74]) (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 75D27EF6 for ; Thu, 22 Jan 2015 22:34:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1421965713; bh=/R/lcF8pMWILjvzog929FL+ANUknPhloS9rJAABTT1s=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=ZE7b1aPKeBmvJKsXa3LMSx2OLAKYnzr/zO7cU1zzzlZObL2WlURKjlYjuyipQ/BSxqQyUMBTNREGrJjg8/JdMxexkjJgaHl6i1hrvBP7bt7sgc+jDf4Wzbu6wGlM4TMABpXzPQZfe14sNsmfBEN1wXE0vHykKHa/EWitNIyDLeUKrbFoG2HufUZiSxbNKFkh/8H3z1rwsJJuvEy28O5ToZYSaZD65+P5JbpoNARGz6DJlesO4uvQ+vwILDfAI7oRk/Biz1b9m+d8h92v3s+Tr5rNw8fUA+NotqUHaOp1Z2s0EizIIYcpa0gp/WSIRLGFNEqKynvDJ8fR0/HjT8FUEQ== Received: from [66.196.81.170] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 22 Jan 2015 22:28:33 -0000 Received: from [68.142.230.69] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 22 Jan 2015 22:28:33 -0000 Received: from [127.0.0.1] by smtp226.mail.bf1.yahoo.com with NNFMP; 22 Jan 2015 22:28:33 -0000 X-Yahoo-Newman-Id: 529817.89239.bm@smtp226.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 77rPpeMVM1li9jHu2en_tl7hy26M.p.XSc6ADHZ83DuQuEq _wYN7uFWNw2W0TRQLpU4iVCKhVzTD6Qg1Fp8lc.UpNCXNCjl4MuK7yv.7Sb. ez3qH_IbhveS_iMDkNT9zkhoFy4T29l0CBOxBO.6d2JbyKVXFmWlNZKXRX4i fovnEUCym3mg9186GURMGRauTf_0XcO0dKSHhwjW_kxanMz1rmb9B_i9N9c3 W00qD5DD1HMZ7MqZUb8Euy1ggfsOOUi1eyfIUPUroaJPShsrL7xCdpO0gC8E 9REKsrCvcrEcclYvockD..a2tsqtLBYJdne9S2LC73NnI3ZoAMDPNCOAVtVh wNi3OYy_T1MBZZH09kY9p2OhJAI19_eUXoHSGDzrUlsKIaAYWtqdXTZNwJBV fb8rCkZhuKqGZM.aevmIztohKOSK.2Qj.BP2KmxnQ3e92vg5RQVe_thsDDWC bmXfrVffihXKkVwTnD4Z8go_sHOl9ie.ied6Z3Vzjqw2kRjWPnxD1x27VxHF ijK0VwjoP5sTOwfL2QMbO7aBoNUVCLLGx X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Message-ID: <54C17999.1050201@FreeBSD.org> Date: Thu, 22 Jan 2015 17:28:41 -0500 From: Pedro Giffuni Organization: FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alan Somers Subject: Re: zero size memset References: <54C17215.8060700@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Hackers , Dirk Engling 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, 22 Jan 2015 22:34:49 -0000 On 22/01/2015 05:04 p.m., Alan Somers wrote: > On Thu, Jan 22, 2015 at 2:56 PM, Pedro Giffuni wrote: >> Hi Dirk; >> >> AFAICT, gdb is unmaintained and will be replaced by LLDB. >> >> About realloc, those are rather difficult to catch. Perhaps >> the clang static analyzer can give you some hints on >> what to look at: >> >> http://scan.freebsd.org/ >> >> And FWIW, we also have reallocf(). >> >> Regards, >> >> Pedro. >> > Both of these errors sound like things that Coverity ought to be able > to detect. Have you looked in the Coverity reports yet? CID 604160, 604163, 604161, 604162 correspond to the issues Dirk grepped. Pedro. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 23 00:30:22 2015 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 741F3CCE for ; Fri, 23 Jan 2015 00:30:22 +0000 (UTC) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E9992D16 for ; Fri, 23 Jan 2015 00:30:21 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id gf13so541873lab.8 for ; Thu, 22 Jan 2015 16:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1RiJk3nSgI9Lvr/YaHo0yBaSIRG2MwVbZwDpLySTaCs=; b=BG+8JZiJfCIZdiWFnM6/3xd2Xt1SLSb3X3dK9ePiLu0myzem3dJwPcpQCW2+nMLgUJ GBao07qgCHrHj/9t5uMWQ4hSBqvkWz6RBaneTdw4kXVvR3NiNQKTVHXqoISxvaQJfCnj GmssIwU7AGSU98ct0+cgn/ZSDYsBFwIqflPsQoIoWraYdGO5qB2WqksQvVsZuXtwGO7g Fj/4a8GYqYjVG6UIijkSCjAfHWsZ0b4CrsqD09raVWGRmLsRwXDklUx5EfbdvBW7MBiG b1Vd3iFr/nDVpFj2YXP3Sfx7c+rcTp4MsCHPQ4ruuBtRXydQESu5or/rvw7ZT7+embOp 1eBg== MIME-Version: 1.0 X-Received: by 10.112.134.74 with SMTP id pi10mr4586059lbb.67.1421973020025; Thu, 22 Jan 2015 16:30:20 -0800 (PST) Received: by 10.114.78.131 with HTTP; Thu, 22 Jan 2015 16:30:19 -0800 (PST) In-Reply-To: <20150122083514.GU42409@kib.kiev.ua> References: <20150120083212.GC42409@kib.kiev.ua> <20150122083514.GU42409@kib.kiev.ua> Date: Thu, 22 Jan 2015 19:30:19 -0500 Message-ID: Subject: Re: Sleeping thread held mutex in vm_pageout_oom() From: Ryan Stone To: Konstantin Belousov 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: Fri, 23 Jan 2015 00:30:22 -0000 Other than the redundant braces on the else below, this looks good. I tested it today and saw no further problems. I do think that a WITNESS_WARN() in vmspace_free() would be appropriate. I'll give that a sanity here to make sure that nothing explodes and if everything looks ok, I'll commit it. > @@ -1573,16 +1602,19 @@ vm_pageout_oom(int shortage) > */ > if (size > bigsize) { > if (bigproc != NULL) > - PROC_UNLOCK(bigproc); > + PRELE(bigproc); > bigproc = p; > bigsize = size; > - } else > - PROC_UNLOCK(p); > + } else { > + PRELE(p); > + } From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 23 08:37:01 2015 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 0EEFE28F for ; Fri, 23 Jan 2015 08:37:01 +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 727A5FC5 for ; Fri, 23 Jan 2015 08:37:00 +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 t0N8asnd091987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 10:36:54 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t0N8asnd091987 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t0N8asKp091986; Fri, 23 Jan 2015 10:36:54 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 23 Jan 2015 10:36:54 +0200 From: Konstantin Belousov To: Ryan Stone Subject: Re: Sleeping thread held mutex in vm_pageout_oom() Message-ID: <20150123083654.GB42409@kib.kiev.ua> References: <20150120083212.GC42409@kib.kiev.ua> <20150122083514.GU42409@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Fri, 23 Jan 2015 08:37:01 -0000 On Thu, Jan 22, 2015 at 07:30:19PM -0500, Ryan Stone wrote: > Other than the redundant braces on the else below, this looks good. I > tested it today and saw no further problems. The (possibly implicit) style rule is to have {} around both branches in if () when one branch requires {}. > > I do think that a WITNESS_WARN() in vmspace_free() would be > appropriate. I'll give that a sanity here to make sure that nothing > explodes and if everything looks ok, I'll commit it. Ok. > > > @@ -1573,16 +1602,19 @@ vm_pageout_oom(int shortage) > > */ > > if (size > bigsize) { > > if (bigproc != NULL) > > - PROC_UNLOCK(bigproc); > > + PRELE(bigproc); > > bigproc = p; > > bigsize = size; > > - } else > > - PROC_UNLOCK(p); > > + } else { > > + PRELE(p); > > + } From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 23 07:37:45 2015 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 9AB71A91 for ; Fri, 23 Jan 2015 07:37:45 +0000 (UTC) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 60B2CA68 for ; Fri, 23 Jan 2015 07:37:45 +0000 (UTC) Received: by mail-ig0-f182.google.com with SMTP id r10so742838igi.3 for ; Thu, 22 Jan 2015 23:37:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=rqP9SWvdqncedfw/03aJz5/qJ/Zkcby9OM3k+rkHyZg=; b=aETEKm5CliDwFUEy/Y1Rgv7cytjL1GlhaYadFRVW/R1XEGbnWm6w7m+8liOKEmn9NL DvD6kffYL9xBtNcSHdJ0Z3tcw+24y+EQQz0n+dEYj3SLueKTtlki7ANDNALCzodFGpqs N124skOwmo8UbNEcW2YCUU+xIMeZ/eYOXe4qLe1Fr736sOaMdO7ZUGbfvnjDdPkr0KFU yK8sNU/ZceMXDm5Y0Gs6YbVPmu7Rbrrw/WpuzRPLv/vM8GFE9jXNNp1mkYfy7wCRJcFT +EOInIkWTjw4SGSf40VUfvb8mE6I2h5o9PWUI22hnGCDcfVnAeyWz1SvmJ2Vg+NPyNiI IUwQ== MIME-Version: 1.0 X-Received: by 10.107.9.99 with SMTP id j96mr2242103ioi.91.1421998664689; Thu, 22 Jan 2015 23:37:44 -0800 (PST) Received: by 10.42.152.1 with HTTP; Thu, 22 Jan 2015 23:37:44 -0800 (PST) Date: Fri, 23 Jan 2015 09:37:44 +0200 Message-ID: Subject: Add AVIC bit to AMD SVM From: Dmitry Luhtionov To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary=001a113ec1064887d0050d4cddd4 X-Mailman-Approved-At: Fri, 23 Jan 2015 12:25:44 +0000 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, 23 Jan 2015 07:37:45 -0000 --001a113ec1064887d0050d4cddd4 Content-Type: text/plain; charset=UTF-8 --001a113ec1064887d0050d4cddd4 Content-Type: text/plain; charset=US-ASCII; name="svm.c.diff" Content-Disposition: attachment; filename="svm.c.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i599464l0 LS0tIHNyYy9zeXMvYW1kNjQvdm1tL2FtZC9zdm0uYy5vcmlnCTIwMTUtMDEtMTYgMTI6NTg6MDQu MDAwMDAwMDAwICswMjAwCisrKyBzcmMvc3lzL2FtZDY0L3ZtbS9hbWQvc3ZtLmMJMjAxNS0wMS0y MyAwOToyOToxMC4wMDAwMDAwMDAgKzAyMDAKQEAgLTgwLDYgKzgwLDcgQEAKICNkZWZpbmUgQU1E X0NQVUlEX1NWTV9ERUNPREVfQVNTSVNUCUJJVCg3KSAgLyogRGVjb2RlIGFzc2lzdCAqLwogI2Rl ZmluZSBBTURfQ1BVSURfU1ZNX1BBVVNFX0lOQwkJQklUKDEwKSAvKiBQYXVzZSBpbnRlcmNlcHQg ZmlsdGVyLiAqLwogI2RlZmluZSBBTURfQ1BVSURfU1ZNX1BBVVNFX0ZUSAkJQklUKDEyKSAvKiBQ YXVzZSBmaWx0ZXIgdGhyZXNob2xkICovCisjZGVmaW5lIEFNRF9DUFVJRF9TVk1fQVZJQwkJQklU KDEzKSAvKiBBZHZhbmNlZCBWaXJ0dWFsIEludGVycnVwdCBDb250cm9sbGVyICovCiAKICNkZWZp bmUJVk1DQl9DQUNIRV9ERUZBVUxUCShWTUNCX0NBQ0hFX0FTSUQgCXwJXAogCQkJCVZNQ0JfQ0FD SEVfSU9QTQkJfAlcCg== --001a113ec1064887d0050d4cddd4-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 23 15:24:39 2015 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 EE7E2461 for ; Fri, 23 Jan 2015 15:24:39 +0000 (UTC) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A41303B0 for ; Fri, 23 Jan 2015 15:24:39 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id v8so6169700qal.8 for ; Fri, 23 Jan 2015 07:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=QvciUcdOdMg/y85V5WkBfUqpQ76U1VwmOfe1PnmLDWI=; b=oEUlGp9iMDDb2HBvpXxIvVQ1NLHG2ANq3A79HeT/8Gw0C8/v81KdLFA1xXdp3sI/+D q8tT6kUtPiaAhTnokMvZZpYDA32g9WDL5/HG2/RU2uCCid3epsmd/2fbEx1GA6fsGugh U9nT3qBFmQXpt7oVaYwpmHKAvk0P+ubg0ShVzlzdVIDiMwADtv19mAmq5MT/IFajBCYi KJhl4/O+qOdA5jIx1ivqGrObhZ6bleOpw+0vhNxl5Pft3Yl7GDVuM7V4Ib7zmbI6BmoE K5LQ/YyR/sVtadbfC76iXS24MWoz8KSZd3dpZenDyYQ/lF3fVX8Vm1TxTeGUJ4lKLay7 kwjQ== X-Received: by 10.140.94.6 with SMTP id f6mr14322904qge.38.1422026678787; Fri, 23 Jan 2015 07:24:38 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.140.39.209 with HTTP; Fri, 23 Jan 2015 07:24:18 -0800 (PST) In-Reply-To: <20150123083654.GB42409@kib.kiev.ua> References: <20150120083212.GC42409@kib.kiev.ua> <20150122083514.GU42409@kib.kiev.ua> <20150123083654.GB42409@kib.kiev.ua> From: Ed Maste Date: Fri, 23 Jan 2015 10:24:18 -0500 X-Google-Sender-Auth: sZfO3SVu0WP1jNEi91DjqfPrZh4 Message-ID: Subject: Re: Sleeping thread held mutex in vm_pageout_oom() To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Ryan Stone 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, 23 Jan 2015 15:24:40 -0000 On 23 January 2015 at 03:36, Konstantin Belousov wrote: > On Thu, Jan 22, 2015 at 07:30:19PM -0500, Ryan Stone wrote: >> Other than the redundant braces on the else below, this looks good. I >> tested it today and saw no further problems. > The (possibly implicit) style rule is to have {} around both branches > in if () when one branch requires {}. Unfortunately style(9) presents the opposite case as an example: Closing and opening braces go on the same line as the else. Braces that are not necessary may be left out. if (test) stmt; else if (bar) { stmt; stmt; } else stmt; It does say that the braces "may be" left out though, and I much prefer the guideline as you state it. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 23 18:30:24 2015 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 D1DC5910 for ; Fri, 23 Jan 2015 18:30:24 +0000 (UTC) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D07CCE1 for ; Fri, 23 Jan 2015 18:30:24 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id x3so9139856wes.5 for ; Fri, 23 Jan 2015 10:30:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aWAbsYhF4QPZmXBHjkPr57PcypnIENK2kwV2Y/qtl8A=; b=TUSwAjFqy0OnBKexGS3t00IVSCvJ6U583HsH6eLAikOEenR80CEAWD2YQCbR48IS9Y BJdNakCE560PkoQYKGCe7176Qb61BxsYhnAt4MWiokeubxbnAgvq7sZnkYDphQ5jmlvl 3VJuSKhurLKQMX391GpG38nY1a0h9bR9z/1JUEXOL5SfV3oLr1tlNY3NvryxhLQddlqW Ed30eilp4Yhqtz6kczH1XARq2xlfg7CNOKMNaH4NqxlJkKb1EhOt+xfnG2EJf5iYE1k4 oFXhP6RXmbKMWFNf5SmF6XqIIj6Ncr9MfTPDTVF2srgNFieltCdWPVcXLuOBm2pwu94k Tyvw== MIME-Version: 1.0 X-Received: by 10.180.105.68 with SMTP id gk4mr384138wib.30.1422037817016; Fri, 23 Jan 2015 10:30:17 -0800 (PST) Received: by 10.27.5.207 with HTTP; Fri, 23 Jan 2015 10:30:16 -0800 (PST) In-Reply-To: References: Date: Fri, 23 Jan 2015 10:30:16 -0800 Message-ID: Subject: Re: Add AVIC bit to AMD SVM From: Neel Natu To: Dmitry Luhtionov Content-Type: text/plain; charset=UTF-8 Cc: 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, 23 Jan 2015 18:30:24 -0000 Hi Dmitry, Thanks for the patch. I'll commit this over the weekend. best Neel On Thu, Jan 22, 2015 at 11:37 PM, Dmitry Luhtionov wrote: > > > _______________________________________________ > 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 Fri Jan 23 21:24:29 2015 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 A7F1E6FF for ; Fri, 23 Jan 2015 21:24:29 +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 1CD035F0 for ; Fri, 23 Jan 2015 21:24:28 +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 t0NLOQOj040057 for ; Fri, 23 Jan 2015 22:24:26 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: puchar.net: Host laptop.wojtek.intra [10.1.0.2] claimed to be [10.1.0.2] Date: Fri, 23 Jan 2015 22:24:22 +0100 (CET) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: freebsd-hackers@freebsd.org Subject: svn checkout head Message-ID: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Fri, 23 Jan 2015 22:24:26 +0100 (CET) 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, 23 Jan 2015 21:24:29 -0000 tried both svn checkout http://svn.freebsd.org/base/head /usr/src-current/ and svnlite svn is from ports. no matter what i use - it ends with signal 11 after some files. svn cleanup and svn update sometimes helps moving few files more any ideas? From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 23 21:30:31 2015 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 0937187F for ; Fri, 23 Jan 2015 21:30:31 +0000 (UTC) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CF10C630 for ; Fri, 23 Jan 2015 21:30:30 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id v10so10926337pde.3 for ; Fri, 23 Jan 2015 13:30:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ORiyHXbbXzrpUSdJ95+IFD1CicVuz7MTVB4XGAmEWz8=; b=YOdHUPjk7qkh/4Rk2hU5bpR1rlJeaA7wBsD4GfGXC1rr65tr/gA8N1TIq2lvVBf78C DVwd6mJTgD5ADHxyeltwd6ThWkHer0A0yO0WDRd8jKb2lthfv+sIPg9W2ZRHPiEI7gSm l+UI7hVdUumgsSrnBzt3yjjeQ0g+LorY/xHhNo9h3XG0D87L1VjGWMReaLHIePdP8yiI xe5J5NHFE8jd7J3Uw/MW8hBkneqBKrpBN4DBp5svbZVz4i34PUTL36S23P9KDgAX8UvZ olhjsKstuqdyuXGg8ZpS8YyVYuFAxNTYOXYNfX7dnVKR7eWU1JRCAZE5Xq0cHye2Ly+j Jv7g== MIME-Version: 1.0 X-Received: by 10.70.29.67 with SMTP id i3mr14746550pdh.132.1422048630446; Fri, 23 Jan 2015 13:30:30 -0800 (PST) Received: by 10.70.101.133 with HTTP; Fri, 23 Jan 2015 13:30:30 -0800 (PST) In-Reply-To: References: Date: Fri, 23 Jan 2015 15:30:30 -0600 Message-ID: Subject: Re: svn checkout head From: Adam Vande More To: Wojciech Puchar Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: 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, 23 Jan 2015 21:30:31 -0000 On Fri, Jan 23, 2015 at 3:24 PM, Wojciech Puchar wrote: > tried both > svn checkout http://svn.freebsd.org/base/head /usr/src-current/ > > and svnlite > > svn is from ports. no matter what i use - it ends with signal 11 after > some files. > > svn cleanup and svn update sometimes helps moving few files more > fsck? -- Adam From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 23 21:30:43 2015 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 5E948970 for ; Fri, 23 Jan 2015 21:30:43 +0000 (UTC) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 23CB0635 for ; Fri, 23 Jan 2015 21:30:43 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id y10so10917256pdj.7 for ; Fri, 23 Jan 2015 13:30:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=FgeJeX1gcfsjZBtjv/HEZs3YE2jz6IwZvEquecUytf4=; b=nDU2fO4w+GvU3gSwTdRyE8ZN0wgcAPgiUyTpbhNRdxkrJhTwdj1q93Tnoe1ojWvuNg qc6aGlFE1eU9U8fsHwKXBTPJwvn9XCqsUJvH4kAwe5+L75+b59MakoKXZkuu8oPclAzz LGchmquTPyUD6GdZy/r2amRdCq+hzcKqWKn6gEd0qmrARzi9kGQBZ2KJwpWaacsT/Cid QbfouV1hbqklONTCnill2xJvk15pDFZaNmZYvw9zgt1eGfkcGHgblG1dlxRSLddHEC2k 0P7+wtj44V9IUdSewUf7lmSviIboTVo94CZ4yg4hYtQTKvHY6e7YwkgSj+omcRc1l3sV umXQ== X-Received: by 10.66.102.1 with SMTP id fk1mr14940797pab.16.1422048642717; Fri, 23 Jan 2015 13:30:42 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:5410:5a6d:b941:52a1? ([2601:8:ab80:7d6:5410:5a6d:b941:52a1]) by mx.google.com with ESMTPSA id i16sm2817534pbq.70.2015.01.23.13.30.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Jan 2015 13:30:42 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_44D9C419-F789-4138-A9F7-E74426225AB6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: svn checkout head From: Garrett Cooper In-Reply-To: Date: Fri, 23 Jan 2015 13:30:40 -0800 Message-Id: References: To: Wojciech Puchar 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: Fri, 23 Jan 2015 21:30:43 -0000 --Apple-Mail=_44D9C419-F789-4138-A9F7-E74426225AB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 23, 2015, at 13:24, Wojciech Puchar wrote: > tried both > svn checkout http://svn.freebsd.org/base/head /usr/src-current/ >=20 > and svnlite >=20 > svn is from ports. no matter what i use - it ends with signal 11 after = some files. >=20 > svn cleanup and svn update sometimes helps moving few files more >=20 >=20 > any ideas? - Compile the port with debug symbols. - Run the command again, optionally via gdb. - Get the backtrace/core. - Send it to the maintainer for review. Cheers, --Apple-Mail=_44D9C419-F789-4138-A9F7-E74426225AB6 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 - https://gpgtools.org iQEcBAEBCgAGBQJUwr2AAAoJEMZr5QU6S73etwIIAJ+R0yexQ9eUaUuwd/oa4RVh iHyVqFk7TXzGK2/v0NJTMxXNJ5irnaL22A5YIvVqO7aEbKVfw8vJFF1ceZT+BV/s t+9by2yczWswhgFORtQl0+UdpS5FZGO3egt1/sScyOV5q1hYsGITIE8Xq8J9f954 Ubp3OJsdE/MRFv/Gul1Ow50MjcpJ5emNlShEij38EfWEw+UBhOOrt8ARAWtUkMdo ljiL4gfrOxoDAy8Ucn7Gn4yP9g3TwM+zCabH6Ns0zVjbpXbh8/43cyoU/btl40op kMfMWA8Ro5caewa3rH2LGui3fLiw0CrLNxsxqY5mNPQSZmYOU42r5NAXSUZE6oU= =gQxZ -----END PGP SIGNATURE----- --Apple-Mail=_44D9C419-F789-4138-A9F7-E74426225AB6-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 23 21:41:42 2015 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 0D222E7F for ; Fri, 23 Jan 2015 21:41:42 +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 8C6E9876 for ; Fri, 23 Jan 2015 21:41:40 +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 t0NLfcen040552; Fri, 23 Jan 2015 22:41:38 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: puchar.net: Host laptop.wojtek.intra [10.1.0.2] claimed to be [10.1.0.2] Date: Fri, 23 Jan 2015 22:41:34 +0100 (CET) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: Adam Vande More Subject: Re: svn checkout head 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]); Fri, 23 Jan 2015 22:41:39 +0100 (CET) Cc: 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, 23 Jan 2015 21:41:42 -0000 no help On Fri, 23 Jan 2015, Adam Vande More wrote: > On Fri, Jan 23, 2015 at 3:24 PM, Wojciech Puchar wrote: > tried both > svn checkout http://svn.freebsd.org/base/head /usr/src-current/ > > and svnlite > > svn is from ports. no matter what i use - it ends with signal 11 after some files. > > svn cleanup and svn update sometimes helps moving few files more > > > fsck? > > -- > Adam > > From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 23 22:08:17 2015 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 1068865F for ; Fri, 23 Jan 2015 22:08:17 +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 9078EAB6 for ; Fri, 23 Jan 2015 22:08:16 +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 t0NM8BZU041806; Fri, 23 Jan 2015 23:08:12 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: puchar.net: Host laptop.wojtek.intra [10.1.0.2] claimed to be [10.1.0.2] Date: Fri, 23 Jan 2015 23:08:08 +0100 (CET) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: Garrett Cooper Subject: Re: svn checkout head 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]); Fri, 23 Jan 2015 23:08:12 +0100 (CET) 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: Fri, 23 Jan 2015 22:08:17 -0000 works without problems with svn instead of http On Fri, 23 Jan 2015, Garrett Cooper wrote: > On Jan 23, 2015, at 13:24, Wojciech Puchar wrote: > >> tried both >> svn checkout http://svn.freebsd.org/base/head /usr/src-current/ >> >> and svnlite >> >> svn is from ports. no matter what i use - it ends with signal 11 after some files. >> >> svn cleanup and svn update sometimes helps moving few files more >> >> >> any ideas? > > - Compile the port with debug symbols. > - Run the command again, optionally via gdb. > - Get the backtrace/core. > - Send it to the maintainer for review. > > Cheers, > > From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 23 23:20:45 2015 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 B2353DA0 for ; Fri, 23 Jan 2015 23:20:45 +0000 (UTC) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 788A324F for ; Fri, 23 Jan 2015 23:20:45 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id et14so161113pad.4 for ; Fri, 23 Jan 2015 15:20:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=a0/k/34gLGUwHqxPUCLKM3/YRxvPcBTZomcEo8vNGv4=; b=p/a9jzVCcIB6neKyzSvxmoKPbPyAi4GDhvdnSSl5znBGPL8VlINQfXfVAJAh4r0FSg ls6xHahinlqM1eIVcq2UW4I+Ttq59wTww5JrvpmjQ0/HJjz+l6Ko2+TId53SA83W3Hk1 jmT0ohOvvSv6vZa7MyAo6iF/3xtCulrhp4IoM7O34m7QnJCMfYXegsljWQM/MqyneVIO S2q/7RsBJ4sXZVbHov40x7Uo33KlAKhSt8auh0AMhsMKHPtCijjM/rwpNSI4vim2CEbq 88v0B9F9NN2GXUOqRF4n5nlA7Jb7T2K+ZWXemOIToHn7+3pL3cd0xeXC5Q4EQSBgQjA6 d/aQ== X-Received: by 10.66.227.136 with SMTP id sa8mr15108617pac.110.1422055245024; Fri, 23 Jan 2015 15:20:45 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:5410:5a6d:b941:52a1? ([2601:8:ab80:7d6:5410:5a6d:b941:52a1]) by mx.google.com with ESMTPSA id bq1sm2933014pbb.78.2015.01.23.15.20.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Jan 2015 15:20:44 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_364F44C8-AE4C-41A6-8E68-385A2246AAAB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: svn checkout head From: Garrett Cooper In-Reply-To: Date: Fri, 23 Jan 2015 15:20:43 -0800 Message-Id: <46F13826-3848-49FF-A14E-4EA3D9DB8D4D@gmail.com> References: To: Wojciech Puchar 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: Fri, 23 Jan 2015 23:20:45 -0000 --Apple-Mail=_364F44C8-AE4C-41A6-8E68-385A2246AAAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 23, 2015, at 14:08, Wojciech Puchar wrote: > works without problems with svn instead of http svn opens up less connections than http and also uses a different = transport library. Are you using libneon or the other transport option for http? I remember = that old versions of svn had a really hard time working with one = transport library over another (then they pushed out the one that worked = and fixed up the one that was broken), but that was a few years back. --Apple-Mail=_364F44C8-AE4C-41A6-8E68-385A2246AAAB 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 - https://gpgtools.org iQEcBAEBCgAGBQJUwtdLAAoJEMZr5QU6S73elWsH/RrYhDM8WOzhQqgjzDC+A7sk 4S76wGYIaw2zY0/imd4o70oHuXoyvVrLi77SdWtBObDNQ8rmVwny7KfHxsjH+gqr WTYUQfAt+lwYy85FV/HP6skv4khSg64Hk8itlKfWMQkEoL1Hf+uA33Y0rMbH7QFB x2sQerdjLoLxQOD5jxutxFwkYvFFKI8zQfQlK1MV04L3bd4CtuvDdUl38B4/Qplf rpKBsOKYCYN7AMC5jTwl/q6qd75NS9VgqnPJrO7TgzKnH9KGO8MGneVLMS2mfwib 6hWCqFe5/ZOlVRB6+LLa/3OmFMOJ8b+armul0ZYzdjHyqCeWinE1KvhAdpsXTsY= =5tDW -----END PGP SIGNATURE----- --Apple-Mail=_364F44C8-AE4C-41A6-8E68-385A2246AAAB-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 24 00:30:08 2015 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 A0B8FDE2; Sat, 24 Jan 2015 00:30:08 +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 2580EB0B; Sat, 24 Jan 2015 00:30:08 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id p9so321149lbv.8; Fri, 23 Jan 2015 16:30:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DTGdE8Hs8h1ePXhoTk/nsiqsQ6dRjvHCE++AbMnKwks=; b=YfRYVb8Gq2LhU73b8aozgPn+MwnCNJVcFIJ9GkvSGE5VBB3H7VABeeHDGuYiOA1uV1 Q2VSEDNrEV3CUBt2BQ1CHQkLO2hi9Yn8XKK7DgbHZwTY8tVmliNNDS75rxadk0t8TYoD +ye7IYwd6/x552zzhDBgaBgpEV3hnOofKWWPED0+VCC234YAMcxci6wlGQ06V9ViNzML DxWFfUs0OxESg4JXmwynDJ5e9qgsNBce1aEs2vc01E/8lMh05gP+Hjyo/c5la/3yHXyw NwkDcv38d/1TboO24++Q1AlxSWcDd8MKuiIZGRh28piB1EMnoEbP3vUScAaeaGUOslCo QRJg== MIME-Version: 1.0 X-Received: by 10.112.160.33 with SMTP id xh1mr10235767lbb.60.1422059406126; Fri, 23 Jan 2015 16:30:06 -0800 (PST) Received: by 10.114.78.131 with HTTP; Fri, 23 Jan 2015 16:30:06 -0800 (PST) In-Reply-To: References: <20150120083212.GC42409@kib.kiev.ua> <20150122083514.GU42409@kib.kiev.ua> <20150123083654.GB42409@kib.kiev.ua> Date: Fri, 23 Jan 2015 19:30:06 -0500 Message-ID: Subject: Re: Sleeping thread held mutex in vm_pageout_oom() From: Ryan Stone To: Ed Maste Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , "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, 24 Jan 2015 00:30:08 -0000 On Fri, Jan 23, 2015 at 10:24 AM, Ed Maste wrote: > It does say that the braces "may be" left out though, and I much > prefer the guideline as you state it. That works for me. The WITNESS_WARN() survived a buildworld, so I'll commit that once kib gets the vm_pageout_oom() fix in From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 24 00:37:45 2015 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 2270F3AE for ; Sat, 24 Jan 2015 00:37:45 +0000 (UTC) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c: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 AAD0DC08 for ; Sat, 24 Jan 2015 00:37:44 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id x3so364627wes.5 for ; Fri, 23 Jan 2015 16:37:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tD7us8WmtdhBnqsJWbPdHvUy45jD6vKnOamzgtNC/HE=; b=lm806cgl7dcC+1lrChhPWuVARoi/v2SkKtPvnrGsKeexQCGCzVaJoaDm/AjKy/kkEe SQYzQj/1hxDwiwmRUm88E3O/W5nyMjSp1UeTxTZmU+3hefWbNDB2Iq4aAZX27rqrqa7B ESvJ2uMmWYZFPokP6HPWhvnB2bxKMBau82fCJV7fitvWP5OoQ9hwrazXKpyoHbtiPWHh UJjDHqxQiXiM4iIWwPVl4jGxOPGTMTv1YWyf79Ge3ab4HN5U9fV0fQZfl1a5OStbTh7X 0Dopp9YzR3XGzw4bwHF23IgfKAFBUNexUUrkBd6mZ08liB3S4mNyqdAtA3FoQsSP1Xsr Ej3w== MIME-Version: 1.0 X-Received: by 10.195.12.35 with SMTP id en3mr19595203wjd.129.1422059863126; Fri, 23 Jan 2015 16:37:43 -0800 (PST) Received: by 10.27.5.207 with HTTP; Fri, 23 Jan 2015 16:37:43 -0800 (PST) In-Reply-To: References: Date: Fri, 23 Jan 2015 16:37:43 -0800 Message-ID: Subject: Re: Add AVIC bit to AMD SVM From: Neel Natu To: Dmitry Luhtionov Content-Type: text/plain; charset=UTF-8 Cc: 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: Sat, 24 Jan 2015 00:37:45 -0000 Committed as r277626. https://svnweb.freebsd.org/changeset/base/277626 best Neel On Fri, Jan 23, 2015 at 10:30 AM, Neel Natu wrote: > Hi Dmitry, > > Thanks for the patch. I'll commit this over the weekend. > > best > Neel > > On Thu, Jan 22, 2015 at 11:37 PM, Dmitry Luhtionov > wrote: >> >> >> _______________________________________________ >> 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 Sat Jan 24 02:00:13 2015 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 B42AE489; Sat, 24 Jan 2015 02:00:13 +0000 (UTC) Received: from m.saper.info (m.saper.info [IPv6:2a01:4f8:a0:7383::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "m.saper.info", Issuer "Marcin Cieslak 2011" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 303BB3B0; Sat, 24 Jan 2015 02:00:12 +0000 (UTC) Received: from m.saper.info (saper@localhost [127.0.0.1]) by m.saper.info (8.14.9/8.14.9) with ESMTP id t0O209rO076242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 24 Jan 2015 02:00:10 GMT (envelope-from saper@saper.info) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=saper.info; s=Sep2014; t=1422064810; bh=L+9s04eKJ+NwIh4fV3XI6h9/jJl6H0IfkMPqyWaJUZU=; h=Date:From:To:Subject; b=TpoE9UgZ/uiKIpeH2qi5rEErv+Md4tbWuRLcjO0rPz3nJnaG3KYddzOCI8Ti1TBkW xZAzjDBjMl9UJvE4qavl+U1jd6bunurKG5RB4iFDjDkWK/LgcLuUEOmCcggUaHGiQ7 Dp2ngrv1fO1ZZi2kDwpeXNZsLQfCoUa3wm/35dVQ= Received: from localhost (saper@localhost) by m.saper.info (8.14.9/8.14.9/Submit) with ESMTP id t0O209xa076239; Sat, 24 Jan 2015 02:00:09 GMT (envelope-from saper@saper.info) X-Authentication-Warning: m.saper.info: saper owned process doing -bs Date: Sat, 24 Jan 2015 02:00:09 +0000 From: Marcin Cieslak To: freebsd-hackers@FreeBSD.org, pjd@FreeBSD.org Subject: Do I need in ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 24 Jan 2015 02:00:13 -0000 I am trying to write a GEOM gate module in C++ - for the project that is already written 100% in C++ .... Unfortunately, trying to #include fails: In file included from GEOMGate.cpp:1: In file included from /usr/include/geom/gate/g_gate.h:37: /usr/include/geom/geom.h:118:21: error: expected ';' after struct LIST_ENTRY(g_class) class; ^ /usr/include/geom/geom.h:118:22: error: declaration of anonymous class must be a definition LIST_ENTRY(g_class) class; ^ /usr/include/geom/geom.h:131:19: error: expected member name or ';' after declaration specifiers struct g_class *class; ~~~~~~ ^ /usr/include/geom/geom.h:186:10: error: expected member name or ';' after declaration specifiers void *private; ~~~~ ^ /usr/include/geom/geom.h:215:10: error: expected member name or ';' after declaration specifiers void *private; ~~~~ ^ I think C++ does not like using "class" in this context. One idea would be to get rid of this word in ; but I also noticed that including in does not seem necessary at all (as this is the userland interface). At least our sample ggate userland programs compile fine without it, and ggate kernel module includes separately. Would that be ok to remove seemingly unnecessary include directive? //Marcin [1] http://thread.gmane.org/gmane.os.freebsd.devel.hackers/52098 From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 24 08:25:00 2015 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 843317B1; Sat, 24 Jan 2015 08:25:00 +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 E692D166; Sat, 24 Jan 2015 08:24:59 +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 t0O8Oo5R010802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Jan 2015 10:24:50 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t0O8Oo5R010802 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t0O8Oo3Z010801; Sat, 24 Jan 2015 10:24:50 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 24 Jan 2015 10:24:49 +0200 From: Konstantin Belousov To: Ryan Stone Subject: Re: Sleeping thread held mutex in vm_pageout_oom() Message-ID: <20150124082449.GM42409@kib.kiev.ua> References: <20150120083212.GC42409@kib.kiev.ua> <20150122083514.GU42409@kib.kiev.ua> <20150123083654.GB42409@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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" , Ed Maste 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, 24 Jan 2015 08:25:00 -0000 On Fri, Jan 23, 2015 at 07:30:06PM -0500, Ryan Stone wrote: > On Fri, Jan 23, 2015 at 10:24 AM, Ed Maste wrote: > > It does say that the braces "may be" left out though, and I much > > prefer the guideline as you state it. > > That works for me. > > The WITNESS_WARN() survived a buildworld, so I'll commit that once kib > gets the vm_pageout_oom() fix in I thought that you intend to commit the fix ? This is what I read from your response to the latest patch, and I replied that I agree. From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 24 15:10:29 2015 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 3B2DBDFB for ; Sat, 24 Jan 2015 15:10:29 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EFB6EAD9 for ; Sat, 24 Jan 2015 15:10:28 +0000 (UTC) Received: from [93.104.18.206] (helo=c720-r276659) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1YF2Lx-00041F-UE for freebsd-hackers@freebsd.org; Sat, 24 Jan 2015 16:10:26 +0100 Date: Sat, 24 Jan 2015 16:10:23 +0100 From: Matthias Apitz To: freebsd-hackers@freebsd.org Subject: Re: make installworld/kernel of an amd64 system into an i386 system Message-ID: <20150124151023.GA2667@c720-r276659> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-hackers@freebsd.org References: <20150121121117.GA10645@sh4-5.1blu.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150121121117.GA10645@sh4-5.1blu.de> X-Operating-System: FreeBSD 11.0-CURRENT r269739 (i386) User-Agent: Mutt/1.5.23 (2014-03-12) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 93.104.18.206 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, 24 Jan 2015 15:10:29 -0000 El día Wednesday, January 21, 2015 a las 01:11:17PM +0100, Matthias Apitz escribió: > > Hello, > > I actually run on one of my laptops (Acer C720) a very fresh -HEAD > (r276659), but in 32bit; I want to change this to amd64; I produced a > amd64 memstick which boots fine and also has the sources and obj tree which > was used to create the memstick in > > /usr/local/acerc720/src > /usr/local/acerc720/obj-amd64 > > What I now think as update procedure to install amd64 into the laptop > is: > > - boot the amd64 system from USB > - mount the old i386 root in /dev/ada0p2 as /mnt (there is only this one big > file system, /dev/ada0p1 is boot and /dev/ada0p3 is swap) > - run > cd /usr/local/acerc720/src > MAKEOBJDIRPREFIX=/usr/local/acerc720/obj-amd64 export MAKEOBJDIRPREFIX > make installworld DESTDIR=/mnt > make installkernel DESTDIR=/mnt > ... The 'make install...' failed and it took me some time to understand the reason. For the cross-compilation on the i386 system I have had to build like this: # cd /usr/local/acerC720/src # mkdir /usr/local/acerC720/obj-amd64 # MAKEOBJDIRPREFIX=/usr/local/acerC720/obj-amd64 # export MAKEOBJDIRPREFIX # make buildworld TARGET=amd64 TARGET_ARCH=amd64 # make buildkernel TARGET=amd64 TARGET_ARCH=amd64 If you later use the obj-tree on the bootet 64 bit system to install into the new disk, one must set the MAKEOBJDIRPREFIX to MAKEOBJDIRPREFIX=/usr/local/acerC720/obj-amd64/amd64.amd64 and all will be installed fine. matthias -- Matthias Apitz, guru@unixarea.de, http://www.unixarea.de/ +49-170-4527211 1989-2014: The Wall was torn down so that we go to war together again. El Muro ha sido derribado para que nos unimos en ir a la guerra otra vez. Diese Grenze wurde aufgehoben damit wir gemeinsam wieder in den Krieg ziehen. -- Matthias Apitz, guru@unixarea.de, http://www.unixarea.de/ +49-170-4527211 1989-2014: The Wall was torn down so that we go to war together again. El Muro ha sido derribado para que nos unimos en ir a la guerra otra vez. Diese Grenze wurde aufgehoben damit wir gemeinsam wieder in den Krieg ziehen. From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 24 19:58:10 2015 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 841787B0 for ; Sat, 24 Jan 2015 19:58:10 +0000 (UTC) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 162FF9B5 for ; Sat, 24 Jan 2015 19:58:10 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id l61so2983033wev.8 for ; Sat, 24 Jan 2015 11:58:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pU23RnI7e5AvHE8hWMGixn/Ya1VMUHd30WUqz2IPtZM=; b=cIditZ3imAQtieszXcNtsUkUKnxQUQqooSoG1mued/RxsLIcGLWYBX7iwvzdjxFHEE rvptqBtctVuOG2xZagHtn6CSmUXiDoHdqFQP/pEcX6vHnvS2YXJJPuLp9FeCY7ej4ier Oh4ar+Laq20cDVGOmDGKAcnLZEASDjkvtwAiiFQIU//CbCJbHSf584uaKmzdReAEmitT HRTSK1re4RvuN9ZPM2Z+SI2kuWjNUl9Nou3FPbVYarjiNfZv1xXQluRI/6fbRfUs8siJ aXqgXe3pHiFQ1PZCWmRAKmtyY38QcW1aj9uN/mbqZ5ck9EBVkrBuxZQQSQeJRywMEdTS osSw== MIME-Version: 1.0 X-Received: by 10.180.83.98 with SMTP id p2mr16675838wiy.76.1422129488530; Sat, 24 Jan 2015 11:58:08 -0800 (PST) Received: by 10.27.160.212 with HTTP; Sat, 24 Jan 2015 11:58:08 -0800 (PST) In-Reply-To: <20141014163531.GB26488@mail.michaelwlucas.com> References: <20141010215842.GA6717@mail.michaelwlucas.com> <20141011113008.705ba16d@X220.alogt.com> <20141011074412.GA9432@mail.michaelwlucas.com> <54394A03.6060403@freebsd.org> <20141011175944.GA11131@mail.michaelwlucas.com> <20141014163531.GB26488@mail.michaelwlucas.com> Date: Sat, 24 Jan 2015 21:58:08 +0200 Message-ID: Subject: Re: GBDE not protecting the user From: Andrii Stesin To: "Michael W. Lucas" 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: Sat, 24 Jan 2015 19:58:10 -0000 Hi, any news on the topic? Thanks! WBR, Andrii On Tue, Oct 14, 2014 at 7:35 PM, Michael W. Lucas wrote: > On Sat, Oct 11, 2014 at 01:59:44PM -0400, Michael W. Lucas wrote: >> On Sat, Oct 11, 2014 at 11:17:23AM -0400, Allan Jude wrote: >> > Michael: please file a PR on this now that it is confirmed, and together >> > we can nag someone to fix it. >> >> Fair enough. >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194304 > > Following up on my own bug report: > > This seems to be a generic GBDE error message breakage. Here I change > key 0's passphrase and key file. > > # gbde setkey da0p1 -n 0 -l da0p1.lock -k rat.jpg -L da0p1.lock-new > Enter passphrase: > Opened with key 0 > Enter new passphrase: > Reenter new passphrase: > > I now have a new lock file with a new passphrase. Let's try the old > key file and see what happens. It appears to work, except it doesn't. > > # gbde attach da0p1 -l da0p1.lock -k rat.jpg > Enter passphrase: > # ls /dev/da0p1* > /dev/da0p1 > # gbde detach da0p1 > gbde: Detach of da0p1 failed: Geom not found: "da0p1.bde" > > The new lock file and passphrase do work. > > I would have expected the attach command to call me an idiot rather > than fail silently. An ignorant, uneducated, non-programmer look at > the code encourages my belief. > > Bug report updated. > > ==ml > > -- > Michael W. Lucas - mwlucas@michaelwlucas.com, Twitter @mwlauthor > http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ > _______________________________________________ > 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 Sat Jan 24 20:05:39 2015 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 18F039B4 for ; Sat, 24 Jan 2015 20:05:39 +0000 (UTC) Received: from mail.michaelwlucas.com (mail.michaelwlucas.com [108.61.84.26]) (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 A72EFA92 for ; Sat, 24 Jan 2015 20:05:38 +0000 (UTC) Received: from mail.michaelwlucas.com (localhost [127.0.0.1]) by mail.michaelwlucas.com (8.14.7/8.14.7) with ESMTP id t0OK5Y2M050571; Sat, 24 Jan 2015 15:05:35 -0500 (EST) (envelope-from mwlucas@mail.michaelwlucas.com) Received: (from mwlucas@localhost) by mail.michaelwlucas.com (8.14.7/8.14.7/Submit) id t0OK5Yf0050570; Sat, 24 Jan 2015 15:05:34 -0500 (EST) (envelope-from mwlucas) Date: Sat, 24 Jan 2015 15:05:31 -0500 From: "Michael W. Lucas" To: Andrii Stesin Subject: Re: GBDE not protecting the user Message-ID: <20150124200530.GA50561@mail.michaelwlucas.com> References: <20141010215842.GA6717@mail.michaelwlucas.com> <20141011113008.705ba16d@X220.alogt.com> <20141011074412.GA9432@mail.michaelwlucas.com> <54394A03.6060403@freebsd.org> <20141011175944.GA11131@mail.michaelwlucas.com> <20141014163531.GB26488@mail.michaelwlucas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.michaelwlucas.com X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.michaelwlucas.com [127.0.0.1]); Sat, 24 Jan 2015 15:05:35 -0500 (EST) 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, 24 Jan 2015 20:05:39 -0000 PHK fixed this, it should work just fine now. On Sat, Jan 24, 2015 at 09:58:08PM +0200, Andrii Stesin wrote: > Hi, > > any news on the topic? > > Thanks! > WBR, > Andrii > > > On Tue, Oct 14, 2014 at 7:35 PM, Michael W. Lucas > wrote: > > On Sat, Oct 11, 2014 at 01:59:44PM -0400, Michael W. Lucas wrote: > >> On Sat, Oct 11, 2014 at 11:17:23AM -0400, Allan Jude wrote: > >> > Michael: please file a PR on this now that it is confirmed, and together > >> > we can nag someone to fix it. > >> > >> Fair enough. > >> > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194304 > > > > Following up on my own bug report: > > > > This seems to be a generic GBDE error message breakage. Here I change > > key 0's passphrase and key file. > > > > # gbde setkey da0p1 -n 0 -l da0p1.lock -k rat.jpg -L da0p1.lock-new > > Enter passphrase: > > Opened with key 0 > > Enter new passphrase: > > Reenter new passphrase: > > > > I now have a new lock file with a new passphrase. Let's try the old > > key file and see what happens. It appears to work, except it doesn't. > > > > # gbde attach da0p1 -l da0p1.lock -k rat.jpg > > Enter passphrase: > > # ls /dev/da0p1* > > /dev/da0p1 > > # gbde detach da0p1 > > gbde: Detach of da0p1 failed: Geom not found: "da0p1.bde" > > > > The new lock file and passphrase do work. > > > > I would have expected the attach command to call me an idiot rather > > than fail silently. An ignorant, uneducated, non-programmer look at > > the code encourages my belief. > > > > Bug report updated. > > > > ==ml > > > > -- > > Michael W. Lucas - mwlucas@michaelwlucas.com, Twitter @mwlauthor > > http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ > > _______________________________________________ > > 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" -- Michael W. Lucas - mwlucas@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/