Jenkins build is still unstable: FreeBSD_HEAD-tests2 #190
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/190/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Enabling vt(4) by default
On Tue, 04 Nov 2014 18:01:41 -0800 Chris H bsd-li...@bsdforge.com wrote: On Tue, 04 Nov 2014 18:22:06 +0100 Jean-Sebastien Pedron jean-sebastien.ped...@dumbbell.fr wrote Hello! As announced a week ago, vt(4) is now the default console driver in 11-CURRENT as of r274085. You may have to update your console settings in /etc/rc.conf. During boot, /etc/rc.d/syscons will indicate what you need to do. The original HEADS UP mentioned several known issues. Among them, the following were fixed: o A video mode can be selected using the following tunable in /boot/loader.conf: kern.vt.fb.default_mode=1024x768 This only works when using a KMS video driver. It's not supported by the VGA backend. See vt(4) man page for further documentation. o The keyboard was not working when kbdmux(4) was disabled. This is fixed. o After loading a KMS driver, the text cursor was in the middle of the kernel messages. The problem was that the cursor position was not updated after the change in window size. This is fixed. Up-to-date information can be found on the wiki page: https://wiki.freebsd.org/Newcons If you want to keep using syscons(4), you can add the following line to /boot/loader.conf: kern.vty=sc Thank you to everyone who tested and reported problems! Please continue to do so, especially if you find the need to go back to syscons. No. Thank _you_! :) I was unable to determine from the wiki. But do all these wonderful new features also work with the nVidia blob, under vt(4)? I'm currently building a new 11-CURRENT from the 10-26 iso, as I write this, and was wondering if the graphics mode at higher resolutions was now possible using the nVidia blob. No, video mode won't work with the nVidia blob. That requires a KMS (in-kernel) driver. -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r273165. ZFS ARC: possible memory leak to Inact
On 05/11/2014 06:15, Marcus Reid wrote: On Tue, Nov 04, 2014 at 06:13:44PM +, Steven Hartland wrote: On 04/11/2014 17:22, Allan Jude wrote: snip... Justin Gibbs and I were helping George from Voxer look at the same issue they are having. They had ~169GB in inact, and only ~60GB being used for ARC. Are there any further debugging steps we can recommend to him to help investigate this? The various scripts attached to the ZS ARC behavior problem and fix PR will help provide detail this. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 I've seen it here where there's been bursts of ZFS I/O specifically write bursts. What happens is that ZFS will consume large amounts of space in various UMA zones to accommodate these bursts. If you push the vmstat -z that he provided through the arc summary script, you'll see that this is not what is happening. His uma stats match up with his arc, and do not account for his inactive memory. uma script summary: Totals oused: 5.860GB, ofree: 1.547GB, ototal: 7.407GB zused: 56.166GB, zfree: 3.918GB, ztotal: 60.084GB used: 62.026GB, free: 5.465GB, total: 67.491GB His provided top stats: Mem: 19G Active, 20G Inact, 81G Wired, 59M Cache, 3308M Buf, 4918M Free ARC: 66G Total, 6926M MFU, 54G MRU, 8069K Anon, 899M Header, 5129M Other The big uma buckets (zio_buf_16384 and zio_data_buf_131072, 18.002GB and 28.802GB respectively) are nearly 0% free. Still potentially accounts for 5.4GB of your 20GB inact. The rest could be malloc backed allocations? Regards Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkg 1.4 freeze please test test test!
On 29/10/2014 15:53, Baptiste Daroussin wrote:
yes remove the current pkg
pkg delete -f pkg
install ports-mgmt/pkg-devel (adding WITH_PKG=devel in make.conf)
use it
So, I followed these instructions and got pkg replaced with 1.4.0.p.a16.
Then I ran pkg upgrade like this:
$ pkg upgrade -y
Updating FreeBSD repository catalogue...
pkg: Repository FreeBSD has a wrong packagesite, need to re-create database
Fetching meta.txz: 100% 944 B 0.9k/s00:01
Fetching digests.txz: 100%2 MB 2.1M/s00:01
Fetching packagesite.txz: 100%5 MB 5.3M/s00:01
Processing new repository entries: 100%
FreeBSD repository update completed. 23591 packages processed:
0 updated, 0 removed and 23591 added.
Updating poudriere repository catalogue...
poudriere repository is up-to-date.
Updating database digests format: 100%
New version of pkg detected; it needs to be installed first.
Checking integrity... done (0 conflicting)
Your packages are up to date.
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
Updating poudriere repository catalogue...
poudriere repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (297 candidates): 0%
Checking for upgrades (297 candidates): 10%
Checking for upgrades (297 candidates): 100%
Processing candidates (297 candidates): 100%
Assertion failed: (curvar != NULL), function pkg_solve_add_request_rule, file
pkg_solve.c, line 463.
Child process pid=78582 terminated abnormally: Abort trap
$ pkg -vv
Version : 1.4.0.pre-alpha16
PKG_DBDIR = /usr/local/var/db/pkg;
PKG_CACHEDIR = /var/cache/pkg;
PORTSDIR = /usr/ports;
INDEXDIR = ;
INDEXFILE = INDEX-11;
HANDLE_RC_SCRIPTS = false;
ASSUME_ALWAYS_YES = false;
REPOS_DIR [
/etc/pkg/,
/usr/local/etc/pkg/repos/,
]
PLIST_KEYWORDS_DIR = ;
SYSLOG = false;
ABI = FreeBSD:11:amd64;
ALTABI = freebsd:11:x86:64;
DEVELOPER_MODE = false;
VULNXML_SITE = http://www.vuxml.org/freebsd/vuln.xml.bz2;;
FETCH_RETRY = 3;
PKG_PLUGINS_DIR = /usr/local/lib/pkg/;
PKG_ENABLE_PLUGINS = true;
PLUGINS [
]
DEBUG_SCRIPTS = false;
PLUGINS_CONF_DIR = /usr/local/etc/pkg/;
PERMISSIVE = false;
REPO_AUTOUPDATE = true;
NAMESERVER = ;
EVENT_PIPE = ;
FETCH_TIMEOUT = 30;
UNSET_TIMESTAMP = false;
SSH_RESTRICT_DIR = ;
PKG_ENV {
}
PKG_SSH_ARGS = ;
DEBUG_LEVEL = 0;
ALIAS {
}
CUDF_SOLVER = ;
SAT_SOLVER = ;
RUN_SCRIPTS = true;
CASE_SENSITIVE_MATCH = false;
LOCK_WAIT = 1;
LOCK_RETRIES = 5;
SQLITE_PROFILE = false;
WORKERS_COUNT = 0;
READ_LOCK = false;
PLIST_ACCEPT_DIRECTORIES = false;
IP_VERSION = 0;
Repositories:
FreeBSD: {
url : pkg+http://pkg.FreeBSD.org/FreeBSD:11:amd64/latest;,
enabled : yes,
mirror_type : SRV,
signature_type : FINGERPRINTS,
fingerprints: /usr/share/keys/pkg
}
poudriere: {
url :
file:///usr/local/poudriere/data/packages/basejail-default,
enabled : yes
}
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r273165. ZFS ARC: possible memory leak to Inact
On 04/11/2014 14:55, Steven Hartland wrote: This is likely spikes in uma zones used by ARC. The VM doesn't ever clean uma zones unless it hits a low memory condition, which explains why your little script helps. Check the output of vmstat -z to confirm. Steve, this is nonsense :-) You know perfectly well that UMA memory is Wired not Inactive. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r273165. ZFS ARC: possible memory leak to Inact
On 04/11/2014 14:55, Steven Hartland wrote: This is likely spikes in uma zones used by ARC. The VM doesn't ever clean uma zones unless it hits a low memory condition, which explains why your little script helps. Check the output of vmstat -z to confirm. Steve, this is nonsense :-) You know perfectly well that UMA memory is Wired not Inactive. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r273165. ZFS ARC: possible memory leak to Inact
On 05/11/2014 09:52, Andriy Gapon wrote: On 04/11/2014 14:55, Steven Hartland wrote: This is likely spikes in uma zones used by ARC. The VM doesn't ever clean uma zones unless it hits a low memory condition, which explains why your little script helps. Check the output of vmstat -z to confirm. Steve, this is nonsense :-) You know perfectly well that UMA memory is Wired not Inactive. I'll wake up in a bit honest, thanks for the slap ;-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r273165. ZFS ARC: possible memory leak to Inact
Steven Hartland wrote On 05/11/2014 06:15, Marcus Reid wrote: On Tue, Nov 04, 2014 at 06:13:44PM +, Steven Hartland wrote: On 04/11/2014 17:22, Allan Jude wrote: snip... Justin Gibbs and I were helping George from Voxer look at the same issue they are having. They had ~169GB in inact, and only ~60GB being used for ARC. Are there any further debugging steps we can recommend to him to help investigate this? The various scripts attached to the ZS ARC behavior problem and fix PR will help provide detail this. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 I've seen it here where there's been bursts of ZFS I/O specifically write bursts. What happens is that ZFS will consume large amounts of space in various UMA zones to accommodate these bursts. If you push the vmstat -z that he provided through the arc summary script, you'll see that this is not what is happening. His uma stats match up with his arc, and do not account for his inactive memory. uma script summary: Totals oused: 5.860GB, ofree: 1.547GB, ototal: 7.407GB zused: 56.166GB, zfree: 3.918GB, ztotal: 60.084GB used: 62.026GB, free: 5.465GB, total: 67.491GB His provided top stats: Mem: 19G Active, 20G Inact, 81G Wired, 59M Cache, 3308M Buf, 4918M Free ARC: 66G Total, 6926M MFU, 54G MRU, 8069K Anon, 899M Header, 5129M Other The big uma buckets (zio_buf_16384 and zio_data_buf_131072, 18.002GB and 28.802GB respectively) are nearly 0% free. Still potentially accounts for 5.4GB of your 20GB inact. The rest could be malloc backed allocations? No. There are few reasons for that. The first one is that Inact constantly grows, and 20GiB you see were 50GiBs before we ran the script. (We have to run it periodically or else our production server will grow slower and slower) The second argumens is that our codebase is the same, the only thing that have changed is OS version. In the previous version Inact was dramatically much smaller: ~hundrets of megabytes. -- View this message in context: http://freebsd.1045724.n5.nabble.com/r273165-ZFS-ARC-possible-memory-leak-to-Inact-tp5962410p5962711.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Build failed in Jenkins: FreeBSD_HEAD-tests2 #191
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/191/ -- [...truncated 2998 lines...] libexec/atf/atf-check/atf-check_test:eflag_negated - passed [0.134s] libexec/atf/atf-check/atf-check_test:stdin - passed [0.064s] libexec/atf/atf-check/atf-check_test:invalid_umask - passed [0.060s] libexec/atf/atf-sh/atf_check_test:info_ok - passed [0.158s] libexec/atf/atf-sh/atf_check_test:expout_mismatch - passed [0.129s] libexec/atf/atf-sh/atf_check_test:experr_mismatch - passed [0.129s] libexec/atf/atf-sh/atf_check_test:null_stdout - passed [0.114s] libexec/atf/atf-sh/atf_check_test:null_stderr - passed [0.115s] libexec/atf/atf-sh/atf_check_test:equal - passed [0.236s] libexec/atf/atf-sh/atf_check_test:flush_stdout_on_timeout - passed [1.079s] libexec/atf/atf-sh/config_test:has - passed [0.204s] libexec/atf/atf-sh/config_test:get - passed [0.161s] libexec/atf/atf-sh/integration_test:no_args - passed [0.062s] libexec/atf/atf-sh/integration_test:missing_script - passed [0.065s] libexec/atf/atf-sh/integration_test:arguments - passed [0.116s] libexec/atf/atf-sh/integration_test:custom_shell__command_line - passed [0.093s] libexec/atf/atf-sh/integration_test:custom_shell__shebang - passed [0.082s] libexec/atf/atf-sh/integration_test:set_e - passed [0.085s] libexec/atf/atf-sh/normalize_test:main - passed [0.096s] libexec/atf/atf-sh/tc_test:default_status - passed [0.195s] libexec/atf/atf-sh/tc_test:missing_body - passed [0.083s] libexec/atf/atf-sh/tp_test:srcdir - passed [0.111s] libexec/rtld-elf/ld_library_pathfds:missing_library - passed [0.028s] libexec/rtld-elf/ld_library_pathfds:wrong_library_directories - passed [0.026s] libexec/rtld-elf/ld_library_pathfds:bad_library_directories - passed [0.025s] libexec/rtld-elf/ld_library_pathfds:single_library_directory - passed [0.024s] libexec/rtld-elf/ld_library_pathfds:first_library_directory - passed [0.025s] libexec/rtld-elf/ld_library_pathfds:middle_library_directory - passed [0.025s] libexec/rtld-elf/ld_library_pathfds:last_library_directory - passed [0.023s] usr.bin/cut/cut_test:basic - passed [0.079s] usr.bin/cut/cut_test:sflag - passed [0.074s] usr.bin/cut/cut_test:dflag - passed [0.070s] usr.bin/cut/cut_test:dsflag - passed [0.074s] usr.bin/cut/cut_test:latin1 - passed [0.086s] usr.bin/cut/cut_test:utf8 - passed [0.113s] usr.bin/gzip/gzip_test:concatenated - passed [0.090s] usr.bin/gzip/gzip_test:pipe - passed [1.705s] usr.bin/gzip/gzip_test:truncated - passed [0.139s] usr.bin/gzip/gzip_test:crcerror - passed [0.074s] usr.bin/gzip/gzip_test:good - passed [0.068s] usr.bin/calendar/legacy_test:main - passed [1.513s] usr.bin/mkimg/mkimg:apm_1x1_512_qcow - passed [0.825s] usr.bin/mkimg/mkimg:apm_1x1_512_qcow2 - passed [0.717s] usr.bin/mkimg/mkimg:apm_1x1_512_raw - passed [1.528s] usr.bin/mkimg/mkimg:apm_1x1_512_vhd - passed [0.973s] usr.bin/mkimg/mkimg:apm_1x1_512_vhdf - passed [1.395s] usr.bin/mkimg/mkimg:apm_1x1_512_vmdk - passed [1.368s] usr.bin/mkimg/mkimg:bsd_1x1_512_qcow - passed [1.084s] usr.bin/mkimg/mkimg:bsd_1x1_512_qcow2 - passed [0.677s] usr.bin/mkimg/mkimg:bsd_1x1_512_raw - passed [0.788s] usr.bin/mkimg/mkimg:bsd_1x1_512_vhd - passed [0.953s] usr.bin/mkimg/mkimg:bsd_1x1_512_vhdf - passed [1.779s] usr.bin/mkimg/mkimg:bsd_1x1_512_vmdk - passed [0.805s] usr.bin/mkimg/mkimg:ebr_1x1_512_qcow - passed [1.227s] usr.bin/mkimg/mkimg:ebr_1x1_512_qcow2 - passed [2.401s] usr.bin/mkimg/mkimg:ebr_1x1_512_raw - passed [1.012s] usr.bin/mkimg/mkimg:ebr_1x1_512_vhd - passed [0.932s] usr.bin/mkimg/mkimg:ebr_1x1_512_vhdf - passed [0.867s] usr.bin/mkimg/mkimg:ebr_1x1_512_vmdk - passed [2.457s] usr.bin/mkimg/mkimg:gpt_1x1_512_qcow - passed [0.697s] usr.bin/mkimg/mkimg:gpt_1x1_512_qcow2 - passed [1.752s] usr.bin/mkimg/mkimg:gpt_1x1_512_raw - passed [0.753s] usr.bin/mkimg/mkimg:gpt_1x1_512_vhd - passed [0.653s] usr.bin/mkimg/mkimg:gpt_1x1_512_vhdf - passed [0.806s] usr.bin/mkimg/mkimg:gpt_1x1_512_vmdk - passed [0.760s] usr.bin/mkimg/mkimg:mbr_1x1_512_qcow - passed [2.012s] usr.bin/mkimg/mkimg:mbr_1x1_512_qcow2 - passed [1.963s] usr.bin/mkimg/mkimg:mbr_1x1_512_raw - passed [2.774s] usr.bin/mkimg/mkimg:mbr_1x1_512_vhd - passed [3.180s] usr.bin/mkimg/mkimg:mbr_1x1_512_vhdf - passed [1.032s] usr.bin/mkimg/mkimg:mbr_1x1_512_vmdk - passed [0.950s] usr.bin/mkimg/mkimg:pc98_1x1_512_qcow - passed [1.807s] usr.bin/mkimg/mkimg:pc98_1x1_512_qcow2 - passed [0.922s] usr.bin/mkimg/mkimg:pc98_1x1_512_raw - passed [2.933s] usr.bin/mkimg/mkimg:pc98_1x1_512_vhd - passed [1.217s] usr.bin/mkimg/mkimg:pc98_1x1_512_vhdf - passed [2.472s] usr.bin/mkimg/mkimg:pc98_1x1_512_vmdk - passed [1.017s] usr.bin/mkimg/mkimg:vtoc8_1x1_512_qcow - passed [0.674s] usr.bin/mkimg/mkimg:vtoc8_1x1_512_qcow2 - passed [0.738s]
Re: r273165. ZFS ARC: possible memory leak to Inact
On 11/4/2014 5:47 AM, Dmitriy Makarov wrote: Funny thing is that when we manually allocate and release memory, using simple python script: ... Current workaround is to periodically invoke this python script by cron. I wonder if this is related to PR https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194513 This is against zfs recv and hanging in process state kmem arena but also has a workaround of allocating lots of memory in userland. But I do not see a lot of inactive with that PR. zpool history also hangs sometimes in kmem arena but I do not have a workaround for that. This PR is filed against 10-STABLE but confirmed against CURRENT too. SUPERTEX:/root# uname -a FreeBSD SUPERTEX.housenet.jrv 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #3 r273476M: Wed Oct 22 15:05:29 CDT 2014 r...@supertex.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 SUPERTEX:/root# top last pid: 37286; load averages: 0.03, 0.05, 0.05 up 11+11:24:34 06:25:46 39 processes: 1 running, 38 sleeping CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 6444K Active, 57M Inact, 6475M Wired, 25G Free ARC: 4753M Total, 862M MFU, 2765M MRU, 52K Anon, 139M Header, 986M Other Swap: 31G Total, 21M Used, 31G Free PID USERNAMETHR PRI NICE SIZERES STATE C TIMEWCPU COMMAND 676 root 1 200 25456K 1048K select 8 0:22 0.00% ntpd 723 root 1 200 24112K 1472K select 13 0:09 0.00% sendmail 12105 root 1 200 103M 35984K kmem a 11 0:04 0.00% zpool 693 root 1 200 30676K 1684K nanslp 10 0:03 0.00% smartd 519 root 1 200 14508K 684K select 5 0:02 0.00% syslogd ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r273165. ZFS ARC: possible memory leak to Inact
On 05/11/2014 14:36, James R. Van Artsdalen wrote: I wonder if this is related to PR https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194513 This is against zfs recv and hanging in process state kmem arena but also has a workaround of allocating lots of memory in userland. If something hangs (appears to hang) and it's ZFS related, then https://wiki.freebsd.org/AvgZfsDeadlockDebug But I do not see a lot of inactive with that PR. zpool history also hangs sometimes in kmem arena but I do not have a workaround for that. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
buildkernel broken in HEAD
HEAD updated just minutes ago: -- stage 3.1: making dependencies -- @/amd64/amd64/genassym.c:79:16: error: no member named 'pm_save' in 'pmap' ASSYM(PM_SAVE, offsetof(struct pmap, pm_save)); pm_save is not present in any pmap.h under /sys. -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: buildkernel broken in HEAD
On Wed, Nov 05, 2014 at 02:18:13PM +0100, Gary Jennejohn wrote: HEAD updated just minutes ago: -- stage 3.1: making dependencies -- @/amd64/amd64/genassym.c:79:16: error: no member named 'pm_save' in 'pmap' ASSYM(PM_SAVE, offsetof(struct pmap, pm_save)); pm_save is not present in any pmap.h under /sys. ... I just built, booted, and smoke-checked: FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1418 r274130M/274133:1100044: Wed Nov 5 05:47:27 PST 2014 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpLr9gjfSLMX.pgp Description: PGP signature
Re: HEADS UP: Enabling vt(4) by default
On Wed, 5 Nov 2014 10:19:51 +0100 Gary Jennejohn gljennj...@gmail.com wrote On Tue, 04 Nov 2014 18:01:41 -0800 Chris H bsd-li...@bsdforge.com wrote: On Tue, 04 Nov 2014 18:22:06 +0100 Jean-Sebastien Pedron jean-sebastien.ped...@dumbbell.fr wrote Hello! As announced a week ago, vt(4) is now the default console driver in 11-CURRENT as of r274085. You may have to update your console settings in /etc/rc.conf. During boot, /etc/rc.d/syscons will indicate what you need to do. The original HEADS UP mentioned several known issues. Among them, the following were fixed: o A video mode can be selected using the following tunable in /boot/loader.conf: kern.vt.fb.default_mode=1024x768 This only works when using a KMS video driver. It's not supported by the VGA backend. See vt(4) man page for further documentation. o The keyboard was not working when kbdmux(4) was disabled. This is fixed. o After loading a KMS driver, the text cursor was in the middle of the kernel messages. The problem was that the cursor position was not updated after the change in window size. This is fixed. Up-to-date information can be found on the wiki page: https://wiki.freebsd.org/Newcons If you want to keep using syscons(4), you can add the following line to /boot/loader.conf: kern.vty=sc Thank you to everyone who tested and reported problems! Please continue to do so, especially if you find the need to go back to syscons. No. Thank _you_! :) I was unable to determine from the wiki. But do all these wonderful new features also work with the nVidia blob, under vt(4)? I'm currently building a new 11-CURRENT from the 10-26 iso, as I write this, and was wondering if the graphics mode at higher resolutions was now possible using the nVidia blob. No, video mode won't work with the nVidia blob. That requires a KMS (in-kernel) driver. Thank you for the reply, Gary. Ahh. I see. So unless I have ATI hardware, I'm pretty much out of luck? Thanks again. --Chris -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Enabling vt(4) by default
On Wed, Nov 5, 2014 at 3:36 PM, Chris H bsd-li...@bsdforge.com wrote: On Wed, 5 Nov 2014 10:19:51 +0100 Gary Jennejohn gljennj...@gmail.com wrote On Tue, 04 Nov 2014 18:01:41 -0800 Chris H bsd-li...@bsdforge.com wrote: On Tue, 04 Nov 2014 18:22:06 +0100 Jean-Sebastien Pedron jean-sebastien.ped...@dumbbell.fr wrote Hello! As announced a week ago, vt(4) is now the default console driver in 11-CURRENT as of r274085. You may have to update your console settings in /etc/rc.conf. During boot, /etc/rc.d/syscons will indicate what you need to do. The original HEADS UP mentioned several known issues. Among them, the following were fixed: o A video mode can be selected using the following tunable in /boot/loader.conf: kern.vt.fb.default_mode=1024x768 This only works when using a KMS video driver. It's not supported by the VGA backend. See vt(4) man page for further documentation. o The keyboard was not working when kbdmux(4) was disabled. This is fixed. o After loading a KMS driver, the text cursor was in the middle of the kernel messages. The problem was that the cursor position was not updated after the change in window size. This is fixed. Up-to-date information can be found on the wiki page: https://wiki.freebsd.org/Newcons If you want to keep using syscons(4), you can add the following line to /boot/loader.conf: kern.vty=sc Thank you to everyone who tested and reported problems! Please continue to do so, especially if you find the need to go back to syscons. No. Thank _you_! :) I was unable to determine from the wiki. But do all these wonderful new features also work with the nVidia blob, under vt(4)? I'm currently building a new 11-CURRENT from the 10-26 iso, as I write this, and was wondering if the graphics mode at higher resolutions was now possible using the nVidia blob. No, video mode won't work with the nVidia blob. That requires a KMS (in-kernel) driver. Thank you for the reply, Gary. Ahh. I see. So unless I have ATI hardware, I'm pretty much out of luck? Thanks again. --Chris -- Gary Jennejohn Well, ATI or Intel chip. Best regards Andreas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: buildkernel broken in HEAD
On Wed, 5 Nov 2014 06:02:39 -0800 David Wolfskill da...@catwhisker.org wrote: On Wed, Nov 05, 2014 at 02:18:13PM +0100, Gary Jennejohn wrote: HEAD updated just minutes ago: -- stage 3.1: making dependencies -- @/amd64/amd64/genassym.c:79:16: error: no member named 'pm_save' in 'pmap' ASSYM(PM_SAVE, offsetof(struct pmap, pm_save)); pm_save is not present in any pmap.h under /sys. ... I just built, booted, and smoke-checked: FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1418 r274130M/274133:1100044: Wed Nov 5 05:47:27 PST 2014 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 Thanks, but I'm at Updating '.': At revision 274134 -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: current panic: Lock (sx) random_adaptors not locked @
Xin Li wrote: On 11/04/14 06:01, Julian H. Stacey wrote: Hi current@ Maybe this is a transient no one else will see ?: with no /boot/loader.conf, my old custom kernel booted my new one paniced: panic: Lock (sx) random_adaptors not locked @ dev/random/random_adaptors.c:278 This was fixed in r274006 FYI. OK, Thanks Xin Li. Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Indent previous with . Interleave reply paragraphs like a play script. Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Enabling vt(4) by default
On Wed, 5 Nov 2014, Chris H wrote: On Wed, 5 Nov 2014 10:19:51 +0100 Gary Jennejohn gljennj...@gmail.com wrote No, video mode won't work with the nVidia blob. That requires a KMS (in-kernel) driver. Thank you for the reply, Gary. Ahh. I see. So unless I have ATI hardware, I'm pretty much out of luck? Or Intel, or anything with KMS drivers. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Enabling vt(4) by default
On Wed, 5 Nov 2014 08:15:04 -0700 (MST) Warren Block wbl...@wonkity.com wrote On Wed, 5 Nov 2014, Chris H wrote: On Wed, 5 Nov 2014 10:19:51 +0100 Gary Jennejohn gljennj...@gmail.com wrote No, video mode won't work with the nVidia blob. That requires a KMS (in-kernel) driver. Thank you for the reply, Gary. Ahh. I see. So unless I have ATI hardware, I'm pretty much out of luck? Or Intel, or anything with KMS drivers. Thanks. Everything I manage, is using nVidia. Looks like the kms VESA might work. But I'm not sure if there would be any appreciable gain going that route (assuming it's even possible). Thanks again, for the reply, Warren. --Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
LOR on CURRENT
Greetings, a fresh install off the 2014-10-26 bootonly iso, generates the following LOR: lock order reversal: 1st 0xfe00f7626b48 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3093 2nd 0xf8000404aa00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:2 84 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0120cd9650 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0120cd9700 witness_checkorder() at witness_checkorder+0xdad/frame 0xfe0120cd9790 _sx_xlock() at _sx_xlock+0x75/frame 0xfe0120cd97d0 ufsdirhash_remove() at ufsdirhash_remove+0x37/frame 0xfe0120cd9800 ufs_dirremove() at ufs_dirremove+0x11b/frame 0xfe0120cd9860 ufs_remove() at ufs_remove+0x75/frame 0xfe0120cd98c0 VOP_REMOVE_APV() at VOP_REMOVE_APV+0xf7/frame 0xfe0120cd98f0 kern_unlinkat() at kern_unlinkat+0x209/frame 0xfe0120cd9ae0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfe0120cd9bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0120cd9bf0 --- syscall (10, FreeBSD ELF64, sys_unlink), rip = 0x800b5208a, rsp = 0x7fff eb58, rbp = 0x7fffeb70 --- it's not FATAL, but thought it worth mentioning. I haven't built, or installed world|kernel (yet). I also have dmesg(8) from that session, out of var/run/dmesg.boot, and would be happy to provide it, on request. Thank you for all your time, and consideration. --Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r273165. ZFS ARC: possible memory leak to Inact
On 05/11/2014 18:32, James R. Van Artsdalen wrote: On 11/5/2014 6:41 AM, Andriy Gapon wrote: If something hangs (appears to hang) and it's ZFS related, then https://wiki.freebsd.org/AvgZfsDeadlockDebug I don't think thezpool history hang is in ZFS or storage layer code: it seems be stalled in kernel malloc(). See PID 12105 (zpool history) below. The wiki page has this underscored line :-) when reporting a problem please always include full information about thread stacks, don't cherry pick; the output can be large, upload it somewhere and post a link SUPERTEX:/root# uname -a FreeBSD SUPERTEX.housenet.jrv 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #3 r273476M: Wed Oct 22 15:05:29 CDT 2014 r...@supertex.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 SUPERTEX:/root# procstat -kk -a kk SUPERTEX:/root# grep zio_wait kk SUPERTEX:/root# grep zio_done kk SUPERTEX:/root# grep zio_int kk SUPERTEX:/root# grep zfs_ kk 0 100475 kernel zfs_vn_rele_task mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 101018 kernel zfs_vn_rele_task mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 101522 kernel zfs_vn_rele_task mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 12105 101599 zpool-mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d vmem_xalloc+0x568 vmem_alloc+0x3d kmem_malloc+0x33 uma_large_malloc+0x49 malloc+0x43 zfs_ioc_pool_get_history+0xbd zfsdev_ioctl+0x5ca devfs_ioctl_f+0x139 kern_ioctl+0x255 sys_ioctl+0x13c amd64_syscall+0x351 Xfast_syscall+0xfb SUPERTEX:/root# grep dmu_ kk SUPERTEX:/root# grep arc_ kk 3 100125 zfskern arc_reclaim_thre mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x18b arc_reclaim_thread+0x288 fork_exit+0x9a fork_trampoline+0xe 3 100126 zfskern l2arc_feed_threa mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x18b l2arc_feed_thread+0x19f fork_exit+0x9a fork_trampoline+0xe SUPERTEX:/root# grep buf_ kk 20 100139 bufdaemon-mi_switch+0xe1 sleepq_timedwait+0x3a _sleep+0x26e buf_daemon+0x78 fork_exit+0x9a fork_trampoline+0xe SUPERTEX:/root# ps lp 12105 UID PID PPID CPU PRI NIVSZ RSS MWCHAN STAT TT TIME COMMAND 0 12105 12104 0 20 0 105692 35984 kmem are D - 0:03.76 zpool history BI SUPERTEX:/root# -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r273165. ZFS ARC: possible memory leak to Inact
On 11/5/2014 6:41 AM, Andriy Gapon wrote: If something hangs (appears to hang) and it's ZFS related, then https://wiki.freebsd.org/AvgZfsDeadlockDebug I don't think thezpool history hang is in ZFS or storage layer code: it seems be stalled in kernel malloc(). See PID 12105 (zpool history) below. SUPERTEX:/root# uname -a FreeBSD SUPERTEX.housenet.jrv 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #3 r273476M: Wed Oct 22 15:05:29 CDT 2014 r...@supertex.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 SUPERTEX:/root# procstat -kk -a kk SUPERTEX:/root# grep zio_wait kk SUPERTEX:/root# grep zio_done kk SUPERTEX:/root# grep zio_int kk SUPERTEX:/root# grep zfs_ kk 0 100475 kernel zfs_vn_rele_task mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 101018 kernel zfs_vn_rele_task mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 0 101522 kernel zfs_vn_rele_task mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a fork_trampoline+0xe 12105 101599 zpool-mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d vmem_xalloc+0x568 vmem_alloc+0x3d kmem_malloc+0x33 uma_large_malloc+0x49 malloc+0x43 zfs_ioc_pool_get_history+0xbd zfsdev_ioctl+0x5ca devfs_ioctl_f+0x139 kern_ioctl+0x255 sys_ioctl+0x13c amd64_syscall+0x351 Xfast_syscall+0xfb SUPERTEX:/root# grep dmu_ kk SUPERTEX:/root# grep arc_ kk 3 100125 zfskern arc_reclaim_thre mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x18b arc_reclaim_thread+0x288 fork_exit+0x9a fork_trampoline+0xe 3 100126 zfskern l2arc_feed_threa mi_switch+0xe1 sleepq_timedwait+0x3a _cv_timedwait_sbt+0x18b l2arc_feed_thread+0x19f fork_exit+0x9a fork_trampoline+0xe SUPERTEX:/root# grep buf_ kk 20 100139 bufdaemon-mi_switch+0xe1 sleepq_timedwait+0x3a _sleep+0x26e buf_daemon+0x78 fork_exit+0x9a fork_trampoline+0xe SUPERTEX:/root# ps lp 12105 UID PID PPID CPU PRI NIVSZ RSS MWCHAN STAT TT TIME COMMAND 0 12105 12104 0 20 0 105692 35984 kmem are D - 0:03.76 zpool history BI SUPERTEX:/root# ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Build failed in Jenkins: FreeBSD_HEAD-tests2 #187
On Nov 4, 2014, at 12:42, Garrett Cooper yaneurab...@gmail.com wrote: On Nov 4, 2014, at 12:09, jenkins-ad...@freebsd.org wrote: See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/187/ ... Hi Craig/Jenkins admins, I opened a pull request to increase the timeout from 1 to 2 hours when running kyua test”: https://github.com/freebsd/freebsd-ci/pull/1/files . Thank you! Hi again, I looked at the output from the latest failed run, and the real problem is that it’s assuming that “# “ is a sufficiently unique string to find a prompt. Long story short is it isn’t. Unique prompt handling is done better in pxssh with a bit more complex algorithms. I’ll provide better unique prompt handling and redo the pull request. Thanks! signature.asc Description: Message signed with OpenPGP using GPGMail
Re: android bsd connectivity tools etc ?
Jamie Landeg-Jones wrote: Julian H. Stacey j...@berklix.com wrote: Any tips for Android / FreeBSD BSD tools for connectivity etc ? I mainly use nfs / ssh (dropbear) / scp for connectivity over IPv6 to my local FreeBSD server. It works quite well - I even have automated cron rsync deduped backups! NFS is used for mounting my media onto /sdcard/Videos /sdcard/Music /sdcard/Pictures Not all androids come with nfs in the kernel though, NFS [ AMD] [ SSH] would be ideal for me. I had a look on my Samsung Galaxy Note 3, with Android 4.4.2 kernel 3.4.0, skimmed index of the 182 page pdf, but I dont know how to tell if mine has NFS ? Or how to get it. I get no umass /dev/da* I probably need to tweak my android somehow. For Per who wrote For tethering I have no idea, sorry. I have usb tethering working :-) if you want it too, see below. My android browser over USB does read from httpd on my FreeBSD :-) Thank to all who have contributed info URLS etc. Collated at: http://www.berklix.com/~jhs/android/#connect Corrections, additions etc welcome. Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Indent previous with . Interleave reply paragraphs like a play script. Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Jenkins build is unstable: FreeBSD_HEAD-tests2 #192
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/192/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: LOR on CURRENT
On Wed, 5 Nov 2014, Chris H wrote: Greetings, a fresh install off the 2014-10-26 bootonly iso, generates the following LOR: lock order reversal: 1st 0xfe00f7626b48 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3093 2nd 0xf8000404aa00 dirhash (dirhash) @ This one is a very well-known false positive. http://sources.zabbadoz.net/freebsd/lor/261.html -Ben ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: LOR on CURRENT
On Wed, 5 Nov 2014 13:38:01 -0500 (EST) Benjamin Kaduk ka...@mit.edu wrote On Wed, 5 Nov 2014, Chris H wrote: Greetings, a fresh install off the 2014-10-26 bootonly iso, generates the following LOR: lock order reversal: 1st 0xfe00f7626b48 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3093 2nd 0xf8000404aa00 dirhash (dirhash) @ This one is a very well-known false positive. http://sources.zabbadoz.net/freebsd/lor/261.html Ahh. I see. Thanks for putting my mind at ease. :) Maybe witness(4) needs to be better educated? Thank you for taking the time to reply, Ben. --Chris -Ben ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ERROR: ctfconvert: aaa_bbb.o doesn't have type data to convert
Greetings, I'm building/installing world/kernel on a fresh 11-CURRENT. As I write this, the kernel is building, and emitting 100's of lines with the following: ERROR: ctfconvert: aaa_bbb.o doesn't have type data to convert where aaa_bbb is the driver file being created. Should I be concerned? What would cause this? Thank you for all your time, and consideration. --Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ERROR: ctfconvert: aaa_bbb.o doesn't have type data to convert
On Wed, Nov 05, 2014 at 11:03:46AM -0800, Chris H wrote: Greetings, I'm building/installing world/kernel on a fresh 11-CURRENT. As I write this, the kernel is building, and emitting 100's of lines with the following: ERROR: ctfconvert: aaa_bbb.o doesn't have type data to convert where aaa_bbb is the driver file being created. Should I be concerned? What would cause this? For posterity, we determined off-list that this was due to removing DEBUG=-g from the kernel config. In this case the ctf tools have no debug symbols to work with, hence the errors. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Enabling vt(4) by default
On Wed, 5 Nov 2014, Chris H wrote: On Wed, 5 Nov 2014 08:15:04 -0700 (MST) Warren Block wbl...@wonkity.com wrote On Wed, 5 Nov 2014, Chris H wrote: On Wed, 5 Nov 2014 10:19:51 +0100 Gary Jennejohn gljennj...@gmail.com wrote No, video mode won't work with the nVidia blob. That requires a KMS (in-kernel) driver. Thank you for the reply, Gary. Ahh. I see. So unless I have ATI hardware, I'm pretty much out of luck? Or Intel, or anything with KMS drivers. Thanks. Everything I manage, is using nVidia. Looks like the kms VESA might work. But I'm not sure if there would be any appreciable gain going that route (assuming it's even possible). It's worth asking Nvidia directly. I would not be optimistic about that, but it's easy to try, and they might surprise everyone. Another option might be nouveau. Don't know the current status of whether that works on FreeBSD, though. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Build failed in Jenkins: FreeBSD_HEAD #1777
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/1777/changes Changes: [ngie] Expect lib.libc.sys.getcontext_test.setcontext_link to fail on amd64; add additional debugging to make the underlying problem more visible Calling setcontext(2) on amd64 as shown in the test program is failing on amd64, not i386, with a return code of -1 and an errno of EINVAL Further investigation is being done in the PR to determine the root cause for the failure PR: 194828 Tested with the following configuration: - amd64/i386 - 11.0-CURRENT @ r273153 - 100 times in a tight loop as root with the following commands... -- kyua test lib/libc -- kyua test lib/libc/sys -- kyua test lib/libc/sys/getcontext_test [ngie] Remove expected failure from lib.libc.sys.t_mincore:mincore_resid The failure was added based on observation seen on 11.0-CURRENT @ r273153, not based on internal testing at EMC/Isilon PR: 194829 Tested with the following configuration: - amd64/i386 - 11.0-CURRENT @ r273153 - 100 times in a tight loop as root with the following commands... -- kyua test lib/libc -- kyua test lib/libc/sys -- kyua test lib/libc/sys/mincore_test [des] Hook up OpenPAM's own unit tests to the build. [bapt] ftp(1) uses nothing from libutil, do not link to it -- [...truncated 173588 lines...] === lib/libpam/modules/pam_opieaccess (all) --- usr.sbin.all__D --- --- nswalk.o --- cc -O2 -pipe -DACPI_ASL_COMPILER -I. -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -fstack-protector -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-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/namespace/nswalk.c --- lib.all__D --- --- pam_opieaccess.8.gz --- gzip -cn https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/libpam/modules/pam_opieaccess/pam_opieaccess.8 pam_opieaccess.8.gz === lib/libpam/modules/pam_passwdqc (all) --- usr.sbin.all__D --- --- all_subdir_amd --- --- fsi_dict.o --- cc -O2 -pipe -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/usr.sbin/amd/fsinfo/../../../contrib/amd/fsinfo -I. -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/usr.sbin/amd/fsinfo -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/usr.sbin/amd/fsinfo/../include -I/usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/usr.sbin/amd/fsinfo/../include -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/usr.sbin/amd/fsinfo/../../../contrib/amd/include -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/usr.sbin/amd/fsinfo/../../../contrib/amd -DHAVE_CONFIG_H -DHOST_CPU=\amd64\ -DHOST_ARCH=\amd64\ -std=gnu99 -fstack-protector -Wsystem-headers -Werror -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-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused- arguments -c https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/usr.sbin/amd/fsinfo/../../../contrib/amd/fsinfo/fsi_dict.c --- all_subdir_acpi --- --- tbdata.o --- cc -O2 -pipe -DACPI_ASL_COMPILER -I. -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -fstack-protector -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-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/tables/tbdata.c --- lib.all__D --- --- pam_passwdqc.8.gz --- gzip -cn https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/libpam/modules/pam_passwdqc/pam_passwdqc.8 pam_passwdqc.8.gz === lib/libpam/modules/pam_permit (all) --- pam_permit.8.gz --- gzip -cn https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/libpam/modules/pam_permit/pam_permit.8 pam_permit.8.gz --- usr.sbin.all__D --- --- tbfadt.o --- --- lib.all__D --- === lib/libpam/modules/pam_radius (all) --- usr.sbin.all__D --- cc -O2 -pipe -DACPI_ASL_COMPILER -I. -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -fstack-protector -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
Re: HEADS UP: Enabling vt(4) by default
On Wed, 5 Nov 2014 12:55:51 -0700 (MST) Warren Block wbl...@wonkity.com wrote On Wed, 5 Nov 2014, Chris H wrote: On Wed, 5 Nov 2014 08:15:04 -0700 (MST) Warren Block wbl...@wonkity.com wrote On Wed, 5 Nov 2014, Chris H wrote: On Wed, 5 Nov 2014 10:19:51 +0100 Gary Jennejohn gljennj...@gmail.com wrote No, video mode won't work with the nVidia blob. That requires a KMS (in-kernel) driver. Thank you for the reply, Gary. Ahh. I see. So unless I have ATI hardware, I'm pretty much out of luck? Or Intel, or anything with KMS drivers. Thanks. Everything I manage, is using nVidia. Looks like the kms VESA might work. But I'm not sure if there would be any appreciable gain going that route (assuming it's even possible). It's worth asking Nvidia directly. I would not be optimistic about that, but it's easy to try, and they might surprise everyone. Another option might be nouveau. Don't know the current status of whether that works on FreeBSD, though. LOL funny you should bring that up, just now. Prior to a fresh install on bare metal. I always boot to a gpartd CD. I use it to easily see, and quickly blank the disk(s). I only choose it, because it's quick-n-easy. It is also the perfect tool to wipe that evil grub[2] off the MBR. Which has given me no end of grief after evaluating some Linux distro. Anyhow, point being; the desktop is powered by nouveau. I've never had an issue with it, and it always seems to pick the right resolution/frequency. So, because of that. I was already thinking of investigating that route. As to talking to nVidia. My past experiences in that regard were, shall I say; less than ideal. They're always friendly. But getting anything that might uncover any coveted driver info, always fell short of helpful. :) Thanks for the reply, and helpful information, Warren. --Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Enabling vt(4) by default
On 11/05/14 22:27, Chris H wrote: On Wed, 5 Nov 2014 12:55:51 -0700 (MST) Warren Block wbl...@wonkity.com wrote On Wed, 5 Nov 2014, Chris H wrote: On Wed, 5 Nov 2014 08:15:04 -0700 (MST) Warren Block wbl...@wonkity.com wrote On Wed, 5 Nov 2014, Chris H wrote: On Wed, 5 Nov 2014 10:19:51 +0100 Gary Jennejohn gljennj...@gmail.com wrote No, video mode won't work with the nVidia blob. That requires a KMS (in-kernel) driver. Thank you for the reply, Gary. Ahh. I see. So unless I have ATI hardware, I'm pretty much out of luck? Or Intel, or anything with KMS drivers. Thanks. Everything I manage, is using nVidia. Looks like the kms VESA might work. But I'm not sure if there would be any appreciable gain going that route (assuming it's even possible). It's worth asking Nvidia directly. I would not be optimistic about that, but it's easy to try, and they might surprise everyone. Another option might be nouveau. Don't know the current status of whether that works on FreeBSD, though. LOL funny you should bring that up, just now. Prior to a fresh install on bare metal. I always boot to a gpartd CD. I use it to easily see, and quickly blank the disk(s). I only choose it, because it's quick-n-easy. It is also the perfect tool to wipe that evil grub[2] off the MBR. Which has given me no end of grief after evaluating some Linux distro. Anyhow, point being; the desktop is powered by nouveau. I've never had an issue with it, and it always seems to pick the right resolution/frequency. So, because of that. I was already thinking of investigating that route. As to talking to nVidia. My past experiences in that regard were, shall I say; less than ideal. They're always friendly. But getting anything that might uncover any coveted driver info, always fell short of helpful. :) Thanks for the reply, and helpful information, Warren. --Chris Hi, FYI: The KMS stuff seems to work on my intel HD graphics based MAC. Finally I can switch back to the console! --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Jenkins build is back to normal : FreeBSD_HEAD #1778
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/1778/changes ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Build failed in Jenkins: Build-UFS-image #330
See https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/330/ -- [...truncated 5350 lines...] https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nvlist_addv_null.3.gz - https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nv.3.gz https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nvlist_addv_bool.3.gz - https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nv.3.gz https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nvlist_addv_number.3.gz - https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nv.3.gz https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nvlist_addv_string.3.gz - https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nv.3.gz https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nvlist_addv_nvlist.3.gz - https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nv.3.gz https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nvlist_addv_descriptor.3.gz - https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nv.3.gz https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nvlist_addv_binary.3.gz - https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nv.3.gz https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nvlist_movev_string.3.gz - https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nv.3.gz https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nvlist_movev_nvlist.3.gz - https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nv.3.gz https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nvlist_movev_descriptor.3.gz - https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nv.3.gz https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nvlist_movev_binary.3.gz - https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nv.3.gz https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nvlist_getv_bool.3.gz - https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nv.3.gz https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nvlist_getv_number.3.gz - https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nv.3.gz https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nvlist_getv_string.3.gz - https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nv.3.gz https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nvlist_getv_nvlist.3.gz - https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nv.3.gz https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nvlist_getv_descriptor.3.gz - https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nv.3.gz https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nvlist_getv_binary.3.gz - https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nv.3.gz https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nvlist_takev_bool.3.gz - https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nv.3.gz https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nvlist_takev_number.3.gz - https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nv.3.gz https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nvlist_takev_string.3.gz - https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nv.3.gz https://jenkins.freebsd.org/jenkins/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/man/man3/nvlist_takev_nvlist.3.gz -
Re: HEADS UP: Enabling vt(4) by default
On Wed, 05 Nov 2014 22:29:53 +0100 Hans Petter Selasky h...@selasky.org wrote On 11/05/14 22:27, Chris H wrote: On Wed, 5 Nov 2014 12:55:51 -0700 (MST) Warren Block wbl...@wonkity.com wrote On Wed, 5 Nov 2014, Chris H wrote: On Wed, 5 Nov 2014 08:15:04 -0700 (MST) Warren Block wbl...@wonkity.com wrote On Wed, 5 Nov 2014, Chris H wrote: On Wed, 5 Nov 2014 10:19:51 +0100 Gary Jennejohn gljennj...@gmail.com wrote No, video mode won't work with the nVidia blob. That requires a KMS (in-kernel) driver. Thank you for the reply, Gary. Ahh. I see. So unless I have ATI hardware, I'm pretty much out of luck? Or Intel, or anything with KMS drivers. Thanks. Everything I manage, is using nVidia. Looks like the kms VESA might work. But I'm not sure if there would be any appreciable gain going that route (assuming it's even possible). It's worth asking Nvidia directly. I would not be optimistic about that, but it's easy to try, and they might surprise everyone. Another option might be nouveau. Don't know the current status of whether that works on FreeBSD, though. LOL funny you should bring that up, just now. Prior to a fresh install on bare metal. I always boot to a gpartd CD. I use it to easily see, and quickly blank the disk(s). I only choose it, because it's quick-n-easy. It is also the perfect tool to wipe that evil grub[2] off the MBR. Which has given me no end of grief after evaluating some Linux distro. Anyhow, point being; the desktop is powered by nouveau. I've never had an issue with it, and it always seems to pick the right resolution/frequency. So, because of that. I was already thinking of investigating that route. As to talking to nVidia. My past experiences in that regard were, shall I say; less than ideal. They're always friendly. But getting anything that might uncover any coveted driver info, always fell short of helpful. :) Thanks for the reply, and helpful information, Warren. --Chris Hi, FYI: The KMS stuff seems to work on my intel HD graphics based MAC. Finally I can switch back to the console! Thanks for sharing that, Hans. I'm looking to pick up some Mac hardware to put FreeBSD on. Now, I'm even more anxious to get it. :) --Chris --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Strange failure with 10.x jail in poudriere on head
Hi,
Today I updated my system to r274133, it works fine, but I see a strange
problem in 10.x jails, which, even stranger, is not happening in 9.x and
8.x jails.
the jails are created using ftp, so downloading official binaries.
The python ports fail with this error at staging time:
running install_lib
error: error listing files in 'build/lib.freebsd-10.1-RC4-i386-2.7':
Operation not supported
*** Error code 1
full log here, against 10.0-p12 on amd64 jail:
http://www.madpilot.net/~mad/python27-2.7.8_6.log
the code (python) is trying to perform
os.listdir('build/lib.freebsd-10.1-RC4-i386-2.7') at that point. The
directory exists and does not have strange permissions.
Installing python in a 10.1 VM in Virtualbox works fine.
I suspect some recent change to head kernel is causing it to produce
this failure in 10.x jails, But I'm at a loss on how this could be
happening.
Any suggestion on how I can debug this? Anyone has an idea what could be
causing this?
I upgraded from r273455.
Thanks in advance.
--
Guido Falsi m...@madpilot.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Strange failure with 10.x jail in poudriere on head
On 11/06/14 00:28, Guido Falsi wrote: Hi, Today I updated my system to r274133, it works fine, but I see a strange problem in 10.x jails, which, even stranger, is not happening in 9.x and 8.x jails. the jails are created using ftp, so downloading official binaries. The python ports fail with this error at staging time: running install_lib error: error listing files in 'build/lib.freebsd-10.1-RC4-i386-2.7': Operation not supported *** Error code 1 full log here, against 10.0-p12 on amd64 jail: correction, the log is from 10.1-RC4-p1 i386, but I have the same error and log from 10.0 amd64 and i386. -- Guido Falsi m...@madpilot.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: android bsd connectivity tools etc ?
Julian H. Stacey j...@berklix.com wrote: Firstly, if you haven't already, I'd recommend 'Android terminal emulator' and 'hackers keyboard' - both free from the Play store. To be able to create startup scripts without reflashing etc. you must have root, and be able to write the file /system/etc/install_recovery.sh NFS [ AMD] [ SSH] would be ideal for me. I had a look on my Samsung Galaxy Note 3, with Android 4.4.2 kernel 3.4.0, skimmed index of the 182 page pdf, but I dont know how to tell if mine has NFS ? Or how to get it. I have the dropbear ssh client and server. I've not managed to compile them or openssh yet - instead I grabbed the binaries (opened source) from inside one of the free sshd server apps on the play store. One of my newer devices doesn't come with NFS, the others do. You need to find the correct nfs.ko kernel module for your kernel, and/or recompile the linux kernel - both things I've not achieved yet (running FreeBSD and not Linux/Windows makes things harder with no SDK etc.) but all this is part of what I'm investigating at the moment, so it would be great to be able to share notes with someone else sith a FreeBSD mindset. If you have nfs already, the standard mount should work from root: | 23:29 [3] (1) root@tabbycat:/usr/users/jamie # mkdir /tmp/test | 23:29 [3] (2) root@tabbycat:/usr/users/jamie # mount -o nolock,hard,ro lnfs:/nfs/b/tabbycat/ /tmp/test | 23:30 [3] (3) root@tabbycat:/usr/users/jamie # df -h | Filesystem Size Used Available Capacity Mounted on | tmpfs 176.7M 52.0K176.7M 0%/dev | devpts 0 0 0 0%/dev/pts | proc 0 0 0 0%/proc | sysfs 0 0 0 0%/sys | none 0 0 0 0%/acct | tmpfs 176.7M 0176.7M 0%/mnt/asec | tmpfs 176.7M 0176.7M 0%/mnt/obb | /dev/block/nandd 1007.9M282.6M725.3M28%/system | /dev/block/nande 1007.9M137.4M870.5M14%/data | /dev/block/nandh 252.0M 4.3M247.7M 2%/cache | /dev/block/nandd 1007.9M282.6M725.3M28%/bin | hidden 0 0 0 0% /system/.bin_mount | tmpfs 128.0M 8.0K128.0M 0%/tmp | /dev/block/nandj2 718.0M404.7M313.3M56%/usr | /dev/block/nandj3 100.4M 19.3M 81.1M19%/var | tmpfs 1.0M 4.0K 1020.0K 0%/var/run | /dev/block/mmcblk0p2 18.6G 1.3G 16.4G 7%/data2 | /dev/block/vold/93:76 23.5M 8.0K 23.5M 0%/mnt/extsd | /dev/block/vold/179:3 10.5G 5.5G 5.0G52%/mnt/sdcard | /dev/block/vold/179:3 10.5G 5.5G 5.0G52% /mnt/secure/asec | tmpfs 0 0 0 0% /mnt/sdcard/.android_secure | lnfs:/nfs/j/Misc/ 1.8T 1.5T143.7G91% /mnt/sdcard/Misc | lnfs:/nfs/j/Music/ 1.8T 1.5T143.7G91% /mnt/sdcard/Music/lapcat | lnfs:/nfs/j/Videos/ 1.8T 1.5T143.7G91% /mnt/sdcard/Videos/lapcat | lnfs:/nfs/j/Pictures/ 1.8T 1.5T143.7G91% /mnt/sdcard/Pictures/lapcat | lnfs:/nfs/APK-archives/ 1.8T 1.5T143.7G91% /APK-archives | lnfs:/nfs/b/tabbycat/ 1.8T 1.5T143.7G91%/backups | lnfs:/nfs/b/tabbycat/ 1.8T 1.5T143.7G91%/tmp/test | | 23:30 [3] (4) root@tabbycat:/usr/users/jamie # l /tmp/test | total 32 | 4 drwxr-x---9 root root 512 Nov 1 07:28 ./ | 0 drwxrwxrwt3 root root 160 Nov 5 23:33 ../ | 4 drwxr-xr-x 20 rootfs rootfs1024 Nov 5 09:23 BASE/ | 4 drwxr-x---2 root root 512 Nov 5 16:35 logs/ | 4 drwxr-x---2 root root 512 Oct 25 11:49 monthly/ | 4 drwxr-x---7 root root 512 Nov 5 16:36 often/ | 4 drwxr-x---5 root root 512 Nov 1 07:49 old/ | 4 drwxr-x---2 root root 512 Oct 29 09:20 partial/ | 4 drwxr-x---4 root root 512 Nov 3 03:35 weekly/ | | 23:30 [3] (5) root@tabbycat:/usr/users/jamie # I'd be more than happy to share my findings/code/ etc. with you, maybe private mail would be better? As a quick 'summary', I use FreeBSD exclusively on my servers etc., but do have 5 Android devices. My achievements with them (not currently complete with all of them) is to give them a decent Unix environment, all running NFS to my home FreeBSD server, sshd, IP6 (FreeBSD server is my IP6 router - it uses tunnelbroker.net to get IP6 over my consumer IP4 only ISP), cron,
Build Fail: r274159
(cd /usr/src/rescue/rescue/../../sbin/fdisk make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/fdisk/ depend make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/fdisk/ fdisk.o geom_mbr_enc.o) cc -O2 -pipe -fno-omit-frame-pointer -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/sbin/fdisk/fdisk.c In file included from /usr/src/sbin/fdisk/fdisk.c:30: /usr/obj/usr/src/tmp/usr/include/sys/disk.h:132:3: error: unknown type name 'off_t' off_t off; ^ 1 error generated. *** Error code 1 Stop. make[6]: stopped in /usr/src/sbin/fdisk *** Error code 1 Stop. make[5]: stopped in /usr/obj/usr/src/rescue/rescue *** Error code 1 Stop. make[4]: stopped in /usr/src/rescue/rescue *** Error code 1 Stop. make[3]: stopped in /usr/src/rescue *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src ^C [1] Done(1) nohup make -DNO_CLEAN buildworld buildkernel make.noc.out 21 borg.lerctr.org /usr/src # borg.lerctr.org /usr/src # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 274159 Node Kind: directory Schedule: normal Last Changed Author: dteske Last Changed Rev: 274159 Last Changed Date: 2014-11-05 19:46:33 -0600 (Wed, 05 Nov 2014) borg.lerctr.org /usr/src # -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Build Fail: r274159
On Nov 5, 2014, at 18:25, Larry Rosenman l...@lerctr.org wrote: (cd /usr/src/rescue/rescue/../../sbin/fdisk make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/fdisk/ depend make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/fdisk/ fdisk.o geom_mbr_enc.o) cc -O2 -pipe -fno-omit-frame-pointer -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/sbin/fdisk/fdisk.c In file included from /usr/src/sbin/fdisk/fdisk.c:30: /usr/obj/usr/src/tmp/usr/include/sys/disk.h:132:3: error: unknown type name 'off_t' off_t off; ^ 1 error generated. *** Error code 1 Probably related to r274154 signature.asc Description: Message signed with OpenPGP using GPGMail
Build failed in Jenkins: FreeBSD_HEAD-tests2 #193
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/193/ -- Started by build flow Build_Image_and_Run_Tests_in_Bhyve_HEAD#190 Building remotely on havoc.ysv.freebsd.org (FreeBSD-10) in workspace https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/ws/ [FreeBSD_HEAD-tests2] $ /bin/sh -xe /tmp/hudson9166051534485122562.sh + sudo python /vm/freebsd-ci/scripts/test/run-tests.py -f /vm/freebsd-ci/scripts/test/config/config.json bhyveload -m 2G -d /net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img vm_test Consoles: userboot FreeBSD/amd64 User boot, Revision 1.1 (rodr...@havoc.ysv.freebsd.org, Tue Oct 21 05:39:14 UTC 2014) |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|Loading /boot/defaults/loader.conf /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\[H[J[7;46H ````[8;46Hs` `.---...--.``` -/[9;46H+o .--` /y:` +.[10;46H yo`:.:o `+-[11;46H y/ -/` -o/[12;46H .- ::/sy+:.[13;46H / `-- /[14;46H`: :`[15;46H`: :`[16;46H / /[17;46H .- -.[18;46H -- -.[19;46H `:` `:`[20;46H .-- `--.[21;46H.---..[25;0H[1;2H __ _ _ [2;2H| | | _ \ / | __ \ [3;2H| |___ _ __ ___ ___ | |_) | (___ | | | |[4;2H| ___| '__/ _ \/ _ \| _ \___ \| | | |[5;2H| | | | | __/ __/| |_) |) | |__| |[6;2H| | | | |||| | | |[7;2H|_| |_| \___|\___||/|_/|_/ [25;0H[10;2H|[11;2H|[12;2H|[13;2H|[14;2H|[15;2H|[16;2H|[17;2H|[18;2H|[19;2H|[20;2H|[21;2H|[10;44H|[11;44H|[12;44H|[13;44H|[14;44H|[15;44H|[16;44H|[17;44H|[18;44H|[19;44H|[20;44H|[21;44H|[9;3H-[22;3H-[9;2H+[22;2H+[9;44H+[22;44H+[25;0H|/-\|/-\|/-\[9;15HWelcome to FreeBSD[11;5H1 [11;6H.[11;8HBoot Multi User [Enter][12;5H2 [12;6H.[12;8HBoot [S]ingle User[13;5H3 [13;6H.[13;8H[Esc]ape to loader prompt[14;5H4 [14;6H.[14;8HReboot[16;5HOptions:[17;5H5 [17;6H.[17;8H[K]ernel: kernel (1 of 2)[18;5H6 [18;6H.[18;8HConfigure Boot [O]ptions...[25;0H[23;4HAutoboot in 9 seconds. [Space] to pause[25;0H[23;4HAutoboot in 8 seconds. [Space] to pause[25;0H[23;4HAutoboot in 7 seconds. [Space] to pause[25;0H[23;4HAutoboot in 6 seconds. [S pace] to pause[25;0H[23;4HAutoboot in 5 seconds. [Space] to pause[25;0H[23;4HAutoboot in 4 seconds. [Space] to pause[25;0H[23;4HAutoboot in 3 seconds. [Space] to pause[25;0H[23;4HAutoboot in 2 seconds. [Space] to pause[25;0H[23;4HAutoboot in 1 seconds. [Space] to pause[25;0H[23;4H [25;0H|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/boot/kernel/kernel text=0x101cd38 /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\ |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/
Re: android bsd connectivity tools etc ?
On Thu, 06 Nov 2014 00:02:59 + Jamie Landeg-Jones ja...@dyslexicfish.net wrote Julian H. Stacey j...@berklix.com wrote: Firstly, if you haven't already, I'd recommend 'Android terminal emulator' and 'hackers keyboard' - both free from the Play store. To be able to create startup scripts without reflashing etc. you must have root, and be able to write the file /system/etc/install_recovery.sh NFS [ AMD] [ SSH] would be ideal for me. I had a look on my Samsung Galaxy Note 3, with Android 4.4.2 kernel 3.4.0, skimmed index of the 182 page pdf, but I dont know how to tell if mine has NFS ? Or how to get it. I have the dropbear ssh client and server. I've not managed to compile them or openssh yet - instead I grabbed the binaries (opened source) from inside one of the free sshd server apps on the play store. One of my newer devices doesn't come with NFS, the others do. You need to find the correct nfs.ko kernel module for your kernel, and/or recompile the linux kernel - both things I've not achieved yet (running FreeBSD and not Linux/Windows makes things harder with no SDK etc.) but all this is part of what I'm investigating at the moment, so it would be great to be able to share notes with someone else sith a FreeBSD mindset. If you have nfs already, the standard mount should work from root: | 23:29 [3] (1) root@tabbycat:/usr/users/jamie # mkdir /tmp/test | 23:29 [3] (2) root@tabbycat:/usr/users/jamie # mount -o nolock,hard,ro lnfs:/nfs/b/tabbycat/ /tmp/test | 23:30 [3] (3) root@tabbycat:/usr/users/jamie # df -h | Filesystem Size Used Available Capacity Mounted on | tmpfs 176.7M 52.0K176.7M 0%/dev | devpts 0 0 0 0%/dev/pts | proc 0 0 0 0%/proc | sysfs 0 0 0 0%/sys | none 0 0 0 0%/acct | tmpfs 176.7M 0176.7M 0% /mnt/asec | tmpfs 176.7M 0176.7M 0% /mnt/obb | /dev/block/nandd 1007.9M282.6M725.3M28% /system | /dev/block/nande 1007.9M137.4M870.5M14% /data | /dev/block/nandh 252.0M 4.3M247.7M 2% /cache | /dev/block/nandd 1007.9M282.6M725.3M28%/bin | hidden 0 0 0 0% /system/.bin_mount | tmpfs 128.0M 8.0K128.0M 0%/tmp | /dev/block/nandj2 718.0M404.7M313.3M56% /usr | /dev/block/nandj3 100.4M 19.3M 81.1M19%/var | tmpfs 1.0M 4.0K 1020.0K 0%/var/run | /dev/block/mmcblk0p2 18.6G 1.3G 16.4G 7%/data2 | /dev/block/vold/93:76 23.5M 8.0K 23.5M 0%/mnt/extsd | /dev/block/vold/179:3 10.5G 5.5G 5.0G52%/mnt/sdcard | /dev/block/vold/179:3 10.5G 5.5G 5.0G52% /mnt/secure/asec | tmpfs 0 0 0 0%/mnt/sdcard/.android_secure | lnfs:/nfs/j/Misc/ 1.8T 1.5T143.7G91%/mnt/sdcard/Misc | lnfs:/nfs/j/Music/ 1.8T 1.5T143.7G91%/mnt/sdcard/Music/lapcat | lnfs:/nfs/j/Videos/ 1.8T 1.5T143.7G91%/mnt/sdcard/Videos/lapcat | lnfs:/nfs/j/Pictures/ 1.8T 1.5T143.7G91% /mnt/sdcard/Pictures/lapcat | lnfs:/nfs/APK-archives/ 1.8T 1.5T 143.7G91%/APK-archives | lnfs:/nfs/b/tabbycat/ 1.8T 1.5T143.7G91%/backups | lnfs:/nfs/b/tabbycat/ 1.8T 1.5T143.7G91%/tmp/test | | 23:30 [3] (4) root@tabbycat:/usr/users/jamie # l /tmp/test | total 32 | 4 drwxr-x---9 root root 512 Nov 1 07:28 ./ | 0 drwxrwxrwt3 root root 160 Nov 5 23:33 ../ | 4 drwxr-xr-x 20 rootfs rootfs1024 Nov 5 09:23 BASE/ | 4 drwxr-x---2 root root 512 Nov 5 16:35 logs/ | 4 drwxr-x---2 root root 512 Oct 25 11:49 monthly/ | 4 drwxr-x---7 root root 512 Nov 5 16:36 often/ | 4 drwxr-x---5 root root 512 Nov 1 07:49 old/ | 4 drwxr-x---2 root root 512 Oct 29 09:20 partial/ | 4 drwxr-x---4 root root 512 Nov 3 03:35 weekly/ | | 23:30 [3] (5) root@tabbycat:/usr/users/jamie # I'd be more than happy to share my findings/code/ etc. with you, maybe private mail would be better? As a quick 'summary', I use FreeBSD exclusively on my servers etc., but do have 5 Android devices. My achievements with them (not currently complete with all of them) is to give them a decent Unix environment,
Build failed in Jenkins: FreeBSD_HEAD #1780
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/1780/changes Changes: [gjb] Bump __FreeBSD_version after SA-14:23, SA-14:24, SA-14:25. Approved by:re (implicit) Sponsored by: The FreeBSD Foundation [dteske] Upon second-thought (following r274144), remove spurious (unused) line-noise (libdialog never lived in lib/ -- but rather the noise came from translating a comment that was introduced 16 years ago via r40306; translation from comment to code occurred via r267511). MFC after: 3 days Reviewed by:ngie X-MFC-to: stable/10 [mav] Add to CTL support for logical block provisioning threshold notifications. For ZVOL-backed LUNs this allows to inform initiators if storage's used or available spaces get above/below the configured thresholds. MFC after: 2 weeks Sponsored by: iXsystems, Inc. -- [...truncated 139428 lines...] --- gnu.all__D --- --- groff_www.7 --- Making groff_www.7 from https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/gnu/usr.bin/groff/tmac/../../../../contrib/groff/tmac/groff_www.man --- lib.all__D --- --- h_stpncpy --- cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -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-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -o h_stpncpy h_stpncpy.o (cd https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/libc/tests/ssp make -f https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/libc/tests/ssp/Makefile _RECURSING_PROGS= SUBDIR= PROG=h_strcat DEPENDFILE=.depend.h_strcat .MAKE.DEPENDFILE=.depend.h_strcat ) --- gnu.all__D --- --- groff_ms.7.gz --- gzip -cn groff_ms.7 groff_ms.7.gz --- groff_man.7.gz --- --- lib.all__D --- --- h_strcat.o --- --- gnu.all__D --- gzip -cn groff_man.7 groff_man.7.gz --- lib.all__D --- cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -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-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/contrib/netbsd-tests/lib/libc/ssp/h_strcat.c --- gnu.all__D --- --- groff_me.7.gz --- gzip -cn groff_me.7 groff_me.7.gz --- groff_mdoc.7.gz --- gzip -cn groff_mdoc.7 groff_mdoc.7.gz --- lib.all__D --- --- h_strcat --- cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -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-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -o h_strcat h_strcat.o --- gnu.all__D --- --- groff_trace.7.gz --- gzip -cn groff_trace.7 groff_trace.7.gz --- lib.all__D --- (cd https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/libc/tests/ssp make -f https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/libc/tests/ssp/Makefile _RECURSING_PROGS= SUBDIR= PROG=h_strcpy DEPENDFILE=.depend.h_strcpy .MAKE.DEPENDFILE=.depend.h_strcpy ) --- gnu.all__D --- --- groff_www.7.gz --- gzip -cn groff_www.7 groff_www.7.gz --- all_subdir_rcs --- === gnu/usr.bin/rcs (all) --- _sub.all --- === gnu/usr.bin/rcs/lib (all) --- lib.all__D --- --- h_strcpy.o --- cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -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-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/contrib/netbsd-tests/lib/libc/ssp/h_strcpy.c --- h_strcpy --- cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -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-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -o h_strcpy h_strcpy.o --- rescue.all__D --- --- geom_bsd_enc.o --- cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
