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
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
panic: biodone2 already on -8 i386 XEN3PAE DOMU
Hi,
we have a package builder named i386-nb8, a XEN DomU currently with
a 20180328 8.0_BETA kernel with DIAGNOSTIC. It panics every few days
with "biodone2 already".
Debug info so far:
panic: biodone2 already
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip 0xc0105424 cs 0x9 eflags 0x200246 cr2 0xe9b51000 ilevel
0 esp 0xe8655ef4
curlwp 0xd0ce57e0 pid 0 lid 4 lowest kstack 0xe86532c0
Stopped in pid 0.4 (system) at netbsd:breakpoint+0x4: popl%ebp
breakpoint(c04243b0,c060f560,c0453f43,e8655f10,d1c363c8,c04c1dc0,e86482b4,e8655f04,c031b2e8,c0453f43)
at netbsd:breakpoint+0x4
vpanic(c0453f43,e8655f10,e8655f28,c035fb76,c0453f43,0,e86482b4,fffe,c0115894,d1c363c8)
at netbsd:vpanic+0x12d
panic(c0453f43,0,e86482b4,fffe,c0115894,d1c363c8,c04c1dc0,e8655f50,c035fbcc,0)
at netbsd:panic+0x18
biodone2(0,1af50,0,25fa1089,fffe,c0115894,0,e8648004,e8655f8c,c02ed793) at
netbsd:biodone2+0x196
biointr(0,c02cecb7,0,c010912e,6,1,0,0,d0ce57e0,0) at netbsd:biointr+0x4c
softint_thread(e8648004,14f6000,c04d2200,0,c0100075,0,0,0,0,0) at
netbsd:softint_thread+0x93
ds c0310011iostat_busy+0x201
es e8650011
fs c0450031ostype+0x2c5f9
gs 11
edi e8655f10
esi c0453f43ostype+0x3050b
ebp e8655ed0
ebx 104
edx 1
ecx 0
eax 1
eip c0105424breakpoint+0x4
cs 9
eflags 200246
esp e8655ed0
ss 11
netbsd:breakpoint+0x4: popl%ebp
db{0}> ps /l
PIDLID S CPU FLAGS STRUCT LWP * NAME WAIT
226411 3 0 0 da8adaa0pkg_add biolock
174741 3 080 d4fde540 sh wait
100361 3 180 d4f96800 pickup kqueue
132 1 3 180 d179d540pbulk-build wait
237601 3 080 d911e2c0 sh wait
298511 3 280 d1fe0a80 sh wait
172741 3 080 da67a2c0 sh wait
9134 1 3 080 d12e6d40top select
174201 3 280 d1fe0540 screen-4.6.2 pause
240 1 3 080 d1b38a80 tcsh pause
525 1 3 180 d1ac02c0 sshd select
235 1 3 080 d16ae000 sshd select
742 1 3 280 d1290020 getty ttyraw
225 1 3 180 d1ac0d40 cron nanoslp
764 1 3 080 d1ac0800 inetd kqueue
211 1 3 180 d179d2a0 qmgr kqueue
273 1 3 180 d17612c0 master kqueue
419 1 3 080 d1761020 sshd select
373 1 3 080 d12e6020 powerd kqueue
365 1 3 280 d1761560 ntpd pause
367 1 3 080 d12e6560 tcsh pause
350 1 3 080 d12e6800 sh wait
357 1 3 180 d1761aa0 tail kqueue
349 1 3 180 d1761d40 sh wait
346 1 3 080 d12e6aa0 screen-4.6.2 select
177 > 1 7 2 0 d12e62c0syslogd
11 3 080 d118e2a0 init wait
0 61 3 0 200 d16ae2a0 nfsio nfsiod
0 60 3 0 200 d16ae540 nfsio nfsiod
0 59 3 1 200 d16ae7e0 nfsio nfsiod
0 58 3 2 200 d16aea80 nfsio nfsiod
0 57 3 0 200 d1290aa0physiod physiod
0 56 3 1 200 d12902c0 aiodoned aiodoned
0 55 3 2 200 d1290560ioflush syncer
0 54 3 1 200 d1290800 pgdaemon pgdaemon
0 51 3 1 200 d118e000npfgc-0 npfgccv
0 50 3 0 200 d118e540rt_free rt_free
0 49 3 0 200 d118e7e0 unpgc unpgc
0 48 3 2 200 d118ea80key_timehandler key_timehandler
0 47 3 2 200 d118ed20icmp6_wqinput/2 icmp6_wqinput
0 46 3 1 200 d0fc67e0icmp6_wqinput/1 icmp6_wqinput
0 45 3 0 200 d0fc6540icmp6_wqinput/0 icmp6_wqinput
0 44 3 2 200 d0fc62a0 nd6_timer nd6_timer
0 43 3 2 200 d0fc6000 icmp_wqinput/2 icmp_w
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
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
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
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
OpenSSL 1.0.1m imported
Hi, the vulnerability fixes for the latest advisory set from OpenSSL went in last week; this is merely an exercise getting to a clean copy, especially since OpenSSL changed the source format and we'll want to do updates in the future, too. As a result, the diffs are sadly very messy. I've tested amd64. i386 and sparc will get a run by the automated tester; if people with powerpc and sparc64 running -current could give it a whirl before pullups to the release branches, that would be helpful. 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
A Spooky MeetBSD California 2014 (Fwd)
Dear all, happy conferencing to all who make it there :) the conference announcement: - Forwarded message from Matt Olander - 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
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
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
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)
making xterm do UTF-8 again
Hi, with the recent update, among others we gained a new xterm version. New xterm by default should do UTF-8 when told so by LC_CTYPE, LANG etc environment variables at startup. The xterm built in the crossover build alas didn't recognise UTF-8 chars, etc. It seems that setting/expanding CPPFLAGS in the cross-over Makefile does not actually have an effect. But, we do have xsrc/external/mit/xterm/include/xtermcfg.h, and if you define OPT_WIDE_CHARS there UTF-8 will work as advertised (the previous behaviour was more flexible IMO, but whatever; at least the behaviour of xterm and its documentation now match). Assuming that the other settings in CPPFLAGS that don't seem to get applied will be useful, I arrive at the attached patch. Comments? Hardwiring LUIT_PATH this way seems clumsy, is there a nicer solution? regards, spz -- s...@serpens.de (S.P.Zeidler) Index: include/xtermcfg.h === RCS file: /cvsroot/xsrc/external/mit/xterm/include/xtermcfg.h,v retrieving revision 1.5 diff -u -r1.5 xtermcfg.h --- include/xtermcfg.h 31 May 2013 21:48:11 - 1.5 +++ include/xtermcfg.h 10 Jul 2013 20:55:24 - @@ -108,7 +108,7 @@ #define HAVE_XKBKEYCODETOKEYSYM 1 /* AC_CHECK_FUNCS(XkbKeycodeToKeysym) */ #define HAVE_XKBQUERYEXTENSION 1 /* AC_CHECK_FUNCS(XkbQueryExtension) */ #define HAVE_XKB_BELL_EXT 1/* CF_XKB_BELL_EXT */ -/* #undef LUIT_PATH */ /* CF_ARG_ENABLE(luit) */ +#define LUIT_PATH "/usr/X11R7/bin/luit"/* CF_ARG_ENABLE(luit) */ /* #undef NO_ACTIVE_ICON *//* CF_ARG_DISABLE(active-icon) */ /* #undef NO_LEAKS */ /* CF_ARG_DISABLE(leaks) */ /* #undef OPT_256_COLORS *//* CF_ARG_ENABLE(256-color) */ @@ -135,7 +135,7 @@ /* #undef OPT_INPUT_METHOD */ /* CF_ARG_DISABLE(input-method) */ /* #undef OPT_ISO_COLORS *//* CF_ARG_DISABLE(ansi-color) */ /* #undef OPT_LOAD_VTFONTS */ /* CF_ARG_ENABLE(load-vt-fonts) */ -/* #undef OPT_LUIT_PROG */ /* CF_ARG_ENABLE(luit) */ +#define OPT_LUIT_PROG 1/* CF_ARG_ENABLE(luit) */ /* #undef OPT_MAXIMIZE */ /* CF_ARG_DISABLE(maximize) */ /* #undef OPT_MINI_LUIT */ /* CF_ARG_ENABLE(mini-luit) */ /* #undef OPT_NUM_LOCK */ /* CF_ARG_DISABLE(num-lock) */ @@ -155,7 +155,7 @@ /* #undef OPT_TOOLBAR */ /* CF_ARG_ENABLE(toolbar) */ /* #undef OPT_VT52_MODE */ /* CF_ARG_DISABLE(vt52) */ /* #undef OPT_WIDER_ICHAR */ /* CF_ARG_ENABLE(16bit-chars) */ -/* #undef OPT_WIDE_CHARS *//* CF_ARG_OPTION(wide-chars) */ +#define OPT_WIDE_CHARS 1 /* CF_ARG_OPTION(wide-chars) */ /* #undef OPT_XMC_GLITCH *//* CF_ARG_ENABLE(xmc-glitch) */ /* #undef OPT_ZICONBEEP */ /* CF_ARG_DISABLE(ziconbeep) */ /* #undef OWN_TERMINFO_DIR */ /* AC_ARG_WITH(own-terminfo) */ @@ -178,6 +178,7 @@ /* #undef USE_UTMP_SETGID */ /* AC_ARG_WITH(utmp-setgid) */ #define UTMPX_FOR_UTMP 1 /* CF_UTMP */ #define XRENDERFONT 1 /* CF_X_FREETYPE */ +#define XFREE86_FT2 1 /* #undef cc_t */ /* CF_TYPE_CC_T */ /* #undef gid_t */ /* AC_TYPE_UID_T */ /* #undef mode_t *//* AC_TYPE_MODE_T */
