> Date: Tue, 23 Apr 2024 10:52:41 -0400
> From: Jared Barnak
>
> I watched "How to get started hacking NetBSD" and it was great, I just
> noticed that some things didn't work when cross compiling for amd64. and
> frankly, I'm not sure what I did wrong.
Cool, thanks! The main thing you're
> Date: Tue, 26 Mar 2024 17:41:52 -0400
> From: Thor Lancelot Simon
>
> On Tue, Mar 26, 2024 at 12:25:07AM +0000, Taylor R Campbell wrote:
> >
> > We should really expose a /dev/ugen* instance for _every_ USB device;
> > those that have kernel drivers attache
> Date: Mon, 25 Mar 2024 19:47:31 -0400
> From: Greg Troxel
>
> Jason Thorpe writes:
>
> > I should be able to do this with OpenOCD (pkgsrc/devel/openocd), but
> > libfdti1 fails to find the device because libusb1 only deals in
> > "ugen".
>
> Is that fundamental, in that ugen has ioctls that
> Date: Mon, 22 Jan 2024 20:49:56 +0100
> From: Andreas Hecht
>
> I am trying to get the volume hotkeys (VolumeUp, VolumeDown, VolumeMute) on my
> Lenovo Thinkpad X200 to work. Unfortunately the respective hotkey events are
> not seen by thinkpad_acpi driver's thinkpad_notify_handler. The
> Date: Sun, 31 Dec 2023 11:36:41 +0100
> From: Emile 'iMil' Heitor
>
> I ported pvclock / kvm_clock from OpenBSD in order for Firecracker to
> have an RTC. It's working but I'm not entirely sure where to attach it.
>
> The device is x86 only so I added the source code in arch/x86/x86, and
>
I propose to deprecate the kmem(9) interface and go back to the
malloc(9) interface.
1. The main difference is that the malloc(9) interface enables
attribution of memory usage: how many bytes have been used for this
purpose vs that purpose, partitioned by named malloc tags like
M_MBUF
> Date: Thu, 28 Dec 2023 01:02:08 +0100
> From: Tobias Nygren
>
> I've spent some time testing GPUs on aarch64 and fixing bugs.
> Attached are some patches to make things more usable.
Cool, thanks! Some notes below. Everything else seems fine.
> [2] /libdata/firmware/amdgpu is not shipped.
>
ations -- only a target _minimum_, with an average that
is higher by necessity.
>From bca90989210e59c45efee9b44d7575e91f053a07 Mon Sep 17 00:00:00 2001
From: Taylor R Campbell
Date: Sat, 23 Dec 2023 21:03:13 +
Subject: [PATCH] time(9): Avoid adding partial tick to periodic interval
timers.
This way, configuring
> Date: Fri, 22 Dec 2023 23:41:47 -0500 (EST)
> From: Mouse
>
> Specifically, under a kernel built with HZ=100, requesting signals at
> 100Hz actually delivers them at 50Hz. This is behind the clock running
> at half speed on my VAX emulator, and quite likely behind similar
> behaviour from
> Date: Wed, 20 Dec 2023 08:37:32 +0100
> From: Emile 'iMil' Heitor
>
> On 12/20/23 06:55, Emile 'iMil' Heitor wrote:
>
> > Well that's the thing, I can't find where does MMIO attaches on FreeBSD,
> > they have a very simple way of creating the resources:
>
> After a bit of digging, their
> Date: Tue, 19 Dec 2023 08:55:32 +0100
> From: Emile 'iMil' Heitor
>
> Maybe related: the interrupt handler function I wrote uses
> softint_establish() as there's no "real" hardware behind this
> block device, is this the correct way to deal with it?
You need to use softint_schedule in order
> Date: Tue, 17 Oct 2023 14:39:57 +0200
> From: tlaro...@kergis.com
>
> I have modified drm.4 to state that the drivers are obsolete and
> to suppress a mention of viadrm that was removed long ago (now superseded by
> viadrmums, provided in drm2/ ---drmkms--- part).
>
> Patch can be retrieved
> Date: Sat, 14 Oct 2023 19:57:59 +0200
> From: tlaro...@kergis.com
>
> [I'm sending this to the tech-kern since the previous message on
> tech-userlevel is only: the list seems dead?]
Not dead, just quiet so far this month.
> DRM or now DRM2 (aka DRM/KMS) are inherently and heavily linked to
>
> Date: Fri, 13 Oct 2023 13:41:50 -0700
> From: Jason Thorpe
>
> > On Oct 13, 2023, at 11:48 AM, Andrew Doran wrote:
> >
> > Add cv_fdrestart() (better name suggestions welcome):
>
> Oof.
Why do we need this at all?
Condition variable semantics is standard, well-studied, and
> Date: Mon, 18 Sep 2023 19:21:09 +0200
> From: Martin Husemann
>
> On Mon, Sep 18, 2023 at 06:14:58PM +0100, David Brownlee wrote:
> > Specifically in the absence of any other information (empty devname?
> > etc), would it not be reasonable to fall back to the bootme marked
> > filesystem as a
[trimming tech-userlevel and tech-kern from cc list to avoid
cross-posting the entire thread]
> Date: Thu, 7 Sep 2023 11:53:56 + (UTC)
> From: RVP
>
> On Thu, 7 Sep 2023, Taylor R Campbell wrote:
>
> > I think we should have these knobs on by default, but of co
Today I learned that you can create hard links to a file you don't own
and can't write to or even read from:
$ su -l root -c 'touch /tmp/foo && chmod 600 /tmp/foo'
$ ln /tmp/foo /tmp/bar
This strikes me as bonkers and a likely source of security issues.
POSIX says:
> The implementation may
> Date: Wed, 23 Aug 2023 04:54:34 +0200
> From: "Vladimir 'phcoder' Serbinenko"
>
> This patch adds support for incompat_64bit on ext4 filesystem. This feature
> is enabled by default on new filesystems on Ubuntu and probably other
> distros
Cool, thanks! christos@ committed this.
It looks
Is there any mechanism that limits the memory usage of processes via
memfd(2)?
Without memfd(2), there are ulimits -- you can use RLIMIT_AS to limit
the address space size, and the number of file descriptors a process
can create to store data in pipe buffers is limited, and the amount of
data
> Date: Wed, 9 Aug 2023 13:11:13 -0400
> From: Theodore Preduta
>
> On 2023-08-09 04:58, Taylor R Campbell wrote:
> >> Date: Tue, 8 Aug 2023 11:47:17 -0400
> >> From: Theodore Preduta
> >>
> >> The semantics come from MacOS (and are the same in
> Date: Tue, 8 Aug 2023 11:47:17 -0400
> From: Theodore Preduta
>
> On 2023-08-08 06:53, Taylor R Campbell wrote:
> > What is the new struct kevent::ext member about? I read the new man
> > page but I'm still unclear on it.
> > 8. Is this API shared with any othe
What is the new struct kevent::ext member about? I read the new man
page but I'm still unclear on it.
1. Who owns it? Does it depend on the filter, the identifier, or
both?
2. Who writes or reads it, inside the kernel? It doesn't seem to be
mentioned in kern_event.c.
3. Why is
veriexec(4), and the fileassoc(9) API it uses internally, needs
maintenance and probably some serious rework to fix synchronization
problems on any MP and/or preemptible kernels (i.e., all x86 of the
past couple decades) with implications for any security properties it
is supposed to provide.
If
> Date: Mon, 31 Jul 2023 22:29:29 +0100
> From: Robert Swindells
>
> Theodore Preduta wrote:
> > This comes somewhat as a "part 2" to
> > https://mail-index.netbsd.org/tech-kern/2023/06/21/msg028926.html
> >
> > Given the responses to that thread, I decided to add native stubs
> > for epoll
The thorpej-cfargs branch had a change to systematically remove
interface attributes from config attachments:
https://mail-index.netbsd.org/source-changes-hg/2021/03/23/msg273413.html
I don't understand what the purpose is. It's like changing function
calls to not name the function that you're
> Date: Sat, 15 Jul 2023 03:48:54 +0200
> From: "Vladimir 'phcoder' Serbinenko"
>
> I've submitted a similar patch for OpenBSD recently and it got merged. It
> adds support for Elantech I2C touchpad used on many laptops. Tested on my
> Chromebook Elemi
Cool! This looks great. I don't have any
> Date: Mon, 24 Jul 2023 12:05:34 +0900
> From: PHO
>
> I realized the cause of this:
> [...]
> There were cases where the function was destroying a condvar that it
> didn't initialize! Ugh, this is the very reason why I dislike C...
Oops... Sorry, was blowing through the vmwgfx code a little
> Date: Sun, 23 Jul 2023 22:57:14 +0900
> From: PHO
>
> On 7/23/23 21:24, Taylor R Campbell wrote:
> > Why can't the loop just use dma_fence_get_rcu and dma_fence_put?
> >
> > Might need to release and reacquire the lock around dma_fence_put.
>
> I tried bu
> Date: Sun, 23 Jul 2023 12:36:10 +0900
> From: PHO
>
> This:
> https://github.com/depressed-pho/netbsd-src/blob/91daa67f17222da355d3fddd6fa849c786d9c545/sys/external/bsd/drm2/dist/drm/vmwgfx/vmwgfx_fence.c#L45
>
> and this:
>
> Date: Sun, 23 Jul 2023 00:47:39 +0900
> From: PHO
>
> On 7/22/23 22:23, Taylor R Campbell wrote:
> > For that matter, do we even need a new allocator here? Can we just do
> > a new bus_dmamem_alloc/load for each one?
>
> Sure, but I fear that would degrade the p
> Date: Sat, 22 Jul 2023 17:14:11 +0200
> From: BERTRAND Joël
>
> I have rebuilt my tree, started and stopped altqd.
Excellent, thanks!
Can you either:
(a) send me a tarball of your altqd binary together with all the
shared libraries and .debug files that gdb mentioned, and together
> Date: Sat, 22 Jul 2023 21:52:40 +0900
> From: PHO
>
> Jul 17 00:52:34 netbsd-current /netbsd: [ 64017.6151161]
> vmw_fence_wait() at netbsd:vmw_fence_wait+0xdc
Just to confirm, what does `info line *(vmw_fence_wait+0xdc)' say in
gdb?
And, if you can get to the frame in gdb, what does gdb
> Date: Sat, 22 Jul 2023 21:52:40 +0900
> From: PHO
>
> >> cv_destroy(); // <-- Panics!
> >>
> >> It seldom panics on KASSERT(!cv_has_waiters(cv)) in cv_destroy() but not
> >> always. The panic seems to happen when cv_timedwait_sig() exits due to
> >> the timeout expiring before it gets
> Date: Sun, 16 Jul 2023 04:50:35 +0900
> From: PHO
>
> On 7/16/23 04:19, Taylor R Campbell wrote:
>
> > 1. Did you reimplement an allocator for the dma_pool_* API? Should it
> > use vmem(9) instead or can that not handle the requests that it
> >
> Date: Mon, 17 Jul 2023 12:57:42 +0900
> From: PHO
>
> While further testing my DRM/KMS vmwgfx driver patches by playing
> games/minetest from pkgsrc, I experienced inexplicable kernel panics on
> this code:
>
>
> Date: Wed, 19 Jul 2023 03:51:29 +
> From: David Holland
>
> On Tue, Jul 18, 2023 at 03:25:02PM -0700, Jason Thorpe wrote:
> > That *might* work in this particular case, but it would not work
> > for e.g. a cloning device where you get additional descriptors via
> > dup() or whatever.
>
> Date: Wed, 19 Jul 2023 15:36:48 +0200
> From: BERTRAND Joël
>
> Yesterday, I have done a mistake... ALTQD is running on one of my
> NetBSD server (this server routes rtp packets) and I have tried to
> reboot this machine... It was not possible: shutdown stalled on
> "Stopping altqd"
be worthwhile, but performance measurements for
this sort of thing constitute a rabbit hole that I probably won't find
the time to fall into for in the foreseeable future.
>From 494ce7f4bddb181a7de6e97aa461899926c8e761 Mon Sep 17 00:00:00 2001
From: Taylor R Campbell
Date: Thu, 13 Jul 2023 20
ting `struct foo' everywhere --
you can use `union foo' with a single anonymous struct member, and
it's one character shorter!)
>From 724e1b6101fd3d4397d34ac2678ec07aa2d3ba28 Mon Sep 17 00:00:00 2001
From: Taylor R Campbell
Date: Tue, 11 Jul 2023 09:57:54 +
Subject: [PATCH] style(5): Advise
> Date: Sun, 16 Jul 2023 01:12:48 +0900
> From: PHO
>
> I've been working on vmwgfx driver, a driver for VMware virtualized GPU.
> It was partly ported to NetBSD but wasn't buildable, and now it builds
> and actually works. (Thank you riastradh@, your prior work helped
> tremendously. I don't
> Date: Tue, 11 Jul 2023 19:50:19 -0700
> From: Jason Thorpe
>
> > On Jul 11, 2023, at 2:56 PM, Taylor R Campbell
> > wrote:
> >
> > I agree the keyword is ugly, and it's unfortunate that in order to
> > omit it we would have to use C++, but the u
> Date: Tue, 11 Jul 2023 15:36:08 -0700
> From: Phil Nelson
>
> I'm working on getting the iwlwifi driver for intel devices into
> the new wifi framework. In going over the files as named I see
> that there are multiple different files "xxx/tx.c" and "yyy/tx.c".
> Those names would both
ate: Tue, 11 Jul 2023 05:56:27 -0700
> From: Jason Thorpe
>
> > On Jul 11, 2023, at 3:17 AM, Taylor R Campbell wrote:
> >
> > If we used `struct bus_dma_tag *' instead, the forward declaration
> > could be `struct bus_dma_tag;' instead of having to pull in all of
&g
> Date: Tue, 11 Jul 2023 22:00:25 +0100
> From: Robert Swindells
>
> Linux has the kcmp(2) syscall, Mesa makes use of it.
>
> Do we want a version of the syscall?
Can you give any more details?
What is kcmp(2) useful for?
Is kcmp(2) a good design for that goal?
What does Mesa use kcmp(2)
.)
Objections?
>From 69dc9658454c8edce695630d2e1bc75db86c43eb Mon Sep 17 00:00:00 2001
From: Taylor R Campbell
Date: Tue, 11 Jul 2023 09:57:54 +
Subject: [PATCH] style(5): Prohibit new struct typedefs and explain why.
---
share/misc/style | 16 +++-
1 file changed, 15 insertions(+)
sys/lib/libc/sys/t_timerfd.c timerfd_block is intermittently failing
on the i386 test bed. I added some diagnostic prints to see exactly
what the timing failure is, which yielded:
t_timerfd.c:198: then=1368.605876566 now=1369.462708087 delta=0.856831521
On discussion with chs@, I realize that:
(a) you could just use uao_create(INT64_MAX - PAGE_SIZE), like tmpfs
does, and not bother with defining a uao_resize (just .pgo_put the
pages when you truncate and update the length under the lock);
but
(b) this is kind of duplicating the existing
> Date: Tue, 27 Jun 2023 16:27:34 -0400
> From: Theodore Preduta
>
> On 2023-06-26 20:03, Taylor R Campbell wrote:
> > For a syscall, you should implement it in terms of uvm anonymous
> > objects:
>
> Is there a preexisting way to resize a uvm_object? Or do I need
> Date: Mon, 26 Jun 2023 18:13:17 -0400
> From: Theodore Preduta
>
> Is it possible to create a vnode for a regular file in a file system
> without linking the vnode to any directory, so that it disappears when
> all open file descriptors to it are closed? (As far as I can tell, this
> isn't
> Date: Wed, 31 May 2023 20:54:34 +
> From: Andrew Doran
>
> On Sat, Oct 29, 2022 at 02:42:27PM +0000, Taylor R Campbell wrote:
>
> > - Was the rationale migrating to kmem(9) written down or discussed
> > publicly anywhere?
>
> Some I know of are:
>
Looks like there are actually already two different drivers for some
kind of sd@spi, but they live under evbsh3 -- so, not sure if they're
actually specific to sh3 boards or what:
https://nxr.netbsd.org/xref/src/sys/arch/evbsh3/t_sh7706lan/scimci.c
> Date: Tue, 23 May 2023 22:54:13 -0700
> From: Phil Nelson
>
>I'm presuming that we'll need something in the dev/spi/files.spi,
> but haven't figured out what to say to get it to work. And I'm
> assuming there is a .c file that needs to implement the interface
> between the sdmmc and the
> Date: Fri, 19 May 2023 11:55:09 +0200
> From: BERTRAND Joël
>
> This morning, ccd0 (and of course dk5) are "locked". All tasks stall in
> uninterruptible state when they try to access to dk5:
>
> legendre# cd /var/squid/cache
> legendre# du -hs
> ^C^C^C^C^Cs^C^C^C
Can you show the
> Date: Thu, 18 May 2023 22:55:04 +0200
> From: BERTRAND Joël
>
> Both wd0 and wd1 have been tested and don't have smart alerts. When I
> restart this server, I can see a message just before system reboots. If
> I remember, this message indicates that ccd0 is removed from system
> before
> Date: Wed, 10 May 2023 01:08:27 +
> From: Taylor R Campbell
>
> I propose to add new config_*_acquire/release functions: [...]
Updated patch so that the legacy config_* operations require the
caller to hold the kernel lock, while the new config_*_acquire/release
ones do n
If we think too hard about making this precise we'll wind up with
names like uiosimulateviolatingnocloningtheorem and uiowavecollapse.
uioskip serves either to discard data without consuming it, or to
advance the pointer after using the data with uiopeek.
peek is in contrast to get, like
> Date: Tue, 9 May 2023 23:03:27 -0400 (EDT)
> From: Mouse
>
> > (In general, erroring in I/O is a whole additional can of worms; it's
> > wrong to not report back however much work happened before the error
> > when it can't be undone, but also impossible to both report work and
> > raise an
config_attach_pseudo_acquire as the aux argument to the .ca_attach
function.
>From 066f934f6c0dd3c3884b827d1b78f02c4b50fc3e Mon Sep 17 00:00:00 2001
From: Taylor R Campbell
Date: Fri, 26 Aug 2022 10:35:08 +
Subject: [PATCH] autoconf(9): New functions for referenced attach/detach.
New functio
tl;dr
I propose adding uiopeek(buf, n, uio) and uioskip(n, uio) which
together are equivalent to successful uiomove(buf, n, uio).
This allows a driver to separately:
1. transfer data into a buffer (uiopeek) first, and then
2. advance the uio (uioskip) only after determining how much of the
> Date: Fri, 28 Apr 2023 11:32:44 +0200
> From: Edgar Fuß
>
> But we still don't know what led to the disconnect. Does the
> ohci0: 1 scheduling overruns
> give any clue?
Suggests a hardware problem to me.
According to the OHCI spec, this can happen if the driver has
committed too much
> Date: Thu, 27 Apr 2023 21:39:38 +0200
> From: Edgar Fuß
>
> > list *(ugen_get_cdesc+0xb1)
> 0x802f8f2e is in ugen_get_cdesc (/usr/src-8/sys/dev/usb/ugen.c:1376).
> 1371usb_config_descriptor_t *cdesc, *tdesc, cdescr;
> 1372int len;
> 1373usbd_status
> Date: Thu, 27 Apr 2023 13:10:19 +0200
> From: Timo Buhrmester
>
> | uvm_fault(0xfe82574c2458, 0x0, 1) -> e
> | fatal page fault in supervisor mode
> | trap type 6 code 0 rip 0x802f627e cs 0x8 rflags 0x10246 cr2 0x2
> ilevel 6 (NB: could be ilevel 0 as well) rsp 0x80013f482c10
Last year hannken@ changed fstrans(9) to use a hash table mapping
struct mount pointers to fstrans info, in order to fix a crash found
by syzkaller arising from a race between fstrans_start(vp->v_mount)
and vgone(vp):
https://syzkaller.appspot.com/bug?extid=54dc9ac0804a97b59bc6
> Date: Wed, 22 Mar 2023 12:21:41 -0700
> From: Brian Buhrow
>
> Both machines are running a single FFSV1 root filesystem and one
> directory has over 32,000 files in it. This directory is
> continually appended and, once a day, files are purged from it.
> When the panic occurs, the systems
> Date: Thu, 30 Mar 2023 08:22:45 -0400 (EDT)
> From: Mouse
>
> I actually ran into a case where this distinction caused trouble. I
> have a program that uses curses for output but wants to do non-blocking
> input. So I set stdin nonblocking and threw fd 0 into the poll() loop.
>
> But, in
> Date: Wed, 22 Mar 2023 17:18:45 +0100
> From: Manuel Bouyer
>
> I did this but it didn't unblock the python process. It did tell me:
> #rndctl -L /tmp/foo
> rndctl: no entropy in seed
> Also I had a /var/db/entropy-file, but maybe without entropy.
> But /tmp/foo should have some, it was
> Date: Wed, 22 Mar 2023 16:33:55 +0100
> From: Manuel Bouyer
>
> I upgraded a Xen guest from -7 to 10, and run into:
> entropy: pid 17200 (python) blocking due to lack of entropy
>
> how do I get out of this ? I tried various things with rndctl, including
> copying /var/db/entropy-file from
file defining it and the .c
files using it.
Pretty simple. Any objections?
>From f3e8932d02d1c80582de05cc0869aa3693ec339c Mon Sep 17 00:00:00 2001
From: Taylor R Campbell
Date: Wed, 15 Mar 2023 10:47:47 +
Subject: [PATCH] style(5): Forbid extern in .c files.
---
share/misc/style | 6 --
> Date: Wed, 8 Mar 2023 08:58:47 -0500 (EST)
> From: Mouse
>
> Ugh, I hate using build.sh for small things like individual kernels.
> It always (well, far too often, at least) insists on rebuilding make,
> which takes significant time on some machines, like my shark, and
> requires extra
> Date: Tue, 7 Mar 2023 18:32:46 -0500 (EST)
> From: Mouse
>
> This completed apparently normally, reporting the build directory and
> telling me to remember to make depend. I then went to ~/kbuild/GEN91
> and ran make depend && make. It failed fast - no more than a second or
> two - with
>
>
> Date: Sun, 5 Mar 2023 21:20:55 +0300
> From: Valery Ushakov
>
> We don't seem to have(9) a man page that lists all __HAVE_* macros
> that a port may provide. E.g.
>
> $ apropos -M '"__HAVE_PREEMPTION"'
> cpu_need_resched (9)context switch notification
>
> but
>
> $ apropos -M
> Date: Fri, 24 Feb 2023 23:21:35 -0800
> From: Jeff Frasca
>
> Ok, first off, the FP code I've run into is in the Display
> Core code, specifically in:
> sys/external/bsd/drm2/dist/drm/amd/display/dc/calcs/amdgpu_dcn_calcs.c
> It's all SIMD code operating on xmmN registers. To get to
> this
> Date: Wed, 22 Feb 2023 12:57:24 +
> From: Taylor R Campbell
>
> I propose to delete current use of __HAVE_ATOMIC_AS_MEMBAR because it
> is a bad API, and replace it by one of two options:
>
> (a) Add membar_release_preatomic and membar_acq
Questions about rwlock(9) memory ordering semantics:
1. Is rw_tryupgrade an acquire operation, so that all prior reader
critical sections happen-before anything sequenced after it?
Or does it only order stores issued by the caller, while loads in
the following write section can be
I propose to delete current use of __HAVE_ATOMIC_AS_MEMBAR because it
is a bad API, and replace it by one of two options:
(a) Add membar_release_preatomic and membar_acquire_postatomic: noop
if __HAVE_ATOMIC_AS_MEMBAR, alias for membar_release/acquire
otherwise.
(Maybe also add
> Date: Wed, 1 Feb 2023 23:24:53 -0800
> From: Brian Buhrow
>
> I'm runing NetBSD-9.99.77, which predates the pr kern/56962
> fixes. Is this behavior expected prior to the fix for this bug or
> am I running into something else?
I don't recall the details and don't have time to think
> Date: Sun, 29 Jan 2023 16:44:08 +0100
> From: tlaro...@polynum.com
>
> I will look (silently) to dev/pci/radeonfb.c to understand better the
> logics and try to find if there is a way to obtain a better console
> display.
FYI, dev/pci/radeonfb.c is the legacy radeon framebuffer driver only
for
rampling
> or breaking other guests. I'm happy to have a conversation with any
> NetBSD devs looking to update nvmm to support these features.
Thanks -- do you have an image we can run in a guest to test the
potential trampling?
>From ae344260c6d354438c6f8b08042ac8776875a462 Mon Sep 17 00:00:
> Date: Mon, 23 Jan 2023 13:29:07 +
> From: Taylor R Campbell
>
> The attached patch series largely eliminates condiitonals on
> __HAVE_ATOMIC_AS_MEMBAR by introducing wrappers
> membar_release_preatomic and membar_acquire_postatomic with the
> obvious definitions.
S
efe Mon Sep 17 00:00:00 2001
From: Taylor R Campbell
Date: Sun, 22 Jan 2023 18:45:19 +
Subject: [PATCH] npf(9): Another comment tweak to match upstream.
No functional change.
---
sys/net/npf/npf_tableset.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sys/net/
> Date: Mon, 23 Jan 2023 09:33:45 +0100
> From: tlaro...@polynum.com
>
> Le Mon, Jan 23, 2023 at 05:17:29AM +0700, Robert Elz a écrit :
> > Date:Sun, 22 Jan 2023 20:27:24 +0100
> > From:tlaro...@polynum.com
> > Message-ID:
> >
> >
> > | +Zone kernel: Available
Try the attached patch?
>From 89b144a95e698df4a844157c55b70cef488548ba Mon Sep 17 00:00:00 2001
From: Taylor R Campbell
Date: Sun, 22 Jan 2023 15:56:55 +
Subject: [PATCH] npf(9): Don't hold table lock across copyout.
Instead, block npf_table_gc during copyout of anything that might be
G
> Date: Wed, 18 Jan 2023 13:33:37 +0100
> From: Reinoud Zandijk
>
> Oops, wrong list, sorry. Although its supposed to compile on NetBSD 9.3 I
> still wonder if this really is a good idea.
Should be fine as long as the code is built with a standard feature
macro like _POSIX_C_SOURCE=200809L, and
> Date: Wed, 11 Jan 2023 13:05:04 -0500
> From: Brad Spencer
>
> I think I know what the root problem is for kern/57136 and
> kern/57181... a couple of PRs I wrote about problems I have been having
> with NPF, but I am not at all sure that my solution is correct.
These are the same issue. Your
> Date: Wed, 11 Jan 2023 08:30:20 +
> From: Emmanuel Dreyfus
>
> An interesting problem on an all-in-one HP PC. Booting
> NetBSD-10.0_BETA/amd64 (or prior versions) works fine until the
> kernel starts displaying its messages. At that point the screen
> turns dark.
Do you have serial
> Date: Fri, 6 Jan 2023 15:55:37 +0100
> From: BERTRAND Joël
>
> /etc/rc.d/altqd onestop doesn't stop altqd. top shows that altqd
> remains on CPU (and takes 100% of a CPU).
>
> gdb -p 1342 (altq) returns that altqd stalls in qop_clear() function (I
> don't have altdq sources on this
The acpiwmibus interface attribute should be handled by combining the
definition in files.wmi with the logic in wmi_acpi.c to call
config_found:
# ACPI WMI mapper
device acpiwmi: acpiwmibus
attach acpiwmi at acpinodebus
filedev/acpi/wmi/wmi_acpi.c acpiwmi
/* acpi_wmi_attach */
> Date: Sat, 10 Dec 2022 02:42:05 +0300
> From: Valery Ushakov
>
> So the culprit is KDTRACE_HOOKS in sys/arch/x86/x86/intr.c
>
> revision 1.163
> date: 2022-10-29 16:59:04 +0300; author: riastradh; state: Exp; lines:
> +38 -2; commitid: w28zVvYhMCIOsCZD;
> x86: Add dtrace probes for
> Date: Tue, 29 Nov 2022 02:11:15 +
> From: Bruno Melo
>
> and then the crash happens in my bus_space_unmap(). Please, do you
> have any idea what could be the problem or how i can investigate it?
> Picture attached and code below:
There's only one call to bus_space_unmap in your driver.
> Date: Sat, 19 Nov 2022 15:39:55 +0100
> From: BERTRAND Joël
>
> I don't understand how modules really work. For example :
> legendre# modstat | grep iscsi
> iscsi driver builtin -0 - -
>
> If I understand, this module is loaded from kernel,
> Date: Fri, 18 Nov 2022 09:13:06 -0800
> From: bch
>
> On Fri, Nov 18, 2022 at 03:31 Taylor R Campbell <
> campbell+netbsd-tech-k...@mumble.net> wrote:
>
> > > Date: Fri, 18 Nov 2022 10:06:19 +
> > > From: nia
> > >
> >
> Date: Fri, 18 Nov 2022 10:06:19 +
> From: nia
>
> This is neat, thanks for the work. Do we need a kernel
> compiled with any specific options to make the DTrace
> probes active?
Just `options KDTRACE_HOOKS', which is on by default in x86 and arm
GENERIC kernels. dtrace itself, and the
Too much of the kernel still runs with the kernel lock, which is bad
for performance -- and especially for interactive system
responsiveness, since most of wscons including keyboard and mouse
input still use the kernel lock. On single-CPU systems, the same
problem arises with interrupt latency on
Starting 10-15 years ago, the NetBSD kernel has been slowly migrating
from the traditional BSD malloc(9) API to the Solaris-inspired kmem(9)
API.
The main differences between the interfaces are:
malloc(9) kmem(9)
- ---
. attribution by
> Date: Sat, 15 Oct 2022 19:21:35 +
> From: Taylor R Campbell
>
> #pragma once
> [...]
> How reliable/consistent is toolchain support for it? Is it worth
> adopting or is the benefit negligible over continuing to use
> traditional #include guards? Likely probl
> Date: Tue, 4 Oct 2022 14:08:18 +
> From: Emmanuel Dreyfus
>
> I follow up here after getting no success at
> http://mail-index.netbsd.org/port-xen/2022/10/03/msg010258.html
>
> Applying the change below to netbsd-9 branch would work around
> the problem. Any opinion?
> [...]
> +#ifndef
[bcc tech-userlevel tech-toolchain, followups on tech-kern]
Traditionally to avoid problems with repeated inclusion of a header
file, you put #include guards around it, say in sys/dev/foo.h:
#ifndef _SYS_DEV_FOO_H_
#define _SYS_DEV_FOO_H_
...
#endif /* _SYS_DEV_FOO_H_ */
With newer compilers
> Date: Tue, 11 Oct 2022 16:50:17 +0200
> From: Edgar Fuß
>
> void
> mpii_start(struct mpii_softc *sc, struct mpii_ccb *ccb)
> {
> struct mpii_request_header *rhp;
> struct mpii_request_descr descr;
> #if defined(__LP64__) && 0
> u_long *rdp
> Date: Sat, 8 Oct 2022 10:58:58 -0500
> From: Mario Campos
>
> I ran a SAST tool, CodeQL, against trunk and found a couple of
> instances (below) where the 16-bit integer `i` is compared to the
> 32-bit integer `max_rx_queues` or `max_tx_queues` in ixg(4). If
> `max_rx_queues` (or
/constty bugs early
before you need those diagnostics for something else!
>From b1dac0b91583b768a457ae946751e7c69c4554a1 Mon Sep 17 00:00:00 2001
From: Taylor R Campbell
Date: Sat, 1 Oct 2022 14:00:43 +
Subject: [PATCH 1/5] cons(9): New function cn_set_tab.
Increment of progress toward eliminat
1 - 100 of 691 matches
Mail list logo
