On Mon, Aug 15, 2016 at 09:56:09PM +0200, Mark Kettenis wrote:
> The functions that clean/invalidate the caches by virtual address,
> bail out after cleaning 32k worth of data. The 32k matches the L1
> cache of most of the CPUs we current run on. But the Cortex-A7 has an
> integrated L2 cache tha
> On 16 Aug 2016, at 08:28, Mark Kettenis wrote:
>
>> Date: Tue, 16 Aug 2016 08:21:42 +1000
>> From: Jonathan Matthew
>>
>> On Mon, Aug 15, 2016 at 02:47:29PM +0200, Mark Kettenis wrote:
Date: Mon, 15 Aug 2016 22:08:16 +1000
From: Jonathan Matthew
This removes ART's relia
> Date: Tue, 16 Aug 2016 08:21:42 +1000
> From: Jonathan Matthew
>
> On Mon, Aug 15, 2016 at 02:47:29PM +0200, Mark Kettenis wrote:
> > > Date: Mon, 15 Aug 2016 22:08:16 +1000
> > > From: Jonathan Matthew
> > >
> > > This removes ART's reliance on the kernel lock to serialise
> > > updates. I
On Mon, Aug 15, 2016 at 02:47:29PM +0200, Mark Kettenis wrote:
> > Date: Mon, 15 Aug 2016 22:08:16 +1000
> > From: Jonathan Matthew
> >
> > This removes ART's reliance on the kernel lock to serialise updates.
> > I sent out an earlier version of this prior to 6.0, but it didn't make it
> > in.
>
On Mon, Aug 15, 2016 at 06:10:55PM -0400, Ted Unangst wrote:
> same change as for i386, but now for arm and sparcs.
>
ok mlarkin
> Index: arm/arm/mem.c
> ===
> RCS file: /cvs/src/sys/arch/arm/arm/mem.c,v
> retrieving revision 1.16
>
same change as for i386, but now for arm and sparcs.
Index: arm/arm/mem.c
===
RCS file: /cvs/src/sys/arch/arm/arm/mem.c,v
retrieving revision 1.16
diff -u -p -r1.16 mem.c
--- arm/arm/mem.c 15 Aug 2016 22:01:59 - 1.16
++
It looks like we're going to use com(4) on armv7 after all. Given
that we have a device tree there, we have a pretty good idea what UART
type we're driving. So we should be able to avoid the flaky probing
code in com(4). Here is a diff that makes the driver only do the
probing if the uart type w
Yeah, ok in that context, sure.. since this is userspace shit the caching
if any should probably happen there.
On Mon, Aug 15, 2016 at 2:20 PM, Ted Unangst wrote:
> Bob Beck wrote:
> > Note - NFS has similar behaviour ;)
> >
> > at least within a directory. - so this isn't tht "unusual" for no
Bob Beck wrote:
> Note - NFS has similar behaviour ;)
>
> at least within a directory. - so this isn't tht "unusual" for non-local
>
> I'm wondering if this isn't a bit premature Have you looked for other side
> effects of this removal?
I think the nature of FUSE is that it's used with even "fa
Note - NFS has similar behaviour ;)
at least within a directory. - so this isn't tht "unusual" for non-local
I'm wondering if this isn't a bit premature Have you looked for other side
effects of this removal?
On Mon, Aug 15, 2016 at 1:52 PM, Ted Unangst wrote:
> Martin Natano wrote:
> > Watc
The functions that clean/invalidate the caches by virtual address,
bail out after cleaning 32k worth of data. The 32k matches the L1
cache of most of the CPUs we current run on. But the Cortex-A7 has an
integrated L2 cache that is larger. And if you only flush it
partially you may get into troub
Martin Natano wrote:
> Watch this:
>
> $ doas sshfs natano@localhost:/tmp /mnt
> $ cat /mnt/foo
> cat: /mnt/foo: No such file or directory
> $ echo bar > /tmp/foo
> $ cat /mnt/foo
> cat: /mnt/foo: No such file or directory
> $ touch /mnt/foo
> $ cat
Watch this:
$ doas sshfs natano@localhost:/tmp /mnt
$ cat /mnt/foo
cat: /mnt/foo: No such file or directory
$ echo bar > /tmp/foo
$ cat /mnt/foo
cat: /mnt/foo: No such file or directory
$ touch /mnt/foo
$ cat /mnt/foo
bar
Hi,
has somebody else seen something like "Persistent connection issue in
FastCGI" as described in https://github.com/reyk/httpd/issues/49 ?
Reyk
On Mon, Aug 15, 2016 at 02:15:27PM -0300, Daniel Bolgheroni wrote:
> Typo.
>
> s/drirect/direct/
It's in - Thank you!
> Index: bytgpio.4
> ===
> RCS file: /cvs/src/share/man/man4/bytgpio.4,v
> retrieving revision 1.2
> diff -u -p
Typo.
s/drirect/direct/
Index: bytgpio.4
===
RCS file: /cvs/src/share/man/man4/bytgpio.4,v
retrieving revision 1.2
diff -u -p -r1.2 bytgpio.4
--- bytgpio.4 28 Mar 2016 20:08:56 - 1.2
+++ bytgpio.4 15 Aug 2016 17:11:31 -0
On Mon, Aug 15, 2016 at 06:26:44PM +0200, Theo Buehler wrote:
> On Mon, Aug 15, 2016 at 03:33:38PM +0200, Jérôme FRGACIC wrote:
> > Hello tech,
> >
> > I recently use ed(1) to transmit some input lines to another command.
> > However, I remark that after the 'w' command, I can exit ed without any
On Mon, Aug 15, 2016 at 03:33:38PM +0200, Jérôme FRGACIC wrote:
> Hello tech,
>
> I recently use ed(1) to transmit some input lines to another command.
> However, I remark that after the 'w' command, I can exit ed without any
> warnings even if the data were not saved into a file.
>
> Here is an
Hello tech,
I recently use ed(1) to transmit some input lines to another command.
However, I remark that after the 'w' command, I can exit ed without any
warnings even if the data were not saved into a file.
Here is an example :
$ ed
P
*a
A simple line.
.
*w !sed 's/^/#/'
#A simple line.
15
*q
$
On Mon, Aug 15, 2016 at 11:33:18PM +1000, Joel Sing wrote:
> On Monday 15 August 2016 13:04:43 Reyk Floeter wrote:
> > On Sat, Aug 13, 2016 at 02:57:14AM +1000, Joel Sing wrote:
> > > The following diff makes httpd stricter with respect to TLS configuration:
> > >
> > > - Do not allow TLS and non-
I'd like to make sure that bpf_tap(9) does not grab the KERNEL_LOCK().
The reason is to reduce the potential lock ordering problems within PF.
I'm currently using a mutex to serialize buffer changes, but since
bpf_wakeup() will still need the KERNEL_LOCK(), I'm using a task for
that.
Diff below o
On Monday 15 August 2016 13:04:43 Reyk Floeter wrote:
> On Sat, Aug 13, 2016 at 02:57:14AM +1000, Joel Sing wrote:
> > The following diff makes httpd stricter with respect to TLS configuration:
> >
> > - Do not allow TLS and non-TLS to be configured on the same port.
> > - Do not allow TLS options
> Date: Mon, 15 Aug 2016 22:08:16 +1000
> From: Jonathan Matthew
>
> This removes ART's reliance on the kernel lock to serialise updates.
> I sent out an earlier version of this prior to 6.0, but it didn't make it in.
> Since then, we've decided to go with rwlocks in the packet processing path,
>
The wireless stack usually runs its scanning loop once per frequency band.
It begins with 5GHz so that APs on this band are preferred. Within a band,
an AP with the best RSSI (receive signal strength indicator) is chosen,
after matching all other desired parameters such as the ESSID etc.
I am not
> From: David Gwynne
> Date: Sun, 14 Aug 2016 16:26:45 +1000
>
> > On 13 Aug 2016, at 5:48 AM, Mark Kettenis wrote:
> >
> >> From: Martin Pieuchot
> >> Date: Fri, 12 Aug 2016 20:44:04 +0200
> >>
> >> On 08/11/16 06:43, David Gwynne wrote:
> >>> ive been tinkering with per cpu memory in the ke
This removes ART's reliance on the kernel lock to serialise updates.
I sent out an earlier version of this prior to 6.0, but it didn't make it in.
Since then, we've decided to go with rwlocks in the packet processing path,
so here's a version with an rwlock instead of a mutex.
Index: art.c
==
> Date: Sun, 14 Aug 2016 13:59:00 +0200 (CEST)
> From: Mark Kettenis
>
> Here are two diffs for the sunxi armv7 platform that I can't test
> myself. The first one is for sxiahci(4), and changes it to use the
> regulator API to power on the bus. The second one is for sxie(4), and
> changes it to
On 11/08/16(Thu) 16:04, Martin Pieuchot wrote:
> 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
On Sat, Aug 13, 2016 at 02:57:14AM +1000, Joel Sing wrote:
> The following diff makes httpd stricter with respect to TLS configuration:
>
> - Do not allow TLS and non-TLS to be configured on the same port.
> - Do not allow TLS options to be specified without a TLS listener.
> - Ensure that TLS opt
This is one of the quirks of cvs that I have a hard time getting used to:
$ cvs commit
Log message unchanged or not specified
a)bort, c)ontinue, e)dit, !)reuse this message unchanged for remaining dirs
Action: (continue)
I don't think I'll ever want to c)ontinue here because I don't want to
comm
On Mon, Aug 15, 2016 at 11:08:54AM +0200, Martin Pieuchot wrote:
> Using fe80:: as gateway is not be a good idea since by default
> netstart(8) insert:
>
> fe80::/10 ::1 UGRS0 0 32768 8 lo0
>
> As you can see this route is attached to lo0 *and* has RTF_GATEWAY.
>
> T
Using fe80:: as gateway is not be a good idea since by default
netstart(8) insert:
fe80::/10 ::1 UGRS0 0 32768 8 lo0
As you can see this route is attached to lo0 *and* has RTF_GATEWAY.
This contradicts what rt_setgwroute() wants and make the kernel unhappy,
diff belo
On 15/08/16(Mon) 10:25, Claudio Jeker wrote:
> On Mon, Aug 15, 2016 at 08:42:06AM +0200, Martin Pieuchot wrote:
> > On 08/08/16(Mon) 11:48, Martin Pieuchot wrote:
> > > The rtable_walk() & prio bug I just sent a fix for should theoretically
> > > not cause any trouble. Sadly it is piled on top of
On Mon, Aug 15, 2016 at 08:42:06AM +0200, Martin Pieuchot wrote:
> On 08/08/16(Mon) 11:48, Martin Pieuchot wrote:
> > The rtable_walk() & prio bug I just sent a fix for should theoretically
> > not cause any trouble. Sadly it is piled on top of another bug for
> > which a fix is attached.
> >
> >
On Mon, Aug 15, 2016 at 08:41:52AM +0200, Martin Pieuchot wrote:
> On 08/08/16(Mon) 11:42, Martin Pieuchot wrote:
> > On the train back from n2k16 I found the real cause of the hang reported
> > by Dimitris Papastamos [0] and exposed by our recent
> > changes to the routing table.
> >
> > When an
35 matches
Mail list logo
