re: [uvm_hotplug] Fixing the build of tests

> This is only the case if a real "larger physical page size" is = > available, of course, as opposed to simply clustering e.g. 4 4KiB = > physical pages into a 16KiB VM page. > > Another thing that would be interesting would be to bucket memory so = > that the allocator could easily request e.g.

re: [uvm_hotplug] Fixing the build of tests

> I believe the right thing to do would be to just fix the type in > uvmexp.npages to the correct type instead of adjusting the test > to accommodate it. What would be the consequences of this? > > Also, I hadn't realised that the tests aren't wired into the > build. They really should be.

re: [uvm_hotplug] Fixing the build of tests

semi-related, but perhaps a change to begin marking places we need to fix... > The reason for failure was the comparison between psize_t (which is > defined as unsigned log inside t_uvm_hotplug.c) and int resulting in a > sign compare error (-Werror=sign-compare). This was used to compare > the

re: pci_intr_alloc() vs pci_intr_establish() - retry type?

> This reminds me - how does a driver know if any kind of MSI support is > even available? it shouldn't need to. unless it has specific need to avoid or prefer a particular type of interrupt, the MD pci needs to deal with this. eg, whatever the pci_chipset_tag_t the driver attches with, should

re: Time accounting on statclock()

> For eg: if a clock interrupt from userland got deferred as pending, even > if it came in from userland (is this possible ?), because the current > spl level was at, say, SPL_HIGH, it now seems to be the case that the > system accounts for the delayed execution by charging the *entire* time >

re: Time to merge the pgoyette-compat branch (take two)

why bother keeping the monolithic compat module? i was expecting it to be replaced by this merge, not as an additional way to get the same thing. .mrg.

re: Time to merge the pgoyette-compat branch (take two)

> The original change from .a -> .o was made by maxv, in order to avoid > having to determine where a couple of support objects were needed, and > to avoid having to determine if there were any other such objects. By > changing from .a to .o method, maxv simply ensured that these support >

re: Time to merge the pgoyette-compat branch (take two)

Martin Husemann writes: > On Sat, Sep 08, 2018 at 02:19:41PM +1000, matthew green wrote: > > Greg Troxel writes: > > > I am just barely paying attention, but I think modules working well is > > > important, and also having minimal code for what's needed. So if mrg's &g

re: Time to merge the pgoyette-compat branch

> >> * Introduction of module "aliases". In addition to its own name, a > >>module can now provide alias names. This is useful for the > >>monolithic compat module, which now contains the functionality of > >>the many version-specific modules. If you load the monolithic module, > >>

re: Time to merge the pgoyette-compat branch

congrats getting this fixed up. i don't like the monolithic module we have currently ;-) > * Introduction of module "aliases". In addition to its own name, a >module can now provide alias names. This is useful for the >monolithic compat module, which now contains the functionality of >

re: 8.0 performance issue when running build.sh?

> > >> 100.002054 14.18 kernel_lock > > >> 47.43 846 6.72 kernel_lockfileassoc_file_delete+20 > > >> 23.73 188 3.36 kernel_lockintr_biglock_wrapper+16 > > >> 16.01 203 2.27 kernel_lockscsipi_adapter_request+63

re: Debugging DRM on a laptop?

co...@sdf.org writes: > Hi folks, > > we're working on a drmkms update. > I'm testing it on a Dell XPS 9550. It's a laptop with a Skylake CPU. > It has a power button. The power button powers off, not reboot. > This means the dmesg buffer gets wiped. > No serial console as far as I know. > > Now

re: CVS commit: src/sys/kern

Jason Thorpe writes: > > > > On Jul 1, 2018, at 2:48 AM, Martin Husemann wrote: > > > > I'd rather not have this at all - instead just drop the useless timestamps > > at boot time, they are useless here and make console output unreadable. > > > > They are fine after mountroot, but is there

re: ./build.sh -k feature request (was Re: GENERIC Kernel Build errors with -fsanitize=undefined option enabled)

why can't you just use "nbmake-$foo -k " instead of enabling an option that will lead to odd build issues and support requests. i'd really rather avoid this option in build.sh itself. .mrg.

re: Audio update pertaining to mixer devices and hw.driverN.multiuser

hi Nat, i object to the plan here. we should simply just use the file system to control this, like normal unix stuff. eg, ttyaction should chown the audio device to the console user or whatever the admin chooses. it should be possible for me to decide to make things as open or as closed as

re: Kernel module framework status?

John Nemeth writes: > On May 3, 10:54pm, Mouse wrote: > } > } > There is also the idea of having a module specify the device(s) > } > it handles by vendor:product > } > } Isn't that rather restrictive in what buses it permits supporting? > > I suppose that other types of identifiers

re: secmodel_securelevel(9) and machdep.svs.enabled

Maxime Villard writes: > Le 25/04/2018 à 19:47, Alexander Nasonov a écrit : > > Alexander Nasonov wrote: > >> Alexander Nasonov wrote: > >>> When securelevel is set, should be lock 1->0 change for > >>> machdep.svs.enabled (and possibly for other sysctls related > >>> to recent security

re: Is there a current known getrusage() problem (amd64)

this sounds like the timecounter goes backwards issue. for a long on the sparc port time we saw issues where getrusage() would return garbage (very large) values for times. after a lot of debugging, i tracked it down to the tc giving a lower value than it should have, without ever getting close

re: Fixing excessive shootdowns during FFS read (kern/53124) on x86 - emap, direct map

> 4GB of KVA; and in addition pmap_kernel will consume some KVA too. i386 for > example has only 4GB of ram and 4GB of KVA, so we'll just never add a direct > map there. note that it changes your direct map point, but, i386 GENERIC_PAE works fine for at least 16GB ram. it should work upto 64GB.

re: mmap implementation advice needed.

> A resource limit for mmap in total would solve the problem though. RLIMIT_AS? you'll have to add support to set it in MD code, but eg. these lines should help. 465:uvm_init_limits(struct proc *p) [..] 479:p->p_rlimit[RLIMIT_AS].rlim_cur = RLIM_INFINITY; 480:

re: gcc: optimizations, and stack traces

Andrew Cagney writes: > On 23 February 2018 at 03:41, Maxime Villard wrote: > > > Many of our ASM functions don't push frames, but that's a different issue. > > /me mumbles something about the assembler needing to be marked up with > .cfi directives yup -- with proper

re: setting DDB_COMMANDONENTER="bt" by default

> >> eg, make it look like, with new "dumpstack" sysctl, defaults > >> to value of 1: > >> > >> if (dumpstack > 0) > >> do current dumpstack method > >> if (onpanic > 0) > >> enter ddb > >> reboot > >> > >> (this idea came from jmcneill@.) > > > > I'll take a look. thanks for

re: setting DDB_COMMANDONENTER="bt" by default

> also the backtrace is not that useful on the default glass console tty > unless you also limit the number of backtrace level with the new sysctl > variable I recently added. if by "default" you mean the KMS one, then there are usually *heaps* of lines available, and video cameras help :-)

re: setting DDB_COMMANDONENTER="bt" by default

Valery Ushakov writes: > 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

re: setting DDB_COMMANDONENTER="bt" by default

Christos Zoulas writes: > In article , > Sevan Janiyan wrote: > >Hello, > >Is there any reason good reason why we should not opt for > >DDB_COMMANDONENTER="bt" by default across the board?? > >We have it set or a

re: modstat and kaslr

Maxime Villard writes: > Hi, > Here is a patch [1] that hides the addresses of the kernel modules when > 'modstat -k' is entered by an unprivileged user. The current behavior is > preserved for root. > > The addresses currently leaked cannot be used to reconstruct the layout of > the kernel,

re: untangling the compat mess

Maxime Villard writes: > Le 06/12/2017 à 21:23, matthew green a écrit : > > kernel libraries are supposed to be built as a .o not a .a, > > for modular/lkm kernels. did this get lost some where? > > libcompat is a .a, I saw that too ah, so that is the underlying problem.

re: untangling the compat mess

Christos Zoulas writes: > In article <27887.1512591...@splode.eterna.com.au>, > matthew green <m...@eterna.com.au> wrote: > >kernel libraries are supposed to be built as a .o not a .a, > >for modular/lkm kernels. did this get lost some where? > >

re: untangling the compat mess

kernel libraries are supposed to be built as a .o not a .a, for modular/lkm kernels. did this get lost some where? ie, if you have a MODULAR kernel, then the build should always include all the library stuff, in libkern, etc. see the KERN_AS variable. sounds like libcompat is not being treated

re: increase softint_bytes

> It'll take a little time to write this change. And, it's low level > and important code, so it will take a time to test the stability > before sending pullup request. So, > > 0) Apply the following change to -current. > > > Index: kern_softint.c >

re: increase softint_bytes

Masanobu SAITOH writes: > Hi, all. > > Some device drivers now allocate a lot of softints. > See: > > http://mail-index.netbsd.org/current-users/2017/11/09/msg032581.html > > To avoid this panic, I wrote the following patch: > >

re: kaslr: better rng

> Ah alright. But in my mail (that you were answering to) I did understand that > the entropy file comes from the previous run; what I was saying was, I would > prefer the file in question to contain random data right away and not just a > seed. In such a way that whoever wants to get random uints

re: kaslr: better rng

> Well, we could indeed extend /var/db/entropy-file. However, I would really > prefer the random area to be generated from a previous run of the system, and > not from the bootloader taking a seed in the file. Unless there is a > combination of both? it would be nice if the lack of this file

re: Deadlock on fragmented memory?

> Thanks for doing this. > > How difficult you gather it would be to convert the execargs to use 4K > pages rathern then continuous KVA, are there any particular gotchas? I > would be interested to look at this - it sounds like nice high-kernel only > project for me, to make a break from the ATA

re: how to tell if a process is 64-bit

Thor Lancelot Simon writes: > On Sun, Sep 10, 2017 at 03:29:22PM +, paul.kon...@dell.com wrote: > > > > MIPS has four ABIs, if you include "O64". Whether a particular OS allows > > all four concurrently is another matter; it isn't clear that would make > > sense. Mixing "O" and "N" ABIs is

re: how to tell if a process is 64-bit

> > In addition to amd64/i386, it occurs to me that sparc64/sparc32 is > > another case; IIRC it's possible to take sparc64 hardware and build a > > (special? not sure) kernel that runs sparc32 userland. I've never > > tried it; I don't know whether sparc32 and sparc64 are as freely > > mixable

re: how to tell if a process is 64-bit

> Is the answer "it's using an ISA with 64-bit registers and addresses"? > This actually can be broken down into the "registers" and "addresses" > portion, but, in practice, the two tend to go together. (Always true > on most "64-bit" ports, a real question on amd64 (and others, if any) > which

re: how to tell if a process is 64-bit

> In a cross-platform process utility tool the question came up how to > decide if a process is 64-bit. > > https://github.com/giampaolo/psutil/issues/1102 > > What's the best answer for NetBSD? in C: internally, just check #ifdef _LP64. externally, kvm_getprocs() with KERN_PROC_PID. in other

re: Proposal: Disable autoload of compat_xyz modules

> > Otherwise it has to be balanced. > > Certainly. It does not seem to me that moving compat_linux* into modules is in > any way illegitimate or unbalanced. That's the opinion I was stating. if you want to move useful and used by a large number of users functionality out of GENERIC and into

re: Proposal: Disable autoload of compat_xyz modules

> compat_linux > compat_linux32 > compat_netbsd32 all of these are used regularly by many netbsd users. please don't include them in your list of targets. saying "modload is OK" is not how we treat the GENERIC kernel -- if it's OK, then it's OK for GENERIC is how we treat that. the latter is

re: Can't compile NetBSD kernel in Virtual Box due to assym.h error

Robert Elz writes: > Date:Tue, 04 Jul 2017 07:24:43 +0100 > From:Robert Swindells > Message-ID: > > | You are running NetBSD/amd64 but trying to build a NetBSD/i386 kernel > | using the native tools, that won't

re: Linux procfs

Robert Swindells writes: > > Do we care about keeping all the Linux procfs code in > sys/miscfs/proc/procfs_linux.c ? > > Some Linux applications have started grovelling in /proc/self/status to > read various values. > > I have added some Linux emulation specific code to procfs_status.c but >

re: ARM pmap

Michael writes: > Hello, > > On Fri, 16 Jun 2017 14:30:18 +1000 > matthew green <m...@eterna.com.au> wrote: > > > > Or just tar xpzf ... - ours at least unlinks files before writing them, > > > install(1) instead of cp(1) for single files. > >

re: ARM pmap

> Or just tar xpzf ... - ours at least unlinks files before writing them, > install(1) instead of cp(1) for single files. FWIW, it's temp file + rename, not unlink. .mrg.

re: ARM pmap

Robert Swindells writes: > > Is there anything in the way that uvm is used on ARM that would break > being able to replace executables that are in use ? > > Trying to update a running system on a CubieTruck causes garbage to be > written to /sbin/init and it fails to start up on reboot. > > I

re: CVS commit: src/sys/sys

> I'm evaluating it from the osabi (pkgsrc term) point of view. I'm > targeting LLDB for 7.99.62+. If the kernel bump approach is reserved for > loadable kernel modules, I will follow this in future changes. it's about whether code is expected to work in that kernel environment or not. it's not

re: Fixed modular kernel path and different kernels

> The 'tarball' variant has other problems, such as "how does the kernel > extract a module from the tarball to facilitate auto-load?" Last time > I looked, there was no kernel version of tar or pax. :) IMHO, Loss of > the autoload capability would severely reduce the useability of modules.

re: Fixed modular kernel path and different kernels

please consider lukem's proposal from a large number of years ago where the kernel + modules are considered a unit and are stored together (in a tarball? in a subdir? details..) doing it like this enables all sorts of useful things to be done besides testing kernel+modules. .mrg.

re: History of disklables

> Do our VAX disk drivers for Unibus/Massbus hardware retain the compiled > in partitioning as a fallback? Without it, it'd be tough to even read > old Unix filesystems without modifying the disk contents (to write either > an Ultrix or 4.4BSD label into place). dkctl(8) in modern netbsd would

re: Another kvm user can go away?

> Yeah, I figured that out after I replied (with the help of Christos's > suggestion. My latest revision uses a 'struct timespec' which has two > 64-bit members, so preserves alignment of subsequent members! this is incorrect. timespec has a time_t (int64) and a long (variable). i didn't see

re: UVM and the NULL page

> There was a bunch of fuss before about being able to "fool" UVM into > mapping at address 0 in spite of this supposedly being disabled; for > some reason the "fix" was to bodge around it rather than to fix UVM to > honor its specification, which I don't understand. If you can fool UVM > into

re: vrele vs. syncer deadlock

> > Some time ago I unconditionally removed LK_NOWAIT from vn_lock(). > > Suppose we need this patch: > > > > RCS file: /cvsroot/src/sys/ufs/ffs/ffs_vfsops.c,v > > retrieving revision 1.341 > > diff -p -u -2 -r1.341 ffs_vfsops.c > > --- ffs_vfsops.c20 Oct 2016 19:31:32 - 1.341 > >

re: spkr vs spkr_synth module

FWIW, pcppi is *not* x86 specific. the module might only be built there today, but that's a build artifact not a code fact. it should probably be built for "all isa" platforms. whatever those are. ideally. .mrg.

re: x86: move the LAPIC va

these CPUs clearly aren't rare and the assertion that it's only old CPUs and ones without lapic is questionable. i see this problem on a pentium4-m system. this change needs to be fixed or reverted. .mrg.

re: D_MPSAFE drivers

co...@sdf.org writes: > Hi! > > Poking around I noticed KERNEL_LOCK is occasionally > grabbed by cdev_* for noticeable periods of time. > > Looking at the code, it grabs DEV_LOCK which is effectively > KERNEL_LOCK if the driver is not declared MPSAFE. > > It appears that many "big name" drivers

re: Signed vs unsigned comparisons in sys/dev/pcio/if_wm.c

> While starting to investigate the possibility of modularizing the > if_wm(4) driver, I discovered some issues where signed expressions are > being compared to unsigned expressions. When if_wm.c is being compiled > as a built-in driver, these errors are ignored. However, when build as > a

re: union wait

David Holland writes: > We still have elements of union wait hanging around in sys/wait.h. > This has been deprecated for > 20 years; does anyone mind if I G/C > them? > > (I think just about all the legacy code in pkgsrc that uses union wait > has been fixed by now as it doesn't exist on a

re: "Wire" definitions and __packed

John Nemeth writes: > On Oct 6, 3:01pm, matthew green wrote: > } > } > X86 doesn't have alignment restrictions. The platform > } > practically lets you get away with murder, and thus is not useful > } > as a test platform. > } > } FWIW, this hasn't been

re: "Wire" definitions and __packed

> X86 doesn't have alignment restrictions. The platform > practically lets you get away with murder, and thus is not useful > as a test platform. FWIW, this hasn't been true since at least 1999 (SSE.) also, while no one uses them, x86 has "alignment checking" options. .mrg.

re: Fixing signal records when ktrace'ing under netbsd32 emulation

couple of comments about the patch itself, not the potentially intrusiveness of it (which i'm not sure is that bad): > - ktrpsig(signo, SIGACTION_PS(ps, signo).sa_handler, > - mask, ksi); > + if

re: -falign-functions=16 for i386/amd64

> dut1# cpuctl identify 0 > cpu0: highest basic info 000b > cpu0: highest extended info 8008 > cpu0: "Intel(R) Atom(TM) CPU C2558 @ 2.40GHz" > cpu0: Intel Atom C2000 (686-class), 2400.27 MHz > cpu0: family 0x6 model 0x4d stepping 0x8 (id 0x406d8) > cpu0: features >

re: -falign-functions=16 for i386/amd64

Ryota Ozaki writes: > On Thu, Sep 1, 2016 at 4:04 PM, matthew green <m...@eterna.com.au> wrote: > > have you tested other values than 1 and 16? what about 4 or 8? > > 4 and 8 are not so good; their performance fluctuations are > similar to the unaligned case in my experim

re: -falign-functions=16 for i386/amd64

have you tested other values than 1 and 16? what about 4 or 8? can you post the size difference of kernels? particularly the kernel without DIAGNOSTIC or DEBUG (since those are the ones where performance matters most.) thanks. .mrg.

re: dump to cgdNb device

> That means that either cpu_dump or the next function returned ENXIO. > The code is very careful to dump only on partitions that are marked as > swap and on devices it knows about to avoid accidents. Dumping on > "software" devices is very dangerous since typically when you are dumping > you've

re: Locking strategy for device deletion (also see PR kern/48536)

>that one i think is a much larger issue that affects *all* of our >drivers and needs a general fix where eg device_lookup_private() >returns a reference counted value that must be returned, before the >module can be considered ready to unload (this still leaves a very >minor

re: Locking strategy for device deletion (also see PR kern/48536)

Paul Goyette writes: > Can anyone suggest a reliable way to ensure that a device-driver module > can be _really_ safely detached? the method the USB drivers use seems to be fairly safe. there's one condition i'm not 100% sure about, but seems unlikely. see the usage of eg, sc_dying in ugen.c.

re: gets in the kernel

Christos Zoulas writes: > > Hi, > > I noticed that gets_s (a bounded version of gets) was added in the kernel. > While this iis nice, it conflicts with the c-11 "Annex K" which has a > different prototype (takes rsize_t instead of size_t). Perhaps we should > rename this to kgets() or getl() now

re: amd64: move proc0's stack

> We can then easily apply a redzone on it, the same way the rest of the system > does under DIAGNOSTIC. please do this. redzones for stacks are extremely useful. thanks! .mrg.

re: device-major question

Kimihiro Nonaka writes: > Hi, > > I found hdmicec and MI com use same device-major "char 260". > Would it be acceptable? > > - sys/conf/majors > device-major hdmicec char 260hdmicec > - > > - sys/conf/majors.tty > device-majorcom char 260

re: MP-safe ifnet with psz & psref

Thor Lancelot Simon writes: > I do not think you should do any extra work to support kvm grovelling. existing tool functionality should not be broken, however. the netstat -i groveller code should be either updated to the new method or converted to a real sysctl, though the current work around

re: struct file reference at VFS level

Emmanuel Dreyfus writes: > matthew green <m...@eterna.com.au> wrote: > > > you do realise that kauth_cred_t is shared across processes in > > some cases but not all, right? > > VFS uses a kauth_cred_t from struct file f_cred field, which is tied to > the stru

re: RAIDframe raidN device order

Edgar Fu? writes: > When I configure my RAIDframe devcices using raidN.conf, I may run into the > problem that after a reboot, the MPT controller may have assigned new pseudo > SCSI Target ID to my SAS discs, so they get different sdN numbers and the > array may fail to configure. > The

re: remove webnfs?

> I wonder if anyone knew we ever had it, I sure didn't. i only did from the very original commit way back when and the "wtf?" that came with it :-) .mrg.

re: missing SDT_PROVIDER_DEFINE(sdt)

Taylor R Campbell writes: >Date: Fri, 1 Apr 2016 12:29:19 +0900 >From: Kengo NAKAHARA > >There is SDT_PROVIDER_DECLARE(sdt) in sdt.h. >http://nxr.netbsd.org/xref/src/sys/sys/sdt.h#416 >However, there is no SDT_PROVIDER_DEFINE(sdt). I think this is >

re: Very slow transfers to/from micro SD card on a RPi B+

Joerg Sonnenberger writes: > On Tue, Jan 19, 2016 at 10:25:46AM -0800, Chuck Silvers wrote: > > I wouldn't want it as a default for everything either, it breaks things > > like xbiff. > > the linux "relatime" thing seems like a reasonable compromise. > > Haven't we been implementing relatime

re: How to identify specific wait-state for a "DE" process?

Stephan writes: > > # crash > > Crash version 7.99.25, image version 7.99.25. > > Output from a running system is unreliable. > > crash> trace/t 0t455 > > trace: pid 455 lid 1 at 0xfe8002ff0ce0 > > sleepq_block() at sleepq_block+0xa2 > > cv_wait() at cv_wait+0x116 > > fd_close() at

re: How to identify specific wait-state for a "DE" process?

> Does anyone have any good suggestions for how to arrange for another > thread/lwp to run so it can remove the extra reference to the logging > descriptor? filemon(4) as written should just be replaced with a method that works without replacing system calls or borrowing fds or any of these

re: raidctl -B syntax

Edgar Fu? writes: > > going on the manual, it's "raidctl -B ". eg, "raidctl -B raid4". > A, yes, of course. Stupid me. > > The other questions remain, though. oster@? :) .mrg.

re: raidctl -B syntax

Edgar Fu? writes: > I'm unsure what the "dev" argument to raidctl -B is: the spare or the > original? > > Suppose I have a level 1 RAID with components A and B; B failed. I add C as a > hot spare (raidctl -a C) and reconstruct on it (raidctl -F B) now I have A > "optimal", B "spared" and C

re: raidctl -B syntax

> I am confident that an I/O error duing reconstruction will result in the > reconstruction failing. it does for RAID1. i've not used RAID5 for years. i had a disk failure, followed by the otherside giving read errors while reconstructing. my rebuild failed sort of appropriately (it would be

re: On softints, softnet_lock and sleeping (aka ipv6 vs USB network interfaces)

Manuel Bouyer writes: > On Sun, Dec 06, 2015 at 04:01:22PM +, Taylor R Campbell wrote: > > [...] > >2) CPU 0 takes clock interrupt and nd6_timer expires. nd6_timer starts > > and > >tries to take softnet lock and blocks > > a callout shout never sleep. When it does, this delays all

re: In-kernel units for block numbers, etc ...

> } A quick test shows that it works with a NFS file. I don't know > } how stable that is. > > It's documented as not working, and I know from experience > that it doesn't work, unless something has changed recently. My > test case, at least the most recent one from memory, has to do with >

re: In-kernel units for block numbers, etc ...

> raidframe I haven't thought about, or investigated, at all. FWIW, i "fixed" raidframe on 4K disks a few years back. i say "fixed" because of the way a lot of storage seems to work, it must continue to be accessed in 4K sector mode. i have a umass adapter that will export >2TB disks as 4K

re: kern_sig.c

> Renaming things is fine, but please try not to break it :-) i'm not sure i agree with any of the proposals here for renaming. these are well entrenched names and concepts here and i don't think we should rename them without significant consideration. i've never had problems with this code

re: Problem with syscall_disestablish() - PR kern/50430

Paul Goyette writes: > > i don't think that filemon(4) is done properly or at the right > > layers. it should hook directly into the vfs layer itself, not > > hijack system calls. it certainly still doesn't work properly > > for netbds32 binaries or any other binaries. > > > > your changes are

re: Problem with syscall_disestablish() - PR kern/50430

> >> - filemon(4) is utterly broken. it literally replaces the sysent > >> values for the current emulation while active. so it has an ugly > >> obvious problem with runtime usage (particularly at unload.) > >> however, a much bigger problem is that it adjusts an emulation > >> that

re: Problem with syscall_disestablish() - PR kern/50430

additional problems i've realised: - this should be process specific, not LWP specific. - we might need some way to copy this across fork(). - as l_sysent seems unreliable, we should just remove it. > In a nut-shell, we cannot rely on the struct lwp's l_sysent member > to determine if a

re: Problem with syscall_disestablish() - PR kern/50430

Martin Husemann writes: > On Tue, Nov 17, 2015 at 05:48:17PM +1100, matthew green wrote: > > it also slows down normal operation adding branches and data access > > to the call path of every system call. and bloats struct lwp and > > more. > > At least all operations

re: Problem with syscall_disestablish() - PR kern/50430

> >>> there's a fairly significant problem with this implementation. > >>> > >>> you're only catching callers who use end up going through sy_call() > >>> and that's not the majority. mostly they're called directly from > >>> MD code. so to fix that, you have to update every platform syscall >

re: Problem with syscall_disestablish() - PR kern/50430

there's a fairly significant problem with this implementation. you're only catching callers who use end up going through sy_call() and that's not the majority. mostly they're called directly from MD code. so to fix that, you have to update every platform syscall handler. it also slows down

re: Questions regarding 'struct modstat'

> >> 3. If I wanted to add another address field (ms_modaddr for the address > >>of the module's 'struct module'), would it be better to > >> > >>a) insert a new uint64_t in the middle of this structure, > >> after the current ms_addr field, > >> > >>b) insert a new uint64_t in

add ability to use syscall debug via kernhist.

hi. i'd been wanting to get this working for a while, and i've finally gotten this to the point it works properly: http://www.netbsd.org/~mrg/scdebug_kernhist.diff it's kind of ugly due to the limitations of kernhist, but it already has proven useful to me, and the ugliness is limited

re: Anomalies while handling p_nstopchild count

i wonder if this is why i occasionally see hangs when trying to suspend processes. this usually happens when i run "some -command | less", and before "some -command" has finished completing (it has blocked due to a full pipe), i hit ^Z. this regularly hangs on me until i kill -9 the "some"

re: Preproc condition for GCC 2.x

Michael McConville writes: > Joerg Sonnenberger wrote: > > On Mon, Sep 14, 2015 at 11:15:34PM -0400, Michael McConville wrote: > > > I suspect that this preproc condition isn't necessary anymore? It's in > > > sys/sys/device.h:246. > > > > We require C99 support for the kernel, so no, just use

re: New sysctl entry: proc.PID.realpath

it seems to me that the "curtain" should control access to this info like it does other process info. see: security.models.extensions.curtain security.curtain sysctl nodes. .mrg.

re: PCI extended configuration support

> - too much ACPI dependence, there's nothing that says you have to use >ACPI MCFG to get this information in particular, there is way too much ACPI specific code in pci_machdep.c with this change. whatever of that code remains should mostly be moved into an ACPI specific file (possibly

re: argument of pci_msi[x]_count()

I don't have a problem with it, I was just questioning the rationale about passing pci_attach_args to functions... the original pci(9) interfaces didn't do this, but a 3rd member of pci_attach_args{} was needed for a new change, so someone (i forget now, but CVS will tell you) changed it to

re: panic: locking xyz against myself (linux DRM?!)

Now, whenever the system is up for a few days, and I didn't think of restarting firefox for a while, it eventually crashes with: panic: kernel diagnostic assertion ((mutex-wwm_state != WW_OWNED) || (mutex-wwm_u.owner != curlwp)) failed: file /usr/src/sys/external/bsd/drm2/linux/

re: panic: locking xyz against myself (linux DRM?!)

I've been offering the attached patch to try to debug the source of the problem before the symptom you described happens. I haven't gotten any diagnostics back from anyone yet. If you can, please try it out and let me know. i've got this running on my laptop but i'm not using it very

re: x96 cannot build without MULTIPROCESSOR

last i tried, it was only a couple of minor fixes needed to make x86 build without MULTIPROCESSOR. i think even one of those got commited by someone else in the meantime... .mrg.

<    1   2   3   4   5   >