Re: Experience with Epyc 8/9004 series CPUs?
On Fri, 1 Dec 2023 10:22:22 +, Martin Husemann wrote: > Could you please file a PR about this? Done, kern/57737 Cheerio, Hauke -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in emailInstitut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
Re: Experience with Epyc 8/9004 series CPUs?
On Mon, 27 Nov 2023 15:02:26 +0100, Frank Kardel wrote: > Has anybody had a chance to try out NetBSD on Zen4/4c EPYC 8004/9004 > CPUs with some results? Since you asked: Epyc 9554P (64c) on Gigabyte R263-Z70 board <ftp://oak.causeuse.org/pub/NetBSD/netbsd-10-GA_R263-Z70_epyc9554p.bootlog.gz> This is one of two machines that will eventually run Arch Linux for Matlab and python numerical simulations. If you have any fixes to try out in the next couple weeks, I will be able to do that. Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
pf(4) and altq in -current
Hi, with yesterday's 9.99.108 kernel, the altq instructions in my pf.conf broke, because "unsupported". Is this a conscious change, five minutes before branching -10, or a regression? I couldn't find anything related in doc/CHANGES*, nor anywhere else (which probably doesn't mean much, NetBSD information is not very search-engine-able). Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: iscsi target on a zfs zvol?
At 9:15 Uhr -0700 13.07.2022, Brian Buhrow wrote: > [...] you'll get much better read-write performance if you create a standard >zfs filesystem for your time machine backup, then create a regular file in >it which you export via iscsi. To wrap up the issue, I don't even care much about which side is at fault, initiator or target. It's just the experience was nothing I would like to deal with daily. For this home setup, while it would have been nice to use thge server's raid1, I found 2 TB of spinning rust for 50 EUR which does the job nicely. In a similar setting at work, three latest-model iMacs are happily running their Time Machine against Samba shares on a FreeBSD server. Since NetBSD's zfs does not support extended attributes, that wasn't an option here. Cheerio, Hauke -- "It's never straight up and down" (DEVO)
Re: iscsi target on a zfs zvol?
On Sun, 10 Jul 2022 19:40:56 - (UTC), Michael van Elst wrote: >> I would like to set up an iscsi target backed by a zfs zvol, to serve=20 >> as a Mac time machine volume. > > Independent of your problem you should use 'istgt' from pkgsrc. Thanks. Different, but not (much) better. While iscsi-target(8) gave me at least one run with 20 GB, before it started erroring out, istgt(8) goes away once a minute with Jul 10 22:56:18 pizza istgt[9108]: istgt_iscsi.c:4165:istgt_iscsi_op_nopout: ***ERROR*** CmdSN(24873146) error ExpCmdSN=24873145 Jul 10 22:56:18 pizza istgt[9108]: istgt_iscsi.c:5045:istgt_iscsi_execute: ***ERROR*** iscsi_op_nopout() failed Jul 10 22:56:18 pizza istgt[9108]: istgt_iscsi.c:5731:worker: ***ERROR*** iscsi_execute() failed on iqn.2007-09.jp.ne.peach.istgt:disk1,t,0x0001(iqn.20 (initiator is daemon-tools.cc). Pity - it's such a nice idea... Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
iscsi target on a zfs zvol?
Hi, I would like to set up an iscsi target backed by a zfs zvol, to serve as a Mac time machine volume. But the attempt to start the target fails with # /etc/rc.d/iscsi_target onestart Starting iscsi_target. Reading configuration from `/etc/iscsi/targets' target0:rw:0.0.0.0/0 extent0:/dev/zvol/rdsk/tank/time_machine_1:0:0 DISK: 1 logical unit (0 blocks, 512 bytes/block), type iscsi fs DISK: LUN 0: pid 863:/u/sources/netbsd-developer/src/external/bsd/iscsi/lib/../dist/src/lib/disk.c:720: ***ERROR*** error reading "target0" pid 863:/u/sources/netbsd-developer/src/external/bsd/iscsi/lib/../dist/src/lib/disk.c:886: ***ERROR*** error allocating space for "target0" pid 863:/u/sources/netbsd-developer/src/external/bsd/iscsi/lib/../dist/src/lib/target.c:1990: ***ERROR*** device_init() failed iscsi_target_start() failed # until I do something like # hexdump -C -n 512 /dev/zvol/rdsk/tank/time_machine_1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fe || 01c0 ff ff ee fe ff ff 01 00 00 00 fe ff ff ff 00 00 || 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..U.| 0200 # at which point # /etc/rc.d/iscsi_target onestart Starting iscsi_target. Reading configuration from `/etc/iscsi/targets' target0:rw:0.0.0.0/0 extent0:/dev/zvol/rdsk/tank/time_machine_1:0:219902322 DISK: 1 logical unit (4294967296 blocks, 512 bytes/block), type iscsi fs DISK: LUN 0: 2097152 MB disk storage for "target0" TARGET: iSCSI Qualified Name (IQN) is iqn.1994-04.org.netbsd.iscsi-target # Looks like an initialization issue on behalf of iscsi-target. Does that ring a bell for anyone? Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: ixg wierdness
On Wed, 22 Dec 2021 12:26:21 +, Patrick Welche wrote: > The box in 53155 is Hauke's - also a Dell, but slightly different model. he@, not hauke@ -- no Dell boxes here. Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: Problem reports for version control systems
On Sat, 1 May 2021 12:58:50 +1200, Lloyd Parkes wrote: > I'm not using a SLOG. I couldn't be bothered setting one up on my > crash and burn systems. It doesn't seem to be too bad, except for > when I try and run "rm -rf src". Looking at 'systat -w2 vmstat' during writes to zfs, the activity on my machine's ZLOG is amazing. And for the end phase of a 'cvs update', it would make a huge difference. >> Both from home (16 MBit DSL) and $WORKPLACE I am frequently running cvs >> updates through filtering routers (pf(4) here), and basically never see >> connection issues. > > Germany is pretty much the opposite of New Zealand. It's close to > everywhere, but its last mile access speeds are a bit infamous. More speed is available where I live, I just don't have an imminent need. 'cvs update' works anyway. ;) Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: Problem reports for version control systems
On Fri, 30 Apr 2021 19:51:27 +1000, matthew green wrote: >> I too get long pauses with cvs, both at the beginning, >> and even longer at the end after update is complete. > > the end part is most likely cvs cleaning up after itslf by > removing all the subdirs it created but doesn't need. ... which is mostly metadata operations that take a _lot_ longer on spinning rust. Which is why I asked about SLOG. Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: Problem reports for version control systems
On Fri, 30 Apr 2021 17:31:53 +1200, Lloyd Parkes wrote: > The host is a Xeon E3-1241 v3 @ 3.50GHz with eight hyperthreads and > 32GB RAM. It has a 128GB SSD for / and 4x4TB disks in a raidz zpool > on /vol. All work is being done on /vol. Out of curiosity: Do you use a ZIL SLOG* volume with that setup? I remember cvs operations used to be a lot slower on spinning rust than on SSD. Both from home (16 MBit DSL) and $WORKPLACE I am frequently running cvs updates through filtering routers (pf(4) here), and basically never see connection issues. Cheerio, Hauke * <https://www.servethehome.com/what-is-the-zfs-zil-slog-and-what-makes-a-good-one/> -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: -current tar(1) breakage
On Wed, 31 Mar 2021 17:56:16 -0400, Christos Zoulas wrote: > What is the NFS server? Because on NetBSD it returns 255... netbsd-9 (amd64). Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: -current tar(1) breakage
On Sun, 28 Mar 2021 17:24:50 +0100, Robert Swindells wrote: >> >> Interesting. Is that net-booted, or just the pkgsrc tree over nfs? > > Just pkgsrc over NFS. > > Does your netbooted machine have a swapfile on NFS ? No, with 32 GB RAM there is no need, and the server is space limited. Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: -current tar(1) breakage
On Sun, 28 Mar 2021 14:28:52 +0100, Robert Swindells wrote: > On Fri, 26 Mar 2021 15:16:13 +0100, Hauke Fath wrote: >> building editors/xemacs-nox11 on a -current machine (net-booted, if it >> matters) fails [...] > > Have you stated anywhere in the thread what the NFS server is running ? netbsd-9 (Jan 5 userland and kernel of this week's sources). > The unmodified package builds fine for me over NFS, with -current as > both client and server. Interesting. Is that net-booted, or just the pkgsrc tree over nfs? Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: -current tar(1) breakage
On Fri, 26 Mar 2021 15:16:13 +0100, Hauke Fath wrote: > building editors/xemacs-nox11 on a -current machine (net-booted, if it > matters) fails [...] See PR bin/56080. As a workaround, I have adapted editors/xemacs* to use gtar, instead. Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: -current tar(1) breakage
On Sun, 28 Mar 2021 06:49:33 + (UTC), RVP wrote: > Run the code on your NFS-mounted FS and check what FS sizes are > reported. If they are all 0, then it is the same bug (probably). [hauke@i386-pxe] ~/src/tar-fssize > ./a.out /var/obj/pkgsrc/editors/xemacs-nox11/work/xemacs-21.4.24/lisp/console.el sfs.f_frsize: 512 sfs.f_iosize: 32768 sfs.f_bsize: 512 [hauke@i386-pxe] ~/src/tar-fssize > -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: -current tar(1) breakage
On Sat, 27 Mar 2021 18:34:27 -0400, Christos Zoulas wrote:
> I didn't expect output, but I wanted to look at the pointer data.
> Does it contain 0xa5 now instead of other random strings?
Ah. You mean *cv? No, same value:
[hauke@i386-pxe] /<6>xemacs-21.4.24/lisp > env MALLOC_CONF='junk:true'
tar -cf /dev/null .
Segmentation fault (core dumped)
[hauke@i386-pxe] /<6>xemacs-21.4.24/lisp > gdb /bin/tar tar.core
GNU gdb (GDB) 11.0.50.20200914-git
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64--netbsd".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /bin/tar...
Reading symbols from /usr/libdata/debug//bin/tar.debug...
[New process 6992]
Core was generated by `tar'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x6fe46fc67866 in _citrus_iconv_convert
(nresults=0x7f7fffe70f48, flags=0, outbytes=0x7f7fffe70fc8,
out=0x7f7fffe70fc0,
inbytes=0x7f7fffe70fb8, in=0x7f7fffe70fb0, cv=0x6fe471f0e0e0) at
/usr/src/lib/libc/citrus/citrus_iconv.h:61
61 _DIAGASSERT(cv && cv->cv_shared && cv->cv_shared->ci_ops &&
(gdb) print *cv
$1 = {cv_shared = 0x6c652e73, cv_closure = 0x6fe471bcd050}
(gdb) print *cv->cv_shared
Cannot access memory at address 0x6c652e73
(gdb)
--
Hauke Fath
Linnéweg 7
64342 Seeheim-Jugenheim
Germany
Re: -current tar(1) breakage
On Sat, 27 Mar 2021 17:04:58 -0400, Christos Zoulas wrote: > Maybe we are accessing freed memory? Can you run it with: > > env MALLOC_CONF='junk:true' No output: [hauke@i386-pxe] /<6>xemacs-21.4.24/lisp > env MALLOC_CONF='junk:true' tar -cf /dev/null . Segmentation fault (core dumped) [hauke@i386-pxe] /<6>xemacs-21.4.24/lisp > -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: -current tar(1) breakage
On Sat, 27 Mar 2021 18:02:32 +0100, Hauke Fath wrote: > On Sat, 27 Mar 2021 12:27:20 -0400, Christos Zoulas wrote: >> Joerg thinks that this is an nfs issue (a bug with nfs giving >> incorrect data). > > Doesn't do that in other locations, though: [/var/tmp] Maybe it does: [hauke@i386-pxe] /var/log > tar -cvf /dev/null . a . a ./rdist a ./amdlog a ./authlog[hauke@i386-pxe] /var/log > -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: -current tar(1) breakage
On Sat, 27 Mar 2021 12:27:20 -0400, Christos Zoulas wrote:
> Joerg thinks that this is an nfs issue (a bug with nfs giving
> incorrect data).
Doesn't do that in other locations, though:
[hauke@i386-pxe] /var/tmp > tar -cvf /dev/null .
a .
a ./vi.recover
a ./pkg_rr.out
a ./pizza-etc.tgz
[hauke@i386-pxe] /var/tmp >
> Nevertheless can you
>
> print *cv,
> print *cv->shared
> print *cv->shared->ci_ops
(gdb) print *cv
$1 = {cv_shared = 0x6c652e73, cv_closure = 0x761713184050}
(gdb) print *cv->shared
There is no member named shared.
(gdb) print *cv->cv_shared
Cannot access memory at address 0x6c652e73
(gdb) print *cv->cv_shared->ci_ops
Cannot access memory at address 0x6c652e73
(gdb)
Cheerio,
Hauke
--
Hauke Fath
Linnéweg 7
64342 Seeheim-Jugenheim
Germany
Re: -current tar(1) breakage
On Sat, 27 Mar 2021 09:22:16 -0400, Christos Zoulas wrote: > Can't you just download the pre-build ones? Assuming you are using > reproducible builds, we might get lucky? Running 'ktrace -di tar -cf /dev/null .' from the same directory (ditors/xemacs-nox11/work/xemacs-21.4.24/lisp): % kdump [...] 14308 14308 tar GIO fd 8 read 1728 bytes " msw-select.el --- Lisp interface to mswindows selections.\n\n;; Copyright (C) 1990, 1997 Free Software Foundation, Inc.\n;; Copyright (C) \ 1995 Sun Microsystems.\n\n;; Maintainer: XEmacs Development Team\n;; Keywords: extensions, dumped\n\n;; This file is part of XEmacs.\n\n;; XEm\ acs is free software; you can redistribute it and/or modify it\n;; under the terms of the GNU General Public License as published by\n;; the F\ ree Software Foundation; either version 2, or (at your option)\n;; any later version.\n\n;; XEmacs is distributed in the hope that it will be \ useful, but\n;; WITHOUT ANY WARRANTY; without even the implied warranty of\n;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the G\ NU\n;; General Public License for more details.\n\n;; You should have received a copy of the GNU General Public License\n;; along with XEmacs;\ see the file COPYING. If not, write to the \n;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,\n;; Boston, MA 02111-1307, USA.\ \n\n;;; Synched up with: Not in FSF\n\n;;; Commentary:\n\n;; This file is dumped with XEmacs (when mswindows support is compiled in).\n;; \ Only copes with copying/pasting text\n\n;;; Code:\n\n(defun mswindows-paste-clipboard ()\n \"Insert the current contents of the mswindows cl\ ipboard at point,\nreplacing the active selection if there is one.\"\n (interactive \"*\")\n (setq last-command nil)\n (setq this-command '\ yank) ; so that yank-pop works.\n (let ((clip (get-clipboard)) (s (mark-marker)) (e (point-marker)))\n(or clip (error \"there is no text \ on the clipboard\"))\n(if s\n (if mouse-track-rectangle-p\n (delete-rectangle s e)\n (delete-region s e)))\n(push-mar\ k)\n(if mouse-track-rectangle-p\n (insert-rectangle clip)\n (insert clip\n\n\n\n\n" 14308 14308 tar RET read 1728/0x6c0 14308 14308 tar CALL close(8) 14308 14308 tar RET close 0 14308 14308 tar CALL fstatat(6,0x761713209062,0x76171320a300,0x200) 14308 14308 tar NAMI "gtk-widget-accessors.el" 14308 14308 tar RET fstatat 0 14308 14308 tar CALL fchdir(6) 14308 14308 tar RET fchdir 0 14308 14308 tar CALL openat(6,0x761713209100,4,0x761710eb0c9a) 14308 14308 tar NAMI "gtk-widget-accessors.el" 14308 14308 tar RET openat 8 14308 14308 tar CALL __acl_get_fd(8,4,0x761712de2000) 14308 14308 tar RET __acl_get_fd -1 errno 45 Operation not supported 14308 14308 tar CALL __acl_get_fd(8,2,0x7617130d8000) 14308 14308 tar RET __acl_get_fd -1 errno 45 Operation not supported 14308 14308 tar CALL extattr_list_fd(8,1,0,0) 14308 14308 tar RET extattr_list_fd -1 errno 45 Operation not supported 14308 14308 tar CALL close(8) 14308 14308 tar RET close 0 14308 14308 tar CALL fchdir(4) 14308 14308 tar RET fchdir 0 14308 14308 tar PSIG SIGSEGV SIG_DFL: code=SEGV_MAPERR, addr=0x6c652e73, trap=6) 14308 14308 tar NAMI "tar.core" % -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: -current tar(1) breakage
On Sat, 27 Mar 2021 09:22:16 -0400, Christos Zoulas wrote: > Can't you just download the pre-build ones? Assuming you are using > reproducible builds, we might get lucky? [...] Reading symbols from /bin/tar... Reading symbols from /usr/libdata/debug//bin/tar.debug... [New process 10317] Core was generated by `tar'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7f0a03467866 in _citrus_iconv_convert (nresults=0x7f7fff902d18, flags=0, outbytes=0x7f7fff902d98, out=0x7f7fff902d90, inbytes=0x7f7fff902d88, in=0x7f7fff902d80, cv=0x7f0a057c40e0) at /usr/src/lib/libc/citrus/citrus_iconv.h:61 61 _DIAGASSERT(cv && cv->cv_shared && cv->cv_shared->ci_ops && (gdb) bt #0 0x7f0a03467866 in _citrus_iconv_convert (nresults=0x7f7fff902d18, flags=0, outbytes=0x7f7fff902d98, out=0x7f7fff902d90, inbytes=0x7f7fff902d88, in=0x7f7fff902d80, cv=0x7f0a057c40e0) at /usr/src/lib/libc/citrus/citrus_iconv.h:61 #1 _iconv (handle=handle@entry=0x7f0a057c40e0, in=in@entry=0x7f7fff902d80, szin=szin@entry=0x7f7fff902d88, out=out@entry=0x7f7fff902d90, szout=szout@entry=0x7f7fff902d98) at /usr/src/lib/libc/iconv/iconv.c:97 #2 0x7f0a05483834 in iconv_strncat_in_locale (as=0x7f0a05762158, _p=, length=, sc=0x7f0a056eb000) at /usr/src/external/bsd/libarchive/dist/libarchive/archive_string.c:2039 #3 0x7f0a054844ba in archive_strncat_l (as=as@entry=0x7f0a05762158, _p=, n=, sc=) at /usr/src/external/bsd/libarchive/dist/libarchive/archive_string.c:1998 #4 0x7f0a0548459a in archive_strncpy_l (as=as@entry=0x7f0a05762158, _p=, n=, sc=) at /usr/src/external/bsd/libarchive/dist/libarchive/archive_string.c:1944 #5 0x7f0a054847d9 in archive_mstring_get_mbs_l (aes=0x7f0a05762110, p=0x7f7fff902eb8, length=0x7f7fff902ee8, sc=) at /usr/src/external/bsd/libarchive/dist/libarchive/archive_string.c:4005 #6 0x7f0a0547b810 in _archive_entry_pathname_l (entry=, p=, len=, sc=) at /usr/src/external/bsd/libarchive/dist/libarchive/archive_entry.c:598 #7 0x7f0a0541f051 in get_entry_pathname (a=0x7f0a057b6000, entry=, name=, length=, sc=) at /usr/src/external/bsd/libarchive/dist/libarchive/archive_write_set_format_pax.c:428 #8 0x7f0a0541f5da in archive_write_pax_header (a=0x7f0a057b6000, entry_original=0x7f0a05761500) at /usr/src/external/bsd/libarchive/dist/libarchive/archive_write_set_format_pax.c:839 #9 0x7f0a0546a1da in _archive_write_header (_a=0x7f0a057b6000, entry=0x7f0a05761500) at /usr/src/external/bsd/libarchive/dist/libarchive/archive_write.c:650 #10 0x7b008ac2 in write_entry (bsdtar=bsdtar@entry=0x7f7fff9037f0, a=a@entry=0x7f0a057b6000, entry=0x7f0a05761500) at /usr/src/external/bsd/libarchive/dist/tar/write.c:974 #11 0x7b008cac in write_file (entry=, a=0x7f0a057b6000, bsdtar=0x7f7fff9037f0) at /usr/src/external/bsd/libarchive/dist/tar/write.c:962 #12 write_hierarchy (bsdtar=bsdtar@entry=0x7f7fff9037f0, a=a@entry=0x7f0a057b6000, path=path@entry=0x7f7fff9042f2 ".") at /usr/src/external/bsd/libarchive/dist/tar/write.c:941 #13 0x7b00907e in write_archive (a=a@entry=0x7f0a057b6000, bsdtar=bsdtar@entry=0x7f7fff9037f0) at /usr/src/external/bsd/libarchive/dist/tar/write.c:513 #14 0x7b0098a4 in tar_mode_c (bsdtar=bsdtar@entry=0x7f7fff9037f0) at /usr/src/external/bsd/libarchive/dist/tar/write.c:247 #15 0x7b00ba4d in main (argc=, argv=) at /usr/src/external/bsd/libarchive/dist/tar/bsdtar.c:910 (gdb) HTH, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: -current tar(1) breakage
On Fri, 26 Mar 2021 20:08:40 +0100, Hauke Fath wrote: > On Fri, 26 Mar 2021 14:41:56 -0400, Christos Zoulas wrote: >> Can you install the debug sets? > > Will do - have to build them first, though. Sorry, the build died. It wants more than 20 GB for objects, which I currently don't have on that machine... Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: -current tar(1) breakage
On Fri, 26 Mar 2021 14:41:56 -0400, Christos Zoulas wrote: > Can you install the debug sets? Will do - have to build them first, though. Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: -current tar(1) breakage
On Fri, 26 Mar 2021 18:56:09 +0100, Martin Husemann wrote: > On Fri, Mar 26, 2021 at 06:52:04PM +0100, Hauke Fath wrote: >> Program terminated with signal SIGSEGV, Segmentation fault. >> #0 0x74e0e8667866 in iconv () from /lib/libc.so.12 >> (gdb) bt >> #0 0x74e0e8667866 in iconv () from /lib/libc.so.12 > > What are your locale settings? None set - this is a pretty plain -current amd64 installation with about a dozen packages installed, adapted for netboot. Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: -current tar(1) breakage
On Fri, 26 Mar 2021 18:52:04 +0100, Hauke Fath wrote: > Also, from a 'ktrace -di': FTR, This is from a plain 'ktrace -di /usr/bin/tar -cf - . > /dev/null' on an nfs volume. Works with GNU tar(1). Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: -current tar(1) breakage
On Fri, 26 Mar 2021 15:34:21 +, Robert Swindells wrote: > The package builds fine for me on -current, what is unusual about your > build host ? It is net-booted. As soon as I put WRKOBJDIR on a local disk, I am fine. Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: -current tar(1) breakage
On Fri, 26 Mar 2021 16:28:38 - (UTC), Christos Zoulas wrote: > What does the core file show? Reading symbols from /usr/bin/tar... (No debugging symbols found in /usr/bin/tar) [New process 29527] Core was generated by `tar'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x74e0e8667866 in iconv () from /lib/libc.so.12 (gdb) bt #0 0x74e0e8667866 in iconv () from /lib/libc.so.12 #1 0x74e0ea683834 in ?? () from /usr/lib/libarchive.so.4 #2 0x74e0ea6844ba in archive_strncat_l () from /usr/lib/libarchive.so.4 #3 0x74e0ea6847d9 in archive_mstring_get_mbs_l () from /usr/lib/libarchive.so.4 #4 0x74e0ea61f051 in ?? () from /usr/lib/libarchive.so.4 #5 0x74e0ea61f5da in ?? () from /usr/lib/libarchive.so.4 #6 0x74e0ea66a1da in ?? () from /usr/lib/libarchive.so.4 #7 0x000155a08ac2 in write_entry () #8 0x000155a08cac in write_hierarchy () #9 0x000155a0907e in write_archive () #10 0x000155a098a4 in tar_mode_c () #11 0x000155a0ba4d in main () (gdb) Also, from a 'ktrace -di': [...] 29527 29527 tar CALL __acl_get_fd(7,4,0x74e0ea5dc000) 29527 29527 tar RET __acl_get_fd -1 errno 45 Operation not supported 29527 29527 tar CALL mmap(0,0x5000,PROT_READ|PROT_WRITE,0x1002,0x,0,0) 29527 29527 tar RET mmap 128509353488384/0x74e0ea5d7000 29527 29527 tar CALL munmap(0x74e0ea5d7000,0x5000) 29527 29527 tar RET munmap 0 29527 29527 tar CALL mmap(0,0x6000,PROT_READ|PROT_WRITE,0xd001002,0x,0,0) 29527 29527 tar RET mmap 128509353484288/0x74e0ea5d6000 29527 29527 tar CALL munmap(0x74e0ea5db000,0x1000) 29527 29527 tar RET munmap 0 29527 29527 tar CALL __acl_get_fd(7,2,0x74e0ea5d6000) 29527 29527 tar RET __acl_get_fd -1 errno 45 Operation not supported 29527 29527 tar CALL extattr_list_fd(7,1,0,0) 29527 29527 tar RET extattr_list_fd -1 errno 45 Operation not supported 29527 29527 tar CALL close(7) 29527 29527 tar RET close 0 29527 29527 tar CALL fchdir(3) 29527 29527 tar RET fchdir 0 29527 29527 tar PSIG SIGSEGV SIG_DFL: code=SEGV_MAPERR, addr=0x68, trap=6) 29527 29527 tar NAMI "tar.core" -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: -current tar(1) breakage
On Fri, 26 Mar 2021 16:03:53 +0100, Thomas Klausner wrote: > On Fri, Mar 26, 2021 at 03:16:13PM +0100, Hauke Fath wrote: >> building editors/xemacs-nox11 on a -current machine (net-booted, if it >> matters) fails with > > Just as a data point, this packages fine for me on 9.99.81/amd64 (with > a local file system). Confirmed. So it's tar(1) on NFS... Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: -current tar(1) breakage
On Fri, 26 Mar 2021 14:38:08 +, Robert Swindells wrote: >> The workaround was to symlink /usr/pkg/bin/gtar to .tools/bin/tar. Is >> there any pkgsrc magic for making gtar pose as tar(1), or am I on my >> own? > > You can put a line in the pkgsrc Makefile of: > > EXTRACT_USING= gtar I've seen (and used) EXTRACT_USING. But does this just cover extracts by the pkgsrc framework, or also any invocations of tar by the package's build system? Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
-current tar(1) breakage
Hi,
building editors/xemacs-nox11 on a -current machine (net-booted, if it
matters) fails with
[...]
Copying /var/obj/pkgsrc/editors/xemacs-nox11/work/xemacs-21.4.24/etc...
./TUTORIAL.ko: Truncated tar archive
tar: Error exit delayed from previous errors.
[1] Segmentation fault (core dumped) (cd ${dir} && tar -cf - .) |
Done(1) (cd ${dest} && umask 022 && tar -xf -)
Copying /var/obj/pkgsrc/editors/xemacs-nox11/work/xemacs-21.4.24/lisp...
./syntax.el: Truncated tar archive
tar: Error exit delayed from previous errors.
[1] Segmentation fault (core dumped) (cd ${dir} && tar -cf - .) |
Done(1) (cd ${dest} && umask 022 && tar -xf -)
This works on netbsd-9. What has changed in the -current tar?
The workaround was to symlink /usr/pkg/bin/gtar to .tools/bin/tar. Is
there any pkgsrc magic for making gtar pose as tar(1), or am I on my
own?
Cheerio,
Hauke
--
Hauke Fath
Linnéweg 7
64342 Seeheim-Jugenheim
Germany
ramdisk-zfsroot bild fails in route(8) code
Attempting to build ramdisk-zfsroot after <https://wiki.netbsd.org/wiki/RootOnZFS/> in -current fails for me with a gcc warning [...] # compile x_route/rtutil.o /u3/netbsd-builds/developer/amd64/tools/bin/x86_64--netbsd-gcc -Os -fno-asynchronous-unwind-tables -pipe -Wall -Wno-error -pipe -std=gnu99 -Werror --sysroot=/u3/netbsd-builds/developer/amd64/destdir -DSMALL -I/export/netbsd-developer/distrib/utils/x_route/../../../sbin/route -DCRUNCHOPS -DINET6 -c /export/netbsd-developer/distrib/utils/x_route/../../../sbin/route/rtutil.c -o rtutil.o.o /export/netbsd-developer/distrib/utils/x_route/../../../sbin/route/rtutil.c: In function 'netname6': /export/netbsd-developer/distrib/utils/x_route/../../../sbin/route/rtutil.c:690:32: error: '%s' directive output may be truncated writing up to 1024 bytes into a region of size 256 [-Werror=format-truncation=] 690 | snprintf(line, sizeof(line), "%s/%d", hbuf, masklen); |^~ /export/netbsd-developer/distrib/utils/x_route/../../../sbin/route/rtutil.c:690:31: note: directive argument in the range [0, 2147483647] 690 | snprintf(line, sizeof(line), "%s/%d", hbuf, masklen); | ^~~ /export/netbsd-developer/distrib/utils/x_route/../../../sbin/route/rtutil.c:690:2: note: 'snprintf' output between 3 and 1036 bytes into a destination of size 256 690 | snprintf(line, sizeof(line), "%s/%d", hbuf, masklen); | ^~~~ cc1: all warnings being treated as errors *** Failed target: rtutil.o *** Failed command: /u3/netbsd-builds/developer/amd64/tools/bin/x86_64--netbsd-gcc -Os -fno-asynchronous-unwind-tables -pipe -Wall -Wno-error -pipe -std=gnu99 -Werror --sysroot=/u3/netbsd-builds/developer/amd64/destdir -DSMALL -I/export/netbsd-developer/distrib/utils/x_route/../../../sbin/route -DCRUNCHOPS -DINET6 -c /export/netbsd-developer/distrib/utils/x_route/../../../sbin/route/rtutil.c -o rtutil.o.o *** Error code 1 Stop. nbmake[2]: stopped in /u1/netbsd-developer/src/distrib/amd64/ramdisks/ramdisk-zfsroot/route [...] Given the netname6() function does elaborate dances with masklen, does this speak to anybody? Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
-9 build failure
A macppc build of today's netbsd-9 on amd64 fails with
[...]
dependall ===> lib/../sys/rump/net/lib/libvlan
# compile libvlan/if_vlan.o
/u3/netbsd-builds/9/macppc/tools/bin/powerpc--netbsd-gcc -O2
-fno-delete-null-pointer-checks -ffreestanding -fno-strict-aliasing
-std=gnu99-Wa
ll -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wno-sign-compare -Wsystem-headers -Wno-traditional
-Wa,--fatal-warnings -Wreturn-ty
pe -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra
-Wno-unused-parameter -Wno-sign-compare -Werror -Wno-format-zero-length
-Wno-pointer-sign
-I/export/netbsd-9/sys/rump/net/lib/libvlan/../../../include
--sysroot=/u3/netbsd-builds/9/macppc/destdir -D_RUMPKERNEL
-I/export/netbsd-9/sys/rump/
net/lib/libvlan/../../../librump/rumpkern -DCOMPAT_50 -DCOMPAT_60
-DCOMPAT_70 -DCOMPAT_80 -nostdinc -imacros
/export/netbsd-9/sys/rump/net/lib/libvlan
/../../../include/opt/opt_rumpkernel.h
-I/export/netbsd-9/sys/rump/net/lib/libvlan -I.
-I/export/netbsd-9/sys/rump/net/lib/libvlan/../../../../../comm
on/include -I/export/netbsd-9/sys/rump/net/lib/libvlan/../../../include
-I/export/netbsd-9/sys/rump/net/lib/libvlan/../../../include/opt
-I/export/net
bsd-9/sys/rump/net/lib/libvlan/../../../../arch
-I/export/netbsd-9/sys/rump/net/lib/libvlan/../../../.. -DDIAGNOSTIC
-DKTRACE -c/export/netbsd-9
/sys/rump/net/lib/libvlan/../../../../net/if_vlan.c -o if_vlan.o
/export/netbsd-9/sys/rump/net/lib/libvlan/../../../../net/if_vlan.c: In
function 'vlan_ether_addmulti':
/export/netbsd-9/sys/rump/net/lib/libvlan/../../../../net/if_vlan.c:1211:78:
error: format '%ld' expects argument of type 'long int', but argument 4
has type 'unsigned int' [-Werror=format=]
printf("%s: sa->sa_len (%d) larger than sizeof(struct
sockaddr_storage) (%ld)\n",
~~^
%d
cc1: all warnings being treated as errors
*** Failed target: if_vlan.o
[...]
Cheerio,
Hauke
--
Hauke Fath
Linnéweg 7
64342 Seeheim-Jugenheim
Germany
Re: -9 build failure
On Wed, 27 Jan 2021 12:28:55 +0100, Hauke Fath wrote: > A macppc build of today's netbsd-9 on amd64 fails with [...] Ignore that, it is from leftover debugging code. Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: Best practice for setting up disks for ZFS on NetBSD
On Thu, 3 Dec 2020 00:30:17 +, David Brownlee wrote: > - Wedges, setup as a single large gpt partition of type zfs (eg /dev/dk7) > - Entire disk (eg: /dev/wd0 or /dev/sd4) "Traditional" (solarish) zfs lore recommends giving zfs the entire disk, unpartitioned, since it can make more efficient use of it then. Zfs will generally be able to re-assemble a volume after renumbering components - I have seen it do that on OmniOS after swapping an Areca RAID controller in JBOD mode out for a plain SAS controller. Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: new system for automated tests now live
At 12:30 Uhr + 26.10.2020, S.P.Zeidler wrote: >For the curious the new hardware is: > > [nice things] Congrats to the new hardware, sounds like a nice package! Cheerio, Hauke -- "It's never straight up and down" (DEVO)
Re: NetBSD 9 on ThinkPad X220
On Wed, 27 May 2020 19:24:22 +0300, Jukka Ruohonen wrote: >> Which browser? (I'm responsible for the Firefox audio code on NetBSD.) > > I tried both Midori and Firefox. Do I need pulseaudio for the latter? As I > recall, at some point they deprecated everything else at least for Linux. FWIW, I build with # Globals PKG_DEFAULT_OPTIONS = cups oss -pulseaudio and firefox 76 played a youtube video with sound for me just this afternoon. Cheerio, Hauke -- Hauke Fath Grabengasse 57 64372 Ober-Ramstadt Germany
Re: github.com/NetBSD/src 5 days old?
[re-directing to tech-repository, which was created precisely to keep debates like this one off the other lists...] On Thu, 14 May 2020 14:47:02 +0200, Jens Rehsack wrote: > I doubt that you'll find a modern solution running fine on any 4M computer. > Network filesystems, cross compilers etc. where invented to support machines > which can't provide all required resources for a job on their own. Unfortunately, the VCS equivalent to your list would be a client connecting to a beefy local DVCS instance, which to the best of my knowledge has not been invented, yet. Cheerio, Hauke -- Hauke Fath Grabengasse 57 64372 Ober-Ramstadt Germany
Re: Panic on current on mac68k
At 21:33 Uhr + 24.02.2019, John Klos wrote: >[ 3.2026086] sd0 at scsibus0 target 0 lun 0: >disk removable >[ 3.3027567] sd0: 61064 MB, 16383 cyl, 15 head, 63 sec, 512 bytes/sect x >125059072 sectors >[ 3.4035060] sd1 at scsibus0 target 0 lun 1: >disk removable >[ 3.5038328] sd1: drive offline >[ 3.5399414] sd2 at scsibus0 target 0 lun 2: >disk removable >[ 3.6369543] sd2: drive offline >[ 3.6729607] sd3 at scsibus0 target 0 lun 3: 1.28> disk removable >[ 3.7720454] sd3: 61056 MB, 15506 cyl, 128 head, 63 sec, 512 bytes/sect >x 125042688 sectors >[ 3.8770380] sd4 at scsibus0 target 0 lun 4: >disk removable >[ 3.9741249] sd4: drive offline >[ 4.0117232] sd0: async, 8-bit transfers >[ 4.0117232] sd1: async, 8-bit transfers >[ 4.0117232] sd2: async, 8-bit transfers >[ 4.0117232] sd3: async, 8-bit transfers >[ 4.0117232] sd4: async, 8-bit transfers That is a whole raft of, erm, non-standard disk drives you have there. How are the silicon disks bridged, and how reliable and standard conformant (sp?) are these bridges? Do you get the panic with traditional spinning rust? Cheerio, hauke -- "It's never straight up and down" (DEVO)
-current tpm breakage
Builds with a (non-standard) MKTPM=1 break with
[...]
#create libtspi/.depend
rm -f .depend
CC=/u/netbsd-builds/developer/amd64/tools/bin/x86_64--netbsd-gcc
/u/netbsd-builds/developer/amd64/tools/bin/nbmkdep -s .o\ .po\ .pico\
.go\ .ln\ .d -d -f .depend hash.d hosttable.
# compile libtspi/hash.o
/u/netbsd-builds/developer/amd64/tools/bin/x86_64--netbsd-gcc -O2
-std=gnu99 -Werror -fPIE
--sysroot=/u/netbsd-builds/developer/amd64/destdir
-I/public/netbsd-developer/c
/public/netbsd-developer/crypto/external/cpl/trousers/dist/src/trspi/crypto/openssl/hash.c:
In function 'Trspi_Hash':
/public/netbsd-developer/crypto/external/cpl/trousers/dist/src/trspi/crypto/openssl/hash.c:59:13:
error: storage size of 'md_ctx' isn't known
EVP_MD_CTX md_ctx;
^~
/public/netbsd-developer/crypto/external/cpl/trousers/dist/src/trspi/crypto/openssl/hash.c:
In function 'Trspi_HashInit':
/public/netbsd-developer/crypto/external/cpl/trousers/dist/src/trspi/crypto/openssl/hash.c:115:32:
error: invalid application of 'sizeof' to incomplete type 'EVP_MD_CTX
{aka struc
if ((ctx->ctx = malloc(sizeof(EVP_MD_CTX))) == NULL)
^~
*** Failed target: hash.o
*** Failed command:
/u/netbsd-builds/developer/amd64/tools/bin/x86_64--netbsd-gcc -O2
-std=gnu99 -Werror -fPIE
--sysroot=/u/netbsd-builds/developer/amd64/destdir -I/public/netbsd-
*** Error code 1
Stop.
nbmake[8]: stopped in
/public/netbsd-developer/crypto/external/cpl/trousers/lib/libtspi
*** Failed target: dependall
*** Failed command: cd
"/public/netbsd-developer/crypto/external/cpl/trousers/lib/libtspi";
/u/netbsd-builds/developer/amd64/tools/bin/nbmake realall
*** Error code 1
-- I guess the code hasn't kept up with openssl evolution?
Cheerio,
hauke
--
The ASCII Ribbon Campaign Hauke Fath
() No HTML/RTF in email Institut für Nachrichtentechnik
/\ No Word docs in email TU Darmstadt
Respect for open standards Ruf +49-6151-16-21344
Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]
On Sat, 18 Nov 2017 21:24:18 +0100, Rhialto wrote:
> On Sat 18 Nov 2017 at 15:02:01 +0100, Hauke Fath wrote:
>> And note the following excerpt from fortune(6):
>>
>> -o[...]
>
> You may have noted that the mentioned quotes are NOT part of the
> offensive set!
I haven't, and you didn't mention it, nor suggest that the supposedly
offensive quotes should be moved, instead of deleted.
> I agree that bad history should be remembered in context and not
> forgotten. However, that is not what these quotes do. They give no
> context,
I don't know about you, but the attribution to Adolf Hitler gives me
all the context I need for a quote, and then some.
> and they make A.H. seem like a relatively normal person. Now if
> he was quoted at his worst, it might be obvious what sort of monster he
> was,
I kind of object to this attempt to de-humanize Hitler. I think it very
much belittles the role of the millions of willingly helping hands (and
brains) he found, and without which he would not have gone anywhere.
Brecht's "Questions from A Worker Who Reads" applies, I guess:
<https://msu.edu/~sullivan/TransBrechtWorker.html>.
For better or worse, humanity gets to own Hitler, just like Pol Pot,
Stalin, Cromwell and all the other butchers. This is what we can turn
into, when push comes to shove.
> but that is not the effect of these quotes. His crimes against
> humanity are trivialised by putting things he said next to people like
> Mahatma Gandhi.
Like on a public library shelf ("biographies"), you mean, or on TV,
where a nazi war film will be displayed through the same apparatus as a
Gandhi film?
Cheerio,
hauke
--
Hauke Fath<ha...@espresso.rhein-neckar.de>
Ernst-Ludwig-Straße 15
64625 Bensheim
Germany
Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]
On Sat, 18 Nov 2017 13:21:25 +0100, Rhialto wrote: > It has come to my attention that FreeBSD has removed fortunes quoted > from Adolf Hitler a few days ago. I was very surprised that there > actually were such quotes! Nihil novae... <http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=33495> > I checked our fortune cookies database, and I was appalled to notice > that we do have the same quotes there. To my understanding, the fact that a certain quote is in the fortunes database does not mean the NetBSD project identifies with it in any way. > Apart from those quotes being > wholly inappropriate in a list of funny quotes, they are probably > illegal in Germany (where I now happen to live). I call bullshit on this one. Using symbols of Nazi Germany, like the Hitlergruß or swastikas, and denying its crimes is a criminal offense here . But you can quote Adolf Hitler till the cows come home if that's all you do, as opposed to identifying with the ideology. > I hereby propose to remove them (but not remove all fortunes). If we officially decide that each and every fortune cookie must comply with NetBSD rules, and not hurt any feelings whatsoever, we should indeed remove all of fortune(6). Pulling the quotes unfortunately does not change the harsh historic reality one bit. > I have sent a pr (bin/52735, http://gnats.netbsd.org/52735) with a > patch. >> How-To-Repeat: > > $ fortune -m Hitler all Just don't do that, then. And note the following excerpt from fortune(6): -oChoose only from potentially offensive aphorisms. Please, please, please request a potentially offensive fortune if and only if you believe, deep down in your heart, that you are willing to be offended. (And that if you are, you'll just quit using -o rather than give us grief about it, okay?) Cheerio, hauke -- Hauke Fath<ha...@espresso.rhein-neckar.de> Ernst-Ludwig-Straße 15 64625 Bensheim Germany
Re: Using NET_MPSAFE
On Wed, 9 Aug 2017 08:43:09 -0700, Brian Buhrow wrote: > Are you saying that pf(4) doesn't work well in NetBSD-8_BETA? Our single-router installation was rock stable under netbsd-5, and when it showed the occasional hiccup under -7, there was a push towards redundancy. So I set up a pair of machines running as failover routers (carp, pf) with netbsd-7, then netbsd-8. The crash rate went from twice a day to twice an hour; PRs are 51729, 51877, 51930, 52263. In the end, I had to acknowledge I was clearly out of my depth, and looked elsewhere. When I learned that FreeBSD had mp-enabled pf, my choice was made. The installation is stable, and max. throughput over 10 GBE is +50% over NetBSD. I put pkgsrc on the machines, and I do miss NetBSD's clean simplicity - FreeBSD feels byzantine at times. But there is no arguing in the face of stability. Cheerio, -- Hauke Fath<ha...@espresso.rhein-neckar.de> Ernst-Ludwig-Straße 15 64625 Bensheim Germany
Re: Using NET_MPSAFE
On Tue, 8 Aug 2017 16:53:11 -0700, Brian Buhrow wrote:
> Unfortunately, npf(4) doesn't have all
> the functionality we need to implement the configurations we use.
> Consequently, it may be necessary to MP-ify pf(4) as well, as I suspect
> that's easier than implementing its functionality in npf(4).
FreeBSD has taken that route, and after my ordeal with a netbsd-{7,8}
pf router pair I am quite happy with the result.
Cheerio,
hauke
--
Hauke Fath<ha...@espresso.rhein-neckar.de>
Ernst-Ludwig-Straße 15
64625 Bensheim
Germany
Re: -current panic
On 05/26/17 12:12, Hauke Fath wrote: All, after upgrading my infamous router pair to HEAD, I got an interesting panic just a few minutes ago: panic: kernel diagnostic assertion "(m)->m_type != MT_FREE" failed: file "/public/netbsd-developer/sys/kern/uipc_mbuf.c", line 1973 Hm, got a second one of those. And then this, FTFOI: NetBSD 7.99.73 (FIFI-$Revision$) #2: Fri May 26 15:51:24 CEST 2017 [...] fatal protection fault in supervisor mode trap type 4 code 0 rip 0x805bbd58 cs 0x8 rflags 0x10206 cr2 0x80008f892000 ilevel 0x8 rsp 0xfe810e863a50 curlwp 0xfe821e726420 pid 0.3 lowest kstack 0xfe810e8602c0 panic: trap cpu0: Begin traceback... vpanic() at netbsd:vpanic+0x140 snprintf() at netbsd:snprintf trap() at netbsd:trap+0xbab --- trap (number 4) --- m__freem() at netbsd:m__freem+0x59 ixgbe_txeof() at netbsd:ixgbe_txeof+0x175 ixgbe_mq_start_locked() at netbsd:ixgbe_mq_start_locked+0xa1 ixgbe_mq_start() at netbsd:ixgbe_mq_start+0x10a vlan_start() at netbsd:vlan_start+0x1be if_transmit() at netbsd:if_transmit+0x129 ether_output() at netbsd:ether_output+0x3d0 ip_output() at netbsd:ip_output+0x13b1 ip_forward() at netbsd:ip_forward+0x19f ipintr() at netbsd:ipintr+0x1349 softint_dispatch() at netbsd:softint_dispatch+0xd4 DDB lost frame for netbsd:Xsoftintr+0x4f, trying 0xfe810e863ff0 Xsoftintr() at netbsd:Xsoftintr+0x4f --- interrupt --- 0: cpu0: End traceback... rebooting... Cheerio, hauke -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
-current panic
All, after upgrading my infamous router pair to HEAD, I got an interesting panic just a few minutes ago: panic: kernel diagnostic assertion "(m)->m_type != MT_FREE" failed: file "/public/netbsd-developer/sys/kern/uipc_mbuf.c", line 1973 cpu2: Begin traceback... vpanic() at netbsd:vpanic+0x140 ugen_get_alt_index() at netbsd:ugen_get_alt_index m__freem() at netbsd:m__freem+0xab pf_free_fragment() at netbsd:pf_free_fragment+0xc3 pf_purge_expired_fragments() at netbsd:pf_purge_expired_fragments+0x5c pf_purge_thread() at netbsd:pf_purge_thread+0x79 cpu2: End traceback... rebooting... -- the machine doesn't have any usb devices attached. What's going on here? Cheerio, hauke -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
-current MKTPM=1 build failure
During a -current build with MKTPM=1, I have run into [...] --- tpm_nvread.o --- # compile tpm_nvread/tpm_nvread.o /var/tmp/netbsd-builds/developer/amd64/tools/bin/x86_64--netbsd-gcc -O2 -fPIE-std=gnu99 -Werror --sysroot=/var/tmp/netbsd-builds/developer/amd64/destdi /local/source/netbsd-developer/crypto/external/cpl/tpm-tools/dist/src/tpm_mgmt/tpm_nvread.c: In function 'main': /local/source/netbsd-developer/crypto/external/cpl/tpm-tools/dist/src/tpm_mgmt/tpm_nvread.c:273:49: error: 'S_IRUSR' undeclared (first use in this function) fd = open(filename, O_WRONLY|O_TRUNC|O_CREAT, S_IRUSR|S_IWUSR); ^ /local/source/netbsd-developer/crypto/external/cpl/tpm-tools/dist/src/tpm_mgmt/tpm_nvread.c:273:49: note: each undeclared identifier is reported only once for e /local/source/netbsd-developer/crypto/external/cpl/tpm-tools/dist/src/tpm_mgmt/tpm_nvread.c:273:57: error: 'S_IWUSR' undeclared (first use in this function) fd = open(filename, O_WRONLY|O_TRUNC|O_CREAT, S_IRUSR|S_IWUSR); ^ --- dependall-usr.bin --- /var/tmp/netbsd-builds/developer/amd64/tools/bin/nbctfconvert -g -L VERSION setemul.o --- dependall-crypto/external --- *** [tpm_nvread.o] Error code 1 nbmake[10]: stopped in /local/source/netbsd-developer/crypto/external/cpl/tpm-tools/bin/tpm_nvread which the following patch fixes Index: crypto/external/cpl/tpm-tools/dist/src/tpm_mgmt/tpm_nvread.c === RCS file: /cvsroot/src/crypto/external/cpl/tpm-tools/dist/src/tpm_mgmt/tpm_nvread.c,v retrieving revision 1.1.1.1 diff -u -u -r1.1.1.1 tpm_nvread.c --- crypto/external/cpl/tpm-tools/dist/src/tpm_mgmt/tpm_nvread.c 28 Jan 2012 02:57:29 - 1.1.1.1 +++ crypto/external/cpl/tpm-tools/dist/src/tpm_mgmt/tpm_nvread.c 12 Jan 2017 14:37:42 - @@ -23,6 +23,7 @@ #include #include #include +#include #include "tpm_nvcommon.h" #include "tpm_tspi.h" -- okay to commit? Cheerio, hauke -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
netbsd-7 kernel build failure
A netbsd-7 kernel build from today's sources with -Os errors out with # compile P3B-F/drmfb_pci.o /u/netbsd-builds/7/i386/tools/bin/i486--netbsdelf-gcc -msoft-float -mno-mmx -mno-sse -mno-avx -ffreestanding -fno-zero-initialized-in-bss -pipe -Os -march=pentium3 -fstack-protector -Wstack-protector --param ssp-buffer-size=1 -fno-strict-aliasing -fno-common -std=gnu99 -Werror -Wall -Wno-main -Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wno-unreachable-code -Wno-pointer-sign -Wno-attributes -Wextra -Wno-unused-parameter -Wold-style-definition -Wno-sign-compare --sysroot=/u/netbsd-builds/7/i386/destdir -Di386 -I. -I/public/netbsd-7/sys/../common/include -I/public/netbsd-7/sys/arch -I/public/netbsd-7/sys -nostdinc -DP1003_1B_SEMAPHORE -DMAXUSERS=64 -D_KERNEL -D_KERNEL_OPT -std=gnu99 -I/public/netbsd-7/sys/lib/libkern/../../../common/lib/libc/quad -I/public/netbsd-7/sys/lib/libkern/../../../common/lib/libc/string -I/public/netbsd-7/sys/lib/libkern/../../../common/lib/libc/arch/i386/string -D_FORTIFY_SOURCE=2 -I/public/netbsd-7/sys/external/bsd/drm2/include -I/public/netbsd-7/sys/external/bsd/common/include -I/public/netbsd-7/sys/external/bsd/drm2/include -I/public/netbsd-7/sys/external/bsd/drm2/include/drm -I/public/netbsd-7/sys/external/bsd/drm2/dist -I/public/netbsd-7/sys/external/bsd/drm2/dist/include -I/public/netbsd-7/sys/external/bsd/drm2/dist/include/drm -I/public/netbsd-7/sys/external/bsd/drm2/dist/uapi -I/public/netbsd-7/sys/external/bsd/common/include -D__KERNEL__ -I/public/netbsd-7/sys/../common/include -DCONFIG_AGP -I/public/netbsd-7/sys/external/bsd/drm2/dist/drm/i915 -I/public/netbsd-7/sys/external/bsd/drm2/i915drm -DCONFIG_DRM_I915_FBDEV -I/public/netbsd-7/sys/external/bsd/drm2/dist/drm/radeon -I/public/netbsd-7/sys/external/bsd/drm2/include/radeon -I/public/netbsd-7/sys/external/bsd/drm2/radeon -I/public/netbsd-7/sys/external/bsd/acpica/dist/include -c /public/netbsd-7/sys/external/bsd/drm2/pci/drmfb_pci.c --- drm_scatter.o --- /public/netbsd-7/sys/external/bsd/drm2/drm/drm_scatter.c: In function 'drm_sg_alloc': /public/netbsd-7/sys/external/bsd/drm2/drm/drm_scatter.c:83:10: error: 'sg' may be used uninitialized in this function [-Werror=maybe-uninitialized] dev-sg = sg; ^ cc1: all warnings being treated as errors *** [drm_scatter.o] Error code 1 nbmake: stopped in /var/obj/netbsd-builds/7/i386/sys/arch/i386/compile/P3B-F 1 error drm_sg_alloc_mem() sets up sg, but the compiler cannot know, I guess. hauke -- The ASCII Ribbon CampaignHauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-3281
Re: netbsd-7 kernel build failure
On Mon, 04 May 2015 16:18:42 +0200, Hauke Fath wrote: A netbsd-7 kernel build from today's sources with -Os errors out with [...] ... and a few more. Looks like '-Os' applies slightly different criteria than '-O2' to what gcc perceives as an unused variable. The question is - should we care? In the files I patched, initializing the variable clarified things, but that clarity lies in the eyes of the beholder... hauke -- The ASCII Ribbon CampaignHauke Fath () No HTML/RTF in emailInstitut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-3281
Re: pf--?
On Sat, 17 Jan 2015 00:50:16 +0100, Thomas Klausner wrote: Is there still much point in keeping pf(4) in NetBSD now that we have npf(4) (and also ipfilter(4))? We run a busy pf based router @work, and it generally just works where ipf(4) broke - has http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=27164 ever been fixed? And npf(4) - no offense meant to its authors - is neither stable nor feature complete at this point - watch the steady trickle of PRs against it. The last time it was updated was, according to the CHANGES files, in 2008, to the version coming with OpenBSD 4.2. It works for me. Answering your question: Yes, there is. Maybe drop it after NetBSD 10? ;) Cheerio, hauke -- Hauke Fathha...@espresso.rhein-neckar.de Ernst-Ludwig-Straße 15 64625 Bensheim Germany
[netbsd-7] in4_cksum: offset 0 too short for IP header 20
All, on a machine upgraded to yesterday's netbsd-7, the kernel issues an endless stream of in4_cksum: offset 0 too short for IP header 20 swamping syslogd. The machine runs pf(4). Has anybody seen this, or knows how to make it stop? Thanks, hauke -- Hauke Fathha...@espresso.rhein-neckar.de Ernst-Ludwig-Straße 15 64625 Bensheim Germany
Re: Removing openldap?
On Thu, 02 Oct 2014 22:56:56 +0400, Aleksej Saushev wrote: openldap is used by postfix, sshd and amd. There is also pam-ldap in pkgsrc that we might want to import into base. All this is only using the client part of openldap. I'd like better intergration of LDAP with at least PAM and NSS modules. Yes, but Thomas' point (which I support) is that unless _you_ commit to doing it, it's not going to happen any time soon. Note that back then, ldap support was a major selling point for an all-dynamically linked userland. Statically linking the distribution, meanwhile, has been broken for several releases. I've seen too many things go into the distribution with promises of great things to pass (build it, and they will come), and then go stale. ldap and mdns support are only two of them. New subsystems should come with a watchdog timer and zip lines, to be cut loose, if the promised development hasn't happened. As a side-effect, this might cut bikeshed debates short, since the proof will be in the pudding, instead of the hype and fears about it. hauke -- Hauke Fathha...@espresso.rhein-neckar.de Ernst-Ludwig-Straße 15 64625 Bensheim Germany
Re: Booting from gpt-on-raid1-on-gpt?
On Sat, 28 Sep 2013 11:20:53 + (UTC), Michael van Elst wrote: h...@spg.tu-darmstadt.de (Hauke Fath) writes: since I have just run into the problem again: Is there any perspective for booting NetBSD from a gpt-on-RAID1-on-gpt setup (see PR 44982) without falling back to disklabel(8)? What part of the boot process fails? Looking into things, I found that gpt(8) looks for a partition type that it considers bootable. And 'raid' is apparently not such a type, so gpt(8) will not install a mbr. The error message could probably be worded more clearly - I only understood what was going on after hexdump(1)ing the first block of the raw disk, and finding it empty. Booting requires - MBR to fetch PBR ... see above - MBR not installed won't fetch PBR. I still have to find out whether a type 'raid' partition will have a PBR, and where that would be located - at the beginning of the 'raid' (raidframe) partition, or at the beginning of the root partition on the raid? - PBR interpreting GPT - PBR detecting RAID(?) volume and raidframe label. My understanding is that PBR currently dowsn't do that. But my understanding is hazy, given the maze of little asm- and makefiles, all alike, that make up arch/i386/stand. - PBR interpreting GPT inside the RAID volume - PBR reading /boot - /boot repeating about the same to read /netbsd - /netbsd repeating about the same to mount / Step 2 and 3 of PBR (same code as in /boot) probably need to be implemented. Sounds spot on. I am still trying to tie the arch/i386/stand files to the steps you listed above... Thanks for your comments. hauke -- Hauke Fathha...@espresso.rhein-neckar.de Ernst-Ludwig-Straße 15 64625 Bensheim Germany
