Re: per cpu memory in the kernel

On Thu, Aug 11, 2016 at 02:43:16PM +1000, David Gwynne wrote: > ive been tinkering with per cpu memory in the kernel. i think vi threw up a little bit on the diff i sent out, so this should work. it should also work on !MULTIPROCESSOR kernels now. some of that is fixes to the percpu.h bits, but

Add / Amend history info for some utilities in /bin

Hello, Attached diff adds history sections to chio(1), dd(1), echo(1), pax(1), sleep(1) and test(1). Corrects the version info in sync(8). Ammends kill(1) to note originally the command appeared in section eight. Info obtained from the CSRG CD set and hosted copies of man pages at TUHS. By the

Re: socket splice task

On Mon, Aug 08, 2016 at 04:04:33PM +0200, Alexander Bluhm wrote: > On Mon, Aug 08, 2016 at 12:17:30PM +0200, Martin Pieuchot wrote: > > On 07/30/16 02:41, Alexander Bluhm wrote: > > Are you sure it is not set? Or does the scheduler keeps selecting your > > task? > > After some printf debugging I

Re: IP_SENDSRCADDR [2/2] : add cmsg support

On 2016/06/27 13:00, Jérémie Courrèges-Anglas wrote: > Stuart Henderson writes: > > > On 2016/06/15 19:43, Vincent Gross wrote: > >> On Mon, 13 Jun 2016 16:49:01 +0200 > >> Vincent Gross wrote: > >> > > >> > While validating source address inside

Re: fuse needs ufs ihash

Martin Natano wrote: > I'm already working on a diff to decouple fuse from ufs ihash. In the > meantime: Make sure the necessary code is compiled in when fuse is > enabled in the config. Are people building kernels with FFS? This is like the old INET option, which I deleted because it was insane

MP-safe L2 "lookup" w/o atomic operation

One of the remaining SMP issue with our routing table usage is to guarantee that the L2 entry referenced by a RTF_GATEWAY route via the ``rt_gwroute'' pointer wont be replaced/invalidated by another CPU while we are filling the address field of an Ethernet frame. The most efficient way,

Re: Amend history info for some utilities in /bin

Hi Sevan, Sevan Janiyan Solaris wrote on Thu, Aug 11, 2016 at 02:30:05PM +0100: > Thanks Ingo, will man.openbsd.org update automatically at some point > or is it a manual process? http://man.openbsd.org/OpenBSD-current/* updates automatically every night, using snapshots that it downloards

Re: Amend history info for some utilities in /bin

Thanks Ingo, will man.openbsd.org update automatically at some point or is it a manual process? Sevan

fuse needs ufs ihash

I'm already working on a diff to decouple fuse from ufs ihash. In the meantime: Make sure the necessary code is compiled in when fuse is enabled in the config. natano Index: conf/files === RCS file: /cvs/src/sys/conf/files,v

Re: armv7/sxipio ofw_gpio

> Date: Thu, 11 Aug 2016 13:44:06 +1000 > From: Jonathan Gray > > On Thu, Aug 11, 2016 at 05:41:35AM +0300, Artturi Alm wrote: > > Hi, > > > > what's the plan for solving ordering issues for these devices? > > could this be attached 'manually' from sunxi_platform_init_mainbus()

Re: armv7 Cortex-A7 fix

> Date: Wed, 10 Aug 2016 23:11:52 -0700 > From: Chris Cappuccio > > Tinker [ti...@openmailbox.org] wrote: > > On 2016-08-11 08:30, Mark Kettenis wrote: > > > Finally found the pmap bug that kept Cortex-A7 from working. Turns > > > out we have to flush the TLB when removing a

Re: armv7/omap: amdisplay(4)

On Sun, Aug 07, 2016 at 02:16:45PM +0200, Mark Kettenis wrote: > Much lower risk I'd say; it all depends on the quality of the code of Excellent. amdisplay(4) work continues uneventfully. WIP patch below: Index: conf/GENERIC ===

Re: armv7 Cortex-A7 fix

Tinker [ti...@openmailbox.org] wrote: > On 2016-08-11 08:30, Mark Kettenis wrote: > > Finally found the pmap bug that kept Cortex-A7 from working. Turns > > out we have to flush the TLB when removing a L1 slot as well. Already > > committed the diff, but here it is for those that are interested.