Re: Supported graphics (in HEAD)

I wrote: > I didn't think of [trying other Nvidia boards]. Tried two even older Nvidia boards I happened to have on the shelf, but the kernel crashed during autoconfiguration with both of them. Then I found this cute little Radeon board, a really old one, and now I'm happy as a clam. Never had

Re: Supported graphics (in HEAD)

matthew green writes: > can you file a PR about this? Done. kern/56826 > i don't see the problem on 750 or 730 cards. I didn't think of that... I do have a couple of other graphics boards on the shelf, but as they're all Nvidia, I figured it didn't make sense to try them. Guess I'll do

Re: Supported graphics (in HEAD)

Robert Elz writes: > Any advice? Well, in my experience, nvidia is probably something you only want if you have lots of RAM in your workstation. In HEAD, there's a lot of memory leaking going on - every change to the image on the monitor leaks kmem-04096 items, and on my 1920x1080 monitor,

Re: Disappearing mouse buttons

n...@netbsd.org writes: > Nope, too low level. Take a look at how buttons are processed here: > > xsrc/external/mit/xf86-input-ws/dist/src/ws.c Thanks - I'll take a look at it tonight, instrument it a bit, and see what I can discover. Interestingly, the modification I suggested didn't make any

Re: Disappearing mouse buttons

n...@netbsd.org writes: > I think you're looking in the wrong area - the most likely culprit is > a change I made to Xorg where the default driver for pointing devices > will be "ws" instead of "mouse" (this is primaily useful for > touchscreens and touchpads, and mirrors a similar change for

Re: Disappearing mouse buttons

Michael writes: > Does it still work as expected with an older -current? Yup. It still works the way it used to when I plug it into my Pinebook, that still runs a -current from early September, and likewise with my Linux laptop. The dmesg output from the Pinebook is identical: it says "5

Disappearing mouse buttons

I'm looking for something that I can't find... The "Kensington Expert Mouse" trackball on my amd64-current workstation has four buttons and a scroll wheel, and these used to generate all different button presses - so at least six distinct buttons. This was still working with a -current from back

MIDI with Java on -current?

I have this Java application (JSynthLib) that needs to talk MIDI with my synthesizers. I've previously run it with older versions of the JRE, using the LinuxCharDevMidiProvider that came with it - but that no longer works with the current environments. All I really need is a standard interface

Partial reads on unix domain sockets

Some time last year, probably late summer or autumn, a change was made that caused transfer of small chunks of data over unix domain sockets to have a higher chance of resulting in a read() getting only part of the chunk. While there is no guarantee of a one to one relationship between writes and

Re: Is anyone using the wg(4) driver with a commerical VPN service??

Brad Spencer writes: > Just wondering if anyone has succeeded in getting the wg(4) network > driver working with one of the commercial VPN providers? I attempted it > with one in particular, with an admitted slightly older -current and did > not succeed in getting it working. Haven't tried

Re: cmake hanging

Chavdar Ivanov writes: > je_malloc_mutex_lock_slow is seen in the both traces in one of the > threads (weird that all of them are trying to mknod...). The same call > is seen in my trace. Ditto for mine. -tih -- Most people who graduate with CS degrees don't understand the significance of

Re: cmake hanging

Chavdar Ivanov writes: > I am having the same cmake hangs as in this thread. I've attached the > gdb 'thread apply all bt' output (collected with script). That looks suspiciouly similar to the hangs I'm seeing with dhcpd on amd64-current (note the mutex lock attempt, while nothing else looks

Re: WireGuard in NetBSD

Robert Swindells writes: > Does it work for IPv6 ? Yes, it does. I've been using it all along, with my main NetBSD server system as a hub, and various NetBSD and Linux laptops, android phones, and the NetBSD system at our mountain cabin connecting to it. It's been very well behaved on amd64

Re: USB keyboard input overrun on EHCI?

I wrote: > I'll test a kernel without that "else if" block tonight. After discussion on IRC, what I'll try first of all is to change callout_reset(>sc_delay, 1, ukbd_delayed_decode, sc); to callout_reset(>sc_delay, 0, ukbd_delayed_decode, sc); inside the "else if" block. We only need

Re: USB keyboard input overrun on EHCI?

Brian Buhrow writes: > hello. My recollection may be slightly wrong here since I'm > still running NetBSD-5 in most cases, but my understanding is that > ehci(4) connected devices are all USB-2.0 and for slower devices, the > uhci(4) or ohci(4) hub drivers provide service. Ah, it's not

USB keyboard input overrun on EHCI?

This is a problem that I believe has been present for a while, but has recently (since the new year) become worse: I have, for a long time, been using a bar code scanner to register books on LibraryThing, and I've been noticing that my amd64 home workstation has had a tendency to drop a digit

Re: mpv coredump

Thomas Klausner writes: >> To generate a diff of this commit: >> cvs rdiff -u -r1.164 -r1.165 src/lib/libpthread/pthread.c >> cvs rdiff -u -r1.101 -r1.102 src/lib/libpthread/pthread_int.h >> cvs rdiff -u -r1.74 -r1.75 src/lib/libpthread/pthread_mutex.c >> cvs rdiff -u -r1.18 -r1.19

Re: crashes in amd64 8.99.51/9.99.2 with panic: pr_find_pagehead: [npfcn4pl]

Tom Ivar Helbekkmo writes: > Geoff Wing writes: > >> 8.99.51 crash: >> panic: pr_find_pagehead: [npfcn4pl] item 0x98a0b89491b8 poolid 182 != 181 > > I'm seeing these on amd64 and aarch64, both current at the time that the > release branch for version 9 was create

Re: crashes in amd64 8.99.51/9.99.2 with panic: pr_find_pagehead: [npfcn4pl]

Geoff Wing writes: > 8.99.51 crash: > panic: pr_find_pagehead: [npfcn4pl] item 0x98a0b89491b8 poolid 182 != 181 I'm seeing these on amd64 and aarch64, both current at the time that the release branch for version 9 was created. The crashes seem to happen when there's quite a bit of disk

Re: Recent USB changes broke kernel memory allocation

Jaromír Doleček writes: > Fixed now. If you update the tree to have sys/dev/usb/umass.c rev. > 1.174 you'll get the fixed files. That did the trick! Thanks! :) -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in

Recent USB changes broke kernel memory allocation

It seems that changes made to USB code on February 7th broke the kernel memory allocation arena. After that point, it is enough to insert a USB memory stick into my amd64 laptop, and then remove it, to make the kernel crash. It seems the changes to the allocating and freeing calls got a bit

Re: Kernel crash trying to use union mount

"J. Hannken-Illjes" writes: > Please show your mounted file systems. : barsoom# ;mount /dev/ld0a on / type ffs (local) /dev/ld0f on /var type ffs (log, local) /dev/ld0e on /usr type ffs (log, NFS exported, local) /dev/ld1f on /var/pgsql/data type ffs (log, local) /dev/ld2e on /usr/local type

Kernel crash trying to use union mount

I just had a really weird crash on a NetBSD/amd64-current system, running a kernel 8.99.30 from January 2nd. Here's what happened: I was going to experiment with a rather large set of changes to the local copy of the source tree, which I'd want to revert afterwards, so I created a directory on

sys/arch/evbarm/conf/majors.evbarm missing in -current

Running 'postinstall check' on a Raspberry Pi 3B+ with a current (well, as of just before the openssl upgrade of a few days ago) evbarm64 installation complains about a missing majors file: makedev check: ERROR: can't find majors file '/usr/src/sys/arch/evbarm/conf/majors.evbarm' and

Re: A couple of amd64-current crashes

Martin Husemann writes: > Is that uhci a companion of a xhci? Which version of sys/dev/usb/xhci.c > do you have and can you post a full dmesg please? No xhci in this system, no. The uhci usage here is serial communication with a Z-Wave device that implements ucom0, as seen

A couple of amd64-current crashes

I'm playing with home automation software, so I'm suddenly doing a lot of USB communication. Here are a couple of crashes with -current as of a couple of days ago: : dejah# ;crash -N netbsd.9 -M netbsd.9.core Crash version 8.99.14, image version 8.99.14. System panicked: kernel diagnostic

Re: -current cloner interfaces broken/gone/unusable

Thomas Klausner writes: > On Tue, Apr 24, 2018 at 08:56:48AM +0100, Roy Marples wrote: >> Saying this, from what I'm hearing this only happens at boot time, so we >> could potentially shrink the buffer back down again if we need to consider >> dynamically growing it in the

Re: $ sudo ifconfig run0 up list scan

Andrew Cagney writes: > I'm guessing it should list both my and a few near by networks? I'm > getting no output and wpa_supplicant never gets past scanning. Same here. On my Raspberry Pi model B+: NetBSD 8.99.10 (OTIUM) #7: Mon Jan 1 14:03:12 CET 2018

Re: Heads-up: RPI FDTisation committed

Ryo ONODERA writes: > -current of 201801020600Z boots fine on my Raspberry Pi. > Maybe > https://mail-index.netbsd.org/source-changes/2018/01/01/msg090821.html > helps me. That's the change that made mine start working again. -tih -- Most people who graduate with CS degrees

Re: Build failing after recent vadvise changes

Christos Zoulas writes: > That's right, and the dependencies files point to them. Remember you > need to to this both in the regular libc and compat. Then the recent change to UPDATING by Martin Husemann should probably be amended slightly, so it no longer states that a

Re: Build failing after recent vadvise changes

Christos Zoulas writes: > You need to make cleandir in libc and rebuild. I thought that was what a full build without "-u" did, but it obviously isn't. What I've now done is physically remove everything in the obj directories under libc, and start a new build. (The

Re: Build failing after recent vadvise changes

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > Kamil Rytarowski <n...@gmx.com> writes: > >> It has been documented in doc/UPDATING: >> [...] >> +or a one time build without -u will do. > > ...which is what I did. It didn't do. :) Interest

Re: Build failing after recent vadvise changes

Kamil Rytarowski writes: > It has been documented in doc/UPDATING: > [...] > + or a one time build without -u will do. ...which is what I did. It didn't do. :) -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most

Build failing after recent vadvise changes

I just updated from CVS again today, and, following the advice in UPDATING, started a build without -u. That didn't do the trick: /usr/tools/bin/x86_64--netbsd-gcc -nodefaultlibs -shared -Wl,-soname,libc.so.12 -Wl,--warn-shared-textrel -Wl,-Map=libc.so.12.map -Wl,-z,initfirst

Re: 8.99.9 hangs

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > The hang is hard enough that hitting the NMI switch doesn't do > anything, which is interesting. Sorry, that's not correct: it does acknowledge the NMI; it just doesn't manage to get into DDB. I get (manually copied from a photogr

Re: 8.99.9 hangs

Thomas Klausner writes: > After updating to 8.99.9 I've experienced strange hangs. The keyboard > and mouse don't work any longer, and it doesn't react to the power > button, so I have to reset. Same here. It was really bad with a version from about a week ago, but after

Re: What's with pkgsrc and checksums?

Leonardo Taccari writes: > The main difference between `make mps' and manually invoking sha1(1) > is that the RCS $NetBSD$ keywords are deleted in the former, and hence > why the SHA1 checksum differs. Ah, and that's why the latter suddenly failed for me when I modified an

Re: What's with pkgsrc and checksums?

Joerg Sonnenberger writes: > That's never really been supported... The correct target is makepatchsum > (mps) or makedistinfo. Ah, "make distinfo" in the relevant pkgsrc directory. That works; it makes /usr/pkgsrc/mk/checksum/checksum claim that the checksum is wrong (and it also

What's with pkgsrc and checksums?

I'm used to being able to add local patches to pkgsrc, by putting the patch file in the patches/ subdirectory of the package, and then just doing "cd patches/; sha1 patch-my.new.patch >> ../distinfo". Now, these fail like this (in this particular case, I've modified a patch file, so I've replace

Re: Incompatible struct in_pktinfo (kern/48166)

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > [...] PR#48166, which is more than four years old, but still open. Christos showed me in a private email that the problem has since been all but solved. The rest, I'm pretty sure I've got a good handle on. I'll prepare a patch for

Incompatible struct in_pktinfo (kern/48166)

I decided to see exactly what changes it would take to get the latest PowerDNS suite to compile under NetBSD-current, which turns out to be "not a lot". One of the problems, though, is at our end, and concerns more than just PowerDNS. It has to do with how a UDP service on a multi-homed machine

Build failing on new gdb?

Trying to update to a fresh current, I get: #create libgdb/ada-lang.d CC=/usr/tools/bin/x86_64--netbsd-c++\ -std=gnu++11\ -Wno-error=stack-protector /usr/tools/bin/nbmkdep -f ada-lang.d.tmp -- --sysroot=/usr/arena/amd64 -D_KERNTYPES -I/usr/src/external/gpl3/gdb/lib/libgdb

Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]

m...@netbsd.org writes: > For any fortune quote you add, you may remove another, no questions > asked. > > For you, that means you can get rid of things you find even slightly > offensive without needing to convince another person of it being > "offensive enough". I assume this was intended as

Re: Crash related to VLANs in Oct 18th -current

Roy Marples writes: > The caveat is that we now need to ARP announce the address during > reboot to ensure dhcpcd gets the reply on an active interface. I assume it'll only do send a gratuitous ARP announcement for an address whose lease is still active? :) > Let me know

Re: Crash related to VLANs in Oct 18th -current

Roy Marples writes: > And you can stop the kernel from doing this too if not using dhcpcd > ndp -i wm0 -- -auto_linklocal Thanks, Roy! I wasn't aware of that possibility. Here's my modified /etc/ifconfig.wm0: !/usr/sbin/ndp -i wm0 -- -auto_linklocal up media 100baseTX

Re: Crash related to VLANs in Oct 18th -current

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > Anyway, I've updated my local copy with your patch to improve the UDP > error logging, and it's running now. It'll be interesting to see what > it says -- but I guess, since my network interface does checksumming in > ha

Re: Crash related to VLANs in Oct 18th -current

Roy Marples writes: > I don't know anything about 802.1q trunks. > How can I tell that it is one, and why shouldn't it have a local address? Maybe it should, at that? I was just a bit surprised. I've been thinking of 802.1q trunk end points as something other than network

Re: Crash related to VLANs in Oct 18th -current

Roy Marples writes: > This normally indicates a UDP checksum failure. > [...] > Maybe try disabling hardware processing of UDP checksums on the interface? Ah, I should have said: the packets it's complaining about are being sent by the local host's dhcpd to a DHCP client on

Re: Crash related to VLANs in Oct 18th -current

Kengo NAKAHARA writes: > Hmm..., sorry, I am not sure about this problem from that information. > Could you get tcpdump? Of course, if it is not a problem, please do it. tcpdump seems to show that this is dhcpcd listening on other interfaces than the one I'm trying to keep

Re: Crash related to VLANs in Oct 18th -current

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > That did the trick! Thank you! :) I'm actually wondering if there may be something else strange going on. Everything works fine -- but I have this dhcpcd running, because one of my VLANs is connected to a network where this ma

Re: Crash related to VLANs in Oct 18th -current

Kengo NAKAHARA writes: > Could you try the following patch? That did the trick! Thank you! :) -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay

Crash related to VLANs in Oct 18th -current

I just updated to a fresh -current yesterday, and am running it on a couple of amd64 systems. It crashes during boot on the third one, though, the one that has VLANs. It configures wm0 thus: # cat ifconfig.wm0 up media 100baseTX mediaopt full-duplex ip4csum tcp4csum udp4csum ...and then goes

Re: SSL/TLS and certificates

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > This is after installing packages mozilla-rootcerts and > mozilla-rootcerts-openssl, and configuring Postfix with > smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt ...and there's my silly mistake right there: "smtpd

Re: npf bug(?)

6b...@6bone.informatik.uni-leipzig.de writes: > Thanks for the patch. Unfortunately, I could not apply it to -7. I've > tested -current. The problem seems to be solved. Here it is, adjusted for the "netbsd-7" cvs tag: --- sys/net/npf/npf_handler.c~ 2017-03-30 17:26:49.458901595 +0200 +++

Re: Error/warning message from rc.d/npf

Paul Goyette writes: > See PR kern/51818 for more details - it seems that the second > "element" in $ext_if is ignored, and the ruleset is applied only to > the first "element". I'm guessing tun0 doesn't exist at the time npf is loaded, and a workaround would be to reload it

Re: PulseAudio and OSS audio of recent NetBSD-current

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > After the latest upgrade (from 7.99.59 to 7.99.64), it stopped working > for me, as well. I've gone back to using OSS directly instead. :) Just to add some detail: I was using pulseaudio (mostly from Firefox and Audacious

Re: PulseAudio and OSS audio of recent NetBSD-current

Johnny Billquist writes: >> ...and *man*, I'd forgotten how much 16-bit audio sucks. :) > > I guess that means you detest CDs like nothing else. :-) Yup. Compared, side-by-side, to a good vinyl recording, a CD sucks. But you've got a point. Falling back to OSS gives

Re: PulseAudio and OSS audio of recent NetBSD-current

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > After the latest upgrade (from 7.99.59 to 7.99.64), it stopped working > for me, as well. I've gone back to using OSS directly instead. :) ...and *man*, I'd forgotten how much 16-bit audio sucks. :) -tih -- Most people

Re: PulseAudio and OSS audio of recent NetBSD-current

Ryo ONODERA writes: > I would like to know if my problem is my environment specific > or not. After the latest upgrade (from 7.99.59 to 7.99.64), it stopped working for me, as well. I've gone back to using OSS directly instead. :) -tih -- Most people who graduate with

Re: A few crashes with yesterday's amd64-current -- IPv6 related?

Ryota Ozaki writes: > Hmm. Where did the first crash happen? In re(4) or NFS or ffs? No idea, I'm afraid. I'll just have to provoke another one. -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in

Re: A few crashes with yesterday's amd64-current -- IPv6 related?

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > Have done so, and have been building stuff for two or three hours with > no accidents. Looking good so far, in other words. It crashed just now, though. Unfortunately, it crashed again during boot, and ended up overwriting the o

Re: A few crashes with yesterday's amd64-current -- IPv6 related?

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > I will -- I'll just let it finish building firefox first. Had to give up on that -- too unstable. > Once that's done, I'll apply your patch to sys/net/if.c, and start > some heavy building over NFS again. Have done so, and hav

Re: A few crashes with yesterday's amd64-current -- IPv6 related?

Ryota Ozaki writes: > Oops. Reverting the commit makes no sense. Please ignore the second > request. OK! :) -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay

A few crashes with yesterday's amd64-current -- IPv6 related?

I updated again yesterday, and it seems at least one stability issue has been introduced since 7.99.59, which I was running before this. The first crash came when I was trying to shut down to single user after booting the new kernel with the existing userland. I *think* it was triggered by the

Re: NFS, UDP, and IPv6 don't play nice together

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > In fact, the very specific combination that doesn't work is NFS using > UDP over IPv6. That fails when writes are attempted, if the client is > running -current. The other three protocol combinations work fine. Simplest

NFS, UDP, and IPv6 don't play nice together

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > ...and with NFS over TCP, writing works without hanging. :) In fact, the very specific combination that doesn't work is NFS using UDP over IPv6. That fails when writes are attempted, if the client is running -current. The ot

Re: OpenVPN causes fresh -current to crash

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > Hm. Maybe I should change to a TCP mount, and see what happens... ...and with NFS over TCP, writing works without hanging. :) -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is

Re: OpenVPN causes fresh -current to crash

Ryota Ozaki writes: >>> The latest pfil.c (v1.34) should fix the panic. Could you try it? >> >> I'll give it a go tonight, and report back. I re-introduced the change that I previously rolled back to get things working, and then upgraded pfil.c to 1.34 and built a new

Re: OpenVPN causes fresh -current to crash

Ryota Ozaki writes: > The latest pfil.c (v1.34) should fix the panic. Could you try it? I'll give it a go tonight, and report back. Meanwhile, do you think this ongoing MPSAFE work may have some unwanted consequences for NFS? There's a problem that's been around for at

Re: OpenVPN causes fresh -current to crash

Martin Husemann writes: > Could you try backing out this change and see if it helps? > > http://mail-index.netbsd.org/source-changes/2017/01/16/msg081115.html That did the trick. I've rebooted a few times, now, and the system comes up as it should, with no incident, every

OpenVPN causes fresh -current to crash

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > Didn't go so well. My main machine does routing between several VLANs, > using Quagga to manage the routing, NPF and ALTQ for traffic management, > and OpenVPN for tunnels from remote devices, all the while offering a >

Re: wm devices don't work under current amd64

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > Christos Zoulas <chris...@zoulas.com> writes: > >> Right now it seems to be a good time to upgrade for example... > > That's what I'm hoping for - I started a couple of hours ago. :) Didn't go so well. My mai

Re: wm devices don't work under current amd64

Christos Zoulas writes: > Right now it seems to be a good time to upgrade for example... That's what I'm hoping for - I started a couple of hours ago. :) -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most

Re: wm devices don't work under current amd64

Christos Zoulas writes: > I don't know about that. It is pretty stable with me... I guess I worded that a bit clumsily. :) I meant that there seem to be a number of rather deep changes going on, accompanied by more reports of crashes than I'm used to seeing on

Re: wm devices don't work under current amd64

Christos Zoulas writes: > Perhaps we want a lock? OK, that makes sense - and might explain why my problem returned. (Especially as it's not quite the same as before, and the differences may well be locking related.) But should I pursue this on 7.99.39, or should I upgrade

Re: wm devices don't work under current amd64

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > However, another amd64 system that doesn't use VLANs, and is an NFS > client, is unable to write to NFS file systems if it runs a kernel > with the patch applied. Don't mind me - after a little while, the problem returned on th

Re: wm devices don't work under current amd64

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > Masanobu SAITOH <msai...@execsw.org> writes: > >> Please test the latest -current. knakahara found a problem: > > That worked fine! No longer any need for the tcpdump hack. :) > > (I didn't get the latest

Re: wm devices don't work under current amd64

Masanobu SAITOH writes: > Please test the latest -current. knakahara found a problem: That worked fine! No longer any need for the tcpdump hack. :) (I didn't get the latest -current; I just added those patches to 7.99.39.) -tih -- Most people who graduate with CS

Leap seconds and date(1)

Happy new year! :) Being awake, I decided to observe the leap second. Not much luck. Turns out that date(1) shows :59 for two seconds, instead of going to the correct :60 during the extra second. Is that correct behaviour? -tih -- Most people who graduate with CS degrees don't understand the

Re: panic enabling ipfilter (Dec 27)

Geoff Wing writes: > Unfortunately my machine is mostly headless and I can't get dmesg saved > after reboot. > [...] > Is "bt;sync" better? If you want the dmesg output, you do want the core dump: # dmesg -N /var/crash/netbsd.42 -M /var/crash/netbsd.42.core ...and for

Re: File descriptor leak involving kqueue

Eric Haszlakiewicz writes: > For cross-OS support you'll need to add a configure check for that. > In some environments it seems that the memory leak can't be fixed, > since res_ndestroy doesn't exist. Looks that way -- Linux doesn't even have res_nclose(), so I guess

Re: File descriptor leak involving kqueue

Joerg Sonnenberger writes: > It seems pretty obvious that OpenDMARC is not correctly managing > ressources. It creates an on-stack res_state, initialized it with > res_ninit, but never destroys it. Ah! I didn't catch that - thanks! I'll modify OpenDMARC to use res_ndestroy()

Re: File descriptor leak involving kqueue

Robert Swindells writes: > I think that close() of a socket can leak the kevent(2) structures > if there are some still active. No, I think something else is going on, and it's in the resolver. In lib/libc/resolv/res_send.c, in the function res_nsend(), res_check() is called,

Re: File descriptor leak involving kqueue

Robert Swindells writes: > Could you try with the following patch ? Running with it now - but not seeing any occurrences of your knote messages. -tih -- I like long walks, especially when they are taken by people who annoy me.

File descriptor leak involving kqueue

Lately, I'm running my postfix with opendkim and opendmarc milters (both from pkgsrc). Something about opendmarc is bleeding the system empty of file handles, and I'd appreciate some help thinking about how to find out exactly what's going on. fstat shows me this: opendmar opendmarc 12624 wd

Re: xorg.conf is read but not acted on correctly

co...@sdf.org writes: > Try this: Cool! I've got a working console again. Thanks! :) -tih -- I like long walks, especially when they are taken by people who annoy me.

Re: xorg.conf is read but not acted on correctly

co...@sdf.org writes: > Try this: I will! ...tomorrow, when I'm back home with my build system. I'm at our mountain cabin right now, with a cell phone as my modem/router. :) -tih -- I like long walks, especially when they are taken by people who annoy me.

Re: xorg.conf is read but not acted on correctly

co...@sdf.org writes: > (I dunno why it would be different on NetBSD than linux... > the xorg bits are identical). It's probably at a lower level. NetBSD fails to display the (text) console correctly with the nouveau driver, so I have to wait anxiously for the psychedelic, misaligned scan lines

Re: xorg.conf is read but not acted on correctly

I just tried attaching an external monitor to my old Dell Latitude E6400 laptop. The plug is VGA style. Linux happily tells me I have two monitors, with different resolutions, and it finds the correct maximum resolution of the external monitor. NetBSD (using the nouveau driver) decides to run

Re: The NPF firewall leaks! (was Re: in_cksum: out of data)

Mindaugas Rasiukevicius writes: > I agree that this is not really intuitive and the documentation did > not clarify this either. Yes, the documentation should be changed to state that when you explicitly specify tcp and stateful, you get the s/safr set. Most importantly, the

The NPF firewall leaks! (was Re: in_cksum: out of data)

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > So far, I have just one improvement suggestion for npf: the ability to > use sets instead of singletons in rules is great, but needs to be > extended to letting sets of addresses and networks cross address > families. I now

Re: in_cksum: out of data

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > Thanks, Christos! Then I'll be converting from pf to npf+altqd over the > weekend, I suppose. Hmpf! It's been only, what?, a few years? since I > converted from ipfilter to pf! ;) Well, that was quick and easy! I've n

Re: in_cksum: out of data

Christos Zoulas writes: >>Or, to ask more specifically: what *is* the preferred/suggested software >>firewall to use in a NetBSD system these days? > > npf... Thanks, Christos! Then I'll be converting from pf to npf+altqd over the weekend, I suppose. Hmpf! It's been

Re: in_cksum: out of data

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > Are there any plans for upgrading pf to a more current version (the > IPv6 support has been improved), or is the idea that one should > transition to npf + altqd? Or, to ask more specifically: what *is* the preferred/sug

Re: in_cksum: out of data

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > I'm using pf on it -- is this just a consequence of pf not supporting > fragmented IPv6 packets? That seems to be what it is. Are there any plans for upgrading pf to a more current version (the IPv6 support has been improved), or

in_cksum: out of data

I've started using IPv6, and since then, my main NetBSD system, which is my router connecting the ISP uplink to my various internal networks, has been sporadically emitting the message "in_cksum: out of data". I'm using pf on it -- is this just a consequence of pf not supporting fragmented IPv6

Re: dhcpcd build failure

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > Martin Husemann <mar...@duskware.de> writes: > >> I would completely remove $OBJDIR/external/bsd/dhcpcd [...] It turns out that's not the only one that needs to go. It's being separately built for a number of ramdisk

dhcpcd build failure

/usr/src/UPDATING says: 20161009: a new version of dhcpcd has been imported with slightly changed build infrastructure. When doing a build.sh -u this requires pruning the external/bsd/dhcpcd objdir. However, even with this pruning, the build fails: --- dhcpcd-embedded.d

Re: dump(8) 4.3BSD syntax

Thomas Klausner writes: > dump still supports, but doesn't document, the 4.3BSD style syntax. > > Is there someone who still finds that useful and thinks it should stay > supported, or is it perhaps time to lose that bit of compatibility? I hope that dump, just like ps, will

Re: USB serial problems

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > It's still doing it. But not after updating sys/dev/usb/ucom.c to revision 1.114, which was committed by Nick Hudson today. Previously, it would reliably hang on my second attempt to run a test program that opened and read the USB se

  1   2   >