Re: READ ME: updating mpc, mpfr, and eventually gmp
Hi, mueller6...@bellsouth.net (Thomas Mueller) writes: from Paul Goyette: I've had intermittent similar problems with NetBSD for at least three years now. I have no idea what the problem is, though. I've suspected some sort of memory corruption, but was never able to make any progress in tracking it down. It could be a corruption or bug in NetBSD. I've come to expect these things with NetBSD. This is in particular a sudden inability to build NetBSD-current from source. Those happen, and are usually fixed by reading UPDATING and doing what it recommends (or in the case of obvious breaks, waiting a day, updating and running the build again). -current is built by umpteen people (like eg me), and on current and releases and .. my Azubi even managed to build release on Linux with very little coaching, it's not hard, usually. If you can't get it built using build.sh with fairly simple mk.conf -ever- (and not just this one checkout), there's something wrong with your machine or installation. Until I see information about an update of base gcc, I don't plan to try any more using base gcc. I could try to build gcc-aux or gcc48 from pkgsrc and use that, if build is successful. I think I could set HOST_CC and HOST_CXX to tell the build to use that in place of base gcc. That is IMO asking for interesting times. regards, spz -- s...@serpens.de (S.P.Zeidler)
HEADS UP: bind 9.10.0-P2 imported
Dear all, I've just imported bind 9.10.0-P2. Our previous version in HEAD was 9.10.0-b1, so it's not a gigantic step exactly, but it gets us a release version. Also I have enabled installation of two new tools, delv and dnssec-importkey, which also gets us a new library, libirs. delv (Domain Entity Lookup Validation) is the tool to use if your resolver named has issues with the DNSSEC setup of a domain and you want to find out why. libisccfg got a version bump, you may want to remove it from your destdir before building. regards, spz
HEADS UP: dhcp 4.3.0 imported
Dear all, I've imported dhcp 4.3.0 today. The previous version was 4.2.5-P1. The new version has dhcpv6 enabled. I could only weakly test it, if you are able to give it some exercise please do (and if you find issues, please report them). regards, spz
A Spooky MeetBSD California 2014 (Fwd)
Dear all, happy conferencing to all who make it there :) the conference announcement: - Forwarded message from Matt Olander m...@freebsd.org - Greetings! In addition to All Hallows' Eve, it is also time for MeetBSD California 2014, coming up November 1st and 2nd, the day after Halloween! Join us in San Jose, California, at Western Digital, to discuss all things BSD. Talks Sessions include Jordan Hubbard, Kirk McKusick, Brendan Gregg, David Maxwell, a ZFS Panel, Virtualization breakout, etc. The tentative agenda, so far (subject to change): https://www.meetbsd.com/agenda/ After the first day's activities, enjoy a Social Mixer with your peers. Our space at the venue *is* limited, so sign up now at: http://www.meetBSD.com TLDR (yes, longer than the description above): Come see Alfred Perlstein dressed as a Viking! :D What: MeetBSD (un)Conference Where: Western Digital, 5863 Rue Ferrari, San Jose, CA, USA When: November 1st-2nd, Saturday Sunday Cost: $75 USD https://www.facebook.com/MeetBSDCalifornia #meetBSDCa on Twitter Followed by a FreeBSD Developer Vendor Summit (Invite Only): https://wiki.freebsd.org/201411DevAndVendorSummit Thanks to everyone that made this year's MeetBSD possible: iXsystems Inc. Norse Corp. Western Digital EMC Isilon Google The FreeBSD Foundation Netflix Panasas No Starch Press There are still a couple of sponsorship opportunities available. If your company is interested in sponsoring, please contact the MeetBSD Conference Team at info (at) meetbsd (dot) com. Thanks and we hope to see you in November! -- The MeetBSD Team - End forwarded message - regards, spz
OpenSSL updated to 1.0.1k from 1.0.1j
Hi, OpenSSL 1.0.1k has just hit the tree. If you run in snags around it, please send complaints my way. regards, spz
Re: help for OpenSSL update needed
Just to clarify: > http://www.netbsd.org/~spz/openssl-1.0.2j-forHEAD.diff.xz does not try to use src/crypto/external/bsd/openssl/lib/libcrypto/arch/x86_64/sha1-x86_64.S for amd64. To enable using it, edit src/crypto/external/bsd/openssl/lib/libcrypto/arch/x86_64/sha.inc by moving the #if 0 down. We're using sha256 and sha512 from libc, so the asm code for these should not be enabled. regards, spz
Re: help for OpenSSL update needed
Thus wrote S.P.Zeidler (s...@netbsd.org): > - the new sha1 asm for x86_64 doesn't work, [...] Thanks to Christos this part is fixed. I still need verifications from non-x86 :) regards, spz
help for OpenSSL update needed
Dear all, I've prepared a OpenSSL 1.0.2j import for current, but have a few things to resolve that I need help with: - the new sha1 asm for x86_64 doesn't work, it throws illegal instruction in SHA1_Update and that impacts quite a few crypto mechanisms. We can skip asm sha1 for now, but this has a bit of a speed impact (see http://www.netbsd.org/~spz/openssl-speed-compare). Someone skilled in amd64 ASM to the fore? - given the above, the other archs using asm bits should probably be checked as well before it's "so sorry, updating your system has just become a) necessary b) hard". Archs using asm bits for libcrypto, and those having changed are: i386 powerpc sparc sparc64 x86_64 I can check i386 myself, if people with -current on the other archs could please build a tree with: http://www.netbsd.org/~spz/openssl-1.0.2j-forHEAD.diff.xz thrown on it, install it in a chroot and run tests in /usr/tests/crypto/libcrypto (and tell us if it succeeded or where it failed). regards, spz
Re: help for OpenSSL update needed
Thus wrote Martin Husemann (mar...@duskware.de): > On Wed, Oct 12, 2016 at 10:30:27PM +0900, Rin Okuyama wrote: > > I also tested it on UltraSPARC-IIe. Both sparc64 and sparc (GENERIC32.UP > > kernel from sparc64 and userland from sparc) version passed the 29 tests > > in /usr/tests/crypto/libcrypto. > > The sparc64 tests work for me too, but sparc on 32bit hardware > fails a few tests by timing out: > > t_libcrypto (4/5): 6 test cases > bn: [300.074482s] Failed: Test case timed out after 300 seconds > t_pubkey (5/5): 7 test cases > dh: [22.872256s] Passed. > dsa: [23.997709s] Passed. > ec: [301.048359s] Failed: Test case timed out after 300 seconds > ecdh: [66.262402s] Passed. > ecdsa: [301.034882s] Failed: Test case timed out after 300 seconds > rsa: [299.283552s] Failed: Test case timed out after 300 seconds if you run: /usr/tests/crypto/libcrypto/h_bntest /usr/tests/crypto/libcrypto/h_ectest /usr/tests/crypto/libcrypto/h_ecdsatest /usr/tests/crypto/libcrypto/h_rsatest directly, they ought to be very talkative and tell you at which test of the respective functions they get stuck. I hope all four have a common cause. > > # Some .S files in arch/sparc* are generated but not used. Is this OK? That's mostly me being a completionist. Makes working on checking if they have an advantage and activating them if yes at a later date easier. > Maybe that is related? If you don't use an ASM method it should fall back to C and that should always work, just be a bit slower, and most of the ASM in sparc only kicks in if MACHINE is sparc64. regards, spz
Re: help for OpenSSL update needed
Thus wrote Rin Okuyama (rokuy...@rk.phys.keio.ac.jp): > On 2016/10/09 6:29, S.P.Zeidler wrote: > >I still need verifications from non-x86 :) > > I tried it on powerpc boxes. Since build fails with your original patch, > I added some corrections. Please find the attached notes and patch. With > my patch, all 29 tests (MKCRYPTO_RC5=yes) in /usr/tests/crypto/libcrypto > passed both on Freescale MPC8544E and IBM 405GPr. Thank you, much appreciated, especially the AES asm fixes. :) I added your patch (with two modifications, see below) plus fixes that make i386 and sparc* compile (and fix i386, which is tested) into my changes and created a new diff from it: http://www.netbsd.org/~spz/openssl-1.0.2j-forHEAD-3.diff.xz Modifications: > (1) Makefile (regen.sh) transferred into the Makefile; less pretty, but keeping style with the other archs. > - Both sha512-ppc.S and sha256-ppc.S (sha512p8-ppc.S and sha256p8-ppc.S) > are generated from sha512-ppc.pl (sha512p8-ppc.pl). The kind of output > file is determined by its name (including 512 or not). I created and added them, but modified sha.inc not to use them since we have sha??? in libc and we're supposed to use these. Instead I enabled sha1 asm, which has been tested by Robert Swindells (also thanks) in the meantime. regards, spz
new system for automated tests now live
Hi, The new babylon5.NetBSD.org has taken over from the old one that had developped issues with its raid controller (which caused the reports to be rather flaky lately). For the curious the new hardware is: ASUS RS500A-E10-RS12U barebone 1U, 1 way rackmount server It came with rails and CPU cooler; its IPMI and its KVM-via-https are ok (though being able to go to the console via ssh would have been nice). I'm pleased with it so far. AMD EPYC 7402P 2.8 GHz 24 core (48 threads) Rome CPU 8x Samsung Semiconductor M393A2K43DB3-CWE 16GB DDR4-3200 CL22 (1Gx8) ECC reg. DR RAM -> 128GB in total, 8 RAM slots in the system still free 2x Samsung 860 PRO MZ-76P1T0B 1TB SSD, set up as raid1. Ryzen and Samsung 860 EVO has reports of being a problematic combination, EPYC and 860 PRO works. Under full load it takes around 180W. OS: 9_STABLE It's in housing with Vautron in Regensburg, Germany. regards, spz
todays dom0 kernel going splat via fdcattach
Hi, it said: [other boot messages elided] [ 1.030] fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2 [ 1.030] uvm_fault(0x80d12860, 0x0, 1) -> e [ 1.030] fatal page fault in supervisor mode [ 1.030] trap type 6 code 0 rip 0x8021d6f8 cs 0xe030 rflags 0x10286 cr2 0x10 ilevel 0x8 rsp 0x810722c0 [ 1.030] curlwp 0x80b47a80 pid 0.0 lowest kstack 0x8106e2c0 kernel: page fault trap, code=0 Stopped in pid 0.0 (system) at netbsd:bus_dmamap_create+0x1a: testb $0x1,10( %rdi) bus_dmamap_create() at netbsd:bus_dmamap_create+0x1a _isa_dmamap_create() at netbsd:_isa_dmamap_create+0x4b fdcattach() at netbsd:fdcattach+0xb2 fdc_isa_attach() at netbsd:fdc_isa_attach+0xfe config_attach_internal() at netbsd:config_attach_internal+0x197 config_attach() at netbsd:config_attach+0x49 isasearch() at netbsd:isasearch+0x1ee mapply() at netbsd:mapply+0x23 config_search_internal() at netbsd:config_search_internal+0x179 config_search() at netbsd:config_search+0x7d isarescan() at netbsd:isarescan+0xb4 isaattach() at netbsd:isaattach+0xad config_attach_internal() at netbsd:config_attach_internal+0x197 config_found() at netbsd:config_found+0xc1 pcibrescan() at netbsd:pcibrescan+0xc1 pcib_callback() at netbsd:pcib_callback+0x12 config_process_deferred() at netbsd:config_process_deferred+0xbc config_attach_internal() at netbsd:config_attach_internal+0x225 config_found() at netbsd:config_found+0xc1 mp_pci_scan() at netbsd:mp_pci_scan+0xd6 hypervisor_attach() at netbsd:hypervisor_attach+0x56c config_attach_internal() at netbsd:config_attach_internal+0x197 config_found() at netbsd:config_found+0xc1 xen_mainbus_attach() at netbsd:xen_mainbus_attach+0x9c mainbus_attach() at netbsd:mainbus_attach+0x4a config_attach_internal() at netbsd:config_attach_internal+0x197 config_rootfound() at netbsd:config_rootfound+0x77 cpu_configure() at netbsd:cpu_configure+0x25 main() at netbsd:main+0x32c ds 0 es 2a40 fs 6970 gs 6f69 rdi 0 rsi 0 rbp 81072330 rbx 0 rdx 1 rcx 0 rax 80c81be0x86_isa_chipset+0x40 r8 0 r9 3 r10 0 r11 80b00394cpu_info_primary+0x694 r12 0 r13 b680025ad940 r14 3 r15 80b559c0cfdata+0x3720 rip 8021d6f8bus_dmamap_create+0x1a cs e030 rflags 10286 rsp 810722c0 ss e02b netbsd:bus_dmamap_create+0x1a: testb $0x1,10(%rdi) This specific boot is with a 4.15 xenkernel but it showed the same behaviour with a 4.8 xenkernel. regards, spz
