Re: MFC of Revision 261913
Oliver Pinter oliver.p...@gmail.com writes: Can you merge back the r261913 commit to stable/10 or is this a POLA violation? It needs to be accompanied by r264964, and you should ask jmg@ about merging r262945 and r263218 as well. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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
wbem, cim and instrumentation
One thing I feel FreeBSD always ignored is instrumentation frameworks. I am talking about wbem, cim model and implementation like OpenPegasus. Why is that? I ported OpenPegasus to work in FreeBSD with few patches. However, of course without providers a wbem doesn't go far. I started to see how to shape providers for freebsd at: github.com/brunolauze/openpegasus-providers my openpegasus port is at: github.com/brunolauze/freebsd-ports/tree/master/net-mgmt/openpegasus Apple ships a wbem Microsoft ships a wbem / non-standard RedHat ships it. Suse ships it. z/OS ships it. Ubuntu and distro-like ships it. And Solaris does also. Why not us? The advantage outside of this idea is better coding technique and design to expose API first and utility based on those APIs. if any utility can be used as API, this discard the need for application to use system() or popen() to execute shell code to accomplish system tasks, which is really bad but widely widespread in lack of good API exposure of those utilities. This reduce a lot of error with changes in utilities switches, etc. and mitigate security risks. Wouldn't it be great to query FreeBSD with queries like: select * from UNIX_DiskDrive where Storage_Capacity 1000 or select * from UNIX_SCSIController WHERE LastErrorCode 0 Anyway, this is just to talk, let me know your opinions! ___ 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: wbem, cim and instrumentation
On Wed, 2014-05-07 at 08:39 -0400, Bruno Lauzé wrote: One thing I feel FreeBSD always ignored is instrumentation frameworks. I am talking about wbem, cim model and implementation like OpenPegasus. Why is that? I ported OpenPegasus to work in FreeBSD with few patches. However, of course without providers a wbem doesn't go far. I started to see how to shape providers for freebsd at: github.com/brunolauze/openpegasus-providers my openpegasus port is at: github.com/brunolauze/freebsd-ports/tree/master/net-mgmt/openpegasus Apple ships a wbem Microsoft ships a wbem / non-standard RedHat ships it. Suse ships it. z/OS ships it. Ubuntu and distro-like ships it. And Solaris does also. Why not us? The advantage outside of this idea is better coding technique and design to expose API first and utility based on those APIs. if any utility can be used as API, this discard the need for application to use system() or popen() to execute shell code to accomplish system tasks, which is really bad but widely widespread in lack of good API exposure of those utilities. This reduce a lot of error with changes in utilities switches, etc. and mitigate security risks. Wouldn't it be great to query FreeBSD with queries like: select * from UNIX_DiskDrive where Storage_Capacity 1000 or select * from UNIX_SCSIController WHERE LastErrorCode 0 Anyway, this is just to talk, let me know your opinions! Are you going to propose updates/new ports for these tools? sean ___ 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: wbem, cim and instrumentation
Hi! One thing I feel FreeBSD always ignored is instrumentation frameworks. I am talking about wbem, cim model and implementation like OpenPegasus. Why is that? I ported OpenPegasus to work in FreeBSD with few patches. github.com/brunolauze/openpegasus-providers my openpegasus port is at: github.com/brunolauze/freebsd-ports/tree/master/net-mgmt/openpegasus So, getting this committed to FreeBSD ports is your goal ? Why not us? Dunno 8-} Anyway, this is just to talk, let me know your opinions! I'll have a look. Not soon, not fast, but I'll have a look at it. -- 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
Fwd: New /dev/random code for review please.
Hi Folks, Please could the wisdom-of-crowds apply its collective attention to this? Thanks! M Begin forwarded message: From: Mark R V Murray m...@grondar.org Subject: New /dev/random code for review please. Date: 4 May 2014 18:28:43 BST To: sect...@freebsd.org Team sect...@freebsd.org Content-Type: multipart/signed; boundary=Apple-Mail=_E0FAF9BA-F43A-41EC-ADF7-C7F66942DC33; protocol=application/pgp-signature; micalg=pgp-sha512 X-Smtp-Server: gromit.grondar.org:grondar X-Universally-Unique-Identifier: 57DA4E05-F926-490F-811D-27C027A43800 Message-Id: 64478e8f-ed98-43c2-99bc-167356d3e...@grondar.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Hi guys I’m now about ready to start the job of merging the revamped /dev/random gubbins over to CURRENT from a project branch. The project branch is svn://svn.freebsd.org/base/projects/random_number_generator Not all of the above branch is to be merged right now; the UMA_ALLOC harvester bit will NOT be merged. In follow-up discussions, I will work out how to do this properly. Right now, that code works, but will no doubt piss off RWatson and company for messing up the carefully optimised slab allocator! :-) In the first merge, very little change should be observed. ‘sysctl kern.random’ will look different as the harvesting has been slightly generalised. Yarrow will still be used, but Fortuna will be available as an alternative. Automatic startup due to probing entropy is tested and more-or-less trusted (analysis of numbers to form part of a more academic study). The code is much simplified, and use of overly complex data structures has been rewritten. I request review and comments please, with a view to merging this to CURRENT. Thanks! M -- Mark R V Murray -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
/usr/src: svn status: svn: E200030: sqlite[S1]: near 1: syntax error
I get this weird error in /usr/src with the port devel/subversion: root@thor: [ports] svn st svn: E200030: sqlite[S1]: near 1: syntax error Using /bin/svn everything is clear. What happened here? OS is FreeBSD 11.0-CURRENT #0 r265433: Tue May 6 13:37:15 CEST 2014 amd64 Regards, Oliver signature.asc Description: PGP signature
New and exciting panic, possibly re(4)
While screwing around with comcast, I can trivially get this panic out of my desktop machine, and am very confused. It seems to happen on link change up/down events. I'm running 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r265280M. I don't have any direct evidence that this is re(4), just a hunch from some discussions in clusteradm@ This can happen when reconnecting my modem or simply issues a netif restart. Fatal trap 9: general protection fault while in kernel mode cpuid = 5; apic id = 15 instruction pointer = 0x20:0x80a4429e stack pointer = 0x28:0xfe046a7f5530 frame pointer = 0x28:0xfe046a7f55d0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1306 (ifconfig) trap number = 9 panic: general protection fault cpuid = 5 KDB: stack backtrace: #0 0x80998510 at kdb_backtrace+0x60 #1 0x80959d05 at panic+0x155 #2 0x80d9f2ff at trap_fatal+0x38f #3 0x80d9ef5d at trap+0x74d #4 0x80d82282 at calltrap+0x8 #5 0x80aa0aa1 at in_ifadownkill+0xd1 #6 0x80a412f0 at rn_walktree+0x80 #7 0x80aa0942 at in_ifadown+0xc2 #8 0x80a95591 at in_difaddr_ioctl+0x3a1 #9 0x80a94763 at in_control+0x463 #10 0x80a3010c at ifioctl+0x145c #11 0x809b1a5d at kern_ioctl+0x3cd #12 0x809b163c at sys_ioctl+0x13c #13 0x80d9fd1b at amd64_syscall+0x3fb #14 0x80d8256b at Xfast_syscall+0xfb Uptime: 10m12s Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. Loaded symbols for /boot/kernel/linprocfs.ko.symbols Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/modules/vboxguest.ko...done. Loaded symbols for /boot/modules/vboxguest.ko Reading symbols from /boot/modules/vboxvideo.ko...done. Loaded symbols for /boot/modules/vboxvideo.ko Reading symbols from /boot/kernel/drm.ko.symbols...done. Loaded symbols for /boot/kernel/drm.ko.symbols Reading symbols from /boot/kernel/ums.ko.symbols...done. Loaded symbols for /boot/kernel/ums.ko.symbols Reading symbols from /boot/kernel/uhid.ko.symbols...done. Loaded symbols for /boot/kernel/uhid.ko.symbols #0 doadump (textdump=value optimized out) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=value optimized out) at pcpu.h:219 #1 0x80959888 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0x80959d44 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:756 #3 0x80d9f2ff in trap_fatal (frame=value optimized out, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:882 #4 0x80d9ef5d in trap (frame=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:224 #5 0x80d82282 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #6 0x80a4429e in rt_expunge (rnh=0x7f000210, rt=0xf800148e10c8) at /usr/src/sys/net/route.c:930 #7 0x80aa0aa1 in in_ifadownkill (rn=0xf800148e10c8, xap=0xfe046a7f5660) at /usr/src/sys/netinet/in_rmx.c:414 #8 0x80a412f0 in rn_walktree (h=value optimized out, f=0x80aa09d0 in_ifadownkill, w=0xfe046a7f5660) at /usr/src/sys/net/radix.c:1097 #9 0x80aa0942 in in_ifadown (ifa=0xf8000d542300, delete=1) at /usr/src/sys/netinet/in_rmx.c:447 #10 0x80a95591 in in_difaddr_ioctl (data=value optimized out, ifp=0xf8000d249000, td=value optimized out) at /usr/src/sys/netinet/in.c:580 #11 0x80a94763 in in_control (so=value optimized out, cmd=value optimized out, data=0xf80126c642c0 lo0, ifp=0xf8000d249000, td=0xf80108ad6000) at /usr/src/sys/netinet/in.c:219 #12 0x80a3010c in ifioctl (so=0xf80014839700, cmd=2149607705, data=0xf80126c642c0 lo0, td=0xf80108ad6000) at /usr/src/sys/net/if.c:2638 #13 0x809b1a5d in kern_ioctl (td=0xf80108ad6000, fd=value optimized out, com=0) at file.h:323 #14 0x809b163c in sys_ioctl (td=0xf80108ad6000, uap=0xfe046a7f59c0) at /usr/src/sys/kern/sys_generic.c:702 #15 0x80d9fd1b in amd64_syscall (td=0xf80108ad6000, traced=0) at subr_syscall.c:133 #16
Re: devel/qmake4: /usr/share/mk/bsd.prog.mk line 176: Malformed conditional (${COMPILER_TYPE}
On May 6, 2014, at 9:38 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
On CURRENT (FreeBSD 11.0-CURRENT #0 r265433: Tue May 6 13:37:15 CEST 2014
amd64) the
build/updating of port devel/qmake4 fails due to:
=== Building for qt4-qmake-4.8.6
make[1]: /usr/share/mk/bsd.prog.mk line 176: Malformed conditional
(${COMPILER_TYPE} ==
clang empty(CXXFLAGS:M-stdlib=libstdc++)) make[1]: Fatal errors
encountered --
cannot continue make[1]: stopped
in /usr/ports/devel/qmake4/work/qt-everywhere-opensource-src-4.8.6/qmake ===
Compilation
failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before
reporting the
failure to the maintainer.
*** Error code 1
I believe all the issues with this have been fixed.
Warner
___
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: New and exciting panic, possibly re(4)
On Wed, 2014-05-07 at 12:24 -0700, Sean Bruno wrote: While screwing around with comcast, I can trivially get this panic out of my desktop machine, and am very confused. It seems to happen on link change up/down events. I'm running 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r265280M. I don't have any direct evidence that this is re(4), just a hunch from some discussions in clusteradm@ This can happen when reconnecting my modem or simply issues a netif restart. Fatal trap 9: general protection fault while in kernel mode cpuid = 5; apic id = 15 instruction pointer = 0x20:0x80a4429e stack pointer = 0x28:0xfe046a7f5530 frame pointer = 0x28:0xfe046a7f55d0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1306 (ifconfig) trap number = 9 panic: general protection fault cpuid = 5 KDB: stack backtrace: #0 0x80998510 at kdb_backtrace+0x60 #1 0x80959d05 at panic+0x155 #2 0x80d9f2ff at trap_fatal+0x38f #3 0x80d9ef5d at trap+0x74d #4 0x80d82282 at calltrap+0x8 #5 0x80aa0aa1 at in_ifadownkill+0xd1 #6 0x80a412f0 at rn_walktree+0x80 #7 0x80aa0942 at in_ifadown+0xc2 #8 0x80a95591 at in_difaddr_ioctl+0x3a1 #9 0x80a94763 at in_control+0x463 #10 0x80a3010c at ifioctl+0x145c #11 0x809b1a5d at kern_ioctl+0x3cd #12 0x809b163c at sys_ioctl+0x13c #13 0x80d9fd1b at amd64_syscall+0x3fb #14 0x80d8256b at Xfast_syscall+0xfb Uptime: 10m12s Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. Loaded symbols for /boot/kernel/linprocfs.ko.symbols Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/modules/vboxguest.ko...done. Loaded symbols for /boot/modules/vboxguest.ko Reading symbols from /boot/modules/vboxvideo.ko...done. Loaded symbols for /boot/modules/vboxvideo.ko Reading symbols from /boot/kernel/drm.ko.symbols...done. Loaded symbols for /boot/kernel/drm.ko.symbols Reading symbols from /boot/kernel/ums.ko.symbols...done. Loaded symbols for /boot/kernel/ums.ko.symbols Reading symbols from /boot/kernel/uhid.ko.symbols...done. Loaded symbols for /boot/kernel/uhid.ko.symbols #0 doadump (textdump=value optimized out) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=value optimized out) at pcpu.h:219 #1 0x80959888 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0x80959d44 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:756 #3 0x80d9f2ff in trap_fatal (frame=value optimized out, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:882 #4 0x80d9ef5d in trap (frame=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:224 #5 0x80d82282 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #6 0x80a4429e in rt_expunge (rnh=0x7f000210, rt=0xf800148e10c8) at /usr/src/sys/net/route.c:930 #7 0x80aa0aa1 in in_ifadownkill (rn=0xf800148e10c8, xap=0xfe046a7f5660) at /usr/src/sys/netinet/in_rmx.c:414 #8 0x80a412f0 in rn_walktree (h=value optimized out, f=0x80aa09d0 in_ifadownkill, w=0xfe046a7f5660) at /usr/src/sys/net/radix.c:1097 #9 0x80aa0942 in in_ifadown (ifa=0xf8000d542300, delete=1) at /usr/src/sys/netinet/in_rmx.c:447 #10 0x80a95591 in in_difaddr_ioctl (data=value optimized out, ifp=0xf8000d249000, td=value optimized out) at /usr/src/sys/netinet/in.c:580 #11 0x80a94763 in in_control (so=value optimized out, cmd=value optimized out, data=0xf80126c642c0 lo0, ifp=0xf8000d249000, td=0xf80108ad6000) at /usr/src/sys/netinet/in.c:219 #12 0x80a3010c in ifioctl (so=0xf80014839700, cmd=2149607705, data=0xf80126c642c0 lo0, td=0xf80108ad6000) at /usr/src/sys/net/if.c:2638 #13 0x809b1a5d in kern_ioctl (td=0xf80108ad6000, fd=value optimized out, com=0) at file.h:323 #14 0x809b163c in sys_ioctl (td=0xf80108ad6000,
ports broken in current
I have just updated my 11-CURRENT tinderbox machine and found an issue that breaks ports building. make: /usr/share/mk/bsd.port.mk line 15: Could not find bsd.own.mk This is highlighted as tinderbox creates a clean build environment while the base system kept working with the old file being left behind - make delete-old doesn't remove bsd.own.mk from base but a clean system doesn't get it installed. In r265420 /head/share/mk/Makefile removed reference to bsd.own.mk and replaced it with src.opts.mk bsd.port.mk was left unaltered still including bsd.own.mk which now doesn't get installed but is still in svn, breaking ports building. Should bsd.port.mk include src.opts.mk instead of bsd.own.mk or should bsd.own.mk be re-added to the install list? This appears to carry on from the yesterdays build fails with src.opts.mk not being found. Shane ___ 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
