Re: Removing ARCNET stuffs

On Fri, May 29, 2015 at 12:49:18PM +0200, Gert Doering wrote: On Fri, May 29, 2015 at 10:22:35AM +, David Holland wrote: Because of these trends, I've been thinking for a while now that maybe it's getting to be time to fork. That would allow having one project that intends to stay

Re: Removing ARCNET stuffs

On Sat, May 30, 2015 at 11:05:30PM +0200, Johnny Billquist wrote: I would argue that this has happened already - FreeBSD and NetBSD are the results... at least from the outside, this is how it looks like, with FreeBSD focusing on few platforms but modernizing itself quite a bit

Re: Removing ARCNET stuffs

On Sat, May 30, 2015 at 10:45:46PM +0200, Gert Doering wrote: On Sat, May 30, 2015 at 07:37:04PM +, David Holland wrote: I would argue that this has happened already - FreeBSD and NetBSD are the results... at least from the outside, this is how it looks like, with FreeBSD

Re: Removing ARCNET stuffs

On Sat, May 30, 2015 at 10:45:59PM +0100, Dave Tyson wrote: I am with Gerald on this. Having used NetBSD from 0.8 I really appreciate the single source tree for all architectures and the ability to cross build painlessly from different platforms. I also like the community and the fact that

Re: rm(1) CPU hog

On Wed, Jul 01, 2015 at 06:38:54PM +, Taylor R Campbell wrote: Date: Wed, 1 Jul 2015 15:19:53 +0200 From: Edgar =?iso-8859-1?B?RnXf?= e...@math.uni-bonn.de I just noticed a rm(1) of a 6.4G file (WAPBL 16k FFSv2) taking 35 seconds. The astonishing fact was the undelying

Re: [PATCH] Fixing soft NFS umount -f, round 1

On Sat, Jun 27, 2015 at 10:33:42AM +0200, Emmanuel Dreyfus wrote: 1) In umount(8), we called sync(2) before attempting a forced unmount(2), but sync(2) does not return before data is sent to storage, and therefore we never had the opportunity to attempt the forced unmount

Re: [PATCH] Fixing soft NFS umount -f, round 1

On Fri, Jul 03, 2015 at 10:07:28AM -0700, Chuck Silvers wrote: ...however, with a dead nfs server even sync() should time out and fail eventually. The problem is that you can ask VFS_SYNC(9) to wait or not, but there is no such option for sync(2). for a soft mount sync()

Re: [PATCH] Fixing soft NFS umount -f, round 3

On Fri, Jul 03, 2015 at 09:59:40AM -0700, Chuck Silvers wrote: there's not really a good way to fully support intr mode anymore without making a mess of UVM and genfs. [...] anyway, I don't want to derail the fixes for soft mounts with debate about intr mounts. let's finish fixing soft

Re: [PATCH] Fixing soft NFS umount -f, round 1

On Sat, Jul 04, 2015 at 08:43:25AM +0200, Emmanuel Dreyfus wrote: Well, sure, but we were talking about soft mounts. While I suppose it would be nice to be able to umount -f a hard mount too, it doesn't seem like a requirement or even necessarily consistent with the intent of hard

mount_checkdirs

It has been brought to my attention that the logic in mount_checkdirs() both (a) races with fork and (b) is probably compromised by the *at() syscalls. The purpose of the code is to update all processes' current dirs and root dirs that have just been mounted over, so nobody ends up sitting on an

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

On Mon, Aug 17, 2015 at 08:13:33PM +0200, Martin Husemann wrote: On Mon, Aug 17, 2015 at 06:08:32PM +, Stephan wrote: I have just rebooted with WAPBL enabled. Some quick notes: -Creating 1000 files takes 0,25 sec. while almost no xfers happen. (It just goes to the log I guess).

Re: NFS writes being corrupted?

On Mon, Aug 03, 2015 at 02:51:37PM -0700, Jeff Rizzo wrote: I need to look deeper, but a quick test writing lines of ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz Shows that corruption starts when the file is exactly 65536 bytes long (with an 8192 byte page size), with anything

Re: 2*(void *) atomic swap?

On Sun, Aug 09, 2015 at 02:46:44PM -0400, Thor Lancelot Simon wrote: Just for the archive, this effectively means Pentium+. There are actually 486-class SMP systems. Heh. There are 386-class SMP systems (including some massively parallel ones, some of which even ran open-source

Re: Another force unmount failure

On Thu, Jul 16, 2015 at 06:57:30PM +0200, Emmanuel Dreyfus wrote: Hello I discovered another scenario where force unmount could not work: an unresponsive PUFFS filesystem. The filesystem got out of order during an operation where the filesystem root vnode is locked. As a result, trying

Re: LOCKDEBUG_BARRIER in mi_userret (was: Re: Another force unmount failure)

On Fri, Jul 17, 2015 at 06:37:30PM +0200, Emmanuel Dreyfus wrote: `Last locked' tells you the return address of the call to rw_enter that last acquired the lock. (The other addresses may be useful for other lockdebug panics but aren't likely to be of much use here.) Here is the

Re: LOCKDEBUG_BARRIER in mi_userret (was: Re: Another force unmount failure)

On Fri, Jul 17, 2015 at 04:43:36PM +, Taylor R Campbell wrote: (Perhaps we ought to put extra lockdebug crud in vn_lock and a new vn_unlock in order to track these things down more usefully.) Yes please :-) (vn_unlock should exist for symmetry; I've been meaning to institute it for so

Re: LOCKDEBUG_BARRIER in mi_userret (was: Re: Another force unmount failure)

On Sat, Jul 18, 2015 at 04:59:36AM +0200, Emmanuel Dreyfus wrote: David Holland dholland-t...@netbsd.org wrote: That you've leaked a vnode lock. I did not leak anything: this is netbsd-7 PUFFS without any add-on from me :-/ Must have been pooka then :-) but that's what happened

Re: Another force unmount failure

On Thu, Jul 16, 2015 at 07:34:20PM +0200, Emmanuel Dreyfus wrote: David Holland dholland-t...@netbsd.org wrote: Either make vnode locks interruptible, or debug puffs. I favor the former, but lost the argument a few years back. Others (including e.g. yamt) said no. Even

Re: [PATCH] Fixing soft NFS umount -f, round 5

On Sun, Jul 12, 2015 at 06:54:21PM -0700, Chuck Silvers wrote: Now I think it would be nice to also cut coners in VFS_SYNC() when the force flag is used, but that touches filesystem-indpendent code, in dounmount(): if ((mp-mnt_flag MNT_RDONLY) == 0) { error

Re: POSIX.1 semaphores vs message queues

On Fri, Nov 13, 2015 at 08:05:25PM +0800, Paul Goyette wrote: > One final attempt to summarize the objections that have been made: > [snip] One other thing: posix semaphores used to be a module. That code was made the victim^W showpiece for demonstrating how the New World Order was going to be.

Re: Including wapbl.h in various lfs_* source files

On Sat, Nov 14, 2015 at 01:41:00PM +0800, Paul Goyette wrote: > Is there a good reason to continue to include wapbl.h in the lfs source > files? As far as I can see, nothing in lfs uses any of the macros or > structs that are defined in wapbl.h; other than the #include lines, the > only

Re: NFS related panics and hangs

On Thu, Nov 05, 2015 at 10:46:17PM +0100, Rhialto wrote: > > This file (fs/nfs/client/nfs_clvnops.c) is part of a second (dead) nfs > > implementation from FreeBSD. It is not part of any kernel. > > > > Our nfs lives in sys/nfs. > > Ok, why is it included in syssrc.tgz then? > I'd say it

testing wanted: layerfs on -6

I have a candidate patch for kern/28448, which at this point only affects -6 (and -5, but it's presumably not getting fixed there) -- the issue is that lookups of ".." can deadlock. The patch has passed an anita run, so it isn't overtly toxic, but that's not itself all that persuasive. I don't

Re: New manpage: locking(9)

On Tue, Jun 23, 2015 at 06:16:08PM +1000, matthew green wrote: I see no reason to capitulate and drop the original naming, refreshed for the current kernel design in favor of some invented linuxism. You're going to cause massive confusion if you write documentation intended

Re: Threaded file system benchmark

On Sun, Jul 12, 2015 at 03:13:56PM +0100, Mindaugas Rasiukevicius wrote: +#if !defined(BITS_PER_LONG) +#define BITS_PER_LONG __SIZEOF_LONG__*8 +#endif I did not look how exactly is this used, but it is a good idea to use brackets around the expression when dealing with macros.

Re: Brainy: some bugs

On Fri, Aug 28, 2015 at 11:17:24AM +0200, Maxime Villard wrote: _11/ UNINITIALIZED VAR: sys/dev/ic/sgec.c _12/ USE-AFTER-FREE: sys/arch/mips/alchemy/dev/aupcmcia.c _13/ MEMORY LEAK: sys/dev/ic/smc91cxx.c _15/ MEMORY LEAK: sys/arch/acorn26/ioc/arcpp.c _17/ MEMORY LEAK: sys/dev/ic/gem.c

Re: kernel libraries and dead code in MODULAR kernels

On Mon, Aug 31, 2015 at 04:43:17PM +, Eric Haszlakiewicz wrote: > On August 30, 2015 11:31:54 PM EDT, Masao Uebayashi > wrote: > >I believe that the exact problem exists in userland's dynamically > >linked libraries/programs, right? If so, how do they deal with this

Re: Brainy: some bugs

On Sun, Sep 06, 2015 at 02:36:07PM +0200, Maxime Villard wrote: > Le 30/08/2015 06:43, David Holland a ?crit : > > On Fri, Aug 28, 2015 at 11:17:24AM +0200, Maxime Villard wrote: > > > _11/ UNINITIALIZED VAR: sys/dev/ic/sgec.c > > > _12/ USE-AFTER-FREE: sys/arch/

Re: New sysctl entry: proc.PID.realpath

On Mon, Sep 07, 2015 at 09:13:11PM +0100, David Laight wrote: > > There's another problem this thread hasn't mentioned, which is that > > the result of vnode_to_path for non-directories isn't necessarily > > unique or deterministic even if the object hasn't been moved about. > > Perhaps the

spiflash.c process_write()

As noted in passing elsewhere, it seems that process_write() in spiflash.c allocates a scratch buffer on every call... and leaks it on every call too. This clearly isn't a good thing. Meanwhile the size of buffer it tries to allocate doesn't have any obvious bound; I suspect it's limited to

Re: New sysctl entry: proc.PID.realpath

On Mon, Sep 07, 2015 at 11:13:35AM +0200, Joerg Sonnenberger wrote: > > Two nits: > > > > 1) vnode_to_path(9) is undocumented > > 2) it only works if you are lucky (IIUC) - which you mostly are > > > > The former is easy to fix, the latter IMHO is a killer before we expose > > this

Re: Brainy: a few more bugs...

On Fri, Sep 11, 2015 at 09:11:02PM +0200, Maxime Villard wrote: > _26/ INCONSISTENCY: sys/fs/udf/udf_strat_rmw.c [+] rev1.24 : _26/ INCONSISTENCY: sys/fs/udf/udf_strat_rmw.c [+] rev1.24 : Inconsistency at l.622 and l.717. 622:lb_size = lb_size; 717:lb_size = lb_size; Er wut?

Re: Brainy: bug in x86/cpu_ucode_intel.c

On Sun, Oct 04, 2015 at 11:52:18AM +1100, matthew green wrote: > how about this: I would suggest using void * for the unaligned pointer, but other than that looks at least correctly consistent with the discussion here. -- David A. Holland dholl...@netbsd.org

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

On Thu, Nov 26, 2015 at 11:25:21PM +, Michael van Elst wrote: > dholland-t...@netbsd.org (David Holland) writes: > > >The problem I see with carrying around unit values at runtime (besides > >potential overhead) is that at least in FS-level code it'll make a

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

On Fri, Nov 27, 2015 at 05:40:39PM +, David Holland wrote: > On Thu, Nov 26, 2015 at 11:25:21PM +, Michael van Elst wrote: > > dholland-t...@netbsd.org (David Holland) writes: > > > > >The problem I see with carrying around unit values at runtime (besides

Re: kernel memory allocation failures

On Thu, Dec 10, 2015 at 08:41:50PM -0800, Chuck Silvers wrote: > > | > So I propose to always check the return value of allocators with > > | > an 'if' and not a KASSERT. > > | > > | There are some codes like "foo = kmem_alloc(size, KM_SLEEP); > > | KASSERT(foo != NULL)". > > | Should the

Re: kernel memory allocation failures

On Fri, Dec 11, 2015 at 11:00:06AM -0500, Christos Zoulas wrote: > Fixing kmem_alloc() and friends not to fail under certain conditions might > be possible, but it could lead to livelock scenarios where everything is > stuck in the kernel waiting for resources to be freed. That's a deadlock,

Re: In-kernel process exit hooks?

On Thu, Jan 07, 2016 at 07:34:33AM +0800, Paul Goyette wrote: > Based on internal implementation of filemon(4), there is an ordering > requirement imposed on the sequence of events that occur when a process > using /dev/filemon exits. In particular, the file descriptor on which the > device

Re: In-kernel process exit hooks?

On Fri, Jan 08, 2016 at 11:22:28AM +0800, Paul Goyette wrote: > Yeah, I was trying to avoid the change in semantics. :) The fewer things > I touch, the fewer things will go wrong, and I definitely don't want to > break make, which would result in difficulties making[sic] a new version. > :)

Re: amd64 profiling kernel build failure

On Fri, Jan 08, 2016 at 02:33:58PM +0900, Kengo NAKAHARA wrote: > --- a/sys/kern/subr_prof.c > +++ b/sys/kern/subr_prof.c > @@ -48,6 +48,10 @@ __KERNEL_RCSID(0, "$NetBSD: subr_prof.c,v 1.47 2014/07/10 > 21:13:52 christos Exp > #include > #include > > +#ifdef MULTIPROCESSOR >

Re: amd64 profiling kernel build failure

On Fri, Jan 08, 2016 at 06:50:02AM +, David Holland wrote: > > --- a/sys/kern/subr_prof.c > > +++ b/sys/kern/subr_prof.c > > @@ -48,6 +48,10 @@ __KERNEL_RCSID(0, "$NetBSD: subr_prof.c,v 1.47 > 2014/07/10 21:13:52 christos Exp > > #include >

Re: In-kernel process exit hooks?

On Fri, Jan 08, 2016 at 07:08:19AM +, David Holland wrote: > For an example of the right way to do this kind of thing, look in > kern_acct.c. Better example: sys_fktrace, since that uses a file handle. And it does virtually the same thing that filemon's trying to do, except muc

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

On Wed, Jan 06, 2016 at 08:10:36AM +0800, Paul Goyette wrote: > 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? A better suggestion: remove the broken behavior of close(). -- David A.

Re: In-kernel process exit hooks?

On Sat, Jan 09, 2016 at 08:25:05AM +0100, Mateusz Guzik wrote: > >if (!mutex_tryenter(parent->p_lock)) { > >mutex_exit(t->p_lock); > >mutex_enter(parent->p_lock); > > As a side note this looks like a bug. t->p_lock

Re: tmpfs race conditions

On Tue, Dec 22, 2015 at 04:15:47PM +, Christos Zoulas wrote: > 1. Do we have a PR for the MFS umount hang? Don't think so. > 2. Do we have a PR for the TEMPFS race? No. Unless it turns out to be the same as some old existing problem; but it seems to have appeared only within the last few

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

On Thu, Nov 26, 2015 at 11:38:14PM +0700, Robert Elz wrote: > (for 4K sector drives, cgd and lvm both give you 1/8 the space that > you should have had on the device.) Ewww > ccd (especially if combining a 4k byte sector device with a 512 byte sector > device) is simply a mess - perhaps

per-process namespaces

As a few people have heard, I thought up a way to implement per-process namespaces reasonably cheaply without requiring massive rewrites of everything. It is kind of a hack, but not super awful. Preliminary patch is here: http://www.netbsd.org/~dholland/tmp/namespaces-20151127.diff It at

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

On Sun, Nov 29, 2015 at 10:52:18AM +, Michael van Elst wrote: > mlel...@serpens.de (Michael van Elst) writes: > >The bizarre disklabel seems to be another problem. > > vnd.c says: >/* > * For historical reasons, if there's no disklabel >

Re: gets in the kernel

On Mon, Jun 06, 2016 at 04:57:02AM +1000, matthew green wrote: > > 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 >

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

On Tue, Jun 07, 2016 at 06:28:11PM +0800, Paul Goyette wrote: > Can anyone suggest a reliable way to ensure that a device-driver module can > be _really_ safely detached? There's a pserialize scheme for this; see e.g. an old thread called "kicking everybody out of the softc". The catch for

Re: gets in the kernel

On Tue, Jun 07, 2016 at 12:04:26PM -0400, Christos Zoulas wrote: > | How about not giving people the false impression it's part of Annex K? > | > | > gets is not gets either, and so far nobody has complained about it. > > Yes, that was my point. I also wanted to remove gets() in SA

Re: gets in the kernel

On Tue, Jun 07, 2016 at 12:36:54PM +0200, Maxime Villard wrote: > >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 >

Re: gets in the kernel

On Fri, Jun 10, 2016 at 03:13:43PM +, David Holland wrote: > > libsa is just made of many libc-like functions. getl and > > bounded_gets are not close to anything in userland. gets_s is, even > > though it is in annex K. > > It's more important not to let an

Re: gets in the kernel

On Wed, Jun 08, 2016 at 12:52:33PM +0200, Maxime Villard wrote: > Le 07/06/2016 ? 18:04, Christos Zoulas a ?crit : > >On Jun 7, 3:20pm, dholland-t...@netbsd.org (David Holland) wrote: > >-- Subject: Re: gets in the kernel > > > >| On Tue, Jun 07, 2016 at 12:36

struct fid/filehandle size and lfs

A while back the filehandle type for ffs was fixed to have a 64-bit inode number instead of silently truncating to 32 bits. Yesterday I naively merged that change into lfs and it exploded the world. It seems that lfs has an extra 32-bit field in its filehandle (that ffs doesn't) -- it is a copy

Re: cookies and kmem_alloc

On Mon, Jan 25, 2016 at 02:31:15PM -0500, Christos Zoulas wrote: > The directory functions pass around ap_cookies, and ap_ncookies, > but if one uses kmem_alloc() instead of malloc(), there is no way > to kmem_free() the buffer, since we don't pass the size. I suggest > that we add a new field

Re: rccide in amd64 GENERIC

On Mon, Feb 15, 2016 at 01:42:51PM +0100, Edgar Fu? wrote: > Is there a special reason for rccide not being listed (not even > commented out) in the amd64 GENERIC kernel configuration? > Are there any known issues with that driver? Nothing I remember hearing about/seeing... -- David A.

remove webnfs?

One of the less useful things we have hanging around is support for WebNFS, which was something Sun tried to get people to use in place of http a long time ago. Is there any reason to keep it? It is not doing any significant harm (other than it has a tentacle interacting with namei) but it's also

Re: struct file reference at VFS level

On Sun, Apr 24, 2016 at 04:40:43AM +0200, Emmanuel Dreyfus wrote: > > If something in fuse is causing these cases to share the same open and > > thus the same struct file, fuse is broken. Fix fuse first. > > > > If that isn't what's happening, the next possible problem is that > >

Re: struct file reference at VFS level

On Wed, Apr 27, 2016 at 03:58:43PM +, Emmanuel Dreyfus wrote: > On Sun, Apr 24, 2016 at 07:11:37PM +0000, David Holland wrote: > > Since you said fuse has a way to do that but it doesn't work for our > > fuse, I guess the right way forward is to make it work in our fu

Re: struct file reference at VFS level

On Fri, Apr 22, 2016 at 09:10:23AM +, Emmanuel Dreyfus wrote: > I talked to the glusterFS developer that hit the problem about the > requirement. This is to iplement mandatory locks, a feature not available > in UFS. UFS isn't relevant. > Quooted below is the scenario chere the problem

Re: struct file reference at VFS level

On Sat, Apr 23, 2016 at 09:20:28PM +0200, Emmanuel Dreyfus wrote: > > If something in fuse is causing these cases to share the same open and > > thus the same struct file, fuse is broken. Fix fuse first. > > The NetBSD VFS interface does not let underlying filesystem distinguish > different

Re: Audio - In kernel audio mixing

On Sun, May 15, 2016 at 03:54:07PM -0700, Lyndon Nerenberg wrote: > > On most architectures, you can't use the FPU in the kernel at this time. > > Something that's lacking is a portable API that lets problem state > programs tell the kernel they are using the FP etc. registers and > need

Re: Scripting DDB in Forth?

On Mon, May 02, 2016 at 04:59:32AM +0300, Valery Ushakov wrote: > I've accidentally wrote a Forth for sh3 (long story). I thought it > might be interesting to put it into the kernel so that it can be > hooked into DDB. > [...] > Is this something that might be of general interest? Sure...

VOP_PARSEPATH?

The vnode interface has long had a misfeature where inside VOP_LOOKUP the filesystem can choose to consume more of the pathname than the next component. We have two users of this functionality: hfs, which uses it to allow addressing resource forks, and rump, which uses it as a shortcut hack to

Re: VOP_PARSEPATH?

On Sun, Apr 17, 2016 at 03:20:33AM +, David Holland wrote: > So: >- Can anyone think of a magic alternative way to handle these cases > without making an extra vop call? (And without complexifying > VOP_LOOKUP as much of the point of the whole exercise is to simplify &

Re: GSoC-2016

On Thu, Jul 14, 2016 at 08:50:26AM -0400, Christos Zoulas wrote: > | On Wed, Jul 13, 2016 at 02:39:37PM -0400, Christos Zoulas wrote: > | > great, are we doing something about tunefs? > | > | You mean fsck_ext2fs ? > > Tunefs so we can adjust superblock flags. Should we have a

Re: Weird case in vfs_bio.c bwrite

On Thu, Jul 21, 2016 at 01:21:57PM +, co...@sdf.org wrote: > 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

Re: UVM and the NULL page

On Fri, Jul 29, 2016 at 10:08:48AM +0200, Maxime Villard wrote: > >IIRC some software relies on this feature, like emulators/wine. If > >really so then something like a sysctl to allow it again would be helpful. > > I thought about that. The only emulator-related problem I found is [1], >

lfs_lock

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 explanation. -- David A. Holland dholl...@netbsd.org

Re: An anomaly in config(1)

On Sat, Jul 16, 2016 at 02:27:32PM +0800, Paul Goyette wrote: > Is there a reason for emitting these unused externs? "bugs" It's obviously wrong, so I think you should just commit the fix... :-) -- David A. Holland dholl...@netbsd.org

Re: Changing the return value of xxx_attach() from void to int.

On Sat, Jul 09, 2016 at 04:57:20PM -0700, John Nemeth wrote: > A number of people have expressed reservation (bring up memories > of device_t and how long that took to settle out) indicating that > this should be done on a branch or something. Personally, I don't > see the need to do so.

Re: Changing the return value of xxx_attach() from void to int.

On Sat, Jul 09, 2016 at 08:45:15PM -0700, John Nemeth wrote: > } The substance of that reservation is that there's not much point doing > } it without also taking the time to correct the behavior, i.e., back > } out properly if something fails. And that requires attention, not just > }

Re: Allow hdaudio(4) to suspend

On Wed, Jan 25, 2017 at 11:05:04PM +0100, Pierre Pronchery wrote: > Subsidiary question: is there a consensus on the behaviour of the kernel if > a device driver matches, but then really fails to attach? The current design is that it's not supposed to happen - drivers that aren't going to

Re: DISKLABEL_EI option for system with MBR

On Sun, Feb 12, 2017 at 11:06:35AM +0800, Paul Goyette wrote: > 5. Does the current FFS_EI allow for creation of opposite-endian >file systems? I don't see any endian option for newfs(8). Not that I know of. Also, based on things I saw when hacking lfs last year (all of which got fixed), I

Re: DISKLABEL_EI option for system with MBR

On Tue, Feb 14, 2017 at 04:10:11PM -0500, Mouse wrote: > > [B]ased on things I saw when hacking lfs last year (all of which got > > fixed), I wouldn't rely on FFS_EI until someone gives it a good > > thorough audit, preferably with some kind of automated checking tool. > > What sort of

Re: How to read crash log of NetBSD 7.0.2?

On Tue, Feb 28, 2017 at 10:50:04PM +0800, Jia-Ju Bai wrote: > Unluckily, after my driver is loaded, I do not see any my "printf" messages > on the screen before the crash occurs :( Most likely the problem is either it's dying before any of your prints, or it dies and resets itself and clears

Re: What is the best layer/device for a write-back cache based in nvram?

On Fri, Sep 09, 2016 at 11:09:49PM +0200, Jose Luis Rodriguez Garcia wrote: > This is a continuation of the thread Is factible to implement full > writes of stripes to raid using NVRAM memory in LFS. > http://mail-index.netbsd.org/tech-kern/2016/08/18/msg020982.html > > I want to discuss in

Re: Plan: journalling fixes for WAPBL

On Fri, Sep 23, 2016 at 07:51:32PM +0200, Manuel Bouyer wrote: > > > *if you have the write cache disabled* > > > > *Running with the write cache enabled is a bad idea* > > On ATA devices, you can't permanently disable the write cache. You have > to do it on every power cycles. There are

Re: Plan: journalling fixes for WAPBL

On Thu, Sep 22, 2016 at 07:57:00AM +0800, Paul Goyette wrote: > While not particularly part of wapbl itself, I would like to see its > callers (ie, lfs) be more modular! lfs is not related to wapbl, or even (now) ufs. > Currently, ffs (whether built-in or modular) has to be built with OPTIONS

Re: FUA and TCQ (was: Plan: journalling fixes for WAPBL)

On Fri, Sep 23, 2016 at 11:49:50AM +0200, Edgar Fu? wrote: > > The whole point of tagged queueing is to let you *not* set [the write > > cache] bit in the mode pages and still get good performance. > > I don't get that. My understanding was that TCQ allowed the drive > to re-order commands

Re: IIs factible to implement full writes of strips to raid using NVRAM memory in LFS?

some quibbles: On Thu, Aug 18, 2016 at 05:24:53PM +, Eduardo Horvath wrote: > And you should be able to roll back the > filesystem to snapshots of any earlier synchronization points. In LFS there are only two snapshots and in practice often one of them's not valid (because it was halfway

Re: IIs factible to implement full writes of strips to raid using NVRAM memory in LFS?

On Thu, Aug 18, 2016 at 07:58:53PM +0200, Jose Luis Rodriguez Garcia wrote: > > LFS writes the metadata at the same time, in the same place as the data. > > No synchronous writes necessary. > > As I understand LFS needs to do synchronous writes when there is > metadata operations

Re: IIs factible to implement full writes of strips to raid using NVRAM memory in LFS?

On Thu, Aug 18, 2016 at 07:00:02PM +, Eduardo Horvath wrote: > > > And you should be able to roll back the > > > filesystem to snapshots of any earlier synchronization points. > > > > In LFS there are only two snapshots and in practice often one of > > them's not valid (because it was

Re: WAPBL fix for deallocation exhaustion + slow file removal

On Sat, Oct 01, 2016 at 05:00:10PM +, Taylor R Campbell wrote: > It's also suboptimal that we sleep while holding rwlocks for vnode > locks, since rw_enter is uninterruptable, so if a wait inside the > kernel hangs with a vnode lock held, anyone else trying to examine > that vnode will

union wait

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 number of other systems; but if not,

Re: probable slight bug in ds1307 RTC driver for year 2100

On Tue, Oct 18, 2016 at 09:49:34PM +0200, Aymeric Vincent wrote: > in order to avoid breaking working setups using a dsrtc at iic, I > introduced a flag DSRTC_FLAG_YEAR_START_2K to impose a base year of 2000 > on a per-chip basis. The existing code starts at POSIX_BASE_YEAR (1970), > with the

Re: Possible buffer cache race?

On Sun, Oct 23, 2016 at 06:27:09PM +0200, Jarom?r Dole?ek wrote: > I have the filesystem mounted async and the machine has huge amount of > RAM, without logging at the moment. So it's mostly buffer cache > exercise, with i/o spikes on sync. > > I see interesting thing - periodically, all of

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

On Sun, Nov 13, 2016 at 09:33:53AM +0800, Paul Goyette wrote: > 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

Re: spkr vs spkr_synth module

On Sat, Dec 10, 2016 at 10:00:30AM +0800, Paul Goyette wrote: > Yeah. Too bad we don't have the ability to enumerate the set > of "all platforms". We have the same > issue with building pci driver modules for only those platforms > that have pci ... Maybe if modules interacted with

Re: vrele vs. syncer deadlock

On Sun, Dec 11, 2016 at 08:39:06PM +, Michael van Elst wrote: > >On a low-memory machine Nick ran into the following deadlock: > > > (a) rename -> vrele on child -> inactive -> truncate -> getblk -> > > no memory in buffer pool -> wait for syncer > > (b) syncer waiting for locked

Re: vrele vs. syncer deadlock

On Mon, Dec 12, 2016 at 10:55:27AM +0100, J. Hannken-Illjes wrote: > Some time ago I unconditionally removed LK_NOWAIT from vn_lock(). > Suppose we need this patch: You realize that isn't sufficient, right? :-) Although it should stop the deadlock. (see my other mail) -- David A. Holland

vrele vs. syncer deadlock

On a low-memory machine Nick ran into the following deadlock: (a) rename -> vrele on child -> inactive -> truncate -> getblk -> no memory in buffer pool -> wait for syncer (b) syncer waiting for locked parent vnode from the rename This makes it in general unsafe to vrele while holding

Re: Fixed modular kernel path and different kernels

On Sat, Jan 14, 2017 at 04:53:50PM +0100, Thomas Klausner wrote: > Perhaps there are other, even better solutions. My point is, we should > switch away from our current method. > > Am I overlooking something? No. It's the way it is because, mostly, of strident dogmatic insistence on the

Re: Error in comment in sys/mutex.h

On Thu, Jan 12, 2017 at 01:31:17AM +, Taylor R Campbell wrote: >Currently, there's a long comment in src/sys/sys/mutex.h which reads in >part: > >... > * > * MUTEX_OWNER(owner) > * Returns the owner of the adaptive mutex (LWP address). >

Re: vrele vs. syncer deadlock

On Thu, Dec 22, 2016 at 12:57:10PM +0100, J. Hannken-Illjes wrote: > > On 11 Dec 2016, at 21:01, David Holland <dholland-t...@netbsd.org> wrote: > > > > On a low-memory machine Nick ran into the following deadlock: > > > > (a) rename -> vrele on

Re: Plan: journalling fixes for WAPBL

On Mon, Jan 02, 2017 at 01:01:34PM -0500, Thor Lancelot Simon wrote: > On Mon, Jan 02, 2017 at 05:31:23PM +0000, David Holland wrote: > > (from a while back) > > > > However, I'm missing something. The I/O queue depths that you need to > > get peak write performanc

Re: Plan: journalling fixes for WAPBL

(from a while back) On Wed, Sep 28, 2016 at 02:27:39PM +, paul.kon...@dell.com wrote: > > On Sep 28, 2016, at 7:22 AM, Jarom?r Dole?ek > > wrote: > > I think it's far assesment to say that on SATA with NCQ/31 tags (max > > is actually 31, not 32 tags), it's

Re: Plan: journalling fixes for WAPBL

On Fri, Sep 23, 2016 at 08:51:30AM -0600, Warner Losh wrote: > [*] There is an NCQ version of TRIM, but it requires the AUX register > to be sent and very few sata hosts controllers support that (though > AHCI does, many of the LSI controllers don't in any performant way). I (somewhat idly)

Re: UVM and the NULL page

On Tue, Dec 27, 2016 at 11:15:59AM -0500, Mouse wrote: > >> Perhaps it's time to implement null pointers as something other than > >> all-bits-zero? > > Wouldn't help much; the next obvious (probably only viable) candidate > > is all-bits-1 and then you just need a slightly larger offset from

<    1   2   3   4   5   6   7   8   >