Re: libcrypto.so.7 not found, needed (?) for X server
Thanks for helpful advice, too much to quote, and I am too tired anyway after a sleepless night and day, was up too late with the HP LaserJet printer. It looks like I might have to rebuild all ports except for portmaster and pkg, already done; update perl to perl5.22, check the list of ports for desired deletions and additions. pkg and "pkg check" seem to know nothing about required shared libraries in base system. Everything was built under FreeBSD-head, though I have 10.2-STABLE in a separate partition, can use that for subversion; also some USB-stick installations of FreeBSD and NetBSD that include subversion. Tom ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD_HEAD_i386 - Build #2147 - Failure
FreeBSD_HEAD_i386 - Build #2147 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2147/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2147/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2147/console Change summaries: 294370 by bdrewery: mkdep: Fix -include not being added for .depend tracking. This fixes incremental build of OpenSSH after the recent upgrade. For example, in secure/lib/libssh, -include ssh_namespace.h is used on all files. This is not tracked in the .depend file though due to MKDEP_CFLAGS not including it. The ssh example was broken in r291941 when not using FAST_DEPEND due to the .depend bug. FAST_DEPEND was not affected by this because it generates dependencies at compile time and thus sees the -include. This ugly make syntax could be simpler for bmake by using :tW but fmake-compatible syntax is used since this needs to be MFC'd all the way to stable/9. Also add a temporary hack to workaround existing checkouts building incrementally with a .depend file not having these headers. MFC after: 1 week Sponsored by: EMC / Isilon Storage Division The end of the build log: [...truncated 171045 lines...] --- iwn2030fw.c --- awk -f /usr/src/sys/tools/fw_stub.awk iwnwifi-2030-18.168.6.1.fw:iwn2030fw -miwn2030fw -ciwn2030fw.c --- depend_subdir_ix --- In file included from /usr/src/sys/modules/ix/../../dev/ixgbe/ix_txrx.c:42: In file included from /usr/src/sys/modules/ix/../../dev/ixgbe/ixgbe.h:98: /usr/src/sys/dev/pci/pci_iov.h:32:10: fatal error: 'pci_iov_if.h' file not found #include "pci_iov_if.h" ^ --- depend_subdir_iwnfw --- --- .depend --- rm -f .depend CC='cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 -include /usr/obj/usr/src/sys/GENERIC/opt_global.h iwn2030fw.c --- depend_subdir_ix --- 1 error generated. --- depend_subdir_iwnfw --- --- depend_subdir_iwn4965 --- ===> iwnfw/iwn4965 (depend) --- depend_subdir_iwn5000 --- ===> iwnfw/iwn5000 (depend) --- depend_subdir_iwn4965 --- --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- depend_subdir_ix --- In file included from /usr/src/sys/modules/ix/../../dev/ixgbe/ixgbe_osdep.c:36: --- depend_subdir_iwnfw --- --- iwn4965fw.c --- --- depend_subdir_ix --- In file included from /usr/src/sys/modules/ix/../../dev/ixgbe/ixgbe.h:98: /usr/src/sys/dev/pci/pci_iov.h:32:10: fatal error: 'pci_iov_if.h' file not found #include "pci_iov_if.h" ^ --- depend_subdir_iwnfw --- awk -f /usr/src/sys/tools/fw_stub.awk iwlwifi-4965-228.61.2.24.fw:iwn4965fw -miwn4965fw -ciwn4965fw.c --- depend_subdir_ix --- 1 error generated. --- depend_subdir_iwnfw --- --- .depend --- rm -f .depend CC='cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 -include /usr/obj/usr/src/sys/GENERIC/opt_global.h iwn4965fw.c --- depend_subdir_iwn5000 --- --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- iwn5000fw.c --- awk -f /usr/src/sys/tools/fw_stub.awk iwlwifi-5000-8.83.5.1.fw:iwn5000fw -miwn5000fw -ciwn5000fw.c --- .depend --- rm -f .depend CC='cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 -include /usr/obj/usr/src/sys/GENERIC/opt_global.h iwn5000fw.c --- depend_subdir_ixv --- ===> ixv (depend) --- depend_subdir_iwnfw --- --- depend_subdir_iwn5150 --- ===> iwnfw/iwn5150 (depend) --- depend_subdir_ixv --- --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- opt_inet.h --- ln -sf /usr/obj/usr/src/sys/GENERIC/opt_inet.h opt_inet.h --- opt_inet6.h --- ln -sf /usr/obj/usr/src/sys/GENERIC/opt_inet6.h opt_inet6.h --- opt_rss.h --- ln -sf /usr/obj/usr/src/sys/GENERIC/opt_rss.h opt_rss.h --- device_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h --- depend_subdir_iwnfw --- --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- --- depend_subdir_ixv --- --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- depend_subdir_iwnfw --- x86 -> /usr/src/sys/x86/include --- iwn5150fw.c --- awk -f /usr/src/sys/tools/fw_stub.awk iwlwifi-5150-8.24.2.2.fw:iwn5150fw -miwn5150fw -ciwn5150fw.c --- .depend --- rm -f .depend CC='cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I/usr/src/sys -I/usr/obj/usr/src/sys/GENERIC -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 -include /usr/obj/usr/src/sys/GENERIC/opt_global.h iwn5150fw.c --- depend_subdir_ixv --- --- pci_if.h --- awk -f /usr/sr
FreeBSD_HEAD_i386 - Build #2146 - Fixed
FreeBSD_HEAD_i386 - Build #2146 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2146/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2146/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2146/console Change summaries: 294367 by jhb: Update for API changes in OpenSSH 6.8p1. First, the authfd API now uses a direct file descriptor for the control socket instead of a more abstract AuthenticationConnection structure. Second, the functions now consistently return an error value. Reviewed by:bdrewery 294366 by jhb: Initialize vm_page_prot to VM_MEMATTR_DEFAULT instead of 0. If a driver's Linux mmap callback passed vm_page_prot through unchanged, then linux_dev_mmap_single() would try to apply whatever VM_MEMATTR_xxx value 0 is to the mapping. On x86, VM_MEMATTR_DEFAULT is the PAT value for write-back (WB) which is 6, while 0 maps to the PAT value for uncacheable (UC). Thus, any mmap request that did not explicitly set page_prot was tried to map memory as UC triggering the warning in sg_pager_getpages(). Tested by: np Reported by:Krishnamraju Eraparaju @ Chelsio MFC after: 3 days Sponsored by: Chelsio Communications 294365 by jhb: List source files (foo.c) instead of object files in SRCS. Reviewed by:bdrewery 294363 by jhibbits: Revert a printf change from r294307. Caused build failures with MPC85XX. Pointy-hat to: jhibbits 294362 by marius: Fix tty_drain() and, thus, TIOCDRAIN of the current tty(4) incarnation to actually wait until the TX FIFOs of UARTs have be drained before returning. This is done by bringing the equivalent of the TS_BUSY flag found in the previous implementation back in an ABI-preserving way. Reported and tested by: Patrick Powell Most likely, drivers for USB-serial-adapters likewise incorporating TX FIFOs as well as other terminal devices that buffer output in some form should also provide implementations of tsw_busy. MFC after: 3 days 294361 by bdrewery: FAST_DEPEND: Fix improperly depending all .So objects on all headers. This was a regression in r290629, which was revealed partly in r294360. Once 'make depend' has ran it will generate all headers already. Thus even with FAST_DEPEND lacking proper dependencies before building, it will not have any missing headers. Once objects are compiled the depend files will be generated with proper dependencies. Sponsored by: EMC / Isilon Storage Division 294360 by bdrewery: Revert r294352. Further research showed it was the wrong fix and revealed a bigger problem with the goal of skipping 'make depend'. 294358 by asomers: Quell harmless CID about unchecked return value in nvlist_get_guids. The return value doesn't need to be checked, because nvlist_get_guid's callers check the returned values of the guids. Coverity CID: 1341869 MFC after: 1 week X-MFC-With: 292066 Sponsored by: Spectra Logic Corp ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
iwn wlan connection losses after recent upgrade from 10-stable to head
Recently I upgraded my system to head from 10-stable: 11.0-CURRENT #0 r293760: iwn0: mem 0xe3c0-0xe3c01fff irq 17 at device 0.0 on pci2 net.wlan.debug: 1 net.wlan.0.debug: 1 wlan0: flags=8843 metric 0 mtu 1500 ether 24:77:03:07:32:b8 inet 192.168.254.21 netmask 0xff00 broadcast 192.168.254.255 nd6 options=29 media: IEEE 802.11 Wireless Ethernet MCS mode 11ng status: associated ssid SSID channel 1 (2412 MHz 11g ht/20) bssid 28:c6:8e:e6:04:7c country US authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit powersavemode CAM powersavesleep 100 txpower 13 bmiss 10 scanvalid 60 protmode CTS ampdulimit 64k ampdudensity 8 -amsdutx amsdurx shortgi wme roaming MANUAL groups: wlan While the 10-STABLE setup was never a pillar of reliability, HEAD seems to have made things worse for my wifi setup. Now my connections drops out several times a day at least resulting in logs such as this: wpa_supplicant[81975]: wlan0: CTRL-EVENT-DISCONNECTED bssid=28:c6:8e:e6:04:7c reason=0 kernel: wlan0: link state changed to DOWN wpa_supplicant[81975]: wlan0: Trying to associate with 28:c6:8e:e6:04:7c (SSID='SSID' freq=2412 MHz) wpa_supplicant[81975]: wlan0: Authentication with 28:c6:8e:e6:04:7c timed out. wpa_supplicant[81975]: wlan0: CTRL-EVENT-DISCONNECTED bssid=28:c6:8e:e6:04:7c reason=3 locally_generated=1 wpa_supplicant[81975]: wlan0: Trying to associate with 28:c6:8e:e6:04:7c (SSID='SSID' freq=2412 MHz) wpa_supplicant[81975]: wlan0: Authentication with 28:c6:8e:e6:04:7c timed out. wpa_supplicant[81975]: wlan0: CTRL-EVENT-DISCONNECTED bssid=28:c6:8e:e6:04:7c reason=3 locally_generated=1 wpa_supplicant[81975]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=1 ssid="SSID" auth_failures=1 duration=10 reason=CONN_FAILED wpa_supplicant[81975]: wlan0: CTRL-EVENT-SSID-REENABLED id=1 ssid="SSID" wpa_supplicant[81975]: wlan0: Trying to associate with 28:c6:8e:e6:04:7c (SSID='SSID' freq=2412 MHz) wpa_supplicant[81975]: wlan0: Authentication with 28:c6:8e:e6:04:7c timed out. wpa_supplicant[81975]: wlan0: CTRL-EVENT-DISCONNECTED bssid=28:c6:8e:e6:04:7c reason=3 locally_generated=1 wpa_supplicant[81975]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=1 ssid="SSID" auth_failures=2 duration=23 reason=CONN_FAILED wpa_supplicant[81975]: wlan0: CTRL-EVENT-SSID-REENABLED id=1 ssid="SSID" wpa_supplicant[81975]: wlan0: Trying to associate with 28:c6:8e:e6:04:7c (SSID='SSID' freq=2412 MHz) wpa_supplicant[81975]: wlan0: Authentication with 28:c6:8e:e6:04:7c timed out. Under 10-STABLE, such events were usually only a few times a week. I've just disabled N to see if that helps, but is the decreased reliability expected? Is there anything I can do to improve stability and preserve N? Thanks, -- Adam ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Shared library version bump?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/19/16 06:49 PM, Jung-uk Kim wrote:
> On 01/19/16 06:05 PM, Dimitry Andric wrote:
>> On 19 Jan 2016, at 23:32, Thomas Mueller
>> wrote:
>>>
>>> Has there recently been a version bump in the shared
>>> libraries? I saw no warning on this in the src or ports
>>> UPDATING files.
>
>> This was already answered in reply to your previous post on this
>> same issue. As mentioned in the reply, OpenSSL has been
>> upgraded, and both of its shared libraries have been bumped, e.g.
>> they are now named libcrypto.so.8 and libssl.so.8.
>
>> (Apparently you deleted the old libcrypto.so.7 and libssl.so.7,
>> even though you should never do so until your ports are
>> upgraded.)
>
>
>>> I can no longer startx and can no longer run many other ports,
>>> getting errors like
>>>
>>> Shared object "libcrypto.so.7" not found, required by "X"
>>> xinit: giving up xinit: unable to connect to X server:
>>> Connection refused xinit: server error
>>>
>>> and
>>>
>>> root@amelia:~ # pkg info -f xserver Shared object
>>> "libssl.so.7" not found, required by "pkg"
>>>
>>> Is this due to a version bump,
>
>> Yes.
>
>
>>> or is it related to the messages I got in yesterday's kernel
>>> installation like "unknown metadata record 4 ..."?
>
>> No, that is something entirely different. It is mainly
>> cosmetic, and you can ignore it, it will go away at the next
>> kernel update, if your kldxref executable is new enough.
>
>
>>> What do I do? Make buildworld and kernel again, or rebuild
>>> all ports? How do I find which ports need updating, or rebuild
>>> all except portmaster and pkg which I rebuilt after getting
>>> the errors?
>
>> It is easiest to use pkg-static to reinstall your ports, e.g.:
>
>> pkg-static update pkg-static upgrade
>
>> Alternatively, rebuild all ports depending on OpenSSL.
>
> A crude way to find almost all the ports depending on old OpenSSL
> is:
>
> find /usr/local -type f -exec file '{}' ';' | \ awk -F: '{ if
> ($2~/ELF/) print $1 }' | \ xargs egrep -l 'lib(crypto|ssl)\.so\.7'
> | \ xargs pkg-static which -oq | sort -u
A slightly improved version (to exclude non-native ELF binaries):
find /usr/local -type f -exec file -e elf '{}' ';' | \
awk -F: '{ if ($2~/ELF.*FreeBSD/) print $1 }' | \
xargs egrep -l 'lib(crypto|ssl)\.so\.7' | \
xargs pkg-static which -oq | sort -u
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJWns9cAAoJEHyflib82/FGgqgIAJGZ/pP+hW6if0OI1bsCuvc8
yAGtNe1ODOlryysqqc/hXh0kxNFz2jZgvf/wxJeRrV1FXsnvi6eyrmSxKJp/uVPp
Ichrmyh46C7Rj2XPCzmuNrWM4oTjCy1flOMk9JubpAyL8OH+TKT6icooj8hXUvBp
razc6crsqNlfcPVeo+8XLvM6zz+hCQDDYd2ScvYBfMeuUJAHbBZ3PN6uyD+L2bag
LR4DU/6twvR/KozxjtLqNSQ/k42TMt4wKgRZa6V1uyWdWNVWiWlbu/fM6vNfHjxZ
4nug6SIm8Vt9y0479MW19yrNIoNwWONYL5uYW4pDSpMABnqtkH9qgGYzVymWTpQ=
=So35
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Shared library version bump?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/19/16 06:05 PM, Dimitry Andric wrote:
> On 19 Jan 2016, at 23:32, Thomas Mueller
> wrote:
>>
>> Has there recently been a version bump in the shared libraries?
>> I saw no warning on this in the src or ports UPDATING files.
>
> This was already answered in reply to your previous post on this
> same issue. As mentioned in the reply, OpenSSL has been upgraded,
> and both of its shared libraries have been bumped, e.g. they are
> now named libcrypto.so.8 and libssl.so.8.
>
> (Apparently you deleted the old libcrypto.so.7 and libssl.so.7,
> even though you should never do so until your ports are upgraded.)
>
>
>> I can no longer startx and can no longer run many other ports,
>> getting errors like
>>
>> Shared object "libcrypto.so.7" not found, required by "X" xinit:
>> giving up xinit: unable to connect to X server: Connection
>> refused xinit: server error
>>
>> and
>>
>> root@amelia:~ # pkg info -f xserver Shared object "libssl.so.7"
>> not found, required by "pkg"
>>
>> Is this due to a version bump,
>
> Yes.
>
>
>> or is it related to the messages I got in yesterday's kernel
>> installation like "unknown metadata record 4 ..."?
>
> No, that is something entirely different. It is mainly cosmetic,
> and you can ignore it, it will go away at the next kernel update,
> if your kldxref executable is new enough.
>
>
>> What do I do? Make buildworld and kernel again, or rebuild all
>> ports? How do I find which ports need updating, or rebuild all
>> except portmaster and pkg which I rebuilt after getting the
>> errors?
>
> It is easiest to use pkg-static to reinstall your ports, e.g.:
>
> pkg-static update pkg-static upgrade
>
> Alternatively, rebuild all ports depending on OpenSSL.
A crude way to find almost all the ports depending on old OpenSSL is:
find /usr/local -type f -exec file '{}' ';' | \
awk -F: '{ if ($2~/ELF/) print $1 }' | \
xargs egrep -l 'lib(crypto|ssl)\.so\.7' | \
xargs pkg-static which -oq | sort -u
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJWnstwAAoJEHyflib82/FGXboH+wdNOXZ7i5z140BEbMlFeAH9
OCKq7fgwqyEzWjw73yiTcyTHir8nIuaFKkljMJFahEWR2/HMdFmBEoUheCWiscjx
cN+Ek2ICTD/ghgz1LGLVQtXw9EAGvAfqCSz+iGaSgSu1AHxwuirk3GMORRXoBWNv
eSrWfcP0bFDfb9p9zVNiMTnsMX4yKvuvDuXUxPsZSJyqb5vcctedIgwgV/L3Tq/X
vY/Nx+xvX/nJMRzePje9/9IziWlGZCK0ZI+aBnYcFb4y8OWg5gYvkr/XdBXSb+Ke
sgZrMAfdmyxDHv7AxDyVRgykHP00UIs3q5tvIDNxp47BEhu++niejX7+UsNHjNU=
=8Jb1
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD_HEAD_i386 - Build #2145 - Still Failing
FreeBSD_HEAD_i386 - Build #2145 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2145/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2145/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2145/console Change summaries: 294357 by bdrewery: Allow specifying an alternative LD_LIBRARY_PATH for the ldd(1) lookup. This is needed to be able to run check-links.sh against a "sysrooted" binary while ensuring that the ldd(1) call done on the host uses the host libc. It is not possible to set LD_LIBRARY_PATH before calling check-links.sh as then the "sysrooted" libc would be incorrectly used. A LD_PRELOAD=libc.so is used to ldd(1) as it needs to use the host libc to run. ldd(1) is a simple wrapper around execve(2) and dlopen(2) with env LD_TRACE_LOADED_OBJECTS set. Due to the dlopen(2) restriction on shared library tracing ldd(1) is still required for this lookup. Sponsored by: EMC / Isilon Storage Division 294356 by bdrewery: Add some documentation. Sponsored by: EMC / Isilon Storage Division 294355 by bdrewery: Validate that the file exists rather than obscure 'Not an elf file' error. Sponsored by: EMC / Isilon Storage Division 294354 by bdrewery: bsd.subdir.mk: Allow easier modification of [STANDALONE_]SUBDIR_TARGETS. This reworks r289254 and removes ALL_SUBDIR_TARGETS. Because there is an include guard in this file there is no need for LOCAL_ or ?= on SUBDIR_TARGETS or STANDALONE_SUBDIR_TARGETS. These can just be set via src.conf. By the time bsd.subdir.mk is included it will just append the values to the existing value and work fine. This allows a consistent way to append to these variables without introducing a LOCAL_ var for STANDALONE_SUBDIR_TARGETS or renaming the historical SUBDIR_TARGETS. Sponsored by: EMC / Isilon Storage Division 294353 by bdrewery: installconfig is PARALLEL_SUBDIR safe. Sponsored by: EMC / Isilon Storage Division 294352 by bdrewery: FAST_DEPEND: Add header dependency missed in r290629. Sponsored by: EMC / Isilon Storage Division 294351 by bdrewery: FAST_DEPEND: Still use if filemon is not used. If filemon is used then there is no need to generate dependency files during compilation as the .meta files will achieve the same result. This is a temporary solution until FAST_DEPEND is default. Once that is default there will be an option to disable dependency generation entirely as it is only useful if an incremental build is planned, thus META_MODE+filemon can enable that option to short-circuit all FAST_DEPEND-related logic. Sponsored by: EMC / Isilon Storage Division 294350 by bdrewery: META_MODE: Ensure bmake does not use filemon if it is not loaded. Sponsored by: EMC / Isilon Storage Division 294349 by bdrewery: Define .MAKE.MODE to normal to avoid the need for :U later. Sponsored by: EMC / Isilon Storage Division 294348 by jilles: sh: Simplify some code related to positional parameters. 294347 by asomers: Fix usr.bin.truncate.truncate_test.bad_truncate with ZFS /tmp. The bad_truncate test sets the uimmutable flag to produce an error in truncate, but that flag isn't supported by ZFS. If /tmp is on a ZFS filesystem, the test will fail. Change it to use readonly permissions and an unpriveleged user instead. Reviewed by:jilles MFC after: 1 week Sponsored by: Spectra Logic Corp Differential Revision: https://reviews.freebsd.org/D4862 294344 by jhb: Various cleanups to the main function for AIO kernel processes: - Pull the vmspace logic out into helper functions and reduce duplication. Operations on the vmspace are all isolated to vm_map.c, but it now exports a new 'vmspace_switch_aio' for use by AIO kernel processes. - When an AIO kernel process wants to exit, break out of the main loop and perform cleanup after the loop end. This reduces a lot of indentation and allows cleanup to more closely mirror setup actions before the loop starts. - Convert a DIAGNOSTIC to KASSERT(). - Replace mycp with more typical 'p'. Reviewed by:kib Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D4990 The end of the build log: [...truncated 40522 lines...] cc -DOPENPAM_STATIC_MODULES -O2 -pipe -I/usr/src/lib/libpam/modules/pam_passwdqc/../../../../contrib/pam_modules/pam_passwdqc -I/usr/src/lib/libpam/modules/pam_passwdqc/../../../../contrib/openpam/include -I/usr/src/lib/libpam/modules/pam_passwdqc/../../libpam -DOPENPAM_DEBUG -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/src/lib/libpam/modules/pam_passwdqc/../../../../contrib/pam_modu
Re: Shared library version bump?
On 19 Jan 2016, at 23:32, Thomas Mueller wrote: > > Has there recently been a version bump in the shared libraries? I saw no > warning on this in the src or ports UPDATING files. This was already answered in reply to your previous post on this same issue. As mentioned in the reply, OpenSSL has been upgraded, and both of its shared libraries have been bumped, e.g. they are now named libcrypto.so.8 and libssl.so.8. (Apparently you deleted the old libcrypto.so.7 and libssl.so.7, even though you should never do so until your ports are upgraded.) > I can no longer startx and can no longer run many other ports, getting errors > like > > Shared object "libcrypto.so.7" not found, required by "X" > xinit: giving up > xinit: unable to connect to X server: Connection refused > xinit: server error > > and > > root@amelia:~ # pkg info -f xserver > Shared object "libssl.so.7" not found, required by "pkg" > > Is this due to a version bump, Yes. > or is it related to the messages I got in yesterday's kernel installation > like "unknown metadata record 4 ..."? No, that is something entirely different. It is mainly cosmetic, and you can ignore it, it will go away at the next kernel update, if your kldxref executable is new enough. > What do I do? Make buildworld and kernel again, or rebuild all ports? How > do I find which ports need updating, or rebuild all except portmaster and pkg > which I rebuilt after getting the errors? It is easiest to use pkg-static to reinstall your ports, e.g.: pkg-static update pkg-static upgrade Alternatively, rebuild all ports depending on OpenSSL. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Shared library version bump?
Has there recently been a version bump in the shared libraries? I saw no warning on this in the src or ports UPDATING files. I can no longer startx and can no longer run many other ports, getting errors like Shared object "libcrypto.so.7" not found, required by "X" xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error and root@amelia:~ # pkg info -f xserver Shared object "libssl.so.7" not found, required by "pkg" Is this due to a version bump, or is it related to the messages I got in yesterday's kernel installation like "unknown metadata record 4 ..."? What do I do? Make buildworld and kernel again, or rebuild all ports? How do I find which ports need updating, or rebuild all except portmaster and pkg which I rebuilt after getting the errors? Tom ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: network/ath: on CURRENT no connections possible on ath-based AP
okay -a ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: network/ath: on CURRENT no connections possible on ath-based AP
On Tue, Jan 19, 2016 at 9:11 PM, Adrian Chadd wrote: > CAn you test AR9380 on that revision? That's -head, right? > No, sorry: I've got only AR9280 based wifi card (Compex WLE200NX 802.11a/b/g/n miniPCI). And yes: it's r293631 on -head. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: network/ath: on CURRENT no connections possible on ath-based AP
CAn you test AR9380 on that revision? That's -head, right? -adrian On 19 January 2016 at 12:08, Olivier Cochard-Labbé wrote: > On Tue, Jan 19, 2016 at 8:17 PM, O. Hartmann > wrote: > >> Running hostapd and a Atheros based AP on recent CURRENT (FreeBSD >> 11.0-CURRENT #8 >> r294329: Tue Jan 19 18:23:20 CET 2016 amd64), clients do not connect >> anymore to that >> specific AP. They did a week or two ago (mobile phones, several notebooks). >> > > Hi, > > I've got no problem on r293631 > > in hostap mode ( > ath0: AR9280 mac 128.2 RF5133 phy 13.0 > ). > > Regards, > > Olivier > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: network/ath: on CURRENT no connections possible on ath-based AP
On Tue, Jan 19, 2016 at 8:17 PM, O. Hartmann wrote: > Running hostapd and a Atheros based AP on recent CURRENT (FreeBSD > 11.0-CURRENT #8 > r294329: Tue Jan 19 18:23:20 CET 2016 amd64), clients do not connect > anymore to that > specific AP. They did a week or two ago (mobile phones, several notebooks). > Hi, I've got no problem on r293631 in hostap mode ( ath0: AR9280 mac 128.2 RF5133 phy 13.0 ). Regards, Olivier ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: network/ath: on CURRENT no connections possible on ath-based AP
Theres been nothing in the ath code that I can think of that'd do this. Can you get me "works" and "doesn't work" revisions? thanks, -a On 19 January 2016 at 11:17, O. Hartmann wrote: > Running hostapd and a Atheros based AP on recent CURRENT (FreeBSD > 11.0-CURRENT #8 > r294329: Tue Jan 19 18:23:20 CET 2016 amd64), clients do not connect anymore > to that > specific AP. They did a week or two ago (mobile phones, several notebooks). > > The WiFi adaptor is this one (dmesg): > > [...] > ath0: mem 0xf7e0-0xf7e1 irq 16 at device 0.0 on pci1 > ar9300_attach: calling ar9300_hw_attach > ar9300_hw_attach: calling ar9300_eeprom_attach > ar9300_flash_map: unimplemented for now > Restoring Cal data from DRAM > Restoring Cal data from EEPROM > ar9300_hw_attach: ar9300_eeprom_attach returned 0 > ath0: [HT] enabling HT modes > ath0: [HT] enabling short-GI in 20MHz mode > ath0: [HT] 1 stream STBC receive enabled > ath0: [HT] 1 stream STBC transmit enabled > ath0: [HT] 3 RX streams; 3 TX streams > ath0: AR9380 mac 448.3 RF5110 phy 3276.12 > ath0: 2GHz radio: 0x; 5GHz radio: 0x > [...] > > and from ifconfig: > > [...] > wlan0: flags=8943 metric 0 > mtu 1500 > ether xx:xx:xx:xx:xx:xx > inet 192.168.2.1 netmask 0xff00 broadcast 192.168.2.255 > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: running > ssid Berghof channel 10 (2457 MHz 11g) bssid xx:xx:xx:xx:xx:xx > regdomain ETSI country DE indoor ecm authmode WPA2/802.11i > privacy MIXED deftxkey 2 AES-CCM 2:128-bit AES-CCM 3:128-bit > txpower 30 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs > groups: wlan > [...] > > On some earlier dmesg outputs, I see the line > > ath0: AR9380 mac 448.3 RF5110 phy 2457.9 > > instead of the most recent > > ath0: AR9380 mac 448.3 RF5110 phy 3276.12 > > I do not see any strange behaviour until clients fetch (successfully!) their > IP via > isc-dhcp (isc-dhcp43-server-4.3.3P1_1), then they die or can not access the > network any > further. > > Has there been a change recently? > > Kind regards, > > Oliver ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
network/ath: on CURRENT no connections possible on ath-based AP
Running hostapd and a Atheros based AP on recent CURRENT (FreeBSD 11.0-CURRENT #8 r294329: Tue Jan 19 18:23:20 CET 2016 amd64), clients do not connect anymore to that specific AP. They did a week or two ago (mobile phones, several notebooks). The WiFi adaptor is this one (dmesg): [...] ath0: mem 0xf7e0-0xf7e1 irq 16 at device 0.0 on pci1 ar9300_attach: calling ar9300_hw_attach ar9300_hw_attach: calling ar9300_eeprom_attach ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] 3 RX streams; 3 TX streams ath0: AR9380 mac 448.3 RF5110 phy 3276.12 ath0: 2GHz radio: 0x; 5GHz radio: 0x [...] and from ifconfig: [...] wlan0: flags=8943 metric 0 mtu 1500 ether xx:xx:xx:xx:xx:xx inet 192.168.2.1 netmask 0xff00 broadcast 192.168.2.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running ssid Berghof channel 10 (2457 MHz 11g) bssid xx:xx:xx:xx:xx:xx regdomain ETSI country DE indoor ecm authmode WPA2/802.11i privacy MIXED deftxkey 2 AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 30 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs groups: wlan [...] On some earlier dmesg outputs, I see the line ath0: AR9380 mac 448.3 RF5110 phy 2457.9 instead of the most recent ath0: AR9380 mac 448.3 RF5110 phy 3276.12 I do not see any strange behaviour until clients fetch (successfully!) their IP via isc-dhcp (isc-dhcp43-server-4.3.3P1_1), then they die or can not access the network any further. Has there been a change recently? Kind regards, Oliver pgpiY9JQLSOeb.pgp Description: OpenPGP digital signature
Re: CAM Shingled Disk support patches available
> On Jan 19, 2016, at 8:25 AM, Kenneth D. Merry wrote: > > >>> 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). >> >> I believe that changes the size of the CCB, so I tried to avoid >> that since I didn???t want to force a recompile of camcontrol(8). >> Adding it to the atacmd structure wasn???t so bad, and the CCB size >> didn???t completely change. The problem was that the atacmd changed >> size and pushed all the other fields. > > Yes. In order to do it, we'll need to add it to struct atacmd, and add > compatibility shims. I don't see another way to do it unfortunately. > No, I object to changing the structure sizes and contents. It should be a new CCB, XPT_ATA_IO_EXT, ccb_ataio_ext. If you want to add more future-looking fields than just the AUX register, maybe a way to define un-typed command and response register objects, that’s fine and probably a good idea. The periph drivers can probe for the proper command to send based on whether the SIM returning CAM_FUNC_NOTAVAIL or via a PIM flag, or even better, via a KVP capability CCB. However I’m firmly against changing the existing data structures; compat shims have been a pain and are a poor solution. Warner and I are pounding out a proposal for this, will share a diff shortly. Scott ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CAM Shingled Disk support patches available
On Tue, Jan 19, 2016 at 12:06:41PM -0500, Kenneth D. Merry wrote: > On Tue, Jan 19, 2016 at 20:02:52 +0300, Slawa Olhovchenkov wrote: > > On Tue, Jan 19, 2016 at 11:38:31AM -0500, Kenneth D. Merry wrote: > > > > > On Tue, Jan 19, 2016 at 14:45:23 +0300, Slawa Olhovchenkov wrote: > > > > On Mon, Jan 18, 2016 at 05:37:04PM -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.) > > > > > > > > Please, check me: currenly SMR lack of support in SCSI devices? On > > > > [hardvare] vendor level? Currenly only SATA controllers compatible > > > > with SMR (on command level)? (I am don't talk about FreeBSD support, > > > > question about common state). > > > > > > No, there are SAS/SCSI SMR drives in development, and there is the SCSI > > > ZBC > > > spec that defines the command set. I don't know whether any vendors are > > > shipping SAS/SCSI SMR drives yet. > > > > > > You can use SATA drives (SMR or not) with either a SATA controller or a > > > SAS > > > controller. But the way you talk to a SATA drive through a SAS controller > > > is with SCSI commands. There is a SCSI spec (SAT) that defines the > > > mapping > > > of SCSI commands to ATA commands. It has recently been updated to support > > > mapping SMR commands from SCSI to ATA, but most (all?) SAS controllers > > > have not caught up with the spec. > > > > > > So to use a SATA SMR drive with a SAS controller that doesn't know how to > > > map SMR commands from SCSI to ATA, you have to send the ATA SMR commands > > > through the SCSI ATA PASS-THROUGH command. That just bypasses the usual > > > translations, and allows sending ATA commands in something like their > > > native form. > > > > What in case of expanders an port replicatiors (SATA drives and HBA > > SAS controllers, of course)? Need expander be compatible with SMR? Or > > any expander with SATA support automaticly compatible? > > Expanders and port replicators shouldn't matter. The place where you need > to know about SMR is the place where the native ATA or SCSI drive commands > are generated. Expanders and port replicators typically just pass commands > through. Thanks for clarification! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CAM Shingled Disk support patches available
On Tue, Jan 19, 2016 at 20:02:52 +0300, Slawa Olhovchenkov wrote: > On Tue, Jan 19, 2016 at 11:38:31AM -0500, Kenneth D. Merry wrote: > > > On Tue, Jan 19, 2016 at 14:45:23 +0300, Slawa Olhovchenkov wrote: > > > On Mon, Jan 18, 2016 at 05:37:04PM -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.) > > > > > > Please, check me: currenly SMR lack of support in SCSI devices? On > > > [hardvare] vendor level? Currenly only SATA controllers compatible > > > with SMR (on command level)? (I am don't talk about FreeBSD support, > > > question about common state). > > > > No, there are SAS/SCSI SMR drives in development, and there is the SCSI ZBC > > spec that defines the command set. I don't know whether any vendors are > > shipping SAS/SCSI SMR drives yet. > > > > You can use SATA drives (SMR or not) with either a SATA controller or a SAS > > controller. But the way you talk to a SATA drive through a SAS controller > > is with SCSI commands. There is a SCSI spec (SAT) that defines the mapping > > of SCSI commands to ATA commands. It has recently been updated to support > > mapping SMR commands from SCSI to ATA, but most (all?) SAS controllers > > have not caught up with the spec. > > > > So to use a SATA SMR drive with a SAS controller that doesn't know how to > > map SMR commands from SCSI to ATA, you have to send the ATA SMR commands > > through the SCSI ATA PASS-THROUGH command. That just bypasses the usual > > translations, and allows sending ATA commands in something like their > > native form. > > What in case of expanders an port replicatiors (SATA drives and HBA > SAS controllers, of course)? Need expander be compatible with SMR? Or > any expander with SATA support automaticly compatible? Expanders and port replicators shouldn't matter. The place where you need to know about SMR is the place where the native ATA or SCSI drive commands are generated. Expanders and port replicators typically just pass commands through. Ken -- Kenneth Merry k...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CAM Shingled Disk support patches available
On Tue, Jan 19, 2016 at 11:38:31AM -0500, Kenneth D. Merry wrote: > On Tue, Jan 19, 2016 at 14:45:23 +0300, Slawa Olhovchenkov wrote: > > On Mon, Jan 18, 2016 at 05:37:04PM -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.) > > > > Please, check me: currenly SMR lack of support in SCSI devices? On > > [hardvare] vendor level? Currenly only SATA controllers compatible > > with SMR (on command level)? (I am don't talk about FreeBSD support, > > question about common state). > > No, there are SAS/SCSI SMR drives in development, and there is the SCSI ZBC > spec that defines the command set. I don't know whether any vendors are > shipping SAS/SCSI SMR drives yet. > > You can use SATA drives (SMR or not) with either a SATA controller or a SAS > controller. But the way you talk to a SATA drive through a SAS controller > is with SCSI commands. There is a SCSI spec (SAT) that defines the mapping > of SCSI commands to ATA commands. It has recently been updated to support > mapping SMR commands from SCSI to ATA, but most (all?) SAS controllers > have not caught up with the spec. > > So to use a SATA SMR drive with a SAS controller that doesn't know how to > map SMR commands from SCSI to ATA, you have to send the ATA SMR commands > through the SCSI ATA PASS-THROUGH command. That just bypasses the usual > translations, and allows sending ATA commands in something like their > native form. What in case of expanders an port replicatiors (SATA drives and HBA SAS controllers, of course)? Need expander be compatible with SMR? Or any expander with SATA support automaticly compatible? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CAM Shingled Disk support patches available
On Tue, Jan 19, 2016 at 14:45:23 +0300, Slawa Olhovchenkov wrote: > On Mon, Jan 18, 2016 at 05:37:04PM -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.) > > Please, check me: currenly SMR lack of support in SCSI devices? On > [hardvare] vendor level? Currenly only SATA controllers compatible > with SMR (on command level)? (I am don't talk about FreeBSD support, > question about common state). No, there are SAS/SCSI SMR drives in development, and there is the SCSI ZBC spec that defines the command set. I don't know whether any vendors are shipping SAS/SCSI SMR drives yet. You can use SATA drives (SMR or not) with either a SATA controller or a SAS controller. But the way you talk to a SATA drive through a SAS controller is with SCSI commands. There is a SCSI spec (SAT) that defines the mapping of SCSI commands to ATA commands. It has recently been updated to support mapping SMR commands from SCSI to ATA, but most (all?) SAS controllers have not caught up with the spec. So to use a SATA SMR drive with a SAS controller that doesn't know how to map SMR commands from SCSI to ATA, you have to send the ATA SMR commands through the SCSI ATA PASS-THROUGH command. That just bypasses the usual translations, and allows sending ATA commands in something like their native form. Ken -- Kenneth Merry k...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CAM Shingled Disk support patches available
On Mon, Jan 18, 2016 at 16:50:34 -0800, Warner Losh wrote: > > > On Jan 18, 2016, at 2:37 PM, 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. > > I???ve plumbed it down, but in a gross, kludgy way to make NCQ Trim work > where the only value in the Auxiliary register needs to be 1. It only takes > up one bit, but it doesn???t change the size of the CCB. If the NCQ Trim > work wasn???t based on the I/O scheduler, I???d have pushed it into head > and would be happy to share code. Yeah, for SMR, we'll need to pass the full register down. That is how you specify the service action (open, close, finish, reset write pointer, report zones). > AHCI can send it, but it turns out that LSI???s drivers (mpt, mps, etc) > can???t do it due to firmware inadequacies. The ability to send a FIS > in these firmwares looked promising, but it requires a full draining of > other requests, which kind of defeats the purpose of NCQ. Yeah, that would kinda defeat the purpose. I'm sending a SCSI command (ATA PASS-THROUGH) to get the SATA zone commands down there. Those are treated like an ordered tag by the LSI firmware as well. Which is just as well, since there is no way to specify the Auxiliary register via that SCSI command, and so we can't do NCQ anyway. LSI/Avago said they're planning to support the zone commands in the SAT layer in the HBAs in the 12Gb boards. Phase 10 doesn't have it from what I understand, but hopefully that'll show up soon. The translation is in the latest SAT draft, and it is very straightforward to map from one to the other, because the SCSI and ATA commands and semantics are pretty much identical. > > 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). > > I believe that changes the size of the CCB, so I tried to avoid > that since I didn???t want to force a recompile of camcontrol(8). > Adding it to the atacmd structure wasn???t so bad, and the CCB size > didn???t completely change. The problem was that the atacmd changed > size and pushed all the other fields. Yes. In order to do it, we'll need to add it to struct atacmd, and add compatibility shims. I don't see another way to do it unfortunately. > > 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.) > > I looked to implement things here, but didn???t want to invent something that > the T-10 would later reinvent. Yeah. Is NCQ trim a new thing? Is that why you were looking at sending it down via a FIS? If so, it is likely that LSI will add it to the SCSI Unmap translation in the firmware. Of course if it isn't already in there, they're only going to put it in their 12Gb controllers and not in the 6Gb controllers at this point. Since the SAT spec has the mapping for the SCSI ZBC -> ZAC commands, it sounds like that'll make it into the LSI 12Gb firmware at some point. > > 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. > > So having said all that, I???m totally open to something better. I think that for the ATA side, we'll just have to add the register to the CCB, bump the version and add compatibility shims. For the SCSI side, we just need a way to probe and see whether the translation is supported in the SAT layer (at least for the ZBC commands, I don't know about trim) and use the SCSI command if it is supported, otherwise use the ATA PASS-THROUGH command if it is not. Ken -- Kenneth Merry k...@freebs
Re: libcrypto.so.7 not found, needed (?) for X server
On Tue, Jan 19, 2016 at 02:17:11PM +0100, Dimitry Andric wrote: > On 19 Jan 2016, at 13:44, Thomas Mueller wrote: > > > > I just updated FreeBSD-current to r294248, and can no longer startx. > > > > Error message is > > > > xauth: file /home/arlene/.serverauth.1177 does not exist > > > > Shared object "libcrypto.so.7" not found, required by "X" > > xinit: giving up > > xinit: unable to connect to X server: Connection refused > > xinit: server error > > > > There is /usr/lib/libcrypto.so but notlibcrypto.so.7. > > > > I also looked in /usr/local/lib, no libcrypto... files. > > > > Now I run > > > > pkg info -f xserver and get > > > > root@amelia:~ # pkg info -f xserver > > Shared object "libssl.so.7" not found, required by "pkg" > > > > What happened here? Bug in new FreeBSD? > > This is explained by the UPDATING entry of October 2015: > > 20151030: > The OpenSSL has been upgraded to 1.0.2d. Any binaries requiring > libcrypto.so.7 or libssl.so.7 must be recompiled. > Given how long ago this happen a simple pkg-static upgrade -f would do the trick because all available packages has been rebuilt in the cluster since and have been published. All official packages for head are linked against newer libcrypto.so and libssl.so Best regards, Bapt signature.asc Description: PGP signature
Re: libcrypto.so.7 not found, needed (?) for X server
>I just updated FreeBSD-current to r294248, and can no longer startx. >Error message is >xauth: file /home/arlene/.serverauth.1177 does not exist >Shared object "libcrypto.so.7" not found, required by "X" >xinit: giving up >xinit: unable to connect to X server: Connection refused >xinit: server error >There is /usr/lib/libcrypto.so but notlibcrypto.so.7. >I also looked in /usr/local/lib, no libcrypto... files. >Now I run >pkg info -f xserver and get >root@amelia:~ # pkg info -f xserver >Shared object "libssl.so.7" not found, required by "pkg" >What happened here? Bug in new FreeBSD? > uname -a shows >FreeBSD amelia 11.0-CURRENT FreeBSD 11.0-CURRENT #10 r294248: Mon Jan 18 >11:28:40 UTC 2016 >root@amelia:/usr/obj/usr/src/sys/SANDY11NC amd64 >Tom >___ >freebsd-current@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" I had exactly the same issue with 11.0-CURRENT r294227, libssl.so.7 missing. I ended up building OpenSSL from ports to resolve.Probably not the answer, but a work around. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: environment corrupt; missing value for QT_IM_MO
On 05/01/2016 10:54, Andriy Gapon wrote: > On 05/01/2016 10:45, Andriy Gapon wrote: >> >> Very weird, this suddenly started happening to me but with libreoffice. I >> can >> not correlate the problem with any actions / events. >> >> stderr: >> soffice.bin: environment corrupt; missing value for QT_IM_MO >> >> gdb: >> Core was generated by `soffice.bin'. >> Program terminated with signal SIGABRT, Aborted. >> #0 thr_kill () at thr_kill.S:3 >> 3 RSYSCALL(thr_kill) >> [Current thread is 2 (Thread 816615000 (LWP 102134))] >> (gdb) bt >> #0 thr_kill () at thr_kill.S:3 >> #1 0x000800dc5ddb in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 >> #2 0x000800dc5d49 in abort () at /usr/src/lib/libc/stdlib/abort.c:65 >> #3 0x000805231318 in tools::extendApplicationEnvironment() () from >> /usr/local/lib/libreoffice/program/libtllo.so >> >> Smells like a possible bug in libc... > > Is there a limit on the environment's size? > QT_IM_MODULE is reported by ps as the last variable. I have taken another look at the problem and I've discovered that the affected variable is corrupted in a peculiar way: (kgdb) p environ[61] $23 = 0x7fffef45 "QT_IM_MO" (kgdb) x/s 0x7fffef45 0x7fffef45: "QT_IM_MO" (kgdb) x/s 0x7fffef4d 0x7fffef4d: "" (kgdb) x/s 0x7fffef4e 0x7fffef4e: "" (kgdb) x/s 0x7fffef4f 0x7fffef4f: "" (kgdb) x/s 0x7fffef50 0x7fffef50: "" (kgdb) x/s 0x7fffef51 0x7fffef51: "=xim" (kgdb) p environ[62] $42 = 0x0 So, it's "QT_IM_MODULE=xim" with 4 bytes (corresponding to "DULE") replaced with zeroes. This is 100% reproducible in my current environment, so it could be a deterministic write to a wrong offset. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Xen/dom0/FreeBSD + NAS4Free WebGUI.
On Tue, Jan 12, 2016 at 02:23:39PM +0100, Roger Pau Monné wrote: [...] > I'm adding Wei to the Cc, he has been working on netfront improvements, > so maybe he also wants to take a stab at netback ;). It's on my radar but I don't have time for it in the near future. If anyone else who is watching FreeBSD Xen implementation have the desire to improve it I'm happy to help. Wei. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libcrypto.so.7 not found, needed (?) for X server
On Tue, Jan 19, 2016 at 12:44:16PM +, Thomas Mueller wrote: > I just updated FreeBSD-current to r294248, and can no longer startx. > > Error message is > > xauth: file /home/arlene/.serverauth.1177 does not exist > > Shared object "libcrypto.so.7" not found, required by "X" > xinit: giving up > xinit: unable to connect to X server: Connection refused > xinit: server error > > There is /usr/lib/libcrypto.so but notlibcrypto.so.7. > On my laptop, in the "head" environment, I have: g1-252(10.3-P)[1] cd /S4 g1-252(10.3-P)[2] ls -ltrT usr/lib/libcrypto* -r--r--r-- 1 root wheel 4281880 Dec 28 05:50:18 2015 usr/lib/libcrypto.a -r--r--r-- 1 root wheel 4531590 Dec 28 05:50:18 2015 usr/lib/libcrypto_p.a lrwxr-xr-x 1 root wheel 24 Jan 19 05:02:24 2016 usr/lib/libcrypto.so -> ../../lib/libcrypto.so.8 g1-252(10.3-P)[3] But I normally run -- and biuld my ports -- in a stable/10 environment, so: g1-252(10.3-P)[1] ldd `which X` | grep crypto libcrypto.so.7 => /lib/libcrypto.so.7 (0x800c84000) g1-252(10.3-P)[2] ls -ltrT /lib/libcrypto* -r--r--r-- 1 root wheel 2039072 Jan 19 04:28:19 2016 /lib/libcrypto.so.7 g1-252(10.3-P)[3] ls -ltrT /usr/lib/libcrypto* -r--r--r-- 1 root wheel 3927330 Dec 4 04:36:08 2015 /usr/lib/libcrypto.a -r--r--r-- 1 root wheel 4158890 Dec 4 04:36:08 2015 /usr/lib/libcrypto_p.a lrwxr-xr-x 1 root wheel 19 Jan 19 04:28:19 2016 /usr/lib/libcrypto.so -> /lib/libcrypto.so.7 g1-252(10.3-P)[4] Finally, something that you may find useful in all this nattering: g1-252(10.3-P)[4] pkg which /usr/local/lib/compat/libcrypto.so.7 /usr/local/lib/compat/libcrypto.so.7 was installed by package compat10x-amd64-10.2.1002000.20151116 g1-252(10.3-P)[5] pkg info -o compat10x-amd64-10.2.1002000.20151116 compat10x-amd64-10.2.1002000.20151116 misc/compat10x g1-252(10.3-P)[6] That is, it looks as if you're trying to run X built under stable/10 while you're running head. You will almost certainly want to install misc/compat10x. Alternatively, delete & re-build/install all ports/packages under head. Peace, david -- David H. Wolfskill da...@catwhisker.org Those who would murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: libcrypto.so.7 not found, needed (?) for X server
On 19 Jan 2016, at 13:44, Thomas Mueller wrote: > > I just updated FreeBSD-current to r294248, and can no longer startx. > > Error message is > > xauth: file /home/arlene/.serverauth.1177 does not exist > > Shared object "libcrypto.so.7" not found, required by "X" > xinit: giving up > xinit: unable to connect to X server: Connection refused > xinit: server error > > There is /usr/lib/libcrypto.so but notlibcrypto.so.7. > > I also looked in /usr/local/lib, no libcrypto... files. > > Now I run > > pkg info -f xserver and get > > root@amelia:~ # pkg info -f xserver > Shared object "libssl.so.7" not found, required by "pkg" > > What happened here? Bug in new FreeBSD? This is explained by the UPDATING entry of October 2015: 20151030: The OpenSSL has been upgraded to 1.0.2d. Any binaries requiring libcrypto.so.7 or libssl.so.7 must be recompiled. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
libcrypto.so.7 not found, needed (?) for X server
I just updated FreeBSD-current to r294248, and can no longer startx. Error message is xauth: file /home/arlene/.serverauth.1177 does not exist Shared object "libcrypto.so.7" not found, required by "X" xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error There is /usr/lib/libcrypto.so but notlibcrypto.so.7. I also looked in /usr/local/lib, no libcrypto... files. Now I run pkg info -f xserver and get root@amelia:~ # pkg info -f xserver Shared object "libssl.so.7" not found, required by "pkg" What happened here? Bug in new FreeBSD? uname -a shows FreeBSD amelia 11.0-CURRENT FreeBSD 11.0-CURRENT #10 r294248: Mon Jan 18 11:28:40 UTC 2016 root@amelia:/usr/obj/usr/src/sys/SANDY11NC amd64 Tom ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CAM Shingled Disk support patches available
On Mon, Jan 18, 2016 at 05:37:04PM -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.) Please, check me: currenly SMR lack of support in SCSI devices? On [hardvare] vendor level? Currenly only SATA controllers compatible with SMR (on command level)? (I am don't talk about FreeBSD support, question about common state). ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
