Re: UVMHIST logs

On Mon, Jul 15, 2024 at 09:42:31 +0200, J. Hannken-Illjes wrote: > No UVMHIST involved. > > Seems to originate from a printf() without "\n" at sys/uvm/uvm_map.c > function uvm_findspace_invariants() at line 1795. Ah, thanks... I looked at the function name and uvm_map_findspace starts with a

UVMHIST logs

I've just got a long message in my dmesg: ...e24 uoffset=0 align=0 flags=0x101 entry=0x8f7f2df8 (uvm_map_findspace line 2011)map=0x8ee29e80 hint=0x7def orig_hint=0x76fc3000 length=0x1000 uobj=0x8fdd0e24 uoffset=0 align=0 flags=0x101 entry=0x8f7f2df8 (uvm_map_findspace line

Re: poll(): IN/OUT vs {RD,WR}NORM

On Tue, May 28, 2024 at 02:33:48 +, David Holland wrote: > anything other than the same set of vague descriptions we had in the > older poll(2). poll(2) is ... ok, I'm not even sure what adjective to use here. I had to write some async TCP poll code that needed to work on Linux, Solaris and

Re: [RFC] new APIs to use wskbd(4) input on non-wsdisplayttydevices

On Mon, Apr 08, 2024 at 23:27:11 +0900, Izumi Tsutsui wrote: > macallan@ wrote: [...] > > Oh, so it's an entire terminal emulation, not just something that lets > > you draw characters? > > Ah, maybe I see misunderstandings among us. > > In sgimips crmfb and newport cases, a putchar() function

Re: [RFC] new APIs to use wskbd(4) input on non-wsdisplay tty devices

On Sat, Apr 06, 2024 at 23:56:27 +0900, Izumi Tsutsui wrote: > To support "text only" framebuffer console, we can use putchar > functions provided by the firmware PROM. Is that a console-typewriter--like device without addressable cursor terminal emulation? Can you use wsemul_dumb to avoid

Re: Change max ttys from 8 to 12?

On Tue, Dec 19, 2023 at 11:10:52 +0100, Dan-Simon Myrland wrote: > 2) Make a custom kernel with the option WSDISPLAY_DEFAULTSCREENS=12 Why? WSDISPLAY_DEFAULTSCREENS is the number of screens pre-created by the kernel, but you can always create as many as you need (subject to

Re: how do I preset ddb's LINES to zero

On Fri, Dec 15, 2023 at 11:19:39 -0500, Andrew Cagney wrote: > I've the stock 10.0 boot.iso booting within a KVM based test > framework. I'd like to set things up so that should there be a panic, > it dumps registers et.al., without stopping half way waiting for > someone to hit the space bar

Re: [RFC] userconf(4) modification

On Thu, Nov 02, 2023 at 16:29:42 +0100, tlaro...@kergis.com wrote: > You will find attached the man page in order to be able to comment > about the proposed new syntax---supplementary syntax: it does not > replace the "legacy" one. The man page is super-confusing. Someone who needs to use

Re: Testing Emulation Syscalls

On Tue, Aug 01, 2023 at 12:39:46 +0200, Martin Husemann wrote: > On Tue, Aug 01, 2023 at 01:34:54PM +0300, Valery Ushakov wrote: > > As for testing emulated syscalls - can we solve this problem with a > > bit of elf branding to convince the kernel to start the binary under > &g

Re: Testing Emulation Syscalls

On Tue, Aug 01, 2023 at 08:16:50 +0200, Martin Husemann wrote: > On Mon, Jul 31, 2023 at 05:03:48PM -0400, Theodore Preduta wrote: > > One idea (mentioned in the original thread) would be to introduce a > > syscall along the lines of > > > > int emul_syscall(const char *emul_name, int

Re: [PATCH] style(5): No struct typedefs

On Tue, Jul 11, 2023 at 05:56:27 -0700, Jason Thorpe wrote: > > 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 > > sys/bus.h, _and_ the C

Re: [PATCH] style(5): No struct typedefs

On Tue, Jul 11, 2023 at 10:17:24 +, Taylor R Campbell wrote: > I propose the attached change to KNF style(5) to advise against > typedefs for structs or unions, or pointers to them. [...] > (Typedefs for integer, function, and function pointer types are not > covered by this advice.) Yes,

Re: PROPOSAL: Split uiomove into uiopeek, uioskip

On Tue, May 09, 2023 at 14:33:26 -0700, Jason Thorpe wrote: > I'm not a fan of uioskip() as a name - I think uioadvance() would be > better. Skip implies, to my brain, that the data is being thrown > away (even if you're already consumed it). I agree. "skip" seem to have wrong connotations

Re: building 9.1 kernel with /usr/src elsewhere?

On Wed, Mar 08, 2023 at 15:22:11 +1100, matthew green wrote: > > 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 -

Re: The list of __HAVE macros

On Sun, Mar 05, 2023 at 18:48:08 +, Taylor R Campbell wrote: > > I think it might be a good idea to document the list in one place with > > xrefs to the relevant section 9 pages (and to document the options > > there too, e.g. __HAVE_SIMPLE_MUTEXES in mutex(9)). > > I agree! Want to draft a

The list of __HAVE macros

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 '"__HAVE_SIMPLE_MUTEXES"' apropos: No relevant results obtained. Please make sure

Re: erlang -> asmjit -> mremap questions/bugs

On Wed, Mar 01, 2023 at 15:29:27 +0100, Thomas Klausner wrote: > It seems the problem is that mmap() in the mremap(2) man page example > (which was used to implement the asmjit version) is not using > MAP_SHARED. > > - I'd like to add MAP_SHARED in the mmap() call in the mremap(2) man > page

Re: Finding the slot in the ioconf table a module attaches to?

On Wed, Feb 01, 2023 at 11:14:42 -0800, Brian Buhrow wrote: > hello. Okay. That is helpful. Passing -1 in as the cmajor > number to the devsw_attach() function does, in fact, assign a > reasonable major number which seems to work. I use the > cdevsw_lookup_major() function to retrieve

Re: Finding the slot in the ioconf table a module attaches to?

On Wed, Feb 01, 2023 at 08:27:57 -0500, Brad Spencer wrote: > To add a bit... generally I have just added an entry to one of the > "major" files in sys/conf. However, I have noticed that in order for > the module to be able to use it, after the major file edit, I had to > rebuild the kernel as

Re: Finding the slot in the ioconf table a module attaches to?

On Wed, Feb 01, 2023 at 08:28:35 +, RVP wrote: > /usr/src/sys/modules/examples/readhappy/readhappy.c > /usr/src/sys/conf/majors* Hmm, lots of real modules seems to use config_init_component() that is not documented at all in the section 9. Can someone please write a man page for that? I'll

Re: Add five new escape sequences to wscons

On Mon, Jan 16, 2023 at 15:10:06 -0300, Crystal Kolipe wrote: > On Mon, Jan 16, 2023 at 08:20:35PM +0300, Valery Ushakov wrote: > > On Mon, Jan 16, 2023 at 09:18:53 -0300, Crystal Kolipe wrote: > > > > > It's useful, because these sequences correspond to the terminfo >

Re: Add five new escape sequences to wscons

On Mon, Jan 16, 2023 at 09:18:53 -0300, Crystal Kolipe wrote: > It's useful, because these sequences correspond to the terminfo > capabilities rin, indn, vpa, hpa, and cbt as defined in the xterm > terminfo entry. With these sequences implemented, it becomes > slightly more practical to set

Re: KSYMS_CLOSEST

On Sun, Dec 25, 2022 at 17:41:10 +0100, Anders Magnusson wrote: > Den 2022-12-25 kl. 17:25, skrev Valery Ushakov: > > On Sun, Dec 25, 2022 at 15:42:47 +0100, Anders Magnusson wrote: > > > > > Den 2022-12-25 kl. 13:43, skrev Valery Ushakov: > > > > On Sun, De

Re: KSYMS_CLOSEST

On Sun, Dec 25, 2022 at 15:42:47 +0100, Anders Magnusson wrote: > Den 2022-12-25 kl. 13:43, skrev Valery Ushakov: > > On Sun, Dec 25, 2022 at 09:20:49 +0100, Anders Magnusson wrote: > > > > > IIRC it was to match the ddb "sift" command. > > I'm not sur

Re: KSYMS_CLOSEST

, or shall we deprecate/delete it? > Den 2022-12-25 kl. 01:01, skrev Valery Ushakov: > > KSYMS_CLOSEST flag is documented as "Nearest lower match". However as > > far as I can tell nothing in ksyms code ever pays attention to this > > flag and it's not clear to m

KSYMS_CLOSEST

KSYMS_CLOSEST flag is documented as "Nearest lower match". However as far as I can tell nothing in ksyms code ever pays attention to this flag and it's not clear to me what meaning one can ascribe to the set of flags that doesn't have KSYMS_CLOSEST set. Ragge, do you remember what did you have

Re: symbol lookup in ddb - bad heuristic

On Sun, Dec 18, 2022 at 09:38:14 -0800, Chuck Silvers wrote: > > May be the hack need to be applied only with a new special flag, say, > > KSYMS_RET? Then we can define separate DB_STGY_PROC (no heuristic) > > and DB_STGY_RET (with the heuristic). > > > > The downside is that all MD

Re: i386: 9.99.108 traps booting on VirtualBox

On Mon, Dec 12, 2022 at 23:31:06 +0300, Valery Ushakov wrote: > > > With KDTRACE_HOOKS enabled (modulo clockintr hack) and the serial > > > console (for debugging) I see the system stuck on console output when > > > rc runs. It gets unstuck on a com int

Re: i386: 9.99.108 traps booting on VirtualBox

On Mon, Dec 12, 2022 at 20:12:57 +, Taylor R Campbell wrote: > Annoying... We really shouldn't abuse function prototypes like this: > according to the prototype, what I did with intr_kdtrace_wrapper is > correct. Right, we decieved the compiler and the compiler was like, ok, boomer... > I

Re: symbol lookup in ddb - bad heuristic

On Sat, Dec 10, 2022 at 01:03:06 +0300, Valery Ushakov wrote: > That causes breakpoints on a function entry to be misreported: Actually it's more than that. The corresponding MD change in i386 db_frame_info that applies the same heuristic causes another side effect. With the heuristic I

Re: symbol lookup in ddb - bad heuristic

On Sat, Dec 10, 2022 at 01:03:06 +0300, Valery Ushakov wrote: > KSYMS_RET? Then we can define separate DB_STGY_PROC (no heuristic) > and DB_STGY_RET (with the heuristic). > > The downside is that all MD db_stack_trace_print functions need to be > adjusted, but it actually mak

Re: i386: 9.99.108 traps booting on VirtualBox

[ATTN: riastradh] On Fri, Dec 09, 2022 at 02:59:12 +0300, Valery Ushakov wrote: > [reposting from current-users] > > On Wed, Nov 30, 2022 at 13:05:52 +0300, Valery Ushakov wrote: > > > I tried to upgrade a 32-bit VBox VM from 9.99.99 to .107 and the > > kernel from

symbol lookup in ddb - bad heuristic

db_printsym has the following heuristic: revision 1.68 date: 2021-12-13 04:25:29 +0300; author: chs; state: Exp; lines: +16 -2; commitid: MT9cIBmUIZU1AqkD; ddb: fix function names of "noreturn" functions in stack traces. when looking up function names for stack traces (where the

i386: 9.99.108 traps booting on VirtualBox

[reposting from current-users] On Wed, Nov 30, 2022 at 13:05:52 +0300, Valery Ushakov wrote: > 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. Tried .108 and it crashes the same with: > boot netbsd.new 219265

Re: Limiting malloc to the low 2GB?

On Mon, Nov 28, 2022 at 23:22:08 +, RVP wrote: > On Tue, 29 Nov 2022, Valery Ushakov wrote: > > > Turns out you can use MALLOC_CONF="dss:primary" to make (the new) > > jemalloc prefer sbrk(2). > > Yes, I saw that, but, I wasn't sure if that setting meant a

Re: Limiting malloc to the low 2GB?

On Mon, Nov 28, 2022 at 21:45:40 +, RVP wrote: > On Mon, 28 Nov 2022, Valery Ushakov wrote: > > > Do we have a way to tell malloc on a 32-bit system to allocate memory > > only below the 2GB boundary (on i386, including when run under amd64)? > > I'm trying

Limiting malloc to the low 2GB?

Do we have a way to tell malloc on a 32-bit system to allocate memory only below the 2GB boundary (on i386, including when run under amd64)? I'm trying to port a(n old) program that wants to use the sign bit for its internal purposes. I guess one option would be to prevent malloc from using mmap

Re: Module autounload proposal: opt-in, not opt-out

On Sun, Aug 07, 2022 at 23:08:47 +, Taylor R Campbell wrote: > Currently there are many types of modules that are autoloaded from > open-ended patterns: Our current auto-load policy is a bit too enthusiastic, IMHO. E.g. an "unknown" ioctl used to (probably still does) trigger autoload of

Re: userconf question

On Fri, Aug 05, 2022 at 07:35:17 +, Emmanuel Dreyfus wrote: > menu=Boot normally:rndseed /var/db/entropy-file;boot > menu=Drop to boot prompt:prompt > default=1 > timeout=3 > userconf=disable atabus0 > clear=1 > > But atabus0 is still configured, and wd0 still breaks the boot with >

Re: Proposal: Deprecate (or rename) extsrc/

On Fri, Jan 07, 2022 at 12:47:53 +1100, Luke Mewburn wrote: > The "extsrc/" tree was added in late 2009. > Nothing in tree uses "extsrc/"; it's a placeholder for third-party > vendors to hook into the build for their own extensions. > There's no reason a vendor can't just integrate into the build

Re: wsvt25 backspace key should match terminfo definition

On Tue, Nov 23, 2021 at 18:37:19 -0500, Greg Troxel wrote: > Valery Ushakov writes: > > > vt52 is different. I never used a real vt52 or a clone, but the > > manual at vt100.net gives the following picture: > > > > https://vt100.net/docs/vt52-mm/figure3-1.ht

Re: wsvt25 backspace key should match terminfo definition

On Tue, Nov 23, 2021 at 19:23:30 +0100, Johnny Billquist wrote: > > But somehow the official terminfo database has kbs=^H for vt220! > > Which is wrong. Exactly. > >kbs=^?, > > Which I think it should be. Amen! (unironically) :) -uwe

Re: wsvt25 backspace key should match terminfo definition

On Tue, Nov 23, 2021 at 09:22:43 -0500, Greg Troxel wrote: > Valery Ushakov writes: > > > On Tue, Nov 23, 2021 at 00:01:40 +, RVP wrote: > > > >> On Tue, 23 Nov 2021, Johnny Billquist wrote: > >> > >> > If something pretends to be a VT

Re: wsvt25 backspace key should match terminfo definition

On Tue, Nov 23, 2021 at 00:01:40 +, RVP wrote: > On Tue, 23 Nov 2021, Johnny Billquist wrote: > > > If something pretends to be a VT220, then the key that deletes > > characters to the left should send DEL, not BS... > > Just saying... > > That's fine with me too. As long as things are

Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl

On Wed, Oct 27, 2021 at 20:59:12 -0700, Jason Thorpe wrote: > > On Oct 27, 2021, at 4:01 PM, Jason Thorpe wrote: > > > > > >> On Oct 27, 2021, at 3:44 PM, Valery Ushakov wrote: > >> > >> On Wed, Oct 27, 2021 at 07:50:55 -0700, Jason Thorpe

Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl

On Wed, Oct 27, 2021 at 07:50:55 -0700, Jason Thorpe wrote: > > On Oct 18, 2021, at 9:41 AM, John Marino (NetBSD) wrote: > > > > yes, it sounds like a __in_signal_trampoline function would work for > > the GCC unwind, and I would think it would work for GDB as well. > > Ok, I have implemented

Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl

On Mon, Oct 18, 2021 at 10:41:48 -0500, John Marino (NetBSD) wrote: > How we did it with libc before is shown in the netbsd-unwind.h link in > the original post. This technique looks for __sigtramp_siginfo_2 > assembly code but no longer works. I don't know how to do this any > other way. GDB

Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl

On Fri, Oct 15, 2021 at 23:14:39 +0300, Valery Ushakov wrote: > On Fri, Oct 15, 2021 at 14:44:16 -0500, John Marino (NetBSD) wrote: > > > Is it possible for NetBSD to implement KERN_PROC_SIGTRAMP sysctl? > > It's been ages since I touched this area, but don't we have > per-

Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl

On Fri, Oct 15, 2021 at 14:44:16 -0500, John Marino (NetBSD) wrote: > Is it possible for NetBSD to implement KERN_PROC_SIGTRAMP sysctl? > > TLDR; > For several years, the GNAT Ada compiler has not been able to unwind a > stack containing a signal trampoline. The unwinder I wrote for gcc >

Re: Level for Unix-domain socket options

On Thu, Aug 05, 2021 at 22:55:12 +0200, Rhialto wrote: > On Thu 05 Aug 2021 at 13:22:55 +, nia wrote: > > The unix(4) man page incorrectly states: > > > > "A UNIX-domain socket supports two socket-level options for use with > > setsockopt(2) and getsockopt(2): [...]" > > > > In reality, the

Re: protect pmf from network drivers that don't provide if_stop

On Thu, Jul 01, 2021 at 06:47:08 -0300, Jared McNeill wrote: > Not really a fan of this as it doesn't protect other potential if_stop users > (and "temporary fix" rarely is..). How about something like this instead? I agree. If for whatever reason we really insist on if-specific stop, then just

Re: Inconsistencies in usage of "locators" argument to config (*ca_rescan)() functions

On Fri, Mar 26, 2021 at 13:18:16 -0700, Jason Thorpe wrote: > I think it may have been the terminology used by Chris Torek in his > paper on the new 4.4BSD device auto configuration framework [...]. > Sadly, that paper is somewhat hard to find, and I don't know if it > was ever actually

Re: checking for a closed socket

On Tue, Feb 02, 2021 at 19:20:22 +0100, Manuel Bouyer wrote: > I've been debugging an issue wuth Xen, where xenstored loops at 100% > CPU on poll(2). > after code analysis it's looping on closed Unix socket desriptors. > From what I understood the code expect poll(2) to return something >

enet(4) problem? (Was: NFS client performance problems)

TL;DR: looks like a problem in enet(4) On Fri, Dec 25, 2020 at 02:20:13 +0300, Valery Ushakov wrote: > I've stumbled into a weird performance problem with NFS client. I > have CompuLab's Utilite Pro (evbarm) machine running a very current > -current. It's connected to my Ubun

NFS client performance problems

I've stumbled into a weird performance problem with NFS client. I have CompuLab's Utilite Pro (evbarm) machine running a very current -current. It's connected to my Ubuntu laptop with Ethernet (direct cable link) and uses it as an NFS server to get e.g. pkgsrc tree and distfiles. The

Re: autoloading compat43 on tty ioctls

On Sat, Oct 10, 2020 at 11:49:47 -0700, Paul Goyette wrote: > True, but the way ioctl's are handled in kern/tty.c seems to auto-load > the compat_43 and compat_60 modules for _any_ unhandled ioctl. So if > you have an illegal/invalid ioctl it will autoload the modules, and then > unload them 10

Re: "Boot this kernel once" functionality? (amd64)

On Wed, Sep 16, 2020 at 12:20:57 +0200, Anthony Mallet wrote: > On Wednesday 16 Sep 2020, at 12:09, Martin Husemann wrote: > > This works fine on e.g. sparc*; I can do: shutdown -b netbsd.t -r > > now > > > > No state is modified on any disks, very convenient. > > Right, not changing any state

-.su file in kernel compile dir

Recent changes to record stack usage cause a file named -.su to be created (that refers assym.c). It plays tricks with targets like clean that refer to *.su -uwe

Re: Submitting a new module example

On Tue, Jun 02, 2020 at 00:02:29 +, bmelo wrote: > I have written a ddb_hello module example. You can found the patch here: > https://pastebin.com/WCUpRc0J > > Could it be imported in src even if there is a ddbping example, please? It's the same skeleton code that ddbping already demoes (a

Re: Rump makes the kernel problematically brittle

On Thu, Apr 02, 2020 at 23:29:55 +0300, Valery Ushakov wrote: > On Thu, Apr 02, 2020 at 16:15:30 -0400, Mouse wrote: > > > > http://www.fixup.fi/misc/rumpkernel-book/ > > > > That page I can look at fine, but when I try to fetch the PDF, I get a > > 403 Fo

Re: Rump makes the kernel problematically brittle

On Thu, Apr 02, 2020 at 16:15:30 -0400, Mouse wrote: > > http://www.fixup.fi/misc/rumpkernel-book/ > > That page I can look at fine, but when I try to fetch the PDF, I get a > 403 Forbidden. In case it helps anyone, the body says > > Code: AccessDenied > Message: Access Denied > RequestId:

Re: Rump makes the kernel problematically brittle

On Fri, Apr 03, 2020 at 02:23:31 +0700, Robert Elz wrote: > | Is this documented anywhere? > > You're putting documented and rump into the same thought space? http://www.fixup.fi/misc/rumpkernel-book/ -uwe

sys_ptrace_lwpstatus.c (Was: CVS commit: src/sys)

On Thu, Dec 26, 2019 at 08:52:39 +, Kamil Rytarowski wrote: > Module Name: src > Committed By: kamil > Date: Thu Dec 26 08:52:39 UTC 2019 > > Modified Files: > src/sys/kern: files.kern sys_ptrace_common.c > src/sys/sys: ptrace.h > Added Files: > src/sys/kern:

xc_barrier()

gcc 8 -Wcast-function-type (enabled by -Wextra that we do turn on for x86 ports and a few others) is not very happy about many function casts for nullop and friends in the kernel. A small portion of them is code that does xcall barrier with: uint64_t where; where =

Re: Proposal, again: Disable autoload of compat_xyz modules

On Fri, Sep 27, 2019 at 11:36:08 -, Christos Zoulas wrote: > >} I propose something very slightly different that can preserve the current > >} functionality with user action: > >} > >} 1. Remove them from standard kernels in architectures where modules are > >}supported. Users can add

Re: Proposal, again: Disable autoload of compat_xyz modules

On Fri, Sep 27, 2019 at 10:57:12 +0200, Jarom?r Dole?ek wrote: > Le jeu. 26 sept. 2019 ? 18:08, Manuel Bouyer a ?crit > : > > > > On Thu, Sep 26, 2019 at 05:10:01PM +0200, Maxime Villard wrote: > > > issues for a clearly marginal use case, and given the current general > >

Re: mknod(2) and POSIX

On Tue, Jun 18, 2019 at 17:22:14 +0200, Kamil Rytarowski wrote: > I wrote a patch to add support for it, but untested as currently the > kernel build is broken: > > http://netbsd.org/~kamil/patch-00128-posix-mknod.txt > > Independently, I have removed unused variable retval. > > If this patch

Re: mknod(2) and POSIX

On Tue, Jun 18, 2019 at 14:30:26 +0200, Jason Thorpe wrote: > > On Jun 18, 2019, at 2:25 PM, Jason Thorpe wrote: > > > >> On Jun 18, 2019, at 2:01 PM, Greg Troxel wrote: > >> > >> I realize mkfifo is preferred in our world, and POSIX says it is > >> preferred. But I believe we have a failure

Re: fork-the-syscall return semantics

On Sat, Feb 16, 2019 at 20:14:35 -0500, Mouse wrote: > In fork1(), in kern/kern_fork.c, there is code > > /* > * Return child pid to parent process, > * marking us as parent via retval[1]. > */ > if (retval != NULL) { > retval[0] =

Re: Help needed with understanding of config(1) debug output

On Thu, Sep 27, 2018 at 16:20:50 +0800, Paul Goyette wrote: > I've got a problem where something I've changed over the last six months > (or more) on the [pgoyette-compat] branch has broken the release build > for at least ``build.sh -m algor'' port. For some unknown reason it is > defining

Re: How to prevent a mutex being _enter()ed from being _destroy()ed?

On Sat, Aug 11, 2018 at 00:46:26 +0700, Robert Elz wrote: > Date:Fri, 10 Aug 2018 08:03:55 -0400 > From:Greg Troxel > Message-ID: > > | Ancient BSD tradition is not to explain these things :-( > > Older than that. Don't you remember > you are not

Old FFS triggers assertion in BUFRD()

I have found OpenWindows Version 3 CD in a drawer. The label claims "ISO 9660 format", but it's really an FFS image. I was able to mount it with a little tweak - ffs_superblock_validate() checked only fs_size, but this CD from 1991 only has fs_old_size (fix committed). The next hiccup I ran

Leaking kernel stack data in struct padding

On Wed, Jun 13, 2018 at 02:09:09 +, Valeriy E. Ushakov wrote: > Module Name: src > Committed By: uwe > Date: Wed Jun 13 02:09:09 UTC 2018 > > Modified Files: > src/sys/dev/wscons: wsevent.c > > Log Message: > wsevent_copyout_events50 - don't leak garbage from the kernel

Re: I would like to contribute to NetBSD

On Sat, Apr 07, 2018 at 18:43:29 -0700, Andy Ruhl wrote: > On Fri, Apr 6, 2018 at 7:31 AM, Narendra Kangralkar > wrote: > > Hello All, > > > > I found that NetBSD a supported guest OS under VirtualBox project is > > partially completed. I would like to work on this

Re: setting DDB_COMMANDONENTER="bt" by default

On Sat, Feb 17, 2018 at 08:35:32 +1100, matthew green wrote: > Valery Ushakov writes: > > On Thu, Feb 15, 2018 at 01:19:31 +, Sevan Janiyan wrote: > > > > > > I might/would suggest > > > > > > > >OPTIONS DDB_ONPANIC=2 > > >

Re: setting DDB_COMMANDONENTER="bt" by default

On Thu, Feb 15, 2018 at 02:11:07 +, Sevan Janiyan wrote: > On 02/15/18 01:23, Valery Ushakov wrote: > > As someone has already mentioned upthread, because printing a > > backtrace might cause another panic, so the default was selected to be > > on the safe(r) side. A

Re: setting DDB_COMMANDONENTER="bt" by default

On Thu, Feb 15, 2018 at 01:19:31 +, Sevan Janiyan wrote: > > I might/would suggest > > > >OPTIONS DDB_ONPANIC=2 > > clear, any reason not to have this as a default? (I'm going to sleep on it) As someone has already mentioned upthread, because printing a backtrace might cause another

Re: gcc: optimizations, and stack traces

[Summoning Krister] On Fri, Feb 09, 2018 at 11:23:17 +0100, Maxime Villard wrote: > There are also several cases where functions in the call tree can disappear > from the backtrace. In the following call tree: > > A -> B -> C -> D (and D panics) > > if, in B, GCC put the two

Re: gcc: optimizations, and stack traces

On Fri, Feb 09, 2018 at 11:38:47 +0100, Martin Husemann wrote: > On Fri, Feb 09, 2018 at 11:23:17AM +0100, Maxime Villard wrote: > > > When I spotted this several months ago (while developing Live > > Kernel ASLR), I tried to look for GCC options that say "optimize > > with -O2, but keep the

Re: Proposal to obsolete SYS_pipe

On Tue, Dec 26, 2017 at 01:29:42 +, Christos Zoulas wrote: > In article , > Kamil Rytarowski wrote: > >-=-=-=-=-=- > >-=-=-=-=-=- > > > >On 25.12.2017 17:43, Christos Zoulas wrote: > >> On Dec 25, 4:42pm, n...@gmx.com (Kamil

Re: Proposal to obsolete SYS_pipe

On Mon, Dec 25, 2017 at 16:37:43 +0100, Kamil Rytarowski wrote: > On 24.12.2017 22:25, Kamil Rytarowski wrote: > > > http://netbsd.org/~kamil/patch-00039-obsolete-SYS_pipe.txt > > I've extracted two patches from the above proposal. > > In these patches SYS_pipe is not marked COMPAT_80 and not

config vs. modules iconf files

[torn off of the original thread] On Fri, Dec 08, 2017 at 04:40:01 +0300, Valery Ushakov wrote: > Date: Fri, 8 Dec 2017 04:40:01 +0300 > From: Valery Ushakov <u...@stderr.spb.ru> > Subject: Re: Attaching to an attribute > To: tech-kern@netbsd.org > Mail-Followup-To:

Re: Attaching to an attribute

On Fri, Dec 08, 2017 at 04:29:49 +0300, Valery Ushakov wrote: > On Thu, Dec 07, 2017 at 23:07:47 +0300, Valery Ushakov wrote: > > > However config(1) instead of providing single wildcard parent spec > > seems to instantiate parent specs for all parents it's seen that carry

Re: Attaching to an attribute

On Thu, Dec 07, 2017 at 23:07:47 +0300, Valery Ushakov wrote: > However config(1) instead of providing single wildcard parent spec > seems to instantiate parent specs for all parents it's seen that carry > the attribute. Bah, my emacs has too many buffers. Apparently I was looking at t

Attaching to an attribute

Devices can be attached to an attribute, e.g. wsmouse* at wsmousedev? where potential parents declare to have that attribute, e.g. device ums: hid, wsmousedev and the autoconf code knows how to attach to the attribute only: static int cfparent_match(const device_t parent,

Re: amd64: kernel aslr support

On Sat, Oct 07, 2017 at 20:42:58 +0200, Maxime Villard wrote: > Le 04/10/2017 ? 21:00, Maxime Villard a ?crit : > > Here is a Kernel ASLR implementation for NetBSD-amd64. > > [...] > > Known issues: > > [...] > > * There are several redefinitions in the prekern headers. The way to remove > >

Re: Patching wscons_keydesc at runtime

On Fri, Aug 04, 2017 at 02:46:15 +0300, Valery Ushakov wrote: > Date: Fri, 4 Aug 2017 02:46:15 +0300 > From: Valery Ushakov <u...@stderr.spb.ru> > Subject: Re: Patching wscons_keydesc at runtime > To: tech-kern@netbsd.org > Mail-Followup-To: tech-kern@netbsd.org > > On

Re: Patching wscons_keydesc at runtime

On Fri, Aug 04, 2017 at 01:38:38 +0200, Emmanuel Dreyfus wrote: > Emmanuel Dreyfus wrote: > > > > Unfortunately this breaks hpcsh which initializes console very early > > > when malloc is not available, so when you boot with wscons the machine > > > wedges. > > > > > > I think

Re: Patching wscons_keydesc at runtime

On Fri, Aug 04, 2017 at 01:30:14 +0200, Emmanuel Dreyfus wrote: > Valery Ushakov <u...@stderr.spb.ru> wrote: > > > Unfortunately this breaks hpcsh which initializes console very early > > when malloc is not available, so when you boot with wscons the machine > >

Re: Patching wscons_keydesc at runtime

On Sat, Jun 10, 2017 at 05:18:16 +0200, Emmanuel Dreyfus wrote: > I managed to restore wscons keymaps by copying > hpckbd_keymapdata.keydesc into a malloc() buffer and changing the > hpckbd_keymapdata.keydesc to the new location, which is mapped > read/write. Unfortunately this breaks hpcsh

Wskbd constness (Was: Patching wscons_keydesc at runtime)

On Sat, Jun 10, 2017 at 05:18:16 +0200, Emmanuel Dreyfus wrote: > I just upgraded an HP Jornada 720 from NetBSD 2.0 to NetBSD 7.1, and > discovered the wscons keymaps were broken in the meantime: it is impossible to > change the keymap using wsconsctl encoding or wsconsctl map. Both commands >

Re: Adding ruminit(4)

On Wed, May 24, 2017 at 17:20:52 +, Christos Zoulas wrote: > Why not move the all the code into a single "ubulkdisable" or > something driver? Finally a thumb to use in-kernel Lua on? :) -uwe

Re: Cnmagic support for wscons

On Tue, Jan 17, 2017 at 11:55:52 +1100, Nathanial Sloss wrote: > On Tue, 17 Jan 2017 07:32:34 Valery Ushakov wrote: > > On Tue, Jan 17, 2017 at 04:26:48 +1100, Nathanial Sloss wrote: > > > On Mon, 16 Jan 2017 00:44:02 Valery Ushakov wrote: > > > > On Sun, Jan 15,

Re: Cnmagic support for wscons

On Tue, Jan 17, 2017 at 04:26:48 +1100, Nathanial Sloss wrote: > On Mon, 16 Jan 2017 00:44:02 Valery Ushakov wrote: > > On Sun, Jan 15, 2017 at 13:30:15 +0100, Martin Husemann wrote: > > > On Sun, Jan 15, 2017 at 01:59:06PM +1100, Nathanial Sloss wrote: > > > > Mapp

Re: Cnmagic support for wscons

On Sun, Jan 15, 2017 at 13:30:15 +0100, Martin Husemann wrote: > On Sun, Jan 15, 2017 at 01:59:06PM +1100, Nathanial Sloss wrote: > > > Mapping KS_Cmd_Debugger would also work but I'm unsure as to how > > to do this without using wskbd key sequences in the magic. > > I don't understand - if you

Re: Cnmagic support for wscons

On Sun, Jan 15, 2017 at 09:08:43 +1100, Nathanial Sloss wrote: > Please see: > > ftp://ftp.netbsd.org/pub/NetBSD/misc/nat/wscons.cnmagic.diff > > Also the original PR: > > http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=48360 > > The diff adds cnmagic support for wscons consoles. >

Re: ptrace(2) interface for hardware watchpoints (breakpoints)

On Thu, Dec 15, 2016 at 19:51:35 +0100, Kamil Rytarowski wrote: > On 15.12.2016 16:42, Valery Ushakov wrote: > > Again, you don't provide any details. What extra logic? Also, what > > are these few dozens of instructions you are talking about? I.e. what > > is that extr

Re: ptrace(2) interface for hardware watchpoints (breakpoints)

On Tue, Dec 13, 2016 at 18:16:04 +0100, Kamil Rytarowski wrote: > >> 4. Do not set watchpoints globally per process, limit them to > >> threads (LWP). [...] Adding process-wide management in the > >> ptrace(2) interface calls adds extra complexity that should be > >> pushed away to user-land

Re: ptrace(2) interface for hardware watchpoints (breakpoints)

On Tue, Dec 13, 2016 at 02:04:36 +0100, Kamil Rytarowski wrote: > The design is as follows: > > 1. Accessors through: > - PT_WRITE_WATCHPOINT - write new watchpoint's state (set, unset, ...), > - PT_READ_WATCHPOINT - read watchpoints's state, > - PT_COUNT_WATCHPOINT - receive the number of

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

On Tue, Nov 29, 2016 at 21:54:11 +, Valeriy E. Ushakov wrote: > Module Name: src > Committed By: uwe > Date: Tue Nov 29 21:54:11 UTC 2016 > > Modified Files: > src/sys/dev/pci: if_vioif.c > > Log Message: > vioif_start() - do not call virtio_enqueue_abort() after error from >

  1   2   >