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

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: 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: spurious DIAGNOSTIC message "no disk label"

On Tue, Dec 27, 2016 at 06:02:01AM +, Michael van Elst wrote: > >> I'm not sure wether disks without labels could be used at all in > >> 4.3bsd. > > >Those memories are pretty fuzzy, but I _think_ it worked this way: > > >4.3 did not have on-disk disklabels. > > 4.3tahoe added the

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

Re: UVM and the NULL page

On Mon, Dec 26, 2016 at 04:40:16PM -0500, Mouse wrote: > > The only reason I know for mapping address zero [...] > > > Anyway mmap() without MAP_FIXED should never return NULL. > > Perhaps it's time to implement null pointers as something other than > all-bits-zero? Wouldn't help much;

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

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

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: 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: 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

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: 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: 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: 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

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: 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: 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: 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: 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: 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: 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], >

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: 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: 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

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: 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: 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.

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: 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

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 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: 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...

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 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 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: 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: 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 &

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

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: 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.

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: 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: 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: 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: 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: 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: 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 >

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 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: 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

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: 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: 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: 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: 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?

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: 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

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: 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 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: 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: 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: 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: 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: 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: 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: [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: 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: 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

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: [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

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: Guidelines for choosing MACHINE MACHINE_ARCH?

On Wed, Jun 24, 2015 at 04:01:24PM -0700, Matt Thomas wrote: I agree that evb* is confusing and increasingly meaningless and would like to see us transition away from it. I contend that moving to sys/arch/cpu is incorrect which there are multiple MACHINE values for that CPU.

Re: VOP_PUTPAGE ignores mount_nfs -o soft,intr

On Fri, Jun 19, 2015 at 05:42:45PM +, Christos Zoulas wrote: This cv_wait() is tiemout-less and uninterruptible. ioflush will sleep there forever, holding vnode lock. Any other process doing I/O on the filesystem will sleep in tstile waiting for the vnode lock with this path:

Re: VOP_PUTPAGE ignores mount_nfs -o soft,intr

On Sat, Jun 20, 2015 at 12:30:28AM +, Christos Zoulas wrote: Sure. But it also doesn't mean that there should be cases where I/O to the filesystem hangs uninterruptibly. Nothing is supposed to hang in tstile; therefore, this wait is incorrect... Ok, what is it supposed to do?

Re: bottom half (was: New manpage: locking(9))

On Thu, Jun 18, 2015 at 11:14:09PM +0200, Edgar Fu? wrote: 1. I was told that kernel halves are not used in NetBSD. I don't get that. Does NetBSD handle interrupts in a way totally different from BSD? bottom halves in the sense used are a linux thing. -- David A. Holland

Re: Removing ARCNET stuffs

On Mon, Jun 08, 2015 at 07:18:24PM +0200, Anders Magnusson wrote: David Holland skrev den 2015-06-08 19:06: On Mon, Jun 08, 2015 at 04:15:15PM +0200, Anders Magnusson wrote: printfing from the back of the front end is definitely totally wrong in other ways that need to be rectified

Re: Removing ARCNET stuffs

On Mon, Jun 08, 2015 at 04:15:15PM +0200, Anders Magnusson wrote: printfing from the back of the front end is definitely totally wrong in other ways that need to be rectified first :( Hm, I may be missing something, but what is wrong? Where should you print it out otherwise? I would say

Re: retrocomputing NetBSD style

On Mon, Jun 01, 2015 at 03:13:32PM -0700, Greg A. Woods wrote: There's one other thing I ought to mention here, which is that I have never entirely understood the point of running a modern OS on old hardware; if you're going to run a modern OS, you can run it on modern hardware and you

Re: Removing ARCNET stuffs

On Sun, May 31, 2015 at 11:50:24AM +0100, Justin Cormack wrote: On 31 May 2015 at 00:09, David Holland dholland-t...@netbsd.org wrote: I'm saying that, fundamentally, if you want to run gcc4 or gcc5 on a Sparc IPC that you're going to have problems. There is no way around this, except

Re: Removing ARCNET stuffs

On Mon, Jun 01, 2015 at 02:41:22PM -0400, Andrew Cagney wrote: To my mind, and I'm assuming a pure SSA compiler design, having SSA forces issues like: [...] I'm missing something; SSA is just a style of program representation. Yes. Lets think of Static Single Assignment as the

<    1   2   3   4   5   6   7   8   >