Re: issues w/ installing stuff multiple times...
Brooks Davis wrote this message on Mon, Oct 27, 2014 at 22:10 +:
> On Mon, Oct 27, 2014 at 02:55:09PM -0700, Garrett Cooper wrote:
> >
> > > On Oct 27, 2014, at 14:50, John-Mark Gurney wrote:
> > >
> > > There are issues w/ installing tests where the test files get installed
> > > multiple times.
> > >
> > > To reproduce this, use the following steps:
> > > make installworld -j 8 DESTDIR= -DNO_ROOT
> > >
> > > Once you have done the above, in there will be the file
> > > METALOG, run:
> > > grep -v type=dir /METALOG | awk '{ print $1 }' | sort |
> > > uniq -d
> > >
> > > This will print out the current list if files that get installed multiple
> > > times
> > >
> > > Currently, it looks like all the tests subdirs are installed a second
> > > time...
> > >
> > > Could someone look at making it so that they don't get installed
> > > multiple times?
> >
> > Hi jmg!
> > I have a patch out for this that I need to commit today. Thank you for
> > the reminder.
>
> Great to hear this will be fixed. Once we've fixed them all, it would be
> really good to have a test in Jenkins looking out for new duplicate files
> since they are always bugs.
I agree I've given the meat of the test above... Any output from
that pipeline means that there is a bug...
Also, it'd be good if Jenkins would do an installworld in addition to
a buildworld... We've recently had breakages that are only uncovered
when installworld is done...
Current items (other than tests) installed multiple times:
/etc/mail/mailer.conf
/usr/libdata/pkgconfig/*
various man pages: nvlist_freef, various loader
So, shouldn't be too much work to knock the rest out... If someone
adds the jenkins test, I'll fix the remaining issues (others are free
to fix these too)...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
___
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: Mounting ZFS with error 5 failed, since r271963 callout convert
On 10/27/2014 22:29, Ryan Stone wrote: On Mon, Oct 27, 2014 at 4:21 PM, Michael Schmiedgen wrote: Hi List, my ZFS does not mount. I bifurcated to r271963 that does not work anymore. The commit seems not directly related to ZFS, but is rather a conversion from timeout(9) to callout(9). After booting the kernel it drops to the mount prompt, stating that ZFS cannot be mounted because of 'error 5'. Any hints? Can I provide some more information? Thanks, Michael The changes to the 3 files there look to be independent, so can you narrow this down further by applying the patch to only a single file? Of those three only ACPI looks like it could affect ZFS or disks, so this will be the patch to try first: https://svnweb.freebsd.org/base/head/sys/dev/acpica/acpi.c?view=patch&r1=271889&r2=271963&pathrev=271963 If you can get a verbose boot log from the machine that would be helpful, but you'd need a serial console to capture that. I applied first acpi.c, then atkbd.c and at last kern_cons.c that triggered the error. https://svnweb.freebsd.org/base/head/sys/kern/kern_cons.c?r1=271963&r2=271962&pathrev=271963 In previous months I had already the same problem with ZFS if nvidia driver was loaded via /boot/loader.conf. It triggered the same error. So I loaded the driver on demand with kldload after login and everything (X + stuff) worked fine. Very strange... Does anyone have a clue what is going on here? Thanks, Michael ___ 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: issues w/ installing stuff multiple times...
On Mon, Oct 27, 2014 at 02:55:09PM -0700, Garrett Cooper wrote:
>
> > On Oct 27, 2014, at 14:50, John-Mark Gurney wrote:
> >
> > There are issues w/ installing tests where the test files get installed
> > multiple times.
> >
> > To reproduce this, use the following steps:
> > make installworld -j 8 DESTDIR= -DNO_ROOT
> >
> > Once you have done the above, in there will be the file
> > METALOG, run:
> > grep -v type=dir /METALOG | awk '{ print $1 }' | sort | uniq
> > -d
> >
> > This will print out the current list if files that get installed multiple
> > times
> >
> > Currently, it looks like all the tests subdirs are installed a second
> > time...
> >
> > Could someone look at making it so that they don't get installed
> > multiple times?
>
> Hi jmg!
> I have a patch out for this that I need to commit today. Thank you for
> the reminder.
Great to hear this will be fixed. Once we've fixed them all, it would be
really good to have a test in Jenkins looking out for new duplicate files
since they are always bugs.
-- Brooks
pgp2b72jek4U3.pgp
Description: PGP signature
Re: issues w/ installing stuff multiple times...
> On Oct 27, 2014, at 14:50, John-Mark Gurney wrote:
>
> There are issues w/ installing tests where the test files get installed
> multiple times.
>
> To reproduce this, use the following steps:
> make installworld -j 8 DESTDIR= -DNO_ROOT
>
> Once you have done the above, in there will be the file
> METALOG, run:
> grep -v type=dir /METALOG | awk '{ print $1 }' | sort | uniq -d
>
> This will print out the current list if files that get installed multiple
> times
>
> Currently, it looks like all the tests subdirs are installed a second
> time...
>
> Could someone look at making it so that they don't get installed
> multiple times?
Hi jmg!
I have a patch out for this that I need to commit today. Thank you for the
reminder.
Cheers!
___
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"
issues w/ installing stuff multiple times...
There are issues w/ installing tests where the test files get installed
multiple times.
To reproduce this, use the following steps:
make installworld -j 8 DESTDIR= -DNO_ROOT
Once you have done the above, in there will be the file
METALOG, run:
grep -v type=dir /METALOG | awk '{ print $1 }' | sort | uniq -d
This will print out the current list if files that get installed multiple
times
Currently, it looks like all the tests subdirs are installed a second
time...
Could someone look at making it so that they don't get installed
multiple times?
Thanks.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
___
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: Mounting ZFS with error 5 failed, since r271963 callout convert
On Mon, Oct 27, 2014 at 4:21 PM, Michael Schmiedgen wrote: > Hi List, > > my ZFS does not mount. I bifurcated to r271963 that > does not work anymore. The commit seems not directly > related to ZFS, but is rather a conversion from timeout(9) > to callout(9). > > After booting the kernel it drops to the mount prompt, > stating that ZFS cannot be mounted because of 'error 5'. > > Any hints? Can I provide some more information? > > Thanks, > Michael The changes to the 3 files there look to be independent, so can you narrow this down further by applying the patch to only a single file? Of those three only ACPI looks like it could affect ZFS or disks, so this will be the patch to try first: https://svnweb.freebsd.org/base/head/sys/dev/acpica/acpi.c?view=patch&r1=271889&r2=271963&pathrev=271963 If you can get a verbose boot log from the machine that would be helpful, but you'd need a serial console to capture that. ___ 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"
Mounting ZFS with error 5 failed, since r271963 callout convert
Hi List, my ZFS does not mount. I bifurcated to r271963 that does not work anymore. The commit seems not directly related to ZFS, but is rather a conversion from timeout(9) to callout(9). After booting the kernel it drops to the mount prompt, stating that ZFS cannot be mounted because of 'error 5'. Any hints? Can I provide some more information? Thanks, Michael ___ 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: Ver 2 of the patch [was: Re: i915 driver update testing]
This is Haswell, right? Didn't Kib say "not interested in haswell testing yet" ? -adrian On 26 October 2014 14:02, Chagin Dmitry wrote: > On Thu, Oct 23, 2014 at 10:03:29PM +0300, Konstantin Belousov wrote: >> On Wed, Oct 22, 2014 at 03:59:23PM -0400, Adam McDougall wrote: >> > On 10/22/2014 08:26, Konstantin Belousov wrote: >> >> Use https://www.kib.kiev.ua/kib/drm/i915.6.patch. I already have one >> private report of the patch worked from person who got the same panic >> in iicbb. > > Hi, Kostik! > > i915.6.patch & i7-4700. > > > FreeBSD dchagin.static.corbina.net 11.0-CURRENT FreeBSD 11.0-CURRENT #93 > r273708+3ca71ce(lemul)-dirty: Sun Oct 26 23:38:47 MSK 2014 > r...@dchagin.static.corbina.net:/home/rootobj/home/dchagin/head/sys/YOY amd64 > > Unread portion of the kernel message buffer: > FDI TX state assertion failure (expected off, current on) > error: [drm:pid840:assert_fdi_rx] *ERROR* Attempting to enable FDI_RX on > Haswell pipe > 0 > error: [drm:pid840:assert_fdi_rx] *ERROR* Attempting to enable FDI_RX on > Haswell pipe > 0 > drmn1: taking over the fictitious range 0xe000-0xf000 > info: [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off > info: [drm] GMBUS [gmbus dpb] timed out, falling back to bit banging on pin 5 > panic: _sx_xlock_hard: recursed on non-recursive sx gmbus @ > /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:370 > > cpuid = 2 > Uptime: 27s > Dumping 582 out of 11954 MB:..3%..11%..22%..31%..42%..53%..61%..72%..83%..91% > > Reading symbols from /boot/kernel/acpi_ibm.ko.symbols...done. > Loaded symbols for /boot/kernel/acpi_ibm.ko.symbols > Reading symbols from /boot/kernel/i915kms.ko.symbols...done. > Loaded symbols for /boot/kernel/i915kms.ko.symbols > Reading symbols from /boot/kernel/drm2.ko.symbols...done. > Loaded symbols for /boot/kernel/drm2.ko.symbols > #0 doadump (textdump=1) at /home/dchagin/head/sys/kern/kern_shutdown.c:261 > 261 dumptid = curthread->td_tid; > (kgdb) #0 doadump (textdump=1) at > /home/dchagin/head/sys/kern/kern_shutdown.c:261 > #1 0x80691a75 in kern_reboot (howto=260) > at /home/dchagin/head/sys/kern/kern_shutdown.c:447 > #2 0x80692670 in vpanic ( > fmt=0x80c763b9 "_sx_xlock_hard: recursed on non-recursive sx %s @ > %s:%d\n", ap=0xfe033c750d60) > at /home/dchagin/head/sys/kern/kern_shutdown.c:746 > #3 0x8069204c in kassert_panic ( > fmt=0x80c763b9 "_sx_xlock_hard: recursed on non-recursive sx %s @ > %s:%d\n") at /home/dchagin/head/sys/kern/kern_shutdown.c:634 > #4 0x806a09b0 in _sx_xlock_hard (sx=0xfe00039480e8, > tid=18446735277793944768, opts=0, > file=0x8166d4e7 > "/home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c", > line=370) > at /home/dchagin/head/sys/kern/kern_sx.c:519 > #5 0x8069f9ed in __sx_xlock (sx=0xfe00039480e8, > td=0xf8000a9324c0, opts=0, > file=0x8166d4e7 > "/home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c", > line=370) at sx.h:154 > #6 0x8069f893 in _sx_xlock (sx=0xfe00039480e8, opts=0, > file=0x8166d4e7 > "/home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c", > line=370) > at /home/dchagin/head/sys/kern/kern_sx.c:311 > #7 0x816464e6 in intel_gmbus_transfer (idev=0xf80080a99900, > msgs=0xfe033c7511e0, nmsgs=2) > at > /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:370 > #8 0x81646ac7 in intel_gmbus_transfer (idev=, > msgs=, nmsgs=) > at iicbus_if.h:131 > #9 0x8044a445 in IICBUS_TRANSFER (dev=0xf80080a99900, > msgs=0xfe033c7511e0, nmsgs=2) at iicbus_if.h:131 > #10 0x8044a39b in iicbus_transfer (bus=0xf80080a99800, > msgs=0xfe033c7511e0, nmsgs=2) > at /home/dchagin/head/sys/dev/iicbus/iiconf.c:355 > #11 0x8169309d in drm_do_probe_ddc_edid (adapter=0xf80080a99800, > buf=0xfe033c751257 ""y", block=, len=1) > at > /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_edid.c:290 > #12 0x816909bc in drm_get_edid (connector=0xf80080826c00, > adapter=0xf80080a99800) > at > /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_edid.c:388 > #13 0x81645690 in intel_hdmi_detect (connector=0xf80080826c00, > force=) > at > /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_hdmi.c:465 > #14 0x8168adf5 in drm_helper_probe_single_connector_modes ( > connector=0xf80080826c00, maxX=8192, maxY=8192) > at > /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_crtc_helper.c:135 > #15 0x8169387f in drm_fb_helper_initial_config ( > fb_helper=0xf8008093b200, bpp_sel=32) > at > /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_fb_helper.c:1164 > #16 0xff
Re: SVN r273734 breaks i386 compilation
Hi! > The updates to dd cause this on an i386 .. Yes, I'm sorry. Change reverted. -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ 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"
SVN r273734 breaks i386 compilation
The updates to dd cause this on an i386 .. ===> bin/dd (all) cc -O2 -pipe -march=pentium4 -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 -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/bin/dd/args.c /usr/src/bin/dd/args.c:192:43: error: format specifies type 'intmax_t' (aka 'long long') but the argument has type 'int' [-Werror,-Wformat] errx(1, "bs must be between 1 and %jd", SSIZE_MAX); ~~~ ^ %d /usr/obj/usr/src/tmp/usr/include/sys/limits.h:72:19: note: expanded from macro 'SSIZE_MAX' #define SSIZE_MAX __SSIZE_MAX /* max value for an ssize_t */ ^~~ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:86:21: note: expanded from macro '__SSIZE_MAX' #define __SSIZE_MAX __INT_MAX ^ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:57:19: note: expanded from macro '__INT_MAX' #define __INT_MAX 0x7fff /* max value for an int */ ^~ /usr/src/bin/dd/args.c:201:44: error: format specifies type 'intmax_t' (aka 'long long') but the argument has type 'int' [-Werror,-Wformat] errx(1, "cbs must be between 1 and %jd", SSIZE_MAX); ~~~ ^ %d /usr/obj/usr/src/tmp/usr/include/sys/limits.h:72:19: note: expanded from macro 'SSIZE_MAX' #define SSIZE_MAX __SSIZE_MAX /* max value for an ssize_t */ ^~~ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:86:21: note: expanded from macro '__SSIZE_MAX' #define __SSIZE_MAX __INT_MAX ^ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:57:19: note: expanded from macro '__INT_MAX' #define __INT_MAX 0x7fff /* max value for an int */ ^~ /usr/src/bin/dd/args.c:221:46: error: format specifies type 'uintmax_t' (aka 'unsigned long long') but the argument has type 'unsigned int' [-Werror,-Wformat] errx(1, "files must be between 1 and %ju", SIZE_MAX); ~~~ ^~~~ %u /usr/obj/usr/src/tmp/usr/include/x86/_stdint.h:180:18: note: expanded from macro 'SIZE_MAX' #define SIZE_MAXUINT32_MAX ^~ /usr/obj/usr/src/tmp/usr/include/x86/_stdint.h:82:20: note: expanded from macro 'UINT32_MAX' #define UINT32_MAX 0xU ^~~ /usr/src/bin/dd/args.c:241:45: error: format specifies type 'uintmax_t' (aka 'unsigned long long') but the argument has type 'int' [-Werror,-Wformat] errx(1, "ibs must be between 1 and %ju", SSIZE_MAX); ~~~ ^ %d /usr/obj/usr/src/tmp/usr/include/sys/limits.h:72:19: note: expanded from macro 'SSIZE_MAX' #define SSIZE_MAX __SSIZE_MAX /* max value for an ssize_t */ ^~~ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:86:21: note: expanded from macro '__SSIZE_MAX' #define __SSIZE_MAX __INT_MAX ^ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:57:19: note: expanded from macro '__INT_MAX' #define __INT_MAX 0x7fff /* max value for an int */ ^~ /usr/src/bin/dd/args.c:259:45: error: format specifies type 'intmax_t' (aka 'long long') but the argument has type 'int' [-Werror,-Wformat] errx(1, "obs must be between 1 and %jd", SSIZE_MAX); ~~~ ^ %d /usr/obj/usr/src/tmp/usr/include/sys/limits.h:72:19: note: expanded from macro 'SSIZE_MAX' #define SSIZE_MAX __SSIZE_MAX /* max value for an ssize_t */ ^~~ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:86:21: note: expanded from macro '__SSIZE_MAX' #define __SSIZE_MAX __INT_MAX ^ /usr/obj/usr/src/tmp/usr/include/x86/_limits.h:57:19: note: expanded from macro '__INT_MAX' #define __INT_MAX 0x7fff /* max value for an int */ ^~ 5 errors generated. *** Error code 1 Stop. make[4]: stopped in /usr/src/bin/dd *** Error code 1 signature.asc Descrip
HEADS UP: Enabling vt(4) by default
Hello! vt(4) is fairly usable today and we would like to enable it by default in one week (Monday November 3, 2014). For those who never used vt(4), here are its benefits: o It supports Unicode and double-width characters. o It supports the kernel video drivers (KMS) and allows to switch to and from an X session. o It supports UEFI. Of course, there are still issues. A list is available on the wiki: https://wiki.freebsd.org/Newcons#Known_Issues And in Bugzilla: https://bugs.freebsd.org/bugzilla/buglist.cgi?resolution=---&keywords=vt Here's a summary of the major problems: o The keymap selection in bsdconfig(8), used by the installer, has not been updated to use the vt keymap list instead of the syscons one. o Only UTF-8 character maps. o The console resolution is currently fixed to the value chosen by the underlying graphics driver. o No support for several vidcontrol(1) features. o Graphics features such as mouse pointers and font setting work only in VGA graphics mode, not in VGA text mode. The goal is to fix remaining bugs in time before FreeBSD 11.0 release cycle. If you want to switch back to syscons, you may use the following line in /boot/loader.conf: kern.vty=sc And please tell us why! :) -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: ssh None cipher
On Sun, Oct 19, 2014 at 10:35 AM, Freddie Cash wrote: > On Oct 19, 2014 12:46 AM, "John-Mark Gurney" wrote: > > > > Freddie Cash wrote this message on Sat, Oct 18, 2014 at 10:21 -0700: > > > On Oct 18, 2014 3:54 AM, "Mark Martinec" > > > > wrote: > > > > > > > > If the purpose of having a none cipher is to have a fast > > > > file transfer, then one should be using sysutils/bbcp > > > > for that purposes. Uses ssd for authentication, and > > > > opens unencrypted channel(s) for the actual data transfer. > > > > It's also very fast, can use multiple TCP streams. > > > > > > That's an interesting alternative to rsync, scp, and ftp, but doesn't > help > > > with zfs send/recv which is where the none cipher really shines. > > > > > > Without the none cipher, SSH becomes the bottleneck limiting transfers > to > > > around 400 Mbps on a gigabit LAN. With the none cipher, the network > becomes > > > the bottleneck limiting transfers to around 920 Mbps on the same > gigabit > > > LAN. > > > > > > This is between two 8-core AMD Opteron 6200 systems using igb(4) NICs. > > > > Are you running on HEAD or possibly 10.x (I believe we have OpenSSL > > 1.0.x on 10.x)? > > Nope, 9.2. And I don't think the 6200 series Opterons have AES-NI. > Correction, the AMD Opteron 6200-series of CPUs to support AES-NI. However, these storage boxes use AMD Opteron 6128 CPUs. :( They do not support AES-NI. AES-based ciphers are extremely slow on these systems; the multithreaded AES-based ciphers are better, but nowhere near what the NONE cipher provides. :) sysutils/bbcp is interesting as an alternative, but it's a lot more complex than just enabling NONE in OpenSSH. -- Freddie Cash fjwc...@gmail.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"
Looking for libvgl users
vgl(3) is a graphics library for syscons(4) that provides some basic graphics operations (e.g. some mode setting, bitmaps, boxes, ellipses). Right now it does not support the newer vt(4) console. In order to help determine the priority of a porting effort to add vt(4) support I'd like to better understand where vgl is being used now. I'd be interested in hearing about both open source software using vgl as well as proprietary or internal applications. So if you're using vgl I'd appreciate a follow up (in private is fine) with a brief description of your use case. Thanks, Ed ___ 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"
emulators/virtualbox-ose: compilation on CURRENT fails due to: tstVMStructRC: 1: Syntax error: "(" unexpected
Compiling emulators/virtualbox-ose on a freshly installed CURRENT
(FreeBSD 11.0-CURRENT #0 r273719: Mon Oct 27 07:59:12 CET 2014 amd64)
results in the below shown error.
I also tried to install the package on CURRENT via pkg install, but
this results in a 32-Bit VirtualBox only - which is inacceptable.
I have running emulators/virtualbox-ose on several other CURRENT
machines, but most of those boxes are "grown", that means, they got
CURRENT months ago and are maintained as usual (buildworld/portmaster).
This box has been installed a couple of weeks ago and is successfully
rejecting compilation of port emulators/virtualbox-ose, although I
already updated the ports tree and did successfully a portmaster -R
-fd /emulators/virtualbox-ose.
Since I use some non-standard optimization flags in /etc/src.conf
and /etc/make.conf (-O3 and CPUTYPE=native instead of plain -O and
outdated architectural compatibilities), I switched back to the FreeBSD
vanilla standard - but still the same. I can not imagine that the CPU
of that specific box could be the culprit:
dmesg output:
CPU: Intel(R) Core(TM)
i5-3470 CPU @ 3.20GHz (3192.82-MHz K8-class CPU) Origin="GenuineIntel"
Id=0x306a9 Family=0x6 Model=0x3a Stepping=9
Features=0xbfebfbff
Features2=0x7fbae3ff
AMD Features=0x28100800 AMD Features2=0x1
Structured Extended Features=0x281
XSAVE Features=0x1
VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID
TSC: P-state invariant, performance statistics
real memory = 9107931136 (8686 MB)
avail memory = 8147902464 (7770 MB)
I have also problems compiling the port on a newly setup laptop (Intel
i5-4200M CPU/Haswell), CURRENT as of the same date as reported here.
The failure is the same. It seems, that on CURRENT installations as of
a certain date not far in the past, the port fails to recompile
successfully.
The error is:
[...]
kBuild: Generating tstVMStructSize
-
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/bin/tstVMStructRC:
1: Syntax error: "(" unexpected kmk: ***
[/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h]
Error 2 kmk: *** Deleting file
`/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h'
kmk: *** Waiting for unfinished jobs filesplitter: Out of 144
files: 144 rewritten, 0 unchanged.
(/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VirtualBox/include)
kmk_builtin_append
"/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VirtualBox/include/COMWrappers"
kmk: *** Exiting with status 2 *** Error code 2
___
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: Some NFS server V4 questions
Kostik wrote: > On Sun, Oct 26, 2014 at 06:42:29PM -0400, Rick Macklem wrote: > > Worked fine for me. Do you mind if I commit this or would you > > rather > > do it. > > I committed the change as r273727. > > One issue with the commit is the specified MFC. The change will > compile > on stable/10, but as far as I remember the state of sysctl patches, > it is nop on 10. It can be made functional with more patches to > nfsserver, but I prefer for the functionality to wait the needed MFCs > in > kern_sysctl.c. Righto. Thanks. I think the workaround of "build a kernel with options NFSD" (which most GENERIC kernels have) will be sufficient for now. Thanks again, rick ps: Now I know what TUN means;-) > ___ > 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"
Re: junior kernel tasks
El 25/10/2014 22:46, "Mateusz Guzik" escribió: > > Hello, > > In short, nice kernel tasks people with C language skills can do in few > evenings. It would be nice if this page lists other junior tasks in base, documentation, etc, not just the kernel. Cheers. > > https://wiki.freebsd.org/JuniorJobs > > It is assumed you know how to obtain sources and build the kernel. > > What you can get in return: > - your own code in FreeBSD tree > - eternal glory [1] > - fun [2] > > If you are not interested, but know someone who does, please pass it > down. > > [1] - not really, no > [2] - well, I guess that's subjective, so that's not a "no" > > Cheers, > -- > Mateusz Guzik > ___ > freebsd-hack...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-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"
Re: ZFS: i/o error - all block copies unavailable #2
Unfortunatelly it changed nothing. Still same error. I also did try grub2, but without success. > On 23 Oct 2014, at 13:12, Beeblebrox wrote: > > You might want to try from the mfsbsd.iso environment, > 1. Import and mount the zpool you want to boot from > 2. Copy /boot/zfs/zpool.cache to /mnt/boot/zfs/ (over-write existing > zpool.cache file) > 3. Edit /mnt/boot/loader.conf and add any of these that you don't already > have: > zfs_load="YES" > opensolaris_load="YES" > vfs.root.mountfrom="zfs:zroot_name" > zpool_cache_load="YES" > zpool_cache_type="/boot/zfs/zpool.cache" > zpool_cache_name="/boot/zfs/zpool.cache" > > Might be worth a try. > > > > - > FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/ZFS-i-o-error-all-block-copies-unavailable-2-tp5958692p5958899.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" ___ 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: Some NFS server V4 questions
On Sun, Oct 26, 2014 at 06:42:29PM -0400, Rick Macklem wrote: > Worked fine for me. Do you mind if I commit this or would you rather > do it. I committed the change as r273727. One issue with the commit is the specified MFC. The change will compile on stable/10, but as far as I remember the state of sysctl patches, it is nop on 10. It can be made functional with more patches to nfsserver, but I prefer for the functionality to wait the needed MFCs in kern_sysctl.c. ___ 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"
