From owner-freebsd-stable@freebsd.org Sun Nov 13 01:13:50 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3011C3D49F for ; Sun, 13 Nov 2016 01:13:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-44.reflexion.net [208.70.210.44]) (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 6A4BE1A52 for ; Sun, 13 Nov 2016 01:13:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17454 invoked from network); 13 Nov 2016 01:13:37 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 13 Nov 2016 01:13:37 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.10.2) with SMTP; Sat, 12 Nov 2016 20:13:58 -0500 (EST) Received: (qmail 17714 invoked from network); 13 Nov 2016 01:13:58 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Nov 2016 01:13:58 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id CD2FDEC7B39; Sat, 12 Nov 2016 17:13:47 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Will there be a sys/arm/conf/ALLWINNER MFC to stable/11 of "Add generic device-tree cpufreq driver"? Message-Id: <13FCBF91-213A-4AF2-8D08-4BBF80736BCA@dsl-only.net> Date: Sat, 12 Nov 2016 17:13:47 -0800 To: freebsd-arm , FreeBSD-STABLE Mailing List , FreeBSD Current X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 01:13:50 -0000 Is the following from head/sys/arm/conf/ALLWINNER (and whatever it takes to support it) ever likely to be MFC'd to stable/11 ? > Revision 305505 - (view) (download) (annotate) - [select for diffs] > Modified Tue Sep 6 21:36:20 2016 UTC (2 months ago) by jmcneill > File length: 2979 byte(s) > Diff to previous 305419 > Add generic device-tree cpufreq driver. Such things might determine if I stick with stable/11 vs. switch to head for a BPi-M3. === Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Sun Nov 13 01:13:56 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7AFEFC3D4AA for ; Sun, 13 Nov 2016 01:13:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-47.reflexion.net [208.70.210.47]) (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 120CC1A63 for ; Sun, 13 Nov 2016 01:13:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17457 invoked from network); 13 Nov 2016 01:13:37 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 13 Nov 2016 01:13:37 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.10.2) with SMTP; Sat, 12 Nov 2016 20:13:52 -0500 (EST) Received: (qmail 23252 invoked from network); 13 Nov 2016 01:13:52 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Nov 2016 01:13:52 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 088C8EC8A88; Sat, 12 Nov 2016 17:13:48 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Will there be a sys/arm/conf/ALLWINNER MFC to stable/11 of "Add generic device-tree cpufreq driver"? Message-Id: <7A3A8EB0-81EF-4C6F-9F78-506B87DCAE72@dsl-only.net> Date: Sat, 12 Nov 2016 17:13:47 -0800 To: freebsd-arm , FreeBSD-STABLE Mailing List , FreeBSD Current X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 01:13:56 -0000 Is the following from head/sys/arm/conf/ALLWINNER (and whatever it takes to support it) ever likely to be MFC'd to stable/11 ? > Revision 305505 - (view) (download) (annotate) - [select for diffs] > Modified Tue Sep 6 21:36:20 2016 UTC (2 months ago) by jmcneill > File length: 2979 byte(s) > Diff to previous 305419 > Add generic device-tree cpufreq driver. Such things might determine if I stick with stable/11 vs. switch to head for a BPi-M3. === Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Sun Nov 13 02:00:15 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D8A5C3D6D1 for ; Sun, 13 Nov 2016 02:00:15 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 4FC881C9C; Sun, 13 Nov 2016 02:00:15 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 82942241; Sun, 13 Nov 2016 02:00:15 +0000 (UTC) Date: Sun, 13 Nov 2016 02:00:15 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <1931306102.33.1479002415054.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <279769347.32.1478981015184.JavaMail.jenkins@jenkins-9.freebsd.org> References: <279769347.32.1478981015184.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_stable_10 #456 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 02:00:15 -0000 https://jenkins.FreeBSD.org/job/FreeBSD_stable_10/456/ From owner-freebsd-stable@freebsd.org Sun Nov 13 03:02:57 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BAB59C3F716 for ; Sun, 13 Nov 2016 03:02:57 +0000 (UTC) (envelope-from pasi@me.com) Received: from mr26p42im-ztdg06103201.me.com (mr26p42im-ztdg06103201.me.com [17.111.243.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A14B3791 for ; Sun, 13 Nov 2016 03:02:57 +0000 (UTC) (envelope-from pasi@me.com) Received: from process-dkim-sign-daemon.mr26p42im-ztdg06103201.me.com by mr26p42im-ztdg06103201.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OGK00L005H82U00@mr26p42im-ztdg06103201.me.com> for freebsd-stable@FreeBSD.org; Sun, 13 Nov 2016 02:02:51 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1479002571; bh=liPD8A6+z8DVBc45/rbCUE5MsC3uO859W3WVYtyU0wo=; h=From:Content-type:Subject:Message-id:Date:To:MIME-version; b=ezHjtOBOo3s0rwf/Sx82uf8T8j+3CvdVLhvOjPnExT0MCWbp/3SFC77Q3eXRHD2vM JhS7UUww6CB2HEfbJ0Q7xTCkfKjY+npNNMbB9c38f1AjwqKwVm7H3ZQDLo28kjPe8k vDpoeHP3YPPVxa8P74451QU3OqJY7gll126M5BuuTJ66POcKIWLGrWCjmkQISSnX3N zAe/gKPW4AdJRXzeL4Yj+c2jB7IonLI1F8TnKi+0xWF/FZmLOCK2b36VkrHl0wOOY1 SRD5hPwqIL70FPItC7+ylcVOhPWruiLNbSpi4rXR/zC6Lk/AcznBA8WTDc3c/+rg6t KAdY6ZY5525rA== Received: from mba.lan.kanalje.se (h-158-24.a357.priv.bahnhof.se [109.228.158.24]) by mr26p42im-ztdg06103201.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OGK002HE5OOWZ50@mr26p42im-ztdg06103201.me.com> for freebsd-stable@FreeBSD.org; Sun, 13 Nov 2016 02:02:51 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-11-12_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=4 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1611130035 From: Pasi Koivisto Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Subject: Trouble with 10.3 and powerd on APU Message-id: <8737C024-D0DB-4A38-963E-F21B8E418623@me.com> Date: Sun, 13 Nov 2016 03:03:32 +0100 To: freebsd-stable@FreeBSD.org MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 03:02:57 -0000 Is this right? Haven't had to check into it but I believe it's new since = upgrade to 10.3 $ dmesg | grep CPU: | tail -n 1 CPU: AMD A4-5300 APU with Radeon(tm) HD Graphics (3393.90-MHz = K8-class CPU) Snippet from /boot/loader.conf cpufreq_load=3D"YES" amdtemp_load=3D"YES" Snippet from /boot/rc.conf # Power management powerd_enable=3D"YES" #powerd_flags=3D"" performance_cx_lowest=3D"Cmax" economy_cx_lowest=3D"Cmax" Case 1: #hint.acpi_throttle.0.disabled=3D"1" from /boot/device.hints $ sysctl -a | grep cpu kern.smp.cpus: 2 kern.smp.maxcpus: 64 <118>powerd: no cpufreq(4) support -- aborting: No such file or = directory cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu0: on acpi0 cpu1: on acpi0 <118>powerd: no cpufreq(4) support -- aborting: No such file or = directory module_register: cannot register cpu/ichss from cpufreq.ko; already = loaded from kernel Module cpu/ichss failed to register: 17 module_register: cannot register cpu/est from cpufreq.ko; already loaded = from kernel Module cpu/est failed to register: 17 module_register: cannot register cpu/hwpstate from cpufreq.ko; already = loaded from kernel Module cpu/hwpstate failed to register: 17 module_register: cannot register cpu/p4tcc from cpufreq.ko; already = loaded from kernel Module cpu/p4tcc failed to register: 17 module_register: cannot register cpu/powernow from cpufreq.ko; already = loaded from kernel Module cpu/powernow failed to register: 17 cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu0: on acpi0 cpu1: on acpi0 <118>powerd: no cpufreq(4) support -- aborting: No such file or = directory cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu0: on acpi0 cpu1: on acpi0 <118>powerd: no cpufreq(4) support -- aborting: No such file or = directory cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu0: on acpi0 cpu1: on acpi0 <118>powerd: no cpufreq(4) support -- aborting: No such file or = directory cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu0: on acpi0 cpu1: on acpi0 <118>powerd: no cpufreq(4) support -- aborting: No such file or = directory cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu0: on acpi0 cpu1: on acpi0 <118>powerd: no cpufreq(4) support -- aborting: No such file or = directory module_register: cannot register cpu/ichss from cpufreq.ko; already = loaded from kernel Module cpu/ichss failed to register: 17 module_register: cannot register cpu/est from cpufreq.ko; already loaded = from kernel Module cpu/est failed to register: 17 module_register: cannot register cpu/hwpstate from cpufreq.ko; already = loaded from kernel Module cpu/hwpstate failed to register: 17 module_register: cannot register cpu/p4tcc from cpufreq.ko; already = loaded from kernel Module cpu/p4tcc failed to register: 17 module_register: cannot register cpu/powernow from cpufreq.ko; already = loaded from kernel Module cpu/powernow failed to register: 17 module_register: cannot register cpu/ichss from cpufreq.ko; already = loaded from kernel Module cpu/ichss failed to register: 17 module_register: cannot register cpu/est from cpufreq.ko; already loaded = from kernel Module cpu/est failed to register: 17 module_register: cannot register cpu/hwpstate from cpufreq.ko; already = loaded from kernel Module cpu/hwpstate failed to register: 17 module_register: cannot register cpu/p4tcc from cpufreq.ko; already = loaded from kernel Module cpu/p4tcc failed to register: 17 module_register: cannot register cpu/powernow from cpufreq.ko; already = loaded from kernel Module cpu/powernow failed to register: 17 module_register: cannot register cpu/ichss from kernel; already loaded = from cpufreq.ko Module cpu/ichss failed to register: 17 module_register: cannot register cpu/powernow from kernel; already = loaded from cpufreq.ko Module cpu/powernow failed to register: 17 module_register: cannot register cpu/est from kernel; already loaded = from cpufreq.ko Module cpu/est failed to register: 17 module_register: cannot register cpu/hwpstate from kernel; already = loaded from cpufreq.ko Module cpu/hwpstate failed to register: 17 module_register: cannot register cpu/p4tcc from kernel; already loaded = from cpufreq.ko Module cpu/p4tcc failed to register: 17 cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu0: on acpi0 cpu1: on acpi0 <118>powerd: no cpufreq(4) support -- aborting: No such file or = directory module_register: cannot register cpu/ichss from kernel; already loaded = from cpufreq.ko Module cpu/ichss failed to register: 17 module_register: cannot register cpu/powernow from kernel; already = loaded from cpufreq.ko Module cpu/powernow failed to register: 17 module_register: cannot register cpu/est from kernel; already loaded = from cpufreq.ko Module cpu/est failed to register: 17 module_register: cannot register cpu/hwpstate from kernel; already = loaded from cpufreq.ko Module cpu/hwpstate failed to register: 17 module_register: cannot register cpu/p4tcc from kernel; already loaded = from cpufreq.ko Module cpu/p4tcc failed to register: 17 cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu0: on acpi0 cpu1: on acpi0 acpi_throttle0: on cpu0 acpi_throttle1: on cpu1 kern.ccpu: 0 0, 1 0, 1 kern.sched.cpusetsize: 8 kern.racct.pcpu_threshold: 1 cpu HAMMER device cpufreq net.inet.tcp.per_cpu_timers: 0 debug.cpufreq.verbose: 0 debug.cpufreq.lowest: 0 debug.acpi.cpu_unordered: 0 hw.ncpu: 2 hw.acpi.cpu.cx_lowest: C8 dev.cpufreq.0.%parent: cpu0 dev.cpufreq.0.%pnpinfo:=20 dev.cpufreq.0.%location:=20 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%desc:=20 dev.cpufreq.%parent:=20 dev.acpi_throttle.0.%parent: cpu0 dev.cpu.1.cx_usage: 100.00% last 155us dev.cpu.1.cx_lowest: C8 dev.cpu.1.cx_supported: C1/1/0 dev.cpu.1.temperature: 40.7C dev.cpu.1.%parent: acpi0 dev.cpu.1.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.1.%location: handle=3D\_PR_.P001 dev.cpu.1.%driver: cpu dev.cpu.1.%desc: ACPI CPU dev.cpu.0.cx_usage: 100.00% last 121us dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_supported: C1/1/0 dev.cpu.0.freq_levels: 3393/-1 2968/-1 2544/-1 2120/-1 1696/-1 1272/-1 = 848/-1 424/-1 dev.cpu.0.freq: 1272 dev.cpu.0.temperature: 40.7C dev.cpu.0.%parent: acpi0 dev.cpu.0.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.0.%location: handle=3D\_PR_.P000 dev.cpu.0.%driver: cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.%parent:=20 $ service powerd status powerd is not running. Case 2: #hint.acpi_throttle.0.disabled=3D"0" from /boot/device.hints $ sysctl -a | grep cpu kern.smp.cpus: 2 kern.smp.maxcpus: 64 <118>powerd: no cpufreq(4) support -- aborting: No such file or = directory cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu0: on acpi0 cpu1: on acpi0 <118>powerd: no cpufreq(4) support -- aborting: No such file or = directory cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu0: on acpi0 cpu1: on acpi0 <118>powerd: no cpufreq(4) support -- aborting: No such file or = directory cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu0: on acpi0 cpu1: on acpi0 <118>powerd: no cpufreq(4) support -- aborting: No such file or = directory cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu0: on acpi0 cpu1: on acpi0 <118>powerd: no cpufreq(4) support -- aborting: No such file or = directory module_register: cannot register cpu/ichss from cpufreq.ko; already = loaded from kernel Module cpu/ichss failed to register: 17 module_register: cannot register cpu/est from cpufreq.ko; already loaded = from kernel Module cpu/est failed to register: 17 module_register: cannot register cpu/hwpstate from cpufreq.ko; already = loaded from kernel Module cpu/hwpstate failed to register: 17 module_register: cannot register cpu/p4tcc from cpufreq.ko; already = loaded from kernel Module cpu/p4tcc failed to register: 17 module_register: cannot register cpu/powernow from cpufreq.ko; already = loaded from kernel Module cpu/powernow failed to register: 17 module_register: cannot register cpu/ichss from cpufreq.ko; already = loaded from kernel Module cpu/ichss failed to register: 17 module_register: cannot register cpu/est from cpufreq.ko; already loaded = from kernel Module cpu/est failed to register: 17 module_register: cannot register cpu/hwpstate from cpufreq.ko; already = loaded from kernel Module cpu/hwpstate failed to register: 17 module_register: cannot register cpu/p4tcc from cpufreq.ko; already = loaded from kernel Module cpu/p4tcc failed to register: 17 module_register: cannot register cpu/powernow from cpufreq.ko; already = loaded from kernel Module cpu/powernow failed to register: 17 module_register: cannot register cpu/ichss from kernel; already loaded = from cpufreq.ko Module cpu/ichss failed to register: 17 module_register: cannot register cpu/powernow from kernel; already = loaded from cpufreq.ko Module cpu/powernow failed to register: 17 module_register: cannot register cpu/est from kernel; already loaded = from cpufreq.ko Module cpu/est failed to register: 17 module_register: cannot register cpu/hwpstate from kernel; already = loaded from cpufreq.ko Module cpu/hwpstate failed to register: 17 module_register: cannot register cpu/p4tcc from kernel; already loaded = from cpufreq.ko Module cpu/p4tcc failed to register: 17 cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu0: on acpi0 cpu1: on acpi0 <118>powerd: no cpufreq(4) support -- aborting: No such file or = directory module_register: cannot register cpu/ichss from kernel; already loaded = from cpufreq.ko Module cpu/ichss failed to register: 17 module_register: cannot register cpu/powernow from kernel; already = loaded from cpufreq.ko Module cpu/powernow failed to register: 17 module_register: cannot register cpu/est from kernel; already loaded = from cpufreq.ko Module cpu/est failed to register: 17 module_register: cannot register cpu/hwpstate from kernel; already = loaded from cpufreq.ko Module cpu/hwpstate failed to register: 17 module_register: cannot register cpu/p4tcc from kernel; already loaded = from cpufreq.ko Module cpu/p4tcc failed to register: 17 cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu0: on acpi0 cpu1: on acpi0 acpi_throttle0: on cpu0 acpi_throttle1: on cpu1 module_register: cannot register cpu/ichss from kernel; already loaded = from cpufreq.ko Module cpu/ichss failed to register: 17 module_register: cannot register cpu/powernow from kernel; already = loaded from cpufreq.ko Module cpu/powernow failed to register: 17 module_register: cannot register cpu/est from kernel; already loaded = from cpufreq.ko Module cpu/est failed to register: 17 module_register: cannot register cpu/hwpstate from kernel; already = loaded from cpufreq.ko Module cpu/hwpstate failed to register: 17 module_register: cannot register cpu/p4tcc from kernel; already loaded = from cpufreq.ko Module cpu/p4tcc failed to register: 17 cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu0: on acpi0 cpu1: on acpi0 <118>powerd: no cpufreq(4) support -- aborting: No such file or = directory module_register: cannot register cpu/ichss from kernel; already loaded = from cpufreq.ko Module cpu/ichss failed to register: 17 module_register: cannot register cpu/powernow from kernel; already = loaded from cpufreq.ko Module cpu/powernow failed to register: 17 module_register: cannot register cpu/est from kernel; already loaded = from cpufreq.ko Module cpu/est failed to register: 17 module_register: cannot register cpu/hwpstate from kernel; already = loaded from cpufreq.ko Module cpu/hwpstate failed to register: 17 module_register: cannot register cpu/p4tcc from kernel; already loaded = from cpufreq.ko Module cpu/p4tcc failed to register: 17 cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu0: on acpi0 cpu1: on acpi0 acpi_throttle0: on cpu0 acpi_throttle1: on cpu1 kern.ccpu: 0 0, 1 0, 1 kern.sched.cpusetsize: 8 kern.racct.pcpu_threshold: 1 cpu HAMMER device cpufreq net.inet.tcp.per_cpu_timers: 0 debug.cpufreq.verbose: 0 debug.cpufreq.lowest: 0 debug.acpi.cpu_unordered: 0 hw.ncpu: 2 hw.acpi.cpu.cx_lowest: C8 dev.cpufreq.0.%parent: cpu0 dev.cpufreq.0.%pnpinfo:=20 dev.cpufreq.0.%location:=20 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%desc:=20 dev.cpufreq.%parent:=20 dev.acpi_throttle.0.%parent: cpu0 dev.cpu.1.cx_usage: 100.00% last 66us dev.cpu.1.cx_lowest: C8 dev.cpu.1.cx_supported: C1/1/0 dev.cpu.1.temperature: 42.0C dev.cpu.1.%parent: acpi0 dev.cpu.1.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.1.%location: handle=3D\_PR_.P001 dev.cpu.1.%driver: cpu dev.cpu.1.%desc: ACPI CPU dev.cpu.0.cx_usage: 100.00% last 1671us dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_supported: C1/1/0 dev.cpu.0.freq_levels: 3393/-1 2968/-1 2544/-1 2120/-1 1696/-1 1272/-1 = 848/-1 424/-1 dev.cpu.0.freq: 1696 dev.cpu.0.temperature: 42.0C dev.cpu.0.%parent: acpi0 dev.cpu.0.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.0.%location: handle=3D\_PR_.P000 dev.cpu.0.%driver: cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.%parent:=20 $ service powerd status powerd is not running.= From owner-freebsd-stable@freebsd.org Sun Nov 13 10:07:24 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD7B9C3D749 for ; Sun, 13 Nov 2016 10:07:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B3BD81ACA; Sun, 13 Nov 2016 10:07:23 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA00119; Sun, 13 Nov 2016 12:07:21 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1c5rh3-000B87-DN; Sun, 13 Nov 2016 12:07:21 +0200 Subject: Re: Freebsd 11.0 RELEASE - ZFS deadlock To: Henri Hennebert , freebsd-stable@FreeBSD.org References: <0c223160-b76f-c635-bb15-4a068ba7efe7@restart.be> <43c9d4d4-1995-5626-d70a-f92a5b456629@FreeBSD.org> <9d1f9a76-5a8d-6eca-9a50-907d55099847@FreeBSD.org> <6bc95dce-31e1-3013-bfe3-7c2dd80f9d1e@restart.be> <23a66749-f138-1f1a-afae-c775f906ff37@restart.be> <8e7547ef-87f7-7fab-6f45-221e8cea1989@FreeBSD.org> <6d991cea-b420-531e-12cc-001e4aeed66b@restart.be> <67f2e8bd-bff0-f808-7557-7dabe5cad78c@FreeBSD.org> <1cb09c54-5f0e-2259-a41a-fefe76b4fe8b@restart.be> <9f20020b-e2f1-862b-c3fc-dc6ff94e301e@restart.be> <599c5a5b-aa08-2030-34f3-23ff19d09a9b@restart.be> Cc: Konstantin Belousov From: Andriy Gapon Message-ID: <32686283-948a-6faf-7ded-ed8fcd23affb@FreeBSD.org> Date: Sun, 13 Nov 2016 12:06:00 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <599c5a5b-aa08-2030-34f3-23ff19d09a9b@restart.be> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 10:07:24 -0000 On 12/11/2016 14:40, Henri Hennebert wrote: > I attatch it Thank you! So, these two threads are trying to get the lock in the exclusive mode: Thread 687 (Thread 101243): #0 sched_switch (td=0xfffff800b642b500, newtd=0xfffff8000285ea00, flags=) at /usr/src/sys/kern/sched_ule.c:1973 #1 0xffffffff80561ae2 in mi_switch (flags=, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:455 #2 0xffffffff805ae8da in sleepq_wait (wchan=0x0, pri=0) at /usr/src/sys/kern/subr_sleepqueue.c:646 #3 0xffffffff8052f854 in sleeplk (lk=, flags=, ilk=, wmesg=0xffffffff813be535 "zfs", pri=, timo=51) at /usr/src/sys/kern/kern_lock.c:222 #4 0xffffffff8052f39d in __lockmgr_args (lk=, flags=, ilk=, wmesg=, pri=, timo=, file=, line=) at /usr/src/sys/kern/kern_lock.c:958 #5 0xffffffff80616a8c in vop_stdlock (ap=) at lockmgr.h:98 #6 0xffffffff8093784d in VOP_LOCK1_APV (vop=, a=) at vnode_if.c:2087 #7 0xffffffff8063c5b3 in _vn_lock (vp=, flags=548864, file=, line=) at vnode_if.h:859 #8 0xffffffff8062a5f7 in vget (vp=0xfffff80049c2c000, flags=548864, td=0xfffff800b642b500) at /usr/src/sys/kern/vfs_subr.c:2523 #9 0xffffffff806118b9 in cache_lookup (dvp=, vpp=, cnp=, tsp=, ticksp=) at /usr/src/sys/kern/vfs_cache.c:686 #10 0xffffffff806133dc in vfs_cache_lookup (ap=) at /usr/src/sys/kern/vfs_cache.c:1081 #11 0xffffffff80935777 in VOP_LOOKUP_APV (vop=, a=) at vnode_if.c:127 #12 0xffffffff8061cdf1 in lookup (ndp=) at vnode_if.h:54 #13 0xffffffff8061c492 in namei (ndp=) at /usr/src/sys/kern/vfs_lookup.c:306 #14 0xffffffff80509395 in kern_execve (td=, args=, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:443 #15 0xffffffff80508ccc in sys_execve (td=0xfffff800b642b500, uap=0xfffffe010182cb80) at /usr/src/sys/kern/kern_exec.c:218 #16 0xffffffff808d449e in amd64_syscall (td=, traced=0) at subr_syscall.c:135 #17 0xffffffff808b7ddb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:396 Thread 681 (Thread 101147): #0 sched_switch (td=0xfffff80065f4e500, newtd=0xfffff8000285f000, flags=) at /usr/src/sys/kern/sched_ule.c:1973 #1 0xffffffff80561ae2 in mi_switch (flags=, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:455 #2 0xffffffff805ae8da in sleepq_wait (wchan=0x0, pri=0) at /usr/src/sys/kern/subr_sleepqueue.c:646 #3 0xffffffff8052f854 in sleeplk (lk=, flags=, ilk=, wmesg=0xffffffff813be535 "zfs", pri=, timo=51) at /usr/src/sys/kern/kern_lock.c:222 #4 0xffffffff8052f39d in __lockmgr_args (lk=, flags=, ilk=, wmesg=, pri=, timo=, file=, line=) at /usr/src/sys/kern/kern_lock.c:958 #5 0xffffffff80616a8c in vop_stdlock (ap=) at lockmgr.h:98 #6 0xffffffff8093784d in VOP_LOCK1_APV (vop=, a=) at vnode_if.c:2087 #7 0xffffffff8063c5b3 in _vn_lock (vp=, flags=548864, file=, line=) at vnode_if.h:859 #8 0xffffffff8062a5f7 in vget (vp=0xfffff80049c2c000, flags=548864, td=0xfffff80065f4e500) at /usr/src/sys/kern/vfs_subr.c:2523 #9 0xffffffff806118b9 in cache_lookup (dvp=, vpp=, cnp=, tsp=, ticksp=) at /usr/src/sys/kern/vfs_cache.c:686 #10 0xffffffff806133dc in vfs_cache_lookup (ap=) at /usr/src/sys/kern/vfs_cache.c:1081 #11 0xffffffff80935777 in VOP_LOOKUP_APV (vop=, a=) at vnode_if.c:127 #12 0xffffffff8061cdf1 in lookup (ndp=) at vnode_if.h:54 #13 0xffffffff8061c492 in namei (ndp=) at /usr/src/sys/kern/vfs_lookup.c:306 #14 0xffffffff80509395 in kern_execve (td=, args=, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:443 #15 0xffffffff80508ccc in sys_execve (td=0xfffff80065f4e500, uap=0xfffffe01016b8b80) at /usr/src/sys/kern/kern_exec.c:218 #16 0xffffffff808d449e in amd64_syscall (td=, traced=0) at subr_syscall.c:135 #17 0xffffffff808b7ddb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:396 And the original stuck thread wants to get the lock in the shared mode. And there should be another thread that already holds the lock in the shared mode. But I am not able to identify it. I wonder if the original thread could be trying to get the lock recursively... It would be interesting to get more details from thread 101112. You can switch to it using tid command, you can use 'fr' to select frames, 'info local' and 'info args' to see what variables are available (not optimized out) and the you can print any that look interesting. It would be nice to get a file path and a directory vnode where the lookup is called. Thank you. -- Andriy Gapon From owner-freebsd-stable@freebsd.org Sun Nov 13 13:28:34 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B50AC3F19A for ; Sun, 13 Nov 2016 13:28:34 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [5.135.182.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8ED9A1908; Sun, 13 Nov 2016 13:28:32 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=2001:41d0:8:bdbe:1:1::; helo=restart.be; envelope-from=hlh@restart.be; receiver=avg@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3tGvc74cBhzsKf DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=restart.be; s=tignes; t=1479043703; bh=BqBt0XHNDre+RDvQQYIrpVYWSVePprVwWZC394LdmEQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To; z=Subject:=20Re:=20Freebsd=2011.0=20RELEASE=20-=20ZFS=20deadlock|To :=20Andriy=20Gapon=20,=20freebsd-stable@FreeBSD.o rg|References:=20<0c223160-b76f-c635-bb15-4a068ba7efe7@restart.be> =0D=0A=20=0D=0A= 20<43c9d4d4-1995-5626-d70a-f92a5b456629@FreeBSD.org>=0D=0A=20=0D=0A=20<9d1f9a76-5a8 d-6eca-9a50-907d55099847@FreeBSD.org>=0D=0A=20<6bc95dce-31e1-3013- bfe3-7c2dd80f9d1e@restart.be>=0D=0A=20=0D=0A=20<23a66749-f138-1f1a-afae-c775f906ff 37@restart.be>=0D=0A=20<8e7547ef-87f7-7fab-6f45-221e8cea1989@FreeB SD.org>=0D=0A=20<6d991cea-b420-531e-12cc-001e4aeed66b@restart.be>= 0D=0A=20<67f2e8bd-bff0-f808-7557-7dabe5cad78c@FreeBSD.org>=0D=0A=2 0<1cb09c54-5f0e-2259-a41a-fefe76b4fe8b@restart.be>=0D=0A=20=0D=0A=20<9f20020b-e2f1 -862b-c3fc-dc6ff94e301e@restart.be>=0D=0A=20=0D=0A=20<599c5a5b-aa08-2030-34f3-23ff 19d09a9b@restart.be>=0D=0A=20<32686283-948a-6faf-7ded-ed8fcd23affb @FreeBSD.org>|Cc:=20Konstantin=20Belousov=20|From :=20Henri=20Hennebert=20|Date:=20Sun,=2013=20Nov=2 02016=2014:28:20=20+0100|In-Reply-To:=20<32686283-948a-6faf-7ded-e d8fcd23affb@FreeBSD.org>; b=QaHDNfZ3qtgreXTBY7s/LqCZiKkJuLnqlIeElRS2VHQfxhnH4vuLb5cOHUnyyq7El /Dqvss1OfzCiu6ono5s+u8HpIUBcToA1w2FeuA0/ElBtCk8tRN9O1qGHPc9GjN2uYC Vw4oNyUBV0epkwU86xddCl7r5UpSf+levCv0GyUzM1/Wcm5cButd3zZ/QRRzhSPB81 N8bQOdZRXvoPkOnvE1T9Ld0wEJ73Ns+N3Otd0tmEW0zr7eMd5++Qh13W6Jzq6Uoxfz dEaTfx5QBbhBNZF6nCsFb2NbKLvM5TMsXRASJbLYBTWuCTMbgNel3QBRa1tESnvKsA sMm3SadtjXWKw== Received: from restart.be (avoriaz.restart.be [IPv6:2001:41d0:8:bdbe:1:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3tGvc74cBhzsKf; Sun, 13 Nov 2016 14:28:23 +0100 (CET) Received: from chamonix.restart.bel (chamonix.restart.bel [IPv6:2001:41d0:8:bdbe:1:9:0:0]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id uADDSKNg071397 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 13 Nov 2016 14:28:22 +0100 (CET) (envelope-from hlh@restart.be) Subject: Re: Freebsd 11.0 RELEASE - ZFS deadlock To: Andriy Gapon , freebsd-stable@FreeBSD.org References: <0c223160-b76f-c635-bb15-4a068ba7efe7@restart.be> <43c9d4d4-1995-5626-d70a-f92a5b456629@FreeBSD.org> <9d1f9a76-5a8d-6eca-9a50-907d55099847@FreeBSD.org> <6bc95dce-31e1-3013-bfe3-7c2dd80f9d1e@restart.be> <23a66749-f138-1f1a-afae-c775f906ff37@restart.be> <8e7547ef-87f7-7fab-6f45-221e8cea1989@FreeBSD.org> <6d991cea-b420-531e-12cc-001e4aeed66b@restart.be> <67f2e8bd-bff0-f808-7557-7dabe5cad78c@FreeBSD.org> <1cb09c54-5f0e-2259-a41a-fefe76b4fe8b@restart.be> <9f20020b-e2f1-862b-c3fc-dc6ff94e301e@restart.be> <599c5a5b-aa08-2030-34f3-23ff19d09a9b@restart.be> <32686283-948a-6faf-7ded-ed8fcd23affb@FreeBSD.org> Cc: Konstantin Belousov From: Henri Hennebert Message-ID: Date: Sun, 13 Nov 2016 14:28:20 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <32686283-948a-6faf-7ded-ed8fcd23affb@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 13:28:34 -0000 On 11/13/2016 11:06, Andriy Gapon wrote: > On 12/11/2016 14:40, Henri Hennebert wrote: >> I attatch it > > Thank you! > So, these two threads are trying to get the lock in the exclusive mode: > Thread 687 (Thread 101243): > #0 sched_switch (td=0xfffff800b642b500, newtd=0xfffff8000285ea00, flags= optimized out>) at /usr/src/sys/kern/sched_ule.c:1973 > #1 0xffffffff80561ae2 in mi_switch (flags=, newtd=0x0) at > /usr/src/sys/kern/kern_synch.c:455 > #2 0xffffffff805ae8da in sleepq_wait (wchan=0x0, pri=0) at > /usr/src/sys/kern/subr_sleepqueue.c:646 > #3 0xffffffff8052f854 in sleeplk (lk=, flags= optimized out>, ilk=, wmesg=0xffffffff813be535 "zfs", > pri=, timo=51) at /usr/src/sys/kern/kern_lock.c:222 > #4 0xffffffff8052f39d in __lockmgr_args (lk=, flags= optimized out>, ilk=, wmesg=, > pri=, timo=, file= out>, line=) at /usr/src/sys/kern/kern_lock.c:958 > #5 0xffffffff80616a8c in vop_stdlock (ap=) at lockmgr.h:98 > #6 0xffffffff8093784d in VOP_LOCK1_APV (vop=, a= optimized out>) at vnode_if.c:2087 > #7 0xffffffff8063c5b3 in _vn_lock (vp=, flags=548864, > file=, line=) at vnode_if.h:859 > #8 0xffffffff8062a5f7 in vget (vp=0xfffff80049c2c000, flags=548864, > td=0xfffff800b642b500) at /usr/src/sys/kern/vfs_subr.c:2523 > #9 0xffffffff806118b9 in cache_lookup (dvp=, vpp= optimized out>, cnp=, tsp=, > ticksp=) at /usr/src/sys/kern/vfs_cache.c:686 > #10 0xffffffff806133dc in vfs_cache_lookup (ap=) at > /usr/src/sys/kern/vfs_cache.c:1081 > #11 0xffffffff80935777 in VOP_LOOKUP_APV (vop=, a= optimized out>) at vnode_if.c:127 > #12 0xffffffff8061cdf1 in lookup (ndp=) at vnode_if.h:54 > #13 0xffffffff8061c492 in namei (ndp=) at > /usr/src/sys/kern/vfs_lookup.c:306 > #14 0xffffffff80509395 in kern_execve (td=, args= optimized out>, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:443 > #15 0xffffffff80508ccc in sys_execve (td=0xfffff800b642b500, > uap=0xfffffe010182cb80) at /usr/src/sys/kern/kern_exec.c:218 > #16 0xffffffff808d449e in amd64_syscall (td=, traced=0) at > subr_syscall.c:135 > #17 0xffffffff808b7ddb in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:396 > > Thread 681 (Thread 101147): > #0 sched_switch (td=0xfffff80065f4e500, newtd=0xfffff8000285f000, flags= optimized out>) at /usr/src/sys/kern/sched_ule.c:1973 > #1 0xffffffff80561ae2 in mi_switch (flags=, newtd=0x0) at > /usr/src/sys/kern/kern_synch.c:455 > #2 0xffffffff805ae8da in sleepq_wait (wchan=0x0, pri=0) at > /usr/src/sys/kern/subr_sleepqueue.c:646 > #3 0xffffffff8052f854 in sleeplk (lk=, flags= optimized out>, ilk=, wmesg=0xffffffff813be535 "zfs", > pri=, timo=51) at /usr/src/sys/kern/kern_lock.c:222 > #4 0xffffffff8052f39d in __lockmgr_args (lk=, flags= optimized out>, ilk=, wmesg=, > pri=, timo=, file= out>, line=) at /usr/src/sys/kern/kern_lock.c:958 > #5 0xffffffff80616a8c in vop_stdlock (ap=) at lockmgr.h:98 > #6 0xffffffff8093784d in VOP_LOCK1_APV (vop=, a= optimized out>) at vnode_if.c:2087 > #7 0xffffffff8063c5b3 in _vn_lock (vp=, flags=548864, > file=, line=) at vnode_if.h:859 > #8 0xffffffff8062a5f7 in vget (vp=0xfffff80049c2c000, flags=548864, > td=0xfffff80065f4e500) at /usr/src/sys/kern/vfs_subr.c:2523 > #9 0xffffffff806118b9 in cache_lookup (dvp=, vpp= optimized out>, cnp=, tsp=, > ticksp=) at /usr/src/sys/kern/vfs_cache.c:686 > #10 0xffffffff806133dc in vfs_cache_lookup (ap=) at > /usr/src/sys/kern/vfs_cache.c:1081 > #11 0xffffffff80935777 in VOP_LOOKUP_APV (vop=, a= optimized out>) at vnode_if.c:127 > #12 0xffffffff8061cdf1 in lookup (ndp=) at vnode_if.h:54 > #13 0xffffffff8061c492 in namei (ndp=) at > /usr/src/sys/kern/vfs_lookup.c:306 > #14 0xffffffff80509395 in kern_execve (td=, args= optimized out>, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:443 > #15 0xffffffff80508ccc in sys_execve (td=0xfffff80065f4e500, > uap=0xfffffe01016b8b80) at /usr/src/sys/kern/kern_exec.c:218 > #16 0xffffffff808d449e in amd64_syscall (td=, traced=0) at > subr_syscall.c:135 > #17 0xffffffff808b7ddb in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:396 This 2 threads are innd processes. In core.txt.4: 8 14789 29165 0 24 4 40040 6612 zfs DN - 0:00.00 [innd] 8 29165 1 0 20 0 42496 6888 select Ds - 0:01.33 [innd] 8 49778 29165 0 24 4 40040 6900 zfs DN - 0:00.00 [innd] 8 82034 29165 0 24 4 132 0 zfs DN - 0:00.00 [innd] the corresponding info treads are: 687 Thread 101243 (PID=49778: innd) sched_switch (td=0xfffff800b642b500, newtd=0xfffff8000285ea00, flags=) at /usr/src/sys/kern/sched_ule.c:1973 681 Thread 101147 (PID=14789: innd) sched_switch (td=0xfffff80065f4e500, newtd=0xfffff8000285f000, flags=) at /usr/src/sys/kern/sched_ule.c:1973 669 Thread 101250 (PID=82034: innd) sched_switch (td=0xfffff800b6429000, newtd=0xfffff8000285ea00, flags=) at /usr/src/sys/kern/sched_ule.c:1973 665 Thread 101262 (PID=29165: innd) sched_switch (td=0xfffff800b6b54a00, newtd=0xfffff8000285ea00, flags=) at /usr/src/sys/kern/sched_ule.c:1973 So your missing tread must be 101250: (kgdb) tid 101250 [Switching to thread 669 (Thread 101250)]#0 sched_switch (td=0xfffff800b6429000, newtd=0xfffff8000285ea00, flags=) at /usr/src/sys/kern/sched_ule.c:1973 1973 cpuid = PCPU_GET(cpuid); Current language: auto; currently minimal (kgdb) bt #0 sched_switch (td=0xfffff800b6429000, newtd=0xfffff8000285ea00, flags=) at /usr/src/sys/kern/sched_ule.c:1973 #1 0xffffffff80561ae2 in mi_switch (flags=, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:455 #2 0xffffffff805ae8da in sleepq_wait (wchan=0x0, pri=0) at /usr/src/sys/kern/subr_sleepqueue.c:646 #3 0xffffffff8052f854 in sleeplk (lk=, flags=, ilk=, wmesg=0xffffffff813be535 "zfs", pri=, timo=51) at /usr/src/sys/kern/kern_lock.c:222 #4 0xffffffff8052f39d in __lockmgr_args (lk=, flags=, ilk=, wmesg=, pri=, timo=, file=, line=) at /usr/src/sys/kern/kern_lock.c:958 #5 0xffffffff80616a8c in vop_stdlock (ap=) at lockmgr.h:98 #6 0xffffffff8093784d in VOP_LOCK1_APV (vop=, a=) at vnode_if.c:2087 #7 0xffffffff8063c5b3 in _vn_lock (vp=, flags=525312, file=, line=) at vnode_if.h:859 #8 0xffffffff804e16cf in exec_elf64_imgact (imgp=) at /usr/src/sys/kern/imgact_elf.c:899 #9 0xffffffff8050983d in kern_execve (td=, args=, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:602 #10 0xffffffff80508ccc in sys_execve (td=0xfffff800b6429000, uap=0xfffffe010184fb80) at /usr/src/sys/kern/kern_exec.c:218 #11 0xffffffff808d449e in amd64_syscall (td=, traced=0) at subr_syscall.c:135 #12 0xffffffff808b7ddb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:396 #13 0x000000080217edaa in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) > > And the original stuck thread wants to get the lock in the shared mode. > And there should be another thread that already holds the lock in the shared > mode. But I am not able to identify it. I wonder if the original thread could > be trying to get the lock recursively... > > It would be interesting to get more details from thread 101112. > You can switch to it using tid command, you can use 'fr' to select frames, 'info > local' and 'info args' to see what variables are available (not optimized out) > and the you can print any that look interesting. It would be nice to get a file > path and a directory vnode where the lookup is called. > > Thank you. > I find nothing interresting: (kgdb) fr 15 #15 0xffffffff806369cc in sys_fstatat (td=0x0, uap=0xfffffe010161db80) at /usr/src/sys/kern/vfs_syscalls.c:2136 2136 error = kern_statat(td, uap->flag, uap->fd, uap->path, (kgdb) print *uap $1 = {fd_l_ = 0xfffffe010161db80 "\234ÿÿÿ", fd = -100, fd_r_ = 0xfffffe010161db84 "", path_l_ = 0xfffffe010161db88 "\210£â", path = 0x800e2a388
, path_r_ = 0xfffffe010161db90 "\020£â", buf_l_ = 0xfffffe010161db90 "\020£â", buf = 0x800e2a310, buf_r_ = 0xfffffe010161db98 "", flag_l_ = 0xfffffe010161db98 "", flag = 512, flag_r_ = 0xfffffe010161db9c ""} (kgdb) print $1->path $2 = 0x800e2a388
(kgdb) fr 8 #8 0xffffffff8062a5f7 in vget (vp=0xfffff80049c2c000, flags=2121728, td=0xfffff80009ba0500) at /usr/src/sys/kern/vfs_subr.c:2523 2523 if ((error = vn_lock(vp, flags)) != 0) { (kgdb) print *vp $3 = {v_tag = 0xffffffff813be535 "zfs", v_op = 0xffffffff813d0f70, v_data = 0xfffff80049c1f420, v_mount = 0xfffff800093aa660, v_nmntvnodes = {tqe_next = 0xfffff80049c2c938, tqe_prev = 0xfffff80049c2bb30}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_cache_src = {lh_first = 0x0}, v_cache_dst = { tqh_first = 0xfffff800bfc8e3f0, tqh_last = 0xfffff800bfc8e410}, v_cache_dd = 0x0, v_lock = {lock_object = { lo_name = 0xffffffff813be535 "zfs", lo_flags = 117112832, lo_data = 0, lo_witness = 0x0}, lk_lock = 23, lk_exslpfail = 0, lk_timo = 51, lk_pri = 96}, v_interlock = {lock_object = {lo_name = 0xffffffff8099e9e0 "vnode interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, v_vnlock = 0xfffff80049c2c068, v_actfreelist = { tqe_next = 0xfffff80049c2c938, tqe_prev = 0xfffff80049ae9bd0}, v_bufobj = {bo_lock = {lock_object = { lo_name = 0xffffffff8099e9f0 "bufobj interlock", lo_flags = 86179840, lo_data = 0, lo_witness = 0x0}, rw_lock = 1}, bo_ops = 0xffffffff80c4bf70, bo_object = 0xfffff800b62e9c60, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0xfffff80049c2c000, __bo_vnode = 0xfffff80049c2c000, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffff80049c2c120}, bv_root = {pt_root = 0}, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffff80049c2c140}, bv_root = {pt_root = 0}, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_bsize = 131072}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0, v_rl = {rl_waiters = {tqh_first = 0x0, tqh_last = 0xfffff80049c2c188}, rl_currdep = 0x0}, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_holdcnt = 10, v_usecount = 6, v_iflag = 512, v_vflag = 32, v_writecount = 0, v_hash = 4833984, v_type = VREG} (kgdb) I also try to get information from the execve of the other treads: for tid 101250: (kgdb) fr 10 #10 0xffffffff80508ccc in sys_execve (td=0xfffff800b6429000, uap=0xfffffe010184fb80) at /usr/src/sys/kern/kern_exec.c:218 218 error = kern_execve(td, &args, NULL); (kgdb) print *uap $4 = {fname_l_ = 0xfffffe010184fb80 "`\220\217\002\b", fname = 0x8028f9060
, fname_r_ = 0xfffffe010184fb88 "`¶ÿÿÿ\177", argv_l_ = 0xfffffe010184fb88 "`¶ÿÿÿ\177", argv = 0x7fffffffb660, argv_r_ = 0xfffffe010184fb90 "\bÜÿÿÿ\177", envv_l_ = 0xfffffe010184fb90 "\bÜÿÿÿ\177", envv = 0x7fffffffdc08, envv_r_ = 0xfffffe010184fb98 ""} (kgdb) for tid 101243: (kgdb) f 15 #15 0xffffffff80508ccc in sys_execve (td=0xfffff800b642b500, uap=0xfffffe010182cb80) at /usr/src/sys/kern/kern_exec.c:218 218 error = kern_execve(td, &args, NULL); (kgdb) print *uap $5 = {fname_l_ = 0xfffffe010182cb80 "ÀÏ\205\002\b", fname = 0x80285cfc0
, fname_r_ = 0xfffffe010182cb88 "`¶ÿÿÿ\177", argv_l_ = 0xfffffe010182cb88 "`¶ÿÿÿ\177", argv = 0x7fffffffb660, argv_r_ = 0xfffffe010182cb90 "\bÜÿÿÿ\177", envv_l_ = 0xfffffe010182cb90 "\bÜÿÿÿ\177", envv = 0x7fffffffdc08, envv_r_ = 0xfffffe010182cb98 ""} (kgdb) Henri From owner-freebsd-stable@freebsd.org Sun Nov 13 13:47:08 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB816C3F76D for ; Sun, 13 Nov 2016 13:47:08 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:8:bdbe:0:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8AD41122F; Sun, 13 Nov 2016 13:47:08 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=2001:41d0:8:bdbe:1:1::; helo=restart.be; envelope-from=hlh@restart.be; receiver=avg@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3tGw1k2Vb7zrFy DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=restart.be; s=tignes; t=1479044826; bh=/Rv38RicVY98+P3PJTt1EVE41CazKZ4MpViWO3Ih4vw=; h=Subject:To:References:Cc:From:Date:In-Reply-To; z=Subject:=20Re:=20Freebsd=2011.0=20RELEASE=20-=20ZFS=20deadlock|To :=20Andriy=20Gapon=20,=20freebsd-stable@FreeBSD.o rg|References:=20<0c223160-b76f-c635-bb15-4a068ba7efe7@restart.be> =0D=0A=20=0D=0A= 20<43c9d4d4-1995-5626-d70a-f92a5b456629@FreeBSD.org>=0D=0A=20=0D=0A=20<9d1f9a76-5a8 d-6eca-9a50-907d55099847@FreeBSD.org>=0D=0A=20<6bc95dce-31e1-3013- bfe3-7c2dd80f9d1e@restart.be>=0D=0A=20=0D=0A=20<23a66749-f138-1f1a-afae-c775f906ff 37@restart.be>=0D=0A=20<8e7547ef-87f7-7fab-6f45-221e8cea1989@FreeB SD.org>=0D=0A=20<6d991cea-b420-531e-12cc-001e4aeed66b@restart.be>= 0D=0A=20<67f2e8bd-bff0-f808-7557-7dabe5cad78c@FreeBSD.org>=0D=0A=2 0<1cb09c54-5f0e-2259-a41a-fefe76b4fe8b@restart.be>=0D=0A=20=0D=0A=20<9f20020b-e2f1 -862b-c3fc-dc6ff94e301e@restart.be>=0D=0A=20=0D=0A=20<599c5a5b-aa08-2030-34f3-23ff 19d09a9b@restart.be>=0D=0A=20<32686283-948a-6faf-7ded-ed8fcd23affb @FreeBSD.org>=0D=0A=20|Cc:=20Konstantin=20Belousov=20|From:=20Henr i=20Hennebert=20|Date:=20Sun,=2013=20Nov=202016=20 14:47:04=20+0100|In-Reply-To:=20; b=jvKaTxb4z3PxDiZaeR9NW6/2d3WFolAcBb5DqiN8Nsna6nfwbHPun/DgrRLFgWEV/ q7HZk5zypbSnvjXC5Q9893D3EINnwE33c6JQT3MrT3F6xWMkMB31OG1MqgGsewnKBo gSmEjsiDlbP7jdqeT7ffd5O0In0q6jrWJGRZykn8eBLTJADXMJlEbAv0ONTeQ6aapi JJMjJCsxPEd95eeVrrW+teA2fWtHt+F5gnEMbsInCfKZJ1dCyA3biGANOBnrLqONkr qthMDUlkYqfaBKa+RnRtNun5AmF9KY2cKY0fiPX8imBjQ82cTOYztSKHcG8qPUMsv/ OyAa430K/DvhA== Received: from restart.be (avoriaz.restart.be [IPv6:2001:41d0:8:bdbe:1:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3tGw1k2Vb7zrFy; Sun, 13 Nov 2016 14:47:05 +0100 (CET) Received: from chamonix.restart.bel (chamonix.restart.bel [IPv6:2001:41d0:8:bdbe:1:9:0:0]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id uADDl4gQ071938 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 13 Nov 2016 14:47:05 +0100 (CET) (envelope-from hlh@restart.be) Subject: Re: Freebsd 11.0 RELEASE - ZFS deadlock To: Andriy Gapon , freebsd-stable@FreeBSD.org References: <0c223160-b76f-c635-bb15-4a068ba7efe7@restart.be> <43c9d4d4-1995-5626-d70a-f92a5b456629@FreeBSD.org> <9d1f9a76-5a8d-6eca-9a50-907d55099847@FreeBSD.org> <6bc95dce-31e1-3013-bfe3-7c2dd80f9d1e@restart.be> <23a66749-f138-1f1a-afae-c775f906ff37@restart.be> <8e7547ef-87f7-7fab-6f45-221e8cea1989@FreeBSD.org> <6d991cea-b420-531e-12cc-001e4aeed66b@restart.be> <67f2e8bd-bff0-f808-7557-7dabe5cad78c@FreeBSD.org> <1cb09c54-5f0e-2259-a41a-fefe76b4fe8b@restart.be> <9f20020b-e2f1-862b-c3fc-dc6ff94e301e@restart.be> <599c5a5b-aa08-2030-34f3-23ff19d09a9b@restart.be> <32686283-948a-6faf-7ded-ed8fcd23affb@FreeBSD.org> Cc: Konstantin Belousov From: Henri Hennebert Message-ID: Date: Sun, 13 Nov 2016 14:47:04 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 13:47:09 -0000 On 11/13/2016 14:28, Henri Hennebert wrote: > This 2 threads are innd processes. In core.txt.4: > > 8 14789 29165 0 24 4 40040 6612 zfs DN - 0:00.00 [innd] > 8 29165 1 0 20 0 42496 6888 select Ds - 0:01.33 [innd] > 8 49778 29165 0 24 4 40040 6900 zfs DN - 0:00.00 [innd] > 8 82034 29165 0 24 4 132 0 zfs DN - 0:00.00 [innd] > > the corresponding info treads are: > > 687 Thread 101243 (PID=49778: innd) sched_switch > (td=0xfffff800b642b500, newtd=0xfffff8000285ea00, flags= out>) at /usr/src/sys/kern/sched_ule.c:1973 > 681 Thread 101147 (PID=14789: innd) sched_switch > (td=0xfffff80065f4e500, newtd=0xfffff8000285f000, flags= out>) at /usr/src/sys/kern/sched_ule.c:1973 > 669 Thread 101250 (PID=82034: innd) sched_switch > (td=0xfffff800b6429000, newtd=0xfffff8000285ea00, flags= out>) at /usr/src/sys/kern/sched_ule.c:1973 > 665 Thread 101262 (PID=29165: innd) sched_switch > (td=0xfffff800b6b54a00, newtd=0xfffff8000285ea00, flags= out>) at /usr/src/sys/kern/sched_ule.c:1973 > In case it may help, I have a look at innd. This processes use 2 execv: one to execute /bin/sh and the other to execute itself: /* ** Re-exec ourselves. */ static const char * CCxexec(char *av[]) { char *innd; char *p; int i; if (CCargv == NULL) return "1 no argv!"; innd = concatpath(innconf->pathbin, "innd"); /* Get the pathname. */ p = av[0]; if (*p == '\0' || strcmp(p, "innd") == 0) CCargv[0] = innd; else return "1 Bad value"; #ifdef DO_PERL PLmode(Mode, OMshutdown, av[0]); #endif #ifdef DO_PYTHON PYmode(Mode, OMshutdown, av[0]); #endif JustCleanup(); syslog(L_NOTICE, "%s execv %s", LogName, CCargv[0]); /* Close all fds to protect possible fd leaking accross successive innds. */ for (i=3; i<30; i++) close(i); execv(CCargv[0], CCargv); syslog(L_FATAL, "%s cant execv %s %m", LogName, CCargv[0]); _exit(1); /* NOTREACHED */ return "1 Exit failed"; } The culprit may be /usr/local/news/bin/innd, remember that find is locked in /usr/local/news/bin Henri From owner-freebsd-stable@freebsd.org Mon Nov 14 01:20:25 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73208C3E56E; Mon, 14 Nov 2016 01:20:25 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 7E0211160; Mon, 14 Nov 2016 01:20:24 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190d-d7bff70000005395-75-5829114fda6b Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 45.25.21397.F4119285; Sun, 13 Nov 2016 20:20:16 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id uAE1KETu019849; Sun, 13 Nov 2016 20:20:15 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uAE1KAkl026681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 13 Nov 2016 20:20:13 -0500 Date: Sun, 13 Nov 2016 19:20:10 -0600 From: Benjamin Kaduk To: freebsd-announce@FreeBSD.org Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: FreeBSD Quarterly Status Report - Third Quarter 2016 Message-ID: <20161114012009.GA86797@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCKsWRmVeSWpSXmKPExsUixCmqrBsgqBlh0LOQzWLXtdPsFl8PT2C1 mPPmA5PF4WYhBxaPGZ/mswQwRnHZpKTmZJalFunbJXBldB45zl5w7D9zRWfvRZYGxlf9zF2M nBwSAiYSLVveAtlcHEICbUwS51ffYoRwNjJKNK54zwThXGWSuN63nQ2khUVAVeLzm39gNpuA msT6FdfARokIKEi09K9lArGZBawl/j1oBIpzcAgL2Eose+sMEuYF2nb0/TtGCFtQ4uTMJywQ 5ToSO7feYQMpZxaQllj+jwMiLC/RvHU22HRRAWWJhhkPmCcw8s9C0j0LSfcshO5ZSLoXMLKs YpRNya3SzU3MzClOTdYtTk7My0st0jXSy80s0UtNKd3ECA5YSd4djP/ueh1iFOBgVOLhfVCo ESHEmlhWXJl7iFGSg0lJlPesOVCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO8BZs0IId6UxMqq 1KJ8mJQ0B4uSOO9/t6/hQgLpiSWp2ampBalFMFkZDg4lCd43/ECNgkWp6akVaZk5JQhpJg5O kOE8QMNfgtTwFhck5hZnpkPkTzG6csw78fwBE8ebXS+B5JQ/H4HktNmfgOSnM18eMAmx5OXn pUqJ8z4EuUwApDmjNA9uPigxSWTvr3nFKA70rjBviABQFQ8wqcFteAW0nAlo+S6Qr3mLSxIR UlINjKVibwrfrL79TKhUVNXFzXLW4VN+/rLPPqpObju9Q99J5tD8S1d+ptgLct+ZaaVlrv15 wbZjW18/XijHb2M36/qlNe4OJzOC2g77NndZPS/5+vrZEYfPUy5KPJobUjJthwJbkOGuRyeN PK1dPKsMg1emHZDtj4g5YL30r8SZQK0z64zWbwmcd1qJpTgj0VCLuag4EQCMllRFJwMAAA== X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 01:20:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 FreeBSD Project Quarterly Status Report - 3rd Quarter 2016 As focused as we are on the present and what is happening now, it is sometimes useful to take a fresh look at where we have come from, and where we are going. This quarter, we had our newest doc committer working to trace through the tangled history of many utilities, and we also get a glimpse looking forward at what may come in FreeBSD 12. Though 11.0-RELEASE was not finalized until after the period covered in this report, we can still have some anticipatory excitement for the features that will be coming in 12.0. The possibilities are tantalizing: a base system with no GPL components, arm64 as a Tier-1 architecture, capsicum protection for common utilities, and the CloudABI for custom software are just a few. The work of the present is no less exciting, with 11.0 making its way out just after the end of Q3, the new core coming into its own, and much more that you'll have to read and find out. --Benjamin Kaduk __________________________________________________________________ Please submit status reports for the fourth quarter of 2016 by January 7. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Release Engineering Team * Ports Collection * The FreeBSD Core Team * The FreeBSD Foundation Projects * Capsicum Update * ClonOS: New FreeBSD-Based Free/Open Hosting Platform * CloudABI: Running Untrusted Programs Directly on top of FreeBSD * Improvements to Non-Transparent Bridge Subsystem * The Graphics Stack on FreeBSD * Using lld, the LLVM Linker, to Link FreeBSD * VirtualBox Shared Folders Filesystem * ZFS Code Sync with Latest OpenZFS/Illumos Kernel * evdev Support * FreeBSD Driver for the Annapurna Labs ENA * FreeBSD on Hyper-V and Azure * Timekeeping Code Improvements Google Summer of Code * Google Summer of Code 2016 * Non-BSM to BSM Conversion Tools * ptnet Driver and bhyve Device Model Architectures * FreeBSD on Annapurna Labs Alpine * FreeBSD on Marvell Armada38x * FreeBSD/arm64 * UEFI Runtime Services Ports * KDE on FreeBSD * LXQt on FreeBSD * Xfce on FreeBSD Documentation * Documenting the History of Utilities in /bin and /sbin __________________________________________________________________ FreeBSD Team Reports FreeBSD Release Engineering Team Links FreeBSD 11.0-RELEASE schedule URL: https://www.FreeBSD.org/releases/11.0R/schedule.html 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 Release Engineering Team continued the 11.0-RELEASE cycle which was planned to be released in September, but as a result of several last-minute issues, the final release announcement was delayed. This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ Ports Collection Links FreeBSD Ports Website URL: https://www.FreeBSD.org/ports/ How to Contribute URL: https://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing/ports-contributing.html Ports Monitoring Website URL: http://portsmon.FreeBSD.org/index.html Ports Management Team Website URL: https://www.FreeBSD.org/portmgr/index.html Ports Management Team on Twitter URL: https://twitter.com/FreeBSD_portmgr/ Ports Management Team on Facebook URL: https://www.facebook.com/portmgr Ports Management Team on Google+ URL: https://plus.google.com/communities/108335846196454338383 Contact: Ren Ladan Contact: FreeBSD Ports Management Team The Ports Tree currently contains over 26,300 ports, with the PR count around 2,150. Of these PRs, 516 are unassigned. The last quarter saw 5,295 commits by 117 active committers. Compared to the preceding quarter, there is both a slight increase in the number of PRs and the number of unassigned PRs, and a slight decrease in the number of committers. In the last quarter, four commits bits were taken in for safe keeping: erwin, miwi, and sem left by their own request and jase was inactive for more than 18 months. We welcomed two new committers: Tobias Berner (tcberner) and Joseph Mingrone (jrm). On the management side, erwin and miwi left portmgr. bapt also left portmgr but is still the liaison for core. On the infrastructure side, three new USES (grantlee, kde, linux) and one new Keyword (javavm) were introduced. The default version of the Linux ports is now CentOS 6, with the Fedora 10 ports scheduled for removal at the end of the year. The license framework has been extended with a NONE license to indicate that a port has no clearly defined licensing terms. For those ports, no packages or distribution files are distributed. Also, support for the complete set of Creative Commons licenses has been added. Some major user-visible ports were updated: Firefox to 49.0 and Firefox Extended Service Release to 45.4.0; Chromium to 52.0.2743.116; the default version of gcc to 4.8.5; and pkg itself to 1.8.7. Behind the scenes, antoine ran 24 exp-runs to validate various package updates, framework changes, and changes to the base system. bdrewery added two new package building machines, supervised the package builds for 11.0-RELEASE, and added support for building arm64 packages. At EuroBSDcon, rene visited a presentation by Landry Breuil explaining how packages are built in the OpenBSD world and explaining various design decisions. Open tasks: 1. If you have some spare time, please take up a PR for testing and committing. __________________________________________________________________ The FreeBSD Core Team Contact: FreeBSD Core Team The third quarter started with the handover to the ninth Core team as it took office. With four members returning from the previous core (Baptiste Daroussin, Ed Maste, George Neville-Neil and Hiroki Sato), one returning member after a term away (John Baldwin), and four members new to core (Allan Jude, Kris Moore, Benedict Reuschling and Benno Rice), the new core team represents just about the ideal balance between experience and fresh blood. Beyond handing over all of the ongoing business, reviewing everything on Core's agenda, and other routine changeover activities, the first action of the new core was to respond to a query from Craig Rodrigues concerning how hardware supplied to the project through donations to the FreeBSD Foundation was being used. The Foundation does keep records of what hardware has been supplied over time and has some idea of the original purpose that hardware was provisioned for, but does not track the current usage of the project's hardware assets. Cluster administration keeps their own configuration database, but this is not suitable for general publication and covers much more than Foundation supplied equipment. After some discussion it was decided that updated information about the current disposition of Foundation supplied equipment should be incorporated in the Foundation's annual report. Ensuring that all of the FreeBSD code base is supplied under open and unencumbered licensing terms and that we do not infringe on patent terms or otherwise act counter to any legal requirements are some of Core's primary concerns. During this quarter, there were three items of this nature. * Importing Concurrency Kit. In consultation with the Foundation's legal counsel, it was determined that importing selected parts of concurrency kit is acceptable, and has been approved. * The proposal to create a shadow GPLv3 toolchain repository was put to the community. Ultimately the whole idea has been rendered largely redundant by faster than anticipated progress on the external toolchain ports and packages for those architectures where LLVM is not yet sufficiently mature. * Concerns were raised about handling GPL code in work in progress on the linuxkpi shim. This issue is not related to the FreeBSD svn repository but Core would like to stress that care must be taken to avoid license infringement and plans to write a set of guidelines for handling GPL code. The item that has absorbed the largest portion of Core's attention this quarter concerns the project's handling of security vulnerabilities in bspatch(1), libarchive(3), freebsd-update(8) and portsnap(8). A partial fix was applied in FreeBSD-SA-16:25.bspatch but this lacks fixes to libarchive code that were not yet available from upstream. SecTeam receives privileged early reports of many vulnerabilities and consequently has a strict policy of not commenting publicly until an advisory and patches have been published. Early access to information about vulnerabilities is contingent on their ability to avoid premature disclosure, and without such, they could not have security advisories and patches ready to go immediately when a vulnerability is published. However, in this case, vulnerabilities were already public and the lack of any official response from the FreeBSD Project was leading to concern amongst users and some critical press coverage. Core stepped in and published a statement clarifying the situation and the particular difficulties involved in securely modifying the mechanisms used to deliver security patches. Core believes that prompt notification and discussion of the implications and possible workarounds to any public vulnerability should not wait on the availability of formal OS patches. The OpenSSH project has deprecated DSA keys upstream. FreeBSD had kept DSA keys enabled in the later 10.x releases for compatibility reasons, but with the release of 11.0 the time has come to synchronize again with upstream. Since there are numerous DSA keys in use in the FreeBSD cluster, this necessitated an exercise to get replacement keys installed. Core would like to thank David Wolfskill and the accounts team for handling the surge in key changes with a great deal of aplomb. During this quarter we welcomed Michael Zhilin, Imre Vadasz, Steve Kiernan and Toomas Soome as new source committers. Over the same period, we said farewell to Martin Wilke and Erwin Lansing who have handed in their commit bits. We wish them well in their future endeavours and hope to see them return as soon as they can. __________________________________________________________________ The FreeBSD Foundation Links FreeBSD Foundation Website URL: https://www.FreeBSDFoundation.org/ 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. Funding comes from individual and corporate donations and is used to fund and manage software development projects, conferences and developer summits, and provide travel grants to FreeBSD contributors. The Foundation purchases hardware to improve and maintain FreeBSD infrastructure and publishes FreeBSD white papers and marketing material to promote, educate, and advocate for the FreeBSD Project. The Foundation also represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Here are some highlights of what we did to help FreeBSD last quarter: Fundraising Efforts Our work is 100% funded by your donations. Our spending budget for 2016 is $1,250,000 and we have raised $271,500 so far. Our Q1-Q3 financial reports will be posted in early November. As you can see, we need your donations to continue supporting FreeBSD at our current level. Please consider making a donation at https://www.FreeBSDFoundation.org/donate/ . OS Improvements The Foundation improves FreeBSD by funding software development projects approved through our proposal submission process, and our internal software developer staff members. Two Foundation-funded projects continued last quarter: one project is to port NetBSD's blacklistd daemon and related elements to FreeBSD, and the second is phase two of the FreeBSD/arm64 port. Foundation staff members were responsible for many changes over the quarter. Kostik Belousov accomplished this work last quarter: * Provided kernel support for EFI Runtime Services calls * Implemented gettimeofday(2) purely in userspace for HPET timers * Implemented fdatasync(2) * Improved the locking of the time keeping code * Made the sleepqueue code immune to rapid callout changes * Made many stability fixes, the most important of which were UFS issues and an i386 bug * Improved the process management and ptrace code Ed Maste, our Project Development Director, accomplished this work last quarter: * Worked on FreeBSD/arm64 issues and Cavium ThunderX deployment (including RMAs) * Worked with upstream developers to test works in progress and prepare LLD as the replacement linker in the FreeBSD base system * Switched to using LLVM's libunwind in the base system * Improved the reproducibility of builds in the FreeBSD base system and ports * Reviewed the blacklistd work that is in progress * Attended BSDCam 2016, with a primary focus on toolchain discussions * Participated in ongoing Capsicum calls, and helped with the Capsicumization of several base system utilities * Fixed a number of ELF Tool Chain issues, and integrated a new upstream version into the FreeBSD base system * Hosted biweekly graphics calls to coordinate work in progress by funded and volunteer developers * Implemented fixes for security issues in some FreeBSD update tools, and coordinated their integration into the stable and release branches George Neville-Neil continued hosting a bi-weekly Transport conference call (notes at https://wiki.FreeBSD.org/TransportProtocols) and the bi-weekly DTrace conference call (notes at https://wiki.FreeBSD.org/DTrace). Release Engineering Foundation staff member Glen Barber worked with the Release Engineering team to continue finalizing the 11.0-RELEASE cycle, which was delayed to address several last-minute issues. As part of the Cluster Administration team, Glen worked with the amazing on-site staff at NYI to rack and install two Cavium ThunderX machines, one of which is used for native package builds for the FreeBSD/arm64 architecture, and the other of which is targeted to be used as a reference machine in the FreeBSD infrastructure. Getting Started with FreeBSD Project We hired a summer intern, with no experience on FreeBSD, Linux, or any command-line operating system, to figure out on his own how to install and use FreeBSD. He wrote easy-to-follow how-to guides to help make the new-user experience straightforward and positive. He submitted bug reports and reported issues through the appropriate channels, and worked with Glen Barber and Brad Davis to improve the new user information on FreeBSD.org to make it easier for new people to get started with FreeBSD. You can find his how-to guides at https://www.FreeBSDFoundation.org/FreeBSD/how-to-guides/ and check out his interview on BSDNow at http://www.bsdnow.tv/episodes/2016_08_24-the_fresh_bsd_experience . Supporting FreeBSD Infrastructure We provide hardware and support for FreeBSD infrastructure. Last quarter we purchased and brought up two 48-core Cavium ThunderX machines to build FreeBSD package sets for the arm64 platform. We also purchased more servers to help with continuous integration efforts. FreeBSD Advocacy and Education A large part of our efforts are dedicated to advocating for the Project. This includes promoting work being done by others using FreeBSD, producing advocacy literature to teach people about FreeBSD and ease the path to starting out with FreeBSD, contributing to the Project, and attending and getting other FreeBSD contributors to volunteer to run FreeBSD events, staff FreeBSD tables, and give FreeBSD presentations. We created new handouts to promote TeachBSD.org (https://www.FreeBSDFoundation.org/wp-content/uploads/2016/08/TeachBSD_half_final.pdf) and the Google Summer of Code program (https://www.FreeBSDFoundation.org/wp-content/uploads/2016/08/GSOC-flyerv2.pdf). We published the July/August issue of the FreeBSD Journal: https://www.FreeBSDFoundation.org/past-issues/FreeBSD-and-rtems/ . We also published monthly newsletters to highlight work being done to support FreeBSD, tell you about upcoming events, and provide other information to keep you in the loop of what we are doing to support the FreeBSD Project and community: https://www.FreeBSDFoundation.org/news-and-events/newsletter/ . Conferences and Events The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, to work together on projects, and facilitate collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness about FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. This quarter, we sponsored and/or attended the following events: * Texas Linux Fest, July 8-9, 2016, Austin, TX (http://2016.texaslinuxfest.org/) * The Eleventh HOPE, July 22-24, 2016, New York, NY (https://hope.net/index.html) * BSDCam 2016, August 15-17, 2016, Cambridge, UK (sponsor, organizer, and participated) (https://wiki.FreeBSD.org/DevSummit/201608) * FOSSCON 2016, August 20, 2016, Philadelphia, PA (https://fosscon.us/) * womENcourage 2016, September 12-13, 2016, Linz, Austria (Silver Sponsor) (http://womencourage.acm.org) * SNIA Storage Developer Conference 2016, September 19-22, 2016, Santa Clara, CA (Industry Partner Sponsor) (http://www.snia.org/events/storage-developer) * EuroBSDcon 2016 and FreeBSD Developer Summit, September 22-25, 2016, Belgrade, Serbia (Silver Sponsor) (https://2016.eurobsdcon.org/) Our EuroBSDcon involvement included: + Held a Women in Tech BoF in partnership with ACM-W Europe + Benedict organized the EuroBSDcon Developer Summit + Deb gave a Foundation Update talk and Hiroki Sato and Benedict Reuschling joined her for a Q&A session. + Kirk McKusick taught his two-day FreeBSD tutorial (https://2016.eurobsdcon.org/speakers/#kirkmckusick) + George Neville-Neil taught a tutorial on Tracing FreeBSD for DevOps and Developers (https://2016.eurobsdcon.org/speakers/#georgenevilleneil) + George also gave the Keynote talk, titled The Coming Decades of BSD + Phillip Paeps was one of the primary organizers for this conference. * OpenZFS Developer Summit 2016, September 26-27, 2016, San Francisco, CA (Silver) (http://open-zfs.org/wiki/OpenZFS_Developer_Summit) + Justin Gibbs gave a talk on Fault Management (http://open-zfs.org/wiki/Fault_Management) We sponsored three FreeBSD contributors to attend EuroBSDcon. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We continued to review requests and grant permission to use the trademarks. FreeBSD Community Engagement Anne Dickison, our Marketing Director, has been overseeing the efforts to rewrite the Project's Code of Conduct to help make this a safe, inclusive, and welcoming community. Other Stuff We Did We welcomed Kylie Liang and Philip Paeps to the Board of Directors. More information and interviews can be found at: https://www.FreeBSDFoundation.org/blog/FreeBSD-foundation-welcomes-new-board-members/ . George attended the ARM Partner Meeting in Cambridge. __________________________________________________________________ Projects Capsicum Update Links Capsicum Wiki Page URL: https://wiki.FreeBSD.org/Capsicum Contact: Allan Jude Contact: Baptiste Daroussin Contact: Conrad Meyer Contact: Ed Maste Contact: Mariusz Zaborski Several developers have undertaken a recent effort to sandbox additional applications in the base system. This work is proceeding nicely and one of the goals is to target basic utilities used in security sensitive applications, like freebsd-update and portsnap. This work higlighted two longstanding challenges in applying Capsicum. First, there are a number of common constructs shared by many simple programs, such as limiting capability rights on the stdio file descriptors. To address this, a set of capsicum helper routines has been added for these common cases. Second, a common challenge occurs where applications need to open an arbitrarily large number of files, possibly from various directories, where preopening the file descriptors may not be suitable. Several possible solutions for this are in discussion. Recently Capsicumized utilities include: * bspatch * cmp * ident * primes * tee * tr * write Additional Capsicum changes are in review: * b64decode, b64encode, uudecode, uuencode * brandelf * dma-mbox-create * elf2aout * file * head * hexdump * iconv * ident * jot * ktrdump * lam * last * ministat * praudit * strings An additional syscall (getdtablesize) and additional sysctls (kern.proc.nfds, kern.hostname, etc.) are now permitted in capability mode. Capability rights are now propagated to child descriptors on accept(2). Capsicum is now enabled in the 32-bit compatibility syscall layer. Per-process (procctl) and global (sysctl) settings have been added to aid in debugging while Capsicumizing existing applications. When enabled, instead of returning ENOTCAPABLE or ECAPMODE for a system call, the kernel will issue a SIGTRAP to generate a core dump or enter the debugger. This project was sponsored by Dell EMC Isilon, ScaleEngine Inc., and The FreeBSD Foundation. __________________________________________________________________ ClonOS: New FreeBSD-Based Free/Open Hosting Platform Links ClonOS Homepage URL: http://clonos.tekroutine.com Contact: Oleg Ginzburg Currently, FreeBSD is well proven as a base for routers (pfSense, OPNSense, BSDRP) and NAS (FreeNAS, zfsGuru, NAS4Free). However, FreeBSD-based solutions are almost completely absent in the virtualization area, and ClonOS is one of the attempts to change that. ClonOS is a new free open-source FreeBSD-based platform for virtual environment creation and management. In the core platform are: * FreeBSD as the host OS * bhyve * xen * vale * jail * CBSD (as a management tool) * puppet (for configuration management) * additional features such as go-micro services (obtaining VMs, resizing disks, and so on) Open tasks: 1. We would like to see ClonOS in real-world use. In this regard we are interested in finding more people and companies that use FreeBSD in hosting tasks. In addition, it could be great to work with the developers of existing NAS solutions (zfsGuru, NAS4Free). __________________________________________________________________ CloudABI: Running Untrusted Programs Directly on top of FreeBSD Links Official CloudABI Website URL: https://nuxi.nl/ Using CloudABI on FreeBSD URL: https://nuxi.nl/cloudabi/freebsd/ Python for CloudABI URL: https://nuxi.nl/blog/2016/08/01/cloudabi-python.html CloudABI on GitHub URL: https://github.com/NuxiNL Contact: Ed Schouten Contact: The CloudABI mailing list CloudABI is a compact UNIX-like runtime environment inspired by FreeBSD's Capsicum security framework. It allows you to safely run potentially untrusted programs directly on top of FreeBSD, Linux and macOS, without requiring the use of virtualisation, jails, etc. This makes it a useful building block for cluster/cloud computing. Over the last couple of months, several new libraries and applications have been ported over to CloudABI, the most important addition being Python 3.6. This means that you can now write strongly sandboxed apps in Python! Support for different hardware platforms has also improved. In addition to amd64 and arm64, we now support i686 and armv6. The release of LLVM 3.9 was important to us, as it has integrated all the necessary changes to support the first three platforms. Full armv6 support is still blocked on some issues with LLVM's linker, LLD. This project was sponsored by Nuxi, the Netherlands. Open tasks: 1. Play around with CloudABI and let us know what you think of it! Full support for amd64 and arm64 is part of FreeBSD 11.0. i686 and armv6 support is only available on head, but will be merged to the stable/11 branch in the future. 2. Interested in Python programming? Give our copy of Python a try and share your experiences! 3. Do you maintain pieces of software that could benefit from strong sandboxing? Try building them using the CloudABI cross compiler! __________________________________________________________________ Improvements to Non-Transparent Bridge Subsystem Contact: Alexander Motin Non-Transparent Bridges allow the creation of memory windows between different systems using the regular PCIe links of CPUs as a transport. During the last quarter, the NTB subsystem gained a significant set of improvements and fixes: * The code was modularized, utilizing FreeBSD's NewBus interfaces to allow support for different hardware types with different drivers, support for multiple NTB instances in a system, using the ntb_transport module for consumers other than if_ntb, etc. * Support for splitting NTB resources between different applications was added, such as doing direct access to some range of remote memory and to a virtual network interface between nodes at the same time, etc. * The virtual network interface driver gained support for many modern features, such as multiple queues, new locking, etc. * NTB performance and SMP scalability was improved. * Multiple workarounds for hardware issues were added. The code is committed to the FreeBSD head, stable/11 and stable/10 branches. This project was sponsored by iXsystems, Inc. Open tasks: 1. Support for the next generation of Intel hardware. 2. Support for non-Intel hardware (AMD, PLX, etc.). 3. Support for I/OAT and other DMA offloads. 4. Creating a more efficient packet transport protocol. 5. Creating a greater variety of NTB applications. __________________________________________________________________ The Graphics Stack on FreeBSD Links GitHub Repository URL: https://github.com/FreeBSDDesktop/FreeBSD-base-graphics Graphics Stack Roadmap and Supported Hardware Matrix URL: https://wiki.FreeBSD.org/Graphics Ports Development Repository URL: https://github.com/FreeBSD/FreeBSD-ports-graphics DRM 4.7 Development Repository URL: https://github.com/FreeBSDDesktop/FreeBSD-base-graphics/tree/drm-next-4.7 GSoC 2016: Link /dev Entries to Sysctl Nodes URL: https://wiki.FreeBSD.org/action/recall/SummerOfCodeIdeas?action=recall&rev=67#Devices_management:_link_.2Fdev_entries_to_sysctl_nodes GSoC 2016: Redesign libdevq URL: https://wiki.FreeBSD.org/SummerOfCode2016/RethinkLibdevq Wayland Notes URL: https://github.com/yohanesu75/FreeBSD-base-graphics/wiki/Wayland-on-FreeBSD Graphics Team Blog URL: https://planet.FreeBSD.org/graphics Contact: FreeBSD Graphics Team Contact: Matthew Macy Contact: Johannes Lundberg We are sad to report that both GSoc projects failed. The libdevq project was abandoned as the student disappeared. The kernel project was incomplete because the student could not work for personal reasons. He plans to resume work and complete the task, even though GSoC 2016 is finished. X.org server version 1.18.4 and updates for the xf86-video-ati and xf86-video-intel DDX drivers are ready for wider testing. A CFT will be sent out shortly. These updates are required to use newer DRM versions. The missing functionality from libdrm that is needed by the amdgpu driver has been added. These changes will be committed to the ports tree shortly after the xorg-server update. DRM from Linux 4.8 was ported to the drm-next branch. This branch should be used for radeon and amdgpu cards. The drm-next-4.7 branch should be used for i915 cards due to instabilities in the intel driver in the drm-next branch. Johannes Lundberg has been working on getting the Wayland environment running on FreeBSD. The Wayland ports are in a working state except for the Weston compositor. The current Weston port (from DragonFlyBSD) might be scrapped and a new port created from scratch based on the upstream source code. With the use of libinput, libudev-devd, and epoll-shim, the diff will not be very large and will be easier to maintain. Patches for wlc (another Wayland compositor) are being pushed upstream. On the TODO list is refactoring the tty code into selectable backends (linux, FreeBSD, etc), as recommended by the author of wlc. For now, it is running on FreeBSD with patches in the ports tree. __________________________________________________________________ Using lld, the LLVM Linker, to Link FreeBSD Links LLD Wiki Page URL: https://wiki.FreeBSD.org/LLD Contact: Ed Maste lld is the linker in the LLVM family of projects. It is a high-performance linker that supports the ELF, COFF, and Mach-O object formats. Where possible, lld maintains command-line and functional compatibility with the existing GNU BFD ld and gold linkers. However, the authors of lld are not constrained by strict compatibility where it would hamper performance or desired functionality. Compared to the GNU ld 2.17.50 currently in the base system, lld will bring: * AArch64 (arm64) support * Link Time Optimization (LTO) * New ABI support * Other linker optimizations * Much faster link times * Maintained code base The upstream lld project has now implemented nearly all of the functionality required to link the amd64 FreeBSD base system, including the kernel. The boot loader components and rescue utilities currently do not build with lld. This project was sponsored by The FreeBSD Foundation. Open tasks: 1. Merge lld to FreeBSD head as part of the Clang 3.9.0 import. 2. Request a ports exp-run with lld installed as /usr/bin/ld. 3. Fix building the boot loader with lld. 4. Fix building rescue with lld. 5. Test and iterate making lld fixes for additional architectures. __________________________________________________________________ VirtualBox Shared Folders Filesystem Links Project Repository URL: https://github.com/lwhsu/FreeBSD-vboxfs Contact: Li-Wen Hsu Contact: Oleksandr Tymoshenko FreeBSD provides an API for guest operating systems to access shared folders on the host so that the kernel driver can expose them to the guest's userland. This project aims to add such functionality to the VirtualBox Guest Additions driver. Good progress was made over the last few months. Developers were able to mount a filesystem in read-only mode and, with some limitations, in read-write mode. The implementation still lacks some critical pieces, but the roadmap is clear. Open tasks: 1. Finish the missing pieces. 2. Implement proper locking. 3. General clean-up and bugfixes. __________________________________________________________________ ZFS Code Sync with Latest OpenZFS/Illumos Contact: Alexander Motin Contact: Andriy Gapon The ZFS code base in FreeBSD regularly gets merges of new code, staying in sync with the latest OpenZFS/Illumos sources. Among other things, the latest merge included the following improvements: * The ARC now mostly stores compressed data, the same as is stored on disk, decompressing them on demand. * The L2ARC now stores the same (compressed) data as the ARC without recompression, and its RAM usage was further reduced. * The largest size of indirect block possible has been increased from 16KB to 128KB, and speculative prefetching of indirect blocks is now performed. * Improved ordering of space allocation. * The SHA-512t256 and Skein hashing algorithms are now supported. __________________________________________________________________ Kernel evdev Support Links evdev WIP Repository URL: https://github.com/wulf7/FreeBSD Original evdev Proposal URL: https://wiki.FreeBSD.org/SummerOfCode2014/evdev_Touchscreens Contact: Vladimir Kondratiev Contact: Oleksandr Tymoshenko evdev is a portable, API-compatible implementation of the Linux /dev/input/eventX interface. It covers a wide variety of input devices like keyboards, mice, and touchscreens (with multitouch support), and support for it is implemented in a lot of existing userland components like Qt, libinput, and tslib. evdev support was started by Jakub Klama as a Google SoC 2014 project, and later picked up and finished by Vladimir Kondratiev. General API and evdev support bits for ukbd and ums were committed to head. Support was also added for TI's AM33xx touchstreen controller (the popular BeagleBone is based on the AM33xx) and the official touschreen for the Raspberry Pi. Multitouch support for the Raspberry Pi was successfully demonstarted using the latest Qt development branch. Open tasks: 1. Documentation. In particular, manual pages are needed for the KPI. 2. Support additional hardware. 3. Enable evdev support in existing ports, and add new evdev-dependent ports. __________________________________________________________________ FreeBSD Driver for the Annapurna Labs ENA Links Amazon AWS Documentation of the ENA URL: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html Contact: Jan Medala Contact: Jakub Palider The Elastic Network Adapter (ENA) is a 25G SmartNIC developed by Annapurna Labs based on a custom ARMv8 chip. This is a high-performance networking card that is available to AWS virtual machines. It introduces enhancements in network utilization scalability on EC2 machines running various operating systems, in particular FreeBSD. The goal of FreeBSD enablement is to provide top performance and a wide range of monitoring and management features such as: * multiple queue modes * various offload functionality * admin queue * asynchronous notification * robust hardware access * scalable number of MSI-X interrupts * counters The current state offers stable driver operation with good performance on machines running FreeBSD directly on the hardware. This project was sponsored by Annapurna Labs -- an Amazon company. Open tasks: 1. Optimize performance for virtualized environments. 2. Prepare for submitting the driver as a Phabricator review. __________________________________________________________________ FreeBSD on Hyper-V and Azure Links FreeBSD Virtual Machines on Microsoft Hyper-V URL: https://wiki.FreeBSD.org/HyperV Supported Linux and FreeBSD virtual machines for Hyper-V on Windows URL: https://technet.microsoft.com/en-us/library/dn531030.aspx Contact: Sepherosa Ziehau Contact: Hongjiang Zhang Contact: Dexuan Cui Contact: Kylie Liang This quarter, the Hyper-V storage driver was greatly improved: its performance was increased by a factor of 1.2-2 by applying BUS_DMA and UNMAP_IO, enlarging the request queue, and selecting the outgoing channel with the LUN considered; TRIM/UNMAP was enabled; and some critical bugs (PRs 209443, 211000, 212998) were fixed so that disk hot add/remove and VHDX online resizing should work now. The VMBus driver also received attention, with enhancements made for the handling of device hot add/remove. In the Hyper-V network driver, configurable RSS key and dynamic MTU change are now supported. FreeBSD images on Azure continue to be updated -- after publishing the FreeBSD 10.3 VM image on the global Microsoft Azure in June, Microsoft also published the VM image on the Microsoft Azure operated by 21Vianet in China in September. Patches have been developed to support PCIe pass-through (also known as Discrete Device Assignment); this feature allows physical PCIe devices to be passed through to FreeBSD VMs running on Hyper-V (Windows Server 2016), giving them near-native performance with low CPU utilization. The patch to enable the feature will be posted for review soon. This project was sponsored by Microsoft. __________________________________________________________________ Timekeeping Code Improvements Contact: Konstantin Belousov Work was done to properly lock the time-keeping code. The existing code correctly interoperated with readers, both kernel- and user-space, giving them lock-less access to the actual data ('timehands') needed to derive the time of day from the timecounter hardware in the presence of updaters. But updates of the timehands, which are performed by periodic clock interrupts, the ntpd-driven sys_ntp_adjtime(2) syscall, the settimeofday(2) syscall, pps sync, and possibly other sources, were not coordinated. Moreso, the NTP code was locked by Giant, which did not really serve any purpose. As a result of the work, locking was applied to ensure that any timehands adjustments are performed by a single mutator. An interesting case is the parallel modification of the timehands from the top of the kernel, for instance the settimeoday(2) syscall, and a simultaneous clock tick event, where the syscall has already acquired the resources. In this case, it is highly desirable to not block (spin) in the tick handler, and the required adjustments are performed by the already executing call from the top half. There, the typical trylock operation is desired, which was surprisingly lacking in our spinlock implementation. mtx_trylock_spin(9) was implemented and is used for this purpose. The userspace gettimeofday(2) implementation was enhanced to allow syscall-less operation on machines that use HPET hardwire for timecounters. The HPET algorithm coexists with older RDTSC-based code, allowing dynamic switching of timecounters. HPET registers a page that is mmap(2)-ed readonly by libc into userland application programs' address space as needed. Measurements demonstrated modest improvements in gettimeofday(2) performance, but, not unexpectedly, even the syscall-less HPET timecounter is slower than invoking a syscall for RDTSC. Some not strictly intertwined but related code is the time-bound sleep implementation. Handling of races between callouts and the top-half code that sets and processes the timeouts depended on the many fine details of the callout_stop(9) KPI (kernel programming interface). In particular, races or unpunctual KPI changes usually result in the "catch-all" unkillable thread state with the "-" waitchain bug. The sleepqueue timeout code was rewritten to stop depending on the KPI details, which removed the source of recurring bugs, and also surprisingly simplified the code. This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ Google Summer of Code Google Summer of Code 2016 Links GSoC 2016 Projects URL: https://wiki.FreeBSD.org/SummerOfCode2016Projects GSoC Ideas page URL: https://wiki.FreeBSD.org/SummerOfCodeIdeas Contact: Gavin Atkinson Contact: Pedro Giffuni As in all previous editions of the Google Summer of Code, FreeBSD was an accepted organization, and we had the chance to mentor 15 projects. Huge thanks to all our mentors for keeping the high quality standards that make our community shine. This year was rather unique in that we accepted for the first time well-known members of the community that are not src committers to co-mentor. We also accepted projects that have a different upstream than FreeBSD. Both are clear signs that FreeBSD is growing and adapting to the wider community. This year we are also had administrative issues with Perforce and have officially accepted the use of external repositories, in particular github, as requested by students. 12 of 15 projects were successful, which we think is an excellent result for a Google Summer of Code. This project was sponsored by Google Inc, and The FreeBSD Foundation. Open tasks: 1. The world is changing and we need fresh project ideas. We need to start looking for those ideas now. 2. The project ideas wiki page has been reset and we need to get it populated before applying for the next Google Summer of Code. Please help unleash the next stream of projects you want to see in FreeBSD. __________________________________________________________________ Non-BSM to BSM Conversion Tools Links Wiki Page URL: https://wiki.FreeBSD.org/SummerOfCode2016/NonBSMtoBSMConversionTools GitHub Repository URL: https://github.com/0mp/FreeBSD Pull Request With Consolidated Patch URL: https://github.com/0mp/FreeBSD/pull/9 Contact: Mateusz Piotrowski <0mp@FreeBSD.org> This project was started during Google Summer of Code this year. The aim was to create a library which can convert the audit trail files in Linux Audit format or the format used by Windows to the BSM format used by FreeBSD for its audit logs. Apart from that, I wanted to create a simple command-line tool and extend auditdistd so that it is possible to send non-BSM logs to it over a secure connection and save those audit logs on disk, preferably in the BSM format. So far, it is possible to reasonably convert some of the most common Linux audit log events to BSM, but it still needs a lot of work. Secondly, I was able to configure auditdistd to communicate with CentOS over an insecure connection. Thirdly, the command-line tool is usable but not perfect. The present work focuses on configuring the secure TLS connection between CentOS and auditdistd. I have already tried using rsyslogd but was not able to make it work. This project was sponsored by Google Summer of Code. Open tasks: 1. I need more examples of rare Linux Audit logs; please send me some examples if you have any. It is much easier to improve the conversion process with real-life examples of audit events as you write the code to convert them. 2. Configure auditdistd to be able to communicate with some software on CentOS over TLS in order to receive audit logs. I was not able to come up with a simple solution for that. 3. Additional open tasks are listed on the Wiki page and in the TODO file in the root directory of the project. __________________________________________________________________ ptnet Driver and bhyve Device Model Links FreeBSD Wiki Page for Project Overview URL: https://wiki.FreeBSD.org/SummerOfCode2016/PtnetDriverAndDeviceModel Conference Paper URL: http://info.iet.unipi.it/~luigi/papers/20160613-ptnet.pdf Subversion Repository URL: https://svnweb.FreeBSD.org/socsvn/soc2016/vincenzo/head/ Contact: Vincenzo Maffione This project provides: * A new driver (if_ptnet) for a paravirtualized network device, modeled after the netmap API. The driver supports multi-queue netmap ports, and it is able to work both in netmap mode and in normal mode. * The emulation of the ptnet device model as a module of the bhyve hypervisor. The ptnet device and driver has been introduced to overcome the performance limitations of TCP/IP networking between bhyve VMs. Prior to this work, the most performant solution for VM-to-VM intra-host TCP communication provided less than 2 Gbps TCP throughput. With ptnet, in the same VM-to-VM TCP communication scenario, it is possible to obtain up to 20 Gbps. This project was sponsored by Google Summer of Code. Open tasks: 1. Share virtio-net header management code with the if_vtnet driver. In the current code, about 100 lines of code have been copied and pasted from if_vtnet.c. __________________________________________________________________ Architectures FreeBSD on Annapurna Labs Alpine Contact: Jan Medala Contact: Michal Stanek Contact: Wojciech Macek Alpine is a family of Platform-on-Chip devices, including multi-core 32-bit (first-gen Alpine) and 64-bit (Alpine V2) ARM CPUs, developed by Annapurna Labs. The primary focus areas of the Alpine platform are high-performance networking, storage, and embedded applications. The network subsystem features 10-, 25-, and 50-Gbit Ethernet controllers with support for virtualization, load-balancing, hardware offload and other advanced features. A basic patch set has already been committed to head including: * PCIe Root Complex support * Cache Coherency Unit driver * North Bridge Service driver * Updated Alpine HAL * Extended MSI support in GICv2 and GICv3 code Additional work, such as an MSI-X driver and full Ethernet support, is currently undergoing community review on Phabricator. The multi-user SMP system is stable and fully working, along with the 1G and 10G Ethernet links. The interrupt management code has been adjusted to work with the new INTRNG framework on both ARM32 and ARM64. This project was sponsored by Annapurna Labs -- an Amazon company, and Semihalf. __________________________________________________________________ FreeBSD on Marvell Armada38x Contact: Marcin Wojtas Contact: Bartosz Szczepanek FreeBSD includes support for the Marvell Armada38x platform, which has been tested and improved in order to gain production quality. Most of this effort has been invested in development and benchmarking of the on-chip Gigabit Ethernet (NETA) functionality. Numerous bug fixes and some new features have been introduced. Work completed this quarter includes: * NETA rework and improvements. * Enable multi-port support in PCIe 2.0 driver (mv_pci_ctrl). * Introduce an alternative, coherent, bus_dma for the armv7 arch. * AHCI controller support. * SDHCI controller support. * Improve the e6000sw etherswitch driver. * Fix Marvell bus configuration for numerous interfaces. Along with support for new boards (SolidRun ClearFog and DB-88F6285-AP), all changes will be submitted upstream. This project was sponsored by Stormshield, and Semihalf. Open tasks: 1. Finalize NETA and prepare for submission. 2. Submit remaining fixes and drivers. __________________________________________________________________ FreeBSD/arm64 Links FreeBSD arm64 Wiki Entry URL: https://wiki.FreeBSD.org/arm64 Using Crochet to Build FreeBSD Images URL: https://github.com/wca/crochet/tree/add-pine64-support Contact: Andrew Turner Contact: Jared McNeill Transparent superpage support has been added. This allows FreeBSD to create 2MiB blocks with a single pagetable and TLB entry. This shows a small but significant improvement in the buildworld time on ThunderX machines. Superpages have been enabled in head and merged to stable/11, but they are disabled by default on stable/11 due to a lack of testing there. Support for the pre-INTRNG interrupt framework has been removed. This means that arm64 requires INTRNG to even build. This has allowed various cleanups within the arm64 drivers that interact with the interrupt controller. The cortex Strings library from Linaro has been imported. The parts of this that have been shown to be improvements over the previous C code were attached to the libc build. There is ongoing work to add ACPI support to the kernel. On ThunderX, FreeBSD can get to the mountroot prompt, however, due to incomplete ACPI tables the external PCIe support needed to support the netboot setup in the test cluster is not functional. Pine64 support has been committed to head. FreeBSD can now boot to multiuser with SMP enabled. This includes support for clocks, secure ID controller, USB Host controller, GPIOs, non-maskable interrupts, AXP81x power management unit, cpu freqency and voltage scaling, MMC, UART, gigabit networking, watchdog, and thermal sensors. This project was sponsored by The FreeBSD Foundation, and ABT Systems Ltd. __________________________________________________________________ UEFI Runtime Services Contact: Konstantin Belousov UEFI (Unified Extensible Firmware Interface) specifies two kinds of services for use by operating systems. Boot Services are designed for OS loaders to load and initialize kernels, while Runtime Services are meant to be used by kernels during regular system operations. The boot and runtime phases are explicitly separated. During boot, when loaders are executed, the machine configuration is owned by UEFI. During runtime, the kernel manages the configuration, but needs to inform the firmware about any changes that are made. The model of split boot/runtime configuration makes assumptions about the OS architecture that do not quite apply to the existing FreeBSD codebase. For instance, the firmware notification of the future runtime configuration must be done while the loader is effectively still in control. In technical terms, the SetVirtualAddressMap() call must be made with the 1:1 physical:virtual mapping on amd64 systems, which for FreeBSD means that the call can only be issued by the loader. But the loader needs to know intimate details of the kernel address map to provide the requested information. This creates a new, unfortunate, coupling between loader and kernel. Reading the publicly available information about the MS Windows boot process explained the UEFI control transfer model. The Windows loader constructs the address map for the kernel, and with such a division of work the UEFI model is reasonable. The FreeBSD kernel constructs its own address space, only relying on a minimal map constructed by the loader, which is enough for the pmap subsystem to bootstrap itself and then to perform machine initialization in common code. Initial experiments with enabling runtime services were centered around utilizing the direct address map (DMAP) on amd64, which currently always exists and linearly maps at least the lower 4G of physical addresses at some KVA location. It was supposed that the kernel would export the DMAP details like linear base and guaranteed size for loader from its ELF image, and provide the needed overflow map if the DMAP cannot completely serve. Unfortunately, two show-stopper bugs were discovered with this approach. First, EDK-based firmware apparently requires that the runtime mapping exists simultaneously with the physical mapping for the SetVirtualAddressMap() call. Second, there were references from other open-source projects mentioning that some firmware required the presence of the physical mapping during the runtime call. Effectively, this forces both kernel and loader to provide both mappings for all runtime calls. With such restrictions, informing the firmware about the details of the kernel address space only adds useless work. We could just as easily establish the 1:1 physical mapping during runtime and get rid of SetVirtualAddressMap() entirely. This approach was coded and the kernel interface to access runtime services is based on it. During development, particularly when trying to make the loader modifications, it was quickly realized that there were no fault-reporting facilities in loader.efi. Machine exceptions resulted in a silent hang. Curiously, in such a situation the Intel firmware outputs the error code over the serial port over 115200/8/1 settings, regardless of UEFI console configuration, which was discovered by accident. Unfortunately, the error code alone is not enough to diagnose most problems. A primitive fault reporter was written for loader.efi on amd64, which intercepts exceptions from the firmware IDT and dumps the machine state to the loader console. Due to the complexity of the interception and possible bugs which might do more harm than good there, the dumper is only activated on explicit administrator action. Note that the described work only provides the kernel interfaces to make calling the EFI runtime services as easy as calling a regular C function. User-visible feature development making use of the new interfaces is being performed right now. This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ Ports KDE on FreeBSD Links KDE on FreeBSD website URL: https://FreeBSD.kde.org/ KDE ports staging area URL: https://FreeBSD.kde.org/area51.php KDE on FreeBSD wiki URL: https://wiki.FreeBSD.org/KDE KDE/FreeBSD mailing list URL: https://mail.kde.org/mailman/listinfo/kde-FreeBSD Development repository for integrating Plasma 5 and KDE Frameworks 5 URL: http://src.mouf.net/area51/log/branches/plasma5 Development repository for integrating Qt 5.7 URL: http://src.mouf.net/area51/log/branches/qt-5.7 Contact: KDE on FreeBSD Team The KDE on FreeBSD team focuses on packaging the KDE software and making sure that the experience of KDE and Qt on FreeBSD is as good as possible. The following big updates were landed in the ports tree this quarter: * Added a Qt5 option to multimedia/mlt. * Added the devel/grantlee5 port and, with it, Uses/grantlee.mk. * Added the multimedia/gstreamer1-qt5 port. * Added the net-im/telepathy-qt5 port. * CMake was updated to versions 3.6.1 and 3.6.2. * An important fix was made to qmake, where the clang version was not correctly detected. * Qt 5.6.1 was committed to ports. * Phonon and its backend to were updated to 4.9.0 in preparation for Qt 5.6.1. * Updated the net-im/telepathy-qt4 port to 0.9.7. * Various LibreSSL related fixes by Matthew Rezny. * bsd.kde4.mk has been replaced by Uses/kde.mk. * www/webkit-qt5 was fixed to depend on the systems leveldb. In our development repository, we have done this work: * The plasma5 branch has been kept up to date with KDE's upstream and contains ports for Frameworks 5.26.0, Plasma Desktop 5.8.0, and Applications 16.08.1 (branches/plasma5). __________________________________________________________________ LXQt on FreeBSD Links FreeBSD LXQt Project URL: https://wiki.FreeBSD.org/LXQt LXQt Project URL: http://lxqt.org/ LXQt Development Repository URL: https://www.assembla.com/spaces/lxqt/subversion/source Contact: Olivier Duchateau Contact: Jesper Schmitz Mouridsen LXQt is the Qt port of and the upcoming version of LXDE, the Lightweight Desktop Environment. It is the product of a merge between the LXDE-Qt and Razor-qt projects. The porting effort remains very much a work in progress: it requires some components of Plasma 5, the new major KDE workspace. The porting of the 0.11 branch is now complete, with new ports (compared to the previous release). See our wiki page for a complete list of applications. We also have updates for: * x11-toolkits/qtermwidget (0.7.0) * x11/qterminal (0.7.0) * x11/qterminal-l10n Open tasks: 1. Improve FreeBSD support in sysutils/lxqt-admin, especially with respect to user management. 2. Add additional panel plugins. __________________________________________________________________ Xfce on FreeBSD Links FreeBSD Xfce Project URL: https://wiki.FreeBSD.org/Xfce FreeBSD Xfce Repository URL: https://www.assembla.com/spaces/xfce4/subversion/source 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: * audio/xfmpc (0.2.3) * deskutils/xfce4-notifyd (0.3.2) * deskutils/xfce4-volumed-pulse (0.2.2) * devel/thunar-vcs-plugin (0.1.5) * misc/xfce4-weather-plugin (0.8.8) * sysutils/xfce4-settings (4.12.1) * x11/xfce4-clipman-plugin (1.4.0) * x11/xfce4-dashboard (0.6.0) * x11/xfce4-goodies, the meta-port for the Xfce4 Goodies Project (plugins, applications) * x11/xfce4-whiskermenu-plugin (1.6.0) We also follow the unstable releases; the current unstable release brings support for Gtk3 (available in our experimental repository) to: * audio/xfce4-mpc-plugin (0.4.99) * sysutils/garcon (0.5.0) * sysutils/xfce4-battery-plugin (1.0.99) * sysutils/xfce4-diskperf-plugin (2.5.99) * sysutils/xfce4-fsguard-plugin (1.0.99) * sysutils/xfce4-netload-plugin (1.2.99) * sysutils/xfce4-systemload-plugin (1.1.99) * www/xfce4-smartbookmark-plugin (0.4.99) * x11/libexo (0.11.1) * x11/libxfce4menu (4.13.1) * x11/xfce4-dashboard (0.7.0) * x11/xfce4-terminal (0.6.92) * x11/xfce4-whiskermenu-plugin (2.0.1) * x11-clocks/xfce4-datetime-plugin (0.6.99) Currently the unstable releases work fine with our Gtk3 ports available in the ports tree, but in the future support for 3.18 will be removed in preference of 3.20.x. Open tasks: 1. Continue working on unstable releases. __________________________________________________________________ Documentation Documenting the History of Utilities in /bin and /sbin Links The igor Port URL: https://svnweb.FreeBSD.org/ports/head/textproc/igor BSD Family Tree in Subversion URL: https://svnweb.FreeBSD.org/base/head/share/misc/bsd-family-tree?view=log The UNIX Heritage Society URL: http://www.tuhs.org Cat-V Manual Library URL: http://man.cat-v.org Contact: Sevan Janiyan For EuroBSDcon, I began looking into inconsistencies within components inside our family of operating systems. My workflow consisted of reading the documentation for a given utility and checking the history in the revision control system for missing fixes or functionality in the trees of NetBSD, FreeBSD, OpenBSD, and DragonFly BSD. One thing which became obvious very quickly was the inconsistency between operating systems about where and/or which version a utility originated in, despite our common heritage. I began working through the man pages in FreeBSD, verifying the details in pages which already had a history section and making patches for those which did not. From there, changes were propogated out to NetBSD, OpenBSD, and Dragonfly BSD where applicable (not all utilities originated from the same source or implementation, for example). This was a good exercise in: * Becoming familiar with mandoc. * Using tools such as the linting functionality in mandoc and the igor documentation script. * Becoming familiar with the locations where things are documented and with external sources of historical information, such as the BSD Family Tree included in the FreeBSD base system, and projects like The UNIX Heritage Society and the manual library on cat-v.org which hosts copies of manuals such as those shipped with Research UNIX. These manuals are not commonly available elsewhere. Open tasks: 1. Cover the remaining manuals for userland utilities, and maybe expand into library and syscall APIs, though I say that without estimating the feasibility. The history of components originating from a closed-source operating system is tricky to document, since older versions are not always available. __________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGgBAEBCgAGBQJYKQ55AAoJECjZpvNk63US3l0MHAo0nou6EhBtZvJK2+9f81RF MUJ/ILEg/nX5JHnhKKdTOaH+SJW4D6OD8L5EjxaC9uv1/IQvE3skl5XoVKwsnaB0 tKET1E6aclCx7kC2LnSkj43IOgmjXJfWOd+ynEsbe4cYAZRm27cBQiHw4X/gDL7X qslMbxVtLxGOJ3nfXPtMQjk57OGN1ltQG9fOK6WbSfv8aaGnQRjp8tWYkyJ/rOhh bo0N+/brsWvAgigkhlV/OR3GQk5Laf6U2CS2gpwWZQrRBG9R/+Zwv2/y9uQv3vE4 qvuwYqLpRrNiv+Q5+DCVKd3N06gCXoDa444kYl5QxRmLPohmmYSHpIOKYgWqM7hX 3DOkOOMCV11L6VYkI6aWpoUFLtPzhsplxdruJcmjdqZ3nCDa2Jvocd2tsFx8+YQ5 oe2ygDAINpFI9sf1Cy+aYocf00n3l1JjBurF/2b/JO8+UKMR5TfW+yU1LkmVITUu +xaIOV4EMvGTFUxCbuOgzwLZnD9CpEwVnrTSj8JUeTvYJhc= =CxJu -----END PGP SIGNATURE----- From owner-freebsd-stable@freebsd.org Mon Nov 14 01:56:11 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D9CFC3FA9C for ; Mon, 14 Nov 2016 01:56:11 +0000 (UTC) (envelope-from felix.the.red@gmail.com) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 EE91D1DAD for ; Mon, 14 Nov 2016 01:56:10 +0000 (UTC) (envelope-from felix.the.red@gmail.com) Received: by mail-qt0-x22d.google.com with SMTP id n6so39797569qtd.1 for ; Sun, 13 Nov 2016 17:56:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=YDMV6PbXeCp3NdyBxlJWsR8m2/pp+ZzV2Ouy+4yqqg4=; b=olz+qbzrscGH2UocF0Q8QoLt61epd8LAaHAuiqixooSaeKtsjiyJVfFBpCcCmCocVI kGvqHjbjZDY7Qv9f6KfFFcWR/K8VTe4kblVDDp+eL2/RLABCLE/ajCzbSku2nDOqWkUn Tg1fzRHSJawLAIS3pPenVDE8cUBqs19O1a5k3EzmmaVK3VBJe3e/+IUDy0nQB0HAFvNU zvkjM41LYq0hs9NMnOeEIDoOTbCA5LfORBeYsJYhD1mzVgCV5sr+89HaI4hlYbftcMJj +dnfiJrcXjGZ8lRbwZRpbGD8otKIBx+GyuoIJihuvpqp8eTA1aTV7Lfe2YGtBqu88lBn Xdjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YDMV6PbXeCp3NdyBxlJWsR8m2/pp+ZzV2Ouy+4yqqg4=; b=UXHcfUHphK7XfvWC4Nt5Skrs3lnEL9i2Y6ITg182Li+pHvx19dFaC8oCZd2whK1Sbd XVvkjw+5v8oQ5OzU5mBcAhAAm3Vr6szKoXG046UqPygiA2I1t80k5QY2syfZwTSO3OEA tRyEuWIw1Gn/fiqm6jQKuwCsw9AxF2liqYmT4xZO0ecf/PMJbkKdWPO0Aj+3oABWGXMG pbcFxgGhVMQMU8Q27PUagDib0B9/W0K/HxrURaP6J1k9pf3vKn0Diz3SJJgVIWc/SGce A0SY2Vz5vhbodw96dEi/6JwixaeCPtTQuEtN3+OGU0FEaevIHBTM8+vbvOlMf1FAELjE Q9FQ== X-Gm-Message-State: ABUngvc+9FrsVkUuRZLYUjRU/sSP3PH8KCtXTZRxYpRpLMH5EFQKLFBpkW7a8pxMvW78gXkdxXSKYh4IOdQ3JQ== X-Received: by 10.237.42.65 with SMTP id k1mr5562301qtf.210.1479088569806; Sun, 13 Nov 2016 17:56:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.30.53 with HTTP; Sun, 13 Nov 2016 17:56:09 -0800 (PST) From: Felix Johnson Date: Sun, 13 Nov 2016 15:56:09 -1000 Message-ID: Subject: Problems with Dell external USB DVD drive To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 01:56:11 -0000 Hello, I have a Dell Inspiron 7547, which lacks an internal CD/DVD drive. I purchased a Dell DW514 external USB DVD drive, which works in Windows, but can't be located in FreeBSD 11.0-p2. I am looking for help in getting FreeBSD to recognize the device. Any help is appreciated, since this is an important step to using this laptop full-time as a FreeBSD workstation. Here is the information I have on my system: [fjohnson@laptop /usr/home/fjohnson]$ uname -a FreeBSD laptop 11.0-RELEASE-p2 FreeBSD 11.0-RELEASE-p2 #0: Mon Oct 24 06:55:27 UTC 2016 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 [fjohnson@laptop /usr/home/fjohnson]$ sudo usbconfig ugen0.1: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (100mA) ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (98mA) ugen0.4: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (450mA) ugen0.5: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) ugen0.6: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) ugen0.7: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) [fjohnson@laptop /usr/home/fjohnson]$ dmesg | grep -i usb xhci0: mem 0xf7d00000-0xf7d0ffff irq 16 at device 20.0 on pci0 usbus0 on xhci0 ehci0: mem 0xf7d23000-0xf7d233ff irq 23 at device 29.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 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 Root mount waiting for: usbus1 usbus0 Root mount waiting for: usbus1 usbus0 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 Root mount waiting for: usbus1 usbus0 ugen0.3: at usbus0 ukbd0: on usbus0 Root mount waiting for: usbus0 ugen0.4: at usbus0 Root mount waiting for: usbus0 ugen0.5: at usbus0 umass0: on usbus0 Root mount waiting for: usbus0 ugen0.6: at usbus0 Root mount waiting for: usbus0 ugen0.7: at usbus0 Root mount waiting for: usbus0 usb_alloc_device: set address 8 failed (USB_ERR_TIMEOUT, ignored) Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 8 failed, USB_ERR_TIMEOUT Root mount waiting for: usbus0 usbd_req_re_enumerate: addr=8, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 8 failed, USB_ERR_TIMEOUT Root mount waiting for: usbus0 Root mount waiting for: usbus0 usbd_req_re_enumerate: addr=8, set address failed! (USB_ERR_TIMEOUT, ignored) Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 8 failed, USB_ERR_TIMEOUT Root mount waiting for: usbus0 usbd_req_re_enumerate: addr=8, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 8 failed, USB_ERR_TIMEOUT Root mount waiting for: usbus0 Root mount waiting for: usbus0 usbd_req_re_enumerate: addr=8, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 8 failed, USB_ERR_TIMEOUT ugen0.8: at usbus0 (disconnected) ums0: on usbus0 uhid0: on usbus0 uhid1: on usbus0 axe0: on usbus0 ue0: on axe0 [fjohnson@laptop /usr/home/fjohnson]$ Thank you! Felix Johnson From owner-freebsd-stable@freebsd.org Mon Nov 14 07:10:48 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 693E5C40B68 for ; Mon, 14 Nov 2016 07:10:48 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 214261AC5 for ; Mon, 14 Nov 2016 07:10:48 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-vk0-x234.google.com with SMTP id p9so56934042vkd.3 for ; Sun, 13 Nov 2016 23:10:48 -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; bh=T4qbDEVytm54FTh+Bxm/t4tIH1DBIRMpFjkSGfiuBPE=; b=rli6Ikmpvk9t4veSzuRkhSAARA+kyQbJlMYa2QoRIJatrfdE7BYYQ5XkjnMu/wXlLz VtCeg+frEhYGu2/cYfwGeYDZi6GhLBnZNaeVsNZxfJm3p3Vbpu+VsnnwGqQH8NvGmnR6 w3fo8XXF1j4UXffVba0ThDiTaA3PPPQ5d8S3XmwjiiCKNlzrGc7Lo6NMFTEgCrd6uvbt gdfT9Cxr18kZnQSJutRedLfUL5/3oj2swE+tFr4qc0Ot/myzpke3y+uhgxtTVoa4qjgl QNq2IUEOxQAAz7fDEi2qaRtEJygAK6O1ckhkuegEfz+ABIlgli6c2oSbienEuUOdUek1 GmGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=T4qbDEVytm54FTh+Bxm/t4tIH1DBIRMpFjkSGfiuBPE=; b=d2qmv6Xpqc3M8Sc5j89ak1n5xIWCaY0NN8VRm+7zsl1dMbO8BTrx1WaGDCvx01+atj 40RWSVOgjDRZH+eDQ87CrmGsuRwcvZTk5iucVuo1cvCMgRZDKjP3W3URTzqBosfFkKNh eBWlFY4mokdmY9NPcxj21HcpzEFWNXPKlL3qD9LLb/h2ab04WfZz7QShU9lhM+U0U7GK oumKKSnWVfuJoGSyRINUAzNa2p0/VRt7MK8FzEBOuHOpMM7ihRvRxCs0oydT2IvNWHlD CGxlNE+EcpoRQ1gg0XLnSVmtht6fTfhkuITRahRfaaIBO2GWfi9PxIPxTuk2OacSvWD9 COog== X-Gm-Message-State: ABUngveVhgBu9HdJU0+hzCr5B4RLHvxRMo2XdtIP+3Vh1dp66F+WEbS/PO98LQO27CS7/blS3rpT17Jf6Uq1Yg== X-Received: by 10.31.237.131 with SMTP id l125mr9292804vkh.56.1479107447252; Sun, 13 Nov 2016 23:10:47 -0800 (PST) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.103.119.79 with HTTP; Sun, 13 Nov 2016 23:10:46 -0800 (PST) In-Reply-To: References: From: Kevin Oberman Date: Sun, 13 Nov 2016 23:10:46 -0800 X-Google-Sender-Auth: R0f3xFtogZal_GTOt0cMz2hfqJU Message-ID: Subject: Re: Problems with Dell external USB DVD drive To: Felix Johnson Cc: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 07:10:48 -0000 On Sun, Nov 13, 2016 at 5:56 PM, Felix Johnson wrote: > Hello, > > I have a Dell Inspiron 7547, which lacks an internal CD/DVD drive. > I purchased a Dell DW514 external USB DVD drive, which works in Windows, > but can't be located in FreeBSD 11.0-p2. I am looking for help in getting > FreeBSD > to recognize the device. > > Any help is appreciated, since this is an important step to using this > laptop > full-time as a FreeBSD workstation. > > Here is the information I have on my system: > > [fjohnson@laptop /usr/home/fjohnson]$ uname -a > FreeBSD laptop 11.0-RELEASE-p2 FreeBSD 11.0-RELEASE-p2 #0: Mon Oct 24 > 06:55:27 UTC 2016 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC > amd64 > > [fjohnson@laptop /usr/home/fjohnson]$ sudo usbconfig > ugen0.1: at usbus0, cfg=0 md=HOST spd=SUPER > (5.0Gbps) pwr=SAVE (0mA) > ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) > pwr=SAVE (0mA) > ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH > (480Mbps) pwr=SAVE (100mA) > ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH > (480Mbps) pwr=SAVE (0mA) > ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) > pwr=ON (98mA) > ugen0.4: at usbus0, cfg=0 md=HOST spd=HIGH > (480Mbps) pwr=ON (450mA) > ugen0.5: at usbus0, cfg=0 md=HOST spd=HIGH > (480Mbps) pwr=ON (500mA) > ugen0.6: at usbus0, cfg=0 md=HOST spd=HIGH > (480Mbps) pwr=ON (500mA) > ugen0.7: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) > pwr=ON (100mA) > > [...] > > Thank you! > Felix Johnson > Can I assume that the drive was plugged in when the usbconfig command was issued? I don't see any indication of it in the output. I was expecting a vendor/product that was not known to the system, but that does nto appear to be the case. the only two not identified have and the first in an Intel vendor ID and the second appears to be an Asix Ethernet controller, though the information on that is sketchy. When you plug in the drive, the console should show a message. A similar message should be sent when it is unplugged. Can you try that and report the message? It should include the vendor and product IDs. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-stable@freebsd.org Mon Nov 14 09:08:48 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F268DC40319 for ; Mon, 14 Nov 2016 09:08:47 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D608E1499; Mon, 14 Nov 2016 09:08:46 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA03148; Mon, 14 Nov 2016 11:08:44 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1c6DFs-000CHM-AN; Mon, 14 Nov 2016 11:08:44 +0200 Subject: Re: Freebsd 11.0 RELEASE - ZFS deadlock To: Henri Hennebert , freebsd-stable@FreeBSD.org References: <0c223160-b76f-c635-bb15-4a068ba7efe7@restart.be> <43c9d4d4-1995-5626-d70a-f92a5b456629@FreeBSD.org> <9d1f9a76-5a8d-6eca-9a50-907d55099847@FreeBSD.org> <6bc95dce-31e1-3013-bfe3-7c2dd80f9d1e@restart.be> <23a66749-f138-1f1a-afae-c775f906ff37@restart.be> <8e7547ef-87f7-7fab-6f45-221e8cea1989@FreeBSD.org> <6d991cea-b420-531e-12cc-001e4aeed66b@restart.be> <67f2e8bd-bff0-f808-7557-7dabe5cad78c@FreeBSD.org> <1cb09c54-5f0e-2259-a41a-fefe76b4fe8b@restart.be> <9f20020b-e2f1-862b-c3fc-dc6ff94e301e@restart.be> <599c5a5b-aa08-2030-34f3-23ff19d09a9b@restart.be> <32686283-948a-6faf-7ded-ed8fcd23affb@FreeBSD.org> Cc: Konstantin Belousov From: Andriy Gapon Message-ID: Date: Mon, 14 Nov 2016 11:07:48 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 09:08:48 -0000 On 13/11/2016 15:28, Henri Hennebert wrote: > On 11/13/2016 11:06, Andriy Gapon wrote: >> On 12/11/2016 14:40, Henri Hennebert wrote: >>> I attatch it >> >> Thank you! >> So, these two threads are trying to get the lock in the exclusive mode: >> Thread 687 (Thread 101243): >> #0 sched_switch (td=0xfffff800b642b500, newtd=0xfffff8000285ea00, flags=> optimized out>) at /usr/src/sys/kern/sched_ule.c:1973 >> #1 0xffffffff80561ae2 in mi_switch (flags=, newtd=0x0) at >> /usr/src/sys/kern/kern_synch.c:455 >> #2 0xffffffff805ae8da in sleepq_wait (wchan=0x0, pri=0) at >> /usr/src/sys/kern/subr_sleepqueue.c:646 >> #3 0xffffffff8052f854 in sleeplk (lk=, flags=> optimized out>, ilk=, wmesg=0xffffffff813be535 "zfs", >> pri=, timo=51) at /usr/src/sys/kern/kern_lock.c:222 >> #4 0xffffffff8052f39d in __lockmgr_args (lk=, flags=> optimized out>, ilk=, wmesg=, >> pri=, timo=, file=> out>, line=) at /usr/src/sys/kern/kern_lock.c:958 >> #5 0xffffffff80616a8c in vop_stdlock (ap=) at lockmgr.h:98 >> #6 0xffffffff8093784d in VOP_LOCK1_APV (vop=, a=> optimized out>) at vnode_if.c:2087 >> #7 0xffffffff8063c5b3 in _vn_lock (vp=, flags=548864, >> file=, line=) at vnode_if.h:859 >> #8 0xffffffff8062a5f7 in vget (vp=0xfffff80049c2c000, flags=548864, >> td=0xfffff800b642b500) at /usr/src/sys/kern/vfs_subr.c:2523 >> #9 0xffffffff806118b9 in cache_lookup (dvp=, vpp=> optimized out>, cnp=, tsp=, >> ticksp=) at /usr/src/sys/kern/vfs_cache.c:686 >> #10 0xffffffff806133dc in vfs_cache_lookup (ap=) at >> /usr/src/sys/kern/vfs_cache.c:1081 >> #11 0xffffffff80935777 in VOP_LOOKUP_APV (vop=, a=> optimized out>) at vnode_if.c:127 >> #12 0xffffffff8061cdf1 in lookup (ndp=) at vnode_if.h:54 >> #13 0xffffffff8061c492 in namei (ndp=) at >> /usr/src/sys/kern/vfs_lookup.c:306 >> #14 0xffffffff80509395 in kern_execve (td=, args=> optimized out>, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:443 >> #15 0xffffffff80508ccc in sys_execve (td=0xfffff800b642b500, >> uap=0xfffffe010182cb80) at /usr/src/sys/kern/kern_exec.c:218 >> #16 0xffffffff808d449e in amd64_syscall (td=, traced=0) at >> subr_syscall.c:135 >> #17 0xffffffff808b7ddb in Xfast_syscall () at >> /usr/src/sys/amd64/amd64/exception.S:396 >> >> Thread 681 (Thread 101147): >> #0 sched_switch (td=0xfffff80065f4e500, newtd=0xfffff8000285f000, flags=> optimized out>) at /usr/src/sys/kern/sched_ule.c:1973 >> #1 0xffffffff80561ae2 in mi_switch (flags=, newtd=0x0) at >> /usr/src/sys/kern/kern_synch.c:455 >> #2 0xffffffff805ae8da in sleepq_wait (wchan=0x0, pri=0) at >> /usr/src/sys/kern/subr_sleepqueue.c:646 >> #3 0xffffffff8052f854 in sleeplk (lk=, flags=> optimized out>, ilk=, wmesg=0xffffffff813be535 "zfs", >> pri=, timo=51) at /usr/src/sys/kern/kern_lock.c:222 >> #4 0xffffffff8052f39d in __lockmgr_args (lk=, flags=> optimized out>, ilk=, wmesg=, >> pri=, timo=, file=> out>, line=) at /usr/src/sys/kern/kern_lock.c:958 >> #5 0xffffffff80616a8c in vop_stdlock (ap=) at lockmgr.h:98 >> #6 0xffffffff8093784d in VOP_LOCK1_APV (vop=, a=> optimized out>) at vnode_if.c:2087 >> #7 0xffffffff8063c5b3 in _vn_lock (vp=, flags=548864, >> file=, line=) at vnode_if.h:859 >> #8 0xffffffff8062a5f7 in vget (vp=0xfffff80049c2c000, flags=548864, >> td=0xfffff80065f4e500) at /usr/src/sys/kern/vfs_subr.c:2523 >> #9 0xffffffff806118b9 in cache_lookup (dvp=, vpp=> optimized out>, cnp=, tsp=, >> ticksp=) at /usr/src/sys/kern/vfs_cache.c:686 >> #10 0xffffffff806133dc in vfs_cache_lookup (ap=) at >> /usr/src/sys/kern/vfs_cache.c:1081 >> #11 0xffffffff80935777 in VOP_LOOKUP_APV (vop=, a=> optimized out>) at vnode_if.c:127 >> #12 0xffffffff8061cdf1 in lookup (ndp=) at vnode_if.h:54 >> #13 0xffffffff8061c492 in namei (ndp=) at >> /usr/src/sys/kern/vfs_lookup.c:306 >> #14 0xffffffff80509395 in kern_execve (td=, args=> optimized out>, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:443 >> #15 0xffffffff80508ccc in sys_execve (td=0xfffff80065f4e500, >> uap=0xfffffe01016b8b80) at /usr/src/sys/kern/kern_exec.c:218 >> #16 0xffffffff808d449e in amd64_syscall (td=, traced=0) at >> subr_syscall.c:135 >> #17 0xffffffff808b7ddb in Xfast_syscall () at >> /usr/src/sys/amd64/amd64/exception.S:396 > > This 2 threads are innd processes. In core.txt.4: > > 8 14789 29165 0 24 4 40040 6612 zfs DN - 0:00.00 [innd] > 8 29165 1 0 20 0 42496 6888 select Ds - 0:01.33 [innd] > 8 49778 29165 0 24 4 40040 6900 zfs DN - 0:00.00 [innd] > 8 82034 29165 0 24 4 132 0 zfs DN - 0:00.00 [innd] > > the corresponding info treads are: > > 687 Thread 101243 (PID=49778: innd) sched_switch (td=0xfffff800b642b500, > newtd=0xfffff8000285ea00, flags=) at > /usr/src/sys/kern/sched_ule.c:1973 > 681 Thread 101147 (PID=14789: innd) sched_switch (td=0xfffff80065f4e500, > newtd=0xfffff8000285f000, flags=) at > /usr/src/sys/kern/sched_ule.c:1973 > 669 Thread 101250 (PID=82034: innd) sched_switch (td=0xfffff800b6429000, > newtd=0xfffff8000285ea00, flags=) at > /usr/src/sys/kern/sched_ule.c:1973 > 665 Thread 101262 (PID=29165: innd) sched_switch (td=0xfffff800b6b54a00, > newtd=0xfffff8000285ea00, flags=) at > /usr/src/sys/kern/sched_ule.c:1973 > > So your missing tread must be 101250: Oh, I missed this thread... But it looks like another LK_EXCLUSIVE contender rather than the lock owner. > (kgdb) tid 101250 > [Switching to thread 669 (Thread 101250)]#0 sched_switch > (td=0xfffff800b6429000, newtd=0xfffff8000285ea00, > flags=) at /usr/src/sys/kern/sched_ule.c:1973 > 1973 cpuid = PCPU_GET(cpuid); > Current language: auto; currently minimal > (kgdb) bt > #0 sched_switch (td=0xfffff800b6429000, newtd=0xfffff8000285ea00, flags= optimized out>) > at /usr/src/sys/kern/sched_ule.c:1973 > #1 0xffffffff80561ae2 in mi_switch (flags=, newtd=0x0) at > /usr/src/sys/kern/kern_synch.c:455 > #2 0xffffffff805ae8da in sleepq_wait (wchan=0x0, pri=0) at > /usr/src/sys/kern/subr_sleepqueue.c:646 > #3 0xffffffff8052f854 in sleeplk (lk=, flags= optimized out>, ilk=, > wmesg=0xffffffff813be535 "zfs", pri=, timo=51) at > /usr/src/sys/kern/kern_lock.c:222 > #4 0xffffffff8052f39d in __lockmgr_args (lk=, flags= optimized out>, ilk=, > wmesg=, pri=, timo= optimized out>, file=, > line=) at /usr/src/sys/kern/kern_lock.c:958 > #5 0xffffffff80616a8c in vop_stdlock (ap=) at lockmgr.h:98 > #6 0xffffffff8093784d in VOP_LOCK1_APV (vop=, a= optimized out>) at vnode_if.c:2087 > #7 0xffffffff8063c5b3 in _vn_lock (vp=, flags=525312, > file=, line=) > at vnode_if.h:859 > #8 0xffffffff804e16cf in exec_elf64_imgact (imgp=) at > /usr/src/sys/kern/imgact_elf.c:899 > #9 0xffffffff8050983d in kern_execve (td=, args= optimized out>, mac_p=0x0) > at /usr/src/sys/kern/kern_exec.c:602 > #10 0xffffffff80508ccc in sys_execve (td=0xfffff800b6429000, > uap=0xfffffe010184fb80) at /usr/src/sys/kern/kern_exec.c:218 > #11 0xffffffff808d449e in amd64_syscall (td=, traced=0) at > subr_syscall.c:135 > #12 0xffffffff808b7ddb in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:396 > #13 0x000000080217edaa in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > >> >> And the original stuck thread wants to get the lock in the shared mode. >> And there should be another thread that already holds the lock in the shared >> mode. But I am not able to identify it. I wonder if the original thread could >> be trying to get the lock recursively... >> >> It would be interesting to get more details from thread 101112. >> You can switch to it using tid command, you can use 'fr' to select frames, 'info >> local' and 'info args' to see what variables are available (not optimized out) >> and the you can print any that look interesting. It would be nice to get a file >> path and a directory vnode where the lookup is called. >> >> Thank you. >> > I find nothing interresting: > > (kgdb) fr 15 [snip] Could you please show 'info local' in frame 14? I expected that 'nd' variable would be defined there and it may contain some useful information. > I also try to get information from the execve of the other treads: > > for tid 101250: > (kgdb) fr 10 > #10 0xffffffff80508ccc in sys_execve (td=0xfffff800b6429000, > uap=0xfffffe010184fb80) at /usr/src/sys/kern/kern_exec.c:218 > 218 error = kern_execve(td, &args, NULL); > (kgdb) print *uap > $4 = {fname_l_ = 0xfffffe010184fb80 "`\220\217\002\b", fname = 0x8028f9060 >
, > fname_r_ = 0xfffffe010184fb88 "`¶ÿÿÿ\177", argv_l_ = 0xfffffe010184fb88 > "`¶ÿÿÿ\177", argv = 0x7fffffffb660, > argv_r_ = 0xfffffe010184fb90 "\bÜÿÿÿ\177", envv_l_ = 0xfffffe010184fb90 > "\bÜÿÿÿ\177", envv = 0x7fffffffdc08, > envv_r_ = 0xfffffe010184fb98 ""} > (kgdb) > > for tid 101243: > > (kgdb) f 15 > #15 0xffffffff80508ccc in sys_execve (td=0xfffff800b642b500, > uap=0xfffffe010182cb80) at /usr/src/sys/kern/kern_exec.c:218 > 218 error = kern_execve(td, &args, NULL); > (kgdb) print *uap > $5 = {fname_l_ = 0xfffffe010182cb80 "ÀÏ\205\002\b", fname = 0x80285cfc0
0x80285cfc0 out of bounds>, > fname_r_ = 0xfffffe010182cb88 "`¶ÿÿÿ\177", argv_l_ = 0xfffffe010182cb88 > "`¶ÿÿÿ\177", argv = 0x7fffffffb660, > argv_r_ = 0xfffffe010182cb90 "\bÜÿÿÿ\177", envv_l_ = 0xfffffe010182cb90 > "\bÜÿÿÿ\177", envv = 0x7fffffffdc08, > envv_r_ = 0xfffffe010182cb98 ""} > (kgdb) I think that you see garbage in those structures because they contain pointers to userland data. Hmm, I've just noticed another interesting thread: Thread 668 (Thread 101245): #0 sched_switch (td=0xfffff800b642aa00, newtd=0xfffff8000285f000, flags=) at /usr/src/sys/kern/sched_ule.c:1973 #1 0xffffffff80561ae2 in mi_switch (flags=, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:455 #2 0xffffffff805ae8da in sleepq_wait (wchan=0x0, pri=0) at /usr/src/sys/kern/subr_sleepqueue.c:646 #3 0xffffffff805614b1 in _sleep (ident=, lock=, priority=, wmesg=0xffffffff809c51bc "vmpfw", sbt=0, pr=, flags=) at /usr/src/sys/kern/kern_synch.c:229 #4 0xffffffff8089d1c1 in vm_page_busy_sleep (m=0xfffff800df68cd40, wmesg=) at /usr/src/sys/vm/vm_page.c:753 #5 0xffffffff8089dd4d in vm_page_sleep_if_busy (m=0xfffff800df68cd40, msg=0xffffffff809c51bc "vmpfw") at /usr/src/sys/vm/vm_page.c:1086 #6 0xffffffff80886be9 in vm_fault_hold (map=, vaddr=, fault_type=4 '\004', fault_flags=0, m_hold=0x0) at /usr/src/sys/vm/vm_fault.c:495 #7 0xffffffff80885448 in vm_fault (map=0xfffff80011d66000, vaddr=, fault_type=4 '\004', fault_flags=) at /usr/src/sys/vm/vm_fault.c:273 #8 0xffffffff808d3c49 in trap_pfault (frame=0xfffffe0101836c00, usermode=1) at /usr/src/sys/amd64/amd64/trap.c:741 #9 0xffffffff808d3386 in trap (frame=0xfffffe0101836c00) at /usr/src/sys/amd64/amd64/trap.c:333 #10 0xffffffff808b7af1 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236 I strongly suspect that this is thread that we were looking for. I think that it has the vnode lock in the shared mode while trying to fault in a page. Could you please check that by going to frame 6 and printing 'fs' and '*fs.vp'? It'd be interesting to understand why this thread is waiting here. So, please also print '*fs.m' and '*fs.object'. Thanks! -- Andriy Gapon From owner-freebsd-stable@freebsd.org Mon Nov 14 09:35:24 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6DA6CC40DD3 for ; Mon, 14 Nov 2016 09:35:24 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:8:bdbe:0:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A9F71528; Mon, 14 Nov 2016 09:35:24 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=2001:41d0:8:bdbe:1:1::; helo=restart.be; envelope-from=hlh@restart.be; receiver=avg@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3tHQNp0kCRzsPf DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=restart.be; s=tignes; t=1479116122; bh=sGwCldBiIZP1LhTxj85bafc7iu8V8yUcw5azYmngvNI=; h=Subject:To:References:Cc:From:Date:In-Reply-To; z=Subject:=20Re:=20Freebsd=2011.0=20RELEASE=20-=20ZFS=20deadlock|To :=20Andriy=20Gapon=20,=20freebsd-stable@FreeBSD.o rg|References:=20<0c223160-b76f-c635-bb15-4a068ba7efe7@restart.be> =0D=0A=20=0D=0A= 20<43c9d4d4-1995-5626-d70a-f92a5b456629@FreeBSD.org>=0D=0A=20=0D=0A=20<9d1f9a76-5a8 d-6eca-9a50-907d55099847@FreeBSD.org>=0D=0A=20<6bc95dce-31e1-3013- bfe3-7c2dd80f9d1e@restart.be>=0D=0A=20=0D=0A=20<23a66749-f138-1f1a-afae-c775f906ff 37@restart.be>=0D=0A=20<8e7547ef-87f7-7fab-6f45-221e8cea1989@FreeB SD.org>=0D=0A=20<6d991cea-b420-531e-12cc-001e4aeed66b@restart.be>= 0D=0A=20<67f2e8bd-bff0-f808-7557-7dabe5cad78c@FreeBSD.org>=0D=0A=2 0<1cb09c54-5f0e-2259-a41a-fefe76b4fe8b@restart.be>=0D=0A=20=0D=0A=20<9f20020b-e2f1 -862b-c3fc-dc6ff94e301e@restart.be>=0D=0A=20=0D=0A=20<599c5a5b-aa08-2030-34f3-23ff 19d09a9b@restart.be>=0D=0A=20<32686283-948a-6faf-7ded-ed8fcd23affb @FreeBSD.org>=0D=0A=20=0D=0A=20|C c:=20Konstantin=20Belousov=20|From:=20Henri=20Hen nebert=20|Date:=20Mon,=2014=20Nov=202016=2010:35:2 0=20+0100|In-Reply-To:=20; b=lwFiqlAZ4R1FuXCJxo91/czDMCKXY+HxjwpvKqhir9LMQmWjVjxRrGj+bpnU/5gPa PPyqF++8GX+4E1jde+sJytc3wimUmxP0NfoYRk0VZ9VXLLJhguNhyOSfTsD4Lwn7r6 aHOhxU/HHzMWiyv9uu4pCc8UNlrPml9qn+LDqaXZPevnY7pULMZ3qsRWrEu1wobyKr B/rALC/230w0C84yh0Yg12jRt/Ys5F+sNLKRInkcdxpH4sTa+aV5CcBzCkFYfk5b4Z Mbgd1XOQ9RJzZP5LW9sTZ89Mb99uAADxDB9KtGy7AMAoqWI89tY1hsbx3HN1jguewq PD4H+sq95hhOQ== Received: from restart.be (avoriaz.restart.be [IPv6:2001:41d0:8:bdbe:1:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3tHQNp0kCRzsPf; Mon, 14 Nov 2016 10:35:21 +0100 (CET) Received: from chamonix.restart.bel (chamonix.restart.bel [IPv6:2001:41d0:8:bdbe:1:9:0:0]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id uAE9ZKdG098099 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 14 Nov 2016 10:35:21 +0100 (CET) (envelope-from hlh@restart.be) Subject: Re: Freebsd 11.0 RELEASE - ZFS deadlock To: Andriy Gapon , freebsd-stable@FreeBSD.org References: <0c223160-b76f-c635-bb15-4a068ba7efe7@restart.be> <43c9d4d4-1995-5626-d70a-f92a5b456629@FreeBSD.org> <9d1f9a76-5a8d-6eca-9a50-907d55099847@FreeBSD.org> <6bc95dce-31e1-3013-bfe3-7c2dd80f9d1e@restart.be> <23a66749-f138-1f1a-afae-c775f906ff37@restart.be> <8e7547ef-87f7-7fab-6f45-221e8cea1989@FreeBSD.org> <6d991cea-b420-531e-12cc-001e4aeed66b@restart.be> <67f2e8bd-bff0-f808-7557-7dabe5cad78c@FreeBSD.org> <1cb09c54-5f0e-2259-a41a-fefe76b4fe8b@restart.be> <9f20020b-e2f1-862b-c3fc-dc6ff94e301e@restart.be> <599c5a5b-aa08-2030-34f3-23ff19d09a9b@restart.be> <32686283-948a-6faf-7ded-ed8fcd23affb@FreeBSD.org> Cc: Konstantin Belousov From: Henri Hennebert Message-ID: <26512d69-94c2-92da-e3ea-50aebf17e3a0@restart.be> Date: Mon, 14 Nov 2016 10:35:20 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 09:35:24 -0000 On 11/14/2016 10:07, Andriy Gapon wrote: > On 13/11/2016 15:28, Henri Hennebert wrote: >> On 11/13/2016 11:06, Andriy Gapon wrote: >>> On 12/11/2016 14:40, Henri Hennebert wrote: > [snip] > > Could you please show 'info local' in frame 14? > I expected that 'nd' variable would be defined there and it may contain some > useful information. > No luck there: (kgdb) fr 14 #14 0xffffffff80636838 in kern_statat (td=0xfffff80009ba0500, flag=, fd=-100, path=0x0, pathseg=, sbp=, hook=0x800e2a388) at /usr/src/sys/kern/vfs_syscalls.c:2160 2160 if ((error = namei(&nd)) != 0) (kgdb) info local rights = nd = error = sb = (kgdb) >> I also try to get information from the execve of the other treads: >> >> for tid 101250: >> (kgdb) fr 10 >> #10 0xffffffff80508ccc in sys_execve (td=0xfffff800b6429000, >> uap=0xfffffe010184fb80) at /usr/src/sys/kern/kern_exec.c:218 >> 218 error = kern_execve(td, &args, NULL); >> (kgdb) print *uap >> $4 = {fname_l_ = 0xfffffe010184fb80 "`\220\217\002\b", fname = 0x8028f9060 >>
, >> fname_r_ = 0xfffffe010184fb88 "`¶ÿÿÿ\177", argv_l_ = 0xfffffe010184fb88 >> "`¶ÿÿÿ\177", argv = 0x7fffffffb660, >> argv_r_ = 0xfffffe010184fb90 "\bÜÿÿÿ\177", envv_l_ = 0xfffffe010184fb90 >> "\bÜÿÿÿ\177", envv = 0x7fffffffdc08, >> envv_r_ = 0xfffffe010184fb98 ""} >> (kgdb) >> >> for tid 101243: >> >> (kgdb) f 15 >> #15 0xffffffff80508ccc in sys_execve (td=0xfffff800b642b500, >> uap=0xfffffe010182cb80) at /usr/src/sys/kern/kern_exec.c:218 >> 218 error = kern_execve(td, &args, NULL); >> (kgdb) print *uap >> $5 = {fname_l_ = 0xfffffe010182cb80 "ÀÏ\205\002\b", fname = 0x80285cfc0
> 0x80285cfc0 out of bounds>, >> fname_r_ = 0xfffffe010182cb88 "`¶ÿÿÿ\177", argv_l_ = 0xfffffe010182cb88 >> "`¶ÿÿÿ\177", argv = 0x7fffffffb660, >> argv_r_ = 0xfffffe010182cb90 "\bÜÿÿÿ\177", envv_l_ = 0xfffffe010182cb90 >> "\bÜÿÿÿ\177", envv = 0x7fffffffdc08, >> envv_r_ = 0xfffffe010182cb98 ""} >> (kgdb) > > I think that you see garbage in those structures because they contain pointers > to userland data. > > Hmm, I've just noticed another interesting thread: > Thread 668 (Thread 101245): > #0 sched_switch (td=0xfffff800b642aa00, newtd=0xfffff8000285f000, flags= optimized out>) at /usr/src/sys/kern/sched_ule.c:1973 > #1 0xffffffff80561ae2 in mi_switch (flags=, newtd=0x0) at > /usr/src/sys/kern/kern_synch.c:455 > #2 0xffffffff805ae8da in sleepq_wait (wchan=0x0, pri=0) at > /usr/src/sys/kern/subr_sleepqueue.c:646 > #3 0xffffffff805614b1 in _sleep (ident=, lock= optimized out>, priority=, wmesg=0xffffffff809c51bc > "vmpfw", sbt=0, pr=, flags=) at > /usr/src/sys/kern/kern_synch.c:229 > #4 0xffffffff8089d1c1 in vm_page_busy_sleep (m=0xfffff800df68cd40, wmesg= optimized out>) at /usr/src/sys/vm/vm_page.c:753 > #5 0xffffffff8089dd4d in vm_page_sleep_if_busy (m=0xfffff800df68cd40, > msg=0xffffffff809c51bc "vmpfw") at /usr/src/sys/vm/vm_page.c:1086 > #6 0xffffffff80886be9 in vm_fault_hold (map=, vaddr= optimized out>, fault_type=4 '\004', fault_flags=0, m_hold=0x0) at > /usr/src/sys/vm/vm_fault.c:495 > #7 0xffffffff80885448 in vm_fault (map=0xfffff80011d66000, vaddr= optimized out>, fault_type=4 '\004', fault_flags=) at > /usr/src/sys/vm/vm_fault.c:273 > #8 0xffffffff808d3c49 in trap_pfault (frame=0xfffffe0101836c00, usermode=1) at > /usr/src/sys/amd64/amd64/trap.c:741 > #9 0xffffffff808d3386 in trap (frame=0xfffffe0101836c00) at > /usr/src/sys/amd64/amd64/trap.c:333 > #10 0xffffffff808b7af1 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236 This tread is another program from the news system: 668 Thread 101245 (PID=49124: innfeed) sched_switch (td=0xfffff800b642aa00, newtd=0xfffff8000285f000, flags=) at /usr/src/sys/kern/sched_ule.c:1973 > > I strongly suspect that this is thread that we were looking for. > I think that it has the vnode lock in the shared mode while trying to fault in a > page. > > Could you please check that by going to frame 6 and printing 'fs' and '*fs.vp'? > It'd be interesting to understand why this thread is waiting here. > So, please also print '*fs.m' and '*fs.object'. No luck :-( (kgdb) fr 6 #6 0xffffffff80886be9 in vm_fault_hold (map=, vaddr=, fault_type=4 '\004', fault_flags=0, m_hold=0x0) at /usr/src/sys/vm/vm_fault.c:495 495 vm_page_sleep_if_busy(fs.m, "vmpfw"); (kgdb) print fs Cannot access memory at address 0xffff00001fa0 (kgdb) Henri From owner-freebsd-stable@freebsd.org Mon Nov 14 11:46:57 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34A0CC41744 for ; Mon, 14 Nov 2016 11:46:57 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5DFC99B3; Mon, 14 Nov 2016 11:46:55 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA03430; Mon, 14 Nov 2016 13:46:54 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1c6Fiw-000COu-Fq; Mon, 14 Nov 2016 13:46:54 +0200 Subject: Re: Freebsd 11.0 RELEASE - ZFS deadlock To: Henri Hennebert , freebsd-stable@FreeBSD.org References: <0c223160-b76f-c635-bb15-4a068ba7efe7@restart.be> <43c9d4d4-1995-5626-d70a-f92a5b456629@FreeBSD.org> <9d1f9a76-5a8d-6eca-9a50-907d55099847@FreeBSD.org> <6bc95dce-31e1-3013-bfe3-7c2dd80f9d1e@restart.be> <23a66749-f138-1f1a-afae-c775f906ff37@restart.be> <8e7547ef-87f7-7fab-6f45-221e8cea1989@FreeBSD.org> <6d991cea-b420-531e-12cc-001e4aeed66b@restart.be> <67f2e8bd-bff0-f808-7557-7dabe5cad78c@FreeBSD.org> <1cb09c54-5f0e-2259-a41a-fefe76b4fe8b@restart.be> <9f20020b-e2f1-862b-c3fc-dc6ff94e301e@restart.be> <599c5a5b-aa08-2030-34f3-23ff19d09a9b@restart.be> <32686283-948a-6faf-7ded-ed8fcd23affb@FreeBSD.org> <26512d69-94c2-92da-e3ea-50aebf17e3a0@restart.be> Cc: Konstantin Belousov From: Andriy Gapon Message-ID: Date: Mon, 14 Nov 2016 13:45:58 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <26512d69-94c2-92da-e3ea-50aebf17e3a0@restart.be> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 11:46:57 -0000 On 14/11/2016 11:35, Henri Hennebert wrote: > > > On 11/14/2016 10:07, Andriy Gapon wrote: >> Hmm, I've just noticed another interesting thread: >> Thread 668 (Thread 101245): >> #0 sched_switch (td=0xfffff800b642aa00, newtd=0xfffff8000285f000, flags=> optimized out>) at /usr/src/sys/kern/sched_ule.c:1973 >> #1 0xffffffff80561ae2 in mi_switch (flags=, newtd=0x0) at >> /usr/src/sys/kern/kern_synch.c:455 >> #2 0xffffffff805ae8da in sleepq_wait (wchan=0x0, pri=0) at >> /usr/src/sys/kern/subr_sleepqueue.c:646 >> #3 0xffffffff805614b1 in _sleep (ident=, lock=> optimized out>, priority=, wmesg=0xffffffff809c51bc >> "vmpfw", sbt=0, pr=, flags=) at >> /usr/src/sys/kern/kern_synch.c:229 >> #4 0xffffffff8089d1c1 in vm_page_busy_sleep (m=0xfffff800df68cd40, wmesg=> optimized out>) at /usr/src/sys/vm/vm_page.c:753 >> #5 0xffffffff8089dd4d in vm_page_sleep_if_busy (m=0xfffff800df68cd40, >> msg=0xffffffff809c51bc "vmpfw") at /usr/src/sys/vm/vm_page.c:1086 >> #6 0xffffffff80886be9 in vm_fault_hold (map=, vaddr=> optimized out>, fault_type=4 '\004', fault_flags=0, m_hold=0x0) at >> /usr/src/sys/vm/vm_fault.c:495 >> #7 0xffffffff80885448 in vm_fault (map=0xfffff80011d66000, vaddr=> optimized out>, fault_type=4 '\004', fault_flags=) at >> /usr/src/sys/vm/vm_fault.c:273 >> #8 0xffffffff808d3c49 in trap_pfault (frame=0xfffffe0101836c00, usermode=1) at >> /usr/src/sys/amd64/amd64/trap.c:741 >> #9 0xffffffff808d3386 in trap (frame=0xfffffe0101836c00) at >> /usr/src/sys/amd64/amd64/trap.c:333 >> #10 0xffffffff808b7af1 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236 > > This tread is another program from the news system: > 668 Thread 101245 (PID=49124: innfeed) sched_switch (td=0xfffff800b642aa00, > newtd=0xfffff8000285f000, flags=) at > /usr/src/sys/kern/sched_ule.c:1973 > >> >> I strongly suspect that this is thread that we were looking for. >> I think that it has the vnode lock in the shared mode while trying to fault in a >> page. >> >> Could you please check that by going to frame 6 and printing 'fs' and '*fs.vp'? >> It'd be interesting to understand why this thread is waiting here. >> So, please also print '*fs.m' and '*fs.object'. > > No luck :-( > (kgdb) fr 6 > #6 0xffffffff80886be9 in vm_fault_hold (map=, vaddr= optimized out>, fault_type=4 '\004', > fault_flags=0, m_hold=0x0) at /usr/src/sys/vm/vm_fault.c:495 > 495 vm_page_sleep_if_busy(fs.m, "vmpfw"); > (kgdb) print fs > Cannot access memory at address 0xffff00001fa0 > (kgdb) Okay. Luckily for us, it seems that 'm' is available in frame 5. It also happens to be the first field of 'struct faultstate'. So, could you please go to frame and print '*m' and '*(struct faultstate *)m' ? -- Andriy Gapon From owner-freebsd-stable@freebsd.org Mon Nov 14 12:01:01 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69BEFC40263 for ; Mon, 14 Nov 2016 12:01:01 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:8:bdbe:0:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8899814A3; Mon, 14 Nov 2016 12:01:00 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=2001:41d0:8:bdbe:1:1::; helo=restart.be; envelope-from=hlh@restart.be; receiver=avg@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3tHTcp5zKczrdg DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=restart.be; s=tignes; t=1479124858; bh=huVPyPuglABUTT8SnByPhsXlXFzpkJeVpdYI84EI128=; h=Subject:To:References:Cc:From:Date:In-Reply-To; z=Subject:=20Re:=20Freebsd=2011.0=20RELEASE=20-=20ZFS=20deadlock|To :=20Andriy=20Gapon=20,=20freebsd-stable@FreeBSD.o rg|References:=20<0c223160-b76f-c635-bb15-4a068ba7efe7@restart.be> =0D=0A=20=0D=0A=2 0<9d1f9a76-5a8d-6eca-9a50-907d55099847@FreeBSD.org>=0D=0A=20<6bc95 dce-31e1-3013-bfe3-7c2dd80f9d1e@restart.be>=0D=0A=20=0D=0A=20<23a66749-f138-1f1a-a fae-c775f906ff37@restart.be>=0D=0A=20<8e7547ef-87f7-7fab-6f45-221e 8cea1989@FreeBSD.org>=0D=0A=20<6d991cea-b420-531e-12cc-001e4aeed66 b@restart.be>=0D=0A=20<67f2e8bd-bff0-f808-7557-7dabe5cad78c@FreeBS D.org>=0D=0A=20<1cb09c54-5f0e-2259-a41a-fefe76b4fe8b@restart.be>=0 D=0A=20=0D=0A=20 <9f20020b-e2f1-862b-c3fc-dc6ff94e301e@restart.be>=0D=0A=20=0D=0A=20<599c5a5b-aa08- 2030-34f3-23ff19d09a9b@restart.be>=0D=0A=20<32686283-948a-6faf-7de d-ed8fcd23affb@FreeBSD.org>=0D=0A=20=0D=0A=20=0D=0A=20<26512d69-94c2-92da-e3ea-50aebf17e3a0@restart .be>=0D=0A=20|Cc :=20Konstantin=20Belousov=20|From:=20Henri=20Henn ebert=20|Date:=20Mon,=2014=20Nov=202016=2013:00:57 =20+0100|In-Reply-To:=20; b=18Zc48vZxB1BQnjLEh1/RV4KKxi/KpZz0v+jr6VIwHMb9jqGqFFuV+M7R0ODaFgLl DAmDcKThRMpMKJEGXVWS0uaTpIg7aY//MsU6vX0vgZ/JvhIdUzYh7jn2ez3UPt8L5E dhboXHa4ACgiIBnETvOtNDtRKzjKazyaoT/g1RXxTAK8KD4Y8piok6XfzPhTn4ItZG zXNdyhPkgPz2/okOv79CFMOyP6bway/SHoxOf9VmIfREsBi7cOypDQl+pj2jXFfAbZ TGKLOr7UOujWnH7TKzzcPkToRJRuc9lugNCV5+BUlldynG3mIwcHWabn5+5tmdnEFS +CZ1nv1oWuIeA== Received: from restart.be (avoriaz.restart.be [IPv6:2001:41d0:8:bdbe:1:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3tHTcp5zKczrdg; Mon, 14 Nov 2016 13:00:58 +0100 (CET) Received: from chamonix.restart.bel (chamonix.restart.bel [IPv6:2001:41d0:8:bdbe:1:9:0:0]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id uAEC0vki001592 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 14 Nov 2016 13:00:57 +0100 (CET) (envelope-from hlh@restart.be) Subject: Re: Freebsd 11.0 RELEASE - ZFS deadlock To: Andriy Gapon , freebsd-stable@FreeBSD.org References: <0c223160-b76f-c635-bb15-4a068ba7efe7@restart.be> <9d1f9a76-5a8d-6eca-9a50-907d55099847@FreeBSD.org> <6bc95dce-31e1-3013-bfe3-7c2dd80f9d1e@restart.be> <23a66749-f138-1f1a-afae-c775f906ff37@restart.be> <8e7547ef-87f7-7fab-6f45-221e8cea1989@FreeBSD.org> <6d991cea-b420-531e-12cc-001e4aeed66b@restart.be> <67f2e8bd-bff0-f808-7557-7dabe5cad78c@FreeBSD.org> <1cb09c54-5f0e-2259-a41a-fefe76b4fe8b@restart.be> <9f20020b-e2f1-862b-c3fc-dc6ff94e301e@restart.be> <599c5a5b-aa08-2030-34f3-23ff19d09a9b@restart.be> <32686283-948a-6faf-7ded-ed8fcd23affb@FreeBSD.org> <26512d69-94c2-92da-e3ea-50aebf17e3a0@restart.be> Cc: Konstantin Belousov From: Henri Hennebert Message-ID: <80f65c86-1015-c409-1bf6-c01a5fe569c8@restart.be> Date: Mon, 14 Nov 2016 13:00:57 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 12:01:01 -0000 On 11/14/2016 12:45, Andriy Gapon wrote: > On 14/11/2016 11:35, Henri Hennebert wrote: >> >> >> On 11/14/2016 10:07, Andriy Gapon wrote: >>> Hmm, I've just noticed another interesting thread: >>> Thread 668 (Thread 101245): >>> #0 sched_switch (td=0xfffff800b642aa00, newtd=0xfffff8000285f000, flags=>> optimized out>) at /usr/src/sys/kern/sched_ule.c:1973 >>> #1 0xffffffff80561ae2 in mi_switch (flags=, newtd=0x0) at >>> /usr/src/sys/kern/kern_synch.c:455 >>> #2 0xffffffff805ae8da in sleepq_wait (wchan=0x0, pri=0) at >>> /usr/src/sys/kern/subr_sleepqueue.c:646 >>> #3 0xffffffff805614b1 in _sleep (ident=, lock=>> optimized out>, priority=, wmesg=0xffffffff809c51bc >>> "vmpfw", sbt=0, pr=, flags=) at >>> /usr/src/sys/kern/kern_synch.c:229 >>> #4 0xffffffff8089d1c1 in vm_page_busy_sleep (m=0xfffff800df68cd40, wmesg=>> optimized out>) at /usr/src/sys/vm/vm_page.c:753 >>> #5 0xffffffff8089dd4d in vm_page_sleep_if_busy (m=0xfffff800df68cd40, >>> msg=0xffffffff809c51bc "vmpfw") at /usr/src/sys/vm/vm_page.c:1086 >>> #6 0xffffffff80886be9 in vm_fault_hold (map=, vaddr=>> optimized out>, fault_type=4 '\004', fault_flags=0, m_hold=0x0) at >>> /usr/src/sys/vm/vm_fault.c:495 >>> #7 0xffffffff80885448 in vm_fault (map=0xfffff80011d66000, vaddr=>> optimized out>, fault_type=4 '\004', fault_flags=) at >>> /usr/src/sys/vm/vm_fault.c:273 >>> #8 0xffffffff808d3c49 in trap_pfault (frame=0xfffffe0101836c00, usermode=1) at >>> /usr/src/sys/amd64/amd64/trap.c:741 >>> #9 0xffffffff808d3386 in trap (frame=0xfffffe0101836c00) at >>> /usr/src/sys/amd64/amd64/trap.c:333 >>> #10 0xffffffff808b7af1 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236 >> >> This tread is another program from the news system: >> 668 Thread 101245 (PID=49124: innfeed) sched_switch (td=0xfffff800b642aa00, >> newtd=0xfffff8000285f000, flags=) at >> /usr/src/sys/kern/sched_ule.c:1973 >> >>> >>> I strongly suspect that this is thread that we were looking for. >>> I think that it has the vnode lock in the shared mode while trying to fault in a >>> page. >>> --clip-- > > Okay. Luckily for us, it seems that 'm' is available in frame 5. It also > happens to be the first field of 'struct faultstate'. So, could you please go > to frame and print '*m' and '*(struct faultstate *)m' ? > (kgdb) fr 4 #4 0xffffffff8089d1c1 in vm_page_busy_sleep (m=0xfffff800df68cd40, wmesg=) at /usr/src/sys/vm/vm_page.c:753 753 msleep(m, vm_page_lockptr(m), PVM | PDROP, wmesg, 0); (kgdb) print *m $1 = {plinks = {q = {tqe_next = 0xfffff800dc5d85b0, tqe_prev = 0xfffff800debf3bd0}, s = {ss = {sle_next = 0xfffff800dc5d85b0}, pv = 0xfffff800debf3bd0}, memguard = {p = 18446735281313646000, v = 18446735281353604048}}, listq = {tqe_next = 0x0, tqe_prev = 0xfffff800dc5d85c0}, object = 0xfffff800b62e9c60, pindex = 11, phys_addr = 3389358080, md = {pv_list = { tqh_first = 0x0, tqh_last = 0xfffff800df68cd78}, pv_gen = 426, pat_mode = 6}, wire_count = 0, busy_lock = 6, hold_count = 0, flags = 0, aflags = 2 '\002', oflags = 0 '\0', queue = 0 '\0', psind = 0 '\0', segind = 3 '\003', order = 13 '\r', pool = 0 '\0', act_count = 0 '\0', valid = 0 '\0', dirty = 0 '\0'} (kgdb) print *(struct faultstate *)m $2 = {m = 0xfffff800dc5d85b0, object = 0xfffff800debf3bd0, pindex = 0, first_m = 0xfffff800dc5d85c0, first_object = 0xfffff800b62e9c60, first_pindex = 11, map = 0xca058000, entry = 0x0, lookup_still_valid = -546779784, vp = 0x6000001aa} (kgdb) From owner-freebsd-stable@freebsd.org Mon Nov 14 17:06:30 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51AA5C415A3 for ; Mon, 14 Nov 2016 17:06:30 +0000 (UTC) (envelope-from felix.the.red@gmail.com) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 0BBAFC72 for ; Mon, 14 Nov 2016 17:06:30 +0000 (UTC) (envelope-from felix.the.red@gmail.com) Received: by mail-qk0-x22c.google.com with SMTP id q130so103276074qke.1 for ; Mon, 14 Nov 2016 09:06: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:from:date:message-id:subject:to :cc; bh=3BCKaQyWrXiO5/1iekJycKJVDMDiTrlEmIGuP7rubMI=; b=oEjlKfNrGmNZSjYihy+x8rT7XVs1/hwqaXQHBByqQi5Z7udxsBoELqOO2qtPPKhLYx MO2aGJRREon2UgzEKy0wk9Pa3DNDoAWqzWfPduiO6eT9EVOyUbHlp8Vst4c+j5kRmHbB 3sjLbDgrxslPjx6h7DfKE8h3jhrpoKtBvN/KvrEZJICc0WXUqOOfJYaJzMbbWQWRfnbi BCb3/BHds4FDLOijFEBffamtiOpmxMIakOUShXq/NZJA06ESU3yrt+ZJ4pBJ3FGwPjWL oYawQneftBXJ9RhQH4zq3o9nNNifXLEA4fHG9tgxf6nUbodMj+VP7itD557u5NijQyAC ii2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3BCKaQyWrXiO5/1iekJycKJVDMDiTrlEmIGuP7rubMI=; b=H+NI7TvELwzNSOQ5ujI87kUEbIV16nKVzBK0m0ZIVyFHE64O3yZ0XL/cqjAROg7OuM ECxttK+kW+gM7/ENPDqVCvMrDeayKir2Nc+15Y7y54JNozx/ZT4lbtCl4F4ALtxRzhhK gcwW5CtxYONvYjsjliWHysydXvcCxD0TFVO/VJnqXhtsPVEdIZSwF9iNADz9cTQssH/a hFTKLo0Rm39O/ZJ2HGmAoZ8OKsn7/+mCwuynsR+c5KbIQhwRNx7ptnmqdv78TKiOMsHF oeDZC2jd9j/q3btzsVO/is8taBTLFTk4/bO5Ht4kKMEiiz2K+zxacXwVuLdgApQ8g5B8 GD7A== X-Gm-Message-State: ABUngvd4BNyunSRdZ5XxaUXV9V6DWP3dNOnUFfA7ur5+F0l1A9wjQFudRsvO/wJGJyBAJ/h0NxhQVFqHkkEcCw== X-Received: by 10.55.17.206 with SMTP id 75mr16561206qkr.10.1479143189063; Mon, 14 Nov 2016 09:06:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.30.53 with HTTP; Mon, 14 Nov 2016 09:06:28 -0800 (PST) In-Reply-To: References: From: Felix Johnson Date: Mon, 14 Nov 2016 07:06:28 -1000 Message-ID: Subject: Re: Problems with Dell external USB DVD drive To: Kevin Oberman Cc: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 17:06:30 -0000 Hi Kevin, The drive was plugged in when I used usbconfig. When I plug the drive in, the drive makes a powering-up noise, as if it's trying to align with a disk that may be inside it. Unfortunately, there are no console messages. I've tried the USB 2 and USB 3 ports, with no change - the device powers up but there is no console message. Besides usbconfig, is there another command I can try to probe individual USB ports? Felix Johnson On Sun, Nov 13, 2016 at 9:10 PM, Kevin Oberman wrote: > On Sun, Nov 13, 2016 at 5:56 PM, Felix Johnson > wrote: > >> Hello, >> >> I have a Dell Inspiron 7547, which lacks an internal CD/DVD drive. >> I purchased a Dell DW514 external USB DVD drive, which works in Windows, >> but can't be located in FreeBSD 11.0-p2. I am looking for help in getting >> FreeBSD >> to recognize the device. >> >> Any help is appreciated, since this is an important step to using this >> laptop >> full-time as a FreeBSD workstation. >> >> Here is the information I have on my system: >> >> [fjohnson@laptop /usr/home/fjohnson]$ uname -a >> FreeBSD laptop 11.0-RELEASE-p2 FreeBSD 11.0-RELEASE-p2 #0: Mon Oct 24 >> 06:55:27 UTC 2016 >> root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC >> amd64 >> >> [fjohnson@laptop /usr/home/fjohnson]$ sudo usbconfig >> ugen0.1: at usbus0, cfg=0 md=HOST spd=SUPER >> (5.0Gbps) pwr=SAVE (0mA) >> ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) >> pwr=SAVE (0mA) >> ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH >> (480Mbps) pwr=SAVE (100mA) >> ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH >> (480Mbps) pwr=SAVE (0mA) >> ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL >> (12Mbps) >> pwr=ON (98mA) >> ugen0.4: at usbus0, cfg=0 md=HOST spd=HIGH >> (480Mbps) pwr=ON (450mA) >> ugen0.5: at usbus0, cfg=0 md=HOST spd=HIGH >> (480Mbps) pwr=ON (500mA) >> ugen0.6: at usbus0, cfg=0 md=HOST spd=HIGH >> (480Mbps) pwr=ON (500mA) >> ugen0.7: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) >> pwr=ON (100mA) >> >> [...] >> > > >> Thank you! >> Felix Johnson >> > > Can I assume that the drive was plugged in when the usbconfig command was > issued? I don't see any indication of it in the output. I was expecting a > vendor/product that was not known to the system, but that does nto appear > to be the case. the only two not identified have and the first in an Intel > vendor ID and the second appears to be an Asix Ethernet controller, though > the information on that is sketchy. > > When you plug in the drive, the console should show a message. A similar > message should be sent when it is unplugged. Can you try that and report > the message? It should include the vendor and product IDs. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > From owner-freebsd-stable@freebsd.org Tue Nov 15 04:14:46 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D8B8C42C78 for ; Tue, 15 Nov 2016 04:14:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-30.reflexion.net [208.70.210.30]) (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 3379C1768 for ; Tue, 15 Nov 2016 04:14:45 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21637 invoked from network); 15 Nov 2016 03:49:04 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 15 Nov 2016 03:49:04 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.10.2) with SMTP; Mon, 14 Nov 2016 22:48:09 -0500 (EST) Received: (qmail 16124 invoked from network); 15 Nov 2016 03:48:07 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Nov 2016 03:48:07 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id ED067EC7B30; Mon, 14 Nov 2016 19:48:02 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: stable/11 -r308135 Build for RPI2 failed for: . . ./bcm2835_ft5406.c:65:10: fatal error: 'mbox_if.h' file not found [Fixed] From: Mark Millard In-Reply-To: <8400BD9A-E08C-4578-8409-274B1BC30C98@dsl-only.net> Date: Mon, 14 Nov 2016 19:48:02 -0800 Cc: FreeBSD Toolchain , Bryan Drewery Content-Transfer-Encoding: quoted-printable Message-Id: <0DCE9672-3FD4-4CC0-9B2A-6E25A21F83ED@dsl-only.net> References: <8400BD9A-E08C-4578-8409-274B1BC30C98@dsl-only.net> To: freebsd-arm , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 04:14:46 -0000 On 2016-Nov-2, at 12:16 PM, Mark Millard wrote: > Quick top post reporting that a build-order-race for -j use seems = likely: the clean-then-build sequence >=20 >> Command: env __MAKE_CONF=3D/root/src.configs/make.conf = SRC_ENV_CONF=3D/root/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host = WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/rpi2_clang make = cleanworld >>=20 >> Command: env __MAKE_CONF=3D/root/src.configs/make.conf = SRC_ENV_CONF=3D/root/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host = WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/rpi2_clang make -j 5 = buildworld buildkernel >=20 > that used -j 5 for buildworld buildkernel got the problem again. But = following that failure by doing just buildkernel without the -j 5: >=20 >> Command: env __MAKE_CONF=3D/root/src.configs/make.conf = SRC_ENV_CONF=3D/root/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host = WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/rpi2_clang make = buildkernel >=20 > completed the rest of the build just fine, creating the = previously-missing file before trying to use it. >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Nov-2, at 3:13 AM, Mark Millard = wrote: >=20 >> Lack of dependency? Race? (I've not isolated why this happened yet = but I was using -j 5 for buildworld buildkernel .) >>=20 >> This was a cross-build attempt from an amd64 context: >>=20 >> # uname -apKU >> FreeBSD FreeBSDx64 11.0-STABLE FreeBSD 11.0-STABLE #1 r308135M: Tue = Nov 1 23:48:47 PDT 2016 = root@FreeBSDx64:/usr/obj/amd64_clang/amd64.amd64/usr/src/sys/GENERIC-NODBG= amd64 amd64 1100506 1100506 >>=20 >> # svnlite info /usr/src/ | grep "Re[lv]" >> Relative URL: ^/stable/11 >> Revision: 308135 >> Last Changed Rev: 308135 >>=20 >> # find /usr/src/sys/ -name "*files*" -exec grep mbox_if {} \; -print = | more >> dev/mbox/mbox_if.m standard >> /usr/src/sys/arm/broadcom/bcm2835/files.bcm283x >> dev/mbox/mbox_if.m optional = ti_mbox >> /usr/src/sys/arm/ti/files.ti >>=20 >> # find /usr/obj/rpi2_clang/arm.armv6/ -name mbox_if.h -print | more = = = =20 >> # >>=20 >> (So no mbox_if.h file is present in the build tree.) >>=20 >> # head = ~/sys_typescripts/typescript_make_rpi2_nodebug_clang_bootstrap-amd64-host-= 2016-11-02:00:59:43 >> Script started on Wed Nov 2 00:59:43 2016 >> Command: env __MAKE_CONF=3D/root/src.configs/make.conf = SRC_ENV_CONF=3D/root/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host = WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/rpi2_clang make -j 5 = buildworld buildkernel >> . . . >> --- all_subdir_rpi_ft5406 --- >> --- bcm2835_ft5406.o --- >> = /usr/src/sys/modules/rpi_ft5406/../../arm/broadcom/bcm2835//bcm2835_ft5406= .c:65:10: fatal error: 'mbox_if.h' file not found >> #include "mbox_if.h" >> ^ >> 1 error generated. >> *** [bcm2835_ft5406.o] Error code 1 . . . Looks like stable/11 -r308655 fix this. (-r308581 for head.) : Author: gonzo Date: Mon Nov 14 22:39:33 2016 New Revision: 308655 URL:=20 https://svnweb.freebsd.org/changeset/base/308655 Log: MFC r308581: =20 [rpi_ft5406] Add missing dependency on mbox_if.h =20 Submitted by: hselasky Modified: stable/11/sys/modules/rpi_ft5406/Makefile Directory Properties: stable/11/ (props changed) Modified: stable/11/sys/modules/rpi_ft5406/Makefile = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- stable/11/sys/modules/rpi_ft5406/Makefile Mon Nov 14 22:33:57 2016 = (r308654) +++ stable/11/sys/modules/rpi_ft5406/Makefile Mon Nov 14 22:39:33 2016 = (r308655) @@ -5,6 +5,6 @@ KMOD=3D rpi_ft5406 SRCS=3D bcm2835_ft5406.c =20 -SRCS+=3D bus_if.h device_if.h ofw_bus_if.h +SRCS+=3D bus_if.h device_if.h mbox_if.h ofw_bus_if.h =20 .include =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Tue Nov 15 16:00:10 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 345DCC4387C for ; Tue, 15 Nov 2016 16:00:10 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [IPv6:2001:418:3fd::f7]) (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 E67F512F0 for ; Tue, 15 Nov 2016 16:00:09 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPv6:::1] (localhost [IPv6:::1]) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTP id uAFFxv1H020564 for ; Tue, 15 Nov 2016 11:00:03 -0500 (EST) (envelope-from george+freebsd@m5p.com) To: FreeBSD Stable Mailing List From: George Mitchell Subject: Symbol/library versioning ... Message-ID: <6427851f-5485-39bd-6690-8acd79e3f47d@m5p.com> Date: Tue, 15 Nov 2016 10:59:57 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=10.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on scollay.m5p.com X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (mailhost.m5p.com [IPv6:::1]); Tue, 15 Nov 2016 11:00:08 -0500 (EST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 16:00:10 -0000 ... is a topic I just marginally understand. But pkg 1.9.3 fails on FreeBSD 10.1-RELEASE-p35 because /lib/libc.so.7 contains no definition for "openat", though /lib/libc.so.7 on 10.3-RELEASE-p11 does define it. I confess to being baffled. How is this supposed to work? 10.1-RELEASE is still supported, right? -- George From owner-freebsd-stable@freebsd.org Tue Nov 15 16:24:37 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76F1BC43F43 for ; Tue, 15 Nov 2016 16:24:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0E56C1A9 for ; Tue, 15 Nov 2016 16:24:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id uAFGOV1c022903 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 15 Nov 2016 18:24:31 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uAFGOV1c022903 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uAFGOV75022902; Tue, 15 Nov 2016 18:24:31 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 15 Nov 2016 18:24:31 +0200 From: Konstantin Belousov To: George Mitchell Cc: FreeBSD Stable Mailing List Subject: Re: Symbol/library versioning ... Message-ID: <20161115162431.GV54029@kib.kiev.ua> References: <6427851f-5485-39bd-6690-8acd79e3f47d@m5p.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6427851f-5485-39bd-6690-8acd79e3f47d@m5p.com> User-Agent: Mutt/1.7.1 (2016-10-04) 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 16:24:37 -0000 On Tue, Nov 15, 2016 at 10:59:57AM -0500, George Mitchell wrote: > ... is a topic I just marginally understand. But pkg 1.9.3 fails > on FreeBSD 10.1-RELEASE-p35 because /lib/libc.so.7 contains no > definition for "openat", though /lib/libc.so.7 on 10.3-RELEASE-p11 > does define it. I confess to being baffled. How is this supposed > to work? 10.1-RELEASE is still supported, right? -- George Let me guess. You are trying to run a pkg binary, built on 10.3 system, on the 10.1 system, do you ? If yes, this is not supported and often breaks. From owner-freebsd-stable@freebsd.org Tue Nov 15 16:41:34 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81E95C4340B for ; Tue, 15 Nov 2016 16:41:34 +0000 (UTC) (envelope-from george@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [IPv6:2001:418:3fd::f7]) (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 3EA27D7D for ; Tue, 15 Nov 2016 16:41:34 +0000 (UTC) (envelope-from george@m5p.com) Received: from [IPv6:::1] (localhost [IPv6:::1]) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTP id uAFGfRSx020852; Tue, 15 Nov 2016 11:41:32 -0500 (EST) (envelope-from george@m5p.com) Subject: Re: Symbol/library versioning ... To: Konstantin Belousov , George Mitchell References: <6427851f-5485-39bd-6690-8acd79e3f47d@m5p.com> <20161115162431.GV54029@kib.kiev.ua> Cc: FreeBSD Stable Mailing List From: George Mitchell Message-ID: Date: Tue, 15 Nov 2016 11:41:27 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161115162431.GV54029@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=10.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on scollay.m5p.com X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (mailhost.m5p.com [IPv6:::1]); Tue, 15 Nov 2016 11:41:32 -0500 (EST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 16:41:34 -0000 On 11/15/16 11:24, Konstantin Belousov wrote: > On Tue, Nov 15, 2016 at 10:59:57AM -0500, George Mitchell wrote: >> ... is a topic I just marginally understand. But pkg 1.9.3 fails >> on FreeBSD 10.1-RELEASE-p35 because /lib/libc.so.7 contains no >> definition for "openat", though /lib/libc.so.7 on 10.3-RELEASE-p11 >> does define it. I confess to being baffled. How is this supposed >> to work? 10.1-RELEASE is still supported, right? -- George > > Let me guess. You are trying to run a pkg binary, built on 10.3 system, > on the 10.1 system, do you ? If yes, this is not supported and often > breaks. > _[...] ... oops ... that's exactly what I did. Sorry for the noise. -- George From owner-freebsd-stable@freebsd.org Thu Nov 17 09:16:15 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E5410C453DB for ; Thu, 17 Nov 2016 09:16:15 +0000 (UTC) (envelope-from marko.cupac@mimar.rs) Received: from mail.mimar.rs (mail1.mimar.rs [193.53.106.128]) (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 A45A4A24 for ; Thu, 17 Nov 2016 09:16:14 +0000 (UTC) (envelope-from marko.cupac@mimar.rs) Received: from mail1.mimar.rs (localhost [127.0.1.128]) by mail.mimar.rs (Postfix) with ESMTP id 7B9339FA8B68 for ; Thu, 17 Nov 2016 10:08:47 +0100 (CET) X-Virus-Scanned: amavisd-new at mimar.rs Received: from mail.mimar.rs ([127.0.1.128]) by mail1.mimar.rs (amavis.mimar.rs [127.0.1.128]) (amavisd-new, port 10026) with LMTP id 5GGt4q47dfzU for ; Thu, 17 Nov 2016 10:08:44 +0100 (CET) Received: from efreet.kappastar.com (nat-nat.kappastar.com [193.53.106.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: marko.cupac@mimar.rs) by mail.mimar.rs (Postfix) with ESMTPSA id 0578D9FA8B66 for ; Thu, 17 Nov 2016 10:08:43 +0100 (CET) Date: Thu, 17 Nov 2016 10:08:44 +0100 From: Marko =?UTF-8?B?Q3VwYcSH?= To: FreeBSD-STABLE Mailing List Subject: moxa uport 1110 RS232 USB to serial support? Message-ID: <20161117100844.22f6492a@efreet.kappastar.com> Organization: Mimar X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 09:16:16 -0000 Hi, is it possible to use Moxa Uport 1110 USB to serial adapter on FreeBSD 11.0? http://www.moxa.com/product/uport_1110.htm Upon plugging in all I get in dmesg is: ugen0.4: at usbus0 No cuaUX devices appear in /dev. Thank you in advance, --=20 Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupa=C4=87 https://www.mimar.rs/ From owner-freebsd-stable@freebsd.org Thu Nov 17 18:47:24 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A605C47925 for ; Thu, 17 Nov 2016 18:47:24 +0000 (UTC) (envelope-from dma_20214@rp.promocat.expvtinboxonline.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 306431BF8 for ; Thu, 17 Nov 2016 18:47:24 +0000 (UTC) (envelope-from dma_20214@rp.promocat.expvtinboxonline.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2C4C1C47923; Thu, 17 Nov 2016 18:47:24 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A29CC47922 for ; Thu, 17 Nov 2016 18:47:24 +0000 (UTC) (envelope-from dma_20214@rp.promocat.expvtinboxonline.com) Received: from c7.promocat.expvtinboxonline.com (c7.promocat.expvtinboxonline.com [187.61.29.7]) by mx1.freebsd.org (Postfix) with ESMTP id C46A31BF6 for ; Thu, 17 Nov 2016 18:47:23 +0000 (UTC) (envelope-from dma_20214@rp.promocat.expvtinboxonline.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=k1; d=promocat.expvtinboxonline.com; h=From:To:Subject:MIME-Version:Content-Type:Reply-To:List-Unsubscribe:Message-ID:Date; bh=AeT/tzFS6h+ep2wbpNSuo5E/kWI=; b=PZuIniSw9DqbcGC6Ss0w+/D4QabXoqunwkmS4dfYLfpy2DO5FWXcoKg2MbgFCzACkHhe5aFtbykc xPPjg7HqxyIcwMa67m2iJ2xH2VPk3FntJdeRJYiHrwh+wtfxrzgkNF7clGQt8hNEi4TjEFVYC8x6 7sHrB6KIXbPPXUK9BUk= Received: by c7.promocat.expvtinboxonline.com id h5ntjm15fb8j for ; Thu, 17 Nov 2016 16:37:14 -0200 (envelope-from ) From: "=?ISO-8859-1?Q?Loja_Catholicus?=" To: "" Subject: =?ISO-8859-1?Q?Os_anjinhos_prepararam_algo_especial_para_voc=EA!?= MIME-Version: 1.0 Reply-To: "=?ISO-8859-1?Q?Loja_Catholicus?=" X-Hash: 20214-865-194181-9a8b94e7034d0ff007fe679c362d2ab8 X-DMA: 43523990 Message-ID: <0.2.2E.12A.1D241019DCAE910.4BD1@c7.promocat.expvtinboxonline.com> Date: Thu, 17 Nov 2016 16:47:23 -0200 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 18:47:24 -0000 Loja Catholicus [http://trk.promocat.expvtinboxonline.com/index.dma/DmaClick?20214,865,194= 181,13321,9a8b94e7034d0ff007fe679c362d2ab8,aHR0cDovL2xvamFjYXRob2xpY3VzLmNv= bS5ici8/dGVybT1pbmZhbnRpbC1hbmpvcyZzPWlnb3ImcG9zdF90eXBlPXByb2R1Y3QmdGF4b25= vbXk9cHJvZHVjdF9jYXQvJnV0bV9zb3VyY2U9VmlydHVhbF9UYXJnZXQmdXRtX21lZGl1bT1FbW= FpbCZ1dG1fY29udGVudD0mdXRtX2NhbXBhaWduPWNhdGhvbGljdXMmdXRtX3Rlcm09,1,ZnJlZW= JzZC5vcmc=3D] [http://trk.promocat.expvtinboxonline.com/index.dma/DmaClick?20214,865,194= 181,13322,9a8b94e7034d0ff007fe679c362d2ab8,aHR0cDovL3BhaW5lbC52aXJ0dWFsdGFy= Z2V0LmNvbS5ici9pbmRleC5kbWEvU29jaWFsU2hhcmU/cD0yMDIxNCw4NjUsMSZ1cmw9aHR0cDo= vL3Ryay5wcm9tb2NhdC5leHB2dGluYm94b25saW5lLmNvbS9pbmRleC5kbWEvRG1hUHJldmlldz= 8yMDIxNC44NjUuMTk0MTgxLjlhOGI5NGU3MDM0ZDBmZjAwN2ZlNjc5YzM2MmQyYWI4LjEmdXRtX= 3NvdXJjZT1WaXJ0dWFsX1RhcmdldCZ1dG1fbWVkaXVtPUVtYWlsJnV0bV9jb250ZW50PSZ1dG1f= Y2FtcGFpZ249Y2F0aG9saWN1cyZ1dG1fdGVybT0=3D,1,ZnJlZWJzZC5vcmc=3D] Twitter [http://trk.promocat.expvtinboxonline.com/index.dma/DmaClick?20214,865,1941= 81,13322,9a8b94e7034d0ff007fe679c362d2ab8,aHR0cDovL3BhaW5lbC52aXJ0dWFsdGFyZ= 2V0LmNvbS5ici9pbmRleC5kbWEvU29jaWFsU2hhcmU/cD0yMDIxNCw4NjUsMSZ1cmw9aHR0cDov= L3Ryay5wcm9tb2NhdC5leHB2dGluYm94b25saW5lLmNvbS9pbmRleC5kbWEvRG1hUHJldmlldz8= yMDIxNC44NjUuMTk0MTgxLjlhOGI5NGU3MDM0ZDBmZjAwN2ZlNjc5YzM2MmQyYWI4LjEmdXRtX3= NvdXJjZT1WaXJ0dWFsX1RhcmdldCZ1dG1fbWVkaXVtPUVtYWlsJnV0bV9jb250ZW50PSZ1dG1fY= 2FtcGFpZ249Y2F0aG9saWN1cyZ1dG1fdGVybT0=3D,1,ZnJlZWJzZC5vcmc=3D] [http://trk.promocat.expvtinboxonline.com/index.dma/DmaClick?20214,865,194= 181,13323,9a8b94e7034d0ff007fe679c362d2ab8,aHR0cDovL3BhaW5lbC52aXJ0dWFsdGFy= Z2V0LmNvbS5ici9pbmRleC5kbWEvU29jaWFsU2hhcmU/cD0yMDIxNCw4NjUsMiZ1cmw9aHR0cDo= vL3Ryay5wcm9tb2NhdC5leHB2dGluYm94b25saW5lLmNvbS9pbmRleC5kbWEvRG1hUHJldmlldz= 8yMDIxNC44NjUuMTk0MTgxLjlhOGI5NGU3MDM0ZDBmZjAwN2ZlNjc5YzM2MmQyYWI4LjEmdXRtX= 3NvdXJjZT1WaXJ0dWFsX1RhcmdldCZ1dG1fbWVkaXVtPUVtYWlsJnV0bV9jb250ZW50PSZ1dG1f= Y2FtcGFpZ249Y2F0aG9saWN1cyZ1dG1fdGVybT0=3D,1,ZnJlZWJzZC5vcmc=3D] Facebook [http://trk.promocat.expvtinboxonline.com/index.dma/DmaClick?20214,865,1941= 81,13323,9a8b94e7034d0ff007fe679c362d2ab8,aHR0cDovL3BhaW5lbC52aXJ0dWFsdGFyZ= 2V0LmNvbS5ici9pbmRleC5kbWEvU29jaWFsU2hhcmU/cD0yMDIxNCw4NjUsMiZ1cmw9aHR0cDov= L3Ryay5wcm9tb2NhdC5leHB2dGluYm94b25saW5lLmNvbS9pbmRleC5kbWEvRG1hUHJldmlldz8= yMDIxNC44NjUuMTk0MTgxLjlhOGI5NGU3MDM0ZDBmZjAwN2ZlNjc5YzM2MmQyYWI4LjEmdXRtX3= NvdXJjZT1WaXJ0dWFsX1RhcmdldCZ1dG1fbWVkaXVtPUVtYWlsJnV0bV9jb250ZW50PSZ1dG1fY= 2FtcGFpZ249Y2F0aG9saWN1cyZ1dG1fdGVybT0=3D,1,ZnJlZWJzZC5vcmc=3D] [http://trk.promocat.expvtinboxonline.com/index.dma/DmaClick?20214,865,194= 181,13324,9a8b94e7034d0ff007fe679c362d2ab8,aHR0cDovL3BhaW5lbC52aXJ0dWFsdGFy= Z2V0LmNvbS5ici9pbmRleC5kbWEvU29jaWFsU2hhcmU/cD0yMDIxNCw4NjUsMyZ1cmw9aHR0cDo= vL3Ryay5wcm9tb2NhdC5leHB2dGluYm94b25saW5lLmNvbS9pbmRleC5kbWEvRG1hUHJldmlldz= 8yMDIxNC44NjUuMTk0MTgxLjlhOGI5NGU3MDM0ZDBmZjAwN2ZlNjc5YzM2MmQyYWI4LjEmdXRtX= 3NvdXJjZT1WaXJ0dWFsX1RhcmdldCZ1dG1fbWVkaXVtPUVtYWlsJnV0bV9jb250ZW50PSZ1dG1f= Y2FtcGFpZ249Y2F0aG9saWN1cyZ1dG1fdGVybT0=3D,1,ZnJlZWJzZC5vcmc=3D] Delicious [http://trk.promocat.expvtinboxonline.com/index.dma/DmaClick?20214,865,1941= 81,13324,9a8b94e7034d0ff007fe679c362d2ab8,aHR0cDovL3BhaW5lbC52aXJ0dWFsdGFyZ= 2V0LmNvbS5ici9pbmRleC5kbWEvU29jaWFsU2hhcmU/cD0yMDIxNCw4NjUsMyZ1cmw9aHR0cDov= L3Ryay5wcm9tb2NhdC5leHB2dGluYm94b25saW5lLmNvbS9pbmRleC5kbWEvRG1hUHJldmlldz8= yMDIxNC44NjUuMTk0MTgxLjlhOGI5NGU3MDM0ZDBmZjAwN2ZlNjc5YzM2MmQyYWI4LjEmdXRtX3= NvdXJjZT1WaXJ0dWFsX1RhcmdldCZ1dG1fbWVkaXVtPUVtYWlsJnV0bV9jb250ZW50PSZ1dG1fY= 2FtcGFpZ249Y2F0aG9saWN1cyZ1dG1fdGVybT0=3D,1,ZnJlZWJzZC5vcmc=3D] [http://trk.promocat.expvtinboxonline.com/index.dma/DmaClick?20214,865,194= 181,13325,9a8b94e7034d0ff007fe679c362d2ab8,aHR0cDovL3BhaW5lbC52aXJ0dWFsdGFy= Z2V0LmNvbS5ici9pbmRleC5kbWEvU29jaWFsU2hhcmU/cD0yMDIxNCw4NjUsNCZ1cmw9aHR0cDo= vL3Ryay5wcm9tb2NhdC5leHB2dGluYm94b25saW5lLmNvbS9pbmRleC5kbWEvRG1hUHJldmlldz= 8yMDIxNC44NjUuMTk0MTgxLjlhOGI5NGU3MDM0ZDBmZjAwN2ZlNjc5YzM2MmQyYWI4LjEmdXRtX= 3NvdXJjZT1WaXJ0dWFsX1RhcmdldCZ1dG1fbWVkaXVtPUVtYWlsJnV0bV9jb250ZW50PSZ1dG1f= Y2FtcGFpZ249Y2F0aG9saWN1cyZ1dG1fdGVybT0=3D,1,ZnJlZWJzZC5vcmc=3D] Digg [http://trk.promocat.expvtinboxonline.com/index.dma/DmaClick?20214,865,1941= 81,13325,9a8b94e7034d0ff007fe679c362d2ab8,aHR0cDovL3BhaW5lbC52aXJ0dWFsdGFyZ= 2V0LmNvbS5ici9pbmRleC5kbWEvU29jaWFsU2hhcmU/cD0yMDIxNCw4NjUsNCZ1cmw9aHR0cDov= L3Ryay5wcm9tb2NhdC5leHB2dGluYm94b25saW5lLmNvbS9pbmRleC5kbWEvRG1hUHJldmlldz8= yMDIxNC44NjUuMTk0MTgxLjlhOGI5NGU3MDM0ZDBmZjAwN2ZlNjc5YzM2MmQyYWI4LjEmdXRtX3= NvdXJjZT1WaXJ0dWFsX1RhcmdldCZ1dG1fbWVkaXVtPUVtYWlsJnV0bV9jb250ZW50PSZ1dG1fY= 2FtcGFpZ249Y2F0aG9saWN1cyZ1dG1fdGVybT0=3D,1,ZnJlZWJzZC5vcmc=3D] [http://trk.promocat.expvtinboxonline.com/index.dma/DmaClick?20214,865,194= 181,13326,9a8b94e7034d0ff007fe679c362d2ab8,aHR0cDovL3BhaW5lbC52aXJ0dWFsdGFy= Z2V0LmNvbS5ici9pbmRleC5kbWEvU29jaWFsU2hhcmU/cD0yMDIxNCw4NjUsNSZ1cmw9aHR0cDo= vL3Ryay5wcm9tb2NhdC5leHB2dGluYm94b25saW5lLmNvbS9pbmRleC5kbWEvRG1hUHJldmlldz= 8yMDIxNC44NjUuMTk0MTgxLjlhOGI5NGU3MDM0ZDBmZjAwN2ZlNjc5YzM2MmQyYWI4LjEmdXRtX= 3NvdXJjZT1WaXJ0dWFsX1RhcmdldCZ1dG1fbWVkaXVtPUVtYWlsJnV0bV9jb250ZW50PSZ1dG1f= Y2FtcGFpZ249Y2F0aG9saWN1cyZ1dG1fdGVybT0=3D,1,ZnJlZWJzZC5vcmc=3D] Blogger [http://trk.promocat.expvtinboxonline.com/index.dma/DmaClick?20214,865,1941= 81,13326,9a8b94e7034d0ff007fe679c362d2ab8,aHR0cDovL3BhaW5lbC52aXJ0dWFsdGFyZ= 2V0LmNvbS5ici9pbmRleC5kbWEvU29jaWFsU2hhcmU/cD0yMDIxNCw4NjUsNSZ1cmw9aHR0cDov= L3Ryay5wcm9tb2NhdC5leHB2dGluYm94b25saW5lLmNvbS9pbmRleC5kbWEvRG1hUHJldmlldz8= yMDIxNC44NjUuMTk0MTgxLjlhOGI5NGU3MDM0ZDBmZjAwN2ZlNjc5YzM2MmQyYWI4LjEmdXRtX3= NvdXJjZT1WaXJ0dWFsX1RhcmdldCZ1dG1fbWVkaXVtPUVtYWlsJnV0bV9jb250ZW50PSZ1dG1fY= 2FtcGFpZ249Y2F0aG9saWN1cyZ1dG1fdGVybT0=3D,1,ZnJlZWJzZC5vcmc=3D] [http://trk.promocat.expvtinboxonline.com/index.dma/DmaClick?20214,865,194= 181,13327,9a8b94e7034d0ff007fe679c362d2ab8,aHR0cDovL3BhaW5lbC52aXJ0dWFsdGFy= Z2V0LmNvbS5ici9pbmRleC5kbWEvU29jaWFsU2hhcmU/cD0yMDIxNCw4NjUsNiZ1cmw9aHR0cDo= vL3Ryay5wcm9tb2NhdC5leHB2dGluYm94b25saW5lLmNvbS9pbmRleC5kbWEvRG1hUHJldmlldz= 8yMDIxNC44NjUuMTk0MTgxLjlhOGI5NGU3MDM0ZDBmZjAwN2ZlNjc5YzM2MmQyYWI4LjEmdXRtX= 3NvdXJjZT1WaXJ0dWFsX1RhcmdldCZ1dG1fbWVkaXVtPUVtYWlsJnV0bV9jb250ZW50PSZ1dG1f= Y2FtcGFpZ249Y2F0aG9saWN1cyZ1dG1fdGVybT0=3D,1,ZnJlZWJzZC5vcmc=3D] LinkedIn [http://trk.promocat.expvtinboxonline.com/index.dma/DmaClick?20214,865,1941= 81,13327,9a8b94e7034d0ff007fe679c362d2ab8,aHR0cDovL3BhaW5lbC52aXJ0dWFsdGFyZ= 2V0LmNvbS5ici9pbmRleC5kbWEvU29jaWFsU2hhcmU/cD0yMDIxNCw4NjUsNiZ1cmw9aHR0cDov= L3Ryay5wcm9tb2NhdC5leHB2dGluYm94b25saW5lLmNvbS9pbmRleC5kbWEvRG1hUHJldmlldz8= yMDIxNC44NjUuMTk0MTgxLjlhOGI5NGU3MDM0ZDBmZjAwN2ZlNjc5YzM2MmQyYWI4LjEmdXRtX3= NvdXJjZT1WaXJ0dWFsX1RhcmdldCZ1dG1fbWVkaXVtPUVtYWlsJnV0bV9jb250ZW50PSZ1dG1fY= 2FtcGFpZ249Y2F0aG9saWN1cyZ1dG1fdGVybT0=3D,1,ZnJlZWJzZC5vcmc=3D] From owner-freebsd-stable@freebsd.org Fri Nov 18 12:29:47 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47923C48864 for ; Fri, 18 Nov 2016 12:29:47 +0000 (UTC) (envelope-from a.ahhh4@aol.com) Received: from oms-a006e.mx.aol.com (oms-a006e.mx.aol.com [204.29.186.153]) (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 078FF7D8 for ; Fri, 18 Nov 2016 12:29:46 +0000 (UTC) (envelope-from a.ahhh4@aol.com) Received: from omr-m006e.mx.aol.com (omr-m006.mx.aol.com [10.74.117.73]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by oms-a006e.mx.aol.com (AOL Outbound OMS Interface) with ESMTPS id 15401380007B for ; Fri, 18 Nov 2016 07:29:46 -0500 (EST) Received: from mtaout-aad01.mx.aol.com (mtaout-aad01.mx.aol.com [172.26.127.225]) by omr-m006e.mx.aol.com (Outbound Mail Relay) with ESMTP id 073B93800093 for ; Fri, 18 Nov 2016 07:29:46 -0500 (EST) Received: from CHRIST (unknown [23.247.155.5]) by mtaout-aad01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPA id CFFD33800009C for ; Fri, 18 Nov 2016 07:29:44 -0500 (EST) From: "Dr Max Hansen" Subject: Read & Get Back To Me Immediately To: freebsd-stable@freebsd.org MIME-Version: 1.0 Reply-To: drmaxhansenni2015@gmail.com Date: Fri, 18 Nov 2016 13:29:35 -0800 Message-ID: <5680697545836946@smtp.aol.com> x-aol-global-disposition: S X-SPAM-FLAG: YES DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1479472185; bh=x6NNP4Jk38kGd6cJuyog6tzJgnU/CXX0OHDKe8sWswo=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=kwhst4+g2Yaxsd7/+tUsyKychqbeDL0Hw1sy8X0Ifrg+67o7xlHF9jYSH//Cnxqb4 B7kWS6Nn+YouKfB2sa8e2BIl6qJHMY4FmS0DWzUs0GNjPmv7UIGU5DpxzqVyjBjQ4N wE/ZI5G5MUivBBxjuRguiRzquUYynNWRy4D1XDck= X-AOL-REROUTE: YES x-aol-sid: 3039ac1a7fe1582ef43821a4 X-AOL-IP: 23.247.155.5 Content-Type: text/plain ; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 12:29:47 -0000 Attn: This is to officially inform you from the office of the presidency reg= arding the release of your long awaited fund of $10,500.000.00.We wish= to inform you that your SWIFT CREDIT CARD payment is being processed= and will be released to you as soon as you respond to this honorable = Office. Please re-confirm to us the following, Your full name, Address= , Phone, Occupation, Age and Marital status: Regard Max From owner-freebsd-stable@freebsd.org Fri Nov 18 12:31:24 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D1EE9C48AB0 for ; Fri, 18 Nov 2016 12:31:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C7966A89; Fri, 18 Nov 2016 12:31:23 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA18390; Fri, 18 Nov 2016 14:31:15 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1c7iK3-000HaV-E5; Fri, 18 Nov 2016 14:31:15 +0200 Subject: Re: Freebsd 11.0 RELEASE - ZFS deadlock To: Henri Hennebert , Konstantin Belousov References: <0c223160-b76f-c635-bb15-4a068ba7efe7@restart.be> <9d1f9a76-5a8d-6eca-9a50-907d55099847@FreeBSD.org> <6bc95dce-31e1-3013-bfe3-7c2dd80f9d1e@restart.be> <23a66749-f138-1f1a-afae-c775f906ff37@restart.be> <8e7547ef-87f7-7fab-6f45-221e8cea1989@FreeBSD.org> <6d991cea-b420-531e-12cc-001e4aeed66b@restart.be> <67f2e8bd-bff0-f808-7557-7dabe5cad78c@FreeBSD.org> <1cb09c54-5f0e-2259-a41a-fefe76b4fe8b@restart.be> <9f20020b-e2f1-862b-c3fc-dc6ff94e301e@restart.be> <599c5a5b-aa08-2030-34f3-23ff19d09a9b@restart.be> <32686283-948a-6faf-7ded-ed8fcd23affb@FreeBSD.org> <26512d69-94c2-92da-e3ea-50aebf17e3a0@restart.be> <80f65c86-1015-c409-1bf6-c01a5fe569c8@restart.be> Cc: freebsd-stable@FreeBSD.org From: Andriy Gapon Message-ID: <7c932021-ff99-9ef9-7042-4f267fb0b955@FreeBSD.org> Date: Fri, 18 Nov 2016 14:30:39 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <80f65c86-1015-c409-1bf6-c01a5fe569c8@restart.be> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 12:31:24 -0000 On 14/11/2016 14:00, Henri Hennebert wrote: > On 11/14/2016 12:45, Andriy Gapon wrote: >> Okay. Luckily for us, it seems that 'm' is available in frame 5. It also >> happens to be the first field of 'struct faultstate'. So, could you please go >> to frame and print '*m' and '*(struct faultstate *)m' ? >> > (kgdb) fr 4 > #4 0xffffffff8089d1c1 in vm_page_busy_sleep (m=0xfffff800df68cd40, wmesg= optimized out>) at /usr/src/sys/vm/vm_page.c:753 > 753 msleep(m, vm_page_lockptr(m), PVM | PDROP, wmesg, 0); > (kgdb) print *m > $1 = {plinks = {q = {tqe_next = 0xfffff800dc5d85b0, tqe_prev = > 0xfffff800debf3bd0}, s = {ss = {sle_next = 0xfffff800dc5d85b0}, > pv = 0xfffff800debf3bd0}, memguard = {p = 18446735281313646000, v = > 18446735281353604048}}, listq = {tqe_next = 0x0, > tqe_prev = 0xfffff800dc5d85c0}, object = 0xfffff800b62e9c60, pindex = 11, > phys_addr = 3389358080, md = {pv_list = { > tqh_first = 0x0, tqh_last = 0xfffff800df68cd78}, pv_gen = 426, pat_mode = > 6}, wire_count = 0, busy_lock = 6, hold_count = 0, > flags = 0, aflags = 2 '\002', oflags = 0 '\0', queue = 0 '\0', psind = 0 '\0', > segind = 3 '\003', order = 13 '\r', > pool = 0 '\0', act_count = 0 '\0', valid = 0 '\0', dirty = 0 '\0'} If I interpret this correctly the page is in the 'exclusive busy' state. Unfortunately, I can't tell much beyond that. But I am confident that this is the root cause of the lock-up. > (kgdb) print *(struct faultstate *)m > $2 = {m = 0xfffff800dc5d85b0, object = 0xfffff800debf3bd0, pindex = 0, first_m = > 0xfffff800dc5d85c0, > first_object = 0xfffff800b62e9c60, first_pindex = 11, map = 0xca058000, entry > = 0x0, lookup_still_valid = -546779784, > vp = 0x6000001aa} > (kgdb) I was wrong on this one as 'm' is actually a pointer, so the above is not correct. Maybe 'info reg' in frame 5 would give a clue about the value of 'fs'. I am not sure how to proceed from here. The only thing I can think of is a lock order reversal between the vnode lock and the page busying quasi-lock. But examining the code I can not spot it. Another possibility is a leak of a busy page, but that's hard to debug. How hard is it to reproduce the problem? Maybe Konstantin would have some ideas or suggestions. -- Andriy Gapon From owner-freebsd-stable@freebsd.org Fri Nov 18 13:16:02 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7CE07C48FC0 for ; Fri, 18 Nov 2016 13:16:02 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [5.135.182.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 29D4AA9C; Fri, 18 Nov 2016 13:16:02 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=2001:41d0:8:bdbe:1:1::; helo=restart.be; envelope-from=hlh@restart.be; receiver=avg@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3tKz5Q0f3Yzrsf DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=restart.be; s=tignes; t=1479474954; bh=viOqvzgsbZT295QoKZP/1qlTxH1Q4gt2UAoPZ1PyzNo=; h=Subject:To:References:Cc:From:Date:In-Reply-To; z=Subject:=20Re:=20Freebsd=2011.0=20RELEASE=20-=20ZFS=20deadlock|To :=20Andriy=20Gapon=20,=20Konstantin=20Belousov=20 |References:=20<0c223160-b76f-c635-bb15-4a068ba7e fe7@restart.be>=0D=0A=20<6bc95dce-31e1-3013-bfe3-7c2dd80f9d1e@rest art.be>=0D=0A=20 =0D=0A=20<23a66749-f138-1f1a-afae-c775f906ff37@restart.be>=0D=0A=2 0<8e7547ef-87f7-7fab-6f45-221e8cea1989@FreeBSD.org>=0D=0A=20<6d991 cea-b420-531e-12cc-001e4aeed66b@restart.be>=0D=0A=20<67f2e8bd-bff0 -f808-7557-7dabe5cad78c@FreeBSD.org>=0D=0A=20<1cb09c54-5f0e-2259-a 41a-fefe76b4fe8b@restart.be>=0D=0A=20=0D=0A=20<9f20020b-e2f1-862b-c3fc-dc6ff94e301 e@restart.be>=0D=0A=20=0D=0A=20<599c5a5b-aa08-2030-34f3-23ff19d09a9b@restart.be>=0 D=0A=20<32686283-948a-6faf-7ded-ed8fcd23affb@FreeBSD.org>=0D=0A=20 =0D=0A=20=0D=0A=20<26512d69-94c2- 92da-e3ea-50aebf17e3a0@restart.be>=0D=0A=20=0D=0A=20<80f65c86-1015-c409-1bf6-c01a5 fe569c8@restart.be>=0D=0A=20<7c932021-ff99-9ef9-7042-4f267fb0b955@ FreeBSD.org>|Cc:=20freebsd-stable@FreeBSD.org|From:=20Henri=20Henn ebert=20|Date:=20Fri,=2018=20Nov=202016=2014:15:51 =20+0100|In-Reply-To:=20<7c932021-ff99-9ef9-7042-4f267fb0b955@Free BSD.org>; b=wgrJQMub/yoDgSkwXHi0hUp516Mh/Ao3IyyGzkhxnUuKdXDii5WctJBVF1gqTI5gd bUT1KH22GDhBbZNXDzmE21L5iULINDz3T2YTAc6usvhwOdN7KoVycWgLB/V7p9/UF6 fbOg3ot+dQegszHTR/V/W90kVkGGAOtsQNuYKvMcADy8gQHokFE8Bxfdj6Yh5db6a2 Qjb/sT9HaeSYRBhJfLufIGgv+D12X+3VqJ+8+DxG2smmNfKezY5L5hwktvxBnVzkIX u6HMAVTEG3UIPWiG/hPUlcKvR+HGh6+ljzeomAJ3sNjQhr+xv8510QBb14hT+lWYdp 1NjYuSJBQgXFw== Received: from restart.be (avoriaz.restart.be [IPv6:2001:41d0:8:bdbe:1:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3tKz5Q0f3Yzrsf; Fri, 18 Nov 2016 14:15:53 +0100 (CET) Received: from chamonix.restart.bel (chamonix.restart.bel [IPv6:2001:41d0:8:bdbe:1:9:0:0]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id uAIDFphH031867 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 18 Nov 2016 14:15:52 +0100 (CET) (envelope-from hlh@restart.be) Subject: Re: Freebsd 11.0 RELEASE - ZFS deadlock To: Andriy Gapon , Konstantin Belousov References: <0c223160-b76f-c635-bb15-4a068ba7efe7@restart.be> <6bc95dce-31e1-3013-bfe3-7c2dd80f9d1e@restart.be> <23a66749-f138-1f1a-afae-c775f906ff37@restart.be> <8e7547ef-87f7-7fab-6f45-221e8cea1989@FreeBSD.org> <6d991cea-b420-531e-12cc-001e4aeed66b@restart.be> <67f2e8bd-bff0-f808-7557-7dabe5cad78c@FreeBSD.org> <1cb09c54-5f0e-2259-a41a-fefe76b4fe8b@restart.be> <9f20020b-e2f1-862b-c3fc-dc6ff94e301e@restart.be> <599c5a5b-aa08-2030-34f3-23ff19d09a9b@restart.be> <32686283-948a-6faf-7ded-ed8fcd23affb@FreeBSD.org> <26512d69-94c2-92da-e3ea-50aebf17e3a0@restart.be> <80f65c86-1015-c409-1bf6-c01a5fe569c8@restart.be> <7c932021-ff99-9ef9-7042-4f267fb0b955@FreeBSD.org> Cc: freebsd-stable@FreeBSD.org From: Henri Hennebert Message-ID: <322f5c54-8fc2-9da1-5cd2-6c12f3a7e7ae@restart.be> Date: Fri, 18 Nov 2016 14:15:51 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <7c932021-ff99-9ef9-7042-4f267fb0b955@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 13:16:02 -0000 On 11/18/2016 13:30, Andriy Gapon wrote: > On 14/11/2016 14:00, Henri Hennebert wrote: >> On 11/14/2016 12:45, Andriy Gapon wrote: >>> Okay. Luckily for us, it seems that 'm' is available in frame 5. It also >>> happens to be the first field of 'struct faultstate'. So, could you please go >>> to frame and print '*m' and '*(struct faultstate *)m' ? >>> >> (kgdb) fr 4 >> #4 0xffffffff8089d1c1 in vm_page_busy_sleep (m=0xfffff800df68cd40, wmesg=> optimized out>) at /usr/src/sys/vm/vm_page.c:753 >> 753 msleep(m, vm_page_lockptr(m), PVM | PDROP, wmesg, 0); >> (kgdb) print *m >> $1 = {plinks = {q = {tqe_next = 0xfffff800dc5d85b0, tqe_prev = >> 0xfffff800debf3bd0}, s = {ss = {sle_next = 0xfffff800dc5d85b0}, >> pv = 0xfffff800debf3bd0}, memguard = {p = 18446735281313646000, v = >> 18446735281353604048}}, listq = {tqe_next = 0x0, >> tqe_prev = 0xfffff800dc5d85c0}, object = 0xfffff800b62e9c60, pindex = 11, >> phys_addr = 3389358080, md = {pv_list = { >> tqh_first = 0x0, tqh_last = 0xfffff800df68cd78}, pv_gen = 426, pat_mode = >> 6}, wire_count = 0, busy_lock = 6, hold_count = 0, >> flags = 0, aflags = 2 '\002', oflags = 0 '\0', queue = 0 '\0', psind = 0 '\0', >> segind = 3 '\003', order = 13 '\r', >> pool = 0 '\0', act_count = 0 '\0', valid = 0 '\0', dirty = 0 '\0'} > > If I interpret this correctly the page is in the 'exclusive busy' state. > Unfortunately, I can't tell much beyond that. > But I am confident that this is the root cause of the lock-up. > >> (kgdb) print *(struct faultstate *)m >> $2 = {m = 0xfffff800dc5d85b0, object = 0xfffff800debf3bd0, pindex = 0, first_m = >> 0xfffff800dc5d85c0, >> first_object = 0xfffff800b62e9c60, first_pindex = 11, map = 0xca058000, entry >> = 0x0, lookup_still_valid = -546779784, >> vp = 0x6000001aa} >> (kgdb) > > I was wrong on this one as 'm' is actually a pointer, so the above is not > correct. Maybe 'info reg' in frame 5 would give a clue about the value of 'fs'. (kgdb) fr 5 #5 0xffffffff8089dd4d in vm_page_sleep_if_busy (m=0xfffff800df68cd40, msg=0xffffffff809c51bc "vmpfw") at /usr/src/sys/vm/vm_page.c:1086 1086 vm_page_busy_sleep(m, msg); (kgdb) info reg rax 0x0 0 rbx 0xfffff800b62e9c78 -8793036514184 rcx 0x0 0 rdx 0x0 0 rsi 0x0 0 rdi 0x0 0 rbp 0xfffffe0101836810 0xfffffe0101836810 rsp 0xfffffe01018367e0 0xfffffe01018367e0 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0x0 0 r12 0xfffff800b642aa00 -8793035200000 r13 0xfffff800df68cd40 -8792344834752 r14 0xfffff800b62e9c60 -8793036514208 r15 0xffffffff809c51bc -2137239108 rip 0xffffffff8089dd4d 0xffffffff8089dd4d eflags 0x0 0 cs 0x0 0 ss 0x0 0 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 I don't know what to do from here. > > I am not sure how to proceed from here. > The only thing I can think of is a lock order reversal between the vnode lock > and the page busying quasi-lock. But examining the code I can not spot it. > Another possibility is a leak of a busy page, but that's hard to debug. > > How hard is it to reproduce the problem? After 7 days all seems normal only one copy of innd: [root@avoriaz ~]# ps xa|grep inn 1193 - Is 0:01.40 /usr/local/news/bin/innd -r 13498 - IN 0:00.01 /usr/local/news/bin/innfeed 1194 v0- IW 0:00.00 /bin/sh /usr/local/news/bin/innwatch -i 60 I will try to stop and restart innd. All continue to look good: [root@avoriaz ~]# ps xa|grep inn 31673 - Ss 0:00.02 /usr/local/news/bin/innd 31694 - SN 0:00.01 /usr/local/news/bin/innfeed 31674 0 S 0:00.01 /bin/sh /usr/local/news/bin/innwatch -i 60 I think to reproduce is just waiting it occurs by itself... One thing here: The deadlock occurs at least 5 times since 10.0R. And always with the directory /usr/local/news/bin > > Maybe Konstantin would have some ideas or suggestions. > Henri From owner-freebsd-stable@freebsd.org Fri Nov 18 13:29:07 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C08FDC45610 for ; Fri, 18 Nov 2016 13:29:07 +0000 (UTC) (envelope-from ardovm@yahoo.it) Received: from nm34-vm7.bullet.mail.ir2.yahoo.com (nm34-vm7.bullet.mail.ir2.yahoo.com [212.82.97.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 408961438 for ; Fri, 18 Nov 2016 13:29:06 +0000 (UTC) (envelope-from ardovm@yahoo.it) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.it; s=s2048; t=1479475739; bh=BkPKZihvhbfExCWdehCjk6P1fRvhhM1fHDa/aRtlT0M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=oaR8URiqGpsfPRdEt+5tjlqxeyCYpx68gjiFuz1xpc3Zx7y+xnHqXkmJnMzqeHhSPcY8eBamo4yzjtc+1jtFCsOqNfLKu7Y4RVvTDXWLSsiU8rHMUe0vhs0piprq5PMTt8ayV6G6DP2SNl7UvRsvucmaEo8dt26OXpj4nemZ1kWkkBBxyeSxJT1MNcPL1y1Aq9xiB4w1CK47Txb9IObpoFg4VqPIhlpYN92MvO8UCaU9+cBweR8641Tvfssn1E/SfxePgxKX2wUgPm2DO26rZCC4MZH1qdETFn3jI+2OyoImu+KTM9IFn0QP11nyOMFtRc6EMobIzuLfDq6XjxiWJw== Received: from [212.82.98.49] by nm34.bullet.mail.ir2.yahoo.com with NNFMP; 18 Nov 2016 13:28:59 -0000 Received: from [46.228.39.67] by tm2.bullet.mail.ir2.yahoo.com with NNFMP; 18 Nov 2016 13:28:59 -0000 Received: from [127.0.0.1] by smtp104.mail.ir2.yahoo.com with NNFMP; 18 Nov 2016 13:28:59 -0000 X-Yahoo-Newman-Id: 591097.72140.bm@smtp104.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Y4wgBC4VM1l4t1KpKd0QYakUQdLGUvbnkEr2h09t_APO0CJ lR21v.hZ8oxu_rSk4tE4PFnrokhfPmP1vs7MQBqbRnKgnJg.61w8RFh6qCwU kcn.xX_BXrZneAdT2e2ioFN.7I4tJz1nUb2yshKpBFV8Se7OtVAvcIpbXwxw eef7NbQqukYiNvZD9I2YLz6Z3Q9fLPHEvdn4Z2seIRtOGk409HGMpucQVh96 bS9GXDK_80lc_hJrBuF9R5et7YArkOSxkYH85oFDvDbIE3HQdOCn9EnqwK.4 xoNbTnaVwqy7xfW9qZCmHlENvbfMKEo8kJhjv2YxtmKc0Yy36XUljTe1Pelm f2YXzDoSgtxZPUvfIxM4JdmX2awSfrzndj3zmWqH.HPLwnEKzu_KYx0.mikv SdQcBr81BuAWKaHv4Bk2XMYZem4mDBFo8TrfK50lq.JOf5hD3iiAq1EGZwu8 vUDk1eQj96sgCD2jcoLk29LwqgxBBRvbIg2aT99TGjTDFOzWwJ8Qhhsyz2FJ OlUAsmTWEmN4Uaudr0m2JYx.OFCitzbUR11eBREwS6JM3vPRF X-Yahoo-SMTP: WU.IBxeswBAAnLcBZV3tEZIK0A-- Received: by nuvolo.localdomain (Postfix, from userid 1001) id 4E6C61AF10D; Fri, 18 Nov 2016 14:28:58 +0100 (CET) Date: Fri, 18 Nov 2016 14:28:58 +0100 From: Arrigo Marchiori To: freebsd-stable@freebsd.org Cc: freebsd-usb@freebsd.org Subject: Re: moxa uport 1110 RS232 USB to serial support? Message-ID: <20161118132858.GA69072@nuvolo> References: <20161117100844.22f6492a@efreet.kappastar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20161117100844.22f6492a@efreet.kappastar.com> User-Agent: Mutt/1.7.1 (2016-10-04) Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 13:29:07 -0000 Hello, I am resending this reply message to the freebsd-usb@ and freebsd-stable@ mailing list, because it bounced back to me after one day. On Thu, Nov 17, 2016 at 10:08:44AM +0100, Marko Cupa=C4=87 wrote: > Hi, >=20 > is it possible to use Moxa Uport 1110 USB to serial adapter on FreeBSD > 11.0? > http://www.moxa.com/product/uport_1110.htm I am afraid that the short answer is =C2=ABno=C2=BB. For what I could find on-line: - the Moxa UPort 1110 driver for Linux is the same as the Texas Instruments TUSB3410 (source: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-sta= ble.git/commit/drivers/usb/serial?id=3Db923c6c62981cec5e2d2187fd700c2fc43= 86fc45) - the port comms/uticom was a driver for the TUSB3410, but it was deprecated, and removed three years ago. FreeBSD forum thread: https://forums.freebsd.org/threads/18151/ Port information: http://www.freshports.org/comms/uticom SourceForge page: https://sourceforge.net/projects/uticom/ I hope this helps. --=20 rigo http://rigo.altervista.org From owner-freebsd-stable@freebsd.org Fri Nov 18 14:22:17 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 011B2C48993 for ; Fri, 18 Nov 2016 14:22:17 +0000 (UTC) (envelope-from marko.cupac@mimar.rs) Received: from mail.mimar.rs (mail1.mimar.rs [193.53.106.128]) (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 B64BC19BB for ; Fri, 18 Nov 2016 14:22:15 +0000 (UTC) (envelope-from marko.cupac@mimar.rs) Received: from mail1.mimar.rs (localhost [127.0.1.128]) by mail.mimar.rs (Postfix) with ESMTP id 329449FA8B67; Fri, 18 Nov 2016 15:22:07 +0100 (CET) X-Virus-Scanned: amavisd-new at mimar.rs Received: from mail.mimar.rs ([127.0.1.128]) by mail1.mimar.rs (amavis.mimar.rs [127.0.1.128]) (amavisd-new, port 10026) with LMTP id TUy0sXw1MDPK; Fri, 18 Nov 2016 15:22:00 +0100 (CET) Received: from efreet.kappastar.com (nat-nat.kappastar.com [193.53.106.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: marko.cupac@mimar.rs) by mail.mimar.rs (Postfix) with ESMTPSA id 628D19FA8B66; Fri, 18 Nov 2016 15:22:00 +0100 (CET) Date: Fri, 18 Nov 2016 15:22:00 +0100 From: Marko =?UTF-8?B?Q3VwYcSH?= To: freebsd-stable@freebsd.org Cc: Arrigo Marchiori Subject: Re: moxa uport 1110 RS232 USB to serial support? Message-ID: <20161118152200.0f4d8a6d@efreet.kappastar.com> In-Reply-To: <20161118132858.GA69072@nuvolo> References: <20161117100844.22f6492a@efreet.kappastar.com> <20161118132858.GA69072@nuvolo> Organization: Mimar X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 14:22:17 -0000 On Fri, 18 Nov 2016 14:28:58 +0100 Arrigo Marchiori via freebsd-stable wrote: > Hello, >=20 > I am resending this reply message to the freebsd-usb@ and > freebsd-stable@ mailing list, because it bounced back to me after one > day. > > I am afraid that the short answer is =C2=ABno=C2=BB. >=20 > For what I could find on-line: >=20 > - the Moxa UPort 1110 driver for Linux is the same as the Texas > Instruments TUSB3410 > (source: > https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/comm= it/drivers/usb/serial?id=3Db923c6c62981cec5e2d2187fd700c2fc4386fc45) >=20 > - the port comms/uticom was a driver for the TUSB3410, but it was > deprecated, and removed three years ago. > FreeBSD forum thread: https://forums.freebsd.org/threads/18151/ > Port information: http://www.freshports.org/comms/uticom > SourceForge page: https://sourceforge.net/projects/uticom/ >=20 > I hope this helps. Arrigo, it does help, thank you. I'm not subscribed to freebsd-usb, but I'm gonna check archives to see if there are any follow-ups. I am not sure, but I think I used this adapter on OpenBSD without the need to install additional packages. Moxa Uport 1110 is also in OpenBSD's usbdevs.h: http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/dev/usb/usbdevs= .h?rev=3D1.683&content-type=3Dtext/plain Perhaps someone with much more knowledge than me would be able to port this to FreeBSD? --=20 Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupa=C4=87 https://www.mimar.rs/ From owner-freebsd-stable@freebsd.org Sat Nov 19 14:01:30 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C474C48720 for ; Sat, 19 Nov 2016 14:01:30 +0000 (UTC) (envelope-from kamisouckova@gmail.com) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 E94038B9 for ; Sat, 19 Nov 2016 14:01:29 +0000 (UTC) (envelope-from kamisouckova@gmail.com) Received: by mail-wm0-x243.google.com with SMTP id g23so13366685wme.1 for ; Sat, 19 Nov 2016 06:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=suJ8qYqN9xOnVpxvb0Kb3NiMKMRur684RELubpmAttg=; b=yDNsu0Fig1j5GUmrQrN/yXY1QnUR2Fpl9xpWLW0v7EBXisq88UBN/iv0UgZtsf+dly aTuE46mxhdNxExQmVgBqYR0onzyi/K0T08o02aUU7JrJuPsjmO4TWLyEPdNNjJd3+HjR 5qedEHpAT6DHeUTYWFJ+tGGxB6IVFX2kmeJGKSpguOP5mMF9rFgQnIwCmkYMbC5NXLir efgAI4qSbq6TYZyMFz2f84sTh7p/W/64xodRwP6ElWyho4TL9ZD3BYM2HS/6pti++OQB FPTn3sF9k6J0bCFp8U12j0wz/tTmgyyX6EIAhad5qYAtJgBv0C1Z95+AQtdfAcwTXpAh Bz+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=suJ8qYqN9xOnVpxvb0Kb3NiMKMRur684RELubpmAttg=; b=TiJx80JLWmZg61Yhf8YMkGYMaKJT6G8sIvX3LeJR53KKJXhldjkK5/Pz/ZjNlIRqfe ru2eGzymcUuAa82zbM6wMJFY9sBFE+r5dXV6NcTwDw2zwr2dKtsODXzX8Fiwhkiw5gSi 2wg0PP3GDkHONSCFcIdV2y2FGfzJom3MbI9GskrTAj27wvNJXasArPzFhiEN7rEFqsKZ Hv7OcNIcllkaGrOQymqhYXC46CW5vl6vK9KyFyDl6fIvVgAvKROfqRoAapp5grk697W6 JLXTH/ZhcyDyjNEh3xEQhZLFyC4BY729oCkOhRVvNC0UQJz4yJWC6PQ9PuNfqHQdxZ/J ChCg== X-Gm-Message-State: AKaTC01GYaUbxqpfDgua0oU4Vh4UWeswaiCQa1YkG6ewHfTUMfTdWG/O6ezggVMdeJI2iEM7WAAbk6ud7jU67A== X-Received: by 10.28.178.10 with SMTP id b10mr3817756wmf.83.1479564087725; Sat, 19 Nov 2016 06:01:27 -0800 (PST) MIME-Version: 1.0 Sender: kamisouckova@gmail.com Received: by 10.194.29.101 with HTTP; Sat, 19 Nov 2016 06:01:07 -0800 (PST) From: =?UTF-8?B?S2FtaWxhIFNvdcSNa292w6E=?= Date: Sat, 19 Nov 2016 15:01:07 +0100 X-Google-Sender-Auth: 4fbQRoYi3Kv5rRa2o9-1z_mOQPI Message-ID: Subject: Panic when tearing down a VNET jail; pf mentioned in stack trace To: freebsd-stable@freebsd.org Cc: =?UTF-8?B?UmljaGFyZCBLcsOhbG92acSN?= Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2016 14:01:30 -0000 Hello, (if this is not the right mailing list, please reroute this email -- I am not sure where to post VNET-related stuff.) I experienced a panic when stopping an iocage-managed jail with VNET. Some information: - The host (which is a physical machine) panicked after calling `iocage stop`. - The host has pf enabled and active, the jail does not. - The standard iocage configuration for VNET is used, i.e. the host part of the epair device is bridged to the local network. - It has only happened to me once in about 10 tries, so I assume it must be a race condition. - The stack trace is attached below. What could be the problem? How can I help debug it? (I do not know anything about FreeBSD internals, yet.) Thank you! Kamila ------------------------------------------- trace: Nov 19 14:12:04 oresme kernel: Fatal trap 12: page fault while in kernel mode Nov 19 14:12:04 oresme kernel: cpuid = 5; apic id = 05 Nov 19 14:12:04 oresme kernel: fault virtual address = 0x420 Nov 19 14:12:04 oresme kernel: fault code = supervisor read data, page not present Nov 19 14:12:04 oresme kernel: instruction pointer = 0x20:0xffffffff826657a9 Nov 19 14:12:04 oresme kernel: stack pointer = 0x28:0xfffffe0852d63340 Nov 19 14:12:04 oresme kernel: frame pointer = 0x28:0xfffffe0852d633b0 Nov 19 14:12:04 oresme kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Nov 19 14:12:04 oresme kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Nov 19 14:12:04 oresme kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Nov 19 14:12:04 oresme kernel: current process = 12 (irq272: igb1:que 1) Nov 19 14:12:04 oresme kernel: trap number = 12 Nov 19 14:12:04 oresme kernel: panic: page fault Nov 19 14:12:04 oresme kernel: cpuid = 5 Nov 19 14:12:04 oresme kernel: KDB: stack backtrace: Nov 19 14:12:04 oresme kernel: #0 0xffffffff80aa8787 at kdb_backtrace+0x67 Nov 19 14:12:04 oresme kernel: #1 0xffffffff80a5d632 at vpanic+0x182 Nov 19 14:12:04 oresme kernel: #2 0xffffffff80a5d4a3 at panic+0x43 Nov 19 14:12:04 oresme kernel: #3 0xffffffff80f3cd51 at trap_fatal+0x351 Nov 19 14:12:04 oresme kernel: #4 0xffffffff80f3cf43 at trap_pfault+0x1e3 Nov 19 14:12:04 oresme kernel: #5 0xffffffff80f3c4ec at trap+0x26c Nov 19 14:12:04 oresme kernel: #6 0xffffffff80f1f521 at calltrap+0x8 Nov 19 14:12:04 oresme kernel: #7 0xffffffff82641acc at pf_test+0xfdc Nov 19 14:12:04 oresme kernel: #8 0xffffffff8265408d at pf_check_in+0x1d Nov 19 14:12:04 oresme kernel: #9 0xffffffff80b820f3 at pfil_run_hooks+0x83 Nov 19 14:12:04 oresme kernel: #10 0xffffffff80be9a5f at ip_input+0x42f Nov 19 14:12:04 oresme kernel: #11 0xffffffff80b8107f at netisr_dispatch_src+0xff Nov 19 14:12:04 oresme kernel: #12 0xffffffff80b6915a at ether_demux+0x13a Nov 19 14:12:04 oresme kernel: #13 0xffffffff80b69e75 at ether_nh_input+0x345 Nov 19 14:12:04 oresme kernel: #14 0xffffffff80b8107f at netisr_dispatch_src+0xff Nov 19 14:12:04 oresme kernel: #15 0xffffffff80b69414 at ether_input+0x54 Nov 19 14:12:04 oresme kernel: #16 0xffffffff80553b9c at igb_rxeof+0x7fc Nov 19 14:12:04 oresme kernel: #17 0xffffffff80552def at igb_msix_que+0x18f