From owner-freebsd-current@freebsd.org Sun Feb 28 07:00:20 2016 Return-Path: Delivered-To: freebsd-current@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 AB354AAEECA for ; Sun, 28 Feb 2016 07:00:20 +0000 (UTC) (envelope-from mail@m.jwh.me.uk) Received: from eva.tinkyfi.com (eva.tinkyfi.com [107.191.63.190]) by mx1.freebsd.org (Postfix) with ESMTP id 78FC61FD3 for ; Sun, 28 Feb 2016 07:00:19 +0000 (UTC) (envelope-from mail@m.jwh.me.uk) Received: from [172.21.88.129] (cpc82705-staf9-2-0-cust342.3-1.cable.virginm.net [81.108.23.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mail@m.jwh.me.uk) by eva.tinkyfi.com (Postfix) with ESMTPSA id 3qCbFn0B7vz5Hj9 for ; Sun, 28 Feb 2016 07:00:12 +0000 (UTC) To: freebsd-current@freebsd.org From: Joe Holden Subject: Bay Trail 32bit UEFI Message-ID: <56D29AF6.50401@m.jwh.me.uk> Date: Sun, 28 Feb 2016 07:00:06 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 07:00:20 -0000 Hi all, Apologies if this is the wrong list... Is there any plan to support booting FreeBSD on 32bit UEFI systems (with or without 64bit kernel/userland)? Obviously there is no i386 efi loader currently so neither is possible... TIA, J From owner-freebsd-current@freebsd.org Sun Feb 28 16:56:44 2016 Return-Path: Delivered-To: freebsd-current@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 B5E3EAB74A6 for ; Sun, 28 Feb 2016 16:56:44 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 97FE9B16 for ; Sun, 28 Feb 2016 16:56:44 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=yPzM5E1kCTytDnFZj1NA+MtGWUTVPXg6fJNitDjwxwU=; b=qujNt2HLz2V0iVfLv9myZsZjSk 4TVGCQVyNtFy0mnF3MYYsmGewfrvnOrNlzTe2dLG4GTwcj2iChc02T3mafYX7XJG8DTm/bFeAsJDY 7AUkFfryCz0aIhafA9nL9TowpgHHBIbOFUc0FafVk1HzpGKS+68k/cco6C7cHd+Y/uhU=; Received: from [2605:6000:ec17:203:ed2:92ff:fe96:98a3] (port=23909 helo=lrosenman-dell2.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aa4eB-000CYz-AN for freebsd-current@freebsd.org; Sun, 28 Feb 2016 10:56:43 -0600 Date: Sun, 28 Feb 2016 10:56:33 -0600 From: Larry Rosenman To: freebsd-current@freebsd.org Subject: Mouse on Inspiron ? Message-ID: <20160228165632.GA1265@lrosenman-dell2.lerctr.org> Mail-Followup-To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Score: -1.0 (-) X-LERCTR-Spam-Score: -1.0 (-) X-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 X-LERCTR-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 16:56:44 -0000 --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I have a Dell Inspiron 5748 running -CURRENT, and I can't seem to get the mouse (trackpad) to work. I'm not sure where it's hiding. I don't see a /dev/psm0, but do see a /dev/sysmouse. Ideas? I'll attach a dmesg, and here's a pciconf -lv: hostb0@pci0:0:0:0: class=0x060000 card=0x06511028 chip=0x0a048086 rev=0x0b hdr=0x00 vendor = 'Intel Corporation' device = 'Haswell-ULT DRAM Controller' class = bridge subclass = HOST-PCI vgapci0@pci0:0:2:0: class=0x030000 card=0x06511028 chip=0x0a168086 rev=0x0b hdr=0x00 vendor = 'Intel Corporation' device = 'Haswell-ULT Integrated Graphics Controller' class = display subclass = VGA hdac0@pci0:0:3:0: class=0x040300 card=0x06511028 chip=0x0a0c8086 rev=0x0b hdr=0x00 vendor = 'Intel Corporation' device = 'Haswell-ULT HD Audio Controller' class = multimedia subclass = HDA none0@pci0:0:22:0: class=0x078000 card=0x06511028 chip=0x9c3a8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '8 Series HECI' class = simple comms hdac1@pci0:0:27:0: class=0x040300 card=0x06511028 chip=0x9c208086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '8 Series HD Audio Controller' class = multimedia subclass = HDA pcib1@pci0:0:28:0: class=0x060400 card=0x06511028 chip=0x9c108086 rev=0xe4 hdr=0x01 vendor = 'Intel Corporation' device = '8 Series PCI Express Root Port 1' class = bridge subclass = PCI-PCI pcib2@pci0:0:28:2: class=0x060400 card=0x06511028 chip=0x9c148086 rev=0xe4 hdr=0x01 vendor = 'Intel Corporation' device = '8 Series PCI Express Root Port 3' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:3: class=0x060400 card=0x06511028 chip=0x9c168086 rev=0xe4 hdr=0x01 vendor = 'Intel Corporation' device = '8 Series PCI Express Root Port 4' class = bridge subclass = PCI-PCI ehci0@pci0:0:29:0: class=0x0c0320 card=0x06511028 chip=0x9c268086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '8 Series USB EHCI' class = serial bus subclass = USB isab0@pci0:0:31:0: class=0x060100 card=0x06511028 chip=0x9c438086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '8 Series LPC Controller' class = bridge subclass = PCI-ISA ahci0@pci0:0:31:2: class=0x010601 card=0x06511028 chip=0x9c038086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '8 Series SATA Controller 1 [AHCI mode]' class = mass storage subclass = SATA ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x06511028 chip=0x9c228086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '8 Series SMBus Controller' class = serial bus subclass = SMBus iwn0@pci0:6:0:0: class=0x028000 card=0x00628086 chip=0x08928086 rev=0xc4 hdr=0x00 vendor = 'Intel Corporation' device = 'Centrino Wireless-N 135' class = network re0@pci0:7:0:0: class=0x020000 card=0x06511028 chip=0x813610ec rev=0x07 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller' class = network subclass = ethernet -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.boot" Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r296155: Sun Feb 28 07:52:00 CST 2016 root@lrosenman-dell2:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225 WARNING: WITNESS option enabled, expect reduced performance. VT(efifb): resolution 1600x900 CPU: Intel(R) Core(TM) i3-4030U CPU @ 1.90GHz (1895.66-MHz K8-class CPU) Origin="GenuineIntel" Id=0x40651 Family=0x6 Model=0x45 Stepping=1 Features=0xbfebfbff Features2=0x7ffafbbf AMD Features=0x2c100800 AMD Features2=0x21 Structured Extended Features=0x27ab XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 8148996096 (7771 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 random: unblocking device. ioapic0 irqs 0-39 on motherboard Cuse v0.1.34 @ /dev/cuse random: entropy device external interface kbd1 at kbdmux0 netmap: loaded module module_register_init: MOD_LOAD (vesa, 0xffffffff80ee3b40, 0) error 19 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" cryptosoft0: on motherboard aesni0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf000-0xf03f mem 0xf7800000-0xf7bfffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 vgapci0: Boot video device hdac0: mem 0xf7e04000-0xf7e07fff irq 16 at device 3.0 on pci0 pci0: at device 22.0 (no driver attached) hdac1: mem 0xf7e00000-0xf7e03fff irq 22 at device 27.0 on pci0 pcib1: irq 16 at device 28.0 on pci0 pci1: on pcib1 pcib2: irq 18 at device 28.2 on pci0 pci2: on pcib2 iwn0: mem 0xf7d00000-0xf7d01fff irq 18 at device 0.0 on pci2 pcib3: irq 19 at device 28.3 on pci0 pci3: on pcib3 re0: port 0xe000-0xe0ff mem 0xf7c00000-0xf7c00fff,0xf0000000-0xf0003fff irq 19 at device 0.0 on pci3 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x44800000 re0: MAC rev. 0x00100000 miibus0: on re0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow re0: Using defaults for TSO: 65518/35/2048 re0: Ethernet address: 74:e6:e2:11:77:8e re0: netmap queues/slots: TX 1/256, RX 1/256 ehci0: mem 0xf7e0b000-0xf7e0b3ff irq 23 at device 29.0 on pci0 usbus0: EHCI version 1.0 usbus0 on ehci0 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xf0b0-0xf0b7,0xf0a0-0xf0a3,0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xf7e0a000-0xf7e0a7ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 4 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ichsmb0: port 0xf040-0xf05f mem 0xf7e09000-0xf7e090ff irq 18 at device 31.3 on pci0 smbus0: on ichsmb0 battery0: on acpi0 acpi_acad0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64,0x62,0x66 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] orm0: at iomem 0xcf000-0xcffff on isa0 ppc0: cannot reserve I/O port range est0: on cpu0 est1: on cpu1 est2: on cpu2 est3: on cpu3 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 3 on hdaa0 hdacc1: at cad 0 on hdac1 hdaa1: at nid 1 on hdacc1 pcm1: at nid 20 and 18 on hdaa1 pcm2: at nid 33 on hdaa1 usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-2 ATA SATA 3.x device cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: Serial Number H086 038887 cd0: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed ada0: Serial Number WXC1E64E8Z3R ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors) SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 IAP/4/48/0x3ff IAF/3/48/0x67 UCP/8/48/0x3f8 UCF/1/48/0x60 Timecounter "TSC" frequency 1895659404 Hz quality 1000 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from zfs:zroot/ROOT/default []... Root mount waiting for: usbus0 uhub0: 2 ports with 2 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 uhub1: on usbus0 uhub1: 8 ports with 8 removable, self powered Root mount waiting for: usbus0 ugen0.3: at usbus0 Root mount waiting for: usbus0 ugen0.4: at usbus0 ugen0.5: at usbus0 wlan0: Ethernet address: 0c:d2:92:96:98:a3 iwn0: iwn_read_firmware: ucode rev=0x12a80601 iwn0: iwn_read_firmware: ucode rev=0x12a80601 wlan0: link state changed to UP re0: link state changed to DOWN ubt0: on usbus0 WARNING: attempt to domain_add(bluetooth) after domainfinalize() WARNING: attempt to domain_add(netgraph) after domainfinalize() --/9DWx/yDrRhgMJTb-- From owner-freebsd-current@freebsd.org Sun Feb 28 17:45:29 2016 Return-Path: Delivered-To: freebsd-current@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 447A3AB6411 for ; Sun, 28 Feb 2016 17:45:29 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 18AC61F1D for ; Sun, 28 Feb 2016 17:45:29 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:To:From:Date; bh=yAW4/vKLq2YEzlrCo+mc2gUXRDbTGShEeFCgpw/+zJs=; b=kH7e KNbcs0HIaETOcgwTC/EQycbEQVyaVgSR3aQAKIYb5N6XKNN3ZHP3bEzVv8UcA0DiUdppOxJKKoIwG ylTgxlg/WJEGpI2sWEpXqjhGVt/kNMeVbOKyf7TqaY4eWom/Om5q2etL76NUZ4MooDkfHDZdZvPDS oHZrImsDtjHyg=; Received: from [2605:6000:ec17:203:ed2:92ff:fe96:98a3] (port=19879 helo=lrosenman-dell2.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aa5PL-000Dma-Qv for freebsd-current@freebsd.org; Sun, 28 Feb 2016 11:45:28 -0600 Date: Sun, 28 Feb 2016 11:45:19 -0600 From: Larry Rosenman To: freebsd-current@freebsd.org Subject: Re: Mouse on Inspiron ? Message-ID: <20160228174518.GA1167@lrosenman-dell2.lerctr.org> Mail-Followup-To: freebsd-current@freebsd.org References: <20160228165632.GA1265@lrosenman-dell2.lerctr.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <20160228165632.GA1265@lrosenman-dell2.lerctr.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Score: -1.0 (-) X-LERCTR-Spam-Score: -1.0 (-) X-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 X-LERCTR-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 17:45:29 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Ok, a verbose boot tells me /dev/psm0 can't allocate an IRQ. Ideas? Verbose boot attached -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.boot" WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from zfs:zroot/ROOT/default []... Root mount waiting for: usbus0 uhub0: 2 ports with 2 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 uhub1: on usbus0 uhub1: 8 ports with 8 removable, self powered Root mount waiting for: usbus0 ugen0.3: at usbus0 Root mount waiting for: usbus0 ugen0.4: at usbus0 ugen0.5: at usbus0 wlan0: Ethernet address: 0c:d2:92:96:98:a3 iwn0: iwn_read_firmware: ucode rev=0x12a80601 iwn0: iwn_read_firmware: ucode rev=0x12a80601 wlan0: link state changed to UP re0: link state changed to DOWN ubt0: on usbus0 WARNING: attempt to domain_add(bluetooth) after domainfinalize() WARNING: attempt to domain_add(netgraph) after domainfinalize() wlan0: link state changed to DOWN Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 0 0 done All buffers synced. lock order reversal: 1st 0xfffff800108775f0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1222 2nd 0xfffff80010772240 zfs_gfs (zfs_gfs) @ /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/gfs.c:494 stack backtrace: #0 0xffffffff80a7f8d0 at witness_debugger+0x70 #1 0xffffffff80a7f7d1 at witness_checkorder+0xe71 #2 0xffffffff809fe68b at __lockmgr_args+0xd3b #3 0xffffffff80ac533c at vop_stdlock+0x3c #4 0xffffffff80fbfb10 at VOP_LOCK1_APV+0x100 #5 0xffffffff80ae601a at _vn_lock+0x9a #6 0xffffffff820b7b13 at gfs_file_create+0x73 #7 0xffffffff820b7bbd at gfs_dir_create+0x1d #8 0xffffffff82180f57 at zfsctl_mknode_snapdir+0x47 #9 0xffffffff820b8135 at gfs_dir_lookup+0x185 #10 0xffffffff820b861d at gfs_vop_lookup+0x1d #11 0xffffffff8217ff75 at zfsctl_root_lookup+0xf5 #12 0xffffffff82180e13 at zfsctl_umount_snapshots+0x83 #13 0xffffffff82199cfb at zfs_umount+0x7b #14 0xffffffff80acecf0 at dounmount+0x530 #15 0xffffffff80ad82fb at vfs_unmountall+0x6b #16 0xffffffff80ab9579 at bufshutdown+0x3b9 #17 0xffffffff80a24d99 at kern_reboot+0x189 lock order reversal: 1st 0xfffff8001051c7c8 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1222 2nd 0xfffff8000dfd5240 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2498 stack backtrace: #0 0xffffffff80a7f8d0 at witness_debugger+0x70 #1 0xffffffff80a7f7d1 at witness_checkorder+0xe71 #2 0xffffffff809fe68b at __lockmgr_args+0xd3b #3 0xffffffff80ac533c at vop_stdlock+0x3c #4 0xffffffff80fbfb10 at VOP_LOCK1_APV+0x100 #5 0xffffffff80ae601a at _vn_lock+0x9a #6 0xffffffff80ad65d3 at vget+0x63 #7 0xffffffff808fac7d at devfs_allocv+0xcd #8 0xffffffff808fa783 at devfs_root+0x43 #9 0xffffffff80acec0f at dounmount+0x44f #10 0xffffffff80ad8354 at vfs_unmountall+0xc4 #11 0xffffffff80ab9579 at bufshutdown+0x3b9 #12 0xffffffff80a24d99 at kern_reboot+0x189 #13 0xffffffff80a24bb3 at sys_reboot+0x3e3 #14 0xffffffff80e6f15b at amd64_syscall+0x2db #15 0xffffffff80e4ecab at Xfast_syscall+0xfb Uptime: 6m13s Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r296155: Sun Feb 28 07:52:00 CST 2016 root@lrosenman-dell2:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225 WARNING: WITNESS option enabled, expect reduced performance. VT(efifb): resolution 1600x900 CPU: Intel(R) Core(TM) i3-4030U CPU @ 1.90GHz (1895.65-MHz K8-class CPU) Origin="GenuineIntel" Id=0x40651 Family=0x6 Model=0x45 Stepping=1 Features=0xbfebfbff Features2=0x7ffafbbf AMD Features=0x2c100800 AMD Features2=0x21 Structured Extended Features=0x27ab XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 8148971520 (7771 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 random: unblocking device. ioapic0 irqs 0-39 on motherboard Cuse v0.1.34 @ /dev/cuse random: entropy device external interface kbd1 at kbdmux0 netmap: loaded module module_register_init: MOD_LOAD (vesa, 0xffffffff80ee3b40, 0) error 19 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" cryptosoft0: on motherboard aesni0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf000-0xf03f mem 0xf7800000-0xf7bfffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 vgapci0: Boot video device hdac0: mem 0xf7e04000-0xf7e07fff irq 16 at device 3.0 on pci0 pci0: at device 22.0 (no driver attached) hdac1: mem 0xf7e00000-0xf7e03fff irq 22 at device 27.0 on pci0 pcib1: irq 16 at device 28.0 on pci0 pci1: on pcib1 pcib2: irq 18 at device 28.2 on pci0 pci2: on pcib2 iwn0: mem 0xf7d00000-0xf7d01fff irq 18 at device 0.0 on pci2 pcib3: irq 19 at device 28.3 on pci0 pci3: on pcib3 re0: port 0xe000-0xe0ff mem 0xf7c00000-0xf7c00fff,0xf0000000-0xf0003fff irq 19 at device 0.0 on pci3 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x44800000 re0: MAC rev. 0x00100000 miibus0: on re0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow re0: Using defaults for TSO: 65518/35/2048 re0: Ethernet address: 74:e6:e2:11:77:8e re0: netmap queues/slots: TX 1/256, RX 1/256 ehci0: mem 0xf7e0b000-0xf7e0b3ff irq 23 at device 29.0 on pci0 usbus0: EHCI version 1.0 usbus0 on ehci0 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xf0b0-0xf0b7,0xf0a0-0xf0a3,0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xf7e0a000-0xf7e0a7ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 4 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ichsmb0: port 0xf040-0xf05f mem 0xf7e09000-0xf7e090ff irq 18 at device 31.3 on pci0 smbus0: on ichsmb0 battery0: on acpi0 acpi_acad0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64,0x62,0x66 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] orm0: at iomem 0xcf000-0xcffff on isa0 ppc0: cannot reserve I/O port range coretemp0: on cpu0 est0: on cpu0 coretemp1: on cpu1 est1: on cpu1 coretemp2: on cpu2 est2: on cpu2 coretemp3: on cpu3 est3: on cpu3 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 3 on hdaa0 hdacc1: at cad 0 on hdac1 hdaa1: at nid 1 on hdacc1 pcm1: at nid 20 and 18 on hdaa1 pcm2: at nid 33 on hdaa1 usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-2 ATA SATA 3.x device cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: Serial Number H086 038887 cd0: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed ada0: Serial Number WXC1E64E8Z3R ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors) SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 IAP/4/48/0x3ff IAF/3/48/0x67 UCP/8/48/0x3f8 UCF/1/48/0x60 Timecounter "TSC" frequency 1895651464 Hz quality 1000 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from zfs:zroot/ROOT/default []... Root mount waiting for: usbus0 uhub0: 2 ports with 2 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 uhub1: on usbus0 uhub1: 8 ports with 8 removable, self powered Root mount waiting for: usbus0 ugen0.3: at usbus0 Root mount waiting for: usbus0 ugen0.4: at usbus0 ugen0.5: at usbus0 wlan0: Ethernet address: 0c:d2:92:96:98:a3 iwn0: iwn_read_firmware: ucode rev=0x12a80601 iwn0: iwn_read_firmware: ucode rev=0x12a80601 wlan0: link state changed to UP re0: link state changed to DOWN ubt0: on usbus0 wlan0: link state changed to DOWN WARNING: attempt to domain_add(bluetooth) after domainfinalize() WARNING: attempt to domain_add(netgraph) after domainfinalize() Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 0 0 done All buffers synced. lock order reversal: 1st 0xfffff8001081ab78 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1222 2nd 0xfffff8001081a5f0 zfs_gfs (zfs_gfs) @ /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/gfs.c:494 stack backtrace: #0 0xffffffff80a7f8d0 at witness_debugger+0x70 #1 0xffffffff80a7f7d1 at witness_checkorder+0xe71 #2 0xffffffff809fe68b at __lockmgr_args+0xd3b #3 0xffffffff80ac533c at vop_stdlock+0x3c #4 0xffffffff80fbfb10 at VOP_LOCK1_APV+0x100 #5 0xffffffff80ae601a at _vn_lock+0x9a #6 0xffffffff820b7b13 at gfs_file_create+0x73 #7 0xffffffff820b7bbd at gfs_dir_create+0x1d #8 0xffffffff82180f57 at zfsctl_mknode_snapdir+0x47 #9 0xffffffff820b8135 at gfs_dir_lookup+0x185 #10 0xffffffff820b861d at gfs_vop_lookup+0x1d #11 0xffffffff8217ff75 at zfsctl_root_lookup+0xf5 #12 0xffffffff82180e13 at zfsctl_umount_snapshots+0x83 #13 0xffffffff82199cfb at zfs_umount+0x7b #14 0xffffffff80acecf0 at dounmount+0x530 #15 0xffffffff80ad82fb at vfs_unmountall+0x6b #16 0xffffffff80ab9579 at bufshutdown+0x3b9 #17 0xffffffff80a24d99 at kern_reboot+0x189 lock order reversal: 1st 0xfffff800105077c8 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1222 2nd 0xfffff8000dfbe240 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2498 stack backtrace: #0 0xffffffff80a7f8d0 at witness_debugger+0x70 #1 0xffffffff80a7f7d1 at witness_checkorder+0xe71 #2 0xffffffff809fe68b at __lockmgr_args+0xd3b #3 0xffffffff80ac533c at vop_stdlock+0x3c #4 0xffffffff80fbfb10 at VOP_LOCK1_APV+0x100 #5 0xffffffff80ae601a at _vn_lock+0x9a #6 0xffffffff80ad65d3 at vget+0x63 #7 0xffffffff808fac7d at devfs_allocv+0xcd #8 0xffffffff808fa783 at devfs_root+0x43 #9 0xffffffff80acec0f at dounmount+0x44f #10 0xffffffff80ad8354 at vfs_unmountall+0xc4 #11 0xffffffff80ab9579 at bufshutdown+0x3b9 #12 0xffffffff80a24d99 at kern_reboot+0x189 #13 0xffffffff80a24bb3 at sys_reboot+0x3e3 #14 0xffffffff80e6f15b at amd64_syscall+0x2db #15 0xffffffff80e4ecab at Xfast_syscall+0xfb Uptime: 59s Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r296155: Sun Feb 28 07:52:00 CST 2016 root@lrosenman-dell2:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225 WARNING: WITNESS option enabled, expect reduced performance. VT(efifb): resolution 1600x900 CPU: Intel(R) Core(TM) i3-4030U CPU @ 1.90GHz (1895.66-MHz K8-class CPU) Origin="GenuineIntel" Id=0x40651 Family=0x6 Model=0x45 Stepping=1 Features=0xbfebfbff Features2=0x7ffafbbf AMD Features=0x2c100800 AMD Features2=0x21 Structured Extended Features=0x27ab XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 8148971520 (7771 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 random: unblocking device. ioapic0 irqs 0-39 on motherboard Cuse v0.1.34 @ /dev/cuse random: entropy device external interface kbd1 at kbdmux0 netmap: loaded module module_register_init: MOD_LOAD (vesa, 0xffffffff80ee3b40, 0) error 19 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" cryptosoft0: on motherboard aesni0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf000-0xf03f mem 0xf7800000-0xf7bfffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 vgapci0: Boot video device hdac0: mem 0xf7e04000-0xf7e07fff irq 16 at device 3.0 on pci0 pci0: at device 22.0 (no driver attached) hdac1: mem 0xf7e00000-0xf7e03fff irq 22 at device 27.0 on pci0 pcib1: irq 16 at device 28.0 on pci0 pci1: on pcib1 pcib2: irq 18 at device 28.2 on pci0 pci2: on pcib2 iwn0: mem 0xf7d00000-0xf7d01fff irq 18 at device 0.0 on pci2 pcib3: irq 19 at device 28.3 on pci0 pci3: on pcib3 re0: port 0xe000-0xe0ff mem 0xf7c00000-0xf7c00fff,0xf0000000-0xf0003fff irq 19 at device 0.0 on pci3 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x44800000 re0: MAC rev. 0x00100000 miibus0: on re0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow re0: Using defaults for TSO: 65518/35/2048 re0: Ethernet address: 74:e6:e2:11:77:8e re0: netmap queues/slots: TX 1/256, RX 1/256 ehci0: mem 0xf7e0b000-0xf7e0b3ff irq 23 at device 29.0 on pci0 usbus0: EHCI version 1.0 usbus0 on ehci0 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xf0b0-0xf0b7,0xf0a0-0xf0a3,0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xf7e0a000-0xf7e0a7ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 4 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ichsmb0: port 0xf040-0xf05f mem 0xf7e09000-0xf7e090ff irq 18 at device 31.3 on pci0 smbus0: on ichsmb0 battery0: on acpi0 acpi_acad0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64,0x62,0x66 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] orm0: at iomem 0xcf000-0xcffff on isa0 ppc0: cannot reserve I/O port range coretemp0: on cpu0 est0: on cpu0 coretemp1: on cpu1 est1: on cpu1 coretemp2: on cpu2 est2: on cpu2 coretemp3: on cpu3 est3: on cpu3 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 3 on hdaa0 hdacc1: at cad 0 on hdac1 hdaa1: at nid 1 on hdacc1 pcm1: at nid 20 and 18 on hdaa1 pcm2: at nid 33 on hdaa1 usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-2 ATA SATA 3.x device cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: Serial Number H086 038887 cd0: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed ada0: Serial Number WXC1E64E8Z3R ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors) SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 IAP/4/48/0x3ff IAF/3/48/0x67 UCP/8/48/0x3f8 UCF/1/48/0x60 Timecounter "TSC" frequency 1895656048 Hz quality 1000 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from zfs:zroot/ROOT/default []... Root mount waiting for: usbus0 uhub0: 2 ports with 2 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 uhub1: on usbus0 uhub1: 8 ports with 8 removable, self powered Root mount waiting for: usbus0 ugen0.3: at usbus0 Root mount waiting for: usbus0 ugen0.4: at usbus0 ugen0.5: at usbus0 wlan0: Ethernet address: 0c:d2:92:96:98:a3 iwn0: iwn_read_firmware: ucode rev=0x12a80601 iwn0: iwn_read_firmware: ucode rev=0x12a80601 wlan0: link state changed to UP re0: link state changed to DOWN ubt0: on usbus0 wlan0: link state changed to DOWN Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 0 0 done All buffers synced. lock order reversal: 1st 0xfffff800108355f0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1222 2nd 0xfffff80010835068 zfs_gfs (zfs_gfs) @ /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/gfs.c:494 stack backtrace: #0 0xffffffff80a7f8d0 at witness_debugger+0x70 #1 0xffffffff80a7f7d1 at witness_checkorder+0xe71 #2 0xffffffff809fe68b at __lockmgr_args+0xd3b #3 0xffffffff80ac533c at vop_stdlock+0x3c #4 0xffffffff80fbfb10 at VOP_LOCK1_APV+0x100 #5 0xffffffff80ae601a at _vn_lock+0x9a #6 0xffffffff820b7b13 at gfs_file_create+0x73 #7 0xffffffff820b7bbd at gfs_dir_create+0x1d #8 0xffffffff82180f57 at zfsctl_mknode_snapdir+0x47 #9 0xffffffff820b8135 at gfs_dir_lookup+0x185 #10 0xffffffff820b861d at gfs_vop_lookup+0x1d #11 0xffffffff8217ff75 at zfsctl_root_lookup+0xf5 #12 0xffffffff82180e13 at zfsctl_umount_snapshots+0x83 #13 0xffffffff82199cfb at zfs_umount+0x7b #14 0xffffffff80acecf0 at dounmount+0x530 #15 0xffffffff80ad82fb at vfs_unmountall+0x6b #16 0xffffffff80ab9579 at bufshutdown+0x3b9 #17 0xffffffff80a24d99 at kern_reboot+0x189 lock order reversal: 1st 0xfffff800104ef7c8 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1222 2nd 0xfffff8000dfd2240 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2498 stack backtrace: #0 0xffffffff80a7f8d0 at witness_debugger+0x70 #1 0xffffffff80a7f7d1 at witness_checkorder+0xe71 #2 0xffffffff809fe68b at __lockmgr_args+0xd3b #3 0xffffffff80ac533c at vop_stdlock+0x3c #4 0xffffffff80fbfb10 at VOP_LOCK1_APV+0x100 #5 0xffffffff80ae601a at _vn_lock+0x9a #6 0xffffffff80ad65d3 at vget+0x63 #7 0xffffffff808fac7d at devfs_allocv+0xcd #8 0xffffffff808fa783 at devfs_root+0x43 #9 0xffffffff80acec0f at dounmount+0x44f #10 0xffffffff80ad8354 at vfs_unmountall+0xc4 #11 0xffffffff80ab9579 at bufshutdown+0x3b9 #12 0xffffffff80a24d99 at kern_reboot+0x189 #13 0xffffffff80a24bb3 at sys_reboot+0x3e3 #14 0xffffffff80e6f15b at amd64_syscall+0x2db #15 0xffffffff80e4ecab at Xfast_syscall+0xfb Uptime: 35s Table 'FACP' at 0xdabf17c0 Table 'APIC' at 0xdabf18d0 APIC: Found table at 0xdabf18d0 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 2 ACPI ID 2: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 1 ACPI ID 3: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 3 ACPI ID 4: enabled SMP: Added CPU 3 (AP) Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r296155: Sun Feb 28 07:52:00 CST 2016 root@lrosenman-dell2:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225 WARNING: WITNESS option enabled, expect reduced performance. PPIM 0: PA=0xe0000000, VA=0xffffffff83010000, size=0x57f000, mode=0x1 VT(efifb): resolution 1600x900 Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff82eab000. Preloaded /boot/entropy "/boot/entropy" at 0xffffffff82eacd68. Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff82eacdb8. Preloaded elf obj module "/boot/kernel/opensolaris.ko" at 0xffffffff82ead5a0. Preloaded elf obj module "/boot/kernel/coretemp.ko" at 0xffffffff82eadbd0. Preloaded elf obj module "/boot/kernel/ichsmb.ko" at 0xffffffff82eae180. Preloaded elf obj module "/boot/kernel/smbus.ko" at 0xffffffff82eae728. Preloaded elf obj module "/boot/kernel/hwpmc.ko" at 0xffffffff82eaec50. Preloaded elf obj module "/boot/kernel/iwn135fw.ko" at 0xffffffff82eaf338. Preloaded elf obj module "/boot/kernel/aesni.ko" at 0xffffffff82eaf868. Preloaded elf obj module "/boot/kernel/cryptodev.ko" at 0xffffffff82eaff50. Preloaded elf obj module "/boot/kernel/dtraceall.ko" at 0xffffffff82eb0600. Preloaded elf obj module "/boot/kernel/profile.ko" at 0xffffffff82eb0af0. Preloaded elf obj module "/boot/kernel/dtrace.ko" at 0xffffffff82eb1198. Preloaded elf obj module "/boot/kernel/systrace_freebsd32.ko" at 0xffffffff82eb18c0. Preloaded elf obj module "/boot/kernel/systrace.ko" at 0xffffffff82eb1ef8. Preloaded elf obj module "/boot/kernel/sdt.ko" at 0xffffffff82eb2528. Preloaded elf obj module "/boot/kernel/fasttrap.ko" at 0xffffffff82eb2ad0. Preloaded elf obj module "/boot/kernel/fbt.ko" at 0xffffffff82eb3200. Preloaded elf obj module "/boot/kernel/dtnfscl.ko" at 0xffffffff82eb3828. Preloaded elf obj module "/boot/kernel/dtmalloc.ko" at 0xffffffff82eb3e50. Preloaded elf obj module "/boot/kernel/cpuctl.ko" at 0xffffffff82eb4480. Preloaded elf obj module "/boot/kernel/cuse.ko" at 0xffffffff82eb4aa8. Calibrating TSC clock ... TSC clock: 1895652288 Hz CPU: Intel(R) Core(TM) i3-4030U CPU @ 1.90GHz (1895.65-MHz K8-class CPU) Origin="GenuineIntel" Id=0x40651 Family=0x6 Model=0x45 Stepping=1 Features=0xbfebfbff Features2=0x7ffafbbf AMD Features=0x2c100800 AMD Features2=0x21 Structured Extended Features=0x27ab XSAVE Features=0x1 VT-x: Basic Features=0xda0400 Pin-Based Controls=0x7f Primary Processor Controls=0xfff9fffe Secondary Processor Controls=0x3cff Exit Controls=0xda0400 Entry Controls=0xda0400 EPT Features=0x6334141 VPID Features=0xf01 TSC: P-state invariant, performance statistics Data TLB: 1 GByte pages, 4-way set associative, 4 entries Data TLB: 4 KB pages, 4-way set associative, 64 entries Instruction TLB: 2M/4M pages, fully associative, 8 entries Instruction TLB: 4KByte pages, 8-way set associative, 64 entries 64-Byte prefetching Shared 2nd-Level TLB: 4 KByte/2MByte pages, 8-way associative, 1024 entries L2 cache: 256 kbytes, 8-way associative, 64 bytes/line real memory = 8589934592 (8192 MB) Physical memory chunk(s): 0x0000000000010000 - 0x0000000000053fff, 278528 bytes (68 pages) 0x0000000000059000 - 0x000000000009efff, 286720 bytes (70 pages) 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) 0x0000000002efd000 - 0x00000000caff0fff, 3356442624 bytes (819444 pages) 0x00000000caff8000 - 0x00000000cb421fff, 4366336 bytes (1066 pages) 0x00000000cba1e000 - 0x00000000da86afff, 249876480 bytes (61005 pages) 0x00000000dbfff000 - 0x00000000dbffffff, 4096 bytes (1 pages) 0x0000000100000000 - 0x0000000211fe9fff, 4596867072 bytes (1122282 pages) avail memory = 8148971520 (7771 MB) Table 'FACP' at 0xdabf17c0 Table 'APIC' at 0xdabf18d0 Table 'FPDT' at 0xdabf1948 Table 'ASF!' at 0xdabf1990 Table 'LPIT' at 0xdabf1a38 Table 'SSDT' at 0xdabf1ad0 Table 'SLIC' at 0xdabf1cf8 Table 'SSDT' at 0xdabf1e70 Table 'SSDT' at 0xdabf2348 Table 'MCFG' at 0xdabf2e20 Table 'HPET' at 0xdabf2e60 Table 'SSDT' at 0xdabf2e98 Table 'SSDT' at 0xdabf31b0 Table 'MSDM' at 0xdabf6758 Table 'BGRT' at 0xdabf67b0 Table 'DMAR' at 0xdabf67e8 DMAR: Found table at 0xdabf67e8 Event timer "LAPIC" quality 600 ACPI APIC Table: INTR: Adding local APIC 2 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 3 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 4 lapic0: CMCI unmasked x86bios: IVT 0x000000-0x0004ff at 0xfffff80000000000 x86bios: SSEG 0x059000-0x059fff at 0xfffffe02287b0000 x86bios: EBDA 0x09d000-0x09ffff at 0xfffff8000009d000 x86bios: ROM 0x0a0000-0x0fefff at 0xfffff800000a0000 random: read 4096 bytes from preloaded cache random: unblocking device. ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0x00000000DABE1000 000024 (v02 DELL ) ACPI: XSDT 0x00000000DABE1098 0000AC (v01 DELL WN09 01072009 AMI 00010013) ACPI: FACP 0x00000000DABF17C0 00010C (v05 DELL WN09 01072009 AMI 00010013) ACPI: DSDT 0x00000000DABE11D0 0105F0 (v02 DELL WN09 00000000 INTL 20120711) ACPI: FACS 0x00000000DB56FF80 000040 ACPI: APIC 0x00000000DABF18D0 000072 (v03 DELL WN09 01072009 AMI 00010013) ACPI: FPDT 0x00000000DABF1948 000044 (v01 DELL WN09 01072009 AMI 00010013) ACPI: ASF! 0x00000000DABF1990 0000A5 (v32 INTEL HCG 00000001 TFSM 000F4240) ACPI: LPIT 0x00000000DABF1A38 000094 (v01 ALASKA 00000000 AMI. 00000005) ACPI: SSDT 0x00000000DABF1AD0 000228 (v01 INTEL sensrhub 00000000 INTL 20120711) ACPI: SLIC 0x00000000DABF1CF8 000176 (v01 DELL WN09 01072009 AMI 00010013) ACPI: SSDT 0x00000000DABF1E70 0004D6 (v01 PmRef Cpu0Ist 00003000 INTL 20120711) ACPI: SSDT 0x00000000DABF2348 000AD8 (v01 PmRef CpuPm 00003000 INTL 20120711) ACPI: MCFG 0x00000000DABF2E20 00003C (v01 DELL WN09 01072009 MSFT 00000097) ACPI: HPET 0x00000000DABF2E60 000038 (v01 DELL WN09 01072009 AMI. 00000005) ACPI: SSDT 0x00000000DABF2E98 000315 (v01 SataRe SataTabl 00001000 INTL 20120711) ACPI: SSDT 0x00000000DABF31B0 0035A5 (v01 SaSsdt SaSsdt 00003000 INTL 20091112) ACPI: MSDM 0x00000000DABF6758 000055 (v03 DELL WN09 01072009 AMI 00010013) ACPI: BGRT 0x00000000DABF67B0 000038 (v00 DELL WN09 01072009 AMI 00010013) ACPI: DMAR 0x00000000DABF67E8 00015C (v01 INTEL HSW 00000001 INTL 00000001) ACPI: CSRT 0x00000000DABF6948 0000C4 (v01 INTL HSWULT-R 00000001 INTL 20100528) MADT: Found IO APIC ID 8, Interrupt 0 at 0xfec00000 ioapic0: ver 0x20 maxredir 0x27 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic: Routing NMI -> LINT1 lapic: LINT1 trigger: edge lapic: LINT1 polarity: high ioapic0 irqs 0-39 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x01060015 LDR: 0x00000001 DFR: 0x00000000 x2APIC: 1 lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000011ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 Cuse v0.1.34 @ /dev/cuse snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 random: entropy device external interface firmware: 'iwn135fw' version 0: 701228 bytes loaded at 0xffffffff824890b8 wlan: <802.11 Link Layer> kbd: new array size 4 kbd1 at kbdmux0 mem: nfslock: pseudo-device netmap: loaded module null: crypto: module_register_init: MOD_LOAD (vesa, 0xffffffff80ee3b40, 0) error 19 io: VMBUS: load random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" cpuctl: access to MSR registers/cpuid info. hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 hptnr: R750/DC7280 controller driver v1.1.4 hpt27xx: RocketRAID 27xx controller driver v1.2.7 random: harvesting attach, 8 bytes (4 bits) from ram0 cryptosoft0: on motherboard crypto: assign cryptosoft0 driver id 0, flags 100663296 crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 23 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 25 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 24 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 26 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 27 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 28 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 random: harvesting attach, 8 bytes (4 bits) from cryptosoft0 aesni0: on motherboard crypto: assign aesni0 driver id 1, flags 83886080 crypto: aesni0 registers alg 11 flags 0 maxoplen 0 crypto: aesni0 registers alg 23 flags 0 maxoplen 0 crypto: aesni0 registers alg 25 flags 0 maxoplen 0 crypto: aesni0 registers alg 26 flags 0 maxoplen 0 crypto: aesni0 registers alg 27 flags 0 maxoplen 0 crypto: aesni0 registers alg 28 flags 0 maxoplen 0 crypto: aesni0 registers alg 22 flags 0 maxoplen 0 random: harvesting attach, 8 bytes (4 bits) from aesni0 acpi0: on motherboard ACPI: 6 ACPI AML tables successfully acquired and loaded PCIe: Memory Mapped configuration base @ 0xf8000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 ACPI: Executed 1 blocks of module-level executable AML code acpi0: Power Button (fixed) random: harvesting attach, 8 bytes (4 bits) from acpi_sysresource0 random: harvesting attach, 8 bytes (4 bits) from acpi_sysresource1 random: harvesting attach, 8 bytes (4 bits) from acpi_sysresource2 random: harvesting attach, 8 bytes (4 bits) from acpi_sysresource3 random: harvesting attach, 8 bytes (4 bits) from acpi_sysresource4 random: harvesting attach, 8 bytes (4 bits) from acpi_sysresource5 cpu0: Processor \134_PR_.CPU0 (ACPI ID 1) -> APIC ID 0 cpu0: on acpi0 ACPI: Dynamic OEM Table Load: ACPI: SSDT 0xFFFFF800045A2400 0003D3 (v01 PmRef Cpu0Cst 00003001 INTL 20120711) random: harvesting attach, 8 bytes (4 bits) from cpu0 cpu1: Processor \134_PR_.CPU1 (ACPI ID 2) -> APIC ID 2 cpu1: on acpi0 ACPI: Dynamic OEM Table Load: ACPI: SSDT 0xFFFFF80006C5D800 0005AA (v01 PmRef ApIst 00003000 INTL 20120711) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0xFFFFF8000459A400 000119 (v01 PmRef ApCst 00003000 INTL 20120711) random: harvesting attach, 8 bytes (4 bits) from cpu1 cpu2: Processor \134_PR_.CPU2 (ACPI ID 3) -> APIC ID 1 cpu2: on acpi0 random: harvesting attach, 8 bytes (4 bits) from cpu2 cpu3: Processor \134_PR_.CPU3 (ACPI ID 4) -> APIC ID 3 cpu3: on acpi0 random: harvesting attach, 8 bytes (4 bits) from cpu3 ACPI: Processor \134_PR_.CPU4 (ACPI ID 5) ignored ACPI: Processor \134_PR_.CPU5 (ACPI ID 6) ignored ACPI: Processor \134_PR_.CPU6 (ACPI ID 7) ignored ACPI: Processor \134_PR_.CPU7 (ACPI ID 8) ignored hpet0: iomem 0xfed00000-0xfed003ff on acpi0 hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 8 timers, legacy route hpet0: t0: irqs 0x00f00000 (0), MSI, 64bit, periodic hpet0: t1: irqs 0x00f00000 (0), MSI hpet0: t2: irqs 0x00f00800 (0), MSI hpet0: t3: irqs 0x00f01000 (0), MSI hpet0: t4: irqs 0x00000000 (0), MSI hpet0: t5: irqs 0x00000000 (0), MSI hpet0: t6: irqs 0x00000000 (0), MSI hpet0: t7: irqs 0x00000000 (0), MSI Timecounter "HPET" frequency 14318180 Hz quality 950 msi: routing MSI-X IRQ 256 to local APIC 0 vector 49 msi: routing MSI-X IRQ 257 to local APIC 0 vector 50 msi: routing MSI-X IRQ 258 to local APIC 0 vector 51 msi: routing MSI-X IRQ 259 to local APIC 0 vector 52 msi: routing MSI-X IRQ 260 to local APIC 0 vector 53 msi: routing MSI-X IRQ 261 to local APIC 0 vector 54 msi: routing MSI-X IRQ 262 to local APIC 0 vector 55 msi: routing MSI-X IRQ 263 to local APIC 0 vector 56 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 random: harvesting attach, 8 bytes (4 bits) from hpet0 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 57 Event timer "RTC" frequency 32768 Hz quality 0 random: harvesting attach, 8 bytes (4 bits) from atrtc0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 58 Event timer "i8254" frequency 1193182 Hz quality 100 random: harvesting attach, 8 bytes (4 bits) from attimer0 ACPI timer: 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 random: harvesting attach, 8 bytes (4 bits) from acpi_timer0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15 random: harvesting attach, 8 bytes (4 bits) from pci_link0 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15 random: harvesting attach, 8 bytes (4 bits) from pci_link1 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 4 5 6 10 11 12 14 15 Validation 0 3 N 0 3 4 5 6 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15 random: harvesting attach, 8 bytes (4 bits) from pci_link2 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15 random: harvesting attach, 8 bytes (4 bits) from pci_link3 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15 random: harvesting attach, 8 bytes (4 bits) from pci_link4 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15 random: harvesting attach, 8 bytes (4 bits) from pci_link5 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15 random: harvesting attach, 8 bytes (4 bits) from pci_link6 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 4 N 0 3 4 5 6 10 11 12 14 15 Validation 0 4 N 0 3 4 5 6 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 10 11 12 14 15 random: harvesting attach, 8 bytes (4 bits) from pci_link7 pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 5 range 0-0x3e pcib0: decoding 4 range 0-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0xd0000-0xd3fff pcib0: decoding 3 range 0xd4000-0xd7fff pcib0: decoding 3 range 0xd8000-0xdbfff pcib0: decoding 3 range 0xdc000-0xdffff pcib0: decoding 3 range 0xdf200000-0xfeafffff pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x0a04, revid=0x0b domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x0a16, revid=0x0b domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xf7800000, size 22, enabled pcib0: allocated type 3 (0xf7800000-0xf7bfffff) for rid 10 of pci0:0:2:0 map[18]: type Prefetchable Memory, range 64, base 0xe0000000, size 28, enabled pcib0: allocated type 3 (0xe0000000-0xefffffff) for rid 18 of pci0:0:2:0 map[20]: type I/O Port, range 32, base 0xf000, size 6, enabled pcib0: allocated type 4 (0xf000-0xf03f) for rid 20 of pci0:0:2:0 pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x0a0c, revid=0x0b domain=0, bus=0, slot=3, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xf7e04000, size 14, memory disabled pcib0: allocated type 3 (0xf7e04000-0xf7e07fff) for rid 10 of pci0:0:3:0 pcib0: matched entry for 0.3.INTA pcib0: slot 3 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x9c3a, revid=0x04 domain=0, bus=0, slot=22, func=0 class=07-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf7e0d000, size 5, enabled pcib0: allocated type 3 (0xf7e0d000-0xf7e0d01f) for rid 10 of pci0:0:22:0 pcib0: matched entry for 0.22.INTA pcib0: slot 22 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x9c20, revid=0x04 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf7e00000, size 14, memory disabled pcib0: allocated type 3 (0xf7e00000-0xf7e03fff) for rid 10 of pci0:0:27:0 pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x9c10, revid=0xe4 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 secbus=4, subbus=4 found-> vendor=0x8086, dev=0x9c14, revid=0xe4 domain=0, bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=3 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTC pcib0: slot 28 INTC hardwired to IRQ 18 secbus=6, subbus=6 found-> vendor=0x8086, dev=0x9c16, revid=0xe4 domain=0, bus=0, slot=28, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTD pcib0: slot 28 INTD hardwired to IRQ 19 secbus=7, subbus=7 found-> vendor=0x8086, dev=0x9c26, revid=0x04 domain=0, bus=0, slot=29, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=4 powerspec 3 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf7e0b000, size 10, enabled pcib0: allocated type 3 (0xf7e0b000-0xf7e0b3ff) for rid 10 of pci0:0:29:0 pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 ehci early: SMM active, request owner change found-> vendor=0x8086, dev=0x9c43, revid=0x04 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x9c03, revid=0x04 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type I/O Port, range 32, base 0xf0b0, size 3, enabled pcib0: allocated type 4 (0xf0b0-0xf0b7) for rid 10 of pci0:0:31:2 map[14]: type I/O Port, range 32, base 0xf0a0, size 2, enabled pcib0: allocated type 4 (0xf0a0-0xf0a3) for rid 14 of pci0:0:31:2 map[18]: type I/O Port, range 32, base 0xf090, size 3, enabled pcib0: allocated type 4 (0xf090-0xf097) for rid 18 of pci0:0:31:2 map[1c]: type I/O Port, range 32, base 0xf080, size 2, enabled pcib0: allocated type 4 (0xf080-0xf083) for rid 1c of pci0:0:31:2 map[20]: type I/O Port, range 32, base 0xf060, size 5, enabled pcib0: allocated type 4 (0xf060-0xf07f) for rid 20 of pci0:0:31:2 map[24]: type Memory, range 32, base 0xf7e0a000, size 11, enabled pcib0: allocated type 3 (0xf7e0a000-0xf7e0a7ff) for rid 24 of pci0:0:31:2 pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x9c22, revid=0x04 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=3 map[10]: type Memory, range 64, base 0xf7e09000, size 8, enabled pcib0: allocated type 3 (0xf7e09000-0xf7e090ff) for rid 10 of pci0:0:31:3 map[20]: type I/O Port, range 32, base 0xf040, size 5, enabled pcib0: allocated type 4 (0xf040-0xf05f) for rid 20 of pci0:0:31:3 pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 random: harvesting attach, 8 bytes (4 bits) from hostb0 vgapci0: port 0xf000-0xf03f mem 0xf7800000-0xf7bfffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 vgapci0: Boot video device random: harvesting attach, 8 bytes (4 bits) from vgapci0 hdac0: mem 0xf7e04000-0xf7e07fff irq 16 at device 3.0 on pci0 hdac0: PCI card vendor: 0x1028, device: 0x0651 hdac0: HDA Driver Revision: 20120126_0002 hdac0: Config options: on=0x00000000 off=0x00000000 hdac0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 264 to local APIC 0 vector 59 hdac0: using IRQ 264 for MSI hdac0: Caps: OSS 2, ISS 0, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 random: harvesting attach, 8 bytes (4 bits) from hdac0 pci0: at device 22.0 (no driver attached) hdac1: mem 0xf7e00000-0xf7e03fff irq 22 at device 27.0 on pci0 hdac1: PCI card vendor: 0x1028, device: 0x0651 hdac1: HDA Driver Revision: 20120126_0002 hdac1: Config options: on=0x00000000 off=0x00000000 hdac1: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 265 to local APIC 0 vector 60 hdac1: using IRQ 265 for MSI hdac1: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 random: harvesting attach, 8 bytes (4 bits) from hdac1 pcib1: irq 16 at device 28.0 on pci0 pcib1: domain 0 pcib1: secondary bus 4 pcib1: subordinate bus 4 pci1: on pcib1 pcib1: allocated bus range (4-4) for rid 0 of pci1 pci1: domain=0, physical bus=4 random: harvesting attach, 8 bytes (4 bits) from pci1 random: harvesting attach, 8 bytes (4 bits) from pcib1 pcib2: irq 18 at device 28.2 on pci0 pcib0: allocated type 3 (0xf7d00000-0xf7dfffff) for rid 20 of pcib2 pcib2: domain 0 pcib2: secondary bus 6 pcib2: subordinate bus 6 pcib2: memory decode 0xf7d00000-0xf7dfffff pci2: on pcib2 pcib2: allocated bus range (6-6) for rid 0 of pci2 pci2: domain=0, physical bus=6 found-> vendor=0x8086, dev=0x0892, revid=0xc4 domain=0, bus=6, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf7d00000, size 13, memory disabled pcib2: allocated memory range (0xf7d00000-0xf7d01fff) for rid 10 of pci0:6:0:0 pcib2: matched entry for 6.0.INTA pcib2: slot 0 INTA hardwired to IRQ 18 iwn0: mem 0xf7d00000-0xf7d01fff irq 18 at device 0.0 on pci2 iwn0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 266 to local APIC 0 vector 61 iwn0: using IRQ 266 for MSI iwn0: MIMO 1T1R, BGN, address 0c:d2:92:96:98:a3 iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 1T1R iwn0: 11ng MCS 20MHz iwn0: MCS 0-7: 6.5Mbps - 65Mbps iwn0: 11ng MCS 20MHz SGI iwn0: MCS 0-7: 7Mbps - 72Mbps iwn0: 11ng MCS 40MHz: iwn0: MCS 0-7: 13.5Mbps - 135Mbps iwn0: 11ng MCS 40MHz SGI: iwn0: MCS 0-7: 15Mbps - 150Mbps random: harvesting attach, 8 bytes (4 bits) from iwn0 random: harvesting attach, 8 bytes (4 bits) from pci2 random: harvesting attach, 8 bytes (4 bits) from pcib2 pcib3: irq 19 at device 28.3 on pci0 pcib0: allocated type 4 (0xe000-0xefff) for rid 1c of pcib3 pcib0: allocated type 3 (0xf7c00000-0xf7cfffff) for rid 20 of pcib3 pcib0: allocated type 3 (0xf0000000-0xf00fffff) for rid 24 of pcib3 pcib3: domain 0 pcib3: secondary bus 7 pcib3: subordinate bus 7 pcib3: I/O decode 0xe000-0xefff pcib3: memory decode 0xf7c00000-0xf7cfffff pcib3: prefetched decode 0xf0000000-0xf00fffff pci3: on pcib3 pcib3: allocated bus range (7-7) for rid 0 of pci3 pci3: domain=0, physical bus=7 found-> vendor=0x10ec, dev=0x8136, revid=0x07 domain=0, bus=7, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 4 messages in map 0x20 map[10]: type I/O Port, range 32, base 0xe000, size 8, enabled pcib3: allocated I/O port range (0xe000-0xe0ff) for rid 10 of pci0:7:0:0 map[18]: type Memory, range 64, base 0xf7c00000, size 12, enabled pcib3: allocated memory range (0xf7c00000-0xf7c00fff) for rid 18 of pci0:7:0:0 map[20]: type Prefetchable Memory, range 64, base 0xf0000000, size 14, enabled pcib3: allocated prefetch range (0xf0000000-0xf0003fff) for rid 20 of pci0:7:0:0 pcib3: matched entry for 7.0.INTA pcib3: slot 0 INTA hardwired to IRQ 19 re0: port 0xe000-0xe0ff mem 0xf7c00000-0xf7c00fff,0xf0000000-0xf0003fff irq 19 at device 0.0 on pci3 re0: MSI count : 1 re0: MSI-X count : 4 re0: attempting to allocate 1 MSI-X vectors (4 supported) msi: routing MSI-X IRQ 267 to local APIC 0 vector 62 re0: using IRQ 267 for MSI-X re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x44800000 re0: MAC rev. 0x00100000 miibus0: on re0 rlphy0: PHY 1 on miibus0 rlphy0: OUI 0x00e04c, model 0x0008, rev. 2 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow random: harvesting attach, 8 bytes (4 bits) from rlphy0 random: harvesting attach, 8 bytes (4 bits) from miibus0 re0: Using defaults for TSO: 65518/35/2048 re0: bpf attached re0: Ethernet address: 74:e6:e2:11:77:8e re0: netmap queues/slots: TX 1/256, RX 1/256 random: harvesting attach, 8 bytes (4 bits) from re0 random: harvesting attach, 8 bytes (4 bits) from pci3 random: harvesting attach, 8 bytes (4 bits) from pcib3 ehci0: mem 0xf7e0b000-0xf7e0b3ff irq 23 at device 29.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 63 usbus0: EHCI version 1.0 usbus0 on ehci0 ehci0: usbpf: Attached random: harvesting attach, 8 bytes (4 bits) from usbus0 random: harvesting attach, 8 bytes (4 bits) from ehci0 isab0: at device 31.0 on pci0 isa0: on isab0 random: harvesting attach, 8 bytes (4 bits) from isa0 random: harvesting attach, 8 bytes (4 bits) from isab0 ahci0: port 0xf0b0-0xf0b7,0xf0a0-0xf0a3,0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xf7e0a000-0xf7e0a7ff irq 19 at device 31.2 on pci0 ahci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 268 to local APIC 0 vector 64 ahci0: using IRQ 268 for MSI ahci0: AHCI v1.30 with 4 6Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ ALP AL CLO 6Gbps PMD SSC PSC 32cmd 4ports ahci0: Caps2: DESO SADM SDS APST ahcich0: at channel 0 on ahci0 ahcich0: Caps: random: harvesting attach, 8 bytes (4 bits) from ahcich0 ahcich1: at channel 1 on ahci0 ahcich1: Caps: random: harvesting attach, 8 bytes (4 bits) from ahcich1 ahcich2: not probed (disabled) ahcich3: not probed (disabled) random: harvesting attach, 8 bytes (4 bits) from ahci0 ichsmb0: port 0xf040-0xf05f mem 0xf7e09000-0xf7e090ff irq 18 at device 31.3 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 65 smbus0: on ichsmb0 random: harvesting attach, 8 bytes (4 bits) from smbus0 random: harvesting attach, 8 bytes (4 bits) from ichsmb0 random: harvesting attach, 8 bytes (4 bits) from pci0 random: harvesting attach, 8 bytes (4 bits) from pcib0 battery0: on acpi0 random: harvesting attach, 8 bytes (4 bits) from battery0 acpi_acad0: on acpi0 random: harvesting attach, 8 bytes (4 bits) from acpi_acad0 acpi_lid0: on acpi0 random: harvesting attach, 8 bytes (4 bits) from acpi_lid0 acpi_button0: on acpi0 random: harvesting attach, 8 bytes (4 bits) from acpi_button0 acpi_button1: on acpi0 random: harvesting attach, 8 bytes (4 bits) from acpi_button1 acpi_tz0: on acpi0 random: harvesting attach, 8 bytes (4 bits) from acpi_tz0 random: harvesting attach, 8 bytes (4 bits) from atdma0 atkbdc0: port 0x60,0x64,0x62,0x66 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x1d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 66 atkbd0: [GIANT-LOCKED] random: harvesting attach, 8 bytes (4 bits) from atkbd0 psm0: unable to allocate IRQ random: harvesting attach, 8 bytes (4 bits) from atkbdc0 ACPI: Enabled 4 GPEs in block 00 to 7F random: harvesting attach, 8 bytes (4 bits) from acpi0 random: harvesting attach, 8 bytes (4 bits) from apic0 acpi0: wakeup code va 0xfffffe02328ef000 pa 0x50000 random: harvesting attach, 8 bytes (4 bits) from nexus0 ahc_isa_identify 0: ioport 0xc00 alloc failed ahc_isa_identify 1: ioport 0x1c00 alloc failed ahc_isa_identify 2: ioport 0x2c00 alloc failed ahc_isa_identify 3: ioport 0x3c00 alloc failed ahc_isa_identify 4: ioport 0x4c00 alloc failed ahc_isa_identify 5: ioport 0x5c00 alloc failed ahc_isa_identify 6: ioport 0x6c00 alloc failed ahc_isa_identify 7: ioport 0x7c00 alloc failed ahc_isa_identify 8: ioport 0x8c00 alloc failed ahc_isa_identify 9: ioport 0x9c00 alloc failed ahc_isa_identify 10: ioport 0xac00 alloc failed ahc_isa_identify 11: ioport 0xbc00 alloc failed ahc_isa_identify 12: ioport 0xcc00 alloc failed ahc_isa_identify 13: ioport 0xdc00 alloc failed ahc_isa_identify 14: ioport 0xec00 alloc failed pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 pcib0: allocated type 3 (0xd0000-0xd07ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd0800-0xd0fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd1000-0xd17ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd1800-0xd1fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd2000-0xd27ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd2800-0xd2fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd3000-0xd37ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd3800-0xd3fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd4000-0xd47ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd4800-0xd4fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd5000-0xd57ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd5800-0xd5fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd6000-0xd67ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd6800-0xd6fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd7000-0xd77ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd7800-0xd7fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd8000-0xd87ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd8800-0xd8fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd9000-0xd97ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd9800-0xd9fff) for rid 1 of orm0 pcib0: allocated type 3 (0xda000-0xda7ff) for rid 1 of orm0 pcib0: allocated type 3 (0xda800-0xdafff) for rid 1 of orm0 pcib0: allocated type 3 (0xdb000-0xdb7ff) for rid 1 of orm0 pcib0: allocated type 3 (0xdb800-0xdbfff) for rid 1 of orm0 pcib0: allocated type 3 (0xdc000-0xdc7ff) for rid 1 of orm0 pcib0: allocated type 3 (0xdc800-0xdcfff) for rid 1 of orm0 pcib0: allocated type 3 (0xdd000-0xdd7ff) for rid 1 of orm0 pcib0: allocated type 3 (0xdd800-0xddfff) for rid 1 of orm0 pcib0: allocated type 3 (0xde000-0xde7ff) for rid 1 of orm0 pcib0: allocated type 3 (0xde800-0xdefff) for rid 1 of orm0 pcib0: allocated type 3 (0xdf000-0xdf7ff) for rid 1 of orm0 pcib0: allocated type 3 (0xdf800-0xdffff) for rid 1 of orm0 isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xcf000-0xcffff on isa0 random: harvesting attach, 8 bytes (4 bits) from orm0 sc0 failed to probe on isa0 vga0 failed to probe on isa0 pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: cannot reserve I/O port range ppc0 failed to probe at irq 7 on isa0 pcib0: allocated type 4 (0x3f8-0x3f8) for rid 0 of uart0 uart0 failed to probe at port 0x3f8 irq 4 on isa0 pcib0: allocated type 4 (0x2f8-0x2f8) for rid 0 of uart1 uart1 failed to probe at port 0x2f8 irq 3 on isa0 wbwd0 failed to probe on isa0 isa_probe_children: probing PnP devices random: harvesting attach, 8 bytes (4 bits) from acpi_perf0 random: harvesting attach, 8 bytes (4 bits) from acpi_perf1 random: harvesting attach, 8 bytes (4 bits) from acpi_perf2 random: harvesting attach, 8 bytes (4 bits) from acpi_perf3 coretemp0: on cpu0 coretemp0: Setting TjMax=100 random: harvesting attach, 8 bytes (4 bits) from coretemp0 est0: on cpu0 random: harvesting attach, 8 bytes (4 bits) from cpufreq0 random: harvesting attach, 8 bytes (4 bits) from est0 coretemp1: on cpu1 coretemp1: Setting TjMax=100 random: harvesting attach, 8 bytes (4 bits) from coretemp1 est1: on cpu1 random: harvesting attach, 8 bytes (4 bits) from cpufreq1 random: harvesting attach, 8 bytes (4 bits) from est1 coretemp2: on cpu2 coretemp2: Setting TjMax=100 random: harvesting attach, 8 bytes (4 bits) from coretemp2 est2: on cpu2 random: harvesting attach, 8 bytes (4 bits) from cpufreq2 random: harvesting attach, 8 bytes (4 bits) from est2 coretemp3: on cpu3 coretemp3: Setting TjMax=100 random: harvesting attach, 8 bytes (4 bits) from coretemp3 est3: on cpu3 random: harvesting attach, 8 bytes (4 bits) from cpufreq3 random: harvesting attach, 8 bytes (4 bits) from est3 Device configuration finished. procfs registered ZFS filesystem version: 5 ZFS storage pool version: features support (5000) lapic: Divisor 2, Frequency 49885612 Hz Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining crypto: tcp_init: net.inet.tcp.tcbhashsize auto tuned to 65536 IPsec: Initialized Security Association Processing. lo0: bpf attached hptrr: no controller detected. hptnr: no controller detected. hpt27xx: no controller detected. hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 hdaa0: Subsystem ID: 0x80860101 hdaa0: NumGPIO=0 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=0 hdaa0: Original pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 3 18560010 1 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa0: Patched pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 3 18560010 1 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa0: 1 associations found: hdaa0: Association 0 (1) out: hdaa0: Pin nid=3 seq=0 hdaa0: Tracing association 0 (1) hdaa0: Pin 3 traced to DAC 2 hdaa0: Association 0 (1) trace succeeded hdaa0: Looking for additional DAC for association 0 (1) hdaa0: Tracing input monitor hdaa0: Tracing other input monitors hdaa0: Tracing beeper hdaa0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref pcm0: at nid 3 on hdaa0 pcm0: Playback: pcm0: Stream cap: 0x00000005 AC3 PCM pcm0: PCM cap: 0x001e07f0 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz pcm0: DAC: 2 pcm0: pcm0: nid=3 [pin: Digital-out (Jack)] pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: pcm0: Master Volume (OSS: vol): 0/0dB pcm0: +- ctl 1 (nid 3 in ): mute pcm0: pcm0: PCM Volume (OSS: pcm): 0/0dB pcm0: +- ctl 1 (nid 3 in ): mute pcm0: pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Soft PCM mixer ENABLED pcm0: Playback channel matrix is: unknown, assuming 7.1 (disconnected) random: harvesting attach, 8 bytes (4 bits) from pcm0 random: harvesting attach, 8 bytes (4 bits) from hdaa0 random: harvesting attach, 8 bytes (4 bits) from hdacc0 hdacc1: at cad 0 on hdac1 hdaa1: at nid 1 on hdacc1 hdaa1: Subsystem ID: 0x10280651 hdaa1: NumGPIO=3 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdaa1: GPIO0: disabled hdaa1: GPIO1: disabled hdaa1: GPIO2: disabled hdaa1: Original pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 18 90a60170 7 0 Mic Fixed Digital Internal Unknown 1 hdaa1: 20 90170140 4 0 Speaker Fixed Analog Internal Unknown 1 hdaa1: 23 40000000 0 0 Line-out None Unknown 0x00 Unknown 0 hdaa1: 24 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa1: 25 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa1: 26 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa1: 27 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa1: 29 40700001 0 1 Modem-handset None Unknown 0x00 Unknown 0 hdaa1: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa1: 33 02211050 5 0 Headphones Jack 1/8 Front Black 0 hdaa1: Patching widget caps nid=29 0x00400400 -> 0x00700400 hdaa1: Patched pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 18 90a60170 7 0 Mic Fixed Digital Internal Unknown 1 hdaa1: 20 90170140 4 0 Speaker Fixed Analog Internal Unknown 1 hdaa1: 23 40000000 0 0 Line-out None Unknown 0x00 Unknown 0 DISA hdaa1: 24 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa1: 25 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa1: 26 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa1: 27 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa1: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa1: 33 02211050 5 0 Headphones Jack 1/8 Front Black 0 hdaa1: 3 associations found: hdaa1: Association 0 (4) out: hdaa1: Pin nid=20 seq=0 hdaa1: Association 1 (5) out: hdaa1: Pin nid=33 seq=0 hdaa1: Association 2 (7) in: hdaa1: Pin nid=18 seq=0 hdaa1: Tracing association 0 (4) hdaa1: Pin 20 traced to DAC 2 hdaa1: Association 0 (4) trace succeeded hdaa1: Tracing association 1 (5) hdaa1: Pin 33 traced to DAC 3 hdaa1: Association 1 (5) trace succeeded hdaa1: Tracing association 2 (7) hdaa1: Pin 18 traced to ADC 8 hdaa1: Association 2 (7) trace succeeded hdaa1: Looking for additional DAC for association 0 (4) hdaa1: Looking for additional DAC for association 1 (5) hdaa1: Looking for additional ADC for association 2 (7) hdaa1: Tracing input monitor hdaa1: Tracing nid 35 to out hdaa1: Tracing other input monitors hdaa1: Tracing nid 18 to out hdaa1: Tracing beeper hdaa1: nid 29 traced to out hdaa1: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref pcm1: at nid 20 and 18 on hdaa1 pcm1: Playback: pcm1: Stream cap: 0x00000001 PCM pcm1: PCM cap: 0x000e0060 16 20 24 bits, 44 48 KHz pcm1: DAC: 2 pcm1: pcm1: nid=20 [pin: Speaker (Fixed)] pcm1: + <- nid=12 [audio mixer] [src: pcm, speaker] pcm1: + <- nid=2 [audio output] [src: pcm] pcm1: + <- nid=11 [audio mixer] [src: speaker] pcm1: + <- nid=29 [beep widget] [src: speaker] pcm1: pcm1: Record: pcm1: Stream cap: 0x00000001 PCM pcm1: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm1: ADC: 8 pcm1: pcm1: nid=8 [audio input] pcm1: + <- nid=35 [audio mixer] [src: speaker, monitor] pcm1: + <- nid=29 [beep widget] [src: speaker] pcm1: + <- nid=11 [audio mixer] [src: speaker] pcm1: + <- nid=29 [beep widget] [src: speaker] pcm1: + <- nid=18 [pin: Mic (Fixed)] [src: monitor] pcm1: pcm1: Master Volume (OSS: vol): -65/0dB pcm1: +- ctl 1 (nid 2 out): -65/0dB (88 steps) pcm1: +- ctl 10 (nid 12 in 0): mute pcm1: +- ctl 11 (nid 12 in 1): mute pcm1: +- ctl 16 (nid 20 in ): mute pcm1: pcm1: PCM Volume (OSS: pcm): -65/0dB pcm1: +- ctl 1 (nid 2 out): -65/0dB (88 steps) pcm1: +- ctl 10 (nid 12 in 0): mute pcm1: pcm1: Microphone2 Volume (OSS: monitor): 0/30dB pcm1: +- ctl 15 (nid 18 out): 0/30dB (4 steps) pcm1: +- ctl 36 (nid 35 in 6): mute pcm1: pcm1: Speaker/Beep Volume (OSS: speaker): -34/12dB pcm1: +- ctl 9 (nid 11 in 4): -34/12dB (32 steps) + mute pcm1: +- ctl 11 (nid 12 in 1): mute pcm1: +- ctl 34 (nid 35 in 4): mute pcm1: +- ctl 35 (nid 35 in 5): mute pcm1: pcm1: Recording Level (OSS: rec): -17/30dB pcm1: +- ctl 3 (nid 8 in 0): -17/30dB (64 steps) + mute pcm1: +- ctl 15 (nid 18 out): 0/30dB (4 steps) pcm1: +- ctl 34 (nid 35 in 4): mute pcm1: +- ctl 35 (nid 35 in 5): mute pcm1: +- ctl 36 (nid 35 in 6): mute pcm1: pcm1: Input Monitoring Level (OSS: igain): 0/0dB pcm1: +- ctl 11 (nid 12 in 1): mute pcm1: pcm1: Mixer "vol": pcm1: Mixer "pcm": pcm1: Mixer "speaker": pcm1: Mixer "rec": pcm1: Mixer "igain": pcm1: Mixer "ogain": pcm1: Mixer "monitor": pcm1: Playback channel set is: Front Left, Front Right, pcm1: Playback channel matrix is: 2.0 (unknown) pcm1: Automatically set rec source to: monitor pcm1: Recording channel set is: Front Left, Front Right, pcm1: Recording channel matrix is: 2.0 (unknown) random: harvesting attach, 8 bytes (4 bits) from pcm1 pcm2: at nid 33 on hdaa1 pcm2: Playback: pcm2: Stream cap: 0x00000001 PCM pcm2: PCM cap: 0x000e0060 16 20 24 bits, 44 48 KHz pcm2: DAC: 3 pcm2: pcm2: nid=33 [pin: Headphones (Black Jack)] pcm2: + <- nid=13 [audio mixer] [src: pcm, speaker] pcm2: + <- nid=3 [audio output] [src: pcm] pcm2: + <- nid=11 [audio mixer] [src: speaker] pcm2: + <- nid=29 [beep widget] [src: speaker] pcm2: pcm2: Master Volume (OSS: vol): -65/0dB pcm2: +- ctl 2 (nid 3 out): -65/0dB (88 steps) pcm2: +- ctl 12 (nid 13 in 0): mute pcm2: +- ctl 13 (nid 13 in 1): mute pcm2: +- ctl 23 (nid 33 in ): mute pcm2: pcm2: PCM Volume (OSS: pcm): -65/0dB pcm2: +- ctl 2 (nid 3 out): -65/0dB (88 steps) pcm2: +- ctl 12 (nid 13 in 0): mute pcm2: pcm2: Speaker/Beep Volume (OSS: speaker) pcm2: +- ctl 13 (nid 13 in 1): mute pcm2: pcm2: Input Monitoring Level (OSS: igain): 0/0dB pcm2: +- ctl 13 (nid 13 in 1): mute pcm2: pcm2: Mixer "vol": pcm2: Mixer "pcm": pcm2: Mixer "igain": pcm2: Mixer "ogain": pcm2: Playback channel set is: Front Left, Front Right, pcm2: Playback channel matrix is: 2.0 (disconnected) random: harvesting attach, 8 bytes (4 bits) from pcm2 random: harvesting attach, 8 bytes (4 bits) from hdaa1 random: harvesting attach, 8 bytes (4 bits) from hdacc1 usbus0: 480Mbps High Speed USB v2.0 ahcich0: AHCI reset... ugen0.1: at usbus0 uhub0: on usbus0 ahcich0: SATA connect time=100us status=00000133 ahcich0: AHCI reset: device found ahcich0: AHCI reset: device ready after 0ms ahcich1: AHCI reset... ahcich1: SATA connect time=1800us status=00000113 ahcich1: AHCI reset: device found ahcich1: AHCI reset: device ready after 0ms battery0: battery initialization start acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: ACS-2 ATA SATA 3.x device pass0: Serial Number WXC1E64E8Z3R battery0: battery initialization done, tried 1 times pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) pass0: Command Queueing enabled pass1 at ahcich1 bus 0 scbus1 target 0 lun 0 pass1: Removable CD-ROM SCSI device pass1: Serial Number H086 038887 pass1: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 GEOM: new disk cd0 cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: Serial Number H086 038887 cd0: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed GEOM: new disk ada0 ada0: ACS-2 ATA SATA 3.x device ada0: Serial Number WXC1E64E8Z3R ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors) lapic2: CMCI unmasked lapic3: CMCI unmasked SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x00000001 VER: 0x01060015 LDR: 0x00000002 DFR: 0x00000000 x2APIC: 1 lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000011ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000100f2 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x00000002 VER: 0x01060015 LDR: 0x00000004 DFR: 0x00000000 x2APIC: 1 lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000011ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x00000003 VER: 0x01060015 LDR: 0x00000008 DFR: 0x00000000 x2APIC: 1 lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000011ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 2 vector 48 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 2 vector 49 msi: Assigning MSI-X IRQ 257 to local APIC 1 vector 48 msi: Assigning MSI-X IRQ 258 to local APIC 2 vector 50 msi: Assigning MSI-X IRQ 259 to local APIC 3 vector 48 msi: Assigning MSI IRQ 264 to local APIC 2 vector 51 msi: Assigning MSI IRQ 266 to local APIC 2 vector 52 msi: Assigning MSI IRQ 268 to local APIC 2 vector 53 hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 IAP/4/48/0x3ff IAF/3/48/0x67 UCP/8/48/0x3f8 UCF/1/48/0x60 SMP: passed TSC synchronization test Timecounter "TSC" frequency 1895652288 Hz quality 1000 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from zfs:zroot/ROOT/default []... Root mount waiting for: usbus0 uhub0: 2 ports with 2 removable, self powered random: harvesting attach, 8 bytes (4 bits) from uhub0 ugen0.2: at usbus0 uhub1: on usbus0 Root mount waiting for: usbus0 uhub1: 8 ports with 8 removable, self powered random: harvesting attach, 8 bytes (4 bits) from uhub1 Root mount waiting for: usbus0 ugen0.3: at usbus0 ugen0.4: at usbus0 Root mount waiting for: usbus0 ugen0.5: at usbus0 start_init: trying /sbin/init wlan0: bpf attached wlan0: bpf attached wlan0: Ethernet address: 0c:d2:92:96:98:a3 iwn0: iwn_read_firmware: ucode rev=0x12a80601 iwn0: iwn_read_firmware: ucode rev=0x12a80601 wlan0: link state changed to UP re0: link state changed to DOWN ubt0: on usbus0 random: harvesting attach, 8 bytes (4 bits) from ubt0 WARNING: attempt to domain_add(bluetooth) after domainfinalize() WARNING: attempt to domain_add(netgraph) after domainfinalize() --PEIAKu/WMn1b1Hv9-- From owner-freebsd-current@freebsd.org Sun Feb 28 19:23:05 2016 Return-Path: Delivered-To: freebsd-current@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 03D13AB76C9 for ; Sun, 28 Feb 2016 19:23:05 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id EE3011D7B; Sun, 28 Feb 2016 19:23:04 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) Received: from [192.168.42.104] (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 93E571655; Sun, 28 Feb 2016 19:23:04 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) From: "Jonathan Anderson" To: "Larry Rosenman" Cc: freebsd-current@freebsd.org Subject: Re: Mouse on Inspiron ? Date: Sun, 28 Feb 2016 15:53:05 -0330 Message-ID: <0598ACAD-4BE4-4CC5-88CE-D62BC781541C@FreeBSD.org> In-Reply-To: <20160228174518.GA1167@lrosenman-dell2.lerctr.org> References: <20160228165632.GA1265@lrosenman-dell2.lerctr.org> <20160228174518.GA1167@lrosenman-dell2.lerctr.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 19:23:05 -0000 On 28 Feb 2016, at 14:15, Larry Rosenman wrote: > Ok, a verbose boot tells me /dev/psm0 can't allocate an IRQ. > > Ideas? > > Verbose boot attached Hi Larry, I believe that someone encountered (and fixed!) a similar problem last year: https://lists.freebsd.org/pipermail/freebsd-stable/2015-February/081757.html It seems that this is becoming an issue on new notebooks: I know that my new ASUS notebook has the same problem (but, unfortunately, Mauro's fix doesn't apply to my machine). Jon -- Jonathan Anderson jonathan@FreeBSD.org From owner-freebsd-current@freebsd.org Sun Feb 28 21:51:58 2016 Return-Path: Delivered-To: freebsd-current@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 1F787AB63E3 for ; Sun, 28 Feb 2016 21:51:58 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0303C1D4B for ; Sun, 28 Feb 2016 21:51:58 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date; bh=s/tgg2Ec+i1iZvXFy7frFUP9C+WVzGbVqk+ark/5tHc=; b=L enbytqQrhHACuD10gMttz8dzy4rldsk6tZqKI6ZBrM45NyYWS80Hr+ftTpUJK0rKq41H1xfXj7ayx McWpAeR0sWdAwnTLWqqXtS2N+gXZl6NCzXAlf0mDpj9Qk/YOTGgLI/iJD0KWa7PuNnqQcm9O3qZpH OeTAQAJc5HNZcv84=; Received: from [2605:6000:ec17:203:ed2:92ff:fe96:98a3] (port=38789 helo=lrosenman-dell2.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aa9Fs-000K1Z-V2; Sun, 28 Feb 2016 15:51:57 -0600 Date: Sun, 28 Feb 2016 15:51:47 -0600 From: Larry Rosenman To: freebsd-current@freebsd.org Cc: medda.mauro@gmail.com Subject: Re: Mouse on Inspiron ? Message-ID: <20160228215147.GA1220@lrosenman-dell2.lerctr.org> Mail-Followup-To: freebsd-current@freebsd.org, medda.mauro@gmail.com References: <20160228165632.GA1265@lrosenman-dell2.lerctr.org> <20160228174518.GA1167@lrosenman-dell2.lerctr.org> <0598ACAD-4BE4-4CC5-88CE-D62BC781541C@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0598ACAD-4BE4-4CC5-88CE-D62BC781541C@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Score: -1.0 (-) X-LERCTR-Spam-Score: -1.0 (-) X-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 X-LERCTR-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 21:51:58 -0000 On Sun, Feb 28, 2016 at 03:53:05PM -0330, Jonathan Anderson wrote: > On 28 Feb 2016, at 14:15, Larry Rosenman wrote: > > > Ok, a verbose boot tells me /dev/psm0 can't allocate an IRQ. > > > > Ideas? > > > > Verbose boot attached > > Hi Larry, > > I believe that someone encountered (and fixed!) a similar problem last > year: > https://lists.freebsd.org/pipermail/freebsd-stable/2015-February/081757.html Yep, that's the SAME laptop. Mauro, can I get a copy of the DSDT or instructions? > > It seems that this is becoming an issue on new notebooks: I know that my > new ASUS notebook has the same problem (but, unfortunately, Mauro's fix > doesn't apply to my machine). > > > Jon > -- > Jonathan Anderson > jonathan@FreeBSD.org -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 From owner-freebsd-current@freebsd.org Sun Feb 28 22:17:03 2016 Return-Path: Delivered-To: freebsd-current@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 5E191AB70B4 for ; Sun, 28 Feb 2016 22:17:03 +0000 (UTC) (envelope-from jilles@stack.nl) 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 4E04F1EC5 for ; Sun, 28 Feb 2016 22:17:03 +0000 (UTC) (envelope-from jilles@stack.nl) Received: by mailman.ysv.freebsd.org (Postfix) id 4980BAB70B2; Sun, 28 Feb 2016 22:17:03 +0000 (UTC) Delivered-To: current@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 490DCAB70B1 for ; Sun, 28 Feb 2016 22:17:03 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D97601EC4; Sun, 28 Feb 2016 22:17:02 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from toad2.stack.nl (toad2.stack.nl [IPv6:2001:610:1108:5010::161]) by mx1.stack.nl (Postfix) with ESMTP id A32633592E6; Sun, 28 Feb 2016 23:16:59 +0100 (CET) Received: by toad2.stack.nl (Postfix, from userid 1677) id 71353892A3; Sun, 28 Feb 2016 23:16:59 +0100 (CET) Date: Sun, 28 Feb 2016 23:16:59 +0100 From: Jilles Tjoelker To: Dimitry Andric Cc: Howard Su , current@freebsd.org Subject: Re: buffer overflow warning in /bin/sh Message-ID: <20160228221659.GA30583@stack.nl> References: <0353BD46-1397-4DAC-9115-6D2355E7F42D@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0353BD46-1397-4DAC-9115-6D2355E7F42D@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 22:17:03 -0000 On Fri, Feb 26, 2016 at 06:21:20PM +0100, Dimitry Andric wrote: > On 26 Feb 2016, at 04:21, Howard Su wrote: > > I got the error when compiling GENERIC kernel with address sanitizer > > /bin/sh: > > --- vers.c --- > > MAKE=make sh /usr/home/howardsu/freebsd/sys/conf/newvers.sh > > GENERIC================================================================= > > ==4132==ERROR: AddressSanitizer: stack-buffer-overflow on address > > 0x7fffffffc9c0 at pc 0x00000045fdc7 bp 0x7fffffffc930 sp 0x7fffffffc0f0 > > WRITE of size 312 at 0x7fffffffc9c0 thread T0 > > #0 0x45fdc6 (/bin/sh+0x45fdc6) > > #1 0x801431767 (/lib/libc.so.7+0x7c767) > > #2 0x42ff5e (/bin/sh+0x42ff5e) > > #3 0x4b6b00 (/bin/sh+0x4b6b00) > > #4 0x49686e (/bin/sh+0x49686e) > > #5 0x495572 (/bin/sh+0x495572) > > #6 0x48c3f9 (/bin/sh+0x48c3f9) > > #7 0x489920 (/bin/sh+0x489920) > > #8 0x4acde8 (/bin/sh+0x4acde8) > > #9 0x4aca4d (/bin/sh+0x4aca4d) > > #10 0x40fb0e (/bin/sh+0x40fb0e) > > #11 0x80071afff () > > Address 0x7fffffffc9c0 is located in stack of thread > > T0==4132==AddressSanitizer CHECK failed: > > /usr/home/howardsu/freebsd/lib/libclang_rt/asan/../../../contrib/compiler-rt/lib/asan/asan_thread.cc:246 > > "((ptr[0] == kCurrentStackFrameMagic)) != (0)" (0x0, 0x0) > > #0 0x422b9d (/bin/sh+0x422b9d) > > #1 0x41de09 (/bin/sh+0x41de09) > > #2 0x41f301 (/bin/sh+0x41f301) > > #3 0x4728be (/bin/sh+0x4728be) > > #4 0x474589 (/bin/sh+0x474589) > > #5 0x47502a (/bin/sh+0x47502a) > > #6 0x45fdef (/bin/sh+0x45fdef) > > #7 0x801431767 (/lib/libc.so.7+0x7c767) > > #8 0x42ff5e (/bin/sh+0x42ff5e) > > #9 0x4b6b00 (/bin/sh+0x4b6b00) > > #10 0x49686e (/bin/sh+0x49686e) > > #11 0x495572 (/bin/sh+0x495572) > > #12 0x48c3f9 (/bin/sh+0x48c3f9) > > #13 0x489920 (/bin/sh+0x489920) > > #14 0x4acde8 (/bin/sh+0x4acde8) > > #15 0x4aca4d (/bin/sh+0x4aca4d) > > #16 0x40fb0e (/bin/sh+0x40fb0e) > > #17 0x80071afff () > > *** [vers.c] Error code 1 > > I am using latest -Current and add the following flags to /etc/make.conf. > > # CFLAGS+= -g -fsanitize=address -fno-omit-frame-pointer > > I rebuild /bin/sh as a first step. with the /bin/sh I got the above error. > > I would like to understand how to get symbols. The following command > > doesn't work at all. > > addr2line -e /bin/sh 0x422b9d > > Any idea? > Please recompile and reinstall world, using WITH_CLANG_EXTRAS=y in > /etc/src.conf. This will install the /usr/bin/llvm-symbolizer command, > which is needed by AddressSanitizer to resolve symbols. I tried this a while ago and asan reported an error when libc cleared a piece of stack memory (va_list, fully in bounds) using asan-interposed memset(). Note that glibc never calls memset() internally in such a way that it can be interposed. > On my system with the projects/clang380-import branch installed, I get > the following AdressSanitizer report. It does not look completely > similar to your case, though: > $ sh sys/conf/newvers.sh > ================================================================= > ==9912==ERROR: AddressSanitizer: stack-buffer-overflow on address 0xbfbfe380 at pc 0x08121f12 bp 0xbfbfe354 sp 0xbfbfe34c > WRITE of size 4 at 0xbfbfe380 thread T0 > #0 0x8121f11 in readtoken1 /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:1419:22 > #1 0x812597d in xxreadtoken /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:930:11 > #2 0x811c90f in readtoken /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:827:6 > #3 0x812341c in simplecmd /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:647:7 > #4 0x812341c in command /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:592 > #5 0x8122e19 in pipeline /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:376:7 > #6 0x811cc57 in andor /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:347:6 > #7 0x811cc57 in list /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:278 > #8 0x8126501 in parsebackq /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:1182:6 > #9 0x811f36c in readtoken1 /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:1556:11 > #10 0x812597d in xxreadtoken /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:930:11 > #11 0x811c90f in readtoken /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:827:6 > #12 0x811c7c9 in parsecmd /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:224:6 > #13 0x811046f in cmdloop /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/main.c:217:7 > #14 0x811015e in main /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/main.c:178:3 > #15 0x80557c9 in _start1 (/bin/sh+0x80557c9) > Address 0xbfbfe380 is located in stack of thread T0 at offset 32 in frame > #0 0x811e8ff in readtoken1 /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:1400 > This frame has 3 object(s): > [16, 20) 'bqlist' > [32, 128) 'state_static' <== Memory access at offset 32 is inside this variable > [160, 170) 'buf' > HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext > (longjmp and C++ exceptions *are* supported) > SUMMARY: AddressSanitizer: stack-buffer-overflow /share/dim/src/freebsd/base/projects/clang380-import/bin/sh/parser.c:1419:22 in readtoken1 > Shadow bytes around the buggy address: > 0x57f7fc20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x57f7fc30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x57f7fc40: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 00 00 > 0x57f7fc50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x57f7fc60: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 04 f2 > =>0x57f7fc70:[f3]f3 f3 f3 f3 f3 00 00 00 00 00 00 f2 f2 f2 f2 > 0x57f7fc80: 00 02 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 > 0x57f7fc90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x57f7fca0: 00 00 00 00 00 00 00 00 f1 f1 04 f2 04 f2 04 f2 > 0x57f7fcb0: 04 f2 04 f3 00 00 00 00 00 00 00 00 00 00 00 00 > 0x57f7fcc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Partially addressable: 01 02 03 04 05 06 07 > Heap left redzone: fa > Heap right redzone: fb > Freed heap region: fd > Stack left redzone: f1 > Stack mid redzone: f2 > Stack right redzone: f3 > Stack partial redzone: f4 > Stack after return: f5 > Stack use after scope: f8 > Global redzone: f9 > Global init order: f6 > Poisoned by user: f7 > Container overflow: fc > Array cookie: ac > Intra object redzone: bb > ASan internal: fe > Left alloca redzone: ca > Right alloca redzone: cb > ==9912==ABORTING > This may be a false positive though. The reported store, which is near the top of the function, is clearly within bounds. -- Jilles Tjoelker From owner-freebsd-current@freebsd.org Sun Feb 28 23:25:10 2016 Return-Path: Delivered-To: freebsd-current@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 C626BAB8A49 for ; Sun, 28 Feb 2016 23:25:10 +0000 (UTC) (envelope-from dim@FreeBSD.org) 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 B14EB1C5 for ; Sun, 28 Feb 2016 23:25:10 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id AF6AAAB8A48; Sun, 28 Feb 2016 23:25:10 +0000 (UTC) Delivered-To: current@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 AF036AB8A47 for ; Sun, 28 Feb 2016 23:25:10 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 76A2C1C4 for ; Sun, 28 Feb 2016 23:25:10 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::e854:b466:3255:c8fc] (unknown [IPv6:2001:7b8:3a7:0:e854:b466:3255:c8fc]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 46C3B14E47; Mon, 29 Feb 2016 00:25:07 +0100 (CET) Subject: Re: buffer overflow warning in /bin/sh Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_ED6EEB56-3E4C-400D-B1B9-28AAA243F883"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <20160228221659.GA30583@stack.nl> Date: Mon, 29 Feb 2016 00:24:44 +0100 Cc: Howard Su , current@freebsd.org Message-Id: <6FC0C3D8-EF6E-4648-903A-92CB1B49DB1F@FreeBSD.org> References: <0353BD46-1397-4DAC-9115-6D2355E7F42D@FreeBSD.org> <20160228221659.GA30583@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 23:25:10 -0000 --Apple-Mail=_ED6EEB56-3E4C-400D-B1B9-28AAA243F883 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 28 Feb 2016, at 23:16, Jilles Tjoelker wrote: >=20 > On Fri, Feb 26, 2016 at 06:21:20PM +0100, Dimitry Andric wrote: ... >> This frame has 3 object(s): >> [16, 20) 'bqlist' >> [32, 128) 'state_static' <=3D=3D Memory access at offset 32 is = inside this variable >> [160, 170) 'buf' ... >> This may be a false positive though. >=20 > The reported store, which is near the top of the function, is clearly > within bounds. Yes, it's definitely a false positive. I'm still attempting to find out where this goes awry, but it isn't in sh, at least. (After some help from Bryan Drewery I managed to run it through valgrind-devel, and that does not complain about anything...) -Dimitry --Apple-Mail=_ED6EEB56-3E4C-400D-B1B9-28AAA243F883 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.29 iEUEARECAAYFAlbTgdIACgkQsF6jCi4glqPSIwCXTELmES3jxOJ9FQ91HY9JI88q 1wCg3fYygZAH7AKFd4E5KG7QgrqQJLU= =CHmz -----END PGP SIGNATURE----- --Apple-Mail=_ED6EEB56-3E4C-400D-B1B9-28AAA243F883-- From owner-freebsd-current@freebsd.org Mon Feb 29 13:27:19 2016 Return-Path: Delivered-To: freebsd-current@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 BE12EAB8881 for ; Mon, 29 Feb 2016 13:27:19 +0000 (UTC) (envelope-from zoleg73@bk.ru) Received: from fallback2.mail.ru (fallback2.mail.ru [94.100.179.22]) by mx1.freebsd.org (Postfix) with ESMTP id 6A79D850 for ; Mon, 29 Feb 2016 13:27:18 +0000 (UTC) (envelope-from zoleg73@bk.ru) Received: from f423.i.mail.ru (f423.i.mail.ru [185.5.136.94]) by fallback2.mail.ru (mPOP.Fallback_MX) with ESMTP id EA1AD6C86289 for ; Mon, 29 Feb 2016 14:02:49 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bk.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:To:From; bh=G2Hr7w2EbATd64AYHJoIMopHTVUr+vzbJabDlP2X1WQ=; b=snhrPpaDFa5wUvUAgy2+MRPS3DcPazReqalVJwqHtYSO1Hzdfc8DWq8aDR7mASQodiNG6VX4VweiTZVGvETj5+Ix87cHOGUhWs+PzZLd2xkV4kfbJ8ONDrPhJYdKqhHccatXs5J+dB5fTr+irjR9eFAGJHf7JusmOqHsiZHvCXI=; Received: from [90.188.37.149] (ident=mail) by f423.i.mail.ru with local (envelope-from ) id 1aaLZb-0007to-Ml for freebsd-current@freebsd.org; Mon, 29 Feb 2016 14:01:07 +0300 Received: from [90.188.37.149] by e.mail.ru with HTTP; Mon, 29 Feb 2016 14:01:07 +0300 From: =?UTF-8?B?0J7Qu9C10LMg0JbQsNGA0LrQvtC5?= To: freebsd-current@freebsd.org Subject: =?UTF-8?B?TlRGUyBkaXNrcyBtb3VudGluZyB0cm91Ymxl?= MIME-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 X-Originating-IP: [90.188.37.149] Date: Mon, 29 Feb 2016 14:01:07 +0300 Reply-To: =?UTF-8?B?0J7Qu9C10LMg0JbQsNGA0LrQvtC5?= X-Priority: 3 (Normal) Message-ID: <1456743667.143653098@f423.i.mail.ru> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Mras: Ok X-Spam: undefined X-Mailman-Approved-At: Mon, 29 Feb 2016 14:16:52 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 13:27:19 -0000 SGkgcGVvcGxlcyEKSSBpbnN0YWxsIEZyZWVCU0QtQ3VycmVudCBhbmQgIHN5c3V0aWxzL2Z1c2Vm cy1udGZzICwgYnV0IHdoZW4gSSB0cnkgbW91bnQgYW55IE5URlMgcGFydGl0aW9uIEkgcmVjZWl2 ZSBlcnJvciBtZXNzYWdlOgpbcm9vdEB6YnNkIC9kZXZdIyBudGZzLTNnIC9kZXYvYWRhMHMyICAv bW50CkVycm9yIHJlYWRpbmcgYm9vdHNlY3RvcjogSW52YWxpZCBhcmd1bWVudApGYWlsZWQgdG8g bW91bnQgJy9kZXYvYWRhMHMyJzogSW52YWxpZCBhcmd1bWVudApUaGUgZGV2aWNlICcvZGV2L2Fk YTBzMicgZG9lc24ndCBzZWVtIHRvIGhhdmUgYSB2YWxpZCBOVEZTLgpNYXliZSB0aGUgd3Jvbmcg ZGV2aWNlIGlzIHVzZWQ/IE9yIHRoZSB3aG9sZSBkaXNrIGluc3RlYWQgb2YgYQpwYXJ0aXRpb24g KGUuZy4gL2Rldi9zZGEsIG5vdCAvZGV2L3NkYTEpPyBPciB0aGUgb3RoZXIgd2F5IGFyb3VuZD8K Cltyb290QHpic2QgL2Rldl0jIGZpbGUgLXMgL2Rldi9hZGEwczIKL2Rldi9hZGEwczI6IERPUy9N QlIgYm9vdCBzZWN0b3IsIGNvZGUgb2Zmc2V0IDB4NTIrMiwgT0VNLUlEICJOVEZTICAiLCBzZWN0 b3JzL2NsdXN0ZXIgOCwgTWVkaWEgZGVzY3JpcHRvciAweGY4LCBzZWN0b3JzL3RyYWNrIDYzLCBo ZWFkcyAyNTUsIGhpZGRlbiBzZWN0b3JzIDI5MjkzNTI3MDQsIGRvcyA8IDQuMCBCb290U2VjdG9y ICgweDgwKSwgRkFUICgxWSBiaXQgYnkgZGVzY3JpcHRvcik7IE5URlMsIHNlY3RvcnMvdHJhY2sg NjMsIHNlY3RvcnMgOTIxNTk5LCAkTUZUIHN0YXJ0IGNsdXN0ZXIgMzg0MDAsICRNRlRNaXJyb3Ig c3RhcnQgY2x1c3RlciAyLCBieXRlcy9SZWNvcmRTZWdtZW50IDJeKC0xKjI0NiksIGNsdXN0ZXJz L2luZGV4IGJsb2NrIDEsIHNlcmlhbCBudW1iZXIgMGEwYjY0ZWVmYjY0ZWM2MGUKCltyb290QHpi c2QgL2Rldl0jIHVuYW1lIC1hCkZyZWVCU0QgemJzZCAxMS4wLUNVUlJFTlQgRnJlZUJTRCAxMS4w LUNVUlJFTlQgIzAgcjI5NjA3ODogRnJpIEZlYiAyNiAxODo1NTo0NiBJUktUIDIwMTYgIHJvb3RA emJzZDovdXNyL29iai91c3Ivc3JjL3N5cy96YnNkICBhbWQ2NApbcm9vdEB6YnNkIC9kZXZdIyBr bGRzdGF0CklkIFJlZnMgQWRkcmVzcyAgU2l6ZSAgTmFtZQrCoDEgIDM5IDB4ZmZmZmZmZmY4MDIw MDAwMCBmNTBhYTAgIGtlcm5lbArCoDIgIDEgMHhmZmZmZmZmZjgxMTUyMDAwIDJkMTY3MCAgemZz LmtvCsKgMyAgMiAweGZmZmZmZmZmODE0MjQwMDAgYTM5OCAgb3BlbnNvbGFyaXMua28KwqA0ICAx IDB4ZmZmZmZmZmY4MTQyZjAwMCBiNjdhYjAgIG52aWRpYS5rbwrCoDUgIDIgMHhmZmZmZmZmZjgx Zjk3MDAwIDQ1MGMwICBsaW51eC5rbwrCoDYgIDIgMHhmZmZmZmZmZjgxZmRkMDAwIDdlZTggIGxp bnV4X2NvbW1vbi5rbwrCoDcgIDEgMHhmZmZmZmZmZjgxZmU1MDAwIDE0ZGQwICBmdXNlLmtvCsKg OCAgMSAweGZmZmZmZmZmODIyMTEwMDAgMjNjNyAgdW1zLmtvCsKgOSAgMSAweGZmZmZmZmZmODIy MTQwMDAgMTg5MCAgdWhpZC5rbwoxMCAgMSAweGZmZmZmZmZmODIyMTYwMDAgMTU2NCAgZmRlc2Nm cy5rbwoxMSAgMSAweGZmZmZmZmZmODIyMTgwMDAgMjNhICBtc2Rvc2ZzX2ljb252LmtvCjEyICAx IDB4ZmZmZmZmZmY4MjIxOTAwMCAzMjJmICBsaWJpY29udi5rbwoKV2hhdCB3cm9uZz8K From owner-freebsd-current@freebsd.org Mon Feb 29 14:20:31 2016 Return-Path: Delivered-To: freebsd-current@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 35DF5AB8D89 for ; Mon, 29 Feb 2016 14:20:31 +0000 (UTC) (envelope-from miguelmclara@gmail.com) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B1D0CCF for ; Mon, 29 Feb 2016 14:20:30 +0000 (UTC) (envelope-from miguelmclara@gmail.com) Received: by mail-lb0-x235.google.com with SMTP id of3so80564579lbc.1 for ; Mon, 29 Feb 2016 06:20:30 -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=8HJa/XmyxBiGzztojfZtDyvp0zSNNVxvVQj7uh5H4ks=; b=mW1f1lHvmbgf3TaiVEs7GTrcKGKl/N9jUDbp0Lx0Z/3Z21SZBEHjrONAyXLJ+Tn33I BQ8emMOZtROvfJH+PGNQkfm39No2abn+zS5+0kKDh1W/AR8TCBnl05BUOG9zxnoTNpH1 xgJxlrLS7rw8d8QwmjeE69DN0W75L62WLgHX9DC7EiPbaOR2HqPSSZPwJeyOym6zEID5 OBRCc/a1ssLNzlby85Wa2kw3dW8WpBudTkM6gIBvYPrMVj+L+CpbEdQB06FtNQjXZ0tn xXOxYIDZbwMNZ8lE1SSJrG7SfgKDfQRz0OGdl9tcw1gcsEgaKZ2HVTyLNljhszKLhw1c nAkw== 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=8HJa/XmyxBiGzztojfZtDyvp0zSNNVxvVQj7uh5H4ks=; b=A2qh253OWblQiSAnIUzRG3DoUEy8N/Gocwea6IB2ySg62qKopMK+E4fGetcLTjGBAa E7elmrpMk93SLLA/79NLVSdsfCEjL2YNy/6Gzgu2XLKv88MiRSuRsxYhuerO1uB9GsB6 NF4a1iq1IBfJL4og+NtRHpsrsgJfQerq+xvGL5mij9+uq0tueSEesT+SU4Xytb/RFf13 IFQXxg7HtCRNozMIhAKtk1yAa2q/y2a1Xw+XRIM51l6opDBRAs7nDUfv9JL1Vg3h0GKC vwBrOYhV/aseM3rgmkgvLcO+R4PiV8HeYidi+h4NyoQiT6Mg3KDk8nstPKj22d7+/r30 x3kg== X-Gm-Message-State: AD7BkJKm2boDW/U5nw4aiV9FRBFCPsxTegLo1ZcVbhTjQ9gLsL3LRAkGFDlX/eBBhWj6Xb3DPPwQPB4wkqsXfw== X-Received: by 10.112.146.35 with SMTP id sz3mr5735249lbb.10.1456755626802; Mon, 29 Feb 2016 06:20:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.15.156 with HTTP; Mon, 29 Feb 2016 06:19:47 -0800 (PST) From: Miguel C Date: Mon, 29 Feb 2016 14:19:47 +0000 Message-ID: Subject: ssh-add -l/L The agent has no identities. To: freebsd-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 14:20:31 -0000 After running ssh-add I get Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa) I excepted to see the key listed when runnign ssh-add -l but what I see is: `The agent has no identities.` This is happening with both ssh-agent and using gpg-agent with ssh support so I'm not sure if the problem is with the agent(s) or ssh-add it self. The permissions of the id_rsa file are ok and in fact nothing was changed in ~/.ssh. Also this used to work just fine and gnome-keyring seems happy, I also noticed that its not using pinentry when I use "ssh host" (when I'm starting gpg-agent from xinit when using other DEs - lumina for example) So I'm not sure if the issue is ssh-add it self, or the agent, the env vars are there, particulary: SSH_AUTH_SOCK=/home/miguelc/.gnupg/S.gpg-agent.ssh And GPG_TTY as the man page says. Using: FreeBSD r2d2 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r294634 Melhores Cumprimentos // Best Regards ----------------------------------------------- *Miguel Clara* *IT - Sys Admin & Developer* From owner-freebsd-current@freebsd.org Mon Feb 29 15:55:37 2016 Return-Path: Delivered-To: freebsd-current@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 A3345AB8019 for ; Mon, 29 Feb 2016 15:55:37 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 85012107D for ; Mon, 29 Feb 2016 15:55:36 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id u1TFvXUk040218 for ; Mon, 29 Feb 2016 07:57:39 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <1456743667.143653098@f423.i.mail.ru> References: <1456743667.143653098@f423.i.mail.ru> From: "Chris H" Subject: Re: NTFS disks mounting trouble Date: Mon, 29 Feb 2016 07:57:39 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <076d9dab6c4b5c1ae2ad80804958c753@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 15:55:37 -0000 On Mon, 29 Feb 2016 14:01:07 +0300 Олег Жаркой wrote > Hi peoples! > I install FreeBSD-Current and sysutils/fusefs-ntfs , but when I try mount > any NTFS partition I receive error message: [root@zbsd /dev]# ntfs-3g > /dev/ada0s2 /mnt Error reading bootsector: Invalid argument > Failed to mount '/dev/ada0s2': Invalid argument > The device '/dev/ada0s2' doesn't seem to have a valid NTFS. > Maybe the wrong device is used? Or the whole disk instead of a > partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around? > > [root@zbsd /dev]# file -s /dev/ada0s2 > /dev/ada0s2: DOS/MBR boot sector, code offset 0x52+2, OEM-ID "NTFS ", > sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, hidden > sectors 2929352704, dos < 4.0 BootSector (0x80), FAT (1Y bit by descriptor); > NTFS, sectors/track 63, sectors 921599, $MFT start cluster 38400, $MFTMirror > start cluster 2, bytes/RecordSegment 2^(-1*246), clusters/index block 1, > serial number 0a0b64eefb64ec60e > > [root@zbsd /dev]# uname -a > FreeBSD zbsd 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r296078: Fri Feb 26 > 18:55:46 IRKT 2016 root@zbsd:/usr/obj/usr/src/sys/zbsd amd64 [root@zbsd > /dev]# kldstat Id Refs Address Size Name >  1 39 0xffffffff80200000 f50aa0 kernel >  2 1 0xffffffff81152000 2d1670 zfs.ko >  3 2 0xffffffff81424000 a398 opensolaris.ko >  4 1 0xffffffff8142f000 b67ab0 nvidia.ko >  5 2 0xffffffff81f97000 450c0 linux.ko >  6 2 0xffffffff81fdd000 7ee8 linux_common.ko >  7 1 0xffffffff81fe5000 14dd0 fuse.ko >  8 1 0xffffffff82211000 23c7 ums.ko >  9 1 0xffffffff82214000 1890 uhid.ko > 10 1 0xffffffff82216000 1564 fdescfs.ko > 11 1 0xffffffff82218000 23a msdosfs_iconv.ko > 12 1 0xffffffff82219000 322f libiconv.ko > > What wrong? Dunno. Maybe a bad boot sector? Is it possible to mount it via: mount -t MSDOS /dev/ada0s2 /mnt ? Just a hunch. --Chris From owner-freebsd-current@freebsd.org Mon Feb 29 16:36:06 2016 Return-Path: Delivered-To: freebsd-current@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 09FF1AB8D74 for ; Mon, 29 Feb 2016 16:36:06 +0000 (UTC) (envelope-from roberfern@gmail.com) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 BE21D6E9 for ; Mon, 29 Feb 2016 16:36:05 +0000 (UTC) (envelope-from roberfern@gmail.com) Received: by mail-yw0-x22f.google.com with SMTP id g127so125627542ywf.2 for ; Mon, 29 Feb 2016 08:36:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Y9Btj92TVXZ4lzxEeFobYPiGbTNlwj8Hxo5z/+klZIc=; b=Wk1v698d+t2jV5W9Y/jON0yLl2IZbtwu6xTPoqqC86Wqo8xmmpofIqV7irf4N89O4d eqRmhdC85ptZsmDNOG3dzZ2TgdfcB1m0o4vX0K5dIO1K8n5wk77S+bW6flFRkpmpbM6y Foa3Cn1HTDhaa6hNSuTpLEEthErjO3B14egW+3n0h5kcg9FUNqfnTv/RAPekHKcF6SIg QS+c9O4Vfu0h27ECqtYZWqW9oJBOtUag81FSpWILD8z/iPx0I93B/6IkVD2qviYuUluW +SlCA5MTDAAmYuvKnBD2boxVQI/NSgR4jzkHuFSOLus9KDNgqmZGR0HlrX45lfOv9nSY 8DHg== 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:date :message-id:subject:from:to:cc; bh=Y9Btj92TVXZ4lzxEeFobYPiGbTNlwj8Hxo5z/+klZIc=; b=L5AX2SEQLxor1vqIoJi22xRQ5FMKbL9ZXJP/r/46Z8GdsBQWxgJJv1DGfkLN+8Hf8j LBX9wqqm5KlAvvYxI29pITcpmCbIAltPVbN4FRz1lZqowh/cKW5r0/cAjQQWRNA9w/zR PtZ5Opn30JSsS2eTebfsFOCVFLfjLoNSaoqh4B5GZJuuUklEczGFyUhEnNmy48TasY7E pEruJdUuKscFjJPi7UjE3iSC1Knif7GyC4Bmq92MO3FgnRmk/gecRabo97UVMxjY8GGX SDigQwW65Mze1gu8zN1/Um7kfCdJtoBpViY3pOlXBubI3oZjYslGhxan34WuMQt4jj8q mGcg== X-Gm-Message-State: AD7BkJJ5muvZluAIgR90IEAjsP/Nfs2qknFc5UrG2NaBdL4/WYY7Yhpp5ZuqBXhhR0XQlS4qLJWmmZAxKQHnAA== MIME-Version: 1.0 X-Received: by 10.129.101.195 with SMTP id z186mr9983790ywb.1.1456763764959; Mon, 29 Feb 2016 08:36:04 -0800 (PST) Received: by 10.37.42.10 with HTTP; Mon, 29 Feb 2016 08:36:04 -0800 (PST) In-Reply-To: <076d9dab6c4b5c1ae2ad80804958c753@ultimatedns.net> References: <1456743667.143653098@f423.i.mail.ru> <076d9dab6c4b5c1ae2ad80804958c753@ultimatedns.net> Date: Mon, 29 Feb 2016 17:36:04 +0100 Message-ID: Subject: Re: NTFS disks mounting trouble From: =?UTF-8?Q?Roberto_Fern=C3=A1ndez?= To: Chris H Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 16:36:06 -0000 That problem seems familiar to me. Are you sure that the partition is not locked by a Windows OS? Sometimes Windows locks the disk on shutdown. Best Regards, Roberto Fernandez Cueto 2016-02-29 16:57 GMT+01:00 Chris H : > On Mon, 29 Feb 2016 14:01:07 +0300 =D0=9E=D0=BB=D0=B5=D0=B3 =D0=96=D0=B0= =D1=80=D0=BA=D0=BE=D0=B9 wrote > > > Hi peoples! > > I install FreeBSD-Current and sysutils/fusefs-ntfs , but when I try > mount > > any NTFS partition I receive error message: [root@zbsd /dev]# ntfs-3g > > /dev/ada0s2 /mnt Error reading bootsector: Invalid argument > > Failed to mount '/dev/ada0s2': Invalid argument > > The device '/dev/ada0s2' doesn't seem to have a valid NTFS. > > Maybe the wrong device is used? Or the whole disk instead of a > > partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around? > > > > [root@zbsd /dev]# file -s /dev/ada0s2 > > /dev/ada0s2: DOS/MBR boot sector, code offset 0x52+2, OEM-ID "NTFS ", > > sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, > hidden > > sectors 2929352704, dos < 4.0 BootSector (0x80), FAT (1Y bit by > descriptor); > > NTFS, sectors/track 63, sectors 921599, $MFT start cluster 38400, > $MFTMirror > > start cluster 2, bytes/RecordSegment 2^(-1*246), clusters/index block 1= , > > serial number 0a0b64eefb64ec60e > > > > [root@zbsd /dev]# uname -a > > FreeBSD zbsd 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r296078: Fri Feb 26 > > 18:55:46 IRKT 2016 root@zbsd:/usr/obj/usr/src/sys/zbsd amd64 > [root@zbsd > > /dev]# kldstat Id Refs Address Size Name > > 1 39 0xffffffff80200000 f50aa0 kernel > > 2 1 0xffffffff81152000 2d1670 zfs.ko > > 3 2 0xffffffff81424000 a398 opensolaris.ko > > 4 1 0xffffffff8142f000 b67ab0 nvidia.ko > > 5 2 0xffffffff81f97000 450c0 linux.ko > > 6 2 0xffffffff81fdd000 7ee8 linux_common.ko > > 7 1 0xffffffff81fe5000 14dd0 fuse.ko > > 8 1 0xffffffff82211000 23c7 ums.ko > > 9 1 0xffffffff82214000 1890 uhid.ko > > 10 1 0xffffffff82216000 1564 fdescfs.ko > > 11 1 0xffffffff82218000 23a msdosfs_iconv.ko > > 12 1 0xffffffff82219000 322f libiconv.ko > > > > What wrong? > Dunno. Maybe a bad boot sector? > Is it possible to mount it via: > mount -t MSDOS /dev/ada0s2 /mnt > ? > Just a hunch. > > --Chris > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@freebsd.org Mon Feb 29 18:15:40 2016 Return-Path: Delivered-To: freebsd-current@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 AF041AB8715 for ; Mon, 29 Feb 2016 18:15:40 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 7742715E0 for ; Mon, 29 Feb 2016 18:15:40 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-ig0-x229.google.com with SMTP id hb3so688423igb.0 for ; Mon, 29 Feb 2016 10:15:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=og6E4pMKTuzf/EyHy/NB9TsvY8KmM8V8l2iT0iGN+/E=; b=ZY2HL7+aJ7tdO8lLDSx+hb0RqfUGsOjXE/bC1eI/dqgvX+pRF8ekqIywK1x5Hvm+1M FSJC2zJhCv/jsvwemhCG0JmSar5I3QVCV2/BF3nYkkt7hLbqqrxEYjuBbu2YdE6NKHVy K2Jk5rY1UHRJlm/eudh0iIGEVl58QodZkDdx7dTytjOY5GsrJ3MbsoKzi+fb8P1ZOqGL gC41W2OAoTeopgKvfE3UTDBYDvYRtlIyKpdWsnb9Ek09bZ8MzcXFNtTMKY7sQqhwbcNd MywcQg2VbFzIgnxnNF6yI5E9SyFs6XWC3wnbDiXosR/3F/tBEFajrhqpsYNcSqfGTbdx gZrA== 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:date :message-id:subject:from:to:cc; bh=og6E4pMKTuzf/EyHy/NB9TsvY8KmM8V8l2iT0iGN+/E=; b=NwKvW2B46jPCxueco+hfH1u15WNgF5CSzo5bkVHnW236IxizUyvqmnJGZVpk/TdQyq +EbJy09goIhw+npEIxeL6KUO0EZs4Mt+jBvaeq444aNSMKPN+NuHDudAurfoni3uDj49 iYBzcLLJtVbylEIAW7kejpeESlWdAANDeXoqxxYmzsmL9n9hJhS1axWQg62RhN0jkD4s vRTT9wS4u+xpQS3kiZeshD//yAwv2Fx1SpHk1ZLmAvsMnJTJskV85v7qzH2jb9x6ePVf RNZVKhnBCdNwMMEEeSw+WiFz7gVQN7quP1uDU+XqyNh/N4FE8WYPAjcs7/1r/Rn81tL9 d+5w== X-Gm-Message-State: AD7BkJJPaH4aJ4sKMb0zmSb4TyRP2ajpjOWuPZQV8BvXFmxN/FmqqZFhRLKiWhHkog5kkuZV6DVNK1awObJYxA== MIME-Version: 1.0 X-Received: by 10.50.142.37 with SMTP id rt5mr10613105igb.15.1456769739788; Mon, 29 Feb 2016 10:15:39 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.79.35.31 with HTTP; Mon, 29 Feb 2016 10:15:39 -0800 (PST) In-Reply-To: References: <1456743667.143653098@f423.i.mail.ru> <076d9dab6c4b5c1ae2ad80804958c753@ultimatedns.net> Date: Mon, 29 Feb 2016 10:15:39 -0800 X-Google-Sender-Auth: MZlGUxoQ8xhBzMFOvRvvohNrmXs Message-ID: Subject: Re: NTFS disks mounting trouble From: Kevin Oberman To: =?UTF-8?Q?Roberto_Fern=C3=A1ndez?= Cc: Chris H , FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 18:15:40 -0000 On Mon, Feb 29, 2016 at 8:36 AM, Roberto Fern=C3=A1ndez wrote: > That problem seems familiar to me. > > Are you sure that the partition is not locked by a Windows OS? > Sometimes Windows locks the disk on shutdown. > > Best Regards, > Roberto Fernandez Cueto > > 2016-02-29 16:57 GMT+01:00 Chris H : > > > On Mon, 29 Feb 2016 14:01:07 +0300 =D0=9E=D0=BB=D0=B5=D0=B3 =D0=96=D0= =B0=D1=80=D0=BA=D0=BE=D0=B9 wrote > > > > > Hi peoples! > > > I install FreeBSD-Current and sysutils/fusefs-ntfs , but when I try > > mount > > > any NTFS partition I receive error message: [root@zbsd /dev]# ntfs-3g > > > /dev/ada0s2 /mnt Error reading bootsector: Invalid argument > > > Failed to mount '/dev/ada0s2': Invalid argument > > > The device '/dev/ada0s2' doesn't seem to have a valid NTFS. > > > Maybe the wrong device is used? Or the whole disk instead of a > > > partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around? > > > > > > [root@zbsd /dev]# file -s /dev/ada0s2 > > > /dev/ada0s2: DOS/MBR boot sector, code offset 0x52+2, OEM-ID "NTFS "= , > > > sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255= , > > hidden > > > sectors 2929352704, dos < 4.0 BootSector (0x80), FAT (1Y bit by > > descriptor); > > > NTFS, sectors/track 63, sectors 921599, $MFT start cluster 38400, > > $MFTMirror > > > start cluster 2, bytes/RecordSegment 2^(-1*246), clusters/index block > 1, > > > serial number 0a0b64eefb64ec60e > > > > > > [root@zbsd /dev]# uname -a > > > FreeBSD zbsd 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r296078: Fri Feb 26 > > > 18:55:46 IRKT 2016 root@zbsd:/usr/obj/usr/src/sys/zbsd amd64 > > [root@zbsd > > > /dev]# kldstat Id Refs Address Size Name > > > 1 39 0xffffffff80200000 f50aa0 kernel > > > 2 1 0xffffffff81152000 2d1670 zfs.ko > > > 3 2 0xffffffff81424000 a398 opensolaris.ko > > > 4 1 0xffffffff8142f000 b67ab0 nvidia.ko > > > 5 2 0xffffffff81f97000 450c0 linux.ko > > > 6 2 0xffffffff81fdd000 7ee8 linux_common.ko > > > 7 1 0xffffffff81fe5000 14dd0 fuse.ko > > > 8 1 0xffffffff82211000 23c7 ums.ko > > > 9 1 0xffffffff82214000 1890 uhid.ko > > > 10 1 0xffffffff82216000 1564 fdescfs.ko > > > 11 1 0xffffffff82218000 23a msdosfs_iconv.ko > > > 12 1 0xffffffff82219000 322f libiconv.ko > > > > > > What wrong? > > Dunno. Maybe a bad boot sector? > > Is it possible to mount it via: > > mount -t MSDOS /dev/ada0s2 /mnt > > ? > > Just a hunch. > > > > --Chris > Has the file system previously mounted on FreeBSD? What does gpart list ada0 show? I am assuming that fuse.ko is loaded. I discovered that FreeBSD can corrupt FUSE file systems that are not unmounted at shutdown. Best guess is that the fuse daemon is exiting before the unmount is complete. ntfsfix(8) could not repair the damage. I had to use Windows to repair them. This applied to at least NTFS and ExFAT systems. I have resolved the issue with a simple rc.d script that makes sure that the FUSE file systems are safely unmounted before the daemon is terminated. You can find the script in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D200513. No indication t= he bug report has been looked at, but the script has prevented the corruption issue for me. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-current@freebsd.org Mon Feb 29 22:19:08 2016 Return-Path: Delivered-To: freebsd-current@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 8BFD1AB94CF for ; Mon, 29 Feb 2016 22:19:08 +0000 (UTC) (envelope-from fidaj@ukr.net) 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 785D4E04 for ; Mon, 29 Feb 2016 22:19:08 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 740B1AB94CE; Mon, 29 Feb 2016 22:19:08 +0000 (UTC) Delivered-To: current@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 73807AB94CD; Mon, 29 Feb 2016 22:19:08 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from frv157.fwdcdn.com (frv157.fwdcdn.com [212.42.77.157]) (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 39CBDE03; Mon, 29 Feb 2016 22:19:07 +0000 (UTC) (envelope-from fidaj@ukr.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=0ZzqdF40kIRI78ZHoH/Y7fepCiLj3f2+qdUBf6gTRoc=; b=sVuzE7Dm8Rhr2wF94s3xE/jasyFYZ1UB32KwJve6hPeXwnld30rOdPSPl5jKroFsM7eF6fUtyNkxhPXYHNoNtyoNCBpdvLCX3V9ckA6edd6PKM8Ah5Bfkb1R29nCFEnM+1Z0tDAk371YyR2tE1EnIncXha6KC/I+BZdmuYg+OQM=; Received: from [37.229.193.176] (helo=nonamehost.local) by frv157.fwdcdn.com with esmtpsa ID 1aaW9c-0008pB-0d ; Tue, 01 Mar 2016 00:19:00 +0200 Date: Tue, 1 Mar 2016 00:18:58 +0200 From: Ivan Klymenko To: "O. Hartmann" Cc: Tommy Scheunemann , current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: emulators/virtualbox-ose-kmod build error Message-ID: <20160301001858.15dafbca@nonamehost.local> In-Reply-To: <20160225094604.12096017@freyja.zeit4.iv.bundesimmobilien.de> References: <20160224220429.08bfdfde@nonamehost.local> <20160225045515.2b016ac4.ohartman@zedat.fu-berlin.de> <20160225094604.12096017@freyja.zeit4.iv.bundesimmobilien.de> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Result: IP=37.229.193.176; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 22:19:08 -0000 On Thu, 25 Feb 2016 09:46:04 +0100 "O. Hartmann" wrote: > On Thu, 25 Feb 2016 09:31:00 +0100 > Tommy Scheunemann wrote: > > > > Am Wed, 24 Feb 2016 22:04:29 +0200 > > > Ivan Klymenko schrieb: > > > > > >> After update from r295867 to r295994: > > >> > > >> ... > > > > > > Same here ... > > > > > > > Hi, > > > > try to disable ccache for building the port. Been running into the > > same problem and disabling ccache fixed it. > > > > Kind regards > > Don't use ccache! https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207561 So the problem is not on the ccache ;) From owner-freebsd-current@freebsd.org Mon Feb 29 23:00:24 2016 Return-Path: Delivered-To: freebsd-current@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 0D006AB839B for ; Mon, 29 Feb 2016 23:00:24 +0000 (UTC) (envelope-from yuri@rawbw.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 F23FB8FD for ; Mon, 29 Feb 2016 23:00:23 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: by mailman.ysv.freebsd.org (Postfix) id ED891AB839A; Mon, 29 Feb 2016 23:00:23 +0000 (UTC) Delivered-To: current@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 ED1DFAB8399 for ; Mon, 29 Feb 2016 23:00:23 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id C3C588FC for ; Mon, 29 Feb 2016 23:00:23 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yuri.doctorlan.com (c-73-71-174-75.hsd1.ca.comcast.net [73.71.174.75]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id u1TN0HRv036062 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 29 Feb 2016 15:00:17 -0800 (PST) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-73-71-174-75.hsd1.ca.comcast.net [73.71.174.75] claimed to be yuri.doctorlan.com To: current From: Yuri Subject: Could somebody just commit this patch: The new command line option to set the daemon(8) process title ? Message-ID: <56D4CD80.2000501@rawbw.com> Date: Mon, 29 Feb 2016 15:00:16 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 23:00:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205016 This is a very simple and mundane (in my opinion) patch that makes it easier to see which daemon is which when there are a lot of them. Yuri From owner-freebsd-current@freebsd.org Mon Feb 29 23:23:39 2016 Return-Path: Delivered-To: freebsd-current@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 5A4DCAB8E56 for ; Mon, 29 Feb 2016 23:23:39 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.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 3B736A79 for ; Mon, 29 Feb 2016 23:23:39 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 36A63AB8E53; Mon, 29 Feb 2016 23:23:39 +0000 (UTC) Delivered-To: current@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 1CB36AB8E52; Mon, 29 Feb 2016 23:23:39 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 ACE29A77; Mon, 29 Feb 2016 23:23:38 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mail-wm0-x229.google.com with SMTP id l68so12613760wml.0; Mon, 29 Feb 2016 15:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=Rjx+/i537o8JQ+Y0pPTcnWeawkz4pG7ElGBkp97QXlw=; b=ZWxkHO4goiqJ4Gd8b3kb7bt74/agN5Mqd8H4MOwOOMG83BVqGT7uetLhXRSpHo6Zgn /7dScJJWG6iGeFch+zW/1+jC1VDbfdWeyNxL78/cVi0Fe1KqvjZaGrGcBZC/Jg3BE1qF b7cCWzb/XsnYCSzdSzYZCKgJ7+Spp2YbHTyifYOTp8RsjvbNopaJtInfDQWIH7H61gRI oVrpIL2Dg641o/rpKFJCD3HR3q/M8CrW6i1HUQAjm3K5ptFex/qDUk2U9ysTs0t8Fvpg MPij9ZreZPlyGLPAgJQ8NU4QPTRA/scmxueORYh7Y/5QUddPFfHlHJzKjWO/cJvVPBGG vlGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:subject:message-id :mime-version:content-disposition:user-agent; bh=Rjx+/i537o8JQ+Y0pPTcnWeawkz4pG7ElGBkp97QXlw=; b=Wrz9U2J9NDlM93p6Fx7E6bLIMjDvDXSB+q2/CTXCwQiVbOcv8sAw0eGXhVB+zcqDM8 9ksN/hz27EypTJgUvMDY/gmfZLmGi4uZQtfL0wJt+cEX9L0ZJ9bREOrN8V4oqDRACoi5 rq8Otl3uYCfVx/6rXHlFzcUT/wDXp4+qPRZnoJPLtJgtR74cSlgWfcuRC/EUylwqJFz7 wSiNNHh9kw29E6qexhZfRhz0H1x2+5TsS2AP0sneyL3zOBpCia+I85axA+aGjin/9co8 Ccl1iwmcVvxyWu+4ej8ry+DvIcntcD5VXhQysdaUOH1Aa1Q/u/m+e4R3h5S0/R9TH9FE c/Ew== X-Gm-Message-State: AD7BkJKrZXFnJnZwurVpx251BGdQFBys7qd/T0O07XpSXrUrsm2REiXQhXHodHMt4B3IQA== X-Received: by 10.194.78.37 with SMTP id y5mr16939920wjw.78.1456788217183; Mon, 29 Feb 2016 15:23:37 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id w144sm18438587wmd.8.2016.02.29.15.23.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Feb 2016 15:23:36 -0800 (PST) Sender: Baptiste Daroussin Date: Tue, 1 Mar 2016 00:23:34 +0100 From: Baptiste Daroussin To: current@freebsd.org, hackers@freebsd.org Subject: Dropping some locales/encodings? Message-ID: <20160229232334.GG84995@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HKEL+t8MFpg/ASTE" Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 23:23:39 -0000 --HKEL+t8MFpg/ASTE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, I have updated few month ago the locales to cldr v27.0.1. I would like to simplify the generation of those locales from cldr to POSIX locales that we do provides. I can properly generate almost any of the said locales/encodings but a few that I would like to remove (provided that unicode version are available) Here is the list of locales/encodings: be_BY.CP1251 be_BY.CP1131 hi_IN.ISCII-DEV hy_AM.ARMSCII-8 zh_HK.Big5HKSCS Provided that those should be covered by respectively: be_BY.ISO8859-5 be_BY.UTF-8 hi_IN.UTF-8 hy_AM.UTF-8 zh_HK.UTF-8 zh_Hans_HK.UTF-8 Anyone has a strong opinion against this removal? The reason to remove those is that they are not provided by cldr Best regards, Bapt --HKEL+t8MFpg/ASTE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW1NL2AAoJEGOJi9zxtz5aHZoP/3uNhflE9oySilU6kWWcEoU+ ayBbrDMvWIsW60Yge06lM2Tpjl+aKX3tPNLcIhh40JdKe8OOR68peJ7hjF1jQaOr J4pFQY5CxvUdd1HNOCzhGNMNHM3cN5QTq4I+1KEjZKbH+fcW13NodN8b3LfA/BG+ ndrJ1hg+QDfA4VvajxJa0kUJVu1ve7MU3e6mnAi/hhHpCy3iyyc81HxplI3oda94 n+NGXFaYF/asK6uLQWQK3rRVj+B0rEuKCUrM/mHORQKfRqaW/ww6ajc4EbViympI 1eok1dOIkpoX+Snrx5uZPM7ELwf3seiyAYJPA5SnPA+Yb6DzlUNCCb3IjMyf7JjA 3lbiVivfZAbgur5DsfFFg7T50OT3PgrKaYM8wCZKQV10BDREWUn4cof3ofYw11+P xt6vGP3aFYdT8ytGiJ0EjyO81KVBa44VN9jDzquyNzdo/Iziti0UntUMMrNiMv1L JwUWJfLQZZdQ5CcQC46dIPBrQWPJAnxIfUz52zLiaBQg2MoQpOGlXpFYgb2g2Ote yTQlylzHwYVzv7NpwvvbrcUxKo5KMilcHBvjMqXhX/n/ht8m7ye8MY4kBrUurmRV A5ONrG/wCwiNCvUQ9cBRlbXQ1HMM7EVTmwlADp8PH0A6alfRLCCrhPX92UHzDPsJ 1usFgsIJWRq52jQWmRhH =8759 -----END PGP SIGNATURE----- --HKEL+t8MFpg/ASTE-- From owner-freebsd-current@freebsd.org Mon Feb 29 23:59:07 2016 Return-Path: Delivered-To: freebsd-current@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 8DE3EAB9B61 for ; Mon, 29 Feb 2016 23:59:07 +0000 (UTC) (envelope-from cse.cem@gmail.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 723D7B28 for ; Mon, 29 Feb 2016 23:59:07 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6D6FDAB9B60; Mon, 29 Feb 2016 23:59:07 +0000 (UTC) Delivered-To: current@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 6D03CAB9B5F for ; Mon, 29 Feb 2016 23:59:07 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-yw0-f169.google.com (mail-yw0-f169.google.com [209.85.161.169]) (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 39628B27 for ; Mon, 29 Feb 2016 23:59:07 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-yw0-f169.google.com with SMTP id h129so135681047ywb.1 for ; Mon, 29 Feb 2016 15:59:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc; bh=iUHqqB3kbm95rU+DRLf1KmijhPJU49ww8TcWEgytPZM=; b=UORnJ73MN+4dgGkMU3YewySwvqkgq4z/atABCEMUdc9atII3Jn3/UmNZKlVGbUzD0E 7396s5lcVpJ34z65LbC9C6pMmpf9HzVuYowkFbPqux7/wD796pfqunD7T0mlTFDrJCmo 5hUXAkSzi357/8WY3APi95emuDd0UNqvxVVkr9v9HO1AdVtXtOaK0bfH5WHiPn4ZkDR8 1TlH7bhCnw2LBbxaMlqNQTCzxprqxrvvOCSJB0BlEMAknyBdLcBA1SVWoMsVYhSvAA/c LI8dFoFii15pe31wgHAgvmkiMH/KcSePKqPwGVJJLKCZMY5BzVy1LSKV6HC+uJ5WhlQJ toLw== X-Gm-Message-State: AD7BkJIoleLuAdsd0KjMEsVCbxw3yX3sRcXsbFVusqpw2OWvJC5bZjn82Rn9mNtIsqZOrQ== X-Received: by 10.13.196.1 with SMTP id g1mr10217432ywd.209.1456787117916; Mon, 29 Feb 2016 15:05:17 -0800 (PST) Received: from mail-yw0-f180.google.com (mail-yw0-f180.google.com. [209.85.161.180]) by smtp.gmail.com with ESMTPSA id g187sm22438717ywd.51.2016.02.29.15.05.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Feb 2016 15:05:17 -0800 (PST) Received: by mail-yw0-f180.google.com with SMTP id h129so134747630ywb.1 for ; Mon, 29 Feb 2016 15:05:17 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.129.31.131 with SMTP id f125mr9843931ywf.267.1456787117278; Mon, 29 Feb 2016 15:05:17 -0800 (PST) Reply-To: cem@FreeBSD.org Received: by 10.37.115.134 with HTTP; Mon, 29 Feb 2016 15:05:17 -0800 (PST) In-Reply-To: <56D4CD80.2000501@rawbw.com> References: <56D4CD80.2000501@rawbw.com> Date: Mon, 29 Feb 2016 15:05:17 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Could somebody just commit this patch: The new command line option to set the daemon(8) process title ? From: Conrad Meyer To: Yuri Cc: current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 23:59:07 -0000 On Mon, Feb 29, 2016 at 3:00 PM, Yuri wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205016 > > This is a very simple and mundane (in my opinion) patch that makes it easier > to see which daemon is which when there are a lot of them. I'd be happy to (+ manual page changes) if I don't hear any objection in the next few days. I would keep [pid] in the title and just replace argv0 with the -t argument. Best, Conrad From owner-freebsd-current@freebsd.org Tue Mar 1 00:23:07 2016 Return-Path: Delivered-To: freebsd-current@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 7BE14AB7F13 for ; Tue, 1 Mar 2016 00:23:07 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F2D32DE for ; Tue, 1 Mar 2016 00:23:07 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date; bh=SfQ+7VS/Augu6dCmnhLFmFS/P+kCyvNjmp2u1Vn/bLg=; b=t f2OT2zdI51IokDX34zJa58mTC2FPd5M8JtRETMYkis15dPmaxa8mx6QKDWVdAcNNLmE607y0w5EYI zG16eNqJFz9n63ISzBJ5wY8IoyQbzwTq3tzv+HpXYUTbylQKRo30/1t4SH2SE3O6qW3Tx18MmSGEg 9lI0b4jvuO7PA/lw=; Received: from [2605:6000:ec17:203:ed2:92ff:fe96:98a3] (port=53995 helo=trivet.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aaY5i-0009Xi-Cy; Mon, 29 Feb 2016 18:23:06 -0600 Date: Mon, 29 Feb 2016 18:22:57 -0600 From: Larry Rosenman To: freebsd-current@freebsd.org Cc: medda.mauro@gmail.com Subject: Re: Mouse on Inspiron ? Message-ID: <20160301002257.GA1205@trivet.lerctr.org> Mail-Followup-To: freebsd-current@freebsd.org, medda.mauro@gmail.com References: <20160228165632.GA1265@lrosenman-dell2.lerctr.org> <20160228174518.GA1167@lrosenman-dell2.lerctr.org> <0598ACAD-4BE4-4CC5-88CE-D62BC781541C@FreeBSD.org> <20160228215147.GA1220@lrosenman-dell2.lerctr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160228215147.GA1220@lrosenman-dell2.lerctr.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Score: -1.0 (-) X-LERCTR-Spam-Score: -1.0 (-) X-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 X-LERCTR-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 00:23:07 -0000 On Sun, Feb 28, 2016 at 03:51:47PM -0600, Larry Rosenman wrote: > On Sun, Feb 28, 2016 at 03:53:05PM -0330, Jonathan Anderson wrote: > > On 28 Feb 2016, at 14:15, Larry Rosenman wrote: > > > > > Ok, a verbose boot tells me /dev/psm0 can't allocate an IRQ. > > > > > > Ideas? > > > > > > Verbose boot attached > > > > Hi Larry, > > > > I believe that someone encountered (and fixed!) a similar problem last > > year: > > https://lists.freebsd.org/pipermail/freebsd-stable/2015-February/081757.html > > Yep, that's the SAME laptop. > > Mauro, can I get a copy of the DSDT or instructions? Can someone(tm) walk me through modifying the DSDT? I can supply whatever you need...... > > > > It seems that this is becoming an issue on new notebooks: I know that my > > new ASUS notebook has the same problem (but, unfortunately, Mauro's fix > > doesn't apply to my machine). > > > > > > Jon > > -- > > Jonathan Anderson > > jonathan@FreeBSD.org > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 214-642-9640 E-Mail: ler@lerctr.org > US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 From owner-freebsd-current@freebsd.org Tue Mar 1 02:55:43 2016 Return-Path: Delivered-To: freebsd-current@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 510EFAB8D78 for ; Tue, 1 Mar 2016 02:55:43 +0000 (UTC) (envelope-from mailing-machine@vniz.net) 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 318F31EB6 for ; Tue, 1 Mar 2016 02:55:43 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mailman.ysv.freebsd.org (Postfix) id 2EEE8AB8D77; Tue, 1 Mar 2016 02:55:43 +0000 (UTC) Delivered-To: current@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 14A39AB8D76 for ; Tue, 1 Mar 2016 02:55:43 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (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 99C5B1EB3 for ; Tue, 1 Mar 2016 02:55:41 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lb0-f171.google.com with SMTP id x1so91301677lbj.3 for ; Mon, 29 Feb 2016 18:55:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=SA02gBLIL0PznJr4HIOSy+nW0PvxopdSH56JsSx57pg=; b=EECl64C/LpLUcLkj20dR7Whi7StCgc8RUhpdK5T/2wugJYahAKru+4VtIyyMXEuefB e8+21N1H3pwizJq2TgTZV/uVhsH0Ojly3OdIk+e7lzbpFZ9TpPAhWJ3avOKqr1AMyxfY 6DyNDHL6hZ6fbVWMgdTPldm9dy82ohyVm1LsI8wfPfYkwkaUHes3VvsPVMkSEOuNNwg3 6dC/5CoP1Xgf7GGKjwGLD6TxdgJWD+eJY6bEc1f6QiXd88Mx1VV9WBCjNzzdalozOhth pQNKXI0YB23pLhmuz09IwrEhcgDKIpptANvGW+9zrcKT4H6H+13lFU46OgNtGtw+iwek y4+A== X-Gm-Message-State: AD7BkJI+EN81niJwYBabjYt7JiAZdmnLeO8euNTALxlG+sgqqNAOYG51VjnNGelibLgxSQ== X-Received: by 10.112.149.73 with SMTP id ty9mr3539528lbb.48.1456800448119; Mon, 29 Feb 2016 18:47:28 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id a124sm4546870lfa.40.2016.02.29.18.47.26 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Feb 2016 18:47:27 -0800 (PST) Subject: Re: Dropping some locales/encodings? To: Baptiste Daroussin , current@freebsd.org, hackers@freebsd.org References: <20160229232334.GG84995@ivaldir.etoilebsd.net> From: Andrey Chernov Message-ID: <56D502BD.9020704@freebsd.org> Date: Tue, 1 Mar 2016 05:47:25 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160229232334.GG84995@ivaldir.etoilebsd.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="j9i60uE0mGJcG9pJuMHkRGdMLSn7tW7s7" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 02:55:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --j9i60uE0mGJcG9pJuMHkRGdMLSn7tW7s7 From: Andrey Chernov To: Baptiste Daroussin , current@freebsd.org, hackers@freebsd.org Message-ID: <56D502BD.9020704@freebsd.org> Subject: Re: Dropping some locales/encodings? References: <20160229232334.GG84995@ivaldir.etoilebsd.net> In-Reply-To: <20160229232334.GG84995@ivaldir.etoilebsd.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01.03.2016 2:23, Baptiste Daroussin wrote: > Hi all, >=20 > I have updated few month ago the locales to cldr v27.0.1. I would like = to > simplify the generation of those locales from cldr to POSIX locales tha= t we do > provides. >=20 > I can properly generate almost any of the said locales/encodings but a = few that > I would like to remove (provided that unicode version are available) >=20 > Here is the list of locales/encodings: >=20 > be_BY.CP1251 CP1251 is Windows native (single characters mode) and widely used to represent Cyrillic: Russian, Bulgarian, Serbian, Ukrainian, Belarusian (i.e. be_BY), Macedonian. IMHO it will be better to not remove it to make easy handling of native encoded texts comes from Windows. Don't know about other mentioned. --=20 http://ache.vniz.net/ --j9i60uE0mGJcG9pJuMHkRGdMLSn7tW7s7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJW1QK+AAoJEKUckv0MjfbKtscH/inCYXG4kIVSGH+eIMMo+Oez Sylov5tFJd4ToEQGI8nQKHK1jCN0yuBLPE0mCPK0B1anpflOaO+K7kEAZbl9UgWa hCIoVQtISnmfjhzBV1UbxlZANLR0uun6Ya8PDU0qSoCjZxSBKQz2hdyCkiem820F q95vmqxR4elSu5Zb4EWbNo6CbjDc3StjZ4GToBYzbfO2OXXJFzoIRLENY7tLlMuA OF16CxRXZosb07FNRH4b02/ZO2EZy4VTeN6q87ZgznqMe/KLS992hAAV1NwOwzao cOri4/qfB8H+YTIEfHOb5QfouTc1gDBNKkPY0AAFmGZ8l2XsRkDJcdwgkTRtqm0= =quXC -----END PGP SIGNATURE----- --j9i60uE0mGJcG9pJuMHkRGdMLSn7tW7s7-- From owner-freebsd-current@freebsd.org Tue Mar 1 03:41:12 2016 Return-Path: Delivered-To: freebsd-current@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 10875AB8414 for ; Tue, 1 Mar 2016 03:41:12 +0000 (UTC) (envelope-from sm@ara-ler.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 E58E71EF0 for ; Tue, 1 Mar 2016 03:41:11 +0000 (UTC) (envelope-from sm@ara-ler.com) Received: by mailman.ysv.freebsd.org (Postfix) id E50FEAB8413; Tue, 1 Mar 2016 03:41:11 +0000 (UTC) Delivered-To: current@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 E4A83AB8411 for ; Tue, 1 Mar 2016 03:41:11 +0000 (UTC) (envelope-from sm@ara-ler.com) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (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 ACCDF1EEF for ; Tue, 1 Mar 2016 03:41:11 +0000 (UTC) (envelope-from sm@ara-ler.com) Received: by mail-ob0-x22a.google.com with SMTP id ts10so155124931obc.1 for ; Mon, 29 Feb 2016 19:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ara-ler-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ZY+j+AgPosCZx3ifPME0haVA1NYNiYB/4eV5djmWC1I=; b=HVbCxiBnywddH/NZLcL1IvyCdfjfte30lzKb5b5jOH2s3txziEVdA/z4CrCF3Q/flq +yvYlGvad9sIVYucTbegLLJUdg0mB+UEBoUpKloSiht6b/zTrWPfQPY2v7rrNBRrCxqy ioJaYedYiRK/qruu3Q0+9jU9guKiEtd1XqVJzkG2T0ZMB25amAPhZAk+FteHpjJIXf5R PL1nGJ4Mz46keXTvhMzF7TyL+p02+oxYT5yXU3rRhkExhd3PTSMCK8gNgofXb7aCOkrL TlZLdcvfU9pYTJ0cDy6M9o06IvdCi8WNqC84+695ysGheE/jOkRyfAwO71WYKYnb1byy zfyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ZY+j+AgPosCZx3ifPME0haVA1NYNiYB/4eV5djmWC1I=; b=WavndkD4yFx6Y89cVz1bqCRBoEa6t5tKxfATiyYdVBRZtT2Ol7yH1PHUWogTuORfg6 pidGUJYd0T4gLzZvkMHo3M3H6+9jeJVhdx9GPqwF9ArKk/UosSdpim+Pkk/yskuN86Vw UP71aqbVSSfBx8gADRqkAhzfpF9yMGZ3jZHdkquFAfmc4tuGU+MnrqSODme1n/TSvNLB DHlXPQlko77INA4Z7CHO2VHY4377QzCJHLQAYsjt8Zif9k+oeECQfJQADlFEBTuUPmwR KXGWv+lt+/BkwoU1pwYbrmurWBeSd145lVRgAgOfHdKADpS39wsxPZ7Aiww0u1Kl4v3F zIGw== X-Gm-Message-State: AD7BkJITrdf4b/qwAiYXHE8I2FjD0KASuxRvKHt63QDRZ9Urff91+lX8VLzmXvIIoJhBdQ== X-Received: by 10.182.55.10 with SMTP id n10mr14309038obp.68.1456803671011; Mon, 29 Feb 2016 19:41:11 -0800 (PST) Received: from dendrobates.araler.com (97-122-190-138.hlrn.qwest.net. [97.122.190.138]) by smtp.gmail.com with ESMTPSA id l136sm20338661oib.5.2016.02.29.19.41.09 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Feb 2016 19:41:10 -0800 (PST) Date: Mon, 29 Feb 2016 20:41:08 -0700 From: Sergey Manucharian To: Baptiste Daroussin Cc: current@freebsd.org, hackers@freebsd.org Subject: Re: Dropping some locales/encodings? Message-ID: <20160301034108.GG52633@dendrobates.araler.com> References: <20160229232334.GG84995@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160229232334.GG84995@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 03:41:12 -0000 Excerpts from Baptiste Daroussin's message from Tue 01-Mar-16 00:23: > > I would like to remove (provided that unicode version are available) > > Here is the list of locales/encodings: > > be_BY.CP1251 > be_BY.CP1131 > hi_IN.ISCII-DEV > hy_AM.ARMSCII-8 > zh_HK.Big5HKSCS > > Provided that those should be covered by respectively: > be_BY.ISO8859-5 be_BY.UTF-8 > hi_IN.UTF-8 > hy_AM.UTF-8 > zh_HK.UTF-8 zh_Hans_HK.UTF-8 > > Anyone has a strong opinion against this removal? > Well, as a locale hy_AM.ARMSCII-8 is definitely not needed. However, as an encoding it's still useful: sometimes I (and probably some other people) need to convert some "ancient" documents from ARMSCII-8 to UTF-8. I do not think that the removing it will prevent such conversion anyway (e.g. with iconv), correct? Sergey P.S. "hy" = Hayastan = Armenia From owner-freebsd-current@freebsd.org Tue Mar 1 03:45:48 2016 Return-Path: Delivered-To: freebsd-current@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 0B899AB87F9 for ; Tue, 1 Mar 2016 03:45:48 +0000 (UTC) (envelope-from sm@ara-ler.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 E004D977 for ; Tue, 1 Mar 2016 03:45:47 +0000 (UTC) (envelope-from sm@ara-ler.com) Received: by mailman.ysv.freebsd.org (Postfix) id DF7F6AB87F5; Tue, 1 Mar 2016 03:45:47 +0000 (UTC) Delivered-To: current@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 DF180AB87F4 for ; Tue, 1 Mar 2016 03:45:47 +0000 (UTC) (envelope-from sm@ara-ler.com) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (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 A5839972 for ; Tue, 1 Mar 2016 03:45:47 +0000 (UTC) (envelope-from sm@ara-ler.com) Received: by mail-ob0-x22f.google.com with SMTP id fz5so23395091obc.0 for ; Mon, 29 Feb 2016 19:45:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ara-ler-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ci4svKoV21Vr+FTrZyaLCMMOJ9FeWZD2exjzRRL+dvw=; b=mjN15Q5S7vmOJDU+Kn+7GEjsGsN/1+l6GZhGIhEnjRviUeJiqPzrORnOXKhjyNBbhA k3n0JvMNVjHbPZh2LrtlTNacMazkntY4d05LX6fnHwuhCS1UyEFIwyCzIgTW9eQgBojX /HJCwAR0yC0+c2y3bT7hJHdtC4jzRX8t06qcp7nIQgE1dmEEn6TtaD+IDStYhnsYm8kb NKYQH7FmULGhaiZ6NBFgiHHmtw3hfBMi4euR5ArSmy3WvX25R87FYki/cQWr+SVEhQyS GYOadF9FnlVxEQDqCAHt9N8vLZFxbq7+dyU58Z6fhp6HbyfngQvQ1cCqCkTBZiEdR7Xn SFIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ci4svKoV21Vr+FTrZyaLCMMOJ9FeWZD2exjzRRL+dvw=; b=MsYww+x2wQYENw9ug0a0wjb433g4Xh5DyctXGxZ3BxtmwkrV66z9unW+axFaHhUMh1 M4Aai0OyYEeIFl4gskEj7K08JQlGvQ5IPZ0QFbTWZ8KPZFJRAXubC3bqXw0tc6opFzQM bGXM+UCUMHfpeYdylro1GhJUHSxf/OAmgadG+e2yjrynYqWRiQ+8NGcccD+DPUhmKMWl lQ8jwUpJK1k38OKWITZxQCDpSl+ZG+5FAmCOp7j5+ibvTHDi1Gfii/FTxjSDK79IeSSn lwzfXMath8bEO8bLxbqvYZ5HIVF4cG4sEA3SJkiR9y0tbLdmu/vf0WkMenU2Fw8oF592 jHAQ== X-Gm-Message-State: AD7BkJI5aOrAcrT4Ozeg64BMtwVWkx8IRF4I9G+4a76fpPoRevI3rtKmQnSm400Pq7BOIA== X-Received: by 10.182.225.231 with SMTP id rn7mr15071406obc.2.1456803946976; Mon, 29 Feb 2016 19:45:46 -0800 (PST) Received: from dendrobates.araler.com (97-122-190-138.hlrn.qwest.net. [97.122.190.138]) by smtp.gmail.com with ESMTPSA id y85sm20369447oif.6.2016.02.29.19.45.46 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Feb 2016 19:45:46 -0800 (PST) Date: Mon, 29 Feb 2016 20:45:44 -0700 From: Sergey Manucharian To: Andrey Chernov Cc: Baptiste Daroussin , current@freebsd.org, hackers@freebsd.org Subject: Re: Dropping some locales/encodings? Message-ID: <20160301034544.GH52633@dendrobates.araler.com> References: <20160229232334.GG84995@ivaldir.etoilebsd.net> <56D502BD.9020704@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56D502BD.9020704@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 03:45:48 -0000 Excerpts from Andrey Chernov's message from Tue 01-Mar-16 05:47: > On 01.03.2016 2:23, Baptiste Daroussin wrote: > > > > I can properly generate almost any of the said locales/encodings but a few that > > I would like to remove (provided that unicode version are available) > > > > Here is the list of locales/encodings: > > > > be_BY.CP1251 > > CP1251 is Windows native (single characters mode) and widely used to > represent Cyrillic: Russian, Bulgarian, Serbian, Ukrainian, Belarusian > (i.e. be_BY), Macedonian. IMHO it will be better to not remove it to > make easy handling of native encoded texts comes from Windows. > I agree with Andrey that CP1251 is needed as one of major Cyrillic encodings. Not sure how the locale existence/absence effects that. Definitely nobody uses it as a locale for more than a decade. Sergey From owner-freebsd-current@freebsd.org Tue Mar 1 07:21:54 2016 Return-Path: Delivered-To: freebsd-current@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 8E78AABC902 for ; Tue, 1 Mar 2016 07:21:54 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (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 5B2EB12B3 for ; Tue, 1 Mar 2016 07:21:54 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 2D3511FE022; Tue, 1 Mar 2016 08:21:21 +0100 (CET) Subject: Re: Touchscreen support (was Re: new computer, strange usb messages at boot) To: "Sergey V. Dyatko" References: <20160220051951.GA47875@lrosenman-dell.lerctr.org> <20160220120401.GA91220@kib.kiev.ua> <20160220122416.GA1026@lrosenman-dell.lerctr.org> <2575cfd714188f7ffbc873cb5d87cc97@thebighonker.lerctr.org> <56CA6F67.4000001@yahoo.com> <56CAB4A7.8080604@selasky.org> <56CB39B0.3020307@yahoo.com> <56CB3C74.7050103@selasky.org> <20160301083006.671d3987@laptop.minsk.domain> Cc: freebsd-current@freebsd.org From: Hans Petter Selasky Message-ID: <56D5438C.8020601@selasky.org> Date: Tue, 1 Mar 2016 08:23:56 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160301083006.671d3987@laptop.minsk.domain> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 07:21:54 -0000 On 03/01/16 06:30, Sergey V. Dyatko wrote: > after that I reconnect my mouse and 'it works' (c) > How I can do this automatically right? There are some examples in /usr/local/etc/rc.d/webcamd for entries you can add to your /etc/rc.conf, to do this automatically. --HPS From owner-freebsd-current@freebsd.org Tue Mar 1 05:33:08 2016 Return-Path: Delivered-To: freebsd-current@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 86AD7ABDC07 for ; Tue, 1 Mar 2016 05:33:08 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 1EBF6108E for ; Tue, 1 Mar 2016 05:33:08 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id n186so19395060wmn.1 for ; Mon, 29 Feb 2016 21:33:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=dV0awrD1xKPqgPMZXXT2HBN8+8pEYWNE/tOESBLtk/Q=; b=GmYYnSeH3vk/M41h0JxlTcyR+xzWEYpVFdhLdum5ubWb/7A5j14kPoGIGkM0t/oA55 FZP6N3kcH+fUR6DdhBH+T46wcNCXXMvx1nGodcCedpnRyPgaLSrrT/1x0SLXbIKHmImR dDD9asBMvqnNDFt+8qc7c+wB8YfqWTEjzBOUKNjpQbLu/ayObACTtzRatC7mIcZiTEvj kPauIhcHVjTrSpzDX/B1Pm7thIRRQLahnAq1SmTvWWFmuOir+UkAi0VZBkRU24wHMH/N WnDiG/G7S+NvNfaW51FyoAYt7Nc43PEsaQ2k2gugX3araa14MAIP0lTqW3Iec7hxpLrE AJig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=dV0awrD1xKPqgPMZXXT2HBN8+8pEYWNE/tOESBLtk/Q=; b=FdPSDHgYumN/KdtM7lvQrdsrR2TmX9PP8WJ+PxAP9DtpVwmfQ/kfjHZq5vwW3I0Ase z53FKcecYwhimAWZmFiP0J+uORyMQJoewkqqAMqEeYZz5eyMZlxZn9jYrTc5c++32u9S ZmsttQYs6fF1vOqaGuX6egqGczQ1I/1MXt23EJJnC+9m2Ep4gi4ii3fJUcun03J3hsdH oJqRgYZ6F6bJwbvzEJF1yZeNp58sEQlhZAzPtretf0GjvK1CWP61bYehpWEZxjDo9ZMo BbDdXQieAhAhvo5YZdsXI5JAepV5oFchYxxYpEuyfeHNGDQasGuLvQ3rn6R/0fU5raFx Huog== X-Gm-Message-State: AD7BkJLL2+dt9rqqg1b+LyuPZeH8vvyXRyOs3yXLtHr1Z8+/BJo/nP8e3lpBae1smrxZ3A== X-Received: by 10.28.141.141 with SMTP id p135mr1590435wmd.30.1456810386076; Mon, 29 Feb 2016 21:33:06 -0800 (PST) Received: from laptop.minsk.domain (minsk.nivalnetwork.com. [86.57.144.74]) by smtp.gmail.com with ESMTPSA id e19sm19595393wmd.1.2016.02.29.21.33.04 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Feb 2016 21:33:05 -0800 (PST) Date: Tue, 1 Mar 2016 08:30:06 +0300 From: "Sergey V. Dyatko" To: Hans Petter Selasky Cc: freebsd-current@freebsd.org Subject: Re: Touchscreen support (was Re: new computer, strange usb messages at boot) Message-ID: <20160301083006.671d3987@laptop.minsk.domain> In-Reply-To: <56CB3C74.7050103@selasky.org> References: <20160220051951.GA47875@lrosenman-dell.lerctr.org> <20160220120401.GA91220@kib.kiev.ua> <20160220122416.GA1026@lrosenman-dell.lerctr.org> <2575cfd714188f7ffbc873cb5d87cc97@thebighonker.lerctr.org> <56CA6F67.4000001@yahoo.com> <56CAB4A7.8080604@selasky.org> <56CB39B0.3020307@yahoo.com> <56CB3C74.7050103@selasky.org> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 05:33:08 -0000 On Mon, 22 Feb 2016 17:51:00 +0100 Hans Petter Selasky wrote: > On 02/22/16 17:39, Anthony Jenkins wrote: > > > > > > On 02/22/2016 02:11 AM, Hans Petter Selasky wrote: > >> On 02/22/16 03:16, Anthony Jenkins wrote: > >>> Yes. I have an eGalax touchscreen and it's doing the same thing. The > >>> number of items it's reporting is 256 (according to my preliminary > >>> debugging), causing the warning. I think these things are a special > >>> subclass of HID for multitouch touchscreens which we don't support > >>> (yet). > >> > >> /usr/ports/multimedia/webcamd will most likely attach if invoked > >> manually, to this device and provide an event device for you! > >> > >> --HPS > > > > Okay that's /amazing/, and not at all intuitive! I mean I'd expect > > multimedia/webcamd to only attach to "video" devices, but lo and behold > > I get a /dev/input/event0 device which spits out gibberish when > > cat(1)'ed and I touch the screen! > > > > My intentions were to port Linux's hid-multitouch device in whole to > > FreeBSD (it's what attaches to my eGalax device and probably to OP's > > touchscreen device) and add support for the device to moused(8), but > > it's not very high on my priority list... > > > > Hi, > > If you apply these patches, will work with your X-org :-) > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196678 > wow... Thanks for your work :) Yesterday I update -CURRENT on my lenovo z400 touch ( r296180), after suspend-resume I spotted that is my usb mouse didn't work (touchpad works as before) I had the feeling that I read something about hid_get_item: Number of items(256) truncated to 255 on ML, so I'm here. What I do: laptop# webcamd -l Available device(s): .... webcamd [-d ugen0.2] -N Synaptics-Large-Touch-Screen-SYNAPTICS -S unknown -M 0 ... Show webcamd usage: webcamd -h laptop# webcamd -N Synaptics-Large-Touch-Screen-SYNAPTICS -S unknown -M 0 Attached to ugen0.2[0] Creating /dev/input/event0 after that I reconnect my mouse and 'it works' (c) How I can do this automatically right? -- wbr, tiger From owner-freebsd-current@freebsd.org Tue Mar 1 08:00:37 2016 Return-Path: Delivered-To: freebsd-current@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 497FBABABDB for ; Tue, 1 Mar 2016 08:00:37 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.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 2958E1FEE for ; Tue, 1 Mar 2016 08:00:37 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 24A4CABABD7; Tue, 1 Mar 2016 08:00:37 +0000 (UTC) Delivered-To: current@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 0A598ABABD6; Tue, 1 Mar 2016 08:00:37 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 968A41FEB; Tue, 1 Mar 2016 08:00:36 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id l68so21407567wml.1; Tue, 01 Mar 2016 00:00:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=8xh7HBQOFuBX8XZ8v8iC8YUbICcrSEu1SuN6oVj+zPo=; b=ngBK/0MhtRlaZBGrotWTd/kYY5cHJ1SNSgno9uk6au6lL2JzPtI58pnucUGlyTu/V1 S9Ua0qP7YFVSSfoIB0yfT/ChxrKE/+847/zTf97dz8Hv+r74mc42tnzvim+irQQ7EATa TenM5jU4x+vmqyT6Oeq9M6srr9kESZAiaXmLT6XxLn1gsYbDeEPEvgHcuWgfkGY3FXLh b9Q9oHMYgf9gk3nT7vrRJMKBTHevdBtfoofnUNKHGZjH+rcQy0QMBBJUCSbVGiZehkqv owBYHpjXC2X2LqKRpox3D9h6ZhYXTWoF7R7YbgotaPIn7nQJeQ2Na1VSE8wkfzsMVROv xwyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=8xh7HBQOFuBX8XZ8v8iC8YUbICcrSEu1SuN6oVj+zPo=; b=B2DPLf0qAbF2AOUL1UCmPnl8DqbcqTpQ5+usmRomuhTkBqCvtISTWZyH3Ux47vIAKQ PKawCGcr/2X4X0wNCdhq5xHva8aG1fvQ/Gz37hh/RkzVet+MnnC3avhDT4AwsVPHzfHx NwYoM/UPgEsYxTh9ixksoyb5XZ2jwYnhobByoKqxObpaUH/snhf3oWIwANn61iv1kmum N1Fa2C5yKqBljb1Ujts5cs5ZKaZ8ttqGJBIRxoVqPsxNk6LpZkcxyRmysTepSFuEBO19 /tinO5ub0X2tVnoX8GGnpbVRpqMmXcEpJs6tFSxA1pdSvP20K3fgDSkfivGJzt0ccVn4 jkLw== X-Gm-Message-State: AD7BkJKLMwKvcRyLqJNeurUzitJU8dNlGPy0XClB5asjhus4Ae3pDGZ5hESeSAQoHBbjGg== X-Received: by 10.28.9.71 with SMTP id 68mr2079952wmj.33.1456819235016; Tue, 01 Mar 2016 00:00:35 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id jf6sm8625152wjb.2.2016.03.01.00.00.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Mar 2016 00:00:34 -0800 (PST) Sender: Baptiste Daroussin Date: Tue, 1 Mar 2016 09:00:32 +0100 From: Baptiste Daroussin To: Sergey Manucharian Cc: current@freebsd.org, hackers@freebsd.org Subject: Re: Dropping some locales/encodings? Message-ID: <20160301080031.GA31877@ivaldir.etoilebsd.net> References: <20160229232334.GG84995@ivaldir.etoilebsd.net> <20160301034108.GG52633@dendrobates.araler.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline In-Reply-To: <20160301034108.GG52633@dendrobates.araler.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 08:00:37 -0000 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 29, 2016 at 08:41:08PM -0700, Sergey Manucharian wrote: > Excerpts from Baptiste Daroussin's message from Tue 01-Mar-16 00:23: > >=20 > > I would like to remove (provided that unicode version are available) > >=20 > > Here is the list of locales/encodings: > >=20 > > be_BY.CP1251 > > be_BY.CP1131 > > hi_IN.ISCII-DEV > > hy_AM.ARMSCII-8 > > zh_HK.Big5HKSCS > >=20 > > Provided that those should be covered by respectively: > > be_BY.ISO8859-5 be_BY.UTF-8 > > hi_IN.UTF-8 > > hy_AM.UTF-8 > > zh_HK.UTF-8 zh_Hans_HK.UTF-8 > >=20 > > Anyone has a strong opinion against this removal? > >=20 >=20 > Well, as a locale hy_AM.ARMSCII-8 is definitely not needed. However, as > an encoding it's still useful: sometimes I (and probably some other peopl= e) > need to convert some "ancient" documents from ARMSCII-8 to UTF-8. >=20 > I do not think that the removing it will prevent such conversion anyway > (e.g. with iconv), correct? Yes iconv will still be able to do such conversion (I will double check) >=20 > Sergey >=20 > P.S. "hy" =3D Hayastan =3D Armenia >=20 --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW1UweAAoJEGOJi9zxtz5axyIQAN3/YtGz8AdgbNjgWs79VCuo d9QNfaBbNB084VNf1ftfPMOWjuinb7HEDbY7imEnWuAQZNz69FJozcybedR2MGM4 EuIPLzF9pb6BT0BCuTk8QUVhdFyrAN3tDYaZvyC2no1KgfNNASVVqj5yTTIwnIST 8J+Pwu2WtR3AkE6aMaEpMPs9gmp6kyeE/YhTwS9rgdQLqfIxXbjbwJ//UUqyZAEy 9H0MINFEh7pgys/Rtlu5ciVUj+Vjv8odZW6v1WhnupK9UeY6IfhwwkugQtleiVCB Mutr7/T6tksmgrLRF84H9kgyu3p1BVEuTyf8slvH9sDFxIUP3kRDuTmbD2yAnbzb mQfb6mrXn8mmyWI6ZASUZOi4Ow+HV7/Qftl8ACK2q6bddYdE7maLBeTJcoKHS4s7 h/Vcp3sEwBA0/RskfXZ7gfSDOHiTBgjT4PoOhZoaoJMaod+BvKdSVHkKSMsl+yyh WIcMz6FT8arbibl3KC8OhZ6HwTBO/C6vZJnrbGn6mY1EJWrbMBgOtGX0XcQ6xAlj RymaCiO0m45wfcX5sgQTTPDrpb0MRliUacmh7D4dEtTdDtr6IOlUGRAgm1t9ixMb 2uyTF+5xz4RK0YBNOh3lo3Jd3W/gCEOvkQFP0QXYmK1HDSUplx3nCgCJYTv2fr3Z a9IaTG/UJm5fvlk6iCoM =ZXAj -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ-- From owner-freebsd-current@freebsd.org Tue Mar 1 08:04:27 2016 Return-Path: Delivered-To: freebsd-current@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 9F853ABF036 for ; Tue, 1 Mar 2016 08:04:27 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.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 7FCB812BD for ; Tue, 1 Mar 2016 08:04:27 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 7B495ABF032; Tue, 1 Mar 2016 08:04:27 +0000 (UTC) Delivered-To: current@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 624A7ABF030; Tue, 1 Mar 2016 08:04:27 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 EE66F12BB; Tue, 1 Mar 2016 08:04:26 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mail-wm0-x229.google.com with SMTP id n186so23583826wmn.1; Tue, 01 Mar 2016 00:04:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=UIzNdk1XIF77wf1ncZ5YVlmoJzxo7xAzSXi7WUf8epg=; b=qQU5g29ZBayZZd83E2LO6L744zzeEXbFWdZ6XmU15GfQs/kI8pfGCXoTPJCHKUow5a 2ytLL5fQE/HDSK+pNoU+cmW1jsS8EU+L+sTp58E/cLVl1f+uA7qn5IvbKhFF62v0oh+z y64DY7XUZFV3IZpK4/WIEjcZ1CGg8lFD/QYj5eU+YAPVkcTU9y2eQRj1n5oqaNXTzylp bYaZJ5jQYwrqwg1TPL+R3ucZgakEUvSy+yC8Ly9pFrSriforuCkysL3YF0XNR0XrxzSI lb57i1iA5lfUEf1lstibKNCejChWAi7vj/Kg+kA3n8gaS/m8fK7KZJPrFx2Yaz0Jp9g4 QQYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=UIzNdk1XIF77wf1ncZ5YVlmoJzxo7xAzSXi7WUf8epg=; b=MLPyXHYbOc7f5nAF17Rq43Q6qVd8+1DHfYEzr47HzKKN3y087HsS0qdzWEf0vaZiSh onxTNeC3clKHCJUr9R/DdCdQUiA2J9UZkllchYAJYJ3v1FKyMQ3dPY4j5myUqBGPZ8WA 4sFBMnjt9CEi3/0BbVLqvQqiXe8LlQK+QrOkOKC+o7UMF6AFqM6hLZmQnMVizeKN7uCA 77MdifcF8CgFQiLbuRFU11KbduBuU6Jt8NXUuBkuV3/HBjAwiTTC7dZWW+5k9JGmTVHW YEe28BB8KLUyi9pB7QeDPprrzNA8Kt80Dp0JF90Wp8zOjwQr5VNrhaslR2YW9Jf00zmi WuuQ== X-Gm-Message-State: AD7BkJK1vp5zQ5WCKsWmABuUm3BWn/3KjzwGOeg7yhU2mT6cdsMt5Z7sgO78XmvSgWLsBQ== X-Received: by 10.28.188.138 with SMTP id m132mr2183396wmf.29.1456819464574; Tue, 01 Mar 2016 00:04:24 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id n10sm28451393wjf.28.2016.03.01.00.04.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Mar 2016 00:04:23 -0800 (PST) Sender: Baptiste Daroussin Date: Tue, 1 Mar 2016 09:04:22 +0100 From: Baptiste Daroussin To: Andrey Chernov Cc: current@freebsd.org, hackers@freebsd.org Subject: Re: Dropping some locales/encodings? Message-ID: <20160301080422.GC31877@ivaldir.etoilebsd.net> References: <20160229232334.GG84995@ivaldir.etoilebsd.net> <56D502BD.9020704@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0vzXIDBeUiKkjNJl" Content-Disposition: inline In-Reply-To: <56D502BD.9020704@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 08:04:27 -0000 --0vzXIDBeUiKkjNJl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 01, 2016 at 05:47:25AM +0300, Andrey Chernov wrote: > On 01.03.2016 2:23, Baptiste Daroussin wrote: > > Hi all, > >=20 > > I have updated few month ago the locales to cldr v27.0.1. I would like = to > > simplify the generation of those locales from cldr to POSIX locales tha= t we do > > provides. > >=20 > > I can properly generate almost any of the said locales/encodings but a = few that > > I would like to remove (provided that unicode version are available) > >=20 > > Here is the list of locales/encodings: > >=20 > > be_BY.CP1251 >=20 > CP1251 is Windows native (single characters mode) and widely used to > represent Cyrillic: Russian, Bulgarian, Serbian, Ukrainian, Belarusian > (i.e. be_BY), Macedonian. IMHO it will be better to not remove it to > make easy handling of native encoded texts comes from Windows. >=20 > Don't know about other mentioned. >=20 Ok Given the replies I will then change the way I'm looking at it and see i= f I can provide static version of those instead of removing and generate all ot= hers =66rom cldr. Thanks for the quick replies Best regards, Bapt --0vzXIDBeUiKkjNJl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW1U0GAAoJEGOJi9zxtz5arNcP/3KiOqdhV24KOAHSW5FzmBEJ k870yi0T2Scymsj+QOTQQgHHyZIvIgTIzihZksdOA3Y8IGuZsGUzYwUnzpDbNNEz XuOkMKp4g+OuknebqOO8kKDTpKFX0l18Rcv595xoyKqr0XCHiaS3jytlLsn+JKfg UdE3h1PShShSxGIGf9pt8hVTAS96wgYPAMRwqyEsN9P3zQMHubQfl2FUb4cGXIn+ GjDH5ECTD7QhCUEH+hSfsQNwMWBl0P9PDCnU19z1iBkdG/FJ7EezDunPjGfMqAGs oc4G78wpGAP4iHbUSa7Ks7AmE17zLtP352B6xevDW+gyGlYSqaDjpPK0KIyNN7Nt h1rhiZfB/Y0MfUn3gkoXFLnz9hPObMiYrsTuDMP1lmfltNjLEGt2DcsZF0VbV+RI iZArpG+QA6XZVOwfTrBHoU/J4rrh1u5Pbx6AlkcNvSBtu3WfEI23znkkwEtlftC5 dZnwlsovlwFX4MftPQOACXRxRrhBJh/KdXYKnXmIjOgmP2kAzdeCdAHS96YV+N7H 6H85tlloFb8S6X7xeoll1g0XEGUKBaY1Sz9e0OhplwArzl6zUUig3jopEPuigaNv uG8aAxIZoFzrVXmbOPHRHMndKX15xTzDG7H8rOUtQLJMuR1dkAswCsK9kvuEwNDR okYZpTjNszRcBYfutu8l =5E1r -----END PGP SIGNATURE----- --0vzXIDBeUiKkjNJl-- From owner-freebsd-current@freebsd.org Tue Mar 1 09:26:00 2016 Return-Path: Delivered-To: freebsd-current@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 B0B2AABFCC0 for ; Tue, 1 Mar 2016 09:26:00 +0000 (UTC) (envelope-from daniel@digsys.bg) 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 9E74E1529 for ; Tue, 1 Mar 2016 09:26:00 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: by mailman.ysv.freebsd.org (Postfix) id 9B513ABFCBF; Tue, 1 Mar 2016 09:26:00 +0000 (UTC) Delivered-To: current@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 9AD2BABFCBD; Tue, 1 Mar 2016 09:26:00 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.21.123]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smtp-sofia.digsys.bg", Issuer "Digital Systems Operational CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0898F1528; Tue, 1 Mar 2016 09:25:59 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from [193.68.6.100] ([193.68.6.100]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.9/8.14.9) with ESMTP id u218wY2o086782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Mar 2016 10:58:35 +0200 (EET) (envelope-from daniel@digsys.bg) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: Dropping some locales/encodings? From: Daniel Kalchev In-Reply-To: <20160301034544.GH52633@dendrobates.araler.com> Date: Tue, 1 Mar 2016 10:58:37 +0200 Cc: Andrey Chernov , Baptiste Daroussin , current@freebsd.org, hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160229232334.GG84995@ivaldir.etoilebsd.net> <56D502BD.9020704@freebsd.org> <20160301034544.GH52633@dendrobates.araler.com> To: Sergey Manucharian X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 09:26:00 -0000 > On 1.03.2016 =D0=B3., at 5:45, Sergey Manucharian = wrote: >=20 > Excerpts from Andrey Chernov's message from Tue 01-Mar-16 05:47: >> On 01.03.2016 2:23, Baptiste Daroussin wrote: >>>=20 >>> I can properly generate almost any of the said locales/encodings but = a few that >>> I would like to remove (provided that unicode version are available) >>>=20 >>> Here is the list of locales/encodings: >>>=20 >>> be_BY.CP1251 >>=20 >> CP1251 is Windows native (single characters mode) and widely used to >> represent Cyrillic: Russian, Bulgarian, Serbian, Ukrainian, = Belarusian >> (i.e. be_BY), Macedonian. IMHO it will be better to not remove it to >> make easy handling of native encoded texts comes from Windows. >>=20 >=20 > I agree with Andrey that CP1251 is needed as one of major Cyrillic > encodings. >=20 > Not sure how the locale existence/absence effects that. Definitely = nobody > uses it as a locale for more than a decade. >=20 I use daily bg_BG.CP1251 on a lot of workstations, primarily to handle = old text documents and source code that contains pre-UTF text. I could = imagine similar use case for be_BY.CP1251. What benefit does it bring to remove an already existing locale? Daniel= From owner-freebsd-current@freebsd.org Tue Mar 1 09:54:55 2016 Return-Path: Delivered-To: freebsd-current@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 B160DABDBA6 for ; Tue, 1 Mar 2016 09:54:55 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.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 8D6DD1CCC for ; Tue, 1 Mar 2016 09:54:55 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8B21AABDBA4; Tue, 1 Mar 2016 09:54:55 +0000 (UTC) Delivered-To: current@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 8A999ABDBA3; Tue, 1 Mar 2016 09:54:55 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 2E9F01CCB; Tue, 1 Mar 2016 09:54:55 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id n186so27930026wmn.1; Tue, 01 Mar 2016 01:54:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=gojvr354T/tpQUAzo3aL11a/90trGHsBjNU+uTl8Uzw=; b=G1IhgThmGBrLK4ADYsdSfsxomjmHpZvAkHiKqx/Y9vtAVx/oJMotj9KAyjhc7K0HgM Jcp7+jGpx8u8lvg9otRO8n/0tGVmKHSU1074wvY+Jl+WNYuQYBC73B/3jl6Hu1jmWjiU 9T4cusnl20t3gCSQSlcGcATStPbJSHe0l3hZyEcFwd7qoaxe+E59Wyvph0SuQ/R3C31N DlInACsQ/UnrPocUEV4x26Ltu9+/rntvCTcS8FPiz9RWM9AbEZWF6PodEiZ/eu17/Aqv a3CvH5YHVKx3ZGOz1Ni5/LlG9LwJ1Fo5LC2urljIoiPDJ6n89Qs4sdtpZvvlq1NxFzFX Q7SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=gojvr354T/tpQUAzo3aL11a/90trGHsBjNU+uTl8Uzw=; b=L8bgR8+P+xf06gRywmYqkvMoKCg0MRyvkPvE8NdjuyPQFjbhOqMtFR5BM8qQv6KLs3 fFtiSzX6VNK4xfsauINBnWWAxH/d3w6JFCSSHz6rUb4DusOPl4QJT2gJQ7jgx7dth7Ba ASr47hfACo86n9hTzXW2mPcc0MgkjdeTN7DrzC8zWg42LZLDAUuP9Gm6V0gbAUVRR5rK EzahbpiXHVmg7ByV/Xwv/AFma2RlYakumc3MX4tXEl617QHhdD/teCx2gstN3uU473Jf 7EvtQ05XronEysjiS1bYY36QwBxik9ZdYEGc10o+kdNLj8k5hCWzuceKnDnEUNIKhpwG fegw== X-Gm-Message-State: AD7BkJLHeKP262aID5qDfYcIlcOl482eP1a+EO47IV3PoouMHHA6kaqkXxB6TMTwrVS0mg== X-Received: by 10.194.83.42 with SMTP id n10mr19785990wjy.20.1456826093662; Tue, 01 Mar 2016 01:54:53 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id j10sm30028280wjb.46.2016.03.01.01.54.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Mar 2016 01:54:52 -0800 (PST) Sender: Baptiste Daroussin Date: Tue, 1 Mar 2016 10:54:50 +0100 From: Baptiste Daroussin To: Daniel Kalchev Cc: Sergey Manucharian , Andrey Chernov , current@freebsd.org, hackers@freebsd.org Subject: Re: Dropping some locales/encodings? Message-ID: <20160301095450.GD31877@ivaldir.etoilebsd.net> References: <20160229232334.GG84995@ivaldir.etoilebsd.net> <56D502BD.9020704@freebsd.org> <20160301034544.GH52633@dendrobates.araler.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zS7rBR6csb6tI2e1" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 09:54:55 -0000 --zS7rBR6csb6tI2e1 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 01, 2016 at 10:58:37AM +0200, Daniel Kalchev wrote: >=20 > > On 1.03.2016 =D0=B3., at 5:45, Sergey Manucharian wrot= e: > >=20 > > Excerpts from Andrey Chernov's message from Tue 01-Mar-16 05:47: > >> On 01.03.2016 2:23, Baptiste Daroussin wrote: > >>>=20 > >>> I can properly generate almost any of the said locales/encodings but = a few that > >>> I would like to remove (provided that unicode version are available) > >>>=20 > >>> Here is the list of locales/encodings: > >>>=20 > >>> be_BY.CP1251 > >>=20 > >> CP1251 is Windows native (single characters mode) and widely used to > >> represent Cyrillic: Russian, Bulgarian, Serbian, Ukrainian, Belarusian > >> (i.e. be_BY), Macedonian. IMHO it will be better to not remove it to > >> make easy handling of native encoded texts comes from Windows. > >>=20 > >=20 > > I agree with Andrey that CP1251 is needed as one of major Cyrillic > > encodings. > >=20 > > Not sure how the locale existence/absence effects that. Definitely nobo= dy > > uses it as a locale for more than a decade. > >=20 >=20 > I use daily bg_BG.CP1251 on a lot of workstations, primarily to handle ol= d text documents and source code that contains pre-UTF text. I could imagin= e similar use case for be_BY.CP1251. >=20 > What benefit does it bring to remove an already existing locale? The benefit is the fact we have no source for those and collation for one a= re wrong for those. (We have added proper collation support in head). But given the feedback I got I will provide them as static (aka non evolving anymore) while others would get refreshed so no locales will be lost and th= at will allow us to continue refreshing others. Best regards, Bapt --zS7rBR6csb6tI2e1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW1WbOAAoJEGOJi9zxtz5ax6IP/2gKSdN3AUAwtiYlpgEzYwa+ YvmqWV+r62pQB8QxHJ1EvlgTzaCP5p0nnbC31kAwJ47k6FYKhgsBUXhW6cyfsZhu lJXh5+Ellpu2ITYq/Ob4R+hIzOS3ZlmdIL0XkcSWbCsGuVbM9DzDRqqB4n9MZWYh F8fX1EG4wWAr8eABumzgr03klFU+sOR1QROCavNWPULsnn//WyIKuk8eN2qkbzu+ 6my7MrX7v+Snb6AERjRG0x2NZtUrNfvv2zNurQBxRKMOkvjPhMKxJ7+sG8RLozUw FlyTkRKRPqWa06wh/Xp6R5m3jFpfPs/8wxGAAB3YbxB1K+ovGdNoX7+AzNtdzXTC YhTcDppCXllZauEHYiHclBezznyj37BXOulDpfFtrQmkZ4eXROC/9i1afAZBon4i ++9QOYwXE36NRhMzBUAd1T8qaJtYcdgRdYpwYEgDq8pzxpC55wqX1eX+S2jQ+vj6 3bQA6g0KzquB1tAneL+u/Szyajx0p9oMBKPx23mJlBmJy4VTTcKElzDbyu2tsqKv 8DDqqy6K8ka5x+6fTdbdwECCMYF6Qcd6YMc97R/ZPMjzFothn1RugUNdEpALCwzv P8GRHgfTa4BMfcZBuFRY249YqTFbZ0sHzwvy/PZrrXXi65c/N2v88P9kMGD5zWru I8ZtTBXeA3K+7s4w4F34 =w4w9 -----END PGP SIGNATURE----- --zS7rBR6csb6tI2e1-- From owner-freebsd-current@freebsd.org Tue Mar 1 13:51:21 2016 Return-Path: Delivered-To: freebsd-current@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 F2FA1ABF296 for ; Tue, 1 Mar 2016 13:51:21 +0000 (UTC) (envelope-from Scoobi_doo@yahoo.com) Received: from nm46-vm10.bullet.mail.bf1.yahoo.com (nm46-vm10.bullet.mail.bf1.yahoo.com [216.109.114.203]) (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 B85D613D4 for ; Tue, 1 Mar 2016 13:51:21 +0000 (UTC) (envelope-from Scoobi_doo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1456840274; bh=Eg9tMZJLoqEbis6UN/0LCxVBuAzcpbFgj2NEaF0FPd0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=DPbwaca/8dSetwnsTu6SXt7F3ELQtoFwtqnEyw0NX/8wZ8V5qU5pd9ZKS6Bk4S8LNk9bgroSs6EZHipxfTZEqEHmb5ELgbp2l23DkNDoGI9Y4D2FOFVNc9k7CBKiyzZWitB31iKyCHP7gqgKqNICn+sIxlrkCOOVdEZjKLlovpv6JUF01zH+WsgMkSjitRgsixW2Zq2uisA967u8GJOZxC0uRs5wfAUFm7y9oFVzOX4gwHC0DsMh+xzGR0YFpvU5WL4HU9S7i8nUU8wzIGkQ4RoI+YqdtIV4f3DIBKKb3hGSr6aZDWP3RFqzuQtqZ4dLltA9XfXdTSKD6co7ZzlqrQ== Received: from [98.139.215.143] by nm46.bullet.mail.bf1.yahoo.com with NNFMP; 01 Mar 2016 13:51:14 -0000 Received: from [68.142.230.70] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 01 Mar 2016 13:51:14 -0000 Received: from [127.0.0.1] by smtp227.mail.bf1.yahoo.com with NNFMP; 01 Mar 2016 13:51:14 -0000 X-Yahoo-Newman-Id: 544311.2827.bm@smtp227.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: IzVyGTMVM1kMwY0ixrlD7fhFYFZW0IaQVLJDAJNrLeGkOQa WwXaIILlAh6fhR6RhaQSEYtT_jUPwy6O3SQVsZHDuej_A6QyS1zVme.HXp4X E92TEnch5sg_hA7w1TBKy9erTyxKTidvZhUFT4w.7VYhBIly77ZQAaJ_wegX dCaoNGfh_LpAe1Nt089054QXwumZrre80FsOn0Jh7yHblaLHyyd6nr71F6Vc uYQjsMoYdEqu8x2Sm1AX46F6eXLpGxdds4fioyBx79bt9baRFG_SiaFB4a5R 8BUhdGRcRDXrLqSnqppuxP8F9pY65LrtXZ54ZGD2qyDv7WPKXCXmPm6VLCvp 3L0zT11h9A.V8GXKJYnBRLYMyCaLJt0P12L2EIzl4teE5LmzzKNNd2Js39dW 48pc5KSjdxapI2FGVPScbt.huniivYGv.2Zo6g24DesEiV94UllK6Gmo._E8 TnZqu3uBREdEUou80zL._nwrggNo0x0aRO6Pn_sVbu08MqSGwGOm60myaSbI Rh_SQLIHsOvwuaxn.f_ByVoVTZMwZVzXIDQ-- X-Yahoo-SMTP: 9sPoSQ2swBBlERuQ.0vs8XLc_MeClW0- Subject: Re: Touchscreen support (was Re: new computer, strange usb messages at boot) To: "Sergey V. Dyatko" References: <20160220051951.GA47875@lrosenman-dell.lerctr.org> <20160220120401.GA91220@kib.kiev.ua> <20160220122416.GA1026@lrosenman-dell.lerctr.org> <2575cfd714188f7ffbc873cb5d87cc97@thebighonker.lerctr.org> <56CA6F67.4000001@yahoo.com> <56CAB4A7.8080604@selasky.org> <56CB39B0.3020307@yahoo.com> <56CB3C74.7050103@selasky.org> <20160301083006.671d3987@laptop.minsk.domain> Cc: Hans Petter Selasky , freebsd-current@freebsd.org From: Anthony Jenkins Message-ID: <56D59E51.4040409@yahoo.com> Date: Tue, 1 Mar 2016 08:51:13 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160301083006.671d3987@laptop.minsk.domain> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 13:51:22 -0000 On 03/01/2016 12:30 AM, Sergey V. Dyatko wrote: > On Mon, 22 Feb 2016 17:51:00 +0100 > Hans Petter Selasky wrote:=20 > >> On 02/22/16 17:39, Anthony Jenkins wrote: >>> >>> On 02/22/2016 02:11 AM, Hans Petter Selasky wrote: =20 >>>> On 02/22/16 03:16, Anthony Jenkins wrote: =20 >>>>> Yes. I have an eGalax touchscreen and it's doing the same thing. T= he >>>>> number of items it's reporting is 256 (according to my preliminary >>>>> debugging), causing the warning. I think these things are a specia= l >>>>> subclass of HID for multitouch touchscreens which we don't support >>>>> (yet). =20 >>>> /usr/ports/multimedia/webcamd will most likely attach if invoked >>>> manually, to this device and provide an event device for you! >>>> >>>> --HPS =20 >>> Okay that's /amazing/, and not at all intuitive! I mean I'd expect >>> multimedia/webcamd to only attach to "video" devices, but lo and beho= ld >>> I get a /dev/input/event0 device which spits out gibberish when >>> cat(1)'ed and I touch the screen! >>> >>> My intentions were to port Linux's hid-multitouch device in whole to >>> FreeBSD (it's what attaches to my eGalax device and probably to OP's >>> touchscreen device) and add support for the device to moused(8), but >>> it's not very high on my priority list... >>> =20 >> Hi, >> >> If you apply these patches, will work with your X-org :-) >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D196678 >> > wow... > Thanks for your work :)=20 > > Yesterday I update -CURRENT on my lenovo z400 touch ( r296180), after > suspend-resume I spotted that is my usb mouse didn't work (touchpad wor= ks as > before) > I had the feeling that I read something about hid_get_item: Number of > items(256) truncated to 255 on ML, so I'm here.=20 > > What I do:=20 > laptop# webcamd -l > Available device(s): > .... > webcamd [-d ugen0.2] -N Synaptics-Large-Touch-Screen-SYNAPTICS -S unkno= wn -M 0 > ... > Show webcamd usage: > webcamd -h > laptop# webcamd -N Synaptics-Large-Touch-Screen-SYNAPTICS -S unknown -= M 0 > Attached to ugen0.2[0] > Creating /dev/input/event0 > > after that I reconnect my mouse and 'it works' (c)=20 > How I can do this automatically right? I got my touchscreen working with the multimedia/webcamd and x11-drivers/xf86-input-evdev ports and an entry in /usr/local/etc/devd/webcamd.conf for my eGalax USB touchscreen device.=20 In webcamd.conf, you can copy the section # Generic USB input devices. notify 100 { match "system" "USB"; match "subsystem" "INTERFACE"; match "type" "ATTACH"; match "intclass" "0x03"; # # Limit HID device attach to Wacom Devices # else webcamd might attach to your keyboard # and mouse # match "vendor" "0x056a"; action "/usr/local/etc/rc.d/webcamd start $cdev $interface"; }; to a new section, changing the 'match "vendor" line to match the USB VendorID of your input device and possibly adding a 'match "product" line= : $ sudo usbconfig -d ugen1.2 dump_device_desc | grep 'id\(Vendor\|Product\= )' idVendor =3D 0x0eef idProduct =3D 0xa119 # My eGalax Touchscreen device. notify 100 { match "system" "USB"; match "subsystem" "INTERFACE"; match "type" "ATTACH"; match "intclass" "0x03"; match "vendor" "0x0eef"; match "product" "0xa119"; action "/usr/local/etc/rc.d/webcamd start $cdev $interface"; }; replacing "ugen1.2" above with your "ugen0.2" as well as the vendor and product values. --=20 Anthony Jenkins From owner-freebsd-current@freebsd.org Tue Mar 1 14:22:26 2016 Return-Path: Delivered-To: freebsd-current@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 435A1ABFDEF for ; Tue, 1 Mar 2016 14:22:26 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 18FCD12AA for ; Tue, 1 Mar 2016 14:22:26 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks CA" (verified OK)) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id BA12D8 for ; Tue, 1 Mar 2016 09:22:23 -0500 (EST) To: freebsd-current From: Michael Butler Subject: continuous stream of writes? Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492 Message-ID: <56D5A59E.8040608@protected-networks.net> Date: Tue, 1 Mar 2016 09:22:22 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 14:22:26 -0000 On an otherwise idle machine, I now see a continuous stream of writes to disk. I've only noted this over the last couple of weeks but this will not be welcome behaviour on an SSD .. How do I find the source of these writes? imb@toshi:/home/imb> iostat 10 tty ada0 cd0 pass0 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 992 58.53 229 13.10 0.00 0 0.00 0.37 0 0.00 13 2 7 1 78 0 23 30.82 12 0.36 0.00 0 0.00 0.00 0 0.00 2 0 4 0 94 0 8 31.38 12 0.37 0.00 0 0.00 0.00 0 0.00 0 0 4 0 96 0 8 31.75 11 0.34 0.00 0 0.00 0.00 0 0.00 3 0 3 0 94 0 8 31.82 11 0.35 0.00 0 0.00 0.00 0 0.00 1 0 3 0 96 0 8 31.76 12 0.36 0.00 0 0.00 0.00 0 0.00 0 0 3 0 96 0 8 31.75 11 0.35 0.00 0 0.00 0.00 0 0.00 1 0 4 0 95 0 8 31.55 12 0.38 0.00 0 0.00 0.00 0 0.00 1 0 3 0 96 From owner-freebsd-current@freebsd.org Tue Mar 1 14:29:58 2016 Return-Path: Delivered-To: freebsd-current@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 BFB14ABD04D for ; Tue, 1 Mar 2016 14:29:58 +0000 (UTC) (envelope-from mma@semihalf.com) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::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 78CE71726 for ; Tue, 1 Mar 2016 14:29:58 +0000 (UTC) (envelope-from mma@semihalf.com) Received: by mail-ig0-x22c.google.com with SMTP id xg9so18953248igb.1 for ; Tue, 01 Mar 2016 06:29:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=cbcuSsw4UagCb94PwVtYkWrGmECTWQpWuzxswFmB58w=; b=GBIrLdc5FxqpRmNXDKlh20R96bFuOzR5h1Z0j2BhRweSbgBS8Zl3cHAkzluBFDbsam eyHVU/6opCKqzEBjagV6kqBBt1bLXO2RGNaVAFzD9Edr+9j6lCCF4nCDtFbG/5sjULLu ri2bAF/hvHiJxMgj1GBcoRZqd44JslkdBXatIt/YYbNx8I6Q+ZlNIZiXsCb6NlZW5DVd vs2pYh5tA5645zPuabhCZnt2MJkaKbG2rk6L0ClLxf1BdDqilxuTa6FZODND/QyQiaY5 ekPAS7V5iwxNtETengbyB3tvywimGmt9eWJdpjxi3Rtf7oLPgT26g+w+j/AE1WTh7DT7 rcSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=cbcuSsw4UagCb94PwVtYkWrGmECTWQpWuzxswFmB58w=; b=DzSzu1q0WNpDIGW7a0c+p+R1CwkNXSXM+n6n1SKb0zkVaIi2n+PTeqTw+MW86DtWN5 1kRQ/6l/U6X5cKiLbC8C/PgLbxhe+NX0BRtBpsW37vTZSBrrB3JqpFFSURtvplRvkyoJ Dg+d7D4YpW4majErH/KDmXXt5e9qSjZeMrgwlsEvNfFtG5opv0YwI9hqLDdUN5CIeWnX agfRXzQe56p/JFUMzXxdvDCPe8shm5SaaaVXhfrEmTUhk9QK+iKiak80RBZpCHRMTjsV TPkZAwDlXBUwinYAhY5IPx+m8G+w8c2PLQNEm965fEn78r8rb9v2g472/RgQZ0hAKjnD 07hw== X-Gm-Message-State: AD7BkJLnYXWo7+qnGgP/d142zf6HN1C5pU24qBNDeGuNBxBDGAmkhnCIuWjQZ5lwC82tCFX7/oNrYt9myxq9TA== MIME-Version: 1.0 X-Received: by 10.50.20.98 with SMTP id m2mr4014181ige.9.1456842597666; Tue, 01 Mar 2016 06:29:57 -0800 (PST) Received: by 10.107.4.8 with HTTP; Tue, 1 Mar 2016 06:29:57 -0800 (PST) Date: Tue, 1 Mar 2016 15:29:57 +0100 Message-ID: Subject: Testing an importing OF PCI implementations patch From: Marcin Mazurek To: freebsd-ppc@freebsd.org, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org Content-Type: multipart/mixed; boundary=047d7bd76bea87df0b052cfd99e4 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 14:29:58 -0000 --047d7bd76bea87df0b052cfd99e4 Content-Type: text/plain; charset=UTF-8 Hello, I am looking for a testers for a patch to import portions of the PowerPC and Sparc64 OF PCI implementations. This extracts common code from PPC's and Sparc64's ofw_pci and moves that to general dev/ofw_pci files. It is currently building successfully on every architecture. I tested it on my arm machine and checked it worked. Unfortunately I do not have any powerpc and sparc hardware to test it on. I tried to use it inside qemu, however I could not run the FBSD on Sparc64 and PPC (I used a "qemu recipes" from the freebsd wiki page). I would like it if this could be tested on these platforms using this code to check if it does not break them. This is very essential patch for me, because it is blocking my other pending commits and I would be very grateful for testing it. Review of this code is here: https://reviews.freebsd.org/D4879 Any comments and feedback are welcome. Thanks, Marcin --047d7bd76bea87df0b052cfd99e4 Content-Type: text/plain; charset=US-ASCII; name="ofw_extract_code.diff" Content-Disposition: attachment; filename="ofw_extract_code.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_il9i6ngp0 ZGlmZiAtLWdpdCBhL3N5cy9jb25mL2ZpbGVzLmFybSBiL3N5cy9jb25mL2ZpbGVzLmFybQppbmRl eCAyNDA3NjE2Li4wNzcwMjYxIDEwMDY0NAotLS0gYS9zeXMvY29uZi9maWxlcy5hcm0KKysrIGIv c3lzL2NvbmYvZmlsZXMuYXJtCkBAIC0xMDMsNiArMTAzLDcgQEAgZGV2L2h3cG1jL2h3cG1jX2Fy bS5jCQlvcHRpb25hbAlod3BtYwogZGV2L2h3cG1jL2h3cG1jX2FybXY3LmMJCW9wdGlvbmFsCWh3 cG1jIGFybXY2CiBkZXYvaWljYnVzL3R3c2kvdHdzaS5jCQlvcHRpb25hbAl0d3NpCiBkZXYvb2Z3 L29md19jcHUuYwkJb3B0aW9uYWwJZmR0CitkZXYvb2Z3L29md19wY2kuYwkJb3B0aW9uYWwgCXBj aSBmZHQKIGRldi9wc2NpL3BzY2kuYwkJCW9wdGlvbmFsCXBzY2kKIGRldi9wc2NpL3BzY2lfYXJt LlMJCW9wdGlvbmFsCXBzY2kKIGRldi9zeXNjb25zL3NjZ2Zicm5kci5jCQlvcHRpb25hbAlzYwpk aWZmIC0tZ2l0IGEvc3lzL2NvbmYvZmlsZXMuYXJtNjQgYi9zeXMvY29uZi9maWxlcy5hcm02NApp bmRleCA4ZjVmMTBhLi5hMzJmNjA5IDEwMDY0NAotLS0gYS9zeXMvY29uZi9maWxlcy5hcm02NAor KysgYi9zeXMvY29uZi9maWxlcy5hcm02NApAQCAtNjYsNiArNjYsNyBAQCBkZXYvaHdwbWMvaHdw bWNfYXJtNjRfbWQuYwlvcHRpb25hbAlod3BtYwogZGV2L21tYy9ob3N0L2R3bW1jLmMJCW9wdGlv bmFsCWR3bW1jCiBkZXYvbW1jL2hvc3QvZHdtbWNfaGlzaS5jCW9wdGlvbmFsCWR3bW1jIHNvY19o aXNpX2hpNjIyMAogZGV2L29mdy9vZndfY3B1LmMJCW9wdGlvbmFsCWZkdAorZGV2L29mdy9vZndf cGNpLmMJCW9wdGlvbmFsCXBjaSBmZHQKIGRldi9wY2kvcGNpX2hvc3RfZ2VuZXJpYy5jCW9wdGlv bmFsCXBjaSBmZHQKIGRldi9wc2NpL3BzY2kuYwkJCW9wdGlvbmFsCXBzY2kKIGRldi9wc2NpL3Bz Y2lfYXJtNjQuUwkJb3B0aW9uYWwJcHNjaQpkaWZmIC0tZ2l0IGEvc3lzL2NvbmYvZmlsZXMuaTM4 NiBiL3N5cy9jb25mL2ZpbGVzLmkzODYKaW5kZXggYjA2NTE2NS4uNTdiYmY1NyAxMDA2NDQKLS0t IGEvc3lzL2NvbmYvZmlsZXMuaTM4NgorKysgYi9zeXMvY29uZi9maWxlcy5pMzg2CkBAIC0yODUs NiArMjg1LDcgQEAgZGV2L252bWUvbnZtZV9zeXNjdGwuYwkJb3B0aW9uYWwgbnZtZQogZGV2L252 bWUvbnZtZV90ZXN0LmMJCW9wdGlvbmFsIG52bWUKIGRldi9udm1lL252bWVfdXRpbC5jCQlvcHRp b25hbCBudm1lCiBkZXYvbnZyYW0vbnZyYW0uYwkJb3B0aW9uYWwgbnZyYW0gaXNhCitkZXYvb2Z3 L29md19wY2kuYwkJb3B0aW9uYWwgcGNpIGZkdAogZGV2L3BjZi9wY2ZfaXNhLmMJCW9wdGlvbmFs IHBjZgogZGV2L3JhbmRvbS9pdnkuYwkJb3B0aW9uYWwgcmRyYW5kX3JuZwogZGV2L3JhbmRvbS9u ZWhlbWlhaC5jCQlvcHRpb25hbCBwYWRsb2NrX3JuZwpkaWZmIC0tZ2l0IGEvc3lzL2NvbmYvZmls ZXMubWlwcyBiL3N5cy9jb25mL2ZpbGVzLm1pcHMKaW5kZXggOTFkNTNhYS4uNjczMzA4MCAxMDA2 NDQKLS0tIGEvc3lzL2NvbmYvZmlsZXMubWlwcworKysgYi9zeXMvY29uZi9maWxlcy5taXBzCkBA IC05MiwzICs5Miw2IEBAIGRldi9udnJhbTJlbnYvbnZyYW0yZW52LmMJCW9wdGlvbmFsCW52cmFt MmVudgogZGV2L2h3cG1jL2h3cG1jX21pcHMuYwkJCW9wdGlvbmFsCWh3cG1jCiBkZXYvaHdwbWMv aHdwbWNfbWlwczI0ay5jCQlvcHRpb25hbAlod3BtY19taXBzMjRrCiBkZXYvaHdwbWMvaHdwbWNf bWlwczc0ay5jCQlvcHRpb25hbAlod3BtY19taXBzNzRrCisKKyMgb2Z3IHN1cHBvcnQKK2Rldi9v Zncvb2Z3X3BjaS5jCQkJb3B0aW9uYWwgCXBjaSBmZHQKZGlmZiAtLWdpdCBhL3N5cy9jb25mL2Zp bGVzLnBvd2VycGMgYi9zeXMvY29uZi9maWxlcy5wb3dlcnBjCmluZGV4IDBhMWU3YzEuLmJkZTQ4 YTMgMTAwNjQ0Ci0tLSBhL3N5cy9jb25mL2ZpbGVzLnBvd2VycGMKKysrIGIvc3lzL2NvbmYvZmls ZXMucG93ZXJwYwpAQCAtNTcsNiArNTcsNyBAQCBkZXYvb2Z3L29md19jb25zb2xlLmMJCW9wdGlv bmFsCWFpbQogZGV2L29mdy9vZndfZGlzay5jCQlvcHRpb25hbAlvZndkIGFpbQogZGV2L29mdy9v ZndfaWljYnVzLmMJCW9wdGlvbmFsCWlpY2J1cyBhaW0KIGRldi9vZncvb2Z3YnVzLmMJCW9wdGlv bmFsCWFpbSB8IGZkdAorZGV2L29mdy9vZndfcGNpLmMJCW9wdGlvbmFsIAlwY2kgZmR0CiBkZXYv b2Z3L29md19zdGFuZGFyZC5jCQlvcHRpb25hbAlhaW0gcG93ZXJwYwogZGV2L29mdy9vZndfc3Vi ci5jCQlvcHRpb25hbAlhaW0gcG93ZXJwYwogZGV2L3Bvd2VybWFjX252cmFtL3Bvd2VybWFjX252 cmFtLmMgb3B0aW9uYWwJcG93ZXJtYWNfbnZyYW0gcG93ZXJtYWMKQEAgLTE0NSw3ICsxNDYsNiBA QCBwb3dlcnBjL21wYzg1eHgvcGNpX21wYzg1eHguYwlvcHRpb25hbAlwY2kgbXBjODV4eCB8IHBj aSBxb3JpcV9kcGFhCiBwb3dlcnBjL21wYzg1eHgvcGNpX21wYzg1eHhfcGNpYi5jCW9wdGlvbmFs CXBjaSBtcGM4NXh4IHwgcGNpIHFvcmlxX2RwYWEKIHBvd2VycGMvbXBjODV4eC9xb3JpcV9ncGlv LmMJb3B0aW9uYWwJbXBjODV4eCBncGlvIHwgcW9yaXFfZHBhYSBncGlvCiBwb3dlcnBjL29mdy9v ZndfbWFjaGRlcC5jCXN0YW5kYXJkCi1wb3dlcnBjL29mdy9vZndfcGNpLmMJCW9wdGlvbmFsCXBj aQogcG93ZXJwYy9vZncvb2Z3X3BjaWJ1cy5jCW9wdGlvbmFsCXBjaQogcG93ZXJwYy9vZncvb2Z3 X3BjaWJfcGNpLmMJb3B0aW9uYWwJcGNpCiBwb3dlcnBjL29mdy9vZndfcmVhbC5jCQlvcHRpb25h bAlhaW0KZGlmZiAtLWdpdCBhL3N5cy9jb25mL2ZpbGVzLnNwYXJjNjQgYi9zeXMvY29uZi9maWxl cy5zcGFyYzY0CmluZGV4IDg0ZjIzZmYuLmM3YzEzOGEgMTAwNjQ0Ci0tLSBhL3N5cy9jb25mL2Zp bGVzLnNwYXJjNjQKKysrIGIvc3lzL2NvbmYvZmlsZXMuc3BhcmM2NApAQCAtNDcsNiArNDcsNyBA QCBkZXYvb2Z3L29md19idXNfaWYubQkJc3RhbmRhcmQKIGRldi9vZncvb2Z3X2J1c19zdWJyLmMJ CXN0YW5kYXJkCiBkZXYvb2Z3L29md19jb25zb2xlLmMJCW9wdGlvbmFsCW9md19jb25zb2xlCiBk ZXYvb2Z3L29md19pZi5tCQlzdGFuZGFyZAorZGV2L29mdy9vZndfcGNpLmMJCW9wdGlvbmFsCXBj aQogZGV2L29mdy9vZndfc3RhbmRhcmQuYwkJc3RhbmRhcmQKIGRldi9vZncvb3BlbmZpcm0uYwkJ c3RhbmRhcmQKIGRldi9vZncvb3BlbmZpcm1pby5jCQlzdGFuZGFyZApAQCAtODIsNyArODMsNyBA QCBzcGFyYzY0L2lzYS9pc2FfZG1hLmMJCW9wdGlvbmFsCWlzYQogc3BhcmM2NC9pc2Evb2Z3X2lz YS5jCQlvcHRpb25hbAllYnVzIHwgaXNhCiBzcGFyYzY0L3BjaS9hcGIuYwkJb3B0aW9uYWwJcGNp CiBzcGFyYzY0L3BjaS9maXJlLmMJCW9wdGlvbmFsCXBjaQotc3BhcmM2NC9wY2kvb2Z3X3BjaS5j CQlvcHRpb25hbAlwY2kKK3NwYXJjNjQvcGNpL3NwYXJjNjRfb2Z3X3BjaS5jCW9wdGlvbmFsCXBj aQogc3BhcmM2NC9wY2kvb2Z3X3BjaWIuYwkJb3B0aW9uYWwJcGNpCiBzcGFyYzY0L3BjaS9vZndf cGNpYl9zdWJyLmMJb3B0aW9uYWwJcGNpCiBzcGFyYzY0L3BjaS9vZndfcGNpYnVzLmMJb3B0aW9u YWwJcGNpCmRpZmYgLS1naXQgYS9zeXMvZGV2L29mdy9vZndfcGNpLmMgYi9zeXMvZGV2L29mdy9v ZndfcGNpLmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uODg1MmNkNwotLS0g L2Rldi9udWxsCisrKyBiL3N5cy9kZXYvb2Z3L29md19wY2kuYwpAQCAtMCwwICsxLDYzNSBAQAor LyotCisgKiBDb3B5cmlnaHQgKGMpIDIwMTEgTmF0aGFuIFdoaXRlaG9ybgorICogQWxsIHJpZ2h0 cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQg YmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1p dHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworICogYXJlIG1ldDoK KyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJv dmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0 aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCisgKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5 IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0 aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRo ZQorICogICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdp dGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZ IFRIRSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECisgKiBBTlkgRVhQUkVT UyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBU SEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1Mg Rk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisgKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5U IFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQorICogRk9SIEFOWSBE SVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNF UVVFTlRJQUwKKyAqIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9D VVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTCisgKiBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0Us IERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikKKyAqIEhPV0VWRVIg Q0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFD VCwgU1RSSUNUCisgKiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9S IE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCisgKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElT IFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GCisgKiBTVUNI IERBTUFHRS4KKyAqLworCisjaW5jbHVkZSA8c3lzL2NkZWZzLmg+CitfX0ZCU0RJRCgiJEZyZWVC U0QkIik7CisjaW5jbHVkZSA8c3lzL3BhcmFtLmg+CisjaW5jbHVkZSA8c3lzL3N5c3RtLmg+Cisj aW5jbHVkZSA8c3lzL21vZHVsZS5oPgorI2luY2x1ZGUgPHN5cy9idXMuaD4KKyNpbmNsdWRlIDxz eXMvY29uZi5oPgorI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4KKyNpbmNsdWRlIDxzeXMvcm1hbi5o PgorCisjaW5jbHVkZSA8ZGV2L29mdy9vcGVuZmlybS5oPgorI2luY2x1ZGUgPGRldi9vZncvb2Z3 X2J1cy5oPgorI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1c19zdWJyLmg+CisjaW5jbHVkZSA8ZGV2 L29mdy9vZndfcGNpLmg+CisKKyNpbmNsdWRlIDxkZXYvcGNpL3BjaXZhci5oPgorI2luY2x1ZGUg PGRldi9wY2kvcGNpcmVnLmg+CisKKyNpbmNsdWRlIDxtYWNoaW5lL2J1cy5oPgorI2luY2x1ZGUg PG1hY2hpbmUvbWRfdmFyLmg+CisjaW5jbHVkZSA8bWFjaGluZS9yZXNvdXJjZS5oPgorCisjaW5j bHVkZSA8dm0vdm0uaD4KKyNpbmNsdWRlIDx2bS9wbWFwLmg+CisKKyNpbmNsdWRlICJwY2liX2lm LmgiCisKKy8qCisgKiBJZiBpdCBpcyBuZWNlc3NhcnkgdG8gc2V0IGFub3RoZXIgdmFsdWUgb2Yg dGhpcyBmb3IKKyAqIHNvbWUgcGxhdGZvcm1zIGl0IHNob3VsZCBiZSBzZXQgYXQgZmR0LmggZmls ZQorICovCisjaWZuZGVmIFBDSV9NQVBfSU5UUgorI2RlZmluZQlQQ0lfTUFQX0lOVFIJNAorI2Vu ZGlmCisKKyNkZWZpbmUJUENJX0lOVFJfUElOUwk0CisKKy8qCisgKiBidXMgaW50ZXJmYWNlLgor ICovCitzdGF0aWMgaW50IG9md19wY2lfYWN0aXZhdGVfcmVzb3VyY2UoZGV2aWNlX3QsIGRldmlj ZV90LCBpbnQsIGludCwKKyAgICBzdHJ1Y3QgcmVzb3VyY2UgKik7CitzdGF0aWMgaW50IG9md19w Y2lfcmVsZWFzZV9yZXNvdXJjZShkZXZpY2VfdCwgZGV2aWNlX3QsIGludCwgaW50LAorICAgIHN0 cnVjdCByZXNvdXJjZSAqKTsKK3N0YXRpYyBpbnQgb2Z3X3BjaV9kZWFjdGl2YXRlX3Jlc291cmNl KGRldmljZV90LCBkZXZpY2VfdCwgaW50LCBpbnQsCisgICAgc3RydWN0IHJlc291cmNlICopOwor CisjaWZkZWYgX19wb3dlcnBjX18KK3N0YXRpYyBidXNfc3BhY2VfdGFnX3Qgb2Z3X3BjaV9idXNf Z2V0X2J1c190YWcoZGV2aWNlX3QsIGRldmljZV90KTsKKyNlbmRpZgorCisvKgorICogcGNpYiBp bnRlcmZhY2UKKyAqLworc3RhdGljIGludCBvZndfcGNpX21heHNsb3RzKGRldmljZV90KTsKKwor LyoKKyAqIERyaXZlciBtZXRob2RzLgorICovCitzdGF0aWMgZGV2aWNlX21ldGhvZF90CW9md19w Y2lfbWV0aG9kc1tdID0geworCisJLyogRGV2aWNlIGludGVyZmFjZSAqLworCURFVk1FVEhPRChk ZXZpY2VfYXR0YWNoLAlvZndfcGNpX2F0dGFjaCksCisKKwkvKiBCdXMgaW50ZXJmYWNlICovCisJ REVWTUVUSE9EKGJ1c19wcmludF9jaGlsZCwJYnVzX2dlbmVyaWNfcHJpbnRfY2hpbGQpLAorCURF Vk1FVEhPRChidXNfcmVhZF9pdmFyLAlvZndfcGNpX3JlYWRfaXZhciksCisJREVWTUVUSE9EKGJ1 c193cml0ZV9pdmFyLAlvZndfcGNpX3dyaXRlX2l2YXIpLAorCURFVk1FVEhPRChidXNfc2V0dXBf aW50ciwJYnVzX2dlbmVyaWNfc2V0dXBfaW50ciksCisJREVWTUVUSE9EKGJ1c190ZWFyZG93bl9p bnRyLAlidXNfZ2VuZXJpY190ZWFyZG93bl9pbnRyKSwKKwlERVZNRVRIT0QoYnVzX2FsbG9jX3Jl c291cmNlLAlvZndfcGNpX2FsbG9jX3Jlc291cmNlKSwKKwlERVZNRVRIT0QoYnVzX3JlbGVhc2Vf cmVzb3VyY2UsCW9md19wY2lfcmVsZWFzZV9yZXNvdXJjZSksCisJREVWTUVUSE9EKGJ1c19hY3Rp dmF0ZV9yZXNvdXJjZSwJb2Z3X3BjaV9hY3RpdmF0ZV9yZXNvdXJjZSksCisJREVWTUVUSE9EKGJ1 c19kZWFjdGl2YXRlX3Jlc291cmNlLAlvZndfcGNpX2RlYWN0aXZhdGVfcmVzb3VyY2UpLAorCURF Vk1FVEhPRChidXNfYWRqdXN0X3Jlc291cmNlLAlvZndfcGNpX2FkanVzdF9yZXNvdXJjZSksCisj aWZkZWYgX19wb3dlcnBjX18KKwlERVZNRVRIT0QoYnVzX2dldF9idXNfdGFnLAlvZndfcGNpX2J1 c19nZXRfYnVzX3RhZyksCisjZW5kaWYKKworCS8qIHBjaWIgaW50ZXJmYWNlICovCisJREVWTUVU SE9EKHBjaWJfbWF4c2xvdHMsCW9md19wY2lfbWF4c2xvdHMpLAorCURFVk1FVEhPRChwY2liX3Jv dXRlX2ludGVycnVwdCwJb2Z3X3BjaV9yb3V0ZV9pbnRlcnJ1cHQpLAorCisJLyogb2Z3X2J1cyBp bnRlcmZhY2UgKi8KKwlERVZNRVRIT0Qob2Z3X2J1c19nZXRfbm9kZSwJb2Z3X3BjaV9nZXRfbm9k ZSksCisKKwlERVZNRVRIT0RfRU5ECit9OworCitERUZJTkVfQ0xBU1NfMChvZndfcGNpLCBvZndf cGNpX2RyaXZlciwgb2Z3X3BjaV9tZXRob2RzLCBzaXplb2Yoc3RydWN0IG9md19wY2lfc29mdGMp KTsKKworaW50CitvZndfcGNpX2luaXQoZGV2aWNlX3QgZGV2KQoreworCXN0cnVjdCBvZndfcGNp X3NvZnRjICpzYzsKKwlwaGFuZGxlX3Qgbm9kZTsKKwl1X2ludDMyX3QgYnVzcmFuZ2VbMl07CisJ c3RydWN0IG9md19wY2lfcmFuZ2UgKnJwOworCWludCBlcnJvcjsKKwlzdHJ1Y3Qgb2Z3X3BjaV9j ZWxsX2luZm8gKmNlbGxfaW5mbzsKKworCW5vZGUgPSBvZndfYnVzX2dldF9ub2RlKGRldik7CisJ c2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJc2MtPnNjX2luaXRpYWxpemVkID0gMTsKKwlz Yy0+c2NfcmFuZ2UgPSBOVUxMOworCisJY2VsbF9pbmZvID0gKHN0cnVjdCBvZndfcGNpX2NlbGxf aW5mbyAqKW1hbGxvYyhzaXplb2YoKmNlbGxfaW5mbyksCisJICAgIE1fREVWQlVGLCBNX1dBSVRP SyB8IE1fWkVSTyk7CisKKwlzYy0+c2NfY2VsbF9pbmZvID0gY2VsbF9pbmZvOworCisJaWYgKE9G X2dldGVuY3Byb3Aobm9kZSwgImJ1cy1yYW5nZSIsIGJ1c3JhbmdlLCBzaXplb2YoYnVzcmFuZ2Up KSAhPSA4KQorCQlidXNyYW5nZVswXSA9IDA7CisKKwlzYy0+c2NfZGV2ID0gZGV2OworCXNjLT5z Y19ub2RlID0gbm9kZTsKKwlzYy0+c2NfYnVzID0gYnVzcmFuZ2VbMF07CisKKwlpZiAoc2MtPnNj X3F1aXJrcyAmIE9GV19QQ0lfUVVJUktfUkFOR0VTX09OX0NISUxEUkVOKSB7CisJCXBoYW5kbGVf dCBjOworCQlpbnQgbiwgaTsKKworCQlzYy0+c2NfbnJhbmdlID0gMDsKKwkJZm9yIChjID0gT0Zf Y2hpbGQobm9kZSk7IGMgIT0gMDsgYyA9IE9GX3BlZXIoYykpIHsKKwkJCW4gPSBvZndfcGNpX25y YW5nZXMoYywgY2VsbF9pbmZvKTsKKwkJCWlmIChuID4gMCkKKwkJCQlzYy0+c2NfbnJhbmdlICs9 IG47CisJCX0KKwkJaWYgKHNjLT5zY19ucmFuZ2UgPT0gMCkgeworCQkJZXJyb3IgPSBFTlhJTzsK KwkJCWdvdG8gb3V0OworCQl9CisJCXNjLT5zY19yYW5nZSA9IG1hbGxvYyhzYy0+c2NfbnJhbmdl ICogc2l6ZW9mKHNjLT5zY19yYW5nZVswXSksCisJCSAgICBNX0RFVkJVRiwgTV9XQUlUT0spOwor CQlpID0gMDsKKwkJZm9yIChjID0gT0ZfY2hpbGQobm9kZSk7IGMgIT0gMDsgYyA9IE9GX3BlZXIo YykpIHsKKwkJCW4gPSBvZndfcGNpX2ZpbGxfcmFuZ2VzKGMsICZzYy0+c2NfcmFuZ2VbaV0pOwor CQkJaWYgKG4gPiAwKQorCQkJCWkgKz0gbjsKKwkJfQorCQlLQVNTRVJUKGkgPT0gc2MtPnNjX25y YW5nZSwgKCJyYW5nZSBjb3VudCBtaXNtYXRjaCIpKTsKKwl9IGVsc2UgeworCQlzYy0+c2NfbnJh bmdlID0gb2Z3X3BjaV9ucmFuZ2VzKG5vZGUsIGNlbGxfaW5mbyk7CisJCWlmIChzYy0+c2NfbnJh bmdlIDw9IDApIHsKKwkJCWRldmljZV9wcmludGYoZGV2LCAiY291bGQgbm90IGdldHJhbmdlc1xu Iik7CisJCQllcnJvciA9IEVOWElPOworCQkJZ290byBvdXQ7CisJCX0KKwkJc2MtPnNjX3Jhbmdl ID0gbWFsbG9jKHNjLT5zY19ucmFuZ2UgKiBzaXplb2Yoc2MtPnNjX3JhbmdlWzBdKSwKKwkJICAg IE1fREVWQlVGLCBNX1dBSVRPSyk7CisJCW9md19wY2lfZmlsbF9yYW5nZXMobm9kZSwgc2MtPnNj X3JhbmdlKTsKKwl9CisKKwlzYy0+c2NfaW9fcm1hbi5ybV90eXBlID0gUk1BTl9BUlJBWTsKKwlz Yy0+c2NfaW9fcm1hbi5ybV9kZXNjciA9ICJQQ0kgSS9PIFBvcnRzIjsKKwllcnJvciA9IHJtYW5f aW5pdCgmc2MtPnNjX2lvX3JtYW4pOworCWlmIChlcnJvcikgeworCQlkZXZpY2VfcHJpbnRmKGRl diwgInJtYW5faW5pdCgpIGZhaWxlZC4gZXJyb3IgPSAlZFxuIiwgZXJyb3IpOworCQlnb3RvIG91 dDsKKwl9CisKKwlzYy0+c2NfbWVtX3JtYW4ucm1fdHlwZSA9IFJNQU5fQVJSQVk7CisJc2MtPnNj X21lbV9ybWFuLnJtX2Rlc2NyID0gIlBDSSBNZW1vcnkiOworCWVycm9yID0gcm1hbl9pbml0KCZz Yy0+c2NfbWVtX3JtYW4pOworCWlmIChlcnJvcikgeworCQlkZXZpY2VfcHJpbnRmKGRldiwgInJt YW5faW5pdCgpIGZhaWxlZC4gZXJyb3IgPSAlZFxuIiwgZXJyb3IpOworCQlnb3RvIG91dDsKKwl9 CisKKwlmb3IgKHJwID0gc2MtPnNjX3JhbmdlOyBycCA8IHNjLT5zY19yYW5nZSArIHNjLT5zY19u cmFuZ2UgJiYKKwkgICAgcnAtPnBjaV9oaSAhPSAwOyBycCsrKSB7CisJCWVycm9yID0gMDsKKwor CQlzd2l0Y2ggKHJwLT5wY2lfaGkgJiBPRldfUENJX1BIWVNfSElfU1BBQ0VNQVNLKSB7CisJCWNh c2UgT0ZXX1BDSV9QSFlTX0hJX1NQQUNFX0NPTkZJRzoKKwkJCWJyZWFrOworCQljYXNlIE9GV19Q Q0lfUEhZU19ISV9TUEFDRV9JTzoKKwkJCWVycm9yID0gcm1hbl9tYW5hZ2VfcmVnaW9uKCZzYy0+ c2NfaW9fcm1hbiwgcnAtPnBjaSwKKwkJCSAgICBycC0+cGNpICsgcnAtPnNpemUgLSAxKTsKKwkJ CWJyZWFrOworCQljYXNlIE9GV19QQ0lfUEhZU19ISV9TUEFDRV9NRU0zMjoKKwkJY2FzZSBPRldf UENJX1BIWVNfSElfU1BBQ0VfTUVNNjQ6CisJCQllcnJvciA9IHJtYW5fbWFuYWdlX3JlZ2lvbigm c2MtPnNjX21lbV9ybWFuLCBycC0+cGNpLAorCQkJICAgIHJwLT5wY2kgKyBycC0+c2l6ZSAtIDEp OworCQkJYnJlYWs7CisJCX0KKworCQlpZiAoZXJyb3IpIHsKKwkJCWRldmljZV9wcmludGYoZGV2 LAorCQkJICAgICJybWFuX21hbmFnZV9yZWdpb24oJXgsICUjangsICUjangpIGZhaWxlZC4gIgor CQkJICAgICJlcnJvciA9ICVkXG4iLCBycC0+cGNpX2hpICYKKwkJCSAgICBPRldfUENJX1BIWVNf SElfU1BBQ0VNQVNLLCBycC0+cGNpLAorCQkJICAgIHJwLT5wY2kgKyBycC0+c2l6ZSAtIDEsIGVy cm9yKTsKKwkJCWdvdG8gb3V0OworCQl9CisJfQorCisJb2Z3X2J1c19zZXR1cF9paW5mbyhub2Rl LCAmc2MtPnNjX3BjaV9paW5mbywgc2l6ZW9mKGNlbGxfdCkpOworCitvdXQ6CisJZnJlZShjZWxs X2luZm8sIE1fREVWQlVGKTsKKwlmcmVlKHNjLT5zY19yYW5nZSwgTV9ERVZCVUYpOworCXJtYW5f ZmluaSgmc2MtPnNjX2lvX3JtYW4pOworCXJtYW5fZmluaSgmc2MtPnNjX21lbV9ybWFuKTsKKwor CXJldHVybiAoZXJyb3IpOworfQorCitpbnQKK29md19wY2lfYXR0YWNoKGRldmljZV90IGRldikK K3sKKwlzdHJ1Y3Qgb2Z3X3BjaV9zb2Z0YyAqc2M7CisJaW50IGVycm9yOworCisJc2MgPSBkZXZp Y2VfZ2V0X3NvZnRjKGRldik7CisJaWYgKCFzYy0+c2NfaW5pdGlhbGl6ZWQpIHsKKwkJZXJyb3Ig PSBvZndfcGNpX2luaXQoZGV2KTsKKwkJaWYgKGVycm9yKQorCQkJcmV0dXJuIChlcnJvcik7CisJ fQorCisJZGV2aWNlX2FkZF9jaGlsZChkZXYsICJwY2kiLCAtMSk7CisJcmV0dXJuIChidXNfZ2Vu ZXJpY19hdHRhY2goZGV2KSk7Cit9CisKK3N0YXRpYyBpbnQKK29md19wY2lfbWF4c2xvdHMoZGV2 aWNlX3QgZGV2KQoreworCisJcmV0dXJuIChQQ0lfU0xPVE1BWCk7Cit9CisKK2ludAorb2Z3X3Bj aV9yb3V0ZV9pbnRlcnJ1cHQoZGV2aWNlX3QgYnVzLCBkZXZpY2VfdCBkZXYsIGludCBwaW4pCit7 CisJc3RydWN0IG9md19wY2lfc29mdGMgKnNjOworCXN0cnVjdCBvZndfcGNpX3JlZ2lzdGVyIHJl ZzsKKwl1aW50MzJfdCBwaW50ciwgbWludHJbUENJX01BUF9JTlRSXTsKKwlpbnQgaW50cmNlbGxz OworCXBoYW5kbGVfdCBpcGFyZW50OworCisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGJ1cyk7CisJ cGludHIgPSBwaW47CisKKwkvKiBGYWJyaWNhdGUgaW1hcCBpbmZvcm1hdGlvbiBpbiBjYXNlIHRo aXMgaXNuJ3QgYW4gT0ZXIGRldmljZSAqLworCWJ6ZXJvKCZyZWcsIHNpemVvZihyZWcpKTsKKwly ZWcucGh5c19oaSA9IChwY2lfZ2V0X2J1cyhkZXYpIDw8IE9GV19QQ0lfUEhZU19ISV9CVVNTSElG VCkgfAorCSAgICAocGNpX2dldF9zbG90KGRldikgPDwgT0ZXX1BDSV9QSFlTX0hJX0RFVklDRVNI SUZUKSB8CisJICAgIChwY2lfZ2V0X2Z1bmN0aW9uKGRldikgPDwgT0ZXX1BDSV9QSFlTX0hJX0ZV TkNUSU9OU0hJRlQpOworCisJaW50cmNlbGxzID0gb2Z3X2J1c19sb29rdXBfaW1hcChvZndfYnVz X2dldF9ub2RlKGRldiksCisJICAgICZzYy0+c2NfcGNpX2lpbmZvLCAmcmVnLCBzaXplb2YocmVn KSwgJnBpbnRyLCBzaXplb2YocGludHIpLAorCSAgICBtaW50ciwgc2l6ZW9mKG1pbnRyKSwgJmlw YXJlbnQpOworCWlmIChpbnRyY2VsbHMgIT0gMCkgeworCQlwaW50ciA9IG9md19idXNfbWFwX2lu dHIoZGV2LCBpcGFyZW50LCBpbnRyY2VsbHMsIG1pbnRyKTsKKwkJcmV0dXJuIChwaW50cik7CisJ fQorCisJLyoKKwkgKiBNYXliZSBpdCdzIGEgcmVhbCBpbnRlcnJ1cHQsIG5vdCBhbiBpbnRwaW4K KwkgKi8KKwlpZiAocGluID4gUENJX0lOVFJfUElOUykKKwkJcmV0dXJuIChwaW4pOworCisJZGV2 aWNlX3ByaW50ZihidXMsICJjb3VsZCBub3Qgcm91dGUgcGluICVkIGZvciBkZXZpY2UgJWQuJWRc biIsCisJICAgIHBpbiwgcGNpX2dldF9zbG90KGRldiksIHBjaV9nZXRfZnVuY3Rpb24oZGV2KSk7 CisJcmV0dXJuIChQQ0lfSU5WQUxJRF9JUlEpOworfQorCitpbnQKK29md19wY2lfcmVhZF9pdmFy KGRldmljZV90IGRldiwgZGV2aWNlX3QgY2hpbGQsIGludCB3aGljaCwgdWludHB0cl90ICpyZXN1 bHQpCit7CisJc3RydWN0IG9md19wY2lfc29mdGMgKnNjOworCisJc2MgPSBkZXZpY2VfZ2V0X3Nv ZnRjKGRldik7CisKKwlzd2l0Y2ggKHdoaWNoKSB7CisJY2FzZSBQQ0lCX0lWQVJfRE9NQUlOOgor CQkqcmVzdWx0ID0gZGV2aWNlX2dldF91bml0KGRldik7CisJCXJldHVybiAoMCk7CisJY2FzZSBQ Q0lCX0lWQVJfQlVTOgorCQkqcmVzdWx0ID0gc2MtPnNjX2J1czsKKwkJcmV0dXJuICgwKTsKKwlk ZWZhdWx0OgorCQlicmVhazsKKwl9CisKKwlyZXR1cm4gKEVOT0VOVCk7Cit9CisKK2ludAorb2Z3 X3BjaV93cml0ZV9pdmFyKGRldmljZV90IGRldiwgZGV2aWNlX3QgY2hpbGQsIGludCB3aGljaCwg dWludHB0cl90IHZhbHVlKQoreworCXN0cnVjdCBvZndfcGNpX3NvZnRjICpzYzsKKworCXNjID0g ZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworCisJc3dpdGNoICh3aGljaCkgeworCWNhc2UgUENJQl9J VkFSX0JVUzoKKwkJc2MtPnNjX2J1cyA9IHZhbHVlOworCQlyZXR1cm4gKDApOworCWRlZmF1bHQ6 CisJCWJyZWFrOworCX0KKworCXJldHVybiAoRU5PRU5UKTsKK30KKworaW50CitvZndfcGNpX25y YW5nZXMocGhhbmRsZV90IG5vZGUsIHN0cnVjdCBvZndfcGNpX2NlbGxfaW5mbyAqaW5mbykKK3sK Kwlzc2l6ZV90IG5iYXNlX3JhbmdlczsKKworCWlmIChpbmZvID09IE5VTEwpCisJCXJldHVybiAo LTEpOworCisJaW5mby0+aG9zdF9hZGRyZXNzX2NlbGxzID0gMTsKKwlpbmZvLT5zaXplX2NlbGxz ID0gMjsKKwlpbmZvLT5wY2lfYWRkcmVzc19jZWxsID0gMzsKKworCU9GX2dldGVuY3Byb3AoT0Zf cGFyZW50KG5vZGUpLCAiI2FkZHJlc3MtY2VsbHMiLAorCSAgICAmKGluZm8tPmhvc3RfYWRkcmVz c19jZWxscyksIHNpemVvZihpbmZvLT5ob3N0X2FkZHJlc3NfY2VsbHMpKTsKKwlPRl9nZXRlbmNw cm9wKG5vZGUsICIjYWRkcmVzcy1jZWxscyIsCisJICAgICYoaW5mby0+cGNpX2FkZHJlc3NfY2Vs bCksIHNpemVvZihpbmZvLT5wY2lfYWRkcmVzc19jZWxsKSk7CisJT0ZfZ2V0ZW5jcHJvcChub2Rl LCAiI3NpemUtY2VsbHMiLCAmKGluZm8tPnNpemVfY2VsbHMpLAorCSAgICBzaXplb2YoaW5mby0+ c2l6ZV9jZWxscykpOworCisJbmJhc2VfcmFuZ2VzID0gT0ZfZ2V0cHJvcGxlbihub2RlLCAicmFu Z2VzIik7CisJaWYgKG5iYXNlX3JhbmdlcyA8PSAwKQorCQlyZXR1cm4gKC0xKTsKKworCXJldHVy biAobmJhc2VfcmFuZ2VzIC8gc2l6ZW9mKGNlbGxfdCkgLworCSAgICAoaW5mby0+cGNpX2FkZHJl c3NfY2VsbCArIGluZm8tPmhvc3RfYWRkcmVzc19jZWxscyArCisJICAgIGluZm8tPnNpemVfY2Vs bHMpKTsKK30KKworc3RydWN0IHJlc291cmNlICoKK29md19wY2lfYWxsb2NfcmVzb3VyY2UoZGV2 aWNlX3QgYnVzLCBkZXZpY2VfdCBjaGlsZCwgaW50IHR5cGUsIGludCAqcmlkLAorICAgIHJtYW5f cmVzX3Qgc3RhcnQsIHJtYW5fcmVzX3QgZW5kLCBybWFuX3Jlc190IGNvdW50LCB1X2ludCBmbGFn cykKK3sKKwlzdHJ1Y3Qgb2Z3X3BjaV9zb2Z0YyAqc2M7CisJc3RydWN0IHJlc291cmNlICpydjsK KwlzdHJ1Y3Qgcm1hbiAqcm07CisJaW50IG5lZWRhY3RpdmF0ZTsKKworCW5lZWRhY3RpdmF0ZSA9 IGZsYWdzICYgUkZfQUNUSVZFOworCWZsYWdzICY9IH5SRl9BQ1RJVkU7CisKKwlzYyA9IGRldmlj ZV9nZXRfc29mdGMoYnVzKTsKKworCXN3aXRjaCAodHlwZSkgeworCWNhc2UgU1lTX1JFU19NRU1P Ulk6CisJCXJtID0gJnNjLT5zY19tZW1fcm1hbjsKKwkJYnJlYWs7CisKKwljYXNlIFNZU19SRVNf SU9QT1JUOgorCQlybSA9ICZzYy0+c2NfaW9fcm1hbjsKKwkJYnJlYWs7CisKKwljYXNlIFNZU19S RVNfSVJROgorCisjaWZkZWYgX19zcGFyYzY0X18KKwkJaWYgKHN0YXJ0ICE9IGVuZCkKKwkJCXBh bmljKCIlczogWFhYOiBpbnRlcnJ1cHQgcmFuZ2UiLCBfX2Z1bmNfXyk7CisJCXJldHVybiAoYnVz X2dlbmVyaWNfYWxsb2NfcmVzb3VyY2UoYnVzLCBjaGlsZCwgdHlwZSwgcmlkLCBzdGFydCwKKwkJ ICAgIGVuZCwgY291bnQsIGZsYWdzKSk7CisjZWxzZQorCQlyZXR1cm4gKGJ1c19hbGxvY19yZXNv dXJjZShidXMsIHR5cGUsIHJpZCwgc3RhcnQsIGVuZCwgY291bnQsCisJCSAgICBmbGFncykpOwor I2VuZGlmCisKKwlkZWZhdWx0OgorCQlkZXZpY2VfcHJpbnRmKGJ1cywgInVua25vd24gcmVzb3Vy Y2UgcmVxdWVzdCBmcm9tICVzXG4iLAorCQkgICAgZGV2aWNlX2dldF9uYW1ldW5pdChjaGlsZCkp OworCQlyZXR1cm4gKE5VTEwpOworCX0KKworCXJ2ID0gcm1hbl9yZXNlcnZlX3Jlc291cmNlKHJt LCBzdGFydCwgZW5kLCBjb3VudCwgZmxhZ3MsIGNoaWxkKTsKKwlpZiAocnYgPT0gTlVMTCkgewor CQlkZXZpY2VfcHJpbnRmKGJ1cywgImZhaWxlZCB0byByZXNlcnZlIHJlc291cmNlIGZvciAlc1xu IiwKKwkJICAgIGRldmljZV9nZXRfbmFtZXVuaXQoY2hpbGQpKTsKKwkJcmV0dXJuIChOVUxMKTsK Kwl9CisKKwlybWFuX3NldF9yaWQocnYsICpyaWQpOworCisJaWYgKG5lZWRhY3RpdmF0ZSkgewor CQlpZiAoYnVzX2FjdGl2YXRlX3Jlc291cmNlKGNoaWxkLCB0eXBlLCAqcmlkLCBydikgIT0gMCkg eworCQkJZGV2aWNlX3ByaW50ZihidXMsCisJCQkgICAgImZhaWxlZCB0byBhY3RpdmF0ZSByZXNv dXJjZSBmb3IgJXNcbiIsCisJCQkgICAgZGV2aWNlX2dldF9uYW1ldW5pdChjaGlsZCkpOworCQkJ cm1hbl9yZWxlYXNlX3Jlc291cmNlKHJ2KTsKKwkJCXJldHVybiAoTlVMTCk7CisJCX0KKwl9CisK KwlyZXR1cm4gKHJ2KTsKK30KKworc3RhdGljIGludAorb2Z3X3BjaV9yZWxlYXNlX3Jlc291cmNl KGRldmljZV90IGJ1cywgZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLCBpbnQgcmlkLAorICAgIHN0 cnVjdCByZXNvdXJjZSAqcmVzKQoreworCisJaWYgKHJtYW5fZ2V0X2ZsYWdzKHJlcykgJiBSRl9B Q1RJVkUpIHsKKwkJaW50IGVycm9yID0gYnVzX2RlYWN0aXZhdGVfcmVzb3VyY2UoY2hpbGQsIHR5 cGUsIHJpZCwgcmVzKTsKKwkJaWYgKGVycm9yKQorCQkJcmV0dXJuIGVycm9yOworCX0KKworCXJl dHVybiAocm1hbl9yZWxlYXNlX3Jlc291cmNlKHJlcykpOworfQorCitzdGF0aWMgaW50CitvZndf cGNpX2FjdGl2YXRlX3Jlc291cmNlKGRldmljZV90IGJ1cywgZGV2aWNlX3QgY2hpbGQsIGludCB0 eXBlLCBpbnQgcmlkLAorICAgIHN0cnVjdCByZXNvdXJjZSAqcmVzKQoreworCXN0cnVjdCBvZndf cGNpX3NvZnRjICpzYzsKKwlidXNfc3BhY2VfaGFuZGxlX3QgaGFuZGxlOworCWJ1c19zcGFjZV90 YWdfdCB0YWc7CisJaW50IHJ2OworCisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGJ1cyk7CisKKwlp ZiAodHlwZSA9PSBTWVNfUkVTX0lSUSkgeworCQlyZXR1cm4gKGJ1c19hY3RpdmF0ZV9yZXNvdXJj ZShidXMsIHR5cGUsIHJpZCwgcmVzKSk7CisJfQorCWlmICh0eXBlID09IFNZU19SRVNfTUVNT1JZ IHx8IHR5cGUgPT0gU1lTX1JFU19JT1BPUlQpIHsKKwkJc3RydWN0IG9md19wY2lfcmFuZ2UgKnJw OworCQl2bV9vZmZzZXRfdCBzdGFydDsKKwkJaW50IHNwYWNlOworCisJCXN0YXJ0ID0gKHZtX29m ZnNldF90KXJtYW5fZ2V0X3N0YXJ0KHJlcyk7CisKKwkJLyoKKwkJICogTWFwIHRoaXMgdGhyb3Vn aCB0aGUgcmFuZ2VzIGxpc3QKKwkJICovCisJCWZvciAocnAgPSBzYy0+c2NfcmFuZ2U7IHJwIDwg c2MtPnNjX3JhbmdlICsgc2MtPnNjX25yYW5nZSAmJgorCQkgICAgcnAtPnBjaV9oaSAhPSAwOyBy cCsrKSB7CisJCQlpZiAoc3RhcnQgPCBycC0+cGNpIHx8IHN0YXJ0ID49IHJwLT5wY2kgKyBycC0+ c2l6ZSkKKwkJCQljb250aW51ZTsKKworCQkJc3dpdGNoIChycC0+cGNpX2hpICYgT0ZXX1BDSV9Q SFlTX0hJX1NQQUNFTUFTSykgeworCQkJY2FzZSBPRldfUENJX1BIWVNfSElfU1BBQ0VfSU86CisJ CQkJc3BhY2UgPSBTWVNfUkVTX0lPUE9SVDsKKwkJCQlicmVhazsKKwkJCWNhc2UgT0ZXX1BDSV9Q SFlTX0hJX1NQQUNFX01FTTMyOgorCQkJY2FzZSBPRldfUENJX1BIWVNfSElfU1BBQ0VfTUVNNjQ6 CisJCQkJc3BhY2UgPSBTWVNfUkVTX01FTU9SWTsKKwkJCQlicmVhazsKKwkJCWRlZmF1bHQ6CisJ CQkJc3BhY2UgPSAtMTsKKwkJCX0KKworCQkJaWYgKHR5cGUgPT0gc3BhY2UpIHsKKwkJCQlzdGFy dCArPSAocnAtPmhvc3QgLSBycC0+cGNpKTsKKwkJCQlicmVhazsKKwkJCX0KKwkJfQorCisJCWlm IChib290dmVyYm9zZSkKKwkJCXByaW50Zigib2Z3X3BjaSBtYXBkZXY6IHN0YXJ0ICV6eCwgbGVu ICVsZFxuIiwgc3RhcnQsCisJCQkgICAgcm1hbl9nZXRfc2l6ZShyZXMpKTsKKworCQl0YWcgPSBC VVNfR0VUX0JVU19UQUcoY2hpbGQsIGNoaWxkKTsKKwkJaWYgKHRhZyA9PSBOVUxMKQorCQkJcmV0 dXJuIChFTk9NRU0pOworCisJCXJtYW5fc2V0X2J1c3RhZyhyZXMsIHRhZyk7CisJCXJ2ID0gYnVz X3NwYWNlX21hcCh0YWcsIHN0YXJ0LAorCQkgICAgcm1hbl9nZXRfc2l6ZShyZXMpLCAwLCAmaGFu ZGxlKTsKKwkJaWYgKHJ2ICE9IDApCisJCQlyZXR1cm4gKEVOT01FTSk7CisKKwkJcm1hbl9zZXRf YnVzaGFuZGxlKHJlcywgaGFuZGxlKTsKKwkJcm1hbl9zZXRfdmlydHVhbChyZXMsICh2b2lkICop aGFuZGxlKTsgLyogWFhYICBmb3IgcG93ZXJwYyBvbmx5ID8gKi8KKwl9CisKKwlyZXR1cm4gKHJt YW5fYWN0aXZhdGVfcmVzb3VyY2UocmVzKSk7Cit9CisKKyNpZmRlZiBfX3Bvd2VycGNfXworc3Rh dGljIGJ1c19zcGFjZV90YWdfdAorb2Z3X3BjaV9idXNfZ2V0X2J1c190YWcoZGV2aWNlX3QgYnVz LCBkZXZpY2VfdCBjaGlsZCkKK3sKKworCXJldHVybiAoJmJzX2xlX3RhZyk7Cit9CisjZW5kaWYK Kworc3RhdGljIGludAorb2Z3X3BjaV9kZWFjdGl2YXRlX3Jlc291cmNlKGRldmljZV90IGJ1cywg ZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLCBpbnQgcmlkLAorICAgIHN0cnVjdCByZXNvdXJjZSAq cmVzKQoreworCisJLyoKKwkgKiBJZiB0aGlzIGlzIGEgbWVtb3J5IHJlc291cmNlLCB1bm1hcCBp dC4KKwkgKi8KKwlpZiAoKHR5cGUgPT0gU1lTX1JFU19NRU1PUlkpIHx8ICh0eXBlID09IFNZU19S RVNfSU9QT1JUKSkgeworCQl1X2ludDMyX3QgcHNpemU7CisKKwkJcHNpemUgPSBybWFuX2dldF9z aXplKHJlcyk7CisKKwkJLyoKKwkJICogWFhYOiBUaGUgaW1wbGVtZW50YXRpb24gaXMgbWFjaGlu ZS1kZXBlbmRlbnQgYW5kCisJCSAqIHNwYXJjNjQgdXNlcyBhIGRpZmZlcmVudCBmdW5jdGlvbiBz aWduYXR1cmUgYXMgd2VsbC4KKwkJICovCisjaWZuZGVmIF9fc3BhcmM2NF9fCisJCXBtYXBfdW5t YXBkZXYoKHZtX29mZnNldF90KXJtYW5fZ2V0X3ZpcnR1YWwocmVzKSwgcHNpemUpOworI2VuZGlm CisJfQorCisJcmV0dXJuIChybWFuX2RlYWN0aXZhdGVfcmVzb3VyY2UocmVzKSk7Cit9CisKK2lu dAorb2Z3X3BjaV9hZGp1c3RfcmVzb3VyY2UoZGV2aWNlX3QgYnVzLCBkZXZpY2VfdCBjaGlsZCwg aW50IHR5cGUsCisgICAgc3RydWN0IHJlc291cmNlICpyZXMsIHJtYW5fcmVzX3Qgc3RhcnQsIHJt YW5fcmVzX3QgZW5kKQoreworCXN0cnVjdCBybWFuICpybSA9IE5VTEw7CisJc3RydWN0IG9md19w Y2lfc29mdGMgKnNjID0gZGV2aWNlX2dldF9zb2Z0YyhidXMpOworCisJS0FTU0VSVCghKHJtYW5f Z2V0X2ZsYWdzKHJlcykgJiBSRl9BQ1RJVkUpLAorCSAgICAoImFjdGl2ZSByZXNvdXJjZXMgY2Fu bm90IGJlIGFkanVzdGVkIikpOworCWlmIChybWFuX2dldF9mbGFncyhyZXMpICYgUkZfQUNUSVZF KQorCQlyZXR1cm4gKEVJTlZBTCk7CisKKwlzd2l0Y2ggKHR5cGUpIHsKKwljYXNlIFNZU19SRVNf TUVNT1JZOgorCQlybSA9ICZzYy0+c2NfbWVtX3JtYW47CisJCWJyZWFrOworCWNhc2UgU1lTX1JF U19JT1BPUlQ6CisJCXJtID0gJnNjLT5zY19pb19ybWFuOworCQlicmVhazsKKwljYXNlIFNZU19S RVNfSVJROgorCQlyZXR1cm4gKGJ1c19nZW5lcmljX2FkanVzdF9yZXNvdXJjZShidXMsIGNoaWxk LCB0eXBlLCByZXMsCisJCSAgICBzdGFydCwgZW5kKSk7CisJZGVmYXVsdDoKKwkJcmV0dXJuIChF TlhJTyk7CisJfQorCisJaWYgKCFybWFuX2lzX3JlZ2lvbl9tYW5hZ2VyKHJlcywgcm0pKQorCQly ZXR1cm4gKEVJTlZBTCk7CisKKwlyZXR1cm4gKHJtYW5fYWRqdXN0X3Jlc291cmNlKHJlcywgc3Rh cnQsIGVuZCkpOworfQorCitwaGFuZGxlX3QKK29md19wY2lfZ2V0X25vZGUoZGV2aWNlX3QgYnVz LCBkZXZpY2VfdCBkZXYpCit7CisJc3RydWN0IG9md19wY2lfc29mdGMgKnNjOworCisJc2MgPSBk ZXZpY2VfZ2V0X3NvZnRjKGJ1cyk7CisJLyogV2Ugb25seSBoYXZlIG9uZSBjaGlsZCwgdGhlIFBD SSBidXMsIHdoaWNoIG5lZWRzIG91ciBvd24gbm9kZS4gKi8KKworCXJldHVybiAoc2MtPnNjX25v ZGUpOworfQorCitidXNfZG1hX3RhZ190CitvZndfcGNpX2dldF9kbWFfdGFnKGRldmljZV90IGJ1 cywgZGV2aWNlX3QgY2hpbGQgX191bnVzZWQpCit7CisJc3RydWN0IG9md19wY2lfc29mdGMgKnNj OworCisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGJ1cyk7CisJcmV0dXJuIChzYy0+c2NfZG1hdCk7 Cit9CisKK2ludAorb2Z3X3BjaV9maWxsX3JhbmdlcyhwaGFuZGxlX3Qgbm9kZSwgc3RydWN0IG9m d19wY2lfcmFuZ2UgKnJhbmdlcykKK3sKKwlzdHJ1Y3Qgb2Z3X3BjaV9jZWxsX2luZm8gKmNlbGxf aW5mbzsKKwlwY2VsbF90ICpiYXNlX3JhbmdlczsKKwlzc2l6ZV90IG5iYXNlX3JhbmdlczsKKwlp bnQgbnJhbmdlczsKKwlpbnQgaSwgaiwgazsKKworCWNlbGxfaW5mbyA9IChzdHJ1Y3Qgb2Z3X3Bj aV9jZWxsX2luZm8gKiltYWxsb2Moc2l6ZW9mKCpjZWxsX2luZm8pLAorCSAgICBNX0RFVkJVRiwg TV9XQUlUT0sgfCBNX1pFUk8pOworCisJbnJhbmdlcyA9IG9md19wY2lfbnJhbmdlcyhub2RlLCBj ZWxsX2luZm8pOworCisJbmJhc2VfcmFuZ2VzID0gT0ZfZ2V0cHJvcGxlbihub2RlLCAicmFuZ2Vz Iik7CisJaWYgKG5iYXNlX3JhbmdlcyA8PSAwKQorCQlyZXR1cm4gKC0xKTsKKwliYXNlX3Jhbmdl cyA9IG1hbGxvYyhuYmFzZV9yYW5nZXMsIE1fREVWQlVGLCBNX1dBSVRPSyk7CisJT0ZfZ2V0ZW5j cHJvcChub2RlLCAicmFuZ2VzIiwgYmFzZV9yYW5nZXMsIG5iYXNlX3Jhbmdlcyk7CisKKwlmb3Ig KGkgPSAwLCBqID0gMDsgaSA8IG5yYW5nZXM7IGkrKykgeworCQlyYW5nZXNbaV0ucGNpX2hpID0g YmFzZV9yYW5nZXNbaisrXTsKKwkJcmFuZ2VzW2ldLnBjaSA9IDA7CisJCWZvciAoayA9IDA7IGsg PCBjZWxsX2luZm8tPnBjaV9hZGRyZXNzX2NlbGwgLSAxOyBrKyspIHsKKwkJCXJhbmdlc1tpXS5w Y2kgPDw9IDMyOworCQkJcmFuZ2VzW2ldLnBjaSB8PSBiYXNlX3Jhbmdlc1tqKytdOworCQl9CisJ CXJhbmdlc1tpXS5ob3N0ID0gMDsKKwkJZm9yIChrID0gMDsgayA8IGNlbGxfaW5mby0+aG9zdF9h ZGRyZXNzX2NlbGxzOyBrKyspIHsKKwkJCXJhbmdlc1tpXS5ob3N0IDw8PSAzMjsKKwkJCXJhbmdl c1tpXS5ob3N0IHw9IGJhc2VfcmFuZ2VzW2orK107CisJCX0KKwkJcmFuZ2VzW2ldLnNpemUgPSAw OworCQlmb3IgKGsgPSAwOyBrIDwgY2VsbF9pbmZvLT5zaXplX2NlbGxzOyBrKyspIHsKKwkJCXJh bmdlc1tpXS5zaXplIDw8PSAzMjsKKwkJCXJhbmdlc1tpXS5zaXplIHw9IGJhc2VfcmFuZ2VzW2or K107CisJCX0KKwl9CisKKwlmcmVlKGJhc2VfcmFuZ2VzLCBNX0RFVkJVRik7CisJcmV0dXJuIChu cmFuZ2VzKTsKK30KZGlmZiAtLWdpdCBhL3N5cy9kZXYvb2Z3L29md19wY2kuaCBiL3N5cy9kZXYv b2Z3L29md19wY2kuaAppbmRleCBlYjYwYzViLi43NDM1NWQyIDEwMDY0NAotLS0gYS9zeXMvZGV2 L29mdy9vZndfcGNpLmgKKysrIGIvc3lzL2Rldi9vZncvb2Z3X3BjaS5oCkBAIC04OSw2ICs4OSw0 NyBAQAogI2RlZmluZSBPRldfUENJX1BIWVNfSElfRlVOQ1RJT04oaGkpIFwKIAkoKChoaSkgJiBP RldfUENJX1BIWVNfSElfRlVOQ1RJT05NQVNLKSA+PiBPRldfUENJX1BIWVNfSElfRlVOQ1RJT05T SElGVCkKIAorI2RlZmluZQlPRldfUENJX1NQQUNFX05VTQkJNAorCisvKgorICogRXhwb3J0IGNs YXNzIGRlZmluaXRpb24gZm9yIGluaGVyaXRhbmNlIHB1cnBvc2VzCisgKi8KK0RFQ0xBUkVfQ0xB U1Mob2Z3X3BjaV9kcml2ZXIpOworCit0eXBlZGVmIHVpbnQzMl90IG9md19wY2lfaW50cl90Owor CisvKiBPRlcgZGV2aWNlIHR5cGVzICovCisjZGVmaW5lCU9GV19UWVBFX1BDSQkJInBjaSIKKyNk ZWZpbmUJT0ZXX1RZUEVfUENJRQkJInBjaWV4IgorCitzdHJ1Y3Qgb2Z3X3BjaV9tc2lfYWRkcl9y YW5nZXMgeworCXVpbnQzMl90CWFkZHIzMl9oaTsKKwl1aW50MzJfdAlhZGRyMzJfbG87CisJdWlu dDMyX3QJYWRkcjMyX3N6OworCXVpbnQzMl90CWFkZHI2NF9oaTsKKwl1aW50MzJfdAlhZGRyNjRf bG87CisJdWludDMyX3QJYWRkcjY0X3N6OworfTsKKworI2RlZmluZQlPRldfUENJX01TSV9BRERS X1JBTkdFXzMyKHIpIFwKKwkoKCh1aW50NjRfdCkociktPmFkZHIzMl9oaSA8PCAzMikgfCAodWlu dDY0X3QpKHIpLT5hZGRyMzJfbG8pCisjZGVmaW5lCU9GV19QQ0lfTVNJX0FERFJfUkFOR0VfNjQo cikgXAorCSgoKHVpbnQ2NF90KShyKS0+YWRkcjY0X2hpIDw8IDMyKSB8ICh1aW50NjRfdCkocikt PmFkZHI2NF9sbykKKworc3RydWN0IG9md19wY2lfbXNpX2VxX3RvX2RldmlubyB7CisJdWludDMy X3QJZXFfZmlyc3Q7CisJdWludDMyX3QJZXFfY291bnQ7CisJdWludDMyX3QJZGV2aW5vX2ZpcnN0 OworfTsKKworc3RydWN0IG9md19wY2lfbXNpX3JhbmdlcyB7CisJdWludDMyX3QJZmlyc3Q7CisJ dWludDMyX3QJY291bnQ7Cit9OworCisvKiBkZWZhdWx0IHZhbHVlcyAqLworI2RlZmluZQlPRldf UENJX0xBVEVOQ1kJNjQKKwogLyoKICAqIFRoaXMgaGFzIHRoZSAzIDMyYml0IGNlbGwgdmFsdWVz LCBwbHVzIDIgbW9yZSB0byBtYWtlIHVwIGEgNjQtYml0IHNpemUuCiAgKi8KQEAgLTEwMCw0ICsx NDEsODcgQEAgc3RydWN0IG9md19wY2lfcmVnaXN0ZXIgewogCXVfaW50MzJfdAlzaXplX2xvOwog fTsKIAorc3RydWN0IG9md19wY2lfY2VsbF9pbmZvIHsKKwlwY2VsbF90IGhvc3RfYWRkcmVzc19j ZWxsczsKKwlwY2VsbF90IHBjaV9hZGRyZXNzX2NlbGw7CisJcGNlbGxfdCBzaXplX2NlbGxzOwor IH07CisKK3N0cnVjdCBvZndfcGNpX3JhbmdlIHsKKwl1aW50MzJfdAlwY2lfaGk7CisJdWludDY0 X3QJcGNpOworCXVpbnQ2NF90CWhvc3Q7CisJdWludDY0X3QJc2l6ZTsKK307CisKKy8qCisgKiBR dWlya3MgZm9yIHNvbWUgYWRhcHRlcnMKKyAqLworZW51bSB7CisJT0ZXX1BDSV9RVUlSS19SQU5H RVNfT05fQ0hJTERSRU4gPSAxLAorfTsKKworLyoKKyAqIEluZGV4IGludG8gdGhlIHNjX2JoW10g YXJyYXksIGl0IGlzCisgKiBjb3JyZXNwb25kaW5nIHRvIHRoZSBQQ0kgc3BhY2UgcmFuZ2VzIHR5 cGUKKyAqLworZW51bSBvZndfcGNpX3Jhbmdlc190eXBlIHsKKwlPRldfUENJX0NPTkZJRyA9IDAs CisJT0ZXX1BDSV9JTywKKwlPRldfUENJX01FTTMyLAorCU9GV19QQ0lfTUVNNjQKK307CisKK3N0 cnVjdCBvZndfcGNpX3NvZnRjIHsKKwlkZXZpY2VfdAlzY19kZXY7CisJcGhhbmRsZV90CXNjX25v ZGU7CisJaW50CQlzY19idXM7CisJaW50CQlzY19pbml0aWFsaXplZDsKKwlpbnQJCXNjX3F1aXJr czsKKwl1aW50OF90CQlzY19zZWNidXM7CisJdWludDhfdAkJc2Nfc3ViYnVzOworCisJc3RydWN0 IG9md19wY2lfcmFuZ2UJCSpzY19yYW5nZTsKKwlpbnQJCQkJc2NfbnJhbmdlOworCXN0cnVjdCBv ZndfcGNpX2NlbGxfaW5mbwkqc2NfY2VsbF9pbmZvOworCisJc3RydWN0IHJtYW4JCQlzY19pb19y bWFuOworCXN0cnVjdCBybWFuCQkJc2NfbWVtX3JtYW47CisJYnVzX3NwYWNlX3RhZ190CQkJc2Nf bWVtdDsKKwlidXNfc3BhY2VfdGFnX3QJCQlzY19jZmd0OworCWJ1c19zcGFjZV90YWdfdAkJCXNj X2lvdDsKKwlidXNfZG1hX3RhZ190CQkJc2NfZG1hdDsKKwlidXNfc3BhY2VfaGFuZGxlX3QJCXNj X2JoW09GV19QQ0lfU1BBQ0VfTlVNXTsKKworCXN0cnVjdCBvZndfYnVzX2lpbmZvCQlzY19wY2lf aWluZm87Cit9OworCitpbnQgb2Z3X3BjaV9pbml0KGRldmljZV90KTsKK2ludCBvZndfcGNpX2F0 dGFjaChkZXZpY2VfdCk7CitpbnQgb2Z3X3BjaV9yZWFkX2l2YXIoZGV2aWNlX3QsIGRldmljZV90 LCBpbnQsIHVpbnRwdHJfdCAqKTsKK2ludCBvZndfcGNpX3dyaXRlX2l2YXIoZGV2aWNlX3QsIGRl dmljZV90LCBpbnQsIHVpbnRwdHJfdCk7CitpbnQgb2Z3X3BjaV9yb3V0ZV9pbnRlcnJ1cHQoZGV2 aWNlX3QsIGRldmljZV90LCBpbnQpOworaW50IG9md19wY2lfbnJhbmdlcyhwaGFuZGxlX3QsIHN0 cnVjdCBvZndfcGNpX2NlbGxfaW5mbyAqKTsKK2ludCBvZndfcGNpX2ZpbGxfcmFuZ2VzKHBoYW5k bGVfdCwgc3RydWN0IG9md19wY2lfcmFuZ2UgKik7CisKK2ludCBvZndfcGNpX2FkanVzdF9yZXNv dXJjZShkZXZpY2VfdCwgZGV2aWNlX3QsIGludCwKKyAgICBzdHJ1Y3QgcmVzb3VyY2UgKiwgdV9s b25nLCB1X2xvbmcpOworc3RydWN0IHJlc291cmNlICogb2Z3X3BjaV9hbGxvY19yZXNvdXJjZShk ZXZpY2VfdCwgZGV2aWNlX3QsCisgICAgaW50LCBpbnQgKiwgdV9sb25nLCB1X2xvbmcsIHVfbG9u ZywgdV9pbnQpOworaW50IHNwYXJjNjRfb2Z3X3BjaV9hY3RpdmF0ZV9yZXNvdXJjZShkZXZpY2Vf dCwgZGV2aWNlX3QsIGludCwgaW50LAorICAgIHN0cnVjdCByZXNvdXJjZSAqKTsKK2ludCBzcGFy YzY0X29md19wY2lfZGVhY3RpdmF0ZV9yZXNvdXJjZShkZXZpY2VfdCwgZGV2aWNlX3QsIGludCwg aW50LAorICAgIHN0cnVjdCByZXNvdXJjZSAqKTsKKworaW50IG9md19wY2lfYXR0YWNoX2NvbW1v bihkZXZpY2VfdCwgYnVzX2RtYV90YWdfdCwgdV9sb25nLCB1X2xvbmcpOwordWludDMyX3Qgb2Z3 X3BjaV9yZWFkX2NvbmZpZ19jb21tb24oZGV2aWNlX3QsIHVfaW50LCB1X2xvbmcsIHVfaW50LCB1 X2ludCwKKyAgICB1X2ludCwgdV9pbnQsIGludCk7Cit2b2lkIG9md19wY2lfd3JpdGVfY29uZmln X2NvbW1vbihkZXZpY2VfdCwgdV9pbnQsIHVfbG9uZywgdV9pbnQsIHVfaW50LAorICAgIHVfaW50 LCB1X2ludCwgdWludDMyX3QsIGludCk7CitvZndfcGNpX2ludHJfdCBvZndfcGNpX3JvdXRlX2lu dGVycnVwdF9jb21tb24oZGV2aWNlX3QsIGRldmljZV90LCBpbnQpOwordm9pZCBvZndfcGNpX2Rt YW1hcF9zeW5jX3N0c3Rfb3JkZXJfY29tbW9uKHZvaWQpOworCitvZndfYnVzX2dldF9ub2RlX3Qg b2Z3X3BjaV9nZXRfbm9kZTsKK2J1c19nZXRfZG1hX3RhZ190IG9md19wY2lfZ2V0X2RtYV90YWc7 CisKICNlbmRpZiAvKiBfREVWX09GV19PRldfUENJX0hfICovCmRpZmYgLS1naXQgYS9zeXMvZGV2 L29mdy9vZndfc3Vici5jIGIvc3lzL2Rldi9vZncvb2Z3X3N1YnIuYwppbmRleCA0ZDE0ZGI3Li5l OWI2NmMyIDEwMDY0NAotLS0gYS9zeXMvZGV2L29mdy9vZndfc3Vici5jCisrKyBiL3N5cy9kZXYv b2Z3L29md19zdWJyLmMKQEAgLTM5LDggKzM5LDkgQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwog I2luY2x1ZGUgPG1hY2hpbmUvYnVzLmg+CiAKICNpbmNsdWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+ Ci0jaW5jbHVkZSA8ZGV2L29mdy9vZndfcGNpLmg+CiAjaW5jbHVkZSA8ZGV2L29mdy9vZndfc3Vi ci5oPgorI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1c19zdWJyLmg+CisjaW5jbHVkZSA8ZGV2L29m dy9vZndfcGNpLmg+CiAKIHN0YXRpYyB2b2lkCiBnZXRfYWRkcl9wcm9wcyhwaGFuZGxlX3Qgbm9k ZSwgdWludDMyX3QgKmFkZHJwLCB1aW50MzJfdCAqc2l6ZXAsIGludCAqcGNpcCkKZGlmZiAtLWdp dCBhL3N5cy9kZXYvdnQvaHcvb2Z3ZmIvb2Z3ZmIuYyBiL3N5cy9kZXYvdnQvaHcvb2Z3ZmIvb2Z3 ZmIuYwppbmRleCAwNzc2YThlLi5mZjQ2N2ZhIDEwMDY0NAotLS0gYS9zeXMvZGV2L3Z0L2h3L29m d2ZiL29md2ZiLmMKKysrIGIvc3lzL2Rldi92dC9ody9vZndmYi9vZndmYi5jCkBAIC0zMSw2ICsz MSw3IEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKICNpbmNsdWRlIDxzeXMva2VybmVsLmg+CiAj aW5jbHVkZSA8c3lzL3N5c3RtLmg+CiAjaW5jbHVkZSA8c3lzL2ZiaW8uaD4KKyNpbmNsdWRlIDxz eXMvcm1hbi5oPgogCiAjaW5jbHVkZSA8ZGV2L3Z0L3Z0Lmg+CiAjaW5jbHVkZSA8ZGV2L3Z0L2h3 L2ZiL3Z0X2ZiLmg+CkBAIC00Niw2ICs0Nyw3IEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKIAog I2luY2x1ZGUgPGRldi9vZncvb3BlbmZpcm0uaD4KICNpbmNsdWRlIDxkZXYvb2Z3L29md19idXMu aD4KKyNpbmNsdWRlIDxkZXYvb2Z3L29md19idXNfc3Vici5oPgogI2luY2x1ZGUgPGRldi9vZncv b2Z3X3BjaS5oPgogCiBzdHJ1Y3Qgb2Z3ZmJfc29mdGMgewpkaWZmIC0tZ2l0IGEvc3lzL3Bvd2Vy cGMvbXBjODV4eC9wY2lfbXBjODV4eC5jIGIvc3lzL3Bvd2VycGMvbXBjODV4eC9wY2lfbXBjODV4 eC5jCmluZGV4IDQzOTdhYzAuLmRlNTVhZmMgMTAwNjQ0Ci0tLSBhL3N5cy9wb3dlcnBjL21wYzg1 eHgvcGNpX21wYzg1eHguYworKysgYi9zeXMvcG93ZXJwYy9tcGM4NXh4L3BjaV9tcGM4NXh4LmMK QEAgLTU1LDE1ICs1NSwxMyBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAjaW5jbHVkZSA8dm0v dm0uaD4KICNpbmNsdWRlIDx2bS9wbWFwLmg+CiAKLSNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2ku aD4KICNpbmNsdWRlIDxkZXYvb2Z3L29md19idXMuaD4KICNpbmNsdWRlIDxkZXYvb2Z3L29md19i dXNfc3Vici5oPgorI2luY2x1ZGUgPGRldi9vZncvb2Z3X3BjaS5oPgogI2luY2x1ZGUgPGRldi9w Y2kvcGNpdmFyLmg+CiAjaW5jbHVkZSA8ZGV2L3BjaS9wY2lyZWcuaD4KICNpbmNsdWRlIDxkZXYv cGNpL3BjaWJfcHJpdmF0ZS5oPgogCi0jaW5jbHVkZSA8cG93ZXJwYy9vZncvb2Z3X3BjaS5oPgot CiAjaW5jbHVkZSAib2Z3X2J1c19pZi5oIgogI2luY2x1ZGUgInBjaWJfaWYuaCIKIApkaWZmIC0t Z2l0IGEvc3lzL3Bvd2VycGMvb2Z3L29md19tYWNoZGVwLmMgYi9zeXMvcG93ZXJwYy9vZncvb2Z3 X21hY2hkZXAuYwppbmRleCAzMDUxZWIzLi40MDkyMjg4IDEwMDY0NAotLS0gYS9zeXMvcG93ZXJw Yy9vZncvb2Z3X21hY2hkZXAuYworKysgYi9zeXMvcG93ZXJwYy9vZncvb2Z3X21hY2hkZXAuYwpA QCAtNTAsNiArNTAsNyBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAKICNpbmNsdWRlIDxkZXYv ZmR0L2ZkdF9jb21tb24uaD4KICNpbmNsdWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+CisjaW5jbHVk ZSA8ZGV2L29mdy9vZndfYnVzX3N1YnIuaD4KICNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4K ICNpbmNsdWRlIDxkZXYvb2Z3L29md19idXMuaD4KICNpbmNsdWRlIDxkZXYvb2Z3L29md19zdWJy Lmg+CmRpZmYgLS1naXQgYS9zeXMvcG93ZXJwYy9vZncvb2Z3X3BjaS5jIGIvc3lzL3Bvd2VycGMv b2Z3L29md19wY2kuYwpkZWxldGVkIGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMGNhNWJjMC4uMDAw MDAwMAotLS0gYS9zeXMvcG93ZXJwYy9vZncvb2Z3X3BjaS5jCisrKyAvZGV2L251bGwKQEAgLTEs NTU4ICswLDAgQEAKLS8qLQotICogQ29weXJpZ2h0IChjKSAyMDExIE5hdGhhbiBXaGl0ZWhvcm4K LSAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuCi0gKgotICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBp biBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0Ci0gKiBtb2RpZmljYXRp b24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMK LSAqIGFyZSBtZXQ6Ci0gKiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCBy ZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAotICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29u ZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgotICogMi4gUmVkaXN0cmlidXRp b25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKLSAq ICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlz Y2xhaW1lciBpbiB0aGUKLSAqICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFs cyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCi0gKgotICogVEhJUyBTT0ZUV0FSRSBJ UyBQUk9WSURFRCBCWSBUSEUgQVVUSE9SIEFORCBDT05UUklCVVRPUlMgYGBBUyBJUycnIEFORAot ICogQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1Qg TElNSVRFRCBUTywgVEhFCi0gKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZ IEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRQotICogQVJFIERJU0NMQUlNRUQu ICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgQVVUSE9SIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUK LSAqIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBM QVJZLCBPUiBDT05TRVFVRU5USUFMCi0gKiBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElN SVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUwotICogT1IgU0VSVklDRVM7 IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04p Ci0gKiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRI RVIgSU4gQ09OVFJBQ1QsIFNUUklDVAotICogTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcg TkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWQotICogT1VUIE9GIFRI RSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElU WSBPRgotICogU1VDSCBEQU1BR0UuCi0gKi8KLQotI2luY2x1ZGUgPHN5cy9jZGVmcy5oPgotX19G QlNESUQoIiRGcmVlQlNEJCIpOwotI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgotI2luY2x1ZGUgPHN5 cy9zeXN0bS5oPgotI2luY2x1ZGUgPHN5cy9tb2R1bGUuaD4KLSNpbmNsdWRlIDxzeXMvYnVzLmg+ Ci0jaW5jbHVkZSA8c3lzL2NvbmYuaD4KLSNpbmNsdWRlIDxzeXMva2VybmVsLmg+Ci0KLSNpbmNs dWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+Ci0jaW5jbHVkZSA8ZGV2L29mdy9vZndfcGNpLmg+Ci0j aW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzLmg+Ci0jaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzX3N1 YnIuaD4KLQotI2luY2x1ZGUgPGRldi9wY2kvcGNpdmFyLmg+Ci0jaW5jbHVkZSA8ZGV2L3BjaS9w Y2lyZWcuaD4KLQotI2luY2x1ZGUgPG1hY2hpbmUvYnVzLmg+Ci0jaW5jbHVkZSA8bWFjaGluZS9p bnRyX21hY2hkZXAuaD4KLSNpbmNsdWRlIDxtYWNoaW5lL21kX3Zhci5oPgotI2luY2x1ZGUgPG1h Y2hpbmUvcGlvLmg+Ci0jaW5jbHVkZSA8bWFjaGluZS9yZXNvdXJjZS5oPgotCi0jaW5jbHVkZSA8 c3lzL3JtYW4uaD4KLQotI2luY2x1ZGUgPHZtL3ZtLmg+Ci0jaW5jbHVkZSA8dm0vcG1hcC5oPgot Ci0jaW5jbHVkZSA8cG93ZXJwYy9vZncvb2Z3X3BjaS5oPgotCi0jaW5jbHVkZSAicGNpYl9pZi5o IgotCi0vKgotICogQnVzIGludGVyZmFjZS4KLSAqLwotc3RhdGljIGludAkJb2Z3X3BjaV9yZWFk X2l2YXIoZGV2aWNlX3QsIGRldmljZV90LCBpbnQsCi0JCQkgICAgdWludHB0cl90ICopOwotc3Rh dGljIHN0cnVjdAkJcmVzb3VyY2UgKiBvZndfcGNpX2FsbG9jX3Jlc291cmNlKGRldmljZV90IGJ1 cywKLQkJCSAgICBkZXZpY2VfdCBjaGlsZCwgaW50IHR5cGUsIGludCAqcmlkLCBybWFuX3Jlc190 IHN0YXJ0LAotCQkJICAgIHJtYW5fcmVzX3QgZW5kLCBybWFuX3Jlc190IGNvdW50LCB1X2ludCBm bGFncyk7Ci1zdGF0aWMgaW50CQlvZndfcGNpX3JlbGVhc2VfcmVzb3VyY2UoZGV2aWNlX3QgYnVz LCBkZXZpY2VfdCBjaGlsZCwKLSAgICAJCQkgICAgaW50IHR5cGUsIGludCByaWQsIHN0cnVjdCBy ZXNvdXJjZSAqcmVzKTsKLXN0YXRpYyBpbnQJCW9md19wY2lfYWN0aXZhdGVfcmVzb3VyY2UoZGV2 aWNlX3QgYnVzLCBkZXZpY2VfdCBjaGlsZCwKLQkJCSAgICBpbnQgdHlwZSwgaW50IHJpZCwgc3Ry dWN0IHJlc291cmNlICpyZXMpOwotc3RhdGljIGludAkJb2Z3X3BjaV9kZWFjdGl2YXRlX3Jlc291 cmNlKGRldmljZV90IGJ1cywKLSAgICAJCQkgICAgZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLCBp bnQgcmlkLAotICAgIAkJCSAgICBzdHJ1Y3QgcmVzb3VyY2UgKnJlcyk7Ci1zdGF0aWMgaW50CQlv ZndfcGNpX2FkanVzdF9yZXNvdXJjZShkZXZpY2VfdCBidXMsIGRldmljZV90IGNoaWxkLAotCQkJ ICAgIGludCB0eXBlLCBzdHJ1Y3QgcmVzb3VyY2UgKnJlcywgcm1hbl9yZXNfdCBzdGFydCwKLQkJ CSAgICBybWFuX3Jlc190IGVuZCk7Ci0KLS8qCi0gKiBwY2liIGludGVyZmFjZS4KLSAqLwotc3Rh dGljIGludAkJb2Z3X3BjaV9tYXhzbG90cyhkZXZpY2VfdCk7Ci1zdGF0aWMgaW50CQlvZndfcGNp X3JvdXRlX2ludGVycnVwdChkZXZpY2VfdCwgZGV2aWNlX3QsIGludCk7Ci0KLS8qCi0gKiBvZndf YnVzIGludGVyZmFjZQotICovCi1zdGF0aWMgcGhhbmRsZV90IG9md19wY2lfZ2V0X25vZGUoZGV2 aWNlX3QgYnVzLCBkZXZpY2VfdCBkZXYpOwotCi0vKgotICogbG9jYWwgbWV0aG9kcwotICovCi0K LXN0YXRpYyBpbnQgb2Z3X3BjaV9ucmFuZ2VzKHBoYW5kbGVfdCBub2RlKTsKLXN0YXRpYyBpbnQg b2Z3X3BjaV9maWxsX3JhbmdlcyhwaGFuZGxlX3Qgbm9kZSwgc3RydWN0IG9md19wY2lfcmFuZ2Ug KnJhbmdlcyk7Ci0KLS8qCi0gKiBEcml2ZXIgbWV0aG9kcy4KLSAqLwotc3RhdGljIGRldmljZV9t ZXRob2RfdAlvZndfcGNpX21ldGhvZHNbXSA9IHsKLQkvKiBEZXZpY2UgaW50ZXJmYWNlICovCi0J REVWTUVUSE9EKGRldmljZV9hdHRhY2gsCW9md19wY2lfYXR0YWNoKSwKLQotCS8qIEJ1cyBpbnRl cmZhY2UgKi8KLQlERVZNRVRIT0QoYnVzX3ByaW50X2NoaWxkLAlidXNfZ2VuZXJpY19wcmludF9j aGlsZCksCi0JREVWTUVUSE9EKGJ1c19yZWFkX2l2YXIsCW9md19wY2lfcmVhZF9pdmFyKSwKLQlE RVZNRVRIT0QoYnVzX3NldHVwX2ludHIsCWJ1c19nZW5lcmljX3NldHVwX2ludHIpLAotCURFVk1F VEhPRChidXNfdGVhcmRvd25faW50ciwJYnVzX2dlbmVyaWNfdGVhcmRvd25faW50ciksCi0JREVW TUVUSE9EKGJ1c19hbGxvY19yZXNvdXJjZSwJb2Z3X3BjaV9hbGxvY19yZXNvdXJjZSksCi0JREVW TUVUSE9EKGJ1c19yZWxlYXNlX3Jlc291cmNlLAlvZndfcGNpX3JlbGVhc2VfcmVzb3VyY2UpLAot CURFVk1FVEhPRChidXNfYWN0aXZhdGVfcmVzb3VyY2UsCW9md19wY2lfYWN0aXZhdGVfcmVzb3Vy Y2UpLAotCURFVk1FVEhPRChidXNfZGVhY3RpdmF0ZV9yZXNvdXJjZSwJb2Z3X3BjaV9kZWFjdGl2 YXRlX3Jlc291cmNlKSwKLQlERVZNRVRIT0QoYnVzX2FkanVzdF9yZXNvdXJjZSwJb2Z3X3BjaV9h ZGp1c3RfcmVzb3VyY2UpLAotCi0JLyogcGNpYiBpbnRlcmZhY2UgKi8KLQlERVZNRVRIT0QocGNp Yl9tYXhzbG90cywJb2Z3X3BjaV9tYXhzbG90cyksCi0JREVWTUVUSE9EKHBjaWJfcm91dGVfaW50 ZXJydXB0LAlvZndfcGNpX3JvdXRlX2ludGVycnVwdCksCi0KLQkvKiBvZndfYnVzIGludGVyZmFj ZSAqLwotCURFVk1FVEhPRChvZndfYnVzX2dldF9ub2RlLCAgICAgb2Z3X3BjaV9nZXRfbm9kZSks Ci0KLQlERVZNRVRIT0RfRU5ECi19OwotCi1ERUZJTkVfQ0xBU1NfMChvZndfcGNpLCBvZndfcGNp X2RyaXZlciwgb2Z3X3BjaV9tZXRob2RzLCAwKTsKLQotaW50Ci1vZndfcGNpX2luaXQoZGV2aWNl X3QgZGV2KQotewotCXN0cnVjdAkJb2Z3X3BjaV9zb2Z0YyAqc2M7Ci0JcGhhbmRsZV90CW5vZGU7 Ci0JdV9pbnQzMl90CWJ1c3JhbmdlWzJdOwotCXN0cnVjdAkJb2Z3X3BjaV9yYW5nZSAqcnA7Ci0J aW50CQllcnJvcjsKLQotCW5vZGUgPSBvZndfYnVzX2dldF9ub2RlKGRldik7Ci0Jc2MgPSBkZXZp Y2VfZ2V0X3NvZnRjKGRldik7Ci0Jc2MtPnNjX2luaXRpYWxpemVkID0gMTsKLQotCWlmIChPRl9n ZXRlbmNwcm9wKG5vZGUsICJidXMtcmFuZ2UiLCBidXNyYW5nZSwgc2l6ZW9mKGJ1c3JhbmdlKSkg IT0gOCkKLQkJYnVzcmFuZ2VbMF0gPSAwOwotCi0Jc2MtPnNjX2RldiA9IGRldjsKLQlzYy0+c2Nf bm9kZSA9IG5vZGU7Ci0Jc2MtPnNjX2J1cyA9IGJ1c3JhbmdlWzBdOwotCi0JaWYgKHNjLT5zY19x dWlya3MgJiBPRldfUENJX1FVSVJLX1JBTkdFU19PTl9DSElMRFJFTikgewotCQlwaGFuZGxlX3Qg YzsKLQkJaW50IG4sIGk7Ci0JCQotCQlzYy0+c2NfbnJhbmdlID0gMDsKLQkJZm9yIChjID0gT0Zf Y2hpbGQobm9kZSk7IGMgIT0gMDsgYyA9IE9GX3BlZXIoYykpIHsKLQkJCW4gPSBvZndfcGNpX25y YW5nZXMoYyk7Ci0JCQlpZiAobiA+IDApCi0JCQkJc2MtPnNjX25yYW5nZSArPSBuOwotCQl9Ci0J CWlmIChzYy0+c2NfbnJhbmdlID09IDApCi0JCQlyZXR1cm4gKEVOWElPKTsKLQkJc2MtPnNjX3Jh bmdlID0gbWFsbG9jKHNjLT5zY19ucmFuZ2UgKiBzaXplb2Yoc2MtPnNjX3JhbmdlWzBdKSwKLQkJ ICAgIE1fREVWQlVGLCBNX1dBSVRPSyk7Ci0JCWkgPSAwOwotCQlmb3IgKGMgPSBPRl9jaGlsZChu b2RlKTsgYyAhPSAwOyBjID0gT0ZfcGVlcihjKSkgewotCQkJbiA9IG9md19wY2lfZmlsbF9yYW5n ZXMoYywgJnNjLT5zY19yYW5nZVtpXSk7Ci0JCQlpZiAobiA+IDApCi0JCQkJaSArPSBuOwotCQl9 Ci0JCUtBU1NFUlQoaSA9PSBzYy0+c2NfbnJhbmdlLCAoInJhbmdlIGNvdW50IG1pc21hdGNoIikp OwotCX0gZWxzZSB7Ci0JCXNjLT5zY19ucmFuZ2UgPSBvZndfcGNpX25yYW5nZXMobm9kZSk7Ci0J CWlmIChzYy0+c2NfbnJhbmdlIDw9IDApIHsKLQkJCWRldmljZV9wcmludGYoZGV2LCAiY291bGQg bm90IGdldCByYW5nZXNcbiIpOwotCQkJcmV0dXJuIChFTlhJTyk7Ci0JCX0KLQkJc2MtPnNjX3Jh bmdlID0gbWFsbG9jKHNjLT5zY19ucmFuZ2UgKiBzaXplb2Yoc2MtPnNjX3JhbmdlWzBdKSwKLQkJ ICAgIE1fREVWQlVGLCBNX1dBSVRPSyk7Ci0JCW9md19wY2lfZmlsbF9yYW5nZXMobm9kZSwgc2Mt PnNjX3JhbmdlKTsKLQl9Ci0JCQotCXNjLT5zY19pb19ybWFuLnJtX3R5cGUgPSBSTUFOX0FSUkFZ OwotCXNjLT5zY19pb19ybWFuLnJtX2Rlc2NyID0gIlBDSSBJL08gUG9ydHMiOwotCWVycm9yID0g cm1hbl9pbml0KCZzYy0+c2NfaW9fcm1hbik7Ci0JaWYgKGVycm9yKSB7Ci0JCWRldmljZV9wcmlu dGYoZGV2LCAicm1hbl9pbml0KCkgZmFpbGVkLiBlcnJvciA9ICVkXG4iLCBlcnJvcik7Ci0JCXJl dHVybiAoZXJyb3IpOwotCX0KLQotCXNjLT5zY19tZW1fcm1hbi5ybV90eXBlID0gUk1BTl9BUlJB WTsKLQlzYy0+c2NfbWVtX3JtYW4ucm1fZGVzY3IgPSAiUENJIE1lbW9yeSI7Ci0JZXJyb3IgPSBy bWFuX2luaXQoJnNjLT5zY19tZW1fcm1hbik7Ci0JaWYgKGVycm9yKSB7Ci0JCWRldmljZV9wcmlu dGYoZGV2LCAicm1hbl9pbml0KCkgZmFpbGVkLiBlcnJvciA9ICVkXG4iLCBlcnJvcik7Ci0JCXJl dHVybiAoZXJyb3IpOwotCX0KLQotCWZvciAocnAgPSBzYy0+c2NfcmFuZ2U7IHJwIDwgc2MtPnNj X3JhbmdlICsgc2MtPnNjX25yYW5nZSAmJgotCSAgICAgICBycC0+cGNpX2hpICE9IDA7IHJwKysp IHsKLQkJZXJyb3IgPSAwOwotCi0JCXN3aXRjaCAocnAtPnBjaV9oaSAmIE9GV19QQ0lfUEhZU19I SV9TUEFDRU1BU0spIHsKLQkJY2FzZSBPRldfUENJX1BIWVNfSElfU1BBQ0VfQ09ORklHOgotCQkJ YnJlYWs7Ci0JCWNhc2UgT0ZXX1BDSV9QSFlTX0hJX1NQQUNFX0lPOgotCQkJZXJyb3IgPSBybWFu X21hbmFnZV9yZWdpb24oJnNjLT5zY19pb19ybWFuLCBycC0+cGNpLAotCQkJICAgIHJwLT5wY2kg KyBycC0+c2l6ZSAtIDEpOwotCQkJYnJlYWs7Ci0JCWNhc2UgT0ZXX1BDSV9QSFlTX0hJX1NQQUNF X01FTTMyOgotCQljYXNlIE9GV19QQ0lfUEhZU19ISV9TUEFDRV9NRU02NDoKLQkJCWVycm9yID0g cm1hbl9tYW5hZ2VfcmVnaW9uKCZzYy0+c2NfbWVtX3JtYW4sIHJwLT5wY2ksCi0JCQkgICAgcnAt PnBjaSArIHJwLT5zaXplIC0gMSk7Ci0JCQlicmVhazsKLQkJfQotCi0JCWlmIChlcnJvcikgewot CQkJZGV2aWNlX3ByaW50ZihkZXYsIAotCQkJICAgICJybWFuX21hbmFnZV9yZWdpb24oJXgsICUj angsICUjangpIGZhaWxlZC4gIgotCQkJICAgICJlcnJvciA9ICVkXG4iLCBycC0+cGNpX2hpICYK LQkJCSAgICBPRldfUENJX1BIWVNfSElfU1BBQ0VNQVNLLCBycC0+cGNpLAotCQkJICAgIHJwLT5w Y2kgKyBycC0+c2l6ZSAtIDEsIGVycm9yKTsKLQkJCXJldHVybiAoZXJyb3IpOwotCQl9Ci0JfQot Ci0Jb2Z3X2J1c19zZXR1cF9paW5mbyhub2RlLCAmc2MtPnNjX3BjaV9paW5mbywgc2l6ZW9mKGNl bGxfdCkpOwotCi0JcmV0dXJuIChlcnJvcik7Ci19Ci0KLWludAotb2Z3X3BjaV9hdHRhY2goZGV2 aWNlX3QgZGV2KQotewotCXN0cnVjdCBvZndfcGNpX3NvZnRjICpzYzsKLQlpbnQgZXJyb3I7Ci0K LQlzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKLQlpZiAoIXNjLT5zY19pbml0aWFsaXplZCkg ewotCQllcnJvciA9IG9md19wY2lfaW5pdChkZXYpOwotCQlpZiAoZXJyb3IpCi0JCQlyZXR1cm4g KGVycm9yKTsKLQl9Ci0KLQlkZXZpY2VfYWRkX2NoaWxkKGRldiwgInBjaSIsIC0xKTsKLQlyZXR1 cm4gKGJ1c19nZW5lcmljX2F0dGFjaChkZXYpKTsKLX0KLQotc3RhdGljIGludAotb2Z3X3BjaV9t YXhzbG90cyhkZXZpY2VfdCBkZXYpCi17Ci0KLQlyZXR1cm4gKFBDSV9TTE9UTUFYKTsKLX0KLQot c3RhdGljIGludAotb2Z3X3BjaV9yb3V0ZV9pbnRlcnJ1cHQoZGV2aWNlX3QgYnVzLCBkZXZpY2Vf dCBkZXYsIGludCBwaW4pCi17Ci0Jc3RydWN0IG9md19wY2lfc29mdGMgKnNjOwotCXN0cnVjdCBv ZndfcGNpX3JlZ2lzdGVyIHJlZzsKLQl1aW50MzJfdCBwaW50ciwgbWludHJbMl07Ci0JaW50IGlu dHJjZWxsczsKLQlwaGFuZGxlX3QgaXBhcmVudDsKLQotCXNjID0gZGV2aWNlX2dldF9zb2Z0Yyhi dXMpOwotCXBpbnRyID0gcGluOwotCi0JLyogRmFicmljYXRlIGltYXAgaW5mb3JtYXRpb24gaW4g Y2FzZSB0aGlzIGlzbid0IGFuIE9GVyBkZXZpY2UgKi8KLQliemVybygmcmVnLCBzaXplb2YocmVn KSk7Ci0JcmVnLnBoeXNfaGkgPSAocGNpX2dldF9idXMoZGV2KSA8PCBPRldfUENJX1BIWVNfSElf QlVTU0hJRlQpIHwKLQkgICAgKHBjaV9nZXRfc2xvdChkZXYpIDw8IE9GV19QQ0lfUEhZU19ISV9E RVZJQ0VTSElGVCkgfAotCSAgICAocGNpX2dldF9mdW5jdGlvbihkZXYpIDw8IE9GV19QQ0lfUEhZ U19ISV9GVU5DVElPTlNISUZUKTsKLQotCWludHJjZWxscyA9IG9md19idXNfbG9va3VwX2ltYXAo b2Z3X2J1c19nZXRfbm9kZShkZXYpLAotCSAgICAmc2MtPnNjX3BjaV9paW5mbywgJnJlZywgc2l6 ZW9mKHJlZyksICZwaW50ciwgc2l6ZW9mKHBpbnRyKSwKLQkgICAgbWludHIsIHNpemVvZihtaW50 ciksICZpcGFyZW50KTsKLQlpZiAoaW50cmNlbGxzKSB7Ci0JCXBpbnRyID0gb2Z3X2J1c19tYXBf aW50cihkZXYsIGlwYXJlbnQsIGludHJjZWxscywgbWludHIpOwotCQlyZXR1cm4gKHBpbnRyKTsK LQl9Ci0KLQkvKiBNYXliZSBpdCdzIGEgcmVhbCBpbnRlcnJ1cHQsIG5vdCBhbiBpbnRwaW4gKi8K LQlpZiAocGluID4gNCkKLQkJcmV0dXJuIChwaW4pOwotCi0JZGV2aWNlX3ByaW50ZihidXMsICJj b3VsZCBub3Qgcm91dGUgcGluICVkIGZvciBkZXZpY2UgJWQuJWRcbiIsCi0JICAgIHBpbiwgcGNp X2dldF9zbG90KGRldiksIHBjaV9nZXRfZnVuY3Rpb24oZGV2KSk7Ci0JcmV0dXJuIChQQ0lfSU5W QUxJRF9JUlEpOwotfQotCi1zdGF0aWMgaW50Ci1vZndfcGNpX3JlYWRfaXZhcihkZXZpY2VfdCBk ZXYsIGRldmljZV90IGNoaWxkLCBpbnQgd2hpY2gsIHVpbnRwdHJfdCAqcmVzdWx0KQotewotCXN0 cnVjdAlvZndfcGNpX3NvZnRjICpzYzsKLQotCXNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOwot Ci0Jc3dpdGNoICh3aGljaCkgewotCWNhc2UgUENJQl9JVkFSX0RPTUFJTjoKLQkJKnJlc3VsdCA9 IGRldmljZV9nZXRfdW5pdChkZXYpOwotCQlyZXR1cm4gKDApOwotCWNhc2UgUENJQl9JVkFSX0JV UzoKLQkJKnJlc3VsdCA9IHNjLT5zY19idXM7Ci0JCXJldHVybiAoMCk7Ci0JfQotCi0JcmV0dXJu IChFTk9FTlQpOwotfQotCi1zdGF0aWMgc3RydWN0IHJlc291cmNlICoKLW9md19wY2lfYWxsb2Nf cmVzb3VyY2UoZGV2aWNlX3QgYnVzLCBkZXZpY2VfdCBjaGlsZCwgaW50IHR5cGUsIGludCAqcmlk LAotICAgIHJtYW5fcmVzX3Qgc3RhcnQsIHJtYW5fcmVzX3QgZW5kLCBybWFuX3Jlc190IGNvdW50 LCB1X2ludCBmbGFncykKLXsKLQlzdHJ1Y3QJCQlvZndfcGNpX3NvZnRjICpzYzsKLQlzdHJ1Y3QJ CQlyZXNvdXJjZSAqcnY7Ci0Jc3RydWN0CQkJcm1hbiAqcm07Ci0JaW50CQkJbmVlZGFjdGl2YXRl OwotCi0JbmVlZGFjdGl2YXRlID0gZmxhZ3MgJiBSRl9BQ1RJVkU7Ci0JZmxhZ3MgJj0gflJGX0FD VElWRTsKLQotCXNjID0gZGV2aWNlX2dldF9zb2Z0YyhidXMpOwotCi0Jc3dpdGNoICh0eXBlKSB7 Ci0JY2FzZSBTWVNfUkVTX01FTU9SWToKLQkJcm0gPSAmc2MtPnNjX21lbV9ybWFuOwotCQlicmVh azsKLQotCWNhc2UgU1lTX1JFU19JT1BPUlQ6Ci0JCXJtID0gJnNjLT5zY19pb19ybWFuOwotCQli cmVhazsKLQotCWNhc2UgU1lTX1JFU19JUlE6Ci0JCXJldHVybiAoYnVzX2FsbG9jX3Jlc291cmNl KGJ1cywgdHlwZSwgcmlkLCBzdGFydCwgZW5kLCBjb3VudCwKLQkJICAgIGZsYWdzKSk7Ci0KLQlk ZWZhdWx0OgotCQlkZXZpY2VfcHJpbnRmKGJ1cywgInVua25vd24gcmVzb3VyY2UgcmVxdWVzdCBm cm9tICVzXG4iLAotCQkgICAgZGV2aWNlX2dldF9uYW1ldW5pdChjaGlsZCkpOwotCQlyZXR1cm4g KE5VTEwpOwotCX0KLQotCXJ2ID0gcm1hbl9yZXNlcnZlX3Jlc291cmNlKHJtLCBzdGFydCwgZW5k LCBjb3VudCwgZmxhZ3MsIGNoaWxkKTsKLQlpZiAocnYgPT0gTlVMTCkgewotCQlkZXZpY2VfcHJp bnRmKGJ1cywgImZhaWxlZCB0byByZXNlcnZlIHJlc291cmNlIGZvciAlc1xuIiwKLQkJICAgIGRl dmljZV9nZXRfbmFtZXVuaXQoY2hpbGQpKTsKLQkJcmV0dXJuIChOVUxMKTsKLQl9Ci0KLQlybWFu X3NldF9yaWQocnYsICpyaWQpOwotCi0JaWYgKG5lZWRhY3RpdmF0ZSkgewotCQlpZiAoYnVzX2Fj dGl2YXRlX3Jlc291cmNlKGNoaWxkLCB0eXBlLCAqcmlkLCBydikgIT0gMCkgewotCQkJZGV2aWNl X3ByaW50ZihidXMsCi0JCQkgICAgImZhaWxlZCB0byBhY3RpdmF0ZSByZXNvdXJjZSBmb3IgJXNc biIsCi0JCQkgICAgZGV2aWNlX2dldF9uYW1ldW5pdChjaGlsZCkpOwotCQkJcm1hbl9yZWxlYXNl X3Jlc291cmNlKHJ2KTsKLQkJCXJldHVybiAoTlVMTCk7Ci0JCX0KLQl9Ci0KLQlyZXR1cm4gKHJ2 KTsKLX0KLQotc3RhdGljIGludAotb2Z3X3BjaV9yZWxlYXNlX3Jlc291cmNlKGRldmljZV90IGJ1 cywgZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLCBpbnQgcmlkLAotICAgIHN0cnVjdCByZXNvdXJj ZSAqcmVzKQotewotCWlmIChybWFuX2dldF9mbGFncyhyZXMpICYgUkZfQUNUSVZFKSB7Ci0JCWlu dCBlcnJvciA9IGJ1c19kZWFjdGl2YXRlX3Jlc291cmNlKGNoaWxkLCB0eXBlLCByaWQsIHJlcyk7 Ci0JCWlmIChlcnJvcikKLQkJCXJldHVybiBlcnJvcjsKLQl9Ci0KLQlyZXR1cm4gKHJtYW5fcmVs ZWFzZV9yZXNvdXJjZShyZXMpKTsKLX0KLQotc3RhdGljIGludAotb2Z3X3BjaV9hY3RpdmF0ZV9y ZXNvdXJjZShkZXZpY2VfdCBidXMsIGRldmljZV90IGNoaWxkLCBpbnQgdHlwZSwgaW50IHJpZCwK LSAgICBzdHJ1Y3QgcmVzb3VyY2UgKnJlcykKLXsKLQlzdHJ1Y3Qgb2Z3X3BjaV9zb2Z0YyAqc2M7 Ci0Jdm9pZAkqcDsKLQotCXNjID0gZGV2aWNlX2dldF9zb2Z0YyhidXMpOwotCi0JaWYgKHR5cGUg PT0gU1lTX1JFU19JUlEpIHsKLQkJcmV0dXJuIChidXNfYWN0aXZhdGVfcmVzb3VyY2UoYnVzLCB0 eXBlLCByaWQsIHJlcykpOwotCX0KLQlpZiAodHlwZSA9PSBTWVNfUkVTX01FTU9SWSB8fCB0eXBl ID09IFNZU19SRVNfSU9QT1JUKSB7Ci0JCXN0cnVjdCBvZndfcGNpX3JhbmdlICpycDsKLQkJdm1f b2Zmc2V0X3Qgc3RhcnQ7Ci0JCWludCBzcGFjZTsKLQotCQlzdGFydCA9ICh2bV9vZmZzZXRfdCly bWFuX2dldF9zdGFydChyZXMpOwotCi0JCS8qCi0JCSAqIE1hcCB0aGlzIHRocm91Z2ggdGhlIHJh bmdlcyBsaXN0Ci0JCSAqLwotCQlmb3IgKHJwID0gc2MtPnNjX3JhbmdlOyBycCA8IHNjLT5zY19y YW5nZSArIHNjLT5zY19ucmFuZ2UgJiYKLQkJICAgICAgIHJwLT5wY2lfaGkgIT0gMDsgcnArKykg ewotCQkJaWYgKHN0YXJ0IDwgcnAtPnBjaSB8fCBzdGFydCA+PSBycC0+cGNpICsgcnAtPnNpemUp Ci0JCQkJY29udGludWU7Ci0KLQkJCXN3aXRjaCAocnAtPnBjaV9oaSAmIE9GV19QQ0lfUEhZU19I SV9TUEFDRU1BU0spIHsKLQkJCWNhc2UgT0ZXX1BDSV9QSFlTX0hJX1NQQUNFX0lPOgotCQkJCXNw YWNlID0gU1lTX1JFU19JT1BPUlQ7Ci0JCQkJYnJlYWs7Ci0JCQljYXNlIE9GV19QQ0lfUEhZU19I SV9TUEFDRV9NRU0zMjoKLQkJCWNhc2UgT0ZXX1BDSV9QSFlTX0hJX1NQQUNFX01FTTY0OgotCQkJ CXNwYWNlID0gU1lTX1JFU19NRU1PUlk7Ci0JCQkJYnJlYWs7Ci0JCQlkZWZhdWx0OgotCQkJCXNw YWNlID0gLTE7Ci0JCQl9Ci0KLQkJCWlmICh0eXBlID09IHNwYWNlKSB7Ci0JCQkJc3RhcnQgKz0g KHJwLT5ob3N0IC0gcnAtPnBjaSk7Ci0JCQkJYnJlYWs7Ci0JCQl9Ci0JCX0KLQotCQlpZiAoYm9v dHZlcmJvc2UpCi0JCQlwcmludGYoIm9md19wY2kgbWFwZGV2OiBzdGFydCAlengsIGxlbiAlbGRc biIsIHN0YXJ0LAotCQkJICAgIHJtYW5fZ2V0X3NpemUocmVzKSk7Ci0KLQkJcCA9IHBtYXBfbWFw ZGV2KHN0YXJ0LCAodm1fc2l6ZV90KXJtYW5fZ2V0X3NpemUocmVzKSk7Ci0JCWlmIChwID09IE5V TEwpCi0JCQlyZXR1cm4gKEVOT01FTSk7Ci0KLQkJcm1hbl9zZXRfdmlydHVhbChyZXMsIHApOwot CQlybWFuX3NldF9idXN0YWcocmVzLCAmYnNfbGVfdGFnKTsKLQkJcm1hbl9zZXRfYnVzaGFuZGxl KHJlcywgKHVfbG9uZylwKTsKLQl9Ci0KLQlyZXR1cm4gKHJtYW5fYWN0aXZhdGVfcmVzb3VyY2Uo cmVzKSk7Ci19Ci0KLXN0YXRpYyBpbnQKLW9md19wY2lfZGVhY3RpdmF0ZV9yZXNvdXJjZShkZXZp Y2VfdCBidXMsIGRldmljZV90IGNoaWxkLCBpbnQgdHlwZSwgaW50IHJpZCwKLSAgICBzdHJ1Y3Qg cmVzb3VyY2UgKnJlcykKLXsKLQkvKgotCSAqIElmIHRoaXMgaXMgYSBtZW1vcnkgcmVzb3VyY2Us IHVubWFwIGl0LgotCSAqLwotCWlmICgodHlwZSA9PSBTWVNfUkVTX01FTU9SWSkgfHwgKHR5cGUg PT0gU1lTX1JFU19JT1BPUlQpKSB7Ci0JCXVfaW50MzJfdCBwc2l6ZTsKLQotCQlwc2l6ZSA9IHJt YW5fZ2V0X3NpemUocmVzKTsKLQkJcG1hcF91bm1hcGRldigodm1fb2Zmc2V0X3Qpcm1hbl9nZXRf dmlydHVhbChyZXMpLCBwc2l6ZSk7Ci0JfQotCi0JcmV0dXJuIChybWFuX2RlYWN0aXZhdGVfcmVz b3VyY2UocmVzKSk7Ci19Ci0KLXN0YXRpYyBpbnQKLW9md19wY2lfYWRqdXN0X3Jlc291cmNlKGRl dmljZV90IGJ1cywgZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLAotICAgIHN0cnVjdCByZXNvdXJj ZSAqcmVzLCBybWFuX3Jlc190IHN0YXJ0LCBybWFuX3Jlc190IGVuZCkKLXsKLQlzdHJ1Y3Qgcm1h biAqcm0gPSBOVUxMOwotCXN0cnVjdCBvZndfcGNpX3NvZnRjICpzYyA9IGRldmljZV9nZXRfc29m dGMoYnVzKTsKLQotCUtBU1NFUlQoIShybWFuX2dldF9mbGFncyhyZXMpICYgUkZfQUNUSVZFKSwK LQkgICAgKCJhY3RpdmUgcmVzb3VyY2VzIGNhbm5vdCBiZSBhZGp1c3RlZCIpKTsKLQlpZiAocm1h bl9nZXRfZmxhZ3MocmVzKSAmIFJGX0FDVElWRSkKLQkJcmV0dXJuIChFSU5WQUwpOwotCi0Jc3dp dGNoICh0eXBlKSB7Ci0JY2FzZSBTWVNfUkVTX01FTU9SWToKLQkJcm0gPSAmc2MtPnNjX21lbV9y bWFuOwotCQlicmVhazsKLQljYXNlIFNZU19SRVNfSU9QT1JUOgotCQlybSA9ICZzYy0+c2NfaW9f cm1hbjsKLQkJYnJlYWs7Ci0JZGVmYXVsdDoKLQkJcmV0dXJuIChFTlhJTyk7Ci0JfQotCi0JaWYg KCFybWFuX2lzX3JlZ2lvbl9tYW5hZ2VyKHJlcywgcm0pKQotCQlyZXR1cm4gKEVJTlZBTCk7Ci0K LQlyZXR1cm4gKHJtYW5fYWRqdXN0X3Jlc291cmNlKHJlcywgc3RhcnQsIGVuZCkpOwotfQotCQot Ci1zdGF0aWMgcGhhbmRsZV90Ci1vZndfcGNpX2dldF9ub2RlKGRldmljZV90IGJ1cywgZGV2aWNl X3QgZGV2KQotewotCXN0cnVjdCBvZndfcGNpX3NvZnRjICpzYzsKLQotCXNjID0gZGV2aWNlX2dl dF9zb2Z0YyhidXMpOwotCS8qIFdlIG9ubHkgaGF2ZSBvbmUgY2hpbGQsIHRoZSBQQ0kgYnVzLCB3 aGljaCBuZWVkcyBvdXIgb3duIG5vZGUuICovCi0KLQlyZXR1cm4gKHNjLT5zY19ub2RlKTsKLX0K LQotc3RhdGljIGludAotb2Z3X3BjaV9ucmFuZ2VzKHBoYW5kbGVfdCBub2RlKQotewotCWludCBo b3N0X2FkZHJlc3NfY2VsbHMgPSAxLCBwY2lfYWRkcmVzc19jZWxscyA9IDMsIHNpemVfY2VsbHMg PSAyOwotCXNzaXplX3QgbmJhc2VfcmFuZ2VzOwotCi0JT0ZfZ2V0ZW5jcHJvcChPRl9wYXJlbnQo bm9kZSksICIjYWRkcmVzcy1jZWxscyIsICZob3N0X2FkZHJlc3NfY2VsbHMsCi0JICAgIHNpemVv Zihob3N0X2FkZHJlc3NfY2VsbHMpKTsKLQlPRl9nZXRlbmNwcm9wKG5vZGUsICIjYWRkcmVzcy1j ZWxscyIsICZwY2lfYWRkcmVzc19jZWxscywKLQkgICAgc2l6ZW9mKHBjaV9hZGRyZXNzX2NlbGxz KSk7Ci0JT0ZfZ2V0ZW5jcHJvcChub2RlLCAiI3NpemUtY2VsbHMiLCAmc2l6ZV9jZWxscywgc2l6 ZW9mKHNpemVfY2VsbHMpKTsKLQotCW5iYXNlX3JhbmdlcyA9IE9GX2dldHByb3BsZW4obm9kZSwg InJhbmdlcyIpOwotCWlmIChuYmFzZV9yYW5nZXMgPD0gMCkKLQkJcmV0dXJuICgtMSk7Ci0KLQly ZXR1cm4gKG5iYXNlX3JhbmdlcyAvIHNpemVvZihjZWxsX3QpIC8KLQkgICAgKHBjaV9hZGRyZXNz X2NlbGxzICsgaG9zdF9hZGRyZXNzX2NlbGxzICsgc2l6ZV9jZWxscykpOwotfQotCi1zdGF0aWMg aW50Ci1vZndfcGNpX2ZpbGxfcmFuZ2VzKHBoYW5kbGVfdCBub2RlLCBzdHJ1Y3Qgb2Z3X3BjaV9y YW5nZSAqcmFuZ2VzKQotewotCWludCBob3N0X2FkZHJlc3NfY2VsbHMgPSAxLCBwY2lfYWRkcmVz c19jZWxscyA9IDMsIHNpemVfY2VsbHMgPSAyOwotCWNlbGxfdCAqYmFzZV9yYW5nZXM7Ci0Jc3Np emVfdCBuYmFzZV9yYW5nZXM7Ci0JaW50IG5yYW5nZXM7Ci0JaW50IGksIGosIGs7Ci0KLQlPRl9n ZXRlbmNwcm9wKE9GX3BhcmVudChub2RlKSwgIiNhZGRyZXNzLWNlbGxzIiwgJmhvc3RfYWRkcmVz c19jZWxscywKLQkgICAgc2l6ZW9mKGhvc3RfYWRkcmVzc19jZWxscykpOwotCU9GX2dldGVuY3By b3Aobm9kZSwgIiNhZGRyZXNzLWNlbGxzIiwgJnBjaV9hZGRyZXNzX2NlbGxzLAotCSAgICBzaXpl b2YocGNpX2FkZHJlc3NfY2VsbHMpKTsKLQlPRl9nZXRlbmNwcm9wKG5vZGUsICIjc2l6ZS1jZWxs cyIsICZzaXplX2NlbGxzLCBzaXplb2Yoc2l6ZV9jZWxscykpOwotCi0JbmJhc2VfcmFuZ2VzID0g T0ZfZ2V0cHJvcGxlbihub2RlLCAicmFuZ2VzIik7Ci0JaWYgKG5iYXNlX3JhbmdlcyA8PSAwKQot CQlyZXR1cm4gKC0xKTsKLQlucmFuZ2VzID0gbmJhc2VfcmFuZ2VzIC8gc2l6ZW9mKGNlbGxfdCkg LwotCSAgICAocGNpX2FkZHJlc3NfY2VsbHMgKyBob3N0X2FkZHJlc3NfY2VsbHMgKyBzaXplX2Nl bGxzKTsKLQotCWJhc2VfcmFuZ2VzID0gbWFsbG9jKG5iYXNlX3JhbmdlcywgTV9ERVZCVUYsIE1f V0FJVE9LKTsKLQlPRl9nZXRlbmNwcm9wKG5vZGUsICJyYW5nZXMiLCBiYXNlX3JhbmdlcywgbmJh c2VfcmFuZ2VzKTsKLQotCWZvciAoaSA9IDAsIGogPSAwOyBpIDwgbnJhbmdlczsgaSsrKSB7Ci0J CXJhbmdlc1tpXS5wY2lfaGkgPSBiYXNlX3Jhbmdlc1tqKytdOwotCQlyYW5nZXNbaV0ucGNpID0g MDsKLQkJZm9yIChrID0gMDsgayA8IHBjaV9hZGRyZXNzX2NlbGxzIC0gMTsgaysrKSB7Ci0JCQly YW5nZXNbaV0ucGNpIDw8PSAzMjsKLQkJCXJhbmdlc1tpXS5wY2kgfD0gYmFzZV9yYW5nZXNbaisr XTsKLQkJfQotCQlyYW5nZXNbaV0uaG9zdCA9IDA7Ci0JCWZvciAoayA9IDA7IGsgPCBob3N0X2Fk ZHJlc3NfY2VsbHM7IGsrKykgewotCQkJcmFuZ2VzW2ldLmhvc3QgPDw9IDMyOwotCQkJcmFuZ2Vz W2ldLmhvc3QgfD0gYmFzZV9yYW5nZXNbaisrXTsKLQkJfQotCQlyYW5nZXNbaV0uc2l6ZSA9IDA7 Ci0JCWZvciAoayA9IDA7IGsgPCBzaXplX2NlbGxzOyBrKyspIHsKLQkJCXJhbmdlc1tpXS5zaXpl IDw8PSAzMjsKLQkJCXJhbmdlc1tpXS5zaXplIHw9IGJhc2VfcmFuZ2VzW2orK107Ci0JCX0KLQl9 Ci0KLQlmcmVlKGJhc2VfcmFuZ2VzLCBNX0RFVkJVRik7Ci0JcmV0dXJuIChucmFuZ2VzKTsKLX0K LQpkaWZmIC0tZ2l0IGEvc3lzL3Bvd2VycGMvb2Z3L29md19wY2kuaCBiL3N5cy9wb3dlcnBjL29m dy9vZndfcGNpLmgKZGVsZXRlZCBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IGRiODgzZDQuLjAwMDAw MDAKLS0tIGEvc3lzL3Bvd2VycGMvb2Z3L29md19wY2kuaAorKysgL2Rldi9udWxsCkBAIC0xLDc0 ICswLDAgQEAKLS8qLQotICogQ29weXJpZ2h0IChjKSAyMDExIE5hdGhhbiBXaGl0ZWhvcm4KLSAq IEFsbCByaWdodHMgcmVzZXJ2ZWQuCi0gKgotICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBz b3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0Ci0gKiBtb2RpZmljYXRpb24s IGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKLSAq IGFyZSBtZXQ6Ci0gKiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRh aW4gdGhlIGFib3ZlIGNvcHlyaWdodAotICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0 aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgotICogMi4gUmVkaXN0cmlidXRpb25z IGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKLSAqICAg IG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xh aW1lciBpbiB0aGUKLSAqICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBw cm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCi0gKgotICogVEhJUyBTT0ZUV0FSRSBJUyBQ Uk9WSURFRCBCWSBUSEUgQVVUSE9SIEFORCBDT05UUklCVVRPUlMgYGBBUyBJUycnIEFORAotICog QU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElN SVRFRCBUTywgVEhFCi0gKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFO RCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRQotICogQVJFIERJU0NMQUlNRUQuICBJ TiBOTyBFVkVOVCBTSEFMTCBUSEUgQVVUSE9SIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUKLSAq IEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZ LCBPUiBDT05TRVFVRU5USUFMCi0gKiBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRF RCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUwotICogT1IgU0VSVklDRVM7IExP U1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pCi0g KiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIg SU4gQ09OVFJBQ1QsIFNUUklDVAotICogTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVH TElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWQotICogT1VUIE9GIFRIRSBV U0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBP RgotICogU1VDSCBEQU1BR0UuCi0gKgotICogJEZyZWVCU0QkCi0gKi8KLQotI2lmbmRlZiBQT1dF UlBDX09GV19PRldfUENJX0gKLSNkZWZpbmUgUE9XRVJQQ19PRldfT0ZXX1BDSV9ICi0KLS8qCi0g KiBFeHBvcnQgY2xhc3MgZGVmaW5pdGlvbiBmb3IgaW5oZXJpdGFuY2UgcHVycG9zZXMKLSAqLwot REVDTEFSRV9DTEFTUyhvZndfcGNpX2RyaXZlcik7Ci0KLXN0cnVjdCBvZndfcGNpX3JhbmdlIHsK LQl1aW50MzJfdAlwY2lfaGk7Ci0JdWludDY0X3QJcGNpOwotCXVpbnQ2NF90CWhvc3Q7Ci0JdWlu dDY0X3QJc2l6ZTsKLX07Ci0KLS8qCi0gKiBRdWlya3MgZm9yIHNvbWUgYWRhcHRlcnMKLSAqLwot ZW51bSB7Ci0JT0ZXX1BDSV9RVUlSS19SQU5HRVNfT05fQ0hJTERSRU4gPSAxLAotfTsKLQotc3Ry dWN0IG9md19wY2lfc29mdGMgewotCWRldmljZV90CQlzY19kZXY7Ci0JcGhhbmRsZV90CQlzY19u b2RlOwotCWludAkJCXNjX2J1czsKLQlpbnQJCQlzY19pbml0aWFsaXplZDsKLQotCWludAkJCXNj X3F1aXJrczsKLQotCXN0cnVjdCBvZndfcGNpX3JhbmdlCSpzY19yYW5nZTsKLQlpbnQJCQlzY19u cmFuZ2U7Ci0KLQlzdHJ1Y3Qgcm1hbgkJc2NfaW9fcm1hbjsKLQlzdHJ1Y3Qgcm1hbgkJc2NfbWVt X3JtYW47Ci0JYnVzX3NwYWNlX3RhZ190CQlzY19tZW10OwotCWJ1c19kbWFfdGFnX3QJCXNjX2Rt YXQ7Ci0KLQlzdHJ1Y3Qgb2Z3X2J1c19paW5mbyAgICBzY19wY2lfaWluZm87Ci19OwotCi1pbnQg b2Z3X3BjaV9pbml0KGRldmljZV90IGRldik7Ci1pbnQgb2Z3X3BjaV9hdHRhY2goZGV2aWNlX3Qg ZGV2KTsKLQotI2VuZGlmIC8vIFBPV0VSUENfT0ZXX09GV19QQ0lfSAotCmRpZmYgLS1naXQgYS9z eXMvcG93ZXJwYy9vZncvb2Z3X3BjaWJfcGNpLmMgYi9zeXMvcG93ZXJwYy9vZncvb2Z3X3BjaWJf cGNpLmMKaW5kZXggODIzZjdjOS4uMWMxMDVmYiAxMDA2NDQKLS0tIGEvc3lzL3Bvd2VycGMvb2Z3 L29md19wY2liX3BjaS5jCisrKyBiL3N5cy9wb3dlcnBjL29mdy9vZndfcGNpYl9wY2kuYwpAQCAt MzYsOSArMzYsOSBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAjaW5jbHVkZSA8c3lzL2tlcm5l bC5oPgogCiAjaW5jbHVkZSA8ZGV2L29mdy9vcGVuZmlybS5oPgotI2luY2x1ZGUgPGRldi9vZncv b2Z3X3BjaS5oPgogI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1cy5oPgogI2luY2x1ZGUgPGRldi9v Zncvb2Z3X2J1c19zdWJyLmg+CisjaW5jbHVkZSA8ZGV2L29mdy9vZndfcGNpLmg+CiAKICNpbmNs dWRlIDxkZXYvcGNpL3BjaXZhci5oPgogI2luY2x1ZGUgPGRldi9wY2kvcGNpcmVnLmg+CmRpZmYg LS1naXQgYS9zeXMvcG93ZXJwYy9vZncvb2Z3X3BjaWJ1cy5jIGIvc3lzL3Bvd2VycGMvb2Z3L29m d19wY2lidXMuYwppbmRleCBjZGUzYzc0Li4xMmFhMjI0IDEwMDY0NAotLS0gYS9zeXMvcG93ZXJw Yy9vZncvb2Z3X3BjaWJ1cy5jCisrKyBiL3N5cy9wb3dlcnBjL29mdy9vZndfcGNpYnVzLmMKQEAg LTU0LDggKzU0LDYgQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwogI2luY2x1ZGUgInBjaWJfaWYu aCIKICNpbmNsdWRlICJwY2lfaWYuaCIKIAotdHlwZWRlZiB1aW50MzJfdCBvZndfcGNpX2ludHJf dDsKLQogLyogTWV0aG9kcyAqLwogc3RhdGljIGRldmljZV9wcm9iZV90IG9md19wY2lidXNfcHJv YmU7CiBzdGF0aWMgZGV2aWNlX2F0dGFjaF90IG9md19wY2lidXNfYXR0YWNoOwpkaWZmIC0tZ2l0 IGEvc3lzL3Bvd2VycGMvb2Z3L29md19wY2lidXMuaCBiL3N5cy9wb3dlcnBjL29mdy9vZndfcGNp YnVzLmgKaW5kZXggYzdiODJkNy4uZmFkNGQ2NiAxMDA2NDQKLS0tIGEvc3lzL3Bvd2VycGMvb2Z3 L29md19wY2lidXMuaAorKysgYi9zeXMvcG93ZXJwYy9vZncvb2Z3X3BjaWJ1cy5oCkBAIC0zMyw2 ICszMyw3IEBACiAjaW5jbHVkZSA8c3lzL3BjaWlvLmg+CiAKICNpbmNsdWRlIDxkZXYvb2Z3L29m d19idXMuaD4KKyNpbmNsdWRlIDxkZXYvb2Z3L29md19idXNfc3Vici5oPgogI2luY2x1ZGUgPGRl di9vZncvb2Z3X3BjaS5oPgogI2luY2x1ZGUgPGRldi9wY2kvcGNpdmFyLmg+CiAKZGlmZiAtLWdp dCBhL3N5cy9wb3dlcnBjL29mdy9vZndfc3lzY29ucy5jIGIvc3lzL3Bvd2VycGMvb2Z3L29md19z eXNjb25zLmMKaW5kZXggYjc2NjQ4NS4uYjQyZjE0MiAxMDA2NDQKLS0tIGEvc3lzL3Bvd2VycGMv b2Z3L29md19zeXNjb25zLmMKKysrIGIvc3lzL3Bvd2VycGMvb2Z3L29md19zeXNjb25zLmMKQEAg LTUzLDYgKzUzLDcgQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwogCiAjaW5jbHVkZSA8ZGV2L29m dy9vcGVuZmlybS5oPgogI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1cy5oPgorI2luY2x1ZGUgPGRl di9vZncvb2Z3X2J1c19zdWJyLmg+CiAjaW5jbHVkZSA8ZGV2L29mdy9vZndfcGNpLmg+CiAjaW5j bHVkZSA8cG93ZXJwYy9vZncvb2Z3X3N5c2NvbnMuaD4KIApkaWZmIC0tZ2l0IGEvc3lzL3Bvd2Vy cGMvcG93ZXJtYWMvY3BjaHQuYyBiL3N5cy9wb3dlcnBjL3Bvd2VybWFjL2NwY2h0LmMKaW5kZXgg NzY1ZDk0Ni4uNzM3ZTg3MiAxMDA2NDQKLS0tIGEvc3lzL3Bvd2VycGMvcG93ZXJtYWMvY3BjaHQu YworKysgYi9zeXMvcG93ZXJwYy9wb3dlcm1hYy9jcGNodC5jCkBAIC0zNiw3ICszNiw2IEBAIF9f RkJTRElEKCIkRnJlZUJTRCQiKTsKICNpbmNsdWRlIDxzeXMvcm1hbi5oPgogCiAjaW5jbHVkZSA8 ZGV2L29mdy9vcGVuZmlybS5oPgotI2luY2x1ZGUgPGRldi9vZncvb2Z3X3BjaS5oPgogCiAjaW5j bHVkZSA8ZGV2L3BjaS9wY2l2YXIuaD4KICNpbmNsdWRlIDxkZXYvcGNpL3BjaXJlZy5oPgpAQCAt NTEsNyArNTAsNyBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAKICNpbmNsdWRlIDxkZXYvb2Z3 L29md19idXMuaD4KICNpbmNsdWRlIDxkZXYvb2Z3L29md19idXNfc3Vici5oPgotI2luY2x1ZGUg PHBvd2VycGMvb2Z3L29md19wY2kuaD4KKyNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KIAog I2luY2x1ZGUgPHZtL3ZtLmg+CiAjaW5jbHVkZSA8dm0vcG1hcC5oPgpkaWZmIC0tZ2l0IGEvc3lz L3Bvd2VycGMvcG93ZXJtYWMvZ3JhY2tsZS5jIGIvc3lzL3Bvd2VycGMvcG93ZXJtYWMvZ3JhY2ts ZS5jCmluZGV4IDk1ZDU5YTEuLmYwOTI4ZjMgMTAwNjQ0Ci0tLSBhL3N5cy9wb3dlcnBjL3Bvd2Vy bWFjL2dyYWNrbGUuYworKysgYi9zeXMvcG93ZXJwYy9wb3dlcm1hYy9ncmFja2xlLmMKQEAgLTM3 LDkgKzM3LDkgQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwogI2luY2x1ZGUgPHN5cy9wcm9jLmg+ CiAKICNpbmNsdWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+Ci0jaW5jbHVkZSA8ZGV2L29mdy9vZndf cGNpLmg+CiAjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzLmg+CiAjaW5jbHVkZSA8ZGV2L29mdy9v ZndfYnVzX3N1YnIuaD4KKyNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KIAogI2luY2x1ZGUg PGRldi9wY2kvcGNpdmFyLmg+CiAjaW5jbHVkZSA8ZGV2L3BjaS9wY2lyZWcuaD4KQEAgLTUyLDcg KzUyLDYgQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwogCiAjaW5jbHVkZSA8c3lzL3JtYW4uaD4K IAotI2luY2x1ZGUgPHBvd2VycGMvb2Z3L29md19wY2kuaD4KICNpbmNsdWRlIDxwb3dlcnBjL3Bv d2VybWFjL2dyYWNrbGV2YXIuaD4KIAogI2luY2x1ZGUgPHZtL3ZtLmg+CmRpZmYgLS1naXQgYS9z eXMvcG93ZXJwYy9wb3dlcm1hYy91bmlub3J0aC5jIGIvc3lzL3Bvd2VycGMvcG93ZXJtYWMvdW5p bm9ydGguYwppbmRleCBlMzRjOWQ4Li4zNTc5MjRhIDEwMDY0NAotLS0gYS9zeXMvcG93ZXJwYy9w b3dlcm1hYy91bmlub3J0aC5jCisrKyBiL3N5cy9wb3dlcnBjL3Bvd2VybWFjL3VuaW5vcnRoLmMK QEAgLTMzLDkgKzMzLDkgQEAKICNpbmNsdWRlIDxzeXMva2VybmVsLmg+CiAKICNpbmNsdWRlIDxk ZXYvb2Z3L29wZW5maXJtLmg+Ci0jaW5jbHVkZSA8ZGV2L29mdy9vZndfcGNpLmg+CiAjaW5jbHVk ZSA8ZGV2L29mdy9vZndfYnVzLmg+CiAjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzX3N1YnIuaD4K KyNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KIAogI2luY2x1ZGUgPGRldi9wY2kvcGNpdmFy Lmg+CiAjaW5jbHVkZSA8ZGV2L3BjaS9wY2lyZWcuaD4KZGlmZiAtLWdpdCBhL3N5cy9wb3dlcnBj L3Bvd2VybWFjL3VuaW5vcnRocGNpLmMgYi9zeXMvcG93ZXJwYy9wb3dlcm1hYy91bmlub3J0aHBj aS5jCmluZGV4IDlkYTA2ZmYuLjVjYjIxYzEgMTAwNjQ0Ci0tLSBhL3N5cy9wb3dlcnBjL3Bvd2Vy bWFjL3VuaW5vcnRocGNpLmMKKysrIGIvc3lzL3Bvd2VycGMvcG93ZXJtYWMvdW5pbm9ydGhwY2ku YwpAQCAtMzQsOSArMzQsOSBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAjaW5jbHVkZSA8c3lz L2tlcm5lbC5oPgogCiAjaW5jbHVkZSA8ZGV2L29mdy9vcGVuZmlybS5oPgotI2luY2x1ZGUgPGRl di9vZncvb2Z3X3BjaS5oPgogI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1cy5oPgogI2luY2x1ZGUg PGRldi9vZncvb2Z3X2J1c19zdWJyLmg+CisjaW5jbHVkZSA8ZGV2L29mdy9vZndfcGNpLmg+CiAK ICNpbmNsdWRlIDxkZXYvcGNpL3BjaXZhci5oPgogI2luY2x1ZGUgPGRldi9wY2kvcGNpcmVnLmg+ CkBAIC00OSw3ICs0OSw2IEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKIAogI2luY2x1ZGUgPHN5 cy9ybWFuLmg+CiAKLSNpbmNsdWRlIDxwb3dlcnBjL29mdy9vZndfcGNpLmg+CiAjaW5jbHVkZSA8 cG93ZXJwYy9wb3dlcm1hYy91bmlub3J0aHZhci5oPgogCiAjaW5jbHVkZSA8dm0vdm0uaD4KZGlm ZiAtLWdpdCBhL3N5cy9wb3dlcnBjL3Bvd2VybWFjL3VuaW5vcnRodmFyLmggYi9zeXMvcG93ZXJw Yy9wb3dlcm1hYy91bmlub3J0aHZhci5oCmluZGV4IGUwODQ3OGQuLmVmZTE2OWMgMTAwNjQ0Ci0t LSBhL3N5cy9wb3dlcnBjL3Bvd2VybWFjL3VuaW5vcnRodmFyLmgKKysrIGIvc3lzL3Bvd2VycGMv cG93ZXJtYWMvdW5pbm9ydGh2YXIuaApAQCAtMzAsNyArMzAsNiBAQAogCiAjaW5jbHVkZSA8ZGV2 L29mdy9vZndfYnVzX3N1YnIuaD4KICNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KLSNpbmNs dWRlIDxwb3dlcnBjL29mdy9vZndfcGNpLmg+CiAKIHN0cnVjdCB1bmlub3J0aF9zb2Z0YyB7CiAJ c3RydWN0IG9md19wY2lfc29mdGMJcGNpX3NjOwpkaWZmIC0tZ2l0IGEvc3lzL3Bvd2VycGMvcHNl cmllcy9ydGFzX3BjaS5jIGIvc3lzL3Bvd2VycGMvcHNlcmllcy9ydGFzX3BjaS5jCmluZGV4IGJi NzJiNzEuLjEzNDhmYzggMTAwNjQ0Ci0tLSBhL3N5cy9wb3dlcnBjL3BzZXJpZXMvcnRhc19wY2ku YworKysgYi9zeXMvcG93ZXJwYy9wc2VyaWVzL3J0YXNfcGNpLmMKQEAgLTM0LDkgKzM0LDkgQEAg X19GQlNESUQoIiRGcmVlQlNEJCIpOwogI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4KIAogI2luY2x1 ZGUgPGRldi9vZncvb3BlbmZpcm0uaD4KLSNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KICNp bmNsdWRlIDxkZXYvb2Z3L29md19idXMuaD4KICNpbmNsdWRlIDxkZXYvb2Z3L29md19idXNfc3Vi ci5oPgorI2luY2x1ZGUgPGRldi9vZncvb2Z3X3BjaS5oPgogCiAjaW5jbHVkZSA8ZGV2L3BjaS9w Y2l2YXIuaD4KICNpbmNsdWRlIDxkZXYvcGNpL3BjaXJlZy5oPgpAQCAtNTMsNyArNTMsNiBAQCBf X0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAjaW5jbHVkZSA8dm0vdm0uaD4KICNpbmNsdWRlIDx2bS9w bWFwLmg+CiAKLSNpbmNsdWRlIDxwb3dlcnBjL29mdy9vZndfcGNpLmg+CiAjaW5jbHVkZSA8cG93 ZXJwYy9wc2VyaWVzL3BscGFyX2lvbW11Lmg+CiAKICNpbmNsdWRlICJwY2liX2lmLmgiCmRpZmYg LS1naXQgYS9zeXMvc3BhcmM2NC9lYnVzL2VidXMuYyBiL3N5cy9zcGFyYzY0L2VidXMvZWJ1cy5j CmluZGV4IGE1M2IyMGIuLjZmNzA1YWQgMTAwNjQ0Ci0tLSBhL3N5cy9zcGFyYzY0L2VidXMvZWJ1 cy5jCisrKyBiL3N5cy9zcGFyYzY0L2VidXMvZWJ1cy5jCkBAIC03NCw2ICs3NCw3IEBAIF9fRkJT RElEKCIkRnJlZUJTRCQiKTsKICNpbmNsdWRlIDxkZXYvb2Z3L29md19idXMuaD4KICNpbmNsdWRl IDxkZXYvb2Z3L29md19idXNfc3Vici5oPgogI2luY2x1ZGUgPGRldi9vZncvb3BlbmZpcm0uaD4K KyNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KIAogI2luY2x1ZGUgPG1hY2hpbmUvYnVzLmg+ CiAjaWZuZGVmIFNVTjRWCkBAIC04NSw4ICs4Niw2IEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsK ICNpbmNsdWRlIDxkZXYvcGNpL3BjaXJlZy5oPgogI2luY2x1ZGUgPGRldi9wY2kvcGNpdmFyLmg+ CiAKLSNpbmNsdWRlIDxzcGFyYzY0L3BjaS9vZndfcGNpLmg+Ci0KIC8qCiAgKiBUaGUgcmVnaXN0 ZXIsIGludGVycnVwdCBtYXAgYW5kIGZvciB0aGUgUENJIHZhcmlhbnQgYWxzbyB0aGUgcmFuZ2Vz CiAgKiBwcm9wZXJ0aWVzIGFyZSBpZGVudGljYWwgdG8gdGhlIElTQSBvbmVzLgpkaWZmIC0tZ2l0 IGEvc3lzL3NwYXJjNjQvaXNhL2lzYS5jIGIvc3lzL3NwYXJjNjQvaXNhL2lzYS5jCmluZGV4IDc0 NjI3YzUuLmNlY2NiOGEgMTAwNjQ0Ci0tLSBhL3N5cy9zcGFyYzY0L2lzYS9pc2EuYworKysgYi9z eXMvc3BhcmM2NC9pc2EvaXNhLmMKQEAgLTQ0LDEzICs0NCwxNCBAQCBfX0ZCU0RJRCgiJEZyZWVC U0QkIik7CiAKICNpbmNsdWRlIDxkZXYvb2Z3L29md19idXMuaD4KICNpbmNsdWRlIDxkZXYvb2Z3 L29wZW5maXJtLmg+CisjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzX3N1YnIuaD4KKyNpbmNsdWRl IDxkZXYvb2Z3L29md19wY2kuaD4KIAogI2luY2x1ZGUgPG1hY2hpbmUvcmVzb3VyY2UuaD4KIAog I2luY2x1ZGUgPGRldi9wY2kvcGNpcmVnLmg+CiAjaW5jbHVkZSA8ZGV2L3BjaS9wY2l2YXIuaD4K IAotI2luY2x1ZGUgPHNwYXJjNjQvcGNpL29md19wY2kuaD4KICNpbmNsdWRlIDxzcGFyYzY0L2lz YS9vZndfaXNhLmg+CiAKIC8qIFRoZXJlIGNhbiBiZSBvbmx5IG9uZSBJU0EgYnVzLCBzbyBpdCBp cyBzYWZlIHRvIHVzZSBnbG9iYWxzLiAqLwpkaWZmIC0tZ2l0IGEvc3lzL3NwYXJjNjQvaXNhL29m d19pc2EuYyBiL3N5cy9zcGFyYzY0L2lzYS9vZndfaXNhLmMKaW5kZXggZGJlNWQ4YS4uMmJlODk0 ZCAxMDA2NDQKLS0tIGEvc3lzL3NwYXJjNjQvaXNhL29md19pc2EuYworKysgYi9zeXMvc3BhcmM2 NC9pc2Evb2Z3X2lzYS5jCkBAIC02NSwxNCArNjUsMTUgQEAgX19GQlNESUQoIiRGcmVlQlNEJCIp OwogI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgogI2luY2x1ZGUgPHN5cy9zeXN0bS5oPgogI2luY2x1 ZGUgPHN5cy9idXMuaD4KKyNpbmNsdWRlIDxzeXMvcm1hbi5oPgogCiAjaW5jbHVkZSA8ZGV2L29m dy9vZndfYnVzX3N1YnIuaD4KICNpbmNsdWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+CisjaW5jbHVk ZSA8ZGV2L29mdy9vZndfcGNpLmg+CiAKICNpbmNsdWRlIDxtYWNoaW5lL2J1cy5oPgogI2luY2x1 ZGUgPG1hY2hpbmUvcmVzb3VyY2UuaD4KIAotI2luY2x1ZGUgPHNwYXJjNjQvcGNpL29md19wY2ku aD4KICNpbmNsdWRlIDxzcGFyYzY0L2lzYS9vZndfaXNhLmg+CiAKICNpbmNsdWRlICJwY2liX2lm LmgiCkBAIC04Myw5ICs4NCw5IEBAIG9md19pc2FfcmFuZ2VfcmVzdHlwZShzdHJ1Y3QgaXNhX3Jh bmdlcyAqcmFuZ2UpCiAJaW50IHBzID0gSVNBX1JBTkdFX1BTKHJhbmdlKTsKIAogCXN3aXRjaCAo cHMpIHsKLQljYXNlIE9GV19QQ0lfQ1NfSU86CisJY2FzZSBPRldfUENJX0lPOgogCQlyZXR1cm4g KFNZU19SRVNfSU9QT1JUKTsKLQljYXNlIE9GV19QQ0lfQ1NfTUVNMzI6CisJY2FzZSBPRldfUENJ X01FTTMyOgogCQlyZXR1cm4gKFNZU19SRVNfTUVNT1JZKTsKIAlkZWZhdWx0OgogCQlwYW5pYygi b2Z3X2lzYV9yYW5nZV9yZXN0eXBlOiBpbGxlZ2FsIHNwYWNlICV4IiwgcHMpOwpkaWZmIC0tZ2l0 IGEvc3lzL3NwYXJjNjQvcGNpL2FwYi5jIGIvc3lzL3NwYXJjNjQvcGNpL2FwYi5jCmluZGV4IGJh MzY0M2MuLmY3MDllOWEgMTAwNjQ0Ci0tLSBhL3N5cy9zcGFyYzY0L3BjaS9hcGIuYworKysgYi9z eXMvc3BhcmM2NC9wY2kvYXBiLmMKQEAgLTUzLDYgKzUzLDggQEAgX19GQlNESUQoIiRGcmVlQlNE JCIpOwogCiAjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzLmg+CiAjaW5jbHVkZSA8ZGV2L29mdy9v cGVuZmlybS5oPgorI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1c19zdWJyLmg+CisjaW5jbHVkZSA8 ZGV2L29mdy9vZndfcGNpLmg+CiAKICNpbmNsdWRlIDxtYWNoaW5lL2J1cy5oPgogI2luY2x1ZGUg PG1hY2hpbmUvcmVzb3VyY2UuaD4KQEAgLTYzLDcgKzY1LDYgQEAgX19GQlNESUQoIiRGcmVlQlNE JCIpOwogCiAjaW5jbHVkZSAicGNpYl9pZi5oIgogCi0jaW5jbHVkZSA8c3BhcmM2NC9wY2kvb2Z3 X3BjaS5oPgogI2luY2x1ZGUgPHNwYXJjNjQvcGNpL29md19wY2liX3N1YnIuaD4KIAogLyoKZGlm ZiAtLWdpdCBhL3N5cy9zcGFyYzY0L3BjaS9maXJlLmMgYi9zeXMvc3BhcmM2NC9wY2kvZmlyZS5j CmluZGV4IGUwNmFkNTAuLmJkNzk1ZDIgMTAwNjQ0Ci0tLSBhL3N5cy9zcGFyYzY0L3BjaS9maXJl LmMKKysrIGIvc3lzL3NwYXJjNjQvcGNpL2ZpcmUuYwpAQCAtNjAsNiArNjAsOCBAQCBfX0ZCU0RJ RCgiJEZyZWVCU0QkIik7CiAKICNpbmNsdWRlIDxkZXYvb2Z3L29md19idXMuaD4KICNpbmNsdWRl IDxkZXYvb2Z3L29wZW5maXJtLmg+CisjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzX3N1YnIuaD4K KyNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KIAogI2luY2x1ZGUgPHZtL3ZtLmg+CiAjaW5j bHVkZSA8dm0vcG1hcC5oPgpAQCAtNzQsNyArNzYsNiBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7 CiAjaW5jbHVkZSA8ZGV2L3BjaS9wY2lyZWcuaD4KICNpbmNsdWRlIDxkZXYvcGNpL3BjaXZhci5o PgogCi0jaW5jbHVkZSA8c3BhcmM2NC9wY2kvb2Z3X3BjaS5oPgogI2luY2x1ZGUgPHNwYXJjNjQv cGNpL2ZpcmVyZWcuaD4KICNpbmNsdWRlIDxzcGFyYzY0L3BjaS9maXJldmFyLmg+CiAKQEAgLTEz Niw4ICsxMzcsOCBAQCBzdGF0aWMgZGV2aWNlX21ldGhvZF90IGZpcmVfbWV0aG9kc1tdID0gewog CURFVk1FVEhPRChidXNfc2V0dXBfaW50ciwJZmlyZV9zZXR1cF9pbnRyKSwKIAlERVZNRVRIT0Qo YnVzX3RlYXJkb3duX2ludHIsCWZpcmVfdGVhcmRvd25faW50ciksCiAJREVWTUVUSE9EKGJ1c19h bGxvY19yZXNvdXJjZSwJZmlyZV9hbGxvY19yZXNvdXJjZSksCi0JREVWTUVUSE9EKGJ1c19hY3Rp dmF0ZV9yZXNvdXJjZSwgb2Z3X3BjaV9hY3RpdmF0ZV9yZXNvdXJjZSksCi0JREVWTUVUSE9EKGJ1 c19kZWFjdGl2YXRlX3Jlc291cmNlLCBidXNfZ2VuZXJpY19kZWFjdGl2YXRlX3Jlc291cmNlKSwK KwlERVZNRVRIT0QoYnVzX2FjdGl2YXRlX3Jlc291cmNlLCAgIHNwYXJjNjRfb2Z3X3BjaV9hY3Rp dmF0ZV9yZXNvdXJjZSksCisJREVWTUVUSE9EKGJ1c19kZWFjdGl2YXRlX3Jlc291cmNlLCBzcGFy YzY0X29md19wY2lfZGVhY3RpdmF0ZV9yZXNvdXJjZSksCiAJREVWTUVUSE9EKGJ1c19hZGp1c3Rf cmVzb3VyY2UsCW9md19wY2lfYWRqdXN0X3Jlc291cmNlKSwKIAlERVZNRVRIT0QoYnVzX3JlbGVh c2VfcmVzb3VyY2UsCWJ1c19nZW5lcmljX3JlbGVhc2VfcmVzb3VyY2UpLAogCURFVk1FVEhPRChi dXNfZ2V0X2RtYV90YWcsCW9md19wY2lfZ2V0X2RtYV90YWcpLApkaWZmIC0tZ2l0IGEvc3lzL3Nw YXJjNjQvcGNpL29md19wY2kuYyBiL3N5cy9zcGFyYzY0L3BjaS9vZndfcGNpLmMKZGVsZXRlZCBm aWxlIG1vZGUgMTAwNjQ0CmluZGV4IDhiYWJkNDkuLjAwMDAwMDAKLS0tIGEvc3lzL3NwYXJjNjQv cGNpL29md19wY2kuYworKysgL2Rldi9udWxsCkBAIC0xLDQwNiArMCwwIEBACi0vKi0KLSAqIENv cHlyaWdodCAoYykgMTk5OSwgMjAwMCBNYXR0aGV3IFIuIEdyZWVuCi0gKiBDb3B5cmlnaHQgKGMp IDIwMDEgLSAyMDAzIGJ5IFRob21hcyBNb2VzdGwgPHRtbUBGcmVlQlNELm9yZz4KLSAqIENvcHly aWdodCAoYykgMjAwNSAtIDIwMTUgYnkgTWFyaXVzIFN0cm9ibCA8bWFyaXVzQEZyZWVCU0Qub3Jn PgotICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KLSAqCi0gKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNl IGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKLSAqIG1vZGlmaWNh dGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9u cwotICogYXJlIG1ldDoKLSAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0 IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0Ci0gKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBj b25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCi0gKiAyLiBSZWRpc3RyaWJ1 dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAot ICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBk aXNjbGFpbWVyIGluIHRoZQotICogICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJp YWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KLSAqIDMuIFRoZSBuYW1lIG9mIHRo ZSBhdXRob3IgbWF5IG5vdCBiZSB1c2VkIHRvIGVuZG9yc2Ugb3IgcHJvbW90ZSBwcm9kdWN0cwot ICogICAgZGVyaXZlZCBmcm9tIHRoaXMgc29mdHdhcmUgd2l0aG91dCBzcGVjaWZpYyBwcmlvciB3 cml0dGVuIHBlcm1pc3Npb24uCi0gKgotICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBU SEUgQVVUSE9SIGBgQVMgSVMnJyBBTkQgQU5ZIEVYUFJFU1MgT1IKLSAqIElNUExJRUQgV0FSUkFO VElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRSBJTVBMSUVEIFdBUlJBTlRJ RVMKLSAqIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBV UlBPU0UgQVJFIERJU0NMQUlNRUQuCi0gKiBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgQVVUSE9SIEJF IExJQUJMRSBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsCi0gKiBJTkNJREVOVEFMLCBTUEVDSUFM LCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwgREFNQUdFUyAoSU5DTFVESU5HLAotICogQlVU IE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTIE9SIFNFUlZJ Q0VTOwotICogTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVS UlVQVElPTikgSE9XRVZFUiBDQVVTRUQKLSAqIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElU WSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUIExJQUJJTElUWSwKLSAqIE9SIFRPUlQgKElO Q0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCi0gKiBP VVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBP U1NJQklMSVRZIE9GCi0gKiBTVUNIIERBTUFHRS4KLSAqCi0gKglmcm9tOiBOZXRCU0Q6IHBzeWNo by5jLHYgMS4zNSAyMDAxLzA5LzEwIDE2OjE3OjA2IGVlaCBFeHAKLSAqLwotCi0jaW5jbHVkZSA8 c3lzL2NkZWZzLmg+Ci1fX0ZCU0RJRCgiJEZyZWVCU0QkIik7Ci0KLSNpbmNsdWRlICJvcHRfb2Z3 X3BjaS5oIgotCi0jaW5jbHVkZSA8c3lzL3BhcmFtLmg+Ci0jaW5jbHVkZSA8c3lzL3N5c3RtLmg+ Ci0jaW5jbHVkZSA8c3lzL2J1cy5oPgotI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4KLSNpbmNsdWRl IDxzeXMvcm1hbi5oPgotCi0jaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzLmg+Ci0jaW5jbHVkZSA8 ZGV2L29mdy9vZndfcGNpLmg+Ci0jaW5jbHVkZSA8ZGV2L29mdy9vcGVuZmlybS5oPgotCi0jaW5j bHVkZSA8ZGV2L3BjaS9wY2lyZWcuaD4KLSNpbmNsdWRlIDxkZXYvcGNpL3BjaXZhci5oPgotCi0j aW5jbHVkZSA8bWFjaGluZS9hc2kuaD4KLSNpbmNsdWRlIDxtYWNoaW5lL2J1cy5oPgotI2luY2x1 ZGUgPG1hY2hpbmUvYnVzX3ByaXZhdGUuaD4KLSNpbmNsdWRlIDxtYWNoaW5lL2NwdWZ1bmMuaD4K LSNpbmNsdWRlIDxtYWNoaW5lL2Zzci5oPgotI2luY2x1ZGUgPG1hY2hpbmUvcmVzb3VyY2UuaD4K LQotI2luY2x1ZGUgPHNwYXJjNjQvcGNpL29md19wY2kuaD4KLQotaW50Ci1vZndfcGNpX2F0dGFj aF9jb21tb24oZGV2aWNlX3QgZGV2LCBidXNfZG1hX3RhZ190IGRtYXQsIHVfbG9uZyBpb3NpemUs Ci0gICAgdV9sb25nIG1lbXNpemUpCi17Ci0Jc3RydWN0IG9md19wY2lfc29mdGMgKnNjOwotCXN0 cnVjdCBvZndfcGNpX3JhbmdlcyAqcmFuZ2U7Ci0JcGhhbmRsZV90IG5vZGU7Ci0JdWludDMyX3Qg cHJvcF9hcnJheVsyXTsKLQl1X2ludCBpLCBqLCBucmFuZ2U7Ci0KLQlzYyA9IGRldmljZV9nZXRf c29mdGMoZGV2KTsKLQlub2RlID0gb2Z3X2J1c19nZXRfbm9kZShkZXYpOwotCXNjLT5zY19ub2Rl ID0gbm9kZTsKLQlzYy0+c2NfcGNpX2RtYXQgPSBkbWF0OwotCi0JLyogSW5pdGlhbGl6ZSBtZW1v cnkgYW5kIEkvTyBybWFucy4gKi8KLQlzYy0+c2NfcGNpX2lvX3JtYW4ucm1fdHlwZSA9IFJNQU5f QVJSQVk7Ci0Jc2MtPnNjX3BjaV9pb19ybWFuLnJtX2Rlc2NyID0gIlBDSSBJL08gUG9ydHMiOwot CWlmIChybWFuX2luaXQoJnNjLT5zY19wY2lfaW9fcm1hbikgIT0gMCB8fAotCSAgICBybWFuX21h bmFnZV9yZWdpb24oJnNjLT5zY19wY2lfaW9fcm1hbiwgMCwgaW9zaXplKSAhPSAwKSB7Ci0JCWRl dmljZV9wcmludGYoZGV2LCAiZmFpbGVkIHRvIHNldCB1cCBJL08gcm1hblxuIik7Ci0JCXJldHVy biAoRU5YSU8pOwotCX0KLQlzYy0+c2NfcGNpX21lbV9ybWFuLnJtX3R5cGUgPSBSTUFOX0FSUkFZ OwotCXNjLT5zY19wY2lfbWVtX3JtYW4ucm1fZGVzY3IgPSAiUENJIE1lbW9yeSI7Ci0JaWYgKHJt YW5faW5pdCgmc2MtPnNjX3BjaV9tZW1fcm1hbikgIT0gMCB8fAotCSAgICBybWFuX21hbmFnZV9y ZWdpb24oJnNjLT5zY19wY2lfbWVtX3JtYW4sIDAsIG1lbXNpemUpICE9IDApIHsKLQkJZGV2aWNl X3ByaW50ZihkZXYsICJmYWlsZWQgdG8gc2V0IHVwIG1lbW9yeSBybWFuXG4iKTsKLQkJcmV0dXJu IChFTlhJTyk7Ci0JfQotCi0JLyoKLQkgKiBGaW5kIHRoZSBhZGRyZXNzZXMgb2YgdGhlIHZhcmlv dXMgYnVzIHNwYWNlcy4gIFRoZSBwaHlzaWNhbAotCSAqIHN0YXJ0IGFkZHJlc3NlcyBvZiB0aGUg cmFuZ2VzIGFyZSB0aGUgY29uZmlndXJhdGlvbiwgSS9PIGFuZAotCSAqIG1lbW9yeSBoYW5kbGVz LiAgVGhlcmUgc2hvdWxkIG5vdCBiZSBtdWx0aXBsZSBvbmVzIG9mIG9uZSBraW5kLgotCSAqLwot CW5yYW5nZSA9IE9GX2dldHByb3BfYWxsb2Mobm9kZSwgInJhbmdlcyIsIHNpemVvZigqcmFuZ2Up LAotCSAgICAodm9pZCAqKikmcmFuZ2UpOwotCWZvciAoaSA9IDA7IGkgPCBucmFuZ2U7IGkrKykg ewotCQlqID0gT0ZXX1BDSV9SQU5HRV9DUygmcmFuZ2VbaV0pOwotCQlpZiAoc2MtPnNjX3BjaV9i aFtqXSAhPSAwKSB7Ci0JCQlkZXZpY2VfcHJpbnRmKGRldiwgImR1cGxpY2F0ZSByYW5nZSBmb3Ig c3BhY2UgJWRcbiIsCi0JCQkgICAgaik7Ci0JCQlmcmVlKHJhbmdlLCBNX09GV1BST1ApOwotCQkJ cmV0dXJuIChFSU5WQUwpOwotCQl9Ci0JCXNjLT5zY19wY2lfYmhbal0gPSBPRldfUENJX1JBTkdF X1BIWVMoJnJhbmdlW2ldKTsKLQl9Ci0JZnJlZShyYW5nZSwgTV9PRldQUk9QKTsKLQotCS8qCi0J ICogTWFrZSBzdXJlIHRoYXQgdGhlIGV4cGVjdGVkIHJhbmdlcyBhcmUgYWN0dWFsbHkgcHJlc2Vu dC4KLQkgKiBUaGUgT0ZXX1BDSV9DU19NRU02NCBvbmUgaXMgbm90IGN1cnJlbnRseSB1c2VkLgot CSAqLwotCWlmIChzYy0+c2NfcGNpX2JoW09GV19QQ0lfQ1NfQ09ORklHXSA9PSAwKSB7Ci0JCWRl dmljZV9wcmludGYoZGV2LCAibWlzc2luZyBDT05GSUcgcmFuZ2VcbiIpOwotCQlyZXR1cm4gKEVO WElPKTsKLQl9Ci0JaWYgKHNjLT5zY19wY2lfYmhbT0ZXX1BDSV9DU19JT10gPT0gMCkgewotCQlk ZXZpY2VfcHJpbnRmKGRldiwgIm1pc3NpbmcgSU8gcmFuZ2VcbiIpOwotCQlyZXR1cm4gKEVOWElP KTsKLQl9Ci0JaWYgKHNjLT5zY19wY2lfYmhbT0ZXX1BDSV9DU19NRU0zMl0gPT0gMCkgewotCQlk ZXZpY2VfcHJpbnRmKGRldiwgIm1pc3NpbmcgTUVNMzIgcmFuZ2VcbiIpOwotCQlyZXR1cm4gKEVO WElPKTsKLQl9Ci0KLQkvKiBBbGxvY2F0ZSBvdXIgdGFncy4gKi8KLQlzYy0+c2NfcGNpX2lvdCA9 IHNwYXJjNjRfYWxsb2NfYnVzX3RhZyhOVUxMLCBQQ0lfSU9fQlVTX1NQQUNFKTsKLQlpZiAoc2Mt PnNjX3BjaV9pb3QgPT0gTlVMTCkgewotCQlkZXZpY2VfcHJpbnRmKGRldiwgImNvdWxkIG5vdCBh bGxvY2F0ZSBQQ0kgSS9PIHRhZ1xuIik7Ci0JCXJldHVybiAoRU5YSU8pOwotCX0KLQlzYy0+c2Nf cGNpX2NmZ3QgPSBzcGFyYzY0X2FsbG9jX2J1c190YWcoTlVMTCwgUENJX0NPTkZJR19CVVNfU1BB Q0UpOwotCWlmIChzYy0+c2NfcGNpX2NmZ3QgPT0gTlVMTCkgewotCQlkZXZpY2VfcHJpbnRmKGRl diwKLQkJICAgICJjb3VsZCBub3QgYWxsb2NhdGUgUENJIGNvbmZpZ3VyYXRpb24gc3BhY2UgdGFn XG4iKTsKLQkJcmV0dXJuIChFTlhJTyk7Ci0JfQotCi0JLyoKLQkgKiBHZXQgdGhlIGJ1cyByYW5n ZSBmcm9tIHRoZSBmaXJtd2FyZS4KLQkgKi8KLQlpID0gT0ZfZ2V0cHJvcChub2RlLCAiYnVzLXJh bmdlIiwgKHZvaWQgKilwcm9wX2FycmF5LAotCSAgICBzaXplb2YocHJvcF9hcnJheSkpOwotCWlm IChpID09IC0xKSB7Ci0JCWRldmljZV9wcmludGYoZGV2LCAiY291bGQgbm90IGdldCBidXMtcmFu Z2VcbiIpOwotCQlyZXR1cm4gKEVOWElPKTsKLQl9Ci0JaWYgKGkgIT0gc2l6ZW9mKHByb3BfYXJy YXkpKSB7Ci0JCWRldmljZV9wcmludGYoZGV2LCAiYnJva2VuIGJ1cy1yYW5nZSAoJWQpIiwgaSk7 Ci0JCXJldHVybiAoRUlOVkFMKTsKLQl9Ci0Jc2MtPnNjX3BjaV9zZWNidXMgPSBwcm9wX2FycmF5 WzBdOwotCXNjLT5zY19wY2lfc3ViYnVzID0gcHJvcF9hcnJheVsxXTsKLQlpZiAoYm9vdHZlcmJv c2UgIT0gMCkKLQkJZGV2aWNlX3ByaW50ZihkZXYsICJidXMgcmFuZ2UgJXUgdG8gJXU7IFBDSSBi dXMgJWRcbiIsCi0JCSAgICBzYy0+c2NfcGNpX3NlY2J1cywgc2MtPnNjX3BjaV9zdWJidXMsIHNj LT5zY19wY2lfc2VjYnVzKTsKLQotCW9md19idXNfc2V0dXBfaWluZm8obm9kZSwgJnNjLT5zY19w Y2lfaWluZm8sIHNpemVvZihvZndfcGNpX2ludHJfdCkpOwotCi0JcmV0dXJuICgwKTsKLX0KLQot dWludDMyX3QKLW9md19wY2lfcmVhZF9jb25maWdfY29tbW9uKGRldmljZV90IGRldiwgdV9pbnQg cmVnbWF4LCB1X2xvbmcgb2Zmc2V0LAotICAgIHVfaW50IGJ1cywgdV9pbnQgc2xvdCwgdV9pbnQg ZnVuYywgdV9pbnQgcmVnLCBpbnQgd2lkdGgpCi17Ci0Jc3RydWN0IG9md19wY2lfc29mdGMgKnNj OwotCWJ1c19zcGFjZV9oYW5kbGVfdCBiaDsKLQl1aW50MzJfdCByLCB3cmQ7Ci0JaW50IGk7Ci0J dWludDE2X3Qgc2hydDsKLQl1aW50OF90IGJ5dGU7Ci0KLQlzYyA9IGRldmljZV9nZXRfc29mdGMo ZGV2KTsKLQlpZiAoYnVzIDwgc2MtPnNjX3BjaV9zZWNidXMgfHwgYnVzID4gc2MtPnNjX3BjaV9z dWJidXMgfHwKLQkgICAgc2xvdCA+IFBDSV9TTE9UTUFYIHx8IGZ1bmMgPiBQQ0lfRlVOQ01BWCB8 fCByZWcgPiByZWdtYXgpCi0JCXJldHVybiAoLTEpOwotCi0JYmggPSBzYy0+c2NfcGNpX2JoW09G V19QQ0lfQ1NfQ09ORklHXTsKLQlzd2l0Y2ggKHdpZHRoKSB7Ci0JY2FzZSAxOgotCQlpID0gYnVz X3NwYWNlX3BlZWtfMShzYy0+c2NfcGNpX2NmZ3QsIGJoLCBvZmZzZXQsICZieXRlKTsKLQkJciA9 IGJ5dGU7Ci0JCWJyZWFrOwotCWNhc2UgMjoKLQkJaSA9IGJ1c19zcGFjZV9wZWVrXzIoc2MtPnNj X3BjaV9jZmd0LCBiaCwgb2Zmc2V0LCAmc2hydCk7Ci0JCXIgPSBzaHJ0OwotCQlicmVhazsKLQlj YXNlIDQ6Ci0JCWkgPSBidXNfc3BhY2VfcGVla180KHNjLT5zY19wY2lfY2ZndCwgYmgsIG9mZnNl dCwgJndyZCk7Ci0JCXIgPSB3cmQ7Ci0JCWJyZWFrOwotCWRlZmF1bHQ6Ci0JCXBhbmljKCIlczog YmFkIHdpZHRoICVkIiwgX19mdW5jX18sIHdpZHRoKTsKLQkJLyogTk9UUkVBQ0hFRCAqLwotCX0K LQotCWlmIChpKSB7Ci0jaWZkZWYgT0ZXX1BDSV9ERUJVRwotCQlwcmludGYoIiVzOiByZWFkIGRh dGEgZXJyb3IgcmVhZGluZzogJWQuJWQuJWQ6IDB4JXhcbiIsCi0JCSAgICBfX2Z1bmNfXywgYnVz LCBzbG90LCBmdW5jLCByZWcpOwotI2VuZGlmCi0JCXIgPSAtMTsKLQl9Ci0JcmV0dXJuIChyKTsK LX0KLQotdm9pZAotb2Z3X3BjaV93cml0ZV9jb25maWdfY29tbW9uKGRldmljZV90IGRldiwgdV9p bnQgcmVnbWF4LCB1X2xvbmcgb2Zmc2V0LAotICAgIHVfaW50IGJ1cywgdV9pbnQgc2xvdCwgdV9p bnQgZnVuYywgdV9pbnQgcmVnLCB1aW50MzJfdCB2YWwsIGludCB3aWR0aCkKLXsKLQlzdHJ1Y3Qg b2Z3X3BjaV9zb2Z0YyAqc2M7Ci0JYnVzX3NwYWNlX2hhbmRsZV90IGJoOwotCi0Jc2MgPSBkZXZp Y2VfZ2V0X3NvZnRjKGRldik7Ci0JaWYgKGJ1cyA8IHNjLT5zY19wY2lfc2VjYnVzIHx8IGJ1cyA+ IHNjLT5zY19wY2lfc3ViYnVzIHx8Ci0JICAgIHNsb3QgPiBQQ0lfU0xPVE1BWCB8fCBmdW5jID4g UENJX0ZVTkNNQVggfHwgcmVnID4gcmVnbWF4KQotCQlyZXR1cm47Ci0KLQliaCA9IHNjLT5zY19w Y2lfYmhbT0ZXX1BDSV9DU19DT05GSUddOwotCXN3aXRjaCAod2lkdGgpIHsKLQljYXNlIDE6Ci0J CWJ1c19zcGFjZV93cml0ZV8xKHNjLT5zY19wY2lfY2ZndCwgYmgsIG9mZnNldCwgdmFsKTsKLQkJ YnJlYWs7Ci0JY2FzZSAyOgotCQlidXNfc3BhY2Vfd3JpdGVfMihzYy0+c2NfcGNpX2NmZ3QsIGJo LCBvZmZzZXQsIHZhbCk7Ci0JCWJyZWFrOwotCWNhc2UgNDoKLQkJYnVzX3NwYWNlX3dyaXRlXzQo c2MtPnNjX3BjaV9jZmd0LCBiaCwgb2Zmc2V0LCB2YWwpOwotCQlicmVhazsKLQlkZWZhdWx0Ogot CQlwYW5pYygiJXM6IGJhZCB3aWR0aCAlZCIsIF9fZnVuY19fLCB3aWR0aCk7Ci0JCS8qIE5PVFJF QUNIRUQgKi8KLQl9Ci19Ci0KLW9md19wY2lfaW50cl90Ci1vZndfcGNpX3JvdXRlX2ludGVycnVw dF9jb21tb24oZGV2aWNlX3QgYnJpZGdlLCBkZXZpY2VfdCBkZXYsIGludCBwaW4pCi17Ci0Jc3Ry dWN0IG9md19wY2lfc29mdGMgKnNjOwotCXN0cnVjdCBvZndfcGNpX3JlZ2lzdGVyIHJlZzsKLQlv ZndfcGNpX2ludHJfdCBwaW50ciwgbWludHI7Ci0KLQlzYyA9IGRldmljZV9nZXRfc29mdGMoYnJp ZGdlKTsKLQlwaW50ciA9IHBpbjsKLQlpZiAob2Z3X2J1c19sb29rdXBfaW1hcChvZndfYnVzX2dl dF9ub2RlKGRldiksICZzYy0+c2NfcGNpX2lpbmZvLAotCSAgICAmcmVnLCBzaXplb2YocmVnKSwg JnBpbnRyLCBzaXplb2YocGludHIpLCAmbWludHIsIHNpemVvZihtaW50ciksCi0JICAgIE5VTEwp ICE9IDApCi0JCXJldHVybiAobWludHIpOwotCXJldHVybiAoUENJX0lOVkFMSURfSVJRKTsKLX0K LQotdm9pZAotb2Z3X3BjaV9kbWFtYXBfc3luY19zdHN0X29yZGVyX2NvbW1vbih2b2lkKQotewot CXN0YXRpYyB1X2NoYXIgYnVmW1ZJU19CTE9DS1NJWkVdIF9fYWxpZ25lZChWSVNfQkxPQ0tTSVpF KTsKLQlyZWdpc3Rlcl90IHJlZywgczsKLQotCXMgPSBpbnRyX2Rpc2FibGUoKTsKLQlyZWcgPSBy ZChmcHJzKTsKLQl3cihmcHJzLCByZWcgfCBGUFJTX0ZFRiwgMCk7Ci0JX19hc20gX192b2xhdGls ZSgic3RkYSAlJWYwLCBbJTBdICUxIgotCSAgICA6IDogInIiIChidWYpLCAibiIgKEFTSV9CTEtf Q09NTUlUX1MpKTsKLQltZW1iYXIoU3luYyk7Ci0Jd3IoZnBycywgcmVnLCAwKTsKLQlpbnRyX3Jl c3RvcmUocyk7Ci19Ci0KLWludAotb2Z3X3BjaV9yZWFkX2l2YXIoZGV2aWNlX3QgZGV2LCBkZXZp Y2VfdCBjaGlsZCBfX3VudXNlZCwgaW50IHdoaWNoLAotICAgIHVpbnRwdHJfdCAqcmVzdWx0KQot ewotCXN0cnVjdCBvZndfcGNpX3NvZnRjICpzYzsKLQotCXN3aXRjaCAod2hpY2gpIHsKLQljYXNl IFBDSUJfSVZBUl9ET01BSU46Ci0JCSpyZXN1bHQgPSBkZXZpY2VfZ2V0X3VuaXQoZGV2KTsKLQkJ cmV0dXJuICgwKTsKLQljYXNlIFBDSUJfSVZBUl9CVVM6Ci0JCXNjID0gZGV2aWNlX2dldF9zb2Z0 YyhkZXYpOwotCQkqcmVzdWx0ID0gc2MtPnNjX3BjaV9zZWNidXM7Ci0JCXJldHVybiAoMCk7Ci0J fQotCXJldHVybiAoRU5PRU5UKTsKLX0KLQotc3RydWN0IHJlc291cmNlICoKLW9md19wY2lfYWxs b2NfcmVzb3VyY2UoZGV2aWNlX3QgYnVzLCBkZXZpY2VfdCBjaGlsZCwgaW50IHR5cGUsIGludCAq cmlkLAotICAgIHJtYW5fcmVzX3Qgc3RhcnQsIHJtYW5fcmVzX3QgZW5kLCBybWFuX3Jlc190IGNv dW50LCB1X2ludCBmbGFncykKLXsKLQlzdHJ1Y3Qgb2Z3X3BjaV9zb2Z0YyAqc2M7Ci0Jc3RydWN0 IHJlc291cmNlICpydjsKLQlzdHJ1Y3Qgcm1hbiAqcm07Ci0KLQlzYyA9IGRldmljZV9nZXRfc29m dGMoYnVzKTsKLQlzd2l0Y2ggKHR5cGUpIHsKLQljYXNlIFNZU19SRVNfSVJROgotCQkvKgotCQkg KiBYWFg6IERvbid0IGFjY2VwdCBibGFuayByYW5nZXMgZm9yIG5vdywgb25seSBzaW5nbGUKLQkJ ICogaW50ZXJydXB0cy4gIFRoZSBvdGhlciBjYXNlIHNob3VsZCBub3QgaGFwcGVuIHdpdGgKLQkJ ICogdGhlIE1JIFBDSSBjb2RlIC4uLgotCQkgKiBYWFg6IFRoaXMgbWF5IHJldHVybiBhIHJlc291 cmNlIHRoYXQgaXMgb3V0IG9mIHRoZQotCQkgKiByYW5nZSB0aGF0IHdhcyBzcGVjaWZpZWQuICBJ cyB0aGlzIGNvcnJlY3QgLi4uPwotCQkgKi8KLQkJaWYgKHN0YXJ0ICE9IGVuZCkKLQkJCXBhbmlj KCIlczogWFhYOiBpbnRlcnJ1cHQgcmFuZ2UiLCBfX2Z1bmNfXyk7Ci0JCXJldHVybiAoYnVzX2dl bmVyaWNfYWxsb2NfcmVzb3VyY2UoYnVzLCBjaGlsZCwgdHlwZSwgcmlkLAotCQkgICAgc3RhcnQs IGVuZCwgY291bnQsIGZsYWdzKSk7Ci0JY2FzZSBTWVNfUkVTX01FTU9SWToKLQkJcm0gPSAmc2Mt PnNjX3BjaV9tZW1fcm1hbjsKLQkJYnJlYWs7Ci0JY2FzZSBTWVNfUkVTX0lPUE9SVDoKLQkJcm0g PSAmc2MtPnNjX3BjaV9pb19ybWFuOwotCQlicmVhazsKLQlkZWZhdWx0OgotCQlyZXR1cm4gKE5V TEwpOwotCX0KLQotCXJ2ID0gcm1hbl9yZXNlcnZlX3Jlc291cmNlKHJtLCBzdGFydCwgZW5kLCBj b3VudCwgZmxhZ3MgJiB+UkZfQUNUSVZFLAotCSAgICBjaGlsZCk7Ci0JaWYgKHJ2ID09IE5VTEwp Ci0JCXJldHVybiAoTlVMTCk7Ci0Jcm1hbl9zZXRfcmlkKHJ2LCAqcmlkKTsKLQotCWlmICgoZmxh Z3MgJiBSRl9BQ1RJVkUpICE9IDAgJiYgYnVzX2FjdGl2YXRlX3Jlc291cmNlKGNoaWxkLCB0eXBl LAotCSAgICAqcmlkLCBydikgIT0gMCkgewotCQlybWFuX3JlbGVhc2VfcmVzb3VyY2UocnYpOwot CQlyZXR1cm4gKE5VTEwpOwotCX0KLQlyZXR1cm4gKHJ2KTsKLX0KLQotaW50Ci1vZndfcGNpX2Fj dGl2YXRlX3Jlc291cmNlKGRldmljZV90IGJ1cywgZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLCBp bnQgcmlkLAotICAgIHN0cnVjdCByZXNvdXJjZSAqcikKLXsKLQlzdHJ1Y3Qgb2Z3X3BjaV9zb2Z0 YyAqc2M7Ci0Jc3RydWN0IGJ1c19zcGFjZV90YWcgKnRhZzsKLQotCXNjID0gZGV2aWNlX2dldF9z b2Z0YyhidXMpOwotCXN3aXRjaCAodHlwZSkgewotCWNhc2UgU1lTX1JFU19JUlE6Ci0JCXJldHVy biAoYnVzX2dlbmVyaWNfYWN0aXZhdGVfcmVzb3VyY2UoYnVzLCBjaGlsZCwgdHlwZSwgcmlkLAot CQkgICAgcikpOwotCWNhc2UgU1lTX1JFU19NRU1PUlk6Ci0JCXRhZyA9IHNwYXJjNjRfYWxsb2Nf YnVzX3RhZyhyLCBQQ0lfTUVNT1JZX0JVU19TUEFDRSk7Ci0JCWlmICh0YWcgPT0gTlVMTCkKLQkJ CXJldHVybiAoRU5PTUVNKTsKLQkJcm1hbl9zZXRfYnVzdGFnKHIsIHRhZyk7Ci0JCXJtYW5fc2V0 X2J1c2hhbmRsZShyLCBzYy0+c2NfcGNpX2JoW09GV19QQ0lfQ1NfTUVNMzJdICsKLQkJICAgIHJt YW5fZ2V0X3N0YXJ0KHIpKTsKLQkJYnJlYWs7Ci0JY2FzZSBTWVNfUkVTX0lPUE9SVDoKLQkJcm1h bl9zZXRfYnVzdGFnKHIsIHNjLT5zY19wY2lfaW90KTsKLQkJcm1hbl9zZXRfYnVzaGFuZGxlKHIs IHNjLT5zY19wY2lfYmhbT0ZXX1BDSV9DU19JT10gKwotCQkgICAgcm1hbl9nZXRfc3RhcnQocikp OwotCQlicmVhazsKLQl9Ci0JcmV0dXJuIChybWFuX2FjdGl2YXRlX3Jlc291cmNlKHIpKTsKLX0K LQotaW50Ci1vZndfcGNpX2FkanVzdF9yZXNvdXJjZShkZXZpY2VfdCBidXMsIGRldmljZV90IGNo aWxkLCBpbnQgdHlwZSwKLSAgICBzdHJ1Y3QgcmVzb3VyY2UgKnIsIHJtYW5fcmVzX3Qgc3RhcnQs IHJtYW5fcmVzX3QgZW5kKQotewotCXN0cnVjdCBvZndfcGNpX3NvZnRjICpzYzsKLQlzdHJ1Y3Qg cm1hbiAqcm07Ci0KLQlzYyA9IGRldmljZV9nZXRfc29mdGMoYnVzKTsKLQlzd2l0Y2ggKHR5cGUp IHsKLQljYXNlIFNZU19SRVNfSVJROgotCQlyZXR1cm4gKGJ1c19nZW5lcmljX2FkanVzdF9yZXNv dXJjZShidXMsIGNoaWxkLCB0eXBlLCByLAotCQkgICAgc3RhcnQsIGVuZCkpOwotCWNhc2UgU1lT X1JFU19NRU1PUlk6Ci0JCXJtID0gJnNjLT5zY19wY2lfbWVtX3JtYW47Ci0JCWJyZWFrOwotCWNh c2UgU1lTX1JFU19JT1BPUlQ6Ci0JCXJtID0gJnNjLT5zY19wY2lfaW9fcm1hbjsKLQkJYnJlYWs7 Ci0JZGVmYXVsdDoKLQkJcmV0dXJuIChFSU5WQUwpOwotCX0KLQlpZiAocm1hbl9pc19yZWdpb25f bWFuYWdlcihyLCBybSkgPT0gMCkKLQkJcmV0dXJuIChFSU5WQUwpOwotCXJldHVybiAocm1hbl9h ZGp1c3RfcmVzb3VyY2Uociwgc3RhcnQsIGVuZCkpOwotfQotCi1idXNfZG1hX3RhZ190Ci1vZndf cGNpX2dldF9kbWFfdGFnKGRldmljZV90IGJ1cywgZGV2aWNlX3QgY2hpbGQgX191bnVzZWQpCi17 Ci0Jc3RydWN0IG9md19wY2lfc29mdGMgKnNjOwotCi0Jc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGJ1 cyk7Ci0JcmV0dXJuIChzYy0+c2NfcGNpX2RtYXQpOwotfQotCi1waGFuZGxlX3QKLW9md19wY2lf Z2V0X25vZGUoZGV2aWNlX3QgYnVzLCBkZXZpY2VfdCBjaGlsZCBfX3VudXNlZCkKLXsKLQlzdHJ1 Y3Qgb2Z3X3BjaV9zb2Z0YyAqc2M7Ci0KLQlzYyA9IGRldmljZV9nZXRfc29mdGMoYnVzKTsKLQkv KiBXZSBvbmx5IGhhdmUgb25lIGNoaWxkLCB0aGUgUENJIGJ1cywgd2hpY2ggbmVlZHMgb3VyIG93 biBub2RlLiAqLwotCXJldHVybiAoc2MtPnNjX25vZGUpOwotfQpkaWZmIC0tZ2l0IGEvc3lzL3Nw YXJjNjQvcGNpL29md19wY2kuaCBiL3N5cy9zcGFyYzY0L3BjaS9vZndfcGNpLmgKZGVsZXRlZCBm aWxlIG1vZGUgMTAwNjQ0CmluZGV4IDZkMWU1ZDkuLjAwMDAwMDAKLS0tIGEvc3lzL3NwYXJjNjQv cGNpL29md19wY2kuaAorKysgL2Rldi9udWxsCkBAIC0xLDE3MCArMCwwIEBACi0vKi0KLSAqIENv cHlyaWdodCAoYykgMTk5OSwgMjAwMCBNYXR0aGV3IFIuIEdyZWVuCi0gKiBBbGwgcmlnaHRzIHJl c2VydmVkLgotICoKLSAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5h cnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAotICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVk IHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCi0gKiBhcmUgbWV0OgotICog MS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBj b3B5cmlnaHQKLSAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBm b2xsb3dpbmcgZGlzY2xhaW1lci4KLSAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9y bSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0Ci0gKiAgICBub3RpY2UsIHRoaXMg bGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhlCi0g KiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0 aGUgZGlzdHJpYnV0aW9uLgotICogMy4gVGhlIG5hbWUgb2YgdGhlIGF1dGhvciBtYXkgbm90IGJl IHVzZWQgdG8gZW5kb3JzZSBvciBwcm9tb3RlIHByb2R1Y3RzCi0gKiAgICBkZXJpdmVkIGZyb20g dGhpcyBzb2Z0d2FyZSB3aXRob3V0IHNwZWNpZmljIHByaW9yIHdyaXR0ZW4gcGVybWlzc2lvbi4K LSAqCi0gKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgYGBBUyBJUycn IEFORCBBTlkgRVhQUkVTUyBPUgotICogSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJV VCBOT1QgTElNSVRFRCBUTywgVEhFIElNUExJRUQgV0FSUkFOVElFUwotICogT0YgTUVSQ0hBTlRB QklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRSBBUkUgRElTQ0xBSU1F RC4KLSAqIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgQkUgTElBQkxFIEZPUiBBTlkgRElS RUNULCBJTkRJUkVDVCwKLSAqIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09O U0VRVUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcsCi0gKiBCVVQgTk9UIExJTUlURUQgVE8sIFBS T0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMgT1IgU0VSVklDRVM7Ci0gKiBMT1NTIE9GIFVT RSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKSBIT1dFVkVSIENB VVNFRAotICogQU5EIE9OIEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRS QUNULCBTVFJJQ1QgTElBQklMSVRZLAotICogT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0Ug T1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkKLSAqIE9VVCBPRiBUSEUgVVNFIE9GIFRI SVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKLSAqIFNV Q0ggREFNQUdFLgotICovCi0KLS8qLQotICogQ29weXJpZ2h0IChjKSAxOTk4LCAxOTk5IEVkdWFy ZG8gRS4gSG9ydmF0aAotICogQ29weXJpZ2h0IChjKSAyMDAxLCAyMDAzIGJ5IFRob21hcyBNb2Vz dGwgPHRtbUBGcmVlQlNELm9yZz4KLSAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuCi0gKgotICogUmVk aXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3 aXRob3V0Ci0gKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUg Zm9sbG93aW5nIGNvbmRpdGlvbnMKLSAqIGFyZSBtZXQ6Ci0gKiAxLiBSZWRpc3RyaWJ1dGlvbnMg b2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAotICogICAgbm90 aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVy LgotICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRo ZSBhYm92ZSBjb3B5cmlnaHQKLSAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMg YW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKLSAqICAgIGRvY3VtZW50YXRpb24g YW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCi0g KiAzLiBUaGUgbmFtZSBvZiB0aGUgYXV0aG9yIG1heSBub3QgYmUgdXNlZCB0byBlbmRvcnNlIG9y IHByb21vdGUgcHJvZHVjdHMKLSAqICAgIGRlcml2ZWQgZnJvbSB0aGlzIHNvZnR3YXJlIHdpdGhv dXQgc3BlY2lmaWMgcHJpb3Igd3JpdHRlbiBwZXJtaXNzaW9uLgotICoKLSAqIFRISVMgU09GVFdB UkUgSVMgUFJPVklERUQgQlkgVEhFIEFVVEhPUiBgYEFTIElTJycgQU5EIEFOWSBFWFBSRVNTIE9S Ci0gKiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBU SEUgSU1QTElFRCBXQVJSQU5USUVTCi0gKiBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1Mg Rk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFIEFSRSBESVNDTEFJTUVELgotICogSU4gTk8gRVZFTlQg U0hBTEwgVEhFIEFVVEhPUiBCRSBMSUFCTEUgRk9SIEFOWSBESVJFQ1QsIElORElSRUNULAotICog SU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMIERBTUFHRVMg KElOQ0xVRElORywKLSAqIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJ VFVURSBHT09EUyBPUiBTRVJWSUNFUzsKLSAqIExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRT OyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pIEhPV0VWRVIgQ0FVU0VECi0gKiBBTkQgT04gQU5Z IFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVCBMSUFCSUxJ VFksCi0gKiBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJ TkcgSU4gQU5ZIFdBWQotICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJ RiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRgotICogU1VDSCBEQU1BR0UuCi0gKgotICoJ ZnJvbTogTmV0QlNEOiBwc3ljaG9yZWcuaCx2IDEuMTQgMjAwOC8wNS8zMCAwMjoyOTozNyBtcmcg RXhwCi0gKgotICogJEZyZWVCU0QkCi0gKi8KLQotI2lmbmRlZiBfU1BBUkM2NF9QQ0lfT0ZXX1BD SV9IXwotI2RlZmluZQlfU1BBUkM2NF9QQ0lfT0ZXX1BDSV9IXwotCi0jaW5jbHVkZSA8c3lzL3Jt YW4uaD4KLQotI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1c19zdWJyLmg+Ci0KLSNpbmNsdWRlICJv ZndfcGNpX2lmLmgiCi0KLXR5cGVkZWYgdWludDMyX3Qgb2Z3X3BjaV9pbnRyX3Q7Ci0KLS8qIFBD SSByYW5nZSBjaGlsZCBzcGFjZXMuIFhYWDogYXJlIHRoZXNlIE1JPyAqLwotI2RlZmluZQlPRldf UENJX0NTX0NPTkZJRwkweDAwCi0jZGVmaW5lCU9GV19QQ0lfQ1NfSU8JCTB4MDEKLSNkZWZpbmUJ T0ZXX1BDSV9DU19NRU0zMgkweDAyCi0jZGVmaW5lCU9GV19QQ0lfQ1NfTUVNNjQJMHgwMwotI2Rl ZmluZQlPRldfUENJX05VTV9DUwkJNAotCi0vKiBPRlcgZGV2aWNlIHR5cGVzICovCi0jZGVmaW5l CU9GV19UWVBFX1BDSQkJInBjaSIKLSNkZWZpbmUJT0ZXX1RZUEVfUENJRQkJInBjaWV4IgotCi1z dHJ1Y3Qgb2Z3X3BjaV9tc2lfYWRkcl9yYW5nZXMgewotCXVpbnQzMl90CWFkZHIzMl9oaTsKLQl1 aW50MzJfdAlhZGRyMzJfbG87Ci0JdWludDMyX3QJYWRkcjMyX3N6OwotCXVpbnQzMl90CWFkZHI2 NF9oaTsKLQl1aW50MzJfdAlhZGRyNjRfbG87Ci0JdWludDMyX3QJYWRkcjY0X3N6OwotfTsKLQot I2RlZmluZQlPRldfUENJX01TSV9BRERSX1JBTkdFXzMyKHIpIFwKLQkoKCh1aW50NjRfdCkocikt PmFkZHIzMl9oaSA8PCAzMikgfCAodWludDY0X3QpKHIpLT5hZGRyMzJfbG8pCi0jZGVmaW5lCU9G V19QQ0lfTVNJX0FERFJfUkFOR0VfNjQocikgXAotCSgoKHVpbnQ2NF90KShyKS0+YWRkcjY0X2hp IDw8IDMyKSB8ICh1aW50NjRfdCkociktPmFkZHI2NF9sbykKLQotc3RydWN0IG9md19wY2lfbXNp X2VxX3RvX2RldmlubyB7Ci0JdWludDMyX3QJZXFfZmlyc3Q7Ci0JdWludDMyX3QJZXFfY291bnQ7 Ci0JdWludDMyX3QJZGV2aW5vX2ZpcnN0OwotfTsKLQotc3RydWN0IG9md19wY2lfbXNpX3Jhbmdl cyB7Ci0JdWludDMyX3QJZmlyc3Q7Ci0JdWludDMyX3QJY291bnQ7Ci19OwotCi1zdHJ1Y3Qgb2Z3 X3BjaV9yYW5nZXMgewotCXVpbnQzMl90CWNzcGFjZTsKLQl1aW50MzJfdAljaGlsZF9oaTsKLQl1 aW50MzJfdAljaGlsZF9sbzsKLQl1aW50MzJfdAlwaHlzX2hpOwotCXVpbnQzMl90CXBoeXNfbG87 Ci0JdWludDMyX3QJc2l6ZV9oaTsKLQl1aW50MzJfdAlzaXplX2xvOwotfTsKLQotI2RlZmluZQlP RldfUENJX1JBTkdFX0NISUxEKHIpIFwKLQkoKCh1aW50NjRfdCkociktPmNoaWxkX2hpIDw8IDMy KSB8ICh1aW50NjRfdCkociktPmNoaWxkX2xvKQotI2RlZmluZQlPRldfUENJX1JBTkdFX1BIWVMo cikgXAotCSgoKHVpbnQ2NF90KShyKS0+cGh5c19oaSA8PCAzMikgfCAodWludDY0X3QpKHIpLT5w aHlzX2xvKQotI2RlZmluZQlPRldfUENJX1JBTkdFX1NJWkUocikgXAotCSgoKHVpbnQ2NF90KShy KS0+c2l6ZV9oaSA8PCAzMikgfCAodWludDY0X3QpKHIpLT5zaXplX2xvKQotI2RlZmluZQlPRldf UENJX1JBTkdFX0NTKHIpCSgoKHIpLT5jc3BhY2UgPj4gMjQpICYgMHgwMykKLQotLyogZGVmYXVs dCB2YWx1ZXMgKi8KLSNkZWZpbmUJT0ZXX1BDSV9MQVRFTkNZCTY0Ci0KLS8qCi0gKiBDb21tb24g YW5kIGdlbmVyaWMgcGFydHMgb2YgaG9zdC1QQ0ktYnJpZGdlIHN1cHBvcnQKLSAqLwotCi1zdHJ1 Y3Qgb2Z3X3BjaV9zb2Z0YyB7Ci0Jc3RydWN0IHJtYW4JCXNjX3BjaV9tZW1fcm1hbjsKLQlzdHJ1 Y3Qgcm1hbgkJc2NfcGNpX2lvX3JtYW47Ci0KLQlidXNfc3BhY2VfaGFuZGxlX3QJc2NfcGNpX2Jo W09GV19QQ0lfTlVNX0NTXTsKLQlidXNfc3BhY2VfdGFnX3QJCXNjX3BjaV9jZmd0OwotCWJ1c19z cGFjZV90YWdfdAkJc2NfcGNpX2lvdDsKLQlidXNfZG1hX3RhZ190CQlzY19wY2lfZG1hdDsKLQot CXN0cnVjdCBvZndfYnVzX2lpbmZvCXNjX3BjaV9paW5mbzsKLQotCXBoYW5kbGVfdAkJc2Nfbm9k ZTsKLQotCXVpbnQ4X3QJCQlzY19wY2lfc2VjYnVzOwotCXVpbnQ4X3QJCQlzY19wY2lfc3ViYnVz OwotfTsKLQotaW50IG9md19wY2lfYXR0YWNoX2NvbW1vbihkZXZpY2VfdCBkZXYsIGJ1c19kbWFf dGFnX3QgZG1hdCwgdV9sb25nIGlvc2l6ZSwKLSAgICB1X2xvbmcgbWVtc2l6ZSk7Ci11aW50MzJf dCBvZndfcGNpX3JlYWRfY29uZmlnX2NvbW1vbihkZXZpY2VfdCBkZXYsIHVfaW50IHJlZ21heCwg dV9sb25nIG9mZnNldCwKLSAgICB1X2ludCBidXMsIHVfaW50IHNsb3QsIHVfaW50IGZ1bmMsIHVf aW50IHJlZywgaW50IHdpZHRoKTsKLXZvaWQgb2Z3X3BjaV93cml0ZV9jb25maWdfY29tbW9uKGRl dmljZV90IGRldiwgdV9pbnQgcmVnbWF4LCB1X2xvbmcgb2Zmc2V0LAotICAgIHVfaW50IGJ1cywg dV9pbnQgc2xvdCwgdV9pbnQgZnVuYywgdV9pbnQgcmVnLCB1aW50MzJfdCB2YWwsIGludCB3aWR0 aCk7Ci1vZndfcGNpX2ludHJfdCBvZndfcGNpX3JvdXRlX2ludGVycnVwdF9jb21tb24oZGV2aWNl X3QgYnJpZGdlLCBkZXZpY2VfdCBkZXYsCi0gICAgaW50IHBpbik7Ci0KLXZvaWQgb2Z3X3BjaV9k bWFtYXBfc3luY19zdHN0X29yZGVyX2NvbW1vbih2b2lkKTsKLQotYnVzX2FjdGl2YXRlX3Jlc291 cmNlX3Qgb2Z3X3BjaV9hY3RpdmF0ZV9yZXNvdXJjZTsKLWJ1c19hZGp1c3RfcmVzb3VyY2VfdCBv ZndfcGNpX2FkanVzdF9yZXNvdXJjZTsKLWJ1c19hbGxvY19yZXNvdXJjZV90IG9md19wY2lfYWxs b2NfcmVzb3VyY2U7Ci1idXNfZ2V0X2RtYV90YWdfdCBvZndfcGNpX2dldF9kbWFfdGFnOwotYnVz X3JlYWRfaXZhcl90IG9md19wY2lfcmVhZF9pdmFyOwotCi1vZndfYnVzX2dldF9ub2RlX3Qgb2Z3 X3BjaV9nZXRfbm9kZTsKLQotI2VuZGlmIC8qICEgX1NQQVJDNjRfUENJX09GV19QQ0lfSF8gKi8K ZGlmZiAtLWdpdCBhL3N5cy9zcGFyYzY0L3BjaS9vZndfcGNpYi5jIGIvc3lzL3NwYXJjNjQvcGNp L29md19wY2liLmMKaW5kZXggNzk0NDIzNy4uNmI0MjkwYiAxMDA2NDQKLS0tIGEvc3lzL3NwYXJj NjQvcGNpL29md19wY2liLmMKKysrIGIvc3lzL3NwYXJjNjQvcGNpL29md19wY2liLmMKQEAgLTQ2 LDE0ICs0NiwxNiBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAKICNpbmNsdWRlIDxkZXYvb2Z3 L29md19idXMuaD4KICNpbmNsdWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+CisjaW5jbHVkZSA8ZGV2 L29mdy9vZndfYnVzX3N1YnIuaD4KKyNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KIAogI2lu Y2x1ZGUgPGRldi9wY2kvcGNpcmVnLmg+CiAjaW5jbHVkZSA8ZGV2L3BjaS9wY2l2YXIuaD4KICNp bmNsdWRlIDxkZXYvcGNpL3BjaWJfcHJpdmF0ZS5oPgogCiAjaW5jbHVkZSAicGNpYl9pZi5oIgor I2luY2x1ZGUgIm9md19wY2lfaWYuaCIKIAotI2luY2x1ZGUgPHNwYXJjNjQvcGNpL29md19wY2ku aD4KICNpbmNsdWRlIDxzcGFyYzY0L3BjaS9vZndfcGNpYl9zdWJyLmg+CiAKICNkZWZpbmUJUENJ X0RFVklEX0FMSV9NNTI0OQkweDUyNDkxMGI5CmRpZmYgLS1naXQgYS9zeXMvc3BhcmM2NC9wY2kv b2Z3X3BjaWJfc3Vici5jIGIvc3lzL3NwYXJjNjQvcGNpL29md19wY2liX3N1YnIuYwppbmRleCAx NGZhNzJiLi40YzJiMTEzIDEwMDY0NAotLS0gYS9zeXMvc3BhcmM2NC9wY2kvb2Z3X3BjaWJfc3Vi ci5jCisrKyBiL3N5cy9zcGFyYzY0L3BjaS9vZndfcGNpYl9zdWJyLmMKQEAgLTM0LDggKzM0LDkg QEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwogI2luY2x1ZGUgPHN5cy9ybWFuLmg+CiAKICNpbmNs dWRlIDxkZXYvb2Z3L29md19idXMuaD4KLSNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KICNp bmNsdWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+CisjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzX3N1 YnIuaD4KKyNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KIAogI2luY2x1ZGUgPG1hY2hpbmUv YnVzLmg+CiAKQEAgLTQ1LDcgKzQ2LDYgQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwogCiAjaW5j bHVkZSAicGNpYl9pZi5oIgogCi0jaW5jbHVkZSA8c3BhcmM2NC9wY2kvb2Z3X3BjaS5oPgogI2lu Y2x1ZGUgPHNwYXJjNjQvcGNpL29md19wY2liX3N1YnIuaD4KIAogdm9pZApkaWZmIC0tZ2l0IGEv c3lzL3NwYXJjNjQvcGNpL29md19wY2lidXMuYyBiL3N5cy9zcGFyYzY0L3BjaS9vZndfcGNpYnVz LmMKaW5kZXggOTJiOWY3Ni4uMTc4NjA2YiAxMDA2NDQKLS0tIGEvc3lzL3NwYXJjNjQvcGNpL29m d19wY2lidXMuYworKysgYi9zeXMvc3BhcmM2NC9wY2kvb2Z3X3BjaWJ1cy5jCkBAIC0zOSwxMCAr MzksMTIgQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwogI2luY2x1ZGUgPHN5cy9saWJrZXJuLmg+ CiAjaW5jbHVkZSA8c3lzL21vZHVsZS5oPgogI2luY2x1ZGUgPHN5cy9wY2lpby5oPgorI2luY2x1 ZGUgPHN5cy9ybWFuLmg+CiAKICNpbmNsdWRlIDxkZXYvb2Z3L29md19idXMuaD4KLSNpbmNsdWRl IDxkZXYvb2Z3L29md19wY2kuaD4KICNpbmNsdWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+CisjaW5j bHVkZSA8ZGV2L29mdy9vZndfYnVzX3N1YnIuaD4KKyNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2ku aD4KIAogI2luY2x1ZGUgPG1hY2hpbmUvYnVzLmg+CiAjaWZuZGVmIFNVTjRWCkBAIC01NSwxMCAr NTcsOSBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAjaW5jbHVkZSA8ZGV2L3BjaS9wY2l2YXIu aD4KICNpbmNsdWRlIDxkZXYvcGNpL3BjaV9wcml2YXRlLmg+CiAKLSNpbmNsdWRlIDxzcGFyYzY0 L3BjaS9vZndfcGNpLmg+Ci0KICNpbmNsdWRlICJwY2liX2lmLmgiCiAjaW5jbHVkZSAicGNpX2lm LmgiCisjaW5jbHVkZSAib2Z3X3BjaV9pZi5oIgogCiAvKiBIZWxwZXIgZnVuY3Rpb25zICovCiBz dGF0aWMgdm9pZCBvZndfcGNpYnVzX3NldHVwX2RldmljZShkZXZpY2VfdCBicmlkZ2UsIHVpbnQz Ml90IGNsb2NrLApkaWZmIC0tZ2l0IGEvc3lzL3NwYXJjNjQvcGNpL3BzeWNoby5jIGIvc3lzL3Nw YXJjNjQvcGNpL3BzeWNoby5jCmluZGV4IDQ5NmRmOTYuLjM0NDFkMDggMTAwNjQ0Ci0tLSBhL3N5 cy9zcGFyYzY0L3BjaS9wc3ljaG8uYworKysgYi9zeXMvc3BhcmM2NC9wY2kvcHN5Y2hvLmMKQEAg LTU4LDYgKzU4LDggQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwogCiAjaW5jbHVkZSA8ZGV2L29m dy9vZndfYnVzLmg+CiAjaW5jbHVkZSA8ZGV2L29mdy9vcGVuZmlybS5oPgorI2luY2x1ZGUgPGRl di9vZncvb2Z3X2J1c19zdWJyLmg+CisjaW5jbHVkZSA8ZGV2L29mdy9vZndfcGNpLmg+CiAKICNp bmNsdWRlIDxtYWNoaW5lL2J1cy5oPgogI2luY2x1ZGUgPG1hY2hpbmUvYnVzX2NvbW1vbi5oPgpA QCAtNzAsMTEgKzcyLDExIEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKICNpbmNsdWRlIDxkZXYv cGNpL3BjaXJlZy5oPgogI2luY2x1ZGUgPGRldi9wY2kvcGNpdmFyLmg+CiAKLSNpbmNsdWRlIDxz cGFyYzY0L3BjaS9vZndfcGNpLmg+CiAjaW5jbHVkZSA8c3BhcmM2NC9wY2kvcHN5Y2hvcmVnLmg+ CiAjaW5jbHVkZSA8c3BhcmM2NC9wY2kvcHN5Y2hvdmFyLmg+CiAKICNpbmNsdWRlICJwY2liX2lm LmgiCisjaW5jbHVkZSAib2Z3X3BjaV9pZi5oIgogCiBzdGF0aWMgY29uc3Qgc3RydWN0IHBzeWNo b19kZXNjICpwc3ljaG9fZmluZF9kZXNjKGNvbnN0IHN0cnVjdCBwc3ljaG9fZGVzYyAqLAogICAg IGNvbnN0IGNoYXIgKik7CkBAIC0xMzAsOCArMTMyLDggQEAgc3RhdGljIGRldmljZV9tZXRob2Rf dCBwc3ljaG9fbWV0aG9kc1tdID0gewogCURFVk1FVEhPRChidXNfc2V0dXBfaW50ciwJcHN5Y2hv X3NldHVwX2ludHIpLAogCURFVk1FVEhPRChidXNfdGVhcmRvd25faW50ciwJYnVzX2dlbmVyaWNf dGVhcmRvd25faW50ciksCiAJREVWTUVUSE9EKGJ1c19hbGxvY19yZXNvdXJjZSwJcHN5Y2hvX2Fs bG9jX3Jlc291cmNlKSwKLQlERVZNRVRIT0QoYnVzX2FjdGl2YXRlX3Jlc291cmNlLCBvZndfcGNp X2FjdGl2YXRlX3Jlc291cmNlKSwKLQlERVZNRVRIT0QoYnVzX2RlYWN0aXZhdGVfcmVzb3VyY2Us IGJ1c19nZW5lcmljX2RlYWN0aXZhdGVfcmVzb3VyY2UpLAorCURFVk1FVEhPRChidXNfYWN0aXZh dGVfcmVzb3VyY2UsICAgc3BhcmM2NF9vZndfcGNpX2FjdGl2YXRlX3Jlc291cmNlKSwKKwlERVZN RVRIT0QoYnVzX2RlYWN0aXZhdGVfcmVzb3VyY2UsIHNwYXJjNjRfb2Z3X3BjaV9kZWFjdGl2YXRl X3Jlc291cmNlKSwKIAlERVZNRVRIT0QoYnVzX2FkanVzdF9yZXNvdXJjZSwJb2Z3X3BjaV9hZGp1 c3RfcmVzb3VyY2UpLAogCURFVk1FVEhPRChidXNfcmVsZWFzZV9yZXNvdXJjZSwJYnVzX2dlbmVy aWNfcmVsZWFzZV9yZXNvdXJjZSksCiAJREVWTUVUSE9EKGJ1c19nZXRfZG1hX3RhZywJb2Z3X3Bj aV9nZXRfZG1hX3RhZyksCkBAIC01NDEsOCArNTQzLDggQEAgcHN5Y2hvX2F0dGFjaChkZXZpY2Vf dCBkZXYpCiAJCXBhbmljKCIlczogb2Z3X3BjaV9hdHRhY2hfY29tbW9uKCkgZmFpbGVkIiwgX19m dW5jX18pOwogCiAJLyogQ2xlYXIgYW55IHBlbmRpbmcgUENJIGVycm9yIGJpdHMuICovCi0JUENJ Ql9XUklURV9DT05GSUcoZGV2LCBzYy0+c2Nfb3BzLnNjX3BjaV9zZWNidXMsIFBDU19ERVZJQ0Us IFBDU19GVU5DLAotCSAgICBQQ0lSX1NUQVRVUywgUENJQl9SRUFEX0NPTkZJRyhkZXYsIHNjLT5z Y19vcHMuc2NfcGNpX3NlY2J1cywKKwlQQ0lCX1dSSVRFX0NPTkZJRyhkZXYsIHNjLT5zY19vcHMu c2Nfc2VjYnVzLCBQQ1NfREVWSUNFLCBQQ1NfRlVOQywKKwkgICAgUENJUl9TVEFUVVMsIFBDSUJf UkVBRF9DT05GSUcoZGV2LCBzYy0+c2Nfb3BzLnNjX3NlY2J1cywKIAkgICAgUENTX0RFVklDRSwg UENTX0ZVTkMsIFBDSVJfU1RBVFVTLCAyKSwgMik7CiAJUENJQ1RMX1dSSVRFOChzYywgUENSX0NT LCBQQ0lDVExfUkVBRDgoc2MsIFBDUl9DUykpOwogCVBDSUNUTF9XUklURTgoc2MsIFBDUl9BRlMs IFBDSUNUTF9SRUFEOChzYywgUENSX0FGUykpOwpAQCAtNjA1LDE5ICs2MDcsMTkgQEAgcHN5Y2hv X2F0dGFjaChkZXZpY2VfdCBkZXYpCiAJICogU2V0IHRoZSBsYXRlbmN5IHRpbWVyIHJlZ2lzdGVy IGFzIHRoaXMgaXNuJ3QgYWx3YXlzIGRvbmUgYnkgdGhlCiAJICogZmlybXdhcmUuCiAJICovCi0J UENJQl9XUklURV9DT05GSUcoZGV2LCBzYy0+c2Nfb3BzLnNjX3BjaV9zZWNidXMsIFBDU19ERVZJ Q0UsIFBDU19GVU5DLAorCVBDSUJfV1JJVEVfQ09ORklHKGRldiwgc2MtPnNjX29wcy5zY19zZWNi dXMsIFBDU19ERVZJQ0UsIFBDU19GVU5DLAogCSAgICBQQ0lSX0xBVFRJTUVSLCBPRldfUENJX0xB VEVOQ1ksIDEpOwogCiAJZm9yIChpID0gUENJUl9WRU5ET1I7IGkgPCBQQ0lSX1NUQVRVUzsgaSAr PSBzaXplb2YodWludDE2X3QpKQogCQlsZTE2ZW5jKCZzYy0+c2NfcGNpX2hwYmNmZ1tpXSwKLQkJ ICAgIGJ1c19zcGFjZV9yZWFkXzIoc2MtPnNjX29wcy5zY19wY2lfY2ZndCwKLQkJICAgIHNjLT5z Y19vcHMuc2NfcGNpX2JoW09GV19QQ0lfQ1NfQ09ORklHXSwKLQkJICAgIFBTWUNIT19DT05GX09G RihzYy0+c2Nfb3BzLnNjX3BjaV9zZWNidXMsIFBDU19ERVZJQ0UsCisJCSAgICBidXNfc3BhY2Vf cmVhZF8yKHNjLT5zY19vcHMuc2NfY2ZndCwKKwkJICAgIHNjLT5zY19vcHMuc2NfYmhbT0ZXX1BD SV9DT05GSUddLAorCQkgICAgUFNZQ0hPX0NPTkZfT0ZGKHNjLT5zY19vcHMuc2Nfc2VjYnVzLCBQ Q1NfREVWSUNFLAogCQkgICAgUENTX0ZVTkMsIGkpKSk7CiAJZm9yIChpID0gUENJUl9SRVZJRDsg aSA8PSBQQ0lSX0JJU1Q7IGkgKz0gc2l6ZW9mKHVpbnQ4X3QpKQotCQlzYy0+c2NfcGNpX2hwYmNm Z1tpXSA9IGJ1c19zcGFjZV9yZWFkXzEoc2MtPnNjX29wcy5zY19wY2lfY2ZndCwKLQkJICAgIHNj LT5zY19vcHMuc2NfcGNpX2JoW09GV19QQ0lfQ1NfQ09ORklHXSwgUFNZQ0hPX0NPTkZfT0ZGKAot CQkgICAgc2MtPnNjX29wcy5zY19wY2lfc2VjYnVzLCBQQ1NfREVWSUNFLCBQQ1NfRlVOQywgaSkp OworCQlzYy0+c2NfcGNpX2hwYmNmZ1tpXSA9IGJ1c19zcGFjZV9yZWFkXzEoc2MtPnNjX29wcy5z Y19jZmd0LAorCQkgICAgc2MtPnNjX29wcy5zY19iaFtPRldfUENJX0NPTkZJR10sIFBTWUNIT19D T05GX09GRigKKwkJICAgIHNjLT5zY19vcHMuc2Nfc2VjYnVzLCBQQ1NfREVWSUNFLCBQQ1NfRlVO QywgaSkpOwogCiAJLyoKIAkgKiBPbiBFMjUwIHRoZSBpbnRlcnJ1cHQgbWFwIGVudHJ5IGZvciB0 aGUgRUJ1cyBicmlkZ2UgaXMgd3JvbmcsCkBAIC04ODIsNyArODg0LDcgQEAgcHN5Y2hvX3JlYWRf Y29uZmlnKGRldmljZV90IGRldiwgdV9pbnQgYnVzLCB1X2ludCBzbG90LCB1X2ludCBmdW5jLCB1 X2ludCByZWcsCiAJICogVGhlIFBzeWNobyBicmlkZ2VzIGNvbnRhaW4gYSBkdXBlIG9mIHRoZWly IGhlYWRlciBhdCAweDgwCiAJICogd2hpY2ggd2UgbnVsbGlmeSB0aGF0IHdheSBhbHNvLgogCSAq LwotCWlmIChidXMgPT0gc2MtPnNjX29wcy5zY19wY2lfc2VjYnVzICYmIHNsb3QgPT0gUENTX0RF VklDRSAmJgorCWlmIChidXMgPT0gc2MtPnNjX29wcy5zY19zZWNidXMgJiYgc2xvdCA9PSBQQ1Nf REVWSUNFICYmCiAJICAgIGZ1bmMgPT0gUENTX0ZVTkMpIHsKIAkJaWYgKHJlZyAlIHdpZHRoICE9 IDApCiAJCQlyZXR1cm4gKC0xKTsKQEAgLTg5Myw5ICs4OTUsOSBAQCBwc3ljaG9fcmVhZF9jb25m aWcoZGV2aWNlX3QgZGV2LCB1X2ludCBidXMsIHVfaW50IHNsb3QsIHVfaW50IGZ1bmMsIHVfaW50 IHJlZywKIAkJaWYgKChyZWcgPCBQQ0lSX1NUQVRVUyAmJiByZWcgKyB3aWR0aCA+IFBDSVJfU1RB VFVTKSB8fAogCQkgICAgcmVnID09IFBDSVJfU1RBVFVTIHx8IHJlZyA9PSBQQ0lSX1NUQVRVUyAr IDEpCiAJCQlsZTE2ZW5jKCZzYy0+c2NfcGNpX2hwYmNmZ1tQQ0lSX1NUQVRVU10sCi0JCQkgICAg YnVzX3NwYWNlX3JlYWRfMihzYy0+c2Nfb3BzLnNjX3BjaV9jZmd0LAotCQkJICAgIHNjLT5zY19v cHMuc2NfcGNpX2JoW09GV19QQ0lfQ1NfQ09ORklHXSwKLQkJCSAgICBQU1lDSE9fQ09ORl9PRkYo c2MtPnNjX29wcy5zY19wY2lfc2VjYnVzLAorCQkJICAgIGJ1c19zcGFjZV9yZWFkXzIoc2MtPnNj X29wcy5zY19jZmd0LAorCQkJICAgIHNjLT5zY19vcHMuc2NfYmhbT0ZXX1BDSV9DT05GSUddLAor CQkJICAgIFBTWUNIT19DT05GX09GRihzYy0+c2Nfb3BzLnNjX3NlY2J1cywKIAkJCSAgICBQQ1Nf REVWSUNFLCBQQ1NfRlVOQywgUENJUl9TVEFUVVMpKSk7CiAKIAkJc3dpdGNoICh3aWR0aCkgewpk aWZmIC0tZ2l0IGEvc3lzL3NwYXJjNjQvcGNpL3NjaGl6by5jIGIvc3lzL3NwYXJjNjQvcGNpL3Nj aGl6by5jCmluZGV4IGE5NjE1NWIuLjhlNDRhNWEgMTAwNjQ0Ci0tLSBhL3N5cy9zcGFyYzY0L3Bj aS9zY2hpem8uYworKysgYi9zeXMvc3BhcmM2NC9wY2kvc2NoaXpvLmMKQEAgLTU4LDYgKzU4LDgg QEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwogCiAjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzLmg+ CiAjaW5jbHVkZSA8ZGV2L29mdy9vcGVuZmlybS5oPgorI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1 c19zdWJyLmg+CisjaW5jbHVkZSA8ZGV2L29mdy9vZndfcGNpLmg+CiAKICNpbmNsdWRlIDxtYWNo aW5lL2J1cy5oPgogI2luY2x1ZGUgPG1hY2hpbmUvYnVzX2NvbW1vbi5oPgpAQCAtNjksMTEgKzcx LDExIEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKICNpbmNsdWRlIDxkZXYvcGNpL3BjaXJlZy5o PgogI2luY2x1ZGUgPGRldi9wY2kvcGNpdmFyLmg+CiAKLSNpbmNsdWRlIDxzcGFyYzY0L3BjaS9v ZndfcGNpLmg+CiAjaW5jbHVkZSA8c3BhcmM2NC9wY2kvc2NoaXpvcmVnLmg+CiAjaW5jbHVkZSA8 c3BhcmM2NC9wY2kvc2NoaXpvdmFyLmg+CiAKICNpbmNsdWRlICJwY2liX2lmLmgiCisjaW5jbHVk ZSAib2Z3X3BjaV9pZi5oIgogCiBzdGF0aWMgY29uc3Qgc3RydWN0IHNjaGl6b19kZXNjICpzY2hp em9fZ2V0X2Rlc2MoZGV2aWNlX3QpOwogc3RhdGljIHZvaWQgc2NoaXpvX3NldF9pbnRyKHN0cnVj dCBzY2hpem9fc29mdGMgKiwgdV9pbnQsIHVfaW50LApAQCAtMTI3LDggKzEyOSw4IEBAIHN0YXRp YyBkZXZpY2VfbWV0aG9kX3Qgc2NoaXpvX21ldGhvZHNbXSA9IHsKIAlERVZNRVRIT0QoYnVzX3Nl dHVwX2ludHIsCXNjaGl6b19zZXR1cF9pbnRyKSwKIAlERVZNRVRIT0QoYnVzX3RlYXJkb3duX2lu dHIsCWJ1c19nZW5lcmljX3RlYXJkb3duX2ludHIpLAogCURFVk1FVEhPRChidXNfYWxsb2NfcmVz b3VyY2UsCXNjaGl6b19hbGxvY19yZXNvdXJjZSksCi0JREVWTUVUSE9EKGJ1c19hY3RpdmF0ZV9y ZXNvdXJjZSwgb2Z3X3BjaV9hY3RpdmF0ZV9yZXNvdXJjZSksCi0JREVWTUVUSE9EKGJ1c19kZWFj dGl2YXRlX3Jlc291cmNlLCBidXNfZ2VuZXJpY19kZWFjdGl2YXRlX3Jlc291cmNlKSwKKwlERVZN RVRIT0QoYnVzX2FjdGl2YXRlX3Jlc291cmNlLCAgIHNwYXJjNjRfb2Z3X3BjaV9hY3RpdmF0ZV9y ZXNvdXJjZSksCisJREVWTUVUSE9EKGJ1c19kZWFjdGl2YXRlX3Jlc291cmNlLCBzcGFyYzY0X29m d19wY2lfZGVhY3RpdmF0ZV9yZXNvdXJjZSksCiAJREVWTUVUSE9EKGJ1c19hZGp1c3RfcmVzb3Vy Y2UsCW9md19wY2lfYWRqdXN0X3Jlc291cmNlKSwKIAlERVZNRVRIT0QoYnVzX3JlbGVhc2VfcmVz b3VyY2UsCWJ1c19nZW5lcmljX3JlbGVhc2VfcmVzb3VyY2UpLAogCURFVk1FVEhPRChidXNfZ2V0 X2RtYV90YWcsCW9md19wY2lfZ2V0X2RtYV90YWcpLApAQCAtNTQ4LDkgKzU1MCw5IEBAIHNjaGl6 b19hdHRhY2goZGV2aWNlX3QgZGV2KQogCQlwYW5pYygiJXM6IG9md19wY2lfYXR0YWNoX2NvbW1v bigpIGZhaWxlZCIsIF9fZnVuY19fKTsKIAogCS8qIENsZWFyIGFueSBwZW5kaW5nIFBDSSBlcnJv ciBiaXRzLiAqLwotCVBDSUJfV1JJVEVfQ09ORklHKGRldiwgc2MtPnNjX29wcy5zY19wY2lfc2Vj YnVzLCBTVFhfQ1NfREVWSUNFLAorCVBDSUJfV1JJVEVfQ09ORklHKGRldiwgc2MtPnNjX29wcy5z Y19zZWNidXMsIFNUWF9DU19ERVZJQ0UsCiAJICAgIFNUWF9DU19GVU5DLCBQQ0lSX1NUQVRVUywg UENJQl9SRUFEX0NPTkZJRyhkZXYsCi0JICAgIHNjLT5zY19vcHMuc2NfcGNpX3NlY2J1cywgU1RY X0NTX0RFVklDRSwgU1RYX0NTX0ZVTkMsIFBDSVJfU1RBVFVTLAorCSAgICBzYy0+c2Nfb3BzLnNj X3NlY2J1cywgU1RYX0NTX0RFVklDRSwgU1RYX0NTX0ZVTkMsIFBDSVJfU1RBVFVTLAogCSAgICAy KSwgMik7CiAJU0NISVpPX1BDSV9TRVQoc2MsIFNUWF9QQ0lfQ1RSTCwgU0NISVpPX1BDSV9SRUFE Xzgoc2MsIFNUWF9QQ0lfQ1RSTCkpOwogCVNDSElaT19QQ0lfU0VUKHNjLCBTVFhfUENJX0FGU1Is IFNDSElaT19QQ0lfUkVBRF84KHNjLCBTVFhfUENJX0FGU1IpKTsKQEAgLTY3OSw3ICs2ODEsNyBA QCBzY2hpem9fYXR0YWNoKGRldmljZV90IGRldikKIAkgKiBTZXQgdGhlIGxhdGVuY3kgdGltZXIg cmVnaXN0ZXIgYXMgdGhpcyBpc24ndCBhbHdheXMgZG9uZSBieSB0aGUKIAkgKiBmaXJtd2FyZS4K IAkgKi8KLQlQQ0lCX1dSSVRFX0NPTkZJRyhkZXYsIHNjLT5zY19vcHMuc2NfcGNpX3NlY2J1cywg U1RYX0NTX0RFVklDRSwKKwlQQ0lCX1dSSVRFX0NPTkZJRyhkZXYsIHNjLT5zY19vcHMuc2Nfc2Vj YnVzLCBTVFhfQ1NfREVWSUNFLAogCSAgICBTVFhfQ1NfRlVOQywgUENJUl9MQVRUSU1FUiwgT0ZX X1BDSV9MQVRFTkNZLCAxKTsKIAogI2RlZmluZQlTQ0hJWk9fU1lTQ1RMX0FERF9VSU5UKG5hbWUs IGFyZywgZGVzYykJCQkJXApAQCAtODA0LDcgKzgwNiw3IEBAIHNjaGl6b19wY2lfYnVzKHZvaWQg KmFyZykKIAkJeHN0YXQgPSBTQ0hJWk9fUENJX1JFQURfOChzYywgWE1TX1BDSV9YX0VSUl9TVEFU KTsKIAllbHNlCiAJCXhzdGF0ID0gMDsKLQlzdGF0dXMgPSBQQ0lCX1JFQURfQ09ORklHKHNjLT5z Y19kZXYsIHNjLT5zY19vcHMuc2NfcGNpX3NlY2J1cywKKwlzdGF0dXMgPSBQQ0lCX1JFQURfQ09O RklHKHNjLT5zY19kZXYsIHNjLT5zY19vcHMuc2Nfc2VjYnVzLAogCSAgICBTVFhfQ1NfREVWSUNF LCBTVFhfQ1NfRlVOQywgUENJUl9TVEFUVVMsIDIpOwogCiAJLyoKQEAgLTg0NSw3ICs4NDcsNyBA QCBzY2hpem9fcGNpX2J1cyh2b2lkICphcmcpCiAJICAgICh1bnNpZ25lZCBsb25nIGxvbmcpaW9t bXUsICh1bnNpZ25lZCBsb25nIGxvbmcpeHN0YXQsIHN0YXR1cyk7CiAKIAkvKiBDbGVhciB0aGUg ZXJyb3IgYml0cyB0aGF0IHdlIGNhdWdodC4gKi8KLQlQQ0lCX1dSSVRFX0NPTkZJRyhzYy0+c2Nf ZGV2LCBzYy0+c2Nfb3BzLnNjX3BjaV9zZWNidXMsIFNUWF9DU19ERVZJQ0UsCisJUENJQl9XUklU RV9DT05GSUcoc2MtPnNjX2Rldiwgc2MtPnNjX29wcy5zY19zZWNidXMsIFNUWF9DU19ERVZJQ0Us CiAJICAgIFNUWF9DU19GVU5DLCBQQ0lSX1NUQVRVUywgc3RhdHVzLCAyKTsKIAlTQ0hJWk9fUENJ X1dSSVRFXzgoc2MsIFNUWF9QQ0lfQ1RSTCwgY3NyKTsKIAlTQ0hJWk9fUENJX1dSSVRFXzgoc2Ms IFNUWF9QQ0lfQUZTUiwgYWZzcik7CkBAIC05NzIsNyArOTc0LDcgQEAgc2NoaXpvX3JlYWRfY29u ZmlnKGRldmljZV90IGRldiwgdV9pbnQgYnVzLCB1X2ludCBzbG90LCB1X2ludCBmdW5jLCB1X2lu dCByZWcsCiAJICogVGhlIFNjaGl6byBicmlkZ2VzIGNvbnRhaW4gYSBkdXBlIG9mIHRoZWlyIGhl YWRlciBhdCAweDgwLgogCSAqLwogCWlmIChzYy0+c2NfbW9kZSA9PSBTQ0hJWk9fTU9ERV9TQ1og JiYKLQkgICAgYnVzID09IHNjLT5zY19vcHMuc2NfcGNpX3NlY2J1cyAmJiBzbG90ID09IFNUWF9D U19ERVZJQ0UgJiYKKwkgICAgYnVzID09IHNjLT5zY19vcHMuc2Nfc2VjYnVzICYmIHNsb3QgPT0g U1RYX0NTX0RFVklDRSAmJgogCSAgICBmdW5jID09IFNUWF9DU19GVU5DICYmIHJlZyArIHdpZHRo ID4gMHg4MCkKIAkJcmV0dXJuICgwKTsKIApkaWZmIC0tZ2l0IGEvc3lzL3NwYXJjNjQvcGNpL3Nw YXJjNjRfb2Z3X3BjaS5jIGIvc3lzL3NwYXJjNjQvcGNpL3NwYXJjNjRfb2Z3X3BjaS5jCm5ldyBm aWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjVlOGQ1OTIKLS0tIC9kZXYvbnVsbAorKysg Yi9zeXMvc3BhcmM2NC9wY2kvc3BhcmM2NF9vZndfcGNpLmMKQEAgLTAsMCArMSwzMTcgQEAKKy8q LQorICogQ29weXJpZ2h0IChjKSAxOTk5LCAyMDAwIE1hdHRoZXcgUi4gR3JlZW4KKyAqIENvcHly aWdodCAoYykgMjAwMSAtIDIwMDMgYnkgVGhvbWFzIE1vZXN0bCA8dG1tQEZyZWVCU0Qub3JnPgor ICogQ29weXJpZ2h0IChjKSAyMDA1IC0gMjAxNSBieSBNYXJpdXMgU3Ryb2JsIDxtYXJpdXNARnJl ZUJTRC5vcmc+CisgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgorICoKKyAqIFJlZGlzdHJpYnV0aW9u IGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAorICog bW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBj b25kaXRpb25zCisgKiBhcmUgbWV0OgorICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBj b2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBs aXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKyAqIDIuIFJl ZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29w eXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9s bG93aW5nIGRpc2NsYWltZXIgaW4gdGhlCisgKiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhl ciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorICogMy4gVGhlIG5h bWUgb2YgdGhlIGF1dGhvciBtYXkgbm90IGJlIHVzZWQgdG8gZW5kb3JzZSBvciBwcm9tb3RlIHBy b2R1Y3RzCisgKiAgICBkZXJpdmVkIGZyb20gdGhpcyBzb2Z0d2FyZSB3aXRob3V0IHNwZWNpZmlj IHByaW9yIHdyaXR0ZW4gcGVybWlzc2lvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJ REVEIEJZIFRIRSBBVVRIT1IgYGBBUyBJUycnIEFORCBBTlkgRVhQUkVTUyBPUgorICogSU1QTElF RCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFIElNUExJRUQg V0FSUkFOVElFUworICogT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJ Q1VMQVIgUFVSUE9TRSBBUkUgRElTQ0xBSU1FRC4KKyAqIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBB VVRIT1IgQkUgTElBQkxFIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwKKyAqIElOQ0lERU5UQUws IFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcs CisgKiBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMg T1IgU0VSVklDRVM7CisgKiBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5F U1MgSU5URVJSVVBUSU9OKSBIT1dFVkVSIENBVVNFRAorICogQU5EIE9OIEFOWSBUSEVPUlkgT0Yg TElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QgTElBQklMSVRZLAorICogT1Ig VE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBX QVkKKyAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBP RiBUSEUgUE9TU0lCSUxJVFkgT0YKKyAqIFNVQ0ggREFNQUdFLgorICoKKyAqCWZyb206IE5ldEJT RDogcHN5Y2hvLmMsdiAxLjM1IDIwMDEvMDkvMTAgMTY6MTc6MDYgZWVoIEV4cAorICovCisKKyNp bmNsdWRlIDxzeXMvY2RlZnMuaD4KK19fRkJTRElEKCIkRnJlZUJTRCQiKTsKKworI2luY2x1ZGUg Im9wdF9vZndfcGNpLmgiCisKKyNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KKyNpbmNsdWRlIDxzeXMv c3lzdG0uaD4KKyNpbmNsdWRlIDxzeXMvYnVzLmg+CisjaW5jbHVkZSA8c3lzL2tlcm5lbC5oPgor I2luY2x1ZGUgPHN5cy9ybWFuLmg+CisKKyNpbmNsdWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+Cisj aW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzLmg+CisjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzX3N1 YnIuaD4KKyNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KKworI2luY2x1ZGUgPGRldi9wY2kv cGNpcmVnLmg+CisjaW5jbHVkZSA8ZGV2L3BjaS9wY2l2YXIuaD4KKworI2luY2x1ZGUgPG1hY2hp bmUvYXNpLmg+CisjaW5jbHVkZSA8bWFjaGluZS9idXMuaD4KKyNpbmNsdWRlIDxtYWNoaW5lL2J1 c19wcml2YXRlLmg+CisjaW5jbHVkZSA8bWFjaGluZS9jcHVmdW5jLmg+CisjaW5jbHVkZSA8bWFj aGluZS9mc3IuaD4KKyNpbmNsdWRlIDxtYWNoaW5lL3Jlc291cmNlLmg+CisKKyNpbmNsdWRlICJv ZndfcGNpX2lmLmgiCisKK3N0YXRpYyBkZXZpY2VfbWV0aG9kX3QJc3BhcmM2NF9vZndfcGNpX21l dGhvZHNbXSA9IHsKKworCURFVk1FVEhPRChidXNfYWN0aXZhdGVfcmVzb3VyY2UsCXNwYXJjNjRf b2Z3X3BjaV9hY3RpdmF0ZV9yZXNvdXJjZSksCisJREVWTUVUSE9EKGJ1c19kZWFjdGl2YXRlX3Jl c291cmNlLAlzcGFyYzY0X29md19wY2lfZGVhY3RpdmF0ZV9yZXNvdXJjZSksCisKKwlERVZNRVRI T0RfRU5ECit9OworCitERUZJTkVfQ0xBU1NfMShvZndfcGNpLCBzcGFyYzY0X29md19wY2lfZHJp dmVyLCBzcGFyYzY0X29md19wY2lfbWV0aG9kcywKKyAgICBzaXplb2Yoc3RydWN0IG9md19wY2lf c29mdGMpLCBvZndfcGNpX2RyaXZlcik7CisKK2ludAorb2Z3X3BjaV9hdHRhY2hfY29tbW9uKGRl dmljZV90IGRldiwgYnVzX2RtYV90YWdfdCBkbWF0LCB1X2xvbmcgaW9zaXplLAorICAgIHVfbG9u ZyBtZW1zaXplKQoreworCXN0cnVjdCBvZndfcGNpX3NvZnRjICpzYzsKKwlzdHJ1Y3Qgb2Z3X3Bj aV9yYW5nZSAqcmFuZ2VzOworCXBoYW5kbGVfdCBub2RlOworCXVpbnQzMl90IHByb3BfYXJyYXlb Ml07CisJdV9pbnQgaSwgaiwgbnJhbmdlOworCisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7 CisJbm9kZSA9IG9md19idXNfZ2V0X25vZGUoZGV2KTsKKwlzYy0+c2Nfbm9kZSA9IG5vZGU7CisJ c2MtPnNjX2RtYXQgPSBkbWF0OworCisJLyogSW5pdGlhbGl6ZSBtZW1vcnkgYW5kIEkvTyBybWFu cy4gKi8KKwlzYy0+c2NfaW9fcm1hbi5ybV90eXBlID0gUk1BTl9BUlJBWTsKKwlzYy0+c2NfaW9f cm1hbi5ybV9kZXNjciA9ICJQQ0kgSS9PIFBvcnRzIjsKKwlpZiAocm1hbl9pbml0KCZzYy0+c2Nf aW9fcm1hbikgIT0gMCB8fAorCSAgICBybWFuX21hbmFnZV9yZWdpb24oJnNjLT5zY19pb19ybWFu LCAwLCBpb3NpemUpICE9IDApIHsKKwkJZGV2aWNlX3ByaW50ZihkZXYsICJmYWlsZWQgdG8gc2V0 IHVwIEkvTyBybWFuXG4iKTsKKwkJcmV0dXJuIChFTlhJTyk7CisJfQorCXNjLT5zY19tZW1fcm1h bi5ybV90eXBlID0gUk1BTl9BUlJBWTsKKwlzYy0+c2NfbWVtX3JtYW4ucm1fZGVzY3IgPSAiUENJ IE1lbW9yeSI7CisJaWYgKHJtYW5faW5pdCgmc2MtPnNjX21lbV9ybWFuKSAhPSAwIHx8CisJICAg IHJtYW5fbWFuYWdlX3JlZ2lvbigmc2MtPnNjX21lbV9ybWFuLCAwLCBtZW1zaXplKSAhPSAwKSB7 CisJCWRldmljZV9wcmludGYoZGV2LCAiZmFpbGVkIHRvIHNldCB1cCBtZW1vcnkgcm1hblxuIik7 CisJCXJldHVybiAoRU5YSU8pOworCX0KKworCS8qCisJICogRmluZCB0aGUgYWRkcmVzc2VzIG9m IHRoZSB2YXJpb3VzIGJ1cyBzcGFjZXMuICBUaGUgcGh5c2ljYWwKKwkgKiBzdGFydCBhZGRyZXNz ZXMgb2YgdGhlIHJhbmdlcyBhcmUgdGhlIGNvbmZpZ3VyYXRpb24sIEkvTyBhbmQKKwkgKiBtZW1v cnkgaGFuZGxlcy4gIFRoZXJlIHNob3VsZCBub3QgYmUgbXVsdGlwbGUgb25lcyBvZiBvbmUga2lu ZC4KKwkgKi8KKwlucmFuZ2UgPSBPRl9nZXRlbmNwcm9wX2FsbG9jKG5vZGUsICJyYW5nZXMiLCBz aXplb2YoKnJhbmdlcyksCisJICAgICh2b2lkICoqKSZyYW5nZXMpOworCWZvciAoaSA9IDA7IGkg PCBucmFuZ2U7IGkrKykgeworCQlqID0gcmFuZ2VzW2ldLnBjaV9oaSAmIE9GV19QQ0lfUEhZU19I SV9TUEFDRU1BU0s7CisJCWlmIChzYy0+c2NfYmhbal0gIT0gMCkgeworCQkJZGV2aWNlX3ByaW50 ZihkZXYsICJkdXBsaWNhdGUgcmFuZ2UgZm9yIHNwYWNlICVkXG4iLAorCQkJICAgIGopOworCQkJ ZnJlZShyYW5nZXMsIE1fT0ZXUFJPUCk7CisJCQlyZXR1cm4gKEVJTlZBTCk7CisJCX0KKwkJc2Mt PnNjX2JoW2pdID0gcmFuZ2VzW2ldLmhvc3Q7CisJfQorCWZyZWUocmFuZ2VzLCBNX09GV1BST1Ap OworCisJLyoKKwkgKiBNYWtlIHN1cmUgdGhhdCB0aGUgZXhwZWN0ZWQgcmFuZ2VzIGFyZSBhY3R1 YWxseSBwcmVzZW50LgorCSAqIFRoZSBPRldfUENJX01FTTY0IG9uZSBpcyBub3QgY3VycmVudGx5 IHVzZWQuCisJICovCisJaWYgKHNjLT5zY19iaFtPRldfUENJX0NPTkZJR10gPT0gMCkgeworCQlk ZXZpY2VfcHJpbnRmKGRldiwgIm1pc3NpbmcgQ09ORklHIHJhbmdlXG4iKTsKKwkJcmV0dXJuIChF TlhJTyk7CisJfQorCWlmIChzYy0+c2NfYmhbT0ZXX1BDSV9JT10gPT0gMCkgeworCQlkZXZpY2Vf cHJpbnRmKGRldiwgIm1pc3NpbmcgSU8gcmFuZ2VcbiIpOworCQlyZXR1cm4gKEVOWElPKTsKKwl9 CisJaWYgKHNjLT5zY19iaFtPRldfUENJX01FTTMyXSA9PSAwKSB7CisJCWRldmljZV9wcmludGYo ZGV2LCAibWlzc2luZyBNRU0zMiByYW5nZVxuIik7CisJCXJldHVybiAoRU5YSU8pOworCX0KKwor CS8qIEFsbG9jYXRlIG91ciB0YWdzLiAqLworCXNjLT5zY19pb3QgPSBzcGFyYzY0X2FsbG9jX2J1 c190YWcoTlVMTCwgUENJX0lPX0JVU19TUEFDRSk7CisJaWYgKHNjLT5zY19pb3QgPT0gTlVMTCkg eworCQlkZXZpY2VfcHJpbnRmKGRldiwgImNvdWxkIG5vdCBhbGxvY2F0ZSBQQ0kgSS9PIHRhZ1xu Iik7CisJCXJldHVybiAoRU5YSU8pOworCX0KKwlzYy0+c2NfY2ZndCA9IHNwYXJjNjRfYWxsb2Nf YnVzX3RhZyhOVUxMLCBQQ0lfQ09ORklHX0JVU19TUEFDRSk7CisJaWYgKHNjLT5zY19jZmd0ID09 IE5VTEwpIHsKKwkJZGV2aWNlX3ByaW50ZihkZXYsCisJCSAgICAiY291bGQgbm90IGFsbG9jYXRl IFBDSSBjb25maWd1cmF0aW9uIHNwYWNlIHRhZ1xuIik7CisJCXJldHVybiAoRU5YSU8pOworCX0K KworCS8qCisJICogR2V0IHRoZSBidXMgcmFuZ2UgZnJvbSB0aGUgZmlybXdhcmUuCisJICovCisJ aSA9IE9GX2dldHByb3Aobm9kZSwgImJ1cy1yYW5nZSIsICh2b2lkICopcHJvcF9hcnJheSwKKwkg ICAgc2l6ZW9mKHByb3BfYXJyYXkpKTsKKwlpZiAoaSA9PSAtMSkgeworCQlkZXZpY2VfcHJpbnRm KGRldiwgImNvdWxkIG5vdCBnZXQgYnVzLXJhbmdlXG4iKTsKKwkJcmV0dXJuIChFTlhJTyk7CisJ fQorCWlmIChpICE9IHNpemVvZihwcm9wX2FycmF5KSkgeworCQlkZXZpY2VfcHJpbnRmKGRldiwg ImJyb2tlbiBidXMtcmFuZ2UgKCVkKSIsIGkpOworCQlyZXR1cm4gKEVJTlZBTCk7CisJfQorCXNj LT5zY19zZWNidXMgPSBwcm9wX2FycmF5WzBdOworCXNjLT5zY19zdWJidXMgPSBwcm9wX2FycmF5 WzFdOworCWlmIChib290dmVyYm9zZSAhPSAwKQorCQlkZXZpY2VfcHJpbnRmKGRldiwgImJ1cyBy YW5nZSAldSB0byAldTsgUENJIGJ1cyAlZFxuIiwKKwkJICAgIHNjLT5zY19zZWNidXMsIHNjLT5z Y19zdWJidXMsIHNjLT5zY19zZWNidXMpOworCisJb2Z3X2J1c19zZXR1cF9paW5mbyhub2RlLCAm c2MtPnNjX3BjaV9paW5mbywgc2l6ZW9mKG9md19wY2lfaW50cl90KSk7CisKKwlyZXR1cm4gKDAp OworfQorCit1aW50MzJfdAorb2Z3X3BjaV9yZWFkX2NvbmZpZ19jb21tb24oZGV2aWNlX3QgZGV2 LCB1X2ludCByZWdtYXgsIHVfbG9uZyBvZmZzZXQsCisgICAgdV9pbnQgYnVzLCB1X2ludCBzbG90 LCB1X2ludCBmdW5jLCB1X2ludCByZWcsIGludCB3aWR0aCkKK3sKKwlzdHJ1Y3Qgb2Z3X3BjaV9z b2Z0YyAqc2M7CisJYnVzX3NwYWNlX2hhbmRsZV90IGJoOworCXVpbnQzMl90IHIsIHdyZDsKKwlp bnQgaTsKKwl1aW50MTZfdCBzaHJ0OworCXVpbnQ4X3QgYnl0ZTsKKworCXNjID0gZGV2aWNlX2dl dF9zb2Z0YyhkZXYpOworCWlmIChidXMgPCBzYy0+c2Nfc2VjYnVzIHx8IGJ1cyA+IHNjLT5zY19z dWJidXMgfHwKKwkgICAgc2xvdCA+IFBDSV9TTE9UTUFYIHx8IGZ1bmMgPiBQQ0lfRlVOQ01BWCB8 fCByZWcgPiByZWdtYXgpCisJCXJldHVybiAoLTEpOworCisJYmggPSBzYy0+c2NfYmhbT0ZXX1BD SV9DT05GSUddOworCXN3aXRjaCAod2lkdGgpIHsKKwljYXNlIDE6CisJCWkgPSBidXNfc3BhY2Vf cGVla18xKHNjLT5zY19jZmd0LCBiaCwgb2Zmc2V0LCAmYnl0ZSk7CisJCXIgPSBieXRlOworCQli cmVhazsKKwljYXNlIDI6CisJCWkgPSBidXNfc3BhY2VfcGVla18yKHNjLT5zY19jZmd0LCBiaCwg b2Zmc2V0LCAmc2hydCk7CisJCXIgPSBzaHJ0OworCQlicmVhazsKKwljYXNlIDQ6CisJCWkgPSBi dXNfc3BhY2VfcGVla180KHNjLT5zY19jZmd0LCBiaCwgb2Zmc2V0LCAmd3JkKTsKKwkJciA9IHdy ZDsKKwkJYnJlYWs7CisJZGVmYXVsdDoKKwkJcGFuaWMoIiVzOiBiYWQgd2lkdGggJWQiLCBfX2Z1 bmNfXywgd2lkdGgpOworCQkvKiBOT1RSRUFDSEVEICovCisJfQorCisJaWYgKGkpIHsKKyNpZmRl ZiBPRldfUENJX0RFQlVHCisJCXByaW50ZigiJXM6IHJlYWQgZGF0YSBlcnJvciByZWFkaW5nOiAl ZC4lZC4lZDogMHgleFxuIiwKKwkJICAgIF9fZnVuY19fLCBidXMsIHNsb3QsIGZ1bmMsIHJlZyk7 CisjZW5kaWYKKwkJciA9IC0xOworCX0KKwlyZXR1cm4gKHIpOworfQorCit2b2lkCitvZndfcGNp X3dyaXRlX2NvbmZpZ19jb21tb24oZGV2aWNlX3QgZGV2LCB1X2ludCByZWdtYXgsIHVfbG9uZyBv ZmZzZXQsCisgICAgdV9pbnQgYnVzLCB1X2ludCBzbG90LCB1X2ludCBmdW5jLCB1X2ludCByZWcs IHVpbnQzMl90IHZhbCwgaW50IHdpZHRoKQoreworCXN0cnVjdCBvZndfcGNpX3NvZnRjICpzYzsK KwlidXNfc3BhY2VfaGFuZGxlX3QgYmg7CisKKwlzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsK KwlpZiAoYnVzIDwgc2MtPnNjX3NlY2J1cyB8fCBidXMgPiBzYy0+c2Nfc3ViYnVzIHx8CisJICAg IHNsb3QgPiBQQ0lfU0xPVE1BWCB8fCBmdW5jID4gUENJX0ZVTkNNQVggfHwgcmVnID4gcmVnbWF4 KQorCQlyZXR1cm47CisKKwliaCA9IHNjLT5zY19iaFtPRldfUENJX0NPTkZJR107CisJc3dpdGNo ICh3aWR0aCkgeworCWNhc2UgMToKKwkJYnVzX3NwYWNlX3dyaXRlXzEoc2MtPnNjX2NmZ3QsIGJo LCBvZmZzZXQsIHZhbCk7CisJCWJyZWFrOworCWNhc2UgMjoKKwkJYnVzX3NwYWNlX3dyaXRlXzIo c2MtPnNjX2NmZ3QsIGJoLCBvZmZzZXQsIHZhbCk7CisJCWJyZWFrOworCWNhc2UgNDoKKwkJYnVz X3NwYWNlX3dyaXRlXzQoc2MtPnNjX2NmZ3QsIGJoLCBvZmZzZXQsIHZhbCk7CisJCWJyZWFrOwor CWRlZmF1bHQ6CisJCXBhbmljKCIlczogYmFkIHdpZHRoICVkIiwgX19mdW5jX18sIHdpZHRoKTsK KwkJLyogTk9UUkVBQ0hFRCAqLworCX0KK30KKworb2Z3X3BjaV9pbnRyX3QKK29md19wY2lfcm91 dGVfaW50ZXJydXB0X2NvbW1vbihkZXZpY2VfdCBicmlkZ2UsIGRldmljZV90IGRldiwgaW50IHBp bikKK3sKKwlzdHJ1Y3Qgb2Z3X3BjaV9zb2Z0YyAqc2M7CisJc3RydWN0IG9md19wY2lfcmVnaXN0 ZXIgcmVnOworCW9md19wY2lfaW50cl90IHBpbnRyLCBtaW50cjsKKworCXNjID0gZGV2aWNlX2dl dF9zb2Z0YyhicmlkZ2UpOworCXBpbnRyID0gcGluOworCWlmIChvZndfYnVzX2xvb2t1cF9pbWFw KG9md19idXNfZ2V0X25vZGUoZGV2KSwgJnNjLT5zY19wY2lfaWluZm8sCisJICAgICZyZWcsIHNp emVvZihyZWcpLCAmcGludHIsIHNpemVvZihwaW50ciksICZtaW50ciwgc2l6ZW9mKG1pbnRyKSwK KwkgICAgTlVMTCkgIT0gMCkKKwkJcmV0dXJuIChtaW50cik7CisJcmV0dXJuIChQQ0lfSU5WQUxJ RF9JUlEpOworfQorCit2b2lkCitvZndfcGNpX2RtYW1hcF9zeW5jX3N0c3Rfb3JkZXJfY29tbW9u KHZvaWQpCit7CisJc3RhdGljIHVfY2hhciBidWZbVklTX0JMT0NLU0laRV0gX19hbGlnbmVkKFZJ U19CTE9DS1NJWkUpOworCXJlZ2lzdGVyX3QgcmVnLCBzOworCisJcyA9IGludHJfZGlzYWJsZSgp OworCXJlZyA9IHJkKGZwcnMpOworCXdyKGZwcnMsIHJlZyB8IEZQUlNfRkVGLCAwKTsKKwlfX2Fz bSBfX3ZvbGF0aWxlKCJzdGRhICUlZjAsIFslMF0gJTEiCisJICAgIDogOiAiciIgKGJ1ZiksICJu IiAoQVNJX0JMS19DT01NSVRfUykpOworCW1lbWJhcihTeW5jKTsKKwl3cihmcHJzLCByZWcsIDAp OworCWludHJfcmVzdG9yZShzKTsKK30KKworaW50CitzcGFyYzY0X29md19wY2lfYWN0aXZhdGVf cmVzb3VyY2UoZGV2aWNlX3QgYnVzLCBkZXZpY2VfdCBjaGlsZCwgaW50IHR5cGUsIGludCByaWQs CisgICAgc3RydWN0IHJlc291cmNlICpyKQoreworCXN0cnVjdCBvZndfcGNpX3NvZnRjICpzYzsK KwlzdHJ1Y3QgYnVzX3NwYWNlX3RhZyAqdGFnOworCisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGJ1 cyk7CisJc3dpdGNoICh0eXBlKSB7CisJY2FzZSBTWVNfUkVTX0lSUToKKwkJcmV0dXJuIChidXNf Z2VuZXJpY19hY3RpdmF0ZV9yZXNvdXJjZShidXMsIGNoaWxkLCB0eXBlLCByaWQsCisJCSAgICBy KSk7CisJY2FzZSBTWVNfUkVTX01FTU9SWToKKwkJdGFnID0gc3BhcmM2NF9hbGxvY19idXNfdGFn KHIsIFBDSV9NRU1PUllfQlVTX1NQQUNFKTsKKwkJaWYgKHRhZyA9PSBOVUxMKQorCQkJcmV0dXJu IChFTk9NRU0pOworCQlybWFuX3NldF9idXN0YWcociwgdGFnKTsKKwkJcm1hbl9zZXRfYnVzaGFu ZGxlKHIsIHNjLT5zY19iaFtPRldfUENJX01FTTMyXSArCisJCSAgICBybWFuX2dldF9zdGFydChy KSk7CisJCWJyZWFrOworCWNhc2UgU1lTX1JFU19JT1BPUlQ6CisJCXJtYW5fc2V0X2J1c3RhZyhy LCBzYy0+c2NfaW90KTsKKwkJcm1hbl9zZXRfYnVzaGFuZGxlKHIsIHNjLT5zY19iaFtPRldfUENJ X0lPXSArCisJCSAgICBybWFuX2dldF9zdGFydChyKSk7CisJCWJyZWFrOworCX0KKwlyZXR1cm4g KHJtYW5fYWN0aXZhdGVfcmVzb3VyY2UocikpOworfQorCitpbnQKK3NwYXJjNjRfb2Z3X3BjaV9k ZWFjdGl2YXRlX3Jlc291cmNlKGRldmljZV90IGJ1cywgZGV2aWNlX3QgY2hpbGQsCisgICAgaW50 IHR5cGUsIGludCByaWQsIHN0cnVjdCByZXNvdXJjZSAqcikKK3sKKworICAgICAgICByZXR1cm4g KGJ1c19nZW5lcmljX2RlYWN0aXZhdGVfcmVzb3VyY2UoYnVzLCBjaGlsZCwgdHlwZSwgcmlkLCBy KSk7Cit9CmRpZmYgLS1naXQgYS9zeXMvc3BhcmM2NC9zcGFyYzY0L2pidXNwcG0uYyBiL3N5cy9z cGFyYzY0L3NwYXJjNjQvamJ1c3BwbS5jCmluZGV4IDEyZjlmMGYuLjBiNDEwNTQgMTAwNjQ0Ci0t LSBhL3N5cy9zcGFyYzY0L3NwYXJjNjQvamJ1c3BwbS5jCisrKyBiL3N5cy9zcGFyYzY0L3NwYXJj NjQvamJ1c3BwbS5jCkBAIC0zNSwxMyArMzUsMTQgQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwog I2luY2x1ZGUgPHN5cy9yZXNvdXJjZS5oPgogI2luY2x1ZGUgPHN5cy9ybWFuLmg+CiAKKyNpbmNs dWRlIDxkZXYvb2Z3L29md19idXNfc3Vici5oPgogI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1cy5o PgogCiAjaW5jbHVkZSA8bWFjaGluZS9idXMuaD4KICNpbmNsdWRlIDxtYWNoaW5lL3Jlc291cmNl Lmg+CiAKICNpZiAxCi0jaW5jbHVkZSA8c3BhcmM2NC9wY2kvb2Z3X3BjaS5oPgorI2luY2x1ZGUg PGRldi9vZncvb2Z3X3BjaS5oPgogI2VuZGlmCiAKICNkZWZpbmUJSkJVU1BQTV9OUkVHCTIKZGlm ZiAtLWdpdCBhL3N5cy9zcGFyYzY0L3NwYXJjNjQvb2Z3X21hY2hkZXAuYyBiL3N5cy9zcGFyYzY0 L3NwYXJjNjQvb2Z3X21hY2hkZXAuYwppbmRleCA3ZmNmNWM4Li5hOWI0MGY4IDEwMDY0NAotLS0g YS9zeXMvc3BhcmM2NC9zcGFyYzY0L29md19tYWNoZGVwLmMKKysrIGIvc3lzL3NwYXJjNjQvc3Bh cmM2NC9vZndfbWFjaGRlcC5jCkBAIC0zNCwxMiArMzQsMTQgQEAgX19GQlNESUQoIiRGcmVlQlNE JCIpOwogI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgogI2luY2x1ZGUgPHN5cy9idXMuaD4KICNpbmNs dWRlIDxzeXMvc3lzdG0uaD4KKyNpbmNsdWRlIDxzeXMvcm1hbi5oPgogCiAjaW5jbHVkZSA8bmV0 L2V0aGVybmV0Lmg+CiAKKyNpbmNsdWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+CiAjaW5jbHVkZSA8 ZGV2L29mdy9vZndfYnVzLmg+CisjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzX3N1YnIuaD4KICNp bmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KLSNpbmNsdWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+ CiAKICNpbmNsdWRlIDxtYWNoaW5lL2J1cy5oPgogI2luY2x1ZGUgPG1hY2hpbmUvaWRwcm9tLmg+ Cg== --047d7bd76bea87df0b052cfd99e4-- From owner-freebsd-current@freebsd.org Tue Mar 1 14:37:10 2016 Return-Path: Delivered-To: freebsd-current@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 7B58CABD4B5 for ; Tue, 1 Mar 2016 14:37:10 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 0BFEF1E25 for ; Tue, 1 Mar 2016 14:37:10 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: by mail-wm0-x229.google.com with SMTP id l68so39920314wml.0 for ; Tue, 01 Mar 2016 06:37:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=1t5gWfQeB9DLibsmu12d8CQH5fSYkPumSRqr5+d5FQk=; b=FpdfE6/6h7AQFARcNRBCzu0RjrQ5IAglRwGD9mWM2h+VdOaBY7O3n5+rQe7yuAD+dj cp7gftJtYAJber8B0JmGAcM2dFY55QpXqrseKYSOPDkn9kZgZz65F9eMJ0PyKBnGZS41 zOdAXYonm1UUBXFdQG87vzmKjCy3p2urpOEvuTkIP+eDXQwL5Ysyy/WM2Kq55V/6ipdX OcPtSN0UHIfRMPjWHy7Qlzx9ddSlUE1mYkJyrY9m1i9pK5rX8pYg8MNG3DpvAC2VIAn0 Gd1qocybsu8vOsO1IET6mjmVrAyVTgFwtJO7oxjeKkzCj4+dTYVvfPuwmF+RrLkQryUf UKgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=1t5gWfQeB9DLibsmu12d8CQH5fSYkPumSRqr5+d5FQk=; b=dWD4SPkKHyUoYc7O5vmxCP0dqXHD549r83nimisF8ngcsewK4xIZDMkauNccJ4L5MI 8Bz8N2P767oU1QTzDjQdJl0ufSQK8KGEsmVMQAcXjszXK3+pfuSVUKLEhh58A8lWC8EM TnK4jgFJw2z3N5elHywxbK+v2tpajZhx0Umh4EHTL3fEl2atTnkHVVwYXY4wgWANeliL UCAK1gA7Hw6u+aEtJmj7kGTu19Wz4Ut8D0ZHsIfTx94iqxAYV3HLwUgyQFwpuijEeTzu mroif4+UCMTdBmApkEBKwTXku8XXSK6Z8aOXLoN13mygU6QFlNsQG8ADo5DF0yJcMRAi b56A== X-Gm-Message-State: AD7BkJLWqmNLUKlkXfa0WnK7Fji6/lyxEqjN1fZ6gQmLLMdp9aR1jAKOk/xljyJxtaZx/g== X-Received: by 10.194.185.199 with SMTP id fe7mr20756675wjc.50.1456843028458; Tue, 01 Mar 2016 06:37:08 -0800 (PST) Received: from laptop.minsk.domain (minsk.nivalnetwork.com. [86.57.144.74]) by smtp.gmail.com with ESMTPSA id jo6sm31317093wjb.48.2016.03.01.06.37.06 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Mar 2016 06:37:07 -0800 (PST) Date: Tue, 1 Mar 2016 17:34:08 +0300 From: "Sergey V. Dyatko" To: Anthony Jenkins Cc: freebsd-current@freebsd.org Subject: Re: Touchscreen support (was Re: new computer, strange usb messages at boot) Message-ID: <20160301173408.10e4767f@laptop.minsk.domain> In-Reply-To: <56D59E51.4040409@yahoo.com> References: <20160220051951.GA47875@lrosenman-dell.lerctr.org> <20160220120401.GA91220@kib.kiev.ua> <20160220122416.GA1026@lrosenman-dell.lerctr.org> <2575cfd714188f7ffbc873cb5d87cc97@thebighonker.lerctr.org> <56CA6F67.4000001@yahoo.com> <56CAB4A7.8080604@selasky.org> <56CB39B0.3020307@yahoo.com> <56CB3C74.7050103@selasky.org> <20160301083006.671d3987@laptop.minsk.domain> <56D59E51.4040409@yahoo.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 14:37:10 -0000 On Tue, 1 Mar 2016 08:51:13 -0500 Anthony Jenkins wrote: > On 03/01/2016 12:30 AM, Sergey V. Dyatko wrote: > > On Mon, 22 Feb 2016 17:51:00 +0100 > > Hans Petter Selasky wrote: > > > >> On 02/22/16 17:39, Anthony Jenkins wrote: > >>> > >>> On 02/22/2016 02:11 AM, Hans Petter Selasky wrote: > >>>> On 02/22/16 03:16, Anthony Jenkins wrote: > >>>>> Yes. I have an eGalax touchscreen and it's doing the same thing. The > >>>>> number of items it's reporting is 256 (according to my preliminary > >>>>> debugging), causing the warning. I think these things are a special > >>>>> subclass of HID for multitouch touchscreens which we don't support > >>>>> (yet). > >>>> /usr/ports/multimedia/webcamd will most likely attach if invoked > >>>> manually, to this device and provide an event device for you! > >>>> > >>>> --HPS > >>> Okay that's /amazing/, and not at all intuitive! I mean I'd expect > >>> multimedia/webcamd to only attach to "video" devices, but lo and behold > >>> I get a /dev/input/event0 device which spits out gibberish when > >>> cat(1)'ed and I touch the screen! > >>> > >>> My intentions were to port Linux's hid-multitouch device in whole to > >>> FreeBSD (it's what attaches to my eGalax device and probably to OP's > >>> touchscreen device) and add support for the device to moused(8), but > >>> it's not very high on my priority list... > >>> > >> Hi, > >> > >> If you apply these patches, will work with your X-org :-) > >> > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196678 > >> > > wow... > > Thanks for your work :) > > > > Yesterday I update -CURRENT on my lenovo z400 touch ( r296180), after > > suspend-resume I spotted that is my usb mouse didn't work (touchpad works as > > before) > > I had the feeling that I read something about hid_get_item: Number of > > items(256) truncated to 255 on ML, so I'm here. > > > > What I do: > > laptop# webcamd -l > > Available device(s): > > .... > > webcamd [-d ugen0.2] -N Synaptics-Large-Touch-Screen-SYNAPTICS -S unknown > > -M 0 ... > > Show webcamd usage: > > webcamd -h > > laptop# webcamd -N Synaptics-Large-Touch-Screen-SYNAPTICS -S unknown -M 0 > > Attached to ugen0.2[0] > > Creating /dev/input/event0 > > > > after that I reconnect my mouse and 'it works' (c) > > How I can do this automatically right? > I got my touchscreen working with the multimedia/webcamd and > x11-drivers/xf86-input-evdev ports and an entry in > /usr/local/etc/devd/webcamd.conf for my eGalax USB touchscreen device. > In webcamd.conf, you can copy the section > > # Generic USB input devices. > notify 100 { > match "system" "USB"; > match "subsystem" "INTERFACE"; > match "type" "ATTACH"; > match "intclass" "0x03"; > # > # Limit HID device attach to Wacom Devices > # else webcamd might attach to your keyboard > # and mouse > # > match "vendor" "0x056a"; > action "/usr/local/etc/rc.d/webcamd start $cdev $interface"; > }; > > to a new section, changing the 'match "vendor" line to match the USB > VendorID of your input device and possibly adding a 'match "product" line: > > $ sudo usbconfig -d ugen1.2 dump_device_desc | grep 'id\(Vendor\|Product\)' > idVendor = 0x0eef > idProduct = 0xa119 > > # My eGalax Touchscreen device. > notify 100 { > match "system" "USB"; > match "subsystem" "INTERFACE"; > match "type" "ATTACH"; > match "intclass" "0x03"; > match "vendor" "0x0eef"; > match "product" "0xa119"; > action "/usr/local/etc/rc.d/webcamd start $cdev $interface"; > }; > > replacing "ugen1.2" above with your "ugen0.2" as well as the vendor and > product values. > Thanks, I'll try this. few hours ago I: 1) install x11-drivers/xf86-input-evdev 2) place following to rc.conf.d/webcamd: [tiger@laptop]:~>cat /etc/rc.conf.d/webcamd webcamd_0_flags="-N Lenovo-EasyCamera-Generic -S 200901010001" webcamd_1_flags="-N Synaptics-Large-Touch-Screen-SYNAPTICS -S unknown" webcamd_enable="YES" 3) restart xorg but still no luck, possible I need change something on xorg.conf? [tiger@laptop]:~>grep -i input /var/log/Xorg.0.log [ 60690.944] (**) |-->Input Device "Mouse0" [ 60690.944] (**) |-->Input Device "Keyboard0" [ 60690.945] X.Org XInput driver : 21.0 [ 60690.979] (II) intel(0): Digital Display Input [ 60691.175] (II) config/hal: Adding input device usbhid [ 60691.175] (EE) No input driver matching `wacom' [ 60691.175] (EE) config/hal: NewInputDeviceRequest failed (15) [ 60691.179] (II) config/hal: Adding input device USB Optical Mouse [ 60691.180] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so [ 60691.180] Module class: X.Org XInput Driver [ 60691.180] ABI class: X.Org XInput driver, version 21.0 [ 60691.180] (II) Using input driver 'mouse' for 'USB Optical Mouse' [ 60691.180] (II) XINPUT: Adding extended input device "USB Optical Mouse" (type: MOUSE, id 6) [ 60691.183] (II) config/hal: Adding input device AT Keyboard [ 60691.184] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so [ 60691.184] Module class: X.Org XInput Driver [ 60691.184] ABI class: X.Org XInput driver, version 21.0 [ 60691.184] (II) Using input driver 'kbd' for 'AT Keyboard' [ 60691.184] (II) XINPUT: Adding extended input device "AT Keyboard" (type: KEYBOARD, id 7) [ 60691.196] (II) config/hal: Adding input device PS/2 Mouse [ 60691.196] (II) Using input driver 'mouse' for 'PS/2 Mouse' [ 60691.270] (II) XINPUT: Adding extended input device "PS/2 Mouse" (type: MOUSE, id 8) -- wbr, tiger From owner-freebsd-current@freebsd.org Tue Mar 1 14:41:24 2016 Return-Path: Delivered-To: freebsd-current@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 5475BABD7D2 for ; Tue, 1 Mar 2016 14:41:24 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id 3F67A1135 for ; Tue, 1 Mar 2016 14:41:24 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from sweettea.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id C8A0C56507; Tue, 1 Mar 2016 08:41:23 -0600 (CST) Subject: Re: continuous stream of writes? To: Michael Butler , freebsd-current References: <56D5A59E.8040608@protected-networks.net> From: Eric van Gyzen Message-ID: <56D5AA10.5090703@FreeBSD.org> Date: Tue, 1 Mar 2016 08:41:20 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56D5A59E.8040608@protected-networks.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 14:41:24 -0000 On 03/01/2016 08:22, Michael Butler wrote: > On an otherwise idle machine, I now see a continuous stream of writes to > disk. I've only noted this over the last couple of weeks but this will > not be welcome behaviour on an SSD .. > > How do I find the source of these writes? > > > imb@toshi:/home/imb> iostat 10 > tty ada0 cd0 pass0 cpu > tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id > 0 992 58.53 229 13.10 0.00 0 0.00 0.37 0 0.00 13 2 7 1 78 > 0 23 30.82 12 0.36 0.00 0 0.00 0.00 0 0.00 2 0 4 0 94 > 0 8 31.38 12 0.37 0.00 0 0.00 0.00 0 0.00 0 0 4 0 96 > 0 8 31.75 11 0.34 0.00 0 0.00 0.00 0 0.00 3 0 3 0 94 > 0 8 31.82 11 0.35 0.00 0 0.00 0.00 0 0.00 1 0 3 0 96 > 0 8 31.76 12 0.36 0.00 0 0.00 0.00 0 0.00 0 0 3 0 96 > 0 8 31.75 11 0.35 0.00 0 0.00 0.00 0 0.00 1 0 4 0 95 > 0 8 31.55 12 0.38 0.00 0 0.00 0.00 0 0.00 1 0 3 0 96 > The I/O mode of "top" might be useful: top -m io Eric From owner-freebsd-current@freebsd.org Tue Mar 1 14:45:39 2016 Return-Path: Delivered-To: freebsd-current@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 584BAABD952 for ; Tue, 1 Mar 2016 14:45:39 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2750914CD; Tue, 1 Mar 2016 14:45:39 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks CA" (verified OK)) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id DF30666; Tue, 1 Mar 2016 09:45:37 -0500 (EST) Subject: Re: continuous stream of writes? To: Eric van Gyzen , freebsd-current References: <56D5A59E.8040608@protected-networks.net> <56D5AA10.5090703@FreeBSD.org> From: Michael Butler Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492 Message-ID: <56D5AB11.7090307@protected-networks.net> Date: Tue, 1 Mar 2016 09:45:37 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56D5AA10.5090703@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 14:45:39 -0000 On 03/01/16 09:41, Eric van Gyzen wrote: > On 03/01/2016 08:22, Michael Butler wrote: >> On an otherwise idle machine, I now see a continuous stream of writes to >> disk. I've only noted this over the last couple of weeks but this will >> not be welcome behaviour on an SSD .. >> >> How do I find the source of these writes? >> >> >> imb@toshi:/home/imb> iostat 10 >> tty ada0 cd0 pass0 cpu >> tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id >> 0 992 58.53 229 13.10 0.00 0 0.00 0.37 0 0.00 13 2 7 1 78 >> 0 23 30.82 12 0.36 0.00 0 0.00 0.00 0 0.00 2 0 4 0 94 >> 0 8 31.38 12 0.37 0.00 0 0.00 0.00 0 0.00 0 0 4 0 96 >> 0 8 31.75 11 0.34 0.00 0 0.00 0.00 0 0.00 3 0 3 0 94 >> 0 8 31.82 11 0.35 0.00 0 0.00 0.00 0 0.00 1 0 3 0 96 >> 0 8 31.76 12 0.36 0.00 0 0.00 0.00 0 0.00 0 0 3 0 96 >> 0 8 31.75 11 0.35 0.00 0 0.00 0.00 0 0.00 1 0 4 0 95 >> 0 8 31.55 12 0.38 0.00 0 0.00 0.00 0 0.00 1 0 3 0 96 >> > > The I/O mode of "top" might be useful: > > top -m io Well that's different .. KDE konsole .. why on earth .. ? last pid: 54891; load averages: 0.32, 0.45, 0.48 up 0+17:32:51 09:43:58 102 processes: 1 running, 101 sleeping CPU: 1.4% user, 0.0% nice, 4.1% system, 0.0% interrupt, 94.5% idle Mem: 463M Active, 1599M Inact, 708M Wired, 255M Buf, 196M Free Swap: 4096M Total, 500M Used, 3596M Free, 12% Inuse PID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND 1395 imb 4 1 0 0 0 0 0.00% gkrellm --sm-client-id 1038b38f3a6339000140789027600000013050011 1498 imb 275 55 0 0 0 0 0.00% /usr/local/bin/firefox 1478 imb 33 7 0 22 0 22 100.00% kdeinit4: kdeinit4: konsole (kdeinit4) 1136 root 16 6 0 0 0 0 0.00% /usr/local/bin/X -br -novtswitch -quiet :0 -nolisten tcp -auth /var/run/xauth/A:0-xl3Taa (Xorg) 1345 imb 35 5 0 0 0 0 0.00% kwin -session 1038b38f3a6339000144659063000000424580056_1456780081_701192 5 From owner-freebsd-current@freebsd.org Tue Mar 1 14:50:06 2016 Return-Path: Delivered-To: freebsd-current@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 455A9ABDBE4 for ; Tue, 1 Mar 2016 14:50:06 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id 2F6321A3B for ; Tue, 1 Mar 2016 14:50:06 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from sweettea.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id D481456507; Tue, 1 Mar 2016 08:50:05 -0600 (CST) Subject: Re: continuous stream of writes? To: Michael Butler , freebsd-current References: <56D5A59E.8040608@protected-networks.net> <56D5AA10.5090703@FreeBSD.org> <56D5AB11.7090307@protected-networks.net> From: Eric van Gyzen Message-ID: <56D5AC1D.4010803@FreeBSD.org> Date: Tue, 1 Mar 2016 08:50:05 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56D5AB11.7090307@protected-networks.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 14:50:06 -0000 On 03/01/2016 08:45, Michael Butler wrote: > On 03/01/16 09:41, Eric van Gyzen wrote: >> On 03/01/2016 08:22, Michael Butler wrote: >>> On an otherwise idle machine, I now see a continuous stream of writes to >>> disk. I've only noted this over the last couple of weeks but this will >>> not be welcome behaviour on an SSD .. >>> >>> How do I find the source of these writes? >>> >>> >>> imb@toshi:/home/imb> iostat 10 >>> tty ada0 cd0 pass0 cpu >>> tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id >>> 0 992 58.53 229 13.10 0.00 0 0.00 0.37 0 0.00 13 2 7 1 78 >>> 0 23 30.82 12 0.36 0.00 0 0.00 0.00 0 0.00 2 0 4 0 94 >>> 0 8 31.38 12 0.37 0.00 0 0.00 0.00 0 0.00 0 0 4 0 96 >>> 0 8 31.75 11 0.34 0.00 0 0.00 0.00 0 0.00 3 0 3 0 94 >>> 0 8 31.82 11 0.35 0.00 0 0.00 0.00 0 0.00 1 0 3 0 96 >>> 0 8 31.76 12 0.36 0.00 0 0.00 0.00 0 0.00 0 0 3 0 96 >>> 0 8 31.75 11 0.35 0.00 0 0.00 0.00 0 0.00 1 0 4 0 95 >>> 0 8 31.55 12 0.38 0.00 0 0.00 0.00 0 0.00 1 0 3 0 96 >>> >> >> The I/O mode of "top" might be useful: >> >> top -m io > > Well that's different .. KDE konsole .. why on earth .. ? Now try ktrace, fstat, and procstat. See the man pages for usage. Eric From owner-freebsd-current@freebsd.org Tue Mar 1 16:04:47 2016 Return-Path: Delivered-To: freebsd-current@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 0E356ABFB7F for ; Tue, 1 Mar 2016 16:04:47 +0000 (UTC) (envelope-from Scoobi_doo@yahoo.com) Received: from nm20.bullet.mail.bf1.yahoo.com (nm20.bullet.mail.bf1.yahoo.com [98.139.212.179]) (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 C4C63111D for ; Tue, 1 Mar 2016 16:04:46 +0000 (UTC) (envelope-from Scoobi_doo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1456844617; bh=LAbLq4la1k7A6aFioC7Ylw9uDgAxiIxjKMtfW3yXA9Q=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=In4yl5QzzGfU/ZnHh1aRKpIyrS13pTHEe5xhgtiU5dnK2VXua9jtvnR9h5JBIl2aDnISqCC5q+0GhzQFftZOrFlMod40ePzPJ5gqlOgNfnUKGy5+8ZK+hJQ1DeOk4CAAbXoBQLKKtUZEoPvW+l+KvfPwYacyeOBTtPS4tGV/OXhqCOzNpxnEyLKvrGujDyFLFaTVzeF++0lucrdruBbqhzt3mUgAgmojU9Rr+sRUkHz5BYup74bS2/j2+n8OkZE4pk2PGeZahdeBR1bOCbvW/BDngwt6D6EAHi7T0FqhNi/T8hStcjiEgIkAyftXr3zs+uVwA8pF7oF+azX6oH6cUg== Received: from [98.139.215.141] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 01 Mar 2016 15:03:37 -0000 Received: from [98.139.211.193] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 01 Mar 2016 15:03:37 -0000 Received: from [127.0.0.1] by smtp202.mail.bf1.yahoo.com with NNFMP; 01 Mar 2016 15:03:37 -0000 X-Yahoo-Newman-Id: 17280.45021.bm@smtp202.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Wj9owSQVM1mewiGX3HnzOPR54Et9x9oVUP1wBgQwlL3j7.O ibWP8GaHibdKEYrqfyrqsTNfnTjhaztvmzUvJEVY.c9cQXGH.nOgdwcbNayi NomsWRY8X_.gvWKb5Lb5ZDlLZ8RVVF8RgPFHfOzQZA7nDAHdCIXi_xJEhEOT zJ6lL2mnFFwIABPOPuXADZK2q56yRVr.V6YyVHgDhyGW26BYKVBLGlCsC7RU XqL0SoDCbIkTdtdfaE9aC9cgC512UNInrsFiaS8C1X9xj0z2rxAqcOpi.pp_ QhgXT4MZx6tf6uL.fQrOEQqDxsRieBWGxFQ93n3MMh8cWComKmz_q0UKNsgG dUMW7ZkogIWYVKo1rg8bXrzl7AhpcPDd9Nk.qN4P2AMmKFyFC6T3PWW_3fXw MzYb1pz.pulXprIs5sS1PnT5nJZwunJtN9gKK.9BcBYIqj28gU5S5VMSXupW hwoY3FOtTIIBtAJX7ewMjEQOtYFuchSf75xrPRHuEtbmQ_9WNVMuPvKUX94C c04qYjNL3X45ZjV9RkSr3nbFYlYATqdFulA-- X-Yahoo-SMTP: 9sPoSQ2swBBlERuQ.0vs8XLc_MeClW0- Subject: Re: Touchscreen support (was Re: new computer, strange usb messages at boot) To: "Sergey V. Dyatko" References: <20160220051951.GA47875@lrosenman-dell.lerctr.org> <20160220120401.GA91220@kib.kiev.ua> <20160220122416.GA1026@lrosenman-dell.lerctr.org> <2575cfd714188f7ffbc873cb5d87cc97@thebighonker.lerctr.org> <56CA6F67.4000001@yahoo.com> <56CAB4A7.8080604@selasky.org> <56CB39B0.3020307@yahoo.com> <56CB3C74.7050103@selasky.org> <20160301083006.671d3987@laptop.minsk.domain> <56D59E51.4040409@yahoo.com> <20160301173408.10e4767f@laptop.minsk.domain> Cc: freebsd-current@freebsd.org From: Anthony Jenkins Message-ID: <56D5AF47.7080005@yahoo.com> Date: Tue, 1 Mar 2016 10:03:35 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160301173408.10e4767f@laptop.minsk.domain> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 16:04:47 -0000 On 03/01/2016 09:34 AM, Sergey V. Dyatko wrote: > On Tue, 1 Mar 2016 08:51:13 -0500 > Anthony Jenkins wrote:=20 > >> On 03/01/2016 12:30 AM, Sergey V. Dyatko wrote: >>> On Mon, 22 Feb 2016 17:51:00 +0100 >>> Hans Petter Selasky wrote:=20 >>> =20 >>>> On 02/22/16 17:39, Anthony Jenkins wrote: =20 >>>>> On 02/22/2016 02:11 AM, Hans Petter Selasky wrote: =20 >>>>>> On 02/22/16 03:16, Anthony Jenkins wrote: =20 >>>>>>> Yes. I have an eGalax touchscreen and it's doing the same thing.= The >>>>>>> number of items it's reporting is 256 (according to my preliminar= y >>>>>>> debugging), causing the warning. I think these things are a spec= ial >>>>>>> subclass of HID for multitouch touchscreens which we don't suppor= t >>>>>>> (yet). =20 >>>>>> /usr/ports/multimedia/webcamd will most likely attach if invoked >>>>>> manually, to this device and provide an event device for you! >>>>>> >>>>>> --HPS =20 >>>>> Okay that's /amazing/, and not at all intuitive! I mean I'd expect= >>>>> multimedia/webcamd to only attach to "video" devices, but lo and be= hold >>>>> I get a /dev/input/event0 device which spits out gibberish when >>>>> cat(1)'ed and I touch the screen! >>>>> >>>>> My intentions were to port Linux's hid-multitouch device in whole t= o >>>>> FreeBSD (it's what attaches to my eGalax device and probably to OP'= s >>>>> touchscreen device) and add support for the device to moused(8), bu= t >>>>> it's not very high on my priority list... >>>>> =20 >>>> Hi, >>>> >>>> If you apply these patches, will work with your X-org :-) >>>> >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D196678 >>>> =20 >>> wow... >>> Thanks for your work :)=20 >>> >>> Yesterday I update -CURRENT on my lenovo z400 touch ( r296180), afte= r >>> suspend-resume I spotted that is my usb mouse didn't work (touchpad w= orks as >>> before) >>> I had the feeling that I read something about hid_get_item: Number of= >>> items(256) truncated to 255 on ML, so I'm here.=20 >>> >>> What I do:=20 >>> laptop# webcamd -l >>> Available device(s): >>> .... >>> webcamd [-d ugen0.2] -N Synaptics-Large-Touch-Screen-SYNAPTICS -S unk= nown >>> -M 0 ... >>> Show webcamd usage: >>> webcamd -h >>> laptop# webcamd -N Synaptics-Large-Touch-Screen-SYNAPTICS -S unknown= -M 0 >>> Attached to ugen0.2[0] >>> Creating /dev/input/event0 >>> >>> after that I reconnect my mouse and 'it works' (c)=20 >>> How I can do this automatically right? =20 >> I got my touchscreen working with the multimedia/webcamd and >> x11-drivers/xf86-input-evdev ports and an entry in >> /usr/local/etc/devd/webcamd.conf for my eGalax USB touchscreen device.= =20 >> In webcamd.conf, you can copy the section >> >> # Generic USB input devices. >> notify 100 { >> match "system" "USB"; >> match "subsystem" "INTERFACE"; >> match "type" "ATTACH"; >> match "intclass" "0x03"; >> # >> # Limit HID device attach to Wacom Devices >> # else webcamd might attach to your keyboard >> # and mouse >> # >> match "vendor" "0x056a"; >> action "/usr/local/etc/rc.d/webcamd start $cdev $interface"; >> }; >> >> to a new section, changing the 'match "vendor" line to match the USB >> VendorID of your input device and possibly adding a 'match "product" l= ine: >> >> $ sudo usbconfig -d ugen1.2 dump_device_desc | grep 'id\(Vendor\|Produ= ct\)' >> idVendor =3D 0x0eef >> idProduct =3D 0xa119 >> >> # My eGalax Touchscreen device. >> notify 100 { >> match "system" "USB"; >> match "subsystem" "INTERFACE"; >> match "type" "ATTACH"; >> match "intclass" "0x03"; >> match "vendor" "0x0eef"; >> match "product" "0xa119"; >> action "/usr/local/etc/rc.d/webcamd start $cdev $interface"; >> }; >> >> replacing "ugen1.2" above with your "ugen0.2" as well as the vendor an= d >> product values. >> > Thanks, I'll try this. > few hours ago I: > 1) install x11-drivers/xf86-input-evdev > 2) place following to rc.conf.d/webcamd: > > [tiger@laptop]:~>cat /etc/rc.conf.d/webcamd > webcamd_0_flags=3D"-N Lenovo-EasyCamera-Generic -S 200901010001" > webcamd_1_flags=3D"-N Synaptics-Large-Touch-Screen-SYNAPTICS -S unknown= " I didn't modify any of webcamd's flags in the rc.conf* files. You will also have to restart devd(8) ('/etc/rc.d/devd restart') to pick up the change to /usr/local/etc/devd/webcamd.conf. Do you see an instance of webcamd(8) running for your touchscreen? Is there a /dev/input/event* device node? I'm running my own spin of xorg-server/config/devd.c, different from the proposed patch to x11-servers/xorg-server, but that really shouldn't be the reason for your difficulty. > webcamd_enable=3D"YES" > 3) restart xorg but still no luck, possible I need change something on > xorg.conf?=20 > > [tiger@laptop]:~>grep -i input /var/log/Xorg.0.log > [ 60690.944] (**) |-->Input Device "Mouse0" > [ 60690.944] (**) |-->Input Device "Keyboard0" > [ 60690.945] X.Org XInput driver : 21.0 > [ 60690.979] (II) intel(0): Digital Display Input > [ 60691.175] (II) config/hal: Adding input device usbhid > [ 60691.175] (EE) No input driver matching `wacom' > [ 60691.175] (EE) config/hal: NewInputDeviceRequest failed (15) > [ 60691.179] (II) config/hal: Adding input device USB Optical Mouse > [ 60691.180] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.s= o > [ 60691.180] Module class: X.Org XInput Driver > [ 60691.180] ABI class: X.Org XInput driver, version 21.0 > [ 60691.180] (II) Using input driver 'mouse' for 'USB Optical Mouse' > [ 60691.180] (II) XINPUT: Adding extended input device "USB Optical > Mouse" (type: MOUSE, id 6) [ 60691.183] (II) config/hal: Adding input d= evice AT > Keyboard [ 60691.184] (II) Loading /usr/local/lib/xorg/modules/input/kb= d_drv.so > [ 60691.184] Module class: X.Org XInput Driver > [ 60691.184] ABI class: X.Org XInput driver, version 21.0 > [ 60691.184] (II) Using input driver 'kbd' for 'AT Keyboard' > [ 60691.184] (II) XINPUT: Adding extended input device "AT Keyboard" (t= ype: > KEYBOARD, id 7) [ 60691.196] (II) config/hal: Adding input device PS/2 = Mouse > [ 60691.196] (II) Using input driver 'mouse' for 'PS/2 Mouse' > [ 60691.270] (II) XINPUT: Adding extended input device "PS/2 Mouse" (ty= pe: > MOUSE, id 8) > --=20 Anthony Jenkins From owner-freebsd-current@freebsd.org Tue Mar 1 16:22:02 2016 Return-Path: Delivered-To: freebsd-current@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 F339DAC048F; Tue, 1 Mar 2016 16:22:02 +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 E74F11FC0; Tue, 1 Mar 2016 16:22:02 +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 7565E614; Tue, 1 Mar 2016 16:22:03 +0000 (UTC) Date: Tue, 1 Mar 2016 16:22:02 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1439051008.177.1456849323438.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <124304149.171.1456838501127.JavaMail.jenkins@jenkins-9.freebsd.org> References: <124304149.171.1456838501127.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #2480 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 16:22:03 -0000 FreeBSD_HEAD_i386 - Build #2480 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2480/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2480/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2480/console Change summaries: No changes From owner-freebsd-current@freebsd.org Tue Mar 1 16:22:18 2016 Return-Path: Delivered-To: freebsd-current@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 6D79AAC04C6 for ; Tue, 1 Mar 2016 16:22:18 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-09.arcor-online.net (mail-in-09.arcor-online.net [151.189.21.49]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 13A7F10F1 for ; Tue, 1 Mar 2016 16:22:17 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-19-z2.arcor-online.net (mail-in-19-z2.arcor-online.net [151.189.8.36]) by mx.arcor.de (Postfix) with ESMTP id 3qF2sd3w5QzB3vR for ; Tue, 1 Mar 2016 16:47:49 +0100 (CET) Received: from mail-in-13.arcor-online.net (mail-in-13.arcor-online.net [151.189.21.53]) by mail-in-19-z2.arcor-online.net (Postfix) with ESMTP id 5CBD535BEA8 for ; Tue, 1 Mar 2016 16:47:49 +0100 (CET) Received: from webmail21.arcor-online.net (webmail21.arcor-online.net [151.189.8.136]) by mail-in-13.arcor-online.net (Postfix) with ESMTP id 3qF2sd27GYz33CS for ; Tue, 1 Mar 2016 16:47:49 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-13.arcor-online.net 3qF2sd27GYz33CS DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arcor.de; s=mail-in; t=1456847269; bh=IZsNYckNyIT9wC9r6BGQl7FO12/3666yn9HS00bT5+k=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=iV6aVu1sSSApcYl6bpGt7uGetTOoIhBiX0HaD+u0gsNsHKiT+tD3fMUTyH0p4uQBk 4wdOmdeDB5FkOVtuh+fj7xBLSJaSgnysrH5CsIgAl4Cd8fCZQEFWU3t9swR5sOIGKQ xpobO+FMrdup8lX8Jw3iZE2vP9WSsM56SIiqnnQ4= Received: from [217.92.152.234] by webmail21.arcor-online.net (151.189.8.136) with HTTP (Arcor Webmail); Tue, 1 Mar 2016 16:47:48 +0100 (CET) Date: Tue, 1 Mar 2016 16:47:49 +0100 (CET) From: Carsten Kunze To: freebsd-current@freebsd.org Message-ID: <1493379294.130887.1456847269287.JavaMail.ngmail@webmail21.arcor-online.net> Subject: WLAN hardware not recognized MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ngMessageSubType: MessageSubType_MAIL X-WebmailclientIP: 217.92.152.234 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 16:22:18 -0000 Hello, the WLAN hardware of my Dell E6540 (intel 633ANHMW) is not recognized (or at least does not work). The only message found in dmesg is: [1] iwn0: mem 0xf7b00000-0xf7b01fff irq 18 at device 0.0 on pci3 Full dmesg is: Copyright (c) 2013-2016 The HardenedBSD Project. [1] Copyright (c) 1992-2016 The FreeBSD Project. [1] Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 [1] The Regents of the University of California. All rights reserved. [1] FreeBSD is a registered trademark of The FreeBSD Foundation. [1] FreeBSD 11.0-CURRENT-HBSD #18 7affcca(HEAD): Fri Feb 19 03:41:41 EST 2016 [1] jenkins@nyi-01.build.hardenedbsd.org:/usr/obj/jenkins/workspace/HardenedBSD-CURRENT-i915kms-amd64/sys/HARDENEDBSD amd64 [1] FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225 [1] WARNING: WITNESS option enabled, expect reduced performance. [1] VT(vga): resolution 640x480 [1] HBSD: initialize and check HardenedBSD features (version 41). [1] [HBSD LOG] logging to system: enabled [1] [HBSD LOG] logging to user: disabled [1] [HBSD ASLR] status: opt-out [1] [HBSD ASLR] mmap: 30 bit [1] [HBSD ASLR] exec base: 30 bit [1] [HBSD ASLR] stack: 42 bit [1] [HBSD ASLR] vdso: 28 bit [1] [HBSD ASLR] map32bit: 18 bit [1] [HBSD ASLR] disallow MAP_32BIT mode mmap: opt-out [1] [HBSD PAGEEXEC] status: opt-out [1] [HBSD MPROTECT] status: opt-out [1] [HBSD HARDENING] procfs hardening: enabled [1] [HBSD HARDENING] randomize pids: enabled [1] [HBSD HARDENING] unset insecure init variables: enabled [1] [HBSD SEGVGUARD] status: opt-in [1] [HBSD SEGVGUARD] expiry: 120 sec [1] [HBSD SEGVGUARD] suspension: 600 sec [1] [HBSD SEGVGUARD] maxcrahes: 5 [1] CPU: Intel(R) Core(TM) i5-4300M CPU @ 2.60GHz (2594.05-MHz K8-class CPU) [1] Origin="GenuineIntel" Id=0x306c3 Family=0x6 Model=0x3c Stepping=3 [1] Features=0xbfebfbff [1] Features2=0x7ffafbff [1] AMD Features=0x2c100800 [1] AMD Features2=0x21 [1] Structured Extended Features=0x27ab [1] XSAVE Features=0x1 [1] VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID [1] TSC: P-state invariant, performance statistics [1] real memory = 8589934592 (8192 MB) [1] avail memory = 8158760960 (7780 MB) [1] Event timer "LAPIC" quality 600 [1] ACPI APIC Table: [1] FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs [1] FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads [1] cpu0 (BSP): APIC ID: 0 [1] cpu1 (AP): APIC ID: 1 [1] cpu2 (AP): APIC ID: 2 [1] cpu3 (AP): APIC ID: 3 [1] random: unblocking device. [1] ioapic0 irqs 0-23 on motherboard [1] random: entropy device external interface [1] kbd1 at kbdmux0 [1] netmap: loaded module [1] module_register_init: MOD_LOAD (vesa, 0xffffffff80eea620, 0) error 19 [1] random: registering fast source Intel Secure Key RNG [1] random: fast provider: "Intel Secure Key RNG" [1] vtvga0: on motherboard [1] cryptosoft0: on motherboard [1] aesni0: on motherboard [1] acpi0: on motherboard [1] acpi0: Power Button (fixed) [1] cpu0: on acpi0 [1] cpu1: on acpi0 [1] cpu2: on acpi0 [1] cpu3: on acpi0 [1] hpet0: iomem 0xfed00000-0xfed003ff on acpi0 [1] Timecounter "HPET" frequency 14318180 Hz quality 950 [1] Event timer "HPET" frequency 14318180 Hz quality 550 [1] Event timer "HPET1" frequency 14318180 Hz quality 440 [1] Event timer "HPET2" frequency 14318180 Hz quality 440 [1] Event timer "HPET3" frequency 14318180 Hz quality 440 [1] Event timer "HPET4" frequency 14318180 Hz quality 440 [1] atrtc0: port 0x70-0x77 irq 8 on acpi0 [1] atrtc0: Warning: Couldn't map I/O. [1] Event timer "RTC" frequency 32768 Hz quality 0 [1] attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 [1] Timecounter "i8254" frequency 1193182 Hz quality 0 [1] Event timer "i8254" frequency 1193182 Hz quality 100 [1] Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 [1] acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 [1] acpi_ec0: port 0x930,0x934 on acpi0 [1] pcib0: port 0xcf8-0xcff on acpi0 [1] pci0: on pcib0 [1] pcib1: irq 16 at device 1.0 on pci0 [1] pci1: on pcib1 [1] vgapci0: port 0xe000-0xe0ff mem 0xe0000000-0xefffffff,0xf7c00000-0xf7c3ffff irq 16 at device 0.0 on pci1 [1] vgapci1: port 0xf000-0xf03f mem 0xf5800000-0xf5bfffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 [1] agp0: on vgapci1 [1] agp0: aperture size is 256M, detected 32764k stolen memory [1] vgapci1: Boot video device [1] hdac0: mem 0xf7d24000-0xf7d27fff irq 16 at device 3.0 on pci0 [1] pci0: at device 22.0 (no driver attached) [1] uart2: port 0xf0e0-0xf0e7 mem 0xf7d2e000-0xf7d2efff irq 19 at device 22.3 on pci0 [1] em0: port 0xf080-0xf09f mem 0xf7d00000-0xf7d1ffff,0xf7d2d000-0xf7d2dfff irq 20 at device 25.0 on pci0 [1] em0: Using an MSI interrupt [1] em0: Ethernet address: f0:1f:af:4e:d5:85 [1] em0: netmap queues/slots: TX 1/1024, RX 1/1024 [1] ehci0: mem 0xf7d2c000-0xf7d2c3ff irq 16 at device 26.0 on pci0 [1] usbus0: EHCI version 1.0 [1] usbus0 on ehci0 [1] hdac1: mem 0xf7d20000-0xf7d23fff irq 22 at device 27.0 on pci0 [1] pcib2: irq 16 at device 28.0 on pci0 [1] pci2: on pcib2 [1] pcib3: irq 18 at device 28.2 on pci0 [1] pci3: on pcib3 [1] iwn0: mem 0xf7b00000-0xf7b01fff irq 18 at device 0.0 on pci3 [1] pcib4: irq 16 at device 28.4 on pci0 [1] pci4: on pcib4 [1] pcib5: irq 17 at device 28.5 on pci0 [1] pci5: on pcib5 [1] pcib6: irq 18 at device 28.6 on pci0 [1] pci6: on pcib6 [1] pcib7: irq 19 at device 28.7 on pci0 [1] pci7: on pcib7 [1] sdhci_pci0: mem 0xf7a01000-0xf7a01fff,0xf7a00000-0xf7a007ff irq 19 at device 0.0 on pci7 [1] sdhci_pci0: Hardware doesn't specify timeout clock frequency, setting BROKEN_TIMEOUT quirk. [1] sdhci_pci0: 1 slot(s) allocated [1] ehci1: mem 0xf7d2b000-0xf7d2b3ff irq 21 at device 29.0 on pci0 [1] usbus1: EHCI version 1.0 [1] usbus1 on ehci1 [1] isab0: at device 31.0 on pci0 [1] isa0: on isab0 [1] ahci0: port 0xf0d0-0xf0d7,0xf0c0-0xf0c3,0xf0b0-0xf0b7,0xf0a0-0xf0a3,0xf060-0xf07f mem 0xf7d2a000-0xf7d2a7ff irq 19 at device 31.2 on pci0 [1] ahci0: AHCI v1.30 with 5 6Gbps ports, Port Multiplier not supported [1] ahcich0: at channel 0 on ahci0 [1] ahcich1: at channel 1 on ahci0 [1] ahcich2: at channel 2 on ahci0 [1] ahciem0: on ahci0 [1] acpi_lid0: on acpi0 [1] acpi_button0: on acpi0 [1] acpi_button1: on acpi0 [1] acpi_acad0: on acpi0 [1] battery0: on acpi0 [1] battery1: on acpi0 [1] acpi_tz0: on acpi0 [1] atkbdc0: port 0x60,0x64 irq 1 on acpi0 [1] atkbd0: irq 1 on atkbdc0 [1] kbd0 at atkbd0 [1] atkbd0: [GIANT-LOCKED] [1] psm0: irq 12 on atkbdc0 [1] psm0: [GIANT-LOCKED] [1] psm0: model GlidePoint, device ID 0 [1] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 [1] ppc0: port 0x378-0x37b irq 7 on acpi0 [1] ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode [1] ppc0: FIFO with 16/16/7 bytes threshold [1] ppbus0: on ppc0 [1] lpt0: on ppbus0 [1] lpt0: Interrupt-driven port [1] ppi0: on ppbus0 [1] coretemp0: on cpu0 [1] est0: on cpu0 [1] coretemp1: on cpu1 [1] est1: on cpu1 [1] coretemp2: on cpu2 [1] est2: on cpu2 [1] coretemp3: on cpu3 [1] est3: on cpu3 [1] usbus0: 480Mbps High Speed USB v2.0 [1] Timecounters tick every 1.000 msec [1] IPsec: Initialized Security Association Processing. [1] hdacc0: at cad 0 on hdac0 [1] hdaa0: at nid 1 on hdacc0 [1] pcm0: at nid 5 on hdaa0 [1] pcm1: at nid 6 on hdaa0 [1] pcm2: at nid 7 on hdaa0 [1] hdacc1: at cad 0 on hdac1 [1] hdaa1: at nid 1 on hdacc1 [1] pcm3: at nid 20,21 on hdaa1 [1] pcm4: at nid 22 on hdaa1 [1] usbus1: 480Mbps High Speed USB v2.0 [1] ugen0.1: at usbus0 [1] uhub0: on usbus0 [1] ugen1.1: at usbus1 [1] uhub1: on usbus1 [1] ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 [1] ses0: SEMB S-E-S 2.00 device [1] ses0: SEMB SES Device [1] ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 [1] ada0: ACS-2 ATA SATA 3.x device [1] ada0: Serial Number W370VA47 [1] ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) [1] ada0: Command Queueing enabled [1] ada0: 476940MB (976773168 512 byte sectors) [1] cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 [1] cd0: Removable CD-ROM SCSI device [1] cd0: Serial Number KW4D8RK1330 [1] cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) [1] cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed [1] SMP: AP CPU #1 Launched! [1] SMP: AP CPU #2 Launched! [1] SMP: AP CPU #3 Launched! [1] Timecounter "TSC-low" frequency 1297023078 Hz quality 1000 [1] WARNING: WITNESS option enabled, expect reduced performance. [1] Trying to mount root from ufs:/dev/ada0s1a [rw]... [2] uhub0: 3 ports with 3 removable, self powered [2] uhub1: 3 ports with 3 removable, self powered [3] ugen0.2: at usbus0 [3] uhub2: on usbus0 [3] ugen1.2: at usbus1 [3] uhub3: on usbus1 [3] uhub2: 6 ports with 6 removable, self powered [3] uhub3: 8 ports with 8 removable, self powered [5] ugen1.3: at usbus1 [5] umass0: on usbus1 [5] umass0: SCSI over Bulk-Only; quirks = 0x8100 [5] umass0:4:0: Attached to scbus4 [5] da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 [5] da0: Removable Direct Access SPC-2 SCSI device [5] da0: Serial Number 001D7D06D2A0BE60A9C60611 [5] da0: 40.000MB/s transfers [5] da0: 30008MB (61457664 512 byte sectors) [5] da0: quirks=0x3 [6] ugen1.4: at usbus1 [6] uhub4: on usbus1 [6] uhub4: MTT enabled [6] uhub4: 3 ports with 3 removable, self powered [7] ugen1.5: at usbus1 [8] ugen1.6: at usbus1 [8] uhub5: on usbus1 [8] uhub5: MTT enabled [8] uhub5: 3 ports with 3 removable, self powered [18] GEOM_ELI: Device ada0s1d.eli created. [18] GEOM_ELI: Encryption: AES-XTS 256 [18] GEOM_ELI: Crypto: hardware [18] GEOM_ELI: Device ada0s1b.eli created. [18] GEOM_ELI: Encryption: AES-XTS 128 [18] GEOM_ELI: Crypto: hardware [22] ums0: on usbus1 [22] ums0: 3 buttons and [XYZ] coordinates ID=0 [28] Security policy loaded: HardenedBSD SECADM Module (secadm) [61] info: [drm] Initialized drm 1.1.0 20060810 [61] drmn1: on vgapci1 [61] info: [drm] Memory usable by graphics device = 2048M [61] info: [drm] MTRR allocation failed. Graphics performance may suffer. [61] iicbus0: error: [drm:pid73115:i915_write32] *ERROR* Unknown unclaimed register before writing to c5100 [61] on iicbb0 addr 0xff [61] iic0: on iicbus0 [61] iic1: on iicbus1 [61] iicbus2: on iicbb1 addr 0x0 [61] iic2: on iicbus2 [61] iic3: on iicbus3 [61] iicbus4: on iicbb2 addr 0x0 [61] iic4: on iicbus4 [61] iic5: on iicbus5 [61] iicbus6: on iicbb3 addr 0x0 [61] iic6: on iicbus6 [61] iic7: on iicbus7 [61] iicbus8: on iicbb4 addr 0x0 [61] iic8: on iicbus8 [61] iic9: on iicbus9 [61] iicbus10: on iicbb5 addr 0x0 [61] iic10: on iicbus10 [61] iic11: on iicbus11 [61] info: [drm] MSI enabled 1 message(s) [61] info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [61] info: [drm] Driver supports precise vblank timestamp query. [61] drmn1: taking over the fictitious range 0xd0000000-0xe0000000 [61] info: [drm] Connector eDP-1: get mode from tunables: [61] info: [drm] - kern.vt.fb.modes.eDP-1 [61] info: [drm] - kern.vt.fb.default_mode [61] info: [drm] Connector VGA-1: get mode from tunables: [61] info: [drm] - kern.vt.fb.modes.VGA-1 [61] info: [drm] - kern.vt.fb.default_mode [61] info: [drm] Connector HDMI-A-1: get mode from tunables: [61] info: [drm] - kern.vt.fb.modes.HDMI-A-1 [61] info: [drm] - kern.vt.fb.default_mode [61] info: [drm] Connector DP-1: get mode from tunables: [61] info: [drm] - kern.vt.fb.modes.DP-1 [61] info: [drm] - kern.vt.fb.default_mode [61] info: [drm] Connector HDMI-A-2: get mode from tunables: [61] info: [drm] - kern.vt.fb.modes.HDMI-A-2 [61] info: [drm] - kern.vt.fb.default_mode [61] info: [drm] Connector DP-2: get mode from tunables: [61] info: [drm] - kern.vt.fb.modes.DP-2 [61] info: [drm] - kern.vt.fb.default_mode [61] info: [drm] Connector HDMI-A-3: get mode from tunables: [61] info: [drm] - kern.vt.fb.modes.HDMI-A-3 [61] info: [drm] - kern.vt.fb.default_mode [61] info: [drm] Connector DP-3: get mode from tunables: [61] info: [drm] - kern.vt.fb.modes.DP-3 [61] info: [drm] - kern.vt.fb.default_mode [61] fbd1 on drmn1 [61] VT: Replacing driver "vga" with new "fb". [61] info: [drm] Initialized i915 1.6.0 20080730 for drmn1 on minor 1 [62] info: [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off [201] em0: link state changed to UP [301] [HBSD INTERNAL] the process has non-default settings [301] -> fname: /usr/local/bin/firefox [301] -> pid: 96371 ppid: 25304 p_pax: 0x56a [305] lock order reversal: [305] 1st 0xfffffe01ea4c6f40 bufwait (bufwait) @ /jenkins/workspace/HardenedBSD-CURRENT-i915kms-amd64/sys/kern/vfs_bio.c:3488 [305] 2nd 0xfffff80006806200 dirhash (dirhash) @ /jenkins/workspace/HardenedBSD-CURRENT-i915kms-amd64/sys/ufs/ufs/ufs_dirhash.c:281 [305] stack backtrace: [305] #0 0xffffffff80a7f360 at witness_debugger+0x70 [305] #1 0xffffffff80a7f261 at witness_checkorder+0xe71 [305] #2 0xffffffff80a2d0e2 at _sx_xlock+0x72 [305] #3 0xffffffff80cc39c7 at ufsdirhash_remove+0x37 [305] #4 0xffffffff80cc8747 at ufs_dirremove+0x127 [305] #5 0xffffffff80cce615 at ufs_remove+0x75 [305] #6 0xffffffff80fc26a7 at VOP_REMOVE_APV+0xf7 [305] #7 0xffffffff80add823 at kern_unlinkat+0x213 [305] #8 0xffffffff80e6effb at amd64_syscall+0x2db [305] #9 0xffffffff80e4eb8b at Xfast_syscall+0xfb From owner-freebsd-current@freebsd.org Tue Mar 1 17:11:13 2016 Return-Path: Delivered-To: freebsd-current@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 16E9CABD7D5 for ; Tue, 1 Mar 2016 17:11:13 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 ACF0110D0 for ; Tue, 1 Mar 2016 17:11:12 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id n186so47450934wmn.1 for ; Tue, 01 Mar 2016 09:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=WS57ztUz3JkSTjBCWxK/95adDUNys854n4WOfyvzlE8=; b=qDS3mzJm6Jz3BhsTB2WCqExiYo4nUGfMYQIoRIF/pXZ0a7eiFcGmTSsCozh5xuWmdP 0paeNdjXhg64aQJIplX3Vl3WYN4b1nZLCRyAtgfLG9uS2I0tGLAz1JjUl4gQ+xiVHaKp mgF442TZkRf+rj40+hq3CAYedlLuf0oo7C6cLzXwtyj2GOpNtBIDShX7BwiNFKTcTZtJ PVqc1Sp9iGC7x4QE+cKX5tRG3YApMYMUAx+iETJx1J+z/wUzGGxoQm7V3SPpnot2/oid eQIhfWAAtCTg6aoKkYof/GU9l+3pNiiMM4dccPWrKYCTwN6h6s0CuZ650+fILn49DRq3 tUJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=WS57ztUz3JkSTjBCWxK/95adDUNys854n4WOfyvzlE8=; b=gm6N8ItQh8Gd5yUOJiEqoZ/90/CeTHcYBXvY5bTHROrr5UcUYNiL6B5AEszFUj5M+L PBABzBNN4j97G8hdnkKeYoCn3vHHcJ+JCjQPQB5/pFV72Dp7ArTS2dZbh3Uf/cr6DPi8 yHYr4HxrkQOrLQgpgz8873Yjd4/zl7OINaTwfmY33pZMC1UBMMotDOCzJr3S8LGWK46R nGkjfqzDiKOIS1Nfu8V25IN43D82qrcSDiUoMBNNCjW65IQlDBoGnTil8OAOxhLsWQDO Qf8hzIv6pqegN8H/WCL8g+nGzpzXNyleSbzQ7eZrS789Josdv8np5urfHLOSKjodPUF0 WlOg== X-Gm-Message-State: AD7BkJJ3H8TvwvodmrY/uJQtPBQJvs04RM51oqL5/n23Wu/UXgd3KxWF+vr8MiPue8lPuQ== X-Received: by 10.194.24.39 with SMTP id r7mr20439158wjf.86.1456852270570; Tue, 01 Mar 2016 09:11:10 -0800 (PST) Received: from laptop.minsk.domain ([37.215.36.68]) by smtp.gmail.com with ESMTPSA id 202sm107822wmo.7.2016.03.01.09.11.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Mar 2016 09:11:09 -0800 (PST) Date: Tue, 1 Mar 2016 20:08:10 +0300 From: "Sergey V. Dyatko" To: Anthony Jenkins Cc: freebsd-current@freebsd.org Subject: Re: Touchscreen support (was Re: new computer, strange usb messages at boot) Message-ID: <20160301200810.7063ad53@laptop.minsk.domain> In-Reply-To: <56D5AF47.7080005@yahoo.com> References: <20160220051951.GA47875@lrosenman-dell.lerctr.org> <20160220120401.GA91220@kib.kiev.ua> <20160220122416.GA1026@lrosenman-dell.lerctr.org> <2575cfd714188f7ffbc873cb5d87cc97@thebighonker.lerctr.org> <56CA6F67.4000001@yahoo.com> <56CAB4A7.8080604@selasky.org> <56CB39B0.3020307@yahoo.com> <56CB3C74.7050103@selasky.org> <20160301083006.671d3987@laptop.minsk.domain> <56D59E51.4040409@yahoo.com> <20160301173408.10e4767f@laptop.minsk.domain> <56D5AF47.7080005@yahoo.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 17:11:13 -0000 On Tue, 1 Mar 2016 10:03:35 -0500 Anthony Jenkins wrote: > On 03/01/2016 09:34 AM, Sergey V. Dyatko wrote: > > On Tue, 1 Mar 2016 08:51:13 -0500 > > Anthony Jenkins wrote: > > > >> On 03/01/2016 12:30 AM, Sergey V. Dyatko wrote: > >>> On Mon, 22 Feb 2016 17:51:00 +0100 > >>> Hans Petter Selasky wrote: > >>> > >>>> On 02/22/16 17:39, Anthony Jenkins wrote: > >>>>> On 02/22/2016 02:11 AM, Hans Petter Selasky wrote: > >>>>>> On 02/22/16 03:16, Anthony Jenkins wrote: > >>>>>>> Yes. I have an eGalax touchscreen and it's doing the same thing. The > >>>>>>> number of items it's reporting is 256 (according to my preliminary > >>>>>>> debugging), causing the warning. I think these things are a special > >>>>>>> subclass of HID for multitouch touchscreens which we don't support > >>>>>>> (yet). > >>>>>> /usr/ports/multimedia/webcamd will most likely attach if invoked > >>>>>> manually, to this device and provide an event device for you! > >>>>>> > >>>>>> --HPS > >>>>> Okay that's /amazing/, and not at all intuitive! I mean I'd expect > >>>>> multimedia/webcamd to only attach to "video" devices, but lo and behold > >>>>> I get a /dev/input/event0 device which spits out gibberish when > >>>>> cat(1)'ed and I touch the screen! > >>>>> > >>>>> My intentions were to port Linux's hid-multitouch device in whole to > >>>>> FreeBSD (it's what attaches to my eGalax device and probably to OP's > >>>>> touchscreen device) and add support for the device to moused(8), but > >>>>> it's not very high on my priority list... > >>>>> > >>>> Hi, > >>>> > >>>> If you apply these patches, will work with your X-org :-) > >>>> > >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196678 > >>>> > >>> wow... > >>> Thanks for your work :) > >>> > >>> Yesterday I update -CURRENT on my lenovo z400 touch ( r296180), after > >>> suspend-resume I spotted that is my usb mouse didn't work (touchpad works > >>> as before) > >>> I had the feeling that I read something about hid_get_item: Number of > >>> items(256) truncated to 255 on ML, so I'm here. > >>> > >>> What I do: > >>> laptop# webcamd -l > >>> Available device(s): > >>> .... > >>> webcamd [-d ugen0.2] -N Synaptics-Large-Touch-Screen-SYNAPTICS -S unknown > >>> -M 0 ... > >>> Show webcamd usage: > >>> webcamd -h > >>> laptop# webcamd -N Synaptics-Large-Touch-Screen-SYNAPTICS -S unknown -M 0 > >>> Attached to ugen0.2[0] > >>> Creating /dev/input/event0 > >>> > >>> after that I reconnect my mouse and 'it works' (c) > >>> How I can do this automatically right? > >> I got my touchscreen working with the multimedia/webcamd and > >> x11-drivers/xf86-input-evdev ports and an entry in > >> /usr/local/etc/devd/webcamd.conf for my eGalax USB touchscreen device. > >> In webcamd.conf, you can copy the section > >> > >> # Generic USB input devices. > >> notify 100 { > >> match "system" "USB"; > >> match "subsystem" "INTERFACE"; > >> match "type" "ATTACH"; > >> match "intclass" "0x03"; > >> # > >> # Limit HID device attach to Wacom Devices > >> # else webcamd might attach to your keyboard > >> # and mouse > >> # > >> match "vendor" "0x056a"; > >> action "/usr/local/etc/rc.d/webcamd start $cdev $interface"; > >> }; > >> > >> to a new section, changing the 'match "vendor" line to match the USB > >> VendorID of your input device and possibly adding a 'match "product" line: > >> > >> $ sudo usbconfig -d ugen1.2 dump_device_desc | grep 'id\(Vendor\|Product\)' > >> idVendor = 0x0eef > >> idProduct = 0xa119 > >> > >> # My eGalax Touchscreen device. > >> notify 100 { > >> match "system" "USB"; > >> match "subsystem" "INTERFACE"; > >> match "type" "ATTACH"; > >> match "intclass" "0x03"; > >> match "vendor" "0x0eef"; > >> match "product" "0xa119"; > >> action "/usr/local/etc/rc.d/webcamd start $cdev $interface"; > >> }; > >> > >> replacing "ugen1.2" above with your "ugen0.2" as well as the vendor and > >> product values. > >> > > Thanks, I'll try this. > > few hours ago I: > > 1) install x11-drivers/xf86-input-evdev > > 2) place following to rc.conf.d/webcamd: > > > > [tiger@laptop]:~>cat /etc/rc.conf.d/webcamd > > webcamd_0_flags="-N Lenovo-EasyCamera-Generic -S 200901010001" > > webcamd_1_flags="-N Synaptics-Large-Touch-Screen-SYNAPTICS -S unknown" > I didn't modify any of webcamd's flags in the rc.conf* files. You will > also have to restart devd(8) ('/etc/rc.d/devd restart') to pick up the > change to /usr/local/etc/devd/webcamd.conf. > > Do you see an instance of webcamd(8) running for your touchscreen? Is > there a /dev/input/event* device node? > laptop# ps axuw |grep webca root 14534 0,0 0,1 35664 6140 - Is 19:43 0:00,51 /usr/local/sbin/webcamd -N Lenovo-EasyCamera-Generic -S 200 root 14543 0,0 0,1 27344 5832 - Is 19:43 0:00,50 /usr/local/sbin/webcamd -N Synaptics-Large-Touch-Screen-SYN laptop# env LC_ALL=C ls -l /dev/input/event* crw-rw---- 1 webcamd webcamd 0x71 Mar 1 19:43 /dev/input/event0 > I'm running my own spin of xorg-server/config/devd.c, different from the > proposed patch to x11-servers/xorg-server, but that really shouldn't be > the reason for your difficulty. > Well.. Seems I missed this step, I have un-patched xorg-server ;( > > webcamd_enable="YES" > > 3) restart xorg but still no luck, possible I need change something on > > xorg.conf? > > > > [tiger@laptop]:~>grep -i input /var/log/Xorg.0.log > > [ 60690.944] (**) |-->Input Device "Mouse0" > > [ 60690.944] (**) |-->Input Device "Keyboard0" > > [ 60690.945] X.Org XInput driver : 21.0 > > [ 60690.979] (II) intel(0): Digital Display Input > > [ 60691.175] (II) config/hal: Adding input device usbhid > > [ 60691.175] (EE) No input driver matching `wacom' > > [ 60691.175] (EE) config/hal: NewInputDeviceRequest failed (15) > > [ 60691.179] (II) config/hal: Adding input device USB Optical Mouse > > [ 60691.180] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so > > [ 60691.180] Module class: X.Org XInput Driver > > [ 60691.180] ABI class: X.Org XInput driver, version 21.0 > > [ 60691.180] (II) Using input driver 'mouse' for 'USB Optical Mouse' > > [ 60691.180] (II) XINPUT: Adding extended input device "USB Optical > > Mouse" (type: MOUSE, id 6) [ 60691.183] (II) config/hal: Adding input > > device AT Keyboard [ 60691.184] (II) > > Loading /usr/local/lib/xorg/modules/input/kbd_drv.so [ 60691.184] Module > > class: X.Org XInput Driver [ 60691.184] ABI class: X.Org XInput driver, > > version 21.0 [ 60691.184] (II) Using input driver 'kbd' for 'AT Keyboard' > > [ 60691.184] (II) XINPUT: Adding extended input device "AT Keyboard" (type: > > KEYBOARD, id 7) [ 60691.196] (II) config/hal: Adding input device PS/2 Mouse > > [ 60691.196] (II) Using input driver 'mouse' for 'PS/2 Mouse' > > [ 60691.270] (II) XINPUT: Adding extended input device "PS/2 Mouse" (type: > > MOUSE, id 8) > > > -- wbr, tiger From owner-freebsd-current@freebsd.org Tue Mar 1 17:28:42 2016 Return-Path: Delivered-To: freebsd-current@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 EF138ABDEB6 for ; Tue, 1 Mar 2016 17:28:41 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E7471A35 for ; Tue, 1 Mar 2016 17:28:41 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: by mail-vk0-x235.google.com with SMTP id e185so174857286vkb.1 for ; Tue, 01 Mar 2016 09:28:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=83p5l7QdKUL5lRJESZ8cCjmGWfdsObNOWtwK273wQgs=; b=il4AscN1cl+fawfX/Ap2koZtJrvSgaGmnq+paH1GX9nT24HMPxvEXSetZ3v3lycWjT bKLJEL7J4dio9bgVFOZxstoV4G+BeFcHn7YSBL+GQqu9Lt6woDeSlZkyylf09QRgURL1 rS3XqmyAX4g+zaolC7mx8zeHSHIpwjfO52IOL6oeP7Qz3psE0DFMVKemcukiM4zxB541 gIOm3ckTqUfeYkvSrPFa4bf9dvDrkqj0P0GmK3UlOJNBxs3wXdc8fjaY+DhDff34fhr6 BQekW/dWIx85j8a45xKUuh7HNto+U8BlYahqY7E1HDHs3U2YdAGlepjwb2HdJQO4PS3s mNUA== 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:date :message-id:subject:from:to:cc; bh=83p5l7QdKUL5lRJESZ8cCjmGWfdsObNOWtwK273wQgs=; b=JisYNDYeGhGL89sBOuUpUDeDtYTgPheNUsYdpIQvLl8cayHc+T4XGrfotl5N54BLNL Yy+3rO2iji6GTwKzdWMMgwIh3s7c20QBgDfw5iKNARFWXfaCLWqcPOM06KhhHIBhcz6U Q40XyQkvyXGVyGb1cJTRTuCzGrygy8i+HePquvF/UW/I3EsROOlKLo7ZdbgefFR+sFaW tXs2xB2p3v0IVxohWd+AKCVk5exL85qxZ5wegtsJ/wTcbsIAkVGp09T6ZPQ3acy/WVR7 D+ou36iF69/RadL48Iqis1535uONEuzYwdDgNgQJLOHUykgiPeVbCy1OHOFu1hnPq8Ev nm/Q== X-Gm-Message-State: AD7BkJLtZqs5Txw31B7Pvxja8/hbtwdgBKYxsvChiLf8vImrR5tmqnjMDh+vRIdyJamKXLs08omip5p6VeqgMA== MIME-Version: 1.0 X-Received: by 10.31.133.19 with SMTP id h19mr16789326vkd.127.1456853320306; Tue, 01 Mar 2016 09:28:40 -0800 (PST) Received: by 10.103.37.196 with HTTP; Tue, 1 Mar 2016 09:28:40 -0800 (PST) In-Reply-To: <1493379294.130887.1456847269287.JavaMail.ngmail@webmail21.arcor-online.net> References: <1493379294.130887.1456847269287.JavaMail.ngmail@webmail21.arcor-online.net> Date: Tue, 1 Mar 2016 12:28:40 -0500 Message-ID: Subject: Re: WLAN hardware not recognized From: Joe Nosay To: Carsten Kunze Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 17:28:42 -0000 Is the card removable? If so, have you tried plugging in one that would have the driver already included with the base - so to speak - system? Have you tried the card in another computer/laptop? On Tue, Mar 1, 2016 at 10:47 AM, Carsten Kunze wrote: > Hello, > > the WLAN hardware of my Dell E6540 (intel 633ANHMW) is not recognized (or > at least does not work). > The only message found in dmesg is: > > [1] iwn0: mem 0xf7b00000-0xf7b01fff irq 18 > at device 0.0 on pci3 > > Full dmesg is: > > Copyright (c) 2013-2016 The HardenedBSD Project. > [1] Copyright (c) 1992-2016 The FreeBSD Project. > [1] Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, > 1994 > [1] The Regents of the University of California. All rights reserved. > [1] FreeBSD is a registered trademark of The FreeBSD Foundation. > [1] FreeBSD 11.0-CURRENT-HBSD #18 7affcca(HEAD): Fri Feb 19 03:41:41 EST > 2016 > [1] jenkins@nyi-01.build.hardenedbsd.org:/usr/obj/jenkins/workspace/HardenedBSD-CURRENT-i915kms-amd64/sys/HARDENEDBSD > amd64 > [1] FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225 > [1] WARNING: WITNESS option enabled, expect reduced performance. > [1] VT(vga): resolution 640x480 > [1] HBSD: initialize and check HardenedBSD features (version 41). > [1] [HBSD LOG] logging to system: enabled > [1] [HBSD LOG] logging to user: disabled > [1] [HBSD ASLR] status: opt-out > [1] [HBSD ASLR] mmap: 30 bit > [1] [HBSD ASLR] exec base: 30 bit > [1] [HBSD ASLR] stack: 42 bit > [1] [HBSD ASLR] vdso: 28 bit > [1] [HBSD ASLR] map32bit: 18 bit > [1] [HBSD ASLR] disallow MAP_32BIT mode mmap: opt-out > [1] [HBSD PAGEEXEC] status: opt-out > [1] [HBSD MPROTECT] status: opt-out > [1] [HBSD HARDENING] procfs hardening: enabled > [1] [HBSD HARDENING] randomize pids: enabled > [1] [HBSD HARDENING] unset insecure init variables: enabled > [1] [HBSD SEGVGUARD] status: opt-in > [1] [HBSD SEGVGUARD] expiry: 120 sec > [1] [HBSD SEGVGUARD] suspension: 600 sec > [1] [HBSD SEGVGUARD] maxcrahes: 5 > [1] CPU: Intel(R) Core(TM) i5-4300M CPU @ 2.60GHz (2594.05-MHz K8-class > CPU) > [1] Origin="GenuineIntel" Id=0x306c3 Family=0x6 Model=0x3c Stepping=3 > [1] > Features=0xbfebfbff > [1] > Features2=0x7ffafbff > [1] AMD Features=0x2c100800 > [1] AMD Features2=0x21 > [1] Structured Extended > Features=0x27ab > [1] XSAVE Features=0x1 > [1] VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID > [1] TSC: P-state invariant, performance statistics > [1] real memory = 8589934592 (8192 MB) > [1] avail memory = 8158760960 (7780 MB) > [1] Event timer "LAPIC" quality 600 > [1] ACPI APIC Table: > [1] FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > [1] FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads > [1] cpu0 (BSP): APIC ID: 0 > [1] cpu1 (AP): APIC ID: 1 > [1] cpu2 (AP): APIC ID: 2 > [1] cpu3 (AP): APIC ID: 3 > [1] random: unblocking device. > [1] ioapic0 irqs 0-23 on motherboard > [1] random: entropy device external interface > [1] kbd1 at kbdmux0 > [1] netmap: loaded module > [1] module_register_init: MOD_LOAD (vesa, 0xffffffff80eea620, 0) error 19 > [1] random: registering fast source Intel Secure Key RNG > [1] random: fast provider: "Intel Secure Key RNG" > [1] vtvga0: on motherboard > [1] cryptosoft0: on motherboard > [1] aesni0: on motherboard > [1] acpi0: on motherboard > [1] acpi0: Power Button (fixed) > [1] cpu0: on acpi0 > [1] cpu1: on acpi0 > [1] cpu2: on acpi0 > [1] cpu3: on acpi0 > [1] hpet0: iomem 0xfed00000-0xfed003ff on > acpi0 > [1] Timecounter "HPET" frequency 14318180 Hz quality 950 > [1] Event timer "HPET" frequency 14318180 Hz quality 550 > [1] Event timer "HPET1" frequency 14318180 Hz quality 440 > [1] Event timer "HPET2" frequency 14318180 Hz quality 440 > [1] Event timer "HPET3" frequency 14318180 Hz quality 440 > [1] Event timer "HPET4" frequency 14318180 Hz quality 440 > [1] atrtc0: port 0x70-0x77 irq 8 on acpi0 > [1] atrtc0: Warning: Couldn't map I/O. > [1] Event timer "RTC" frequency 32768 Hz quality 0 > [1] attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > [1] Timecounter "i8254" frequency 1193182 Hz quality 0 > [1] Event timer "i8254" frequency 1193182 Hz quality 100 > [1] Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > [1] acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 > [1] acpi_ec0: port 0x930,0x934 on acpi0 > [1] pcib0: port 0xcf8-0xcff on acpi0 > [1] pci0: on pcib0 > [1] pcib1: irq 16 at device 1.0 on pci0 > [1] pci1: on pcib1 > [1] vgapci0: port 0xe000-0xe0ff mem > 0xe0000000-0xefffffff,0xf7c00000-0xf7c3ffff irq 16 at device 0.0 on pci1 > [1] vgapci1: port 0xf000-0xf03f mem > 0xf5800000-0xf5bfffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 > [1] agp0: on vgapci1 > [1] agp0: aperture size is 256M, detected 32764k stolen memory > [1] vgapci1: Boot video device > [1] hdac0: mem 0xf7d24000-0xf7d27fff irq 16 > at device 3.0 on pci0 > [1] pci0: at device 22.0 (no driver attached) > [1] uart2: port 0xf0e0-0xf0e7 mem > 0xf7d2e000-0xf7d2efff irq 19 at device 22.3 on pci0 > [1] em0: port 0xf080-0xf09f > mem 0xf7d00000-0xf7d1ffff,0xf7d2d000-0xf7d2dfff irq 20 at device 25.0 on > pci0 > [1] em0: Using an MSI interrupt > [1] em0: Ethernet address: f0:1f:af:4e:d5:85 > [1] em0: netmap queues/slots: TX 1/1024, RX 1/1024 > [1] ehci0: mem > 0xf7d2c000-0xf7d2c3ff irq 16 at device 26.0 on pci0 > [1] usbus0: EHCI version 1.0 > [1] usbus0 on ehci0 > [1] hdac1: mem 0xf7d20000-0xf7d23fff irq > 22 at device 27.0 on pci0 > [1] pcib2: irq 16 at device 28.0 on pci0 > [1] pci2: on pcib2 > [1] pcib3: irq 18 at device 28.2 on pci0 > [1] pci3: on pcib3 > [1] iwn0: mem 0xf7b00000-0xf7b01fff irq 18 > at device 0.0 on pci3 > [1] pcib4: irq 16 at device 28.4 on pci0 > [1] pci4: on pcib4 > [1] pcib5: irq 17 at device 28.5 on pci0 > [1] pci5: on pcib5 > [1] pcib6: irq 18 at device 28.6 on pci0 > [1] pci6: on pcib6 > [1] pcib7: irq 19 at device 28.7 on pci0 > [1] pci7: on pcib7 > [1] sdhci_pci0: mem > 0xf7a01000-0xf7a01fff,0xf7a00000-0xf7a007ff irq 19 at device 0.0 on pci7 > [1] sdhci_pci0: Hardware doesn't specify timeout clock frequency, setting > BROKEN_TIMEOUT quirk. > [1] sdhci_pci0: 1 slot(s) allocated > [1] ehci1: mem > 0xf7d2b000-0xf7d2b3ff irq 21 at device 29.0 on pci0 > [1] usbus1: EHCI version 1.0 > [1] usbus1 on ehci1 > [1] isab0: at device 31.0 on pci0 > [1] isa0: on isab0 > [1] ahci0: port > 0xf0d0-0xf0d7,0xf0c0-0xf0c3,0xf0b0-0xf0b7,0xf0a0-0xf0a3,0xf060-0xf07f mem > 0xf7d2a000-0xf7d2a7ff irq 19 at device 31.2 on pci0 > [1] ahci0: AHCI v1.30 with 5 6Gbps ports, Port Multiplier not supported > [1] ahcich0: at channel 0 on ahci0 > [1] ahcich1: at channel 1 on ahci0 > [1] ahcich2: at channel 2 on ahci0 > [1] ahciem0: on ahci0 > [1] acpi_lid0: on acpi0 > [1] acpi_button0: on acpi0 > [1] acpi_button1: on acpi0 > [1] acpi_acad0: on acpi0 > [1] battery0: on acpi0 > [1] battery1: on acpi0 > [1] acpi_tz0: on acpi0 > [1] atkbdc0: port 0x60,0x64 irq 1 on acpi0 > [1] atkbd0: irq 1 on atkbdc0 > [1] kbd0 at atkbd0 > [1] atkbd0: [GIANT-LOCKED] > [1] psm0: irq 12 on atkbdc0 > [1] psm0: [GIANT-LOCKED] > [1] psm0: model GlidePoint, device ID 0 > [1] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > [1] ppc0: port 0x378-0x37b irq 7 on acpi0 > [1] ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > [1] ppc0: FIFO with 16/16/7 bytes threshold > [1] ppbus0: on ppc0 > [1] lpt0: on ppbus0 > [1] lpt0: Interrupt-driven port > [1] ppi0: on ppbus0 > [1] coretemp0: on cpu0 > [1] est0: on cpu0 > [1] coretemp1: on cpu1 > [1] est1: on cpu1 > [1] coretemp2: on cpu2 > [1] est2: on cpu2 > [1] coretemp3: on cpu3 > [1] est3: on cpu3 > [1] usbus0: 480Mbps High Speed USB v2.0 > [1] Timecounters tick every 1.000 msec > [1] IPsec: Initialized Security Association Processing. > [1] hdacc0: at cad 0 on hdac0 > [1] hdaa0: at nid 1 on hdacc0 > [1] pcm0: at nid 5 on hdaa0 > [1] pcm1: at nid 6 on hdaa0 > [1] pcm2: at nid 7 on hdaa0 > [1] hdacc1: at cad 0 on hdac1 > [1] hdaa1: at nid 1 on hdacc1 > [1] pcm3: at nid 20,21 on hdaa1 > [1] pcm4: at nid 22 on hdaa1 > [1] usbus1: 480Mbps High Speed USB v2.0 > [1] ugen0.1: at usbus0 > [1] uhub0: on > usbus0 > [1] ugen1.1: at usbus1 > [1] uhub1: on > usbus1 > [1] ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 > [1] ses0: SEMB S-E-S 2.00 device > [1] ses0: SEMB SES Device > [1] ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > [1] ada0: ACS-2 ATA SATA 3.x device > [1] ada0: Serial Number W370VA47 > [1] ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > [1] ada0: Command Queueing enabled > [1] ada0: 476940MB (976773168 512 byte sectors) > [1] cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 > [1] cd0: Removable CD-ROM SCSI device > [1] cd0: Serial Number KW4D8RK1330 > [1] cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO > 8192bytes) > [1] cd0: Attempt to query device size failed: NOT READY, Medium not > present - tray closed > [1] SMP: AP CPU #1 Launched! > [1] SMP: AP CPU #2 Launched! > [1] SMP: AP CPU #3 Launched! > [1] Timecounter "TSC-low" frequency 1297023078 Hz quality 1000 > [1] WARNING: WITNESS option enabled, expect reduced performance. > [1] Trying to mount root from ufs:/dev/ada0s1a [rw]... > [2] uhub0: 3 ports with 3 removable, self powered > [2] uhub1: 3 ports with 3 removable, self powered > [3] ugen0.2: at usbus0 > [3] uhub2: 2> on usbus0 > [3] ugen1.2: at usbus1 > [3] uhub3: 2> on usbus1 > [3] uhub2: 6 ports with 6 removable, self powered > [3] uhub3: 8 ports with 8 removable, self powered > [5] ugen1.3: at usbus1 > [5] umass0: > on usbus1 > [5] umass0: SCSI over Bulk-Only; quirks = 0x8100 > [5] umass0:4:0: Attached to scbus4 > [5] da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 > [5] da0: Removable Direct Access SPC-2 > SCSI device > [5] da0: Serial Number 001D7D06D2A0BE60A9C60611 > [5] da0: 40.000MB/s transfers > [5] da0: 30008MB (61457664 512 byte sectors) > [5] da0: quirks=0x3 > [6] ugen1.4: at usbus1 > [6] uhub4: on usbus1 > [6] uhub4: MTT enabled > [6] uhub4: 3 ports with 3 removable, self powered > [7] ugen1.5: at usbus1 > [8] ugen1.6: at usbus1 > [8] uhub5: 6> on usbus1 > [8] uhub5: MTT enabled > [8] uhub5: 3 ports with 3 removable, self powered > [18] GEOM_ELI: Device ada0s1d.eli created. > [18] GEOM_ELI: Encryption: AES-XTS 256 > [18] GEOM_ELI: Crypto: hardware > [18] GEOM_ELI: Device ada0s1b.eli created. > [18] GEOM_ELI: Encryption: AES-XTS 128 > [18] GEOM_ELI: Crypto: hardware > [22] ums0: 5> on usbus1 > [22] ums0: 3 buttons and [XYZ] coordinates ID=0 > [28] Security policy loaded: HardenedBSD SECADM Module (secadm) > [61] info: [drm] Initialized drm 1.1.0 20060810 > [61] drmn1: on vgapci1 > [61] info: [drm] Memory usable by graphics device = 2048M > [61] info: [drm] MTRR allocation failed. Graphics performance may suffer. > [61] iicbus0: error: [drm:pid73115:i915_write32] *ERROR* > Unknown unclaimed register before writing to c5100 > [61] on iicbb0 addr 0xff > [61] iic0: on iicbus0 > [61] iic1: on iicbus1 > [61] iicbus2: on iicbb1 addr 0x0 > [61] iic2: on iicbus2 > [61] iic3: on iicbus3 > [61] iicbus4: on iicbb2 addr 0x0 > [61] iic4: on iicbus4 > [61] iic5: on iicbus5 > [61] iicbus6: on iicbb3 addr 0x0 > [61] iic6: on iicbus6 > [61] iic7: on iicbus7 > [61] iicbus8: on iicbb4 addr 0x0 > [61] iic8: on iicbus8 > [61] iic9: on iicbus9 > [61] iicbus10: on iicbb5 addr 0x0 > [61] iic10: on iicbus10 > [61] iic11: on iicbus11 > [61] info: [drm] MSI enabled 1 message(s) > [61] info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > [61] info: [drm] Driver supports precise vblank timestamp query. > [61] drmn1: taking over the fictitious range 0xd0000000-0xe0000000 > [61] info: [drm] Connector eDP-1: get mode from tunables: > [61] info: [drm] - kern.vt.fb.modes.eDP-1 > [61] info: [drm] - kern.vt.fb.default_mode > [61] info: [drm] Connector VGA-1: get mode from tunables: > [61] info: [drm] - kern.vt.fb.modes.VGA-1 > [61] info: [drm] - kern.vt.fb.default_mode > [61] info: [drm] Connector HDMI-A-1: get mode from tunables: > [61] info: [drm] - kern.vt.fb.modes.HDMI-A-1 > [61] info: [drm] - kern.vt.fb.default_mode > [61] info: [drm] Connector DP-1: get mode from tunables: > [61] info: [drm] - kern.vt.fb.modes.DP-1 > [61] info: [drm] - kern.vt.fb.default_mode > [61] info: [drm] Connector HDMI-A-2: get mode from tunables: > [61] info: [drm] - kern.vt.fb.modes.HDMI-A-2 > [61] info: [drm] - kern.vt.fb.default_mode > [61] info: [drm] Connector DP-2: get mode from tunables: > [61] info: [drm] - kern.vt.fb.modes.DP-2 > [61] info: [drm] - kern.vt.fb.default_mode > [61] info: [drm] Connector HDMI-A-3: get mode from tunables: > [61] info: [drm] - kern.vt.fb.modes.HDMI-A-3 > [61] info: [drm] - kern.vt.fb.default_mode > [61] info: [drm] Connector DP-3: get mode from tunables: > [61] info: [drm] - kern.vt.fb.modes.DP-3 > [61] info: [drm] - kern.vt.fb.default_mode > [61] fbd1 on drmn1 > [61] VT: Replacing driver "vga" with new "fb". > [61] info: [drm] Initialized i915 1.6.0 20080730 for drmn1 on minor 1 > [62] info: [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off > [201] em0: link state changed to UP > [301] [HBSD INTERNAL] the process has non-default settings > [301] -> fname: /usr/local/bin/firefox > [301] -> pid: 96371 ppid: 25304 p_pax: > 0x56a > [305] lock order reversal: > [305] 1st 0xfffffe01ea4c6f40 bufwait (bufwait) @ > /jenkins/workspace/HardenedBSD-CURRENT-i915kms-amd64/sys/kern/vfs_bio.c:3488 > [305] 2nd 0xfffff80006806200 dirhash (dirhash) @ > /jenkins/workspace/HardenedBSD-CURRENT-i915kms-amd64/sys/ufs/ufs/ufs_dirhash.c:281 > [305] stack backtrace: > [305] #0 0xffffffff80a7f360 at witness_debugger+0x70 > [305] #1 0xffffffff80a7f261 at witness_checkorder+0xe71 > [305] #2 0xffffffff80a2d0e2 at _sx_xlock+0x72 > [305] #3 0xffffffff80cc39c7 at ufsdirhash_remove+0x37 > [305] #4 0xffffffff80cc8747 at ufs_dirremove+0x127 > [305] #5 0xffffffff80cce615 at ufs_remove+0x75 > [305] #6 0xffffffff80fc26a7 at VOP_REMOVE_APV+0xf7 > [305] #7 0xffffffff80add823 at kern_unlinkat+0x213 > [305] #8 0xffffffff80e6effb at amd64_syscall+0x2db > [305] #9 0xffffffff80e4eb8b at Xfast_syscall+0xfb > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Tue Mar 1 18:05:02 2016 Return-Path: Delivered-To: freebsd-current@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 229F6ABF4AE for ; Tue, 1 Mar 2016 18:05:02 +0000 (UTC) (envelope-from mailing-machine@vniz.net) 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 F28811747 for ; Tue, 1 Mar 2016 18:05:01 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mailman.ysv.freebsd.org (Postfix) id F0551ABF4AD; Tue, 1 Mar 2016 18:05:01 +0000 (UTC) Delivered-To: current@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 D6253ABF4AC for ; Tue, 1 Mar 2016 18:05:01 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) (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 83DB11746 for ; Tue, 1 Mar 2016 18:05:01 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f43.google.com with SMTP id v124so25786318lff.0 for ; Tue, 01 Mar 2016 10:05:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=P493u8dJeTKCkBwMnVjiJxKUSqvmI/A89NjmBuK2v3U=; b=MaLaWT0SmpOPPsAmBJq4GayMbnIxwR/rkYb1BniN39Rt7Kr4Js6qBVNGw2xrmGlUke dUHV+8Du4SV4g3SWtQ3X0VzvtuuijIfyNohhhZx/Yt0xmvdH88/cnTpcAtX3/g4tkAu0 0JypXanowQ5dniutcr5INiq1SwNp/Z3EiMs96oY0ZjiKRUTENu/hjTUP7x8lPyK8ANaH OZ2OAuXaEvaLvhY0EfjH6ZSLbCGTQkuVOTjerKCiutawmu8VrcAXf3UIv7wjl5/LZUhs 0xgFAOUvd2HW/zs/VcWyZWG6mxP9Sf8DZI2kf52+WqBx542CpERMZsbdKzXX7nEKszyb i3eQ== X-Gm-Message-State: AD7BkJJ8Lcz0ER+ytKlM2H21hyQAB+InnhauWmF/DBYU2vCY/Lus/7yoAo19lL0e8hHamQ== X-Received: by 10.25.30.73 with SMTP id e70mr7756634lfe.13.1456851716920; Tue, 01 Mar 2016 09:01:56 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id h8sm5001991lbd.48.2016.03.01.09.01.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Mar 2016 09:01:55 -0800 (PST) Subject: Re: Dropping some locales/encodings? To: Baptiste Daroussin , Daniel Kalchev References: <20160229232334.GG84995@ivaldir.etoilebsd.net> <56D502BD.9020704@freebsd.org> <20160301034544.GH52633@dendrobates.araler.com> <20160301095450.GD31877@ivaldir.etoilebsd.net> Cc: Sergey Manucharian , current@freebsd.org, hackers@freebsd.org From: Andrey Chernov Message-ID: <56D5CAFF.8020107@freebsd.org> Date: Tue, 1 Mar 2016 20:01:51 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160301095450.GD31877@ivaldir.etoilebsd.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="c1GMjnfjOtU02RJ5KCrtCxvEBhKfMhJIU" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 18:05:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --c1GMjnfjOtU02RJ5KCrtCxvEBhKfMhJIU From: Andrey Chernov To: Baptiste Daroussin , Daniel Kalchev Cc: Sergey Manucharian , current@freebsd.org, hackers@freebsd.org Message-ID: <56D5CAFF.8020107@freebsd.org> Subject: Re: Dropping some locales/encodings? References: <20160229232334.GG84995@ivaldir.etoilebsd.net> <56D502BD.9020704@freebsd.org> <20160301034544.GH52633@dendrobates.araler.com> <20160301095450.GD31877@ivaldir.etoilebsd.net> In-Reply-To: <20160301095450.GD31877@ivaldir.etoilebsd.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01.03.2016 12:54, Baptiste Daroussin wrote: >> What benefit does it bring to remove an already existing locale? >=20 > The benefit is the fact we have no source for those and collation for o= ne are > wrong for those. (We have added proper collation support in head). Unicode mapping for CP1251 (0x98 is undefined) http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1251.TXT Collation is the same as in CLDR --=20 http://ache.vniz.net/ --c1GMjnfjOtU02RJ5KCrtCxvEBhKfMhJIU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJW1csAAAoJEKUckv0MjfbKoacIAKbJg6L3dc4+pQZQAJHXngay rKul89GtGmcQpoYWRB85cU5p5AWEHFahCcbDrMiJPg7hjPv7NMFTqDCf8INJLAeD kU9eworZBNAngtJm/J/t31Jp6W06atROx+QjZtFHpzXcIrlGMwsa893+wVKsmKuw bg7wkI0gxzxRaarqUyfZY6/axJtWiNcTeo5p9GhxIWdAYPzw8a4k29TDkOrdb2ub JmL4VRBq5bgBlHLHtzuqV3/56lRkBTti4tXFoDNTI+aXyTP8YqyDqYJ22WdkR/jI /9uQ9c7qGzuUgGj/lNyE7VI4Zwsu6Kxe0NXqa+172QbU7iR9nkWSHoaPrvbJjEU= =D9oG -----END PGP SIGNATURE----- --c1GMjnfjOtU02RJ5KCrtCxvEBhKfMhJIU-- From owner-freebsd-current@freebsd.org Tue Mar 1 18:23:11 2016 Return-Path: Delivered-To: freebsd-current@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 3E03EABFD6E for ; Tue, 1 Mar 2016 18:23:11 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-16.arcor-online.net (mail-in-16.arcor-online.net [151.189.21.56]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF4AA1462 for ; Tue, 1 Mar 2016 18:23:10 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-05-z2.arcor-online.net (mail-in-05-z2.arcor-online.net [151.189.8.17]) by mx.arcor.de (Postfix) with ESMTP id 3qF6Jq3Mx4z6WQ7 for ; Tue, 1 Mar 2016 19:23:07 +0100 (CET) Received: from mail-in-07.arcor-online.net (mail-in-07.arcor-online.net [151.189.21.47]) by mail-in-05-z2.arcor-online.net (Postfix) with ESMTP id 225726F28B9 for ; Tue, 1 Mar 2016 19:23:07 +0100 (CET) Received: from webmail17.arcor-online.net (webmail17.arcor-online.net [151.189.8.75]) by mail-in-07.arcor-online.net (Postfix) with ESMTP id 3qF6Jq0qkHzBqYF for ; Tue, 1 Mar 2016 19:23:07 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-07.arcor-online.net 3qF6Jq0qkHzBqYF DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arcor.de; s=mail-in; t=1456856587; bh=NsQXHgfacnFATBB7pPn6yj/TAAqtzWRdVWhiODDzpSk=; h=Date:From:To:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type:Content-Transfer-Encoding; b=lCEa9EAc6pBy/AGigNZyZcN5f/uxo+AjgvuIA1nOF41EDzJ0PyALpvth/TENmAS4C /R0yPO7mSNUH2CV+81z8QeF4/F/fAIfFsqfoj/b88CBIqjN4jx16UZ42wOSkvyQrel 52o8VgVFaOrmPW/+AgTIEpxF/fBk020ye7gOEuCU= Received: from [84.179.18.47] by webmail17.arcor-online.net (151.189.8.75) with HTTP (Arcor Webmail); Tue, 1 Mar 2016 19:23:06 +0100 (CET) Date: Tue, 1 Mar 2016 19:23:07 +0100 (CET) From: Carsten Kunze To: freebsd-current@freebsd.org Message-ID: <1134012018.181281.1456856587109.JavaMail.ngmail@webmail17.arcor-online.net> In-Reply-To: References: <1493379294.130887.1456847269287.JavaMail.ngmail@webmail21.arcor-online.net> Subject: Aw: Re: WLAN hardware not recognized MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ngMessageSubType: MessageSubType_MAIL X-WebmailclientIP: 84.179.18.47 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 18:23:11 -0000 Joe Nosay wrote: > Is the card removable? If so, have you tried plugging in one that would > have the driver already included with the base - so to speak - system? Have > you tried the card in another computer/laptop? It is an integrated card. Theoretical it is removeable, but this is by design intented only for repairing reasons. I have never tried another card in this laptop. --Carsten From owner-freebsd-current@freebsd.org Tue Mar 1 18:28:34 2016 Return-Path: Delivered-To: freebsd-current@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 CA90FABFECE; Tue, 1 Mar 2016 18:28:34 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A389F174D; Tue, 1 Mar 2016 18:28:34 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date: Content-Transfer-Encoding:Content-Type:MIME-Version; bh=+MwxYVudSA4aRdWEQA4XBkmMSEaB2YDn/PqtXMJ3fjk=; b=ZVivVFzCS8OO2xe2bXDST5OLQx HSudFQpYf9qnX6kI+/C6PU9QqAqpxo/LUDpE4fcLXbTz4XYV8ipY12YXLG9WIkIIbOWyFliIQcN/b 5xuYsBJDLdTFPqy7HQGsGTUaAdJCHStSf44KhXKhxBxd2hh+fOoX/lsjRLaKqcMT0x0M=; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]:53099 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aap25-000C4v-RN; Tue, 01 Mar 2016 12:28:30 -0600 Received: from proxy.lucent.com ([135.245.49.13]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Tue, 01 Mar 2016 12:28:29 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 01 Mar 2016 12:28:29 -0600 From: Larry Rosenman To: Carsten Kunze Cc: freebsd-current@freebsd.org, owner-freebsd-current@freebsd.org Subject: Re: Aw: Re: WLAN hardware not recognized In-Reply-To: <1134012018.181281.1456856587109.JavaMail.ngmail@webmail17.arcor-online.net> References: <1493379294.130887.1456847269287.JavaMail.ngmail@webmail21.arcor-online.net> <1134012018.181281.1456856587109.JavaMail.ngmail@webmail17.arcor-online.net> Message-ID: <913b75500917c016362a7633e1def254@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.1.4 X-Spam-Score: -1.0 (-) X-LERCTR-Spam-Score: -1.0 (-) X-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 X-LERCTR-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 18:28:34 -0000 On 2016-03-01 12:23, Carsten Kunze wrote: > Joe Nosay wrote: > >> Is the card removable? If so, have you tried plugging in one that >> would >> have the driver already included with the base - so to speak - system? >> Have >> you tried the card in another computer/laptop? > > It is an integrated card. Theoretical it is removeable, but this is > by design intented only for repairing reasons. I have never tried > another card in this laptop. > > --Carsten > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" Did you load the iwn firmware? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 From owner-freebsd-current@freebsd.org Tue Mar 1 19:49:50 2016 Return-Path: Delivered-To: freebsd-current@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 BAF4EABFC9D for ; Tue, 1 Mar 2016 19:49:50 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 814C21481 for ; Tue, 1 Mar 2016 19:49:50 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [89.204.138.241] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1aaqId-0007T1-7l for freebsd-current@freebsd.org; Tue, 01 Mar 2016 20:49:40 +0100 Received: from localhost.my.domain (c720-r292778-amd64 [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id u21JnZsI002158 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 1 Mar 2016 20:49:35 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id u21JnW19002157 for freebsd-current@freebsd.org; Tue, 1 Mar 2016 20:49:32 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Tue, 1 Mar 2016 20:49:32 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: Re: continuous stream of writes? Message-ID: <20160301194932.GA2138@c720-r292778-amd64> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-current@freebsd.org References: <56D5A59E.8040608@protected-networks.net> <56D5AA10.5090703@FreeBSD.org> <56D5AB11.7090307@protected-networks.net> <56D5AC1D.4010803@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56D5AC1D.4010803@FreeBSD.org> X-Operating-System: FreeBSD 11.0-CURRENT r292778 (amd64) User-Agent: Mutt/1.5.24 (2015-08-30) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.138.241 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 19:49:50 -0000 El día Tuesday, March 01, 2016 a las 08:50:05AM -0600, Eric van Gyzen escribió: > >> The I/O mode of "top" might be useful: > >> > >> top -m io > > > > Well that's different .. KDE konsole .. why on earth .. ? > > Now try ktrace, fstat, and procstat. See the man pages for usage. Or as well truss to see on syscall level what the proc is doing/writing; matthias -- Matthias Apitz, ✉ guru@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 From owner-freebsd-current@freebsd.org Tue Mar 1 20:48:18 2016 Return-Path: Delivered-To: freebsd-current@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 A96F0ABE9BB for ; Tue, 1 Mar 2016 20:48:18 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-14.arcor-online.net (mail-in-14.arcor-online.net [151.189.21.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6698314CD for ; Tue, 1 Mar 2016 20:48:17 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-15-z2.arcor-online.net (mail-in-15-z2.arcor-online.net [151.189.8.32]) by mx.arcor.de (Postfix) with ESMTP id 3qF9X91tJfz90bX for ; Tue, 1 Mar 2016 21:48:09 +0100 (CET) Received: from mail-in-16.arcor-online.net (mail-in-16.arcor-online.net [151.189.21.56]) by mail-in-15-z2.arcor-online.net (Postfix) with ESMTP id 3AF15112954 for ; Tue, 1 Mar 2016 21:48:09 +0100 (CET) Received: from webmail17.arcor-online.net (webmail17.arcor-online.net [151.189.8.75]) by mail-in-16.arcor-online.net (Postfix) with ESMTP id 3qF9X91ZkhzCQT5 for ; Tue, 1 Mar 2016 21:48:09 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-16.arcor-online.net 3qF9X91ZkhzCQT5 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arcor.de; s=mail-in; t=1456865289; bh=mL29RZnaTb0z7xvEnp+EVBEsxT2hb7ZGzZsgWCOv2O4=; h=Date:From:To:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type:Content-Transfer-Encoding; b=hyYN8BM1/h4FPSA6e/vbTWfMxe8SRYypPswrULSJxFeyPWSpbGGwjH+wraSgWKiVc 2zm+kQf1kn13AI4vcoIQa/Xyqdi3Uvq442QczqOub4V9YGgqlbQe/zMyLM9QpGnSF6 PwwsFVHa4HYEpBnAN/8+uCGixmzNpnX7u7Y3zaxk= Received: from [84.179.18.47] by webmail17.arcor-online.net (151.189.8.75) with HTTP (Arcor Webmail); Tue, 1 Mar 2016 21:48:09 +0100 (CET) Date: Tue, 1 Mar 2016 21:48:09 +0100 (CET) From: Carsten Kunze To: freebsd-current@freebsd.org Message-ID: <1355875693.183451.1456865289211.JavaMail.ngmail@webmail17.arcor-online.net> In-Reply-To: <913b75500917c016362a7633e1def254@thebighonker.lerctr.org> References: <913b75500917c016362a7633e1def254@thebighonker.lerctr.org> <1493379294.130887.1456847269287.JavaMail.ngmail@webmail21.arcor-online.net> <1134012018.181281.1456856587109.JavaMail.ngmail@webmail17.arcor-online.net> Subject: Re: WLAN hardware not recognized MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ngMessageSubType: MessageSubType_MAIL X-WebmailclientIP: 84.179.18.47 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 20:48:18 -0000 Larry Rosenman wrote: > Did you load the iwn firmware? How do I do this? I put "if_iwn_load="YES"" into /boot/loader.conf, now I get "module iwn already present!" in dmesg... From owner-freebsd-current@freebsd.org Tue Mar 1 20:51:52 2016 Return-Path: Delivered-To: freebsd-current@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 CC758ABECB4; Tue, 1 Mar 2016 20:51:52 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ABF111A7D; Tue, 1 Mar 2016 20:51:52 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date: Content-Transfer-Encoding:Content-Type:MIME-Version; bh=iufF5Lloy/PRn3GN8+SE7xVfGz86bViMpjqrIhy64Tc=; b=nlGr/8YcRZVdU7i7u7o68ORc2l pOgNR1rPK8MBsTr/QviWt8WgliDzGwih2IYO2nD5Sco2db/yvb+5PU98VRNCvwRFky23yFDHYFt9a rnIpLqGtxZZcrKxHGGIQYuWziUEv92O0J/FUf5kmYtD9V2V28G1JpJ/0pCzFYAzGTvwQ=; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]:49266 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aarGo-000GHd-Sw; Tue, 01 Mar 2016 14:51:51 -0600 Received: from proxy.lucent.com ([135.245.49.13]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Tue, 01 Mar 2016 14:51:50 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 01 Mar 2016 14:51:50 -0600 From: Larry Rosenman To: Carsten Kunze Cc: freebsd-current@freebsd.org, owner-freebsd-current@freebsd.org Subject: Re: WLAN hardware not recognized In-Reply-To: <1355875693.183451.1456865289211.JavaMail.ngmail@webmail17.arcor-online.net> References: <913b75500917c016362a7633e1def254@thebighonker.lerctr.org> <1493379294.130887.1456847269287.JavaMail.ngmail@webmail21.arcor-online.net> <1134012018.181281.1456856587109.JavaMail.ngmail@webmail17.arcor-online.net> <1355875693.183451.1456865289211.JavaMail.ngmail@webmail17.arcor-online.net> Message-ID: X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.1.4 X-Spam-Score: -1.0 (-) X-LERCTR-Spam-Score: -1.0 (-) X-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 X-LERCTR-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 20:51:52 -0000 On 2016-03-01 14:48, Carsten Kunze wrote: > Larry Rosenman wrote: > >> Did you load the iwn firmware? > > How do I do this? > > I put "if_iwn_load="YES"" into /boot/loader.conf, now I get > "module iwn already present!" in dmesg... > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" iwn1000fw_load="YES" iwn100fw_load="YES" iwn105fw_load="YES" iwn135fw_load="YES" iwn2000fw_load="YES" iwn2030fw_load="YES" iwn4965fw_load="YES" iwn5000fw_load="YES" iwn5150fw_load="YES" iwn6000fw_load="YES" iwn6000g2afw_load="YES" iwn6000g2bfw_load="YES" iwn6050fw_load="YES" See man iwn for more details -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 From owner-freebsd-current@freebsd.org Tue Mar 1 20:56:15 2016 Return-Path: Delivered-To: freebsd-current@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 48FF7ABF005 for ; Tue, 1 Mar 2016 20:56:15 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com [209.85.160.174]) (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 1241C1D0C for ; Tue, 1 Mar 2016 20:56:14 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-yk0-f174.google.com with SMTP id 1so8784509ykg.3 for ; Tue, 01 Mar 2016 12:56:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc; bh=neWLATDR5cHSR/EzfGIxJOpPI0J+pE6gMx8jMtOw7FY=; b=elrLn4NAFWyRY1Z0KLJC3Oz9uvgOblDgVH5dr5fNzgyFuNnhuLViM4Je9S0mLoClsM OAIi+x66/6XqxawocgT0qeo/P8LCqWifVcurKajgrMYMItBwRbPlyx5XfhHluPGkg+Fk ohu4+mhaq4iKYvoz7RF6Q0ZAZORhtVJCDLow2/q8Q2j5GRAM2v9VkSpG8pohR3zBEPhQ wy6uVsYJrA/6br9nS4BD2shGKh0G/g2knyRNs91EgJGtDlH8Uv7JAoj9VXPy1OpgOmPq ko6puW9d4YQ4jzwYR+rq2hJrlCNAFIfYcTZOGFZLlZmPI2nG2K7wonmYfE7EnPvj22SW cf5A== X-Gm-Message-State: AD7BkJIuEB5SB2+tpZ+06WTreQQ9001whGty52KTtm83Ia0RcE6A2v2/FRn/P0f43zW7Eg== X-Received: by 10.37.231.70 with SMTP id e67mr13635181ybh.57.1456865444574; Tue, 01 Mar 2016 12:50:44 -0800 (PST) Received: from mail-yw0-f176.google.com (mail-yw0-f176.google.com. [209.85.161.176]) by smtp.gmail.com with ESMTPSA id f126sm26021030ywc.22.2016.03.01.12.50.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Mar 2016 12:50:44 -0800 (PST) Received: by mail-yw0-f176.google.com with SMTP id u200so159739411ywf.0 for ; Tue, 01 Mar 2016 12:50:44 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.129.31.67 with SMTP id f64mr12735201ywf.94.1456865443989; Tue, 01 Mar 2016 12:50:43 -0800 (PST) Reply-To: cem@FreeBSD.org Received: by 10.37.115.134 with HTTP; Tue, 1 Mar 2016 12:50:43 -0800 (PST) In-Reply-To: <1355875693.183451.1456865289211.JavaMail.ngmail@webmail17.arcor-online.net> References: <1493379294.130887.1456847269287.JavaMail.ngmail@webmail21.arcor-online.net> <1134012018.181281.1456856587109.JavaMail.ngmail@webmail17.arcor-online.net> <913b75500917c016362a7633e1def254@thebighonker.lerctr.org> <1355875693.183451.1456865289211.JavaMail.ngmail@webmail17.arcor-online.net> Date: Tue, 1 Mar 2016 12:50:43 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: WLAN hardware not recognized From: Conrad Meyer To: Carsten Kunze Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 20:56:15 -0000 kldload iwn6000fw, iwn6000g2afw, iwn6000g2bfw. On Tue, Mar 1, 2016 at 12:48 PM, Carsten Kunze wrote: > Larry Rosenman wrote: > >> Did you load the iwn firmware? > > How do I do this? > > I put "if_iwn_load="YES"" into /boot/loader.conf, now I get > "module iwn already present!" in dmesg... > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Tue Mar 1 21:20:18 2016 Return-Path: Delivered-To: freebsd-current@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 DD9D9ABFB2C for ; Tue, 1 Mar 2016 21:20:18 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 A1CDB1B20 for ; Tue, 1 Mar 2016 21:20:18 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1aariD-003XzP-Ub>; Tue, 01 Mar 2016 22:20:09 +0100 Received: from f052150237.adsl.alicedsl.de ([78.52.150.237] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1aariD-001A2H-LJ>; Tue, 01 Mar 2016 22:20:09 +0100 Date: Tue, 1 Mar 2016 22:20:04 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: mounting CIFS share (tcp/455) with FreeBSD and mount_smbfs(8) Message-ID: <20160301222004.4cdaafc9.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/9Q4.F_qXCr/Feim3t3BN3Nk"; protocol="application/pgp-signature" X-Originating-IP: 78.52.150.237 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 21:20:19 -0000 --Sig_/9Q4.F_qXCr/Feim3t3BN3Nk Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I need to mount a CIFS share from windows server 2012 r2 via CIFS, tcp/445 = as NetBIOS service (tcp/139) has been deprecated due to serious vulnerability issues.= =20 Until the disabling of NetBIOS and tcp/139 we used successfully autofs and = mount_smbfs. this is no longer working. I tried to force autofs/mount_smbfs to bind to p= ort 445 on the server via ://@xxx.xxx.xxx.xxx:445/sharename, but this doesn't work. Trying to mount a share from a samba 4.3 server (FreeBSD CURRENT, net/samba= 43, both most recent sources), where I configured samba_server via smb ports =3D 445 to u= se port tcp 445 only and only SMB2 and SMB3 (server min protocol =3D SMB2) protocols via th= e following command: mount_smbfs -I xxx.xxx.xxx.xxx -U a_user -W \ WORKGROUP //a_user@xxx.xxx.xxx.xxx:445/sharename /mnt results in the error mount_smbfs: unable to open connection: syserr =3D RPC struct is bad Setting "smb ports =3D 139,445" and "server min protocol =3D NT1" seems to = work, the share can be bound, but this is SMB over tcp/139 and not CIFS. I desperately need CIFS and I need tcp/445 since tcp/139 is from now on fir= ewalled.=20 So: what do I miss here? Kind regards and thank you in advance, O. Hartmann --Sig_/9Q4.F_qXCr/Feim3t3BN3Nk Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW1geEAAoJEOgBcD7A/5N88mYIAKRoy5uN5GomTfAv/fVQKPBa 16YoGgaLvf7HNvzRxGlnRwOqvXuIWne2czkhwPmg3LxHgTLu4pUsECr+MCTxUJXy UH0nmoaQkOqGI0D11Bn67Ot9pztqgL3lT8XyzXDb2BshZhj9J3S7MaX8K2nH20qA 6IXRU7UcZ7DpcbhV0brGHswBg/0TY8ABCjkUn//y25RiEl5N2qxLapB5+B8WwxFP US6bZ2XVm7+P9e09c1/j9K6SaVF6aexvfNA7w1zuWSuIqU5pZeHZgg9IgpQATib8 2Z/L7EymCb/6a3CXAqU/wHQH1BMCvpKw1nLupfjL09n4XBJcSRamZW44V5u4BzQ= =NpeP -----END PGP SIGNATURE----- --Sig_/9Q4.F_qXCr/Feim3t3BN3Nk-- From owner-freebsd-current@freebsd.org Tue Mar 1 21:32:57 2016 Return-Path: Delivered-To: freebsd-current@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 6D848AC00A9 for ; Tue, 1 Mar 2016 21:32:57 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-07.arcor-online.net (mail-in-07.arcor-online.net [151.189.21.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2602F130F for ; Tue, 1 Mar 2016 21:32:56 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-19-z2.arcor-online.net (mail-in-19-z2.arcor-online.net [151.189.8.36]) by mx.arcor.de (Postfix) with ESMTP id 3qF9q62DHqzBqDZ for ; Tue, 1 Mar 2016 22:01:06 +0100 (CET) Received: from mail-in-14.arcor-online.net (mail-in-14.arcor-online.net [151.189.21.54]) by mail-in-19-z2.arcor-online.net (Postfix) with ESMTP id 4934F35BDB2 for ; Tue, 1 Mar 2016 22:01:06 +0100 (CET) Received: from webmail17.arcor-online.net (webmail17.arcor-online.net [151.189.8.75]) by mail-in-14.arcor-online.net (Postfix) with ESMTP id 3qF9q61zp0z8ywq for ; Tue, 1 Mar 2016 22:01:06 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-14.arcor-online.net 3qF9q61zp0z8ywq DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arcor.de; s=mail-in; t=1456866066; bh=D07e1IArs5BVlOctfZwrpSYIlouchiKhMptXtvTw1Gk=; h=Date:From:To:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type:Content-Transfer-Encoding; b=DSlYdcqPHqK0QLpo0Hp8AQrxvuHUbJzVdsUXBVby5uIdoP3AdpkJ7wM1eW2bz+Iyr QAkLbjqtwbbU8bWFiwjWeclaaPVoS5+IFhN4xaYYBcIHfM+PuZ+/d4bkwcY+D81WJo beW+v23UI3slS1lZtBYw/8De/R78Dq5vnWYHy4MA= Received: from [84.179.18.47] by webmail17.arcor-online.net (151.189.8.75) with HTTP (Arcor Webmail); Tue, 1 Mar 2016 22:01:06 +0100 (CET) Date: Tue, 1 Mar 2016 22:01:06 +0100 (CET) From: Carsten Kunze To: freebsd-current@freebsd.org Message-ID: <1495441441.183610.1456866066268.JavaMail.ngmail@webmail17.arcor-online.net> In-Reply-To: References: <1493379294.130887.1456847269287.JavaMail.ngmail@webmail21.arcor-online.net> <1134012018.181281.1456856587109.JavaMail.ngmail@webmail17.arcor-online.net> <913b75500917c016362a7633e1def254@thebighonker.lerctr.org> <1355875693.183451.1456865289211.JavaMail.ngmail@webmail17.arcor-online.net> Subject: Re: WLAN hardware not recognized MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ngMessageSubType: MessageSubType_MAIL X-WebmailclientIP: 84.179.18.47 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 21:32:57 -0000 Conrad Meyer wrote: > kldload iwn6000fw, iwn6000g2afw, iwn6000g2bfw. This or edit loader.conf doesn't help, all these things had already been in the kernel. dmesg stays the same. From owner-freebsd-current@freebsd.org Tue Mar 1 21:39:34 2016 Return-Path: Delivered-To: freebsd-current@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 8EF4CAC02A5 for ; Tue, 1 Mar 2016 21:39:34 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from cerebro.liukuma.net (cerebro.liukuma.net [IPv6:2a00:d1e0:1000:1b00::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2A572185C for ; Tue, 1 Mar 2016 21:39:34 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from cerebro.liukuma.net (localhost [127.0.0.1]) by cerebro.liukuma.net (Postfix) with ESMTP id E7A418B172B for ; Tue, 1 Mar 2016 23:39:25 +0200 (EET) DKIM-Filter: OpenDKIM Filter v2.10.3 cerebro.liukuma.net E7A418B172B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=liukuma.net; s=liukudkim; t=1456868365; bh=y+Od77E0ICH257IC0Hj1GT9iBof4TXg7P/mUlJBtKOY=; h=From:To:References:In-Reply-To:Subject:Date; b=Gr/5XYMia+O4Bnr7QA8XJbifJLcyWwK07pEiCXlQ/tNf1JiXpfwX+NuixFdQmXXJD 7T8Gf8gjkAmZAL5XixWTjfvzCHvLoY8KN06IzBG7byvN7ADAbpsPIA9q0QIA3BngAB ZRY3kjAc76V6KGiVYo1tVkroFUy2fla3qs8VpVLQ= X-Virus-Scanned: amavisd-new at liukuma.net Received: from cerebro.liukuma.net ([127.0.0.1]) by cerebro.liukuma.net (cerebro.liukuma.net [127.0.0.1]) (amavisd-new, port 10027) with LMTP id nkATyl3ItlsE for ; Tue, 1 Mar 2016 23:39:24 +0200 (EET) Received: from Rivendell (dsl-kmibrasgw1-50dfdd-193.dhcp.inet.fi [80.223.221.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: ignatz@cerebro.liukuma.net) by cerebro.liukuma.net (Postfix) with ESMTPSA id BF4E18B171C for ; Tue, 1 Mar 2016 23:39:23 +0200 (EET) DKIM-Filter: OpenDKIM Filter v2.10.3 cerebro.liukuma.net BF4E18B171C Message-ID: <32E522F2674A4DEBBE2492D3A307A0C1@Rivendell> From: "Reko Turja" To: "FreeBSD CURRENT" References: <20160301222004.4cdaafc9.ohartman@zedat.fu-berlin.de> In-Reply-To: <20160301222004.4cdaafc9.ohartman@zedat.fu-berlin.de> Subject: Re: mounting CIFS share (tcp/455) with FreeBSD and mount_smbfs(8) Date: Tue, 1 Mar 2016 23:39:22 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3564.1216 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3564.1216 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 21:39:34 -0000 -----Original Message-----=20 From: O. Hartmann=20 Subject: mounting CIFS share (tcp/455) with FreeBSD and mount_smbfs(8)=20 > > I need to mount a CIFS share from windows server 2012 r2 via CIFS, = tcp/445 as NetBIOS > service (tcp/139) has been deprecated due to serious vulnerability = issues.=20 > . > . > . > I desperately need CIFS and I need tcp/445 since tcp/139 is from now = on firewalled.=20 There's actually alternative available that's far more UNIX-friendly and = not depending on the SAMBA foibles. https://technet.microsoft.com/en-us/library/jj574143.aspx?f=3D255&MSPPErr= or=3D-2147217396 Of course, you need to have admin access to the server or get the admins = enable NFS on it. -Reko (I've used the Windows NFS the other way around- FreeBSD NFS shares = mounted with on Win7.) From owner-freebsd-current@freebsd.org Tue Mar 1 21:42:53 2016 Return-Path: Delivered-To: freebsd-current@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 C0E36AC04AD for ; Tue, 1 Mar 2016 21:42:53 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.161.179]) (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 88E531C1F for ; Tue, 1 Mar 2016 21:42:53 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-yw0-f179.google.com with SMTP id h129so160855458ywb.1 for ; Tue, 01 Mar 2016 13:42:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc; bh=7kLlDbcfoSKkEPBYPGN91s8bh1T+kJLLDywl3VIyXg0=; b=mj9f0mc8iYorvt4PEOTfqajD7huDTcs6YcDz3gVwQWVLovX/VX3QeAJA/g2+/S009t Pcc+zY3EnTxvmBOEQyEVG+/C/S8r6zrXLBGt0H4urr9dhOlebNsahWh9Nsv88qGq908H DewhJOIGeiXDztwz3QbdkpSAW6vPZ2du+WXtCrnMOHlEAeS24C5iY3zRLgXV6jLn0UaQ hQHOPPd3crPDXDR32+luhLAOJmRpJjkRJ7VlLmidJSp5oQCqKZ41NA0zSl87ezocDByq C0DZI5vgbYSaUqzI2RAcDacoIuX0TWmzCBhYD0jb1Dd77o7xytQmd1KqMGkbiTzTWstm yp7w== X-Gm-Message-State: AD7BkJLkY8/Isy2RGHpUQoNXS069FBu4H254sbndUVTb3jUa70bhjZ9Ru3tLgfxOP19/Wg== X-Received: by 10.129.91.6 with SMTP id p6mr12539687ywb.325.1456868572224; Tue, 01 Mar 2016 13:42:52 -0800 (PST) Received: from mail-yk0-f173.google.com (mail-yk0-f173.google.com. [209.85.160.173]) by smtp.gmail.com with ESMTPSA id c126sm26063124ywa.52.2016.03.01.13.42.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Mar 2016 13:42:52 -0800 (PST) Received: by mail-yk0-f173.google.com with SMTP id 1so9354994ykg.3 for ; Tue, 01 Mar 2016 13:42:51 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.37.59.19 with SMTP id i19mr731992yba.115.1456868571748; Tue, 01 Mar 2016 13:42:51 -0800 (PST) Reply-To: cem@FreeBSD.org Received: by 10.37.115.134 with HTTP; Tue, 1 Mar 2016 13:42:51 -0800 (PST) In-Reply-To: <1495441441.183610.1456866066268.JavaMail.ngmail@webmail17.arcor-online.net> References: <1493379294.130887.1456847269287.JavaMail.ngmail@webmail21.arcor-online.net> <1134012018.181281.1456856587109.JavaMail.ngmail@webmail17.arcor-online.net> <913b75500917c016362a7633e1def254@thebighonker.lerctr.org> <1355875693.183451.1456865289211.JavaMail.ngmail@webmail17.arcor-online.net> <1495441441.183610.1456866066268.JavaMail.ngmail@webmail17.arcor-online.net> Date: Tue, 1 Mar 2016 13:42:51 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: WLAN hardware not recognized From: Conrad Meyer To: Carsten Kunze Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 21:42:53 -0000 "[1] iwn0: mem 0xf7b00000-0xf7b01fff irq 18 at device 0.0 on pci3" is fine; "module iwn already present!" is fine. What makes you say it isn't recognized or doesn't work? On Tue, Mar 1, 2016 at 1:01 PM, Carsten Kunze wrote: > Conrad Meyer wrote: > >> kldload iwn6000fw, iwn6000g2afw, iwn6000g2bfw. > > This or edit loader.conf doesn't help, all these things had already been in the kernel. dmesg stays the same. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Tue Mar 1 22:04:29 2016 Return-Path: Delivered-To: freebsd-current@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 91272AC0E7B for ; Tue, 1 Mar 2016 22:04:29 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 59D561749; Tue, 1 Mar 2016 22:04:29 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x22f.google.com with SMTP id g203so239000128iof.2; Tue, 01 Mar 2016 14:04:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=HV5kpf5ktqn7d72LxWRb/NtwgGILlDI2Czt8z8GvJ7M=; b=mY4LIx1m8vUjMQmc7MJF2cPmwhJ7eXSeOKbGsuJqH78pnJBcaXWzFyzfcPmKvDgBte s871rdHQyEPwHA3Jhj625Y/yV6MjZYxD2wMt2oVIYfGDt+X9aBLdVtK3PTbbHhEN4psh MD1fuAJWzBr0V/J3Hq6zVvVxPgKII341j71WpxNW8uIwGdIBRSspPP5TZIR27OTyfWd0 1Yv2aDPc4+y6fyPEZTjAKlZ3phAyiop9Q6b5s41EVgljpCnCSyGQIcRFAHqBGuVgRjdx sx7QO62l2KA00iX/jLx1nbRtaj8aFvQktXEkx5aM4ZnrgaoHqtYYG8FEBAN9FBi7ZYgC vdug== 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:date :message-id:subject:from:to:cc; bh=HV5kpf5ktqn7d72LxWRb/NtwgGILlDI2Czt8z8GvJ7M=; b=YFcuPbj6BV7JA1roxAt7yoY/l5hZqd3SBoCRFiU66GdoEWSZJ2t41Saxx2EO8fdOP6 tsYZBISemlqblH1tlD23ibJkwuuUD+dGfnWE0uT4wZcSV379f6GozJYIUxhEh3Dd1dKh 32J31JQCk96aln8NCQkA2sebiAYEV+ys9593LtYmH9t9vdDjrVxZ0e4bpfV89/Mc7BHA rGBB4+9fG1B0Vlfft+MDICfCcuXIJ7LXOC3Z4cxi+QKwWzZ/kjiXUIciEUIZbtMRQe89 bbKNUV27elYPlF0b0C2Hk0HAzCPtdWaLdRL+WksNd8FkCQmSLA762nDkGnEZYx12anKh ED8Q== X-Gm-Message-State: AG10YORcMRvElalcjwELbHDBLZ8sOJM8S1hnKW7TYSQvHf0ra/s3yN2TWhDMEeHRItLdInKkQinEr1ngYQ8BTQ== MIME-Version: 1.0 X-Received: by 10.107.11.231 with SMTP id 100mr25780985iol.165.1456869868321; Tue, 01 Mar 2016 14:04:28 -0800 (PST) Received: by 10.36.14.19 with HTTP; Tue, 1 Mar 2016 14:04:28 -0800 (PST) In-Reply-To: References: <1493379294.130887.1456847269287.JavaMail.ngmail@webmail21.arcor-online.net> <1134012018.181281.1456856587109.JavaMail.ngmail@webmail17.arcor-online.net> <913b75500917c016362a7633e1def254@thebighonker.lerctr.org> <1355875693.183451.1456865289211.JavaMail.ngmail@webmail17.arcor-online.net> <1495441441.183610.1456866066268.JavaMail.ngmail@webmail17.arcor-online.net> Date: Tue, 1 Mar 2016 14:04:28 -0800 Message-ID: Subject: Re: WLAN hardware not recognized From: Adrian Chadd To: cem@freebsd.org Cc: Carsten Kunze , freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 22:04:29 -0000 sysctl net.wlan.devices iwn0 no longer shows up in ifconfig -a . -a On 1 March 2016 at 13:42, Conrad Meyer wrote: > "[1] iwn0: mem 0xf7b00000-0xf7b01fff > irq 18 at device 0.0 on pci3" is fine; "module iwn already present!" > is fine. > > What makes you say it isn't recognized or doesn't work? > > On Tue, Mar 1, 2016 at 1:01 PM, Carsten Kunze wrote: >> Conrad Meyer wrote: >> >>> kldload iwn6000fw, iwn6000g2afw, iwn6000g2bfw. >> >> This or edit loader.conf doesn't help, all these things had already been in the kernel. dmesg stays the same. >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Tue Mar 1 22:13:58 2016 Return-Path: Delivered-To: freebsd-current@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 7B31EABF303 for ; Tue, 1 Mar 2016 22:13:58 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-05.arcor-online.net (mail-in-05.arcor-online.net [151.189.21.45]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 36D911F68 for ; Tue, 1 Mar 2016 22:13:57 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-13-z2.arcor-online.net (mail-in-13-z2.arcor-online.net [151.189.8.30]) by mx.arcor.de (Postfix) with ESMTP id 3qFCR11VYFz2xHs for ; Tue, 1 Mar 2016 23:13:49 +0100 (CET) Received: from mail-in-12.arcor-online.net (mail-in-12.arcor-online.net [151.189.21.52]) by mail-in-13-z2.arcor-online.net (Postfix) with ESMTP id 2F68B3C591E for ; Tue, 1 Mar 2016 23:13:49 +0100 (CET) Received: from webmail17.arcor-online.net (webmail17.arcor-online.net [151.189.8.75]) by mail-in-12.arcor-online.net (Postfix) with ESMTP id 3qFCR11F6rz8RhX for ; Tue, 1 Mar 2016 23:13:49 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-12.arcor-online.net 3qFCR11F6rz8RhX DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arcor.de; s=mail-in; t=1456870429; bh=5CYRimeGZcIDIUr34cja2XhgX4xNZHvgGQv4tNMRVAw=; h=Date:From:To:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type:Content-Transfer-Encoding; b=cvrLgRtzFmqxTEXiNjkb11m+HIH92HGO1IuvdC0PIDzxslF0JKV5L9xvkBt18+oMo hNtDAuu1YSmn1CvpooyiDI0OGb0q1dYDT42w5WDTbnvVcsPL5HBQt1XepvbgGIIV9l aNBEOkeEK4ZR5hQrs0QUIRH4POwvbj39OBV++qgE= Received: from [84.179.18.47] by webmail17.arcor-online.net (151.189.8.75) with HTTP (Arcor Webmail); Tue, 1 Mar 2016 23:13:48 +0100 (CET) Date: Tue, 1 Mar 2016 23:13:49 +0100 (CET) From: Carsten Kunze To: freebsd-current@freebsd.org Message-ID: <467796244.184206.1456870429167.JavaMail.ngmail@webmail17.arcor-online.net> In-Reply-To: References: <1493379294.130887.1456847269287.JavaMail.ngmail@webmail21.arcor-online.net> <1134012018.181281.1456856587109.JavaMail.ngmail@webmail17.arcor-online.net> <913b75500917c016362a7633e1def254@thebighonker.lerctr.org> <1355875693.183451.1456865289211.JavaMail.ngmail@webmail17.arcor-online.net> <1495441441.183610.1456866066268.JavaMail.ngmail@webmail17.arcor-online.net> Subject: Aw: Re: WLAN hardware not recognized MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ngMessageSubType: MessageSubType_MAIL X-WebmailclientIP: 84.179.18.47 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 22:13:58 -0000 Adrian Chadd wrote: > sysctl net.wlan.devices > > iwn0 no longer shows up in ifconfig -a . > > > -a Ok, "sysctl -a|grep iwn" gives quite some output. Actually I tried to start wpa_supplicant, but WLAN didn't react. Then--just for testing--I wrote "ifconfig iwn0 up", where ifconfig reported that iwn0 is unknown. From owner-freebsd-current@freebsd.org Tue Mar 1 22:17:28 2016 Return-Path: Delivered-To: freebsd-current@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 CFEA9ABF47C for ; Tue, 1 Mar 2016 22:17:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 98E3810D1 for ; Tue, 1 Mar 2016 22:17:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x234.google.com with SMTP id l127so239321710iof.3 for ; Tue, 01 Mar 2016 14:17:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=sCk4cKjKjg45jh0y+r5WrGQUvYhT+yZ3xlbgAyCQBq4=; b=iqkM3/FQQpCA0jGZlghgLNRCUc2WoFKoVifRUSysWJpAfLRIUJaoPXORAoWcnS20bR SJEhLw8mnLCy7JM+3oGAUK6iNNTlaJ4ahsrC50uuMw+GS5wBcf9Pdbs2xejo3R7InfyV PQFIIxZLx2iRiN6KNqhBdX7R/4Koc+Au9qZOn/7ZAzJZxmfdHzeCJ8WugUy7p+SoiLsF RNZ5BeEadGnW/Yx/Qg3cteY3cliHD4nftmcmySBGKQzRIqVnedc/4Pwf5jUJkhQbpbJw Jg96tU1zSz7NqzfIRIRlqX9Gpwb5BCZYyx8rDDyc4+7jYbStLznDY8dyDWYvr+oVH5gR SOfQ== 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:date :message-id:subject:from:to:cc; bh=sCk4cKjKjg45jh0y+r5WrGQUvYhT+yZ3xlbgAyCQBq4=; b=elO6Rh37awCdvk+C2DhvtcNhSwnNH58ThlOw7Lgj2tnqj6ps42G6feXOQAuZxqJ5QR m3RXDMExJQOpRlV6Iul/nY4VAd+cjjR1LKTASh5bPp8WFW4NrwyCklj42MVze746df9K KnlJJ05+f9dUyrC1HIhPydrBh283ui86mbeLcms6S2jtcKrmnkyRR7vRRGsBttDCt8Oa qHlKz2Zgv9bICAjFC8eAZMeKCHSbdq9aNTUnmf/Sc9eSTsx5fEw6cSeZEROA778HtbVp rx0mlcP1St0rpHYwjd2fsKlHQKTtKhTCa+SpzbrUdEje8JV1I+uy6CpRJbhgO6Plofva N1QQ== X-Gm-Message-State: AG10YOScQTZ3hC1G3wDsUOHJcqR702nFt51+JE24RgNGRZOXuMVJEPob2RMfDF8xuYuVjaaUUQVMO7CMdNXTIA== MIME-Version: 1.0 X-Received: by 10.107.132.142 with SMTP id o14mr26445458ioi.75.1456870648091; Tue, 01 Mar 2016 14:17:28 -0800 (PST) Received: by 10.36.14.19 with HTTP; Tue, 1 Mar 2016 14:17:28 -0800 (PST) In-Reply-To: <467796244.184206.1456870429167.JavaMail.ngmail@webmail17.arcor-online.net> References: <1493379294.130887.1456847269287.JavaMail.ngmail@webmail21.arcor-online.net> <1134012018.181281.1456856587109.JavaMail.ngmail@webmail17.arcor-online.net> <913b75500917c016362a7633e1def254@thebighonker.lerctr.org> <1355875693.183451.1456865289211.JavaMail.ngmail@webmail17.arcor-online.net> <1495441441.183610.1456866066268.JavaMail.ngmail@webmail17.arcor-online.net> <467796244.184206.1456870429167.JavaMail.ngmail@webmail17.arcor-online.net> Date: Tue, 1 Mar 2016 14:17:28 -0800 Message-ID: Subject: Re: Re: WLAN hardware not recognized From: Adrian Chadd To: Carsten Kunze Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 22:17:29 -0000 Right, you need to create the interface: ifconfig wlan0 create wlandev iwn0 then run wpa_spuplicant (or do it all in /etc/rc.conf .. :) -a On 1 March 2016 at 14:13, Carsten Kunze wrote: > Adrian Chadd wrote: > >> sysctl net.wlan.devices >> >> iwn0 no longer shows up in ifconfig -a . >> >> >> -a > > Ok, "sysctl -a|grep iwn" gives quite some output. > > Actually I tried to start wpa_supplicant, but WLAN didn't react. Then--just for testing--I wrote "ifconfig iwn0 up", where ifconfig reported that iwn0 is unknown. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Tue Mar 1 22:23:53 2016 Return-Path: Delivered-To: freebsd-current@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 BEDE0ABF830 for ; Tue, 1 Mar 2016 22:23:53 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-06.arcor-online.net (mail-in-06.arcor-online.net [151.189.21.46]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A2291501 for ; Tue, 1 Mar 2016 22:23:53 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-14-z2.arcor-online.net (mail-in-14-z2.arcor-online.net [151.189.8.31]) by mx.arcor.de (Postfix) with ESMTP id 3qFBv22cGmz7lVl for ; Tue, 1 Mar 2016 22:49:34 +0100 (CET) Received: from mail-in-06.arcor-online.net (mail-in-06.arcor-online.net [151.189.21.46]) by mail-in-14-z2.arcor-online.net (Postfix) with ESMTP id 56B31208AB6 for ; Tue, 1 Mar 2016 22:49:34 +0100 (CET) Received: from webmail17.arcor-online.net (webmail17.arcor-online.net [151.189.8.75]) by mail-in-06.arcor-online.net (Postfix) with ESMTP id 3qFBv22Nrhz7lVl for ; Tue, 1 Mar 2016 22:49:34 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-06.arcor-online.net 3qFBv22Nrhz7lVl DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arcor.de; s=mail-in; t=1456868974; bh=l8ZOgANTCjgyDX3T3RXrnRdh8T4u1U4cGZT05lY6Y54=; h=Date:From:To:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Cn44URm77xBsocvj5s5DRvymX9+htiY1eWNCmXAwNa/+o2jLbD7tZgGkxpThRfGuQ oAQqP0/tgOYZp9D8WY/PdAVU9xR5egjyNXhOBVaTRPjsS9arhXvtCTv6yfPIZqre2s xWKnTnmVC1xSykb29LeFcXY58jXySI3tVF1jpu5k= Received: from [84.179.18.47] by webmail17.arcor-online.net (151.189.8.75) with HTTP (Arcor Webmail); Tue, 1 Mar 2016 22:49:33 +0100 (CET) Date: Tue, 1 Mar 2016 22:49:34 +0100 (CET) From: Carsten Kunze To: freebsd-current@freebsd.org Message-ID: <122138363.184008.1456868974325.JavaMail.ngmail@webmail17.arcor-online.net> In-Reply-To: References: <1493379294.130887.1456847269287.JavaMail.ngmail@webmail21.arcor-online.net> <1134012018.181281.1456856587109.JavaMail.ngmail@webmail17.arcor-online.net> <913b75500917c016362a7633e1def254@thebighonker.lerctr.org> <1355875693.183451.1456865289211.JavaMail.ngmail@webmail17.arcor-online.net> <1495441441.183610.1456866066268.JavaMail.ngmail@webmail17.arcor-online.net> Subject: Re: WLAN hardware not recognized MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ngMessageSubType: MessageSubType_MAIL X-WebmailclientIP: 84.179.18.47 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 22:23:53 -0000 Conrad Meyer wrote: > "[1] iwn0: mem 0xf7b00000-0xf7b01fff > irq 18 at device 0.0 on pci3" is fine; "module iwn already present!" > is fine. > > What makes you say it isn't recognized or doesn't work? ifconfig iwn0 .... says "interface iwn0 does not exist". Also starting wpa_supplicant doesn't work (I use a wpa setup that did work on my previous laptop on FreeBSD 10). At install time I only "configured" ethernet, iwn0 I skipped since I intented to configure that later. But that may not be relevant. From owner-freebsd-current@freebsd.org Tue Mar 1 22:29:43 2016 Return-Path: Delivered-To: freebsd-current@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 4181FABFB1D; Tue, 1 Mar 2016 22:29:43 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1723F1C4F; Tue, 1 Mar 2016 22:29:43 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks CA" (verified OK)) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id 6DE628; Tue, 1 Mar 2016 17:29:39 -0500 (EST) To: freebsd-current Cc: "freebsd-emulation@freebsd.org" From: Michael Butler Subject: SVN r296272 breaks virtualbox Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492 Message-ID: <56D617D1.5040209@protected-networks.net> Date: Tue, 1 Mar 2016 17:29:37 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 22:29:43 -0000 The removal of "taskqueue_enqueue_fast" breaks the virtualbox kmods: Mar 1 16:54:36 toshi kernel: vboxdrv: fAsync=0 offMin=0x914 offMax=0x151c Mar 1 16:54:36 toshi kernel: link_elf_obj: symbol taskqueue_enqueue_fast undefined Mar 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type Mar 1 16:54:36 toshi kernel: link_elf_obj: symbol taskqueue_enqueue_fast undefined Mar 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type Mar 1 16:54:36 toshi kernel: KLD vboxnetadp.ko: depends on vboxnetflt - not available or version mismatch Mar 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type Michael From owner-freebsd-current@freebsd.org Tue Mar 1 22:42:08 2016 Return-Path: Delivered-To: freebsd-current@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 15FFCAC06D8 for ; Tue, 1 Mar 2016 22:42:08 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 A715913D0 for ; Tue, 1 Mar 2016 22:42:07 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by mail-wm0-x22d.google.com with SMTP id p65so56111993wmp.1 for ; Tue, 01 Mar 2016 14:42:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=eHKAHok/fIBMIr+1k3UY/iGvjR5DQEj1CxxRvSSZiDI=; b=HEsFxTViliusFBzX38za4V+w+6oJQUHn3/IQPEJXrOxZqbxcZb9Am8q6m/951kB7Rv ryy8IiscIV9zA5fgwR4/Yz+anwZlUsUVz7cnmBTPccRg9u9LePPYFmYvs3+8fmfyufzd qjLIIrDeGy2LJB0rtJMblYnJTyskjqURNN4+zgsecnUvzpZUKWv1lSlvTJsne5qBFPCy L9TvDZaNo6wYMknA6S5SmkWpUOzDMK907US1tRmWjBe/D7+ShDssLBnzC2R7seh4j7Qp K+zxv2WRtVMZA7Tbpb/3PtZva+JvQt6cta+mNRKoMJqpVOj6MHX0BpyzH5ofxOolkDED J18Q== 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:date :message-id:subject:from:to:cc; bh=eHKAHok/fIBMIr+1k3UY/iGvjR5DQEj1CxxRvSSZiDI=; b=eZZOYAx5jxm4BLJyz2d4Ke308JAZyeSYW4e+G+bJgjr5dMnpaelCMy1lAXpaKlHzVV zEY+r+r3UJ9tT2YapWSWMee2PcsMeL7qHVIya0NL+mDmwb07g6bPVDVfFxWkB161ZTrz GHViwMnC+vjb2A8DcTFIK8Fk9NtG1SgSfoZYqM1JYc7ax5WBzJswuONwDKTgutJqEAgW SjHsblYPZHv96t1XSVkIeCali6rGti0o17tW0J+4UiaX/3KnxgU9U6ioe8lQZZibsEgk 5bwCdLxlxf9al+eiuAvenntFz0lh4NLzCC+nwHUSGbNasOEbFBExOzGBRAX2K7nFDhAI Ej3Q== X-Gm-Message-State: AD7BkJLDfWVK2Q2d/QDmCSkIQXNGIM9zxTqJPyEtFHgiGokqal339zvgW55Ys8Bapae1mQrs/O3PuYCZd6+ExMNN MIME-Version: 1.0 X-Received: by 10.194.77.193 with SMTP id u1mr22735826wjw.73.1456872126248; Tue, 01 Mar 2016 14:42:06 -0800 (PST) Received: by 10.194.243.98 with HTTP; Tue, 1 Mar 2016 14:42:06 -0800 (PST) In-Reply-To: <122138363.184008.1456868974325.JavaMail.ngmail@webmail17.arcor-online.net> References: <1493379294.130887.1456847269287.JavaMail.ngmail@webmail21.arcor-online.net> <1134012018.181281.1456856587109.JavaMail.ngmail@webmail17.arcor-online.net> <913b75500917c016362a7633e1def254@thebighonker.lerctr.org> <1355875693.183451.1456865289211.JavaMail.ngmail@webmail17.arcor-online.net> <1495441441.183610.1456866066268.JavaMail.ngmail@webmail17.arcor-online.net> <122138363.184008.1456868974325.JavaMail.ngmail@webmail17.arcor-online.net> Date: Tue, 1 Mar 2016 23:42:06 +0100 Message-ID: Subject: Re: WLAN hardware not recognized From: Oliver Pinter To: Carsten Kunze Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 22:42:08 -0000 On 3/1/16, Carsten Kunze wrote: > Conrad Meyer wrote: > >> "[1] iwn0: mem 0xf7b00000-0xf7b01fff >> irq 18 at device 0.0 on pci3" is fine; "module iwn already present!" >> is fine. >> >> What makes you say it isn't recognized or doesn't work? > > ifconfig iwn0 .... says "interface iwn0 does not exist". Also starting > wpa_supplicant doesn't work (I use a wpa setup that did work on my previous > laptop on FreeBSD 10). The wireless subsystem changed a lot since 10-STABLE, and there are no more iwn interfaces shown via ifconfig. You could query them as Adrian mentioned. If you successfully upgraded your base system _too_ and not just the kernel, then you should put a similar lines into rc.conf: wlans_iwn0="wlan0" ifconfig_wlan0="WPA DHCP country HU -wme -powersave" And you should put the relevant firmware module's loading request into /boot/loader.conf, this was mentioned in one mail before. > > At install time I only "configured" ethernet, iwn0 I skipped since I > intented to configure that later. But that may not be relevant. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Tue Mar 1 22:42:23 2016 Return-Path: Delivered-To: freebsd-current@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 799FCAC06FE; Tue, 1 Mar 2016 22:42:23 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from frv157.fwdcdn.com (frv157.fwdcdn.com [212.42.77.157]) (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 406F0153D; Tue, 1 Mar 2016 22:42:22 +0000 (UTC) (envelope-from fidaj@ukr.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=G69PXd1qYvhc+W7u/W+IMXGnWTh+Eh4djDt2FVKjW5o=; b=kJAZC72IjCKJoBCNaCJiEuoWnsyD08WavU9oBNKiv4BUzPgO9zT2c/3ltBMvby/XQtbqSELgI1tWQSFMA+XPtWuGJfEaibnsE6LZSxhbKCcye30mds+JGa9psU8hoZVnXI72hq4TR7pLW9V8iH4bHxIAKcgnJcnkgSAFRmMTkmQ=; Received: from [37.229.193.176] (helo=nonamehost.local) by frv157.fwdcdn.com with esmtpsa ID 1aaszW-000NhP-Hh ; Wed, 02 Mar 2016 00:42:06 +0200 Date: Wed, 2 Mar 2016 00:42:05 +0200 From: Ivan Klymenko To: Michael Butler Cc: freebsd-current , "freebsd-emulation@freebsd.org" Subject: Re: SVN r296272 breaks virtualbox Message-ID: <20160302004206.5bc6e0b3@nonamehost.local> In-Reply-To: <56D617D1.5040209@protected-networks.net> References: <56D617D1.5040209@protected-networks.net> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Result: IP=37.229.193.176; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 22:42:23 -0000 On Tue, 1 Mar 2016 17:29:37 -0500 Michael Butler wrote: > The removal of "taskqueue_enqueue_fast" breaks the virtualbox kmods: > > Mar 1 16:54:36 toshi kernel: vboxdrv: fAsync=0 offMin=0x914 > offMax=0x151c Mar 1 16:54:36 toshi kernel: link_elf_obj: symbol > taskqueue_enqueue_fast undefined > Mar 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type > Mar 1 16:54:36 toshi kernel: link_elf_obj: symbol > taskqueue_enqueue_fast undefined > Mar 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type > Mar 1 16:54:36 toshi kernel: KLD vboxnetadp.ko: depends on > vboxnetflt - not available or version mismatch > Mar 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type > > Michael > +1 From owner-freebsd-current@freebsd.org Tue Mar 1 22:48:02 2016 Return-Path: Delivered-To: freebsd-current@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 87D29AC08C7 for ; Tue, 1 Mar 2016 22:48:02 +0000 (UTC) (envelope-from ken@kdm.org) 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 72B691970 for ; Tue, 1 Mar 2016 22:48:02 +0000 (UTC) (envelope-from ken@kdm.org) Received: by mailman.ysv.freebsd.org (Postfix) id 6F5C2AC08C5; Tue, 1 Mar 2016 22:48:02 +0000 (UTC) Delivered-To: current@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 6EC5EAC08C4; Tue, 1 Mar 2016 22:48:02 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 34396196F; Tue, 1 Mar 2016 22:48:01 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPS id u21MlwhB087148 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 1 Mar 2016 17:47:58 -0500 (EST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.15.2/8.14.9/Submit) id u21Mlwff087147; Tue, 1 Mar 2016 17:47:58 -0500 (EST) (envelope-from ken) Date: Tue, 1 Mar 2016 17:47:58 -0500 From: "Kenneth D. Merry" To: scsi@freebsd.org, current@freebsd.org Subject: Re: CAM Shingled Disk support patches available Message-ID: <20160301224758.GA86834@mithlond.kdm.org> References: <20151118171309.GA3564@mithlond.kdm.org> <20160118223704.GA87506@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160118223704.GA87506@mithlond.kdm.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Tue, 01 Mar 2016 17:47:58 -0500 (EST) X-Spam-Status: No, score=-0.4 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mithlond.kdm.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 22:48:02 -0000 I have a new set of SMR patches available. (See the original message below for a more detailed description of what these patches do.) The primary change is to add library versioning to libcam so that we can change the function prototype of scsi_ata_pass_16() in a way that won't break existing binaries. If someone more familiar with library versioning wants to review this, I'd appreciate it. The patches are here: FreeBSD/head, as of SVN revision 296278 https://people.freebsd.org/~ken/cam_smr.head.20160301.1.txt stable/10, as of SVN revision 296248 https://people.freebsd.org/~ken/cam_smr.stable10.20160301.1.txt (Note that although there is a stable/10 version of the patches, I'm not planning to merge them to stable/10 because of the change to struct bio. I can't really figure out a good way to make that backward compatible. If there is consensus that breaking it is fine because it isn't a user API, then that may be another story.) The problem is that the existing, in-tree version of scsi_ata_pass_16() has a dxfer_len argument that is a uint16_t. That restricts transfer sizes to 64KB. So, we need to update it to allow larger than 64K transfers. I could just create a new function, but I'd rather just retire the broken version. The intent here is that: 1. Binaries built against the old version of libcam, before versioning was turned on, will get the old version of the scsi_ata_pass_16() function with a uint16_t dxfer_len. 2. Binaries built against the new version of libcam will get the new version of the scsi_ata_pass_16() function with a uint32_t dxfer_len. I've tested this, and it appears to work, but I'm not 100% certain this is all correct. I looked at Dan Eischen's description of symbol versioning here: https://people.freebsd.org/~deischen/symver/freebsd_versioning.txt And it looks like the actual implementation is a little different than what is described there. I looked around the tree, and didn't see anything that is obviously exactly like what I'm trying to do here. So, what I did is as follows: 1. For the kernel, the only change is to switch the dxfer_len argument from a uint16_t to a uint32_t. 2. For userland, in scsi_all.c, there are now two versions of scsi_ata_pass_16 -- _ver1 and _ver2. _ver1 is aliased to scsi_ata_pass_16() for FBSD_1.3 using __sym_compat(). _ver2 is aliased to scsi_ata_pass_16() for FBSD_1.4 using __sym_default(). 3. In lib/libcam/Versions.def, I defined FBSD_1.3 and FBSD_1.4, which depends on FBSD_1.3. 4. In lib/libcam/Symbol.map, I pulled out all of the functions defined in libcam, sorted them, and defined them in FBSD_1.3. I moved scsi_ata_pass_16() to FBSD_1.4. (According to the freebsd_versioning.txt paper linked above, I should have been able to have scsi_ata_pass_16() in both FBSD_1.3 and FBSD_1.4, but that isn't the case in practice.) In testing an old binary (linked against libcam without symbol versioning) against a new libcam (with symbol versioning), the old version of the function appears to be used. With a new binary, the new version of the function appears to be used. So it looks like things work as intended, but I don't fully trust my understanding here. So, if someone could take a look at the changes, I'd appreciate it. In particular, I have a few questions: 1. If this change to scsi_ata_pass_16() gets merged to stable/10 (apart from the larger SMR changes), what should be done with the libcam library version? 2. Are 1.3 and 1.4 the proper versions to use? 3. If we make additional CAM helper function library changes, when do the versions get bumped? i.e., is this an opportunity to look for other library functions with issues and make changes if possible? 4. When you're going from an unversioned library to a versioned library, which version of a function gets linked in to a binary linked to the unversioned library when you run it against a versioned library? In other words, what is supposed to happen in the test scenario I tried above, and am I really seeing what is supposed to happen? Thanks, Ken On Mon, Jan 18, 2016 at 17:37:04 -0500, Kenneth D. Merry wrote: > I have a new set of SMR patches available. See below for the full > explanation. > > The primary change here is that I have added SMR support to the ada(4) > driver. I spent some time considering whether to try to make the da(4) and > ada(4) probe infrastructure somewhat common, but in the end concluded it > would be too involved with not enough code reduction (if any) in the end. > > So, although the ideas are similar, the probe logic is separate. > > Note that NCQ support for SMR commands (Report Zones, Reset Write Pointer, > etc.) for SATA protocol shingled drives isn't active. For both the da(4) > and ada(4) driver this is for lack of a way to plumb the ATA Auxiliary > register down to the drive. > > In the ada(4) case, we need to add the register to struct ccb_ataio and > add support in one or more of the underlying SATA drivers, e.g. ahci(4). > > In the da(4) case, it will require an update of the T-10 SAT spec to > provide a way to pass the Auxiliary register down via the SCSI ATA > PASS-THROUGH command, and then a subsquent update of the SAT layer in > various vendors' SAS controller firmware. At that point, there may be > an official mapping of the SCSI ZBC commands to the ATA ZAC commands, and > we may be able to just issue the SCSI version of the commands instead of > composing ATA commands in the da(4) driver. (We'll still need to keep the > ATA passthrough version for a while at least to support controllers that > don't have the updated translation code.) > > FreeBSD/head as of SVN revision 294105: > > https://people.freebsd.org/~ken/cam_smr.head.20160118.1.txt > > FreeBSD stable/10 as of SVN revision 294100: > > https://people.freebsd.org/~ken/cam_smr.stable10.20160118.1.txt > > Testing and comments are welcome. > > Ken > > On Wed, Nov 18, 2015 at 12:13:09 -0500, Kenneth D. Merry wrote: > > > > I have work in progress patches to add SMR (Shingled Magnetic Recording) > > support to CAM and GEOM here: > > > > FreeBSD/head as of SVN revision 290997: > > > > https://people.freebsd.org/~ken/cam_smr.head.20151117.1.txt > > > > FreeBSD stable/10 as of SVN revision 290995: > > > > https://people.freebsd.org/~ken/cam_smr.stable10.20151117.1.txt > > > > This includes support for Host Managed, Host Aware and Drive Managed SMR > > drives that are either SCSI (ZBC) or ATA (ZAC) attached via a SAS > > controller. This does not include support for SMR ATA drives attched via > > an ATA controller. Also, I have not yet figured out how to properly detect > > a Host Managed ATA drive, so this code won't do that. > > > > The big drive vendors are moving to SMR for at least some of their drives. > > The primary challenge with SMR is that it requires writing a relatively > > large zone sequentially starting at the beginning of the zone. The usual > > zone size is 256MB. It is conceptually almost like having a 256MB sector > > size. > > > > We (Spectra Logic) are working on ZFS changes that will use this CAM and > > GEOM infrastructure to make ZFS play well with SMR drives. Those changes > > aren't yet done. > > > > The patches linked above include: > > o A new 'camcontrol zone' command that allows displaying and managing > > drive zones via SCSI/ATA passthrough. > > o A new zonectl(8) utility that uses the new DIOCZONECMD ioctl to display > > and manage zones via the da(4) (and later ada(4)) driver. > > o Changes to diskinfo -v to display the zone mode of a drive. > > o A new disk zone API, sys/sys/disk_zone.h. > > o A new bio type, BIO_ZONE, and modifications to GEOM to support it. This > > new bio will allow filesystems to query zone support in a drive and > > manage zoned drives. > > o Extensive modifications to the da(4) driver to handle probing SCSI and > > SATA behind SAS SMR drives. > > o Additional CAM CDB building functions for zone commands. > > > > The current issues that need to be addressed are: > > o The da(4) driver now has 6 additional probe states, 5 of which are > > needed for probing ATA drives behind SAS controllers. I have not yet > > added support for BIO_ZONE bios to ada(4), but it will be very similar > > to the da(4) driver version. The ATA probe code needs to be pulled > > out of the da(4) driver and changed into a form that will allow it to > > work for either the ada(4) or da(4) driver. Otherwise we'll have a fair > > amount of code duplication between the two drivers. > > > > o There is a reasonable amount of code duplication between 'camcontrol zone' > > and zonectl(8). This was done for speed / expediency's sake, but it may > > be possible to make more of the code common there. > > > > o In order to add the new BIO_ZONE bio command, I had to change the bio_cmd > > field in struct bio from a uint8_t to a uint16_t. This will cause > > binary compatibility problems with any 3rd party loadable modules. > > Advice on how to handle this would be welcome. > > > > o In the process of developing these changes, I discovered that the > > dxfer_len paramter for scsi_ata_pass_16() was too small (uint16_t, and > > it needed to be uint32_t). I increased it, but that will potentially > > cause a binary incompatibility problem with any existing applications > > that use the current API via libcam. Advice on how to handle that > > would be welcome. > > > > If you look through the code, you'll notice that the disk_zone.h API is > > separate from the SCSI and ATA APIs. The intent is to allow filesystems > > and other consumers of the API to just talk to the disk zone API without > > dealing with the SCSI and ATA specifics. Another reason behind all of this > > is that even though the SCSI ZBC and ATA ZAC specs were developed in > > concert, and are intended to be functionally identical, they are still SCSI > > and ATA. As usual, SCSI is big endian and ATA is little endian. So to > > present a common API to the filesystem, we give all of the zone data back > > in native byte order, regardless of the underlying device protocol. > > > > Another thing to note is the extensive use of ATA passthrough in the da(4) > > driver. This is necessary because the SCSI SAT (SCSI to ATA Translation) > > specification has not yet caught up with translating SCSI zone commands > > (ZBC) to ATA zone commands (ZAC). So, until the spec is updated and LSI > > and other vendors update their SCSI to ATA translation layers, we'll have > > to use the ATA version of the commands when talking to ATA drives via SAS > > controllers. > > > > I have only tested the code so far with Seagate SATA Drive Managed and Host > > Aware drives. I would appreciate testing with any drives. (And testing to > > make sure that the patches don't cause problems with existing hardware.) > > Right now, all you can really do is manage the zones manually using > > camcontrol(8) or zonectl(8). Automatic management will come with the ZFS > > changes. (Or changes to other filesysems if people want to do it.) > > > > If you have a SATA Host Aware drive, in theory camcontrol(8) should allow > > you to manage the drive if you have it attached to a SATA controller. > > > > Here is an example of some of the commands. > > > > Get general zoning information: > > > > [root@sm4u-1 ~]# zonectl -c params -d /dev/da21 > > Zone Mode: Host Aware > > Command support: Report Zones, Open, Close, Finish, Reset Write Pointer > > Unrestricted Read in Sequential Write Required Zone (URSWRZ): No > > Optimal Number of Open Sequential Write Preferred Zones: 128 > > Optimal Number of Non-Sequentially Written Sequential Write Preferred Zones: 8 > > Maximum Number of Open Sequential Write Required Zones: Unlimited > > > > Look at information from the da(4) driver: > > > > [root@sm4u-1 ~]# sysctl kern.cam.da.21 > > kern.cam.da.21.delete_method: NONE > > kern.cam.da.21.delete_max: 1081344 > > kern.cam.da.21.minimum_cmd_size: 6 > > kern.cam.da.21.sort_io_queue: -1 > > kern.cam.da.21.zone_mode: Host Aware > > kern.cam.da.21.zone_support: Report Zones, Open, Close, Finish, Reset Write Pointer > > kern.cam.da.21.optimal_seq_zones: 128 > > kern.cam.da.21.optimal_nonseq_zones: 8 > > kern.cam.da.21.max_seq_zones: 4294967295 > > kern.cam.da.21.error_inject: 0 > > > > Display all of the zones with zonectl(8): > > > > [root@sm4u-1 ~]# zonectl -d /dev/da21 -c rz > > 29809 zones, Maximum LBA 0x3a3812aaf (15628053167) > > Zone lengths and types may vary > > Start LBA Length WP LBA Zone Type Condition Sequential Reset > > 0, 524288, 0x80000, Conventional, NWP, Sequential, No Reset Needed > > 0x80000, 524288, 0x100000, Conventional, NWP, Sequential, No Reset Needed > > 0x100000, 524288, 0x180000, Conventional, NWP, Sequential, No Reset Needed > > 0x180000, 524288, 0x200000, Conventional, NWP, Sequential, No Reset Needed > > 0x200000, 524288, 0x280000, Conventional, NWP, Sequential, No Reset Needed > > 0x280000, 524288, 0x300000, Conventional, NWP, Sequential, No Reset Needed > > 0x300000, 524288, 0x380000, Conventional, NWP, Sequential, No Reset Needed > > 0x380000, 524288, 0x400000, Conventional, NWP, Sequential, No Reset Needed > > 0x400000, 524288, 0x480000, Conventional, NWP, Sequential, No Reset Needed > > 0x480000, 524288, 0x500000, Conventional, NWP, Sequential, No Reset Needed > > 0x500000, 524288, 0x580000, Conventional, NWP, Sequential, No Reset Needed > > 0x580000, 524288, 0x600000, Conventional, NWP, Sequential, No Reset Needed > > 0x600000, 524288, 0x680000, Conventional, NWP, Sequential, No Reset Needed > > 0x680000, 524288, 0x700000, Conventional, NWP, Sequential, No Reset Needed > > 0x700000, 524288, 0x780000, Conventional, NWP, Sequential, No Reset Needed > > [ ... ] > > 0x1f00000, 524288, 0x1f80000, Conventional, NWP, Sequential, No Reset Needed > > 0x1f80000, 524288, 0x2000000, Conventional, NWP, Sequential, No Reset Needed > > 0x2000000, 524288, 0x2080000, Seq Preferred, Full, Sequential, No Reset Needed > > 0x2080000, 524288, 0x2100000, Seq Preferred, Full, Sequential, No Reset Needed > > 0x2100000, 524288, 0x2180000, Seq Preferred, Full, Sequential, No Reset Needed > > 0x2180000, 524288, 0x2200000, Seq Preferred, Full, Sequential, No Reset Needed > > 0x2200000, 524288, 0x2280000, Seq Preferred, Full, Sequential, No Reset Needed > > 0x2280000, 524288, 0x2300000, Seq Preferred, Full, Sequential, No Reset Needed > > [ ... ] > > > > Use camcontrol zone to reset the write pointer for the first shingled zone > > listed above: > > > > [root@sm4u-1 ~]# camcontrol zone da21 -v -c rwp -l 0x2000000 > > > > Use camcontrol zone to ask the drive to report empty zones: > > > > [root@sm4u-1 ~]# camcontrol zone da21 -v -c rz -o empty > > 1 zones, Maximum LBA 0x3a3812aaf (15628053167) > > Zone lengths and types may vary > > Start LBA Length WP LBA Zone Type Condition Sequential Reset > > 0x2000000, 524288, 0x2000000, Seq Preferred, Empty, Sequential, No Reset Needed > > > > Get information on a Host Aware drive: > > > > root@sm4u-1 ~]# diskinfo -v da21 > > da21 > > 512 # sectorsize > > 8001563222016 # mediasize in bytes (7.3T) > > 15628053168 # mediasize in sectors > > 4096 # stripesize > > 0 # stripeoffset > > 972801 # Cylinders according to firmware. > > 255 # Heads according to firmware. > > 63 # Sectors according to firmware. > > Z84008NY # Disk ident. > > enc@5003048001f311fd/elmtype@array_device/slot@22 # Physical path > > Host Aware # Zone Mode > > > > Get information on a drive managed drive: > > > > [root@sm4u-1 ~]# diskinfo -v da20 > > da20 > > 512 # sectorsize > > 8001563222016 # mediasize in bytes (7.3T) > > 15628053168 # mediasize in sectors > > 4096 # stripesize > > 0 # stripeoffset > > 972801 # Cylinders according to firmware. > > 255 # Heads according to firmware. > > 63 # Sectors according to firmware. > > Z8405938 # Disk ident. > > enc@5003048001f311fd/elmtype@array_device/slot@21 # Physical path > > Drive Managed # Zone Mode > > > > Get information on a non-zoned drive: > > > > [root@sm4u-1 ~]# diskinfo -v da4 > > da4 > > 512 # sectorsize > > 100030242816 # mediasize in bytes (93G) > > 195371568 # mediasize in sectors > > 0 # stripesize > > 0 # stripeoffset > > 12161 # Cylinders according to firmware. > > 255 # Heads according to firmware. > > 63 # Sectors according to firmware. > > 124903574F36 # Disk ident. > > enc@5003048001f311fd/elmtype@array_device/slot@5 # Physical path > > Not Zoned # Zone Mode > > > > Testing and comments are welcome. > > > > Thanks, > > > > Ken > > -- > > Kenneth Merry > > ken@FreeBSD.ORG > > -- > Kenneth Merry > ken@FreeBSD.ORG -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@freebsd.org Tue Mar 1 22:56:31 2016 Return-Path: Delivered-To: freebsd-current@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 4BAE5AC0CC2 for ; Tue, 1 Mar 2016 22:56:31 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-11.arcor-online.net (mail-in-11.arcor-online.net [151.189.21.51]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 06C6F1055 for ; Tue, 1 Mar 2016 22:56:30 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-15-z2.arcor-online.net (mail-in-15-z2.arcor-online.net [151.189.8.32]) by mx.arcor.de (Postfix) with ESMTP id 3qFCgx4FS5z31rH for ; Tue, 1 Mar 2016 23:25:01 +0100 (CET) Received: from mail-in-11.arcor-online.net (mail-in-11.arcor-online.net [151.189.21.51]) by mail-in-15-z2.arcor-online.net (Postfix) with ESMTP id 8BAC1112726 for ; Tue, 1 Mar 2016 23:25:01 +0100 (CET) Received: from webmail17.arcor-online.net (webmail17.arcor-online.net [151.189.8.75]) by mail-in-11.arcor-online.net (Postfix) with ESMTP id 3qFCgx3v9Fz31rH for ; Tue, 1 Mar 2016 23:25:01 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-11.arcor-online.net 3qFCgx3v9Fz31rH DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arcor.de; s=mail-in; t=1456871101; bh=TVvIRGfHvW6KcAWai1bDHrEmae9EQxZNYdVz0teGbFA=; h=Date:From:To:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ppp5s6oVr6kZjdcYhLyIk79DsXQwP95mdK3etXsfOAUDz/NWi+DYIMvBPDdSJKtR4 ZwpnGIC3v9dXuNZBxvKfumALIkDelXW/f89u3DmtXQakaWSMIfRfdYU9MiCsJ8DUFR TKslkngJa9ZkqRD+zhnjRNmKj0F0sp7K8VFKdxFM= Received: from [84.179.18.47] by webmail17.arcor-online.net (151.189.8.75) with HTTP (Arcor Webmail); Tue, 1 Mar 2016 23:25:01 +0100 (CET) Date: Tue, 1 Mar 2016 23:25:01 +0100 (CET) From: Carsten Kunze To: freebsd-current@freebsd.org Message-ID: <1801644476.184239.1456871101536.JavaMail.ngmail@webmail17.arcor-online.net> In-Reply-To: References: <1493379294.130887.1456847269287.JavaMail.ngmail@webmail21.arcor-online.net> <1134012018.181281.1456856587109.JavaMail.ngmail@webmail17.arcor-online.net> <913b75500917c016362a7633e1def254@thebighonker.lerctr.org> <1355875693.183451.1456865289211.JavaMail.ngmail@webmail17.arcor-online.net> <1495441441.183610.1456866066268.JavaMail.ngmail@webmail17.arcor-online.net> <467796244.184206.1456870429167.JavaMail.ngmail@webmail17.arcor-online.net> Subject: Re: WLAN hardware not recognized MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ngMessageSubType: MessageSubType_MAIL X-WebmailclientIP: 84.179.18.47 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 22:56:31 -0000 Adrian Chadd wrote: > Right, you need to create the interface: > > ifconfig wlan0 create wlandev iwn0 > > then run wpa_spuplicant > > (or do it all in /etc/rc.conf .. :) That seems to work. There seems to be something configured wrong for wpa_supplicant but WLAN does react. Thank you for all your WLAN work! From owner-freebsd-current@freebsd.org Wed Mar 2 01:29:16 2016 Return-Path: Delivered-To: freebsd-current@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 10725AC021F; Wed, 2 Mar 2016 01:29:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::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 E4B90196C; Wed, 2 Mar 2016 01:29:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 026FFB96B; Tue, 1 Mar 2016 20:29:15 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Cc: Ivan Klymenko , Michael Butler , "freebsd-emulation@freebsd.org" Subject: Re: SVN r296272 breaks virtualbox Date: Tue, 01 Mar 2016 17:27:35 -0800 Message-ID: <76770847.2GZvgBdTxv@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160302004206.5bc6e0b3@nonamehost.local> References: <56D617D1.5040209@protected-networks.net> <20160302004206.5bc6e0b3@nonamehost.local> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 01 Mar 2016 20:29:15 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 01:29:16 -0000 On Wednesday, March 02, 2016 12:42:05 AM Ivan Klymenko wrote: > On Tue, 1 Mar 2016 17:29:37 -0500 > Michael Butler wrote: > > > The removal of "taskqueue_enqueue_fast" breaks the virtualbox kmods: > > > > Mar 1 16:54:36 toshi kernel: vboxdrv: fAsync=0 offMin=0x914 > > offMax=0x151c Mar 1 16:54:36 toshi kernel: link_elf_obj: symbol > > taskqueue_enqueue_fast undefined > > Mar 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type > > Mar 1 16:54:36 toshi kernel: link_elf_obj: symbol > > taskqueue_enqueue_fast undefined > > Mar 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type > > Mar 1 16:54:36 toshi kernel: KLD vboxnetadp.ko: depends on > > vboxnetflt - not available or version mismatch > > Mar 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type > > > > Michael > > > > > +1 Then the port needs to be patched? It's been using an API deprecated for the last 15 years. A simple s/taskqueue_enqueue_fast/taskqueue_enqueue/ will fix it. -- John Baldwin From owner-freebsd-current@freebsd.org Wed Mar 2 01:29:17 2016 Return-Path: Delivered-To: freebsd-current@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 5F54CAC0231 for ; Wed, 2 Mar 2016 01:29:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::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 4147B1971 for ; Wed, 2 Mar 2016 01:29:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 515E9B972; Tue, 1 Mar 2016 20:29:16 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Cc: Joe Holden Subject: Re: Bay Trail 32bit UEFI Date: Tue, 01 Mar 2016 17:20:34 -0800 Message-ID: <4073395.HnTjdCHcSr@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <56D29AF6.50401@m.jwh.me.uk> References: <56D29AF6.50401@m.jwh.me.uk> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 01 Mar 2016 20:29:16 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 01:29:17 -0000 On Sunday, February 28, 2016 07:00:06 AM Joe Holden wrote: > Hi all, > > Apologies if this is the wrong list... > > Is there any plan to support booting FreeBSD on 32bit UEFI systems (with > or without 64bit kernel/userland)? Obviously there is no i386 efi loader > currently so neither is possible... I don't think anyone is actively working on it. I think it shouldn't be that much work once the i386 loader is resurrected. The i386 kernel just needs to use the EFI memory map and I think the rest of it should generally just work. -- John Baldwin From owner-freebsd-current@freebsd.org Wed Mar 2 01:29:18 2016 Return-Path: Delivered-To: freebsd-current@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 C7613AC0242; Wed, 2 Mar 2016 01:29:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::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 A53D819CB; Wed, 2 Mar 2016 01:29:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A415DB990; Tue, 1 Mar 2016 20:29:17 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Cc: Warner Losh , Marcel Moolenaar , "Lundberg, Johannes" , "freebsd-embedded@freebsd.org" , "freebsd-mobile@freebsd.org" Subject: Re: hint.uart.1 in device.hints causes freeze at boot Date: Tue, 01 Mar 2016 17:19:34 -0800 Message-ID: <21207070.KlEgumgKTW@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <4E9118B0-FC9F-444F-B277-3E5BAE75C723@xcllnt.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 01 Mar 2016 20:29:17 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 01:29:18 -0000 On Friday, February 26, 2016 11:08:37 PM Warner Losh wrote: > On Fri, Feb 26, 2016 at 6:49 PM, Marcel Moolenaar wrote: > > Any reason not to add .disabled=1 to all the entries that are there, > with the possible exception of uart.0? At least for i386 and amd64? > Bonus points for writing code that filters those out when there's > no ACPI. While PNPBIOS could also supply this info, I doubt that you > could find hardware that has pnpbios data and not ACPI data except > maybe some of the soekris boxes to test against. > > Better still would be to split the current GENERIC.hints into two bits. > One that was strictly for legacy (!ACPI and !PNPBIOS) situations, and > one that we always load. There look to be at least a couple of hints > that are universally relevant still. I might have a 200MHz pentium I > can test this with... If there was an easy way to load a new hints file we could ship a /boot/legacy.hints and have a note in the handbook / FAQ about using it if needed. We could even have smarts in the loader to suck it in perhaps if !ACPI and !PnPBIOS. > As near as I can tell, only the following are relevant: > hint.fd.0.at="fdc0" > hint.fd.0.drive="0" > hint.fd.1.at="fdc0" > hint.fd.1.drive="1" > hint.acpi_throttle.0.disabled="1" > hint.p4tcc.0.disabled="1" hint.sc.0.at is relevant if you want to use sc(4) instead of vt(4). For a long time I've booted machines that only had that hint. The npx.0 hint used to matter (but no longer does). I think we should definitely trim the hints file for amd64. amd64 pretty much mandates ACPI. For i386 I would be fine with a the legacy.hints route even if it wasn't automagical but something you had to manually load. The only thing about the hints that is still somewhat useful on x86 is enabling serial console (though boot -h and/or console=comconsole already does that) and enabling remote GDB. (hint.uart.1.flags=0x80 is shorter and doesn't require remembering random I/O port addresses like the hw.uart route for GDB.) -- John Baldwin From owner-freebsd-current@freebsd.org Wed Mar 2 01:45:20 2016 Return-Path: Delivered-To: freebsd-current@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 22C5DAC093A for ; Wed, 2 Mar 2016 01:45:20 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D98AF1806 for ; Wed, 2 Mar 2016 01:45:19 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-vk0-x22e.google.com with SMTP id e185so187285171vkb.1 for ; Tue, 01 Mar 2016 17:45:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brilliantservice-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iiPDtSTndojkgLvK6J4LlsImqFthMFBICP8KocEZIaY=; b=p3VV+owVg9oiaee0S25jO7xpqSClkosdmrREpSyUfWk0VtTYmzeTy6KbjaPp7gtg+M tY+frwaI9jRQev+HGrGkam6/02e4pofYJI69rJTm8hxlpgtCtuDyva0OoyQAJrIE2X1Z 5l8nPoL5RodprZRI2w4Njrv71JZmVDd4/WTninFdz/Flcvjtphko9v5p86faPJOVzyL0 40WEytGfN7nlZE078uci71TzCHmnc394+zLDs7t18enow43U1ncWW9eo0HnOir3d0aVO Rs4RMq26/gXPzWIBx6NJgguiW+PupFV/xlJcjAklsH+ndEY8BCarMJxK6+X4a47IwbVe 5qww== 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=iiPDtSTndojkgLvK6J4LlsImqFthMFBICP8KocEZIaY=; b=h5aaQboCp+Z3fPfLSFJDTY+6LMKsSkPyhixDwcrZGaFX2R6Hkog3HrDq1Gr14gcOLR VFR8YoIXhvt98eGOSKaZKpQx0DePDZ/lE9a5ImgKOC4MH9PgR4bSxrWU75If6BQKAtdM mhbDE5JX9ktK/AVbPfPhFcb/v0XfWKui/tcIEotq1W5DCKRpXEPZd9N2FYqXbUbUajDJ 1Id66IleUwafPL//6bv/OrNuyGMjaTNMkG8nSkDK23HTTI6RTroK5KasZPWuSb8hZDXX 43C36kHwiXutP5BWNg5cs5h8d+KfjNQ2T3yRNOIwDZkVzg9sGLw5WRXIxj6GACgGC9bB jn1g== X-Gm-Message-State: AD7BkJIxJaY7SEtvtgbt0W+sLsj4PvyAPHq2D/EIyB8P15gJPNzu9Bx0J/jdAKIFgkAIvpsTsGLcJUjAUqESVWLdgYGK64mY/7IBt+upu0zd96OQAU7QHfpEk03v6GNZ1OeGbG/RczF/cTOmzVrJkh4JOEE= X-Received: by 10.31.16.218 with SMTP id 87mr18620818vkq.105.1456883118473; Tue, 01 Mar 2016 17:45:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.36.197 with HTTP; Tue, 1 Mar 2016 17:45:04 -0800 (PST) In-Reply-To: <4073395.HnTjdCHcSr@ralph.baldwin.cx> References: <56D29AF6.50401@m.jwh.me.uk> <4073395.HnTjdCHcSr@ralph.baldwin.cx> From: "Lundberg, Johannes" Date: Tue, 1 Mar 2016 17:45:04 -0800 Message-ID: Subject: Re: Bay Trail 32bit UEFI To: John Baldwin Cc: FreeBSD Current , Joe Holden Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 01:45:20 -0000 Q2hlcnJ5VHJhaWwgZGV2aWNlcy9ib2FyZHMgd2l0aCA2NGJpdCBVRUZJIGFyZSBhbHJlYWR5IG91 dC4gVXBncmFkaW5nIHRoZQ0KaGFyZHdhcmUgaXMgb25lIHNvbHV0aW9uIChJIGRpZCkuDQoNCkkg bmV2ZXIgZGlkIHRyeSBGcmVlQlNEIG9uIEJheVRyYWlsIGJ1dCBmb3IgcnVubmluZyBMaW51eCBv biBCYXlUcmFpbCBJDQp1c2VkIHNwZWNpYWwgYnVpbHQgR3J1YiB0aGF0IHdhcyAzMmJpdCBidXQg Y291bGQgbG9hZCA2NGJpdCBPUy4gQ291bGQgdGhpcw0Ka2luZCBvZiBHcnViIGJvb3QgYSA2NGJp dCBGcmVlQlNELCBJIHdvbmRlcj8NCg0KDQpPbiBUdWUsIE1hciAxLCAyMDE2IGF0IDU6MjAgUE0s IEpvaG4gQmFsZHdpbiA8amhiQGZyZWVic2Qub3JnPiB3cm90ZToNCg0KPiBPbiBTdW5kYXksIEZl YnJ1YXJ5IDI4LCAyMDE2IDA3OjAwOjA2IEFNIEpvZSBIb2xkZW4gd3JvdGU6DQo+ID4gSGkgYWxs LA0KPiA+DQo+ID4gQXBvbG9naWVzIGlmIHRoaXMgaXMgdGhlIHdyb25nIGxpc3QuLi4NCj4gPg0K PiA+IElzIHRoZXJlIGFueSBwbGFuIHRvIHN1cHBvcnQgYm9vdGluZyBGcmVlQlNEIG9uIDMyYml0 IFVFRkkgc3lzdGVtcyAod2l0aA0KPiA+IG9yIHdpdGhvdXQgNjRiaXQga2VybmVsL3VzZXJsYW5k KT8gT2J2aW91c2x5IHRoZXJlIGlzIG5vIGkzODYgZWZpIGxvYWRlcg0KPiA+IGN1cnJlbnRseSBz byBuZWl0aGVyIGlzIHBvc3NpYmxlLi4uDQo+DQo+IEkgZG9uJ3QgdGhpbmsgYW55b25lIGlzIGFj dGl2ZWx5IHdvcmtpbmcgb24gaXQuICBJIHRoaW5rIGl0IHNob3VsZG4ndCBiZQ0KPiB0aGF0IG11 Y2ggd29yayBvbmNlIHRoZSBpMzg2IGxvYWRlciBpcyByZXN1cnJlY3RlZC4gIFRoZSBpMzg2IGtl cm5lbCBqdXN0DQo+IG5lZWRzIHRvIHVzZSB0aGUgRUZJIG1lbW9yeSBtYXAgYW5kIEkgdGhpbmsg dGhlIHJlc3Qgb2YgaXQgc2hvdWxkIGdlbmVyYWxseQ0KPiBqdXN0IHdvcmsuDQo+DQo+IC0tDQo+ IEpvaG4gQmFsZHdpbg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBmcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0DQo+IGh0 dHBzOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLWN1cnJlbnQN Cj4gVG8gdW5zdWJzY3JpYmUsIHNlbmQgYW55IG1haWwgdG8gImZyZWVic2QtY3VycmVudC11bnN1 YnNjcmliZUBmcmVlYnNkLm9yZyINCj4NCgotLSAKPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09 LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tCuenmOWvhuS/neaMgeOBq+OBpOOBhOOBpu+8muOB k+OBrumbu+WtkOODoeODvOODq+OBr+OAgeWQjeWum+S6uuOBq+mAgeS/oeOBl+OBn+OCguOBruOB p+OBguOCiuOAgeenmOWMv+eJueaoqeOBruWvvuixoeOBqOOBquOCi+aDheWgseOCkuWQq+OCk+OB p+OBhOOBvuOBmeOAggrjgoLjgZfjgIHlkI3lrpvkurrku6XlpJbjga7mlrnjgYzlj5fkv6HjgZXj gozjgZ/loLTlkIjjgIHjgZPjga7jg6Hjg7zjg6vjga7noLTmo4TjgIHjgYrjgojjgbPjgZPjga7j g6Hjg7zjg6vjgavplqLjgZnjgovkuIDliIfjga7plovnpLrjgIEK6KSH5YaZ44CB6YWN5biD44CB 44Gd44Gu5LuW44Gu5Yip55So44CB44G+44Gf44Gv6KiY6LyJ5YaF5a6544Gr5Z+644Gl44GP44GE 44GL44Gq44KL6KGM5YuV44KC44GV44KM44Gq44GE44KI44GG44GK6aGY44GE55Sz44GX5LiK44GS 44G+44GZ44CCCi0tLQpDT05GSURFTlRJQUxJVFkgTk9URTogVGhlIGluZm9ybWF0aW9uIGluIHRo aXMgZW1haWwgaXMgY29uZmlkZW50aWFsCmFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRy ZXNzZWUuCkRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciBhbnkgb3RoZXIgYWN0 aW9uIG9mIHVzZSBvZiB0aGlzCmVtYWlsIGJ5IHBlcnNvbiBvdGhlciB0aGFuIGludGVuZGVkIHJl Y2lwaWVudCwgaXMgcHJvaGliaXRlZC4KSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCBhbmQgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluCmVycm9yLCBwbGVhc2UgZGVzdHJv eSB0aGUgb3JpZ2luYWwgbWVzc2FnZS4K From owner-freebsd-current@freebsd.org Wed Mar 2 02:00:16 2016 Return-Path: Delivered-To: freebsd-current@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 9C2A2AC0D59; Wed, 2 Mar 2016 02:00:16 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 6C9841D7C; Wed, 2 Mar 2016 02:00:16 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: by mail-pf0-x232.google.com with SMTP id l6so26307206pfl.3; Tue, 01 Mar 2016 18:00:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:reply-to:subject:references:to:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Ngat3i0XscDPT+4OoVy3hATrHDYIyFKu3hsvulN+LXQ=; b=LVHQjvIXBxo647YEDYjtGx6XOv0VgiyhgxLw21/GvSLnKMBQ29UYDL1sSO8VQ+xphq Uj+PJTqI7nUakYdFatonQTQyU/EmZrnA0VmE6CVEJbsIP/R++4EdxogUOSHSGV8eRUsv aIyjoqPMX9yPnMZBnlYrCWEF0ZM2AUBm3aM2C0MKvT62IGz8WKY3qDaqa5TDS2/+A0t2 5THhr8pGll5Lpa1fbg9GXTDS7Ym9WUwAZkD7X7AcQerOKRsQTBNPnIcUTpML6K6UatnB WypiiDe5il3oogE12oDmC8s36F0nRDmZYi8IRkPJLXheCOHy3rmsyVQ3IxaQPadPcdZF 8yog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:reply-to:subject:references:to:cc:from :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Ngat3i0XscDPT+4OoVy3hATrHDYIyFKu3hsvulN+LXQ=; b=IRiEy29EWmw9skQ/pw5hYzT2MG1BXbPxSQW4krrkrRDncWCv7qp+bzVZe8h4IJGVWw Zqzfr5XIL3NxorvMe1KgG2VkH3QB7nyDOKuxq1YgDl0JMOXMH/2xO2gbWisxeMng5zrB MVuKIRtQkevQQJh1uD1H00PAPtnPBnLxUTWXB+9wUH8iBT45mSdfbBv3ymxp1UnthprW c4VBnXUTVFzEraraDWsUbNbFy54/losHwtZUcTjsvy2ZVc4PoxtdfoaNofsK91/d6Dbs /q3l3JhIMIfSVrNDwhhgz1oaP8Wp43Jvi3B+VgX5OwavErESMeskb9MvwI3HL0j1gV+1 WgVA== X-Gm-Message-State: AD7BkJJ2Z1FJTETgZ5+iTTNui7AHf78DyYjOf5w9c6HBabkUOfyodmXX6KZjNAJzCXBpMQ== X-Received: by 10.98.69.1 with SMTP id s1mr34612792pfa.120.1456884015718; Tue, 01 Mar 2016 18:00:15 -0800 (PST) Received: from ?IPv6:2001:44b8:31ae:7b01::1? (2001-44b8-31ae-7b01-0000-0000-0000-0001.static.ipv6.internode.on.net. [2001:44b8:31ae:7b01::1]) by smtp.gmail.com with ESMTPSA id 85sm48326339pfl.18.2016.03.01.18.00.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Mar 2016 18:00:15 -0800 (PST) Sender: Kubilay Kocak Reply-To: koobs@FreeBSD.org Subject: Re: SVN r296272 breaks virtualbox References: <56D617D1.5040209@protected-networks.net> To: Michael Butler , freebsd-current Cc: "freebsd-emulation@freebsd.org" From: Kubilay Kocak Message-ID: <116fdc9e-b601-a45a-4d2c-2530f082c6b4@FreeBSD.org> Date: Wed, 2 Mar 2016 13:00:09 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <56D617D1.5040209@protected-networks.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 02:00:16 -0000 On 2/03/2016 9:29 AM, Michael Butler wrote: > The removal of "taskqueue_enqueue_fast" breaks the virtualbox kmods: > > Mar 1 16:54:36 toshi kernel: vboxdrv: fAsync=0 offMin=0x914 offMax=0x151c > Mar 1 16:54:36 toshi kernel: link_elf_obj: symbol > taskqueue_enqueue_fast undefined > Mar 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type > Mar 1 16:54:36 toshi kernel: link_elf_obj: symbol > taskqueue_enqueue_fast undefined > Mar 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type > Mar 1 16:54:36 toshi kernel: KLD vboxnetadp.ko: depends on vboxnetflt - > not available or version mismatch > Mar 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type > > Michael > Please create a bugzilla issue to track this, including: * a link to this mailing list thread so the maintainers can see the suggestion by John. * An attachment containing a log with the errors observed * Reference/link to the commit that caused the regression * CC the committer of the base revision in question Attaching a patch to fix the issue will likely encourage it to be committed sooner, but is not compulsory ./koobs From owner-freebsd-current@freebsd.org Wed Mar 2 03:13:49 2016 Return-Path: Delivered-To: freebsd-current@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 E1AFEAC093F for ; Wed, 2 Mar 2016 03:13:49 +0000 (UTC) (envelope-from scott4long@yahoo.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 C3FAD1C43 for ; Wed, 2 Mar 2016 03:13:49 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: by mailman.ysv.freebsd.org (Postfix) id C3A18AC093D; Wed, 2 Mar 2016 03:13:49 +0000 (UTC) Delivered-To: current@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 A94BCAC093B for ; Wed, 2 Mar 2016 03:13:49 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm6-vm3.bullet.mail.gq1.yahoo.com (nm6-vm3.bullet.mail.gq1.yahoo.com [98.136.218.194]) (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 850F71C41 for ; Wed, 2 Mar 2016 03:13:49 +0000 (UTC) (envelope-from scott4long@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1456888040; bh=UCZKjbPdIVUwMTzDRBF6t2TsyAPQThiGsCYj4EcMn3M=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=cFjVE2PbLhuX60/cEUKGYYbhIEQeJBJ/vqovNwqEefJeg3gLQBkV8urRxuHO3Q3RMzr1HWe1VXQMYq2uf71H57++kqBLoqWq+tbu0rhw905zomvNMvF6EJUdwt569Qm4mwThnSCzJ2Qjias1EkWfu2CLFWnoM/VhYy8qnL3/67GcRqswUIfZju0WVlsxMyzX1aeUHiMEzzx8D9UdTSOBbZtB8QBAudALTTLfJEFdtRS042lz5i5okImiu9YewgYUsXei8rskA8/epiRb0uPrz1VkdgiTD3iOOm4eQI96ePQ6lz3Za8xy4S2ksBNmhs7gFRq/FAmfOFLvRimTEPzVow== Received: from [98.137.12.59] by nm6.bullet.mail.gq1.yahoo.com with NNFMP; 02 Mar 2016 03:07:20 -0000 Received: from [98.136.164.76] by tm4.bullet.mail.gq1.yahoo.com with NNFMP; 02 Mar 2016 03:07:20 -0000 Received: from [127.0.0.1] by smtp238.mail.gq1.yahoo.com with NNFMP; 02 Mar 2016 03:07:20 -0000 X-Yahoo-Newman-Id: 398030.1184.bm@smtp238.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: nwGW3xoVM1ljTQPYibjrm1mnX6yOxVOs5c3.d6oU5AeNIMO T87POG1p9CluxHr61TK5Th31_EeFuw.iVCcHZhxHn74GewwUBSB97YjXDIuQ GpWnZPmGnVPGZvVk.umJTHmZYOMAKHua1TfcLG.HfKNpcRyVJ1ujZ6napN53 12gMeqr_2_TBRC7N2p2yT5_Z6LvuDaeYCta5hvKjgzDcKoFJ9.gvZ0mhtc0w wJAycRY8UAg97uefUmgDF_an_ju2YHuDJqWTCQZaLCnKI6UPjOLUdyFkGmJl Pp6Y0ryOSyi1ReI.5nkHI6Hsbn3JbY7i_WivphrUh1PxuSaVoxnQER2oSX2L UP4K3_exRbWQEYbFyzzdASMFGdPQgyMwkEfs.vFP7s6LaquLLX6YHCHC6PkR MSePIrwM6mTHJqLOkADIAwRjCge091jAcW4qg6EzRYKL.HSuvWtVytrLO.Y. rDOofDTWZUXzKKtQ1OoO1wroNgPh_Pbc_P2FHHbY.bIvuf3BHwkR5sMqcfm. ZwrGKTPSdwN_gRkAQHr0crWizQQZKk0J5v78.2g0E X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: CAM Shingled Disk support patches available From: Scott Long In-Reply-To: <20160301224758.GA86834@mithlond.kdm.org> Date: Tue, 1 Mar 2016 20:07:19 -0700 Cc: scsi@freebsd.org, current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151118171309.GA3564@mithlond.kdm.org> <20160118223704.GA87506@mithlond.kdm.org> <20160301224758.GA86834@mithlond.kdm.org> To: "Kenneth D. Merry" X-Mailer: Apple Mail (2.3112) X-Mailman-Approved-At: Wed, 02 Mar 2016 03:33:05 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 03:13:50 -0000 Hi Ken, I=E2=80=99m against changing the function signature of = scsi_ata_pass_16(). Even if you manage to get things right with symbol versioning, it still leads = to problems of code compatibility. Maybe pre-existing binaries will work, = but source code will forever have to include an #if __FreeBSD_version < xxxxxx bit of nonsense. I agree that it was incorrect for dxferlen to be declared as a uint16_t. However, the function already contains a sector count argument pair. In theory the sector count multiplied by the sector length, both of which = the application should know in order to arrive at a sensible dxferlen, can substitute for the dxferlen argument. If so, then we can just ignore = that argument and declare that sector_count has logical priority. Really though, I think that scsi_ata_pass_16() is a crummy function. If = its purpose is to implement SAT-3 12.2.2, it does an incredibly poor job at = it: - By my count, it only covers 12 of the available 13 registers. - It has no 12 byte, opcode 0xa1 variant. - It doesn=E2=80=99t make any allowance for providing the response = registers to the caller on completion. Well, maybe it kinda does through a sense = descriptor, but=E2=80=A6. it=E2=80=99s kinda open to vague interpretation. - Its use of the registers is clunky, assuming for example that you=E2=80=99= ll only want to fill the six LBA registers with a host-ordered 64-bit number. There = are plenty of commands that re-use sub-parts of the LBA, features, and/or = sector count registers for different things. =20 I know you stated that you didn=E2=80=99t want to do this, but I think = it=E2=80=99s better to start over with a better function that has a better signature and a new name. = In fact, I think it=E2=80=99s better to use the existing ata_cmd and ata_res = structures from=20 sys/cam/ata/ata_all.h, provide accessors for the multi-byte registers if = needed, provide a 12-byte compatibility, and simply the signature. Something = like this: void scsi_ata_pass(struct ccb_scsiio *csio, u_int32_t retries, void (*cbfcnp)(struct cam_periph *, union ccb *), u_int32_t flags, u_int8_t tag_action, struct ata_cmd *cmd, struct ata_res *res, u_int8_t *data_ptr, u_int32_t dxfer_len, u_int8_t *data_ptr, u_int16_t dxfer_len, u_int8_t sense_len, u_int32_t timeout); To differentiate between the 12 and 16 byte variants, you=E2=80=99d look = at the AP_EXTEND flag in the protocol field. Btw, the handling of that flag is inconsistent in the implementation of the existing scsi_ata_pass_16(). = If the caller providse an ata_res pointer then it gets filled on = completion, otherwise the caller does its best to look at 12.2.2.6 and extract what = it can from the sense descriptor. So my proposal is to create a new scsi_ata_pass and deprecate but not = remove scsi_ata_pass_16. Tell people that if they need to use it, dxfer_len is = going to have lower priority than sector_count/sector_count_exp if the latter = multiply to more than 65535. Scott > On Mar 1, 2016, at 3:47 PM, Kenneth D. Merry wrote: >=20 > I have a new set of SMR patches available. (See the original message = below > for a more detailed description of what these patches do.) >=20 > The primary change is to add library versioning to libcam so that we = can > change the function prototype of scsi_ata_pass_16() in a way that = won't > break existing binaries. >=20 > If someone more familiar with library versioning wants to review this, = I'd > appreciate it. >=20 > The patches are here: >=20 > FreeBSD/head, as of SVN revision 296278 >=20 > https://people.freebsd.org/~ken/cam_smr.head.20160301.1.txt >=20 > stable/10, as of SVN revision 296248 >=20 > https://people.freebsd.org/~ken/cam_smr.stable10.20160301.1.txt >=20 > (Note that although there is a stable/10 version of the patches, I'm = not > planning to merge them to stable/10 because of the change to struct = bio. I > can't really figure out a good way to make that backward compatible. = If > there is consensus that breaking it is fine because it isn't a user = API, > then that may be another story.) >=20 > The problem is that the existing, in-tree version of = scsi_ata_pass_16() has > a dxfer_len argument that is a uint16_t. That restricts transfer = sizes to > 64KB. So, we need to update it to allow larger than 64K transfers. I > could just create a new function, but I'd rather just retire the = broken > version. >=20 > The intent here is that: >=20 > 1. Binaries built against the old version of libcam, before versioning = was > turned on, will get the old version of the scsi_ata_pass_16() function = with > a uint16_t dxfer_len. >=20 > 2. Binaries built against the new version of libcam will get the new > version of the scsi_ata_pass_16() function with a uint32_t dxfer_len. >=20 > I've tested this, and it appears to work, but I'm not 100% certain = this is > all correct. I looked at Dan Eischen's description of symbol = versioning > here: >=20 > https://people.freebsd.org/~deischen/symver/freebsd_versioning.txt >=20 > And it looks like the actual implementation is a little different than = what > is described there. I looked around the tree, and didn't see anything = that > is obviously exactly like what I'm trying to do here. >=20 > So, what I did is as follows: >=20 > 1. For the kernel, the only change is to switch the dxfer_len argument = from > a uint16_t to a uint32_t. >=20 > 2. For userland, in scsi_all.c, there are now two versions of > scsi_ata_pass_16 -- _ver1 and _ver2. _ver1 is aliased to > scsi_ata_pass_16() for FBSD_1.3 using __sym_compat(). _ver2 is = aliased to > scsi_ata_pass_16() for FBSD_1.4 using __sym_default(). >=20 > 3. In lib/libcam/Versions.def, I defined FBSD_1.3 and FBSD_1.4, which > depends on FBSD_1.3. >=20 > 4. In lib/libcam/Symbol.map, I pulled out all of the functions defined = in > libcam, sorted them, and defined them in FBSD_1.3. I moved > scsi_ata_pass_16() to FBSD_1.4. (According to the = freebsd_versioning.txt > paper linked above, I should have been able to have scsi_ata_pass_16() = in > both FBSD_1.3 and FBSD_1.4, but that isn't the case in practice.) >=20 > In testing an old binary (linked against libcam without symbol = versioning) > against a new libcam (with symbol versioning), the old version of the > function appears to be used. With a new binary, the new version of = the > function appears to be used. >=20 > So it looks like things work as intended, but I don't fully trust my > understanding here. So, if someone could take a look at the changes, = I'd > appreciate it. >=20 > In particular, I have a few questions: >=20 > 1. If this change to scsi_ata_pass_16() gets merged to stable/10 = (apart > from the larger SMR changes), what should be done with the libcam = library > version? >=20 > 2. Are 1.3 and 1.4 the proper versions to use? >=20 > 3. If we make additional CAM helper function library changes, when do = the > versions get bumped? i.e., is this an opportunity to look for other > library functions with issues and make changes if possible? >=20 > 4. When you're going from an unversioned library to a versioned = library, > which version of a function gets linked in to a binary linked to the > unversioned library when you run it against a versioned library? In = other > words, what is supposed to happen in the test scenario I tried above, = and > am I really seeing what is supposed to happen? >=20 > Thanks, >=20 > Ken >=20 > On Mon, Jan 18, 2016 at 17:37:04 -0500, Kenneth D. Merry wrote: >> I have a new set of SMR patches available. See below for the full >> explanation. >>=20 >> The primary change here is that I have added SMR support to the = ada(4) >> driver. I spent some time considering whether to try to make the = da(4) and >> ada(4) probe infrastructure somewhat common, but in the end concluded = it >> would be too involved with not enough code reduction (if any) in the = end. >>=20 >> So, although the ideas are similar, the probe logic is separate. >>=20 >> Note that NCQ support for SMR commands (Report Zones, Reset Write = Pointer, >> etc.) for SATA protocol shingled drives isn't active. For both the = da(4) >> and ada(4) driver this is for lack of a way to plumb the ATA = Auxiliary >> register down to the drive. >>=20 >> In the ada(4) case, we need to add the register to struct ccb_ataio = and >> add support in one or more of the underlying SATA drivers, e.g. = ahci(4). >>=20 >> In the da(4) case, it will require an update of the T-10 SAT spec to >> provide a way to pass the Auxiliary register down via the SCSI ATA >> PASS-THROUGH command, and then a subsquent update of the SAT layer in >> various vendors' SAS controller firmware. At that point, there may = be=20 >> an official mapping of the SCSI ZBC commands to the ATA ZAC commands, = and >> we may be able to just issue the SCSI version of the commands instead = of >> composing ATA commands in the da(4) driver. (We'll still need to = keep the >> ATA passthrough version for a while at least to support controllers = that >> don't have the updated translation code.) >>=20 >> FreeBSD/head as of SVN revision 294105: >>=20 >> https://people.freebsd.org/~ken/cam_smr.head.20160118.1.txt >>=20 >> FreeBSD stable/10 as of SVN revision 294100: >>=20 >> https://people.freebsd.org/~ken/cam_smr.stable10.20160118.1.txt >>=20 >> Testing and comments are welcome. >>=20 >> Ken >>=20 >> On Wed, Nov 18, 2015 at 12:13:09 -0500, Kenneth D. Merry wrote: >>>=20 >>> I have work in progress patches to add SMR (Shingled Magnetic = Recording) >>> support to CAM and GEOM here: >>>=20 >>> FreeBSD/head as of SVN revision 290997: >>>=20 >>> https://people.freebsd.org/~ken/cam_smr.head.20151117.1.txt >>>=20 >>> FreeBSD stable/10 as of SVN revision 290995: >>>=20 >>> https://people.freebsd.org/~ken/cam_smr.stable10.20151117.1.txt >>>=20 >>> This includes support for Host Managed, Host Aware and Drive Managed = SMR >>> drives that are either SCSI (ZBC) or ATA (ZAC) attached via a SAS >>> controller. This does not include support for SMR ATA drives = attched via >>> an ATA controller. Also, I have not yet figured out how to properly = detect >>> a Host Managed ATA drive, so this code won't do that. >>>=20 >>> The big drive vendors are moving to SMR for at least some of their = drives. >>> The primary challenge with SMR is that it requires writing a = relatively >>> large zone sequentially starting at the beginning of the zone. The = usual >>> zone size is 256MB. It is conceptually almost like having a 256MB = sector >>> size. >>>=20 >>> We (Spectra Logic) are working on ZFS changes that will use this CAM = and >>> GEOM infrastructure to make ZFS play well with SMR drives. Those = changes >>> aren't yet done. >>>=20 >>> The patches linked above include: >>> o A new 'camcontrol zone' command that allows displaying and = managing >>> drive zones via SCSI/ATA passthrough. >>> o A new zonectl(8) utility that uses the new DIOCZONECMD ioctl to = display >>> and manage zones via the da(4) (and later ada(4)) driver. >>> o Changes to diskinfo -v to display the zone mode of a drive. >>> o A new disk zone API, sys/sys/disk_zone.h. >>> o A new bio type, BIO_ZONE, and modifications to GEOM to support it. = This >>> new bio will allow filesystems to query zone support in a drive = and >>> manage zoned drives. >>> o Extensive modifications to the da(4) driver to handle probing SCSI = and >>> SATA behind SAS SMR drives. >>> o Additional CAM CDB building functions for zone commands. >>>=20 >>> The current issues that need to be addressed are: >>> o The da(4) driver now has 6 additional probe states, 5 of which are >>> needed for probing ATA drives behind SAS controllers. I have not = yet >>> added support for BIO_ZONE bios to ada(4), but it will be very = similar >>> to the da(4) driver version. The ATA probe code needs to be = pulled >>> out of the da(4) driver and changed into a form that will allow it = to >>> work for either the ada(4) or da(4) driver. Otherwise we'll have = a fair >>> amount of code duplication between the two drivers. >>>=20 >>> o There is a reasonable amount of code duplication between = 'camcontrol zone' >>> and zonectl(8). This was done for speed / expediency's sake, but = it may >>> be possible to make more of the code common there. >>>=20 >>> o In order to add the new BIO_ZONE bio command, I had to change the = bio_cmd >>> field in struct bio from a uint8_t to a uint16_t. This will cause >>> binary compatibility problems with any 3rd party loadable modules. >>> Advice on how to handle this would be welcome. >>>=20 >>> o In the process of developing these changes, I discovered that the >>> dxfer_len paramter for scsi_ata_pass_16() was too small (uint16_t, = and >>> it needed to be uint32_t). I increased it, but that will = potentially >>> cause a binary incompatibility problem with any existing = applications >>> that use the current API via libcam. Advice on how to handle that >>> would be welcome. >>>=20 >>> If you look through the code, you'll notice that the disk_zone.h API = is >>> separate from the SCSI and ATA APIs. The intent is to allow = filesystems >>> and other consumers of the API to just talk to the disk zone API = without >>> dealing with the SCSI and ATA specifics. Another reason behind all = of this >>> is that even though the SCSI ZBC and ATA ZAC specs were developed in >>> concert, and are intended to be functionally identical, they are = still SCSI >>> and ATA. As usual, SCSI is big endian and ATA is little endian. So = to >>> present a common API to the filesystem, we give all of the zone data = back >>> in native byte order, regardless of the underlying device protocol. >>>=20 >>> Another thing to note is the extensive use of ATA passthrough in the = da(4) >>> driver. This is necessary because the SCSI SAT (SCSI to ATA = Translation) >>> specification has not yet caught up with translating SCSI zone = commands >>> (ZBC) to ATA zone commands (ZAC). So, until the spec is updated and = LSI >>> and other vendors update their SCSI to ATA translation layers, we'll = have >>> to use the ATA version of the commands when talking to ATA drives = via SAS >>> controllers. >>>=20 >>> I have only tested the code so far with Seagate SATA Drive Managed = and Host >>> Aware drives. I would appreciate testing with any drives. (And = testing to >>> make sure that the patches don't cause problems with existing = hardware.) >>> Right now, all you can really do is manage the zones manually using >>> camcontrol(8) or zonectl(8). Automatic management will come with = the ZFS >>> changes. (Or changes to other filesysems if people want to do it.) >>>=20 >>> If you have a SATA Host Aware drive, in theory camcontrol(8) should = allow >>> you to manage the drive if you have it attached to a SATA = controller. >>>=20 >>> Here is an example of some of the commands. >>>=20 >>> Get general zoning information: >>>=20 >>> [root@sm4u-1 ~]# zonectl -c params -d /dev/da21 >>> Zone Mode: Host Aware >>> Command support: Report Zones, Open, Close, Finish, Reset Write = Pointer >>> Unrestricted Read in Sequential Write Required Zone (URSWRZ): No >>> Optimal Number of Open Sequential Write Preferred Zones: 128 >>> Optimal Number of Non-Sequentially Written Sequential Write = Preferred Zones: 8 >>> Maximum Number of Open Sequential Write Required Zones: Unlimited >>>=20 >>> Look at information from the da(4) driver: >>>=20 >>> [root@sm4u-1 ~]# sysctl kern.cam.da.21 >>> kern.cam.da.21.delete_method: NONE >>> kern.cam.da.21.delete_max: 1081344 >>> kern.cam.da.21.minimum_cmd_size: 6 >>> kern.cam.da.21.sort_io_queue: -1 >>> kern.cam.da.21.zone_mode: Host Aware >>> kern.cam.da.21.zone_support: Report Zones, Open, Close, Finish, = Reset Write Pointer >>> kern.cam.da.21.optimal_seq_zones: 128 >>> kern.cam.da.21.optimal_nonseq_zones: 8 >>> kern.cam.da.21.max_seq_zones: 4294967295 >>> kern.cam.da.21.error_inject: 0 >>>=20 >>> Display all of the zones with zonectl(8): >>>=20 >>> [root@sm4u-1 ~]# zonectl -d /dev/da21 -c rz >>> 29809 zones, Maximum LBA 0x3a3812aaf (15628053167) >>> Zone lengths and types may vary >>> Start LBA Length WP LBA Zone Type Condition = Sequential Reset >>> 0, 524288, 0x80000, Conventional, NWP, = Sequential, No Reset Needed >>> 0x80000, 524288, 0x100000, Conventional, NWP, = Sequential, No Reset Needed >>> 0x100000, 524288, 0x180000, Conventional, NWP, = Sequential, No Reset Needed >>> 0x180000, 524288, 0x200000, Conventional, NWP, = Sequential, No Reset Needed >>> 0x200000, 524288, 0x280000, Conventional, NWP, = Sequential, No Reset Needed >>> 0x280000, 524288, 0x300000, Conventional, NWP, = Sequential, No Reset Needed >>> 0x300000, 524288, 0x380000, Conventional, NWP, = Sequential, No Reset Needed >>> 0x380000, 524288, 0x400000, Conventional, NWP, = Sequential, No Reset Needed >>> 0x400000, 524288, 0x480000, Conventional, NWP, = Sequential, No Reset Needed >>> 0x480000, 524288, 0x500000, Conventional, NWP, = Sequential, No Reset Needed >>> 0x500000, 524288, 0x580000, Conventional, NWP, = Sequential, No Reset Needed >>> 0x580000, 524288, 0x600000, Conventional, NWP, = Sequential, No Reset Needed >>> 0x600000, 524288, 0x680000, Conventional, NWP, = Sequential, No Reset Needed >>> 0x680000, 524288, 0x700000, Conventional, NWP, = Sequential, No Reset Needed >>> 0x700000, 524288, 0x780000, Conventional, NWP, = Sequential, No Reset Needed >>> [ ... ] >>> 0x1f00000, 524288, 0x1f80000, Conventional, NWP, = Sequential, No Reset Needed >>> 0x1f80000, 524288, 0x2000000, Conventional, NWP, = Sequential, No Reset Needed >>> 0x2000000, 524288, 0x2080000, Seq Preferred, Full, = Sequential, No Reset Needed >>> 0x2080000, 524288, 0x2100000, Seq Preferred, Full, = Sequential, No Reset Needed >>> 0x2100000, 524288, 0x2180000, Seq Preferred, Full, = Sequential, No Reset Needed >>> 0x2180000, 524288, 0x2200000, Seq Preferred, Full, = Sequential, No Reset Needed >>> 0x2200000, 524288, 0x2280000, Seq Preferred, Full, = Sequential, No Reset Needed >>> 0x2280000, 524288, 0x2300000, Seq Preferred, Full, = Sequential, No Reset Needed >>> [ ... ] >>>=20 >>> Use camcontrol zone to reset the write pointer for the first = shingled zone >>> listed above: >>>=20 >>> [root@sm4u-1 ~]# camcontrol zone da21 -v -c rwp -l 0x2000000 >>>=20 >>> Use camcontrol zone to ask the drive to report empty zones: >>>=20 >>> [root@sm4u-1 ~]# camcontrol zone da21 -v -c rz -o empty >>> 1 zones, Maximum LBA 0x3a3812aaf (15628053167) >>> Zone lengths and types may vary >>> Start LBA Length WP LBA Zone Type Condition = Sequential Reset >>> 0x2000000, 524288, 0x2000000, Seq Preferred, Empty, = Sequential, No Reset Needed >>>=20 >>> Get information on a Host Aware drive: >>>=20 >>> root@sm4u-1 ~]# diskinfo -v da21 >>> da21 >>> 512 # sectorsize >>> 8001563222016 # mediasize in bytes (7.3T) >>> 15628053168 # mediasize in sectors >>> 4096 # stripesize >>> 0 # stripeoffset >>> 972801 # Cylinders according to firmware. >>> 255 # Heads according to firmware. >>> 63 # Sectors according to firmware. >>> Z84008NY # Disk ident. >>> enc@5003048001f311fd/elmtype@array_device/slot@22 # = Physical path >>> Host Aware # Zone Mode >>>=20 >>> Get information on a drive managed drive: >>>=20 >>> [root@sm4u-1 ~]# diskinfo -v da20 >>> da20 >>> 512 # sectorsize >>> 8001563222016 # mediasize in bytes (7.3T) >>> 15628053168 # mediasize in sectors >>> 4096 # stripesize >>> 0 # stripeoffset >>> 972801 # Cylinders according to firmware. >>> 255 # Heads according to firmware. >>> 63 # Sectors according to firmware. >>> Z8405938 # Disk ident. >>> enc@5003048001f311fd/elmtype@array_device/slot@21 # = Physical path >>> Drive Managed # Zone Mode >>>=20 >>> Get information on a non-zoned drive: >>>=20 >>> [root@sm4u-1 ~]# diskinfo -v da4 >>> da4 >>> 512 # sectorsize >>> 100030242816 # mediasize in bytes (93G) >>> 195371568 # mediasize in sectors >>> 0 # stripesize >>> 0 # stripeoffset >>> 12161 # Cylinders according to firmware. >>> 255 # Heads according to firmware. >>> 63 # Sectors according to firmware. >>> 124903574F36 # Disk ident. >>> enc@5003048001f311fd/elmtype@array_device/slot@5 # = Physical path >>> Not Zoned # Zone Mode >>>=20 >>> Testing and comments are welcome. >>>=20 >>> Thanks, >>>=20 >>> Ken >>> --=20 >>> Kenneth Merry >>> ken@FreeBSD.ORG >>=20 >> --=20 >> Kenneth Merry >> ken@FreeBSD.ORG >=20 > --=20 > Kenneth Merry > ken@FreeBSD.ORG > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to = "freebsd-scsi-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Wed Mar 2 05:03:02 2016 Return-Path: Delivered-To: freebsd-current@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 54E23AC0DB9; Wed, 2 Mar 2016 05:03:02 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 18D441FE6; Wed, 2 Mar 2016 05:03:01 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1aayw6-000jdN-Uf>; Wed, 02 Mar 2016 06:02:58 +0100 Received: from x5ce1089a.dyn.telefonica.de ([92.225.8.154] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1aayw6-001f9a-LO>; Wed, 02 Mar 2016 06:02:58 +0100 Date: Wed, 2 Mar 2016 06:02:43 +0100 From: "O. Hartmann" To: FreeBSD CURRENT , FreeBSD CURRENT , FreeBSD Questions Subject: mounting CIFS share (tcp/445) with FreeBSD and mount_smbfs(8) Message-ID: <20160302060243.518568d7.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/.X=WLKyueDJLSxNF_XQhZxr"; protocol="application/pgp-signature" X-Originating-IP: 92.225.8.154 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 05:03:02 -0000 --Sig_/.X=WLKyueDJLSxNF_XQhZxr Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello list. I need to mount a CIFS share from windows server 2012 r2 via CIFS, tcp/445 = as NetBIOS service (tcp/139) has been deprecated due to serious vulnerability issues.= =20 Until the disabling of NetBIOS and tcp/139 we used successfully autofs and = mount_smbfs. this is no longer working. I tried to force autofs/mount_smbfs to bind to p= ort 445 on the server via ://@xxx.xxx.xxx.xxx:445/sharename, but this doesn't work. Trying to mount a share from a samba 4.3 server (FreeBSD CURRENT, net/samba= 43, both most recent sources), where I configured samba_server via smb ports =3D 445 to u= se port tcp 445 only and only SMB2 and SMB3 (server min protocol =3D SMB2) protocols via th= e following command: mount_smbfs -I xxx.xxx.xxx.xxx -U a_user -W \ WORKGROUP //a_user@xxx.xxx.xxx.xxx:445/sharename /mnt results in the error mount_smbfs: unable to open connection: syserr =3D RPC struct is bad Setting "smb ports =3D 139,445" and "server min protocol =3D NT1" seems to = work, the share can be bound, but this is SMB over tcp/139 and not CIFS. I desperately need CIFS and I need tcp/445 since tcp/139 is from now on fir= ewalled.=20 So: what do I miss here? Kind regards and thank you in advance, O. Hartmann P.S. Please CC me --Sig_/.X=WLKyueDJLSxNF_XQhZxr Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW1nPzAAoJEOgBcD7A/5N8YD0IAOQ0brQ+riue9ecYB8Ps3RoU Or+gylwEe/WjQnBIb4CenJNf9cXT4JgPHDbF8EYIjQy8bI4G2Z5Luauz4QnYdSD7 tsmCgKLRckiQ2AJrP/aMBA50Mx6i4q6jzRhIKTYVskwysgChM/b+rU6NPohh6wTR I3VMUdeIcOCwcy4dFwczNC15s2LpvIJmCadmU9LStyih1ZPFvawOe6X/wQN0IN53 I8L2w/LRis8FzWSqM//LOwwZHK0jgdouXBRfPja+UnP1m6sGsuSQ6UgLemcSLdl4 gmGorbHH+mEbLY2gkIUOWXVu6grnHdPb55EB4fSjzHOEznUjwPvHYG/ATZTBA6c= =YXhO -----END PGP SIGNATURE----- --Sig_/.X=WLKyueDJLSxNF_XQhZxr-- From owner-freebsd-current@freebsd.org Wed Mar 2 06:27:48 2016 Return-Path: Delivered-To: freebsd-current@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 B6DCEAC1951; Wed, 2 Mar 2016 06:27:48 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (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 80F7B138F; Wed, 2 Mar 2016 06:27:48 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1ab0G9-00041A-So; Wed, 02 Mar 2016 07:27:45 +0100 Date: Wed, 2 Mar 2016 07:27:45 +0100 From: Kurt Jaeger To: John Baldwin Cc: freebsd-current@freebsd.org, freebsd-emulation@freebsd.org Subject: Re: SVN r296272 breaks virtualbox Message-ID: <20160302062745.GD79128@home.opsec.eu> References: <56D617D1.5040209@protected-networks.net> <20160302004206.5bc6e0b3@nonamehost.local> <76770847.2GZvgBdTxv@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76770847.2GZvgBdTxv@ralph.baldwin.cx> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 06:27:48 -0000 Hi! > > > The removal of "taskqueue_enqueue_fast" breaks the virtualbox kmods: [...] > Then the port needs to be patched? It's been using an API deprecated > for the last 15 years. A simple s/taskqueue_enqueue_fast/taskqueue_enqueue/ > will fix it. A patch is possible if a new __FreeBSD_version is created for that API. Who can do that ? -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-current@freebsd.org Wed Mar 2 07:06:37 2016 Return-Path: Delivered-To: freebsd-current@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 1FC4FAC059F; Wed, 2 Mar 2016 07:06:37 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 E5B1D1491; Wed, 2 Mar 2016 07:06:36 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: by mail-ig0-x233.google.com with SMTP id y8so38957613igp.0; Tue, 01 Mar 2016 23:06:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vYfw764g9zm543rLanFjCllthg3Gjvajc1EnH04c/LI=; b=pQBJRINC1vMg/MXDLm5pkwxpDk+Rq2mHKEVdi/GtW9GJ8DIw9DmdwfRzGfGz3yFZLu wZ/w3rtUoGY9J/fsTG0pRoF/q2exYCvhdyTp0+hu4UL18ZjozgjtvfxzuMo7rY504/81 iE45LF+kRSyjBgVe+UL1qo66sFxmIIW1oZuuADcER8ls+3XPL0r3qHO1pc2zIB2ExEWm vyRF892Vxs6g/aRGFHkFaEwL474xn5lyXx7WlNyYpOWfOPP2I8KUUj7jR5drHaDAqsyw y8JXjX3MyR0q46AyISJbyQT8PmG030ZbT8ykQOIIXgk7qAlSe4j5NNewjA8rhl3vxCQr Du6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vYfw764g9zm543rLanFjCllthg3Gjvajc1EnH04c/LI=; b=PiRG8+EknVITIGfryedKad6UtIegyRADiI3tp4CYUYUXsEo/z1dx8fG9OAR6Pzbc7Q PupOfbWn5ip7ney87q/WUusDo6R9MexxNqcrKqb2Cgl3c55Sb/oBx7Yjajk4foAFxYFf FwwXcOP9NHts+q4C6S3vx+SS2FlNB8Xu1PEcThjhPNsAwaqx8wvltUnCKbEbevk2ojVa Cvbr+fXi488sUojZwUFytBD4WJbzAd/MHbOqgsl20KuDlcNw84CvgatDkzWMf9hFUB+N Rf6NE/DUjO35lcKvlLtQ3LQB7dsD/DZn/trIfIr6F7f6CytxXFBEu9OwRdF63Byg9QRM THew== X-Gm-Message-State: AD7BkJLSAdk4Ww06aKZJg9uczEe2bV3D4WbqD2iyNtVsFJh/aKyK09PdQMshnuRmOIFO9ur7aeC1bULlcUQBQQ== X-Received: by 10.50.98.74 with SMTP id eg10mr3050079igb.17.1456902396174; Tue, 01 Mar 2016 23:06:36 -0800 (PST) MIME-Version: 1.0 References: <56D617D1.5040209@protected-networks.net> <20160302004206.5bc6e0b3@nonamehost.local> <76770847.2GZvgBdTxv@ralph.baldwin.cx> <20160302062745.GD79128@home.opsec.eu> In-Reply-To: <20160302062745.GD79128@home.opsec.eu> From: Howard Su Date: Wed, 02 Mar 2016 07:06:26 +0000 Message-ID: Subject: Re: SVN r296272 breaks virtualbox To: Kurt Jaeger , John Baldwin Cc: freebsd-current@freebsd.org, freebsd-emulation@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 07:06:37 -0000 On Tue, Mar 1, 2016 at 10:28 PM Kurt Jaeger wrote: > Hi! > > > > > The removal of "taskqueue_enqueue_fast" breaks the virtualbox kmods: > [...] > > Then the port needs to be patched? It's been using an API deprecated > > for the last 15 years. A simple > s/taskqueue_enqueue_fast/taskqueue_enqueue/ > > will fix it. > > A patch is possible if a new __FreeBSD_version is created for that > API. Who can do that ? > There is no version pump and it is not needed. r296272 didn't have any behavior change. binary compatible is kept as well. And taskqueue_enqueue_fast should and is able to be replaced with taskqueue_enqueue long time ago.Blind replace taskqueue_enqueue_fast with taskqueue_enqueue is enough. -Howard > > -- > pi@opsec.eu +49 171 3101372 4 years to > go ! > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Wed Mar 2 08:16:25 2016 Return-Path: Delivered-To: freebsd-current@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 C62F2ABF334; Wed, 2 Mar 2016 08:16:25 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::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 4D04E12D5; Wed, 2 Mar 2016 08:16:25 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: by mail-lb0-x22d.google.com with SMTP id of3so113418959lbc.1; Wed, 02 Mar 2016 00:16:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Vsa7PwwXK1TRqz3Lht3bqB7dr0BFbftoAk4iimzlRC8=; b=Rh4sgwuKyY+q7iomuOgeEtzrOD7HkWmfxK7VEwh8YDmhC+rD4nsiLalrtN11Ut+eNu Na2M+lU8dN/tACH6Fx+y/vgods4RVr8wk91szLF+BCqffonrZoe0EMi1XE3KZqgiaFkS imBCbIeSgzIUe3Rs/YTpGFs46RbjU8cQuY11bTMoEFFquZBScWWXOEnJS48YVzlfSvL1 DwVqBWn5x7TbWutvniTRXSBQc5UlAYYKJR8/vwnOTOHopKXhaQfK8bh6cZYSNZCiYx7a G40l8SRNFHQOMlQcVdK9aI9jAxo99yk30JbC9ZY+y9D9/8tW9ayudHTwtwCUEme8JzJB JRhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Vsa7PwwXK1TRqz3Lht3bqB7dr0BFbftoAk4iimzlRC8=; b=IviNvulNGzXTjlQz5JB7gnO5uLjyJ8UYYFpap93JFuKZpNMumnHrf/r+J4tS+auBtp hBZqBCFT8DXCJp800CMoQEGS6RKgenmt08zVU28q80r550f3fIerJwaTPI8kR/7bjz1+ rPF+eAdGSheSpQwHBw00EzHhEN6Wa0z56PAG3OFr65ClW4NdBkA5TZ6JQZhBPClbldEv LC3bB3p28dRMSIi62yN3T4t1kmgnesYR4M4Q424/W/yVCQHntqtLGRFp+NT965dlcJH9 vFrjQMtxLHfa/0mqSvd+20tBhdUE94IQZXrzRY3tluy1dYa6fiiugEvXft9YDHRnPJgk mxKA== X-Gm-Message-State: AD7BkJKCMHKF7udzBLmMtpLxA9G9iTH/mMoGCxNt+/lc9Mtz8B9WQNGHrHh3pfT68mymOw== X-Received: by 10.112.235.71 with SMTP id uk7mr9301370lbc.39.1456906583190; Wed, 02 Mar 2016 00:16:23 -0800 (PST) Received: from localhost ([46.148.229.244]) by smtp.gmail.com with ESMTPSA id cc7sm5398018lbd.11.2016.03.02.00.16.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Mar 2016 00:16:22 -0800 (PST) Date: Wed, 2 Mar 2016 11:16:21 +0300 From: Vladimir Zakharov To: Michael Butler Cc: freebsd-current , "freebsd-emulation@freebsd.org" Subject: Re: SVN r296272 breaks virtualbox Message-ID: <20160302081621.GA29906@vzakharov> References: <56D617D1.5040209@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <56D617D1.5040209@protected-networks.net> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-PGP-Key: http://vzakharov.ru/pubkey.asc User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 08:16:25 -0000 On Tue, Mar 01, 2016, Michael Butler wrote: > The removal of "taskqueue_enqueue_fast" breaks the virtualbox kmods: > > Mar 1 16:54:36 toshi kernel: vboxdrv: fAsync=0 offMin=0x914 offMax=0x151c > Mar 1 16:54:36 toshi kernel: link_elf_obj: symbol > taskqueue_enqueue_fast undefined > Mar 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type > Mar 1 16:54:36 toshi kernel: link_elf_obj: symbol > taskqueue_enqueue_fast undefined > Mar 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type > Mar 1 16:54:36 toshi kernel: KLD vboxnetadp.ko: depends on vboxnetflt - > not available or version mismatch > Mar 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type Attached patch for emulators/virtualbox-ose and rebuilding virtualbox-ose and virtualbox-ose-kmod fixed problem for me. ======================= --- files/patch-src-VBox-HostDrivers-VBoxNetFlt-freebsd-VBoxNetFlt-freebsd.c.orig 2016-03-02 10:15:39.814893000 +0300 +++ files/patch-src-VBox-HostDrivers-VBoxNetFlt-freebsd-VBoxNetFlt-freebsd.c 2016-03-02 10:16:39.070847000 +0300 @@ -1,10 +1,5 @@ -Add VLAN trunking support to vboxnetflt - -See: http://lists.freebsd.org/pipermail/freebsd-emulation/2012-April/009698.html -See: http://lists.freebsd.org/pipermail/freebsd-emulation/2013-May/010605.html -Submitted by: Landon J Fuller ---- ./src/VBox/HostDrivers/VBoxNetFlt/freebsd/VBoxNetFlt-freebsd.c.orig 2013-04-12 06:38:11.000000000 -0400 -+++ ./src/VBox/HostDrivers/VBoxNetFlt/freebsd/VBoxNetFlt-freebsd.c 2013-05-25 20:14:52.152180452 -0400 +--- src/VBox/HostDrivers/VBoxNetFlt/freebsd/VBoxNetFlt-freebsd.c.orig 2016-01-19 22:18:38.000000000 +0300 ++++ src/VBox/HostDrivers/VBoxNetFlt/freebsd/VBoxNetFlt-freebsd.c 2016-03-02 10:10:21.181922000 +0300 @@ -51,6 +51,7 @@ #include #include @@ -13,6 +8,24 @@ #include #include +@@ -369,7 +370,7 @@ + mtx_lock_spin(&pThis->u.s.inq.ifq_mtx); + _IF_ENQUEUE(&pThis->u.s.inq, m); + mtx_unlock_spin(&pThis->u.s.inq.ifq_mtx); +- taskqueue_enqueue_fast(taskqueue_fast, &pThis->u.s.tskin); ++ taskqueue_enqueue(taskqueue_fast, &pThis->u.s.tskin); + } + /* + * Handle mbufs on the outgoing hook, frames going to the interface +@@ -387,7 +388,7 @@ + mtx_lock_spin(&pThis->u.s.outq.ifq_mtx); + _IF_ENQUEUE(&pThis->u.s.outq, m); + mtx_unlock_spin(&pThis->u.s.outq.ifq_mtx); +- taskqueue_enqueue_fast(taskqueue_fast, &pThis->u.s.tskout); ++ taskqueue_enqueue(taskqueue_fast, &pThis->u.s.tskout); + } + else + { @@ -427,6 +428,8 @@ struct ifnet *ifp = pThis->u.s.ifp; unsigned int cSegs = 0; ======================= -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra From owner-freebsd-current@freebsd.org Wed Mar 2 10:10:20 2016 Return-Path: Delivered-To: freebsd-current@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 01960AC0AF9 for ; Wed, 2 Mar 2016 10:10:20 +0000 (UTC) (envelope-from mail@m.jwh.me.uk) Received: from eva.tinkyfi.com (eva.tinkyfi.com [107.191.63.190]) by mx1.freebsd.org (Postfix) with ESMTP id C415F1435; Wed, 2 Mar 2016 10:10:19 +0000 (UTC) (envelope-from mail@m.jwh.me.uk) Received: from [172.21.88.129] (cpc82705-staf9-2-0-cust342.3-1.cable.virginm.net [81.108.23.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mail@m.jwh.me.uk) by eva.tinkyfi.com (Postfix) with ESMTPSA id 3qFWKc5YS5z5Hj9; Wed, 2 Mar 2016 10:10:12 +0000 (UTC) Subject: Re: Bay Trail 32bit UEFI To: "Lundberg, Johannes" , John Baldwin References: <56D29AF6.50401@m.jwh.me.uk> <4073395.HnTjdCHcSr@ralph.baldwin.cx> Cc: FreeBSD Current From: Joe Holden Message-ID: <56D6BC03.2040508@m.jwh.me.uk> Date: Wed, 2 Mar 2016 10:10:11 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 10:10:20 -0000 On 02/03/2016 01:45, Lundberg, Johannes wrote: > CherryTrail devices/boards with 64bit UEFI are already out. Upgrading > the hardware is one solution (I did). > I'm thinking of the sticks etc, they all have 32bit UEFI and no CSM/legacy boot, but have 64bit cpus > I never did try FreeBSD on BayTrail but for running Linux on BayTrail I > used special built Grub that was 32bit but could load 64bit OS. Could > this kind of Grub boot a 64bit FreeBSD, I wonder? > I looked at this but honestly it looked like a giant nightmare - I did get grub loading on a test platform (tablet, for display etc) but didn't manage to make it boot anything > > On Tue, Mar 1, 2016 at 5:20 PM, John Baldwin > wrote: > > On Sunday, February 28, 2016 07:00:06 AM Joe Holden wrote: > > Hi all, > > > > Apologies if this is the wrong list... > > > > Is there any plan to support booting FreeBSD on 32bit UEFI systems (with > > or without 64bit kernel/userland)? Obviously there is no i386 efi loader > > currently so neither is possible... > > I don't think anyone is actively working on it. I think it shouldn't be > that much work once the i386 loader is resurrected. The i386 kernel > just > needs to use the EFI memory map and I think the rest of it should > generally > just work. > > -- > John Baldwin > _______________________________________________ > freebsd-current@freebsd.org > mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org > " From owner-freebsd-current@freebsd.org Wed Mar 2 12:18:22 2016 Return-Path: Delivered-To: freebsd-current@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 CB65AAC12A6 for ; Wed, 2 Mar 2016 12:18:22 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD01E1589 for ; Wed, 2 Mar 2016 12:18:22 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=67rzpL6mJGG+dspm3x1XW8XqITfTLLVIur7StwXBcr8=; b=n582u3lOyxpr55yRFfzLGm7M6O cVIXbyxNzRxub7ZGvnQJP1mckiHrYY05jA9R0tYNDKs7y57PEyPgAe3HOw+PUYffkMWOcsrGEIjML WUVZgtraL7h4yvGHBo/ABxebgoNqkkR0k19Jrv895iechNV693SBB5W5+v+kYXP0cZRM=; Received: from [2605:6000:ec17:203:ed2:92ff:fe96:98a3] (port=56585 helo=trivet.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1ab5jR-000D6L-8y for freebsd-current@freebsd.org; Wed, 02 Mar 2016 06:18:21 -0600 Date: Wed, 2 Mar 2016 06:18:19 -0600 From: Larry Rosenman To: freebsd-current@freebsd.org Subject: random ZFS panic... Message-ID: <20160302121819.GB1499@trivet.lerctr.org> Mail-Followup-To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Score: -1.0 (-) X-LERCTR-Spam-Score: -1.0 (-) X-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 X-LERCTR-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 12:18:23 -0000 Was rebooting my laptop, and got the following: trivet dumped core - see /var/crash/vmcore.0 Wed Mar 2 06:09:19 CST 2016 FreeBSD trivet 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r296287: Tue Mar 1 19:13:37 CST 2016 root@trivet:/usr/obj/usr/src/sys/GENERIC amd64 panic: from debugger GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: <118>. <118>Terminated <118>Mar 2 06:07:22 trivet syslogd: exiting on signal 15 <5>wlan0: link state changed to DOWN Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 0 0 done All buffers synced. lock order reversal: 1st 0xfffff80012855d50 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1222 2nd 0xfffff800128557c8 zfs_gfs (zfs_gfs) @ /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/gfs.c:494 stack backtrace: #0 0xffffffff80a825a0 at witness_debugger+0x70 #1 0xffffffff80a824a1 at witness_checkorder+0xe71 #2 0xffffffff80a00a6b at __lockmgr_args+0xd3b #3 0xffffffff80ace2bc at vop_stdlock+0x3c #4 0xffffffff80fcb010 at VOP_LOCK1_APV+0x100 #5 0xffffffff80aeef9a at _vn_lock+0x9a #6 0xffffffff820c8b13 at gfs_file_create+0x73 #7 0xffffffff820c8bbd at gfs_dir_create+0x1d #8 0xffffffff82191f57 at zfsctl_mknode_snapdir+0x47 #9 0xffffffff820c9135 at gfs_dir_lookup+0x185 #10 0xffffffff820c961d at gfs_vop_lookup+0x1d #11 0xffffffff82190f75 at zfsctl_root_lookup+0xf5 #12 0xffffffff82191e13 at zfsctl_umount_snapshots+0x83 #13 0xffffffff821aacfb at zfs_umount+0x7b #14 0xffffffff80ad7c70 at dounmount+0x530 #15 0xffffffff80ae127b at vfs_unmountall+0x6b #16 0xffffffff80ac24f9 at bufshutdown+0x3b9 #17 0xffffffff80a26fe9 at kern_reboot+0x189 lock order reversal: 1st 0xfffff800125197c8 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1222 2nd 0xfffff8000ffbc240 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2498 stack backtrace: #0 0xffffffff80a825a0 at witness_debugger+0x70 #1 0xffffffff80a824a1 at witness_checkorder+0xe71 #2 0xffffffff80a00a6b at __lockmgr_args+0xd3b #3 0xffffffff80ace2bc at vop_stdlock+0x3c #4 0xffffffff80fcb010 at VOP_LOCK1_APV+0x100 #5 0xffffffff80aeef9a at _vn_lock+0x9a #6 0xffffffff80adf553 at vget+0x63 #7 0xffffffff808fcb4d at devfs_allocv+0xcd #8 0xffffffff808fc653 at devfs_root+0x43 #9 0xffffffff80ad7b8f at dounmount+0x44f #10 0xffffffff80ae12d4 at vfs_unmountall+0xc4 #11 0xffffffff80ac24f9 at bufshutdown+0x3b9 #12 0xffffffff80a26fe9 at kern_reboot+0x189 #13 0xffffffff80a26e03 at sys_reboot+0x3e3 #14 0xffffffff80e7a15b at amd64_syscall+0x2db #15 0xffffffff80e5926b at Xfast_syscall+0xfb Uptime: 7h20m6s Fatal trap 9: general protection fault while in kernel mode cpuid = 2; apic id = 02 instruction pointer = 0x20:0xffffffff8215369b stack pointer = 0x28:0xfffffe02329189b0 frame pointer = 0x28:0xfffffe02329189c0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (dbu_evict) Uptime: 7h20m7s Dumping 2338 out of 8050 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/zfs.ko.debug...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /usr/lib/debug//boot/kernel/opensolaris.ko.debug...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /usr/lib/debug//boot/kernel/coretemp.ko.debug...done. done. Loaded symbols for /boot/kernel/coretemp.ko Reading symbols from /boot/kernel/ichsmb.ko...Reading symbols from /usr/lib/debug//boot/kernel/ichsmb.ko.debug...done. done. Loaded symbols for /boot/kernel/ichsmb.ko Reading symbols from /boot/kernel/smbus.ko...Reading symbols from /usr/lib/debug//boot/kernel/smbus.ko.debug...done. done. Loaded symbols for /boot/kernel/smbus.ko Reading symbols from /boot/kernel/hwpmc.ko...Reading symbols from /usr/lib/debug//boot/kernel/hwpmc.ko.debug...done. done. Loaded symbols for /boot/kernel/hwpmc.ko Reading symbols from /boot/kernel/iwn135fw.ko...Reading symbols from /usr/lib/debug//boot/kernel/iwn135fw.ko.debug...done. done. Loaded symbols for /boot/kernel/iwn135fw.ko Reading symbols from /boot/kernel/aesni.ko...Reading symbols from /usr/lib/debug//boot/kernel/aesni.ko.debug...done. done. Loaded symbols for /boot/kernel/aesni.ko Reading symbols from /boot/kernel/cryptodev.ko...Reading symbols from /usr/lib/debug//boot/kernel/cryptodev.ko.debug...done. done. Loaded symbols for /boot/kernel/cryptodev.ko Reading symbols from /boot/kernel/dtraceall.ko...Reading symbols from /usr/lib/debug//boot/kernel/dtraceall.ko.debug...done. done. Loaded symbols for /boot/kernel/dtraceall.ko Reading symbols from /boot/kernel/profile.ko...Reading symbols from /usr/lib/debug//boot/kernel/profile.ko.debug...done. done. Loaded symbols for /boot/kernel/profile.ko Reading symbols from /boot/kernel/dtrace.ko...Reading symbols from /usr/lib/debug//boot/kernel/dtrace.ko.debug...done. done. Loaded symbols for /boot/kernel/dtrace.ko Reading symbols from /boot/kernel/systrace_freebsd32.ko...Reading symbols from /usr/lib/debug//boot/kernel/systrace_freebsd32.ko.debug...done. done. Loaded symbols for /boot/kernel/systrace_freebsd32.ko Reading symbols from /boot/kernel/systrace.ko...Reading symbols from /usr/lib/debug//boot/kernel/systrace.ko.debug...done. done. Loaded symbols for /boot/kernel/systrace.ko Reading symbols from /boot/kernel/sdt.ko...Reading symbols from /usr/lib/debug//boot/kernel/sdt.ko.debug...done. done. Loaded symbols for /boot/kernel/sdt.ko Reading symbols from /boot/kernel/fasttrap.ko...Reading symbols from /usr/lib/debug//boot/kernel/fasttrap.ko.debug...done. done. Loaded symbols for /boot/kernel/fasttrap.ko Reading symbols from /boot/kernel/fbt.ko...Reading symbols from /usr/lib/debug//boot/kernel/fbt.ko.debug...done. done. Loaded symbols for /boot/kernel/fbt.ko Reading symbols from /boot/kernel/dtnfscl.ko...Reading symbols from /usr/lib/debug//boot/kernel/dtnfscl.ko.debug...done. done. Loaded symbols for /boot/kernel/dtnfscl.ko Reading symbols from /boot/kernel/dtmalloc.ko...Reading symbols from /usr/lib/debug//boot/kernel/dtmalloc.ko.debug...done. done. Loaded symbols for /boot/kernel/dtmalloc.ko Reading symbols from /boot/kernel/cpuctl.ko...Reading symbols from /usr/lib/debug//boot/kernel/cpuctl.ko.debug...done. done. Loaded symbols for /boot/kernel/cpuctl.ko Reading symbols from /boot/kernel/cuse.ko...Reading symbols from /usr/lib/debug//boot/kernel/cuse.ko.debug...done. done. Loaded symbols for /boot/kernel/cuse.ko Reading symbols from /boot/kernel/ng_ubt.ko...Reading symbols from /usr/lib/debug//boot/kernel/ng_ubt.ko.debug...done. done. Loaded symbols for /boot/kernel/ng_ubt.ko Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /usr/lib/debug//boot/kernel/netgraph.ko.debug...done. done. Loaded symbols for /boot/kernel/netgraph.ko Reading symbols from /boot/kernel/ng_hci.ko...Reading symbols from /usr/lib/debug//boot/kernel/ng_hci.ko.debug...done. done. Loaded symbols for /boot/kernel/ng_hci.ko Reading symbols from /boot/kernel/ng_bluetooth.ko...Reading symbols from /usr/lib/debug//boot/kernel/ng_bluetooth.ko.debug...done. done. Loaded symbols for /boot/kernel/ng_bluetooth.ko Reading symbols from /boot/kernel/ng_l2cap.ko...Reading symbols from /usr/lib/debug//boot/kernel/ng_l2cap.ko.debug...done. done. Loaded symbols for /boot/kernel/ng_l2cap.ko Reading symbols from /boot/kernel/ng_btsocket.ko...Reading symbols from /usr/lib/debug//boot/kernel/ng_btsocket.ko.debug...done. done. Loaded symbols for /boot/kernel/ng_btsocket.ko Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from /usr/lib/debug//boot/kernel/ng_socket.ko.debug...done. done. Loaded symbols for /boot/kernel/ng_socket.ko #0 doadump (textdump=1) at pcpu.h:221 221 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:221 #1 0xffffffff80a27235 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364 #2 0xffffffff80a2780b in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:757 #3 0xffffffff80a27853 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:688 #4 0xffffffff80383887 in db_panic (addr=, have_addr=false, count=0, modif=0x0) at /usr/src/sys/ddb/db_command.c:473 #5 0xffffffff80382ebe in db_command (cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:440 #6 0xffffffff80382c54 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 #7 0xffffffff803856eb in db_trap (type=, code=0) at /usr/src/sys/ddb/db_main.c:251 #8 0xffffffff80a65773 in kdb_trap (type=9, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:654 #9 0xffffffff80e79961 in trap_fatal (frame=0xfffffe0232918900, eva=) at /usr/src/sys/amd64/amd64/trap.c:836 #10 0xffffffff80e7963a in trap (frame=) at /usr/src/sys/amd64/amd64/trap.c:203 #11 0xffffffff80e58f87 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:234 #12 0xffffffff8215369b in txg_list_member (tl=0xfffff8001221c320, p=, txg=) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c:850 #13 0xffffffff82112309 in dsl_dir_evict (dbu=0xfffff8000fedc400) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c:145 #14 0xffffffff80a75e30 in taskqueue_run_locked (queue=0xfffff80004557800) at /usr/src/sys/kern/subr_taskqueue.c:430 #15 0xffffffff80a76958 in taskqueue_thread_loop (arg=) at /usr/src/sys/kern/subr_taskqueue.c:683 #16 0xffffffff809eb474 in fork_exit ( callout=0xffffffff80a768d0 , arg=0xfffff80006b7c170, frame=0xfffffe0232918ac0) at /usr/src/sys/kern/kern_fork.c:1034 #17 0xffffffff80e594be in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:609 #18 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) Ideas? Core IS available. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 From owner-freebsd-current@freebsd.org Wed Mar 2 14:29:49 2016 Return-Path: Delivered-To: freebsd-current@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 D6E86AC09AA for ; Wed, 2 Mar 2016 14:29:49 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 9BE3A1A87 for ; Wed, 2 Mar 2016 14:29:49 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1ab7mc-003w0w-QL>; Wed, 02 Mar 2016 15:29:46 +0100 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1ab7mc-002Vgz-Fi>; Wed, 02 Mar 2016 15:29:46 +0100 Date: Wed, 2 Mar 2016 15:29:39 +0100 From: "O. Hartmann" To: "Reko Turja" Cc: "FreeBSD CURRENT" Subject: Re: mounting CIFS share (tcp/445) with FreeBSD and mount_smbfs(8) Message-ID: <20160302152939.17333d19@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <32E522F2674A4DEBBE2492D3A307A0C1@Rivendell> References: <20160301222004.4cdaafc9.ohartman@zedat.fu-berlin.de> <32E522F2674A4DEBBE2492D3A307A0C1@Rivendell> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 14:29:50 -0000 On Tue, 1 Mar 2016 23:39:22 +0200 "Reko Turja" wrote: > -----Original Message----- > From: O. Hartmann > Subject: mounting CIFS share (tcp/455) with FreeBSD and mount_smbfs(8) > > > > I need to mount a CIFS share from windows server 2012 r2 via CIFS, tcp/445 > > as NetBIOS service (tcp/139) has been deprecated due to serious > > vulnerability issues. . > > . > > . > > I desperately need CIFS and I need tcp/445 since tcp/139 is from now on > > firewalled. > > There's actually alternative available that's far more UNIX-friendly and not > depending on the SAMBA foibles. > > https://technet.microsoft.com/en-us/library/jj574143.aspx?f=255&MSPPError=-2147217396 > > Of course, you need to have admin access to the server or get the admins > enable NFS on it. > > -Reko > > (I've used the Windows NFS the other way around- FreeBSD NFS shares mounted > with on Win7.) _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Using others than CIFS is impossible, I'm dependend on existing services. Within the next forseable time port tcp/139 gets firewalled. So far I have compiled NETSMB, SMBFS, LIBMCHAIN and LIBICONV (I think the latter two are prerequests for NETSMB/SMBFS, didn't find much in the very sparse and unfinished docs for that subject!) into the kernel. I found this following the exact subject I ran into: http://agreif.blogspot.de/2014/01/blog-post.html It doesn't work with either SAMBA 4.3 or Windows Server 2012 R2. Consider the following situation. Windows/samba server has IP 10.0.0.1, it's WINS name is locus, its domain is ASUF the user is pimmel. The passowrd is in /etc/nsmb.conf, hashed: [default] charsets=utf-8:utf-8 [LOCUS:PIMMEL] address=10.0.0.1 password=$$ajdhasuih57 The, following the above instructions, the mount_smbfs(8) command would be mount_smbfs -I10.0.0.1 -Wasuf -N //pimmel@10.0.0.1:445/share /mnt If -W is fed with ASUF (all uppercase), I get a strange error: mount_smbfs: invalid local charset specification (IT4) Connecting to the SAMBA 4.3 server, and with -Wasuf, I get mount_smbfs: unable to open connection: syserr = RPC struct is bad Connectingto the Windows 2012 R2 server results in mount_smbfs: unable to open connection: syserr = Connection reset by peer First, the manpage for mount_smbfs(8) is everything else than FreeBSD standard! There is an unexplained option "-n opt". What is that? Second, CIFS over tcp/445 seems to be now very(!) common in the Windooze world - why is that fact not reflected by FreeBSD? I tried to find some explanations/manpages for "man netsmb" or "smbfs" (the kernel options), but none found :-( My interpretation of the above errors are: FreeBSD is incapable to handle CIFS over tcp/445. The above URL/site claims to have solved the problem, but it seems not true for CURRENT. From owner-freebsd-current@freebsd.org Wed Mar 2 14:51:33 2016 Return-Path: Delivered-To: freebsd-current@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 88733AC1309 for ; Wed, 2 Mar 2016 14:51:33 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward17h.cmail.yandex.net (forward17h.cmail.yandex.net [IPv6:2a02:6b8:0:f35::a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4186D198D for ; Wed, 2 Mar 2016 14:51:33 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp2h.mail.yandex.net (smtp2h.mail.yandex.net [IPv6:2a02:6b8:0:f05::116]) by forward17h.cmail.yandex.net (Yandex) with ESMTP id 13A3421A3C; Wed, 2 Mar 2016 17:51:04 +0300 (MSK) Received: from smtp2h.mail.yandex.net (localhost [127.0.0.1]) by smtp2h.mail.yandex.net (Yandex) with ESMTP id 010011703822; Wed, 2 Mar 2016 17:51:03 +0300 (MSK) Received: by smtp2h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id M9q1WazsHz-p3JKSNsY; Wed, 02 Mar 2016 17:51:03 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1456930263; bh=6h4I38l8UxeL9Gm9LEcd/a7PVBnyyOdwwVUXg3tGNZk=; h=Subject:To:References:Cc:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type; b=X+nq3p/An0WwGBGOXEFT0x5pK/mR/a9XNlfZb6NZmFoFSshpXPt9gtUrvcd984/Ds +GbUa7WiukrvsWFNzTI+wLdCgj0dJBlmUFZwomN1Uc9ZaUnVmX6DlM1DNg3xNzBVOF UJTmjIMgo1bNitBzq17WoPdn8/gbOuMnEptPEUK8= Authentication-Results: smtp2h.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-ForeignMX: US X-Yandex-Suid-Status: 1 0,1 0,1 0 Subject: Re: mounting CIFS share (tcp/445) with FreeBSD and mount_smbfs(8) To: "O. Hartmann" , Reko Turja References: <20160301222004.4cdaafc9.ohartman@zedat.fu-berlin.de> <32E522F2674A4DEBBE2492D3A307A0C1@Rivendell> <20160302152939.17333d19@freyja.zeit4.iv.bundesimmobilien.de> Cc: FreeBSD CURRENT From: "Andrey V. Elsukov" Message-ID: <56D6FD84.5020305@yandex.ru> Date: Wed, 2 Mar 2016 17:49:40 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160302152939.17333d19@freyja.zeit4.iv.bundesimmobilien.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GjViMgQUItkqRuh8ChGwHf2d0r0aSm9pi" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 14:51:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GjViMgQUItkqRuh8ChGwHf2d0r0aSm9pi Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02.03.16 17:29, O. Hartmann wrote: > My interpretation of the above errors are: FreeBSD is incapable to hand= le CIFS > over tcp/445. The above URL/site claims to have solved the problem, but= it > seems not true for CURRENT.=20 Did you try some FUSE CIFS implementations? --=20 WBR, Andrey V. Elsukov --GjViMgQUItkqRuh8ChGwHf2d0r0aSm9pi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJW1v2IAAoJEAHF6gQQyKF6tSwIALz0XSHjTpaGbC6xfq0M5nMy 9UFWxS9doNKg9vjdGqFjESmL/Bw+pfmraz/8L1uBzspqwsGHTNAFFrsjBJti0vYF DB33PPu2tb278dFKTKXpnmuWFq1S5F8ofK+wPOKOxfyME2Qs+oeDnom5v67dUEZz X/QNXmrbd7IAqC/O6tdNfeCAeG0wPQ4TWBCr2MOk3f8DyE+Fg0ysog3rjrZ5W4Ka Gt3iFVqZfdGz56QJmGgZ5kHlRtlhf7+ryGkrHxyPvGRCYA4VcxqTdMXSj87raHlM WW3s1ao0HGtXJFe+/9QbUrlOE3eASrCpKsFkbUU1AKUGEDbsUcwyEDL9u3EyLBM= =U4nR -----END PGP SIGNATURE----- --GjViMgQUItkqRuh8ChGwHf2d0r0aSm9pi-- From owner-freebsd-current@freebsd.org Wed Mar 2 15:02:18 2016 Return-Path: Delivered-To: freebsd-current@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 C8EBDAC169D for ; Wed, 2 Mar 2016 15:02:18 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from fmailer.gwdg.de (fmailer.gwdg.de [134.76.11.16]) (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 927F01EBB for ; Wed, 2 Mar 2016 15:02:18 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from um-excht-a02.um.gwdg.de ([134.76.11.222] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (Exim 4.80) (envelope-from ) id 1ab8Hw-0000ea-0j; Wed, 02 Mar 2016 16:02:08 +0100 Received: from pc028.nfv.nw-fva.de (134.76.242.1) by email.gwdg.de (134.76.9.211) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 2 Mar 2016 16:02:07 +0100 Subject: Re: mounting CIFS share (tcp/445) with FreeBSD and mount_smbfs(8) To: "O. Hartmann" References: <20160301222004.4cdaafc9.ohartman@zedat.fu-berlin.de> <32E522F2674A4DEBBE2492D3A307A0C1@Rivendell> <20160302152939.17333d19@freyja.zeit4.iv.bundesimmobilien.de> CC: Reko Turja , FreeBSD CURRENT From: Rainer Hurling Message-ID: <56D70065.2010304@gwdg.de> Date: Wed, 2 Mar 2016 16:01:57 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160302152939.17333d19@freyja.zeit4.iv.bundesimmobilien.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Level: - X-Virus-Scanned: (clean) by clamav X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 15:02:18 -0000 Hi Oliver, Am 02.03.16 um 15:29 schrieb O. Hartmann: > On Tue, 1 Mar 2016 23:39:22 +0200 > "Reko Turja" wrote: > >> -----Original Message----- >> From: O. Hartmann >> Subject: mounting CIFS share (tcp/455) with FreeBSD and mount_smbfs(8) >>> >>> I need to mount a CIFS share from windows server 2012 r2 via CIFS, tcp/445 >>> as NetBIOS service (tcp/139) has been deprecated due to serious >>> vulnerability issues. . >>> . >>> . >>> I desperately need CIFS and I need tcp/445 since tcp/139 is from now on >>> firewalled. >> >> There's actually alternative available that's far more UNIX-friendly and not >> depending on the SAMBA foibles. >> >> https://technet.microsoft.com/en-us/library/jj574143.aspx?f=255&MSPPError=-2147217396 >> >> Of course, you need to have admin access to the server or get the admins >> enable NFS on it. >> >> -Reko >> >> (I've used the Windows NFS the other way around- FreeBSD NFS shares mounted >> with on Win7.) _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > Using others than CIFS is impossible, I'm dependend on existing services. > Within the next forseable time port tcp/139 gets firewalled. > > So far I have compiled NETSMB, SMBFS, LIBMCHAIN and LIBICONV (I think the > latter two are prerequests for NETSMB/SMBFS, didn't find much in the very > sparse and unfinished docs for that subject!) into the kernel. > > I found this following the exact subject I ran into: > > http://agreif.blogspot.de/2014/01/blog-post.html > > It doesn't work with either SAMBA 4.3 or Windows Server 2012 R2. Consider the > following situation. > > Windows/samba server has IP 10.0.0.1, it's WINS name is locus, its domain is > ASUF the user is pimmel. The passowrd is in /etc/nsmb.conf, > hashed: > > > [default] > charsets=utf-8:utf-8 > > [LOCUS:PIMMEL] > address=10.0.0.1 > password=$$ajdhasuih57 > > The, following the above instructions, the mount_smbfs(8) command would be > > mount_smbfs -I10.0.0.1 -Wasuf -N //pimmel@10.0.0.1:445/share /mnt > > If -W is fed with ASUF (all uppercase), I get a strange error: > > mount_smbfs: invalid local charset specification (IT4) > > Connecting to the SAMBA 4.3 server, and with -Wasuf, I get > > mount_smbfs: unable to open connection: syserr = RPC struct is bad > > Connectingto the Windows 2012 R2 server results in > > mount_smbfs: unable to open connection: syserr = Connection reset by peer > > First, the manpage for mount_smbfs(8) is everything else than FreeBSD standard! > There is an unexplained option "-n opt". What is that? > > Second, CIFS over tcp/445 seems to be now very(!) common in the Windooze world > - why is that fact not reflected by FreeBSD? I tried to find some > explanations/manpages for "man netsmb" or "smbfs" (the kernel options), but > none found :-( > > My interpretation of the above errors are: FreeBSD is incapable to handle CIFS > over tcp/445. The above URL/site claims to have solved the problem, but it > seems not true for CURRENT. For me, the described scenario works well with base smbfs (on recent HEAD amd64). My configuration differs in some way from yours. GROUPNAME, SERVERNAME, and USERNAME should be written in capital letters (?), domainname\\username in small letters (?): # ------------------------------------------- #cat /etc/nsmb.conf ... [default] workgroup=GROUPNAME [SERVERNAME] nbns=xxx.xxx.xxx.xxx (IPv4 address) charsets=UTF-8:CP866 addr=servername.xxx.de [SERVERNAME:USERNAME] username=domainname\\username password=HASHED_PASSWORD # ------------------------------------------- My entries in /etc/fstab look like this: ... ### Mountpoints for mount_smbfs (of base system) //username@servername/dir /SMB/DIR smbfs rw,late 0 0 [and this also works with port 445:] //username@servername:445/dir /SMB/DIR smbfs rw,late 0 0 # ------------------------------------------- !!! If this was a real hashed password in your mail above, you should change it ... HTH and greetings, Rainer From owner-freebsd-current@freebsd.org Wed Mar 2 17:26:30 2016 Return-Path: Delivered-To: freebsd-current@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 738CBAC1BF3; Wed, 2 Mar 2016 17:26:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::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 550E71C96; Wed, 2 Mar 2016 17:26:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 68796B958; Wed, 2 Mar 2016 12:26:29 -0500 (EST) From: John Baldwin To: Howard Su Cc: Kurt Jaeger , freebsd-current@freebsd.org, freebsd-emulation@freebsd.org Subject: Re: SVN r296272 breaks virtualbox Date: Wed, 02 Mar 2016 09:01:34 -0800 Message-ID: <1918581.xCMVRkph0K@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <56D617D1.5040209@protected-networks.net> <20160302062745.GD79128@home.opsec.eu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 02 Mar 2016 12:26:29 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 17:26:30 -0000 On Wednesday, March 02, 2016 07:06:26 AM Howard Su wrote: > On Tue, Mar 1, 2016 at 10:28 PM Kurt Jaeger wrote: > > > Hi! > > > > > > > The removal of "taskqueue_enqueue_fast" breaks the virtualbox kmods: > > [...] > > > Then the port needs to be patched? It's been using an API deprecated > > > for the last 15 years. A simple > > s/taskqueue_enqueue_fast/taskqueue_enqueue/ > > > will fix it. > > > > A patch is possible if a new __FreeBSD_version is created for that > > API. Who can do that ? > > > There is no version pump and it is not needed. r296272 didn't have any > behavior change. binary compatible is kept as well. Actually, I broke binary compat in HEAD as 11.0 hasn't shipped yet and 11.0 won't be released for a while yet. In this case I think ripping the band-aid off is fine, especially since the replacement API has been ready for such a long time (and goes back to 7.0). -- John Baldwin From owner-freebsd-current@freebsd.org Wed Mar 2 17:26:29 2016 Return-Path: Delivered-To: freebsd-current@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 AF116AC1BF1 for ; Wed, 2 Mar 2016 17:26:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::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 907CF1C95 for ; Wed, 2 Mar 2016 17:26:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 13E2BB96B; Wed, 2 Mar 2016 12:26:28 -0500 (EST) From: John Baldwin To: "Lundberg, Johannes" Cc: FreeBSD Current , Joe Holden Subject: Re: Bay Trail 32bit UEFI Date: Wed, 02 Mar 2016 09:02:34 -0800 Message-ID: <9198708.r56Xi4muft@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <56D29AF6.50401@m.jwh.me.uk> <4073395.HnTjdCHcSr@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 02 Mar 2016 12:26:28 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 17:26:29 -0000 On Tuesday, March 01, 2016 05:45:04 PM Lundberg, Johannes wrote: > CherryTrail devices/boards with 64bit UEFI are already out. Upgrading the > hardware is one solution (I did). > > I never did try FreeBSD on BayTrail but for running Linux on BayTrail I > used special built Grub that was 32bit but could load 64bit OS. Could this > kind of Grub boot a 64bit FreeBSD, I wonder? Mmm, booting an amd64 kernel from an i386 UEFI loader would be a bit more work. OTOH, in the non-UEFI case we use an i386 loader that boots an amd64 kernel, so it isn't impossible. -- John Baldwin From owner-freebsd-current@freebsd.org Wed Mar 2 17:26:31 2016 Return-Path: Delivered-To: freebsd-current@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 B7D16AC1C0B; Wed, 2 Mar 2016 17:26:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::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 9A34B1C9E; Wed, 2 Mar 2016 17:26:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AA3E8B962; Wed, 2 Mar 2016 12:26:30 -0500 (EST) From: John Baldwin To: Kurt Jaeger Cc: freebsd-current@freebsd.org, freebsd-emulation@freebsd.org Subject: Re: SVN r296272 breaks virtualbox Date: Wed, 02 Mar 2016 08:59:51 -0800 Message-ID: <5082358.nZ96iaI1mi@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160302062745.GD79128@home.opsec.eu> References: <56D617D1.5040209@protected-networks.net> <76770847.2GZvgBdTxv@ralph.baldwin.cx> <20160302062745.GD79128@home.opsec.eu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 02 Mar 2016 12:26:30 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 17:26:31 -0000 On Wednesday, March 02, 2016 07:27:45 AM Kurt Jaeger wrote: > Hi! > > > > > The removal of "taskqueue_enqueue_fast" breaks the virtualbox kmods: > [...] > > Then the port needs to be patched? It's been using an API deprecated > > for the last 15 years. A simple s/taskqueue_enqueue_fast/taskqueue_enqueue/ > > will fix it. > > A patch is possible if a new __FreeBSD_version is created for that > API. Who can do that ? You don't need a new bump. taskqueue_enqueue has worked fine for a "fast" taskqueue since 700013, so you can use that version. OTOH, I would be surprised if VirtualBox worked on FreeBSD 6.x. -- John Baldwin From owner-freebsd-current@freebsd.org Wed Mar 2 18:12:12 2016 Return-Path: Delivered-To: freebsd-current@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 38251AC2205 for ; Wed, 2 Mar 2016 18:12:12 +0000 (UTC) (envelope-from dgilbert@interlog.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 22EA31BF6 for ; Wed, 2 Mar 2016 18:12:12 +0000 (UTC) (envelope-from dgilbert@interlog.com) Received: by mailman.ysv.freebsd.org (Postfix) id 208F4AC2202; Wed, 2 Mar 2016 18:12:12 +0000 (UTC) Delivered-To: current@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 06112AC2201; Wed, 2 Mar 2016 18:12:12 +0000 (UTC) (envelope-from dgilbert@interlog.com) Received: from smtp.infotech.no (smtp.infotech.no [82.134.31.41]) by mx1.freebsd.org (Postfix) with ESMTP id 1D8841BF2; Wed, 2 Mar 2016 18:12:10 +0000 (UTC) (envelope-from dgilbert@interlog.com) Received: from localhost (localhost [127.0.0.1]) by smtp.infotech.no (Postfix) with ESMTP id D2E7C204195; Wed, 2 Mar 2016 19:12:09 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.6 (20110518) (Debian) at infotech.no Received: from smtp.infotech.no ([127.0.0.1]) by localhost (smtp.infotech.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zP-pPFar928I; Wed, 2 Mar 2016 19:12:09 +0100 (CET) Received: from [10.7.0.18] (unknown [10.7.0.18]) by smtp.infotech.no (Postfix) with ESMTPA id A846F204192; Wed, 2 Mar 2016 19:12:08 +0100 (CET) Reply-To: dgilbert@interlog.com Subject: Re: CAM Shingled Disk support patches available References: <20151118171309.GA3564@mithlond.kdm.org> <20160118223704.GA87506@mithlond.kdm.org> <20160301224758.GA86834@mithlond.kdm.org> To: Scott Long , "Kenneth D. Merry" Cc: current@freebsd.org, scsi@freebsd.org From: Douglas Gilbert Message-ID: <56D72CF7.2040806@interlog.com> Date: Wed, 2 Mar 2016 13:12:07 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 02 Mar 2016 18:15:43 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 18:12:12 -0000 On 16-03-01 10:07 PM, Scott Long via freebsd-scsi wrote: > Hi Ken, > > I’m against changing the function signature of scsi_ata_pass_16(). Even > if you manage to get things right with symbol versioning, it still leads to > problems of code compatibility. Maybe pre-existing binaries will work, but > source code will forever have to include an #if __FreeBSD_version < > xxxxxx bit of nonsense. > > I agree that it was incorrect for dxferlen to be declared as a uint16_t. > However, the function already contains a sector count argument pair. In > theory the sector count multiplied by the sector length, both of which the > application should know in order to arrive at a sensible dxferlen, can > substitute for the dxferlen argument. If so, then we can just ignore that > argument and declare that sector_count has logical priority. > > Really though, I think that scsi_ata_pass_16() is a crummy function. If its > purpose is to implement SAT-3 12.2.2, it does an incredibly poor job at it: > > - By my count, it only covers 12 of the available 13 registers. > > - It has no 12 byte, opcode 0xa1 variant. > > - It doesn’t make any allowance for providing the response registers to the > caller on completion. Well, maybe it kinda does through a sense descriptor, > but…. it’s kinda open to vague interpretation. > > - Its use of the registers is clunky, assuming for example that you’ll only want > to fill the six LBA registers with a host-ordered 64-bit number. There are > plenty of commands that re-use sub-parts of the LBA, features, and/or sector > count registers for different things. > > I know you stated that you didn’t want to do this, but I think it’s better to start > over with a better function that has a better signature and a new name. In fact, > I think it’s better to use the existing ata_cmd and ata_res structures from > sys/cam/ata/ata_all.h, provide accessors for the multi-byte registers if needed, > provide a 12-byte compatibility, and simply the signature. Something like this: > > void scsi_ata_pass(struct ccb_scsiio *csio, u_int32_t retries, > void (*cbfcnp)(struct cam_periph *, union ccb *), > u_int32_t flags, u_int8_t tag_action, > struct ata_cmd *cmd, struct ata_res *res, > u_int8_t *data_ptr, u_int32_t dxfer_len, > u_int8_t *data_ptr, u_int16_t dxfer_len, > u_int8_t sense_len, u_int32_t timeout); uint32_t and uint8_t please :-) For the pendants: https://www.freebsd.org/cgi/man.cgi?query=style&sektion=9 "The project is slowly moving to use the ISO/IEC 9899:1999 (``ISO C99'') unsigned integer identifiers of the form uintXX_t in preference to the older BSD-style integer identifiers of the form u_intXX_t. New code should use the former, and old code should be converted to the new form if other major work is being done in that area and there is no overriding reason to prefer the older BSD-style. Like white-space commits, care should be taken in making uintXX_t only commits." The Linux kernel ain't much better with u8, u16 and u32 typedefs everywhere. Doug Gilbert > To differentiate between the 12 and 16 byte variants, you’d look at the > AP_EXTEND flag in the protocol field. Btw, the handling of that flag is > inconsistent in the implementation of the existing scsi_ata_pass_16(). If > the caller providse an ata_res pointer then it gets filled on completion, > otherwise the caller does its best to look at 12.2.2.6 and extract what it > can from the sense descriptor. > > So my proposal is to create a new scsi_ata_pass and deprecate but not remove > scsi_ata_pass_16. Tell people that if they need to use it, dxfer_len is going to > have lower priority than sector_count/sector_count_exp if the latter multiply to > more than 65535. > > Scott > > > >> On Mar 1, 2016, at 3:47 PM, Kenneth D. Merry wrote: >> >> I have a new set of SMR patches available. (See the original message below >> for a more detailed description of what these patches do.) >> >> The primary change is to add library versioning to libcam so that we can >> change the function prototype of scsi_ata_pass_16() in a way that won't >> break existing binaries. >> >> If someone more familiar with library versioning wants to review this, I'd >> appreciate it. >> >> The patches are here: >> >> FreeBSD/head, as of SVN revision 296278 >> >> https://people.freebsd.org/~ken/cam_smr.head.20160301.1.txt >> >> stable/10, as of SVN revision 296248 >> >> https://people.freebsd.org/~ken/cam_smr.stable10.20160301.1.txt >> >> (Note that although there is a stable/10 version of the patches, I'm not >> planning to merge them to stable/10 because of the change to struct bio. I >> can't really figure out a good way to make that backward compatible. If >> there is consensus that breaking it is fine because it isn't a user API, >> then that may be another story.) >> >> The problem is that the existing, in-tree version of scsi_ata_pass_16() has >> a dxfer_len argument that is a uint16_t. That restricts transfer sizes to >> 64KB. So, we need to update it to allow larger than 64K transfers. I >> could just create a new function, but I'd rather just retire the broken >> version. >> >> The intent here is that: >> >> 1. Binaries built against the old version of libcam, before versioning was >> turned on, will get the old version of the scsi_ata_pass_16() function with >> a uint16_t dxfer_len. >> >> 2. Binaries built against the new version of libcam will get the new >> version of the scsi_ata_pass_16() function with a uint32_t dxfer_len. >> >> I've tested this, and it appears to work, but I'm not 100% certain this is >> all correct. I looked at Dan Eischen's description of symbol versioning >> here: >> >> https://people.freebsd.org/~deischen/symver/freebsd_versioning.txt >> >> And it looks like the actual implementation is a little different than what >> is described there. I looked around the tree, and didn't see anything that >> is obviously exactly like what I'm trying to do here. >> >> So, what I did is as follows: >> >> 1. For the kernel, the only change is to switch the dxfer_len argument from >> a uint16_t to a uint32_t. >> >> 2. For userland, in scsi_all.c, there are now two versions of >> scsi_ata_pass_16 -- _ver1 and _ver2. _ver1 is aliased to >> scsi_ata_pass_16() for FBSD_1.3 using __sym_compat(). _ver2 is aliased to >> scsi_ata_pass_16() for FBSD_1.4 using __sym_default(). >> >> 3. In lib/libcam/Versions.def, I defined FBSD_1.3 and FBSD_1.4, which >> depends on FBSD_1.3. >> >> 4. In lib/libcam/Symbol.map, I pulled out all of the functions defined in >> libcam, sorted them, and defined them in FBSD_1.3. I moved >> scsi_ata_pass_16() to FBSD_1.4. (According to the freebsd_versioning.txt >> paper linked above, I should have been able to have scsi_ata_pass_16() in >> both FBSD_1.3 and FBSD_1.4, but that isn't the case in practice.) >> >> In testing an old binary (linked against libcam without symbol versioning) >> against a new libcam (with symbol versioning), the old version of the >> function appears to be used. With a new binary, the new version of the >> function appears to be used. >> >> So it looks like things work as intended, but I don't fully trust my >> understanding here. So, if someone could take a look at the changes, I'd >> appreciate it. >> >> In particular, I have a few questions: >> >> 1. If this change to scsi_ata_pass_16() gets merged to stable/10 (apart >> from the larger SMR changes), what should be done with the libcam library >> version? >> >> 2. Are 1.3 and 1.4 the proper versions to use? >> >> 3. If we make additional CAM helper function library changes, when do the >> versions get bumped? i.e., is this an opportunity to look for other >> library functions with issues and make changes if possible? >> >> 4. When you're going from an unversioned library to a versioned library, >> which version of a function gets linked in to a binary linked to the >> unversioned library when you run it against a versioned library? In other >> words, what is supposed to happen in the test scenario I tried above, and >> am I really seeing what is supposed to happen? >> >> Thanks, >> >> Ken >> >> On Mon, Jan 18, 2016 at 17:37:04 -0500, Kenneth D. Merry wrote: >>> I have a new set of SMR patches available. See below for the full >>> explanation. >>> >>> The primary change here is that I have added SMR support to the ada(4) >>> driver. I spent some time considering whether to try to make the da(4) and >>> ada(4) probe infrastructure somewhat common, but in the end concluded it >>> would be too involved with not enough code reduction (if any) in the end. >>> >>> So, although the ideas are similar, the probe logic is separate. >>> >>> Note that NCQ support for SMR commands (Report Zones, Reset Write Pointer, >>> etc.) for SATA protocol shingled drives isn't active. For both the da(4) >>> and ada(4) driver this is for lack of a way to plumb the ATA Auxiliary >>> register down to the drive. >>> >>> In the ada(4) case, we need to add the register to struct ccb_ataio and >>> add support in one or more of the underlying SATA drivers, e.g. ahci(4). >>> >>> In the da(4) case, it will require an update of the T-10 SAT spec to >>> provide a way to pass the Auxiliary register down via the SCSI ATA >>> PASS-THROUGH command, and then a subsquent update of the SAT layer in >>> various vendors' SAS controller firmware. At that point, there may be >>> an official mapping of the SCSI ZBC commands to the ATA ZAC commands, and >>> we may be able to just issue the SCSI version of the commands instead of >>> composing ATA commands in the da(4) driver. (We'll still need to keep the >>> ATA passthrough version for a while at least to support controllers that >>> don't have the updated translation code.) >>> >>> FreeBSD/head as of SVN revision 294105: >>> >>> https://people.freebsd.org/~ken/cam_smr.head.20160118.1.txt >>> >>> FreeBSD stable/10 as of SVN revision 294100: >>> >>> https://people.freebsd.org/~ken/cam_smr.stable10.20160118.1.txt >>> >>> Testing and comments are welcome. >>> >>> Ken >>> >>> On Wed, Nov 18, 2015 at 12:13:09 -0500, Kenneth D. Merry wrote: >>>> >>>> I have work in progress patches to add SMR (Shingled Magnetic Recording) >>>> support to CAM and GEOM here: >>>> >>>> FreeBSD/head as of SVN revision 290997: >>>> >>>> https://people.freebsd.org/~ken/cam_smr.head.20151117.1.txt >>>> >>>> FreeBSD stable/10 as of SVN revision 290995: >>>> >>>> https://people.freebsd.org/~ken/cam_smr.stable10.20151117.1.txt >>>> >>>> This includes support for Host Managed, Host Aware and Drive Managed SMR >>>> drives that are either SCSI (ZBC) or ATA (ZAC) attached via a SAS >>>> controller. This does not include support for SMR ATA drives attched via >>>> an ATA controller. Also, I have not yet figured out how to properly detect >>>> a Host Managed ATA drive, so this code won't do that. >>>> >>>> The big drive vendors are moving to SMR for at least some of their drives. >>>> The primary challenge with SMR is that it requires writing a relatively >>>> large zone sequentially starting at the beginning of the zone. The usual >>>> zone size is 256MB. It is conceptually almost like having a 256MB sector >>>> size. >>>> >>>> We (Spectra Logic) are working on ZFS changes that will use this CAM and >>>> GEOM infrastructure to make ZFS play well with SMR drives. Those changes >>>> aren't yet done. >>>> >>>> The patches linked above include: >>>> o A new 'camcontrol zone' command that allows displaying and managing >>>> drive zones via SCSI/ATA passthrough. >>>> o A new zonectl(8) utility that uses the new DIOCZONECMD ioctl to display >>>> and manage zones via the da(4) (and later ada(4)) driver. >>>> o Changes to diskinfo -v to display the zone mode of a drive. >>>> o A new disk zone API, sys/sys/disk_zone.h. >>>> o A new bio type, BIO_ZONE, and modifications to GEOM to support it. This >>>> new bio will allow filesystems to query zone support in a drive and >>>> manage zoned drives. >>>> o Extensive modifications to the da(4) driver to handle probing SCSI and >>>> SATA behind SAS SMR drives. >>>> o Additional CAM CDB building functions for zone commands. >>>> >>>> The current issues that need to be addressed are: >>>> o The da(4) driver now has 6 additional probe states, 5 of which are >>>> needed for probing ATA drives behind SAS controllers. I have not yet >>>> added support for BIO_ZONE bios to ada(4), but it will be very similar >>>> to the da(4) driver version. The ATA probe code needs to be pulled >>>> out of the da(4) driver and changed into a form that will allow it to >>>> work for either the ada(4) or da(4) driver. Otherwise we'll have a fair >>>> amount of code duplication between the two drivers. >>>> >>>> o There is a reasonable amount of code duplication between 'camcontrol zone' >>>> and zonectl(8). This was done for speed / expediency's sake, but it may >>>> be possible to make more of the code common there. >>>> >>>> o In order to add the new BIO_ZONE bio command, I had to change the bio_cmd >>>> field in struct bio from a uint8_t to a uint16_t. This will cause >>>> binary compatibility problems with any 3rd party loadable modules. >>>> Advice on how to handle this would be welcome. >>>> >>>> o In the process of developing these changes, I discovered that the >>>> dxfer_len paramter for scsi_ata_pass_16() was too small (uint16_t, and >>>> it needed to be uint32_t). I increased it, but that will potentially >>>> cause a binary incompatibility problem with any existing applications >>>> that use the current API via libcam. Advice on how to handle that >>>> would be welcome. >>>> >>>> If you look through the code, you'll notice that the disk_zone.h API is >>>> separate from the SCSI and ATA APIs. The intent is to allow filesystems >>>> and other consumers of the API to just talk to the disk zone API without >>>> dealing with the SCSI and ATA specifics. Another reason behind all of this >>>> is that even though the SCSI ZBC and ATA ZAC specs were developed in >>>> concert, and are intended to be functionally identical, they are still SCSI >>>> and ATA. As usual, SCSI is big endian and ATA is little endian. So to >>>> present a common API to the filesystem, we give all of the zone data back >>>> in native byte order, regardless of the underlying device protocol. >>>> >>>> Another thing to note is the extensive use of ATA passthrough in the da(4) >>>> driver. This is necessary because the SCSI SAT (SCSI to ATA Translation) >>>> specification has not yet caught up with translating SCSI zone commands >>>> (ZBC) to ATA zone commands (ZAC). So, until the spec is updated and LSI >>>> and other vendors update their SCSI to ATA translation layers, we'll have >>>> to use the ATA version of the commands when talking to ATA drives via SAS >>>> controllers. >>>> >>>> I have only tested the code so far with Seagate SATA Drive Managed and Host >>>> Aware drives. I would appreciate testing with any drives. (And testing to >>>> make sure that the patches don't cause problems with existing hardware.) >>>> Right now, all you can really do is manage the zones manually using >>>> camcontrol(8) or zonectl(8). Automatic management will come with the ZFS >>>> changes. (Or changes to other filesysems if people want to do it.) >>>> >>>> If you have a SATA Host Aware drive, in theory camcontrol(8) should allow >>>> you to manage the drive if you have it attached to a SATA controller. >>>> >>>> Here is an example of some of the commands. >>>> >>>> Get general zoning information: >>>> >>>> [root@sm4u-1 ~]# zonectl -c params -d /dev/da21 >>>> Zone Mode: Host Aware >>>> Command support: Report Zones, Open, Close, Finish, Reset Write Pointer >>>> Unrestricted Read in Sequential Write Required Zone (URSWRZ): No >>>> Optimal Number of Open Sequential Write Preferred Zones: 128 >>>> Optimal Number of Non-Sequentially Written Sequential Write Preferred Zones: 8 >>>> Maximum Number of Open Sequential Write Required Zones: Unlimited >>>> >>>> Look at information from the da(4) driver: >>>> >>>> [root@sm4u-1 ~]# sysctl kern.cam.da.21 >>>> kern.cam.da.21.delete_method: NONE >>>> kern.cam.da.21.delete_max: 1081344 >>>> kern.cam.da.21.minimum_cmd_size: 6 >>>> kern.cam.da.21.sort_io_queue: -1 >>>> kern.cam.da.21.zone_mode: Host Aware >>>> kern.cam.da.21.zone_support: Report Zones, Open, Close, Finish, Reset Write Pointer >>>> kern.cam.da.21.optimal_seq_zones: 128 >>>> kern.cam.da.21.optimal_nonseq_zones: 8 >>>> kern.cam.da.21.max_seq_zones: 4294967295 >>>> kern.cam.da.21.error_inject: 0 >>>> >>>> Display all of the zones with zonectl(8): >>>> >>>> [root@sm4u-1 ~]# zonectl -d /dev/da21 -c rz >>>> 29809 zones, Maximum LBA 0x3a3812aaf (15628053167) >>>> Zone lengths and types may vary >>>> Start LBA Length WP LBA Zone Type Condition Sequential Reset >>>> 0, 524288, 0x80000, Conventional, NWP, Sequential, No Reset Needed >>>> 0x80000, 524288, 0x100000, Conventional, NWP, Sequential, No Reset Needed >>>> 0x100000, 524288, 0x180000, Conventional, NWP, Sequential, No Reset Needed >>>> 0x180000, 524288, 0x200000, Conventional, NWP, Sequential, No Reset Needed >>>> 0x200000, 524288, 0x280000, Conventional, NWP, Sequential, No Reset Needed >>>> 0x280000, 524288, 0x300000, Conventional, NWP, Sequential, No Reset Needed >>>> 0x300000, 524288, 0x380000, Conventional, NWP, Sequential, No Reset Needed >>>> 0x380000, 524288, 0x400000, Conventional, NWP, Sequential, No Reset Needed >>>> 0x400000, 524288, 0x480000, Conventional, NWP, Sequential, No Reset Needed >>>> 0x480000, 524288, 0x500000, Conventional, NWP, Sequential, No Reset Needed >>>> 0x500000, 524288, 0x580000, Conventional, NWP, Sequential, No Reset Needed >>>> 0x580000, 524288, 0x600000, Conventional, NWP, Sequential, No Reset Needed >>>> 0x600000, 524288, 0x680000, Conventional, NWP, Sequential, No Reset Needed >>>> 0x680000, 524288, 0x700000, Conventional, NWP, Sequential, No Reset Needed >>>> 0x700000, 524288, 0x780000, Conventional, NWP, Sequential, No Reset Needed >>>> [ ... ] >>>> 0x1f00000, 524288, 0x1f80000, Conventional, NWP, Sequential, No Reset Needed >>>> 0x1f80000, 524288, 0x2000000, Conventional, NWP, Sequential, No Reset Needed >>>> 0x2000000, 524288, 0x2080000, Seq Preferred, Full, Sequential, No Reset Needed >>>> 0x2080000, 524288, 0x2100000, Seq Preferred, Full, Sequential, No Reset Needed >>>> 0x2100000, 524288, 0x2180000, Seq Preferred, Full, Sequential, No Reset Needed >>>> 0x2180000, 524288, 0x2200000, Seq Preferred, Full, Sequential, No Reset Needed >>>> 0x2200000, 524288, 0x2280000, Seq Preferred, Full, Sequential, No Reset Needed >>>> 0x2280000, 524288, 0x2300000, Seq Preferred, Full, Sequential, No Reset Needed >>>> [ ... ] >>>> >>>> Use camcontrol zone to reset the write pointer for the first shingled zone >>>> listed above: >>>> >>>> [root@sm4u-1 ~]# camcontrol zone da21 -v -c rwp -l 0x2000000 >>>> >>>> Use camcontrol zone to ask the drive to report empty zones: >>>> >>>> [root@sm4u-1 ~]# camcontrol zone da21 -v -c rz -o empty >>>> 1 zones, Maximum LBA 0x3a3812aaf (15628053167) >>>> Zone lengths and types may vary >>>> Start LBA Length WP LBA Zone Type Condition Sequential Reset >>>> 0x2000000, 524288, 0x2000000, Seq Preferred, Empty, Sequential, No Reset Needed >>>> >>>> Get information on a Host Aware drive: >>>> >>>> root@sm4u-1 ~]# diskinfo -v da21 >>>> da21 >>>> 512 # sectorsize >>>> 8001563222016 # mediasize in bytes (7.3T) >>>> 15628053168 # mediasize in sectors >>>> 4096 # stripesize >>>> 0 # stripeoffset >>>> 972801 # Cylinders according to firmware. >>>> 255 # Heads according to firmware. >>>> 63 # Sectors according to firmware. >>>> Z84008NY # Disk ident. >>>> enc@5003048001f311fd/elmtype@array_device/slot@22 # Physical path >>>> Host Aware # Zone Mode >>>> >>>> Get information on a drive managed drive: >>>> >>>> [root@sm4u-1 ~]# diskinfo -v da20 >>>> da20 >>>> 512 # sectorsize >>>> 8001563222016 # mediasize in bytes (7.3T) >>>> 15628053168 # mediasize in sectors >>>> 4096 # stripesize >>>> 0 # stripeoffset >>>> 972801 # Cylinders according to firmware. >>>> 255 # Heads according to firmware. >>>> 63 # Sectors according to firmware. >>>> Z8405938 # Disk ident. >>>> enc@5003048001f311fd/elmtype@array_device/slot@21 # Physical path >>>> Drive Managed # Zone Mode >>>> >>>> Get information on a non-zoned drive: >>>> >>>> [root@sm4u-1 ~]# diskinfo -v da4 >>>> da4 >>>> 512 # sectorsize >>>> 100030242816 # mediasize in bytes (93G) >>>> 195371568 # mediasize in sectors >>>> 0 # stripesize >>>> 0 # stripeoffset >>>> 12161 # Cylinders according to firmware. >>>> 255 # Heads according to firmware. >>>> 63 # Sectors according to firmware. >>>> 124903574F36 # Disk ident. >>>> enc@5003048001f311fd/elmtype@array_device/slot@5 # Physical path >>>> Not Zoned # Zone Mode >>>> >>>> Testing and comments are welcome. >>>> >>>> Thanks, >>>> >>>> Ken >>>> -- >>>> Kenneth Merry >>>> ken@FreeBSD.ORG >>> >>> -- >>> Kenneth Merry >>> ken@FreeBSD.ORG >> >> -- >> Kenneth Merry >> ken@FreeBSD.ORG >> _______________________________________________ >> freebsd-scsi@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-scsi >> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Wed Mar 2 19:00:20 2016 Return-Path: Delivered-To: freebsd-current@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 40F2AAC06C6 for ; Wed, 2 Mar 2016 19:00:20 +0000 (UTC) (envelope-from lists@opsec.eu) 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 324A61AF7 for ; Wed, 2 Mar 2016 19:00:20 +0000 (UTC) (envelope-from lists@opsec.eu) Received: by mailman.ysv.freebsd.org (Postfix) id 3025BAC06C4; Wed, 2 Mar 2016 19:00:20 +0000 (UTC) Delivered-To: current@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 2FC20AC06C3 for ; Wed, 2 Mar 2016 19:00:20 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (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 EE7971AF6 for ; Wed, 2 Mar 2016 19:00:19 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1abC0U-0005MS-MG for current@freebsd.org; Wed, 02 Mar 2016 20:00:22 +0100 Date: Wed, 2 Mar 2016 20:00:22 +0100 From: Kurt Jaeger To: current@freebsd.org Subject: Build error on current@r296308: 'yacc.h' file not found Message-ID: <20160302190022.GA20540@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 19:00:20 -0000 Hi! Today, I upgraded to r296308 and had this failure during buildworld: ===> usr.bin/mkesdb_static (obj,build-tools) cc -O2 -pipe -I/usr/src/usr.bin/mkesdb_static -I/usr/src/usr.bin/mkesdb_static/../mkesdb -I/usr/src/usr.bin/mkesdb_static/../../lib/libc/iconv -g -std=gnu99 -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -c lex.c -o lex.o /usr/src/usr.bin/mkesdb_static/../mkesdb/lex.l:44:10: fatal error: 'yacc.h' file not found #include "yacc.h" 1 error generated. *** Error code 1 A 'script' output is available at http://people.freebsd.org/~pi/logs/src-up-2 Is it just me or ... ? -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-current@freebsd.org Wed Mar 2 19:00:50 2016 Return-Path: Delivered-To: freebsd-current@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 C378AAC07B1 for ; Wed, 2 Mar 2016 19:00:50 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 7BB521CA9 for ; Wed, 2 Mar 2016 19:00:50 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-vk0-x22f.google.com with SMTP id k196so212722863vka.0 for ; Wed, 02 Mar 2016 11:00:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brilliantservice-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tgC9Q5151XDEChMmLZo1vx1ARGMNyVX72mKHuf+DrY8=; b=YC+9eZRFbsHu4X8yaixdqgVTAzuLIRHteuZlVMmEeGvDsHSZHrQJlUyCwlggCM9ijv 4r/8nJpAVUUgyb5BUfIfYkaTTFeWGskNAMZYas1iggvcCW4DHeQdS8GXZXyvRgSpBZre joSpEldOcmm+HGWWe0pUPOP0ZQdkR0GDf7BVucT263GNnvXLGHALz6mA5bB+epIo2m3h eWVNX63vNFdgvh0fxijp81XHdHZ69CjqPdx7iUqMfAewD245r8PxBbvSkoYwLJvfqbnt vHJnBmSLSR/nNTRtu4GH5rrEsk9Dx8V4Il4bYQLMdKwLlChD6SKOvJmcGCkNJ/LSNAfz 2uDg== 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=tgC9Q5151XDEChMmLZo1vx1ARGMNyVX72mKHuf+DrY8=; b=KiO9eHy2lQsGf/HHn/LSx+PFLd40eYJxVNJKaB8Js6oKvahK8hiGmPvg/6Gmd1zpK9 BMix7EqUFUQX5LouU9Q4C4dbXTVrkSHtov2Oy7DpCYv5Rhui4/188zNg59gOu1UuEgn7 bxJVC4SWAeF4xYlG+OrAcQ3XnPAm+0axsD+Jk8vwZYX+lScw4YYyCSDASAIhEQoTAU8A lH7kaH3LqSIrHyzfBHJNlkiETHvIUg2MIt4AQdPaioSIyOD9pJjX1vfRlql9ChYGTnx9 of32di6BN7C/oODuxirS9kRn3iSCdqPYH+BfsoYqiLwRaKOQ6oRO11tCZnrCrVeQtb8w /OSg== X-Gm-Message-State: AD7BkJLQtiKVpYIup5VqI+th5yme8zizwJlZsYVhVu6ZKlgtuXJqk30phbgsOzVZblDUc5Ibge+z4WTPJFDDOJGMx+KzGiyXj9Whiky+uRwLbCOu2Z1HIo1ad/HRxyQFZsv89I7sjceefXYUJPL9g+AuJrA= X-Received: by 10.31.50.202 with SMTP id y193mr21244522vky.48.1456945249470; Wed, 02 Mar 2016 11:00:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.36.197 with HTTP; Wed, 2 Mar 2016 11:00:35 -0800 (PST) In-Reply-To: <56D6BC03.2040508@m.jwh.me.uk> References: <56D29AF6.50401@m.jwh.me.uk> <4073395.HnTjdCHcSr@ralph.baldwin.cx> <56D6BC03.2040508@m.jwh.me.uk> From: "Lundberg, Johannes" Date: Wed, 2 Mar 2016 11:00:35 -0800 Message-ID: Subject: Re: Bay Trail 32bit UEFI To: Joe Holden Cc: John Baldwin , FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 19:00:50 -0000 On Wed, Mar 2, 2016 at 2:10 AM, Joe Holden wrote: > On 02/03/2016 01:45, Lundberg, Johannes wrote: > >> CherryTrail devices/boards with 64bit UEFI are already out. Upgrading >> the hardware is one solution (I did). >> >> I'm thinking of the sticks etc, they all have 32bit UEFI and no > CSM/legacy boot, but have 64bit cpus Yeah and it sucks. All to adapt to Microsoft who couldn't make 64bit UEFI boot loader in time (or so I heard)... I heard though that newer (Linux) versions of Intel Compute Stick would have 64bit UEFI but I'm not sure. > > I never did try FreeBSD on BayTrail but for running Linux on BayTrail I >> used special built Grub that was 32bit but could load 64bit OS. Could >> this kind of Grub boot a 64bit FreeBSD, I wonder? >> >> I looked at this but honestly it looked like a giant nightmare - I did > get grub loading on a test platform (tablet, for display etc) but didn't > manage to make it boot anything > This page contains some instructions and a downloadable booti32.efi image that you can put in the EFI folder. That will boot a 64bit grub that should be able to boot a 64bit OS. http://liliputing.com/2013/10/booting-ubuntu-asus-transformer-book-t100.htm= l I do have customized Arch Linux memstick image with Grub and this booti32.efi image so it boots on these systems. This can be used to install a Grub bootloader that maybe can boot FreeBSD. One question is, would Grub's filesystem drivers for FreeBSD work in this mode? Maybe I should give it a shot today.. > >> On Tue, Mar 1, 2016 at 5:20 PM, John Baldwin > > wrote: >> >> On Sunday, February 28, 2016 07:00:06 AM Joe Holden wrote: >> > Hi all, >> > >> > Apologies if this is the wrong list... >> > >> > Is there any plan to support booting FreeBSD on 32bit UEFI systems >> (with >> > or without 64bit kernel/userland)? Obviously there is no i386 efi >> loader >> > currently so neither is possible... >> >> I don't think anyone is actively working on it. I think it shouldn'= t >> be >> that much work once the i386 loader is resurrected. The i386 kernel >> just >> needs to use the EFI memory map and I think the rest of it should >> generally >> just work. >> >> -- >> John Baldwin >> _______________________________________________ >> freebsd-current@freebsd.org >> mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org >> " >> > > > --=20 =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- =E7=A7=98=E5=AF=86=E4=BF=9D=E6=8C=81=E3=81=AB=E3=81=A4=E3=81=84=E3=81=A6=EF= =BC=9A=E3=81=93=E3=81=AE=E9=9B=BB=E5=AD=90=E3=83=A1=E3=83=BC=E3=83=AB=E3=81= =AF=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E3=81=AB=E9=80=81=E4=BF=A1=E3=81=97= =E3=81=9F=E3=82=82=E3=81=AE=E3=81=A7=E3=81=82=E3=82=8A=E3=80=81=E7=A7=98=E5= =8C=BF=E7=89=B9=E6=A8=A9=E3=81=AE=E5=AF=BE=E8=B1=A1=E3=81=A8=E3=81=AA=E3=82= =8B=E6=83=85=E5=A0=B1=E3=82=92=E5=90=AB=E3=82=93=E3=81=A7=E3=81=84=E3=81=BE= =E3=81=99=E3=80=82 =E3=82=82=E3=81=97=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E4=BB=A5=E5=A4=96=E3= =81=AE=E6=96=B9=E3=81=8C=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5=A0= =B4=E5=90=88=E3=80=81=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AE= =E7=A0=B4=E6=A3=84=E3=80=81=E3=81=8A=E3=82=88=E3=81=B3=E3=81=93=E3=81=AE=E3= =83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E9=96=A2=E3=81=99=E3=82=8B=E4=B8=80=E5=88= =87=E3=81=AE=E9=96=8B=E7=A4=BA=E3=80=81 =E8=A4=87=E5=86=99=E3=80=81=E9=85=8D=E5=B8=83=E3=80=81=E3=81=9D=E3=81=AE=E4= =BB=96=E3=81=AE=E5=88=A9=E7=94=A8=E3=80=81=E3=81=BE=E3=81=9F=E3=81=AF=E8=A8= =98=E8=BC=89=E5=86=85=E5=AE=B9=E3=81=AB=E5=9F=BA=E3=81=A5=E3=81=8F=E3=81=84= =E3=81=8B=E3=81=AA=E3=82=8B=E8=A1=8C=E5=8B=95=E3=82=82=E3=81=95=E3=82=8C=E3= =81=AA=E3=81=84=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81= =97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. From owner-freebsd-current@freebsd.org Wed Mar 2 19:03:00 2016 Return-Path: Delivered-To: freebsd-current@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 66C70AC0A76 for ; Wed, 2 Mar 2016 19:03:00 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3973B10D3 for ; Wed, 2 Mar 2016 19:03:00 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yuri.doctorlan.com (c-73-71-174-75.hsd1.ca.comcast.net [73.71.174.75]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id u22J2rTi051390 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 2 Mar 2016 11:02:54 -0800 (PST) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-73-71-174-75.hsd1.ca.comcast.net [73.71.174.75] claimed to be yuri.doctorlan.com Subject: Re: Could somebody just commit this patch: The new command line option to set the daemon(8) process title ? To: freebsd-current@freebsd.org References: <56D4CD80.2000501@rawbw.com> From: Yuri Message-ID: <56D738DC.5000908@rawbw.com> Date: Wed, 2 Mar 2016 11:02:52 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 19:03:00 -0000 On 02/29/2016 15:05, Conrad Meyer wrote: > I'd be happy to (+ manual page changes) if I don't hear any objection > in the next few days. I would keep [pid] in the title and just > replace argv0 with the -t argument. Conrad, thank you for taking it. Best, Yuri From owner-freebsd-current@freebsd.org Wed Mar 2 18:49:44 2016 Return-Path: Delivered-To: freebsd-current@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 194AEAC2FB0; Wed, 2 Mar 2016 18:49:44 +0000 (UTC) (envelope-from lists@rakupottery.org.uk) Received: from iprslrsmtp2msp.cpwnetworks.com (rslrsmtp2.opaltelecom.net [62.24.128.202]) by mx1.freebsd.org (Postfix) with ESMTP id 85FE41182; Wed, 2 Mar 2016 18:49:42 +0000 (UTC) (envelope-from lists@rakupottery.org.uk) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AIBQCDNNdW//6AGD5eGQEBAg8BAQEBg1xtpkYFAYEPAZAuhAgZhXYCghQBAQEBAQFlJ4RBAQEBAQIBOEARCxgJEwMPCQMCAQIBNw4GAQwGAgEBiBUMuy8BAQEHAQEBAQEbhUqFAoN6I4RSAQSXEoVaiWmERIMChVBEjghig2RqAYhfAQEB X-IPAS-Result: A2AIBQCDNNdW//6AGD5eGQEBAg8BAQEBg1xtpkYFAYEPAZAuhAgZhXYCghQBAQEBAQFlJ4RBAQEBAQIBOEARCxgJEwMPCQMCAQIBNw4GAQwGAgEBiBUMuy8BAQEHAQEBAQEbhUqFAoN6I4RSAQSXEoVaiWmERIMChVBEjghig2RqAYhfAQEB X-IronPort-AV: E=Sophos;i="5.22,529,1449532800"; d="scan'208";a="694946956" Received: from smtp-pub.talktalk.net (HELO rslr-smtp-1.cpwnetworks.com) ([62.24.128.254]) by iprslrsmtp2msp.cpwnetworks.com with ESMTP; 02 Mar 2016 18:48:30 +0000 Received: from [92.27.146.104] (helo=imac.local) by rslr-smtp-1.cpwnetworks.com with esmtp (Exim 4.63) (envelope-from ) id 1abBp0-0007cX-6I; Wed, 02 Mar 2016 18:48:30 +0000 Subject: Re: mounting CIFS share (tcp/445) with FreeBSD and mount_smbfs(8) To: "O. Hartmann" , FreeBSD CURRENT , FreeBSD Questions References: <20160302060243.518568d7.ohartman@zedat.fu-berlin.de> From: Martin Smith Message-ID: <56D73578.4040802@rakupottery.org.uk> Date: Wed, 2 Mar 2016 18:48:24 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160302060243.518568d7.ohartman@zedat.fu-berlin.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 02 Mar 2016 19:15:49 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 18:49:44 -0000 On 02/03/2016 05:02, O. Hartmann wrote: > Hello list. > > I need to mount a CIFS share from windows server 2012 r2 via CIFS, tcp/445 as NetBIOS > service (tcp/139) has been deprecated due to serious vulnerability issues. > > Until the disabling of NetBIOS and tcp/139 we used successfully autofs and mount_smbfs. > this is no longer working. I tried to force autofs/mount_smbfs to bind to port 445 on the > server via ://@xxx.xxx.xxx.xxx:445/sharename, but this doesn't work. > > Trying to mount a share from a samba 4.3 server (FreeBSD CURRENT, net/samba43, both most > recent sources), where I configured samba_server via smb ports = 445 to use port tcp 445 > only and only SMB2 and SMB3 (server min protocol = SMB2) protocols via the following > command: > > mount_smbfs -I xxx.xxx.xxx.xxx -U a_user -W \ > WORKGROUP //a_user@xxx.xxx.xxx.xxx:445/sharename /mnt > > results in the error > > mount_smbfs: unable to open connection: syserr = RPC struct is bad > > Setting "smb ports = 139,445" and "server min protocol = NT1" seems to work, the share > can be bound, but this is SMB over tcp/139 and not CIFS. > > I desperately need CIFS and I need tcp/445 since tcp/139 is from now on firewalled. > > So: what do I miss here? I think this is a windows server problem, though I am not in a position to make any useful suggestions except to say that I am continually coming up against similar problems with windows machines as well sorry I cant be any more help > > Kind regards and thank you in advance, > > O. Hartmann > > P.S. Please CC me From owner-freebsd-current@freebsd.org Wed Mar 2 19:18:11 2016 Return-Path: Delivered-To: freebsd-current@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 1AE88AC11F0 for ; Wed, 2 Mar 2016 19:18:11 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-yw0-f169.google.com (mail-yw0-f169.google.com [209.85.161.169]) (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 D7FC81BE3 for ; Wed, 2 Mar 2016 19:18:10 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-yw0-f169.google.com with SMTP id e63so184951502ywc.3 for ; Wed, 02 Mar 2016 11:18:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc; bh=W7dvte8Q90YFPEq8/YpfS/L7Iqnef4fh4h9JjEpT2jk=; b=JRrZKH+4Tf+rU0wdMAJiLk+ka4INXI4XFcp2Uu6mXGW8zhcbMJx8UqwIuV4nMz10do TRBS8FkK6WOk93g3M0m1YJTM+NTNARmUJjETefLXEyjohSuk1gEoWQvYtdF2zrOhBIEY DPsrb54KaQwWGyWBp+Zc+B7h2rs9A6YpDyVtwJLPczOH64jMEU3vlrpU55She4517Q4D lzMIbtqskrWe0UNdRb4KLjCjT+YtOdcgMesawhACMJW5AUlphjF8ZjRkNeR/cA3ks9Tw 49AIAlfu+rSKApVeSwcX8Di9iVUdgsaIBWhcst3P7FiloELS6QbTgAq4P8y/X8csqmAU OQ4A== X-Gm-Message-State: AD7BkJIVt33nVb4zS0vWBrkMXUub0DPRd/YN/MpjRC7WgceHHK8VozlxHeiFR9MiAxl6pg== X-Received: by 10.129.98.138 with SMTP id w132mr17086456ywb.226.1456945971454; Wed, 02 Mar 2016 11:12:51 -0800 (PST) Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com. [209.85.161.182]) by smtp.gmail.com with ESMTPSA id t76sm29556349ywe.47.2016.03.02.11.12.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Mar 2016 11:12:51 -0800 (PST) Received: by mail-yw0-f182.google.com with SMTP id e63so184823839ywc.3 for ; Wed, 02 Mar 2016 11:12:51 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.129.40.78 with SMTP id o75mr17420515ywo.9.1456945970926; Wed, 02 Mar 2016 11:12:50 -0800 (PST) Reply-To: cem@FreeBSD.org Received: by 10.37.115.134 with HTTP; Wed, 2 Mar 2016 11:12:50 -0800 (PST) In-Reply-To: <56D738DC.5000908@rawbw.com> References: <56D4CD80.2000501@rawbw.com> <56D738DC.5000908@rawbw.com> Date: Wed, 2 Mar 2016 11:12:50 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Could somebody just commit this patch: The new command line option to set the daemon(8) process title ? From: Conrad Meyer To: Yuri Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 19:18:11 -0000 Committed in r296321, thanks! On Wed, Mar 2, 2016 at 11:02 AM, Yuri wrote: > On 02/29/2016 15:05, Conrad Meyer wrote: >> >> I'd be happy to (+ manual page changes) if I don't hear any objection >> in the next few days. I would keep [pid] in the title and just >> replace argv0 with the -t argument. > > > Conrad, > > thank you for taking it. > > Best, > > Yuri > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Wed Mar 2 19:45:57 2016 Return-Path: Delivered-To: freebsd-current@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 39B04AC1D80 for ; Wed, 2 Mar 2016 19:45:57 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E58EF1BAC for ; Wed, 2 Mar 2016 19:45:56 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-vk0-x230.google.com with SMTP id c3so212976091vkb.3 for ; Wed, 02 Mar 2016 11:45:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brilliantservice-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Qx8hczc489C79MksL1QU+V81ETsuTtU1pMlJcNI7Exg=; b=yQIotQLbZcRAGUzvXaRd19hHXIQCo69lu5iNkraKVhhfjkwwgXFcT1SexBGS0muySp euwcvfnmgQ+Cyj/nXsn8gH9jc17kgsR+1vGsUQfW992b2i+hUmDv2fOoupiCdjYctCPv 0XfEG9NhnZiT2ayv3pchZvsiARtPVB5fDOmmzXBGFAFXyxagFhrg4Mw100vOdHzIKD92 ZkkzlWYo5YbGZPhebzAeEjJ2I9v0OualP22LikKRRIayMRdQBOZEJbcTBPoDlI6TRhuk 01Oj8f8rbRA31XGhkGIIH0VdzTB/UHRj0tb1rJePkvmwsq3XgJvChRlvMOcD6Xbcxhrd dYOw== 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=Qx8hczc489C79MksL1QU+V81ETsuTtU1pMlJcNI7Exg=; b=DDeJQw4awhpHzURpiYb1wH5cABCnWcaalPbCZDT5iSKcJe7F9KHylY7/UwSZZfGBKq bmqsN+FeTLCswIVVkqdQm8a54hpZkjcKWhVD6ugHAXvi8MupFHlUYiWOhlZ/KTOxugNz 8NHEtnsJx+VKtpPlXCETuI/pyalBVseCeJG6PdYm3N9JVr+f2aOAqsiWPWyaifcuWM3M vUyACohulcgXtReWuPXzTzygegDMhZBR+i2PnalEetQWp2s8fr6jO9MTGvpkfS3fZH7S NAzd6jJfy985RZVHljg+Q2otfeTb8gc4IxaqYjOoKwTOMfP3Cm3UAGACDslwqv4Bbtmi 6Q5g== X-Gm-Message-State: AD7BkJLLD3U8+D9REeSXMZQ/comI5BYUSTPDLNBTn8UIzyoxv0w+ztCaGvMHBtdBM8l4+dzPG60y0g6MiuqyNTMhoSCZedyQf+c2n704VZbP8iLvjFgHfSD4d1bbudYjEqh04iZczhwfM3Y20B85HgetpEY= X-Received: by 10.31.50.202 with SMTP id y193mr21406943vky.48.1456947955898; Wed, 02 Mar 2016 11:45:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.36.197 with HTTP; Wed, 2 Mar 2016 11:45:41 -0800 (PST) In-Reply-To: <18013.85.229.93.153.1456947431.squirrel@webmail.alvermark.net> References: <56D29AF6.50401@m.jwh.me.uk> <4073395.HnTjdCHcSr@ralph.baldwin.cx> <56D6BC03.2040508@m.jwh.me.uk> <18013.85.229.93.153.1456947431.squirrel@webmail.alvermark.net> From: "Lundberg, Johannes" Date: Wed, 2 Mar 2016 11:45:41 -0800 Message-ID: Subject: Re: Bay Trail 32bit UEFI To: Jakob Alvermark Cc: Joe Holden , John Baldwin , FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 19:45:57 -0000 T24gV2VkLCBNYXIgMiwgMjAxNiBhdCAxMTozNyBBTSwgSmFrb2IgQWx2ZXJtYXJrIDxqYWtvYkBh bHZlcm1hcmsubmV0Pg0Kd3JvdGU6DQoNCj4gT24gV2VkLCBNYXJjaCAyLCAyMDE2IDIwOjAwLCBM dW5kYmVyZywgSm9oYW5uZXMgd3JvdGU6DQo+ID4gT24gV2VkLCBNYXIgMiwgMjAxNiBhdCAyOjEw IEFNLCBKb2UgSG9sZGVuIDxtYWlsQG0uandoLm1lLnVrPiB3cm90ZToNCj4gPg0KPiA+DQo+ID4+ IE9uIDAyLzAzLzIwMTYgMDE6NDUsIEx1bmRiZXJnLCBKb2hhbm5lcyB3cm90ZToNCj4gPj4NCj4g Pj4NCj4gPj4+IENoZXJyeVRyYWlsIGRldmljZXMvYm9hcmRzIHdpdGggNjRiaXQgVUVGSSBhcmUg YWxyZWFkeSBvdXQuIFVwZ3JhZGluZw0KPiA+Pj4gIHRoZSBoYXJkd2FyZSBpcyBvbmUgc29sdXRp b24gKEkgZGlkKS4NCj4gPj4+DQo+ID4+PiBJJ20gdGhpbmtpbmcgb2YgdGhlIHN0aWNrcyBldGMs IHRoZXkgYWxsIGhhdmUgMzJiaXQgVUVGSSBhbmQgbm8NCj4gPj4+DQo+ID4+IENTTS9sZWdhY3kg Ym9vdCwgYnV0IGhhdmUgNjRiaXQgY3B1cw0KPiA+Pg0KPiA+DQo+ID4NCj4gPg0KPiA+IFllYWgg YW5kIGl0IHN1Y2tzLiBBbGwgdG8gYWRhcHQgdG8gTWljcm9zb2Z0IHdobyBjb3VsZG4ndCBtYWtl IDY0Yml0IFVFRkkNCj4gPiAgYm9vdCBsb2FkZXIgaW4gdGltZSAob3Igc28gSSBoZWFyZCkuLi4g SSBoZWFyZCB0aG91Z2ggdGhhdCBuZXdlciAoTGludXgpDQo+ID4gdmVyc2lvbnMgb2YgSW50ZWwg Q29tcHV0ZSBTdGljayB3b3VsZCBoYXZlIDY0Yml0IFVFRkkgYnV0IEknbSBub3Qgc3VyZS4NCj4N Cj4gVGhlIEludGVsIENvbXB1dGUgc3RpY2tzIGNhbiBib290IGJvdGggMzIgYW5kIDY0IGJpdC4g SXQgZG9lc24ndCBtYXR0ZXIgaWYNCj4geW91IGhhdmUgdGhlIFdpbmRvd3Mgb3IgTGludXggdmVy c2lvbi4gKFRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIGlzIHRoZQ0KPiBhbW91bnQgb2YgUkFN IGFuZCBvbmJvYXJkIHN0b3JhZ2UsIHRoZSBmaXJtd2FyZSBpcyB0aGUgc2FtZSkNCj4NCj4gSSBo YXZlIHRoZSBXaW5kb3dzIG9uZSBhbmQgaXQgYm9vdHMgNjQgYml0IGp1c3QgZmluZS4NCj4gWW91 IGNhbiBzZWxlY3QgaXQgaW4gdGhlIHNldHRpbmdzLiAoT1Mgc2V0dGluZzogV2luZG93cz0zMiBi aXQsIExpbnV4PTY0DQo+IGJpdCkNCj4NCg0KVGhhdCdzIGdyZWF0LiBIb3dldmVyLCBhcyBmb3Ig YWxsIG90aGVyIEJheVRyYWlsIGRldmljZXMgb3V0IHRoZXJlIHRoYXQNCmRvZXMgbm90IHN1cHBv cnQgTGludXggb2ZmaWNpYWxseSBJIHRoaW5rIHlvdSdyZSBzdHVjayB3aXRoIDMyYml0Lg0KDQoN Cj4NCj4gSmFrb2INCj4NCj4NCgotLSAKPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09 LT0tPS09LT0tPS09LT0tPS09LT0tCuenmOWvhuS/neaMgeOBq+OBpOOBhOOBpu+8muOBk+OBrumb u+WtkOODoeODvOODq+OBr+OAgeWQjeWum+S6uuOBq+mAgeS/oeOBl+OBn+OCguOBruOBp+OBguOC iuOAgeenmOWMv+eJueaoqeOBruWvvuixoeOBqOOBquOCi+aDheWgseOCkuWQq+OCk+OBp+OBhOOB vuOBmeOAggrjgoLjgZfjgIHlkI3lrpvkurrku6XlpJbjga7mlrnjgYzlj5fkv6HjgZXjgozjgZ/l oLTlkIjjgIHjgZPjga7jg6Hjg7zjg6vjga7noLTmo4TjgIHjgYrjgojjgbPjgZPjga7jg6Hjg7zj g6vjgavplqLjgZnjgovkuIDliIfjga7plovnpLrjgIEK6KSH5YaZ44CB6YWN5biD44CB44Gd44Gu 5LuW44Gu5Yip55So44CB44G+44Gf44Gv6KiY6LyJ5YaF5a6544Gr5Z+644Gl44GP44GE44GL44Gq 44KL6KGM5YuV44KC44GV44KM44Gq44GE44KI44GG44GK6aGY44GE55Sz44GX5LiK44GS44G+44GZ 44CCCi0tLQpDT05GSURFTlRJQUxJVFkgTk9URTogVGhlIGluZm9ybWF0aW9uIGluIHRoaXMgZW1h aWwgaXMgY29uZmlkZW50aWFsCmFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUu CkRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciBhbnkgb3RoZXIgYWN0aW9uIG9m IHVzZSBvZiB0aGlzCmVtYWlsIGJ5IHBlcnNvbiBvdGhlciB0aGFuIGludGVuZGVkIHJlY2lwaWVu dCwgaXMgcHJvaGliaXRlZC4KSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBh bmQgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluCmVycm9yLCBwbGVhc2UgZGVzdHJveSB0aGUg b3JpZ2luYWwgbWVzc2FnZS4K From owner-freebsd-current@freebsd.org Wed Mar 2 19:48:23 2016 Return-Path: Delivered-To: freebsd-current@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 5FE07AC1E84 for ; Wed, 2 Mar 2016 19:48:23 +0000 (UTC) (envelope-from lists@opsec.eu) 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 50F701D61 for ; Wed, 2 Mar 2016 19:48:23 +0000 (UTC) (envelope-from lists@opsec.eu) Received: by mailman.ysv.freebsd.org (Postfix) id 4E63AAC1E83; Wed, 2 Mar 2016 19:48:23 +0000 (UTC) Delivered-To: current@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 4DF94AC1E82 for ; Wed, 2 Mar 2016 19:48:23 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (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 1524B1D5D for ; Wed, 2 Mar 2016 19:48:23 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1abCl0-0005Qg-15 for current@freebsd.org; Wed, 02 Mar 2016 20:48:26 +0100 Date: Wed, 2 Mar 2016 20:48:26 +0100 From: Kurt Jaeger To: current@freebsd.org Subject: Re: Build error on current@r296308: 'yacc.h' file not found Message-ID: <20160302194825.GF79128@home.opsec.eu> References: <20160302190022.GA20540@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160302190022.GA20540@home.opsec.eu> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 19:48:23 -0000 Hi! > Today, I upgraded to r296308 and had this failure during buildworld: > > ===> usr.bin/mkesdb_static (obj,build-tools) > cc -O2 -pipe -I/usr/src/usr.bin/mkesdb_static -I/usr/src/usr.bin/mkesdb_static/../mkesdb -I/usr/src/usr.bin/mkesdb_static/../../lib/libc/iconv -g -std=gnu99 -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -c lex.c -o lex.o > /usr/src/usr.bin/mkesdb_static/../mkesdb/lex.l:44:10: fatal error: 'yacc.h' file not found > #include "yacc.h" > 1 error generated. > *** Error code 1 > > A 'script' output is available at http://people.freebsd.org/~pi/logs/src-up-2 > > Is it just me or ... ? If I change the sequence in /usr/src/usr.bin/mkesdb/Makefile.inc for line SRCS+= lex.l yacc.y to SRCS+= yacc.y lex.l it builds ? That file was last touched 4 years ago ? -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-current@freebsd.org Wed Mar 2 19:58:11 2016 Return-Path: Delivered-To: freebsd-current@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 824C3AC21C7 for ; Wed, 2 Mar 2016 19:58:11 +0000 (UTC) (envelope-from xxjack12xx@gmail.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 6585C119B for ; Wed, 2 Mar 2016 19:58:11 +0000 (UTC) (envelope-from xxjack12xx@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 62C0BAC21C6; Wed, 2 Mar 2016 19:58:11 +0000 (UTC) Delivered-To: current@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 62571AC21C5 for ; Wed, 2 Mar 2016 19:58:11 +0000 (UTC) (envelope-from xxjack12xx@gmail.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2FED0119A for ; Wed, 2 Mar 2016 19:58:11 +0000 (UTC) (envelope-from xxjack12xx@gmail.com) Received: by mail-io0-x236.google.com with SMTP id g203so3808849iof.2 for ; Wed, 02 Mar 2016 11:58:11 -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=JdeECAg+fqb+2oCvB6pLpf0fM7IEs+Xxc5YGCE32C4k=; b=KPBEUp2Yh5Q9QrQLl5LOB6TcXreBoHGWfPF7kQaWksHmu8B1RXrxKP75sadZaqAl4A kys/c9/ravBXwp1lrmyV7aUeP8Jlsb6wH0+W7cQ4+M5IGkNT8AGv6YoXTYBf4Tbvjbj4 JAP0J6cCPgk9QkHWl9D+afyYRwY5SLdlmCPxeoUROIcfk7OLxQ2iRoLIuM964HThZZIu HRiyaQSyweyCHHPIBJHvmC41HYV9bhkN3Uuv6eEHdfBw9x7IJpTN9fMqKJGhS3CuRtw3 k/WHkuT5hTX/FUCopoFt4o+iWckEXUsHJN5c//DAIxb4PZta0GQwn+KEqDOYdoS/YWDQ bJNQ== 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=JdeECAg+fqb+2oCvB6pLpf0fM7IEs+Xxc5YGCE32C4k=; b=WCW9w25vKeLgi8BbqtkYvdRhJA/MLtevKGM7EOKRWKljUo3HlfOw8cJi4tPn45k0Or QHTU9FNgTVyxWfwhgUaWA9jE4cXdObtIv67fPevUrPVJY2Uo2qELtC9Y7E5ldtSpOsYE pB8Ri1lC5wfBndLaa71O/2xFtQLymCbGFB0i8umLqYPBD9iDus0E5Uy8aFk1PrDtJvII AEj5xyTDIGXMzdQjK6HzS6Qc8Dyo6JikhcOnCu4iBheZM/iwQ/YEqDCc38YVnMQ0zaHo bwMK+Gcre+yD+LdW/B1+p8r61a4nn+fuI6mTphNTqLhNg+yQDAvbbgyWkM05NvYJ0jRp n+YA== X-Gm-Message-State: AG10YOQZ/euHI/whIiS+qRmvlNp/mi++XaNxSjzVicMYMb4aW87Ys16BMcdI2tz/sRuBo2KjhdyqzYsj5QVhdg== X-Received: by 10.107.164.225 with SMTP id d94mr32202905ioj.187.1456948690484; Wed, 02 Mar 2016 11:58:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.41.129 with HTTP; Wed, 2 Mar 2016 11:57:31 -0800 (PST) In-Reply-To: <20160302194825.GF79128@home.opsec.eu> References: <20160302190022.GA20540@home.opsec.eu> <20160302194825.GF79128@home.opsec.eu> From: "Jack L." Date: Wed, 2 Mar 2016 11:57:31 -0800 Message-ID: Subject: Re: Build error on current@r296308: 'yacc.h' file not found To: Kurt Jaeger Cc: current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 19:58:11 -0000 I have the same compilation error when I tried to build current today as well. On Wed, Mar 2, 2016 at 11:48 AM, Kurt Jaeger wrote: > Hi! > >> Today, I upgraded to r296308 and had this failure during buildworld: >> >> ===> usr.bin/mkesdb_static (obj,build-tools) >> cc -O2 -pipe -I/usr/src/usr.bin/mkesdb_static -I/usr/src/usr.bin/mkesdb_static/../mkesdb -I/usr/src/usr.bin/mkesdb_static/../../lib/libc/iconv -g -std=gnu99 -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -c lex.c -o lex.o >> /usr/src/usr.bin/mkesdb_static/../mkesdb/lex.l:44:10: fatal error: 'yacc.h' file not found >> #include "yacc.h" >> 1 error generated. >> *** Error code 1 >> >> A 'script' output is available at http://people.freebsd.org/~pi/logs/src-up-2 >> >> Is it just me or ... ? > > If I change the sequence in > > /usr/src/usr.bin/mkesdb/Makefile.inc > > for line > > SRCS+= lex.l yacc.y > > to > > SRCS+= yacc.y lex.l > > it builds ? That file was last touched 4 years ago ? > > -- > pi@opsec.eu +49 171 3101372 4 years to go ! > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Wed Mar 2 20:05:23 2016 Return-Path: Delivered-To: freebsd-current@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 B2E5DAC24E6 for ; Wed, 2 Mar 2016 20:05:23 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from smtprelay-b22.telenor.se (smtprelay-b22.telenor.se [195.54.99.213]) (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 26FF319A7; Wed, 2 Mar 2016 20:05:22 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from ipb4.telenor.se (ipb4.telenor.se [195.54.127.167]) by smtprelay-b22.telenor.se (Postfix) with ESMTP id F3AAC44389; Wed, 2 Mar 2016 20:37:34 +0100 (CET) X-SENDER-IP: [85.229.94.62] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2A0BwC1QNdWPD5e5VVeGQEBAgsBAgEBAQEBgwqBPwaGX7EmhAiGDwKBRzwRAQEBAQEBAQYBAQEBQUCEQgEBBCMPASMjEAsYAgImAgItDAoGAQ0GExuICgGsOI8WAQEBAQYBAQEBHHuJUYQWAQEHB4MPgToFlxIBgUSbFI0fAYEsNoIvGYFJOy6HJgEHF4EbAQEB X-IPAS-Result: A2A0BwC1QNdWPD5e5VVeGQEBAgsBAgEBAQEBgwqBPwaGX7EmhAiGDwKBRzwRAQEBAQEBAQYBAQEBQUCEQgEBBCMPASMjEAsYAgImAgItDAoGAQ0GExuICgGsOI8WAQEBAQYBAQEBHHuJUYQWAQEHB4MPgToFlxIBgUSbFI0fAYEsNoIvGYFJOy6HJgEHF4EbAQEB X-IronPort-AV: E=Sophos;i="5.22,530,1449529200"; d="scan'208";a="206137663" Received: from c-3e5ee555.06-11-73746f31.cust.bredbandsbolaget.se (HELO sigyn.alvermark.net) ([85.229.94.62]) by ipb4.telenor.se with ESMTP; 02 Mar 2016 20:37:13 +0100 Received: from localhost ([127.0.0.1] helo=webmail.alvermark.net) by sigyn.alvermark.net with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1abCa7-000HXp-LE; Wed, 02 Mar 2016 20:37:11 +0100 Received: from 85.229.93.153 (SquirrelMail authenticated user alvis) by webmail.alvermark.net with HTTP; Wed, 2 Mar 2016 20:37:11 +0100 (CET) Message-ID: <18013.85.229.93.153.1456947431.squirrel@webmail.alvermark.net> In-Reply-To: References: <56D29AF6.50401@m.jwh.me.uk> <4073395.HnTjdCHcSr@ralph.baldwin.cx> <56D6BC03.2040508@m.jwh.me.uk> Date: Wed, 2 Mar 2016 20:37:11 +0100 (CET) Subject: Re: Bay Trail 32bit UEFI From: "Jakob Alvermark" To: "Lundberg, Johannes" Cc: "Joe Holden" , "John Baldwin" , "FreeBSD Current" User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 20:05:23 -0000 On Wed, March 2, 2016 20:00, Lundberg, Johannes wrote: > On Wed, Mar 2, 2016 at 2:10 AM, Joe Holden wrote: > > >> On 02/03/2016 01:45, Lundberg, Johannes wrote: >> >> >>> CherryTrail devices/boards with 64bit UEFI are already out. Upgrading >>> the hardware is one solution (I did). >>> >>> I'm thinking of the sticks etc, they all have 32bit UEFI and no >>> >> CSM/legacy boot, but have 64bit cpus >> > > > > Yeah and it sucks. All to adapt to Microsoft who couldn't make 64bit UEFI > boot loader in time (or so I heard)... I heard though that newer (Linux) > versions of Intel Compute Stick would have 64bit UEFI but I'm not sure. The Intel Compute sticks can boot both 32 and 64 bit. It doesn't matter if you have the Windows or Linux version. (The difference between the is the amount of RAM and onboard storage, the firmware is the same) I have the Windows one and it boots 64 bit just fine. You can select it in the settings. (OS setting: Windows=32 bit, Linux=64 bit) Jakob From owner-freebsd-current@freebsd.org Wed Mar 2 20:12:36 2016 Return-Path: Delivered-To: freebsd-current@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 EE13CAC28CB for ; Wed, 2 Mar 2016 20:12:35 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 AFA9A1309 for ; Wed, 2 Mar 2016 20:12:35 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1abD8K-001SWe-Kz>; Wed, 02 Mar 2016 21:12:32 +0100 Received: from x55b38056.dyn.telefonica.de ([85.179.128.86] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1abD8K-002zs3-AQ>; Wed, 02 Mar 2016 21:12:32 +0100 Date: Wed, 2 Mar 2016 21:12:25 +0100 From: "O. Hartmann" To: Rainer Hurling Cc: Reko Turja , FreeBSD CURRENT Subject: Re: mounting CIFS share (tcp/445) with FreeBSD and mount_smbfs(8) Message-ID: <20160302211225.73452ba5.ohartman@zedat.fu-berlin.de> In-Reply-To: <56D70065.2010304@gwdg.de> References: <20160301222004.4cdaafc9.ohartman@zedat.fu-berlin.de> <32E522F2674A4DEBBE2492D3A307A0C1@Rivendell> <20160302152939.17333d19@freyja.zeit4.iv.bundesimmobilien.de> <56D70065.2010304@gwdg.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/4.c7B6WdtDYii0REUTJ2swA"; protocol="application/pgp-signature" X-Originating-IP: 85.179.128.86 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 20:12:36 -0000 --Sig_/4.c7B6WdtDYii0REUTJ2swA Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Wed, 2 Mar 2016 16:01:57 +0100 Rainer Hurling schrieb: > Hi Oliver, >=20 > Am 02.03.16 um 15:29 schrieb O. Hartmann: > > On Tue, 1 Mar 2016 23:39:22 +0200 > > "Reko Turja" wrote: > > =20 > >> -----Original Message----- > >> From: O. Hartmann > >> Subject: mounting CIFS share (tcp/455) with FreeBSD and mount_smbfs(8)= =20 > >>> > >>> I need to mount a CIFS share from windows server 2012 r2 via CIFS, tc= p/445 > >>> as NetBIOS service (tcp/139) has been deprecated due to serious > >>> vulnerability issues. . > >>> . > >>> . > >>> I desperately need CIFS and I need tcp/445 since tcp/139 is from now = on > >>> firewalled. =20 > >> > >> There's actually alternative available that's far more UNIX-friendly a= nd not > >> depending on the SAMBA foibles. > >> > >> https://technet.microsoft.com/en-us/library/jj574143.aspx?f=3D255&MSPP= Error=3D-2147217396 > >> > >> Of course, you need to have admin access to the server or get the admi= ns > >> enable NFS on it. > >> > >> -Reko > >> > >> (I've used the Windows NFS the other way around- FreeBSD NFS shares mo= unted > >> with on Win7.) _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.= org" =20 > > > > Using others than CIFS is impossible, I'm dependend on existing service= s. > > Within the next forseable time port tcp/139 gets firewalled. > > > > So far I have compiled NETSMB, SMBFS, LIBMCHAIN and LIBICONV (I think t= he > > latter two are prerequests for NETSMB/SMBFS, didn't find much in the ve= ry > > sparse and unfinished docs for that subject!) into the kernel. > > > > I found this following the exact subject I ran into: > > > > http://agreif.blogspot.de/2014/01/blog-post.html > > > > It doesn't work with either SAMBA 4.3 or Windows Server 2012 R2. Consid= er the > > following situation. > > > > Windows/samba server has IP 10.0.0.1, it's WINS name is locus, its doma= in is > > ASUF the user is pimmel. The passowrd is in /etc/nsmb.conf, > > hashed: > > > > > > [default] > > charsets=3Dutf-8:utf-8 > > > > [LOCUS:PIMMEL] > > address=3D10.0.0.1 > > password=3D$$ajdhasuih57 > > > > The, following the above instructions, the mount_smbfs(8) command would= be > > > > mount_smbfs -I10.0.0.1 -Wasuf -N //pimmel@10.0.0.1:445/share /mnt > > > > If -W is fed with ASUF (all uppercase), I get a strange error: > > > > mount_smbfs: invalid local charset specification (IT4) > > > > Connecting to the SAMBA 4.3 server, and with -Wasuf, I get > > > > mount_smbfs: unable to open connection: syserr =3D RPC struct is bad > > > > Connectingto the Windows 2012 R2 server results in > > > > mount_smbfs: unable to open connection: syserr =3D Connection reset by = peer > > > > First, the manpage for mount_smbfs(8) is everything else than FreeBSD s= tandard! > > There is an unexplained option "-n opt". What is that? > > > > Second, CIFS over tcp/445 seems to be now very(!) common in the Windooz= e world > > - why is that fact not reflected by FreeBSD? I tried to find some > > explanations/manpages for "man netsmb" or "smbfs" (the kernel options),= but > > none found :-( > > > > My interpretation of the above errors are: FreeBSD is incapable to hand= le CIFS > > over tcp/445. The above URL/site claims to have solved the problem, but= it > > seems not true for CURRENT. =20 >=20 > For me, the described scenario works well with base smbfs (on recent=20 > HEAD amd64). My configuration differs in some way from yours. I use recent HEAD (most recent, just recompiled world a minute ago ...) >=20 > GROUPNAME, SERVERNAME, and USERNAME should be written in capital letters= =20 > (?), domainname\\username in small letters (?): I have almost every permutation used by now. Using -WUPPERCASE on the comma= ndline gives me strange errors like: mount_smbfs: invalid local charset specification (IT4), -wlowercase doen't. Using tcp/139 NetBIOS with both Samba 4.3 and Win 2012 R2 works with lowerc= ase username, servername. >=20 >=20 > # ------------------------------------------- > #cat /etc/nsmb.conf > ... > [default] > workgroup=3DGROUPNAME >=20 > [SERVERNAME] > nbns=3Dxxx.xxx.xxx.xxx (IPv4 address) > charsets=3DUTF-8:CP866 > addr=3Dservername.xxx.de >=20 > [SERVERNAME:USERNAME] > username=3Ddomainname\\username > password=3DHASHED_PASSWORD >=20 >=20 > # ------------------------------------------- > My entries in /etc/fstab look like this: > ... > ### Mountpoints for mount_smbfs (of base system) > //username@servername/dir /SMB/DIR smbfs rw,late 0 0 >=20 > [and this also works with port 445:] > //username@servername:445/dir /SMB/DIR smbfs rw,late > 0 0 >=20 >=20 > # ------------------------------------------- > !!! If this was a real hashed password in your mail above, you should=20 > change it ... it isn't ;-) >=20 > HTH and greetings, > Rainer Thanks and kind regards, Oliver --Sig_/4.c7B6WdtDYii0REUTJ2swA Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW10kqAAoJEOgBcD7A/5N8WcsIAIFsGQSFR4dD7fDWhDBugDjU 6+hS5UG1flshV7738be1HBEAFwIjyI7Pt3m9boc8w3RWt4igKNgYfefjtUZLy1cp WbpZtgeM4+Jw2msq9vSoGMkBAw4hp/sVB5Xfi/ISFrCk1a/IpjTwdR8w2Rv77qME GDHzCdJgoEb9a5De27JepZBgNwXDR+I7bUD5bqlykzYH7o1pygo2PwpLuPANECbR 5iEtO4TMZQl3SDii8nEPKgQ+CEZd9Df6m3R/fjrrIxho21gwjpLZH1W3CNuA/pWI MmTUn+pmmVQauFpD9kwcdNj+bLSg0NLJxpv82QT/nAxy7pDwRI25vtlH+Tsn6FY= =mUfN -----END PGP SIGNATURE----- --Sig_/4.c7B6WdtDYii0REUTJ2swA-- From owner-freebsd-current@freebsd.org Wed Mar 2 20:49:52 2016 Return-Path: Delivered-To: freebsd-current@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 7248CAC18FE for ; Wed, 2 Mar 2016 20:49:52 +0000 (UTC) (envelope-from lists@opsec.eu) 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 632A41DFB for ; Wed, 2 Mar 2016 20:49:52 +0000 (UTC) (envelope-from lists@opsec.eu) Received: by mailman.ysv.freebsd.org (Postfix) id 6194FAC18FD; Wed, 2 Mar 2016 20:49:52 +0000 (UTC) Delivered-To: current@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 61395AC18FC for ; Wed, 2 Mar 2016 20:49:52 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (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 2B3ED1DF9 for ; Wed, 2 Mar 2016 20:49:52 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1abDiU-0005Yf-VL; Wed, 02 Mar 2016 21:49:54 +0100 Date: Wed, 2 Mar 2016 21:49:54 +0100 From: Kurt Jaeger To: "Jack L." Cc: current@freebsd.org Subject: Re: Build error on current@r296308: 'yacc.h' file not found Message-ID: <20160302204954.GG79128@home.opsec.eu> References: <20160302190022.GA20540@home.opsec.eu> <20160302194825.GF79128@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 20:49:52 -0000 Hi! > I have the same compilation error when I tried to build current today as well. /usr/src/usr.bin/mkcsmapper/Makefile.inc has the same problem. -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-current@freebsd.org Wed Mar 2 20:52:35 2016 Return-Path: Delivered-To: freebsd-current@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 8BD60AC1B67 for ; Wed, 2 Mar 2016 20:52:35 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) 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 7610A1349 for ; Wed, 2 Mar 2016 20:52:35 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 73C0BAC1B66; Wed, 2 Mar 2016 20:52:35 +0000 (UTC) Delivered-To: current@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 73592AC1B65 for ; Wed, 2 Mar 2016 20:52:35 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 62F891348; Wed, 2 Mar 2016 20:52:35 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 5B33F1543; Wed, 2 Mar 2016 20:52:35 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 1C3171B818; Wed, 2 Mar 2016 20:52:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id 274ZaEhjhh7C; Wed, 2 Mar 2016 20:52:32 +0000 (UTC) Subject: Re: Build error on current@r296308: 'yacc.h' file not found DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 1034F1B813 To: Kurt Jaeger , current@freebsd.org References: <20160302190022.GA20540@home.opsec.eu> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <56D7528E.7030407@FreeBSD.org> Date: Wed, 2 Mar 2016 12:52:30 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160302190022.GA20540@home.opsec.eu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="e8uCX5Ufb4FQL5EdTuUi6wJ2ntQ63d3Ae" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 20:52:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --e8uCX5Ufb4FQL5EdTuUi6wJ2ntQ63d3Ae Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/2/2016 11:00 AM, Kurt Jaeger wrote: > Hi! >=20 > Today, I upgraded to r296308 and had this failure during buildworld: >=20 > =3D=3D=3D> usr.bin/mkesdb_static (obj,build-tools) > cc -O2 -pipe -I/usr/src/usr.bin/mkesdb_static -I/usr/src/usr.bin/mkesdb= _static/../mkesdb -I/usr/src/usr.bin/mkesdb_static/../../lib/libc/iconv = -g -std=3Dgnu99 -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/in= clude -c lex.c -o lex.o > /usr/src/usr.bin/mkesdb_static/../mkesdb/lex.l:44:10: fatal error: 'yac= c.h' file not found > #include "yacc.h" > 1 error generated. > *** Error code 1 >=20 > A 'script' output is available at http://people.freebsd.org/~pi/logs/sr= c-up-2 >=20 > Is it just me or ... ? >=20 My fault. I am working on a fix. --=20 Regards, Bryan Drewery --e8uCX5Ufb4FQL5EdTuUi6wJ2ntQ63d3Ae Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJW11KOAAoJEDXXcbtuRpfPFI0H/irrNYRpUy5J8ow4g+cRBXzH O3ib8WAELR2+U9xondsWkbq2DuyNv6IcKcnWN3jihFLEGdnOrYgufPFuEzL1RNGp zuIHf3Q4/Okw4iXKmGMkODCcJdr+lPEwPE0LnfFTXljOxNFGGM5vl8/9UB1NydOg jn7XzmS2B99lk0QBLzolj8mEJ5VyKBukcWXrtKxuVv8A38QFt/4CUhLBusvxKufL COtmXezCFoP1ouaF86QDSCJdGvBySJeFEWCHEDd+3zfJr56OFBY1fp5EdPkisxxe mNYmhut79hVm0XjAcHCIT3pWhJkQ33R9aH1WOPFnkZ77tiXRazcTsIjxEq5zoEo= =l7pL -----END PGP SIGNATURE----- --e8uCX5Ufb4FQL5EdTuUi6wJ2ntQ63d3Ae-- From owner-freebsd-current@freebsd.org Wed Mar 2 21:04:17 2016 Return-Path: Delivered-To: freebsd-current@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 94E7EAC026C for ; Wed, 2 Mar 2016 21:04:17 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) 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 7F2BC1F29 for ; Wed, 2 Mar 2016 21:04:17 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7B3A0AC026B; Wed, 2 Mar 2016 21:04:17 +0000 (UTC) Delivered-To: current@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 7AD3AAC026A for ; Wed, 2 Mar 2016 21:04:17 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 6A7001F28; Wed, 2 Mar 2016 21:04:17 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 626AC19F1; Wed, 2 Mar 2016 21:04:17 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 2206B1B863; Wed, 2 Mar 2016 21:04:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id RLLR1o1L_0gn; Wed, 2 Mar 2016 21:04:11 +0000 (UTC) Subject: Re: Build error on current@r296308: 'yacc.h' file not found DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 7922A1B85E To: Kurt Jaeger , current@freebsd.org References: <20160302190022.GA20540@home.opsec.eu> <56D7528E.7030407@FreeBSD.org> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <56D7554B.9060109@FreeBSD.org> Date: Wed, 2 Mar 2016 13:04:11 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56D7528E.7030407@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lJLAbQQ8cMjb4PccdjWiwTsW1ubw6g85b" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 21:04:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lJLAbQQ8cMjb4PccdjWiwTsW1ubw6g85b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/2/2016 12:52 PM, Bryan Drewery wrote: > On 3/2/2016 11:00 AM, Kurt Jaeger wrote: >> Hi! >> >> Today, I upgraded to r296308 and had this failure during buildworld: >> >> =3D=3D=3D> usr.bin/mkesdb_static (obj,build-tools) >> cc -O2 -pipe -I/usr/src/usr.bin/mkesdb_static -I/usr/src/usr.bin/mkesd= b_static/../mkesdb -I/usr/src/usr.bin/mkesdb_static/../../lib/libc/iconv= -g -std=3Dgnu99 -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/i= nclude -c lex.c -o lex.o >> /usr/src/usr.bin/mkesdb_static/../mkesdb/lex.l:44:10: fatal error: 'ya= cc.h' file not found >> #include "yacc.h" >> 1 error generated. >> *** Error code 1 >> >> A 'script' output is available at http://people.freebsd.org/~pi/logs/s= rc-up-2 >> >> Is it just me or ... ? >> >=20 > My fault. I am working on a fix. >=20 Fixed in r296324. --=20 Regards, Bryan Drewery --lJLAbQQ8cMjb4PccdjWiwTsW1ubw6g85b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJW11VLAAoJEDXXcbtuRpfPALMIAKJp7I+IonrGvP57g0lPECM9 Kde1Zp8efg8YasfI6VcE1iODu7FnudKIqyISk1ZkL7M2AUA7mWUOzE3bsttXM0em 8YnwUM1nqdTX7RxG7i9qYSzO+RgM0cNSwttOKGUy29qGuHlfbILzYI3t2p6mPMmb c3i0MzOkA/oaE8FrvHU7R9jnrOFv+3DxYq4PVl6/CN/6g2SnyJ+kRelzRcV/osvl UTNZlMrZLOiz655IbC/JXjlB8jSM+Q2gG6dZq1WKwYo3TslYDHmhWh+bkWVpi4EA R0L0N/iy/3kAx27I7COBtuXbGvWymMew3W5aN+jEb7VTxjxkyOJwoC7sMudVMfM= =36qH -----END PGP SIGNATURE----- --lJLAbQQ8cMjb4PccdjWiwTsW1ubw6g85b-- From owner-freebsd-current@freebsd.org Wed Mar 2 21:17:38 2016 Return-Path: Delivered-To: freebsd-current@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 C0841AC0755 for ; Wed, 2 Mar 2016 21:17:38 +0000 (UTC) (envelope-from dave@dogwood.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 A62F315C1 for ; Wed, 2 Mar 2016 21:17:38 +0000 (UTC) (envelope-from dave@dogwood.com) Received: by mailman.ysv.freebsd.org (Postfix) id A22E3AC0754; Wed, 2 Mar 2016 21:17:38 +0000 (UTC) Delivered-To: current@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 A1C2DAC0753 for ; Wed, 2 Mar 2016 21:17:38 +0000 (UTC) (envelope-from dave@dogwood.com) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::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 7DB9A15C0 for ; Wed, 2 Mar 2016 21:17:38 +0000 (UTC) (envelope-from dave@dogwood.com) Received: by mail-yk0-x22c.google.com with SMTP id 1so821853ykg.3 for ; Wed, 02 Mar 2016 13:17:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dogwood.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=p8kYrNzRubIEwgOFKKFkiRHqSw9RbUWSZ1V8dm1Wpmo=; b=KxevzAiVxv6j/twT7i9TNzlRqOqY6uJozXbfkqYD5w/c3wmlg2B4K3oTovkyVPHcJd PAtFv/jUq55IpCR8tyibFvZfplsSdI+PFc4b23uVg9RxG5dCrH109UM1+8OwjjIBjvu1 eS1gR57ohMVFGy64VX0qoyebmqVJ3ZTdMayUs= 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:date :message-id:subject:from:to:cc; bh=p8kYrNzRubIEwgOFKKFkiRHqSw9RbUWSZ1V8dm1Wpmo=; b=VK6r/SEebAf9fdylH8CP5lNoUiR9G9fdetYLTfrf0fPU7CKpHzKMaXjJDYfqQaooLH htBBTNrgHjHYiAOserm4h6r2wzOaE1i/nlzLPsTzXvaEnmgnNg7Q02G+7IV09lPfVI1G mb766EAu4YRtGsznSKMJ8c2CVzXOpjewMqXXONQLtLnerxLMhGBBxW8PPqwWtO0xJCe1 ACfnhhdT2yqMINugPBjJULnFZZD8dbz7YVAhVz1eD4PRyisG7CMsWHrFHtyMy/FxyV8h PqyVQXTZXtfL7siYGXka31GGyDr8I6QjTcOBqmnjKMrQJkAMllkf1j0R08XYL2SgfNX6 HZOQ== X-Gm-Message-State: AD7BkJIPo7cokJv+CIeFaybN9ECia5VCUc95q4RSATCfBOhg50rqN7iH6d5OStmjRdLnDae9xmCG6ITMlSaMybwB MIME-Version: 1.0 X-Received: by 10.37.32.4 with SMTP id g4mr15955219ybg.66.1456953457488; Wed, 02 Mar 2016 13:17:37 -0800 (PST) Received: by 10.13.205.129 with HTTP; Wed, 2 Mar 2016 13:17:37 -0800 (PST) In-Reply-To: <56D7554B.9060109@FreeBSD.org> References: <20160302190022.GA20540@home.opsec.eu> <56D7528E.7030407@FreeBSD.org> <56D7554B.9060109@FreeBSD.org> Date: Wed, 2 Mar 2016 11:17:37 -1000 Message-ID: Subject: Re: Build error on current@r296308: 'yacc.h' file not found From: David Cornejo To: Bryan Drewery Cc: Kurt Jaeger , "current@FreeBSD.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 21:17:38 -0000 On Wed, Mar 2, 2016 at 11:04 AM, Bryan Drewery wrote: > On 3/2/2016 12:52 PM, Bryan Drewery wrote: >> On 3/2/2016 11:00 AM, Kurt Jaeger wrote: >>> Hi! >>> >>> Today, I upgraded to r296308 and had this failure during buildworld: >>> >>> ===> usr.bin/mkesdb_static (obj,build-tools) >>> cc -O2 -pipe -I/usr/src/usr.bin/mkesdb_static -I/usr/src/usr.bin/mkesdb_static/../mkesdb -I/usr/src/usr.bin/mkesdb_static/../../lib/libc/iconv -g -std=gnu99 -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -c lex.c -o lex.o >>> /usr/src/usr.bin/mkesdb_static/../mkesdb/lex.l:44:10: fatal error: 'yacc.h' file not found >>> #include "yacc.h" >>> 1 error generated. >>> *** Error code 1 >>> >>> A 'script' output is available at http://people.freebsd.org/~pi/logs/src-up-2 >>> >>> Is it just me or ... ? >>> >> >> My fault. I am working on a fix. >> > > Fixed in r296324. > > -- > Regards, > Bryan Drewery > fix worked, thank you for quick resolution! dave c From owner-freebsd-current@freebsd.org Wed Mar 2 21:25:34 2016 Return-Path: Delivered-To: freebsd-current@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 53A9DAC0B21 for ; Wed, 2 Mar 2016 21:25:34 +0000 (UTC) (envelope-from ken@kdm.org) 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 3EFB91E53 for ; Wed, 2 Mar 2016 21:25:34 +0000 (UTC) (envelope-from ken@kdm.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3A2D1AC0B1F; Wed, 2 Mar 2016 21:25:34 +0000 (UTC) Delivered-To: current@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 399EEAC0B1D; Wed, 2 Mar 2016 21:25:34 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1638D1E52; Wed, 2 Mar 2016 21:25:33 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPS id u22LPPa5006990 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 2 Mar 2016 16:25:25 -0500 (EST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.15.2/8.14.9/Submit) id u22LPPPD006989; Wed, 2 Mar 2016 16:25:25 -0500 (EST) (envelope-from ken) Date: Wed, 2 Mar 2016 16:25:25 -0500 From: "Kenneth D. Merry" To: Scott Long Cc: scsi@freebsd.org, current@freebsd.org Subject: Re: CAM Shingled Disk support patches available Message-ID: <20160302212525.GA5920@mithlond.kdm.org> References: <20151118171309.GA3564@mithlond.kdm.org> <20160118223704.GA87506@mithlond.kdm.org> <20160301224758.GA86834@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Wed, 02 Mar 2016 16:25:25 -0500 (EST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mithlond.kdm.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 21:25:34 -0000 On Tue, Mar 01, 2016 at 20:07:19 -0700, Scott Long wrote: > Hi Ken, > > I???m against changing the function signature of scsi_ata_pass_16(). Even > if you manage to get things right with symbol versioning, it still leads to > problems of code compatibility. Maybe pre-existing binaries will work, but > source code will forever have to include an #if __FreeBSD_version < > xxxxxx bit of nonsense. Good point, that would be annoying. > I agree that it was incorrect for dxferlen to be declared as a uint16_t. > However, the function already contains a sector count argument pair. In > theory the sector count multiplied by the sector length, both of which the > application should know in order to arrive at a sensible dxferlen, can > substitute for the dxferlen argument. If so, then we can just ignore that > argument and declare that sector_count has logical priority. Okay. That will probably work for the most part. > Really though, I think that scsi_ata_pass_16() is a crummy function. If its > purpose is to implement SAT-3 12.2.2, it does an incredibly poor job at it: > > - By my count, it only covers 12 of the available 13 registers. > > - It has no 12 byte, opcode 0xa1 variant. > > - It doesn???t make any allowance for providing the response registers to the > caller on completion. Well, maybe it kinda does through a sense descriptor, > but???. it???s kinda open to vague interpretation. > > - Its use of the registers is clunky, assuming for example that you???ll only want > to fill the six LBA registers with a host-ordered 64-bit number. There are > plenty of commands that re-use sub-parts of the LBA, features, and/or sector > count registers for different things. > > I know you stated that you didn???t want to do this, but I think it???s better to start > over with a better function that has a better signature and a new name. In fact, > I think it???s better to use the existing ata_cmd and ata_res structures from > sys/cam/ata/ata_all.h, provide accessors for the multi-byte registers if needed, > provide a 12-byte compatibility, and simply the signature. Something like this: > > void scsi_ata_pass(struct ccb_scsiio *csio, u_int32_t retries, > void (*cbfcnp)(struct cam_periph *, union ccb *), > u_int32_t flags, u_int8_t tag_action, > struct ata_cmd *cmd, struct ata_res *res, > u_int8_t *data_ptr, u_int32_t dxfer_len, > u_int8_t *data_ptr, u_int16_t dxfer_len, I assume you only intended one line there, not two. :) > u_int8_t sense_len, u_int32_t timeout); > > To differentiate between the 12 and 16 byte variants, you???d look at the > AP_EXTEND flag in the protocol field. Btw, the handling of that flag is > inconsistent in the implementation of the existing scsi_ata_pass_16(). If > the caller providse an ata_res pointer then it gets filled on completion, > otherwise the caller does its best to look at 12.2.2.6 and extract what it > can from the sense descriptor. > > So my proposal is to create a new scsi_ata_pass and deprecate but not remove > scsi_ata_pass_16. Tell people that if they need to use it, dxfer_len is going to > have lower priority than sector_count/sector_count_exp if the latter multiply to > more than 65535. In general I think that's a reasonable idea, but we should probably go further. While we're at it, we should figure out what we need to do to add the Auxiliary register to struct ata_cmd. We'll need that to do the NCQ versions of the various SMR commands, as well as TRIM. The obvious challenge is that probably means changing the existing struct ccb_ataio CCB and bumping the CAM version. At least that will be source compatible, but will require ifdefs if people want to compile on older versions of FreeBSD. But in that case, they'll also be faced with no support for sending the NCQ versions of the commands, anyway. No way around that, though, since we have to follow the changing specs. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@freebsd.org Wed Mar 2 22:18:14 2016 Return-Path: Delivered-To: freebsd-current@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 90513AC1E82 for ; Wed, 2 Mar 2016 22:18:14 +0000 (UTC) (envelope-from mail@m.jwh.me.uk) Received: from eva.tinkyfi.com (eva.tinkyfi.com [107.191.63.190]) by mx1.freebsd.org (Postfix) with ESMTP id 5BB1112D9; Wed, 2 Mar 2016 22:18:13 +0000 (UTC) (envelope-from mail@m.jwh.me.uk) Received: from [172.21.88.129] (cpc82705-staf9-2-0-cust342.3-1.cable.virginm.net [81.108.23.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mail@m.jwh.me.uk) by eva.tinkyfi.com (Postfix) with ESMTPSA id 3qFqTb3RPsz5Hj9; Wed, 2 Mar 2016 22:18:11 +0000 (UTC) Subject: Re: Bay Trail 32bit UEFI To: "Lundberg, Johannes" , Jakob Alvermark References: <56D29AF6.50401@m.jwh.me.uk> <4073395.HnTjdCHcSr@ralph.baldwin.cx> <56D6BC03.2040508@m.jwh.me.uk> <18013.85.229.93.153.1456947431.squirrel@webmail.alvermark.net> Cc: John Baldwin , FreeBSD Current From: Joe Holden Message-ID: <56D766A1.3000702@m.jwh.me.uk> Date: Wed, 2 Mar 2016 22:18:09 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 22:18:14 -0000 On 02/03/2016 19:45, Lundberg, Johannes wrote: > On Wed, Mar 2, 2016 at 11:37 AM, Jakob Alvermark > wrote: > > On Wed, March 2, 2016 20:00, Lundberg, Johannes wrote: > > On Wed, Mar 2, 2016 at 2:10 AM, Joe Holden > wrote: > > > > > >> On 02/03/2016 01:45, Lundberg, Johannes wrote: > >> > >> > >>> CherryTrail devices/boards with 64bit UEFI are already out. Upgrading > >>> the hardware is one solution (I did). > >>> > >>> I'm thinking of the sticks etc, they all have 32bit UEFI and no > >>> > >> CSM/legacy boot, but have 64bit cpus > >> > > > > > > > > Yeah and it sucks. All to adapt to Microsoft who couldn't make 64bit UEFI > > boot loader in time (or so I heard)... I heard though that newer (Linux) > > versions of Intel Compute Stick would have 64bit UEFI but I'm not sure. > > The Intel Compute sticks can boot both 32 and 64 bit. It doesn't > matter if > you have the Windows or Linux version. (The difference between the > is the > amount of RAM and onboard storage, the firmware is the same) > > I have the Windows one and it boots 64 bit just fine. > You can select it in the settings. (OS setting: Windows=32 bit, > Linux=64 bit) > > > That's great. However, as for all other BayTrail devices out there that > does not support Linux officially I think you're stuck with 32bit. > > > Jakob > My point was that it is possible to boot amd64 bit kernels from 32bit UEFI, grub (and therefore, linux) does it. I think even openbsd at least has a 32bit loader, I'd settle for 32bit but the problem is I can't easily boot it. From owner-freebsd-current@freebsd.org Wed Mar 2 22:30:52 2016 Return-Path: Delivered-To: freebsd-current@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 137A0AC238D; Wed, 2 Mar 2016 22:30:52 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id B5E6B1D1F; Wed, 2 Mar 2016 22:30:51 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: SVN r296272 breaks virtualbox To: Michael Butler , freebsd-current References: <56D617D1.5040209@protected-networks.net> Cc: "freebsd-emulation@freebsd.org" From: Jung-uk Kim Message-ID: <56D7699B.10602@FreeBSD.org> Date: Wed, 2 Mar 2016 17:30:51 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56D617D1.5040209@protected-networks.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 22:30:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/ 1/16 05:29 PM, Michael Butler wrote: > The removal of "taskqueue_enqueue_fast" breaks the virtualbox > kmods: > > Mar 1 16:54:36 toshi kernel: vboxdrv: fAsync=0 offMin=0x914 > offMax=0x151c Mar 1 16:54:36 toshi kernel: link_elf_obj: symbol > taskqueue_enqueue_fast undefined Mar 1 16:54:36 toshi kernel: > linker_load_file: Unsupported file type Mar 1 16:54:36 toshi > kernel: link_elf_obj: symbol taskqueue_enqueue_fast undefined Mar > 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type > Mar 1 16:54:36 toshi kernel: KLD vboxnetadp.ko: depends on > vboxnetflt - not available or version mismatch Mar 1 16:54:36 > toshi kernel: linker_load_file: Unsupported file type It should be fixed now (r409965). Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW12mUAAoJEHyflib82/FGjCoIAI7SgVEn4KsODrF4/y/Aifp1 vw9jDQ9oGo7z3zRKk7C14/tLeS6Z+GjrfZldKOJBZHKoWLlzs9+WCpXmESez10Kj 0nR3dbk2RHAE0iHFqwz7jzzANGu/eZohsgQ44a7ZhZcnrlUchGLCIz3eZMQWctYz KFUHLewYbr0/nBn/HB5G/5LI/DEBvhlxgplfjOFyvjZXXeYWot3q2cUvhNUjWQMf B3iqXmeMQmQ4lHPA/GkIDpIUwhi0sSn8FoaaV+dF13MU023lBE//klcUn5GbYd4Y 4DkLzZJKy4gpfdKelkSU8GUAVERRKonxkROtRRvt9eioE8IpEcT2KDMkshEmXFU= =Fj+q -----END PGP SIGNATURE----- From owner-freebsd-current@freebsd.org Wed Mar 2 23:54:31 2016 Return-Path: Delivered-To: freebsd-current@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 58C43AC12E8; Wed, 2 Mar 2016 23:54:31 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 4AA7D1E2B; Wed, 2 Mar 2016 23:54:31 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id BEF2C1A3A; Wed, 2 Mar 2016 23:54:30 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Wed, 2 Mar 2016 23:54:29 +0000 From: Glen Barber To: freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org Subject: [CFT] packaging the base system with pkg(8) Message-ID: <20160302235429.GD75641@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MIdTMoZhcV1D07fI" Content-Disposition: inline X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 23:54:31 -0000 --MIdTMoZhcV1D07fI Content-Type: multipart/mixed; boundary="d9ADC0YsG2v16Js0" Content-Disposition: inline --d9ADC0YsG2v16Js0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline For those who have missed the initial email surrounding this topic, we are planning on packaging the base system with pkg(8) for 11.0-RELEASE. https://lists.freebsd.org/pipermail/freebsd-pkgbase/2016-January/000000.html At this time, I believe the major blockers and critical issues have been resolved where it is time for an official call-for-testing. Please note, as with any development branch, this is not yet intended for production environments. Testing on virtual machines or dedicated testing machines is strongly encouraged. Also note (as repeated below), running 'pkg delete -a' will implicitly remove base system packages after they are installed. To obtain the sources for testing, please use the projects/release-pkg branch: # svn co svn://svn.freebsd.org/base/projects/release-pkg /usr/src The projects/release-pkg branch is (at this time) in sync with head revision r296327. After checking out the project branch, build the userland and kernel as normal with the 'buildworld' and 'buildkernel' targets. Afterward, packages can be created with the 'packages' target. # cd /usr/src # make [make flags] buildworld # make [make flags] buildkernel # make packages At present, the base system consists of 755 packages with the default build (empty src.conf(5) and make.conf(5)) for amd64. The number of packages depends on several factors, but for most cases a runtime binary is split into several components. In particular, most shared libraries are individually packaged, in addition to debugging symbols, profiling libraries, and 32-bit packaged separately. The package repository will be created within /usr/obj/usr/src/repo by default. To enable the repository, create /usr/local/etc/pkg/repos/base.conf with the following contents: # FreeBSD base system repository FreeBSD-base: { url: "file:///usr/obj/usr/src/repo/${ABI}/latest", mirror_type: "none", enabled: yes } To initially bootstrap the 'FreeBSD-*' packages, they must be forcibly installed. Package registration is not performed during 'installworld' or 'installkernel', and there are no immediate plans to do this. This can be done by running: # pkg update -r FreeBSD-base # pkg install -g 'FreeBSD-*' Please note the following: 1) The pkg(8) binary is required for this to work, however an additional patch against the ports-mgmt/pkg port is required to properly track base system shared libraries. The patch against the ports-mgmt/pkg port is attached. In my testing, excluding this patch has not caused anything horrible to happen, however applying both patches is suggested at this point. The main noticeable effect of excluding the patch is system binary packages and their dependent library packages are not directly linked, which makes it possible to delete a library package that is required by a runtime binary. 2) At present, running 'pkg delete -a' will implicitly remove the 'FreeBSD-*' packages, leaving the system in an unusable state. There are valid use cases for removing all packages, such as test chroot(8) or jail(8) environments, so a solution to avoid accidental foot shooting is still being investigated. 3) With the attached patch, /lib32 and /usr/lib32 shared libraries are not tracked. Since they are optional and do not affect the default running userland, this should not prevent testing, however it is worth noting. 4) For kernel packages, the first listed kernel in KERNCONF is installed as /boot/kernel, and subsequent kernels in KERNCONF are installed as /boot/kernel.${KERNEL}. Building GENERIC is not required, as each kernel package is named with the kernel name included. For example, if 'KERNCONF=MYLOCALKERNEL' is set in make.conf(5), the resulting kernel package will be 'FreeBSD-kernel-mylocalkernel-release', and the debug symbols as 'FreeBSD-kernel-mylocalkernel-debug'. 5) There are still a few outstanding issues with configuration file merging, which is still being investigated. Please follow up on the freebsd-pkgbase@ mailing list with problems (and successes). Many suggestions were made, such as further granularity between runtime binaries and daemons (rwho(1) and rwhod(8) is one example I recall off-hand), that have not been implemented yet (and also not forgotten). Thank you in advance to everyone that can test this, so we can get this completed in time for 11.0-RELEASE. Glen --d9ADC0YsG2v16Js0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pkgpatch.diff.txt" Content-Transfer-Encoding: quoted-printable Index: ports-mgmt/pkg/files/patch-libpkg_pkg__config.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- ports-mgmt/pkg/files/patch-libpkg_pkg__config.c (nonexistent) +++ ports-mgmt/pkg/files/patch-libpkg_pkg__config.c (working copy) @@ -0,0 +1,15 @@ +--- libpkg/pkg_config.c.orig 2016-01-26 23:32:05 UTC ++++ libpkg/pkg_config.c +@@ -390,6 +390,12 @@ static struct config_entry c[] =3D { + "VALID_URL_SCHEME", + "pkg+http,pkg+https,https,http,ftp,file,ssh", + }, ++ { ++ PKG_BOOL, ++ "ALLOW_BASE_SHLIBS", ++ "NO", ++ "Enable base libraries analysis", ++ }, + }; +=20 + static bool parsed =3D false; Index: ports-mgmt/pkg/files/patch-libpkg_pkg__elf.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- ports-mgmt/pkg/files/patch-libpkg_pkg__elf.c (nonexistent) +++ ports-mgmt/pkg/files/patch-libpkg_pkg__elf.c (working copy) @@ -0,0 +1,40 @@ +--- libpkg/pkg_elf.c.orig 2015-09-21 08:53:23 UTC ++++ libpkg/pkg_elf.c +@@ -85,23 +85,28 @@ static int + filter_system_shlibs(const char *name, char *path, size_t pathlen) + { + const char *shlib_path; ++ bool packaging_base =3D pkg_object_bool(pkg_config_get("ALLOW_BASE_SHLIB= S")); +=20 +- shlib_path =3D shlib_list_find_by_name(name); +- if (shlib_path =3D=3D NULL) { +- /* dynamic linker could not resolve */ +- return (EPKG_FATAL); ++ if (!packaging_base) { ++ shlib_path =3D shlib_list_find_by_name(name); ++ if (shlib_path =3D=3D NULL) { ++ /* dynamic linker could not resolve */ ++ return (EPKG_FATAL); ++ } + } +=20 +- /* match /lib, /lib32, /usr/lib and /usr/lib32 */ +- if (strncmp(shlib_path, "/lib", 4) =3D=3D 0 || +- strncmp(shlib_path, "/usr/lib", 8) =3D=3D 0) +- return (EPKG_END); /* ignore libs from base */ ++ if (!packaging_base) { ++ /* match /lib, /lib32, /usr/lib and /usr/lib32 */ ++ if (strncmp(shlib_path, "/lib", 4) =3D=3D 0 || ++ strncmp(shlib_path, "/usr/lib", 8) =3D=3D 0) ++ return (EPKG_END); /* ignore libs from base */ ++ } +=20 + if (path !=3D NULL) + strncpy(path, shlib_path, pathlen); +=20 + return (EPKG_OK); +-}=20 ++} +=20 + /* ARGSUSED */ + static int --d9ADC0YsG2v16Js0-- --MIdTMoZhcV1D07fI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW1301AAoJEAMUWKVHj+KT+rwP/3NogwgInBqdjhcsfjE8mCVa ZfrIm8JB6Rrlq53W3T6TTvcGMCZSzSowXL7l5doxJO9FbToU9md1A0iELv0VTQks lgSzQOuArYzRINI9H/PLlmIaMlCJPvk4KJyvZkIj9QgY8Bhmr1AQKNG3KvXBzxo+ NvaKET8GDnbriALn4zaAWNxquPIWCmjsvTg+/B8C40yvyr0roEZbMCH7MFP//lBv B3Ah3UYp8jdtQ5x7d5tCVy919W4cZsHSWWxMdSA6GPbdbxvScVT14v6fTi/jWdQP WaewRsOK22vmoZj0F/oVaQmg9tBCHTiSN5J7cXd7zWNO6LQr+Rfk5xQBgi2SRYdq l5bkr3XmJC3TggYecPNqUDw+CAq/U+KkVqw4Zc8I2aZJW/e1EqMO8fTKUu5Ce8L9 iYKkymHjTPgye/o3rAfHWb7iK3N0vNtdUEShyYStAK3UMOD0NJwDsjrhuQy8P453 2tXxm9JZ2Sdo+Psnf62NgzBwEprkZdENhuFnvYxIOYbij3x5Sf6R0CYgw0TodF6f 9M4J4iINh7fuNORhutjmroSTfGffx5SNQ9fjtk1YV4txRCVi6NsLqedePEQ1S5K0 lEH2ozwr4nv/UNb4RPN/YanbPXOjlbQltDN+3OqWBNwyWM/966zR4KKlCHN9yKnx iR5GzudtG3KrxSAdBUAu =HWlk -----END PGP SIGNATURE----- --MIdTMoZhcV1D07fI-- From owner-freebsd-current@freebsd.org Thu Mar 3 02:23:44 2016 Return-Path: Delivered-To: freebsd-current@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 839A3AC108D; Thu, 3 Mar 2016 02:23:44 +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 76B1F1B29; Thu, 3 Mar 2016 02:23:44 +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 83115A3E; Thu, 3 Mar 2016 02:23:44 +0000 (UTC) Date: Thu, 3 Mar 2016 02:23:42 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jhibbits@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1214799324.181.1456971824500.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1532402484.179.1456961857741.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1532402484.179.1456961857741.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #2496 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 02:23:44 -0000 FreeBSD_HEAD_i386 - Build #2496 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2496/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2496/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2496/console Change summaries: 296331 by jhibbits: Let rman_init() initialize the default rman range. If rm_start and rm_end are both 0 on input to rman_init(), rman_init() pre-initializes them to the default range. No need to set it before. 296330 by jhibbits: Another convert to bus_alloc_resource_anywhere(). Depending on how cbus hands out resources, this could actually be bus_alloc_resource_any() instead. 296329 by jhibbits: Allocate the PCI BAR resource with bus_alloc_resource_any() We don't support allocating any other range with PCI BARs. From owner-freebsd-current@freebsd.org Thu Mar 3 04:40:58 2016 Return-Path: Delivered-To: freebsd-current@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 33B7CAC25F8 for ; Thu, 3 Mar 2016 04:40:58 +0000 (UTC) (envelope-from scott4long@yahoo.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 168721016 for ; Thu, 3 Mar 2016 04:40:58 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: by mailman.ysv.freebsd.org (Postfix) id 1581BAC25F3; Thu, 3 Mar 2016 04:40:58 +0000 (UTC) Delivered-To: current@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 150A2AC25F2 for ; Thu, 3 Mar 2016 04:40:58 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm13-vm4.bullet.mail.gq1.yahoo.com (nm13-vm4.bullet.mail.gq1.yahoo.com [98.136.218.223]) (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 E58201014 for ; Thu, 3 Mar 2016 04:40:57 +0000 (UTC) (envelope-from scott4long@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1456979648; bh=WrFp9V/33FP1bsmF71UyyvBcSlbjuUb+r1vGM1zpmGg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=cd+ODG2dIsA2LujYbbnOzsgVcdaFx9ZjkTeUBts+Ulhw+9lzosrlWTmVejlJdsZXvMreHZLMDh1vewyOmtWXHk3oh7EU8Zn+QMH4pT6qm3ES5/4IRAT51NaKJFa5W6OFIAEXUVN3u4mHOwWdV4w0uRAYXaY1H48rtIN0wRqBkmutADUaa5CEl14vudh8ASP7DXpMDtxmusZfFZcYgBj1gOhAJ+QE9TSgehyo9qLfU5sNDlYPmVg1xG45j/HjD3rF6u489ltGEtrSBoMPUPAgotO6YCS4EqZLRhQn6lCH/1FEyv//bYapoHrG542Ae/vZVny/JCqSqp/HVgNUw4ZzXA== Received: from [98.137.12.62] by nm13.bullet.mail.gq1.yahoo.com with NNFMP; 03 Mar 2016 04:34:08 -0000 Received: from [208.71.42.193] by tm7.bullet.mail.gq1.yahoo.com with NNFMP; 03 Mar 2016 04:34:08 -0000 Received: from [127.0.0.1] by smtp204.mail.gq1.yahoo.com with NNFMP; 03 Mar 2016 04:34:08 -0000 X-Yahoo-Newman-Id: 214424.84781.bm@smtp204.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: WOvY3psVM1mdxXpbsNSZCHMK3IcoNYxTKiQRIHglkua2SqL wlr_D694MaVtAl6ZSrinNnQmMm_w.QtgxThnea095M_Tx3unjMUh1ufPRGlh xtJCHG5czo_LweuXHT98B4gBiBVAD4U72VcVHpNOWlIP9B1QGtq7ta9EAppj .G0iIXjZx4mme00VNJ7GDkhvlwdm9u8qH5spv28_b_1F8qch.jgWPCeRQP.G BWf3DGJtaeRdRIEkmsYUc4iQawi5GMpZgACeWIB802a9XRONTipRkgPKLdZT TBlji5a80R0N2Vx.Lie.W3h9rO6eUWhKKPFx0jW9zACbUeAOYtgnXdsk5BV0 il14i0m8Y3wSfKygKvIs4TZT3uASeWRZMs33B2Y5VOXyyE3g47NWPXCyYVBJ 0nAqsn3fJjC54yATeQHC4viI7bJzVvuiKvZqoeA.PExJSHxtUnzY_gqu0ZKa 1s48yWzK_PvLDUokEIBqoqoy8TavkTspu8G58jw_2R6.u3tUc3mpxubIKWze G6JI3P2OZA9DzaS0zxwYKT5e36m7N.uokWRD3ayGR X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: CAM Shingled Disk support patches available From: Scott Long In-Reply-To: <20160302212525.GA5920@mithlond.kdm.org> Date: Wed, 2 Mar 2016 21:34:05 -0700 Cc: scsi@freebsd.org, current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151118171309.GA3564@mithlond.kdm.org> <20160118223704.GA87506@mithlond.kdm.org> <20160301224758.GA86834@mithlond.kdm.org> <20160302212525.GA5920@mithlond.kdm.org> To: "Kenneth D. Merry" X-Mailer: Apple Mail (2.3112) X-Mailman-Approved-At: Thu, 03 Mar 2016 04:55:34 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 04:40:58 -0000 > On Mar 2, 2016, at 2:25 PM, Kenneth D. Merry wrote: >=20 >>=20 >>=20 >> void scsi_ata_pass(struct ccb_scsiio *csio, u_int32_t retries, >> void (*cbfcnp)(struct cam_periph *, union ccb = *), >> u_int32_t flags, u_int8_t tag_action, >> struct ata_cmd *cmd, struct ata_res *res, >> u_int8_t *data_ptr, u_int32_t dxfer_len, >> u_int8_t *data_ptr, u_int16_t dxfer_len, >=20 > I assume you only intended one line there, not two. :) >=20 Indeed =3D-) >> u_int8_t sense_len, u_int32_t timeout); >>=20 >> To differentiate between the 12 and 16 byte variants, you???d look at = the >> AP_EXTEND flag in the protocol field. Btw, the handling of that flag = is >> inconsistent in the implementation of the existing = scsi_ata_pass_16(). If >> the caller providse an ata_res pointer then it gets filled on = completion, >> otherwise the caller does its best to look at 12.2.2.6 and extract = what it >> can from the sense descriptor. >>=20 >> So my proposal is to create a new scsi_ata_pass and deprecate but not = remove >> scsi_ata_pass_16. Tell people that if they need to use it, dxfer_len = is going to >> have lower priority than sector_count/sector_count_exp if the latter = multiply to >> more than 65535. >=20 > In general I think that's a reasonable idea, but we should probably go > further. >=20 > While we're at it, we should figure out what we need to do to add the > Auxiliary register to struct ata_cmd. We'll need that to do the NCQ > versions of the various SMR commands, as well as TRIM. >=20 Warner and I talked about this, and I thought that at one point we had a = patch that defined a =E2=80=98struct ata_cmd_aux=E2=80=99. As with function = signatures, I=E2=80=99m very much against redefining structures, and I think it=E2=80=99s reasonable = to create a new structure for what=E2=80=99s basically a late addition to the specs. = I need to read more of the draft ACS and SATA specs to see if there=E2=80=99s anything = else on the horizon that should also be included. However, and I talk a little bit = about this below, I think the situation is a bit more complicated than just = adding a field to the structure. The ata_cmd structure mostly models what=E2=80=99= s in an ATA taskfile, and the taskfile definition, whether from ACS or APT, has = never been expanded to include the aux (and aux_exp) registers. They exist = only in SATA as part of the Device-to-Host (D2H) FIS. However, I=E2=80=99m = kinda back and forth on this; maybe my interpretation of ata_cmd is too strict, and = we can stick in whatever is needed and let the SIM deal with it. At one point I had some patches that defined the various FIS packets and allowed the periphs to send in an XPT_SATA_FIS instead of an XPT_ATA_IO, but it seemed to not provide much value since most drivers (and hardware) still operate in terms of legacy ATA = taskfiles. It also wasn=E2=80=99t clear in the scheme of driving I/O via a FIS = where the responsibility of the periph stopped and the SIM started; If the periph sends a H2D FIS to initiate an I/O, does it need to then drive the PIO and/or DMA FIS=E2=80=99s as well? The FIS is really in the realm of the = transport, not the protocol, and it=E2=80=99s a huge shame that ATA is starting to = blur the lines by having the FIS Aux registers be part of the protocol. > The obvious challenge is that probably means changing the existing = struct > ccb_ataio CCB and bumping the CAM version. At least that will be = source > compatible, but will require ifdefs if people want to compile on older > versions of FreeBSD. But in that case, they'll also be faced with no > support for sending the NCQ versions of the commands, anyway. No way > around that, though, since we have to follow the changing specs. >=20 Again, not a fan of redefining the structures. A couple of other thoughts here. Steve Hartland was right about not = abusing the AP_EXTEND flag. What are your thoughts on having a new flag in the function to signal 12 vs 16 byte variants? Also do you have any = thoughts on the existing arguments? I=E2=80=99m not sure that tag_action has = ever made any sense for the ATA transport, there=E2=80=99s no such a thing as ordered = tags in ATA and we don=E2=80=99t expose the NCQ tag number outside of the SIM. MSG_SIMPLE_Q_TAG definitely has no meaning in ATA. I think the argument could go away. Second, I=E2=80=99m not sure that cam_ata_pass (or cam_ata_pass_16, for = that matter) is the right place to include the aux register. My reading is that = it=E2=80=99s implementing the 12.2.2.x chapter of SAT-3, and that doesn=E2=80=99t have any = allowance for the aux register. SAT-4 r.04a doesn=E2=80=99t seem to mention this register = either. The register seems to only be exposed when you have access to creating a H2D = FIS, and SAT is pretty much silent on that. IIRC, when Warner implemented NCQ TRIM, which required the Aux register, it could only be used on = devices attached via AHCI; LSI controllers had no way of expressing the = register. Still, we could add this ad-hoc to cam_ata_pass(). Maybe instead of it taking = an ata_cmd struct, it takes a union of ata_cmd and ata_cmd_aux, and we add = an argument to the function that tells it what is in the union. Maybe the = union could also include a H2D FIS? Anyways, here=E2=80=99s a possibility: union ata_cmds { struct ata_cmd cmd; struct ata_cmd_aux cmd_aux; /* Don=E2=80=99t = forget that this includes both aux registers! */ struct ata_fis_h2d fis; }; #define ATA_FORMAT_CMD 0x01 #define ATA_FORMAT_CMD_AUX 0x02 #define ATA_FORMAT_FIS_H2D 0x03 void scsi_ata_pass(struct ccb_scsiio *csio, u_int32_t retries, void (*cbfcnp)(struct cam_periph *, union ccb *), u_int32_t flags, u_int format, union ata_cmds *cmd, struct ata_res *res, u_int8_t *data_ptr, u_int32_t dxfer_len, u_int8_t *data_ptr, u_int16_t dxfer_len, u_int8_t sense_len, u_int32_t timeout); Scott > Ken > --=20 > Kenneth Merry > ken@FreeBSD.ORG From owner-freebsd-current@freebsd.org Thu Mar 3 05:49:40 2016 Return-Path: Delivered-To: freebsd-current@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 64B91AC1029 for ; Thu, 3 Mar 2016 05:49:40 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 301A611D6 for ; Thu, 3 Mar 2016 05:49:39 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id u235nX1D045250 for ; Wed, 2 Mar 2016 21:49:39 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD CURRENT" From: "Chris H" Subject: Several LOR's with most recent install media Date: Wed, 02 Mar 2016 21:49:39 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 05:49:40 -0000 Hello all, I just finished an install off of the 11.0-CURRENT-i386-20160206-r295345-bootonly iso image burnt to DVD. After rebooting to the fresh install; shutting down the system results in several LOR's. Given so much information is dumped to screen, and that I no longer have access to the system; How can I get a copy of the LOR's output? I can capture the screen with my cell phone. But the information would sure be a lot more valuable in text form; no? :-) Thanks for any suggestions. --Chris From owner-freebsd-current@freebsd.org Thu Mar 3 06:42:22 2016 Return-Path: Delivered-To: freebsd-current@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 4E14AAC23C0 for ; Thu, 3 Mar 2016 06:42:22 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 14BDC1B49 for ; Thu, 3 Mar 2016 06:42:21 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1abMxf-003DAy-Tz>; Thu, 03 Mar 2016 07:42:11 +0100 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1abMxf-003iHu-L7>; Thu, 03 Mar 2016 07:42:11 +0100 Date: Thu, 3 Mar 2016 07:42:06 +0100 From: "O. Hartmann" To: "Andrey V. Elsukov" Cc: Reko Turja , FreeBSD CURRENT Subject: Re: mounting CIFS share (tcp/445) with FreeBSD and mount_smbfs(8) Message-ID: <20160303074206.55736b13@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <56D6FD84.5020305@yandex.ru> References: <20160301222004.4cdaafc9.ohartman@zedat.fu-berlin.de> <32E522F2674A4DEBBE2492D3A307A0C1@Rivendell> <20160302152939.17333d19@freyja.zeit4.iv.bundesimmobilien.de> <56D6FD84.5020305@yandex.ru> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 06:42:22 -0000 On Wed, 2 Mar 2016 17:49:40 +0300 "Andrey V. Elsukov" wrote: > On 02.03.16 17:29, O. Hartmann wrote: > > My interpretation of the above errors are: FreeBSD is incapable to handle > > CIFS over tcp/445. The above URL/site claims to have solved the problem, > > but it seems not true for CURRENT. > > Did you try some FUSE CIFS implementations? > FUSE and its sibblings doesn't get attention, since it is something additional from ports. We have for the project security considerations and my intention is to perform that task with most FreeBSD-only software. But thanks anyway - I didn't have that project in mind so far, only SAMBA 4.3, misused as a client ... From owner-freebsd-current@freebsd.org Thu Mar 3 06:44:57 2016 Return-Path: Delivered-To: freebsd-current@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 54243AC2484; Thu, 3 Mar 2016 06:44:57 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 1AABD1CE3; Thu, 3 Mar 2016 06:44:56 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1abN0J-003Dl4-3r>; Thu, 03 Mar 2016 07:44:55 +0100 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1abN0I-003iQm-R8>; Thu, 03 Mar 2016 07:44:55 +0100 Date: Thu, 3 Mar 2016 07:44:54 +0100 From: "O. Hartmann" To: Martin Smith Cc: FreeBSD CURRENT , FreeBSD Questions Subject: Re: mounting CIFS share (tcp/445) with FreeBSD and mount_smbfs(8) Message-ID: <20160303074454.23e596d7@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <56D73578.4040802@rakupottery.org.uk> References: <20160302060243.518568d7.ohartman@zedat.fu-berlin.de> <56D73578.4040802@rakupottery.org.uk> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 06:44:57 -0000 On Wed, 2 Mar 2016 18:48:24 +0000 Martin Smith wrote: > On 02/03/2016 05:02, O. Hartmann wrote: > > Hello list. > > > > I need to mount a CIFS share from windows server 2012 r2 via CIFS, tcp/445 > > as NetBIOS service (tcp/139) has been deprecated due to serious > > vulnerability issues. > > > > Until the disabling of NetBIOS and tcp/139 we used successfully autofs and > > mount_smbfs. this is no longer working. I tried to force autofs/mount_smbfs > > to bind to port 445 on the server via ://@xxx.xxx.xxx.xxx:445/sharename, > > but this doesn't work. > > > > Trying to mount a share from a samba 4.3 server (FreeBSD CURRENT, > > net/samba43, both most recent sources), where I configured samba_server via > > smb ports = 445 to use port tcp 445 only and only SMB2 and SMB3 (server min > > protocol = SMB2) protocols via the following command: > > > > mount_smbfs -I xxx.xxx.xxx.xxx -U a_user -W \ > > WORKGROUP //a_user@xxx.xxx.xxx.xxx:445/sharename /mnt > > > > results in the error > > > > mount_smbfs: unable to open connection: syserr = RPC struct is bad > > > > Setting "smb ports = 139,445" and "server min protocol = NT1" seems to > > work, the share can be bound, but this is SMB over tcp/139 and not CIFS. > > > > I desperately need CIFS and I need tcp/445 since tcp/139 is from now on > > firewalled. > > > > So: what do I miss here? > I think this is a windows server problem, though I am not in a position > to make any useful suggestions > except to say that I am continually coming up against similar problems > with windows machines as well > sorry I cant be any more help Since I manag to connect to a SAMBA 4.3 server via 445/tcp only, but only when "min protocol = NT1" is set (tried also SMB2). Connecting to Windows 2012 R2 doesn't work. I guess mount_smbfs "understands" only NT1 and below, the Win 2012R2 offers at least SMB2? > > > > > > Kind regards and thank you in advance, > > > > O. Hartmann > > > > P.S. Please CC me From owner-freebsd-current@freebsd.org Thu Mar 3 07:00:45 2016 Return-Path: Delivered-To: freebsd-current@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 2177CAC2977 for ; Thu, 3 Mar 2016 07:00:45 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 EAB3E135B for ; Thu, 3 Mar 2016 07:00:44 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id u2370cMQ050300 for ; Wed, 2 Mar 2016 23:00:44 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: References: From: "Chris H" Subject: Re: Several LOR's with most recent install media Date: Wed, 02 Mar 2016 23:00:44 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 07:00:45 -0000 On Wed, 02 Mar 2016 21:49:39 -0800 "Chris H" wrote > Hello all, > I just finished an install off of the > 11.0-CURRENT-i386-20160206-r295345-bootonly iso image burnt to DVD. > After rebooting to the fresh install; shutting down the system > results in several LOR's. Given so much information is dumped to > screen, and that I no longer have access to the system; How can I > get a copy of the LOR's output? I can capture the screen with my > cell phone. But the information would sure be a lot more valuable > in text form; no? :-) > > Thanks for any suggestions. > OK. Just got a couple more while checking out head/ports Mar 2 22:00:00 spare newsyslog[705]: logfile turned over due to size>100K Mar 2 22:12:00 spare kernel: lock order reversal: Mar 2 22:12:00 spare kernel: 1st 0xda5f45a0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3488 Mar 2 22:12:00 spare kernel: 2nd 0xc6880600 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 Mar 2 22:12:00 spare kernel: stack backtrace: Mar 2 22:12:00 spare kernel: #0 0xc0c86001 at witness_debugger+0x81 Mar 2 22:12:00 spare kernel: #1 0xc0c85f2a at witness_checkorder+0xd6a Mar 2 22:12:00 spare kernel: #2 0xc0c31a5 Mar 2 22:12:00 spare kernel: 1 at _sx_xlock+0x71 Mar 2 22:12:00 spare kernel: #3 0xc0ef0b Mar 2 22:12:01 spare kernel: 70 at ufsdirhash_add+0x40 Mar 2 22:12:01 spare kernel: #4 0xc0ef3b32 at ufs_direnter+0x682 Mar 2 22:12:01 spare kernel: #5 0xc0efc8bb at ufs_mkdir+0x7eb Mar 2 22:12:01 spare kernel: #6 0xc11ad428 at VOP_MKDIR_APV+0x108 Mar 2 22:12:01 spare kernel: #7 0xc0ced83a at kern_mkdirat+0x23a Mar 2 22:12:01 spare kernel: #8 0xc0ced5f1 at sys_mkdir+0x31 Mar 2 22:12:01 spare kernel: #9 0xc117d4ed at syscall+0x37d Mar 2 22:12:01 spare kernel: #10 0xc116827f at Xint0x80_syscall+0x2f Mar 2 22:19:31 spare kernel: lock order reversal: Mar 2 22:19:31 spare kernel: 1st 0xc71704a4 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:873 Mar 2 22:19:31 spare kernel: 2nd 0xda5f4458 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:263 Mar 2 22:19:31 spare kernel: 3rd 0xcb9e07f8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2476 Mar 2 22:19:31 spare kernel: stack backtrace: Mar 2 22:19:31 spare kernel: #0 0xc0c86001 at witness_debugger+0x81 Mar 2 22:19:31 spare kernel: #1 0xc0c85f2a at witness_checkorder+0xd6a Mar 2 22:19:31 spare kernel: #2 0xc0c00c57 at __lockmgr_args+0xd57 Mar 2 22:19:31 spare kernel: #3 0xc0eeb374 at ffs_lock+0x84 Mar 2 22:19:31 spare kernel: #4 0xc11adef8 at VOP_LOCK1_APV+0x118 Mar 2 22:19:31 spare kernel: #5 0xc0cf0b16 at _vn_lock+0x96 Mar 2 22:19:31 spare kernel: #6 0xc0cdf2d4 at vget+0x64 Mar 2 22:19:31 spare kernel: #7 0xc0cd1a01 at vfs_hash_get+0xd1 Mar 2 22:19:31 spare kernel: #8 0xc0ee5d64 at ffs_vgetf+0x44 Mar 2 22:19:31 spare kernel: #9 0xc0edd36b at softdep_sync_buf+0xb0b Mar 2 22:19:31 spare kernel: #10 0xc0eec0ba at ffs_syncvnode+0x2aa Mar 2 22:19:31 spare kernel: #11 0xc0eeb206 at ffs_fsync+0x26 Mar 2 22:19:31 spare kernel: #12 0xc11acde8 at VOP_FSYNC_APV+0x108 Mar 2 22:19:31 spare kernel: #13 0xc0cbfc40 at bufsync+0x40 Mar 2 22:19:31 spare kernel: #14 0xc0cdd1f4 at bufobj_invalbuf+0x94 Mar 2 22:19:31 spare kernel: #15 0xc0ce07d0 at vgonel+0x1b0 Mar 2 22:19:31 spare kernel: #16 0xc0ce374b at vnlru_proc+0x65b Mar 2 22:19:31 spare kernel: #17 0xc0bead5e at fork_exit+0x7e Sorry for any undesirable line-wraps. I can attache the output, if needed. Thanks for any help preventing these. --Chris From owner-freebsd-current@freebsd.org Thu Mar 3 08:35:45 2016 Return-Path: Delivered-To: freebsd-current@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 7D6A2A92BBE; Thu, 3 Mar 2016 08:35:45 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 43B2D6BE2D; Thu, 3 Mar 2016 08:35:45 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1abOjP-000MPz-MN; Thu, 03 Mar 2016 11:35:35 +0300 Date: Thu, 3 Mar 2016 11:35:35 +0300 From: Slawa Olhovchenkov To: Glen Barber Cc: freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160303083535.GG11654@zxy.spb.ru> References: <20160302235429.GD75641@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160302235429.GD75641@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 08:35:45 -0000 On Wed, Mar 02, 2016 at 11:54:29PM +0000, Glen Barber wrote: > For those who have missed the initial email surrounding this topic, we > are planning on packaging the base system with pkg(8) for 11.0-RELEASE. > > https://lists.freebsd.org/pipermail/freebsd-pkgbase/2016-January/000000.html > > At this time, I believe the major blockers and critical issues have been > resolved where it is time for an official call-for-testing. > > Please note, as with any development branch, this is not yet intended > for production environments. Testing on virtual machines or dedicated > testing machines is strongly encouraged. > > Also note (as repeated below), running 'pkg delete -a' will implicitly > remove base system packages after they are installed. > > To obtain the sources for testing, please use the projects/release-pkg > branch: > > # svn co svn://svn.freebsd.org/base/projects/release-pkg /usr/src > > The projects/release-pkg branch is (at this time) in sync with head > revision r296327. > > After checking out the project branch, build the userland and kernel as > normal with the 'buildworld' and 'buildkernel' targets. Afterward, > packages can be created with the 'packages' target. > > # cd /usr/src > # make [make flags] buildworld > # make [make flags] buildkernel > # make packages > > At present, the base system consists of 755 packages with the default 755! :(((( What purpose of this? At time of split Xorg to multiple packages talk about individual update single package and don't touching rest. In reality we have un-obvious garbage fully rebuild on every update. Also, list of packagess too long and badly mantained on rescue console (for see and for control). From owner-freebsd-current@freebsd.org Thu Mar 3 09:47:25 2016 Return-Path: Delivered-To: freebsd-current@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 BA3A6A93033 for ; Thu, 3 Mar 2016 09:47:25 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 822F4FD6 for ; Thu, 3 Mar 2016 09:47:25 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1abPqs-004ANc-Dy>; Thu, 03 Mar 2016 10:47:22 +0100 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1abPqs-003z9F-2q>; Thu, 03 Mar 2016 10:47:22 +0100 Date: Thu, 3 Mar 2016 10:47:21 +0100 From: "O. Hartmann" To: freebsd-current Subject: mount_smbfs(8): support for SMBv3.02? Message-ID: <20160303104721.097ae352@freyja.zeit4.iv.bundesimmobilien.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 09:47:25 -0000 Does FreeBSD's mount_smbfs(8) support for Microsoft's SMBv3 protocol introduced with Windows 8 and Windows Server 2012/R2? I tried to find informations/documentation for the kernel options NETSMB SMBFS which I suspect to maintain this aspect, but I couldn't find anything regarding NETSMB or SMBFS. The manpage for mount_smbfs(8) seems not to provide any further informations. What does option "-n opt" of mount_smbfs(8) do? See manpage for that sepcific command, it lacks of explanation. I'm required to mount a SHARE provided by a Windows Server 2012 R2, which has explicitely deisabled NetBIOS over 139/tcp (firewalled, too). I'm running FreeBSD CURRENT, most recent. I'd like to use FreeBSD tools only - as far as this is possible. Now it seems that mount_smbfs(8) can not handle SMBv3 - but this is simply a guess based upon incomplete documentation. Can someone shed light on the maximal protocol version supported by mount_smbfs(8)? I need to track down why I can not mount a share with 445/tcp only. I can do so via 139/tcp NetBIOS from the very same server (windows 2012R2). Since I do not understand much about how windows negotiate the protocol used with a client's request - if any negotiation ever takes place - I try to find out what I did wrong with the configuration/usage of mount_smbfs(8). I have running a Samba 4.3 server on CURRENT on which I can set "min protocol" and "max protocol" as I like. this server does not allow connections via 139/tcp (filtered via ipfw). When setting "min protocol = SMB2" any mount attempt with mount_smbfs(8) fail, setting the tag to NT1 I'm able to succesfully connect via port 445/tcp. So for that reason I suspect a problem with the SMB version negotiated with the 2012 R2 server and the inability of mount_smbfs(8) (or its appropriate kernel backend) to handle any protocol version higher than NT1 (or SMB1). Thanks in advance and kind regards, Oliver From owner-freebsd-current@freebsd.org Thu Mar 3 10:27:21 2016 Return-Path: Delivered-To: freebsd-current@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 578C1A93BBA for ; Thu, 3 Mar 2016 10:27:21 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [IPv6:2001:8b0:151:1:c4ea:bd49:619b:6cb3]) (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 1631BA7F for ; Thu, 3 Mar 2016 10:27:21 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from ox-dell39.ox.adestra.com (unknown [85.199.232.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id 5992926D2 for ; Thu, 3 Mar 2016 10:27:15 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/5992926D2; dkim=none; dkim-atps=neutral Subject: Re: [CFT] packaging the base system with pkg(8) To: freebsd-current@freebsd.org References: <20160302235429.GD75641@FreeBSD.org> From: Matthew Seaman X-Enigmail-Draft-Status: N1110 Message-ID: <56D81174.3070000@freebsd.org> Date: Thu, 3 Mar 2016 10:27:00 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160302235429.GD75641@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TEVdqX44PD161CoX9RRUowDWQTV1Uk7BC" X-Virus-Scanned: clamav-milter 0.99 at smtp.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=2.2 required=5.0 tests=RDNS_NONE,SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.1 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on smtp.infracaninophile.co.uk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 10:27:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TEVdqX44PD161CoX9RRUowDWQTV1Uk7BC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/02/16 23:54, Glen Barber wrote: > Also note (as repeated below), running 'pkg delete -a' will implicitly > remove base system packages after they are installed. This has the potential for many feet to be shot, given that up to now, 'pkg delete -a' would always leave you with a viable system. We already make an exception for pkg itself -- you need 'pkg delete -fa' to actually remove pkg(8) as well. (Note to self: this needs to be documented in the pkg-delete(8) man page.) We should have similar exceptions for the essential bits of the base system -- at minimum everything you need to boot the system up and install stuff from a package repository. We should also have a command line that will remove all ported software but leave the base intact. Maybe by adding '-r reponame' functionality to 'pkg delete'? Cheers, Matthew --TEVdqX44PD161CoX9RRUowDWQTV1Uk7BC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJW2BF0AAoJEABRPxDgqeTncAsP/j5s4IU11/qEY/qBxgI839xa XW8z6vo/6+eAPYWw+2dnVg2EdxXbWbmurWJ8Rt8Fq6ixyz+bLdTMF9iADs/R877X c8xKl7sCqjIL8C3u+Ws8c1FR2lw8JlMP6Va5TTyeku3n7o+a8bz9a/Z3eSQLl7j7 rhU2FOV2efSKwatWwW2LAVBBf0oBRVfUI4bj49/VM6/mr+I7F4zxpEx0uQcUIqmr JAw+md1GR+sBDZAau3FPSZ6NkxTm4HdG8UnFyLPx0pgl8JJNS80NIiHliuVowdEU 0BEkW31vxU4NkwcJ9Z4gVeadOnDTB0T+Be9TF22NFvKxio1NsbRuWNmvi59y2wbu 21OEb3OrO5Hv9ZSZw6Z0ujzcuLLnluZVUpxAeXsDjs0OmTk8CH15jrIlQH6oJfNk mGXRPMXTV5puBazhQ1xnpigN4CCaXi+gV1md+PqH/9794pgJsIeAj3kGtBtS1bz/ x6jmkyXAZCbuPJo7LLIuf8cloyxzTUSMLaOeNtKN8Z5mNFfyi4aQVloK0BrSJRij PX51dTgxulhLUiHIjiL2uta/KhqDDnnB0n8wIhYy8qQsN4MhXCwrcyZzvQQpNciB soScz9gwpa+JUUXPUcA0L33qMO/dss3/crdCEVfFVGum22CWyfTgVqInu4hoUhcd f6gspGTiFMjXF1GjRAAB =GyPK -----END PGP SIGNATURE----- --TEVdqX44PD161CoX9RRUowDWQTV1Uk7BC-- From owner-freebsd-current@freebsd.org Thu Mar 3 13:48:27 2016 Return-Path: Delivered-To: freebsd-current@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 60062A93EB2 for ; Thu, 3 Mar 2016 13:48:27 +0000 (UTC) (envelope-from Scoobi_doo@yahoo.com) Received: from nm15.bullet.mail.bf1.yahoo.com (nm15.bullet.mail.bf1.yahoo.com [98.139.212.174]) (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 1B870F54 for ; Thu, 3 Mar 2016 13:48:26 +0000 (UTC) (envelope-from Scoobi_doo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1457012779; bh=gyMDuJZA0Quo2XCL00gFxv95nQZkcLWRo8wQjj01RyI=; h=To:From:Subject:Date:From:Subject; b=qKSB8GfybLvNAbVZEEZ05X0dBMOplG0PNtw0ufdh2r5/9/+KhIHg/hHpqxHzgQ782mcljQUgHrBjxbokszfGeszCFa5EUldL6HoI2UXaqDyVT1RXMIjsi0Jd0ZgsIK0oxuYoLmmb2Jk3SFogQGtnd8zKeROJ07+kTfMlSQjkf6KCvvJQ/FeM8N86qP1B0PivLqpbHi1o8sSVy2wGYrMKxjq3hrBMw60UdD6wZVpwTiElJahVlZeMHyZAa+HwTTKpDHbyrOqChtOM09ziIkuJMxMPijjbMY46a167d6KLLvqsnRaNM/Zwv1vJr5MXOnajYIVidE4mNUiYdb+mBMV5ug== Received: from [66.196.81.172] by nm15.bullet.mail.bf1.yahoo.com with NNFMP; 03 Mar 2016 13:46:19 -0000 Received: from [98.139.213.13] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 03 Mar 2016 13:46:19 -0000 Received: from [127.0.0.1] by smtp113.mail.bf1.yahoo.com with NNFMP; 03 Mar 2016 13:46:19 -0000 X-Yahoo-Newman-Id: 419717.54956.bm@smtp113.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: q8IYajQVM1kvfebJpxRfWzG0GPWEnpw1oHKE8i8d0Qy1csq Wv9I9ls6UH.bkfZ5vFX2o6cOVWRPpDVJYXyPVYlFjeTZmDkLbURwY9x1qXHo fhbkbZSueSkFqwOQ0sK.Pffq2_NsNS_QN4poP5hMPZjU0QvNhz0bqbzWmdpW W7lJu1YHkWi6anxs4ZdeXUPex4wjm8V13hquvH_oCsQIsd5v2Ev1d3Wr8NAv NCF15BEjk81P.q6zXvhSQQgvdr4m54wIbBQPilMuG2iR5k1fhsd7U0yNYXSQ feWUDzg1HK6SnfbxsaazAoNePBFtKTaHYbcAoCGJnp.m90IawXXNqCdLTyBL A6MzD2vB6dKCv.uCfJBZeTpi3u2_ES8FE2XzjGvoep18uzJ7Fw07L3GZLyyd zUqJMD931RbIAeBZIPthSZptQhONbGdD5Asi_Lqf5MaalmBUJJYxlv5AtjGh verNdKsX8ZDCaBYgExVnIImEVsImyarV6ktASy3pbNvgGUTEBi1DztUZMhvq BLfBf1kdkEVyM6lGhO5IbOlg5RnDKWiqU X-Yahoo-SMTP: 9sPoSQ2swBBlERuQ.0vs8XLc_MeClW0- To: freebsd-current@freebsd.org From: Anthony Jenkins Subject: UEFI boot issues on HP laptop Message-ID: <56D84027.5070705@yahoo.com> Date: Thu, 3 Mar 2016 08:46:15 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 13:48:27 -0000 First of all, thanks to everyone who got FreeBSD's UEFI + ZFS boot working, I'm now triple-booting FreeBSD, Kubuntu Linux and my HP laptop's native Windows 10 (all 3 spread among about 13 GPT partitions including an EFI partition). I have a couple issues - an EFI configuration disables some devices and FreeBSD's EFI boot file not showing up in boot menu. Until recently I booted FreeBSD by bringing up the BIOS boot menu, selecting "F9 - Boot Device Options" -> "Boot From EFI File" and navigating to \EFI\FreeBSD\boot1.efi on the EFI partition. Yesterday I decided to replace the default EFI boot file (apparently \EFI\Microsoft\Boot\bootmgfw.efi) with FreeBSD's EFI boot file, which works... /sorta/. If I allow the machine to boot, FreeBSD comes up with no need for me to interact with the BIOS, but several devices no longer work - my Intel 3160 PCIe wireless card and my eGalax USB touchscreen are non-responsive. They're both /detected/ on their respective busses and their drivers are loaded, but touching the screen no longer moves the cursor in KDE4 and I cannot connect to an access point. I can 'cat /dev/input/event0' and see data when I touch the screen, and I can 'ifconfig wlan0 list scan' to see broadcasting APs, which is weird. Anyone know what's going on? I'm assuming HP Support won't help me out with this sort of issue. To be accurate, I copied the FreeBSD EFI boot file to two places=20 \EFI\Boot\bootx64.efi (I thought BIOSes booted this file by default) and \EFI\Microsoft\Boot\bootmgfw.efi. The other issue is just me being jealous of EFI Linux showing up in a toplevel BIOS boot menu: Selecting "F9 - Boot Device Options" goes to the "Boot Manager" screen: Boot Option Menu - OS boot Manager - ubuntu (MKNSSDRE1TB) - Boot From EFI File - Notebook Hard Drive How did Ubuntu get in there? Some attribute of its EFI boot file that tells the BIOS (or boot manager EFI app) to add an entry for it? How do I get FreeBSD in there? Thanks! --=20 Anthony Jenkins From owner-freebsd-current@freebsd.org Thu Mar 3 14:58:21 2016 Return-Path: Delivered-To: freebsd-current@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 0003FA9343F for ; Thu, 3 Mar 2016 14:58:20 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from smtprelay-h22.telenor.se (smtprelay-h22.telenor.se [195.54.99.197]) (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 8912D75B for ; Thu, 3 Mar 2016 14:58:20 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from ipb4.telenor.se (ipb4.telenor.se [195.54.127.167]) by smtprelay-h22.telenor.se (Postfix) with ESMTP id 551B614256 for ; Thu, 3 Mar 2016 15:39:16 +0100 (CET) X-SENDER-IP: [85.229.94.62] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2ChBwDiS9hWPD5e5VVdGQEBAgsBAgEBAQEBgwqBRYZgsTKCIYFohg8CgSo7EgEBAQEBAQEGAQEBAUFAhEIBAQMBIw8BIyMFCwsODAImAgItDAoGAQ0GiCwMAa43jzMBAQEBBgIBHXuJWYc4gToFh1mPQwGBRJsVjSABgSwnBYI0BRmBSTuJUAEBAQ X-IPAS-Result: A2ChBwDiS9hWPD5e5VVdGQEBAgsBAgEBAQEBgwqBRYZgsTKCIYFohg8CgSo7EgEBAQEBAQEGAQEBAUFAhEIBAQMBIw8BIyMFCwsODAImAgItDAoGAQ0GiCwMAa43jzMBAQEBBgIBHXuJWYc4gToFh1mPQwGBRJsVjSABgSwnBYI0BRmBSTuJUAEBAQ X-IronPort-AV: E=Sophos;i="5.22,532,1449529200"; d="scan'208";a="207587224" Received: from c-3e5ee555.06-11-73746f31.cust.bredbandsbolaget.se (HELO sigyn.alvermark.net) ([85.229.94.62]) by ipb4.telenor.se with ESMTP; 03 Mar 2016 15:39:16 +0100 Received: from localhost ([127.0.0.1] helo=webmail.alvermark.net) by sigyn.alvermark.net with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1abUPK-000Kuj-1p; Thu, 03 Mar 2016 15:39:14 +0100 Received: from 212.247.8.97 (SquirrelMail authenticated user alvis) by webmail.alvermark.net with HTTP; Thu, 3 Mar 2016 15:39:14 +0100 (CET) Message-ID: <58622.212.247.8.97.1457015954.squirrel@webmail.alvermark.net> In-Reply-To: <56D84027.5070705@yahoo.com> References: <56D84027.5070705@yahoo.com> Date: Thu, 3 Mar 2016 15:39:14 +0100 (CET) Subject: Re: UEFI boot issues on HP laptop From: "Jakob Alvermark" To: "Anthony Jenkins" Cc: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 14:58:21 -0000 Hi, On Thu, March 3, 2016 14:46, Anthony Jenkins wrote: > The other issue is just me being jealous of EFI Linux showing up in a > toplevel BIOS boot menu: > > Selecting "F9 - Boot Device Options" goes to the "Boot Manager" screen: > > > Boot Option Menu > > > - OS boot Manager > - ubuntu (MKNSSDRE1TB) > - Boot From EFI File > - Notebook Hard Drive > > > > How did Ubuntu get in there? Some attribute of its EFI boot file that > tells the BIOS (or boot manager EFI app) to add an entry for it? How do I > get FreeBSD in there? You can modify the this from Windows, using the command line tool 'bcdedit'. That's what I did on my Thinkpad. >From administrator command prompt, 'bcedit /enum all' will show you something like this at the top: Firmware Boot Manager --------------------- identifier {fwbootmgr} displayorder {5d090d98-8e36-11e5-827b-806e6f6e6963} {f43a1eb3-82e3-11e5-8252-94659c6abc55} {bootmgr} {4a919591-82e1-11e5-a7d6-806e6f6e6963} {4a919592-82e1-11e5-a7d6-806e6f6e6963} {4a919593-82e1-11e5-a7d6-806e6f6e6963} {4a919594-82e1-11e5-a7d6-806e6f6e6963} {4a919595-82e1-11e5-a7d6-806e6f6e6963} {4a919596-82e1-11e5-a7d6-806e6f6e6963} {4a919590-82e1-11e5-a7d6-806e6f6e6963} timeout 0 Windows Boot Manager -------------------- identifier {bootmgr} device partition=\Device\HarddiskVolume2 path \EFI\Microsoft\Boot\bootmgfw.efi description Windows Boot Manager locale en-US inherit {globalsettings} integrityservices Enable default {current} resumeobject {f43a1eac-82e3-11e5-8252-94659c6abc55} displayorder {current} toolsdisplayorder {memdiag} timeout 30 You can add new entries to the displayorder, and they should show up in your boot options. I have added theese two: Firmware Application (101fffff) ------------------------------- identifier {5d090d98-8e36-11e5-827b-806e6f6e6963} device partition=\Device\HarddiskVolume2 path \EFI\BSD\freebsd.efi description FreeBSD Firmware Application (101fffff) ------------------------------- identifier {f43a1eb3-82e3-11e5-8252-94659c6abc55} device partition=\Device\HarddiskVolume2 path \EFI\BSD\openbsd.efi description OpenBSD So I have FreeBSD booting by default, and I can boot OpenBSD and Windows as second and third choices, respectively. Hope to get you in the right direction with this. Jakob From owner-freebsd-current@freebsd.org Thu Mar 3 15:24:11 2016 Return-Path: Delivered-To: freebsd-current@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 6479CA93CFC for ; Thu, 3 Mar 2016 15:24:11 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 4F440660 for ; Thu, 3 Mar 2016 15:24:10 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id u23FO5Sa092200 for ; Thu, 3 Mar 2016 07:24:11 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: References: , From: "Chris H" Subject: Re: Several LOR's with most recent install media Date: Thu, 03 Mar 2016 07:24:11 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <5edad7eb58694a7b7da11bbb9a82e9a3@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 15:24:11 -0000 On Wed, 02 Mar 2016 23:00:44 -0800 "Chris H" wrote > On Wed, 02 Mar 2016 21:49:39 -0800 "Chris H" wrote > > > Hello all, > > I just finished an install off of the > > 11.0-CURRENT-i386-20160206-r295345-bootonly iso image burnt to DVD. > > After rebooting to the fresh install; shutting down the system > > results in several LOR's. Given so much information is dumped to > > screen, and that I no longer have access to the system; How can I > > get a copy of the LOR's output? I can capture the screen with my > > cell phone. But the information would sure be a lot more valuable > > in text form; no? :-) > > > > Thanks for any suggestions. > > > OK. Just got a couple more while checking out head/ports > > Mar 2 22:00:00 spare newsyslog[705]: logfile turned over due to size>100K > Mar 2 22:12:00 spare kernel: lock order reversal: > Mar 2 22:12:00 spare kernel: 1st 0xda5f45a0 bufwait (bufwait) @ > /usr/src/sys/kern/vfs_bio.c:3488 > Mar 2 22:12:00 spare kernel: 2nd 0xc6880600 dirhash (dirhash) @ > /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 > Mar 2 22:12:00 spare kernel: stack backtrace: > Mar 2 22:12:00 spare kernel: #0 0xc0c86001 at witness_debugger+0x81 > Mar 2 22:12:00 spare kernel: #1 0xc0c85f2a at witness_checkorder+0xd6a > Mar 2 22:12:00 spare kernel: #2 0xc0c31a5 > Mar 2 22:12:00 spare kernel: 1 at _sx_xlock+0x71 > Mar 2 22:12:00 spare kernel: #3 0xc0ef0b > Mar 2 22:12:01 spare kernel: 70 at ufsdirhash_add+0x40 > Mar 2 22:12:01 spare kernel: #4 0xc0ef3b32 at ufs_direnter+0x682 > Mar 2 22:12:01 spare kernel: #5 0xc0efc8bb at ufs_mkdir+0x7eb > Mar 2 22:12:01 spare kernel: #6 0xc11ad428 at VOP_MKDIR_APV+0x108 > Mar 2 22:12:01 spare kernel: #7 0xc0ced83a at kern_mkdirat+0x23a > Mar 2 22:12:01 spare kernel: #8 0xc0ced5f1 at sys_mkdir+0x31 > Mar 2 22:12:01 spare kernel: #9 0xc117d4ed at syscall+0x37d > Mar 2 22:12:01 spare kernel: #10 0xc116827f at Xint0x80_syscall+0x2f > Mar 2 22:19:31 spare kernel: lock order reversal: > Mar 2 22:19:31 spare kernel: 1st 0xc71704a4 ufs (ufs) @ > /usr/src/sys/kern/vfs_subr.c:873 > Mar 2 22:19:31 spare kernel: 2nd 0xda5f4458 bufwait (bufwait) @ > /usr/src/sys/ufs/ffs/ffs_vnops.c:263 > Mar 2 22:19:31 spare kernel: 3rd 0xcb9e07f8 ufs (ufs) @ > /usr/src/sys/kern/vfs_subr.c:2476 > Mar 2 22:19:31 spare kernel: stack backtrace: > Mar 2 22:19:31 spare kernel: #0 0xc0c86001 at witness_debugger+0x81 > Mar 2 22:19:31 spare kernel: #1 0xc0c85f2a at witness_checkorder+0xd6a > Mar 2 22:19:31 spare kernel: #2 0xc0c00c57 at __lockmgr_args+0xd57 > Mar 2 22:19:31 spare kernel: #3 0xc0eeb374 at ffs_lock+0x84 > Mar 2 22:19:31 spare kernel: #4 0xc11adef8 at VOP_LOCK1_APV+0x118 > Mar 2 22:19:31 spare kernel: #5 0xc0cf0b16 at _vn_lock+0x96 > Mar 2 22:19:31 spare kernel: #6 0xc0cdf2d4 at vget+0x64 > Mar 2 22:19:31 spare kernel: #7 0xc0cd1a01 at vfs_hash_get+0xd1 > Mar 2 22:19:31 spare kernel: #8 0xc0ee5d64 at ffs_vgetf+0x44 > Mar 2 22:19:31 spare kernel: #9 0xc0edd36b at softdep_sync_buf+0xb0b > Mar 2 22:19:31 spare kernel: #10 0xc0eec0ba at ffs_syncvnode+0x2aa > Mar 2 22:19:31 spare kernel: #11 0xc0eeb206 at ffs_fsync+0x26 > Mar 2 22:19:31 spare kernel: #12 0xc11acde8 at VOP_FSYNC_APV+0x108 > Mar 2 22:19:31 spare kernel: #13 0xc0cbfc40 at bufsync+0x40 > Mar 2 22:19:31 spare kernel: #14 0xc0cdd1f4 at bufobj_invalbuf+0x94 > Mar 2 22:19:31 spare kernel: #15 0xc0ce07d0 at vgonel+0x1b0 > Mar 2 22:19:31 spare kernel: #16 0xc0ce374b at vnlru_proc+0x65b > Mar 2 22:19:31 spare kernel: #17 0xc0bead5e at fork_exit+0x7e > > Sorry for any undesirable line-wraps. > I can attache the output, if needed. > > Thanks for any help preventing these. > OK. Got another one wile checking out /usr/src Mar 3 06:45:41 spare kernel: 1st 0xda5fc478 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3488 Mar 3 06:45:41 spare kernel: 2nd 0xcbf89a00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 Mar 3 06:45:41 spare kernel: stack backtrace: Mar 3 06:45:41 spare kernel: #0 0xc0c86001 at witness_debugger+0x81 Mar 3 06:45:41 spare kernel: #1 0xc0c85f2a at witness_checkorder+0xd6a Mar 3 06:45:41 spare kernel: #2 0xc0c31a51 at _sx_xlock+0x71 Mar 3 06:45:41 spare kernel: #3 0xc0ef0b70 at ufsdirhash_add+0x40 Mar 3 06:45:41 spare kernel: #4 0xc0ef3b32 at ufs_direnter+0x682 Mar 3 06:45:41 spare kernel: #5 0xc0efc8bb at ufs_mkdir+0x7eb Mar 3 06:45:41 spare kernel: #6 0xc11ad428 at VOP_MKDIR_APV+0x108 Mar 3 06:45:41 spare kernel: #7 0xc0ced83a at kern_mkdirat+0x23a Mar 3 06:45:41 spare kernel: #8 0xc0ced5f1 at sys_mkdir+0x31 Mar 3 06:45:41 spare kernel: #9 0xc117d4ed at syscall+0x37d Mar 3 06:45:41 spare kernel: #10 0xc116827f at Xint0x80_syscall+0x2f Mar 3 06:50:42 spare kernel: lock order reversal: Mar 3 06:50:42 spare kernel: 1st 0xc880ca30 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:873 Mar 3 06:50:42 spare kernel: 2nd 0xda651cd8 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:263 Mar 3 06:50:42 spare kernel: 3rd 0xcb3675c0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2476 Mar 3 06:50:42 spare kernel: stack backtrace: Mar 3 06:50:42 spare kernel: #0 0xc0c86001 at witness_debugger+0x81 Mar 3 06:50:42 spare kernel: #1 0xc0c85f2a at witness_checkorder+0xd6a Mar 3 06:50:42 spare kernel: #2 0xc0c00c57 at __lockmgr_args+0xd57 Mar 3 06:50:42 spare kernel: #3 0xc0eeb374 at ffs_lock+0x84 Mar 3 06:50:42 spare kernel: #4 0xc11adef8 at VOP_LOCK1_APV+0x118 Mar 3 06:50:42 spare kernel: #5 0xc0cf0b16 at _vn_lock+0x96 Mar 3 06:50:42 spare kernel: #6 0xc0cdf2d4 at vget+0x64 Mar 3 06:50:42 spare kernel: #7 0xc0cd1a01 at vfs_hash_get+0xd1 Mar 3 06:50:42 spare kernel: #8 0xc0ee5d64 at ffs_vgetf+0x44 Mar 3 06:50:42 spare kernel: #9 0xc0edd36b at softdep_sync_buf+0xb0b Mar 3 06:50:42 spare kernel: #10 0xc0eec0ba at ffs_syncvnode+0x2aa Mar 3 06:50:42 spare kernel: #11 0xc0eeb206 at ffs_fsync+0x26 Mar 3 06:50:42 spare kernel: #12 0xc11acde8 at VOP_FSYNC_APV+0x108 Mar 3 06:50:42 spare kernel: #13 0xc0cbfc40 at bufsync+0x40 Mar 3 06:50:42 spare kernel: #14 0xc0cdd1f4 at bufobj_invalbuf+0x94 Mar 3 06:50:42 spare kernel: #15 0xc0ce07d0 at vgonel+0x1b0 Mar 3 06:50:42 spare kernel: #16 0xc0ce374b at vnlru_proc+0x65b Mar 3 06:50:42 spare kernel: #17 0xc0bead5e at fork_exit+0x7e This one looks *very* similar to what I get at shutdown(8). Only it is repeated 3 times -- presumably once for each slice (excluding swap). Please let me know if you need any more info, or I should blow this attempted install away, and wait for another (newer) revision. Thanks! --Chris From owner-freebsd-current@freebsd.org Thu Mar 3 16:19:45 2016 Return-Path: Delivered-To: freebsd-current@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 32ADCA93D73 for ; Thu, 3 Mar 2016 16:19:45 +0000 (UTC) (envelope-from Scoobi_doo@yahoo.com) Received: from nm38-vm5.bullet.mail.bf1.yahoo.com (nm38-vm5.bullet.mail.bf1.yahoo.com [72.30.239.21]) (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 F0E358 for ; Thu, 3 Mar 2016 16:19:44 +0000 (UTC) (envelope-from Scoobi_doo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1457021859; bh=qWe/RIEsfJ3LOWM+KfLF5x0diQ6S+2fiwVLG0CULp+U=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=HjTh+XLK/GDn8m50nSBHY8RG6PG/2AOSxWt9osQEBURVGgAfgUh7EvJ12veOsG71NEV4Mc5/XGPzmB2TFH7c7ElcIxrl9ffBGycofwP0JxYuL7x9ieuVPSipNZwFYdiw9sdRJOInOx/lBTaJRkJPCwYlxolVI6B9sGZjfg82wwoDdsqakIBV9e3WGmNQwxrcFWhAMFCHErAbEXzbYTh7ATrNiGjQLJ9reDbXROa79JuQYZzAQvLzUcvSXRsFDUhFJulBRoDCWFbiih8/DGTlz8ltN8tQkXw3ZmgFc76W83C8+HU/x6Nh5EZtovTSG5TPUUpfizBjSUdA+9fPzfFpDw== Received: from [98.139.215.143] by nm38.bullet.mail.bf1.yahoo.com with NNFMP; 03 Mar 2016 16:17:39 -0000 Received: from [98.139.211.195] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 03 Mar 2016 16:17:39 -0000 Received: from [127.0.0.1] by smtp204.mail.bf1.yahoo.com with NNFMP; 03 Mar 2016 16:17:39 -0000 X-Yahoo-Newman-Id: 75788.64891.bm@smtp204.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: jLcGfsgVM1kRxQZbuC.9N.pggOGOIDdtaTwW9DUF7tkX2ZK Uk46jFAYmms0je4vObZLNlwA4uM6s6xmDK8S5r0CBrt4kxnkFiDlVFr_B6UC 4mn9ekTGXv521d2pYtHv7w9SP55H9e0NrEjtFf.yZA5Mysrb0QUTa3i632u. ecvW0mW9a_xZtB3MPLbETt8TuLmYnlHWruZyY9SxE8R9wPnKXW9AvcG5r3QL .7nfjtAdW_V2NU0jUGMNm1dKhAXMhc5DGzAlsjzCeNIaYz7uXCaty2G.KSW6 kCEZl1Hs0QcQ7TAel5aDgC_zNhFKxx5lFSLFJDsrVOPGLKV_jLqFJmQ3kaFe O2cR7CwfTUBqGeaRKlIOt1WpnZS.s9W2PfRnO3AGGA8qiY9uZYg309b05aA4 sdGC_Zax5tYZer0_eW7RtS1GdDvSb.miRy_G4AveL9HihBzkqYyTAITQ6zuB L0uRPrlEOi.5Mtg7taHnCeJ0zOuDYCyWvK4Xqrf2PGiIQv4HTBOZ5HWjtYmP 97ytBE1b7.ZNpPdcH4Y4cAX6Pq3XRDY4- X-Yahoo-SMTP: 9sPoSQ2swBBlERuQ.0vs8XLc_MeClW0- Subject: Re: UEFI boot issues on HP laptop To: Jakob Alvermark References: <56D84027.5070705@yahoo.com> <58622.212.247.8.97.1457015954.squirrel@webmail.alvermark.net> Cc: freebsd-current@freebsd.org From: Anthony Jenkins Message-ID: <56D863A1.4040403@yahoo.com> Date: Thu, 3 Mar 2016 11:17:37 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <58622.212.247.8.97.1457015954.squirrel@webmail.alvermark.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 16:19:45 -0000 On 03/03/2016 09:39 AM, Jakob Alvermark wrote: > Hi, > > On Thu, March 3, 2016 14:46, Anthony Jenkins wrote: > >> The other issue is just me being jealous of EFI Linux showing up in a >> toplevel BIOS boot menu: >> >> Selecting "F9 - Boot Device Options" goes to the "Boot Manager" screen: >> >> >> Boot Option Menu >> >> >> - OS boot Manager >> - ubuntu (MKNSSDRE1TB) >> - Boot From EFI File >> - Notebook Hard Drive >> >> >> >> How did Ubuntu get in there? Some attribute of its EFI boot file that >> tells the BIOS (or boot manager EFI app) to add an entry for it? How do I >> get FreeBSD in there? > You can modify the this from Windows, using the command line tool 'bcdedit'. > That's what I did on my Thinkpad. > > From administrator command prompt, 'bcedit /enum all' will show you > something like this at the top: > > Firmware Boot Manager > --------------------- > identifier {fwbootmgr} > displayorder {5d090d98-8e36-11e5-827b-806e6f6e6963} > {f43a1eb3-82e3-11e5-8252-94659c6abc55} > {bootmgr} > {4a919591-82e1-11e5-a7d6-806e6f6e6963} > {4a919592-82e1-11e5-a7d6-806e6f6e6963} > {4a919593-82e1-11e5-a7d6-806e6f6e6963} > {4a919594-82e1-11e5-a7d6-806e6f6e6963} > {4a919595-82e1-11e5-a7d6-806e6f6e6963} > {4a919596-82e1-11e5-a7d6-806e6f6e6963} > {4a919590-82e1-11e5-a7d6-806e6f6e6963} > timeout 0 > > Windows Boot Manager > -------------------- > identifier {bootmgr} > device partition=\Device\HarddiskVolume2 > path \EFI\Microsoft\Boot\bootmgfw.efi > description Windows Boot Manager > locale en-US > inherit {globalsettings} > integrityservices Enable > default {current} > resumeobject {f43a1eac-82e3-11e5-8252-94659c6abc55} > displayorder {current} > toolsdisplayorder {memdiag} > timeout 30 > > You can add new entries to the displayorder, and they should show up in > your boot options. > > I have added theese two: > Firmware Application (101fffff) > ------------------------------- > identifier {5d090d98-8e36-11e5-827b-806e6f6e6963} > device partition=\Device\HarddiskVolume2 > path \EFI\BSD\freebsd.efi > description FreeBSD > > Firmware Application (101fffff) > ------------------------------- > identifier {f43a1eb3-82e3-11e5-8252-94659c6abc55} > device partition=\Device\HarddiskVolume2 > path \EFI\BSD\openbsd.efi > description OpenBSD > > So I have FreeBSD booting by default, and I can boot OpenBSD and Windows > as second and third choices, respectively. > > Hope to get you in the right direction with this. > > Jakob Wow, awesome! Will try this today, thanks! -- Anthony Jenkins From owner-freebsd-current@freebsd.org Fri Mar 4 06:55:33 2016 Return-Path: Delivered-To: freebsd-current@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 10D3B9D93EE for ; Fri, 4 Mar 2016 06:55:33 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 CD68F1063 for ; Fri, 4 Mar 2016 06:55:31 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1abje0-000J9z-GF>; Fri, 04 Mar 2016 07:55:24 +0100 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1abje0-001RW9-4H>; Fri, 04 Mar 2016 07:55:24 +0100 Date: Fri, 4 Mar 2016 07:55:16 +0100 From: "O. Hartmann" To: freebsd-current Subject: kernel build failure in if_lmc when bpf(4) disabled! Message-ID: <20160304075516.362bd276@freyja.zeit4.iv.bundesimmobilien.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 06:55:33 -0000 Building a custom kernel fails when bpf(4) is disabled as suggested in security(7) due to the error shown below. I also tried to define in make.conf WITHOUT_MODULES="lmc" or WITHOU_MODULES="if_lmc" assuming I could avoid building the culprit module/device, but it did not work as expected! I need to disable bpf(4). What is to do to avoid building this failing module? [...] cc -c -O2 -pipe -fno-strict-aliasing -nostdinc -I. -I/empty/src/ALG/CURRENT/sys -I/empty/src/ALG/CURRENT/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /empty/src/ALG/CURRENT/sys/x86/acpica/madt.c --- modules-all --- /empty/src/ALG/CURRENT/sys/modules/lmc/../../dev/lmc/if_lmc.c:4357:33: error: use of undeclared identifier 'DEV_BPF' ALTQ_PRESENT ? "ALTQ " : "", NBPFILTER ? "BPF " : "", ^ /empty/src/ALG/CURRENT/sys/modules/lmc/../../dev/lmc/if_lmc.c:94:20: note: expanded from macro 'NBPFILTER' # define NBPFILTER DEV_BPF ^ 4 errors generated. *** [if_lmc.o] Error code 1 From owner-freebsd-current@freebsd.org Fri Mar 4 12:17:25 2016 Return-Path: Delivered-To: freebsd-current@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 3C0B99DA6F3 for ; Fri, 4 Mar 2016 12:17:25 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 00E21B1F for ; Fri, 4 Mar 2016 12:17:24 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1abofa-003BUX-6j>; Fri, 04 Mar 2016 13:17:22 +0100 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1abofZ-001upe-UG>; Fri, 04 Mar 2016 13:17:22 +0100 Date: Fri, 4 Mar 2016 13:17:17 +0100 From: "O. Hartmann" To: freebsd-current Subject: WITHOUT_MODULES=if_lmc not working in NanoBSD Message-ID: <20160304131717.5f8e8623@freyja.zeit4.iv.bundesimmobilien.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 12:17:25 -0000 I try to disable device bpf in the kernel, which results in a compilation error of if_lmc: [...] --- /empty/src/ALG/CURRENT/sys/modules/lmc/../../dev/lmc/if_lmc.c:4357:33: error: use of undeclared identifier 'DEV_BPF' ALTQ_PRESENT ? "ALTQ " : "", NBPFILTER ? "BPF " : "", ^ /empty/src/ALG/CURRENT/sys/modules/lmc/../../dev/lmc/if_lmc.c:94:20: note: expanded from macro 'NBPFILTER' # define NBPFILTER DEV_BPF ^ 4 errors generated. *** [if_lmc.o] Error code 1 In NanoBSD's common.conf, I defined therefore CONF_WORLD=' WITHOUT_MODULES=if_lmc ... ' or, since it doesn't work as expected, CONF_WORLD=' WITHOUT_MODULES=lmc ... ' It doesn't work as expected! WITHOUT_MODULES= doesn't work at all. Module/driver if_lmc (lmc) is compiled everytime and running therefore into that error, the build of the driver/module is not skipped. How can I securely disable bpf AND exclude modules from being build? Thanks in advance, O. Hartmann From owner-freebsd-current@freebsd.org Fri Mar 4 08:02:22 2016 Return-Path: Delivered-To: freebsd-current@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 866929DAFC9 for ; Fri, 4 Mar 2016 08:02:22 +0000 (UTC) (envelope-from me@lexasoft.ru) 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 6A666EFD for ; Fri, 4 Mar 2016 08:02:22 +0000 (UTC) (envelope-from me@lexasoft.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 691309DAFC8; Fri, 4 Mar 2016 08:02:22 +0000 (UTC) Delivered-To: current@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 689D99DAFC6 for ; Fri, 4 Mar 2016 08:02:22 +0000 (UTC) (envelope-from me@lexasoft.ru) Received: from mail.fly-group.ru (mail.fly-group.ru [91.205.125.25]) (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 022B8EFA for ; Fri, 4 Mar 2016 08:02:21 +0000 (UTC) (envelope-from me@lexasoft.ru) Received: from localhost (localhost [127.0.0.1]) by mail.fly-group.ru (Postfix) with ESMTP id CACE2209C48C for ; Fri, 4 Mar 2016 11:02:11 +0300 (MSK) Received: from mail.fly-group.ru ([127.0.0.1]) by localhost (mail.fly-group.ru [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id LKPLcWFNgHdL; Fri, 4 Mar 2016 11:02:11 +0300 (MSK) Received: from localhost (localhost [127.0.0.1]) by mail.fly-group.ru (Postfix) with ESMTP id 0D959209C484; Fri, 4 Mar 2016 11:02:11 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.9.2 mail.fly-group.ru 0D959209C484 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lexasoft.ru; s=108F67EA-0FB0-11E3-B95A-30512DDDB480; t=1457078531; bh=3Dj4to1ycYR33BR4JWctxbyq5eM2Apirw0W01dYkwS8=; h=From:Content-Type:Subject:Date:Message-Id:To:Mime-Version; b=FGhxs0ExqNdoDKTGU4p2E+2gnQzNtrhaSDPjD5exU28dbu++LgelD9iHUazXxb4p0 6kSVaWXPvCXdDsEf5uwGgXWzKBsbMVGr76B/vyLP4Ty1hZwSInC7y5VxLpRYEgaAth 6i2TUuYXL4mtmV2tJjwUA1VfcwYwqnvi9iBN4uv8= X-Virus-Scanned: amavisd-new at mail.fly-group.ru Received: from mail.fly-group.ru ([127.0.0.1]) by localhost (mail.fly-group.ru [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dnJwQT2zAWJc; Fri, 4 Mar 2016 11:02:10 +0300 (MSK) Received: from [10.1.2.10] (unknown [5.79.104.170]) by mail.fly-group.ru (Postfix) with ESMTPSA id 8C420209C47D; Fri, 4 Mar 2016 11:02:10 +0300 (MSK) From: Alexey Tarasov Content-Type: multipart/signed; boundary="Apple-Mail=_192845DF-E756-483E-A746-24A0BBA8486B"; protocol="application/pkcs7-signature"; micalg=sha1 Subject: Virtio network: poor performance with KVM hypervisor (latest Proxmox) Date: Fri, 4 Mar 2016 11:02:08 +0300 Message-Id: Cc: =?utf-8?B?0KLQsNGA0LDRgdC+0LIg0JDQu9C10LrRgdC10LnigI4KINCS0Lg=?= =?utf-8?B?0LrRgtC+0YDQvtCy0LjRhw==?= To: current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-Mailman-Approved-At: Fri, 04 Mar 2016 12:18:51 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 08:02:22 -0000 --Apple-Mail=_192845DF-E756-483E-A746-24A0BBA8486B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all!=20 I am using the latest Proxmox 4.1 with all updates installed.=20 I have several VM's with FreeBSD guests and 1 VM with Ubuntu 14 (all = KVM).=20 Host system file download speed: 60 MBps.=20 FreeBSD guest download speed: 2 MBps on virtio network with TSO enabled, = 5-9 MBps with TSO disabled; 12 MBps on e1000 network.=20 Ubuntu guest: 60 MBps with virtio.=20 I've tried the following:=20 1) Different FreeBSD versions: 9.3, 10.2, 10.3-BETA3.=20 2) Different TSO settings, enabling/disabling RXCSUM.=20 3) Different TSO settings on host system.=20 The best results I got described above :(=20 Does anyone have any ideas how to get full network performance inside = FreeBSD guests?=20 -- Alexey Tarasov (\__/)=20 (=3D'.'=3D)=20 E[: | | | | :]=D0=97=20 (")_(") --Apple-Mail=_192845DF-E756-483E-A746-24A0BBA8486B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBT4w ggQmoAMCAQICEGM37e7QrPrTTQE5t15vU6owDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAzIENsaWVudCBDQTAeFw0xNjAyMTYx NTU0NDVaFw0xOTAyMTYxNTU0NDVaMH4xCzAJBgNVBAYTAkNZMRAwDgYDVQQIDAdMYXJuYWNhMRAw DgYDVQQHDAdMYXJuYWNhMRMwEQYDVQQKDApTb2JtYWcgTHRkMRcwFQYDVQQDDA5BbGV4ZXkgVGFy YXNvdjEdMBsGCSqGSIb3DQEJARYObWVAbGV4YXNvZnQucnUwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQC+8slwuQl/KMAu7oVUIaru4AMqnj0b3Lg8kj8/caa/UCRiDT1RyJCQ4cIcCjM6 e4aVJhSCbJ8j46U8D47ZYn9OQ70+c2vlaX+slMIgDhb9mfK3ONtjiow7GrAAKUuGbmFV22hENubw hPWXd6wt4/lQkDd6qEibd1UkSJKgrrriCZ2Sr1qTVf8/9ON+PAuG6UOekcLzDn3y1WQyRUzJazEz ZViSXLYJJDS5sZ/K+E4rQPF427X8aL8oQfwijR9YCQY1iFDo2Dfady4LLMtw/gUS6shx29mj9/Du vX8tCb3ZIO08/O59fwfT5IeJ/CjObl2pKdKpR97fUNwdsgseLVCdAgMBAAGjggG/MIIBuzAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFO3UN7rXXd392DNxbKLJ95QrKufwMB8GA1UdIwQYMBaAFDRac8Qfq3FjZ7NPwJstIKed 5skfMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50My5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDMu Y3JsMBkGA1UdEQQSMBCBDm1lQGxleGFzb2Z0LnJ1MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tLzBUBgNVHSAETTBLMAwGCisGAQQBgbU3BgEwOwYLKwYBBAGBtTcBAgQwLDAqBggr BgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IB AQARYZ+R33xZF/iQxyHV8u4U0DlHjzCD7D0038pyCzLzkXFjjC9/Le8FXssrw/pExTZE1wtb6dlb 6cMUSGzKh7qafqNTgzP4j1ug+nRbmpFhd7IQs466K112Olc4tBIW4ey35QZvp7QJ6WCZM3Ts825K /xDDbJGMy6vkmxqv3dGe7SHudo0cDquY1lk4PUUrOT9JSIuRawr8Ik4ViTIz1+2Ez1MzP8WCNqYg x5FQjHAZoxO5ASoo2maRwL9PJiRrury0mV5/7x0qN9xG8F2QOhIItSfM1IOwN55x8Hrzbp3w072B Tk4jM80vMh91Jw4q74b38AWxVoNPYRcRSwVXk0auMIIF4jCCA8qgAwIBAgIQNnlSVMsTVZ4wJtIr LksQ6zANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1WhcNMzAxMjE2 MDEwMDA1WjB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNz IDMgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iNw4XNWMxV6aJ+o rxVhEO+PFTERzmygUF9p3djV7ttm5/MpvX/JNqUxdbqJ6lqGJEG1r36L2d/T1G3QISM1GWRRVNWN 1DFSM1YZy8D/tsaosU4HkO1zpzrqh2Ex+J8S+sVFzqhcMTrwKK+jX2yZoUmh7s/OTQNfLmX5/z7w t5KQrawJ5hNIpR5wzWS3q/3nmGBZBYp6GpbhdKzmI4k6pbOmtbhPGdAtBN6ahARQxog7ZQF+h5dM J5yUL0OAO9KXpMDQOomIsFYDoEUEzgoKaU46zVZ/dPdDLdLe0C7DaCWTRXEOpsoL/dk8xOtT2azP hSG62CfUc1o4Y9wP3cD4rwIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQrMCkwJ6AloCOG IWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRaMFgwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0cDovL2FpYS5z dGFydHNzbC5jb20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBQ0WnPEH6txY2ezT8CbLSCnnebJHzAf BgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUdIAAwLDAqBggr BgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IC AQC0a9N7fLS6jr6GeBJE58fgLMvcaZd9AO23V6+m39+zsWxWAJPWE7O41YFCf0pcJCXN+TGbkwEK oZRbPfdz6N2JOKcjOfgHDJoR2z9sZYAFIKDdq7tCvk0AbqXrlEP7FFr4nKsJJy+3WUIiUCYPSgjk JUJ7RiTS15ZrZlJFkZ/7VLZ7KbMYqHpNpTSrahgU+PB/tNmwNwPRHOSWt3ceyMZnLVZQHfPDl5OD kec0FDXTsjt73zGeOGzMhSnjKZhGgKvjxKeo6JsJtSlpV21OU+zy3GClEPiIPfsMDI6yVvtMVwX5 604w+0Ppib7eKJ9SkfwCbzlK5SxTbXYHS3XS+wZPtlMPbNZ2mls6QXudw5RBilAKxcI07jRTblSV tU+hZvSsH9yp8tO2xPdvaYIO309KN+NLkCBlG6Zpask/KmaHVVMia6JUcUDsz/75VefE/RgP7Rg7 OQPy/U+9FH29zsP4XkQTyC1XIw7g0mBmK1U51g1KsVRiqun90VpFa4O92HkVuUkLqCTF6ji6W2C6 O6D6qv9GC3sU1RqG80BcPyycykh/lz69IgBTZdurs4RG2cl5pXvZPWzT0uA9k/EqJu1egM58ICHi vi1P9mtbst7Gm3iWAXng9jvV2MYSpM+1w2OAgL80iOogAQR5PrXWUgHw8VPerf26OnVi5IBJFASs YTGCA04wggNKAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkw JwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRD b20gQ2xhc3MgMyBDbGllbnQgQ0ECEGM37e7QrPrTTQE5t15vU6owCQYFKw4DAhoFAKCCAZkwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwMzA0MDgwMjA5WjAjBgkq hkiG9w0BCQQxFgQU/71PJpFLWslCVSBfe0zfNXCKPjcwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDMgQ2xpZW50IENB AhBjN+3u0Kz6000BObdeb1OqMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDMgQ2xpZW50IENBAhBjN+3u0Kz6000B Obdeb1OqMA0GCSqGSIb3DQEBAQUABIIBAJuyrYfyx2EnMgmyqxYqeun30bfxViQxaij25agQuBPs NAOntFSXF+80spL3xNXQ6+grW6DeLeDlGvIkqeFi3N3OWSrQitDU/TQ9ZJdLZRXWjy9dsQYwVj+F dMxiCL7p0nFKH1D8hoRFVVsIRA7jStQe+0ChZ7oez7iRwXxUZrcXS3YC/E2fEGLrybmEdAL2OpIS L1eZC/5BGWtIfpk1QrejQeGc0GMsReSvWfEjBsjpMx3Fh08otW3mvm7A5G5Z7wq4va+xiYAmjxmD 2+41x6xwwr6Uf5WdFE167LR4ER8FfTpmE7r9saTCtcvQqXqEymH0FhuuDL6ysgNHHuV5RnUAAAAA AAA= --Apple-Mail=_192845DF-E756-483E-A746-24A0BBA8486B-- From owner-freebsd-current@freebsd.org Fri Mar 4 12:53:36 2016 Return-Path: Delivered-To: freebsd-current@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 37E4B9DAD65 for ; Fri, 4 Mar 2016 12:53:36 +0000 (UTC) (envelope-from satan@ukr.net) 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 28AE5EBC for ; Fri, 4 Mar 2016 12:53:36 +0000 (UTC) (envelope-from satan@ukr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 251639DAD64; Fri, 4 Mar 2016 12:53:36 +0000 (UTC) Delivered-To: current@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 0ABB29DAD61 for ; Fri, 4 Mar 2016 12:53:36 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (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 C51D0EB6 for ; Fri, 4 Mar 2016 12:53:35 +0000 (UTC) (envelope-from satan@ukr.net) Received: from satan by hell.ukr.net with local ID 1abp2M-0006Y7-2B for current@freebsd.org; Fri, 04 Mar 2016 14:40:54 +0200 Date: Fri, 4 Mar 2016 14:40:54 +0200 From: Vitalij Satanivskij To: current@freebsd.org Subject: CURRENT r296381 panic in vn_sendfile (/usr/src/sys/kern/kern_sendfile.c:833) Message-ID: <20160304124053.GA25071@hell.ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 12:53:36 -0000 Hello. I get kernel panic on high loaded server with messages savecore: reboot after panic: vn_sendfile: mlen 326 space -20 hdrlen 326 # kgdb kernel.debug /var/crash/vmcore.0 Unread portion of the kernel message buffer: panic: vn_sendfile: mlen 326 space -20 hdrlen 326 cpuid = 5 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe20206314f0 vpanic() at vpanic+0x182/frame 0xfffffe2020631570 kassert_panic() at kassert_panic+0x126/frame 0xfffffe20206315e0 vn_sendfile() at vn_sendfile+0x14ca/frame 0xfffffe2020631900 sys_sendfile() at sys_sendfile+0x11e/frame 0xfffffe20206319a0 amd64_syscall() at amd64_syscall+0x2db/frame 0xfffffe2020631ab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe2020631ab0 --- syscall (393, FreeBSD ELF64, sys_sendfile), rip = 0x801ef062a, rsp = 0x7fffffffd8d8, rbp = 0x7fffffffe1d0 --- KDB: enter: panic Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/zfs.ko.debug...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /usr/lib/debug//boot/kernel/opensolaris.ko.debug...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/carp.ko...Reading symbols from /usr/lib/debug//boot/kernel/carp.ko.debug...done. done. Loaded symbols for /boot/kernel/carp.ko Reading symbols from /boot/kernel/ums.ko...Reading symbols from /usr/lib/debug//boot/kernel/ums.ko.debug...done. done. Loaded symbols for /boot/kernel/ums.ko Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/tmpfs.ko.debug...done. done. Loaded symbols for /boot/kernel/tmpfs.ko #0 doadump (textdump=0) at pcpu.h:221 221 __asm("movq %%gs:%1,%0" : "=r" (td) (kgdb) bt #0 doadump (textdump=0) at pcpu.h:221 #1 0xffffffff80384a0b in db_dump (dummy=, dummy2=false, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:533 #2 0xffffffff803847fe in db_command (cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:440 #3 0xffffffff80384594 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 #4 0xffffffff8038702b in db_trap (type=, code=0) at /usr/src/sys/ddb/db_main.c:251 #5 0xffffffff80a656e3 in kdb_trap (type=3, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff80ea1298 in trap (frame=0xfffffe2020631420) at /usr/src/sys/amd64/amd64/trap.c:556 #7 0xffffffff80e81a77 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:234 #8 0xffffffff80a64dcb in kdb_enter (why=0xffffffff813b6c2f "panic", msg=0x80
) at cpufunc.h:63 #9 0xffffffff80a27b5f in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:750 #10 0xffffffff80a279b6 in kassert_panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:647 #11 0xffffffff80a25efa in vn_sendfile (fp=, sockfd=1619, hdr_uio=, trl_uio=0x0, offset=0, nbytes=, sent=, flags=, kflags=, td=0xa8) at /usr/src/sys/kern/kern_sendfile.c:833 #12 0xffffffff80a2641e in sys_sendfile (td=0xfffff80253593000, uap=0xfffffe2020631a40) at file.h:382 #13 0xffffffff80ea214b in amd64_syscall (td=0xfffff80253593000, traced=0) at subr_syscall.c:135 #14 0xffffffff80e81d5b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:394 #15 0x0000000801ef062a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) list *0xffffffff80a25efa 0xffffffff80a25efa is in vn_sendfile (/usr/src/sys/kern/kern_sendfile.c:833). 828 free(sfio, M_TEMP); 829 goto done; 830 } 831 832 /* Add the buffer chain to the socket buffer. */ 833 KASSERT(m_length(m, NULL) == space + hdrlen, 834 ("%s: mlen %u space %d hdrlen %d", 835 __func__, m_length(m, NULL), space, hdrlen)); 836 837 CURVNET_SET(so->so_vnet); System have 128Gb memory zfs as FS DB's worked on it and web pages served by this server. core saved. panic periodicaly repeted (few hours -- up to few days) Before this, old current (about two year old CURRENT ) work on this server without crashes. Can anybody point me to way of more complex problem diagnostic or any other useful things Thank you. From owner-freebsd-current@freebsd.org Fri Mar 4 16:47:45 2016 Return-Path: Delivered-To: freebsd-current@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 ADB669DAA0C for ; Fri, 4 Mar 2016 16:47:45 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 79F306BC for ; Fri, 4 Mar 2016 16:47:44 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id u24GlcHr031496 for ; Fri, 4 Mar 2016 08:47:44 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD CURRENT" From: "Chris H" Subject: ERROR: ctfconvert: *.o doesn't have type data to convert Date: Fri, 04 Mar 2016 08:47:44 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 16:47:45 -0000 I've just finished building world, and am building a custom kernel. (11-CURRENT svn co from yesterday, and on an i386) I see the following message emitted on every lib being processed during the build: ERROR: ctfconvert: *.o doesn't have type data to convert (replace the asterisk (*) with any given library) Will this result in an unusable kernel? Should I be concerned? Thanks! --Chris From owner-freebsd-current@freebsd.org Fri Mar 4 18:47:59 2016 Return-Path: Delivered-To: freebsd-current@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 33FB9A09D38 for ; Fri, 4 Mar 2016 18:47:59 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 F1027AAF for ; Fri, 4 Mar 2016 18:47:58 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id u24IlvdQ042688 for ; Fri, 4 Mar 2016 10:48:03 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: References: From: "Chris H" Subject: Re: ERROR: ctfconvert: *.o doesn't have type data to convert Date: Fri, 04 Mar 2016 10:48:03 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 18:47:59 -0000 On Fri, 04 Mar 2016 08:47:44 -0800 "Chris H" wrote > I've just finished building world, and am building a custom kernel. > (11-CURRENT svn co from yesterday, and on an i386) > > I see the following message emitted on every lib being processed > during the build: > > ERROR: ctfconvert: *.o doesn't have type data to convert > (replace the asterisk (*) with any given library) > > Will this result in an unusable kernel? Should I be concerned? > Well. It didn't seem to cause any *real* harm. (new) kernel doesn't (yet) seem to exhibit any unexpected behavior. --Chris From owner-freebsd-current@freebsd.org Fri Mar 4 19:18:45 2016 Return-Path: Delivered-To: freebsd-current@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 170019DAB56 for ; Fri, 4 Mar 2016 19:18:45 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 DCE80C7 for ; Fri, 4 Mar 2016 19:18:44 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pf0-x233.google.com with SMTP id 4so40113089pfd.1 for ; Fri, 04 Mar 2016 11:18:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=h+UjdrLhDMSjH+Gmvl1RPYnJuBy/RdudyMdALsDBNSE=; b=xePj2KRUW8lXTTJH4nSNszC8/xbzlEEug04x9T109kc/3B78jpM1MpZzU0XGiSegKk 85dy273DmWaFg9VDAhGikpoxcyFgGqoC7+WQqopKslf3TWcICxKnCLxuFpBCU7qON49w 0CsdAujBKUPCJn2pQIQfiPTSLBof5Ou/XBjvHui5ro8oJ05ruKFwNmGIBWLTjOUR0MtY cWdfCTh0YR/Hfx80op121JNVtJPEPJFC/AErFCvQ+jq8XPMAEq3EQ++gtk8tKyfOd3li TpvSp8qQS7Gq1+zuwJXNo8ysbyoqycHThfffKVyo4Dn+Cy+7/RedaouvN/7ZOJxiGFse Bowg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=h+UjdrLhDMSjH+Gmvl1RPYnJuBy/RdudyMdALsDBNSE=; b=Emozm3fbF+achIZk8/AsP3/6aWlPzYTyNWjwRKBhjjCs/zjkAP+YV7qQlzQXDd/P2v 4IA2eCdYOQ7QDSdwLN+W/W1vXfjUese43V2aP6m8z6dus6gtwzbiDROVhogIxX18C6H2 KJSfjzgOx83HE6v96Mh6lQZZAwNQ9nryTH4zw4L5XVccKA6BVWld+kPsOOpCg6Jo/VAz swCnC0ldG7FmvG0qlTZJk/9us3MztKA7MSUA21v+PVBCkh8+JxofEsgi6fIKOGV5x1XI 3PPoWEw+Dim47XRvM1PvSg46wkHBWwP+3V4O3OVX14f6IZQ9C2bH+Sb9aHoIvO3GW9TB Po1Q== X-Gm-Message-State: AD7BkJKQztFoVQKPgYc5GqBdMddt0RXaifMLd0vueyaj63Tt2vjAMAo/JjmBRCm6JC0Z1Q== X-Received: by 10.98.9.27 with SMTP id e27mr14530928pfd.59.1457119124446; Fri, 04 Mar 2016 11:18:44 -0800 (PST) Received: from wkstn-mjohnston.west.isilon.com (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by smtp.gmail.com with ESMTPSA id v7sm7247235pfi.56.2016.03.04.11.18.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Mar 2016 11:18:43 -0800 (PST) Sender: Mark Johnston Date: Fri, 4 Mar 2016 11:21:33 -0800 From: Mark Johnston To: Chris H Cc: FreeBSD CURRENT Subject: Re: ERROR: ctfconvert: *.o doesn't have type data to convert Message-ID: <20160304192133.GA52454@wkstn-mjohnston.west.isilon.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 19:18:45 -0000 On Fri, Mar 04, 2016 at 08:47:44AM -0800, Chris H wrote: > I've just finished building world, and am building a custom kernel. > (11-CURRENT svn co from yesterday, and on an i386) > > I see the following message emitted on every lib being processed > during the build: > > ERROR: ctfconvert: *.o doesn't have type data to convert > (replace the asterisk (*) with any given library) This is probably because your kernel config contains "makeoptions WITH_CTF=1" but not "DEBUG=-g". ctfconvert has nothing to do because no DWARF info is available, and emits that error as a result. > > Will this result in an unusable kernel? Should I be concerned? No, it'll work fine. Some parts of DTrace will not work. From owner-freebsd-current@freebsd.org Fri Mar 4 19:31:01 2016 Return-Path: Delivered-To: freebsd-current@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 C40249DB0F6 for ; Fri, 4 Mar 2016 19:31:01 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 AC0599AC for ; Fri, 4 Mar 2016 19:31:01 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id u24JV13q045790 for ; Fri, 4 Mar 2016 11:31:07 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <5edad7eb58694a7b7da11bbb9a82e9a3@ultimatedns.net> References: , , <5edad7eb58694a7b7da11bbb9a82e9a3@ultimatedns.net> From: "Chris H" Subject: Re: Several LOR's with most recent install media Date: Fri, 04 Mar 2016 11:31:07 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <5fc9215ffffee8a03b5c0dc883129042@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 19:31:01 -0000 On Thu, 03 Mar 2016 07:24:11 -0800 "Chris H" wrote > On Wed, 02 Mar 2016 23:00:44 -0800 "Chris H" wrote > > > On Wed, 02 Mar 2016 21:49:39 -0800 "Chris H" wrote > > > > > Hello all, > > > I just finished an install off of the > > > 11.0-CURRENT-i386-20160206-r295345-bootonly iso image burnt to DVD. > > > After rebooting to the fresh install; shutting down the system > > > results in several LOR's. Given so much information is dumped to > > > screen, and that I no longer have access to the system; How can I > > > get a copy of the LOR's output? I can capture the screen with my > > > cell phone. But the information would sure be a lot more valuable > > > in text form; no? :-) > > > > > > Thanks for any suggestions. > > > > > OK. Just got a couple more while checking out head/ports > > > > Mar 2 22:00:00 spare newsyslog[705]: logfile turned over due to size>100K > > Mar 2 22:12:00 spare kernel: lock order reversal: > > Mar 2 22:12:00 spare kernel: 1st 0xda5f45a0 bufwait (bufwait) @ > > /usr/src/sys/kern/vfs_bio.c:3488 > > Mar 2 22:12:00 spare kernel: 2nd 0xc6880600 dirhash (dirhash) @ > > /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 > > Mar 2 22:12:00 spare kernel: stack backtrace: > > Mar 2 22:12:00 spare kernel: #0 0xc0c86001 at witness_debugger+0x81 > > Mar 2 22:12:00 spare kernel: #1 0xc0c85f2a at witness_checkorder+0xd6a > > Mar 2 22:12:00 spare kernel: #2 0xc0c31a5 > > Mar 2 22:12:00 spare kernel: 1 at _sx_xlock+0x71 > > Mar 2 22:12:00 spare kernel: #3 0xc0ef0b > > Mar 2 22:12:01 spare kernel: 70 at ufsdirhash_add+0x40 > > Mar 2 22:12:01 spare kernel: #4 0xc0ef3b32 at ufs_direnter+0x682 > > Mar 2 22:12:01 spare kernel: #5 0xc0efc8bb at ufs_mkdir+0x7eb > > Mar 2 22:12:01 spare kernel: #6 0xc11ad428 at VOP_MKDIR_APV+0x108 > > Mar 2 22:12:01 spare kernel: #7 0xc0ced83a at kern_mkdirat+0x23a > > Mar 2 22:12:01 spare kernel: #8 0xc0ced5f1 at sys_mkdir+0x31 > > Mar 2 22:12:01 spare kernel: #9 0xc117d4ed at syscall+0x37d > > Mar 2 22:12:01 spare kernel: #10 0xc116827f at Xint0x80_syscall+0x2f > > Mar 2 22:19:31 spare kernel: lock order reversal: > > Mar 2 22:19:31 spare kernel: 1st 0xc71704a4 ufs (ufs) @ > > /usr/src/sys/kern/vfs_subr.c:873 > > Mar 2 22:19:31 spare kernel: 2nd 0xda5f4458 bufwait (bufwait) @ > > /usr/src/sys/ufs/ffs/ffs_vnops.c:263 > > Mar 2 22:19:31 spare kernel: 3rd 0xcb9e07f8 ufs (ufs) @ > > /usr/src/sys/kern/vfs_subr.c:2476 > > Mar 2 22:19:31 spare kernel: stack backtrace: > > Mar 2 22:19:31 spare kernel: #0 0xc0c86001 at witness_debugger+0x81 > > Mar 2 22:19:31 spare kernel: #1 0xc0c85f2a at witness_checkorder+0xd6a > > Mar 2 22:19:31 spare kernel: #2 0xc0c00c57 at __lockmgr_args+0xd57 > > Mar 2 22:19:31 spare kernel: #3 0xc0eeb374 at ffs_lock+0x84 > > Mar 2 22:19:31 spare kernel: #4 0xc11adef8 at VOP_LOCK1_APV+0x118 > > Mar 2 22:19:31 spare kernel: #5 0xc0cf0b16 at _vn_lock+0x96 > > Mar 2 22:19:31 spare kernel: #6 0xc0cdf2d4 at vget+0x64 > > Mar 2 22:19:31 spare kernel: #7 0xc0cd1a01 at vfs_hash_get+0xd1 > > Mar 2 22:19:31 spare kernel: #8 0xc0ee5d64 at ffs_vgetf+0x44 > > Mar 2 22:19:31 spare kernel: #9 0xc0edd36b at softdep_sync_buf+0xb0b > > Mar 2 22:19:31 spare kernel: #10 0xc0eec0ba at ffs_syncvnode+0x2aa > > Mar 2 22:19:31 spare kernel: #11 0xc0eeb206 at ffs_fsync+0x26 > > Mar 2 22:19:31 spare kernel: #12 0xc11acde8 at VOP_FSYNC_APV+0x108 > > Mar 2 22:19:31 spare kernel: #13 0xc0cbfc40 at bufsync+0x40 > > Mar 2 22:19:31 spare kernel: #14 0xc0cdd1f4 at bufobj_invalbuf+0x94 > > Mar 2 22:19:31 spare kernel: #15 0xc0ce07d0 at vgonel+0x1b0 > > Mar 2 22:19:31 spare kernel: #16 0xc0ce374b at vnlru_proc+0x65b > > Mar 2 22:19:31 spare kernel: #17 0xc0bead5e at fork_exit+0x7e > > > > Sorry for any undesirable line-wraps. > > I can attache the output, if needed. > > > > Thanks for any help preventing these. > > > OK. Got another one wile checking out /usr/src > > Mar 3 06:45:41 spare kernel: 1st 0xda5fc478 bufwait (bufwait) @ > /usr/src/sys/kern/vfs_bio.c:3488 > Mar 3 06:45:41 spare kernel: 2nd 0xcbf89a00 dirhash (dirhash) @ > /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 > Mar 3 06:45:41 spare kernel: stack backtrace: > Mar 3 06:45:41 spare kernel: #0 0xc0c86001 at witness_debugger+0x81 > Mar 3 06:45:41 spare kernel: #1 0xc0c85f2a at witness_checkorder+0xd6a > Mar 3 06:45:41 spare kernel: #2 0xc0c31a51 at _sx_xlock+0x71 > Mar 3 06:45:41 spare kernel: #3 0xc0ef0b70 at ufsdirhash_add+0x40 > Mar 3 06:45:41 spare kernel: #4 0xc0ef3b32 at ufs_direnter+0x682 > Mar 3 06:45:41 spare kernel: #5 0xc0efc8bb at ufs_mkdir+0x7eb > Mar 3 06:45:41 spare kernel: #6 0xc11ad428 at VOP_MKDIR_APV+0x108 > Mar 3 06:45:41 spare kernel: #7 0xc0ced83a at kern_mkdirat+0x23a > Mar 3 06:45:41 spare kernel: #8 0xc0ced5f1 at sys_mkdir+0x31 > Mar 3 06:45:41 spare kernel: #9 0xc117d4ed at syscall+0x37d > Mar 3 06:45:41 spare kernel: #10 0xc116827f at Xint0x80_syscall+0x2f > Mar 3 06:50:42 spare kernel: lock order reversal: > Mar 3 06:50:42 spare kernel: 1st 0xc880ca30 ufs (ufs) @ > /usr/src/sys/kern/vfs_subr.c:873 > Mar 3 06:50:42 spare kernel: 2nd 0xda651cd8 bufwait (bufwait) @ > /usr/src/sys/ufs/ffs/ffs_vnops.c:263 > Mar 3 06:50:42 spare kernel: 3rd 0xcb3675c0 ufs (ufs) @ > /usr/src/sys/kern/vfs_subr.c:2476 > Mar 3 06:50:42 spare kernel: stack backtrace: > Mar 3 06:50:42 spare kernel: #0 0xc0c86001 at witness_debugger+0x81 > Mar 3 06:50:42 spare kernel: #1 0xc0c85f2a at witness_checkorder+0xd6a > Mar 3 06:50:42 spare kernel: #2 0xc0c00c57 at __lockmgr_args+0xd57 > Mar 3 06:50:42 spare kernel: #3 0xc0eeb374 at ffs_lock+0x84 > Mar 3 06:50:42 spare kernel: #4 0xc11adef8 at VOP_LOCK1_APV+0x118 > Mar 3 06:50:42 spare kernel: #5 0xc0cf0b16 at _vn_lock+0x96 > Mar 3 06:50:42 spare kernel: #6 0xc0cdf2d4 at vget+0x64 > Mar 3 06:50:42 spare kernel: #7 0xc0cd1a01 at vfs_hash_get+0xd1 > Mar 3 06:50:42 spare kernel: #8 0xc0ee5d64 at ffs_vgetf+0x44 > Mar 3 06:50:42 spare kernel: #9 0xc0edd36b at softdep_sync_buf+0xb0b > Mar 3 06:50:42 spare kernel: #10 0xc0eec0ba at ffs_syncvnode+0x2aa > Mar 3 06:50:42 spare kernel: #11 0xc0eeb206 at ffs_fsync+0x26 > Mar 3 06:50:42 spare kernel: #12 0xc11acde8 at VOP_FSYNC_APV+0x108 > Mar 3 06:50:42 spare kernel: #13 0xc0cbfc40 at bufsync+0x40 > Mar 3 06:50:42 spare kernel: #14 0xc0cdd1f4 at bufobj_invalbuf+0x94 > Mar 3 06:50:42 spare kernel: #15 0xc0ce07d0 at vgonel+0x1b0 > Mar 3 06:50:42 spare kernel: #16 0xc0ce374b at vnlru_proc+0x65b > Mar 3 06:50:42 spare kernel: #17 0xc0bead5e at fork_exit+0x7e > > This one looks *very* similar to what I get at shutdown(8). Only it > is repeated 3 times -- presumably once for each slice (excluding swap). > > Please let me know if you need any more info, or I should blow > this attempted install away, and wait for another (newer) revision. > Well, it didn't seem adversely affect building/installing world/kernel. While several LOR's flashed on the screen during the buildworld session. The results of the installed world/kernel seem to be unaffected. If nothing else; perhaps the output I've provided above will somehow be helpful, for removing them (LOR's) in future versions. :) --Chris From owner-freebsd-current@freebsd.org Fri Mar 4 19:47:28 2016 Return-Path: Delivered-To: freebsd-current@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 C7E689DB6BD for ; Fri, 4 Mar 2016 19:47:28 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 AB905FE8 for ; Fri, 4 Mar 2016 19:47:28 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id u24JlSew047002 for ; Fri, 4 Mar 2016 11:47:34 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <20160304192133.GA52454@wkstn-mjohnston.west.isilon.com> References: , <20160304192133.GA52454@wkstn-mjohnston.west.isilon.com> From: "Chris H" Subject: Re: ERROR: ctfconvert: *.o doesn't have type data to convert Date: Fri, 04 Mar 2016 11:47:34 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <19eff96835bb393a6806e453c9a61b43@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 19:47:28 -0000 On Fri, 4 Mar 2016 11:21:33 -0800 Mark Johnston wrote > On Fri, Mar 04, 2016 at 08:47:44AM -0800, Chris H wrote: > > I've just finished building world, and am building a custom kernel. > > (11-CURRENT svn co from yesterday, and on an i386) > > > > I see the following message emitted on every lib being processed > > during the build: > > > > ERROR: ctfconvert: *.o doesn't have type data to convert > > (replace the asterisk (*) with any given library) > > This is probably because your kernel config contains > "makeoptions WITH_CTF=1" but not "DEBUG=-g". ctfconvert has nothing to > do because no DWARF info is available, and emits that error as a result. Right you are. I also considered something to that affect, but was *sure* I had commented *both* DEBUG=-g and WITH_CFT=1. But a quick check reveals I forgot WITH_CFT=1 -- D'OH! Thanks, Mark! > > > > > Will this result in an unusable kernel? Should I be concerned? > > No, it'll work fine. Some parts of DTrace will not work. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --Chris From owner-freebsd-current@freebsd.org Fri Mar 4 21:47:48 2016 Return-Path: Delivered-To: freebsd-current@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 D66B1A090EB for ; Fri, 4 Mar 2016 21:47:48 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 8B885EC0 for ; Fri, 4 Mar 2016 21:47:48 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190c-b7bff70000000df6-a6-56da014faec3 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 1A.F7.03574.F410AD65; Fri, 4 Mar 2016 16:42:39 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u24LgcoX029872; Fri, 4 Mar 2016 16:42:38 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u24LgZbL027386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Mar 2016 16:42:37 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u24LgY0M000403; Fri, 4 Mar 2016 16:42:34 -0500 (EST) Date: Fri, 4 Mar 2016 16:42:34 -0500 (EST) From: Benjamin Kaduk To: Chris H cc: freebsd-current@freebsd.org Subject: Re: Several LOR's with most recent install media In-Reply-To: <5edad7eb58694a7b7da11bbb9a82e9a3@ultimatedns.net> Message-ID: References: , <5edad7eb58694a7b7da11bbb9a82e9a3@ultimatedns.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsUixG6nruvPeCvMYPFuDou5M9axW8x584HJ gcnj44oVrB4zPs1nCWCK4rJJSc3JLEst0rdL4Mr4+2YNU8EMnooJk5vYGhjfcHYxcnBICJhI TN1X0cXIxSEk0MYkseJfByOEs4FR4u3mG+wQzkEmicX9c4EcTiCnXuLqqiNMIDaLgJbEuXPH GUFsNgEViZlvNrKB2CJA9r7Gt8wgNrOAvMT/K5fB6oUFLCX+3usGq+cUsJe4P3c2mM0r4Chx aeFbRoj5SxklznRyg9iiAjoSq/dPYYGoEZQ4OfMJC8RMLYnl07exTGAUmIUkNQtJagEj0ypG 2ZTcKt3cxMyc4tRk3eLkxLy81CJdQ73czBK91JTSTYyggOSU5NnBeOaN1yFGAQ5GJR7eF89u hgmxJpYVV+YeYpTkYFIS5b39ECjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhHftbqAcb0piZVVq UT5MSpqDRUmct3D/6TAhgfTEktTs1NSC1CKYrAwHh5IErz3DrTAhwaLU9NSKtMycEoQ0Ewcn yHAeoOGWIDW8xQWJucWZ6RD5U4yKUuK85/4DbRUASWSU5sH1ghPGbibVV4ziQK8I83qDtPMA kw1c9yugwUxAgxU3XAMZXJKIkJJqYBRgCxCxqnt8W3LmbqM7Zc3pjwXLrqVFtxY3zwj6pBY5 c4ZDauxEybfPudLsfmpe873ncyd7w3ybsKdMuy728bZNmHbtzdM+Js+g1HkLDt2cI1tye0N3 SILqQh9bj5uvLF4GzPb59C2q0yqkJOrMBn/WW48y3pTUrN4WcEbKhPH+MYWrXR5TMpVYijMS DbWYi4oTAfsfJ+fzAgAA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 21:47:49 -0000 On Thu, 3 Mar 2016, Chris H wrote: > > > > Mar 2 22:00:00 spare newsyslog[705]: logfile turned over due to size>100K > > Mar 2 22:12:00 spare kernel: lock order reversal: > > Mar 2 22:12:00 spare kernel: 1st 0xda5f45a0 bufwait (bufwait) @ > > /usr/src/sys/kern/vfs_bio.c:3488 > > Mar 2 22:12:00 spare kernel: 2nd 0xc6880600 dirhash (dirhash) @ > > /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 bufwait/dirhash is "well-known" and harmless > > Mar 2 22:19:31 spare kernel: lock order reversal: > > Mar 2 22:19:31 spare kernel: 1st 0xc71704a4 ufs (ufs) @ > > /usr/src/sys/kern/vfs_subr.c:873 > > Mar 2 22:19:31 spare kernel: 2nd 0xda5f4458 bufwait (bufwait) @ > > /usr/src/sys/ufs/ffs/ffs_vnops.c:263 > > Mar 2 22:19:31 spare kernel: 3rd 0xcb9e07f8 ufs (ufs) @ > > /usr/src/sys/kern/vfs_subr.c:2476 As is this one. > OK. Got another one wile checking out /usr/src > > Mar 3 06:45:41 spare kernel: 1st 0xda5fc478 bufwait (bufwait) @ > /usr/src/sys/kern/vfs_bio.c:3488 > Mar 3 06:45:41 spare kernel: 2nd 0xcbf89a00 dirhash (dirhash) @ > /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 This is the same as the first one; still harmless. > > Please let me know if you need any more info, or I should blow > this attempted install away, and wait for another (newer) revision. I don't think any of those actions are called for; you should just ignore these particular LORs and continue using the system. (LOR printouts are conditional on certain debugging kernel options that are disabled in official release builds.) -Ben From owner-freebsd-current@freebsd.org Sat Mar 5 09:34:57 2016 Return-Path: Delivered-To: freebsd-current@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 95FCE9DAA2F for ; Sat, 5 Mar 2016 09:34:57 +0000 (UTC) (envelope-from satan@ukr.net) 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 87BADAB8 for ; Sat, 5 Mar 2016 09:34:57 +0000 (UTC) (envelope-from satan@ukr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 834199DAA2E; Sat, 5 Mar 2016 09:34:57 +0000 (UTC) Delivered-To: current@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 82D669DAA2D for ; Sat, 5 Mar 2016 09:34:57 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (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 49B4BAB7 for ; Sat, 5 Mar 2016 09:34:57 +0000 (UTC) (envelope-from satan@ukr.net) Received: from satan by hell.ukr.net with local ID 1ac8bt-000588-W4 for current@freebsd.org; Sat, 05 Mar 2016 11:34:54 +0200 Date: Sat, 5 Mar 2016 11:34:53 +0200 From: Vitalij Satanivskij To: current@freebsd.org Subject: CURRENT r296381 somewere near tcp_detach? Message-ID: <20160305093453.GA19431@hell.ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 09:34:57 -0000 Hello. Just after report about panic somewere in sendfile (http://docs.freebsd.org/cgi/getmsg.cgi?fetch=883140+0+current/freebsd-current), and disabling sendfile functionality in software (nginx) I got another kernel panic (at last twice for this moment) System message after reboot: Mar 5 05:49:11 srv11 savecore: reboot after panic: tcp_detach: INP_TIMEWAIT && INP_DROPPED && tp != NULL Mar 5 05:49:11 srv11 savecore: writing core to /var/crash/vmcore.2 kgdb kernel.debug /var/crash/vmcore.2 is : GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: tcp_detach: INP_TIMEWAIT && INP_DROPPED && tp != NULL cpuid = 11 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe1f9d1f4730 vpanic() at vpanic+0x182/frame 0xfffffe1f9d1f47b0 kassert_panic() at kassert_panic+0x126/frame 0xfffffe1f9d1f4820 tcp_usr_detach() at tcp_usr_detach+0x1bc/frame 0xfffffe1f9d1f4850 sofree() at sofree+0x1a6/frame 0xfffffe1f9d1f4880 tcp_close() at tcp_close+0x11e/frame 0xfffffe1f9d1f48b0 tcp_timer_2msl() at tcp_timer_2msl+0x278/frame 0xfffffe1f9d1f48e0 softclock_call_cc() at softclock_call_cc+0x1af/frame 0xfffffe1f9d1f49c0 softclock() at softclock+0x47/frame 0xfffffe1f9d1f49e0 intr_event_execute_handlers() at intr_event_execute_handlers+0x96/frame 0xfffffe1f9d1f4a20 ithread_loop() at ithread_loop+0xa6/frame 0xfffffe1f9d1f4a70 fork_exit() at fork_exit+0x84/frame 0xfffffe1f9d1f4ab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe1f9d1f4ab0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/zfs.ko.debug...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /usr/lib/debug//boot/kernel/opensolaris.ko.debug...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/carp.ko...Reading symbols from /usr/lib/debug//boot/kernel/carp.ko.debug...done. done. Loaded symbols for /boot/kernel/carp.ko Reading symbols from /boot/kernel/ums.ko...Reading symbols from /usr/lib/debug//boot/kernel/ums.ko.debug...done. done. Loaded symbols for /boot/kernel/ums.ko Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/tmpfs.ko.debug...done. done. Loaded symbols for /boot/kernel/tmpfs.ko #0 doadump (textdump=0) at pcpu.h:221 221 __asm("movq %%gs:%1,%0" : "=r" (td) (kgdb) bt #0 doadump (textdump=0) at pcpu.h:221 #1 0xffffffff80384a0b in db_dump (dummy=, dummy2=false, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:533 #2 0xffffffff803847fe in db_command (cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:440 #3 0xffffffff80384594 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 #4 0xffffffff8038702b in db_trap (type=, code=0) at /usr/src/sys/ddb/db_main.c:251 #5 0xffffffff80a656e3 in kdb_trap (type=3, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff80ea1298 in trap (frame=0xfffffe1f9d1f4660) at /usr/src/sys/amd64/amd64/trap.c:556 #7 0xffffffff80e81a77 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:234 #8 0xffffffff80a64dcb in kdb_enter (why=0xffffffff813b6c2f "panic", msg=0x80
) at cpufunc.h:63 #9 0xffffffff80a27b5f in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:750 #10 0xffffffff80a279b6 in kassert_panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:647 #11 0xffffffff80bf9bbc in tcp_usr_detach (so=) at /usr/src/sys/netinet/tcp_usrreq.c:213 #12 0xffffffff80aad0b6 in sofree (so=0xfffff81820f89000) at /usr/src/sys/kern/uipc_socket.c:820 #13 0xffffffff80bf179e in tcp_close (tp=) at /usr/src/sys/netinet/tcp_subr.c:1496 #14 0xffffffff80bf72f8 in tcp_timer_2msl (xtp=0xfffff81650263820) at /usr/src/sys/netinet/tcp_timer.c:374 #15 0xffffffff80a3d72f in softclock_call_cc (c=0xfffff81650263b68, cc=0xffffffff81d2db80, direct=0) at /usr/src/sys/kern/kern_timeout.c:723 #16 0xffffffff80a3dae7 in softclock (arg=) at /usr/src/sys/kern/kern_timeout.c:861 #17 0xffffffff809ee7b6 in intr_event_execute_handlers (p=, ie=0xfffff80114558d00) at /usr/src/sys/kern/kern_intr.c:1262 #18 0xffffffff809eee46 in ithread_loop (arg=0xfffff8011452fac0) at /usr/src/sys/kern/kern_intr.c:1275 #19 0xffffffff809ec074 in fork_exit (callout=0xffffffff809eeda0 , arg=0xfffff8011452fac0, frame=0xfffffe1f9d1f4ac0) at /usr/src/sys/kern/kern_fork.c:1034 #20 0xffffffff80e81fae in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:609 #21 0x0000000000000000 in ?? () Current language: auto; currently minimal kernel.debug and cores can be found here . http://hell.ukr.net/free/ (vmcore.1 and vmcore.2 for this panic) Some addition info If_igb, carp and pf used on server. I would appreciate any kind of help in solving the problem. From owner-freebsd-current@freebsd.org Sat Mar 5 16:15:45 2016 Return-Path: Delivered-To: freebsd-current@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 76E879DBDFB for ; Sat, 5 Mar 2016 16:15:45 +0000 (UTC) (envelope-from aneesh.for.open.source@gmail.com) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (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 42D47AE0 for ; Sat, 5 Mar 2016 16:15:45 +0000 (UTC) (envelope-from aneesh.for.open.source@gmail.com) Received: by mail-ob0-x229.google.com with SMTP id xx9so74287473obc.2 for ; Sat, 05 Mar 2016 08:15:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=RWkx71M+EZfJgjoW2bU6T4fA3mwlR6uWbcggpHOF6ts=; b=p2KFk4Z1jTVHILE8Lp7YjzbcX8UmElz5GzXtYk1JTFM/51J8jR67qjxKqNBOOu9DSf obVCcqQFjZ5hbXQTC/dMHdnc+mU5OZrLM8HczD1XMRkRms2xo77ZoxQf5+L9smAvozM7 x0zl9v+jwLep2OmdSXV0+tSdLTzxD4Lt7ZkB3t8wb/GXUysOgp1gsLyyEivphuJ4nnQb S9ywqNznVxqEo8tdMkea5s7N4HpYY/XJI0Hq3FtMXmOepUupw4L8NITlkaoYWCqREXJu DbwCLjeg92ZtJFFAVnsXO8waXmz+k2AnOkPgrxp09/1sIJ8RYFdB017xumGYISoA3iI4 s7qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=RWkx71M+EZfJgjoW2bU6T4fA3mwlR6uWbcggpHOF6ts=; b=gT/3nIFt4RnwZYk1eNhDLqM+Tyym8Bu2V/Iqw14OwomSHWAxKAeiuDWgO2/gsBuPNL V7Oi6wAQHZwJPQ/L4xkJHgIZ7nxE0Gp5F7eb97kZMTWlVGAv/QFrEminnERtN8rceZUa BW869zC6qwdixqb/9F//38Zama2wIEmJNK7NzeyjxL0UwLZdOsG5QREt/26QwXBFjumI aWAc+u8FMcSPtZce3kCAW5dGKtZJhhto3qK1y8gB2NSg87n0TkOGSAaDAMfjKidPW9FF hOhFEplMG3niyP5MCk5LfJn9AaWexIGH4twXdU58xUJuIKGUZ7fCgNEgYollJXV/ltHG yc7w== X-Gm-Message-State: AD7BkJIneK4o+LxyIsai8fieq4xPPyF8wpEU2y8uwwAIp0AkC1iCkOi8TIE8jHt6zNNHkgPMvsTVm/EiNW4d8A== MIME-Version: 1.0 X-Received: by 10.60.93.162 with SMTP id cv2mr9389393oeb.28.1457194544268; Sat, 05 Mar 2016 08:15:44 -0800 (PST) Received: by 10.202.204.145 with HTTP; Sat, 5 Mar 2016 08:15:44 -0800 (PST) Date: Sat, 5 Mar 2016 21:45:44 +0530 Message-ID: Subject: Contributing From: Aneesh Dandime To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 16:15:45 -0000 Hey guys! I want to start contributing to freebsd, but i don't know how to get started. Is there a 'easy-hacks' or 'bugs' list that I can begin with? I have downloaded freebsd-10.2-Release-amd64-bootonly. I am currently studying Operating system concepts from this book called 'Operating system concepts' by Silberschatz. I want to contribute to open source while learning from that book. Any suggestions would be really helpful. Thank You. P.S. Apologies if this is the wrong list for such queries. From owner-freebsd-current@freebsd.org Sat Mar 5 16:27:02 2016 Return-Path: Delivered-To: freebsd-current@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 07809A09214 for ; Sat, 5 Mar 2016 16:27:02 +0000 (UTC) (envelope-from lists@opsec.eu) 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 EC838F70 for ; Sat, 5 Mar 2016 16:27:01 +0000 (UTC) (envelope-from lists@opsec.eu) Received: by mailman.ysv.freebsd.org (Postfix) id E7C83A09213; Sat, 5 Mar 2016 16:27:01 +0000 (UTC) Delivered-To: current@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 E755CA09210 for ; Sat, 5 Mar 2016 16:27:01 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (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 A7CEEF6E for ; Sat, 5 Mar 2016 16:27:01 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1acF2j-000HZh-CS; Sat, 05 Mar 2016 17:27:01 +0100 Date: Sat, 5 Mar 2016 17:27:01 +0100 From: Kurt Jaeger To: Aneesh Dandime Cc: current@freebsd.org Subject: Re: Contributing Message-ID: <20160305162701.GC35640@home.opsec.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 16:27:02 -0000 Hi! > I want to start contributing to freebsd, but i don't know how to get > started. Cool. The best way to start is the questions@ mailing list: https://lists.freebsd.org/pipermail/freebsd-questions/ Try to ask and answer questions there, sometimes it's quite challenging 8-) What is your main interest ? Which programming language, which application area ? Are you into C programming or what would be of interest to you ? > Is there a 'easy-hacks' or 'bugs' list that I can begin with? There's a page with ideas: https://wiki.freebsd.org/IdeasPage and there's the Google Summer of Code ideas page: https://wiki.freebsd.org/SummerOfCodeIdeas And if you want to start bug-squashing, dig into https://bugs.freebsd.org/ and search for interesting bugs to reproduce, and propose patches. > I have downloaded freebsd-10.2-Release-amd64-bootonly. One topic that is always hot is testing and integrating new wireless and other device drivers. https://lists.freebsd.org/pipermail/freebsd-wireless/ > I am currently studying Operating system concepts from this book called > 'Operating system concepts' by Silberschatz. I want to contribute to open > source while learning from that book. I recommend reading the general handbook for the concepts: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ Then, if you really want to do operation-system coding, look at the Developers handbook. https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook If you want to have start in the application area, look at the ports tree, and it's handbook: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-current@freebsd.org Sat Mar 5 21:33:00 2016 Return-Path: Delivered-To: freebsd-current@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 57D6AA923A0 for ; Sat, 5 Mar 2016 21:33:00 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 21CF885F for ; Sat, 5 Mar 2016 21:32:59 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::801c:51b8:cf22:6fdb] (unknown [IPv6:2001:7b8:3a7:0:801c:51b8:cf22:6fdb]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A62B03E2A4 for ; Sat, 5 Mar 2016 22:32:56 +0100 (CET) From: Dimitry Andric X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) Content-Type: multipart/signed; boundary="Apple-Mail=_FDE15EB4-C101-43B0-9B07-8D2226DFE443"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: HEADS UP: clang/llvm/lldb/compiler-rt 3.8.0 imported Date: Sat, 5 Mar 2016 22:32:36 +0100 Message-Id: <06A7CAA8-1F51-4A86-97D1-F0DA938C2BC4@FreeBSD.org> To: freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 21:33:00 -0000 --Apple-Mail=_FDE15EB4-C101-43B0-9B07-8D2226DFE443 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi, I imported the (tentative) 3.8.0 release of clang, llvm, lldb and compiler-rt into head, in r296417. The upstream release is going to be very soon now, but I do not expect any changes anymore. This was tested with make universe, and a few exp-runs, but there is always a chance that you might run into something unexpected, either with the base system or ports. In such cases, please file bugs, and make sure you note somewhere in the description that it is related to this import. Last but not least, thanks to Ed Maste, Roman Divacky, Davide Italiano and Antoine Brodin for their help with the import. -Dimitry --Apple-Mail=_FDE15EB4-C101-43B0-9B07-8D2226DFE443 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.29 iEYEARECAAYFAlbbUIgACgkQsF6jCi4glqPp8QCgl8wHbMD8w1j11ZBoSJQxlLyc 9toAoPB9Z9nKeXxEybCeMXKV9dgenOOl =vUTq -----END PGP SIGNATURE----- --Apple-Mail=_FDE15EB4-C101-43B0-9B07-8D2226DFE443-- From owner-freebsd-current@freebsd.org Sat Mar 5 23:30:25 2016 Return-Path: Delivered-To: freebsd-current@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 6FFB5A13F78 for ; Sat, 5 Mar 2016 23:30:25 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 37731FB5 for ; Sat, 5 Mar 2016 23:30:24 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::801c:51b8:cf22:6fdb] (unknown [IPv6:2001:7b8:3a7:0:801c:51b8:cf22:6fdb]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 1A7A53E42D for ; Sun, 6 Mar 2016 00:30:22 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_6320E5E5-BA8C-4DFD-BF69-035F9330F839"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: HEADS UP: clang/llvm/lldb/compiler-rt 3.8.0 imported X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <06A7CAA8-1F51-4A86-97D1-F0DA938C2BC4@FreeBSD.org> Date: Sun, 6 Mar 2016 00:30:14 +0100 Message-Id: <0CAC6D2A-D16B-4BD5-90F0-3A1E2F1FC375@FreeBSD.org> References: <06A7CAA8-1F51-4A86-97D1-F0DA938C2BC4@FreeBSD.org> To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 23:30:25 -0000 --Apple-Mail=_6320E5E5-BA8C-4DFD-BF69-035F9330F839 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 05 Mar 2016, at 22:32, Dimitry Andric wrote: > > I imported the (tentative) 3.8.0 release of clang, llvm, lldb and > compiler-rt into head, in r296417. The upstream release is going to be > very soon now, but I do not expect any changes anymore. > > This was tested with make universe, and a few exp-runs, but there is > always a chance that you might run into something unexpected, either > with the base system or ports. In such cases, please file bugs, and > make sure you note somewhere in the description that it is related to > this import. Please hold off upgrading for now, if you are on amd64, and loading the aesni.ko module. It appears that loading this module can cause the kernel ELF linker to panic, but it is not yet clear why. This is being tracked in PR207729 [1]. -Dimitry https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207729 --Apple-Mail=_6320E5E5-BA8C-4DFD-BF69-035F9330F839 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.29 iEYEARECAAYFAlbbbA0ACgkQsF6jCi4glqNokQCgiaPoU1astDMmVn7+0Xpcnk52 87cAoOu0yiUEHHBFntG4ajDS3DZ8IsBL =qgSn -----END PGP SIGNATURE----- --Apple-Mail=_6320E5E5-BA8C-4DFD-BF69-035F9330F839--