Re: ulpt can't attach Lexmark E120
On 08/24/13 02:44, George Mitchell wrote: On 08/23/13 07:11, George Mitchell wrote: On 08/23/13 02:18, Hans Petter Selasky wrote: On 08/23/13 02:29, George Mitchell wrote: On 08/22/13 07:34, Hans Petter Selasky wrote: Give that the printer works fine with the same code on my amd64 machines, does this suggest we have a byte-ordering problem in the driver? -- George Hi, I looked at the code and your debug prints, and it looks like the usbd_transfer_setup() function is to blame. To get further debugging here, you need to enable hw.usb.debug=15 and hw.usb.dwcotg.debug=15 or something like that. error = usbd_transfer_setup(uaa->device, &iface_index, sc->sc_xfer, ulpt_config, ULPT_N_TRANSFER, sc, &sc->sc_mtx); I think this should be trivial to fix one the cause is found. --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: pkgng
Hi, I solved my problem by myself. I update PACKAGESITE in /usr/local/etc/pkg.conf in accordance with the information in another expert web site. --- 2013/8/24 Hideki Yamamoto > > Hi, > > As I moved from old pkg_xxx to pkg2ng. > But I cannot install any new packages as follows: > > # rm -f/var/db/pkg* > > # pkg2ng > > # pkg install gs > > freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32, > freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32 >- >- >- >- > freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32, > freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32 > > # echo $? 3 # > # gsview > gsview: Commandnot found. > > > > Does someone help me? > > Thanks in advance. > > Hideki Yamamoto > > > ___ 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"
pkgng
Hi, As I moved from old pkg_xxx to pkg2ng. But I cannot install any new packages as follows: # rm -f/var/db/pkg* # pkg2ng # pkg install gs freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32 - - - - freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32, freebsd:9:x86:32 # echo $? 3 # # gsview gsview: Commandnot found. Does someone help me? Thanks in advance. Hideki Yamamoto ___ 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: GCC withdraw
On 8/24/13 3:23 AM, Mark Felder wrote: On Fri, Aug 23, 2013, at 13:20, Julian Elischer wrote: On 8/23/13 7:55 PM, Poul-Henning Kamp wrote: In message <52174d51.2050...@digsys.bg>, Daniel Kalchev writes: - 9.x gcc default and clang in base; - 10.x clang default and gcc in ports; I believe this is the best idea so far. As long as these ports work with gcc in ports, that is. +1 well as I was forced to go back to gcc to get a compiling & running kernel on my VPS (xen) I'm not convinced that clang is there yet. I'd be really grumpy if I had to go through al the ports hoopla to recompile my kernel. Curious which Xen version. I'd like to try to replicate this issue. I've seen FreeBSD 10 run just fine on XenServer 6.0 and 6.2. I don't know.. whatever RootBSD run, but the fact that I needed gcc for anything suggests that we should keep it around for a while. ___ 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: ulpt can't attach Lexmark E120
On 08/23/13 07:11, George Mitchell wrote: On 08/23/13 02:18, Hans Petter Selasky wrote: On 08/23/13 02:29, George Mitchell wrote: On 08/22/13 07:34, Hans Petter Selasky wrote: Here's the result: [...] (at which point if I type control-c to stop usbdump, the system gets a fatal kernel mode translation fault, but that's another story.) Hope this helps. -- George I would expect to see some messages ERR != 0 when you plug the device. Can you show both usbdump output and dmesg output which belongs together? --HPS Not sure exactly how I would get the usbdump output and log output interspersed in the correct order, and the fact that the pi panics when I type control-C at usbdump doesn't help. Subjectively, the "ulpt0 attach returned 12" seemed to occur a fraction of a second later than the others. But I'll see what I can come up with this evening. -- George Well, what I ended up doing is turning on ulpt debugging and then piping usbdump into logger, yielding the attachment. But I'm not 100% sure that the output is in the proper sequence. Give that the printer works fine with the same code on my amd64 machines, does this suggest we have a byte-ordering problem in the driver? -- George Aug 24 00:10:24 pi kernel: ugen0.5: at usbus0 Aug 24 00:10:24 pi kernel: ulpt_probe: Aug 24 00:10:24 pi kernel: ulpt_probe: Aug 24 00:10:24 pi kernel: ulpt_attach: sc=0xc2d46a00 Aug 24 00:10:24 pi kernel: ulpt0: on usbus0 Aug 24 00:10:24 pi kernel: ulpt_attach: setting alternate config number: 0 Aug 24 00:10:24 pi kernel: ulpt_attach: error=USB_ERR_INVAL Aug 24 00:10:24 pi kernel: ulpt_detach: sc=0xc2d46a00 Aug 24 00:10:24 pi kernel: device_attach: ulpt0 attach returned 12 Aug 24 00:10:24 pi george: 00:08:02.619534 usbus0.5 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.620189 usbus0.5 DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.620282 usbus0.5 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.621186 usbus0.5 DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.638617 usbus0.5 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.640299 usbus0.5 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.640802 usbus0.5 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.643668 usbus0.5 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=20,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.643831 usbus0.5 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.646289 usbus0.5 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.646389 usbus0.5 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.648294 usbus0.5 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.648404 usbus0.5 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.650283 usbus0.5 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.650380 usbus0.5 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.658667 usbus0.5 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=16,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.658783 usbus0.5 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.661289 usbus0.5 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.661386 usbus0.5 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.664291 usbus0.5 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=44,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.664404 usbus0.5 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.666289 usbus0.5 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.666387 usbus0.5 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.668663 usbus0.5 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=28,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.668850 usbus0.5 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.671284 usbus0.5 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=12,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.671411 usbus0.5 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.678038 usbus0.5 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=32,IVAL=0,ERR=0 Aug 24 00:10:24 pi george: 00:08:02.678144 usbus0.5 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 Aug 24 00:10:24 pi george: 00:08:02.680296 usbus0.5
Re: patch to add AES intrinsics to gcc
On Aug 23, 2013, at 4:01 PM, Alfred Perlstein wrote: > On 8/23/13 3:35 AM, David Chisnall wrote: >> On 23 Aug 2013, at 10:58, Bernhard Fröhlich wrote: >> >>> I don't know if you are aware that IF you really do that we will have >>> serious >>> problems to ship packages for 10. USE_GCC=any is the fallback in the >>> portstree for all ports that are unable to build with clang which was >>> introduced >>> when HEAD switched to clang as default cc. Right now there are 150 ports in >>> the tree that use this fallback and quite a few of them are high profile >>> ports: >>> >>> the highlights: >>> audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose >>> emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxine >>> multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 >>> security/clamav >>> >>> the full list: >>> http://dpaste.com/1354075/ >>> >>> A possible hack could be to add a check for USE_GCC=any to behave like >>> a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc >>> from ports for a lot of people on HEAD I suppose. >>> >>> We certainly need to do that switch to remove the ancient gcc from base >>> some time but with my portmgr hat on I can only say we don't plan to do that >>> before 10.0 especially not if we are only talking about a few weeks time >>> window. >> That is unfortunate. We have said for over a year that 10.0 should not ship >> with gcc. I can delay committing the patch to flip the switch until later >> in the code slush, if re approves, but ports that require gcc should be >> building with gcc from ports (which will also improve code quality, as gcc >> 4.6/7 produce significantly better code than 4.2.1). >> >> David >> >> ___ >> > Why can't ports just then add the old-version of GCC? This tight coupling > between src and ports is screwing us over for far too long. ports already has various gcc versions in ports, needed for dozens of ports that require newer gcc, and this could be adopted for the gcc from base issue. But that's not the issue. It is making the ports that need it use it, and from the quoted message it sounds like that would take work. Work takes time, and the window is closing. > If src needs to move on, and it surely seems like it does, then ports needs > to adapt. I'd dispute the 'and surely it seems like it does' part of this. Non x86 architectures will continue to use gcc because clang just isn't ready at this time for them. Some are very close (arm), some are close (powerpc64, mips*), some are no where near ready, or will never be ready (sparc64, ia64). There's no coherent, documented plan for these absent gcc at the moment. There are lots of pieces there, and those pieces will form the basis of the solution (+handbook updates) for the removal of gcc in 11, but we just aren't there yet. > No offense to either team, but this is just common sense. The only ones that would really matter are ones in any bootstrap path we might need for external toolchains. Since qemu is the basis for cross building ports, it is disturbing to see that on the list. I know qemu has, in the past, been sensitive to compiler versions, as are many of the emulators in the tree. It might not be a simple matter to just use gcc 4.6 or 4.7 for some of the items on the list. When I've moved gcc versions and had problems with FOSS it is either due to new warnings/errors and language violations. Some of these are trivial to fix, others reveal fundamental flaws in the code and many changes are needed. Sometimes newer compilers also have optimizations bugs (as opposed to language violations now optimized differently) which break things at run-time, despite things appearing to compile. These aren't insurmountable problems, but do take time to implement and test. 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: How to best overload the fileops ?
On 08/23/2013 13:36, Ian Lepore wrote:
I think the point is that devfs_ops_f provides several devfs-specific
methods and then "inherits" the rest by referencing the standard
vn_whatever functions. Since John recommended that you expose the
fo_whatever methods, I think he's suggesting you build your ops table by
providing your own close method and fill in the rest of the table with
the now-exposed kqueue ops methods.
So you are suggesting to just make kqueue fileops public? This was my
first suggestion, and this was rejected by Roman Divacky (who was
supposed to check it in) as very ugly. I did this through the method
kqueue_ops(), not directly though.
So can we agree on way to be used here?
Way#1: struct fileops* kqueue_fileops() which is used as the base for
epoll fileops.
Way#2: make kqueueops public and use as a base for epoll.
It's not as neat and clean as "class epollops : public kqueueops {...}"
but it's probably not as bad as using clever macros to try to turn C
into a sort of C++Lite.
Whatever makes code more clear is better. I don't think I suggested to
turn C into anything.
Yuri
___
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: patch to add AES intrinsics to gcc
On 8/23/13 3:35 AM, David Chisnall wrote: On 23 Aug 2013, at 10:58, Bernhard Fröhlich wrote: I don't know if you are aware that IF you really do that we will have serious problems to ship packages for 10. USE_GCC=any is the fallback in the portstree for all ports that are unable to build with clang which was introduced when HEAD switched to clang as default cc. Right now there are 150 ports in the tree that use this fallback and quite a few of them are high profile ports: the highlights: audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxine multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 security/clamav the full list: http://dpaste.com/1354075/ A possible hack could be to add a check for USE_GCC=any to behave like a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc from ports for a lot of people on HEAD I suppose. We certainly need to do that switch to remove the ancient gcc from base some time but with my portmgr hat on I can only say we don't plan to do that before 10.0 especially not if we are only talking about a few weeks time window. That is unfortunate. We have said for over a year that 10.0 should not ship with gcc. I can delay committing the patch to flip the switch until later in the code slush, if re approves, but ports that require gcc should be building with gcc from ports (which will also improve code quality, as gcc 4.6/7 produce significantly better code than 4.2.1). David ___ Why can't ports just then add the old-version of GCC? This tight coupling between src and ports is screwing us over for far too long. If src needs to move on, and it surely seems like it does, then ports needs to adapt. No offense to either team, but this is just common sense. ___ 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"
devel/gettext build error in jail i386 environment on amd64 host
Hello. I have: FreeBSD 10.0-CURRENT #0 r254719 and and jail for i386 environment when building the port devel/gettext I get the following error: http://privatepaste.com/46f9477022 who can tell me what could be the cause of the error and how to fix it? still about a month ago, I successfully compiled the port in jail i386 environment Thanks. ___ 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: patch to add AES intrinsics to gcc
On Fri, Aug 23, 2013 at 06:54:44AM -0700, Adrian Chadd wrote: > Hi! > > If firewire code doesn't build on clang correctly, have you filed a bug so > it gets looked at before 10.0 is released? that's pretty broken > code/behaviour. How I can do it correctly? Currently in src.conf: WITHOUT_CLANG=yes WITHOUT_CLANG_IS_CC=yes Need recompile world? System build from sources Jun 8. clang -- Jan 9. ___ 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"
[rfc] migrate lagg to an rmlock
Hi, I'd like to commit this to -10. It migrates the if_lagg locking from a rw lock to a rm lock. We see a bit of contention between the transmit and receive sides of lagg during traffic loads (10+ gigabit per second.) Using rmlocks eliminate this. http://people.freebsd.org/~adrian/netflix/20130819-lagg-rmlock-1.diff Thanks, -adrian ___ 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: Diskless setup with NFS_V4
On Fri, Aug 23, 2013 at 09:32:35AM -0400, Rick Macklem wrote: > Slawa Olhovchenkov wrote: > > Its posible use currentle FreeBSD on NFS_V4 root? > > > > Explain: > > > > pxeboot do NFS_v3 (not NFS_v4) mount and pass fd to kernel. > > In this setup kernel can use only configured (established) nfs fh. > > This is not allowed to switch version or some options. > > > > When pxeboot use TFTP (not NFS) kernel (in nfs/bootp_subr.c) do DHCP > > discover and don't allow (in nfs/nfs_diskless.c:nfs_parse_options) > > 'nfsv4' option. > > > > nfs/nfs_diskless.c:nfs_setup_diskless also initialy set > > > > nd3->root_args.flags = (NFSMNT_NFSV3 | NFSMNT_WSIZE | NFSMNT_RSIZE | > > NFSMNT_RESVPORT); > > > > and don't allow 'nfsv4' option. > > > > Where I be wrong? > > How I can use diskless setup with R/O root on NFS_V4 share? > No. There are a couple of problems that would need to be resolved > for an NFSv4 root fs to work. > 1 - An NFSv4 mount needs a unique identifier for the client machine. > It currently uses the host uuid, but that is filled in by a > userland utility run from the root fs (ie. not available soon enough). > Linux uses the ip host address for this, which I believe is bogus > and inappropriate. As I see in /etc/rc.d/hostid first try is 'kenv -q smbios.system.uuid'. This is not need userland utility. > 2 - Without the nfsuserd daemon running, there is currently no uid/gid<-->name > mappings available. This might work, but there would be a lot of "file > owned > by nobody" situations that could cause problems. This is ok for kernel loading and is same as NFSv3. > I suspect this can be fixed by hardwiring a few mappings (root, bin,...), > but there is currently no code to do this. > The Linux solution for this is to put the number in a string on the wire > and the updated draft of RFC3530 (called rfc3530bis, not yet an RFC) > allows > this, so eventually this will be supported by most/all servers. > > Until 1 and 2 are resolved, doing an NFSv4 root fs mount is not practical. > To be honest, I don't see a need for it, since I'm "old fashioned" and still > believe that the root fs should be a small volume of critical system utilities > only, so an NFSv3 mount of it should be sufficient. (ie. If /var and any > other subtrees where files might get byte range locked are on separate > volumes, > I think it should be fine with a NFSv3 root fs mount, even without running > rpc.lockd.) I am try to build many diskless workers with fat software. NFSv4 targeting as more fast. And NFSv4 don't have problem with different UIDs. ___ 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: patch to improve AES-NI performance
Dag-Erling Smrgrav wrote this message on Fri, Aug 23, 2013 at 21:30 +0200: > John-Mark Gurney writes: > > Mike Tancsa writes: > > > John-Mark Gurney writes: > > > > My patch would only effect userland applications that use /dev/crypto... > > > For me its ssh which I think does, no ? > > It looks like it uses OpenSSL for it's crypto, not /dev/crypto... > > It uses OpenSSL engines, which use /dev/crypto. This is why we had to > turn off sandbox mode - a CRIOGET ioctl fails because the sandbox code > sets RLIMIT_NOFILES to 0. If it does use /dev/crypto via OpenSSL (see below), OpenSSL only uses CBC mode, which means that only decryption will see any significant performance improvement w/ my changes... Also, how many people know to load the kernel module cryptodev and aesni to use it? OpenSSL should use AES-NI natively instead of using the cryptodev engine since it'll eliminate kernel calls, etc... Hmm... looking at the source for openssl speed, it looks like it only measures CBC encryption speed, not decryption speed, so you won't be able to see the performance difference between encryption and decryption for CBC mode... I'm not sure that even if you set cryptodev engine on -HEAD that it actually uses it... I just did a: ktrace openssl speed -engine cryptodev aes-128-cbc But this is part of the trace: 4377 openssl CALL ioctl(0x4,CIOCGSESSION,0x7fff9ac0) 4377 openssl RET ioctl -1 errno 22 Invalid argument 4377 openssl CALL close(0x4) 4377 openssl RET close 0 4377 openssl CALL write(0x2,0x7fff9250,0x18) 4377 openssl GIO fd 2 wrote 24 bytes "engine "cryptodev" set. " 4377 openssl RET write 24/0x18 4377 openssl CALL sigaction(SIGALRM,0x7fff9b60,0x7fff9b40) 4377 openssl RET sigaction 0 4377 openssl CALL write(0x2,0x7fff9270,0x2c) 4377 openssl GIO fd 2 wrote 44 bytes "Doing aes-128 cbc for 3s on 16 size blocks: " 4377 openssl RET write 44/0x2c 4377 openssl CALL setitimer(0,0x7fff9b70,0x7fff9b50) 4377 openssl RET setitimer 0 4377 openssl CALL getrusage(0,0x7fff9ab0) 4377 openssl RET getrusage 0 4377 openssl CALL getrusage(0x,0x7fff9ab0) 4377 openssl RET getrusage 0 4377 openssl PSIG SIGALRM caught handler=0x451550 mask=0x0 code=SI_KERNEL 4377 openssl CALL sigaction(SIGALRM,0x7fff9520,0x7fff9500) 4377 openssl RET sigaction 0 4377 openssl CALL sigreturn(0x7fff9580) 4377 openssl RET sigreturn JUSTRETURN 4377 openssl CALL getrusage(0,0x7fff9ab0) 4377 openssl RET getrusage 0 4377 openssl CALL getrusage(0x,0x7fff9ab0) 4377 openssl RET getrusage 0 4377 openssl CALL write(0x2,0x7fff9250,0x20) 4377 openssl GIO fd 2 wrote 32 bytes "18712524 aes-128 cbc's in 2.99s " Shouldn't there be a whole host of ioctl's between the Doing print and the x aes-128 cbc's print if it was doing cryptodev? This does explain why the numbers w/ both engine cryptodev and w/o (kernel module unloaded, so not possible to use) were similar... > (trimming security@ from the cc: list as it's an alias for secteam@ > which is not the appropriate venue for this discussion.) > > 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" -- 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: How to best overload the fileops ?
On Fri, 2013-08-23 at 13:06 -0700, Yuri wrote:
> On 08/23/2013 10:02, John Baldwin wrote:
> > There is something similar: see devfs_ops_f in sys/fs/devfs/devfs_vnops.c.
>
> devfs_ops_f is a local static fileops object for devfs. I don't see how
> is this similar to our situation. devfs doesn't overload any other file
> system, they are a file system on their own.
>
I think the point is that devfs_ops_f provides several devfs-specific
methods and then "inherits" the rest by referencing the standard
vn_whatever functions. Since John recommended that you expose the
fo_whatever methods, I think he's suggesting you build your ops table by
providing your own close method and fill in the rest of the table with
the now-exposed kqueue ops methods.
It's not as neat and clean as "class epollops : public kqueueops {...}"
but it's probably not as bad as using clever macros to try to turn C
into a sort of C++Lite.
-- Ian
> >
> > I don't think we need a generic framework for this, just expose the
> > relevant fo_ methods for kqueue ops and use them in your epoll_ops.
>
> In epoll case, fileops object as a whole should be exposed and used for
> fp->f_ops, except fo_close which is overloaded.
>
> So would you think struct fileops* kqueue_fileops(); be ok then?
>
> Yuri
> ___
> 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: How to best overload the fileops ?
On 08/23/2013 10:02, John Baldwin wrote: There is something similar: see devfs_ops_f in sys/fs/devfs/devfs_vnops.c. devfs_ops_f is a local static fileops object for devfs. I don't see how is this similar to our situation. devfs doesn't overload any other file system, they are a file system on their own. I don't think we need a generic framework for this, just expose the relevant fo_ methods for kqueue ops and use them in your epoll_ops. In epoll case, fileops object as a whole should be exposed and used for fp->f_ops, except fo_close which is overloaded. So would you think struct fileops* kqueue_fileops(); be ok then? Yuri ___ 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: patch to improve AES-NI performance
John-Mark Gurney writes: > Mike Tancsa writes: > > John-Mark Gurney writes: > > > My patch would only effect userland applications that use /dev/crypto... > > For me its ssh which I think does, no ? > It looks like it uses OpenSSL for it's crypto, not /dev/crypto... It uses OpenSSL engines, which use /dev/crypto. This is why we had to turn off sandbox mode - a CRIOGET ioctl fails because the sandbox code sets RLIMIT_NOFILES to 0. (trimming security@ from the cc: list as it's an alias for secteam@ which is not the appropriate venue for this discussion.) 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"
Re: GCC withdraw
On Fri, Aug 23, 2013, at 13:20, Julian Elischer wrote: > On 8/23/13 7:55 PM, Poul-Henning Kamp wrote: > > In message <52174d51.2050...@digsys.bg>, Daniel Kalchev writes: > > > >>> - 9.x gcc default and clang in base; > >>> - 10.x clang default and gcc in ports; > >> I believe this is the best idea so far. As long as these ports work with > >> gcc in ports, that is. > > +1 > > > well as I was forced to go back to gcc to get a compiling & running > kernel on my VPS (xen) > I'm not convinced that clang is there yet. I'd be really grumpy if I > had to go through al the ports hoopla to recompile my kernel. > > Curious which Xen version. I'd like to try to replicate this issue. I've seen FreeBSD 10 run just fine on XenServer 6.0 and 6.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: How to best overload the fileops ?
On Wednesday, August 21, 2013 8:30:05 pm Yuri wrote: > On 08/21/2013 17:10, Mateusz Guzik wrote: > > Short answer is provide epollops with your own fo_close and the rest as > > it is currently in kqueueops. All function are static, but this is not a > > real problem since you have to modify kern_event.c anyway. > > This is exactly what this code I am asking about is doing. > kqueueops functions are all static. This modification allows to export > fileops to child modules. > Since there is nothing similar in the kernel code, I am asking does this > way look ugly or not. There is something similar: see devfs_ops_f in sys/fs/devfs/devfs_vnops.c. I don't think we need a generic framework for this, just expose the relevant fo_ methods for kqueue ops and use them in your epoll_ops. -- John Baldwin ___ 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: OCE driver on Freebsd 10.0-Current
On Friday, August 23, 2013 4:55:06 am Venkata Duvvuru wrote:
> Hi,
>
> I'm running iperf on Emulex's OCE network adapter in Freebsd-10-current. At
> heavy traffic (iperf with ~10 connections), iperf is hanging. The same
> driver is working on all other Freebsd versions.
>
> top -HS shows the below information.
>
> PID USERNAME PRI NICE SIZERES STATE C TIME WCPU COMMAND
>
>11 root 155 ki31 0K 128K CPU44 146:36 100.00% idle{idle:
> cpu4}
>
>12 root -60- 0K 688K CPU66 52:38 100.00% intr{swi4:
> clock}
>
>11 root 155 ki31 0K 128K CPU22 148:42 99.66% idle{idle:
> cpu2}
>
>11 root 155 ki31 0K 128K CPU77 149:24 99.27% idle{idle:
> cpu7}
>
>11 root 155 ki31 0K 128K RUN 0 148:00 99.27% idle{idle:
> cpu0}
>
>11 root 155 ki31 0K 128K CPU11 149:44 99.17% idle{idle:
> cpu1}
>
>11 root 155 ki31 0K 128K CPU55 148:46 99.17% idle{idle:
> cpu5}
>
>11 root 155 ki31 0K 128K CPU33 96:57 89.06% idle{idle:
> cpu3}
>
>11 root 155 ki31 0K 128K RUN 6 149:11 13.87% idle{idle:
> cpu6}
>
>
>
> One interesting thing I observed is that intr is taking 100% on CPU6 when
> iperf hangs, while iperf is running fine, the intr WCPU percentage is very
> low. What does this below line mean? Why intr is 100% on CPU6??
>
> 12 root -60- 0K 688K CPU66 52:38 100.00% intr{swi4:
> clock}
This is the thread that runs timers configured via callout_reset() or
timeout(). Those are handled differently in 10 than in older branches.
I suspect you have a callout that is rescheduling itself constantly or
some such.
--
John Baldwin
___
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: patch to improve AES-NI performance
Mike Tancsa wrote this message on Fri, Aug 23, 2013 at 14:19 -0400: > On 8/23/2013 2:05 PM, John-Mark Gurney wrote: > >> Speeding up userland AES is very interesting to me for a couple of apps. > >> If there is a proper way I should test on RELENG_9, please let me know > >> as I am few boxes that I would be happy to test/deploy on. > > > > My patch would only effect userland applications that use /dev/crypto... > > > > If they do their own AES-NI work, then there isn't any improvement... > > For me its ssh which I think does, no ? It looks like it uses OpenSSL for it's crypto, not /dev/crypto... Also, my work was done improving AES-XTS which isn't used by OpenSSH... OpenSSH looks like it uses either AES-GCM or AES-CTR, neither of which are supported by /dev/crypto... My gcc patch does include PCLMULQDQ support, which will be helpful for improving the performance of AES-GCM, and it looks like OpenSSL 1.0.1 has support, which is in HEAD, not RELENG_9 yet... So, if you want better ssh performance, install OpenSSL 1.0.1 and compile OpenSSH against it... -- 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: patch to improve AES-NI performance
According to John-Mark Gurney: pjd did not merge (as he said at the time of commit) r226839 & r226839. Is there any objection to merge these two (and possibly 247061 as well -- copyright update)? > > You repeated r226839 twice. What is the correct second revision? You are right, I wanted to say r226837 which is the "code" one. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.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: GCC withdraw
On 8/23/13 7:55 PM, Poul-Henning Kamp wrote: In message <52174d51.2050...@digsys.bg>, Daniel Kalchev writes: - 9.x gcc default and clang in base; - 10.x clang default and gcc in ports; I believe this is the best idea so far. As long as these ports work with gcc in ports, that is. +1 well as I was forced to go back to gcc to get a compiling & running kernel on my VPS (xen) I'm not convinced that clang is there yet. I'd be really grumpy if I had to go through al the ports hoopla to recompile my kernel. ___ 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: patch to improve AES-NI performance
On 8/23/2013 2:05 PM, John-Mark Gurney wrote: >> Speeding up userland AES is very interesting to me for a couple of apps. >> If there is a proper way I should test on RELENG_9, please let me know >> as I am few boxes that I would be happy to test/deploy on. > > My patch would only effect userland applications that use /dev/crypto... > > If they do their own AES-NI work, then there isn't any improvement... For me its ssh which I think does, no ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: patch to add AES intrinsics to gcc
On 8/23/13 8:26 PM, Andriy Gapon wrote: on 23/08/2013 14:06 David Chisnall said the following: Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in its atomic generation so you can't use it sensibly without lots of inline assembly (which it doesn't support for newer architectures) for multithreaded things. Our libstdc++ is ancient and doesn't work with modern C++ codebases. On the other hand these tools are perfect for building FreeBSD kernel and base. Extrapolating my experience with base GCC I am very confident in it as a FreeBSD development tool. Extrapolating my experience with Clang I am not yet confident in it as a FreeBSD development tool. I do not care about C11, C++11 and modern C++ codebases. I care about what's in /usr/src and what gets compiled by buildkernel/buildworld. That's just me, of course. But, OTOH, those who care modern C++ codebases should be perfectly capable to install a compiler from ports or switch to clang as their default compiler. +1 I'd like to see it still be "there if you need it" in 10 in 11 it's in ports ___ 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: patch to improve AES-NI performance
Mike Tancsa wrote this message on Fri, Aug 23, 2013 at 11:26 -0400: > On 8/23/2013 11:16 AM, Ollivier Robert wrote: > > According to John-Mark Gurney on Thu, Aug 22, 2013 at 01:20:27PM -0700: > >> I have developed a patch to improve AES-NI performance. If you took the > >> AES-XTS algorithm into userland (no cryptodev or geli usage), these > >> changes improve the performance over 10x in my tests (from ~150MB/sec to > >> over 2GB/sec). In tests of geli on gnop, the performance improvement is > >> more moderate, around 4x due to overhead in other parts of the system. > > > > Thanks a lot for this patch. Now, looking at it in the stable/9 context, I > > can see that pjd did not merge (as he said at the time of commit) r226839 & > > r226839. Is there any objection to merge these two (and possibly 247061 as > > well -- copyright update)? > > > > I ask that for two reasons, these two revisions are speeding up AES-NI > > quite a bit and they are required for using jmg's patch. > > > > I'll be testing all this in the next few days on my new AES-NI enabled > > machine. > > > > Speeding up userland AES is very interesting to me for a couple of apps. > If there is a proper way I should test on RELENG_9, please let me know > as I am few boxes that I would be happy to test/deploy on. My patch would only effect userland applications that use /dev/crypto... If they do their own AES-NI work, then there isn't any improvement... -- 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: patch to improve AES-NI performance
Ollivier Robert wrote this message on Fri, Aug 23, 2013 at 17:16 +0200: > According to John-Mark Gurney on Thu, Aug 22, 2013 at 01:20:27PM -0700: > > I have developed a patch to improve AES-NI performance. If you took the > > AES-XTS algorithm into userland (no cryptodev or geli usage), these > > changes improve the performance over 10x in my tests (from ~150MB/sec to > > over 2GB/sec). In tests of geli on gnop, the performance improvement is > > more moderate, around 4x due to overhead in other parts of the system. > > Thanks a lot for this patch. Now, looking at it in the stable/9 context, I > can see that pjd did not merge (as he said at the time of commit) r226839 & > r226839. Is there any objection to merge these two (and possibly 247061 as > well -- copyright update)? You repeated r226839 twice. What is the correct second revision? And both the ones above are just copyright updates, no functionality changes... > I ask that for two reasons, these two revisions are speeding up AES-NI quite > a bit and they are required for using jmg's patch. > > I'll be testing all this in the next few days on my new AES-NI enabled > machine. -- 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: GCC withdraw (was: Re: patch to add AES intrinsics to gcc)
> As for me I expect something like this: > . 9.x gcc default and clang in base; > . 10.x clang default and gcc in base; > . 11.x gcc withdraw. There is also the concern whether clang in base will reliably build gcc required for some ports, and then there are those CPU architectures for which clang is nonexistent or not ready. Regarding those ports that build with the ancient gcc 4.2.1 but not with newer versions, that has to be considered a bug. Consider that Linux and the other BSDs use newer versions of gcc to build their base system and ports or pkgsrc. 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: patch to improve AES-NI performance
On 8/23/2013 11:16 AM, Ollivier Robert wrote: > According to John-Mark Gurney on Thu, Aug 22, 2013 at 01:20:27PM -0700: >> I have developed a patch to improve AES-NI performance. If you took the >> AES-XTS algorithm into userland (no cryptodev or geli usage), these >> changes improve the performance over 10x in my tests (from ~150MB/sec to >> over 2GB/sec). In tests of geli on gnop, the performance improvement is >> more moderate, around 4x due to overhead in other parts of the system. > > Thanks a lot for this patch. Now, looking at it in the stable/9 context, I > can see that pjd did not merge (as he said at the time of commit) r226839 & > r226839. Is there any objection to merge these two (and possibly 247061 as > well -- copyright update)? > > I ask that for two reasons, these two revisions are speeding up AES-NI quite > a bit and they are required for using jmg's patch. > > I'll be testing all this in the next few days on my new AES-NI enabled > machine. > Speeding up userland AES is very interesting to me for a couple of apps. If there is a proper way I should test on RELENG_9, please let me know as I am few boxes that I would be happy to test/deploy on. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: Question about socket timeouts
On Friday, August 23, 2013 9:53:12 am Davide Italiano wrote:
> On Fri, Aug 23, 2013 at 3:45 PM, John Baldwin wrote:
> > On Friday, August 23, 2013 2:27:58 am Vitja Makarov wrote:
> >> 2013/8/22 John Baldwin :
> >> > On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote:
> >> >> 2013/8/21 John Baldwin :
> >> >> > On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote:
> >> >> >> On Mon, 19 Aug 2013, Adrian Chadd wrote:
> >> >> >>
> >> >> >> > Yes! Please file a PR!
> >> >> >>
> >> >> >> This sorta implies that both are acceptable (although,
> >> >> >> the Linux behavior seems more desirable).
> >> >> >>
> >> >> >>http://austingroupbugs.net/view.php?id=369
> >> >> >
> >> >> > No, that says "round up", so it does mean that the requested timeout
> >> >> > should be the minimum amount slept. tvtohz() does this. Really odd
> >> >> > that the socket code is using its own version of this rather than
> >> >> > tvtohz().
> >> >> >
> >> >> > Oh, I bet this just predates tvtohz(). Interesting that it keeps
getting
> >> >> > bug fixes in its history that simply using tvtohz() would have
solved.
> >> >> >
> >> >> > Try this:
> >> >> >
> >> >> > Index: uipc_socket.c
> >> >> > ===
> >> >> > --- uipc_socket.c (revision 254570)
> >> >> > +++ uipc_socket.c (working copy)
> >> >> > @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt
*sopt)
> >> >> > if (error)
> >> >> > goto bad;
> >> >> >
> >> >> > - /* assert(hz > 0); */
> >> >> > if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX /
hz ||
> >> >> > tv.tv_usec < 0 || tv.tv_usec >= 100)
{
> >> >> > error = EDOM;
> >> >> > goto bad;
> >> >> > }
> >> >> > - /* assert(tick > 0); */
> >> >> > - /* assert(ULONG_MAX - INT_MAX >= 100);
*/
> >> >> > - val = (u_long)(tv.tv_sec * hz) + tv.tv_usec
/ tick;
> >> >> > - if (val > INT_MAX) {
> >> >> > + val = tvtohz(&tv);
> >> >> > + if (val == INT_MAX) {
> >> >> > error = EDOM;
> >> >> > goto bad;
> >> >> > }
> >> >> > - if (val == 0 && tv.tv_usec != 0)
> >> >> > - val = 1;
> >> >> >
> >> >> > switch (sopt->sopt_name) {
> >> >> > case SO_SNDTIMEO:
> >> >> >
> >> >>
> >> >> That must help. But I want to see the issue solved in the next
> >> >> release. I can't apply patch to the production system. Btw in
> >> >> production environment we have kern.hz set to 1000 so it's not a
> >> >> problem there.
> >> >
> >> > Can you test this in some way in a test environment?
> >> >
> >>
> >> Ok, sorry for posting out of the list.
> >>
> >> Simple test program is attached. Without your patch timeout expires in
> >> about 20ms. With it it's ~40ms.
> >>
> >> 40 instead of 30 is beacuse of odd tick added by tvtohz().
> >
> > Ok, thanks. tvtohz() will be good to MFC (and I will do that), but for
> > HEAD I think we can fix this to use a precise timeout. I've cc'd davide@
> > so he can take a look at that.
> >
> > --
> > John Baldwin
>
> Hi,
> I think I can switch this code to new timeout KPI, but this will
> require the timeout field of 'struct sockbuf' to be changed from 'int'
> to 'sbintime_t' which breaks binary compatibility. Do you have any
> strong objections about this? If any, I would like this to happen ABI
> freeze, so it looks like this is the right moment.
This should be fine to change now, it just can't be MFC'd (which we can't
do anyway).
--
John Baldwin
___
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 reboot
Hi current, I have FreeBSD 10.0-CURRENT #5 r254404 on my laptop. During reboot, I get the following LOR. Could someone please fix this? Thanks! Ke Sun Syncing disks, vnodes remaining...0 0 0 0 0 0 done All buffers synced. lock order reversal: 1st 0xfe00094bd5f0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237 2nd 0xfe000903b418 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1411 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xff81a7582470 kdb_backtrace() at kdb_backtrace+0x39/frame 0xff81a7582520 witness_checkorder() at witness_checkorder+0xd4f/frame 0xff81a75825b0 __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xff81a75826e0 vop_stdlock() at vop_stdlock+0x3c/frame 0xff81a7582700 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xff81a7582730 _vn_lock() at _vn_lock+0xab/frame 0xff81a75827a0 ffs_flushfiles() at ffs_flushfiles+0x88/frame 0xff81a7582800 ffs_unmount() at ffs_unmount+0x162/frame 0xff81a7582860 dounmount() at dounmount+0x39e/frame 0xff81a75828e0 vfs_unmountall() at vfs_unmountall+0x61/frame 0xff81a7582910 kern_reboot() at kern_reboot+0x548/frame 0xff81a7582980 sys_reboot() at sys_reboot+0x58/frame 0xff81a75829a0 amd64_syscall() at amd64_syscall+0x265/frame 0xff81a7582ab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xff81a7582ab0 --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x80085f5ec, rsp = 0x7fffd9b8, rbp = 0x7fffdb20 --- ___ 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: Question about socket timeouts
2013/8/23 Davide Italiano :
> On Fri, Aug 23, 2013 at 3:45 PM, John Baldwin wrote:
>> On Friday, August 23, 2013 2:27:58 am Vitja Makarov wrote:
>>> 2013/8/22 John Baldwin :
>>> > On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote:
>>> >> 2013/8/21 John Baldwin :
>>> >> > On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote:
>>> >> >> On Mon, 19 Aug 2013, Adrian Chadd wrote:
>>> >> >>
>>> >> >> > Yes! Please file a PR!
>>> >> >>
>>> >> >> This sorta implies that both are acceptable (although,
>>> >> >> the Linux behavior seems more desirable).
>>> >> >>
>>> >> >>http://austingroupbugs.net/view.php?id=369
>>> >> >
>>> >> > No, that says "round up", so it does mean that the requested timeout
>>> >> > should be the minimum amount slept. tvtohz() does this. Really odd
>>> >> > that the socket code is using its own version of this rather than
>>> >> > tvtohz().
>>> >> >
>>> >> > Oh, I bet this just predates tvtohz(). Interesting that it keeps
>>> >> > getting
>>> >> > bug fixes in its history that simply using tvtohz() would have solved.
>>> >> >
>>> >> > Try this:
>>> >> >
>>> >> > Index: uipc_socket.c
>>> >> > ===
>>> >> > --- uipc_socket.c (revision 254570)
>>> >> > +++ uipc_socket.c (working copy)
>>> >> > @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt
>>> >> > *sopt)
>>> >> > if (error)
>>> >> > goto bad;
>>> >> >
>>> >> > - /* assert(hz > 0); */
>>> >> > if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX / hz
>>> >> > ||
>>> >> > tv.tv_usec < 0 || tv.tv_usec >= 100) {
>>> >> > error = EDOM;
>>> >> > goto bad;
>>> >> > }
>>> >> > - /* assert(tick > 0); */
>>> >> > - /* assert(ULONG_MAX - INT_MAX >= 100); */
>>> >> > - val = (u_long)(tv.tv_sec * hz) + tv.tv_usec /
>>> >> > tick;
>>> >> > - if (val > INT_MAX) {
>>> >> > + val = tvtohz(&tv);
>>> >> > + if (val == INT_MAX) {
>>> >> > error = EDOM;
>>> >> > goto bad;
>>> >> > }
>>> >> > - if (val == 0 && tv.tv_usec != 0)
>>> >> > - val = 1;
>>> >> >
>>> >> > switch (sopt->sopt_name) {
>>> >> > case SO_SNDTIMEO:
>>> >> >
>>> >>
>>> >> That must help. But I want to see the issue solved in the next
>>> >> release. I can't apply patch to the production system. Btw in
>>> >> production environment we have kern.hz set to 1000 so it's not a
>>> >> problem there.
>>> >
>>> > Can you test this in some way in a test environment?
>>> >
>>>
>>> Ok, sorry for posting out of the list.
>>>
>>> Simple test program is attached. Without your patch timeout expires in
>>> about 20ms. With it it's ~40ms.
>>>
>>> 40 instead of 30 is beacuse of odd tick added by tvtohz().
>>
>> Ok, thanks. tvtohz() will be good to MFC (and I will do that), but for
>> HEAD I think we can fix this to use a precise timeout. I've cc'd davide@
>> so he can take a look at that.
>>
>> --
>> John Baldwin
>
> Hi,
> I think I can switch this code to new timeout KPI, but this will
> require the timeout field of 'struct sockbuf' to be changed from 'int'
> to 'sbintime_t' which breaks binary compatibility. Do you have any
> strong objections about this? If any, I would like this to happen ABI
> freeze, so it looks like this is the right moment.
>
I think that for socket's timeouts it's ok to have a HZ-precision. It
would be much more important to implement high-precision timeouts for
select() and friends, if it's not done yet (sorry I'm running 9.1).
--
vitja.
___
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: GCC withdraw (was: Re: patch to add AES intrinsics to gcc)
On Fri, Aug 23, 2013 at 03:02:18PM +0400, Boris Samorodov wrote: > 23.08.2013 13:16, David Chisnall ??: > >> I have a patch that I intend to commit before the 10.0 code >> slush that removes GCC and libstdc++ from the default build >> on platforms where clang is the system compiler. We definitely >> don't want to be supporting our 6-year-old versions of these >> for the lifetime of the 10.x branch. > > Isn't it a POLA violation? > > As for me I expect something like this: > . 9.x gcc default and clang in base; > . 10.x clang default and gcc in base; > . 11.x gcc withdraw. > +1 -- 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: patch to improve AES-NI performance
According to John-Mark Gurney on Thu, Aug 22, 2013 at 01:20:27PM -0700: > I have developed a patch to improve AES-NI performance. If you took the > AES-XTS algorithm into userland (no cryptodev or geli usage), these > changes improve the performance over 10x in my tests (from ~150MB/sec to > over 2GB/sec). In tests of geli on gnop, the performance improvement is > more moderate, around 4x due to overhead in other parts of the system. Thanks a lot for this patch. Now, looking at it in the stable/9 context, I can see that pjd did not merge (as he said at the time of commit) r226839 & r226839. Is there any objection to merge these two (and possibly 247061 as well -- copyright update)? I ask that for two reasons, these two revisions are speeding up AES-NI quite a bit and they are required for using jmg's patch. I'll be testing all this in the next few days on my new AES-NI enabled machine. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.net In memoriam to Ondine, our 2nd child: http://ondine.keltia.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: GCC withdraw (was: Re: patch to add AES intrinsics to gcc)
On Aug 23, 2013, at 7:54 AM, David Chisnall wrote: > On 23 Aug 2013, at 14:52, Warner Losh wrote: >> No. That breaks non x86 architecutres. gcc must remain in base for now, or >> there's no bootstrap ability. Nobody has done the lifting to cleanly >> integrate gcc as a port into buildworld, althogh Brooks' work gets us most >> of the way there. > > We've been using brooks' work to build the base system with an out-of-tree > toolchain for some time now... I'll have to try the native build part of the cycle then... Early versions of the patch failed when you cross built the target, installed the target, but wound up with no compilers to bootstrap the external toolchains with to do native builds on the target. 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: patch to add AES intrinsics to gcc
On Aug 23, 2013, at 6:30 AM, Ian Lepore wrote: > On Fri, 2013-08-23 at 12:06 +0100, David Chisnall wrote: >> On 23 Aug 2013, at 11:42, Julian Elischer wrote: >> >>> no, I believe we have said that 10 would ship with clang by default. NO >>> mention was made about gcc being absent, and I am uncomfortable with taking >>> that step yet. Having gcc just present, will not hurt you.. even after it >>> is gone we will need to support those who will be replacing clang with >>> newer versions of gcc in hteir own products. >> >> The plan is not to delete gcc from the tree, it is to disable building gcc >> by default when clang is the system compiler. If you are building products >> then you are perfectly at liberty to set WITH_GCC=yes in your src.conf. >> >> Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in its >> atomic generation so you can't use it sensibly without lots of inline >> assembly (which it doesn't support for newer architectures) for >> multithreaded things. >> >> Our libstdc++ is ancient and doesn't work with modern C++ codebases. >> Putting them in the base system means that people will use them. If anyone >> wants them to remain, then speak now and this will be taken as your >> volunteering to: >> >> - Maintain our forks of both gcc and libstdc++ >> - Handle every single PR that is filed by people using these >> >> If you are willing to do this, then that's great. If not, then you are >> asking other people to support ancient codebases that they are not using. >> >> David >> > > I don't understand, you start by pointing out that gcc will still be in > the tree and usable, then you go on to point out that it it won't be > supported or maintained unless someone volunteers to do that, and you > seem to be doing your best to discourage anyone from volunteering. > Doesn't that sort of moot the point that the source isn't being deleted? If it is in the tree it's gotta work. And it has to be in the tree for !x86 architectures. So on or off for x86 doesn't really add to the load at all, and the C++/C11 stuff is a red herring. If it isn't cc, then people wanting clang by default won't care... And besides, ports aren't completely ready to kill it, so it has to work for them. 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: patch to add AES intrinsics to gcc
Hi! If firewire code doesn't build on clang correctly, have you filed a bug so it gets looked at before 10.0 is released? that's pretty broken code/behaviour. -adrian On 23 August 2013 04:46, Slawa Olhovchenkov wrote: > On Fri, Aug 23, 2013 at 06:42:21PM +0800, Julian Elischer wrote: > > > On 8/23/13 6:35 PM, David Chisnall wrote: > > > On 23 Aug 2013, at 10:58, Bernhard Fr?hlich wrote: > > > > > >> I don't know if you are aware that IF you really do that we will have > serious > > >> problems to ship packages for 10. USE_GCC=any is the fallback in the > > >> portstree for all ports that are unable to build with clang which was > introduced > > >> when HEAD switched to clang as default cc. Right now there are 150 > ports in > > >> the tree that use this fallback and quite a few of them are high > profile ports: > > >> > > >> the highlights: > > >> audio/nas devel/mingw32-binutils emulators/qemu > emulators/virtualbox-ose > > >> emulators/wine lang/go lang/v8 mail/courier math/fftw3 > multimedia/libxine > > >> multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 > > >> security/clamav > > >> > > >> the full list: > > >> http://dpaste.com/1354075/ > > >> > > >> A possible hack could be to add a check for USE_GCC=any to behave like > > >> a USE_GCC=yes on HEAD on the affected platforms. This pulls in > lang/gcc > > >> from ports for a lot of people on HEAD I suppose. > > >> > > >> We certainly need to do that switch to remove the ancient gcc from > base > > >> some time but with my portmgr hat on I can only say we don't plan to > do that > > >> before 10.0 especially not if we are only talking about a few weeks > time window. > > > That is unfortunate. We have said for over a year that 10.0 should > not ship with gcc. I can delay committing the patch to flip the switch > until later in the code slush, if re approves, but ports that require gcc > should be building with gcc from ports (which will also improve code > quality, as gcc 4.6/7 produce significantly better code than 4.2.1). > > no, I believe we have said that 10 would ship with clang by default. > > 10 from this winner have broken firewire code when building by clang > -- cannot resume from sleep. > ___ > 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: GCC withdraw (was: Re: patch to add AES intrinsics to gcc)
On 23 Aug 2013, at 14:52, Warner Losh wrote: > No. That breaks non x86 architecutres. gcc must remain in base for now, or > there's no bootstrap ability. Nobody has done the lifting to cleanly > integrate gcc as a port into buildworld, althogh Brooks' work gets us most of > the way there. We've been using brooks' work to build the base system with an out-of-tree toolchain for some time now... David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Question about socket timeouts
On Fri, Aug 23, 2013 at 3:45 PM, John Baldwin wrote:
> On Friday, August 23, 2013 2:27:58 am Vitja Makarov wrote:
>> 2013/8/22 John Baldwin :
>> > On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote:
>> >> 2013/8/21 John Baldwin :
>> >> > On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote:
>> >> >> On Mon, 19 Aug 2013, Adrian Chadd wrote:
>> >> >>
>> >> >> > Yes! Please file a PR!
>> >> >>
>> >> >> This sorta implies that both are acceptable (although,
>> >> >> the Linux behavior seems more desirable).
>> >> >>
>> >> >>http://austingroupbugs.net/view.php?id=369
>> >> >
>> >> > No, that says "round up", so it does mean that the requested timeout
>> >> > should be the minimum amount slept. tvtohz() does this. Really odd
>> >> > that the socket code is using its own version of this rather than
>> >> > tvtohz().
>> >> >
>> >> > Oh, I bet this just predates tvtohz(). Interesting that it keeps
>> >> > getting
>> >> > bug fixes in its history that simply using tvtohz() would have solved.
>> >> >
>> >> > Try this:
>> >> >
>> >> > Index: uipc_socket.c
>> >> > ===
>> >> > --- uipc_socket.c (revision 254570)
>> >> > +++ uipc_socket.c (working copy)
>> >> > @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt
>> >> > *sopt)
>> >> > if (error)
>> >> > goto bad;
>> >> >
>> >> > - /* assert(hz > 0); */
>> >> > if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX / hz ||
>> >> > tv.tv_usec < 0 || tv.tv_usec >= 100) {
>> >> > error = EDOM;
>> >> > goto bad;
>> >> > }
>> >> > - /* assert(tick > 0); */
>> >> > - /* assert(ULONG_MAX - INT_MAX >= 100); */
>> >> > - val = (u_long)(tv.tv_sec * hz) + tv.tv_usec /
>> >> > tick;
>> >> > - if (val > INT_MAX) {
>> >> > + val = tvtohz(&tv);
>> >> > + if (val == INT_MAX) {
>> >> > error = EDOM;
>> >> > goto bad;
>> >> > }
>> >> > - if (val == 0 && tv.tv_usec != 0)
>> >> > - val = 1;
>> >> >
>> >> > switch (sopt->sopt_name) {
>> >> > case SO_SNDTIMEO:
>> >> >
>> >>
>> >> That must help. But I want to see the issue solved in the next
>> >> release. I can't apply patch to the production system. Btw in
>> >> production environment we have kern.hz set to 1000 so it's not a
>> >> problem there.
>> >
>> > Can you test this in some way in a test environment?
>> >
>>
>> Ok, sorry for posting out of the list.
>>
>> Simple test program is attached. Without your patch timeout expires in
>> about 20ms. With it it's ~40ms.
>>
>> 40 instead of 30 is beacuse of odd tick added by tvtohz().
>
> Ok, thanks. tvtohz() will be good to MFC (and I will do that), but for
> HEAD I think we can fix this to use a precise timeout. I've cc'd davide@
> so he can take a look at that.
>
> --
> John Baldwin
Hi,
I think I can switch this code to new timeout KPI, but this will
require the timeout field of 'struct sockbuf' to be changed from 'int'
to 'sbintime_t' which breaks binary compatibility. Do you have any
strong objections about this? If any, I would like this to happen ABI
freeze, so it looks like this is the right moment.
Thanks,
--
Davide
"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare
___
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: GCC withdraw (was: Re: patch to add AES intrinsics to gcc)
On Aug 23, 2013, at 5:16 AM, Kurt Jaeger wrote: > Hi! > >>> I have a patch that I intend to commit before the 10.0 code >>> slush that removes GCC and libstdc++ from the default build on >>> platforms where clang is the system compiler. We definitely don't >>> want to be supporting our 6-year-old versions of these for the >>> lifetime of the 10.x branch. >> >> Isn't it a POLA violation? >> >> As for me I expect something like this: >> . 9.x gcc default and clang in base; >> . 10.x clang default and gcc in base; >> . 11.x gcc withdraw. > > If the 150 ports that only work with gcc, all work with a ports > gcc and do not need the gcc from base, would the following be OK ? > > - 9.x gcc default and clang in base; > - 10.x clang default and gcc in ports; No. That breaks non x86 architecutres. gcc must remain in base for now, or there's no bootstrap ability. Nobody has done the lifting to cleanly integrate gcc as a port into buildworld, althogh Brooks' work gets us most of the way there. 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: patch to add AES intrinsics to gcc
On Aug 23, 2013, at 5:06 AM, David Chisnall wrote: > On 23 Aug 2013, at 11:42, Julian Elischer wrote: > >> no, I believe we have said that 10 would ship with clang by default. NO >> mention was made about gcc being absent, and I am uncomfortable with taking >> that step yet. Having gcc just present, will not hurt you.. even after it >> is gone we will need to support those who will be replacing clang with >> newer versions of gcc in hteir own products. > > The plan is not to delete gcc from the tree, it is to disable building gcc by > default when clang is the system compiler. If you are building products then > you are perfectly at liberty to set WITH_GCC=yes in your src.conf. > > Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in its > atomic generation so you can't use it sensibly without lots of inline > assembly (which it doesn't support for newer architectures) for multithreaded > things. > > Our libstdc++ is ancient and doesn't work with modern C++ codebases. Putting > them in the base system means that people will use them. If anyone wants > them to remain, then speak now and this will be taken as your volunteering to: > > - Maintain our forks of both gcc and libstdc++ > - Handle every single PR that is filed by people using these > > If you are willing to do this, then that's great. If not, then you are > asking other people to support ancient codebases that they are not using. Well, it isn't quite that cut and dried. The date that gcc is from is not relevant. It works today for most of the code out there. True, it doesn't have the latest features that a small fraction of the code needs, but it works well enough. And it also needs to be there for some upgrade paths. There's a use for gcc, and it will likely be needed for these paths. As such, it has to work. Doesn't matter if it is built by default or not, it simply has to keep working as well as it has been working for the past 5 years to fill these roles. For these tasks the nice C++ things simply don't matter or aren't relevant. c11 features can't be put into the base for some time still because of the issues on other architectures. We *HAVE* to have gcc on the other architectures. clang simply isn't ready for MIPS, and has several outstanding problems on ARM. While work is ongoing in these areas, clang simply won't be in as good a shape for !x86 as it is for x86 in the 10.0 time frame. So even if gcc is turned off by default in 10 on x86, it still has to work at least well enough to build the system and bootstrap clang. Turning it off by default or on by default doesn't change this, and the feature set that is used in 10 will basically be frozen soon, and the non-x86 architectures will require the MI parts continue to work. I don't see much decay that can happen in the x86MD parts that would break it... 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: Question about socket timeouts
On Friday, August 23, 2013 2:27:58 am Vitja Makarov wrote:
> 2013/8/22 John Baldwin :
> > On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote:
> >> 2013/8/21 John Baldwin :
> >> > On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote:
> >> >> On Mon, 19 Aug 2013, Adrian Chadd wrote:
> >> >>
> >> >> > Yes! Please file a PR!
> >> >>
> >> >> This sorta implies that both are acceptable (although,
> >> >> the Linux behavior seems more desirable).
> >> >>
> >> >>http://austingroupbugs.net/view.php?id=369
> >> >
> >> > No, that says "round up", so it does mean that the requested timeout
> >> > should be the minimum amount slept. tvtohz() does this. Really odd
> >> > that the socket code is using its own version of this rather than
> >> > tvtohz().
> >> >
> >> > Oh, I bet this just predates tvtohz(). Interesting that it keeps getting
> >> > bug fixes in its history that simply using tvtohz() would have solved.
> >> >
> >> > Try this:
> >> >
> >> > Index: uipc_socket.c
> >> > ===
> >> > --- uipc_socket.c (revision 254570)
> >> > +++ uipc_socket.c (working copy)
> >> > @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt *sopt)
> >> > if (error)
> >> > goto bad;
> >> >
> >> > - /* assert(hz > 0); */
> >> > if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX / hz ||
> >> > tv.tv_usec < 0 || tv.tv_usec >= 100) {
> >> > error = EDOM;
> >> > goto bad;
> >> > }
> >> > - /* assert(tick > 0); */
> >> > - /* assert(ULONG_MAX - INT_MAX >= 100); */
> >> > - val = (u_long)(tv.tv_sec * hz) + tv.tv_usec /
> >> > tick;
> >> > - if (val > INT_MAX) {
> >> > + val = tvtohz(&tv);
> >> > + if (val == INT_MAX) {
> >> > error = EDOM;
> >> > goto bad;
> >> > }
> >> > - if (val == 0 && tv.tv_usec != 0)
> >> > - val = 1;
> >> >
> >> > switch (sopt->sopt_name) {
> >> > case SO_SNDTIMEO:
> >> >
> >>
> >> That must help. But I want to see the issue solved in the next
> >> release. I can't apply patch to the production system. Btw in
> >> production environment we have kern.hz set to 1000 so it's not a
> >> problem there.
> >
> > Can you test this in some way in a test environment?
> >
>
> Ok, sorry for posting out of the list.
>
> Simple test program is attached. Without your patch timeout expires in
> about 20ms. With it it's ~40ms.
>
> 40 instead of 30 is beacuse of odd tick added by tvtohz().
Ok, thanks. tvtohz() will be good to MFC (and I will do that), but for
HEAD I think we can fix this to use a precise timeout. I've cc'd davide@
so he can take a look at that.
--
John Baldwin
___
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: patch to add AES intrinsics to gcc
On 08/23/13 07:30, Ian Lepore wrote: On Fri, 2013-08-23 at 12:06 +0100, David Chisnall wrote: On 23 Aug 2013, at 11:42, Julian Elischer wrote: no, I believe we have said that 10 would ship with clang by default. NO mention was made about gcc being absent, and I am uncomfortable with taking that step yet. Having gcc just present, will not hurt you.. even after it is gone we will need to support those who will be replacing clang with newer versions of gcc in hteir own products. The plan is not to delete gcc from the tree, it is to disable building gcc by default when clang is the system compiler. If you are building products then you are perfectly at liberty to set WITH_GCC=yes in your src.conf. Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in its atomic generation so you can't use it sensibly without lots of inline assembly (which it doesn't support for newer architectures) for multithreaded things. Our libstdc++ is ancient and doesn't work with modern C++ codebases. Putting them in the base system means that people will use them. If anyone wants them to remain, then speak now and this will be taken as your volunteering to: - Maintain our forks of both gcc and libstdc++ - Handle every single PR that is filed by people using these If you are willing to do this, then that's great. If not, then you are asking other people to support ancient codebases that they are not using. David I don't understand, you start by pointing out that gcc will still be in the tree and usable, then you go on to point out that it it won't be supported or maintained unless someone volunteers to do that, and you seem to be doing your best to discourage anyone from volunteering. Doesn't that sort of moot the point that the source isn't being deleted? It has to stay in the tree and usable -- at least for a while -- because not all of our Tier-2 platforms can build with clang yet. Those platforms, however, are typically not the ones that will require patching and maintenance (UltraSPARC 3s are not gaining any new features). I think that turning it off frees us during the 10.x release lifetime to actually remove it if the maintenance burden becomes too high -- or to revert our decision to turn it off at any time. Having it on by default locks us in to maintaining it for the lifetime of the branch. -Nathan ___ 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: Diskless setup with NFS_V4
Slawa Olhovchenkov wrote: > Its posible use currentle FreeBSD on NFS_V4 root? > > Explain: > > pxeboot do NFS_v3 (not NFS_v4) mount and pass fd to kernel. > In this setup kernel can use only configured (established) nfs fh. > This is not allowed to switch version or some options. > > When pxeboot use TFTP (not NFS) kernel (in nfs/bootp_subr.c) do DHCP > discover and don't allow (in nfs/nfs_diskless.c:nfs_parse_options) > 'nfsv4' option. > > nfs/nfs_diskless.c:nfs_setup_diskless also initialy set > > nd3->root_args.flags = (NFSMNT_NFSV3 | NFSMNT_WSIZE | NFSMNT_RSIZE | > NFSMNT_RESVPORT); > > and don't allow 'nfsv4' option. > > Where I be wrong? > How I can use diskless setup with R/O root on NFS_V4 share? No. There are a couple of problems that would need to be resolved for an NFSv4 root fs to work. 1 - An NFSv4 mount needs a unique identifier for the client machine. It currently uses the host uuid, but that is filled in by a userland utility run from the root fs (ie. not available soon enough). Linux uses the ip host address for this, which I believe is bogus and inappropriate. 2 - Without the nfsuserd daemon running, there is currently no uid/gid<-->name mappings available. This might work, but there would be a lot of "file owned by nobody" situations that could cause problems. I suspect this can be fixed by hardwiring a few mappings (root, bin,...), but there is currently no code to do this. The Linux solution for this is to put the number in a string on the wire and the updated draft of RFC3530 (called rfc3530bis, not yet an RFC) allows this, so eventually this will be supported by most/all servers. Until 1 and 2 are resolved, doing an NFSv4 root fs mount is not practical. To be honest, I don't see a need for it, since I'm "old fashioned" and still believe that the root fs should be a small volume of critical system utilities only, so an NFSv3 mount of it should be sufficient. (ie. If /var and any other subtrees where files might get byte range locked are on separate volumes, I think it should be fine with a NFSv3 root fs mount, even without running rpc.lockd.) rick > ___ > 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: stable/8 kernel-toolchain fails with clang on head
On Aug 23, 2013, at 14:16, Andriy Gapon wrote: > $ /usr/obj/usr/devel/svn/base/stable/8/make.amd64/make kernel-toolchain > WITHOUT_CLANG=1 __MAKE_CONF=/dev/null SRCCONF=/dev/null ... > It seems that the problem is specific to stable/8 and is caused by missing > -std=gnu89. And that seems to be caused by -DNO_WARNS that is used for > toolchain target. > Dependency between NO_WARNS and CSTD was removed in r198335 + r198365, but > those > were never MFC-ed. > > What do you think? Yes, I agree those should be MFC'd to stable/8. -Dimitry ___ 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: patch to add AES intrinsics to gcc
on 23/08/2013 15:56 David Chisnall said the following: > So you don't want a working debugger? Our gdb doesn't work at all on MIPS > and barely works with code compiled with clang or a recent gcc. I am capable of using devel/gdb. Or do you mean kernel debugger? > We are > planning on importing LLDB soon (Ed Maste has been working on it, funded by > the FreeBSD Foundation), and it is a C++11 code base. It will not build with > our gcc or with our libstdc++ (and, in fact, since it uses the LLVM > libraries, will require LLVM in base to link libc++). There are multiple possible solutions to this issue. And note that I do support having clang in base and it being the default in head. > Or perhaps you don't care about flattened device trees. To be honest - no, I don't care about them. > The device tree > compiler that we have in base is written in C++ and contains numerous > occurrences of ugly code to make it work with old compilers. I will be very > happy to remove a load of hacks once C++11 support is available in the base > system (not for 10.0, as dtc is used on a lot of tier 2 archs where gcc is > still default). -- 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: patch to add AES intrinsics to gcc
on 23/08/2013 15:34 Nathan Whitehorn said the following: > On 08/23/13 07:26, Andriy Gapon wrote: >> on 23/08/2013 14:06 David Chisnall said the following: >>> Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in its >>> atomic generation so you can't use it sensibly without lots of inline >>> assembly (which it doesn't support for newer architectures) for >>> multithreaded things. >>> >>> Our libstdc++ is ancient and doesn't work with modern C++ codebases. >> On the other hand these tools are perfect for building FreeBSD kernel and >> base. >> Extrapolating my experience with base GCC I am very confident in it as a >> FreeBSD development tool. >> Extrapolating my experience with Clang I am not yet confident in it as a >> FreeBSD development tool. >> > > This isn't even true. It's been true for me. > As CPUs gain new features, the set of available intrinsics > gets more and more ancient, requiring ever more patching, workarounds, and > #ifdef. Just look at the original subject of this thread! Yes. I am more comfortable with incremental changes. Bugs in those can be pinpointed quite easily and I do not affect those who don't use the new features. > We're just talking about the default of a make.conf setting here. Switching to > clang is a long-term goal of the project for good reason. I agree. > Other vendors (Apple, > for instance) have made the plunge first. This seems like as good a time as > any > to do it. And if it goes wrong somehow, we have lots of BETAs and it is > trivial > to change back at any time. I am totally comfortable with clang being default in head. I am also comfortable with gcc not being built by default in head. I am not yet comfortable with clang being default in a release. Even .0 one. JIMHO, it needs to age a little bit more. -- 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: patch to add AES intrinsics to gcc
On 23 Aug 2013, at 13:26, Andriy Gapon wrote: > On the other hand these tools are perfect for building FreeBSD kernel and > base. > Extrapolating my experience with base GCC I am very confident in it as a > FreeBSD development tool. > Extrapolating my experience with Clang I am not yet confident in it as a > FreeBSD development tool. Nathan has already dealt with this. > I do not care about C11, C++11 and modern C++ codebases. I care about what's > in /usr/src and what gets compiled by buildkernel/buildworld. That's just me, > of course. But, OTOH, those who care modern C++ codebases should be perfectly > capable to install a compiler from ports or switch to clang as their default > compiler. So you don't want a working debugger? Our gdb doesn't work at all on MIPS and barely works with code compiled with clang or a recent gcc. We are planning on importing LLDB soon (Ed Maste has been working on it, funded by the FreeBSD Foundation), and it is a C++11 code base. It will not build with our gcc or with our libstdc++ (and, in fact, since it uses the LLVM libraries, will require LLVM in base to link libc++). Or perhaps you don't care about flattened device trees. The device tree compiler that we have in base is written in C++ and contains numerous occurrences of ugly code to make it work with old compilers. I will be very happy to remove a load of hacks once C++11 support is available in the base system (not for 10.0, as dtc is used on a lot of tier 2 archs where gcc is still default). 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: patch to add AES intrinsics to gcc
On 08/23/13 07:26, Andriy Gapon wrote: on 23/08/2013 14:06 David Chisnall said the following: Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in its atomic generation so you can't use it sensibly without lots of inline assembly (which it doesn't support for newer architectures) for multithreaded things. Our libstdc++ is ancient and doesn't work with modern C++ codebases. On the other hand these tools are perfect for building FreeBSD kernel and base. Extrapolating my experience with base GCC I am very confident in it as a FreeBSD development tool. Extrapolating my experience with Clang I am not yet confident in it as a FreeBSD development tool. This isn't even true. As CPUs gain new features, the set of available intrinsics gets more and more ancient, requiring ever more patching, workarounds, and #ifdef. Just look at the original subject of this thread! We're just talking about the default of a make.conf setting here. Switching to clang is a long-term goal of the project for good reason. Other vendors (Apple, for instance) have made the plunge first. This seems like as good a time as any to do it. And if it goes wrong somehow, we have lots of BETAs and it is trivial to change back at any time. -Nathan ___ 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: patch to add AES intrinsics to gcc
On Fri, 2013-08-23 at 12:06 +0100, David Chisnall wrote: > On 23 Aug 2013, at 11:42, Julian Elischer wrote: > > > no, I believe we have said that 10 would ship with clang by default. NO > > mention was made about gcc being absent, and I am uncomfortable with taking > > that step yet. Having gcc just present, will not hurt you.. even after it > > is gone we will need to support those who will be replacing clang with > > newer versions of gcc in hteir own products. > > The plan is not to delete gcc from the tree, it is to disable building gcc by > default when clang is the system compiler. If you are building products then > you are perfectly at liberty to set WITH_GCC=yes in your src.conf. > > Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in its > atomic generation so you can't use it sensibly without lots of inline > assembly (which it doesn't support for newer architectures) for multithreaded > things. > > Our libstdc++ is ancient and doesn't work with modern C++ codebases. Putting > them in the base system means that people will use them. If anyone wants > them to remain, then speak now and this will be taken as your volunteering to: > > - Maintain our forks of both gcc and libstdc++ > - Handle every single PR that is filed by people using these > > If you are willing to do this, then that's great. If not, then you are > asking other people to support ancient codebases that they are not using. > > David > I don't understand, you start by pointing out that gcc will still be in the tree and usable, then you go on to point out that it it won't be supported or maintained unless someone volunteers to do that, and you seem to be doing your best to discourage anyone from volunteering. Doesn't that sort of moot the point that the source isn't being deleted? -- Ian ___ 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: patch to add AES intrinsics to gcc
On Fri, Aug 23, 2013 at 2:12 PM, Volodymyr Kostyrko wrote: > 23.08.2013 12:58, Bernhard Fröhlich wrote: >> >> I don't know if you are aware that IF you really do that we will have >> serious >> problems to ship packages for 10. USE_GCC=any is the fallback in the >> portstree for all ports that are unable to build with clang which was >> introduced >> when HEAD switched to clang as default cc. Right now there are 150 ports >> in >> the tree that use this fallback and quite a few of them are high profile >> ports: >> >> the highlights: >> audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose >> emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxine >> multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 >> security/clamav >> >> the full list: >> http://dpaste.com/1354075/ >> >> A possible hack could be to add a check for USE_GCC=any to behave like >> a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc >> from ports for a lot of people on HEAD I suppose. > > > I object. Many ports that compiles perfectly on gcc 4.2.1 can't be compiled > with lang/gcc. I checked this once and the number of ports that require > strictly gcc 4.2.1 was bigger for me then number of ports that can't be > compiled with clang but fill fine on lang/gcc. > > I'll gonna recheck whether lang/gcc42 is sufficient for them. But I have > that bad feeling... lang/gcc42 is on the list of ports that have USE_GCC=any. So you would need to fix it first to be able to compile it with clang 3.3 from base. We are not trying to build everything with lang/gcc but just the ports that have USE_GCC=any in their Makefile. Per default all ports are still build with cc from base so clang 3.3 on HEAD. -- Bernhard Froehlich http://www.bluelife.at/ ___ 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: patch to add AES intrinsics to gcc
on 23/08/2013 14:06 David Chisnall said the following: > Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in its > atomic generation so you can't use it sensibly without lots of inline > assembly (which it doesn't support for newer architectures) for > multithreaded things. > > Our libstdc++ is ancient and doesn't work with modern C++ codebases. On the other hand these tools are perfect for building FreeBSD kernel and base. Extrapolating my experience with base GCC I am very confident in it as a FreeBSD development tool. Extrapolating my experience with Clang I am not yet confident in it as a FreeBSD development tool. I do not care about C11, C++11 and modern C++ codebases. I care about what's in /usr/src and what gets compiled by buildkernel/buildworld. That's just me, of course. But, OTOH, those who care modern C++ codebases should be perfectly capable to install a compiler from ports or switch to clang as their default compiler. -- 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"
stable/8 kernel-toolchain fails with clang on head
$ /usr/obj/usr/devel/svn/base/stable/8/make.amd64/make kernel-toolchain WITHOUT_CLANG=1 __MAKE_CONF=/dev/null SRCCONF=/dev/null ... cc -O2 -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/usr/devel/svn/base/stable/8/tmp/usr\" -I/usr/obj/usr/devel/svn/base/stable/8/tmp/usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include -I/usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include -I/usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/devel/svn/base/stable/8/tmp/legacy/usr/include -DTARGET_NAME=\"amd64-undermydesk-freebsd\" -c /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/toplev.c In file included from /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/toplev.c:58: /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/output.h:123:6: warning: 'format' attribute argument not supported: __asm_fprintf__ [-Wignored-attributes] ATTRIBUTE_ASM_FPRINTF(2, 3); ^ /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/output.h:113:53: note: expanded from macro 'ATTRIBUTE_ASM_FPRINTF' #define ATTRIBUTE_ASM_FPRINTF(m, n) __attribute__ ((__format__ (__asm_fprintf__, m, n))) ATTRIBUTE_NONNULL(m) ^ /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/toplev.c:542:1: error: redefinition of a 'extern inline' function 'floor_log2' is not supported in C99 mode floor_log2 (unsigned HOST_WIDE_INT x) ^ /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/toplev.h:174:1: note: previous definition is here floor_log2 (unsigned HOST_WIDE_INT x) ^ /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/toplev.c:577:1: error: redefinition of a 'extern inline' function 'exact_log2' is not supported in C99 mode exact_log2 (unsigned HOST_WIDE_INT x) ^ /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/toplev.h:180:1: note: previous definition is here exact_log2 (unsigned HOST_WIDE_INT x) ^ 1 warning and 2 errors generated. *** Error code 1 Stop in /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int. It seems that the problem is specific to stable/8 and is caused by missing -std=gnu89. And that seems to be caused by -DNO_WARNS that is used for toolchain target. Dependency between NO_WARNS and CSTD was removed in r198335 + r198365, but those were never MFC-ed. What do you think? -- 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: patch to add AES intrinsics to gcc
23.08.2013 12:58, Bernhard Fröhlich wrote: I don't know if you are aware that IF you really do that we will have serious problems to ship packages for 10. USE_GCC=any is the fallback in the portstree for all ports that are unable to build with clang which was introduced when HEAD switched to clang as default cc. Right now there are 150 ports in the tree that use this fallback and quite a few of them are high profile ports: the highlights: audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxine multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 security/clamav the full list: http://dpaste.com/1354075/ A possible hack could be to add a check for USE_GCC=any to behave like a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc from ports for a lot of people on HEAD I suppose. I object. Many ports that compiles perfectly on gcc 4.2.1 can't be compiled with lang/gcc. I checked this once and the number of ports that require strictly gcc 4.2.1 was bigger for me then number of ports that can't be compiled with clang but fill fine on lang/gcc. I'll gonna recheck whether lang/gcc42 is sufficient for them. But I have that bad feeling... -- Sphinx of black quartz, judge my vow. ___ 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: GCC withdraw
In message <52174d51.2050...@digsys.bg>, Daniel Kalchev writes: >> - 9.x gcc default and clang in base; >> - 10.x clang default and gcc in ports; > >I believe this is the best idea so far. As long as these ports work with >gcc in ports, that is. +1 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: GCC withdraw
On 23.08.13 14:16, Kurt Jaeger wrote: Hi! I have a patch that I intend to commit before the 10.0 code slush that removes GCC and libstdc++ from the default build on platforms where clang is the system compiler. We definitely don't want to be supporting our 6-year-old versions of these for the lifetime of the 10.x branch. Isn't it a POLA violation? As for me I expect something like this: . 9.x gcc default and clang in base; . 10.x clang default and gcc in base; . 11.x gcc withdraw. If the 150 ports that only work with gcc, all work with a ports gcc and do not need the gcc from base, would the following be OK ? - 9.x gcc default and clang in base; - 10.x clang default and gcc in ports; I believe this is the best idea so far. As long as these ports work with gcc in ports, that is. For many of the "important" ports, they do get used together with other ports that already require newer gcc from ports anyway. So no additional pollution will be created. Daniel ___ 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: patch to add AES intrinsics to gcc
On Fri, Aug 23, 2013 at 06:42:21PM +0800, Julian Elischer wrote: > On 8/23/13 6:35 PM, David Chisnall wrote: > > On 23 Aug 2013, at 10:58, Bernhard Fr?hlich wrote: > > > >> I don't know if you are aware that IF you really do that we will have > >> serious > >> problems to ship packages for 10. USE_GCC=any is the fallback in the > >> portstree for all ports that are unable to build with clang which was > >> introduced > >> when HEAD switched to clang as default cc. Right now there are 150 ports in > >> the tree that use this fallback and quite a few of them are high profile > >> ports: > >> > >> the highlights: > >> audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose > >> emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxine > >> multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 > >> security/clamav > >> > >> the full list: > >> http://dpaste.com/1354075/ > >> > >> A possible hack could be to add a check for USE_GCC=any to behave like > >> a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc > >> from ports for a lot of people on HEAD I suppose. > >> > >> We certainly need to do that switch to remove the ancient gcc from base > >> some time but with my portmgr hat on I can only say we don't plan to do > >> that > >> before 10.0 especially not if we are only talking about a few weeks time > >> window. > > That is unfortunate. We have said for over a year that 10.0 should not > > ship with gcc. I can delay committing the patch to flip the switch until > > later in the code slush, if re approves, but ports that require gcc should > > be building with gcc from ports (which will also improve code quality, as > > gcc 4.6/7 produce significantly better code than 4.2.1). > no, I believe we have said that 10 would ship with clang by default. 10 from this winner have broken firewire code when building by clang -- cannot resume from sleep. ___ 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: Question about socket timeouts
2013/8/22 John Baldwin :
> On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote:
>> 2013/8/21 John Baldwin :
>> > On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote:
>> >> On Mon, 19 Aug 2013, Adrian Chadd wrote:
>> >>
>> >> > Yes! Please file a PR!
>> >>
>> >> This sorta implies that both are acceptable (although,
>> >> the Linux behavior seems more desirable).
>> >>
>> >>http://austingroupbugs.net/view.php?id=369
>> >
>> > No, that says "round up", so it does mean that the requested timeout
>> > should be the minimum amount slept. tvtohz() does this. Really odd
>> > that the socket code is using its own version of this rather than
>> > tvtohz().
>> >
>> > Oh, I bet this just predates tvtohz(). Interesting that it keeps getting
>> > bug fixes in its history that simply using tvtohz() would have solved.
>> >
>> > Try this:
>> >
>> > Index: uipc_socket.c
>> > ===
>> > --- uipc_socket.c (revision 254570)
>> > +++ uipc_socket.c (working copy)
>> > @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt *sopt)
>> > if (error)
>> > goto bad;
>> >
>> > - /* assert(hz > 0); */
>> > if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX / hz ||
>> > tv.tv_usec < 0 || tv.tv_usec >= 100) {
>> > error = EDOM;
>> > goto bad;
>> > }
>> > - /* assert(tick > 0); */
>> > - /* assert(ULONG_MAX - INT_MAX >= 100); */
>> > - val = (u_long)(tv.tv_sec * hz) + tv.tv_usec / tick;
>> > - if (val > INT_MAX) {
>> > + val = tvtohz(&tv);
>> > + if (val == INT_MAX) {
>> > error = EDOM;
>> > goto bad;
>> > }
>> > - if (val == 0 && tv.tv_usec != 0)
>> > - val = 1;
>> >
>> > switch (sopt->sopt_name) {
>> > case SO_SNDTIMEO:
>> >
>>
>> That must help. But I want to see the issue solved in the next
>> release. I can't apply patch to the production system. Btw in
>> production environment we have kern.hz set to 1000 so it's not a
>> problem there.
>
> Can you test this in some way in a test environment?
>
Ok, sorry for posting out of the list.
Simple test program is attached. Without your patch timeout expires in
about 20ms. With it it's ~40ms.
40 instead of 30 is beacuse of odd tick added by tvtohz().
--
vitja.
___
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: patch to add AES intrinsics to gcc
On Fri, Aug 23, 2013 at 12:35 PM, David Chisnall wrote: > On 23 Aug 2013, at 10:58, Bernhard Fröhlich wrote: > >> I don't know if you are aware that IF you really do that we will have serious >> problems to ship packages for 10. USE_GCC=any is the fallback in the >> portstree for all ports that are unable to build with clang which was >> introduced >> when HEAD switched to clang as default cc. Right now there are 150 ports in >> the tree that use this fallback and quite a few of them are high profile >> ports: >> >> the highlights: >> audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose >> emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxine >> multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 >> security/clamav >> >> the full list: >> http://dpaste.com/1354075/ >> >> A possible hack could be to add a check for USE_GCC=any to behave like >> a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc >> from ports for a lot of people on HEAD I suppose. >> >> We certainly need to do that switch to remove the ancient gcc from base >> some time but with my portmgr hat on I can only say we don't plan to do that >> before 10.0 especially not if we are only talking about a few weeks time >> window. > > That is unfortunate. We have said for over a year that 10.0 should not ship > with gcc. I can delay committing the patch to flip the switch until later in > the code slush, if re approves, but ports that require gcc should be building > with gcc from ports (which will also improve code quality, as gcc 4.6/7 > produce significantly better code than 4.2.1). I have asked the question of "when will gcc be removed from base" multiple times over the last year and I got varying results back with the majority saying "after 10". I'm just trying to say that It looks like some people in src also don't expect it to be removed in 10. Anyway bapt already did some testing without gcc in base on HEAD and the results were bad but not totally awful. We will see if we can fix the most important ones in time before 10 but we can't promise anything. If someone wants to have a look at the failures with no gcc in base on HEAD: http://pb2.nyi.freebsd.org/bulk/nogcc-default/2013-08-04_01h01m20s/ (this also includes HEAD failures caused by clang) -- Bernhard Froehlich http://www.bluelife.at/ ___ 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: GCC withdraw
23.08.2013 15:16, Kurt Jaeger пишет: > Hi! > >>> I have a patch that I intend to commit before the 10.0 code >>> slush that removes GCC and libstdc++ from the default build on >>> platforms where clang is the system compiler. We definitely don't >>> want to be supporting our 6-year-old versions of these for the >>> lifetime of the 10.x branch. >> >> Isn't it a POLA violation? >> >> As for me I expect something like this: >> . 9.x gcc default and clang in base; >> . 10.x clang default and gcc in base; >> . 11.x gcc withdraw. > > If the 150 ports that only work with gcc, all work with a ports > gcc and do not need the gcc from base, would the following be OK ? > > - 9.x gcc default and clang in base; > - 10.x clang default and gcc in ports; Well, we write rules and we brake them. ;-) Just say that we know we brake them but it's inevitable because... And go futher. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: GCC withdraw (was: Re: patch to add AES intrinsics to gcc)
Hi! > > I have a patch that I intend to commit before the 10.0 code > > slush that removes GCC and libstdc++ from the default build on > > platforms where clang is the system compiler. We definitely don't > > want to be supporting our 6-year-old versions of these for the > > lifetime of the 10.x branch. > > Isn't it a POLA violation? > > As for me I expect something like this: > . 9.x gcc default and clang in base; > . 10.x clang default and gcc in base; > . 11.x gcc withdraw. If the 150 ports that only work with gcc, all work with a ports gcc and do not need the gcc from base, would the following be OK ? - 9.x gcc default and clang in base; - 10.x clang default and gcc in ports; -- p...@opsec.eu+49 171 3101372 7 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"
Re: ulpt can't attach Lexmark E120
On 08/23/13 02:18, Hans Petter Selasky wrote: On 08/23/13 02:29, George Mitchell wrote: On 08/22/13 07:34, Hans Petter Selasky wrote: Here's the result: [...] (at which point if I type control-c to stop usbdump, the system gets a fatal kernel mode translation fault, but that's another story.) Hope this helps. -- George I would expect to see some messages ERR != 0 when you plug the device. Can you show both usbdump output and dmesg output which belongs together? --HPS Not sure exactly how I would get the usbdump output and log output interspersed in the correct order, and the fact that the pi panics when I type control-C at usbdump doesn't help. Subjectively, the "ulpt0 attach returned 12" seemed to occur a fraction of a second later than the others. But I'll see what I can come up with this evening. -- George ___ 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: patch to add AES intrinsics to gcc
On 23 Aug 2013, at 11:42, Julian Elischer wrote: > no, I believe we have said that 10 would ship with clang by default. NO > mention was made about gcc being absent, and I am uncomfortable with taking > that step yet. Having gcc just present, will not hurt you.. even after it is > gone we will need to support those who will be replacing clang with newer > versions of gcc in hteir own products. The plan is not to delete gcc from the tree, it is to disable building gcc by default when clang is the system compiler. If you are building products then you are perfectly at liberty to set WITH_GCC=yes in your src.conf. Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in its atomic generation so you can't use it sensibly without lots of inline assembly (which it doesn't support for newer architectures) for multithreaded things. Our libstdc++ is ancient and doesn't work with modern C++ codebases. Putting them in the base system means that people will use them. If anyone wants them to remain, then speak now and this will be taken as your volunteering to: - Maintain our forks of both gcc and libstdc++ - Handle every single PR that is filed by people using these If you are willing to do this, then that's great. If not, then you are asking other people to support ancient codebases that they are not using. David signature.asc Description: Message signed with OpenPGP using GPGMail
GCC withdraw (was: Re: patch to add AES intrinsics to gcc)
23.08.2013 13:16, David Chisnall пишет: > I have a patch that I intend to commit before the 10.0 code slush that > removes GCC and libstdc++ from the default build on platforms where clang is > the system compiler. We definitely don't want to be supporting our > 6-year-old versions of these for the lifetime of the 10.x branch. Isn't it a POLA violation? As for me I expect something like this: . 9.x gcc default and clang in base; . 10.x clang default and gcc in base; . 11.x gcc withdraw. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: patch to add AES intrinsics to gcc
On 8/23/13 6:35 PM, David Chisnall wrote: On 23 Aug 2013, at 10:58, Bernhard Fröhlich wrote: I don't know if you are aware that IF you really do that we will have serious problems to ship packages for 10. USE_GCC=any is the fallback in the portstree for all ports that are unable to build with clang which was introduced when HEAD switched to clang as default cc. Right now there are 150 ports in the tree that use this fallback and quite a few of them are high profile ports: the highlights: audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxine multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 security/clamav the full list: http://dpaste.com/1354075/ A possible hack could be to add a check for USE_GCC=any to behave like a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc from ports for a lot of people on HEAD I suppose. We certainly need to do that switch to remove the ancient gcc from base some time but with my portmgr hat on I can only say we don't plan to do that before 10.0 especially not if we are only talking about a few weeks time window. That is unfortunate. We have said for over a year that 10.0 should not ship with gcc. I can delay committing the patch to flip the switch until later in the code slush, if re approves, but ports that require gcc should be building with gcc from ports (which will also improve code quality, as gcc 4.6/7 produce significantly better code than 4.2.1). no, I believe we have said that 10 would ship with clang by default. NO mention was made about gcc being absent, and I am uncomfortable with taking that step yet. Having gcc just present, will not hurt you.. even after it is gone we will need to support those who will be replacing clang with newer versions of gcc in hteir own products. 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" ___ 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: patch to add AES intrinsics to gcc
On 23 Aug 2013, at 10:58, Bernhard Fröhlich wrote: > I don't know if you are aware that IF you really do that we will have serious > problems to ship packages for 10. USE_GCC=any is the fallback in the > portstree for all ports that are unable to build with clang which was > introduced > when HEAD switched to clang as default cc. Right now there are 150 ports in > the tree that use this fallback and quite a few of them are high profile > ports: > > the highlights: > audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose > emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxine > multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 > security/clamav > > the full list: > http://dpaste.com/1354075/ > > A possible hack could be to add a check for USE_GCC=any to behave like > a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc > from ports for a lot of people on HEAD I suppose. > > We certainly need to do that switch to remove the ancient gcc from base > some time but with my portmgr hat on I can only say we don't plan to do that > before 10.0 especially not if we are only talking about a few weeks time > window. That is unfortunate. We have said for over a year that 10.0 should not ship with gcc. I can delay committing the patch to flip the switch until later in the code slush, if re approves, but ports that require gcc should be building with gcc from ports (which will also improve code quality, as gcc 4.6/7 produce significantly better code than 4.2.1). 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: patch to add AES intrinsics to gcc
I don't know if you are aware that IF you really do that we will have serious problems to ship packages for 10. USE_GCC=any is the fallback in the portstree for all ports that are unable to build with clang which was introduced when HEAD switched to clang as default cc. Right now there are 150 ports in the tree that use this fallback and quite a few of them are high profile ports: the highlights: audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxine multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 security/clamav the full list: http://dpaste.com/1354075/ A possible hack could be to add a check for USE_GCC=any to behave like a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc from ports for a lot of people on HEAD I suppose. We certainly need to do that switch to remove the ancient gcc from base some time but with my portmgr hat on I can only say we don't plan to do that before 10.0 especially not if we are only talking about a few weeks time window. -- Bernhard Froehlich http://www.bluelife.at/ On Fri, Aug 23, 2013 at 11:16 AM, David Chisnall wrote: > I have a patch that I intend to commit before the 10.0 code slush that > removes GCC and libstdc++ from the default build on platforms where clang is > the system compiler. We definitely don't want to be supporting our > 6-year-old versions of these for the lifetime of the 10.x branch. > > David > > On 22 Aug 2013, at 21:09, John-Mark Gurney wrote: > >> In my work to get AES-NI performance in a better state and the fact >> that we haven't deprecated gcc yet, I have developed another patch to >> add the appropriate AES intrinstic headers to gcc. >> >> The patch is available at: >> https://people.freebsd.org/~jmg/gcc.aes.intrin.patch >> >> I did have to change the opth-gen.awk script, since it wouldn't let >> me use bit 31, and recent changes to gcc used up all the remaining >> bits. I also was unable to add the -mpclmul option because of running >> out of these bits. >> >> Thanks. >> >> -- >> John-Mark Gurney Voice: +1 415 225 5579 >> >> "All that I will do, has been done, All that I have, has not." >> ___ >> freebsd-toolch...@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain >> To unsubscribe, send any mail to "freebsd-toolchain-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: patch to add AES intrinsics to gcc
on 23/08/2013 12:16 David Chisnall said the following: > I have a patch that I intend to commit before the 10.0 code slush that > removes GCC and libstdc++ from the default build on platforms where clang > is the system compiler. We definitely don't want to be supporting our > 6-year-old versions of these for the lifetime of the 10.x branch. I have an alternative proposal (to re@ and core@) to set WITHOUT_CLANG_IS_CC in stable/10 or at least releng/10.0. -- 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: patch to add AES intrinsics to gcc
I have a patch that I intend to commit before the 10.0 code slush that removes GCC and libstdc++ from the default build on platforms where clang is the system compiler. We definitely don't want to be supporting our 6-year-old versions of these for the lifetime of the 10.x branch. David On 22 Aug 2013, at 21:09, John-Mark Gurney wrote: > In my work to get AES-NI performance in a better state and the fact > that we haven't deprecated gcc yet, I have developed another patch to > add the appropriate AES intrinstic headers to gcc. > > The patch is available at: > https://people.freebsd.org/~jmg/gcc.aes.intrin.patch > > I did have to change the opth-gen.awk script, since it wouldn't let > me use bit 31, and recent changes to gcc used up all the remaining > bits. I also was unable to add the -mpclmul option because of running > out of these bits. > > Thanks. > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > ___ > freebsd-toolch...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org" signature.asc Description: Message signed with OpenPGP using GPGMail
OCE driver on Freebsd 10.0-Current
Hi,
I'm running iperf on Emulex's OCE network adapter in Freebsd-10-current. At
heavy traffic (iperf with ~10 connections), iperf is hanging. The same driver
is working on all other Freebsd versions.
top -HS shows the below information.
PID USERNAME PRI NICE SIZERES STATE C TIME WCPU COMMAND
11 root 155 ki31 0K 128K CPU44 146:36 100.00% idle{idle:
cpu4}
12 root -60- 0K 688K CPU66 52:38 100.00% intr{swi4:
clock}
11 root 155 ki31 0K 128K CPU22 148:42 99.66% idle{idle: cpu2}
11 root 155 ki31 0K 128K CPU77 149:24 99.27% idle{idle: cpu7}
11 root 155 ki31 0K 128K RUN 0 148:00 99.27% idle{idle: cpu0}
11 root 155 ki31 0K 128K CPU11 149:44 99.17% idle{idle: cpu1}
11 root 155 ki31 0K 128K CPU55 148:46 99.17% idle{idle: cpu5}
11 root 155 ki31 0K 128K CPU33 96:57 89.06% idle{idle: cpu3}
11 root 155 ki31 0K 128K RUN 6 149:11 13.87% idle{idle: cpu6}
One interesting thing I observed is that intr is taking 100% on CPU6 when iperf
hangs, while iperf is running fine, the intr WCPU percentage is very low. What
does this below line mean? Why intr is 100% on CPU6??
12 root -60- 0K 688K CPU66 52:38 100.00% intr{swi4: clock}
/Venkat.
___
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"
problem building stable/{9,8} toolchains on head
I am trying to build stable/{9,8} GENERIC kernels on a recent-ish head system
(cc is clang).
To be sure I first try to build the respective tool-chains using the following
process:
1. make make
2. /usr/obj/path/to/make toolchain WITHOUT_CLANG=1 NO_WERROR=yes WERROR=
WERROR stuff is to increase chances of a successful build.
I am getting the following errors though.
stable/9:
building shared library libc.so.7
/usr/bin/ld: cap_getrights.So: relocation R_X86_64_32S against
`SYS_cap_getrights' can not be used when making a shared object; recompile with
-fPIC
stable/8:
cc -O2 -pipe -O2 -fno-strict-aliasing -pipe -march=amdfam10
-I/usr/devel/svn/base/stable/8/lib/libc/include
-I/usr/devel/svn/base/stable/8/lib/libc/../../include
-I/usr/devel/svn/base/stable/8/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE
-I/usr/devel/svn/base/stable/8/lib/libc/../../contrib/gdtoa
-I/usr/obj/usr/devel/svn/base/stable/8/lib/libc
-I/usr/devel/svn/base/stable/8/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE
-DMALLOC_PRODUCTION -I/usr/devel/svn/base/stable/8/lib/libc/locale -DBROKEN_DES
-DPORTMAP -DDES_BUILTIN -I/usr/devel/svn/base/stable/8/lib/libc/rpc -DYP
-DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers
-Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c syscall.S
/usr/devel/svn/base/stable/8/lib/libc/include/compat.h:41:38: error: expected a
'@' in the name
.symver freebsd7___semctl , __semctl @ FBSD_1.0;
^
/usr/devel/svn/base/stable/8/lib/libc/include/compat.h:42:34: error: expected a
'@' in the name
.symver freebsd7_msgctl , msgctl @ FBSD_1.0;
^
/usr/devel/svn/base/stable/8/lib/libc/include/compat.h:43:34: error: expected a
'@' in the name
.symver freebsd7_shmctl , shmctl @ FBSD_1.0;
^
I would appreciate any help with getting this straightened.
--
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"
