Re: FYI: 11.0-CURRENT's contrib/ntp -r280915, some boot-time ntpd error messages
On Wed, Apr 01, 2015 at 12:08:55PM -0700, Mark Millard wrote: > I rebuilt and the boot-message line > > > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: line 22 column 1 syntax error > > > is no longer is occurring. But I'm still getting the other two: > > > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 for > > [omitted] fails: Can't assign requested address > > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 for > > [omitted] fails: Can't assign requested address I've also noticed that net/bird6 can't seem to do OSPF on -CURRENT (r280426 here): Apr 2 05:41:32 midgar bird6: ospf0: Socket error on vlan2: Can't assign requested address vlan2 has both an auto_linklocal address and globally unique unicast address. ___ 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.org gets SANCTIONED .RU!
Dear FreeBSD-{advocacy,chat,current,doc}@,
It has come to my attention that FreeBSD.org has been sanctioned today.
It has been sanctioned in the category of best server OS.
Some other sites sanctioned together with FreeBSD.org are
OpenBSD.org for providing a desktop OS,
NetBSD.org for powering toasters, and
nginx.org for an engine with an X (not sure what that means, anyone?).
http://We.Are.Sanctioned.RU/
Regardless, everyone, please keep up the good work!
And feel free to nominate other web-sites with #SanctionedRU!
Cheers,
Constantine.
___
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: FYI: 11.0-CURRENT's contrib/ntp -r280915, some boot-time ntpd error messages
On Wed, Apr 1, 2015 at 12:08 PM, Mark Millard wrote: > I rebuilt and the boot-message line > > > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: line 22 column 1 syntax error > > > is no longer is occurring. But I'm still getting the other two: > > > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 for > [omitted] fails: Can't assign requested address > > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 for > [omitted] fails: Can't assign requested address > > > === > Mark Millard > markmi at dsl-only.net > This is probably way too obvious, but is the system configured for IPv6? -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@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"
Re: FYI: 11.0-CURRENT's contrib/ntp -r280915, some boot-time ntpd error messages
I rebuilt and the boot-message line > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: line 22 column 1 syntax error is no longer is occurring. But I'm still getting the other two: > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 for > [omitted] fails: Can't assign requested address > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 for > [omitted] fails: Can't assign requested address === Mark Millard markmi at dsl-only.net On 2015-Mar-31, at 07:13 PM, Mark Millard wrote: Basic context: > $ dmesg | head > ... > FreeBSD 11.0-CURRENT #3 r280867M: Tue Mar 31 16:19:53 PDT 2015 >root@FBSDG5C0:/usr/obj/usr/src/sys/GENERIC64vtsc-NODEBUG powerpc > gcc version 4.9.1 (FreeBSD Ports Collection for powerpc64) > $ freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r280867M: Tue Mar 31 > 16:19:53 PDT 2015 > root@FBSDG5C0:/usr/obj/usr/src/sys/GENERIC64vtsc-NODEBUG powerpc powerpc64 > 1100067 1100066 I normally do not go beyond the most recent 11.0-CURRENT snapshot (-r280862 at this point) but I wanted to pick up the the checkins that enable building the system clang via powerpc64-xtoolchain-gcc's powerpc64-gcc (as part of a self-hosted rebuild). So I choose to: svnlite update /usr/src -r280867 . I also later did "svnlite update /usr/src/contrib/ntp/ -r280915" because the overall the -r280867 vintage materials in that area failed to compile. Other than -r280915's contrib/ntp/ntpd/ntp_parser.y, contrib/ntp/... is the -r280849 update that would have been in a -r280862 snapshot. The problem (new ntpd error messages but probably not important to my activities): After buildworld buildkernel installkernel installworld and rebooting it now reports during the boot (with a little context shown): > ... > Starting sendmail_submit. > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: line 22 column 1 syntax error > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 for > [omitted] fails: Can't assign requested address > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 for > [omitted] fails: Can't assign requested address > Starting sendmail_msp_queue. > ... The "line 22 column 1 syntax error" is not explicit about the file involved. Presuming /etc/ntp.conf ... > # > # $FreeBSD: head/etc/ntp.conf 259973 2013-12-27 23:06:15Z delphij $ > # > ... > # The option `iburst' is used for faster initial synchronization. > # > server 0.freebsd.pool.ntp.org iburst > server 1.freebsd.pool.ntp.org iburst > server 2.freebsd.pool.ntp.org iburst > #server 3.freebsd.pool.ntp.org iburst > ... That first "server" line is line 22 and is the first non-#/non-empty line in the file. head/etc/ntp.conf 259973 seems to still be the most recent in head's svn area. And /etc/ntp.conf is unedited: > # diff /etc/ntp.conf /usr/src/etc/ntp.conf > # As of the the earlier "svnlite update /usr/src -r280598" to match that earlier snapshot I was not getting such messages from the earlier build. Context details: > # more /etc/rc.conf > hostname="FBSDG5C0" > ifconfig_bge0="DHCP" > ifconfig_bge0_ipv6="inet6 accept_rtadv" > ifconfig_gem0="DHCP" > ifconfig_gem0_ipv6="inet6 accept_rtadv" > sshd_enable="YES" > ntpd_enable="YES" > ntpd_sync_on_start="YES" > # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable > dumpdev="AUTO" > hald_enable="YES" > dbus_enable="YES" > make -j 8 CROSS_TOOLCHAIN=powerpc64-gcc \ > WITHOUT_CLANG_BOOTSTRAP= WITH_CLANG= WITH_CLANG_IS_CC= \ > WITH_LLDB= \ > WITHOUT_GCC_BOOTSTRAP= WITHOUT_GCC= WITHOUT_GNUCXX= \ > WITHOUT_BOOT= WITHOUT_LIB32= \ > buildworld buildkernel \ > KERNCONF=GENERIC64vtsc-NODEBUG \ > TARGET=powerpc TARGET_ARCH=powerpc64 > # more /etc/src.conf > NO_WERROR= > WITH_LIBCPLUSPLUS= > CC=/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=gcc > CFLAGS+=-L/usr/obj/usr/src/tmp/usr/lib/. > CXXFLAGS+=-I/usr/obj/usr/src/tmp/usr/include/c++/v1/. -std=gnu++11 > -L/usr/obj/usr/src/lib/libc++/. > CXXFLAGS+=-I/usr/include/c++/v1/. -std=gnu++11 -L/usr/lib/. === Mark Millard markmi at dsl-only.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: Bazaaring the cathedral (Lowering the Barrier to Entry)
On 01/04/2015 19:55, Eitan Adler wrote: > To solve this problem I propose a simple solution: self-serve commit > access. We create a web service on accounts.freebsd.org via which > users can create themselves a freefall account. In addition to a > freefall account, the identical username would be created for the wiki > and phabricator, bugzilla, and any other service we might provide. Your proposal is incomplete because itd oesn't say anything about booking a mentor. Even if it's a bazaar a neophyte still has to get themselves a mentor, JIMHO. -- 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: umass, Verbatim STORE N GO drive, CAM status 0x50
On Wed, 1 Apr 2015, Hans Petter Selasky wrote: > Date: Wed, 1 Apr 2015 16:38:03 > From: Hans Petter Selasky > To: Damian Weber , Kurt Jaeger > Cc: freebsd-current@freebsd.org > Subject: Re: umass, Verbatim STORE N GO drive, CAM status 0x50 > > On 04/01/15 16:27, Damian Weber wrote: > > > > > Try adding some quirks: > > > > > > usbconfig dump_quirk_names | grep MSC > > > > > > --HPS > > > > Dear Hans Petter and Kurt, thank you for your great advice, > > I successfully attached my Verbatim USB drive > > > > the magic lines are > > > > in ./dev/usb/usbdevs : > > > > +vendor VERBATIM0x18a5 Verbatim > > +product VERBATIM STORENGO 0x0243 Verbatim Store N Go > > > > in ./dev/usb/quirk/usb_quirk.c > > > > /* copied from SANDISK, SDCZ2_128 */ > > > > + USB_QUIRK(VERBATIM, STORENGO, 0x, 0x, UQ_MSC_FORCE_WIRE_BBB, > > + UQ_MSC_FORCE_PROTO_SCSI, UQ_MSC_IGNORE_RESIDUE, > > + UQ_MSC_NO_SYNC_CACHE), > > > > > > result: > > a) can mount it (mount_msdosfs) > > b) can read/write files (sha1-checksums verified) > > > > two questions remain > > > > 1) can the dmesg error messages be dealt with? ILLEGAL REQUEST asc:20,0 > > > > ugen2.2: at usbus2 > > umass0: on usbus2 > > umass0: SCSI over Bulk-Only; quirks = 0x4080 > > umass0:4:0: Attached to scbus4 > > (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 > > 00 00 > > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > > (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid > > command operation code) > > (probe0:umass-sim0:0:0:0): Error 22, Unretryable error > > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 > > da0: Removable Direct Access SPC-4 SCSI device > > da0: 40.000MB/s transfers > > da0: 14909MB (30535401 512 byte sectors: 255H 63S/T 1900C) > > da0: quirks=0x2 > > > > 2) is it possible to modify usb_quirk.c without > > going through the whole make-kernel dance? > > > > Hi, > > If usb_quirk is built like a module you only rebuild that and load. > > Can you put this quirk and patch in a PR and assign to me and I'll get it in! > > --HPS > PR filed as Bug 199101 has been added to the database Email sent to: freebsd-...@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: Bazaaring the cathedral (Lowering the Barrier to Entry)
You mean, like sourceforge offered in 2000? :) -a ___ 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: Bazaaring the cathedral (Lowering the Barrier to Entry)
On Wed, Apr 1, 2015 at 9:55 AM, Eitan Adler wrote: > > To solve this problem I propose a simple solution: self-serve commit > access. We create a web service on accounts.freebsd.org via which > users can create themselves a freefall account. In addition to a > freefall account, the identical username would be created for the wiki > and phabricator, bugzilla, and any other service we might provide. > I support the creation of accounts.freebsd.org. I suggest that we use PWM ( http://code.google.com/p/pwm/ ) as a web-based front-end to a back-end LDAP database. The FreeBSD cluster already has LDAP ( https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#kerberos-ldap ) The FreeBSD cluster LDAP + Kerberos back-end infrastructure is something developed by clusteradm (most likely Peter Wemm). It works quite well. I succeeded in using the FreeBSD cluster LDAP system for Jenkins authentication, and it just worked like a champ. The FreeBSD cluster LDAP system just needs a better front-end that is more user friendly, and easier to manage. If you log into hub.freebsd.org and look at /etc/aliases, you will see that there are 12 people who receive clusteradm e-mails. My experience working with Jenkins is that only about 2-3 people actively do clusteradm work, and they are *way* overloaded. If we could have accounts.freebsd.org which streamlines a lot of the account creation and management, and works across many modern web applications, that would be super cool, and would hopefully reduce the load on clusteradm! -- Craig ___ 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"
Bazaaring the cathedral (Lowering the Barrier to Entry)
Hi all, FreeBSD today has a significant problem of attracting new developers. The lack of new developers manifests itself in a dearth of driver support, inadequate documentation, and trailing third party packages. One of the key reasons for the lack of people is the high barrier of entry to joining the FreeBSD project. While every modern project uses git (usually hosted on github), FreeBSD uses self-hosted subversion. The use of git goes beyond just the choice of version control. It allows for workflows that FreeBSD can't even dream of. The linux kernel has no concept of a committer. Instead anyone can clone the git tree, build a kernel, and call themselves a Linux distribution. Our wiki and code review tools are in an even worse position than our repository. In order to contribute you need to send an email to clusteradm@ and hope they deem you worthy enough of access. The bug tracking system is in a better shape but isn't perfect: while any user can create an account, their privileges are limited: they can't help close out bad PRs, reclassify good ones, or do other generally useful work. To solve this problem I propose a simple solution: self-serve commit access. We create a web service on accounts.freebsd.org via which users can create themselves a freefall account. In addition to a freefall account, the identical username would be created for the wiki and phabricator, bugzilla, and any other service we might provide. This will allow us to quickly gain large number of contributors, who will be able to make better progress on our missing features, and rectify some of the drawbacks listed above. Today I hope we turn ourselves from the cathedral into a truly open and democratic project! -- Eitan Adler ___ 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"
ntpd errors after upgrade on current amd64
After build install world on current ntpd doesn't work. Here is error: FreeBSD/amd64 (pozo.com) (ttyu0) login: Apr 1 08:29:19 pozo ntpd[49825]: line 22 column 1 syntax error Apr 1 08:29:19 pozo ntpd[49825]: setsockopt IPV6_MULTICAST_IF 0 for fe80::1%2 fails: Can't assign requested address I'm using the stock ntp.conf from /usr/src/etc. It worked fine before the upgrade Thanks || n...@pozo.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"
Re: umass, Verbatim STORE N GO drive, CAM status 0x50
On 04/01/15 16:27, Damian Weber wrote: Try adding some quirks: usbconfig dump_quirk_names | grep MSC --HPS Dear Hans Petter and Kurt, thank you for your great advice, I successfully attached my Verbatim USB drive the magic lines are in ./dev/usb/usbdevs : +vendor VERBATIM0x18a5 Verbatim +product VERBATIM STORENGO 0x0243 Verbatim Store N Go in ./dev/usb/quirk/usb_quirk.c /* copied from SANDISK, SDCZ2_128 */ + USB_QUIRK(VERBATIM, STORENGO, 0x, 0x, UQ_MSC_FORCE_WIRE_BBB, + UQ_MSC_FORCE_PROTO_SCSI, UQ_MSC_IGNORE_RESIDUE, + UQ_MSC_NO_SYNC_CACHE), result: a) can mount it (mount_msdosfs) b) can read/write files (sha1-checksums verified) two questions remain 1) can the dmesg error messages be dealt with? ILLEGAL REQUEST asc:20,0 ugen2.2: at usbus2 umass0: on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x4080 umass0:4:0: Attached to scbus4 (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable error da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: Removable Direct Access SPC-4 SCSI device da0: 40.000MB/s transfers da0: 14909MB (30535401 512 byte sectors: 255H 63S/T 1900C) da0: quirks=0x2 2) is it possible to modify usb_quirk.c without going through the whole make-kernel dance? Hi, If usb_quirk is built like a module you only rebuild that and load. Can you put this quirk and patch in a PR and assign to me and I'll get it in! --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"
Re: umass, Verbatim STORE N GO drive, CAM status 0x50
> Try adding some quirks: > > usbconfig dump_quirk_names | grep MSC > > --HPS Dear Hans Petter and Kurt, thank you for your great advice, I successfully attached my Verbatim USB drive the magic lines are in ./dev/usb/usbdevs : +vendor VERBATIM0x18a5 Verbatim +product VERBATIM STORENGO 0x0243 Verbatim Store N Go in ./dev/usb/quirk/usb_quirk.c /* copied from SANDISK, SDCZ2_128 */ + USB_QUIRK(VERBATIM, STORENGO, 0x, 0x, UQ_MSC_FORCE_WIRE_BBB, + UQ_MSC_FORCE_PROTO_SCSI, UQ_MSC_IGNORE_RESIDUE, + UQ_MSC_NO_SYNC_CACHE), result: a) can mount it (mount_msdosfs) b) can read/write files (sha1-checksums verified) two questions remain 1) can the dmesg error messages be dealt with? ILLEGAL REQUEST asc:20,0 ugen2.2: at usbus2 umass0: on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x4080 umass0:4:0: Attached to scbus4 (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable error da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: Removable Direct Access SPC-4 SCSI device da0: 40.000MB/s transfers da0: 14909MB (30535401 512 byte sectors: 255H 63S/T 1900C) da0: quirks=0x2 2) is it possible to modify usb_quirk.c without going through the whole make-kernel dance? Best wishes Damian ___ 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: [CFT] Call for testing pkg 1.5.0
On Wed, Apr 01, 2015 at 01:56:38PM +0100, David Chisnall wrote: > On 1 Apr 2015, at 05:03, Rui Paulo wrote: > > > > That is expected. WITH_PKG=devel is a make(1) option that only affects > > ports (non-binary pkgs). > > Are you sure? I have it in make.conf on one of my systems where I never > build ports manually (and don't even have a ports tree installed) and there I > get this: > > $ pkg -v > 1.4.99.13 > > In a jail on the same machine without the make.conf entry, I get the stable > version. This is how I've been testing pkg-devel for a while. Is there a > different recommended way? > That is because you enforced installing pkg-devel one day via: pkg install pkg-devel probably then it will stay on pkg-devel :) pkg itself is not aware of make.conf Best regards Bapt pgptYK5cp2usY.pgp Description: PGP signature
Re: [CFT] Call for testing pkg 1.5.0
On 1 Apr 2015, at 05:03, Rui Paulo wrote: > > That is expected. WITH_PKG=devel is a make(1) option that only affects ports > (non-binary pkgs). Are you sure? I have it in make.conf on one of my systems where I never build ports manually (and don't even have a ports tree installed) and there I get this: $ pkg -v 1.4.99.13 In a jail on the same machine without the make.conf entry, I get the stable version. This is how I've been testing pkg-devel for a while. Is there a different recommended way? David ___ 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: [CFT] Call for testing pkg 1.5.0
On Wed, Apr 01, 2015 at 11:48:27AM +, Thomas Mueller wrote: > Excerpt from Baptiste Daroussin: > > - Initial support for OS X > - Initial support for NetBSD/EdjeBSD > > How would pkg-1.5.0 integrate with NetBSD pkgsrc? > > I didn't think there were any plans to port FreeBSD ports to NetBSD. Or is > such a plan in the works? > There are people looking at integrating pkg with pkgsrc yes, don't know the status, (pkg is already in pkgsrc-wip but no further integration for what I do know And yes you are right it is EdgeBSD not EdjeBSD sorry. Best regards, Bapt pgpCVf9bVjpMp.pgp Description: PGP signature
Re: [CFT] Call for testing pkg 1.5.0
Excerpt from Baptiste Daroussin: - Initial support for OS X - Initial support for NetBSD/EdjeBSD How would pkg-1.5.0 integrate with NetBSD pkgsrc? I didn't think there were any plans to port FreeBSD ports to NetBSD. Or is such a plan in the works? EdjeBSD should be EdgeBSD. A little spelling error can be critical when trying to find something on the Internet. Web site is edgebsd.org (I just went there). Tom ___ 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: [CFT] Call for testing pkg 1.5.0
On Mar 31, 2015, at 17:24, Sergei Vyshenski wrote: > Instead, the following succeded: > # cd /usr/ports/ports-mgmt/pkg-devel > # make reinstall > ... > # pkg -v > 1.4.99.16 That is expected. WITH_PKG=devel is a make(1) option that only affects ports (non-binary pkgs). -- Rui Paulo ___ 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"
FYI: 11.0-CURRENT's contrib/ntp -r280915, some boot-time ntpd error messages
Basic context: > $ dmesg | head > ... > FreeBSD 11.0-CURRENT #3 r280867M: Tue Mar 31 16:19:53 PDT 2015 > root@FBSDG5C0:/usr/obj/usr/src/sys/GENERIC64vtsc-NODEBUG powerpc > gcc version 4.9.1 (FreeBSD Ports Collection for powerpc64) > $ freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r280867M: Tue Mar 31 > 16:19:53 PDT 2015 > root@FBSDG5C0:/usr/obj/usr/src/sys/GENERIC64vtsc-NODEBUG powerpc powerpc64 > 1100067 1100066 I normally do not go beyond the most recent 11.0-CURRENT snapshot (-r280862 at this point) but I wanted to pick up the the checkins that enable building the system clang via powerpc64-xtoolchain-gcc's powerpc64-gcc (as part of a self-hosted rebuild). So I choose to: svnlite update /usr/src -r280867 . I also later did "svnlite update /usr/src/contrib/ntp/ -r280915" because the overall the -r280867 vintage materials in that area failed to compile. Other than -r280915's contrib/ntp/ntpd/ntp_parser.y, contrib/ntp/... is the -r280849 update that would have been in a -r280862 snapshot. The problem (new ntpd error messages but probably not important to my activities): After buildworld buildkernel installkernel installworld and rebooting it now reports during the boot (with a little context shown): > ... > Starting sendmail_submit. > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: line 22 column 1 syntax error > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 for > [omitted] fails: Can't assign requested address > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 for > [omitted] fails: Can't assign requested address > Starting sendmail_msp_queue. > ... The "line 22 column 1 syntax error" is not explicit about the file involved. Presuming /etc/ntp.conf ... > # > # $FreeBSD: head/etc/ntp.conf 259973 2013-12-27 23:06:15Z delphij $ > # > ... > # The option `iburst' is used for faster initial synchronization. > # > server 0.freebsd.pool.ntp.org iburst > server 1.freebsd.pool.ntp.org iburst > server 2.freebsd.pool.ntp.org iburst > #server 3.freebsd.pool.ntp.org iburst > ... That first "server" line is line 22 and is the first non-#/non-empty line in the file. head/etc/ntp.conf 259973 seems to still be the most recent in head's svn area. And /etc/ntp.conf is unedited: > # diff /etc/ntp.conf /usr/src/etc/ntp.conf > # As of the the earlier "svnlite update /usr/src -r280598" to match that earlier snapshot I was not getting such messages from the earlier build. Context details: > # more /etc/rc.conf > hostname="FBSDG5C0" > ifconfig_bge0="DHCP" > ifconfig_bge0_ipv6="inet6 accept_rtadv" > ifconfig_gem0="DHCP" > ifconfig_gem0_ipv6="inet6 accept_rtadv" > sshd_enable="YES" > ntpd_enable="YES" > ntpd_sync_on_start="YES" > # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable > dumpdev="AUTO" > hald_enable="YES" > dbus_enable="YES" > make -j 8 CROSS_TOOLCHAIN=powerpc64-gcc \ > WITHOUT_CLANG_BOOTSTRAP= WITH_CLANG= WITH_CLANG_IS_CC= \ > WITH_LLDB= \ > WITHOUT_GCC_BOOTSTRAP= WITHOUT_GCC= WITHOUT_GNUCXX= \ > WITHOUT_BOOT= WITHOUT_LIB32= \ > buildworld buildkernel \ > KERNCONF=GENERIC64vtsc-NODEBUG \ > TARGET=powerpc TARGET_ARCH=powerpc64 > # more /etc/src.conf > NO_WERROR= > WITH_LIBCPLUSPLUS= > CC=/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=gcc > CFLAGS+=-L/usr/obj/usr/src/tmp/usr/lib/. > CXXFLAGS+=-I/usr/obj/usr/src/tmp/usr/include/c++/v1/. -std=gnu++11 > -L/usr/obj/usr/src/lib/libc++/. > CXXFLAGS+=-I/usr/include/c++/v1/. -std=gnu++11 -L/usr/lib/. === Mark Millard markmi at dsl-only.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: async pass(4) patches available
On Tue, Mar 31, 2015 at 04:50:51PM -0600, Kenneth D. Merry wrote: > On Tue, Mar 31, 2015 at 03:49:12 +0300, Konstantin Belousov wrote: > > On Mon, Mar 30, 2015 at 04:23:58PM -0600, Kenneth D. Merry wrote: > > > Kernel memory for data transferred via the queued interface is > > > allocated from the zone allocator in MAXPHYS sized chunks, and user > > > data is copied in and out. This is likely faster than the > > > vmapbuf()/vunmapbuf() method used by the CAMIOCOMMAND ioctl in > > > configurations with many processors (there are more TLB shootdowns > > > caused by the mapping/unmapping operation) but may not be as fast > > > as running with unmapped I/O. > > cam_periph_mapmem() uses vmapbuf() with an indicator to always map the > > user pages mostly because I do not know CAM code and wanted to make > > the least intrusive changes there. It is not inherently impossible > > to pass unmapped pages down from cam_periph_mapmem(), but might > > require some more plumbing for driver to indicate that it is acceptable. > > I think that would probably not be too difficult to change. That API isn't > one that is exposed, so changing it shouldn't be a problem. The only > reason not to do unmapped I/O there is just if the underlying controller > doesn't support it. The lower parts of the stack shouldn't be trying to > sniff the data that is read or written to the device, although that has > happened in the past. We'd have to audit a couple of the drivers to > make sure they aren't trying to access the data. This is why I mentioned 'plumbing' required to map pages when needed. > > > > The new memory handling model for user requests also allows > > > applications to send CCBs with request sizes that are larger than > > > MAXPHYS. The pass(4) driver now limits queued requests to the I/O > > > size listed by the SIM driver in the maxio field in the Path > > > Inquiry (XPT_PATH_INQ) CCB. > > > > > > There are some things things would be good to add: > > > > > > 1. Come up with a way to do unmapped I/O on multiple buffers. > > >Currently the unmapped I/O interface operates on a struct bio, > > >which includes only one address and length. It would be nice > > >to be able to send an unmapped scatter/gather list down to > > >busdma. This would allow eliminating the copy we currently do > > >for data. > > Only because nothing more was needed. The struct bio does not use > > address/length pair when unmapped, it passes the list of physical > > pages, see bio_ma array pointer. It is indeed taylored to be a pointer > > to struct buf' b_pages, but it does not have to be. > > > > The busdma unmapped non-specific interface is bus_dmamap_load_ma(), > > which again takes array of pages to load. If you want some additional > > helper, suitable for your goals, please provide the desired interface > > definition. > > What I'd like to be able to do is pass down a CCB with a user virtual > S/G list (CAM_DATA_SG, but with user virtual pointers) and have busdma deal > with it. Is there an existing definition of the 'user s/g list' ? Some structure, or existing example of use ? > > The trouble would likely be figuring out a flag to use to indicate that the > S/G list in question contains user virtual pointers. (Backwards/binary > compatibility is always an issue with CCB flags, since they have all been > used.) > > But that is essentially what is needed. > I can write the code, but I need API specification. Also, ideally I need a rough example which uses the API. ___ 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"
