Hi all,
There appears to be a memory corruption bug that only happens on AMD
CPUs running NetBSD (or OpenBSD). The same code doesn't fail on Intel.
This affects Go and they've made some bug reports investigating it[1][2].
People have narrowed it down to this simple Go reproducer
(install
On Thu, Sep 23, 2021 at 02:43:23PM +, coypu wrote:
> Might be an issue for not obsoleting directories on non-DRM archs.
So it wasn't, they are created unconditionally, so I need this
additional change:
---
Squash - directories are created unconditionally. Put back in base/mi
---
dist
This set is only installed on amd64,i386,evbarm.
This set is installed on minimal installs and on install media, in
case someone needs it for basic driver functionality.
Comments:
Switched to a single MK tunable for it - that is probably unneeded.
Might be an issue for not obsoleting directories
Hi David,
On Thu, Sep 23, 2021 at 05:41:45PM +0100, David Brownlee wrote:
> If gpu firmware is somewhat special, is there any sense in moving it
> to /usr/libdata/firmware/gpu/... ?
It's not particularly special, but only some platforms have DRM drivers
and it is about to get fat with the
On Thu, Mar 25, 2021 at 08:36:25PM +, co...@sdf.org wrote:
> Hi all,
>
> I'd like to offer bounties for the following.
> I am also utilizing the wiki to make it easy for others to add their own
> bounties: http://wiki.netbsd.org/projects/funded/
>
>
>
> xHCI resume
Hi all,
I'd normally not be offering bounties again for a while, but nia
reported having the same problem that I spent weeks blindly debugging.
"This one is personal". Story at bottom.
I can offer $500 to a fix for PR 56086: "Resume hangs when tpm(4) is
enabled"
Hint: I suspect that the OpenBSD
Hi all,
I'd like to offer bounties for the following.
I am also utilizing the wiki to make it easy for others to add their own
bounties: http://wiki.netbsd.org/projects/funded/
xHCI resume support
xhci is everywhere, and for many machines, it's the only remaining step
On Tue, Nov 03, 2020 at 10:42:27PM +0100, Martin Husemann wrote:
> On Tue, Nov 03, 2020 at 10:23:30PM +0100, Reinoud Zandijk wrote:
> > To be clear, do we want to (keep) supporting legacy devices? Its not
> > required
> > in 1.0 and could clean up the code a lot!
>
> Yes, we need that still, as
On Tue, Sep 01, 2020 at 01:28:44PM +, co...@sdf.org wrote:
> Hi all,
>
> I'd like to offer a bounty for anyone who is interested in working on
> VirtIO 1.0 support. It's a well-documented, simple interface.
>
> I can offer $750 for anyone to send a patch, or in the case of a
> developer with
On Wed, Oct 21, 2020 at 04:02:41PM +, Eduardo Horvath wrote:
> On Wed, 21 Oct 2020, co...@sdf.org wrote:
>
> > In the event someone adds support for another OS with this problem (say,
> > modern Solaris), I don't expect this compat to be enabled by default,
> > for security reasons. So the
On Tue, Oct 20, 2020 at 07:11:05PM +, co...@sdf.org wrote:
> hello,
>
> As a background, some Linux binaries don't claim to be targeting the
> Linux OS, but instead are "SYSV".
>
> We have used some heuristics to still identify those binaries as being
> Linux binaries, like looking into the
hello,
As a background, some Linux binaries don't claim to be targeting the
Linux OS, but instead are "SYSV".
We have used some heuristics to still identify those binaries as being
Linux binaries, like looking into the symbols defined by the binary.
it looks like we no longer have other forms
Hi all,
I'd like to offer a bounty for anyone who is interested in working on
VirtIO 1.0 support. It's a well-documented, simple interface.
I can offer $750 for anyone to send a patch, or in the case of a
developer with commit access, commit it, for the following:
- 1af4:1044 VirtIO 1.0 random
Disaster averted thanks to how macOS this limitation :)
I have a patch (thanks to nia) that avoids the need for process-shared
semaphores, so we aren't in a bad shape. Will commit soon.
Hi all,
I'd like to call attention to a bug we have:
http://gnats.netbsd.org/55386
At some point Firefox added support for running on multiple OS
processes. To do this, it uses a process-shared semaphores.
We used to not support them properly (rather: lied about supporting
them, but failed to
For some background, I believe this is the device in question:
https://www.ebay.com/itm/Yap-USB-Phone-Software-Yap-Time-Your-Alternative-Phone-/264056870659
It was added in 2001, and I believe it's unlikely to be in use today.
It's pretty easy for a USB device to impersonate another USB device,
Hi tech-kern,
I'd like to propose removing uyurex(4)
This is a driver for a machine created as an elaborate joke in 2008.
http://pinktentacle.com/2008/12/yurex-restless-leg-monitor-by-maywa-denki/
It is disabled by default right now, but still:
- appearing as results when searching for similar
Hi folks,
urio(4) is a driver for Rio 500, an MP3 player released in 1999.
It recently received some discussion due to problems detected
during maxv's USB-fuzzing.
Since I expect there are very few functional devices left, I
am proposing to delete this driver from NetBSD.
I'd also like to
On Sun, Jul 21, 2019 at 04:53:08PM +, Taylor R Campbell wrote:
> It has become popular to redefine the traditional semantics of
> /dev/random or /dev/urandom so that one or both will block once at
> boot until the OS thinks the entropy pool may have been seeded, and
> then never block
I'm just pissed off with the current status quo that we tolerate
everything being broken.
AMD CPUs do not provide hardware RNG.
NVMe isn't used as an RNG source because it would slow it down too much.
netbsd/xen never heard about RNG. Or monotonic time. Why are we using
this to build packages?!
hi,
since netbsd won't stop using broken setups like xen (which don't
provide randomness) to build packages, why don't we give up on
/dev/random entirely?
On Tue, Jul 02, 2019 at 07:18:31AM -0700, Jason Thorpe wrote:
> There is a lot of code still using the old names, but using #define is the
> wrong way to provide it.
>
> I would suggest changing it to a static inline __unused function instead.
>
> -- thorpej
> Sent from my iPhone.
>
> > On Jul
Hi folks,
I'm working on an import of a giant pile of code, and ran into the
following build error:
drm_gem.c:987:23: error: macro "free" requires 2 arguments, but only 1 given
obj->funcs->free(obj);
^
This was confusing for a bit, but apparently is due to
On Mon, Feb 18, 2019 at 01:03:03AM +0100, Christoph Badura wrote:
> On Sun, Feb 17, 2019 at 01:48:52PM -0800, Jason Thorpe wrote:
> > > On Feb 17, 2019, at 1:32 PM, co...@sdf.org wrote:
> > > the linux equivalent code seems to be using futex_wait/wake.
> >
> > I’m working on integrating a new
Hi folks,
Do we have anything that resembles EVFILT_USER?
Apparently, it makes it possible for userland to send events around.
This came up in a programming language port.
https://github.com/ziglang/zig/blob/master/std/event/loop.zig
I assume (based on a superficial reading) that I would like
On Sat, Jan 26, 2019 at 12:38:09PM +0900, Tetsuya Isaki wrote:
> At Wed, 23 Jan 2019 16:32:01 +,
> co...@sdf.org wrote:
> > > the latency issue doesn't matter;
> > Using an AMD Ryzen 7 2700X (or: this machine isn't weak):
> >
> > > mpv --no-video "https://www.youtube.com...;
> > PID
> the latency issue doesn't matter;
Using an AMD Ryzen 7 2700X (or: this machine isn't weak):
> mpv --no-video "https://www.youtube.com...;
PID USERNAME PRI NICE SIZE RES STATE TIME WCPUCPU COMMAND
4908 fly 250 299M 41M CPU/0 2:32 98.83% 98.78% mpv
Thanks.
I'm not sure if it is a sufficient explanation though, there's a
CFATTACH_DECL_NEW(pckbc_acpi, ...
but no
CFATTACH_DCEL_NEW(pckbc, ..
Or does that work somehow?
Hi folks,
looking at port-i386/43331 I came across pckbc_cd.
It doens't appear to be defined anywhere or initialized, though there's
an extern in sys/arch/i386/pnpbios/pckbc_pnpbios.c
How does this work? how does it compile?! :-)
Hi,
Is named semaphores the only way to have locking shared across
processes?
Thinking of:
1. Implementing shared process lock using named semaphores
2. Using this to implement locked atomics for machines with insufficient
atomic instructions
> there's always the Attic
I'm currently using a custom kernel with a driver from netbsd-8
(nouveau), it was surprisingly painless to put the old version in.
(in case anyone is curious, copy sys/external/bsd/{common,drm2}. Of
course, I should attempt to fix it, but I like to be able to run
On Mon, Nov 12, 2018 at 10:23:26AM -0500, Greg Troxel wrote:
>
> co...@sdf.org writes:
>
> > This is an automatically generated list with some hand touchups, feel
> > free to do whatever with it. I only generated the output.
> >
> > ac100ic
> > acemidi
> > acpipmtr
> > [snip]
>
> I wonder if
This is an automatically generated list with some hand touchups, feel
free to do whatever with it. I only generated the output.
ac100ic
acemidi
acpipmtr
acpismbus
act8846pm
addcom
altmem
am2315temp
applesmc
aps
aria
atppc
auvitek
axp809pm
az
azalia
because
boca
btvmei
btvmeii
cec
cir
clcd
cms
hi,
attached is the generated output of a filedesc(9) rewrite.
The source to generate it is less important, but also available here:
http://coypu.sdf.org/filedesc.9
Most of the changes were rewriting the functions to describe the new API
names and signatures.
I tried to add some more functions
Hi folks,
I've been requested to rewrite filedesc(9) (the manual page, not the
API) as it describes the old API.
I noticed we have fd_putvnode with these two matches in src/sys:
kern/kern_descrip.c
140:__strong_alias(fd_putvnode,fd_putfile)
sys/filedesc.h
205:void fd_putvnode(unsigned);
On Mon, Aug 06, 2018 at 11:02:45AM +1000, matthew green wrote:
> 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
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 it reaches a point where the screen
On Tue, Jul 24, 2018 at 05:46:16PM -0400, Thor Lancelot Simon wrote:
> On Tue, Jul 24, 2018 at 07:01:36PM +, co...@sdf.org wrote:
> > hi netbsd,
> >
> > if I were to state I totally need hashtables, what already existing API
> > would you tell me to use instead?
>
> The kernel has lots of
hi netbsd,
if I were to state I totally need hashtables, what already existing API
would you tell me to use instead?
I am porting code:
https://github.com/torvalds/linux/blob/605dc7761d2701f73c17183649de0e3044609817/drivers/gpu/drm/i915/i915_cmd_parser.c#L842-L852
im probably not qualified to give an explanation but:
as i understand it, rcu is supposed to be a synchronization mechanism
that produces less contention/locks.
suppose we store our objects in a linked list:
[A] -> [myobj] -> [C]
In order to write, we can change the linked list to look like
hi folks,
in
https://github.com/NetBSD/src/commit/a9e749a2e2d0044b947401ce80790a5788fad76e#diff-9353912fc541114002b043446f11751e
bouyer had moved many definitions out of usbhid.h.
This is a user-visible header and appears in third party packages, which
now need even more ifdefs, and those need
Thanks for confirming! :-)
I'll still hold my original promise of waiting a month to do so.
Hi,
The code in sys/dev/pci/n8 has bitrotted - it still makes references to
LKM_ system things, so it is unlikely it builds.
This has been the case since netbsd-6.
I am interested in removing this because while playing with a
text-processing tool to look for bugs, I came across this and spent
Hi folks,
we have two ports of linux drm code. old drm, which exists because not
all devices/drivers work with the newer, also non-x86 architectures use
this.
new drm ("drm2") which hopefully we'll transition to.
there are two via drivers:
viadrmums (drm2)
viadrm (old drm)
according to PR
Hi,
Currently Apollo Lake CPUs fail to boot with SMP enabled.[1]
This is because we use MONITOR/MWAIT with interrupts disabled for
waiting for secondary CPUs to hatch.
Errata means the wakeup doesn't happen.[2]
I've written the attached patch, and tested it by matching my existing
CPU which
tuff.
I'm omitting the actual firmware from the diff because it's big and
binary.
Let me know what you think. I will commit this in a few days if nobody
objects.
>From 4df83365c365371a15d2f6d837bd906add23bee0 Mon Sep 17 00:00:00 2001
From: coypu <co...@sdf.org>
Date: Fri, 4 May 2018 0
OK to commit this? I don't have any of the devices unfortunately.
G/C custom rateset definitions.
use standard where applicable.
Built tested only.
Index: dev/ic/atw.c
===
RCS file: /cvsroot/src/sys/dev/ic/atw.c,v
retrieving
14b Mon Sep 17 00:00:00 2001
From: coypu <co...@sdf.org>
Date: Tue, 24 Apr 2018 19:54:27 +0300
Subject: [PATCH 1/1] add RTS525A support. From openbsd.
---
sys/dev/ic/rtsx.c | 26 ---
sys/dev/ic/rtsxreg.h | 8 ++
sys/dev/ic/rtsxvar.h | 10 ---
sys/dev/pci/r
Hi I am looking at code related to PR 53096 (really important please
look at it too), I came across this code, in vfs_vnode.c vrelel:
732 mutex_exit(vp->v_interlock);
733 error = vn_lock(vp,
734 LK_EXCLUSIVE | LK_RETRY | (force ? 0
Hi folks.
I've been trying to use a lemote yeeloong. it has internal usb wifi and
usb is on pci.
wifi occasionally works fine, and sometimes it will say 'ehci_sync_hc
timeout' and fail to work until I reboot.
I'm wondering what it could be, but don't know what to look for. some
low power mode
Hi folks.
Spectre is also a vulnerability. It's been discussed in the context of
web browsers, but it does have repercussions for kernel.
The gist of it seems to be, if you have code that looks like this:
Variant 1:
if (malicious offset is safe)
value = array[malicious_offset];
value2 =
This leaks information that unprivileged user probably has no reason to
own:
> cat /dev/ksyms > ksyms
> readelf -a ksyms |wc -l
47594
Any strong reason not to apply the following?
Presumably it will have benefits for GENERIC_KASLR, or people with
Intel CPUs :-)
Index: MAKEDEV.tmpl
Hi folks,
as I understand, a reason to have page coloring is extra broken MIPS
hardware which has cache aliasing issues unless a large page size
is used. picking the same color avoids aliasing.
now, looking at uvm_pagealloc_pgfl:
do {
/* trying to find pages in color.. */
/*
Summarising our IRC discussion:
"someone" (aka joerg):
hashing on paddrs is probably subpar, it's as much work but without
balancing.
the free pagequeue is a good first goal, and contention on it leads
to contention on the non-free pagequeue too.
frustrated we have per-CPU and global free page
hi folks.
I wonder why we are not using a hashed lock for uvm_pageqlock.
(lock only some of the pages for most accesses). but someone
called it a 'brute force' method.
I can't think of a more sophisticated or clever thing to do.
ideas?
Hi,
COMPAT_IRIX needed e_fault, an alternative implementation of uvm_fault.
But it's been removed. can I remove e_fault from the struct, or would
this break compat too hard?
Its sole use is a check in mips/trap.c. I would like to remove this,
too.
On Thu, Nov 16, 2017 at 09:54:44AM -0500, Mouse wrote:
> They are generated by _newfs_ and left untouched thereafter.
Interesting, thanks. what's so useful about the superblock at newfs
time? is that for disaster recovery when half my drive is gone and I
might be able to salvage something from a
Hi folks.
>From the looks of it, the ext2fs code only updates the primary
superblock:
/*
* Write a superblock and associated information back to disk.
*/
int
ext2fs_sbupdate(struct ufsmount *mp, int waitfor)
{
struct m_ext2fs *fs = mp->um_e2fs;
struct buf *bp;
int error
I'm not sure if the licensing is needed also to use it on netbsd, or
just for windows usage where intel also functions as a certificate
authority.
Hi,
this number is way too easy to hit just linking things in pkgsrc. can we
raise it? things fail hard when it is hit.
ive seen people say 'when your build dies, restart it with MAKE_JOBS=1
so it doesn't link in parallel'.
Hi,
callout(9) says:
callout_destroy() destroys the callout, preventing further use.
... The callout should be stopped before callout_destroy() is
called by calling callout_halt(). Note that callout_stop()
shouldn't be used for this purpose.
Some users use callout_stop:
./dev/usb/if_run.c
At the risk of making people angry, this answer works for linux and netbsd:
$ file -L /proc/self/exe
/proc/self/exe: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked, interpreter /usr/libexec/ld.elf_so, for NetBSD 8.99.2, not
stripped
On Wed, Aug 02, 2017 at 06:02:57PM +, Taylor R Campbell wrote:
> % cd www/opera && bmake package
> ERROR: This package has set PKG_FAIL_REASON:
> ERROR: opera-12.16 has an unacceptable license condition:
> ERROR: opera-1200-license
> ERROR: You can mark the license ``opera-1200-license''
Hi,
does rwlock RW_WRITER prevent new readers?
thanks
On Sun, Jun 18, 2017 at 11:19:59AM +0200, Martin Husemann wrote:
> Isn't the idea of blocking with preemption enabled bogus?
>
> So instead of disallowing migration with preemption disabled, KASSERT
> in all blocking primitives that preemption is enabled and fix the fallout
> at the call sites?
Hello tech-kern,
It seems that kpreempt_disable() does not prevent a lwp from
migrating. The assumption that it does is in some places in
NetBSD.
This came up as I am using a non-MPSAFE filesystem (LFS), and had
panics in x86 pmap's pmap_extract, which states it makes this assumption
in a
Martin mentioned it's probably because the kernel is loaded by PMON
(firmware bootloader which speaks ELF) which might be passing the
symbols differently or not at all.
Adding
makeoptions COPY_SYMTAB=1 # size for embedded symbol table
seemed to do the trick, I can even use 'bt' now! :)
On Sun, Apr 30, 2017 at 08:49:04AM +0800, Paul Goyette wrote:
> While working on getting the localcount(9) stuff whipped into shape, I ran
> across a situation where it is desirable to ensure that the current
> process/lwp does not already own a mutex.
>
> We cannot use !mutex_owned() since that
On Mon, Apr 17, 2017 at 12:40:58AM +, Emmanuel Dreyfus wrote:
> On Mon, Apr 17, 2017 at 12:01:38AM +0300, Jukka Marin wrote:
> > I know that there exists hardware that can not control the USB port power
> > supply. At least in the non-laptop world.
>
> In the meantime, I found this that
Have YOU ever wanted to quickly analyze locking on a long function?
well, wait no longer!
I have this function as a script:
$ cat ~/bin/fun
#!/bin/sh
awk "/^$@/,/^}/" *
Example usage:
$ fun lfs_truncate |grep -e mutex -e PUTPAGES
Hi,
I'd like to tackle LFS issues. I've been running it as my root
filesystem to get some real world testing, and it often wedges, and this
with heavy use of KERNEL_LOCK (it's not marked MPSAFE).
I'm still getting to know it, and not there yet.
I don't feel comfortable with how it has its own
On Sun, Feb 26, 2017 at 03:27:05PM +0100, Kamil Rytarowski wrote:
> On 26.02.2017 15:05, co...@sdf.org wrote:
> > On Sun, Feb 26, 2017 at 02:52:39PM +0100, Kamil Rytarowski wrote:
> >> Can we have something like MAP_NOMPROTECT? Something like it would be
> >> used to mmap(2) RWX region:
> >>
> >>
On Sat, Feb 25, 2017 at 10:35:27PM +0100, Joerg Sonnenberger wrote:
> the answer can't be
> "disable PAX mprotect on bin/python*"
We could theoretically have python-wx-2.7, infra-wise it's not too
hard, just terrible.
On Sun, Feb 26, 2017 at 02:52:39PM +0100, Kamil Rytarowski wrote:
> Can we have something like MAP_NOMPROTECT? Something like it would be
> used to mmap(2) RWX region:
>
> void *mapping = mmap(NULL, rounded_size, PROT_READ | PROT_WRITE |
> PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_NOMPROTECT, -1,
I've been told to post it here. please cc me for replies. thanks.
npx(4) referred to 387 support for x86 at some point.
it's not really a driver any more. we don't attach npx at acpi, etc.
moreover, all of the code related to it was renamed, so you will be
hard-pressed to find any references to
On Tue, Dec 27, 2016 at 03:26:04PM +, David Holland wrote:
> Userspace memory shouldn't have supervisor execute permission anyway,
> although I suppose x86 can't represent that.
>
Not all x86, but newer CPUs have SMEP/SMAP which do that.
This wine argument is mostly hypothetical. It can run plenty of programs
with the disable in place. I know because I've used it since the change.
See the following:
http://web.archive.org/web/20150324113601/http://wiki.winehq.org/PreloaderPageZeroProblem
On Mon, Dec 26, 2016 at 09:22:29PM +,
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 (wd, nvme) do
not have d_flags
On Fri, Nov 25, 2016 at 08:30:51AM +1100, Nathanial Sloss wrote:
> What is your underlying audio driver, AFAICT it works with hdaudio, uaudio
> and Raspberry Pi vcaudio.
>
I've got multiple possible outputs, but only using one.
one from a graphics card (for HDMI), and some creative labs with
To clarify, I don't consider most of these to be problems.
The only things that are problematic are the underruns and audioctl hanging.
On Wed, Nov 23, 2016 at 12:22:05PM +1100, Nathanial Sloss wrote:
> Hi,
>
> I've made changes to in kernel audio mixing and made them available at
> ftp.NetBSD.org/pub/NetBSD/misc/nat/nextaudio5-kern.gz
>
> This patch includes only changes to audio the synthesized spkr device will be
> in a
On Fri, Oct 28, 2016 at 11:48:19PM +, Christos Zoulas wrote:
>
> cvs update, I fixed it.
>
> christos
Hurray, it works!
I can continue building Firefox, which has hand-written o32 code.
Thanks.
Hi,
I've been trying to run code meant for MIPS o32 ABI on MIPS n32.
Background:
Both of them run under netbsd32 compat (when running mips64).
MIPS o32 ABI calling convention says there are 4 registers meant for
passing arguments, the rest go onto the stack.
Also, o32 has 32bit registers.
So a
This value cannot stay 1.
It should be either 0 (drmkms) or 2.
I find it extremely hard to imagine there's any machine that can suspend
& resume properly with the value of 1 (feel free to tell me about your
15 year old hardware, though).
Pick one, commit.
attached diff for 0.
diff --git
On Sat, Aug 13, 2016 at 05:17:17PM -0400, Thor Lancelot Simon wrote:
> On Fri, Aug 12, 2016 at 07:37:50PM +, paul_kon...@dell.com wrote:
> >
> > It seems sensible. It could be done by a common CRC routine that takes a
> > table pointer argument, then the two specific routines are just
jakllsch disabled gpio at ichlpcib by default with r1.51 of
sys/arch/x86/pci/ichlpcib.c
it is probably the best idea - users typically have no business messing
with it normally, and you can re-enable it by jumping through a few hoops.
thanks!
I have been trying to get suspend working well on my laptop (a very
plain Dell Inspiron n4030), and gpio(4) is the only thing standing in
my way :-)
it's currently enabled by default for GENERIC on amd64:
gpio0 at ichlpcib0: 64 pins
the behaviour is that on first resume, it'll work fine, but
Hi,
I've been reading the vfs code for no reason.
in vfs_bio.c:802 we have:
vp = bp->b_vp;
then we have a test if it's NULL, but strangely, we do not leave the
function, we continue with it.
there is even a call in vfs_bio.c:873
VOP_STRATEGY(vp, bp);
which will still happen for the vp=NULL
On Thu, Jul 14, 2016 at 08:51:45PM +, Michael van Elst wrote:
> dholland-t...@netbsd.org (David Holland) writes:
>
> >Is there any reason lfs is using a global (rather than per-volume)
> >lock? ad@ seems to have introduced it but as usual there's little in
> >the way of reasoning or
I've resorted to taking advantage of the fact I'm running an emulator
and made it print a message to stderr every time it changes the
interrupt level.
Which, conveniently, didn't boot as well (although it got stuck a lot
later).
However, the problem was found:
Seems like all the interrupt code is
On Tue, Jul 05, 2016 at 03:52:21AM +, David Holland wrote:
> On Tue, Jul 05, 2016 at 02:00:35AM +, co...@sdf.org wrote:
> > After failing to fix enough broken things with the interrupt code by
> > reading it, I wanted to try adding some code to let me know when the
> > interrupt level
I was under the impression I am seeing init being forked by the kernel
(which I was told is lwp0), but that is not the case.
This is also not the first fork1 call.
So I am back to looking at machine-dependent code disabling interrupts
and not enabling them back.
Hi,
I've been trying to understand why with DIAGNOSTIC, a pmax kernel panics
at init, with the following:
init path (default /sbin/init):
init: copying out path `/sbin/init' 11
pid 1(init): ABI set to O32 (e_flags=0x1007)
panic: kernel diagnostic assertion "pcb2->pcb_context.val[_L_SR] &
Feel free to ignore, it does work as is!
Sorry for the noise
Replying to myself on tech-kern for the sake of completeness, in case
anyone has similar issues.
For the failure of `cat hugefile.gz | gunzip -` I must use both
PIPE_SOCKETPAIR and SOSEND_LOAN (default on)
I've built a kernel with UVMHIST and DEBUG (and fixed/hacked some of the
fallout) and ran
On Sun, Jun 19, 2016 at 04:25:20PM +0100, Robert Swindells wrote:
>
> You can find what the option does using grep(1). Use the search button
> on the mailing list archives to see if anyone else has had a similar
> problem.
>
> It looks to me as if the only place that it is used is in
>
Hi,
in emulating pmax with gxemul I ran into an issue that:
cat somefile | command
does not work if somefile is bigger than 4096 bytes (but does for
smaller, or if I use 'command somefile' instead).
using 'options SOSEND_NO_LOAN' in the kernel config 'fixes' it.
what will be a good way to
On Thu, Jun 09, 2016 at 08:07:57PM -0700, Michael Plass wrote:
> Does this ring a bell with anybody? The only similar panic on gnats that I
> was able to
> find was closed in 2011. But I've had trouble finding things in gnats before.
>
PR/50381
http://gnats.netbsd.org/50381
Sometimes, I use
On Sat, Jun 04, 2016 at 01:35:16PM -0400, D'Arcy J.M. Cain wrote:
> In fact, cleaning out the source seems like a more beneficial
> improvement than reducing the binary. Save human resources (viewing
> source) over computer resources.
I can personally attest to wasting time looking at some of
How about this change instead?
Still going over the rest of the function calls of wapbl_flush.
>From d51a64a5e9a15169949b8f1442c79060c157536d Mon Sep 17 00:00:00 2001
From: coypu <co...@sdf.org>
Date: Wed, 11 May 2016 13:08:06 +0300
Subject: [PATCH 1/2] assert wl_mtx held in wapbl_transa
1 - 100 of 102 matches
Mail list logo
