Re: Looking for TNF clang format config file
On Wed, Aug 14, 2024 at 22:56:19 +0200, Thomas Klausner wrote:
> # newline before "{" except for functions
> BreakBeforeBraces: WebKit
The comment seems to contradict the value? We use newline before "{"
for functions, but not for control flow &c.
-uwe
Re: HEADS UP: plan to switch many ports over to GCC 12 soon
[trimmed the cc list down] On Mon, Jul 01, 2024 at 09:59:54 +0900, Rin Okuyama wrote: > With in-tree GCC 12.4, kernel crashes just same as 12.3 :( > > Even a single character is output to console. I tried to > drop some features from kernel config to reduce size > significantly, but it does not help. On the other hand, > same kernel works just fine if compiled by GCC 10.5. Are binutils the same? I'd first rule out section alignment/layout issues (cf. netwinder changes to make netbsd-10 work again). I'd compile the kernel with gcc 10, then remove (stow away, really) half the object files and compile with gcc 12. If the result works, repeat with the half of the remaining half. If it doesn't - restore the gcc10 objects and bisect them. I had to this couple of times on previous gcc uprqades. Sorry, I sitll haven't moved back most of my small machines from my self-isolation lair, so my landisk is currently not here to test. -uwe
Re: Specify swap device priority in fstab?
On Wed, Jun 05, 2024 at 12:28:45 -0400, Brad Spencer wrote: > Valery Ushakov writes: > > > On Wed, Jun 05, 2024 at 06:38:04 -0700, Paul Goyette wrote: > > > >> Yup, that works, even when using ``sw,dp,priority=100'' (ie, the > >> dp portion can intervene and it still works). > >> > >> Thanks - the obvious answer is the hardest to find! > > > > A sign that fstab(5) could use some clarifications. :) One can sort of > > make the necessary inferences, but explicit text (and examples) are > > better. [...] > While it may not be the most obvious, the required information is > already in swapctl(8) (at least in -current) as far as I can tell. Exegetical exercises are nice, but perhaps we should consider the target audience of man pages to be, say, a tired, sleep-deprived admin trying to fix a system at 3am :) Abundant cross-references are helpful, even if hard(er) to maintain. -uwe
Re: Specify swap device priority in fstab?
On Wed, Jun 05, 2024 at 06:38:04 -0700, Paul Goyette wrote: > Yup, that works, even when using ``sw,dp,priority=100'' (ie, the > dp portion can intervene and it still works). > > Thanks - the obvious answer is the hardest to find! A sign that fstab(5) could use some clarifications. :) One can sort of make the necessary inferences, but explicit text (and examples) are better. Can someone, please, tweak fstab(5) to explicitly say that some options from the options column are processed by the mount(8) frontend itself and the rest is passed to the appropriate mount program (where swapctl(8) is the "mount" program for swaps) via -o. We already have the text that explains fs_type, though that could use a bit of copyediting too. Don't worry about the markup too much, I'll clean it up if necessary. -uwe
Re: glitches in framebuffer console - NL/CR
On Wed, Mar 20, 2024 at 20:37:09 +0100, Riccardo Mottola wrote: > Boot, dmesg, login come up fine, no issue. > > Certain programs however print out the text by making only a NL and no > CR, making a staircase effect. > E.g. pkgin or dhcpcd do that. > Sometimes in this situation also keyboard input stops to work, e.g. > pkgin asks Y/n and typing does nothing. > dhcpcd completes without issues. May be something weird in your /etc/ttys? Like getty on both cons* and ttyE0 and the like? The input either works and just not echo'ed and needs explicit ^J instead or to get read by the program. Or it may be stolen by the other program reading from the terminal. Switch to another console and check "ps auxww" output for processes that use ttyE0. > Using bash however seems fine. readline explicitly manipulates tty state, so it can dodge a lot of weird terminal conditions. -uwe
Re: Usage/syntax for command-line utilities
On Mon, Mar 18, 2024 at 20:40:57 -0700, Paul Goyette wrote: > Why do we have drvctl(8) and gpt(8) (for example only, there are > others) which put the device-to-act-on at the end of the command: > > gpt [-Hnqrv] [-m mediasize] [-s sectorsize] [-T timestamp] > command [command_options] device > > while others such as dkctl(8) and scsictl(8) put the device-to-act-on > immediately after the utility name: > > dkctl device command [arg [...]] > scsictl device command [arg [...]] Imperative vs object-oriented? :) gpt show(wd3) vs. scsictl sd0.debug(2) Whatever the author of the tool prefers and finds "natural". ifconfig, e.g., is bit of a mixed bag, b/c stuff after the interface name is "parameters", but it also has stuff that is clearly commands in that postition (ifconfig gre0 create, etc). OO style makes more sense in places where the commands after the "object" are dependent on the type of the object. -uwe
Re: Removing a superfluous warning from xf86-input-ws/dist/src/ws.c
On Sun, Feb 04, 2024 at 20:23:24 +0100, Rhialto wrote: > and it prints this warning every time I scroll using the touchpad on my > ThinkPad. Apparently it is a "new" way for touchpads to report scrolling > (both horizontal and vertica). > > These messages are filling up my /var/log/Xorg.0.log and wearing out my > NVMe unnecesarily. > > This touchpad method is not supported by the xf86-input-mouse driver so > with that one the touchpad doesn't scroll. > > Shall I just remove the warning? May be make it reported only once, so that the message is still there in the log, but it's not spammed uselessly, adding no new information? -uwe
Re: Update ARFLAGS?
On Fri, Dec 29, 2023 at 12:06:26 +1100, matthew green wrote: > Thomas Klausner writes: > > > As noted in PR 57565, the default ARFLAGS in share/mk/sys.mk are > > broken - they use 'l' which changed behaviour between binutils 2.34 > > and 2.39. > > > > Ok to commit the change? > > > > (This broke the build of ruby-nokogiri recently, which is how I > > noticed.) > > the change? removing 'l'? yes... though i still find it > pretty offensive that it changed behaviour now. it was an > ignored option before so, removing it is the right change. Amen. -uwe
Re: Upgrading a 90s laptop from 5.1 to 10 -- no FD or CDROM
On Fri, Dec 22, 2023 at 05:48:57 -, jo...@sdf.org wrote: > I couldn't get the version of boot I have to recognize any USB or CF > drives. I guess because not recognized by BIOS? I guess I could upgrade > boot as a first step? [...] > [ 1.040] Firmware Error (ACPI): A valid RSDP was not found > (20221020/tbxfroot-275) Forgot about that one... You might want to experiment with custom kernels with pnpbios instead of ACPI. Machines from that era often have weird ACPI implementations. On the other hand pnpbios might have its own set of issues. -uwe
Re: Upgrading a 90s laptop from 5.1 to 10 -- no FD or CDROM
On Wed, Dec 20, 2023 at 23:34:34 -, jo...@sdf.org wrote: > I have a pcmcia 3Com NIC and so internet access (IPv6 only!). But the FD > adapter and the CDROM bay both died years ago. > > I can plug in a pcmcia CF card and mount it. The old BIOS can't boot from > that though. There's also a single USB revision 1.0 port. If you don't mind a bit of manual work, you can just easily upgrade in place. I've recently updated an old Dell Latitude CP of the late 90s vintage (iirc). The big issue was that drivers for the pcmcia network cards seems to have bitrotted w.r.t. infrastructural changes, so you might want to look out for that (one of the cards - ironically, a wifi - worked for me, but I had to set up an open 11b access point :). It's not hard, really. As far as I understand sysupgrade more or less just scripts that scenario, and I never really understood why one would need to script it. Compile a new kernel and get it onto your machine (present day GENERIC might be a bit too fat, make sure the necessary compat options are in place). Probably install it as netbsd.new or something so that if it doesn't work, you can still boot into the old one. Get the sets (from releng or build.sh distribution) onto the machine (or onto some removable medium you can plug into it). Make a backup of /rescue just in case if you don't have one. Boot with the new kenel. You may either boot multiuser into the old userland and give the new kernel a bit of a workout (then "shutdown now" into single user), of you may boot single user right away and go for the upgrade (don't forget to remount root read-write and mount /usr if it's on a separate fs). Go to where your sets are and do something like for f in [!ekx]*.tgz x[!e]*.tgz; do echo === $f ===; tar -C / -zxpf $f; done i.e. unpack all sets except etc, xetc, and kern* if you happen to have them from releng (that's basically a TL;DR of sysupgrade :). Actually on an old i386 you might want to avoid installing gpufw that is fat and not needed on an old machine anyway. Modifying the above to avoid gpufw but to include games is left as an exercise to the reader :) When the sets are unpacked, make sure you have stty rows/cols and TERM set properly and: etcupate -val -s etc.tgz -x xetc.tgz Unless you had some heavy customizations you will mostly just have to press "i" for "install" a bunch of times. The "d" for "delete" might sound a bit scary, but it's actually the safe option of "skip this new file, and leave the old file untouched". If need be you can run etcupdate repeatedly to verify your current state and to incrementally merge more new files. The two files you will have to pay attention to are passwd and groups, b/c for that a long a time gap they will contain changes (new users/groups) and you will have to merge these changes (in the interactive merge press "l" for for "left" for your user(s), "r" for "right" for the new users). After that etcupdate will tell you to run postinstall. If you updated etc, you only need postinstall to fix catpages, obsolete files and create new devices, iirc. Use (that's what etcupate runs at the end): postinstall -s etc.tgz -s xetc.tgz check and your judgement. Doing a round of "fix catpages" first and then "fix obsolete" should get rid of most of the noise. Re-run check after that. PS: "Ask your physician for the information to your individual case." etc, etc... -uwe
Re: grafana rc.d scripts reports process not running
On Fri, Dec 15, 2023 at 15:17:57 +0100, Thomas Klausner wrote: > So grafana saved its PID into /var/run/grafana.pid, which is what's > configured in the rc.d script as pidfile, but the status command > thinks it's not running, despite a grafana process with the > corresponding PID running. Can you run the status command with sh -x? -uwe
Re: Can't cross-build on macOS: clock.h
On Fri, Oct 27, 2023 at 19:10:09 +1100, Simon Burge wrote: > isn't installed on all architectures? The original > change was to include but then that added #ifdef magic. > > Since is already a system header file, wouldn't it be > better to make sure is installed everywhere? This happens when we build a tool - which is a bit of a balancing act b/c we mix bits of netbsd sources with host system's headers. -uwe
Re: gdb issues?
On Wed, Oct 11, 2023 at 09:31:19 +0200, Havard Eidnes wrote:
> armv7: {2} gdb .core
> GNU gdb (GDB) 8.3
> Copyright (C) 2019 Free Software Foundation, Inc.
> [another dozen or so lines of fsf spam]
Pro tip: gdb -q :)
-uwe
Re: kernel size change
On Thu, Jul 13, 2023 at 00:51:45 +0200, Thomas Klausner wrote: > diff old new (after removing address column): For the love of god, please use diff -u for diffs :) -uwe
Re: I can't cross build 10 on 10??
On Fri, Apr 28, 2023 at 13:22:02 +1200, Lloyd Parkes wrote: > It looks like something is going wrong with the host tools and they are > trying to use host includes when they should be using in-tree includes. One > concise example is [...] > For some reason, the include path isn't set correctly. I can see that the > missing files are in the tree. You can go to $OBJDIR/lib/csu and re-run that command with --verbose and gcc will tell you the include directories it uses. You should some something like: ignoring nonexistent directory "/home/uwe/work/netbsd/build/distrib/sparc/usr/local/include" ignoring nonexistent directory "/home/uwe/work/netbsd/build/tools/lib/gcc/sparc--netbsdelf/10.4.0/../../../../sparc--netbsdelf/include" #include "..." search starts here: #include <...> search starts here: /home/uwe/work/netbsd/ro/src/lib/csu/arch/sparc /home/uwe/work/netbsd/ro/src/lib/csu/common . /home/uwe/work/netbsd/build/distrib/sparc/usr/include/gcc-10 /home/uwe/work/netbsd/build/tools/lib/gcc/sparc--netbsdelf/10.4.0/include-fixed /home/uwe/work/netbsd/build/distrib/sparc/usr/include End of search list. -uwe
Re: Building old systems
On Thu, Apr 20, 2023 at 11:08:43 -0600, Brook Milligan wrote: > What should I be configuring to make sure that a tooldir compiler is > usable? The tools in the tooldir expect that the netbsd src makefiles call them with -isysroot (or some such flag(s), sorry, writing from memory). I have some very old notes about making the tooldir+destdir into a self-contained cross toolchain: http://www.stderr.spb.ru/~uwe/netbsd/cross.html so that you can use CC=arch-netbsd-gcc and don't worry about -isysroot, -L, etc (I used that procedure to work e.g. on j2me cldc jvm and qt embedded). But keep in mind that that will give you a *cross* toolchain. You cannot expect it to work natively for the same $arch host as the target. You *might* be lucky, but the logistics of aligning all the things just right to get that hack to work is probably too compilcated and the result is probably too fragile. Since you try to use tooldir as HOST_*, you must be on a netbsd host - so it's probably easier to use a chroot with an old netbsd system (base + comp) in that case. -uwe
Re: Building old systems
On Wed, Apr 19, 2023 at 16:34:19 -0600, Brook Milligan wrote: > I am trying to build an old kernel with build.sh on a recent > (9.99.108) amd64 system. However, compiling nbmake fails > immediately with errors like > > /usr/bin/ld: buf.o:(.bss+0x0): multiple definition of `debug_file'; > arch.o:(.bss+0x0): first defined here > > Unless I am doing something silly, it clearly is not possible for a > current system to build old tools and kernels at arbitrary points in > time. > > What is the best strategy for building old kernels to, for example, > bisect the code? It might be better to use corresponding older tools to build older kernels. Modern gcc switched to -fno-common by default, so if you want to compile an older kernel that has multiple variable definitions you will need to arrange for -fcommon option to be used. -uwe
Re: LLONG_MAX not available from c++
On Fri, Mar 31, 2023 at 15:25:02 +, RVP wrote: > You have to create an empty file for `-E -dM' to work correctly: Not necessary, -x c++ is enough, but that's a very common pitfall indeed. # c, despite being called as c++ $ g++ -dM -E - < /dev/null | egrep -i 'stdc|plus' #define __STDC_HOSTED__ 1 #define __STDC_UTF_16__ 1 #define __STDC_VERSION__ 201112L #define __GNUC_STDC_INLINE__ 1 #define __STDC_UTF_32__ 1 #define __STDC__ 1 # needs explicit language selection with -x or an an input file suffix $ gcc -x c++ -dM -E - < /dev/null | egrep -i 'stdc|plus' #define __STDC_HOSTED__ 1 #define __cplusplus 199711L #define __STDC__ 1 -uwe
i386: 9.99.107 traps booting on VirtualBox
I tried to upgrade a 32-bit VBox VM from 9.99.99 to .107 and the
kernel from the yesterday's sources crashes on boot.
...
attimer1: attached to pcppi0
fatal page fault in supervisor mode
trap type 6 code 0 eip 0xc0d3d808 cs 0x8 eflags 0x10246 cr2 0x3c ilevel 0x7 esp
0x6
curlwp 0xc1657840 pid 0 lid 0 lowest kstack 0xc192e2c0
kernel: supervisor trap page fault, code=0
Stopped in pid 0.0 (system) at netbsd:hardclock+0x23: movl3c(%esi),%eax
db{0}> bt
hardclock(0,0,da3eef6c,c04ac8f1,0,0,0,0,0,0) at netbsd:hardclock+0x23
clockintr(0,0,0,0,0,0,0,0,c2d72000,c010322a) at netbsd:clockintr+0x2a
intr_kdtrace_wrapper(c2f50680,c1930d9c,0,0,0,0,0,0,0,0) at
netbsd:intr_kdtrace_wrapper+0x21
--- switch to interrupt stack ---
Xintr_legacy0() at netbsd:Xintr_legacy0+0xda
--- interrupt ---
outb(c16230c0,c1620f80,0,20,1,0,0,c16c2a80,c1930e94,0) at netbsd:outb+0x9
intr_establish_xname(0,c16230c0,0,1,7,c04c96c5,0,0,c134e6d0,0) at
netbsd:intr_establish_xname+0x2ba
isa_intr_establish_xname(0,0,1,7,c04c96c5,0,c134e6d0,c1930f14,c04c9bbf,0) at
netbsd:isa_intr_establish_xname+0x91
isa_intr_establish(0,0,1,7,c04c96c5,0,c1930f60,c0d3d1ca,c04b6858,1000) at
netbsd:isa_intr_establish+0x3c
i8254_initclocks(c04b6858,1000,3,c11b01f0,db0bc000,db0bb000,c166db40,0,c1930f60,c0e5f3f7)
at netbsd:i8254_initclocks+0x3a
initclocks(3,5,64,0,0,0,0,0,1680,0) at netbsd:initclocks+0x1c
main(0,0,0,0,0,0,0,0,0,0) at netbsd:main+0x365
-uwe
Re: noisy dhcpcd messages
On Sat, Nov 05, 2022 at 17:41:54 +0300, Valery Ushakov wrote: > > Or syslog has a different bug, because more details from the same log > > file: > > You can probably run syslog with debugging enabled, but it looks like > it needs a small fix to be able to specify debug level without > recompilation (the relevant dprintf is for D_DATA, which is not in > D_DEFAULT) - see usr.sbin/syslogd/syslogd.c:331 I have just committed the fix to make -d accept an optional argument. You can run syslogd -d2 (D_DATA) to get f_prevcount related messages. (You'll still need to recompile syslogd, but only once ;) -uwe
Re: noisy dhcpcd messages
On Sat, Nov 05, 2022 at 13:38:34 +0100, Thomas Klausner wrote: > Date: Sat, 5 Nov 2022 13:38:34 +0100 > From: Thomas Klausner > Subject: Re: noisy dhcpcd messages > To: current-users@NetBSD.org > > On Tue, Nov 01, 2022 at 01:29:19PM +0300, Valeriy E. Ushakov wrote: > > On Tue, Nov 01, 2022 at 10:05:19 +0100, Thomas Klausner wrote: > > > > > What's up with these log lines? > > > > > > Oct 31 07:52:59 yt dhcpcd[3496]: wm0: requesting DHCPv6 information > > > Oct 31 07:53:52 yt syslogd[4885]: last message repeated 5 times > > [...] > > > This is not a new issue, I can find these log lines in my messages > > > files going back to at least August 31. Does this message have a point > > > or should we remove it from the default log level? > > > > It is, but in -current, > > Do you mean "it is removed, but in -current"? That confuses me, > because these messages I see are on 9.99.104. Then it's trying to tell you something, I guess :) The logic in dhcpcd that is in current is to log that message at info the first time and then to use debug for it unless $reasons. But my knowedge of dhcpcd internals is not enough to tell interpret those reasons in a human readable way... See dhcp6_startinform external/bsd/dhcpcd/dist/src/dhcp6.c:1651 if (state->new_start || (state->new == NULL && !state->failed)) llevel = LOG_INFO; else llevel = LOG_DEBUG; logmessage(llevel, "%s: requesting DHCPv6 information", ifp->name); > Or syslog has a different bug, because more details from the same log > file: You can probably run syslog with debugging enabled, but it looks like it needs a small fix to be able to specify debug level without recompilation (the relevant dprintf is for D_DATA, which is not in D_DEFAULT) - see usr.sbin/syslogd/syslogd.c:331 -uwe
Re: nosiy dhcpcd messages
On Tue, Nov 01, 2022 at 10:05:19 +0100, Thomas Klausner wrote: > What's up with these log lines? > > Oct 31 07:52:59 yt dhcpcd[3496]: wm0: requesting DHCPv6 information > Oct 31 07:53:52 yt syslogd[4885]: last message repeated 5 times [...] > This is not a new issue, I can find these log lines in my messages > files going back to at least August 31. Does this message have a point > or should we remove it from the default log level? It is, but in -current, we need to either pull up dhcpd or backport the relevant change that logs those messages at info ~once and then downgrades it to debug. -uwe
Re: building source against installed libraries?
On Mon, Oct 31, 2022 at 12:07:03 +0100, Thomas Klausner wrote:
> On Mon, Oct 31, 2022 at 01:46:56PM +0300, Valeriy E. Ushakov wrote:
> > On Mon, Oct 31, 2022 at 11:10:24 +0100, Thomas Klausner wrote:
> >
> > > For test builds, I use 'USETOOLS=no make' to avoid building a
> > > toolchain. However that still wants to link against libraries built
> > > in the source tree, i.e. I have to 'cd /usr/src/lib/libcrypto &&
> > > USETOOLS=no make' to build a new libcrypto if this library is used.
> > >
> > > Is there a toggle to build against the installed libraries instead?
> >
> > It's entirely unclear from this description what exactly you are
> > trying to do and how does it fail.
>
> I'm trying this:
>
> wiz@yt:/usr/src/external/bsd/nsd> USETOOLS=no make
>
> and get
> ...
> all ===> lib/libnsd
> all ===> lib/libxfrd
> all ===> sbin
> all ===> sbin/nsd
> make[2]: don't know how to make
> /disk/6/archive/foreign/src/external/bsd/libevent/lib/libevent/libevent.a.
> Stop
>
> I want the build to use /usr/lib/libevent.a instead.
>
> > If I have to venture a guess (I don't have time atm to second guess/
> > reverse engineer the question), you are probably running into
> > something like LIBDPLIBS dependencies that are explicitly listed in
> > the in-tree makefiles, b/c those makefiles are intended to build the
> > in-tree code (e.g. for curses I would disable its LIBDPLIBS dependency
> > on terminfo). Just overriding them on the command line might help.
>
> I guess this is
>
> ./Makefile.inc:DPLIBS+= event
> ${NETBSDSRCDIR}/external/bsd/libevent/lib/libevent
>
> so perhaps what you're talking about?
Yes. Makefile.inc in nsd subdirs will use that variable to set
PROGDPLIBS and LIBDPLIBS - which are the real vars you want to avoid.
> What do I have to set? Do I have to do this for every library
> separately?
I'm afraid you will have to fix bsd.prog.mk :), b/c it uses PROGDPLIBS
to add libs to LDADD, etc. There's also incomplete s/BIN/PROG/ edito
in that code.
Pooka hacked bsd.lib.mk in revision 1.325 to do something like what
you want but for libs, and for individual libs only.
You probably want to add a bit of logic there that convert *DPLIBS
into -l for LDADD but without -L and without the dependency parts.
-uwe
Re: building source against installed libraries?
On Mon, Oct 31, 2022 at 11:10:24 +0100, Thomas Klausner wrote: > For test builds, I use 'USETOOLS=no make' to avoid building a > toolchain. However that still wants to link against libraries built > in the source tree, i.e. I have to 'cd /usr/src/lib/libcrypto && > USETOOLS=no make' to build a new libcrypto if this library is used. > > Is there a toggle to build against the installed libraries instead? It's entirely unclear from this description what exactly you are trying to do and how does it fail. If I have to venture a guess (I don't have time atm to second guess/ reverse engineer the question), you are probably running into something like LIBDPLIBS dependencies that are explicitly listed in the in-tree makefiles, b/c those makefiles are intended to build the in-tree code (e.g. for curses I would disable its LIBDPLIBS dependency on terminfo). Just overriding them on the command line might help. -uwe
Re: How to map Alt keys in X windows under NetBSD-9?
On Tue, Oct 11, 2022 at 01:28:31 -0700, Brian Buhrow wrote:
> It looks like all is working as I expect, except I can't seem to
> generate an alt-return key sequence. I just get a bell when I try
> to do this and the application I'm using doesn't receive the
> keystroke.
I haven't used xterm in ages, but defining key bindings might help
here. E.g. - from a very old xresources file:
XTerm*VT100*Translations:#override \
ShiftPrior:scroll-back(1,page) \n\
ShiftNext: scroll-forw(1,page) \n\
The function to "input" literal text into the terminal is
string("text") or string(0x42)
-uwe
Re: Virtio Viocon driver - possible to backport from OpenBSD?
On Thu, Aug 04, 2022 at 21:53:25 +0200, Matthias Petermann wrote: > the OpenBSD virtio driver has its origin in NetBSD. Viocon Support > was added later and not ported back yet. I am wondering how much > effort it would take to merge it from > > https://cvsweb.openbsd.org/src/sys/dev/pv/viocon.c?rev=1.8&content-type=text/x-cvsweb-markup My uninformed estimation would be from "not that much" to "hardly any". -uwe
Re: namespace pollution? clone()
On Mon, Aug 01, 2022 at 16:50:14 +0200, Thomas Klausner wrote: > On Mon, Aug 01, 2022 at 05:45:23PM +0300, Valeriy E. Ushakov wrote: > > Shouldn't we expose __clone(2) (the real symbol in the reserved > > namespace) under _NETBSD_SOURCE and only hide clone(2) weak alias > > under _GNU_SOURCE? You kinda sidestep some potential issues here in > > this case b/c __clone is an assembler syscall stub, so there's no C > > source that implements __close() that has to see the declaration. > > I don't understand the problem you see here - please fix it as you > find appropriate. I think we should still expose __clone() under _NETBSD_SOURCE, but expose clone() only under _GNU_SOURCE. My original reply that prompted your patch was not very clear about this, but it talked specifically about clone() (and clone() only). Your patch hides both clone() and __clone() under _GNU_SOURCE. You were not forced to consider this choice b/c __clone() is not implemented in C, so there's no C code in the tree that needs to see the __clone() prototype that your patch hides. __clone is in the reserved namespace, so no well behaving programs should be affected by that declaration. -uwe
Re: namespace pollution? clone()
On Mon, Aug 01, 2022 at 15:57:19 +0200, Thomas Klausner wrote: > On Tue, Jul 26, 2022 at 03:03:54PM +0200, Martin Husemann wrote: > > On Tue, Jul 26, 2022 at 03:46:14PM +0300, Valery Ushakov wrote: > > > On Linux clone(2) is declared only for _GNU_SOURCE, which explains why > > > linux doesn't run into the name clash. I gather we should follow > > > suit, as that's what the apps expect. > > > > Yes, that is the right thing to do here, especially as clone(2) does > > only exist as a portability helper for linux code. > > > > I think we could even pull that change up to -9. > > The attached diff survived a complete amd64-current build. Ok to commit? > Index: sched.h > === > RCS file: /cvsroot/src/include/sched.h,v > retrieving revision 1.12 > diff -u -r1.12 sched.h > --- sched.h 11 Jan 2009 03:04:12 - 1.12 > +++ sched.h 1 Aug 2022 13:57:06 - > @@ -59,20 +59,26 @@ > #define sched_yield __libc_thr_yield > #endif /* __LIBPTHREAD_SOURCE__ */ > > -#if defined(_NETBSD_SOURCE) > - > __BEGIN_DECLS > > +#if defined(_NETBSD_SOURCE) > + > /* Process affinity functions (not portable) */ > int sched_getaffinity_np(pid_t, size_t, cpuset_t *); > int sched_setaffinity_np(pid_t, size_t, cpuset_t *); > > +#endif /* _NETBSD_SOURCE */ > + > +#if defined(_GNU_SOURCE) > + > /* Historical functions, not defined in standard */ > +/* Linux man page documents these functions as only available when > + * _GNU_SOURCE is defined */ > pid_t clone(int (*)(void *), void *, int, void *); > pid_t__clone(int (*)(void *), void *, int, void *); > > -__END_DECLS > +#endif /* _GNU_SOURCE */ > > -#endif /* _NETBSD_SOURCE */ > +__END_DECLS > > #endif /* _SCHED_H_ */ Shouldn't we expose __clone(2) (the real symbol in the reserved namespace) under _NETBSD_SOURCE and only hide clone(2) weak alias under _GNU_SOURCE? You kinda sidestep some potential issues here in this case b/c __clone is an assembler syscall stub, so there's no C source that implements __close() that has to see the declaration. -uwe
Re: namespace pollution? clone()
On Tue, Jul 26, 2022 at 13:27:43 +0300, Valery Ushakov wrote: > On Tue, Jul 26, 2022 at 12:00:16 +0200, Thomas Klausner wrote: > > > I wonder why it's visible though, since in sched.h it's protected by > > _NETBSD_SOURCE. > > Re-run that command with -E -dD and without -c and related options Ok, so _NETBSD_SOURCE is the default unless ansi, posix or x/open was explicitly requested. sched.h declares both clone and __clone, where the latter is the actual function and the former is a weak alias. On Linux clone(2) is declared only for _GNU_SOURCE, which explains why linux doesn't run into the name clash. I gather we should follow suit, as that's what the apps expect. -uwe
Re: namespace pollution? clone()
On Tue, Jul 26, 2022 at 12:00:16 +0200, Thomas Klausner wrote: > I wonder why it's visible though, since in sched.h it's protected by > _NETBSD_SOURCE. Re-run that command with -E -dD and without -c and related options -uwe
syslog spam from nslookup
recentish current spams syslog on each invocation of nslookup: Jun 27 18:48:53 hd32 nslookup: setting maxthreads to 4 from 128 Jun 27 18:48:53 hd32 nslookup: isc_hp_new: max_hps=1 max_threads=4 Jun 27 18:49:08 hd32 syslogd[305]: last message repeated 3 times Looks like Christos added this to debug some problem (in bind itself, I guess), but I'd say unconditional LOG_ERR is way too verbose for it given that this code is used not just by bind itself. Please, can we tune it down? -uwe
Re: Archive of .iso images for -current
On Wed, Jun 15, 2022 at 00:05:43 +, Chavdar Ivanov wrote: > On 14 June 2022 23:06:56 (+01:00), Roland Illig wrote: > > > NetBSD-current fails for me in a VirtualBox with more than 1 CPU. > > > > https://gnats.netbsd.org/56883 > > https://gnats.netbsd.org/56884 > > https://gnats.netbsd.org/56885 > > > > NetBSD 9.2 from 2020-02-14 works fine. > > NetBSD 9.99.97 from 2022-06-14 doesn't work. > > It works just fine for me: Features of the host CPU are exposed to the guest, but not all of them - that might also be a factor if your host CPU is spiffy enough (disclaimer: I am clueless about x86 cpu features). ISTR, Qt didn't work in certain cases inside VBox b/c part of Qt code checked CPUID and correctly detected that some feature was not available, while some other part of Qt code checked instead, roughly speaking, the CPU generation and incorrectly assumed that the same feature is available in all CPUs of that generation. http://virtualbox.org/manual/ch08.html#vboxmanage-modifyvm and search for cpuid. -uwe
Re: x86 console size
On Thu, Jun 09, 2022 at 20:50:07 +, RVP wrote: > On Thu, 9 Jun 2022, Valery Ushakov wrote: > > > Can't we just fix the font name in wsfont/bold16x32.h to be > > Boldface-16x32? :) Avoids confusion in wsfontload -l output too. > > Yes! I would prefer that. Any objections to this from others? We have that font included into several kernels but I guess its primary use is to have a large'ish font for automatic font selection to use for higher-res displays. I.e. people probably don't have it in their wscons.conf, so renaming it shouldn't break things too much for people. > > PS: would be nice to have a version of echo that shqoute(3) its > > arguments to use for DOIT too. > > This, below, do? (I did the same with printf(1)--"%q", but I was just > chucking away fieldwidth and precesion there, so echo it is.): Sorry, I was sloppy in my wording, I didn't mean echo(1), just *some* echo-like thing (printf, vis, ...). vis already supports VIS_SHELL &c, but its output mostly makes me want to claw my eyes out, and not in a good way. Since %q is already in bash and zsh there's an argument to be made that it's the way to go, if only to avoid gratuitous divergence. Adding flags to echo(1) is probably not the best idea in any case. ISTR, kre@ commented on that bit of history some time in the past on one of the lists. shquote(3) is not intended for human consumption, so we might also want to think about a pretty-printing version (may be as new vis(3) flag?) that tries to DTRT and produce more human-friendly output. I think our shell's set -x (that is intended for humans) already has the code. -uwe
Re: x86 console size
On Wed, Jun 08, 2022 at 21:35:49 +, RVP wrote:
> Apropos that: can this patch be applied so that font-names (and their
> filenames) can be quoted more intuitively?
> Like this:
>
> setvar ttyE0 fontBoldface\ 16x32
>
> instead of (currently) this:
>
> setvar ttyE0 fontBoldface\\\ 16x32
>
> An example in wscons.conf(5) indicating this would also be helpful.
>
> -RVP
>
> ---START---
> diff -u etc/rc.d.orig/wscons etc/rc.d/wscons
> --- etc/rc.d.orig/wscons 2011-08-09 08:08:10.0 +
> +++ etc/rc.d/wscons 2022-06-08 21:21:47.950605000 +
> @@ -87,7 +87,7 @@
> cmd="$cmd -e $enc"
> ;;
> esac
> - cmd="$cmd -N $name $file"
> + cmd="$cmd -N \"$name\" \"$file\""
> eval $DOIT $cmd
> ;;
>
> ---END---
Uhm, you cite "setvar" in your example, but the patch affects handling
of the "font" command, it seems.
Can't we just fix the font name in wsfont/bold16x32.h to be
Boldface-16x32? :) Avoids confusion in wsfontload -l output too.
eval is nasty, but here we currently need it to undo the quoting of
the argument to -N (in your patch) or the extra backspace (before your
patch).
So I'd rather we avoid it altogether and rewrite the loop to consume
all the arguments first, then use the
set -- "$@" ...
idiom to construct the command line, something along the lines of:
set -- "$@" ${enc:+ "-e" "$enc"}
set -- "$@" ${name:+ "-N" "$name"}
set -- "$@" ${file:+ "-f" "$file"}
$DOIT "$cmd" "$@"
PS: would be nice to have a version of echo that shqoute(3) its
arguments to use for DOIT too.
-uwe
Re: x86 console size
On Tue, Jun 07, 2022 at 19:02:08 +0200, Reinoud Zandijk wrote: > On Sun, Jun 05, 2022 at 11:52:51AM +, RVP wrote: > > On Sun, 5 Jun 2022, Reinoud Zandijk wrote: > > > > > Could switching to the big fonts be an option? > > > > > > > With both fonts compiled in you can switch between them > > using: > > > > wsconsctl -dw font='Boldface 16x32' > > wsconsctl -dw font=Boldface > > These work quite well! Only how to configure this? When and where is > this set and configured? man 5 wscons.conf -uwe
Re: Framebuffer console font size selection issues?
On Thu, May 26, 2022 at 17:13:37 -0500, John D. Baker wrote:
> So, I managed to switch "ttyE0" ("constty") to "Boldface" (8x16). I
> tried to do the same for the other virtual terminals, but "/dev/ttyE0"
> seems hard-coded rather than operate on the current terminal or to be
> able to specify a terminal. How can I change the font on "/dev/ttyE[1-3]"?
wsconstctl -f /dev/ttyE1 -dw font=Whatever
etc. -f `tty` is convenient if you are doing that interactively on
the terminal you want to change.
-uwe
Re: /dev/wsfont permissions (Was: CVS commit: src/sys/dev/wsfont)
On Fri, May 13, 2022 at 02:49:29 +0300, Valery Ushakov wrote: > On Thu, May 12, 2022 at 23:17:42 +, Valeriy E. Ushakov wrote: > > > Module Name:src > > Committed By: uwe > > Date: Thu May 12 23:17:42 UTC 2022 > > > > Modified Files: > > src/sys/dev/wsfont: wsfontdev.c > > > > Log Message: > > wsfont(4): WSDISPLAYIO_LDFONT requires device opened for writing. > > /dev/wsfont used to be root:root 0600 and didn't bother to check > FWRITE in its ioctl code. macallan@ recently added support for > listing the loaded fonts (WSDISPLAYIO_LISTFONTS, wsfontload -l). It > would make sense to make that available to normal users - it's weird > to allow them to set the font but not list the available fonts. But > that creates a bit of a problem if someone uses new MAKEDEV that > creates 0644 /dev/wsfont but boots an old kernel that doesn't have the > FWRITE check. Any thoughts on this? The problematic scenario is that the system is upgraded, new MAKEDEV is run after the upgrade to (re)create the devices, it creates world readabile /dev/wsfont, and then an old kernel is booted (which is kinda in the unsupported territory). That would allow fonts to be loaded by anyone, exposing whatever bugs are lurking in wsfont(4) to J. Random User. Does anyone have a secret devfs project that can be merged in time for 10 by any chance? :) -uwe
/dev/wsfont permissions (Was: CVS commit: src/sys/dev/wsfont)
On Thu, May 12, 2022 at 23:17:42 +, Valeriy E. Ushakov wrote: > Module Name: src > Committed By: uwe > Date: Thu May 12 23:17:42 UTC 2022 > > Modified Files: > src/sys/dev/wsfont: wsfontdev.c > > Log Message: > wsfont(4): WSDISPLAYIO_LDFONT requires device opened for writing. /dev/wsfont used to be root:root 0600 and didn't bother to check FWRITE in its ioctl code. macallan@ recently added support for listing the loaded fonts (WSDISPLAYIO_LISTFONTS, wsfontload -l). It would make sense to make that available to normal users - it's weird to allow them to set the font but not list the available fonts. But that creates a bit of a problem if someone uses new MAKEDEV that creates 0644 /dev/wsfont but boots an old kernel that doesn't have the FWRITE check. -uwe
Re: xterm-color256: Different behavior between NetBSD 9.2 and 9.99.93?
On Thu, Feb 03, 2022 at 14:15:45 +0100, Martin Husemann wrote: > Bug in the terminfo compiler? http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/tic/tic.c#rev1.39 sounds like it might be related. -uwe
Re: Heads up: objdir is now rm -rf resistent
On Wed, Dec 15, 2021 at 07:53:55 -0500, Greg Troxel wrote: > I wonder if "rm -rf" should actually succeed with these modes, by doing > a chmod when necessary. It has always seem to me that -f is supposed to > really mean -f. But maybe POSIX says otherwise. That would be a security hole, wouldn't it? There will be a window where the directory that is not supposed to be readable becomes readable. -uwe
Re: Help with libcurses and lynx under NetBSD-9 and -current?
On Tue, Sep 21, 2021 at 17:24:16 +0930, Brett Lymn wrote: > On Tue, Sep 21, 2021 at 07:08:16AM +0300, Valery Ushakov wrote: > > > > nl/nonl are defined to affect *input* translation, turning off ICRNL, > > so that apps can distinguish carriage return key. I *guess* that the > > code changes ONLCR in lockstep out of lazyness, so that for apps that > > run with echo/nl the nl->cr+nl on output is done by tty(4). Of course > > that bites back by messing up cud1. I would say this is saving a > > penny losing a pound. > > Well, ONLCR is not explicitly unset on start up AFAICT, the state is > noted and the refresh code handles it. Right, right, but this is ... deeply embarassing. Please, can we get this fixed? -uwe
Re: Help with libcurses and lynx under NetBSD-9 and -current?
On Tue, Sep 21, 2021 at 07:43:28 +0930, Brett Lymn wrote: > On Mon, Sep 20, 2021 at 02:44:21PM +0300, Valery Ushakov wrote: > > > > > > Not always. You are right it is ttys that is doing it. The bug was > > > that cursor down with onlcr on always moved the cursor to the first > > > column of the next line. > > > > Right, right, and my question is: why do we have onlcr on for curses > > output? > > That is a good question, onlcr is explicitly set/unset in a few places > so it appears to be deliberate. > > > > Window(1) doesn't use ^J for cursor down so the output was > > > stair-stepping. > > > > Do you mean curses code was running with onlcr and was compensating > > for its own bug? > > It would appear so and has been doing this since before NetBSD which is > not a justification, just an observation. nl/nonl are defined to affect *input* translation, turning off ICRNL, so that apps can distinguish carriage return key. I *guess* that the code changes ONLCR in lockstep out of lazyness, so that for apps that run with echo/nl the nl->cr+nl on output is done by tty(4). Of course that bites back by messing up cud1. I would say this is saving a penny losing a pound. PS: From a quick look at xcurses - it seems to say that cbreak mode implies ICRNL cleared: cbreak Mode - [...] This mode achieves the same effect as non-canonical-mode, Case B input processing (with MIN set to 1 and ICRNL cleared) as specified in the XBD specification. -uwe
Re: Help with libcurses and lynx under NetBSD-9 and -current?
On Mon, Sep 20, 2021 at 07:37:55 +0930, Brett Lymn wrote: > On Fri, Sep 17, 2021 at 02:32:39PM +0300, Valery Ushakov wrote: > > > > Huh?! ^J does NOT have that side effect, ttys onlcr does. Which > > should be turned off for curses output, shouldn't it? > > > > Not always. You are right it is ttys that is doing it. The bug was > that cursor down with onlcr on always moved the cursor to the first > column of the next line. Right, right, and my question is: why do we have onlcr on for curses output? > Window(1) doesn't use ^J for cursor down so the output was > stair-stepping. Do you mean curses code was running with onlcr and was compensating for its own bug? -uwe
Re: Help with libcurses and lynx under NetBSD-9 and -current?
On Fri, Sep 17, 2021 at 07:33:00 +0930, Brett Lymn wrote: > which was the case with the previous bug I squashed. That one had been > there since curses was imported into NetBSD, every other terminal in > popular use must use ^J for cud1 which had the side effect of moving the > cursor to the beginning of the next line but window has a true cursor > down that does not move the cursor to the beginning of the next line. > It took me ages to believe that was the issue. Huh?! ^J does NOT have that side effect, ttys onlcr does. Which should be turned off for curses output, shouldn't it? -uwe
Re: VirtualBox guest additions - new failure
On Mon, Aug 09, 2021 at 20:11:52 +0100, Chavdar Ivanov wrote: > Awesome, thanks! The following does the job: > > --- src/VBox/Additions/common/VBoxGuest/VBoxGuest-netbsd.c.ORIG > 2021-07-28 17:16:22.0 +0100 > +++ src/VBox/Additions/common/VBoxGuest/VBoxGuest-netbsd.c > 2021-08-09 20:10:02.660642422 +0100 > @@ -416,7 +416,10 @@ > if (RT_FAILURE(rc)) > goto fail; > > -#if __NetBSD_Prereq__(9,99,82) > +#if __NetBSD_Prereq__(9,99,88) > +config_found(sc->sc_dev, &am, wsmousedevprint, > + CFARGS(.iattr = "wsmousedev")); > +#elif __NetBSD_Prereq__(9,99,82) > config_found(sc->sc_dev, &am, wsmousedevprint, > CFARG_IATTR, "wsmousedev", > CFARG_EOL); Sorry for the delay. I've committed this to the VBox repository both to trunk and to the 6.1 branch. One nit though, this patch loses the result from the config_found(9), so I've added the missing sc->sc_wsmousedev = ... part. -uwe
Re: /bin/sh tabcomplete
On Tue, Sep 14, 2021 at 17:24:11 +0700, Robert Elz wrote: > Date:Tue, 14 Sep 2021 09:19:36 +0100 > From:Patrick Welche > Message-ID: > > | It seems that after updating a box from August -current to yesterday's > | -current, /bin/sh's tabcomplete no longer escapes spaces? > > If something changed there, it must be related to the way that libedit now > works, Christos? I haven't actually verified it, but I wonder if http://gnats.netbsd.org/54510 might be related. -uwe
Re: VirtualBox guest additions build failure
On Wed, Apr 28, 2021 at 19:38:39 +0100, Chavdar Ivanov wrote: > Anyway, thanks; now works as before (the daemon still exits but the > reason is different, as before - [...] > 10:19:44.966110 main Error: Failed to connect to the guest > property service! Error: VERR_NOT_SUPPORTED > 10:19:44.966128 main Error: Service 'timesync' failed pre-init: > VERR_NOT_SUPPORTED This is the usual problem of not having a fixed major. Some new devices were added, so the old /dev/vboxguest device points to the wrong driver. -uwe
Re: VirtualBox guest additions build failure
On Tue, Apr 27, 2021 at 21:45:10 +0100, Chavdar Ivanov wrote: > I switched early today my VirtualBox NetBSD-current guest; as usual, I > rebuilt the additions (it works without them, but it is better to have > them - e.g. without them the X cursor is almost invisible). There are > a couple of patches I always have to apply under -current, which I > did; it failed further with an error due to implicit function > declaration > > ... > src/VBox/Additions/common/VBoxGuest/VBoxGuest-netbsd.c:419:25: error: > implicit declaration of function ?config_found_ia?; did you mean > ?config_found?? [-Werror=implicit-function-declaration] This is probably the recent config changes committed by thorpej@. I'd appreciate a quick TL;DR and the condition to check to choose the new API and I will make the change in the VBox tree. -uwe
Re: pkgsrc build hang of python38
On Sat, Feb 27, 2021 at 21:50:35 +0100, Riccardo Mottola wrote: > python38 hangs during build. I tried several times, it hangs in > exactly the same place again. I don't know of course where the issue > comes from, since all is new now :) I vaguely remember running into something like this b/c the system was out of randomness. I don't remember if there should be something obvious in dmesg when that happens, I think it should. As a workaround: https://mail-index.netbsd.org/current-users/2020/05/01/msg038495.html | you can fool it into thinking there is more entropy by running | | dd if=/dev/urandom of=/dev/random bs=32 count=1 | sysctl -w kern.entropy.consolidate=1 | | as root. The kernel will assume that any data written by root to | /dev/u?random have full entropy -uwe
Re: Help with libcurses and lynx under NetBSD-9 and -current?
On Wed, Jan 27, 2021 at 08:49:26 -0800, Brian Buhrow wrote: > 1. How do I get pkgsrc/www/lynx to compile using -ncurses instead > of the native curses library? I tried setting various options in > /etc/mk.conf, but it looks like it really wants to compile using the > native curses library. I tried changing options.mk in the pkgsrc > directory, but I apparently don't fully understand the maze of > pkgsrc Makefiles. I'm not a pkgsrc expert, but I think make PREFER.curses=pkgsrc should nudge it to select ncursesw package. -uwe
Re: [HEADS UP] pkgsrc default database directory changed
On Wed, Dec 02, 2020 at 11:28:41 +0100, Thomas Klausner wrote:
> The new default for the pkgsrc database (which contains information
> about all installed packages) in pkgsrc-HEAD has changed from
> /var/db/pkg to ${PREFIX}/pkgdb (so usually /usr/pkg/pkgdb).
This seems to be broken with current (with the new pkg_install)
vs. building from source from pkgsrc-quarterly
The new tools use the new location by default, but the quarterly
branch uses PKG_DBDIR?=/var/db/pkg, so when you build packages the
build process looks (and writes) to the wrong place. So you need
PKG_DBDIR=/usr/pkg/pkgdb in mk.conf
-uwe
Re: diskless sparc locks up under memory pressure
On Sat, Nov 07, 2020 at 18:33:26 +0300, Valery Ushakov wrote: > I've upgraded my Krups (64MB RAM, diskless) to 9.99.75 as of Nov 6 and > the machine is locking up at boot time in rc.d/fccache. If I disable > fccache in rc.conf it boots but then eventually locks up when > makemandb is run. The machine doesn't respond to pings, etc, but can > enter ddb. In all cases the ddb stacktrace goes through: > > ... > uvm_fault_internal > mem_access_fault4m > memfault_sun4m > copyout > > with the top part of the stack trace varying. This turned out to be unsafe inline asm in pmap code miscompiled by the newer gcc. Many thanks to chs@ for his help. -uwe
Re: [HEADS UP] pkgsrc default database directory changed
On Wed, Dec 02, 2020 at 11:28:41 +0100, Thomas Klausner wrote:
> There is one potential pitfall: you'll have to make sure
> ${PREFIX}/sbin/pkg_* is used and not mixed with /usr/sbin/pkg_* (which
> will default to the old location until -current and the branches are
> updated).
>
> So please make sure your admin user's PATH has ${PREFIX}/sbin before
> /usr/sbin, or copy the new pkg_install tools from ${PREFIX}/sbin to
> /usr/sbin.
NetBSD daily cron job uses full paths. They can be changed by adding
pkg_admin=/usr/pkg/sbin/pkg_admin
pkg_info=/usr/pkg/sbin/pkg_info
to /etc/pkgpath.conf
-uwe
diskless sparc locks up under memory pressure
I've upgraded my Krups (64MB RAM, diskless) to 9.99.75 as of Nov 6 and the machine is locking up at boot time in rc.d/fccache. If I disable fccache in rc.conf it boots but then eventually locks up when makemandb is run. The machine doesn't respond to pings, etc, but can enter ddb. In all cases the ddb stacktrace goes through: ... uvm_fault_internal mem_access_fault4m memfault_sun4m copyout with the top part of the stack trace varying. -uwe
Re: atexit(), dlclose() and more atexit()
On Tue, Jun 30, 2020 at 15:09:14 +0200, Kamil Rytarowski wrote: > On 30.06.2020 14:24, Valery Ushakov wrote: > > On Tue, Jun 30, 2020 at 13:43:00 +0200, Kamil Rytarowski wrote: > > > >> On 30.06.2020 05:16, Jason Thorpe wrote: > >>> > >>>> On Jun 29, 2020, at 5:13 PM, Kamil Rytarowski wrote: > >>>> > >>>>> > >>>>> The atexit() function shall register the function pointed to by func, > >>>>> to be called without arguments at normal program termination. At normal > >>>>> program termination, all functions registered by the atexit() function > >>>>> shall be called, in the reverse order of their registration, except > >>>>> that a function is called after any previously registered functions > >>>>> that had already been called at the time it was registered. Normal > >>>>> termination occurs either by a call to exit() or a return from main(). > >>>>> > >>>>> > >>>>> My reading of the standard here is that atexit() handlers are called at > >>>>> "normal program termination", and that "normal program termination" is > >>>>> explicitly defined as either a call to exit() or returning from main(), > >>>>> and thus any other call to atexit() handlers is expressly forbidden by > >>>>> the standard. > >>>>> > >>>> > >>>> There is no word "only", so it's unspecified. > >>> > >>> Sorry, but that seems like a huge stretch. Everything seems tied to the > >>> process "exit" path in the description of atexit(). Even in the > >>> APPLICATION USAGE section, they have the following informative text: > >>> > >>> > >>> All functions registered by the atexit() function are called at normal > >>> process termination, which occurs by a call to the exit() function or a > >>> return from main() or on the last thread termination, when the behavior > >>> is as if the implementation called exit() with a zero argument at thread > >>> termination time. > >>> > >>> > >>> ...specifically, the "is as if" qualifier. In my reading, if the > >>> enclosing program is not terminating, then atexit() handlers should not > >>> be called. > >>> > >>> dlclose() does not initiate "normal program termination" (it's also > >>> specified in Issue 7, so I double-checked!), nor does it mention anything > >>> about being considered "normal program termination" from the perspective > >>> of the shared object that is being closed. > >>> > >>> Can you point to another place in the standard that uses the "only" type > >>> wording to justify your reading of atexit()? > >>> > >> > >> This is an extension and extensions are allowed. > >> > >> There is also no better alternative as __cxa_atexit() besides of being > >> C++ ABI specific, it is documented as internal only: > >> > >> "No user interface to __cxa_atexit is supported, so the user is not able > >> to register an atexit function with a parameter or a home DSO." > >> > >> https://itanium-cxx-abi.github.io/cxx-abi/abi.html > >> > >> This is only me, but DSO can be treated as a subprogram loaded after > >> dlopen() and terminated upon dlclose(). atexit(3) in this metaphor > >> naturally associates to dlclose(). > > > > That's an enticing line of reasoning, and yes one can see how it > > caused the current atexit abuse (heck, I would have done it myself, > > people are lazy :), but as all analogies it can only be taken so far. > > A program termination means the program will be gone very soon, it's > > memory freed, file descriptors closed, etc. In contrast, the program > > continues to work after dlclose, so resource leaks are a real concern. > > So cleanup code that runs at exit time and at the dlclose time have > > very different operational constraints. atexit-for-dlclose really > > pushes you further back into MSDOS-like environment where programs are > > not insulated from each other. > > Dynamic loading and unloading code predates MSDOS. It also predates > shared libraries in UNIX (e.g. Lisp C bindings, predating MSDOS). What are you even talking about?! You go out of your way to misinterpret ~anything said to you and/or to put/steer it into the context that was obviously not intended. If talking to you requires math like precision in specifying every tiny detail then expect people to dissmiss you and your arguments regardless of whatever technical merits they might have. > atexit-for-dlclose is already done in C++ behind the scenes for Objects > and nobody calls it MSDOS-like environment (even if it is, it's not a > bad design). Two can play that game... What does that sentence mean? Which c++ implementation are you talking about? What specific aspect of that implementation do you refer to as atexit-for-dlclose? Please provide specific examples. -uwe
Re: atexit(), dlclose() and more atexit()
On Tue, Jun 30, 2020 at 13:43:00 +0200, Kamil Rytarowski wrote: > On 30.06.2020 05:16, Jason Thorpe wrote: > > > >> On Jun 29, 2020, at 5:13 PM, Kamil Rytarowski wrote: > >> > >>> > >>> The atexit() function shall register the function pointed to by func, to > >>> be called without arguments at normal program termination. At normal > >>> program termination, all functions registered by the atexit() function > >>> shall be called, in the reverse order of their registration, except that > >>> a function is called after any previously registered functions that had > >>> already been called at the time it was registered. Normal termination > >>> occurs either by a call to exit() or a return from main(). > >>> > >>> > >>> My reading of the standard here is that atexit() handlers are called at > >>> "normal program termination", and that "normal program termination" is > >>> explicitly defined as either a call to exit() or returning from main(), > >>> and thus any other call to atexit() handlers is expressly forbidden by > >>> the standard. > >>> > >> > >> There is no word "only", so it's unspecified. > > > > Sorry, but that seems like a huge stretch. Everything seems tied to the > > process "exit" path in the description of atexit(). Even in the > > APPLICATION USAGE section, they have the following informative text: > > > > > > All functions registered by the atexit() function are called at normal > > process termination, which occurs by a call to the exit() function or a > > return from main() or on the last thread termination, when the behavior is > > as if the implementation called exit() with a zero argument at thread > > termination time. > > > > > > ...specifically, the "is as if" qualifier. In my reading, if the enclosing > > program is not terminating, then atexit() handlers should not be called. > > > > dlclose() does not initiate "normal program termination" (it's also > > specified in Issue 7, so I double-checked!), nor does it mention anything > > about being considered "normal program termination" from the perspective of > > the shared object that is being closed. > > > > Can you point to another place in the standard that uses the "only" type > > wording to justify your reading of atexit()? > > > > This is an extension and extensions are allowed. > > There is also no better alternative as __cxa_atexit() besides of being > C++ ABI specific, it is documented as internal only: > > "No user interface to __cxa_atexit is supported, so the user is not able > to register an atexit function with a parameter or a home DSO." > > https://itanium-cxx-abi.github.io/cxx-abi/abi.html > > This is only me, but DSO can be treated as a subprogram loaded after > dlopen() and terminated upon dlclose(). atexit(3) in this metaphor > naturally associates to dlclose(). That's an enticing line of reasoning, and yes one can see how it caused the current atexit abuse (heck, I would have done it myself, people are lazy :), but as all analogies it can only be taken so far. A program termination means the program will be gone very soon, it's memory freed, file descriptors closed, etc. In contrast, the program continues to work after dlclose, so resource leaks are a real concern. So cleanup code that runs at exit time and at the dlclose time have very different operational constraints. atexit-for-dlclose really pushes you further back into MSDOS-like environment where programs are not insulated from each other. -uwe
Re: NetBSD 9.0 RC1 amd64 not working on VirtualBox 6.1.0
On Thu, Dec 12, 2019 at 06:47:50 +0100, Bodie wrote: > On 11.12.2019 23:32, Valery Ushakov wrote: > > On Wed, Dec 11, 2019 at 23:15:38 +0100, Bodie wrote: > > > > > FYI https://www.virtualbox.org/ticket/19146 > > > > > > Not possible to boot installer of NetBSD 9.0RC1. cc me as I am not > > > subscribed to list. > > > > CPUID values are ... = guest (host): > > > > IBRS_IBPB - IA32_SPEC_CTRL.IBRS and IA32_PRED_CMD.IBPB = 0 (1) > > STIBP - Supports IA32_SPEC_CTRL.STIBP = 0 (1) > > SSBD - Supports IA32_SPEC_CTRL.SSBD = 0 (1) > > > > so the NetBSD guest is told the cpu doesn't support IA32_SPEC_CTRL > > (0x48), > > but still the guest tries to read it: > > NetBSD 8.1 STABLE amd64 on same configuration with same values boots > just fine and works. Right, b/c NetBSD 8 doesn't read that nonexistent MSR. > > 00:00:11.518912 IEM: rdmsr(0x48) -> #GP(0) > > 00:00:11.518920 Changing the VM state from 'RUNNING' to > > 'GURU_MEDITATION' 00:00:11.520158 CPUM0: 0008:8022714b 0f 32 rdmsr This is mitigation_v2_apply_cpu(), V2_MITIGATION_INTEL_ENHANCED_IBRS case it seems, so either the kernel misdetects the mitigation variant to use, or vbox doesnt' scrub host capabilities enough. Someone with the clue should look at the VBox.log (it has the cpuinfo dump). -uwe
Re: NetBSD 9.0 RC1 amd64 not working on VirtualBox 6.1.0
On Wed, Dec 11, 2019 at 23:15:38 +0100, Bodie wrote: > FYI https://www.virtualbox.org/ticket/19146 > > Not possible to boot installer of NetBSD 9.0RC1. cc me as I am not > subscribed to list. CPUID values are ... = guest (host): IBRS_IBPB - IA32_SPEC_CTRL.IBRS and IA32_PRED_CMD.IBPB = 0 (1) STIBP - Supports IA32_SPEC_CTRL.STIBP = 0 (1) SSBD - Supports IA32_SPEC_CTRL.SSBD = 0 (1) so the NetBSD guest is told the cpu doesn't support IA32_SPEC_CTRL (0x48), but still the guest tries to read it: 00:00:11.518912 IEM: rdmsr(0x48) -> #GP(0) 00:00:11.518920 Changing the VM state from 'RUNNING' to 'GURU_MEDITATION' -uwe
Re: File sharing over virtio-9p
On Mon, Oct 28, 2019 at 12:29:40 +0900, Ryota Ozaki wrote: > On Fri, Oct 25, 2019 at 11:19 PM Mouse wrote: > > > > > [W]hich of the following is more readable to the user: > > > > > $ ls foo > > > ls: foo: No such file or directory > > > > > or > > > > > $ ls foo > > > ls: stat(foo): No such file or directory > > > > It depends entirely on the user. > > > > As I recently wrote on a non-NetBSD mailing list, there is no such > > thing as a good or bad user interface; there is only a good or bad user > > interfaces for a particular user (or class of sufficiently-similar > > users). > > > > I've lost track of the number of times I've had to resort to a > > sledgehammer such as ktrace to find out what's really going wrong > > because an error message doesn't report enough information. > > I've had similar experiences on KASSERT; if a KASSERT fails because of > memory corruption, I wish to know not only if it fails or not but also > values used in KASSERT. KASSERT is, very specifically, information for developers (asserting something about the internal state of the code), not for users. -uwe
Re: File sharing over virtio-9p
On Fri, Oct 25, 2019 at 12:56:43 +0900, Ryota Ozaki wrote: > > @@ -72,7 +74,7 @@ serverconnect(const char *addr, unsigned short port) > > [...] > > + err(1, "setsockopt(SO_NOSIGPIPE)"); > > > > I'd just trim it down to "SO_NOSIGPIPE". > > > > +err(1, "open(%s)", path); > > > > Ditto. Just make it "%s". > > I prefer more informative messages. Why do you want to trim them? Consider that from the user perspective. As a developer it's tempting to dump the implementation details, but which of the following is more readable to the user: $ ls foo ls: foo: No such file or directory or $ ls foo ls: stat(foo): No such file or directory -uwe
Re: Tar extract behaviour changed
On Thu, Oct 24, 2019 at 05:26:41 +0200, Martin Husemann wrote:
> Deal with this properly in sysinst would mean:
>
> 1) run a script like:
> rm -f /tmp/list
> for s in *.${suffix}
> do
>for dir in $( tar tvf "$s" | egrep '^d' | awk '{ print $9}' )
>do
> readlink "$dir" && echo "$dir" >> /tmp/list
>done
> done
Isn't that info already available from mtree files? IIRC, set.base
has all of the directories, including those that are populated by
other sets. So you should be able to extract that and run mtree to
check it.
-uwe
Re: File sharing over virtio-9p
On Thu, Oct 24, 2019 at 13:32:59 +0900, Ryota Ozaki wrote: > I've prepared complete patches ready to commit: > https://www.netbsd.org/~ozaki-r/tweak-MAKEDEV.diff > https://www.netbsd.org/~ozaki-r/vio9p.diff > https://www.netbsd.org/~ozaki-r/vio9p-configs.diff > https://www.netbsd.org/~ozaki-r/mount_9p-cdev.diff Just a few minor nit-picks: @@ -60,6 +60,8 @@ usage(void) [...] + fprintf(stderr, " %s [-s] [-o mntopts] -cu cdevfile mountpoint\n", Why not [-su] as in the usage just above for the TCP case? @@ -72,7 +74,7 @@ serverconnect(const char *addr, unsigned short port) [...] + err(1, "setsockopt(SO_NOSIGPIPE)"); I'd just trim it down to "SO_NOSIGPIPE". +err(1, "open(%s)", path); Ditto. Just make it "%s". Thanks! -uwe
Re: How to best build a smalle libcurses for tiny crunched installers?
On Thu, Jul 25, 2019 at 23:27:51 +0300, Valery Ushakov wrote: > On Thu, Jul 25, 2019 at 21:38:16 +0200, Martin Husemann wrote: > > > I wonder if we could build a hack version of libcurses with > > DISABLE_WCHAR, or is it better to just include the relevant files > > from libcurses in libhack instead? > > I did some work to excise the enhanced curses stuff from the > !HAVE_WCHAR build last November but got distracted. > > I have just fixed the DISABLE_WCHAR build (I did all the preparatory > work on attributes.c and then never got around to add the ifdefs, > sorry). I have also added HAVE_WCHAR ifdefs to slk.c, which I forgot about. >From a quick visual inspection the DISABLE_WCHAR curses no longer refers to anything untoward. HAVE_WCHAR curses additionally refers to: + U __setlocale50 + U btowc + U fgetwc + U fputwc + U iswprint + U mbrtowc + U nl_langinfo + U strcasecmp + U wcslen + U wcsrtombs + U wcwidth + U wmemchr + U wmemcpy so i guess not pulling in that stuff from libc should help to reduce the size of the program binary. -uwe
Re: How to best build a smalle libcurses for tiny crunched installers?
On Thu, Jul 25, 2019 at 21:38:16 +0200, Martin Husemann wrote: > I wonder if we could build a hack version of libcurses with > DISABLE_WCHAR, or is it better to just include the relevant files > from libcurses in libhack instead? I did some work to excise the enhanced curses stuff from the !HAVE_WCHAR build last November but got distracted. I have just fixed the DISABLE_WCHAR build (I did all the preparatory work on attributes.c and then never got around to add the ifdefs, sorry). On amd64 I get: textdata bss dec hex filename 15820271128200 173514 2a5ca libcurses.so.8.2 # normal 10986845462080 116494 1c70e libcurses.so.8.2 # DISABLE_WCHAR or, probably more relevant for sysinst, for the .a files: textdata bss dec hex filename 11127541262405 117806 1cc2e (TOTALS) # normal 7623120781379 79688 13748 (TOTALS) # DISABLE_WCHAR So about 36K. Actual savings will be less since sysinst likely doesn't pull in all of it. -uwe
Re: CVS commit: src/usr.sbin/postinstall
On Thu, Jun 13, 2019 at 17:07:36 -, Christos Zoulas wrote: > In article <20190613112930.gr17...@pony.stderr.spb.ru>, > Valery Ushakov wrote: > >On Thu, Jun 13, 2019 at 12:50:02 +0200, Manuel Bouyer wrote: > > > >> On Thu, Jun 13, 2019 at 01:13:52PM +0300, Valery Ushakov wrote: > >> > On Thu, Jun 13, 2019 at 10:00:03 +0200, Manuel Bouyer wrote: > >> > > >> > > On Thu, Jun 13, 2019 at 06:17:29AM +0300, Valery Ushakov wrote: > >> > > > [...] > >> > > > I've been using etcupdate for ages so I only ever really used > >> > > > postinstall to fix "obsolete" and "catpages". etcupdate -a has some > >> > > > kinks and may be we should concentrate on fixing those instead? > >> > > > >> > > I *never* used etcupdate, so for me it's better to have a working > >postinstall > >> > > (I have a PR about it: install/52349, which may have been fixed by the > >> > > recent change) > >> > > >> > The rc.d part is probably addressed by this very change that Christos > >> > made (that i was replying to). > >> > > >> > The other part is exactly what I'm talking about. postinstall does > >> > NOT update your system to the new etc.tgz set, it cherry picks stuff > >> > from the new etc.tgz. > >> > >> It should create files and directory that are expected to be there > >> but are not. > > > >That "should" seems to be the crux of the matter. It seems that > >different people think that postinstall should do different things. > > >Most new files added to etc that were not previously there are not > >needed to boot your system with its old etc (shinynewd may be hip and > >progressive, but if that system ran without it, it will happily > >continue to run without it for the time being). My conception of > >postinstall has always been that it takes care specifically about > >those rare cases where a new file in etc *is* required to keep the > >system operational and you, for whatever reasons, can't/don't want to > >do a full etc update. I may be misremembering, it's been about 15 > >years, please correct me if I do. > > No, this is correct (most shiny new files are not needed). There are > problems though: > 1. Files that get updated sometimes need the new files (npf for example >recently), and break otherwise. Was that file that get updated also in etc, as I understood from your private comments - in which case the new file won't be there since you still have mostly old etc, right? If something in the base set changes that requires a coordinated update to the configuration in etc then yes, that's the prime thing for postinstall to fix, as I understand. Consider e.g. ssh check that moves existing(!) /etc/ssh* files to /etc/ssh/* > 2. There is significant amount of work to keep things synchronized over. >There are multiple places people need to edit when adding/removing stuff >and this is error prone. Right. > 3. Keep upgrading and you end up missing more and more files in >/etc. What's the mechanism *in base* to help you keep them in >sync. etcupdate(8)? I've been using it all this time, since Martti committed it to base. I used it to upgrade very old machines (my mr.coffee hasn't been booted in a decade since 2007 and I upgraded it in 2017 and it was all very smooth). As I said, it has its kinks. Special handling for passwd/group would be very nice and -a (automatic) should really install new files without asking. Other then that I really love it. Adding a bit more user-friendliness to it might be in order simpley because most people that don't track current only use it may be once in a couple of years, so some handholding in this rather delicate task of merging new etc would definitely help to reassure them. > 4. Unpacking sets installs programs, postinstall deletes programs. This is >driven from the sets. OTOH their respective rc files don't get installed >or removed from postinstall; this seems inconsistent to me. For example, >dhclient got removed as a program, the rc file is still there. >The automount stuff got installed as programs the rc files did not. postinstall fix obsolete will delete programs, yes, but it should not be run blindly. Say, oldd is removed from base, as long as you don't run fix obsolete, you should be fine. Except, as I mentioned, fix rc seems to also delete obsolete rc files, in which case fix rc might screw your system by deleting oldd rc script (while the oldd itself and oldd.conf are still in plac
Re: CVS commit: src/usr.sbin/postinstall
On Thu, Jun 13, 2019 at 12:50:02 +0200, Manuel Bouyer wrote: > On Thu, Jun 13, 2019 at 01:13:52PM +0300, Valery Ushakov wrote: > > On Thu, Jun 13, 2019 at 10:00:03 +0200, Manuel Bouyer wrote: > > > > > On Thu, Jun 13, 2019 at 06:17:29AM +0300, Valery Ushakov wrote: > > > > [...] > > > > I've been using etcupdate for ages so I only ever really used > > > > postinstall to fix "obsolete" and "catpages". etcupdate -a has some > > > > kinks and may be we should concentrate on fixing those instead? > > > > > > I *never* used etcupdate, so for me it's better to have a working > > > postinstall > > > (I have a PR about it: install/52349, which may have been fixed by the > > > recent change) > > > > The rc.d part is probably addressed by this very change that Christos > > made (that i was replying to). > > > > The other part is exactly what I'm talking about. postinstall does > > NOT update your system to the new etc.tgz set, it cherry picks stuff > > from the new etc.tgz. > > It should create files and directory that are expected to be there > but are not. That "should" seems to be the crux of the matter. It seems that different people think that postinstall should do different things. Most new files added to etc that were not previously there are not needed to boot your system with its old etc (shinynewd may be hip and progressive, but if that system ran without it, it will happily continue to run without it for the time being). My conception of postinstall has always been that it takes care specifically about those rare cases where a new file in etc *is* required to keep the system operational and you, for whatever reasons, can't/don't want to do a full etc update. I may be misremembering, it's been about 15 years, please correct me if I do. -uwe
Re: CVS commit: src/usr.sbin/postinstall
On Thu, Jun 13, 2019 at 10:24:58 +0100, Roy Marples wrote: > Date: Thu, 13 Jun 2019 10:24:58 +0100 > From: Roy Marples > Subject: Re: CVS commit: src/usr.sbin/postinstall > To: Manuel Bouyer , current-users@NetBSD.org > > On 13/06/2019 09:00, Manuel Bouyer wrote: > > On Thu, Jun 13, 2019 at 06:17:29AM +0300, Valery Ushakov wrote: > > > [...] > > > I've been using etcupdate for ages so I only ever really used > > > postinstall to fix "obsolete" and "catpages". etcupdate -a has some > > > kinks and may be we should concentrate on fixing those instead? > > > > I *never* used etcupdate, so for me it's better to have a working > > postinstall > > (I have a PR about it: install/52349, which may have been fixed by the > > recent change) > > I used etc-update once and accidently overwrote master.passwd > Never used it since, far too risky. Well, updating your etc is risky. Handling of passwd/group (or rather lack of special handling for them) is probably the weakest part of etcupdate UX. -uwe
Re: CVS commit: src/usr.sbin/postinstall
On Thu, Jun 13, 2019 at 10:00:03 +0200, Manuel Bouyer wrote: > On Thu, Jun 13, 2019 at 06:17:29AM +0300, Valery Ushakov wrote: > > [...] > > I've been using etcupdate for ages so I only ever really used > > postinstall to fix "obsolete" and "catpages". etcupdate -a has some > > kinks and may be we should concentrate on fixing those instead? > > I *never* used etcupdate, so for me it's better to have a working postinstall > (I have a PR about it: install/52349, which may have been fixed by the > recent change) The rc.d part is probably addressed by this very change that Christos made (that i was replying to). The other part is exactly what I'm talking about. postinstall does NOT update your system to the new etc.tgz set, it cherry picks stuff from the new etc.tgz. -uwe
Re: CVS commit: src/usr.sbin/postinstall
On Wed, Jun 12, 2019 at 13:45:24 -0400, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Wed Jun 12 17:45:24 UTC 2019 > > Modified Files: > src/usr.sbin/postinstall: postinstall > > Log Message: > Remove hard-coded lists of rc files and generate them dynamically > from the sets. Fixes issues with automount, npf_boot etc. that were > never updated here! Isn't it the job of etcupdate to install the new files? Also, from a quick look postinstall fix rc will happily overwrite any local modifications you made to rc.d scripts - yes, changing them is not the best practice, but life happens. Also isn't it kinda strange to install /etc/rc.d/shinynewd and not install /etc/shinynewd.conf? Deleting obsolete rc.d files in "rc" (not "obsolete") also looks kinda scary to me. Say, we obsolete oldd. Alice installs new base.tgz, the old /sbin/oldd is still there (she's careful not to run "fix obsolete") and she has it still enabled for now. Then "fix rc" will delete its rc.d script, won't it? Note that if you do etcupdate you will get new /var/db/obsolete/etc, so later when you are ready you can do "fix obsolete" and get the rc script deleted along with the obsoleted binary. I guess what I'm trying to say is, does it really make sense to try to make postinstall provide some of the etcupdate functionality but in an ad-hoc and not quite safe manner? We are effectively trying to support the scenario where you do NOT do a full update to the new etc.tgz and still expect things to run. This might be not an unreasonable scenario to support, but then we probably shouldn't install inconsistent subset of the new etc.tgz in a a potentially unsafe manner. I've been using etcupdate for ages so I only ever really used postinstall to fix "obsolete" and "catpages". etcupdate -a has some kinks and may be we should concentrate on fixing those instead? -uwe
Re: Enabling xdm in sysinst breaks console login?
On Sun, Jun 09, 2019 at 23:45:34 +1000, matthew green wrote: > sounds like constty should work for all cases, is there a > any issue i'm missing? To provide a bit more context. From the etc.i386/ttys log: revision 1.19 date: 2008-10-07 14:00:01 +0400; author: abs; state: Exp; lines: +2 -1; branches: 1.19.18; 1.19.20; Add a constty entry, marked 'off', with otherwise the same settings as the console. Now when coming up in single user mode the tset in /.profile can set the terminal type correctly. Note: I believe constty should be 'on' and console 'off', but thats a separate discussion [...] revision 1.17 date: 2003-10-04 11:41:12 +0400; author: dsl; state: Exp; lines: +2 -2; Revert 'console' back to /dev/console (from /dev/constty) revision 1.16 date: 2003-10-03 18:54:21 +0400; author: dsl; state: Exp; lines: +2 -2; Change 'console' login to use /dev/constty so that its output isn't stolen by code that requests system messages using TIOCCONS. The original thread (it would be nice if people re-read it before starting the new bikeshed :) http://mail-index.netbsd.org/tech-kern/2003/10/03/0008.html was quite a bit antagonistic (hence the revert). From a quick refresher the positions seemed to be 1) "movable" console as in what the system currently booted with (what mrg described in the part of his message not quoted above) vs. 2) "fixed" console tty (using real hw entry, like tty00 or ttyE0 or whatever). As I was using sparcs at that time and booting them once headless and once headful is pretty easy (the OFW just DTRT) I liked the change. I didn't care for the bikeshed about the default. :) I haven't thought this through, but my uninfomred opinion is that constty would seem be a more robust default in the "sh*t happens" scenario where you need to boot with unusual console setup (headless instead of headful or vice versa). It takes care of the TIOCCONS. People that want console wired down to specific hw device has to edit the ttys either way. PS: console(4) would probably be a good idea. -uwe
Re: Enabling xdm in sysinst breaks console login?
On Sat, Jun 08, 2019 at 19:36:52 -0500, John D. Baker wrote: > On Sat, 8 Jun 2019, David Brownlee wrote: > > > That looks to be it - now I recall I set console off and constty on to > > DTRT with or without wscons. > > I've been wondering what the "constty" device was all about. The thread is here: http://mail-index.netbsd.org/tech-kern/2003/10/03/0008.html TL;DR | Subject: On /dev/console, /dev/constty and the TIOCCONS ioctl | To: None | From: David Laight | List: tech-kern | Date: 10/03/2003 21:05:06 | | I've committed changes today that add a /dev/constty device, and changed | /etc/ttys so that getty (and hence any console login session) use it | instead of /etc/console. init also uses it for single user mode. [...] | The only difference between /dev/console and /dev/constty is that output | to the latter is not intercepted by the TIOCCONS ioctl. | | I made the change because I want to capture kernel messages generated | while sysinst is running in order to stop them 'messing up' the screen. | | It also makes it possible to log in on the 'console' while xconsole | (or similar) is running - a problem someone else mentioned yesterday. [...] -uwe
Build fails on Linux in CTF
Building amd64 on a linux host. Build fails in tools/libctf with tools/libctf/../../external/cddl/osnet/sys/sys/uio.h:77:15: error: field 'uio_segflg' has incomplete type enum uio_seg uio_segflg; ^ tools/libctf/../../external/cddl/osnet/sys/sys/uio.h:78:14: error: field 'uio_rw' has incomplete type enum uio_rw uio_rw; ^ etc... -uwe
Re: sysinst garbled screen on i386 - curses issue?
On Fri, Jun 07, 2019 at 22:15:41 +0100, David Brownlee wrote: > There seems to be something off with the cursor positioning [...] > Does anyone else see this or am I going quietly mad? :) lib/54263? -uwe
Re: jemalloc fallout for i386 on amd64?
On Sun, May 12, 2019 at 08:12:35 +0200, Martin Husemann wrote: > On Sun, May 12, 2019 at 04:43:45AM +0300, Valery Ushakov wrote: > > I have an old i386 kmk binary built on 6.1 > > > Core was generated by `kmk'. > > Program terminated with signal SIGSEGV, Segmentation fault. > > #0 0xf618abc9 in je_tcache_bin_flush_large () from /usr/lib/i386/libc.so.12 > > (gdb) bt > > #0 0xf618abc9 in je_tcache_bin_flush_large () from /usr/lib/i386/libc.so.12 > > #1 0xf618b6f0 in je_tcache_event_hard () from /usr/lib/i386/libc.so.12 > > #2 0xf61f5712 in ?? () from /usr/lib/i386/libc.so.12 > > #3 0xf61f72d7 in je_arena_ralloc () from /usr/lib/i386/libc.so.12 > > #4 0xf6201f9f in realloc () from /usr/lib/i386/libc.so.12 > > #5 0x08073908 in xrealloc (ptr=0xf5910e00, size=) > > at kbuild/kbuild-trunk/src/kmk/misc.c:569 > > My bet would be: 0xf5910e00 is not a proper pointer returned from malloc > (or friends) before (that is: bug in kmk). That's, of course, possible, but I'd guess is unlikely. kmk is basically a gmake derivative and this realloc is from the part that reads a makefile (so probably unchanged original gmake code). I've tried running a bit more recent kmk under linux under valgrind and I've only got a couple of complaints about "Conditional jump or move depends on uninitialised value" for __wmemchr_avx2 in glibc. -uwe
jemalloc fallout for i386 on amd64?
I have an old i386 kmk binary built on 6.1 $ file kBuild/bin/netbsd.amd64/kmk kBuild/bin/netbsd.amd64/kmk: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /usr/libexec/ld.elf_so, for NetBSD 6.1.5, with debug_info, not stripped As you might have guessed from the pathname I'm using it on amd64, b/c I've been too lazy to build a native amd64 version. I've just upgraded an amd64 machine to a very current current and when I try to run that binary it segfaults with: $ gdb -q kBuild/bin/netbsd.amd64/kmk kmk.core Reading symbols from kBuild/bin/netbsd.amd64/kmk...done. [New process 1] warning: `/usr/libexec/ld.elf_so': Shared library architecture i386:x86-64 is not compatible with target architecture i386. warning: .dynamic section for "/usr/libexec/ld.elf_so" is not at the expected address (wrong library or version mismatch?) Core was generated by `kmk'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0xf618abc9 in je_tcache_bin_flush_large () from /usr/lib/i386/libc.so.12 (gdb) bt #0 0xf618abc9 in je_tcache_bin_flush_large () from /usr/lib/i386/libc.so.12 #1 0xf618b6f0 in je_tcache_event_hard () from /usr/lib/i386/libc.so.12 #2 0xf61f5712 in ?? () from /usr/lib/i386/libc.so.12 #3 0xf61f72d7 in je_arena_ralloc () from /usr/lib/i386/libc.so.12 #4 0xf6201f9f in realloc () from /usr/lib/i386/libc.so.12 #5 0x08073908 in xrealloc (ptr=0xf5910e00, size=) at kbuild/kbuild-trunk/src/kmk/misc.c:569 #6 0x08050e9d in readline (ebuf=0xfff4d42c) at kbuild/kbuild-trunk/src/kmk/read.c:3182 #7 0x08052cea in eval (ebuf=0xfff4d42c, set_default=1) at kbuild/kbuild-trunk/src/kmk/read.c:776 [...] (gdb) x/i $eip => 0xf618abc9 : paddq -0x138(%ebp),%xmm0 (gdb) p/x $ebp $1 = 0xfff4cf3c (gdb) p/x $xmm0 $2 = -uwe
Re: Automated report: NetBSD-current/i386 test failure
On Mon, Apr 29, 2019 at 10:29:43 +0700, Robert Elz wrote: > I've done some searching (not exhaustive for sure) and the only > thing I can find that uses 'F' in our tree that I can find is > (which provided the newly added example in snprintb.3) > which is missing that final NUL after the F field - and which I > suspect is the motivation for the "off by one" fix. I rememeber writing some. E.g. in sys/arch/sh3/include/adcreg.h #define SH7709_ADCR_BITS \ "\177\020" "F\06\02\0" ":\03TRGE\0" "b\05SCAN\0" PS: The way the one in sys/mman.h is formatted is a crime against humanity :) -uwe
Re: cross-compiling fails on MacOS
On Mon, Feb 25, 2019 at 15:55:33 +0100, K. Schreiner wrote: > tryed to cross-compile NetBSD (amd64) on MacOS and failed with > > > create compat/.depend > compile compat/atoll.lo > clang: error: unknown argument: '-fno-ipa-sra' > > *** Failed target: atoll.lo > *** Failed command: cc -O -fno-omit-frame-pointer -fno-optimize-sibling-calls > -fno-ipa-sra -no-cpp-precomp -I. -I./include -I/u/NetBSD/src/tools/compat > -I/u/NetBSD/src/tools/compat/sys -DHAVE_NBTOOL_CONFIG_H=1 > -D_FILE_OFFSET_BITS=64 -D__DBINTERFACE_PRIVATE -c -o atoll.lo.o > /u/NetBSD/src/tools/compat/../../lib/libc/stdlib/atoll.c > *** Error code 1 [...] > Any idea what to change where to get things going? share/mk/bsd.host.mk has # disable compiler options that interfere with dtrace HOST_DTRACE_OPTS?= -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-ipa-sra which should probably be conditionalized depending on what the host compiler is, but it doesn't look like we have the infrastructure in place. For now you can just override it in your local build. -uwe
Re: "libmpfr.so.4" not found
On Wed, Oct 03, 2018 at 18:57:42 +0700, Robert Elz wrote: > dependall ===> tools/xz-include > /bin/sh > /readonly/release/testing/src/tools/xz-include/../../external/public-domain/xz/dist/configure > --enable-threads=no --disable-nls CC=cc > /readonly/release/testing/src/tools/xz-include/../../external/public-domain/xz/dist/configure: > cannot create configure.lineno: read-only file system > configure: error: cannot create configure.lineno; rerun with a POSIX shell Are you sure you did't have an objdir accident before? In my experience an error like this is most likely a result of one. Like, a stray /readonly/release/testing/src/tools/xz-include/obj accidentally created in the read-write view of that tree by running make in the wrong dir, etc? -uwe
Re: VirtualBox mouse problem
On Mon, Jun 11, 2018 at 21:53:13 +0300, Arto Huusko wrote: > Valery Ushakov kirjoitti 10.6.2018 klo 20:19: > > > NetBSD vboxguest driver now provides wsmouse(4) interface so X11 can > > use stock "ws" driver. > > Thanks, using "ws" driver fixed the issue. But note that I was trying to > use stock "mouse" driver, not vboxmouse driver. Sorry, I have zero clue about X11 drivers :) With the new additions you get wsmouse1 at vboxguest0 mux 0 and wsmouse1 will only ever feed absolute position events into the wsmouse mux (src/VBox/Additions/common/VBoxGuest/VBoxGuest-netbsd.c) > However, mouse buttons 6 and 7 still do not work correctly: xev shows > the same events for buttons 4 and 6 and for 5 and 7. See above. This should not be a problem with additions. Button press events come from wsmouse0 that talks to the emulated mouse, not to the vboxguest driver. That seems like a vbox bug, I see the same problem in a linux guest (horizontal scrolling reported as 4/5 instead of 6/7, as the host does). > Another problem is that pkgsrc modular xorg xf86-input-ws does not > attach mouse at all: it tries to attach the mouse as a touchscreen and > fails due to some unsupported ioctl. Sorry, I dont't have time to build and test modular xorg. It would be nice if someone could investigate this. -uwe
Re: VirtualBox mouse problem
Moi, Arto. On Sun, Jun 10, 2018 at 16:06:38 +0300, Arto Huusko wrote: > I recently updated my virtualbox netbsd installation to 8.99.18, but > this caused the mouse to stop working correctly. > xorg.conf for mouse has simply: > > Section "ServerLayout" > InputDevice"Mouse0" "CorePointer" > > > Section "InputDevice" > Identifier "Mouse0" > Driver "mouse" > Option "Device" "/dev/wsmouse" > Option "ZAxisMapping" "4 5" > EndSection NetBSD vboxguest driver now provides wsmouse(4) interface so X11 can use stock "ws" driver. Relevant xorg.conf fragment: Section "InputDevice" Identifier "Mouse0" Driver "ws" Option "Device" "/dev/wsmouse" Option "ZAxisMapping" "4 5 6 7" EndSection -uwe
Re: More build.sh ctf fallout on a linux host
On Sun, Jun 03, 2018 at 18:16:47 -0700, Chuck Silvers wrote: > > /home/uwe/work/netbsd/ro/src/tools/libctf/../../external/cddl/osnet/dist/uts/common/rpc/types.h:57:9: > > error: unknown type name 'u_longlong_t' > > typedef u_longlong_t ulonglong_t; > > ^ > > I was afraid that might happen... > which distribution and version of linux was that on? > the one I did my fix for linux on was fedora 26. Sorry, I should have been specific. It's on Ubuntu 16.04 LTS. -uwe
More build.sh ctf fallout on a linux host
# compile libctf/ctf_error.lo cc -pipe -O2 -DCTF_OLD_VERSIONS -I/home/uwe/work/netbsd/ro/src/tools/libctf/../compat -I/home/uwe/work/netbsd/ro/src/tools/libctf/../../external/cddl/osnet/sys -I/home/uwe/work/netbsd/ro/src/tools/libctf/../../external/cddl/osnet/include -I/home/uwe/work/netbsd/ro/src/tools/libctf/../../external/cddl/osnet/dist/head -I/home/uwe/work/netbsd/ro/src/tools/libctf/../../external/cddl/osnet/dist/common/ctf -I/home/uwe/work/netbsd/ro/src/tools/libctf/../../external/cddl/osnet/dist/lib/libctf/common -I/home/uwe/work/netbsd/ro/src/tools/libctf/../../external/cddl/osnet/dist/uts/common -I/home/uwe/work/netbsd/ro/src/tools/libctf/../../external/bsd/elftoolchain/dist/libelf -DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -I/home/uwe/work/netbsd/build/tools/include/compat -I/home/uwe/work/netbsd/ro/src/tools/compat -DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -I/home/uwe/work/netbsd/build/tools/include -I/home/uwe/work/netbsd/build/tools/include/nbinclude -c -o ctf_error.lo.o /home/uwe/work/netbsd/ro/src/tools/libctf/../../external/cddl/osnet/dist/common/ctf/ctf_error.c In file included from /home/uwe/work/netbsd/ro/src/tools/libctf/../compat/compat_defs.h:75:0, from /home/uwe/work/netbsd/build/tools/include/compat/nbtool_config.h:882, from /home/uwe/work/netbsd/ro/src/tools/libctf/../../external/cddl/osnet/dist/common/ctf/ctf_error.c:23: /home/uwe/work/netbsd/ro/src/tools/libctf/../../external/cddl/osnet/dist/uts/common/rpc/types.h:57:9: error: unknown type name 'u_longlong_t' typedef u_longlong_t ulonglong_t; ^ -uwe
Re: Missing file after postisnstall?
On Tue, Feb 13, 2018 at 06:22:41 +0800, Paul Goyette wrote: > On Tue, 13 Feb 2018, Paul Goyette wrote: > > > On Tue, 13 Feb 2018, Valery Ushakov wrote: > > > > > On Tue, Feb 13, 2018 at 05:40:22 +0800, Paul Goyette wrote: > > > > > > > I recently updated from 8.99.7 to 8.99.12 and noticed that my > > > > daily security > > > > job reported a missing file: > > > > > > > > Checking special files and directories. > > > > ./etc/rc.d/dhcpd6 missing > > > > > > > > Shouldn't this have been found and fixed by postinstall? > > > > > > Why it should be "fixed" if it ain't broken? :) Your system still > > > happily boots without DHCP6 server, isn't it? If you want to update > > > your configuration files to the new etc.tgz you run etcupdate. > > > > > > postinstall only does minimal configuration tweaks that are necessary > > > to keep the system working with the new userland, or at least that was > > > its original design goal as I remember it. > > > > I also ran `etcupdate -al -s etc.gz -s xetc.gz` and it does not find the > > missing rc.d file, either. > > The missing file is listed in an mtree specification file that was installed > as part of the upgrade, so the file should exist. But there doesn't seem to > be any "sample" file anywhere in /usr/share so nothing that can be copied. > > Since the postinstall/etcupdate process has previously found other missing > rc.d files, and successfully fixed/installed them, I still consider this to > be a bug in -current. The mtree file says the file should exist, but it > doesn't. I guess is@ forgot to add it to etc/rc.d/Makefile and distrib/sets/lists/etc/mi in http://mail-index.netbsd.org/source-changes/2017/12/29/msg090788.html -uwe
Re: Missing file after postisnstall?
On Tue, Feb 13, 2018 at 05:40:22 +0800, Paul Goyette wrote: > I recently updated from 8.99.7 to 8.99.12 and noticed that my daily security > job reported a missing file: > > Checking special files and directories. > ./etc/rc.d/dhcpd6 missing > > Shouldn't this have been found and fixed by postinstall? Why it should be "fixed" if it ain't broken? :) Your system still happily boots without DHCP6 server, isn't it? If you want to update your configuration files to the new etc.tgz you run etcupdate. postinstall only does minimal configuration tweaks that are necessary to keep the system working with the new userland, or at least that was its original design goal as I remember it. -uwe
Re: cross-compiling kernel
On Fri, Aug 04, 2017 at 14:18:36 +0200, Riccardo Mottola wrote:
> Is building an x86 a "full cross compile"? I suppose yes and I
> followef the NetBSD build for sparc, just with x86.
Yes, it's full cross compilation.
> I want to use the standard kernel GENERIC, thus I did:
>
> ./build.sh -U -m i386 -u tools
>
> I don't get a full x86 toolchain though, in /usr/obj I find:
> $ ls /usr/obj/
> sys tools
> tooldir.NetBSD-8.99.1-amd64
>
> I expected instead something like:
> /usr/obj/tooldir.NetBSD-8.99.1-i386
[...]
> ===> TOOLDIR path: /usr/src/obj/tooldir.NetBSD-8.99.1-amd64
[...]
> so it is expected apparently.
TOOLDIR defaults to tooldir.${host_ostype}, so it reflects your os.
> although I find inside multiple binaries, e.g. :
> /usr/obj/tooldir.NetBSD-8.99.1-amd64/bin/nbmake
> /usr/obj/tooldir.NetBSD-8.99.1-amd64/bin/nbmake-amd64
> /usr/obj/tooldir.NetBSD-8.99.1-amd64/bin/nbmake-i386
>
> I thus tried:
> $ /usr/obj/tooldir.NetBSD-8.99.1-amd64/bin/nbmake-i386 depend
>
> but this fails:
> /usr/src/obj/tooldir.NetBSD-8.99.1-amd64/bin/nbgenassym:
> /usr/src/obj/tooldir.NetBSD-8.99.1-amd64/bin/i486--netbsdelf-gcc: not found
>
> I have several i486 tools, but not all:
> /usr/obj/tooldir.NetBSD-8.99.1-amd64/bin/i486--netbsdelf-dbsym
> /usr/obj/tooldir.NetBSD-8.99.1-amd64/bin/i486--netbsdelf-fdisk
> /usr/obj/tooldir.NetBSD-8.99.1-amd64/bin/i486--netbsdelf-install
> /usr/obj/tooldir.NetBSD-8.99.1-amd64/bin/i486--netbsdelf-mdsetimage
This is strange. Anything in your /etc/mk.conf or environment? You
can look at the /usr/obj/tooldir.NetBSD-8.99.1-amd64/bin/nbmake-i386
make wrapper script and check what does it set TOOLDIR too.
-uwe
Re: building a kernel "the old way"
On Fri, May 26, 2017 at 11:11:21 +0200, Christian Groessler wrote: > Date: Fri, 26 May 2017 11:11:21 +0200 > From: Christian Groessler > Subject: Re: building a kernel "the old way" > To: port-mac...@netbsd.org, current-users@netbsd.org > > On 05/25/17 03:07, Valery Ushakov wrote: > > > Move your /etc/mk.conf out of the way temporarily. I suspect you > > might be running into some obscure corner cases of objdir handling. > > See (emphasis mine): > > > >nbmake[1]: stopped in /local/netbsd-src/OBJ/.../compile/GENERIC/lib/kern > > > > while > > > >nbmake[1]: cannot open ../../../../../../lib/libkern/Makefile. > > > > seems to indicate it assumes you are running inside the src tree (not > > in an objdir). > > > Yes, I'm running inside the src tree (I thought that was clear from my > posted command sequences). Obviously that was clear. What I meant is, that judging by the ../... prefix, that specific command thinks it's run from the specific place inside the source tree, not from the corresponding specific place in the objdir (that may or may not be inside the source tree too). > But this answer (and the other answer to run "make obj" before) put > me on the right track. > > Moving mk.conf out of the way didn't help either. Error message now > indicated a missing directory in the /usr/obj tree. Sorry, I always forget about /usr/obj magic. As I said - obscure corner cases of objdir handling. As a general rule I think it's a bad idea to have anything directly objdir related(*) in mk.conf and (not that I remember it) to have /usr/obj. (*) In case I'm not clear enough again, I mean MAKEOBJ* (generic) and MKOBJDIRS (specific to netbsd source tree) variables. Stuff like OBJMACHINE is fine. -uwe
Re: building a kernel "the old way"
On Thu, May 25, 2017 at 04:07:09 +0300, Valery Ushakov wrote: > Move your /etc/mk.conf out of the way temporarily. I suspect you > might be running into some obscure corner cases of objdir handling. [...] Alternatively, run (nb)make obj before running (nb)make dependall, since your mk.conf requires objdir. -uwe
Re: building a kernel "the old way"
On Thu, May 25, 2017 at 03:14:10 +0200, Christian Groessler wrote: > On 05/25/17 01:25, Christian Groessler wrote: > > If you guys/gals run "config"/"nbconfig", do you have a lib/compat dir > > in the compile dir? > > Any input on that? Yes, there is such a directory. See my earlier replies about objdirs. -uwe
Re: building a kernel "the old way"
On Thu, May 25, 2017 at 01:50:23 +0200, Christian Groessler wrote: > On 05/25/17 01:44, Robert Swindells wrote: > > Christian Groessler wrote: > > > I should have a complete source tree. 'build.sh', at least, was able to > > > build the whole system without errors. [...] > > [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/conf]$ rm -rf > ../compile/GENERIC/ > [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/conf]$ > /local/netbsd-src/tools/bin/nbconfig GENERIC > Build directory is ../compile/GENERIC > Don't forget to run "make depend" > [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/conf]$ cd - > /local/netbsd-src/src/sys/arch/macppc/compile/GENERIC > [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC]$ > /local/netbsd-src/tools/bin/nbmake-macppc depend > depending the kern library objects > nbmake[1]: cannot open ../../../../../../lib/libkern/Makefile. > > nbmake[1]: stopped in > /local/netbsd-src/obj/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC/lib/kern > > *** Failed target: dependkernlib > *** Failed command: cd > /local/netbsd-src/obj/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC/lib/kern > && /local/netbsd-src/tools/bin/nbmake ... Move your /etc/mk.conf out of the way temporarily. I suspect you might be running into some obscure corner cases of objdir handling. See (emphasis mine): nbmake[1]: stopped in /local/netbsd-src/OBJ/.../compile/GENERIC/lib/kern while nbmake[1]: cannot open ../../../../../../lib/libkern/Makefile. seems to indicate it assumes you are running inside the src tree (not in an objdir). -uwe
Re: building a kernel "the old way"
On Wed, May 24, 2017 at 16:59:58 +0200, Christian Groessler wrote: > with "old way" I mean not using build.sh. > > I ran: > > - > [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/conf]$ config GENERIC > Build directory is ../compile/GENERIC > Don't forget to run "make depend" > [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/conf]$ cd > ../compile/GENERIC/ > [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC]$ make > making sure the compat library is up to date... > make[1]: cannot open ../../../../../../compat/common/Makefile. $ make USETOOLS=no should work - if the sources are ~the same as the host you build on (config is compatible, etc, etc). -uwe
Re: audio/moc dumps core in libcurses
On Mon, Jan 30, 2017 at 12:28:21 +, Roy Marples wrote: > On 30/01/2017 11:40, Valery Ushakov wrote: > > It was my impression that the traditional interface was for a program > > to just set global ESCDELAY variable directly and that set_escdelay() > > was a wrapper function intended to provide internal locking for > > multithreaded programs. I.e. it's not a setter that hides where and > > how the value is stored. > > > > From a quick look at the code in current it looks like you've broken > > this for existing programs that just set the ESCDELAY variable > > directly, since the new code ignores the variable. > > That's a fair observation. > > Maybe we should store a bit on the screen to indicate whether we should > use the screen variable or the global variable? It's not clear what would be the right thing to do since ESCDELAY is non-standard (does anyone know if it predates set_term? my guess would be yes). I guess the least ugly backward compatible solution would be to use the global variable in getch() and save/restore its value in the screen's structure when set_term() is called. -uwe
Re: audio/moc dumps core in libcurses
On Mon, Jan 30, 2017 at 11:02:05 +, Roy Marples wrote: > On 30/01/2017 04:22, co...@sdf.org wrote: > > I've applied a patch to audio/moc. It works on my end now. > > It was attempting set_escdelay (25); very early, before setting > > up a window. > > > > On nbcurses it was:_cursesi_screen->ESCDELAY = escdelay; > > which was a null deref. > > > > for ncurses, it was returning an error, but it was ignoring it. > > We have a lot of similar functions which operate without checking the > terminal has been setup or not. > It *IS* a programming error, so it's probably best to use an assert > rather than simply returning ERR. > > Anyone have any stronger opinions on this before I add asserts > liberally to our curses? It was my impression that the traditional interface was for a program to just set global ESCDELAY variable directly and that set_escdelay() was a wrapper function intended to provide internal locking for multithreaded programs. I.e. it's not a setter that hides where and how the value is stored. >From a quick look at the code in current it looks like you've broken this for existing programs that just set the ESCDELAY variable directly, since the new code ignores the variable. -uwe
Re: i386 on VirturalBox boot failed
On Wed, Nov 30, 2016 at 13:34:16 +0300, Valery Ushakov wrote:
> On Wed, Nov 30, 2016 at 04:58:40 +0300, Valery Ushakov wrote:
>
> > On Wed, Nov 30, 2016 at 08:53:02 +0900, Jun Ebihara wrote:
> >
> > > VirtualBox 5.0.30 on CentOS6.8:
> > >
> > > use nyftp iso image:
> > >
> > > NetBSD 7.99.42 GENERIC.201611131540Z ... boot fine.
> > >
> > > dmesg:
> > > https://github.com/ebijun/NetBSD/blob/master/dmesg/i386/VirtualBox
>
> Sorry I managed to miss this part.
>
> > > NetBSD 7.99.42 GENERIC.201611271450Z: ... stucked.
> > > NetBSD 7.99.43 GENERIC.201611291610Z: ... stucked.
> > >
> > > kernel: supervisor trap page fault, code=0
> > > uvm_fault(0xc12bc400,0xc153000,1) -> 0xe
> > > fatal page fault in supervisor mode
> > > trap type 6 code 0 eip c0153468 cs 8 eflags 10282 cr2 c153300 ilevel 8
> > > esp c0f41cfd
> > > curlwp 0xc1228720 pid 0 lid 1 lowest kstack 0xc14c92c0
> > > kernel: supervisor trap page fault, code=0
> > >:
> > >
> > > and stucked.
>
> The problem starts with
>
> cpu0 at mainbus0uvm_fault(0xc12bc400, 0xc1534000, 1) -> 0xe
> fatal page fault in supervisor mode
> trap type 6 code 0 eip c013135c cs 8 eflags 10287 cr2 c1534020 ilevel 8 esp
> c0f44d79
> curlwp 0xc1228720 pid 0 lid 1 lowest kstack 0xc14ca2c0
> kernel: supervisor trap page fault, code=0
> uvm_fault(0xc12bc400, 0xc1534000, 1) -> 0xe
> fatal page fault in supervisor mode
> trap type 6 code 0 eip c0153468 cs 8 eflags 10286 cr2 c1534300 ilevel 8 esp
> c0f41cfd
> curlwp 0xc1228720 pid 0 lid 1 lowest kstack 0xc14ca2c0
> kernel: supervisor trap page fault, code=0
> ...
>
> - and then the latter repeats.
>
>
> The first fault is in cpu_attach() accessing lapic_cpu_number() in
> sys/arch/x86/x86/cpu.c line 389:
>
> aprint_naive(": %s Processor\n",
> caa->cpu_role == CPU_ROLE_SP ? "Single" : "Boot");
> ci = &cpu_info_primary;
> #if NLAPIC > 0
> if (cpunum != lapic_cpu_number()) ...
>
> callaprint_naive# ": %s Processor\n" ...
> mov 0xc125de80, %eax# local_apic_va
> mov 0x20(%eax), %eax# LAPIC_ID
>
>
> That second, repeating fault is i82489_icr_wait(), also accessing
> local_apic_va.
>
>
> So I'd guess the problem is the fallout from this commit:
>
> http://mail-index.netbsd.org/source-changes/2016/11/25/msg079344.html
>
>
> I don't know much about x86 to tell whether it's vbox problem :).
I guess that change exposed an old bug. Previously, the lapic page
was statically pre-allocated and so it was always there. Even if
lapic wasn't initialized, we could still read (garbage) from that
page. Now the page is allocated dynamically, so when we try to read
uninitialized data, we get a fault.
A quick workaround for now is to check "Enable I/O APIC" in VM's
preferences in the System settings.
-uwe
Re: i386 on VirturalBox boot failed
On Wed, Nov 30, 2016 at 04:58:40 +0300, Valery Ushakov wrote:
> On Wed, Nov 30, 2016 at 08:53:02 +0900, Jun Ebihara wrote:
>
> > VirtualBox 5.0.30 on CentOS6.8:
> >
> > use nyftp iso image:
> >
> > NetBSD 7.99.42 GENERIC.201611131540Z ... boot fine.
> >
> > dmesg:
> > https://github.com/ebijun/NetBSD/blob/master/dmesg/i386/VirtualBox
Sorry I managed to miss this part.
> > NetBSD 7.99.42 GENERIC.201611271450Z: ... stucked.
> > NetBSD 7.99.43 GENERIC.201611291610Z: ... stucked.
> >
> > kernel: supervisor trap page fault, code=0
> > uvm_fault(0xc12bc400,0xc153000,1) -> 0xe
> > fatal page fault in supervisor mode
> > trap type 6 code 0 eip c0153468 cs 8 eflags 10282 cr2 c153300 ilevel 8 esp
> > c0f41cfd
> > curlwp 0xc1228720 pid 0 lid 1 lowest kstack 0xc14c92c0
> > kernel: supervisor trap page fault, code=0
> >:
> >
> > and stucked.
The problem starts with
cpu0 at mainbus0uvm_fault(0xc12bc400, 0xc1534000, 1) -> 0xe
fatal page fault in supervisor mode
trap type 6 code 0 eip c013135c cs 8 eflags 10287 cr2 c1534020 ilevel 8 esp
c0f44d79
curlwp 0xc1228720 pid 0 lid 1 lowest kstack 0xc14ca2c0
kernel: supervisor trap page fault, code=0
uvm_fault(0xc12bc400, 0xc1534000, 1) -> 0xe
fatal page fault in supervisor mode
trap type 6 code 0 eip c0153468 cs 8 eflags 10286 cr2 c1534300 ilevel 8 esp
c0f41cfd
curlwp 0xc1228720 pid 0 lid 1 lowest kstack 0xc14ca2c0
kernel: supervisor trap page fault, code=0
...
- and then the latter repeats.
The first fault is in cpu_attach() accessing lapic_cpu_number() in
sys/arch/x86/x86/cpu.c line 389:
aprint_naive(": %s Processor\n",
caa->cpu_role == CPU_ROLE_SP ? "Single" : "Boot");
ci = &cpu_info_primary;
#if NLAPIC > 0
if (cpunum != lapic_cpu_number()) ...
callaprint_naive# ": %s Processor\n" ...
mov 0xc125de80, %eax# local_apic_va
mov 0x20(%eax), %eax# LAPIC_ID
That second, repeating fault is i82489_icr_wait(), also accessing
local_apic_va.
So I'd guess the problem is the fallout from this commit:
http://mail-index.netbsd.org/source-changes/2016/11/25/msg079344.html
I don't know much about x86 to tell whether it's vbox problem :).
-uwe
Re: i386 on VirturalBox boot failed
On Wed, Nov 30, 2016 at 08:53:02 +0900, Jun Ebihara wrote: > VirtualBox 5.0.30 on CentOS6.8: > > use nyftp iso image: > > NetBSD 7.99.42 GENERIC.201611131540Z ... boot fine. > > dmesg: > https://github.com/ebijun/NetBSD/blob/master/dmesg/i386/VirtualBox > > NetBSD 7.99.42 GENERIC.201611271450Z: ... stucked. > NetBSD 7.99.43 GENERIC.201611291610Z: ... stucked. > > kernel: supervisor trap page fault, code=0 > uvm_fault(0xc12bc400,0xc153000,1) -> 0xe > fatal page fault in supervisor mode > trap type 6 code 0 eip c0153468 cs 8 eflags 10282 cr2 c153300 ilevel 8 esp > c0f41cfd > curlwp 0xc1228720 pid 0 lid 1 lowest kstack 0xc14c92c0 > kernel: supervisor trap page fault, code=0 >: > > and stucked. Does your host cpu support VT-x? -uwe
Re: rasops15 byte order bug
On Fri, Sep 16, 2016 at 13:05:16 -0400, Michael wrote: > On Fri, 16 Sep 2016 11:11:34 +0200 > Manuel Bouyer wrote: > > > On Wed, Sep 14, 2016 at 01:40:50PM -0700, scole_mail wrote: > > > Anyone using a 15/16 bit rasops console without issues? I think there is > > > a byte order error in rasops15.c . > > > > > > This patch worked for me, wondering if anyone else can confirm the error > > > and/or verify this fix. > > > > It's been a while since I played with this, but I think this is used for > > tifb (am335x SoCs, as found on the beaglebone). AFAIK It works fine for me > > with a 16bit display. > > I suspect the #ifdef shouldn't check just host byte order but host byte > order vs. video hardware byte order. Probably needs a new rasops_info flag. I haven't touched this in a *very* long time, but (about early 2002) in rasops8.c I ended up with #if BYTE_ORDER == BIG_ENDIAN #define NEED_LITTLE_ENDIAN_STAMP RI_BSWAP #else #define NEED_LITTLE_ENDIAN_STAMP 0 #endif if ((ri->ri_flg & RI_BSWAP) == NEED_LITTLE_ENDIAN_STAMP) ... Don't know how correct that was, but it's been working for the endian permutations we have. Note that we apply RI_BSWAP to 32 and 15/16 bit cases in rasops.c, not when building stamps. -uwe
Re: rasops15 byte order bug
On Wed, Sep 14, 2016 at 13:40:50 -0700, scole_mail wrote: > Anyone using a 15/16 bit rasops console without issues? I think > there is a byte order error in rasops15.c Are you sure it's not the case of missing RI_BSWAP flag in your framebuffer attachment? -uwe
Re: pipe read returning EAGAIN
On Mon, Feb 08, 2016 at 11:47:44 +0100, Manuel Bouyer wrote: > On Sun, Feb 07, 2016 at 08:49:32PM +0100, Manuel Bouyer wrote: > > On Sun, Feb 07, 2016 at 03:23:58PM +0100, Manuel Bouyer wrote: > > > It looks like the read(2) syscall returns a EAGAIN when the caller > > > expect it to block if there's no data available. > > > > I could capture the pipe setup before getting the stream of EAGAIN: > > 20110 1 nagios EMUL "netbsd" > > 20110 1 nagios CALL read(3,0xbb51a000,0x8) > > 20110 1 nagios GIO fd 3 read 114 bytes > >"job_id=5513\0type=0\0command=/usr/pkg/libexec/nagios/check_snmp -H > > 10.\ > > 128.12.0 -o .1.3.6.1.2.1.1.5.0\0timeout=60\0\^A\0\0\0" > > 20110 1 nagios RET read 114/0x72 > > 20110 1 nagios CALL __gettimeofday50(0xbb59d08c,0) > > 20110 1 nagios RET __gettimeofday50 0 > > 20110 1 nagios CALL __gettimeofday50(0xbf7fe4a4,0) > > 20110 1 nagios RET __gettimeofday50 0 > > 20110 1 nagios CALL __gettimeofday50(0xbf7fe4ac,0) > > 20110 1 nagios RET __gettimeofday50 0 > > 20110 1 nagios CALL __gettimeofday50(0xbf7fe468,0) > > 20110 1 nagios RET __gettimeofday50 0 > > 20110 1 nagios CALL pipe > > 20110 1 nagios RET pipe 4, 5 > > 20110 1 nagios CALL pipe > > 20110 1 nagios RET pipe 6, 7 > > 20110 1 nagios CALL fcntl(4,4,4) > > 20110 1 nagios RET fcntl 0 > > 20110 1 nagios CALL fcntl(6,4,4) > > 20110 1 nagios RET fcntl 0 > > 20110 1 nagios CALL fork > > 20110 1 nagios RET fork 1822/0x71e > > 20110 1 nagios CALL close(5) > > 20110 1 nagios RET close 0 > > 20110 1 nagios CALL close(7) > > 20110 1 nagios RET close 0 > > 20110 1 nagios CALL read(4,0xbf7fd4e0,0x1000) > > 20110 1 nagios RET read -1 errno 35 Resource temporarily > > unavailable > > 20110 1 nagios CALL read(4,0xbf7fd4e0,0x1000) > > 20110 1 nagios RET read -1 errno 35 Resource temporarily > > unavailable > > 20110 1 nagios CALL read(4,0xbf7fd4e0,0x1000) > > 20110 1 nagios RET read -1 errno 35 Resource temporarily > > unavailable > > > > If I read this properly, the 2 fnctl calls do a F_SETFL with > > O_NONBLOCK. So it looks normal for the read to return EAGAIN in this case. > > > > What I find strange is that there's no call to poll(2) or select(2) > > before before the call to read(2). > > If I read the sources properly the process should use poll(2) before calling > > read(2). I can't see why this would not show up in the ktrace output. > > There is a call to pool. What happens is that it gets a POLLIN event > for both fd 3 (which really has data to read) and fd 4 (wich doesn't). > > The read callback for fd 4 expects to be called only when there's really > data to be read, and if read returns EAGAIN it loops until it gets data. I guess it may be argued both ways, but I always thought that poll's contract was that the call to read(2) (or corresponding syscall) will not block. So occasionally reporting a descriptor that will cause read(2) to return EAGAIN may be is not that useful, but doesn't violate the contract. Of course if poll(2) always reported such descriptors on each call, it would be useless/buggy. But I think callers must not assume that the data are guarnteed to be available, so I'd say this caller is buggy. > poll is called with a set of descriptors, and returns that there is > 1 descriptor ready to be read. But the POLLIN flag is set for both > descriptors 3 and 4. This is a bug. It should have returned 2 if it set revents for fd 4 to non-zero value. -uwe
Re: Does wscons use compat syscalls to switch sessions
On Sun, Oct 18, 2015 at 11:03:37 +0800, Paul Goyette wrote:
> I just noticed that when switching console sessions from my X display
> (on ttyE4) to the console session (on ttyE0), the system auto-loads the
> "compat" kernel module.
>
> Is this expected? normal? Shouldn't all "current" production code be
> using "current" syscalls and/or ioctls?
This might be (haven't looked) the same problem I complained about
some time ago on tech-kern:
http://mail-index.netbsd.org/tech-kern/2013/12/15/msg016327.html
On Sun, Dec 15, 2013 at 15:35:01 +0400, Valery Ushakov wrote:
> Date: Sun, 15 Dec 2013 15:35:01 +0400
> From: Valery Ushakov
> Subject: Compat module auto-bounce
> To: tech-k...@netbsd.org
>
> ttioctl() in sys/tty.c ends with doing
>
> (void)module_autoload("compat", MODULE_CLASS_ANY);
>
> for ioctls that it doesn't know about. This causes compat module to
> auto-bounce in and out a lot. Note that this happens even for
> up-to-date userland that doesn't need compat code. E.g. ttyname(3)
> uses TIOCPTSNAME which ttioctl() doesn't handle. Running vi on
> console seems to cause compat.mod to be autoloaded twice.
>
> This seems rather wasteful.
-uwe
Re: sqlite3.pc strikes again
On Sat, Mar 08, 2014 at 17:09:11 +, David Laight wrote: > On Sat, Mar 08, 2014 at 07:43:36PM +0400, Valery Ushakov wrote: > > There is still a problems with sqlite3.pc. It's generated with wrong > > CC invocation. On an Ubuntu host, where there's no > > /usr/include/stdarg.h the build fails with: > > Interesting - I thought that was a posix header. > A quick search for va_copy gives a linux man page that tells you > to include stdarg.h - so what is ubunto up to? Right, but stdarg.h doesn't have to be in /usr/include, it just has to be in compiler's default include search path (/usr/lib/gcc/.../mumble). -uwe
