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
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
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 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 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 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
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 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 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 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 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 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 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
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 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
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 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.
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 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
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 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
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
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, 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
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.
>
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 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
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 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 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 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 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 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 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 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 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, 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 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, 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
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 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
On Wed, Feb 05, 2025 at 09:34:21AM -0800, Jason Thorpe wrote:
> > On Feb 4, 2025, at 11:40 PM, Simon Burge wrote:
> > Emile `iMil' Heitor wrote:
> > --- a/sys/dev/ic/com.c
> > +++ b/sys/dev/ic/com.c
> > @@ -589,8 +589,15 @@ com_attach_subr(struct com_softc *sc)
> >break;
>
On Fri, Feb 07, 2025 at 06:35:04AM +0100, Emile `iMil' Heitor wrote:
> On Wed, 5 Feb 2025, Emile `iMil' Heitor wrote:
> Here are the results of discussions about finally getting rid of delay()
> and instead checking LSR_TXRDY (aka LSR_THRE) or LSR_TSRE (aka LSR_TEMT)
>
> @@ -588,9 +589,13 @@ com_a
So, I don't understand this changes and the followup change by kre.
Why, exactly, do we need "a more secure random generator" to randomly drop
packets from a queue? What was the actual complaint by coverity and why
wasn't it a false positive?
The followup commit by kre partiallly undid the chang
On Tue, Mar 04, 2025 at 01:26:42PM -0800, Jason Thorpe wrote:
> The firmware selects which CPU module gets to boot the system (the
> criteria used is unimportant here), and the UART on that module is
> connected to the console port and the RTC on that module is the
> authoritative RTC for the syste
On Tue, Apr 08, 2025 at 08:47:43AM -0400, Greg Troxel wrote:
> I think that NetBSD should document an unmaintained repo as upstream,
> because it suggests that every change to our tree should be filed as a
> PR upstream. That doesn't seem like a good use of time, adding friction
> without benefit.
On Tue, Apr 08, 2025 at 02:57:03PM -0400, Greg Troxel wrote:
> Christoph Badura writes:
> > With the git export, pulling out changes and submitting them upstream is
> > not difficult.
>
> True, and I didn't mean to say that anyone should be discouraged from
> doing
On Mon, Mar 10, 2025 at 04:43:30PM +0200, Andrius V wrote:
> Taylor has a good analysis and explanation of the issue
> https://mail-index.netbsd.org/netbsd-bugs/2024/03/26/msg082202.html,
> which I also noticed by testing ATA RAID setup on VIA controllers.
> [...]
Good analysis.
> Given that thr
On Tue, Mar 11, 2025 at 04:33:51PM +0200, Andrius V wrote:
> The major difference is that vn_bdev_open() increments
> (*vpp)->v_writecount++;
> That prevents from the v_writecount > 0 assert failure on vn_close()
> (https://nxr.netbsd.org/xref/src/sys/dev/ata/ld_ataraid.c#249)
>
> My only conce
On Thu, Apr 17, 2025 at 08:44:10PM +0300, Andrius V wrote:
> I also came up with one more option to set atac_set_modes to
> sata_setup_channel together with udma option and use null check to set
> via_setup_channel otherwise.
Since you are carefull to test on all the different VIA boards that you
On Sat, Mar 08, 2025 at 11:18:07AM -0800, Jason Thorpe wrote:
> > On Mar 6, 2025, at 1:57 AM, Christoph Badura wrote:
> > My first thought over morning coffe was to add a thin layer on the
> > cnputc/cngetc/cnpollc interface level. Basically have a stack of
> > cn_tabs (
On Sun, May 11, 2025 at 07:34:29AM -0700, Paul Goyette wrote:
> On Sun, 11 May 2025, Greg Troxel wrote:
> >Paul Goyette writes:
> >
> >>>Yup, I think you're missing the fact that all of this relates to the
> >>>ratther new-ish KERNEL_DIR option, support for which was only recently
> >>>completed (
On Mon, May 12, 2025 at 06:45:06PM +0200, Edgar Fuß wrote:
> As suggested privately by riastradh@, I ran the tar command under dtrace
> dtrace -n 'profile:::profile-97 { @[stack()] = count() }' -c ...
> and got output I can't make sense of. I attach the last (top-count) lines.
>
> The first
On Tue, May 13, 2025 at 10:06:16PM +, RVP wrote:
> qemu$ cd /tmp
>
> qemu$ (pax -h; tar -h; xzcat ~/pkgsrc-HEAD.tar.xz) >/dev/null 2>&1
Is that so that the pax and tar executables are paged in entirely?
> qemu$ time -p xzcat ~/pkgsrc-HEAD.tar.xz | tar -xf -; rm -rf pkgsrc
> qemu$ time -p xzc
On Wed, May 14, 2025 at 11:30:56AM +0200, Edgar Fuß wrote:
> EF> The second question is what the single number without a backtrace means.
> CB> That is the number of time that the backtrace was sampled.
> An empty backtrace?
Oops. I missed the word "single".
--chris
On Sat, Jun 14, 2025 at 04:11:33PM -, Christos Zoulas wrote:
> In article <102k6l5$u8i$1...@ciao.gmane.io>,
> Christos Zoulas wrote:
> >In article
> >,
> >Joshua Gillett wrote:
> >>-=-=-=-=-=-
> >>
> >>tech-kern,
> >>
> >>I wanted to follow up. I’m interesting in doing some work on this and
I wanted to reply to this earlier but it is probably better that it took so
long and you nobody commented for a couple of days to drive my point home.
Your message is very difficult to respond to for a number of reasons:
- it's difficult to understand what you are talking about.
- you don't share
On Thu, Jul 10, 2025 at 06:27:59PM +0200, Nemanja Simonovic wrote:
> I tried asking this on users list but got no reply.
I saw it but didn't have time to reply yet.
> When trying to load modules to rump_server I am getting kernel
> "panic: uvm_km_alloc failed". Both with -m parameter and with
> r
On Sat, Jul 26, 2025 at 09:11:44PM +0200, Nemanja Simonovic wrote:
> I've tracked down uvm_km_alloc failed to PaX mprotect restrictions
> for underlying mmap. t_modautoload passes as it has +a +m paxctl
> flags.
Thank your for reporting back the cause of error. That will help other
people in the
60 matches
Mail list logo
