On Wed, Oct 30, 2024 at 08:53:25PM -0400, Greg Troxel wrote:
> I wrote a script:
>
> create 100 dirs with 100 files each
> sync
> sleep 10
> remove the files
> sync
I've meant to reply early. One question would be if the files need to
contain any data or if rm'ing a bunch of zero-lengt
On Sun, Aug 11, 2024 at 02:08:32PM -0400, Greg Troxel wrote:
> Christoph Badura writes:
>
> > Currently the vio9p driver is commented out in {i386,amd64}/conf/GENERIC:
> > #vio9p* at virtio? # Virtio 9P device
> >
> > The obvious way to enab
NB: redirecting followups to tech-kern.
Currently the vio9p driver is commented out in {i386,amd64}/conf/GENERIC:
#vio9p* at virtio? # Virtio 9P device
The obvious way to enable that is by adding a line to GENERIC.local:
vio9p* at virtio?
But doing so
On Tue, Jun 27, 2023 at 11:30:24AM -0400, Mouse wrote:
> It's a normal state to be in. But, as I read it, the post was asking
> for a way to reach that state _without_ passing through a "has a name
> in some directory" state; it's not clear to me whether that's possible
> in general (ie, without d
On Wed, May 26, 2021 at 05:02:52AM +1000, matthew green wrote:
> > > +options HZ=8000
> this can become a problem due to integer division.
>
> any number of ticks less than hz (8000) will be rounded
> down to 0 in a number of places now, where as before it
> was only less than 100. i've seen thi
On Tue, May 25, 2021 at 04:04:56PM -0400, Mouse wrote:
> > I suppose it's not possible to configure ahcisata in the BIOS on the
> > long-delay machines?
>
> Thank you very much! Yes. That is possible - and it fixes the delay.
> I would not have thought to look for that; I would not have expected
On Mon, Nov 18, 2019 at 02:26:17PM -0800, Jason Thorpe wrote:
> > On Nov 18, 2019, at 1:13 PM, Mouse wrote:
> > All you need is a second magic block number. Block number zero is
> > already reserved for holes. Making, say, block number 1, or -1, or
> > some such, reserved to represent "block-of-
On Tue, Sep 10, 2019 at 09:45:50PM +0200, Christoph Badura wrote:
> This is to catch the following case(s): The file might have the
> following permissions "--x--x--x" (or equivalent where the open()ing
> process doesn't have read or write permission).
On Tue, Sep 10, 2019 at 07:31:47PM +0200, Kamil Rytarowski wrote:
> On 10.09.2019 18:21, David Holland wrote:
> > > O_EXEC should be tunable in runtime, with:
> > > fcntl(fd, F_SETFL, fcntl(fd, F_GETFL) | O_EXEC);
> > Why? You can't do that with O_WRITE.
> I don't know. I was looking for a corne
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 Linux-compatible futex
> implementation written by Taylor (that led me down the
On Sat, Feb 16, 2019 at 09:02:05PM -0800, John Nemeth wrote:
> On Feb 16, 11:25pm, Kamil Rytarowski wrote:
> } Where and how to reserve these major numbers?
>
> The ideal thing is to not reserve numbers at all and have them
> allocated dynamically. This requires the module reporting the
> nu
On Mon, Jan 21, 2019 at 11:44:04PM +0100, Christoph Badura wrote:
> On Tue, Jan 22, 2019 at 08:32:48AM +1100, matthew green wrote:
> > > > @@ -472,6 +472,9 @@
> > > > const char *bootname = device_xname(bdv);
> > > > size_t len = strlen(bootn
On Tue, Jan 22, 2019 at 08:32:48AM +1100, matthew green wrote:
> > > @@ -472,6 +472,9 @@
> > > const char *bootname = device_xname(bdv);
> > > size_t len = strlen(bootname);
> > >
> > > + if (bdv == NULL)
> > > + return 0;
> > > +
> >
> > This looked suspicious, even before I read th
On Mon, Jan 21, 2019 at 04:24:49PM -0500, Greg Troxel wrote:
> Separetaly from debug code being careful, if it's a rule that bdv can't
> be NULL, it's just as well to put in a KASSERT. Then we'll find out
> where that isn't true and can fix it.
I must not be getting something. If rf_containsboot
On Mon, Jan 21, 2019 at 06:36:37PM +0100, Christoph Badura wrote:
> I think the following is better. Compile-tested only for both #ifdef
> conditions, but I think that is OK.
Ugh. I forgot to put a comment on that function. How about this:
/*
* Provide a wrapper around rf_containsboo
On Mon, Jan 21, 2019 at 10:42:10AM -0500, Greg Troxel wrote:
> Christoph Badura writes:
> > Index: rf_netbsdkintf.c
> > ===
> > RCS file: /cvsroot/src/sys/dev/raidframe/rf_netbsdkintf.c,v
> > retrieving
Here is some instrumentation I found useful during my recent debugging.
If there are no objections, I'd like to commit soon.
The change to rf_containsroot() simplifies the second DPRINTF that I added.
Index: rf_netbsdkintf.c
===
RCS
On Sun, Jan 13, 2019 at 08:45:31AM -, Michael van Elst wrote:
> b...@bsd.de (Christoph Badura) writes:
> >> So, assuming 'raid0' has a component 'dk0' which is based on 'wd0', it
> >> should work to specify 'wd0' as bootdev.
>
On Tue, Jan 08, 2019 at 09:28:07PM -, Michael van Elst wrote:
> b...@bsd.de (Christoph Badura) writes:
>
> >With "raidctl -A softroot raid0" the XEN3_DOM0 kernel does not detect
> >raid0 as root device.
>
> raidframe checks if the system was booted from o
I have a Xen server with two disk, gpt partitioned, raidframe mirrors on the
dk(4) devices. That system boots off an USB flash key.
With "raidctl -A softroot raid0" the XEN3_DOM0 kernel does not detect
raid0 as root device.
It also doesn't detect raid0 as root device when
the dom0 kernel is loa
On Tue, May 03, 2016 at 12:20:41PM +, Emmanuel Dreyfus wrote:
> Well, I need you to explain me what happens in sys_flock() then.
> Is it a bug?
> error = VOP_ADVLOCK(vp, fp, F_UNLCK, &lf, F_FLOCK);
>
> fp is struct file. Same thing happens in open_setfp() and closef()
sys_floc
On Tue, May 03, 2016 at 08:20:02AM +, Emmanuel Dreyfus wrote:
> On Tue, May 03, 2016 at 09:30:22AM +0200, Christoph Badura wrote:
> > - for the write case
> >off = current_file_offset
> >VOP_ADVLOCK(F_WRLCK, off, size_of_write)
> >VOP_WRITE(...)
>
On Tue, May 03, 2016 at 05:33:34AM +0200, Emmanuel Dreyfus wrote:
> Christoph Badura wrote:
>
> > Mandatory file locking simply is a SMOP for the kernel to add a flag to a
> > vnode that indicates whether mandatory locking is in effect and adding the
> > necessary che
On Mon, May 02, 2016 at 07:15:12AM +, Emmanuel Dreyfus wrote:
> NetBSD filesystems implement advisory locks, where the only place the
> filesystem actually check locks as VOP_ADVLOCK. Any other operation
> performed on a file region locked by someone else succeeds: the locks
> are only advisor
On Fri, Apr 15, 2016 at 12:52:36AM -0400, Thor Lancelot Simon wrote:
> It definitely does for me (that same dd, but from /dev/rsd0d, goes to
> 60% "Interrupt" time on pkgbuild). I can't help noticing everyone who
> doesn't see the problem is using wd, while I see it with ciss or arcmsr.
I didn't
On Sun, Mar 13, 2016 at 07:08:04PM -0400, Thor Lancelot Simon wrote:
> I had occasion a couple of days ago to try to block-copy a very large
> filesystem from a xen dom0 to another machine across a fast local network.
> [...]
> Shockingly, I saw the system go to 0% idle time, with 45-55% "Interrupt
On Sat, Mar 21, 2015 at 10:31:17AM +, Taylor R Campbell wrote:
> I don't see why that wouldn't work: you're just ignoring the update of
> timeout and repeating the bookkeeping yourself.
Hmm, right. Lucky for the people who do the mechanical conversion without
thinking, which was my point.
I
On Fri, Mar 20, 2015 at 01:37:59PM +, Taylor R Campbell wrote:
> int cv_timedwaitns(kcondvar_t *, kmutex_t *, struct timespec *);
> int cv_timedwaitns_sig(kcondvar_t *, kmutex_t *, struct timespec *);
To me the small difference in the name doesn't adequately reflect the
semantic difference
I want to enable the build of ubsec(4) as a module in sys/modules/Makefile
for all arches that have PCI bus and a reference to ubsec in some kernel
config file.
Reading sys/modules/Makefile I found little guidance. I get the
impression that this hasn't been tried before.
I've come up with the fo
On Tue, Nov 19, 2013 at 04:02:51PM +0100, Christoph Badura wrote:
> After updating my -current kernel from 6.99.24 to 6.99.27 so I could
> commit my ubsec(4) changes I noticed that under 6.99.27 I get between
> 3 and 8 percent less throughput on accelerated crypto ops.
I was able to pin
After updating my -current kernel from 6.99.24 to 6.99.27 so I could
commit my ubsec(4) changes I noticed that under 6.99.27 I get between
3 and 8 percent less throughput on accelerated crypto ops.
Note that I am using the exact same ubsec(4) code[1] with both kernels, so
I think it is unlikely a
On Mon, Nov 18, 2013 at 12:31:41PM +1100, matthew green wrote:
> i would buy this argument if mmap()ing a large sparse file
> and filling it up randomly (but with relatively large chunks
> at a time) did not lead to severely fragmented files that
> can take 10x to read, vs one written with plain se
On Fri, Nov 01, 2013 at 01:06:07PM -0400, Greg Troxel wrote:
> This patch to netbsd-5 adds pps support to ucom(4), which should enable
> pps on all usb serial chips that report modem control changes.
> [...]
> I am inclined to port this change to -current, compile-test it, and
> commit it. Objecti
On Fri, Nov 15, 2013 at 08:57:26AM -0800, Matt Thomas wrote:
> it's intentional. dmamap create/destroy can't be done from interrupt
> because they allocate memory. besides mbufs, memory can't be
> allocated. I don't agree with the softintr restriction (where else
> can drivers allocate).
Bummer.
While trying to port BCM586x support I discovered that I get the following
panic under -current. The same code works fine on -6. What gives?
panic: kernel diagnostic assertion "((!cpu_intr_p() && !cpu_softintr_p()) ||
(pc->pc_pool.pr_ipl != IPL_NONE || cold || panicstr != NULL)" failed: file
"
On Tue, Oct 15, 2013 at 06:01:29PM -0300, Lourival Vieira Neto wrote:
> > Also, having to switch mentally between zero-based arrays in the kernel C
> > code and 1-based arrays in the Lua code make my head ache.
> It's something that doesn't bug me so much.. But, if necessary it
> could be changed t
First, I find the usage of the "buf" terminology confusing. In kernel
context I associate "buf" with the file system buffe cache "buf" structure.
Packet buffers a called "mbufs". I would appreciate it if the terminology
was consistent with the kernel or at least not confusing.
Also, having to sw
On Mon, Dec 05, 2011 at 07:33:35PM +0100, Jean-Yves Migeon wrote:
> On Mon, 5 Dec 2011 16:22:33 +0100, Christoph Badura wrote:
> >That is by design. The idea behind splitting the decision process
> >into
> >separate secmodels is to decouple the models and the decision maki
On Mon, Dec 05, 2011 at 02:35:53PM -0500, Elad Efrat wrote:
> What the new API allows is interaction between secmodels that are
> built by people who are not part of NetBSD and don't want their
> secmodel to become part of NetBSD but do want to take advantage of
> features in secmodels provided by
On Tue, Nov 29, 2011 at 02:51:38AM +0100, Jean-Yves Migeon wrote:
> A few weeks back I tried adding a sysctl knob to allow users to control
> their CPU affinity. However, while implementing checks to restrict usage
> of this sysctl, I hit a limitation regarding secmodel(9): the current
> design can
On Tue, Jan 26, 2010 at 03:32:23PM +0100, Manuel Bouyer wrote:
> Can you give more details on the corruption ?
> Was it only directory entries that were corrupted, or did you notice
> corruptions in the data block too ?
I was seeing corruption in data blocks too. That's what I meant, when I
menti
I am seeing FS corruption on my development server in the source trees.
The server is running Xen on i386 with a 128MB RAM dom0 and 256MB RAM domUs.
I'm using netbsd-5 in the dom0 and some domUs -current in other domUs.
Typical ways to provoke corruption is rsync'ing a source tree from the
vnd-bac
42 matches
Mail list logo
