Re: CVS commit: src/bin/sh

Roland Illig writes: > Anyway, the code in question was more verbose than necessary, so I made > it simpler. I also experimented with replacing the switch with a single > if statement, but that would have become too dense and thus difficult to > decipher. Yes, the code in exec.c looks much

Re: CVS commit: src/bin/sh

Roland Illig writes: > sh: ignore lint error about 'continue' in 'do while' loop > > exec.c(575): error: continue in 'do ... while (0)' loop [323] > jobs.c(203): error: continue in 'do ... while (0)' loop [323] > > It is certainly a rarely used feature, I saw it the first time today > and I

CVS commit: src/usr.sbin/inetd

Module Name:src Committed By: tih Date: Mon Aug 30 06:27:49 UTC 2021 Modified Files: src/usr.sbin/inetd: parse_v2.c Log Message: Summary: char is unsigned on arm, so use int when -1 indicates error hex_to_bits() returns -1 on error, so declare it int, and do the same for

CVS commit: src/usr.sbin/inetd

Module Name:src Committed By: tih Date: Mon Aug 30 06:27:49 UTC 2021 Modified Files: src/usr.sbin/inetd: parse_v2.c Log Message: Summary: char is unsigned on arm, so use int when -1 indicates error hex_to_bits() returns -1 on error, so declare it int, and do the same for

Re: CVS commit: src

Christos Zoulas writes: > Module Name: src > Committed By: christos > Date: Sun Aug 29 09:54:18 UTC 2021 > > Modified Files: > src/distrib/sets/lists/debug: mi > src/distrib/sets/lists/tests: mi > src/etc/mtree: NetBSD.dist.tests > src/tests/usr.sbin: Makefile >

Re: CVS commit: src/sys/dev/pci

Tobias Nygren writes: > Yep, MSI works now. According to the PCI Express Base Specification, > Revision 3.0, table 7-3, having the bus master bit set to 0 disables > MSI. Asmedia chip seems to have a bug which makes DMA work regardless ... Yup - it works just fine! Well done! :) ahcisata0:

Re: CVS commit: src/sys/dev/pci

Tobias Nygren writes: > Module Name: src > Committed By: tnn > Date: Fri Oct 18 17:16:50 UTC 2019 > > Modified Files: > src/sys/dev/pci: ahcisata_pci.c > > Log Message: > ahcisata: make sure bus mastering and memory space are actually enabled > > This makes the "ROCKPro64 PCI-e to

Re: CVS commit: src/external/bsd/jemalloc

Kamil Rytarowski writes: > I've pushed a fix to unbreak the build. > > Now we have a mismatch mallctlnametomib vs mallctltomib in malloc.h. > > Which one is correct? Rather obviously mallctlnametomib, I'd say - that's the one that's described in external/bsd/jemalloc/dist/doc/jemalloc.3. -tih

Re: CVS commit: src/external/bsd/jemalloc

Christos Zoulas writes: > Module Name: src > Committed By: christos > Date: Sun Mar 10 02:49:52 UTC 2019 > > Modified Files: > src/external/bsd/jemalloc/dist/src: jemalloc.c > src/external/bsd/jemalloc/include/jemalloc: jemalloc.h > src/external/bsd/jemalloc/lib:

Re: CVS commit: src/sys/arch

Tom Ivar Helbekkmo writes: > This one goes black: > > nouveau0 at pci1 dev 0 function 0: vendor 10de product 06eb (rev. 0xa1) > drm kern info: nouveau [ DEVICE][nouveau0] BOOT0 : 0x298580a2 > drm kern info: nouveau [ DEVICE][nouveau0] Chipset: G98 (NV98) > drm kern info:

Re: CVS commit: src/sys/arch

Robert Swindells writes: > Can we at least get some more data on which GPUs don't work ? This one goes black: nouveau0 at pci1 dev 0 function 0: vendor 10de product 06eb (rev. 0xa1) drm kern info: nouveau [ DEVICE][nouveau0] BOOT0 : 0x298580a2 drm kern info: nouveau [ DEVICE][nouveau0]

Re: CVS commit: src/sys/kern

Christos Zoulas <chris...@netbsd.org> writes: > Log Message: > make sure that we have enough space, don't require the exact size > (Tom Ivar Helbekkmo) Oops. That wasn't enough. If we're going to allow the caller of getsockopt(2) to supply an oversized buffer for receiving the

Re: CVS commit: src/sys/kern

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > Wouldn't it be better to check that sopt->sopt_size >= len, and return > an error if not? ...in other words, something like this (the second change is for sockopt_setmbuf() a few lines down, where I suspect the same risk i

Re: CVS commit: src/sys/kern

Christos Zoulas writes: > Log Message: > pass valsize for getsockopt like we do for setsockopt Looks like that uncovered something: Crash version 8.99.9, image version 8.99.9. System panicked: kernel diagnostic assertion "sopt->sopt_size == len" failed: file

Re: CVS commit: src/sys/netinet

Ryota Ozaki writes: > Yeah, so I hoped a better fix. For now, I'm running with yours, and it seems to have solved the problem. If a more correct solution is in place, I'm looking forward to testing that on my susceptible system, but it'll take a few days before I can: I'm

Re: CVS commit: src/sys/netinet

Ryota Ozaki writes: > Oh, my patch failed to keep SPL at IPL_VM because mutex_exit > tries to restore an SPL where mutex_enter is called. So I had to > put splvm before mutex_enter. Could you try the 2nd patch: > http://www.netbsd.org/~ozaki-r/fix-pool_catchup.diff Will

Re: CVS commit: src/sys/netinet

Ryota Ozaki writes: > I think the below patch fixes the above issue, but probably > there is a better solution. Looks like didn't -- it just changed it a little bit. Just like the last time, the hang happened while reading email over IMAP, which exercises disk and network

Re: CVS commit: src/sys/netinet

Ryota Ozaki writes: > I think the below patch fixes the above issue, but probably > there is a better solution. Thanks! I'm now running a fully up-to-date system (from just a half hour ago), with this patch added. I'll push it hard over the next 24h, with a mix of disk and

Re: CVS commit: src/sys/netinet

Ryota Ozaki writes: > One possible fix has been committed. > > Can you update the source code and try a new kernel? Will do. Meanwhile, before I got around to building a kernel with debug options enabled, I had another hang. Got it into DDB successfully, but then I

Re: CVS commit: src/sys/netinet

Martin Husemann writes: > The sparc64 hang happened with: > > $NetBSD: ip_output.c,v 1.288 2017/12/22 11:22:37 ozaki-r Exp $ My amd64 that experienced hangs has: $NetBSD: ip_output.c,v 1.287 2017/12/15 04:03:46 ozaki-r Exp $ ...and was last updated from CVS on

Re: CVS commit: src/games/fortune/datfiles

Tom Ivar Helbekkmo <t...@hamartun.priv.no> writes: > "stop out journey" should be "stop our journey", and the last sentence > should probably be "It seems that you care more about barking than the > dog does, and more about winning the war with a lousy pup

Re: CVS commit: src/games/fortune/datfiles

John Nemeth writes: > Log Message: > add quote about libraries offending everyone Nice! 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

Re: CVS commit: src/sys

Let me suggest a possible solution: Maxime very sensibly wants to minimize the attack surface of a basic, default, installation of the system. The main argument against this is that it would mean that casual installers would find that they couldn't run e.g. Linux binaries on a NetBSD/amd64

Re: CVS commit: src/share/dict

Maya Rashish writes: > potate isn't a word (at least not in English), remove it Maybe it was a typo for "potage", which is, and is missing. -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer

Re: CVS commit: src/sbin/mount_nfs

Robert Elz writes: > Did you intend to keep ... > > + printf("netid=%s\n", netid); > > ? He probably didn't - but updating mount_nfs (and removing this line for tidiness) solves my NFS problem. It now works for all combinations of upd, tcp, ipv4, and

Re: CVS commit: src/sys/arch

scole_m...@gmx.com writes: > I run emacs on stable i386 and it crashes for me probably once a day, > especially when opening large files or using a lot of "M-x compile" > commands. OK, for various reasons, I've "forever" been running with larger than default ulimits on i386 (and still had

Re: CVS commit: src/sys/arch

Maxime Villard writes: > AFAICT, emacs is known to be buggy on netbsd. That's strange, seeing as I've been using it daily since NetBSD 0.0, with no problems. That's on i386, vax, mips, sparc, and amd64 platforms. (It's been a while since I had a vax, mips, or sparc system

Re: CVS commit: src/sys/dev/usb

Nick Hudson writes: > Log Message: > Do not hold the softc lock (IPL_SOFTUSB) unnecessarily and specifically > across ucomparam (and the ucom_param method). The method can sleep wait- > ing for transfers... any input/output will try to acquire the lock and get > stuck This